A guardian module is add-on hardware that incorporates an Azure Sphere chip and physically attaches to a port on a "brownfield" device—that is, an existing device that may already be in use. By using a guardian module, you can add secure IoT capabilities to equipment that either doesn't support internet connectivity or doesn't support it securely. In short, a guardian module provides a way to implement secure connectivity in existing devices without exposing those devices to the internet. Because it's an Azure Sphere device, all the Azure Sphere security and connectivity features are available: all data is encrypted, OS and application updates are delivered securely, and authentication ensures that the module communicates only with trusted hosts.
Here's how a guardian module works:
The guardian module connects to a brownfield device through an existing peripheral on the device, and connects to the internet through Wi-Fi or Ethernet. The brownfield device itself is not connected to the network.
The Azure Sphere OS runs on the guardian module along with a custom high-level application and any other Azure Sphere applications your scenario requires.
The guardian module uses the Azure Sphere Security Service for certificate-based authentication, failure reporting, and over-the-air software updates.
The brownfield device communicates with the guardian module, which can respond by taking a local action or by reporting to a cloud presence such as Azure IoT Central.
You can buy guardian modules from a vendor and further customize them for your usage scenario, or you can design your own guardian module, possibly working with a hardware partner. See the Azure Sphere website for information about hardware suppliers.
Uses for a guardian module
A guardian module can do anything any other Azure Sphere device can do. Possible usage scenarios for a guardian module include:
- Cull data from the brownfield device, process it, and transmit it securely to a cloud endpoint
- Send data to multiple endpoints, provided that it can authenticate each endpoint
- Gather additional data that's not available from the brownfield device; for example, sensors on the guardian module could provide environmental data for use with operating data from the brownfield device
- Save data from the brownfield device in case connectivity is lost
High-level applications for guardian modules
A guardian module requires at least one high-level application. The high-level application communicates upstream with the internet (including the Azure Sphere Security Service and other cloud services) and downstream with the brownfield device. These connections, along with other device- and application-specific details, must be listed in the application manifest. As a result, the high-level application must be custom-written or customized for each organization's brownfield devices. If your guardian module supplier provides an application, be sure that you receive the high-level application source code and libraries so that you can update the application as necessary.
A high-level application that runs on a guardian module is responsible for:
- Establishing and maintaining downstream connectivity with the brownfield equipment and upstream connectivity with the internet
- Handling data sent upstream from the brownfield device, unpacking and storing if necessary, and communicating with the internet hosts as appropriate
- Handling data sent from an internet host, unpacking and storing if necessary, and communicating with the brownfield equipment as appropriate
The application can connect and authenticate to web servers and use mutual authentication for such connections. Data sent upstream might include error reports, operating parameters, or overall telemetry. Azure Sphere ensures that all such data are encrypted.
Data sent downstream might include updated software or changes to settings or parameters for the brownfield device. To avoid potential security breaches, the app should validate incoming data before passing it downstream to the brownfield device.
For downstream connections from the guardian module to the brownfield equipment, you can use any peripheral that the guardian module exposes. Private Ethernet support in the Azure Sphere OS allows a connection to the brownfield device over Ethernet without exposing it to the public internet.
Peripheral device support
Like other Azure Sphere devices, guardian modules differ in the peripherals that they expose. Choose a guardian module that provides the connectivity and sensing capabilities your scenario requires. Depending on the hardware architecture of the guardian module—that is, how it exposes capabilities of the Azure Sphere chip—you can determine whether the software to access individual features must be implemented as a high-level or a real-time capable application.
Azure Sphere has limited storage, so carefully consider how much data will be exchanged between the guardian module and the brownfield device, and between the guardian module and the cloud.
Azure Sphere applications can use up to 256 KiB of RAM. If you plan to send data downstream from the cloud to the brownfield device, ensure that the guardian module has enough space to hold the data. For example, if you want to deliver firmware updates for the brownfield device, make sure they will fit in the storage available on the guardian module. You might need to send such updates in "chunks"; the HTTPS_Curl_Multi sample in the Azure Sphere GitHub samples repo shows how to do this. Keep in mind that your downstream device will also need a similar mechanism.
For data that travels upstream (from the brownfield device to the guardian module), ensure that your application can handle upstream connectivity failures. If the brownfield device provides ongoing telemetry, you need to consider which data and how much of it to retain and later transmit when connectivity is restored.
App development and deployment
Developing an application for a guardian module is no different from developing an application for any other Azure Sphere device. You'll need access to the service UART on the Azure Sphere chip so that you can read and write from the local device. If you design your own device, you will need to ensure that the service UART signals are exposed and that you support a way to interface with the service UART either on the guardian module itself or on a separate piece of hardware. If you purchase modules from a vendor, the vendor should provide a solution that enables this connection.
If your supplier or another third party will create the application, you might need to provide access to your Azure Sphere tenant so that the application developer can load and test the application and create a deployment. If your module provides a service UART connection, you can sideload the production app before final deployment.