ASAM MBFS

History

Work on the standard started in 1997 within the MSR (Manufacturer Supplier Relationship) organization. Major drivers of the standardization were Continental (formerly Siemens Automotive) and Daimler. They regularly faced the challenge to convert functional models from ETAS ASCET, which they received from Bosch, to their preferred model-based development tool MathWorks Simulink. The translation of models turned out to be very time consuming and error prone. There was no clear 1-on-1 relationship between the blocks of ASCET and Simulink, so that the translation of models caused work that was comparable with the original development efforts of the functional models.

Continental, Daimler and other companies joined forces in the MSR MEGMA working group with the goal to solve this problem. Their original goal to define a standard that allows seamless model exchange was quickly dropped, because the behavior of simulation engines from ASCET and Simulink were too different. The group then focused on the definition of a blockset that is available in both tool environments. They chose the ASCET blockset as a baseline and created a standard that allows an implementation of the same blockset in Simulink. The working group also published a reference implementation of the MEGMA blockset for earlier versions of Simulink.

The MSR MEGMA working group created the first versions of the standard up to version 1.16. In 2005, the standardization activities had been transferred to ASAM. The standard was renamed to MBFS (Model Based Function Specification) and released as ASAM MBFS V1.0 by the end of 2006. This release includes a detailed description of a reference implementation of the MBFS blockset in MATLAB and Simulink.

 

Motivation

Embedded software development in the automotive industry increasingly relies on model-based development and graphical programming. This has the advantage that algorithms are better understandable for engineers and are better documented. Models serve as executable specifications throughout the development process and are the input for production code generators. This single source concept in control strategies development saves enormous time and reduces the number of potential error sources.

The core of model-based development is the blockset, which essentially represents a graphical programming language. Several vendor-specific tool-suites emerged on the market that use different blocksets with different semantics and different graphical representations. In the automotive industry, ETAS ASCET and MathWorks Simulink are widely used. Although their proprietary blocksets provide roughly the same functionality, many small differences in block semantics and appearance makes conversion of models very labor intensive and error-prone.

ASAM MBFS (Model Based Function Specification) overcomes this problem by setting a vendor-independent standard for a blockset library with typical automotive operators and functions. If this blockset is used in models, then function developers and application engineers read the models the same way and have the same understanding of their functionality. ASAM MBFS is an essential part of company-specific modeling guidelines, which stipulate the use of specific blocks for functional models. The standard in conjunction with modeling guidelines guaranties that the models can be used in all stages of the development process and are ultimately ready for production code generation. The standardized blockset furthermore helps to save ROM resources in the ECU, since it allows production code generators to reuse the same code for the same functions.

With ASAM MBFS, models from different tool suites are exchangeable without translation. One block in one tool vendor's model has exactly the same appearance, interface and functional behavior than the same block in another's vendor's tool suite. Models still need to be converted to tool-specific description formats, but this conversion does not require any kind of translation of functional behavior of blocks, nor do models have to be re-wired due to different port arrangements at blocks. As a result, model conversion is fast and safe, if ASAM MBFS is used.

Another advantage of blockset standardization is that engineers only have to learn one language. Without standardization, they would have to learn several "dialects", which is more time consuming and runs the risk that the dialects are confused with each other, causing misinterpretation of models and wrong designs. Furthermore, a standardized language is the prerequisite that training is offered at universities and independent training providers on a larger scale.

 

Application Areas

Model-based function specification is state-of-the-art in automotive control system and software development. The ASAM MBFS blockset is the graphical language for function designs expressed in executable specifications, also called models. In many automotive companies, models are the foundation of the embedded controls software development process. They are being used in rapid-control prototyping, production code generation and XIL-simulation techniques such as MIL, SIL, PIL and HIL.

ASAM MBFS has been specifically developed for the application in tools that provide an environment for simulation and graphical programming for embedded control systems. The blockset is typically part of a suite of tools, which includes a graphical block diagram editor, a simulation engine, a code generator and documentation generator. Formal and standardized languages, such as ASAM MBFS, can serve as a prerequisite for the certification of ECU software in accordance with IEC 61508 and ISO 26262.

Although ASAM MBFS is more geared towards control strategies design, the blockset can also be used for plant modeling.

 

Technical Content

Scope

The ASAM MBFS standard specifies the appearance and functional behavior of blocks for model-based development tools. The standard defines the block icon, placement and name of inports and outports, initialization behavior and runtime behavior. The behavior is specified via C-like pseudo code. Test cases are given that allow to verify the standard-compliance of block implementations.

The standard focuses on the specification of behavioral blocks. It does not cover more advanced aspects such as virtual blocks, block diagram architecture, the simulation engine, document- and code-generation.

Virtual blocks provide essential functions for signal routing and visualization of simulation results. Since they do not have any functional behavior (no impact on simulation or code generation), they are not included in the standardization. The same statement applies to blocks that would determine the architecture of block diagrams.

The simulation engine calculates simulation results during block diagram execution. As such, it determines the interplay between blocks in dependence of a chosen execution order, execution rate and data types of their input and output signals. ASAM MBFS has been written to be independent of the computation model of the simulation engine. The standard gives only a few hints on execution order and data type handling. Code generation and document generation are out-of-focus for ASAM MBFS.

General Characteristics of Blocks

Block input and output data types are categorized as "real" or "logic". "Real" covers all data types that represent real numbers such as fixed-point or floating point numbers. The default data type for "real" in the C language is "double". "Logic" represents Boolean values, i.e. "true" or "false". The default data type for "logic" in the C language is "unsigned char". Blocks may also have internal data of type "integer", containing whole positive and negative numbers including zero.

