Advances in Automotive System Modeling: EAST-ADL (Part 1): Page 3 of 6

May 16, 2013 //By DeJiu Chen, KTH; Lei Feng, Volvo; Henrik Lönn, Volvo; Juha-Pekka Tolvanen, MetaCase
Advances in Automotive System Modeling: EAST-ADL (Part 1)
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 HMIs.
the specification of vehicle level requirements. EAST-ADL supports capturing different kinds of requirements, including quality related extra-functional concerns, along with their bindings to various artefacts in the system development lifecycle. Requirements can also be imported from existing requirements management tools and aligned with EAST-ADL models. For example, in Figure 2 AdvancedBraking feature satisfies the Anti-LockBraking requirement. Such relation to features, or other kind of model elements, can be then later incorporated back to possibly used external requirements management tools.

Implementation independent architecture

The core part of the EAST-ADL, as its name suggests, focuses on the specifications of multi-levelled system design in terms of architectures. As the first step towards the realisation of expected vehicle features, the complete electric functionality of an automotive embedded system can be specified as an implementation independent functional analysis architecture. Such an architecture specification is characterized by the composition of some interacting abstract application functions. Each of these functions is specified by its input-output interfaces, execution patterns, as well as related behavioural and extra-functional constraints. Figure 3 shows a part of the ABS related functional architecture specification. Here ABS_1 function is connected with a brake force request to Brake_1, which is an abstract actuation device (FunctionalDevice). This brake actuation device then provides a physical energy flow representing the actual brake torque.

Figure 3. Functional analysis architecture related to ABS. For higher resolution click here.

EAST-ADL follows a type-prototype pattern for component definition and instantiation. For example, the function types such as the ABS and BrakeActuator, can be instantiated multiple times for the different brake instances (in this electric vehicle there are actually four brake function prototypes – one for each of the four brakes).

Similarly to the feature models, the various requirements can be mapped to individual architectural elements, enabling tracing and analysis on how the system meets the various requirements. Here the ABS_1 function is satisfying a Brake force reduction requirement derived from the

Design category: 

Vous êtes certain ?

Si vous désactivez les cookies, vous ne pouvez plus naviguer sur le site.

Vous allez être rediriger vers Google.