Advances in Automotive System Modeling: EAST-ADL (Part 2)

Advances in Automotive System Modeling: EAST-ADL (Part 2)

Technology News |
For decades developers of automotive embedded systems have enjoyed the benefits of modeling. Models have not only served communication and gaining better understanding but are also used to prototype, analyze, simulate and test the developed systems. With dedicated generators it has also been possible to produce production-quality software code from the models. Typical cases of code generation are various control-engineering solutions and infotainment systems with HMI’s.
By eeNews Europe


Behaviour description and analysis

With EAST-ADL, developers can capture and formalize various behaviour concerns, motivated by the needs of requirements engineering, quality predictions, design verification and validation, safety engineering. For the formalisation of behaviour descriptions, EAST-ADL provides a hybrid-system model that integrates both discrete-event and continuous-time behaviour models. All behaviour descriptions are managed seamlessly together with the specifications of requirements, system design and constraints, and verification and validation cases. Figure 8 shows an example where function type ABS is constrained by ABS_BehaviorConstraint.

Figure 8. Annotating behaviour constraints on the ABS function.

EAST-ADL captures formally three categories of behavioural constraints. It is up to the engineers, in their particular design and analysis contexts, to decide the exact types and degree of constraints to be applied. These categories of behavioural constraints are:

Attribute Quantification Constraint – relating to the declarations of value attributes and the related acausal quantifications (e.g., U=I*R). Temporal Constraint – relating to the declarations of behaviour constraints where the history of behaviours on a timeline is taken into consideration.Computation Constraint – relating to the declarations of cause-effect dependencies of data in terms of logical transformations (for data assignments) and logical paths.

Let’s consider an example of the attribute quantification constraint to be met by the ABS function. In Figure 9, the VehicleSpeedIn and WheelSpeedIn are two monitored variables received from the ports. These two external variables together with the constant WheelRadius decide the estimated SlipRate according to the quantification Condition[SlipRateQuantification].

Figure 9. Annotating attribute quantification constraint on the ABS function. For full resolution click here.

In Figure 10, the behaviour constraint is further elaborated by capturing the ABS control logic in terms of a state machine. The state invariants and transition guards are precisely defined by some attribute quantification specifications, such as Conditon[VehicleSpeedIn > ABSVehicleSpeedThreshhold] and Conditon[SliprateThreshhold <= SlipRate <=1].

Figure 10. Annotating temporal constraint on the ABS function. For full resolution click here.

Figure 11 shows the related computation constraints on the ABS function. The specification declares two allowed invocations to the transformation Set_ABSBrakeTorqueOut() that calculates the ABS brake torque request.

Figure 11. Annotating computation constraint on the ABS function. For full resolution click here.

In regards to the execution of application functions, EAST-ADL, through its timing model, enables specifying the mapping of overall timing constraints to the timing properties of individual functions for multitasking. For each system function such timing properties include the preferred triggering policy (e.g. time- or event-triggered) and related timing constraints (e.g. response time, precedence and synchronization). If triggered, each system function runs according to a run-to-completion semantics.

EAST-ADL aims to obtain most of its analytical leverage through well established analysis methods and tools. To this end, the support for model transformations from EAST-ADL behaviour models to external analysis tools includes SPIN, UPPAAL, Matlab/Simulink and Modelica.

Let’s consider an example of exhaustively verifying the behavioural model against requirements with the model checker SPIN. The verifiable requirements include assertion, freedom of deadlock, reachability of the desired state, avoidance of or compliance with given execution patterns, and linear temporal logic (LTL) statements. We have defined the generic mapping rules between EAST-ADL behaviour constructs and PROMELA language used to specify SPIN models.

The mapping rules are implemented as an algorithm in MetaEdit+ to automatically transform the behaviour model of EAST-ADL into the SPIN model. Figure 12 shows the PROMELA code section of the ABS function. The assertion statement assert(0) guides SPIN to search the execution path to reach the statement and the path indicates the locked condition of a wheel. In model checking terminology, the path is a counterexample, which gives the designer the hint on how the given state may be reached.

