Range of Industrial Monitoring Devices
IntroductionFollowing on from the technology demonstrator described in Asset tracking/environmental monitoring device, Metanate’s client developed a range of low-cost asset tracking and sensor devices for industrial deployment, and needed to gather data from these in a cloud-hosted database. Real-time monitoring of some sensors using mobile apps was also needed.
The tracking and sensor devices themselves were battery-powered and required to work unattended for several years. They used Bluetooth Low Energy (BLE) to transmit data - current status, significant events and diagnostics.
A mains-powered repeater was developed to relay the data from nearby BLE devices to the cloud using a cellular modem. The repeater also supported over-the-air updates to its configuration and both its own and devices’ firmware. The devices needed to remain fully operational while firmware was being downloaded onto them, with downtime to activate the updates minimised.
The repeater and communication protocols were designed to be device-agnostic, allowing new device types to be added to the product range easily without changes to the repeater firmware.
Metanate was commissioned to design and develop five components for this system:
- Firmware for four tracking and sensor device types.
- Firmware for the repeater.
- A server/database handling online repeater configuration and firmware image management.
- A manufacturing application for the factory that produced the devices and repeaters.
- Prototype iOS and Android mobile apps for interacting with the devices and repeaters.
Tracker and Sensor DevicesAll devices were based on a common platform, with optional firmware modules to handle different fitted sensors.
- The main CPU was a Nordic nRF52832 System-on-Chip (ARM Cortex M4 CPU).
- The firmware was developed using a Linux-hosted GNU C cross-compiler toolchain.
- It used a single-threaded, event-driven design operating in limited RAM.
- A variety of interrupt-driven and polled sensors were supported, using I2C, UART, SPI or ADC interfaces.
- CPU and attached component sleep modes were utilised to minimise power consumption.
- A "Coulomb counting" algorithm was devised to monitor up-time for each component and compute remaining battery life; the devices used lithium-ion batteries whose voltage did not drop, allowing discharge to be measured.
Event Recording and Transmission
- Significant events were stored in code flash for relay via a repeater.
- Bluetooth Low Energy (BLE) status beacons were advertised in bursts, either periodically or on sensor reading changes, to prolong the battery life.
- BLE Peripheral connection support enabled repeaters to retrieve stored events from the devices and download firmware onto them while they continued functioning.
- Event data was encoded in a compact binary format, because the limited RAM precluded the use of JSON or similar encoding.
- BLE beacon and event data was encrypted, and events were authenticated with CMACs, using AES-128 implemented in the Nordic hardware and keys unique to each device installed during manufacture.
- Firmware images were in Nordic Secure DFU format with a SHA-256 hash and ECDSA signature, providing authentication and integrity-checking.
RepeaterThe repeater was based on the same Nordic nRF52832 System-on-Chip as the devices, with a broadly similar firmware design, but fitted with a cellular modem instead of any sensors. Although it was mains-powered, the firmware utilised processor sleep modes in readiness for a future battery-powered variant.
Bluetooth Low Energy (BLE) Functionality
- BLE status beacons were advertised to allow monitoring and connection by mobile apps.
- BLE Central connection was used to retrieve events from devices and download firmware to them. Firmware images and events awaiting transmission to the cloud were maintained in SPI flash.
- BLE Peripheral connection support allowed mobile apps to query the state of the repeater and devices in range of it.
- Quectel 2G GSM and 3G/4G cellular modems were handled.
- Cellular call scheduling could be configured to minimise costs in large deployments, with optional SMS alert reception to avoid speculative calls to check for updates.
- Device BLE beacons and/or events could be relayed to the cloud, configurable per device type.
- Configuration updates were retrieved from the cloud, using a compact binary format similar to device events, because the limited RAM precluded the use of JSON or similar encoding.
- Firmware images were downloaded from the cloud in blocks using HTTP ranges, and could be resumed if the cellular connection was lost.
- Encrypted HTTPS connections were used with trusted TLS certificate verification.
- Sensor data in device events and BLE beacons was relayed through the repeater without decryption.
- A separate encryption key for each device was downloaded from a network HSM and used to encrypt requests and responses exchanged over BLE Central connections to it.
Configuration and Firmware Server/DatabaseAlthough the primary purpose of this was to support online repeater configuration and firmware downloads, it was also able to store beacons and events relayed from devices, to facilitate their development and testing while the customer-facing cloud service was being developed elsewhere.
- It was based on an Apache web server hosted on a Linux system.
- A MariaDB database contained repeater configurations, available firmware image details and device data.
- Custom FastCGI code in C++ handled the binary-encoded device events and repeater configuration requests.
- A JSON REST API was implemented for the web management interface, and also used by the mobile apps.
- Configuration and firmware release updates triggered requests to an external SMS gateway to send alerts to the relevant repeaters.
Manufacturing ApplicationThis was developed to automate the factory provisioning and testing of both tracking and sensor devices and repeaters.
- A barcode scanner was used to input each device's unique serial number, assigned during PCB manufacture.
- It programmed test firmware onto the device using a JTag connection, which queried hardware component serial numbers and ran factory tests.
- It initialised the device configuration, including their unique cryptographic keys obtained from the network HSM.
- For repeaters, current firmware images for common device types were pre-installed, to save them having to be downloaded over cellular after deployment.
- It then programmed the application firmware onto the device.
- It reset the device and verified that the firmware advertised its BLE beacon.
- It then submitted the device manufacturing properties to the cloud database using a JSON REST API and OAuth2 authentication.
- Finally it submitted a comprehensive manufacturing process log to the cloud.
Prototype Mobile AppsMetanate produced prototype mobile apps on both iOS and Android to demonstrate the potential of the system. Their functionality included:
- Retrieval of encryption keys from the network HSM to decrypt sensor readings in device BLE beacons and allow BLE connections to repeaters.
- Display of BLE beacons received directly from nearby active devices.
- BLE Central connection to repeaters to query their state and display the devices of which they had knowledge.
- Retrieval and display of device and repeater manufacturing properties from the cloud database using its JSON REST API.
- Upload of location and other installation-specific properties to the cloud database.