MetaEdit+ EAST-ADL tooling

Supporting automotive system and software development

EAST-ADL in a nutshell

A domain-specific modeling language

Targets specification and analysis of automotive embedded systems

Developed by industry

Compatible with AUTOSAR, ISO 26262

The following slides introduce EAST-ADL through an example of a power window system

Development process (according to V-model)

1 Requirements 2 Features 3 Analysis 4 Design 5 Implementation

Requirements trace

Safety analysis (ISO 26262)

Error analysis

V&V:

System/Integration/Unit

Case: PowerWindow system

This system is used as an example in the slides

1. Requirements

PowerWindow: requirements

PWC_Req1 User shall be able to open and close the window by requesting basicUp or basicDown

PWC_Req2 The window shall stop when it reaches fully opened or fully closed position

PWC_Req3 User shall be able to fully open or fully close the window by requesting expressUp or expressDown

PWC_Req4 At any time, the driver request has a higher priority than the passenger request

Development starts with customer needs

– Specified as requirements

– Requirements are refined during development

PowerWindow related requirements:

in Excel in EAST-ADL model

1. Requirements specification

Specified in some document (Excel, Word, etc.), requirement management tool or directly in EAST-ADL

PowerWindow:

1. Requirements specification

Tool supports requirement management and refinements

– New, updated, removed requirements

Requirements can be automatically transformed from external sources to EAST-ADL models

1. Requirements specification

The modeled requirements are refined and linked

Trace reports provide requirements analysis

Documentation and metrics generated from models

2. Features

PowerWindow: features

Basic up and down

Express up and down (optional feature)

Pinch protection

Power windows for driver

Optional power windows for passengers

Driver control for all windows (if passengers have power windows)

A system can contain a number of (possibly alternative) independent features that satisfy customer needs

– Specified as features that realize the requirements

– Features include both customer-visible and internal features

PowerWindow: features

2. Feature specification

Specify feature trees in EAST-ADL

– Mandatory feature, optional feature, alternative features

– Cardinalities, dependencies

PowerWindow:

2. Feature specification

Features specified, refined and linked with requirements

Trace report produces summary of Features satisfying and realizing requirements

Documentation, metrics and checking generated from models

3. Analysis

PowerWindow: analysis functions

Position sensor provides data on window position

Each window has its own motor controlling the movement of the window

Two kinds of detector: EndStop and Pinch

Main window controller is responsible for sending commands to each window motor

Functions handling the window position data send information to detectors

Each window (driver and passenger) has its own switches

System functionality is divided into a component structure

– Hierarchical structure

– Flow, power and service connections between the components

PowerWindow: analysis functions

3. System analysis

EAST-ADL defines analysis architecture as functions

– Functional devices and analysis functions

– Flow, power and client/server based connections

PowerWindow:

3. System analysis

MetaEdit+ supports function specification and linking with requirements and features

Reports provide tracing of features and requirements, model checking, type declaration listings and usage of types

4. Design

PowerWindow: hardware elements

DriverSwitch <Sensor> controls the driver’s requests for the power window. Requests include normal and express commands for Up and Down

MainPower <ElectricalComponent> is the main power source of the system

DDM <Node> Driver Door Module (DDM) controls window behavior of the door

WindowMotor <Actuator> WindowMotor actuator executes the commands for that window

The functional system architecture is defined alongside the hardware architecture

– Alternative allocations of logical functionality to hardware can be specified

PowerWindow: functions, hardware, allocations

4. System design

Design architecture specifies functions and connections

Hardware architecture specifies HW elements and connections

Allocation Matrix shows allocation of functions to hardware

4. System design

MetaEdit+ supports linking designs with requirements and features for traceability

Design models can be used to generate implementation

– Simulink, ARXML, EAXML, etc.

4. System design

MetaEdit+ supports integrating architecture models:

– Importing existing models, data type definitions etc.

– Checking consistency between models in other tools

– Generating Simulink models, UPPAAL, etc.

PowerWindow: integration example

4. System design

MetaEdit+ supports importing other data to EAST-ADL models

Function models can be transformed into dependability and error models for safety design

Model checking, reporting, traceability support

- Simulink

- Data type definitions

- Code

- EAST-ADL analysis architecture

Safety analysis

PowerWindow: safety analysis items

Occupant Injury hazard (severity 1): Satisfied with pinch protection moving the window down (ASIL=B)

Motor Stall hazard (severity 0):

Safe state satisfied when move max 10 sec and has endStop detection (ASIL=A)

Undesired exposure hazard (severity 0):

Prevent movement if request is not issued

The safety of the system is analyzed according to standards like ISO 26262

– Analysis is traced to original requirements

Safety analysis

PowerWindow hazard: expressUp occupant injury

EAST-ADL directly supports the safety concepts of ISO 26262 as modeling constructs

– Items, hazard, hazard event, safety goals, ASIL

– Safety analysis is traced to original system requirements

PowerWindow: Dependability model and error model

Safety analysis

Tool support enables tracing to requirements and features

Safety analysis can be extended with error models to support automated failure analysis

Initial error models can be generated from system design

PowerWindow: automated FMEA analysis

Safety analysis

Dependability analysis and optimization using error models

Models can be traced and annotated on error propagation

Analysis tools like HIPHOPS automatically perform Failure Models and Effects Analyses (FMEA)

MetaEdit+ for EAST-ADL:

Modeling editors for EAST-ADL

Model checking and reporting

Generators for software, failure analysis, requirements traceability, safety analysis, documentation, metrics

Collaborative modeling support, no merge needed

Scales to large models (up to 4 billion model elements)

Modeling languages and generators can be customized

Integration interfaces with API (SOAP/Web Services/.NET), XML format and command line support

IDE integration with Visual Studio, Eclipse and others

For examples, articles, tutorial: www.metacase.com/solution/east-adl.html

www.metacase.com info@metacase.com