Key components

This topic describes the key components of DI. For more information, see System architecture.

Distributed Intelligence (DI) Platform

A multi-tenant Software as a Service (SaaS) cloud platform that delivers edge computing solutions built by Itron, third-parties, and utilities. It contains a collection of services built to manage applications' distribution, operations, and data delivery using distributed intelligence.

Itron Enterprise Application Center (EAC)

A DI Platform component that provides DI edge application, application version, and application/version-to-meter management. The EAC’s web-based interface allows utility users to view available DI applications and versions, maintain DI application licenses, install licensed DI applications on compatible devices, track application/version-to-meter relationships, and more. Further EAC functionality includes:

  • Presentation of available DI applications and versions

  • Installation of licensed DI applications on compatible devices

  • Download of DI applications (with or without licenses) to devices

  • Download of DI licenses to devices

  • Create and manage device groups

  • Scheduled download of DI applications or licenses

  • Delivery of DI application configuration parameters on installation

  • Utility approval of specific application versions for broader utility deployment

  • Maintenance of DI application licenses, expirations, and renewals

  • Tracking and reporting of application/version-to-device relationships

  • Tracking and reporting of license-to-device relationships

  • Tracking of application health on devices

  • Alerting and details for license expiration, application resource usage excess, and application health

  • Update ApplicationServices (AppServ) on devices as required during application installations

For a utility to access the EAC, their Itron tenant must be configured and enabled for DI.

Application Management Service (AMS)

A DI Platform service that acts as the source of record for the Itron Enterprise Application Center (EAC) data that defines the bundling of agent features into a licensable edge application. AMS also provides the core logic for accepting or rejecting application submissions and permissions requests for application submissions. AMS also manages signing and encrypting of DI agents and applications for secure communication to devices, including the interaction with the Itron team that does production signing and encryption of agent packages.

Configuration Management Service (CMS)

A DI Platform service that maintains the state of DI application configurations at the global edge application level, defaults, and local endpoint-specific configurations. CMS is required for all edge application deployments as part of the DI edge application provisioning process.

Group Management Service (GMS)

A DI Platform service that acts as the source of truth for all DI-related groups outside of the Itron Enterprise Application Center (EAC). GMS controls the creation and management of DI-related groups, which are required for the edge application provisioning process (including target endpoint lists, configurations, and licensing) and persists for the lifetime of the DI applications.

Endpoint Management Service (EMS)

A DI Platform service that manages the hardware, firmware, and ApplicationServices (AppServ) version properties of endpoints.

DI Subscription Service (DSS)

A DI Platform service in the Itron-hosted cloud that validates data integrity and passes the validated data to its authorized users (subscribers).

A broad set of DI systems and third-party agents generate the data passed to DSS, including real-time, periodic, and outcome data. Subscribers to this data can include Itron services, data stores, and systems for Itron or third-party applications.

For subscribers to become authorized to receive data from DSS, permissions must be granted explicitly at the requester, agent, and feature level, as well as at each tenant or utility whose data is required.

Operations Monitoring Service (OpsMon)

A DI Platform service responsible for running system health checks through every component of the DI platform and reporting the results for uptime (percentage of time the platform is available) and availability (percentage of time the platform is functioning as expected).

EAC Gateway (EACGW)

A DI Platform component that exposes REST APIs allowing the Itron Enterprise Application Center (EAC) to interact with the rest of the DI Platform services.

Third-Party Gateway

An API Gateway that provides connectivity to a utility’s Customer Portal and is responsible for the following communication points: provide communication between the customer portal and the DI services; receive requests from the customer portal and forward them to the Itron Enterprise Application Center (EAC); manage request, response, and notification service bus queues. The Third-Party Gateway API conforms to the constraints of the representational state transfer (REST) architecture style, making it a RESTful API.

Application platforms

