Field devices for utility telemetry must use appropriate lightweight protocols so constrained sensors can transmit reliably to the cloud. What should the architecture emphasize?
Select an answer to reveal the explanation.
Short Explanation
Tiny field gadgets cannot speak heavyweight desktop remote-control chatter all day. They need light IoT protocols built for small messages and flaky links. Pick the right radio dialect for the meters, not NFS or email-as-telemetry.
Full Explanation
Constrained field devices need lightweight IoT communication protocols—such as MQTT or similar telemetry-oriented stacks—rather than heavy interactive desktop remoting protocols. Utility telemetry architecture should emphasize protocol selection suited to limited power, bandwidth, duty cycle, and processing on sensors and gateways so readings reach the cloud reliably. Full desktop remote-desktop protocols designed for interactive GUIs are inappropriate as the sole sensor transport and waste constrained device resources. Requiring every sensor to mount NFS file shares across the public internet is insecure and impractical for field meters. Mandating SMTP email as the sole transport for binary meter samples adds overhead and poor delivery semantics for continuous telemetry. Exam caveat: protocol choice is part of IoT design on Cloud+—match device constraints and telemetry patterns, then secure and monitor the path into cloud ingest services. Operational check: standardize on an approved lightweight protocol end to end, test lossy and intermittent network conditions, enforce authentication and encryption, rate-limit anomalous bursts that could indicate faults or abuse, and document how firmware updates are delivered without breaking telemetry.