Architectural Modelling Approaches

2.9.1.1EAST-ADL

The major body of work in developing a system level model approach to automotive electronics has been the EAST-ADL which has been developed as a standardized approach through a series of European collaborative projects. There is extensive literature from the project but a good overview can be derived from the ATESST2 Project Brochure (ATESST2 2010) which describes the status at the end of the project. Ongoing information is also available from the EAST-ADL Association website (http://east-adl.info) and from the website of the current MAENAD project (http://www.maenad.eu).

EAST ADL is an approach to automotive system modelling based on an architecture description language (ADL) that keeps information in a single data structure. The claimed benefits are achieved in improved development time, cost efficiency, quality and dependability. EAST-ADL was initially developed in the EAST EEA and more recently further refined in the ATESST project including compatibility with newer standards such as AUTOSAR and increased dependability analysis.

The scope of EAST ADL is functions, hardware and software for automotive embedded systems and environment. This defines architectural elements and a number of views that give useful abstractions of the overall system for specific purposes during system development lifecycle. Figure 2.10 illustrates the EAST ADL abstraction levels and extensions. Specific use cases include; feature modelling, variant analysis, environment modelling, structural and behavioural modelling of software and hardware, requirements modelling including traceability, timing and failure analysis.

The vehicle level represents an implementation independent model of vehicle feature content and properties. The analysis level contains a more detailed breakdown of functionality, but still abstracting hardware and software deployment, including interactions between functions. The design level then maps the features and functions to hardware and software architectures taking into account issues such as re-use of carryover components and use of off-the-shelf standard design elements. The implementation level details the software architecture at component level for basic software, standard software functions and application software in an AUTOSAR compliant manner.

The modelling approach used in the EAST-ADL language is through a meta-model which defines stereotypes for model entities which are implemented as a UML2 profile. This profile can then be used to create model diagrams in a UML tool with stereotyped entities such as vehicle features which already have defined property types. While EAST-ADL is based around UML2 it also makes use of some of the extensions found in SysML, which is in itself a UML2 profile, such as for requirements traceability. The models give the overall system architecture including interrelationship between functions but a function's internal behaviour is typically defined by other techniques.

EAST-ADL can support timing analysis between top down timing constraints of the functions and the bottom up properties of the implementation utilising the AUTOSAR Timing Extension. Timing requirements such as end to end delay or synchronicity can be modelled as constraints on event chains as illustrated in Figure 2.11.

Figure 2.11. EAST-ADL Event Chain with associated timing constraint (ATESST2 2010)

EAST-ADL supports requirements traceability and decomposition including those of system properties which may be safety relevant, hence it can facilitate ISO26262 processes. EAST-ADL model levels can be mapped on to ISO26262 process requirements and EAST- ADL has defined a dependency package to support analysis such as ASIL (Automotive Safety Integrity Level) decomposition and error modelling. The EAST-ADL error model describes behaviour during a fault condition and attempts to show how this could propagate throughout the system using explicit error propagation ports and connections (see Figure 2.12). These information interdependencies within the system can be used by external tools for safety analysis such as HiP-HOPS tool (Hierarchically Performed Hazard Origin and Propagation Studies) for static safety analysis in terms of FFA, FTA, and FMEA.

Figure 2.12. EAST-ADL error model (ATESST2 2010)

This illustrates a key point regarding EAST-ADL that is fundamentally a structural model showing entities and their relationships does not attempt to contain the behavioural properties of functions which require other modelling tools such as Simulink or Modelica. It is not apparent nor claimed that this will identify any form of emergent behaviour without any use of behavioural diagrams such as state charts, activity diagrams, message sequence charts. However by defining the relationships between behavioural models EAST-ADL can provide a structure to support the integration of multiple behavioural models for analysis at a system or system of systems level. Section 2.11 on formal methods will review work to use EAST-ADL to facilitate formal analysis techniques. To enable linkage between tools EAST- ADL has implemented an Eclipse-based tool platform centered around a UML2 modelling and profiling environment called Papyrus UML.

2.9.1.2COMPASS

Fitzgerald, Larsen, and Woodcock (2014) give an overview of the vision of the COMPASS project in creating a collaborative development environment for the development of Systems of Systems. Their approach, illustrated in Figure 2.13, is based on an interlinked tool architecture comprising of; a SysML modelling tool (Artisan Studio) for modelling the system of systems architecture, a platform for developing more detailed models and conducting static analysis including formal methods and dynamic simulation and analysis (COMPASS Overture) and a real-time testing platform (RT-Tester) for the development of test cases and conducting automated testing.

To facilitate the modelling of system of systems and exchange of data between tools the project will develop a modelling language called the COMPASS Modelling Language (CML). CML is based on experience of VDM (Vienna Development Method) state based formal method and the CSP/Circus process-based formal methods. The project also aims to support fault modelling and analysis at both an architectural level for the whole system of systems and detailed level for constituent systems.

Andrews, Ingram, Payne, Romanovsky, Holt and Perry (2014) describe the project’s approach to fault modelling using a set of SysML diagrams. This fault modelling profile uses structural diagrams (block definition diagrams) and behavioural diagrams (activity and sequence diagrams), to give views on nominal behaviour, fault activation, erroneous behaviour, fault tolerance and recovery mechanisms. These support understanding of the fault behaviour and the definition of the recovery mechanisms. The models are not executable but future work is to develop semi-automatic translation to the CML to allow formal verification of dependability related properties of fault tolerance models.

To address issues of confidentiality in sharing models of constituent systems, a contract approach is being developed to develop abstracted behavioural formal models of the system interface (Bryans, Fitzgerald, Payne and Kristensen, 2014). The project’s strategy to tackle the issues associated with testing large scale models is to use knowledge gained from testing the individual systems.