A software platform for the changing needs of your grid. Certified metrology firmware and independent applications, running on one microcontroller.
New applications. Protected metrology firmware. MeterForge brings both together on one microcontroller, so your meter can evolve with your grid.
A long-life asset.
A changing energy world.
Meters stay in the field for years. Network needs keep moving: new tariffs, electric vehicle charging, energy sharing and power quality monitoring.
MeterForge brings these different timelines together. Keep the certified metrology firmware stable, and extend the meter with independent software applications as your needs evolve.
SOFTWARE ARCHITECTURE
The firmware stays.
The applications evolve.
Deploy new business functions while keeping the legally relevant metrology firmware unchanged.
Separation enforced by hardware.
The processor’s built-in protection isolates the software domains on the same chip.
Native execution on one chip.
One chip.
Software that evolves.
MeterForge separates certified metrology firmware from independent applications through a standardised software interface. Both run natively on the same microcontroller.
Understand the
software architecture.
Three software layers, one microcontroller. Each layer has a distinct role in keeping measurement stable and services adaptable.
01 / THE PROTECTED FOUNDATION
Certified metrology firmware
The legally relevant (LR) firmware contains metrology and its supporting environment: the real-time operating system (RTOS) and hardware abstraction layer (HAL). This is the part designed to remain unchanged as business applications evolve.The processor’s built-in hardware protection separates the firmware from application domains. This separation is implemented within a single microcontroller.
The key distinction is software responsibility.
LR and LNR describe the role of software in the metering system.
02 / THE SHARED CONNECTION
A standardised software interface
The MeterForge interface exposes hardware, operating-system, metrology and LNR services to applications. These services include DLMS and other functions described in the ANDREA architecture.
A shared interface gives manufacturers, utilities and partners a common integration boundary. It is intended to keep development choices open, including the choice of language and compiler.
03 / THE EVOLVING LAYER
Independent, isolated applications
Legally non-relevant (LNR) applications provide additional meter and grid services. They can be developed by the manufacturer, the utility or partners, and added, updated or replaced independently of the metrology firmware.
Applications execute as native machine code, without a virtual machine. The architecture targets binary compatibility within a supported microcontroller class, with the target platform and integration requirements reviewed for each project.
Long-life hardware.
New possibilities.
BUILT FOR THE LIFE OF YOUR NETWORK
01 / DEPLOYMENT
Your applications.
Your schedule.
Add and update business functions across an installed base as your needs change.
02 / INDEPENDENCE
A standardised
software interface.
Develop around a shared interface and native application execution.
03 / EFFICIENCY
Native software.
One microcontroller.
Run firmware and applications on one standard-class microcontroller.