Figure 12. The PROMELA Code Section of the ABS Function. For full resolution click here.

To illustrate the analysis leverage through SPIN, the verification result on this assertion is shown in Figure 13, with the screen snapshot of the SPIN printout. The top line shows the version of the SPIN model checker and the following two lines the applied algorithm options. At the lower section can we see the memory usage of this verification: the actual usage is 154 MB. The last line indicates the execution time, i.e., 4.63 seconds. The reader who is unfamiliar with SPIN may conveniently ignore other details. The counter example can be visualized by SPIN through both tracking variable values and examining process communication via a message sequence chart. The locking condition identified in Figure 13 occurs when the wheel speed is reduced by the brake torque but the latest vehicle speed estimate has not been calculated and broadcasted to the wheels. This scenario is possible in the current architecture because the processes are asynchronous and may occur in any order. If one wants to ensure that the ABS function always receives the latest speed estimate before making the control decision, a stricter execution and communication protocol must be enforced in the software architecture.

Figure 13. SPIN Verification Result. For full resolution click here.

Besides the assertion in the ABS function, we can check many other properties of the entire brake system, including the ABS function, driver’s brake command, wheel and vehicle body dynamics.

Dependability modeling

As an overall system property, safety is concerned with faults and failure cases and how they influence to the system. EAST-ADL aims to express precisely the safety requirements and related information along with the nominal system model in all the phases covered by the ISO 26262 reference safety lifecycle. This means that for any safety requirement EAST-ADL provides support for specifying its allocation, precise meaning, and integrity level based on the ASIL (Automotive Safety Integrity Level) classification scheme of ISO/DIS 26262.

EAST-ADL covers the specifications of safety requirements as well as their system dependability implications, including:

1. Safety goals of the overall system characterized by the vehicle level perspective

2. Functional safety concepts derived from the safety goals and their allocations to high level system functions

3. Technical safety concepts derived from the functional safety requirements and the allocations to hardware and software specific design solutions

4. Hardware and software safety requirements allocated to the hardware and software architectures at the implementation level.

Figure 14. An overview of EAST-ADL support for safety requirements and their allocations to system artifacts. For full resolution click here.

Along with the specification of safety requirements, EAST-ADL allows the formalization of system functions and operational situations for safety analysis at various levels of abstraction.

Figure 14 shows part of the modeling support for PHA (Preliminary Hazard Analysis), which is focused on hazard identification and risk assessment and thereby the definition of safety goals. According to ISO/DIS 26262, an item refers to the function(s), component(s) or system(s) that is of particular concern with regard to functional safety. With EAST-ADL, a PHA is performed at the vehicle level by examining the potential malfunctions of system features, which represent the items of a target system. To shape the top-level safety requirements, each hazard definition captures potentially dangerous item behaviours and the associated hazardous events triggered by such item behaviours occurring in specific operational situations.

Figure 15. Deriving hazardous events and safety goals of braking function through Preliminary Safety Analysis (PHA). For full resolution click here.

To facilitate safety engineering tasks, EAST-ADL tools enable creating initial error models from nominal functional architecture models. Figure 15 shows in MetaEdit+ tool how corresponding dependability and error models are produced from functional design related to regenerative breaking. These automatically produced error models can provide traces to the nominal architecture supporting safety analysis and recognizing the changes in the architecture designs.

Figure 16. Automatically generated error functions from functional design of regenerative breaking. For full resolution click here.

Mapping to existing software architectures and implementation

