Summary
When an FMU represents a virtual ECU, non-volatile memory artifacts are often required for correct behavior across runs. In multi-supplier co-simulation, there is currently no predictable standard way to discover where an FMU expects its NVM input files to be loaded from, or where updated NVM output should be written.
This becomes an interoperability problem between FMU producers, importing tools, and execution/orchestration frameworks, rather than just a local implementation choice.
Why this matters
In our environment at GM, supplier-delivered vECUs are combined into larger co-simulations, and several capabilities depend on NVM readiness and learn-state persistence rather than purely stateless execution. Internal release planning notes explicitly call out ethernet service-discovery learning, Secure ARP, and related capabilities as depending on NVM readiness.
We also see the same theme in technical discussions around current execution gaps:
the current path can support read-only behavior but does not provide a clear persistence model, and ownership of NVM persistence / learn-state reuse is still unclear;
Execution-engine NVM awareness has been unavailable or constrained enough to require re-architecture, with enablement treated as a platform milestone rather than something consumers can simply assume exists;
pipeline behavior is sensitive to NVM handling; in one investigation, disabling NVM read allowed tests to complete locally, which suggests that persistence/load behavior is operationally significant rather than incidental;
execution workflows increasingly want to run a learn step once, save resulting NVM, and then reuse that state across downstream tests, rather than repeating the learning step every time.
Current interoperability gap
Today different FMU producers can reasonably choose different conventions, for example:
putting NVM input/output files in /resources
using a subfolder under /resources
expecting external file locations managed by the orchestration layer
using tool-specific conventions for .bin, .hex, .s19, and similar formats
Those approaches may all work locally, but they do not compose well in a supplier-mixed co-simulation environment because the execution manager has no standard way to know:
whether an FMU uses NVM at all
which files or formats are relevant
where initial NVM content should be supplied
where updated NVM content will be emitted
whether the FMU expects persistence to be internal, resource-relative, or externally managed
Candidate interface options
I am not proposing a single mandated design, but I think FMI could use a standard way to expose this contract. Some possible directions:
Option 1: Declare NVM artifacts in modelDescription.xml
Add metadata that lets an FMU declare:
one or more NVM artifacts
role: input, output, or bidirectional/persistent state
expected format or media type
default relative path if resource-relative
whether external orchestration may override the location
Option 2: Add explicit API support for resolving NVM locations
Provide an interface by which the importing tool / execution manager can:
query the FMU for required NVM artifacts
provide concrete paths for initial load
retrieve concrete paths for save/export results
Option 3: Standardize an execution-time persistence contract
Define a standard convention for persistence lifecycle, for example:
preload before initialization
save on terminate, reset, or explicit checkpoint
clearly distinguish packaged immutable resources from mutable execution artifacts
What would help most
From an importer / orchestration perspective, the minimum useful capability would be:
deterministic discovery of whether NVM is used
deterministic mapping of named NVM artifacts to concrete files
a standard way to override file locations per scenario
a standard way to retrieve or persist resulting state after execution
Questions for discussion
Is there already a recommended FMI pattern for mutable persistent artifacts such as ECU NVM that I have missed?
Would the community prefer a metadata-only approach, an API-level approach, or both?
Should mutable NVM state be treated as a first-class external artifact rather than something implicitly stored under /resources?
Are there existing importer/exporter implementations already solving this in a reusable way?
Context
This comes from combining supplier-delivered virtual ECUs into larger co-simulations, where predictable load/save behavior for NVM files is needed so the execution manager can place scenario-specific initial state correctly and preserve resulting state after runs. Internally we currently have one approach that writes into /resources, but that is clearly only one convention and does not solve interoperability by itself.
The intent here is not to dictate a design, but to raise a recurring interoperability gap that seems likely to affect multiple toolchains and suppliers.
Summary
When an FMU represents a virtual ECU, non-volatile memory artifacts are often required for correct behavior across runs. In multi-supplier co-simulation, there is currently no predictable standard way to discover where an FMU expects its NVM input files to be loaded from, or where updated NVM output should be written.
This becomes an interoperability problem between FMU producers, importing tools, and execution/orchestration frameworks, rather than just a local implementation choice.
Why this matters
In our environment at GM, supplier-delivered vECUs are combined into larger co-simulations, and several capabilities depend on NVM readiness and learn-state persistence rather than purely stateless execution. Internal release planning notes explicitly call out ethernet service-discovery learning, Secure ARP, and related capabilities as depending on NVM readiness.
We also see the same theme in technical discussions around current execution gaps:
the current path can support read-only behavior but does not provide a clear persistence model, and ownership of NVM persistence / learn-state reuse is still unclear;
Execution-engine NVM awareness has been unavailable or constrained enough to require re-architecture, with enablement treated as a platform milestone rather than something consumers can simply assume exists;
pipeline behavior is sensitive to NVM handling; in one investigation, disabling NVM read allowed tests to complete locally, which suggests that persistence/load behavior is operationally significant rather than incidental;
execution workflows increasingly want to run a learn step once, save resulting NVM, and then reuse that state across downstream tests, rather than repeating the learning step every time.
Current interoperability gap
Today different FMU producers can reasonably choose different conventions, for example:
Those approaches may all work locally, but they do not compose well in a supplier-mixed co-simulation environment because the execution manager has no standard way to know:
Candidate interface options
I am not proposing a single mandated design, but I think FMI could use a standard way to expose this contract. Some possible directions:
Option 1: Declare NVM artifacts in modelDescription.xml
Add metadata that lets an FMU declare:
Option 2: Add explicit API support for resolving NVM locations
Provide an interface by which the importing tool / execution manager can:
Option 3: Standardize an execution-time persistence contract
Define a standard convention for persistence lifecycle, for example:
What would help most
From an importer / orchestration perspective, the minimum useful capability would be:
deterministic discovery of whether NVM is used
deterministic mapping of named NVM artifacts to concrete files
a standard way to override file locations per scenario
a standard way to retrieve or persist resulting state after execution
Questions for discussion
Is there already a recommended FMI pattern for mutable persistent artifacts such as ECU NVM that I have missed?
Would the community prefer a metadata-only approach, an API-level approach, or both?
Should mutable NVM state be treated as a first-class external artifact rather than something implicitly stored under /resources?
Are there existing importer/exporter implementations already solving this in a reusable way?
Context
This comes from combining supplier-delivered virtual ECUs into larger co-simulations, where predictable load/save behavior for NVM files is needed so the execution manager can place scenario-specific initial state correctly and preserve resulting state after runs. Internally we currently have one approach that writes into /resources, but that is clearly only one convention and does not solve interoperability by itself.
The intent here is not to dictate a design, but to raise a recurring interoperability gap that seems likely to affect multiple toolchains and suppliers.