The external interface of a block may consist of:

  • signal inputs
  • signal outputs
  • control inputs, such as E (enable), R (reset), RT (trigger reset) and IV (initial value)
  • parameter inputs, such as MX (maximum), MN (minimum), dT0 (initial value for dT) and others
  • internal constants
  • application parameters, which are not modifiable in the model but can be changed during run time via an application system

dT is a special parameter in some blocks that contain the time that has passed between two successive calls of the block. Some control inputs, parameter inputs and signal outputs are optional. In this case, their ports do not appear at the block icon.

All blocks in ASAM MBFS have discrete-time behavior.

In multi-rate execution, the block's reset function shall be executed first, then the actual calculation shall be carried out and the output shall be written to the outports in the last step. Furthermore, each block has an initialization routine, which shall be executed at simulation start. Default values are given for unspecified control and parameter inputs.

The block specification does not include measures to handle division-by-zero, saturation, underflow, overflow and faults by a lack of precision. It is the responsibility of the model designer to prevent  or handle such situations.

List of Blocks

The following table contains the names of all 70 blocks of ASAM MBFS, their assignment to functional groups and a brief description of the functionality of the group of blocks.

Group Blocks Description
Arithmetic operators • Division
• Gain
• Multiplication
• Negation
• Sum
• Subtraction
Carry out basic mathematical operations.
Logical operators • AND
• NOT
• OR
• XOR
Carry out basic logical operations.
Comparison operators • ClosedInterval
• EQ
• GE
• GT
• LE
• LT
• LeftOpenInterval
• NE
• OpenInterval
• RightOpenInterval
Compare input values.
Mathematical functions • Square
• SquareRoot
Carry out complex mathematical functions.
Counters and timers • CountDownResetEnabled
• CountDownResetTriggerEnabled
• CounterResetEnabled
• CounterResetTriggerEnabled
• StopWatchResetEnabled
• StopWatchResetTriggerEnabled
• TimerRetriggerResetEnabled
• TimerRetriggerResetTriggerEnabled
• TimerResetEnabled
• TimerResetTriggerEnabled
• DeltaTime
Provide counter and timer operations. Counters use an increment or decrement of 1. Watches use an increment of dT. Timers use a decrement of dT. dT (DeltaTime) is the time difference between the current and last execution step of the block.
Delay blocks • DelayResetEnabled
• TurnOnDelaySample
• TurnOnDelayTime
• TurnOnDelaySample
• TurnOnDelayTime
Passes signals or signal transitions through with a delay measured in number of execution steps or dT.
Memory blocks • DeltaOneStep
• DifferenceQuotient
• EdgeBi
• EdgeFalling
• EdgeRising
• RSFlipFlop
• SampleAndHoldResetEnabled
Provide operations whose current result depend on the signal value of an earlier execution step. Operations include the calculation of real signal differences, transition detection of logical signals or latching of real and logical signals.
Nonlinear blocks • AbsoluteValue
• DeadBand
• DifferenceLimiter
• GradientLimiter
• Hysteresis
• Limiter
• Maximum
• MaxLogResetEnabled
• MeanValueTResetEnabled
• Minimum
• MinLogResetEnabled
• Signum
Carry out basic, non-linear mathematical operations.
Integrators • AccumulatorResetEnabledLimited
• IntegratorKResetEnabledLimited
• IntegratorTResetEnabledLimited
Carry out signal accumulation or time-discrete integration. Output has upper and lower limits.
Low- and highpass • DigitalLowpassResetEnabled
• HighpassTResetEnabledLowpassKResetEnabled
• LowpassSecondOrderResetEnabled
• LowpassTResetEnabled
Carry out high- and low-pass filtering of signals. Low-pass filtering available with first-or second-order filters. Otherwise first-order filters, only.
Parameter and constant • Curve / 1D Index Lookup Table
• Curve / 1D Interpolation Lookup Table
• Map / 2D Index Lookup Table
• Map / 2D Interpolation Lookup Table
Provide 1D- and 2D-lookup table operations with and without interpolation.
Signal path switches • Switch Select and route signals.

The definition of a block for scalar and array values has been intentionally omitted, as simulation tools are deemed to have sufficient support for this functionality.

 

Industry Adoption

The market for model-based simulation and software development tools has been dominated by a few companies from the US and Germany that started to offer tools of this kind in the early 90th. Their proprietary blocksets has been widely used in plant and controller designs for nearly 10 years before the first versions of ASAM MBFS have been published. The standard encountered a nearly occupied area and therefor adaption of ASAM MBFS had been slow from the beginning.

Today, implementations of the ASAM MBFS blockset are available in Simulink from MathWorks, TargetLink from dSPACE and ASCET from ETAS. They exist in parallel to their proprietary blockset libraries. Although tool suppliers are generally committed to support the standard, they failed to make advanced features available such as efficient code generation and full fixed-point data type support. As a consequence, ASAM MBFS has not yet succeeded in getting a wide acceptance in the automotive industry.

Some large automotive OEMs in Germany have developed their own implementation of ASAM MBFS to overcome the shortcomings of the tool-vendors' implementations. ASAM MBFS-compliant block libraries are part of the corporate powertrain control development tool chains at Volkswagen (including Audi and Porsche) and Continental Automotive. Further implementations exist in other companies at department-level. ASAM MBFS is the agreed standard in joint development projects that include multiple companies and frequent model exchange.

 

List of Deliverables

The standard includes the following deliverables:

  • Standard document
  • Description of a reference implementation in MATLAB and Simulink

 

Further Reading

Our newsletter informs you when a new standard version is released.
Subscribe