All cloud applications must subscribe to their DI feature data via DI Subscription Service (DSS) and decode, ingest, process/enrich, store, and provide interfaces for users or other systems to obtain business value from their application. Itron-built DI applications use different multi-tenant Software as a Service (SaaS) mechanisms for this purpose.

DI Message Processor (DIMP)

A DI Application Platform option. DIMP is a .NET DI platform service for real-time data processing (decode, transform, and operational storage) of messages from Itron-built DI edge applications. It is built using Orleans for real-time processing and Microsoft SQL Server for operational storage for each customer tenant. This includes utility user information, service location and device configurations, grid topology, and edge data collected within the past 13 months. This data can be viewed in cloud applications hosted in Itron Analytics Platform (IAP) or Itron Presentation Layer (IPL).

Itron Analytics Platform (IAP)

A DI Application Platform option. IAP hosts many Itron cloud applications that deliver DI and non-DI use cases such as Gas and Water Customer Service, Theft Detection, Gas and Water District Metering Analysis, and Grid Management Analytics.

Integration Service

An Itron Analytics Platform (IAP) component that does .NET batch data processing (decode and ingest) of messages from Itron-built DI edge applications.

Customer Database

An Itron Analytics Platform (IAP) Microsoft SQL Server database for storing a specific customer’s tenant data. This includes utility user information, service location and device configurations, grid topology, and cloud application data collected within the past 13 months.

Web Application Services

An Itron Analytics Platform (IAP) public multi-tenant web application that hosts the user interface for applications and solution administration, where users can view and edit data in their tenant’s Customer Database according to their user role.

Itron Hybrid Connector (IHC)

A solution whose purpose is to securely transmit data between a customer environment and Itron’s cloud environment in Azure. This data is not transferred or used anywhere else.

Proxy service

A service that routes requests from other cloud services, such as the DI Platform, to make those workloads and commands available for secure download by the correct On-premises Hybrid Service (OHS) instance.

On-premises Hybrid Service (OHS)

A Windows service installed on the utility's network to access an on-premises data source, such as OpenWay Collection Manager (OWCM) on an OpenWay Riva network or Advanced Metering Manager (AMM) on a Gen5 Riva network. Before edge applications can connect to a data source, an instance of OHS must be installed and configured.

OHS acts as a proxy between the DI Platform and customer data sources by only allowing connectivity outbound from the OHS host. OHS polls the proxy service for any workloads and pulls them into the OHS only through secure channels using mTLS authentication. Outbound data is transmitted from OHS only to known, secure channels. It only connects to other systems it has been locally configured for.

The closer OHS is to the data source server, the faster the connection. Installing OHS on the same server as the data source (for example, the head end server) is the best way to avoid network latency between OHS and the on-premises server. The security benefit is that your data source remains secure within your network and network security mechanism: data is transferred only through the secure channel OHS uses.

OHS accesses the data source using the following mechanisms:

  • Data feed. Used for subscribing to data streams published from an on-premises system using a proxy service. This is specifically used for interrogation jobs to collect meter readings, events, exceptions, and alarms.

  • Request/response. OHS can initiate service calls and return responses to interact with Service Oriented Architecture systems. This is specifically used to initiate a request for an interactive read, ping, or valve command from OWCM or an interrogation read from DINA on the GenX platform. DINA, which works with AMM, is a GenX application that delivers metering data from software running on Itron Gen5 Riva electricity meters. DINA accepts requests from OHS and transforms them to a compatible format.

  • File transfer. For file uploads from an on-premises data source, OHS detects new files that are placed into a shared folder, uploads them to a secure Azure Blob Storage Account using Transport Layer Security (TLS) 1.2, and then notifies and provides connection information to Itron Cloud Services for processing. For file downloads from Itron Cloud Services to on-premises locations, a service sends a notification to the proxy service of a file stored on a secure Azure Blob Storage Account to OHS, which then downloads the file to a configured folder using TLS 1.2.

Itron Azure environment

