top of page
Sensus: Next-Gen Hand-Held Application

The Sensus Handheld Application called FieldLogic Tools  supports three primary functions for Sensus metering products: Provisioning, Maintenance, Reading.


Provisioning - Deploy product with appropriate field settings. If there is Radio attached, configure the radio and place it in activated state.

Maintenance - Troubleshoot problems, modify configurations, update meter firmware, etc.

Reading - Collect periodic reading data for billing purposes

 

The current application is designed for Windows Mobile OS and has limited portability due to some of the architectural limitations and tied to the Windows development ecosystem. The goal of the Next-gen Handheld (NGHH) include: 

​

  • Enable modern Multi-platform support: Android and Windows 10.

  • Enable use of modern tools and the open source ecosystem.

  • Design for test.  Support full code test coverage and full test  automation.

  • Improve development efficiencies.  Increase feature velocity.

  • Flexible UI capability.

  • Enable third-party application integration.  (Headless Operation)

  • Mapping support.

System Architecture:

The NGHH application consists of the UI client written in JavaScript and the backend written in Java, communicating with each other using a REST API. The Mobile Application encompasses both the client and server. Apache Cordova is used to provide a platform-independent way to package the client and server into the executable. The backend is completely driven by the UI i.e. the backend does not initiate any transmission towards the UI. To get the status of an operation the UI will have to poll data from the backend.

​

Highlights of the architecture are:

  • Micro-Services vs. Monolithic Architecture

    • User Interface is decoupled from backend services

    • Language independent, structured REST-like interface between UI and back-end business logic.

  • Front-End UI

    • Portable HTML/CSS/Javascript/Polymer.  No proprietary, native platform APIs.

    • Single page application model.

    • Consistent UI, common look and feel across platforms.

    • Cross platform code sharing.

  • Backend Services

    • Business logic developed in Java. Enables access to large open source ecosystem and code sharing across product portfolio.

    • Supports third party integration.

    • Full test automation through headless operation.

User Interface

  • View/Controller: This contains the UI code written in HTML/CSS/JavaScript using Polymer customized elements. Requests to the backend will be made from here.

  • Model: This is the details of the SmartPoint and Meter returned by the backend

  • Backend Simulator: Simulates the backend so that the UI can be run in “demo” mode without starting up the backend.

 

Structured REST Interface

 

  • The “Swagger” tool is used to document and publish the structured REST interface that the backend offers. It’s the industry standard to create well-defined and maintainable APIs.

​

​

Backend

​

  • HTTP Interface Server
    A Jetty server that accepts accept REST API requests coming in from the UI, perform HTTP validation and pass them on to the Core Service.

  • Core Service
    This component continues the request processing by performing domain-specific validation. It interacts with the Device Configuration Data Service to populate parameters before passing the request onto the Communication Layer. It also implements a listener to get the responses back from the communications layer. It buffers and returns the data from the responses back to the UI when requested.

  • Communications Layer (CommLayer)
    This is the biggest component in the system and is responsible for the actual communication with the SmartPoint and/or Meter. It includes code to handle various communication devices like CommandLink, SIRT and Optical Probe. It also contains code to send and receive FlexNet messages to SmartPoints. On receiving data from the endpoint, it parses the responses and creates a model which is returned to the UI.

​

Data Service

 

  • When triggered, this component retrieves the JSON-formatted Device Configuration bundles from the NextGen Hub Server using HTTP.  It converts this JSON into Plain Old Java Objects (POJO) which are accessible programmatically from the other backend components. It also stores user defined settings in memory.

​

Persistent Data

​

  • This component is a persistent store to retain the backend information including the device configuration bundles, state of the backend, and user-defined settings. This is stored as a private file on the mobile tablet/device. This persistent data helps restore NGHH application state in the event that the application crashes or is forcefully shut down.

 

NextGen Hub Server

​

  • The existing FieldLogic Hub is used to create the Device Configuration. NGHH provides a new application called the NextGen Hub which resides on the same PC as the Hub. The NGHH Hub Server monitors the Device Configuration database and also implements a HTTP server. When configuration information changes the NGHH Hub Server converts the configuration bundle tables to JSON. When the NGHH backend needs to read Device Configuration bundles, it retrieves them from the NextGen Hub using HTTP.

​

​

Some of the Key technologies used in this project were -

  • Front end- JavaScript/HTML/CSS , Google Polymer.

  • Apache Cordova for platform dependence packaging.

  • Restful API/YAML for API definition and documentation,

  • Java JettyServlet/Socket Server, Java for backend communication to the Meter.

  • SQL lite database for storing logging information and Log4J for logging.

  • Maven and Jenkins.

Summary of Key Technologies:
bottom of page