From fragmented interfaces to a common data sharing framework: the FLEXMCS Open Operational Architecture

A single megawatt charging session for a long-haul electric truck involves the physical and digital interaction of a driver, a fleet planner, a route planning tool, a charge point operator, a charging point management system connected to an energy management system, a battery storage unit and a grid operator. Today, very little of that exchange is standardised. FLEXMCS Open Operational Architecture maps every actor, component and interface involved, and (in a future release) it will shows exactly where the standards are still missing.

The problem is not the charger, it is everything around it

When a long-haul battery-electric truck (BET) stops for 45 minutes at a highway service station, a lot has to happen in the background: the trip has to be planned around the stop, a charging slot has to be reserved, the driver has to be authenticated and guided to the right bay, the site has to deliver several hundred kilowatts without breaching its grid connection, and the fleet manager has to know when the truck will leave. Each of those steps sits in a different system, owned by a different company.

There is currently no widely adopted framework governing the information exchange needed to coordinate these operational, technical and commercial processes. The result is fragmentation across interfaces and integration effort that has to be repeated for every new combination of truck model, hub and software provider.

The FLEXMCS’ Open Operational Architecture (OOA) is the project's answer: a structured description of the actors, components and interfaces required to run electric heavy-duty transport in a public charging context, and an explicit inventory of which standards already cover each connection.

Two use cases considered

The architecture is built on two concrete situations that reflect how long-haul electric transport is expected to operate at scale.

1.       Fast charging during the mandatory break. A highway service station equipped with Megawatt Charging Systems. The session lasts from 45 minutes to about one hour, at a charging power typically in the range of DC 500 kW to DC 1 MW, and it has to deliver enough energy for another four to five hours of driving. The deliverable coversthe full sequence, from slot reservation by the dispatcher or fleet management system, through licence plate or access code check-in, Plug and Charge authentication, live energy feedback to the driver, and rebooking to a nearby alternative if all chargers turn out to be occupied.

2.       Overnight charging during the daily rest period. A dedicated safe truck parking facility on a major corridor. Here the vehicle can stay connected for up to around nine hours to reach 100% state of charge, at a much lower power of roughly 150 kW DC. The objective shifts from speed to balance: charging is scheduled against the expected dwell time and the available grid capacity, and site access control, parking management and security become part of the service.

Each use case has explicit success and failure conditions, which is what makes them usable as a design reference rather than a narrative.

What is inside the architecture

The architecture is organised into six business roles: vehicle operation, fleet operation, public charging hub operation, digital tool providers, energy providers, and offline tools. Every requirement, component and interface is assigned to one of them, which makes responsibilities and boundaries visible.

Within that structure, D4.3 delivers:

• A stakeholder map covering consortium partners and, deliberately, actors outside the project: municipalities and other permitting authorities, third-party FMS and TMS vendors, and standardisation committees.

• Requirements at three levels, from two project-level objectives down to 23 business requirements and 21 technical requirements, each traceable to the business requirement it serves.

• A component inventory of more than 30 elements, classified as software, hardware, software under development, hardware under development, or actors. The last two categories matter: they flag things like the vehicle digital twin platform, the site geographic optimisation tool and the hub's grid quality monitor, which are not yet standard parts of a charging hub deployment.

• A review of more than 20 application-layer standards and protocols, each mapped to the components it connects, with its approval status and current level of adoption.

• The architecture diagram itself, distinguishing power connections, data connections and actor interactions, with the relevant standard named on each data link.

Undefined connections

The diagram uses a question mark wherever a data connection is needed but no single standard is established, or where several competing options exist. Those question marks are arguably the main output of this intermediate version.

Three areas stand out.

Energy management system interfaces. All interfaces around the EMS require a standard, and several candidates exist: OSCP, S2, EEBus, IEEE 2030.5, OpenADR and others. None has become dominant. FLEXMCS has deliberately not picked a winner yet.

Fleet operation software. Interfaces between transport management systems, fleet management software and route planning tools are not consistently standardised, partly because the same functions are packaged differently by different vendors. Fleet management and transport management functionality often sit in a single product rather than two.

Vehicle and driver-facing links. The FMS standard exists but covers EV-specific parameters poorly, which is why the diagram shows "FMS+", an interface expected to need extension. The in-cab application interface to the fleet management layer is frequently proprietary, tied to a specific vehicle brand, with no widely adopted cross-manufacturer standard.

By contrast, several interfaces are already well served, and the diagram names them directly: ISO 15118-20 between vehicle and charger, OCPP between charger and charging point management system, OCPI for reservations and roaming, OpenADR and IEC 62325 towards grid and market actors.

What happens next

This is an intermediate version. The remaining work, a justified selection among competing standards and a specification of the information content required where no standard exists, will be delivered in D4.5 "Open Operational Architecture, final", due in April 2027.

That leaves a window in which external input can still shape the outcome. If you operate charging hubs, run electric trucks, build fleet or energy management software, or work in the relevant standardisation groups, the project is interested in hearing where this architecture matches your reality and where it does not.

Read the full deliverable: https://www.flexmcs.eu/deliverables