EAST-ADL: Difference between revisions
No edit summary |
No edit summary |
||
Line 62: | Line 62: | ||
EAST-ADL is not governed by a formal standardization body. However, the EAST-ADL UML2 profile is represented in the EAST-ADL annex to the OMG MARTE profile. |
EAST-ADL is not governed by a formal standardization body. However, the EAST-ADL UML2 profile is represented in the EAST-ADL annex to the OMG MARTE profile. |
||
== Modeling Tools and File Format == |
|||
As of 2010, most commercial [[Comparison_of_Unified_Modeling_Language_tools | UML tools]] have not announced EAST-ADL support yet. The only tool that features EAST-ADL2 support is Papyrus UML<ref>[http://www.papyrusuml.org Papyrus UML]</ref>, developed within the ATESST project as concept demonstrator. Some tools also claim support for the older EAST-ADL1 version from 2004<ref>[http://www.metacase.com MetaEdit+]</ref><ref>[http://www.systemite.se/products/main.html SystemWeaver]</ref>, those tools did not announce an update to EAST-ADL2 yet. |
|||
Current EAST-ADL lacks a definition of a standardized data exchange file format for EAST-ADL models. Therefore, an EAST-ADL model created with one tool can not be opened with another tool. |
|||
== Links == |
== Links == |
Revision as of 09:15, 6 April 2010
This article needs additional citations for verification. (April 2008) |
Overview
EAST-ADL is a modeling language defined as a domain-specific language for the development of automotive electronic systems. The modeling element consists of different entities to represent the embedded system (requirements, features, desired behaviors, software, and hardware components) and their dependencies (refinement, allocation, composition, communication, etc.).
EAST-ADL SpotlightEAST-ADL is a domain-specific language using meta-modeling constructs such as classes, attributes, and relationships. |
EAST-ADL is defined with the development of safety-related embedded control systems as a benchmark. The EAST-ADL scope includes early analysis via functional design to the implementation perspective and back to integration and acceptance testing on vehicle level.
The main role of EAST-ADL is that of providing an integrated system model. On this basis, several concerns are addressed:
- Documentation, in terms of an integrated system model.
- Communication between engineers, by providing predefined views as well as the information sufficient for generating a number of other views.
- Analysis, through the description of system structure and properties.
Connection between EAST-ADL and AUTOSAR
EAST-ADL and AUTOSAR in concert provide means for efficient development and management of the complexity of automotive embedded systems from early analysis right down to implementation. Concepts from model-based development and component-based development reinforce one another.
An early, high-level representation of the system can evolve seamlessly into the detailed specifications of the AUTOSAR language. In addition, the EAST-ADL incorporates the following system development concerns:
- Modeling of requirements and verification/validation information,
- Feature modeling and support for software system product lines,
- Modeling of variability of the system design,
- Structural and behavioral modeling of functions and hardware entities in the context of distributed systems,
- Environment, i.e., plant model and adjacent systems, and
- Non-functional operational properties such as a definition of function timing and failure modes, supporting system level analysis.
Unlike EAST-ADL specifications, AUTOSAR specifications do not mention any relationship to EAST-ADL. The AUTOSAR project has created ist own UML profile without consideration of EAST-ADL [1]
Organisation of EAST-ADL Model
The EAST-ADL model is organized according to 4 abstraction levels:
- Vehicle level contains modeling elements to represent intended functionality in a solution-independent way
- Analysis level represents the abstract functional decomposition of the vehicle with the the principal internal and external interfaces.
- Design level has the detailed functional definition, a hardware architecture and allocations of functions to hardware.
- Implementation level relies on AUTOSAR elements and does not have EAST-ADL-specific constructs for the core structure.
For all abstraction levels, relevant extension elements for requirements, behavior, variability and dependability are associated to the core structure.
History and Specification of EAST-ADL
The EAST-ADL language has been defined in several steps within European research projects:
Project name | Time | Budget | EAST-ADL Version | Specification Download | Support by research departments of following vehicle manufacturers(OEMs) |
---|---|---|---|---|---|
EAST-EEA | 1.7.2001 - 30.6.2004 | 40 M€ | EAST-ADL Version 1.0 | No download available after project had finished | BMW, Daimler, Fiat, PSA (Peugeot/Citroen), Renault, Volvo |
ATESST | 1.1.2006 - 31.3. 2008 | 3.9 M€ | EAST-ADL Version 2.0 | http://www.atesst.org/home/liblocal/docs/EAST-ADL-2.0-Specification_2008-02-29.pdf | Daimler, Volvo (Trucks), VW/Carmeq |
ATESST2 | 1.7.2008 - 30.6. 2010 | 3.8 M€ | EAST-ADL Version 2.1 | Not published yet | Volvo (Trucks), Fiat, VW/Carmeq |
EAST-ADL is not governed by a formal standardization body. However, the EAST-ADL UML2 profile is represented in the EAST-ADL annex to the OMG MARTE profile.
Modeling Tools and File Format
As of 2010, most commercial UML tools have not announced EAST-ADL support yet. The only tool that features EAST-ADL2 support is Papyrus UML[2], developed within the ATESST project as concept demonstrator. Some tools also claim support for the older EAST-ADL1 version from 2004[3][4], those tools did not announce an update to EAST-ADL2 yet. Current EAST-ADL lacks a definition of a standardized data exchange file format for EAST-ADL models. Therefore, an EAST-ADL model created with one tool can not be opened with another tool.