An Itron-managed Microsoft Commercial Azure-based infrastructure. It includes a cloud-based, multi-tenant infrastructure and a collection of software services for hosting customer-facing web applications used for analyzing and managing sensor data (including, but not limited to, electricity, gas, and water meters) and DI data.

In addition to taking advantage of Microsoft Commercial Azure’s FedRAMP High, NERC CIP-compliant security controls, Itron has implemented additional security controls following NIST SP 800-53 that is SOC 2, Type 2 attested annually.

Head end systems (HES)

A software application that receives the stream of meter data brought back to the utility by an AMR/AMI system.

OpenWay Collection Manager (OWCM)

Itron’s legacy AMI head end system for deployments on the OpenWay Riva network. OWCM has undergone modification to collect and process edge application data with existing workflows. DI Cloud components and Itron Enterprise Application Center (EAC) interface with OWCM to perform the following DI operations:

  • Assign group membership for devices running specific DI agents and delivering specific DI outcomes.

  • Trigger and manage firmware download tasks to install DI agent binaries on target devices.

  • Act as the passthrough mechanism for DI Configuration jobs so installed DI agents can be reconfigured.

  • Act as a data passthrough broker for installing and updating DI agent licenses.

  • Enable users to include DI outcome data and events within scheduled reads.

UtilityIQ software

Itron's AMI head end software suite for deployments on the GenX Riva network. UtilityIQ software includes applications designed to help utility operators collect and manage AMI meter consumption data. These applications, which include Advanced Metering Manager (AMM) application, Meter Program Configurator (MPC), Firmware Upgrader (FWU), and Meter Plugins, are secure and scalable solutions that support meter reading, management, and analysis for power quality, meter status, peak pricing, and edge compute.

DI Network Adapter (DINA)

A component allowing upstream DI services and components to communicate with UtilityIQ software similarly to how they communicate with OpenWay Collection Manager (OWCM). DINA enables the scheduling and on-demand reads of all DI data, including DI outcome interrogation (periodic) data and Itron Enterprise Application Center (EAC) information.

DINA is an installed Central Authentication and Authorization Service (CAAS) component, so DINA users must initially sign in via the CAAS user interface. CAAS is a software component that supports single sign-on and authentication for supported Itron applications.

DI Code Deployer (DICD)

A service that provides DI-related logic to the existing Firmware Upgrader (FWU) functionality and enables DI Network Adapter (DINA) to request agent package downloads. DICD also acts as an intermediary between DINAShim and FWU for submitting and retrieving agent packages.

DINAShim

An intermediary service between DI Network Adapter (DINA) and the On-Premises Hybrid Service (OHS). It transmits all upstream messages for both the Itron Enterprise Application Center (EAC) and the DI application platform. Likewise, all downstream messages from OHS are translated into the formats required for DINA over RabbitMQ. The DINAShim service integrally supports the UtilityIQ software plugin for the Central Authentication and Authorization Service (CAAS).

ApplicationServices (AppServ)

An interface between all installed DI agents and the DI-capable device. All agent data (events and alarms) passes exclusively via the AppServ component. AppServ sits outside the containers where agents are installed, but there are AppServ APIs within containers that communicate via DBUS only to the AppServ component. The calls these AppServ APIs can make are highly restricted and do not allow agents to transmit data outside of containers without going via AppServ.

One of AppServ’s functions is to govern the amount of data that is passed from agents to the endpoint’s database. It does this via the agent package's policy file that is scrutinized and validated during the agent certification process. The policy file stipulates how much data an agent is intending to produce and transmit within any given 24-hour period. The policy file includes all communication channels (for example, mesh and peer-to-peer), and each channel has independent daily limits. This prevents a single agent from consuming the entire data allowance of an endpoint or flooding the network with data. Without a policy file, the default limit is 15kB of interrogation data and 10 alarms per 24-hour period. No other communication medium (for example, peer-to-peer) is allowed without a policy file.

