This page provides MAP eFMI publications, most importantly the , but also accompanying documents like example eFMUs, introductory presentations, overview papers, project reports and forms etc. For an overview of third party eFMI tooling, please consult the . The publications of MAP eFMI can be categorized in:

releases

There exists no current stable release yet. The first release will be the upcoming ; in the meantime, please see the current candidate-drafts.

The next major upcoming release is version 1.0.0; below are the candidate-drafts for it. Please see for details about the release schedule and for an estimation of maturity of candidate-drafts.

There are no previous stable releases yet. We are still in the process of finishing the first official release; please see the current candidate-drafts.

MAP eFMI published tooling

MAP eFMI provides a set of open source tools and libraries to foster the eFMI ecosystem. For tooling, including commercial tools, that are not MAP eFMI published, please see the . For final release distributions of MAP eFMI published tooling, please check each individual tool’s repository; note that we apply a unique such that every tool version can be mapped to the it supports and vice-versa. The tools published by MAP eFMI are:

Project organization

Recommended documentation and introductory material

Example eFMUs

Drivetrain torque controller with eFMI 1.0.0 Alpha 4

• eFMU (zip)

Example eFMU with Algorithm Code, Production Code, Binary Code and Behavioral Model containers for a drivetrain torque controller. The example and its original Modelica model defining the physics of the drivetrain (the plant model) are test case M04 of the eFMI crosscheck test cases. The embedded controller developed in the eFMU is an approximated inverse model of the drivetrain plant model combined with a simple PI controller. The respective Modelica models of the test setup and controller are:

The example eFMU provides the following eFMI containers, each generated by varying eFMI tooling:

• A Behavioral Model container providing two test scenarios and the original Modelica model defining the controller subject to embedded code generation.
• An Algorithm Code container providing GALEC code – i.e., an algorithmic, causal solution – for the controller; it has been generated using Dymola (Dassault Systèmes).
• Four Production Code containers for the Algorithm Code container, generated using two different tools: CATIA ESP (Dassault Systèmes) and TargetLink (dSPACE GmbH). With each tool two production codes are generated, a 32-Bit and a 64-Bit floating point precision version. All 4 production codes pass MISRA C:2012 checks with Cppcheck 2.10.
• A Binary Code container for the 32-Bit production code of CATIA ESP, targeting Windows x86 and generated using CATIA ESP (Dassault Systèmes).

TPT (PikeTec GmbH) has been used to validate each production code against the scenarios of the Behavioral Model container. The respective test results are stored in TestResult folders of their respective Production Code containers. Minor differences due to floating point precision are visible by the TPT tests; still all 32-Bit compared to 64-Bit floating point precision results are within the tolerances of the test scenarios defined in the Behavioral Model container’s manifest.

The final content of the collaboratively developed eFMU is:

Note that manifests link dependent containers for traceability. Production code manifests, for example, link back to the Algorithm Code container they implement by means of ManifestReference and individual ForeignVariableReference for each block-variable of the original GALEC code. eFMU consistency between dependent artefacts is ensured by means of SHA-1 checksums. For example, the GALEC code of an Algorithm Code container is listed as File element with a mandatory checksum; likewise, the ManifestReference of a Production Code container’s manifest lists the checksum of the respective Algorithm Code container manifest it implements.

The schemas folder contains the XSD Schemas for all manifests as defined in the eFMI Standard 1.0.0. The __content.xml of the eFMU’s root directory lists all containers of the eFMU; it is the unique entry point for reading and working with the eFMU.