based on AWS Primers
The Pragma Architecture comprises layers of solutions:
- Small Thing — The logical representation of the device and fleet of devices
- Intermittent Layer — The control point for access to the Speed Layer and the nexus for fleet management
- Speed Layer — The inbound, high-bandwidth device data bus and the outbound device command bus
- Serving Layer — The access point for systems and humans to interact with the devices in a fleet as well as analysis, archive, correlation, and real-time views of the fleet
Example
After a small thing uses the intermittent layer to authenticate itself with the solution, the small thing regularly sends data to the speed layer. That data could then be processed as telemetry and output for use by people interacting with the serving layer.
- Telemetry — remotely determine what a device senses
- Commands — remotely ask a device to do something
- Device DevOps — remotely ask a device to be something new
- Audit and Authorization — determine if a device should be allowed to do something
Questions
- What should the device do with data if the device can’t send it to the stream?
- What happens if all the devices report at the same time and create massive peaks in reporting? What about a hundred, a thousand, or even ten thousand devices?
- How does one gather data when HTTPS is too heavy for our resource-constrained small thing?
- How can a solution simultaneously provide more local network connections for devices in a global fleet?
By adding a command database (NoSQL Database i.e. DynamoDB) into the architecture, we leverage our past investments in telemetry, add a single point for control for all commands, and gain visibility into those commands.
The Pragma Architecture’s Serving Layer can reliably use the single point of command interaction to offer up a user interface that conveys the last commanded state of the devices under control of the solution.
- On the left of the preceding diagram the HTTPS small things — such as solar power inverters that are sending telemetry to our regional stream — also check for their specific commands directly from the command database.
- When each small thing successfully completes a given command it writes an acknowledgment directly back to the command database.
- This places the retry logic in or near the small thing itself, which usually makes sense because the small thing is in the best position to know something about its current operating environment.
- The M2M Gateway also shown in the diagram has been extended to act as a bridge between the M2M small thing protocol and the command database.
- Every command that is in the command database is placed onto a device-specific M2M command topic.
- When the M2M small thing, which might be a connected relay near the solar inverter, receives and successfully completes the given task, it writes an acknowledgement back to the device’s specific M2M command topic.
- The M2M Gateway in the middle of the diagram then writes the acknowledgment directly to the command database.
- Many M2M protocols (such as MQTT) have already incorporated retry logic for the delivery of messages between the client of a topic and the topic itself.
Scenario:
Giving the growing phenomena of Internet of Things, more and more startups are grappling with the question, “How do I build devices that scale as a fleet and provide the device insights I need to be a successful company”? To answer this question and build an IoT solution, companies must examine the four areas:
- Telemetry — remotely determine what a device senses
- Commands — remotely ask a device to do something
- Device DevOps — remotely ask a device to be something new
- Audit and Authorization — determine if a device should be allowed to do something
As a team member of a new startup, select two of the identified areas and explain why this area is an important consideration and how you could use an AWS service to support this area.
Telemetry and Commands are definitely the more important considerations for our Capstone project which is to build a non-invasive monitoring system for the elderly. The non-invasive feature of the monitoring system requires that there should be minimal user interaction with the sensor modules and for triggering any interaction such as calling the caretaker or ambulance immediately upon a fall detection, the cloud/ fog node should be able to remotely sense it and remotely ask the device to do something.
Our team currently uses AWS IoT Core to register devices to the Device Registry, but have yet to try out the Device Shadow Feature, as we are unsure how it will work in the scene.