In the automotive domain, AUTOSAR is typically used for defining the software architecture, and various behavioural modelling tools are used to generate the code. EAST-ADL provides an ontology for models, separating system implementation from design, but does not replace the tools and notations related to the software architecture. Software components, runnables and frames on implementation level are realizations of functions and connectors on design level. Models describing the implementation can be planned and managed based on the holistic view of the vehicle provided by EAST-ADL. It is also possible to synthesize implementation elements based on the design level model. Consider the example of regenerative breaking in Figure 16: Modeling tool provides options to choose which functions are excluded from AUTOSAR-based implementation. Here local device manager BrakeRR is marked not be based on AUTOSAR and exclusion is also shown in the diagram. Such modeling capabilities are important because in practice different platforms need to live together. The mapping to AUTOSAR and other platforms can be supported in tools by providing more detailed options on how mapping to software architectures should be made as well as reporting on any missing information on making successful platform generation.

Figure 17. Choosing functions to be mapped to AUTOSAR from EAST-ADL models in MetaEdit+. For full resolution click here.


Looking from the V model, EAST-ADL is used to organize the engineering information and provide relations among elements from the early phase to implementation. It is an integrated information model for requirements and variants, features, functional architecture and hardware architecture. Timing, dependability and other non-functional annotations cater for full multi-aspect modelling and analysis. Because early phase models are supported, verification and validation can be done already on the abstract solution. We demonstrated the use of SPIN for behavioural analysis as well as generation of AUTOSAR models. Similar other integration links are implemented into MetaEdit+ from EAST-ADL to UPPAAL, Matlab/Simulink and Modelica.

EAST-ADL provides an opportunity to use a common ontology and exchange format in the industry. It is aligned with AUTOSAR and COTS tools for behavioural modelling. The language is modular and extensible for new modelling needs. With a common language, progress on tools, methods and collaboration practice will be more effective.

The challenge now is to form a critical mass, where a sufficient set of tools are available, allowing a sufficient set of users to apply the EAST-ADL. We have seen it happen with AUTOSAR tooling and platform. With ISO26262, new driveline technology, increasing complexity of embedded systems, the same collaborative approach is needed for the early phases of development, and for the addressing of requirements, dependability and other non-functional aspects.

Further reading

Automotive architecture language EAST-ADL,

Automotive architecture language EAST-ADL,


Matlab Simulink,





About the authors

DeJiu Chen received his PhD degree in Mechanical Engineering with a research on embedded computer control systems from KTH. His research interests are on systems and software architecture, model-based engineering, dependability and self-adaptive embedded systems. He has been actively involved in several research projects, including NFCCPP, ATESST, DySCAS, ATESST2, and MAENAD. From 2007 to 2009, Dr. DeJiu Chen also worked for Enea Data AB, Sweden, as a senior technical instructor. He is currently an associate professor at KTH.

Lei Feng is currently an assistant professor at the Department of Machine Design, KTH Royal Institute of Technology, Sweden. He received his Ph.D. degree from the Department of Electrical and Computer Engineering, University of Toronto, Canada, and Master’s and Bachelor’s degrees from the Department of Mechatronics, Xi’an Jiaotong University, China. His research interests include formal verification using model checking, supervisory control theory, discrete-event systems, and advanced control applications in automotive engineering. From 2009 to 2011, he was a research engineer at Volvo Technology AB in Gothenburg, Sweden.

Henrik Lönn has a PhD in Computer Engineering from Chalmers University of Technology, Sweden, with a research focus on safety-critical real-time systems. Currently at Volvo Group, Advanced Technology and Research, he has worked with prototypes, architecture modelling and communication aspects on vehicle electronic systems. He is also participating in national and international research collaborations on embedded systems development. Previous project involvement includes X-by-Wire, FIT, EAST-EEA, ATESST and TIMMO. He is currently coordinating the FP7 MAENAD project.

Juha-Pekka Tolvanen is the CEO of MetaCase. He has been involved in model-driven approaches, metamodeling, and domain-specific modelling languages and tools since 1991. He has acted as a consultant worldwide on modelling language and code generator development. Juha-Pekka has co-authored a book on Domain-Specific Modelling (Wiley 2008) and written over sixty articles for software development magazines and conferences. He holds a Ph.D. in computer science and he is an adjunct professor at the University of Jyväskylä, Finland.

Linked Articles
eeNews Automotive