VEE Energy User Guide
MICROEJ VEE Energy is a software platform for smart meters and other grid-edge devices. It runs the metering, connectivity and device-management services of the device on a MICROEJ VEE Kernel, and hosts Sandboxed Applications alongside them.
The Kernel is fixed when the meter is built and the applications can evolve independently. They are installed, started, stopped and uninstalled while the device is in the field, so a tariff, a protocol or an analytics feature reaches a meter already in service without rebuilding its firmware.
Architecture
A VEE Energy device implements VEE Energy’s layered architecture, each layer built on the one below it.
Two boundaries cut across the software layers and provide isolation, reducing the scope and reach of the layer above. The Kernel API is where the applications stop and the Kernel begins, the Native Interface is where Managed Code stops and the code written for the board begins. Each lets one side change without the other.
Sandboxed Applications
An application (also called “Feature” in MicroEJ’s terminology) is linked on top of the Kernel, and can be installed while the device runs rather than built into the firmware.
So the capabilities of a meter are not settled when it is manufactured, and an application written by anyone, including third parties, can be installed with the assurance that it will not jeopardize the system: its memory, its processor time and the APIs it may call are bounded by its Policy File. DLMS/COSEM (Device Language Message Specification / Companion Specification for Energy Metering), the metering protocol suite, is one such application, delivered by MicroEJ partners such as Kalkitech. Read more
The file is read at installation; the limits and the permissions are enforced while the application runs.
- Policy File
Declares what one application may consume and what it may reach. The Kernel reads it when the application is installed.
The resource part sets the application’s criticality, which decides who is stopped first when memory runs short, and the priority of its threads. It then bounds each resource the application uses: a share of the CPU, an amount of Managed heap, and for storage and network more than one figure each. Storage is bounded by total size, by how many files may be open at once, and by a write rate, so many bytes in so much time. Network is bounded by how many connections may be open at once, and by a send rate written per subnet, so traffic to the wider internet can be capped while the local network is left alone.
The permission part lists each permission granted, the resources it covers and the actions allowed on them.
Neither part is advisory: while the application runs, the Policy Manager holds it to the limits and the Security Manager to the permissions.
- Threads
Application code, in Java or in Managed C/C++, running as an independent execution flow within an application.
- Static Resources
Read-only files packaged with the application.
VEE Energy Kernel
The Kernel owns the hardware resources, provides common services, manages the application lifecycle and answers their calls.
This is the Kernel & Features model of MICROEJ VEE applied to a meter. Read more
Kernel API
The Kernel API is the set of APIs that the Kernel exposes to the applications.
The Kernel API provides a narrow surface that reduces the reachability of the underlying resources and provides more control of which features the Kernel exposes to untrusted applications.
Kernel APIs used by a Sandboxed Application are checked at compile time by MicroEJ SOAR compiler.
The APIs have additional protections provided by the Security & Policy Managers.
- Security Manager
The Security Manager controls API access based on a permission system: each API is protected by a permission that must be assigned to the application to allow it to call the API.
Permissions are assigned to an application in its policy file. Read more
- Policy Manager
Enforces the CPU, RAM, flash and network limits defined in the application’s policy file. Read more
MicroEJ Core IPs
Under the Kernel sits the MicroEJ foundation, the same on every VEE Energy device: the engine that executes Managed Code, and the two frameworks built on it.
Native Interface
The Native Interface is the barrier between Managed Code and native code. A method of the Kernel calls a native C function, passes parameters, gets a return value and can share memory with it. Native functions are typically the code that addresses the hardware, and they are part of the Board Support Package (BSP) of a given device.
Nothing above the native interface addresses the hardware directly, so the same Kernel and application code runs on another board once its VEE Port exists. MICROEJ VEE specifies it as the Simple Native Interface (SNI). Read more
VEE Port
A VEE Port is MICROEJ VEE implemented for one device: its processor, its peripherals, its real-time operating system (RTOS) or OS, and a toolchain. Changing any of these parameters changes the VEE Port, but nothing above it.
System Components
The diagram below shows the same architecture in more detail, and two flows run through it.
Data goes up: metering samples enter through the native layer, are treated, acted upon, and can be analyzed in the Kernel or by a Sandboxed Application, and leave the device over an application-layer protocol/transport layer, in this example MQTT over TCP/IP, toward the cloud.
Management comes down: an application is installed remotely or locally through AppConnect, and both paths end at the same App Service.
Core Services
Core Services are what the Kernel runs for itself and shares with the applications. Sharing them keeps an application small: it carries no clock, no storage and no logging of its own.
- Resource Monitoring
Measures CPU and RAM usage, per application.
- Connectivity Manager
Network and internet state.
- Service Registry
Where services are registered and looked up.
- Timer
The shared scheduler for delayed and periodic tasks.
- NTP Service
Clock synchronization over the Network Time Protocol (NTP), once the internet is reachable.
- Storage
Applications, configuration and application data. Read more
- Serialization
Protobuf, FlatBuffers, Concise Binary Object Representation (CBOR) and DataStream. Read more
- Logger
Log records to the output, a file or the network.
App & Device Management
The two paths are complementary: the remote one reaches a deployed fleet from the internet, the local one only from the network the device is on. The App Service performs the installation either way, once the signature has been checked.
- LWM2M Client
Lightweight Machine to Machine (LWM2M): registers the device and receives its commands, over the Constrained Application Protocol (CoAP). The remote path, from the management system.
- App Service
Lists, installs, starts, stops and uninstalls applications.
- AppConnect Server
The Kernel side of the local path, reachable on the LAN of the device or over serial, never from the internet. Read more
- Signature Verification Service
Signature and certificate chain verification, before an install.
- HES Connector
The connection to the Head-End System (HES), written for the deployment it serves.
Message Dispatch
Data is distributed with MQTT. The Kernel publishes its measurements on a broker running on the meter itself, applications subscribe to it, and a separate client forwards data off the device.
- Platform API Service
The message interface applications see: the Kernel implements the MQTT topics of the API of the Grid Edge Interoperability and Security Alliance (GEISA), from platform discovery and status to instantaneous, billing and waveform data, actuators and sensors. Read more
- MQTT Broker (on-device)
MQTT version 5 over TCP.
- Protobuf Data Schemas
The shape of what travels on those topics.
- MQTT Client
Publishes off the device, over Transport Layer Security (TLS).
Network
The protocols the Kernel and the applications share, from the sockets up to the secure channels over them.
- Transport & Messaging
TCP, UDP, HTTP, MQTT, CoAP, WebSocket.
- Wi-Fi, Ethernet, LTE
The links the device reaches the network over.
- Secure Channels
TLS over TCP, Datagram TLS (DTLS) over UDP.
- Bluetooth Low Energy (BLE)
A short-range wireless link. Read more
Metrology Services
The metrology engine holds the legally relevant measurements, and usually runs on a core of its own. Metrology Services are the Kernel’s side of that boundary: a set of APIs that carry the measurements up to the applications, without an application reaching the engine itself.
- Metrology API
High-level, protected access to the measurements. Calls pass through the Security Manager and the Policy Manager, like any other Kernel service.
- CMDM
The MicroEJ Canonical Measurement Data Model (CMDM). One model of the measurements that does not depend on a metering protocol, so DLMS, ANSI (American National Standards Institute) and the rest are built on top of it, in deployable applications.
Cryptography
One cryptographic API serves the Kernel and the applications, on top of the Security (Crypto) module of the VEE Port.
- Crypto API
Platform Security Architecture (PSA) Crypto and Java Cryptography Architecture (JCA). Read more
AI
Analysis runs on the device, on the data already in the Kernel, without a round trip to a back end.
- MicroAI
Runs trained inference models. Read more
- PicoAI
Unsupervised clustering and anomaly detection, by MicroEJ partner Boon Logic.
Foundation Libraries
The libraries MICROEJ VEE defines, each one the managed half of a VEE Port module. Read more
- EDC
Embedded Device Configuration: the minimal runtime, the base of every other library. Read more
- BON
Beyond Profile: memory control, immortal objects and timers. Read more
- KF
Kernel & Features: the model the Kernel and the applications are built on. Read more
- SNI
Simple Native Interface: calling native code from Managed Code. Read more
- DEVICE
Identification of the device.
- SERIAL
Serial port communication. Read more
- MICROUI
Display and user input. Read more
- NET
TCP and UDP sockets.
- SSL
Secure Sockets Layer: secure sockets.
- FS
Access to the file system (FS).
- TRACE
Recording execution events. Read more
VEE Port Abstraction Layer
The modules below define the VEE Port Abstraction Layer that VEE Energy needs; each implements the low-level API of one Foundation Library.
- Metrology Native Bridge
Receives and processes the waveform samples, over UDP when they come from the simulator. This is where a real metrology engine is integrated.
- Core (VM / BSP / Clock)
The Core Engine on the Board Support Package (BSP). Read more
- KF RAM
Memory for installing applications. Read more
- Device (ID)
The unique identifier of the device.
- Event Queue
Native events into Managed Code. Read more
- File System
Access to the storage of the device. Read more
- Native CPU Load
Processor load, measured natively.
- Util (Async Worker)
Blocking native calls, off the managed threads.
- Net (Sockets)
TCP and UDP sockets. Read more
- Ecom-Network
The network interfaces of the device. Read more
- SSL / TLS
The native side of the secure channels. Read more
- Security (Crypto)
The native cryptographic primitives. Read more
- Serial (UART)
The Universal Asynchronous Receiver-Transmitter (UART) ports. Read more
- RTT
Real Time Transfer, a debug data channel.
- Trace (CTF)
Traces in the Common Trace Format. Read more
- UI (Display / Touch)
Display and touch, where there is one. Read more
- IEC 61850
The substation communication standard of the International Electrotechnical Commission (IEC).
Remote Tools & Systems
The Analog Front End (AFE) Simulator, the Resource Profiler and the AppConnect Clients are MicroEJ tools; the others are the systems of a deployment.
- MicroEJ Resource Profiler WebApp
Shows what Resource Monitoring pushes to it.
- ADM System
The remote Application & Device Management (ADM) back end, GEISA compliant.
- AppConnect Clients
The local management tools.
- HES
The Head-End System of the utility, whichever one the deployment uses.
- Remote MQTT Broker (off-device)
Receives what the device publishes.
- Data Visualization
Telegraf, InfluxDB and Grafana on that broker.
- MicroEJ Metrology AFE Simulator
Streams waveform samples over UDP, so the stack runs without meter hardware.
Where to Go Next
This page stops at what each part is for.
Kernel & Features and the application security policy, for the Kernel and what it grants applications.
Sandboxed Applications, for writing and deploying one.
The VEE Porting Guide, for the device side.
The Glossary, for the terms used here.
Note
For more information about VEE Energy, please contact your MicroEJ sales representative.