During typical operation, AppServ passes all agent event data into the database for later retrieval via interrogation reads. However, if an agent meets its daily data limit, then AppServ responds to the agent with a data limit error, rejects the data, and stops passing the data into the database. It is up to the individual agent's logic to determine how rejected data is handled.

Scheduled reads are controlled by the utility. At the time of an interrogation read request, the endpoint places all agent event data into a dedicated DI database allocation and includes it within the interrogation read response. Previously-read information can still be accessed locally and via contingency reads.

Agent alarms are also passed through AppServ, but AppServ recognizes the data as real-time agent alarms and they are forwarded immediately to the endpoint comm module for transmission. The policy file also includes a daily limit for agent alarms. After this limit is met, AppServ no longer forwards alarm data to the comm module. This prevents agents from unintentionally flooding the network with alarms. As with rejected agent data, it is the responsibility of the individual agents to handle rejected alarms.

For release notes information for AppServ on a GenX network, see ApplicationServices (AppServ) release notes. For release notes information for AppServ on an OpenWay Riva network, see the relevant DI-capable meter's firmware release notes.

ContainerManager

A service that creates isolated containers for DI agents. The ContainerManager uses unprivileged Linux containers, meaning they are not run with root privileges on the host side.

DI Director Libraries

A library incorporated into Application Services (AppServ) made up of two components: Agent Director and Agent Monitor. Agent Director resides outside the containers, in the same space as AppServ. It communicates with the Agent Monitor, which is installed into each container. The Agent Monitor verifies that all licenses for installed agents are valid and haven’t yet expired. The Agent Monitor triggers an agent shutdown when its license expires. The Agent Monitor also passes runtime status information for each agent installed in the same container. Data that the Agent Monitor passes to the Agent Director includes the following:

  • License status of each installed agent

  • Agent resource usage of CPU, RAM, and flash

  • Agent runtime statistics

The Agent Director receives and collates the data from all Agent Monitors and packages the data for transmission upstream to Itron Enterprise Application Center (EAC). Every 24-hour period at UTC midnight, the Agent Director data is made available for transmission in the next scheduled read.

Applications, agents, and features

A hierarchy of components from the licensed process on a DI-capable device (a feature) to what a utility is trying to achieve (an outcome). From the smallest unit to the largest unit, this includes the following:

Feature

A licensed process within an agent that monitors and consumes the meter's measurement data to deliver a data-driven answer to a specific concern. A feature can also send the result to subscribers.

Agent

A software executable that includes one or more features. Agents run within a container of an outcome data-enabled meter.

Edge application

A collection of features (potentially spanning multiple agents) running on a meter for a specific purpose. This is what is licensed and deployable from the Itron Enterprise Application Center (EAC).

Cloud application

A back-office business web application that uses a combination of batch processes and one or more edge applications to deliver a specific business value to users.

Outcome

A collection of business applications and services that deliver to customers a concise, defined, and observable result or change in business performance, supported by a specific measure.

DI-capable devices

DI agents running on the device subscribe to specific values made available from the register board/metrology. DI agents are able to access one-second data (v6 blurt) or higher frequency data (v7 blurt), but the mechanisms of accessing each are different.

  • V6 blurt. Itron’s DI agent API provides a class by which an agent can request subscriptions to specific data values being sent from the metrology board. Depending on the subscription type, the new data values are pushed to the agent either on a certain frequency or when those values change (up to once per second).

  • V7 blurt (and configuration interface). The same subscription class can be used to request a subscription to the high-frequency cycle and sample data provided by the HW 4.2 metrology. If the agent subscribes to this data, it can expect to receive three messages per second. The data is not parsed into individual elements- this operation is left to the agent.

The content of the final sample data message sent each second can be configured. An API allows an agent to specify a change to this message's content for up to five minutes. This API is included within AppServ and can be accessed by any DI agent. Changing the content of the one second message only impacts the data being passed to the DI agent that requested the change. It does not alter the configuration or message output of the meter’s blurt messages, nor does it impact the meter’s ability to continue to log metrology data.