This page gives a short overview of the development process of the eFMI Standard, its licensing, release cycle, backwards compatibility, and issue system. The actual eFMI Standard can be found on the Resources page. The topics covered in the following are:
eFMI Standard releases and licensing
The eFMI Standard is a freely available, open, cross-community and cross-vendor developed standard.
There is not the eFMI Standard but many separate, self-contained, but incrementally developed improvements, i.e., versions, of it. If it comes to releases of the eFMI Standard, we distinguish between the most recent stable, candidate-draft and previous stable versions. Each eFMI Standard version consists of the actual specification text and the accompanying software artefacts the specification text refers to and leverages on for defining how valid eFMUs must look like and what their meaning is. Such accompanying software artefacts are, for example, the XML Schema Definitions (XSD) for eFMU container manifests; they are distributed under 3-Clause BSD License. The actual specification text of each version is distributed under CC BY-SA 4.0 License (Creative Commons Attribution-ShareAlike 4.0 International Public License) as browsable single-page HTML5 and as a printer-suited Portable Document Format (PDF) document. It is important to understand, that any version of the eFMI Standard is the combination of both, actual specification text and accompanying software artefacts the specification text refers to for defining valid eFMUs and their meaning; just the specification text without the referenced software artefacts is incomplete. All releases of the eFMI Standard are therefore distributed as Zip-archives including both, specification text and accompanying software artefacts. eFMI Standard releases therefore ship with two licenses.
All other – i.e., not part of any eFMI Standard version – software artefacts and tooling provided by the MAP eFMI are released in coordination with eFMI Standard releases (for details about the coordinated release of eFMI Standard and tooling cf. the release cycle). Such support artefacts and tooling are released under 3-Clause BSD License. Examples for such support artefacts and tooling are example eFMUs for the varying eFMI Standard versions, the eFMI Container Manager, eFMI Compliance Checker and eFMI crosscheck test cases.
eFMI Standard releases and supporting artefacts and tooling are published on the Resources page.
Release cycle and versioning
General release organization
We are currently in the second year of our release cycle. The latest candidate-draft is the eFMI Standard 1.0.0 Alpha 4.
We aim to release a new major eFMI version (i.e., eFMI Standard and related tooling) about every 2 years; that is our planned release cycle. In the first year, new features are collected and defined, i.e., we design the:
- what, why, limitations, test scenarios, prototype implementations and…
- …feasibility study that a specification can achieve completeness of rules that can be reasonably implemented – “somebody tries to put it into rules and plays the evil guy trying to break these”.
In the second year, the proposed and accepted features are cleaned up; no new features are accepted and “if in doubt, accepted features are cut”; this comprises:
- Writing the actual specification.
- Cleaning up and preparing the release of MAP eFMI toolings and libraries.
- Tool vendors cleaning up their prototype implementations used in crosschecks to be ready for release.
- Features not crosschecked by official MAP eFMI tests or failing crosschecks are cut.
We avoid minor standard versions. Such are only for bug fixes. We are rigorous to make sure everything works before we release a major version; hence, there should be no need for bug fixing (although our versioning scheme still allows such in case of emergency). To that end major releases are only ready if, and only if, all features are tested in tooling crosschecks.
This means, that eFMI Standard releases and tooling releases are coordinated (which is reflected in our versioning scheme). After all, the eFMI technology is not useful if users have no access to a working toolchain from high-level a-causal modeling and simulation to target-specific embedded code.
Schedule of individual releases
The first candidate-drafts of a new eFMI Standard version are earliest released in the second year of development. Typically, there are an Alpha 1, Alpha 2, Beta 1, Beta 2 and finally Voting Candidate draft versions of the currently developed standard before its final release, roughly evenly spread out within the second year.
The Alpha versions are likely incomplete with open “to do” sections. The Beta versions are complete, but with edges and corners that are to be polished. The Voting Candidate is polished and as far as we know the final version. We only expect typo and minor language improvements as feedback for a Voting Candidate; by all means this is the candidate we will push in the Modelica Association for public release approval.
All artefacts released by MAP eFMI – e.g., the eFMI specification text, XML Schema Definitions for container manifests, example eFMUs, the eFMI Container Manager, eFMI Compliance Checker, and eFMI crosscheck test cases – use a certain versioning scheme consisting of three digits of the form
MAJOR.MINOR.PATCH. In principle, the scheme follows Semantic Versioning 2.0.0, with the following additional restrictions:
- All artefacts of an eFMI Standard must have the very same version. This means for example, that the versions of the XML Schema Definitions for eFMI container manifests (the XSD files / software artefacts) are aligned with the version of the eFMI specification text that uses this very definitions.
- If there is ever a need for a new
MINOReFMI Standard version (hence a pure bug-fix release of the standard according to the general release organization), all artefacts and tooling must provide new releases (incorporating any fix as needed of course), increasing their
MINORdigit respectively. I.e., the
MINORdigit denotes consecutive bug-fix releases of the eFMI Standard and the tooling for it.
PATCHdigit is only used by artefacts and tooling for some eFMI Standard, but never by eFMI Standards (their
PATCHdigit always is 0). This means, that pure tooling bug-fix releases, for the very same eFMI Standard version, are denoted by increasing
PATCHdigits of the version of the respective tooling.
Example: A eFMI Container Manager 1.1.3 release is the third release of the tool for the eFMI Standard 1.1.0, which was a bug-fix release for the eFMI Standard 1.0.0, whereas a eFMI Container Manager 2.0.0 release is the first tooling release for a completely new major eFMI Standard release.
We like to stress that
MINOR eFMI Standard version changes are pure bug-fix releases as explained in the general release organization! This means, no new features are added in such. For that reason, it is valid to just talk about, e.g., eFMI 1 vs. eFMI 2 etc. when denoting the features and general tooling of some eFMI technology space.
Our target domain – embedded, safety critical, real time software – is strict, in fact ridiculous strict, when it comes to documenting, archiving, certifying and sticking to the defined tooling versions throughout the whole development cycle of an embedded project. Changing tooling in the middle of embedded development projects comes with severe requirements on documentation, auditing and certification. In fact, it is not likely to be required because the used tooling is typically extensively tested, or even certified, before being deployed. It is very unlikely that a showstopper tooling-bug is encountered, which means that one is typically much better off to work around minor tooling-bugs than going through the hassle to document and recertify a tool change.
Considering that the eFMI technology requires a toolchain, we can safely assume that once picked, an embedded software development project sticks with the given eFMI Standard until project end. Hence, we do not have to take care of backwards compatibility from the perspective of the eFMI Standard. A standard for embedded development is rather better off by rigorously fixing shortcomings and cleaning up the specification instead of using second quality solutions to also take care of backwards compatibility.
MAP eFMI therefore reserves the right of – and in fact very likely will introduce – backwards compatibility breaking eFMI Standard changes from one
MAJOR version to the next. Embedded developers can switch to new eFMI tooling at the beginning of their next project (which can in fact be to port a released version of an existing project to a newer eFMI Standard as part of its next release – a task that should not be underestimated).
Reporting specification issues and new feature requests
You can report any specification issues you found via the GitHub issue tracker. Before opening any new issues, please consult the contributing and repository policy first. If you create a new issue, please use the label
eFMI Standard and denote the troublesome version of the standard first in the issue title, e.g., “eFMI 1.0.0 Alpha 4: The links in Chapter Foo-Bar are broken”. Further, use the
bug label for real specification bugs, the
enhancement label for general new feature requests and the
question label for general discussions.
If your organization is regularly contributing or checking for issues and releases of the eFMI Standard, or just considers eFMI as an important technology in their field of application, you should consider joining MAP eFMI. To that end, you can find an overview of the project objectives and members on the About page and the project bylaws and application forms on the Resources page.
Joining MAP eFMI as a member is the only way for organizations to get an official saying in standardization decisions, direct the future eFMI development and get early access to in-development versions of the eFMI Standard.