Article Preview
TopIntroduction
EAST-ADL is an Architecture Description Language (ADL) initially defined in the European ITEA EAST-EEA project and subsequently refined and aligned with the more recent AUTOSAR automotive standard (AUTOSAR Development Partnership, 2015) in the European FP6 and FP7 ATESST projects (ATESST2 Consortium, 2010). Currently, it is maintained by the EAST-ADL Association (EAST-ADL Association, 2015). It is an approach for describing automotive electronic systems through an information model that captures engineering information in a standardized form. The language provides a wide range of modelling entities, including vehicle features, functions, requirements, variability, software components, hardware components and communication.
EAST-ADL clearly defines several abstraction levels (see Figure 1) and at each of these levels, the software- and electronics-based functionality of the vehicle is modelled with a different level of detail. The proposed abstraction levels and the contained modelling elements provide a separation of concerns and an implicit style for using the language elements. The embedded system is defined completely on each abstraction level, and identical parts of the model are linked across abstraction levels with various traceability relations. This makes it possible to trace an entity from feature down to components in hardware and software.
Figure 1. The EAST-ADL’s breakdown in abstraction levels (vertically) and in core, environment and extensions (horizontally)
The features in the “TechnicalFeatureModel” at the Vehicle Level represent the content and properties of the vehicle from top-level perspective without exposing the realization. It is possible to manage the content of each vehicle and entire product lines in a systematic manner. A complete representation of the electronic functionality in an abstract form is modelled in the Functional Analysis Architecture (FAA). One or more entities (analysis functions) of the FAA can be combined and reused to realize features. The FAA captures the principal interfaces and behaviour of the vehicle’s subsystems. It allows validation and verification of the integrated system or its subsystems on a high level of abstraction. Critical issues for understanding or analysis can thus be considered, without the risk of them being obscured by implementation details.
The implementation-oriented aspects are introduced while defining the Functional Design Architecture (FDA). The features are realized here in a function architecture that takes into account efficiency, legacy and reuse, COTS availability, hardware allocation, etc. The function structure is such that one or more functions can be subsequently realized by an AUTOSAR software component (SW-C). The external interfaces of such components correspond to the interfaces of the realized functions. The representation of the implementation, the software architecture, is not defined by EAST-ADL but by AUTOSAR. However, traceability is supported from implementation-level elements (AUTOSAR) to vehicle-level elements. The Hardware Design Architecture (HDA) should be considered parallel to application development. On the Design Level and down, the HDA forms a natural constraint for development and the hardware and application software development needs to be iterated and performed together. There is also an indirect effect of hardware on the higher abstraction levels. Control strategies or the entire functionality may have to be revised to be implemented on a realistic hardware architecture. This reflection of implementation constraints needs to be managed in an iterative fashion. To verify and validate a feature across all abstraction levels, using simulation or formal techniques, an environment model is needed early on. This “plant model” captures the behaviour of the vehicle dynamics, driver, etc. The core part of the environment model can be the same for all abstraction levels.