Guardian modules

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, as described in the Connectivity section of this topic. 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, while also acting as a secure interface between existing equipment and an external network. Possible uses for a guardian module include:

• Collecting data from the brownfield device, processing the data, and transmitting the data securely to a cloud endpoint
• Sending data to multiple endpoints, provided that it can authenticate each endpoint
• Gathering 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
• Saving data from the brownfield device in case connectivity is lost

The Azure Sphere samples repository includes two samples that demonstrate how an Azure Sphere device might be used as a guardian module:

• Device to Cloud shows how an Azure Sphere device can be used for data collection while providing secure internet access for a brownfield device that is connected to it via a serial interface.
• Private network services shows how an Azure Sphere device can provide secure internet access for a brownfield device that is connected to it via a TCP/IP interface.

Connectivity

There are several supported mechanisms of connectivity between the guardian module and the network, and between the guardian module and the brownfield device. For general information about Azure Sphere connectivity solutions, see Connectivity overview and Networking requirements.

A guardian module's high-level application communicates upstream with the network, including the Azure Sphere Security Service and other cloud services, and downstream with the brownfield device:

• For upstream connections between the guardian module and the network, you can use Ethernet, Wi-Fi, or cellular.

• For downstream connections between the guardian module and the brownfield equipment, you can use the following:

  • Any serial interface, such as UART, RS-485, or SPI, that the brownfield device exposes
  • Private Ethernet, which does not expose the brownfield device to the public network
  • Wireless, such as Bluetooth or ZigBee

Application development and deployment

Developing and deploying an application for a guardian module is no different from developing and deploying an application for any other Azure Sphere device. See Overview of Azure Sphere applications and Deployment basics for details. As with any Azure Sphere device, a guardian module must have at least one high-level Azure Sphere application and may also have real-time capable applications.

You'll need access to the service UART, which is the main programming and debugging interface between the MT3620 and the development environment running on a host computer. If you design your own guardian module, 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.

High-level applications

A guardian module high-level application must be custom-written 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 modify or update the application as necessary.

As with any Azure Sphere device application, device-specific and application-specific details must be listed in the application manifest. For example, the guardian module's connections are device-specific details that must be included in the manifest.

A high-level application that runs on a guardian module is responsible for the following:

• Establishing and maintaining connectivity with the brownfield equipment
• Establishing and maintaining connectivity with the internet, including the Azure Sphere Security Service and other cloud services
• Handling data received from the brownfield device—unpacking and storing data, if necessary, and communicating with the internet hosts as appropriate
• Handling data received from an internet host—unpacking and storing data, if necessary, and communicating with the brownfield equipment as appropriate

Data sent upstream might include error reports, operating parameters, or overall telemetry. Azure Sphere ensures that all such data are encrypted. The application can connect to web services and use mutual authentication for such connections.

Data sent downstream might include updated software or changes to settings or parameters for the brownfield device. To avoid potential security breaches, the application should validate incoming data before passing it downstream to the brownfield device.

Application considerations

When creating an application, you should consider the peripherals available, storage requirements, and power consumption.

Peripheral devices

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.

Storage requirements

Azure Sphere has limited storage, so carefully consider how much memory is needed for applications and data. See Available memory for more information.

When you send data downstream from the cloud to the brownfield device, ensure that the guardian module has enough space to hold the data. You might need to send data in chunks, as demonstrated by the HTTPS_Curl_Multi sample in the Azure Sphere GitHub samples repository.

When you send data 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 must consider which data and how much of it to retain and later send to the cloud when connectivity is restored. See the store-and-forward gallery sample, which shows how to use local storage to temporarily cache data before it is uploaded.

Power consumption

There are numerous applications in which the guardian module is inactive most of the time. For example, consider an Azure Sphere device that once every hour collects data from a network of sensors and uploads that data to the cloud—an operation that might take a minute or two. In this case, most of the power consumed by the device is wasted.

You can significantly reduce power consumption and thus increase battery life either by placing the device in the Power Down state when it is inactive or by setting a power profile. See Manage Power Down state and Set power profiles for details.