From a desk, utilities can change the settings on a single device or push an upgrade to every device in their service area at once, with no site visits.
Remote device management for utilities
We built the central application a utility technology company’s customers use to manage and upgrade their field radio devices remotely.
Services
- Custom web application development
- Requirements and documentation
- Scrum delivery
- Onshore and offshore team
The challenge
Our client supplies measurement, data collection and control products to water and energy utilities in several countries. Their products help utilities and their customers make better use of limited water and energy.
They needed one central application that would let utilities manage every one of the client’s proprietary radio devices in the field, remotely. The hard part was that the devices themselves were still being developed while we built the software to control them.
Technology
- Java and Spring
- MyBatis and Maven
- ActiveMQ for JMS
- jQuery and Ajax
- HTML5 and CSS3
- SQL Server and Oracle
- Tomcat and Red Hat, clustered
- Shibboleth SAML 2 sign-on
The solution
Because requirements and API specifications changed constantly, we worked in short sprints and replanned each one around what had changed. We helped gather and document the requirements, then ran the project in Scrum, with daily stand-ups and a demo at the end of every sprint so the client could see progress and steer.
The application is built on our jDaptive and WebDaptive frameworks. It talks to several back-end systems over a range of protocols, sends commands to devices, and handles live notifications from the client’s communications engine. Built-in analytics let utilities review each device’s history.
It can be hosted or installed on site. More on the integration side of work like this in why connecting two systems costs more than building one.
How it fits together
Operators work in a browser. The app sends commands through the back-end services and the communications engine to devices in the field, and live notifications come back the same way.
Building against a moving target
The device APIs changed as the hardware did, so each sprint started by replanning around what had moved.
One endpoint or the whole territory
