3.2.4. Design To Withstand Connectivity Failures¶
ID | Priority | Best Practice |
---|---|---|
BP 3.2.4.1 | Required | Synchronize device states upon connection to the cloud |
BP 3.2.4.2 | Highly Recommended | Use device hardware with sufficient capacity to meet your data retention requirements while disconnected |
BP 3.2.4.3 | Highly Recommended | Down sample data to reduce storage requirements and network utilization |
BP 3.2.4.4 | Recommended | Use an exponential backoff with jitter and retry logic to connect remote devices to the cloud |
Architecture Notes - BP 3.2.4.1 - Synchronize device states upon connection to the cloud¶
IoT devices are not always connected to the cloud. Design a mechanism to synchronize device states every time the device has access to the cloud. Synchronizing the device state to the cloud allows the application to get and update device state easily, as the application doesn’t have to wait for the device to come online.
Recommendation 3.2.4.1.1 - Utilize a digital device state digital representation to synchronize device state
- AWS provides device shadow capabilities that can be used to synchronize device state when the device connects to the cloud. The AWS IoT Device Shadow service maintains a shadow for each device that you connect to AWS IoT and is supported by the AWS IoT Device SDK, AWS IoT Greengrass core, and Amazon FreeRTOS.
- Synchronizing device shadows - Device SDKs and the AWS IoT Core take care of synchronizing property values between the connected device and its device shadow in AWS IoT Core.
- AWS IoT Greengrass – AWS IoT Greengrass core software provides local shadow synchronization of devices and these shadows can be configured to sync with cloud.
- FreeRTOS - The Amazon FreeRTOS device shadow API operations define functions to create, update, and delete AWS IoT Device Shadows.
Architecture Notes - BP 3.2.4.2 - Use device hardware with sufficient capacity to meet your data retention requirements while disconnected¶
Store important messages durably offline and, once reconnected, send those messages to the cloud. Device hardware should have capabilities to store data locally for a finite period of time to prevent any loss of information.
Recommendation 3.2.4.2.1 - Leverage device edge software capabilities for storing data locally
- Using AWS IoT Greengrass for device software can help collect, process, and export data streams, including when devices are offline.
- Messages collected on the device are queued and processed in FIFO order.
- By default, the AWS IoT Greengrass Core stores unprocessed messages destined for AWS Cloud targets in memory.
- Configure AWS IoT Greengrass to cache messages to the local file system so that they persist across core restarts.
- AWS IoT Greengrass stream manager makes it easier and more reliable to transfer high-volume IoT data to the AWS Cloud.
- Configure AWS IoT Greengrass core
- Manage data streams on AWS IoT Greengrass Core
- AWS IoT Greengrass Developer Guide
- Run Lambda on AWS IoT Greengrass Core for preprocessing
- The ETL with AWS IoT Extract, Transform, Load with AWS IoT Greengrass Solution Accelerator helps to quickly set up an edge device with AWS IoT Greengrass to perform extract, transform, and load (ETL) functions on data gathered from local devices before being sent to AWS.
- ETL with AWS IoT Greengrass solution accelerator
- Consider using AWS IoT SiteWise for data coming from disparate industrial equipment
- The AWS IoT SiteWise connector sends local equipment data in AWS IoT SiteWise. You can use this connector to collect data from multiple OPC Unified Architecture (UA) servers and publish it to AWS IoT SiteWise.
- AWS IoT SiteWise connector with AWS IoT Greengrass can cache data locally in the event of intermittent network connectivity.
- You can configure the maximum disk buffer size used for caching data. If the cache size exceeds the maximum disk buffer size, the connector discards the earliest data from the queue.
- AWS IoT Greengrass: AWS IoT SiteWise connectors
Architecture Notes - BP 3.2.4.3 - Down sample data to reduce storage requirements and network utilization¶
Data should be down sampled where possible to reduce storage in the device and lower transmission costs and reduce network pressure.
Recommendation 3.2.4.3.1 - Leverage device edge software capabilities for downsampling
- Using AWS IoT Greengrass for device software to down sample data.
- Local Lambda functions can be used on AWS IoT Greengrass to down sample the data before sending it to the cloud.
- ETL with AWS IoT Extract, Transform, Load with AWS IoT Greengrass Solution Accelerator helps to quickly set up an edge device with AWS IoT Greengrass to perform extract, transform, and load (ETL) functions on data gathered from local devices before being sent to AWS.
Architecture Notes - BP 3.2.4.4 - Use an exponential backoff with jitter and retry logic to connect remote devices to the cloud¶
Consider implementing a retry mechanism for IoT device software. The retry mechanism should have exponential backoff with a randomization factor built in to avoid retries from multiple devices occurring simultaneously. Implementing retry logic with exponential backoff with jitter allows the IoT devices to more evenly distribute their traffic and prevent them from creating unnecessary peak traffic.
Recommendation 3.2.4.4.1 - Implement logic in the cloud to notify the device operator if a device has not connected for an extended period of time
- AWS IoT Events can be used to monitor devices remotely.
- Remote monitoring using AWS IoT Events
Recommendation 3.2.4.4.2 - Use device edge software and the SDK to leverage built in exponential back off logic
- Exponential backoff logic is included in the AWS SDK, including the AWS IoT Device SDK, and edge software, such as AWS IoT Greengrass Core and Amazon FreeRTOS.
- AWS SDK handles the exponential back off
- AWS IoT Device SDK for C uses “IOT_MQTT_RETRY_MS_CEILING” for setting maximum retry interval limit.
Recommendation 3.2.4.4.3 - Establish alternate network channels to meet requirements
- Have a separate failover network channel to deliver critical messages to AWS IoT. Failover channels can include WiFi, cellular networks, or a wireless personal network.
- For low latency workload, use AWS Wavelength for 5G devices and AWS Local Zones to keep your cloud services closer to the user.