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

May 24, 2013 // By DeJiu Chen, KTH; Lei Feng, Volvo; Henrik Lönn, Volvo; Juha-Pekka Tolvanen, MetaCase
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.

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

Design category: