In Internet of Things (IoT) development, relying on the availability of field devices can pose different challenges, particularly in the smart energy space. These issues often come in the form of a divergence in timelines between the IoT device installers and the commissioners and the timelines set by the business in terms of the data handling platforms, or the software deployments that need to be developed to interact with the devices. What this means to the development process is that a delay in the devices sending data may lead to squeezed development times, or late the delivery of the software.
For third year student of Electronic Engineering at Waterford Institute of Technology, Jack Jackman joined the PAS team as part of his work placement at the right time. The Smart Energy team in the Programmable & Autonomous Systems (PAS) unit at TSSG were beginning to build a testing device to overcome the challenge of field device availability which became Jacks onboarding project.
PAS are utilising smart sensors deployed by third-party entities and other project partners in order to develop a smart energy management platform. At present, these sensors publish telemetry over MQTT; a lightweight messaging protocol commonly used with IoT devices. However, in the long term, the device owners are planning to update their data flow processes by migrating their device-to-cloud communication to Azure IoTHub, along with their data handling, transformations and storage to Azure services. As it would involve sending a person out to the field to configure the devices in order to conform to the new data flow, this potentially presents a time sensitive problem. Since the sensors are owned by various third parties, the project could be delayed by a matter of months as the developer is forced to wait for an available engineer to manually reconfigure the device.
While the actual code could be developed to allow the the device to handle the data, it would not be possible to develop the system in an integrated way. In other words, once the devices were commissioned they would have a platform ready to take and handle telemetry. This is where the idea to build an IoT device that could be configured to emulate the devices being deployed in the field was conceived.
How does it work?
TSSG named this Electrical-IoT-Emulator and it is a Python application that can be deployed using Docker to a Raspberry Pi which is designed to mimic telemetry generated by the smart grid sensors. It produces random data readings for each of the parameters read by the sensors and formats it in exactly the same way as if it was read manually. The data is then published to IoTHub just as if the readings were therefore demonstrating the flexibility of using remote software bench testing tools in the field of IoT development because the outputs of virtually any IoT device could similarly be mocked. This effectively removes the dependency on having field devices in place and operational in order to test new functionality.
The result is a reduction of the overall time it takes to conduct tests and allows the developer to build applications that require real time and realistic readings to be sent to the IoTHub. Deploying it to multiple devices also enables volume testing on a given application like IoTHub. The flexible nature of a software-based mock device allows scope for Electrical-IoT-Emulator to expand in the future. The Electrical-IoT-Emulator application was built with flexibility in mind and in a way that it can be extended to have new devices and communications protocol included in the application if new use cases arise or if other devices needed to be emulated.
The purpose of Electrical-IoT-Emulator was twofold. In addition to being a functional application to support the unit’s ongoing projects, it also served as an on-boarding project for WIT placement student Jack Jackman. Developing this device and building it through the software development process proved to be an effective on-boarding exercise, allowing Jack to develop an understanding of the tools and techniques used within the team’s client-facing projects. As a project that wasn’t directly connected to some of the other software developed in TSSG, it allowed Jack to be able to experiment and get familiar with some of the technologies such as timeseries databases like InfluxDB and communications protocols, like MQTT.
The development of the Electrical-IoT-Emulator took two months to get it to a point where it could be used to emulate the first device that was to communicate with the IoT platform. This enabled us to have the software developed and deployed one month prior to when the first actual field devices were installed, commissioned and sending telemetry. This pattern followed and at present there are functions deployed, tested and ready to receive telemetry from device types that have yet to be installed.
To build on the work carried out by Jack, the PAS team intend to further increase our emulation capabilities with a view to, not only be capable of emulating devices, but to be able to hook up emulators in a way that we can imiate more complex scenarios. For example, to assess the potential impact of a SolarPv installation or extensive electrical vehicle charging would have on the electrical network in an area.
Written by Jack Jackman, PAS Intern and 4th year WIT student.