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 Beta 1.

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:

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:

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.

Versioning scheme

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:

Example: A eFMI Container Manager 1.1.3 release is the fourth 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.

Backwards compatibility

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

If you are not a project member, you have no access to the repository we use to develop the eFMI Standard. Nevertheless, you can report any specification issues you found via the GitHub issue tracker of the public website repository. 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 Standard 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. We will provide feedback if we consider your issue worthwhile and tranferred it to the non-public eFMI Standard development repository or not.

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. Only members have access to the eFMI Standard development repository with the not yet published, current development branch and source code.