An architectural approach to the analysis, verification and validation of software intensive...

Noname manuscript No.(will be inserted by the editor)

An Architectural Approach to the Analysis,

Veri�cation and Validation of Software Intensive

Embedded Systems

DeJiu Chen · Lei Feng ·Tahir Naseer Qureshi · Henrik Lönn ·Frank Hagl

Received: date / Accepted: date

Abstract EAST-ADL is a domain speci�c Architecture Description Language(ADL) for safety-critical and software-intensive embedded systems. The languageallows a formalized and traceable description of a wide range of engineering con-cerns throughout the entire lifecycle of system development. This makes it possibleto fully utilize the leverage of state-of-the-art methods and tools for the develop-ment of correct-by-construction system functions and components in a seamlessand cost e�cient way. This paper focuses on the recent advancement of EAST-ADLin supporting an architecture-centric analysis, veri�cation&validation of complexbehaviors for the purposes of requirements engineering, application design, andsafety engineering. The approach is architecture centric because all behavior de-scriptions are formalized and connected to a set of standardized design artifactssitting at multiple levels of abstractions. We present the language design to sup-port this, the theoretical underpinning and tool implementation. To show thecapability of EAST-ADL, we also introduce an algorithm and its implementa-tion for transforming the EAST-ADL behavior models to SPIN models for logicmodel checking. Exploiting mature state-of-the-art technologies from computerscience, electronic engineering, and other related domains for a model-based incre-mental system development, the contribution enables the developers of embeddedsystems and software to maintain various engineering concerns coherently usingEAST-ADL.

This work is supported by the projects MAENAD (EU FP7, Grant 260057), DFEA2020 (VIN-NOVA, Grant 2009-00629), and MBAT (ARTEMIS-JU, Grant 269335)

D. Chen · T. N. QureshiDepartment of Machine Design, KTH Royal Institute of Technology, Stockholm, SwedenTel.: +46-8-7906428E-mail: {chen, tahir}@md.kth.se

L. Feng · H. LönnVolvo Group Trucks Technology, Gothenburg, SwedenE-mail: {lei.feng, henrik.lonn}@volvo.com

F. HaglContinental Automotive GmbH, Babenhausen, GermanyE-mail: [email protected]

2 DeJiu Chen et al.

Keywords EAST-ADL · embedded system (ES) · model-based development(MBD) · architecture description language (ADL) · analytical modeling · modeltransformation · model checking · AUTOSAR · ISO26262

1 Introduction

EAST-ADL represents an important initiative of the European automotive indus-try to the model-based development approach to automotive software-intensiveembedded systems [1]. It consists of a modeling language, together with relatedmethodology and tool support, for addressing the particular challenges of correct-by-construction design in a multidisciplinary engineering context, where the con-solidation and traceability of decisions and related rationale play a key role for thesuccess. As a domain speci�c language, EAST-ADL is aligned with salient auto-motive standards, including ISO26262 [2] for functional safety and AUTOSAR [3]for software architecture. Currently, the meta-model of EAST-ADL is de�ned withUML, while the implementation is based on either UML pro�le or DSL (DomainSpeci�cation Language).

The core of EAST-ADL is a well-de�ned system ontology, which provides astandardized conceptualization of automotive embedded systems including thestructures of functions, the deployment of hardware resources, and the con�gura-tion of application and basic software components. Based on the ontology, EAST-ADL also provides necessary language support for managing requirements, perfor-mance and dependability related constraints, and expected veri�cation&validatione�orts.

This paper presents the recent advancement of EAST-ADL with respect toincremental property prediction through analysis and e�ective quality controlthrough veri�cation and validation. Key contributions of this paper fall into twocategories:

1. Architectural modeling for systematic development of embedded software sys-tems;

2. Integration of mature theoretical frameworks for architecture centric formalanalysis, veri�cation and validation.

The development is on the language support with unambiguous semantics for theannotations of behavioral concerns in requirements, design and test case speci�-cations. In particular, for the veri�cation&validation of software components andcode, the language allows the developer to precisely specify various behavioralconstraints derived from a higher level system design or the assumed run-timeenvironment. This constitutes a basis for a systematic approach to the designand evaluation of advanced features as all behavioral concerns can be formallydescribed and linked to the standardized system artifacts, including requirementsand other analytical support, in a common context of system development. Owingto the formal semantics, the developer can also explicitly reason about and de�nethe model transformations from EAST-ADL to other model formats of externalanalysis methods and tools.

This paper is organized as follows: Section 2 provides an overview of the EAST-ADL support for consolidating system-wide concerns; Section 3 then focuses on thelanguage support for annotating and managing behavior constraints as an integral

Title Suppressed Due to Excessive Length 3

part of architecture speci�cation; thereafter Section 4 presents a mapping schemefrom EAST-ADL to SPIN for the analysis leverage followed by an example casein Section 5; �nally, we conclude with a discussion of related work.

2 An overview of EAST-ADL and related concepts

To promote separation-of-concerns, which constitutes the key factor behind suc-cessful complexity-control and e�ective process, a system architecture descriptionin EAST-ADL is given with multiple views [1,4]. To this end, the language isstructured into multiple packages as shown in Fig. 1. The de�nition of systemstructure (e.g., components and their connectors), referred to as System Model,has multiple levels of abstraction according to the fundamental characteristics ofsystem lifecycle. Orthogonal to each of these levels, there are additional languagepackages providing necessary modeling support for the speci�cations of systemenvironment, related requirements, dependability and performance constraints, aswell as derived veri�cation and validation cases.

2.1 Multileveled System Speci�cation

The levels of system modeling are: Vehicle Level, Analysis Level, Design Level, andImplementation Level. The vehicle level system model, referred to as Vehicle Fea-ture Model, provides the topmost de�nition of an embedded system by capturingthe features that represent the externally visible functionalities. Such a high-leveldescription of system functionalities constitutes the basis for the con�guration ofproduct-line, the elicitation of end-to-end timing constraints, as well as the iden-ti�cation of safety goals. A vehicle level system model is re�ned by an analysislevel model, referred to as Functional Analysis Architecture. This system modelEAST-ADL_Extensions.png (PNG Image, 1089x671 pixels) - Scaled (86%) http://www.east-adl.info/images/EAST-ADL_Extensions.png

1 of 1 2012-04-18 12:39

Fig. 1 An overview of the language structure of EAST-ADL (Source: www.east-adl.info).

4 DeJiu Chen et al.

is used to specify the corresponding system input functions (the abstractions ofsensor related HW and SW), application functions (such as feedback control al-gorithms), and output functions (the abstractions of actuator related HW andSW) for the realization of each vehicle level feature. As a further step towardsimplementation, a Functional Analysis Architecture is re�ned by considering therun-time environment. The speci�cation is supported by the design level systemmodel, consisting of a Functional Design Architecture that de�nes the groupingand partitioning of the abstract system functions for software or hardware basedrealizations, and a Hardware Design Architecture that characterizes the targethardware platform, and an allocation description that captures the binding of theabstract system functions to the target hardware platform. The implementationlevel model is based on AUTOSAR [3], specifying the software components andtheir integration. With EAST-ADL, the mappings across a multileveled systemdescription are managed by Realization links.

Conceptually based on SysML [5], EAST-ADL allows each requirement to betraced to the related design solutions, veri�cation and validation cases, as well as toother interdependent requirements. For dependability modeling, the EAST-ADLsupport is also compliant with ISO26262 - an emerging standard on FunctionalSafety for Road Vehicles [2]. This means that all safety related concerns (e.g.,estimated hazards and faults/failures, safety requirements and safety measures)can be derived and managed seamlessly along with the lifecycle of nominal systemdevelopment [7].

In regard to system behaviors, EAST-ADL allows the speci�cation of executionconstraints on system functions through the declarations of triggering policies (e.g.,time- or event-triggered), timing and synchronization constraints (e.g., responsetime, frequency and precedence). If triggered, each function then runs accordingto a run-to-completion semantics [6]. This kind of behavior speci�cation focuses onthe temporal and interface-level characteristics of functions, and subsequently itssoftware components. The covered issues of concern include multitasking, softwarecon�guration and component integration.

To boost a systematic approach to advanced functionality, dependability andperformance, it is expected that EAST-ADL as an architecture description lan-guage would also form the basis for eliciting, analyzing, and consolidating variouskinds of behavioral concerns. Such behavioral concerns are for example relatedto requirements speci�cation and derivation, architectural compositions and re-�nements, or the design of veri�cation&validation cases. From a system designperspective, the issues within the scope include not only the executions of func-tions, but also precise de�nitions of system's operational situations, plant dynam-ics, contingent erroneous behaviors (e.g., the internal state transitions of softwarecomponents), as well as mode logic for quality-of-service, fault treatment, or opti-mized resource deployment.

2.2 Behavior Description Annex

In the previous versions of EAST-ADL (i.e., Version M.2.1.9 and earlier), theprovision of a seamlessly integrated language support to systematic and precisebehavior modeling was considered as a point of extension. Consequently, a widerange of behavior concerns can only be captured in plain texts or in external tools


(e.g., Simulink/Matlab for the expected vehicle plant dynamics and the designof related software control functions). Therefore the language support for model-ing, analysis, and consolidation of various behavioral concerns mentioned aboveremains open. For example, even if the control algorithms of system functions arede�ned in external tools like Matlab/Simulink, there is still a need of maintain-ing the traceability across the descriptions of requirements, multileveled designsolutions, emergent error behaviors and platform modes, analytical annotationsand test cases, and thereby enabling automatic control of the consistency andcompleteness across these descriptions. Owing to the inherent heterogeneity ofsuch descriptions, it is seldom the case that a single analysis tool would providesu�cient support to cover these engineering concerns.

To address the challenge, a new EAST-ADL package, referred to as Behav-ior Description Annex, has recently been developed mainly through MAENAD(an EU FP7 project, http://www.maenad.eu/). The work aims to allow moreprecise descriptions of a variety of behavioral concerns and to consolidate suchdescriptions in a common system development context. To promote the analyticalleverage of EAST-ADL, the Behavior Description Annex constitutes the gatewayenabling a �ne-grained model transformations from native EAST-ADL based sys-tem descriptions to some external state-of-the-art analytical models and tools.This would bring many bene�ts to the development of advanced embedded sys-tems. For example, both requirements engineering and safety engineering will beenhanced because requirements, use cases and operational situations can be re�nedwith precise behavior descriptions and still remain traceable to the correspondingtextual statements. This makes it possible to formally reason about the elicitation,decomposition, validation and satisfaction of requirements, and to automaticallygenerate and assess the test cases. See [8] for the motivations from a safety engi-neering's perspective and some initial concepts.

When capturing error speci�cations, such precise behavior descriptions canbe used to re�ne the de�nitions of estimated failure modes and their transitionsto/from nominal states for advanced safety analysis [9]. By managing all behavioraldescriptions consistently in a traceable system architectural context, the languagesupport provides a powerful modeling basis for the design of dynamic con�gurationand context-aware self-adaptation. The design of such advanced features requiresthe consolidation of many traditionally isolated system aspects, including the sys-tem operational situations, the system mode logic, the con�guration of applicationbehaviors, the execution control and resource deployment services, etc [10]. Whileproviding the fundamental support for assessing the correctness and completenessof requirements and design solutions across multiple levels of abstraction, the sup-port of precise behavior descriptions can also play an important role for componen-tization of software components. This includes the construction and formalizationof component contracts, ranging from their system-wide assumptions to their lo-cal properties, and a more precise reasoning about the compositional e�ects andrequired conformity of components (i.e., the compositionality and composability).We introduce the de�nitions of related EAST-ADL language concepts in Section 3.

6 DeJiu Chen et al.

3 EAST-ADL behavior constraint speci�cation

According to the fundamental needs of system development, a native EAST-ADLbehavior description is subdivided into three categories of behavior constraints,shown in Fig. 2. It is up to the users of EAST-ADL language, on the basis of theirparticular design and analysis contexts, to decide the exact types and degree ofconstraints to be applied.

class Behav iorConstraintsInternalStructure

EAElementAttributeQuantificationConstraint::AttributeQuantificationConstraint

EAElementComputationConstraint::ComputationConstraint

Context

«atpType»Behav iorConstraintType

EAElementTemporalConstraint::TemporalConstraint

+ assertion :String

0..1

+attributeQuantificationConstraint

*

0..1

+computationConstraint

*

0..1

+temporalConstraint

*

Fig. 2 The EAST-ADL meta-model de�nition in UML for the speci�cation of behavior con-straints.

De�nition 1 (Behavior constraint speci�cation)The EAST-ADL behavior constraint BEHCONS is an aggregation of three

constraint speci�cations: BEHCONS = AT T Q ∪ T EMP ∪ COMP, where

� AT T Q is a set of attribute quanti�cation constraints, which are representedby the AttributeQuanti�cationConstraint class in the EAST-ADL meta-model.See De�nition 5.

� T EMP is a set of temporal constraints, which are represented by the Tempo-ralConstraint class in the EAST-ADL meta-model. See De�nition 9.

� COMP is a set of computation constraints, which are represented by the Com-putationConstraint class in the EAST-ADL meta-model. See De�nition 13.

3.1 Behavior constraints and their contexts

For managing various behavioral descriptions in a common context of system de-velopment, EAST-ADL associates the behavior constraints to the requirements,design and analysis artifacts as shown in Fig. 3. Owing to such associations, abehavior constraint speci�cation can get many di�erent roles in the system devel-opment and thereby be composed with or related to other behavior constraints inmany di�erent ways.

If a behavior constraint is associated to a vehicle feature (VehicleFeatureMod-

eling::VehicleFeature), it annotates the behavioral characteristics that have to be


class Behav iorContraintsTargetAssocation2

EAElementBehav ior::Mode

+ condition :String

EAElementBehav ior::FunctionTrigger

+ triggerCondition :String+ triggerPolicy :TriggerPolicyKind

RequirementsRelationshipRequirements::Refine

ContextBehav ior::FunctionBehav ior

+ path :String+ representation :FunctionBehaviorKind

FeatureVehicleFeatureModeling::VehicleFeature

+ isCustomerVisible :Boolean+ isDesignVariabil i tyRationale :Boolean+ isRemoved :Boolean

ContextEAType

«atpType»FunctionModeling::FunctionType

+ isElementary :Boolean

TraceableSpecification

«atpPrototype»Behav iorConstraintPrototype

inherited l ink: Refine->EAElement

EAElementEAPrototype

«atpPrototype»FunctionModeling::FunctionPrototype

AllocationTargetEAPrototype

«atpPrototype»HardwareModeling::

HardwareComponentPrototype

EAElementEAPrototype

«atpPrototype»ErrorModel::ErrorModelPrototype

ContextBehav ior::Behav ior

Context

«atpStructureElement»FeatureModeling::FeatureModel

Context


EATypeTraceableSpecification

«atpType»ErrorModel::ErrorModelType

ContextDependability::Dependability

1+part

*

+constrainedErrorModel

*

+contextOfConstrainedErrorBehavior

*

+constrainedModeBehavior

*

+constrainedFunctionTriggering

*

+contextOfConstrainedFunctionBehavior

*

+targetedFunctionType

*

+contextOfTargetedVehicleFeature

*

+targetedVehicleFeature

*

+constrainedFunctionBehavior

*«instanceRef»

+targetedVehicleFeatureElement*

«instanceRef»

+functionTarget*

«instanceRef»

+hwTarget*

«instanceRef»

+errorModelTarget*

«isOfType»

+type

1

Fig. 3 The EAST-ADL meta-model in UML for associating behavior constraints and theirarchitectural contexts.

ful�lled by this top-level system functionality. This provides the basis for reason-ing about the de�nitions and con�gurations of product features. For example, anassignment of parent-child relation between two vehicle features (e.g., between ve-hicle braking control and anti-lock braking control) also implies the inheritance ofrelated behavior constraints.

Behavior constraints provide the support for specifying the contracts of systemfunctions, in particular the bounds of their acceptable behaviors. This is done byassigning the declarations of behavior constraints to function behaviors (Behav-ior ::FunctionBehavior) and function triggers (Behavior ::FunctionTrigger). Here,FunctionBehavior is a meta-class for declaring any external models capturing thedesign of a system function (by containing the path to a Simulink model), andFunctionTrigger is a meta-class for declaring the triggering policy for the execu-tion of a system function.

The EAST-ADL support for advanced mode management is �rst given throughthe meta-class Behavior::Mode, which is a construct for the purpose of systemcon�guration. The mode logic is de�ned precisely when behavior constraints areassociated to such mode declarations. By relating the descriptions of mode logicand other system behavior constraints, the conditions and e�ects of mode controlin regard to system environmental and internal conditions, including applicationbehaviors, resource deployment, as well as other possible quality-of-service adap-tations, can be formally speci�ed.

Through the EAST-ADL traceability support for requirements re�nement (re-quirement ::re�ne), behavior constraints re�ne the related textual statements of

8 DeJiu Chen et al.

requirements including assumed system operational situations. Such behavior con-straints formalize the related behavioral concerns (e.g., the boundary and temporalconditions, invariants of variables, states and state transitions) for a more rigorousrequirement elicitation, veri�cation and validation, and test case generation.

When targeting a declared error behavior (ErrorModel ::ErrorModelType), abehavior constraint re�nes the de�nitions of anomalies and error propagations.This would then allow a precise reasoning of faulty conditions in value and time,erroneous states and their transitions, and thereby facilitate the incorporationof formal techniques for the analysis of related emergent properties. A behaviorconstraint can be associated to nominal and error behaviors simultaneously. Thismodeling feature is useful for the speci�cation of fault-injection by allowing tran-sitions across nominal states and errors.

As shown in Fig. 3, a behavior constraint has both type and prototype(s) basedon a type-prototype pattern for composition speci�cation [4]. While a type de�ni-tion establishes a template for a range of behavioral constraints that share somecommon declarations and semantics, a prototype de�nition stipulates the instan-tiation of a behavior constraint type in a particular context given by another type.In other words, the prototypes constitute the compositional parts of the types.The parameters for the instantiations of behavior constraint types include At-

tribute (see Section 3.2 for its de�nition) and EventOccurrence(see Section 3.3 forits de�nition). During an instantiation, such parameters of behavior constraintprototypes (which are declared a priori through the type de�nition) are bound tosome parameters owned by the instantiation context. Through such binding dec-larations, the prototypes of behavior constraints are connected to exchange dataor events. If a behavior instantiation binding goes across two system functions orcomponents, there should be at least one corresponding structural communicationconnector through which such bindings can take place.

Fig. 4 shows the behavior constraint speci�cation of a naive power supplysystem. EEPowerSupply_Behavior, EEBattery_Behavior and EEBatteryMode-

Manager_Behavior are the behavior constraint types targeting three types ofsystem components. On top of the �gure, EE_Batt_ModeCtrl, Batt_Primary

and Batt_Secondary are three behavior constraint prototypes instantiated withinthe type EEPowerSupply_Behavior according to the corresponding behavior con-straint type de�nitions.

3.2 Logical time condition - LT C

For the descriptions of behavior constraints, an abstract notion of time, referredto as logical time condition, is introduced. Declarations of such time conditionscan be used to de�ne the time basis of continuous- and discrete-time dynamics orthe timing concerns in state-machine or data-processing related behaviors.

De�nition 2 (Logical time condition)The EAST-ADL logical time condition LT C is the union of an in�nite sequence

of time intervals

LT C =⋃{Ii = [ti, t

′i]|0 ≤ ti ≤ t′i and t′i ≤ ti+1, i ∈ N}


Fig. 4 The behavior constraint speci�cation of a power supply system

class LogicalTimeConditionMappingToTiming

EAElementTemporalConstraint::LogicalTimeCondition

+ isLogicalTimeSuspended :Boolean = false

EAElementTemporalConstraint::State

+ isErrorState :Boolean = false+ isHazard :Boolean = false+ isInitState :Boolean = false+ isMode :Boolean = false

EAElementTemporalConstraint::Transition

EAElementTemporalConstraint::TemporalConstraint

+ assertion :String

BehaviorInstantiationParameterEAElement

TemporalConstraint::TransitionEv ent

EAElementTiming::TimeDuration

+ cseCode :CseCodeType = Time+ cseCodeFactor :Integer = 1+ value :Float = 0.0

EAElementComputationConstraint::LogicalTransformation

+ expression :String+ isClientServ erInterface :Boolean = false

EAElementComputationConstraint::

TransformationOccurrence

EAElementAttributeQuantificationConstraint::

Quantification

+ expression :String

+timeCondition 0..1 +timeInvariant 0..1+timeCondition 0..1

+endPointReference 0..1

+timeGuard *+timeInvariant *

+consecutiveTimeCondition 0..1

+lower 0..1 +width 0..1+upper 0..1 +startPointReference 0..1

0..1

+timeCondition *

Fig. 5 The EAST-ADL meta-model for logical time condition and its roles.

10 DeJiu Chen et al.

An illustrative example of LT C is that each time interval Ii corresponds to thepossible time range of an event occurrence. If ∀i ∈ N(ti = t′i), then LT C reduces toan ascending sequence of discrete time instances. The declarations of logical timeconditions are supported by the meta-class (LogicalTimeCondition)and containedin the declarations of temporal constraints (TemporalConstraint), shown in Fig. 5.The semantics of logical time conditions can be further re�ned by associating suchconditions to the occurrences of execution events (EventOccurrence), such as dueto the change of an environmental condition or the triggering of a function. Thismakes it possible to precisely de�ne the reference points of a time interval (i.e.,startPointReference and endPointReference). Two consecutive time conditions onthe same time line can be declared using the consecutiveTimeCondition property.For example, two time intervals t_k and t_(k+1), shown in Fig. 6, are consec-utive if they represent the time durations [tk, tk+1] and [tk+1, tk+2] respectively.With EAST-ADL, the expression of the value of a logical time condition is based onthe meta-class Timing::TimeDuration in the format of CseCode as in AUTOSARand MSR/ASAM [4]. For descriptions where the notion of time proceeding is not ofinterest, a time condition with isLogicalTimeSuspended=true has to be explicitlydeclared and used.

Fig. 6 The EAST-ADL speci�cation of two consecutive time conditions.

3.3 Attribute quanti�cation constraints - AT T Q

Attribute quanti�cation constraints (AttributeQuanti�cationConstraint) are con-cerned with the value conditions of attributes underlying a behavior on a time-line. They are useful for declaring the variables (e.g., the input-, output- andinternal variables of a function), their expected values and logical relations. Anattribute quanti�cation constraint can be expressed by either simple equationslike F = m × a, V ≤ 90, or dynamics models. When necessary, the correspond-ing constraints on computational operations for data transformations and valueassignment can be declared through the computation constraints (Computation-Constraint). See Fig. 7 for an overview of the meta-model de�nition.

De�nition 3 (Attribute)The EAST-ADL attribute set contains parameters or arguments of the be-

havior constraint speci�cation AT T := {x1, · · · , xn}, where every element xi


class AttributeQuantificationConstraint

EAElementAttributeQuantificationConstraint


Attribute

+ isExternVisible :Boolean = false

EAElementQuantification


Context

«atpType»Behav iorDescription::

Behav iorConstraintType

TraceableSpecification

«atpType»Datatypes::EADatatype

LogicalEv ent


EAElementEAPort

«atpPrototype»FunctionModeling::FunctionPort

EAElementEAPort

«atpStructureElement»HardwareModeling::HardwarePin

+ direction :EADirectionKind [0..1]+ impedance :Float [0..1]+ isGround :Boolean [0..1]+ power :Float [0..1]+ voltage :Float [0..1]



Datatypes::EAValue

+quantification

*

+attribute

*

+visibleThroughHardwarePin*

+type

1

+visibleThroughFunctionPort*

+operand1..*{ordered}

+valueAssignment

*{ordered}

+timeCondition 0..1

0..1+attributeQuantificationConstraint

*

+visibleThroughHardwarePin*

+visibleThroughFunctionPort*

«isOfType»

+type 1


Fig. 7 The EAST-ADL meta-model de�nition in UML for attribute quanti�cation constraintand related properties.

(i = 1, · · · , n) is a name declared in the EAST-ADL model and n the total numberof attributes. Each element is called an attribute. Let

η : AT T → R

be an evaluation function of all attributes. The feasible range of attribute xi isdenoted as set Xi ⊆ R, i.e., ∀η(η(xi) ∈ Xi).

In this paper, we use the convention of always representing an attribute by alower-case letter and its scope by the corresponding capital letter. The descriptionsof attributes are supported by the Attribute class in the EAST-ADL meta-model.An attribute can be a constant or a variable de�ned by the EAST-ADL datatypes (EADataType) for the related meta-information like unit, valid range, re-quired accuracy, etc. If an attribute is externally visible (isExternVisible = true), itdenotes an input or output variable and has associated function ports or hardwarepins for the external accesses. Attributes are also used as instantiation parametersBehaviorInstantiationParameter, to which certain values can be assigned when abehavior constraint type is instantiated as behavior constraint instances in certainmodeling contexts.

De�nition 4 (Quanti�cation)The EAST-ADL quanti�cation QUANT is the set of statements over the at-

tributes about their value conditions or relationsQUANT =

(AT T ,LT C, EXP

), where


� AT T denotes the set of attributes. By De�nition 3, an attribute evaluation isequivalent to a vector in Rn and the set of all feasible attribute evaluations isAE :=

∏ni=1Xi.

� LT C denotes the logical time condition as de�ned in De�nition 2.� EXP denotes the set of valid expressions of the timed attribute-vectors. A timed

attribute-vector is a history of the attribute evaluations over time formalized asa function h : LT C → AE. Then the set of all feasible timed attribute-vectorsis AELT C. Any valid expression exp ∈ EXP converts a timed attribute-vectorto other, i.e., a function exp : AELT C → AELT C.

The descriptions of quanti�cations are supported by the Quanti�cation classin the EAST-ADL meta-model. In modeling practice, the expressions may be de-scribed by the operators and expression grammar of the C language. A quanti�ca-tion description can be decomposed into sub-quanti�cation for complexity control.An attribute quanti�cation constraint speci�cation can be used to annotate be-havior constraints in terms of continuous-time and discrete-time dynamics models.In the development of embedded systems, such acausal speci�cations of behaviorsare necessary for the de�nitions of system environments (e.g., the physical plants),electrical and electronics devices (e.g., the transfer functions of actuators).

As mentioned in De�nition 2, LT C describes either continuous-time or discrete-time dynamics. Because continuous-time dynamics models are based on the rateof change on the state variables, if a state attribute x ∈ AT T exists in the model,then its derivative must also be de�ned, i.e., x ∈ AT T . Discrete-time dynamicsmodels specify behaviors by de�ning the state at next time instant given thecurrent state and inputs. For any attribute x ∈ AT T , the expression necessarilyinvolves at least two di�erent timed evaluation sequences of x: x(ti) and x(ti+1) forany i ∈ N. Tab. 1 illustrates an example of continuous-time dynamics behavior. Inthe example, the attribute x ∈ R represents the system state, the attribute u ∈ Rthe input, and v ∈ R the state disturbance.

Table 1 EAST-ADL annotations for an example dynamics model.

Annotation De�nition

LT C LT C = {t|ti ≤ t ≤ t′i, t ∈ R, ti ∈ R, t′i ∈ R, i ∈ N}

AT T D AT T D = {x, u, v}, |AT T D| = 3

EXPD Let ULT C = {u(t)}, VLT C = {v(t)}, XLT C = {x(t)}, andDXLT C = {x(t)}, we have EXPD = {x(t) = f(x(t), u(t), v(t)),where f : R3 → R is a function},|EXPD| = 1

Fig. 8 shows part of the quanti�cation constraint of the power supply examplein Fig. 4 with discrete-time dynamics behavior. In the example, two battery func-tions are monitored and coordinated by the mode manager. The speci�cation ofdiscrete-time dynamics is based on the declarations of attributes and quanti�ca-tions with explicit time conditions in terms of tk and tk+1.

De�nition 5 (Attribute quanti�cation constraint speci�cation)


<<AttributeQuantificationConstraint>> BatteryParameterSpec

Fig. 8 The quanti�cation speci�cation of the power supply system.

The EAST-ADL attribute quanti�cation constraint speci�cation AT T Q is a

pair AT T Q =(AT T ,QUANT

), where

� AT T is the set of attributes for the behavior being speci�ed.� QUANT is the set of quanti�cation statements over the attributes.

Attribute quanti�cation constraint speci�cations are supported by the At-

tributeQuanti�cationConstraint class in the EAST-ADL meta-model.

3.4 Temporal constraints - T EMP

Temporal constraints (TemporalConstraint) constitute the language support forcapturing the dependency that a behavior has in regard to its own history andother behaviors on the timeline. They are useful for de�ning the discrete behaviorsin requirements or design solutions. All logical time conditions are also de�nedthrough temporal constraints. The language de�nition is aligned with automata.See Fig. 9 for an overview of the related meta-model de�nitions.

A system or component has a �nite set of discrete states, ST AT E = {s0, . . .,sk}, k ∈ N. Each state de�nes a situation where certain value- and time-conditionsmust hold.


A discrete‐time dynamics model specifies the behavior constraint by defining the state at next time instant given the current state and input based on a discrete state transition function.

LTC = |

1.1.3 Temporal constraints specification - TEMP

Temporal constraints provide support for capturing the dependency that a behavior has in regard to its own history and other behaviors on a timeline. They are useful for declaring discrete‐behaviors as well as the logical time conditions of concern. The language support is based on automaton and thereby comparable with approaches like Spin and UPPAAL in regard to analysis support. Compared to those analytical models, the EAST‐ADL support for discrete behaviors emphasizes the integrations of behavior specifications with the specifications of requirements, system design, and verification and validation. See Figure 6 for an overview of the related meta‐model definitions.

Figure 6. The EAST-ADL meta-model definition for TemporalConstraint and its properties

Definition 3 ‐ Temporal constraint specification. A temporal constraint is an automaton, given by the following tuple

TEMP = STATE, EVTOC , TRANS, LTC

class TemporalConstraint

EAElementState

+ isInitState :Boolean = false+ isMode :Boolean = false+ isErrorState :Boolean = false+ isHazard :Boolean = false

EAElementTransition

EAElementTemporalConstraint

+ assertion :String


Ev entOccurrence

EAElementLogicalTimeCondition

+ isLogicalTimeSuspended :boolean = false

EAElementTransformationOccurrance



Context


TraceableSpecificationDependability::Hazard

EAElementBehav ior::Mode

+ condition :String

+initState1

+quantificationInvariant

*

+subTemporalConstraint

*

+state

0..*

+hazardDelcaration

0..*

+readEventOccurrence?0..1

+writeEventOccurrence!0..1

+transition

*

+from 1

+quantificationGuard

*

+to 1

+effect

*

+modeDeclaration 0..1

+timeCondition

*

+temporalConstraint 0..*

+eventOccurrence

0..*

+endPointReference0..1

+startPointReference0..1

+timeInvariant*

+inQuantification

*{ordered}

+outQuantification

*{ordered}

+subQuantification *

+constrainedModeBehavior

0..*

+refinedBehaviorConstraint 0..*

+timeGuard

*

Fig. 9 The EAST-ADL meta-model de�nition of temporal constraint.

De�nition 6 (State invariant)The state invariants at every state is given by the function

SINV : ST AT E → SQI × ST I

where

� SINV denotes the state invariants,� SQI refers to the value invariants of states, i.e., the value conditions that must

hold in individual states, SQI ⊆ 2AE . Recall that AE is the set of attributeevaluations de�ned in De�nition 4.

� ST I refers to the time invariants of states, i.e., the time conditions that musthold in individual states, ST I ⊆ 2LT C,

The descriptions of discrete states are supported by the State class in theEAST-ADL meta-model with the state invariants given by the associations toLogicaTimeCondition and Quanti�cation. A state s is an initial state s0 whenisInitState=true. In the context of system design, a state s can represent one ormultiple operation modes when isMode=true; or one or multiple errors in thesystem when isErrorState=true, or hazards when isHazard=true.

De�nition 7 (Event occurrence)An event occurrence denotes the actual happening of certain logical, execution,

and erroneous conditions, i.e.,

EVT OC = EVT L ∪ EVT E ∪ EVT F

where


� EVT L denotes the logical events triggered by the change of predicates expressedby the attributes and time.

� EVT E denotes the execution events with EVT E = EVT E_F ∪ EVT E_P , i.e.,the execution events are given by the function events EVT E_F or port eventsEVT E_P . Each execution event speci�es a distinct form of state change in arunning system, taking place at distinct points in time. A function event refersto the triggering of a function block, and a port event refers to the data sendingor receiving at a port of function block.

� EVT F denotes the erroneous events with

EVT F = EVT F_F ∪ EVT F_H ∪ EVT F_A

i.e., an erroneous event belongs to exactly one of three disjoint event sets,namely feature �aw events EVT F_F , system hazards EVT F_H, and systemanomalies (faults and failures) EVT F_A.

The meta-model of discrete event occurrences EVT OC is described by theEventOccurrence class in EAST-ADL, illustrated in Fig. 10. The occurrence ofa logical event LogicalEvent denotes a value condition (e.g., when the measuredvalue of vehicle speed is below 30 km/h) that takes place at a particular timeinstance and becomes valid in a certain time interval according to the de�nition ofthe corresponding quanti�cation. Logical events of input or output variables (de-�ned through Attribute) can be communicated through the corresponding ports.An association from EventOccurrence to LogicalEvent de�nes the occurrences oflogical events. Each occurrence of an execution event (supported by the meta-class Timing::Event) denotes a distinct form of state change in system execution,at distinct points in time, such as at the triggering of a function, or at the re-ceiving/sending of data from/to ports. An association from EventOccurrence toTiming::Event de�nes the occurrences of execution events. The de�nition of execu-tion event itself only provides a description about its purpose instead of occurrence.The occurrence of a fault, a failure, or a hazard denotes a distinct form of deviationfrom nominal behaviors in certain time condition. The set of erroneous events is adisjoint union of feature �aws (Dependability::FeatureFlaw), system hazards (De-pendability::HazardeousEvent), and system faults/failures (ErrorModel::Anomaly)as such concepts only di�er in scope or in abstraction level [7].

De�nition 8 (Discrete transition)Discrete transitions describe the possible switches between discrete states be-

cause of the occurrences of discrete events or the violations of a state invariant intime or in value quanti�cation

T RANS ⊆ ST AT E ×RWEVT OC ×QG × T G × EFF × ST AT E

where

� ST AT E denotes the from and to discrete states,� QG denotes the possible value guards, QG ⊆ 2AE

� T G denotes the possible time guards,T G ⊆ 2LT C

� RWEVT OC denotes the event occurrences to read or write ports, RWEVT OC⊆ EVT E .


Dependability::HazardEvent – all these are existing EAST‐ADL construct from the dependability package) denotes a distinct form of deviation from nominal behaviors at distinct points in time. The definitions of those faults and failures provide the descriptions expressing their estimated existences.

Figure 7. The EAST-ADL meta-model definition for EventOccurrence and its properties

A transition between two states may occur due to the occurrence of a discrete event, or due to the violation of a state invariant.

Definition 3.3 – Discrete Transition. A discrete transition describes the switch between two discrete states due to the occurrence of a discrete event or due to the violation of a state invariant.

TRANS STATE EVOCC STATE

Transition – the modeling construct for the declarations of transitions between two states. When the related guard conditions both in time and value domains are met, a transition can be fired to respond to the occurrence of an event (readEventOccurrences?) or to signal the occurrence of an event (writeEventOccurrance!). A transition, when fired, can also invoke one or more logical transformations (TransformationOccurrance).

Logical Time Condition: The logical time condition is an abstraction of real time for the declarations of time conditions in behavioral constraints. As shown in Figure 8, such time conditions can be assigned to attribute quantifications, states, transitions, logical transformations or the occurrences of such transformations, in order to characterize the concerns in regard to timing, causality, and synchronization.

class Ev entOccurrence


Ev entOccurrence

TimingDescriptionTiming::Event

+ isStateChange :Boolean = true

LogicalEvent

+ isExternVisible :boolean = false

EAElementTransition

EAElementTemporalConstraint

+ assertion :String



Ev ents::Ev entFunctionClientServ erPort

+ eventKind :EventFunctionClientServerPortKind

Ev ents::Ev entFunction Ev ents::Ev entFunctionFlowPort

EAElement

«atpPrototype»ErrorModel::Anomaly

+ genericDescription :String

TraceableSpecificationDependability::HazardousEv ent

+ classificationAssumptions :String [0..1]+ controllabil ity :Controllabili tyClassKind+ exposure :ExposureClassKind+ hazardClassification :ASILKind+ severity :SeverityClassKind

TraceableSpecificationDependability::FeatureFlaw

+transition

*

+writeEventOccurrence!

0..1

+readEventOccurrence?

0..1

+eventOccurrence

0..*

+occurredFeatureFlaw

*

+occurredHazardousEvent

0..*

*

+occurredLogicalEvent 0..*

*

+occurredExecutionEvent 0..*+occurredAnomaly

*

Fig. 10 The EAST-ADL meta-model for EventOccurrence and its properties.

� EFF denotes the e�ects of the occurrence of the logical transformations asso-ciated to the transition, EFF ⊆ 2LFNOC. (see De�nition 11 for the de�nitionof LFNOC.)

The descriptions of transitions are supported by the meta-class Transition inEAST-ADL. The from and to roles can be applied to two distinct states or asingle state. When all the given guard conditions are met, a transition may �reto respond to the occurrence of an event (which is indicated by the role readE-

ventOccurrences?) or to signal the occurrence of an event (which is indicated bythe role writeEventOccurrence!). A transition, after execution, leads to the en-trance to the associated to state, and invokes one or more logical transformations(TransformationOccurrence!) as the e�ects of the transition.

De�nition 9 (Temporal constraint speci�cation)The EAST-ADL temporal constraint T EMP is a tuple

T EMP =(ST AT E , EVT OC, T RANS, s0,LT C

)where

� ST AT E denotes the set of states of a discrete behavior to be satis�ed bya system or its environment, ST AT E = {s0, . . . , sk}, k ∈ N. Each state isassociated to an invariant function as de�ned by De�nition 6.

� EVT OC denotes the set of discrete events whose occurrences are taken intoconsideration, as in De�nition 7.

� T RANS denotes the set of discrete transitions of the discrete behavior, as inDe�nition 8.

� s0 ∈ ST AT E is the initial state.� LT C denotes a set of time intervals that constitute the logical time basis.


The descriptions of temporal constraint are supported by the TemporalCon-

straint class in the EAST-ADL language. Fig. 11 further develops the power supplyexample and shows the speci�cation of two state machines. BattModeCtrlSM-Spec speci�es the control logic of switching on/o� the primary and secondarybatteries according to their states of charge. BatterySMSpec captures the bat-tery dynamics of the state of charge. The state invariants and transition guardsare precisely de�ned by the attribute quanti�cation speci�cations, part of whichare illustrated in Fig. 8.

The TemporalConstraint class contains assertions in temporal or predicate logicwhen desired. The EVT OC declares the events that are taken into considerationin a behavior constraint description. Such events can be declared in other EAST-ADL modeling packages for di�erent analytical purposes. For example, an eventoccurring on a transition can be either a function event declared in the EAST-ADL timing package for the annotation of triggering periodicity constraint, or afailure event declared in the EAST-ADL dependability package for the annotationof safety constraint. In e�ect, the de�nition of EVT OC allows those analyticalevents to be instantiated and related in a behavior description.

3.5 Computation constraints - COMP

Computation constraints in EAST-ADL (ComputationConstraint), as in Fig. 12,provide the language support for specifying the restrictions on data processing,especially when the details of design are not available (e.g., for the reasons ofsoftware component IP-protection). The descriptions can be related to both theexpected logical transformations of data and the expected cause-e�ect paths ofevents.

De�nition 10 (Logical transformation)The EAST-ADL logical transformation LFN is a set of conditional executions

of function components to compute the output attributes.

LFN ⊆ PRE × EXP × PST × T INV

where

� PRE and PST are the sets of pre- and postconditions, respectively, over at-tributes and logical time, namely PRE ,PST ⊆ 2AE×LT C;

� EXP is the set of valid expressions of the timed attribute-vectors, as de�nedin De�nition 4;

� T INV is the set of time invariants, namely T INV ⊆ 2LT C, to specify thetime constraints of the function execution, such as the worst-case executiontime and deadline.

Given some in- and local-data that meet certain preconditions, a logical trans-formation always maps these data to some out-data that meet the related postcon-ditions if the time- and value-invariants are not violated during the data process-ing. In system development, the speci�cation of a logical transformation capturesa particular contract that must be satis�ed by the implementation of a system


Fig. 11 The temporal constraints of the battery controller and battery functions.

function by software and hardware. The speci�cation can be used for many pur-poses, such as for component design and integration, test case generation, run-timemonitoring and quality-of-service adaptation, diagnostics, etc.

The EAST-ADL meta-class for the declarations of logical transformations isLogicalTransformation. If a logical transformation is applied to a client-server in-terface (isClientServerInterface=true), it has at least one corresponding operationspeci�ed in a client-server interface de�nition (FunctionModelling::Operation). Alogical transformation can be invoked in logical paths or in state transitions. Theexpressions for any further lower level details of a transformation is currently tex-tual, which can be based on the C Language, AUTOSAR formula language [3], orUML activity description.


class ComputationConstraint

EAElementComputationConstraint

Context

«atpType»Behav iorDescription::

Behav iorConstraintType

EAElementLogicalTransformation

+ expression :String+ isClientServerInterface :Boolean = false

EAElementTransformationOccurrence

EAElementLogicalPath

AttributeQuantificationConstraint::LogicalEv ent




EAElementFunctionModeling::Operation

EAElementAttributeQuantificationConstraint::

Quantification


TimingDescriptionTiming::Ev entChain


AttributeQuantificationConstraint::Attribute


EAElementTemporalConstraint::

Transition


+strand*

+precedingExecutionEventChain

*

+succeedingExecutionEventChain

*+correspondingExecutionEventChain

*+logicalStimulus

*+logicalResponse

*

+segment *{ordered}

+strand*

+effect 0..1

+segment *{ordered}

+postCondition *

+logicalPath

*

0..1+computationConstraint*

+contained*{ordered}

+out*{ordered}

+in*{ordered}

+transformationOccurrence 0..1

+preCondition*

+logicalTransformation

*

+timeInvariant 0..1

+clientServerInterfaceOperation *

+inQuantification

*{ordered}

+outQuantification

*{ordered}

+invokedLogicalTransformation 1

+timeCondition0..1 +quantificationInvariant

*

Fig. 12 The EAST-ADL meta-model for computation constraint and its properties.

De�nition 11 (Occurrence of Logical Transformation)Given a logical transformation lfn = (pre, exp, pst, tinv) ∈ LFN , its occur-

rence is characterized by a tuple oc_lfn := (execution, time), where

� execution is a function

execution : AE → {0, 1} ×AE : a 7→

(0, a), a /∈ pre(0, exp(a)), a ∈ pre ∧ exp(a) /∈ pst(1, exp(a)), a ∈ pre ∧ exp(a) ∈ pst

� time ∈ LT C denotes the actual time duration for the occurrence of the logicaltransformation.

Let LFNOC ⊆ {oc_lfn|lfn ∈ LFN}×LT C be the set of all possible occurrencesof all logical transformations.

The EAST-ADL meta-class for the occurrences of logical transformations isthe LogicalTransformation. Activated by state transitions or logical paths, eachoccurrence of logical transformation can have particular values of in-data (in-Quanti�cation) and out-data (outQuanti�cation) determined by the invocationcontext.

De�nition 12 (Logical path)A logical path lph ∈ LPH in EAST-ADL is de�ned recursively as follows.


� p0 := (es, lfn_oc, er) is a logical path if es, er ∈ EVT L and lfn_oc is atransformation occurrence as de�ned in De�nition 11. The semantics is thatthe occurrence of the logical event es (stimulus) results in the occurrence ofthe logical event er (response) through the occurrence lfn_oc of a logicaltransformation. Denote s(p0) := es and r(p0) := er to retrieve the stimulusand response events of the event path p0.

� Let p1, p2 be two logical paths.

1. If r(p1) = s(p2) (or r(p2) = s(p1)), then the serial concatenation of the twopaths by adjoining r(p1) and s(p2) (or r(p2) and s(p1)) is a logical pathp3 := p1p2 (or p2p1). Moreover s(p3) = s(p1) (or s(p2)) and r(p3) = r(p2)(or r(p1)).

2. If s(p1) = s(p2) and r(p1) = r(p2), then the parallel combination of ad-joining s(p1) and s(p2) and adjoining r(p1) and r(p2) is a logical pathp3 := p1‖p2. Moreover s(p3) = s(p1) and r(p3) = r(p1).

The EAST-ADL logical path, based on the meta-class LogicalPath, providesthe modeling support for annotating the expected cause-e�ect traces across a sys-tem or a component. Logical paths can be combined in parallel (strand) or insequence (segment). By connecting logical events and execution events, it extendsthe descriptions of execution control, which are based on the event chains (Tim-ing::EventChain) capturing the causality of triggering, port reading and writingevents.

De�nition 13 (Computation constraint speci�cation)The EAST-ADL computation constraint COMP is a pair COMP =(LFN ,

LPH), with

� LFN denotes the restrictions on the logical transformations of data, speci�edby De�nition 10.

� LPH denotes the restrictions on the cause-e�ect paths of events, speci�ed byDe�nitions 12.

The EAST-ADL meta-class for computation constraints is ComputationCon-straint, as illustrated in Fig. 12. Fig. 13 shows the computation constraints of theEEBatteryFunction type in the power supply example developed before. Thespeci�cation de�nes two ordered logical paths and two transformations that mustbe invoked according to the precedence given by the path de�nition.

3.6 Execution Semantics

In modeling practice with EAST-ADL, a behavior constraint (BEHCONS) is al-ways instantiated with prototypes. The execution of each atomic prototype hasits own thread of control without any internal concurrency, also following the run-to-completion semantics [6]: when triggered, it reads all input ports, executes thecomputation, and then writes the output ports. If new data arrives at the inputports during the execution or writing phase, it cannot be processed in the currentexecuting cycle. Moreover, each incoming port represent a message bu�er withspeci�c semantics.


Fig. 13 The EAST-ADL computation constraints of the battery function.

De�nition 14 (Semantics of the Message Bu�er)The message bu�er in EAST-ADL has length one, does not block the sender

when it is full or the receiver when it is empty, allows the stored message to bereplaced by new messages, and always retains the message when it is read.

Accordingly the message bu�er is functionally equivalent to the protectedglobal variable in EAST-ADL.

4 SPIN Transformation

Focusing on the support for standardized speci�cation of embedded systems forcommunication and information management, EAST-ADL aims to obtain mostof its analytical leverage through well established analysis methods and tools. Forthe analysis based on the behavior constraint speci�cation, one e�ective tool is theSPIN model checker [11,12].

SPIN is a powerful open-source software tool for detecting software defects indistributed and concurrent system designs [11]. It is a logic model checker thate�ciently characterizes all possible executions generated by the design model,rather than a small subset reachable by the traditional methods based on humaninspection, testing, or random simulation. SPIN can therefore exhaustively ver-ify the design model against logical requirements, including assertion, freedom ofdeadlock, reachability of the desired state, avoidance of or compliance with givenexecution patterns, and other complex user-de�ned correctness criteria. The SPINmodel is speci�ed by PROMELA (Process Meta-Language), which emphasizes themodeling of process synchronization and coordination as opposed to computation.


The basic building blocks of SPIN models are asynchronous processes, bu�ered andrendezvous message channels, synchronizing statements, and structured data [11].Inside SPIN, the asynchronous processes and their interactions are representedas �nite state automata. SPIN o�ers several ways for specifying the correctnessrequirements, including basic assertions, invalid end-states, linear temporal logic

(LTL) constraints, etc.As the EAST-ADL behavior constraint description has wider scope than the

native SPIN semantics, some modeling delimitations are necessary for the trans-formation. For example, SPIN does not naturally support the counting of time,nor does it complex calculation or �oating data type. In our investigation, thefollowing restrictions on the behavior constraint speci�cation have to be assumed.

� The speci�cations of logical time conditions (LT C) depending on precise timevalues should be avoided or replaced with qualitative speci�cations in temporallogic.

� The speci�cations of attributes and quanti�cations (AT T andQUANT ) basedon �oating-point data type and expressions like sin(x) or

√x should be avoided

for the time being, as the direct support of SPIN covers only basic arithmeticcalculations.

By De�nition 1 a behavior constraint prototype consists of a set of attributes,a set of computation constraints, and a temporal constraint formalized as an au-tomaton. Tab. 2 summarizes the mapping rules from an EAST-ADL behavior con-straint prototype to a SPIN model. In essence, attributes in the behavior model aremapped to data objects in the SPIN model, computations mapped to PROMELAexpressions and assignments, the temporal constraint mapped to a process type inSPIN, and the read/write event occurrence mapped to message receiving/sendingstatement in SPIN.

To enable computer-aided modeling and formal analysis, the expression inEAST-ADL models follows the syntax and semantics of a subset of the C pro-gramming language, namely the MISRA-C [13]. The syntactic resemblance be-tween C and PROMELA allows most C expressions used by EAST-ADL to bedirectly reused in the SPIN model. Some exceptions and the corresponding map-ping rules are listed in Tab. 3. The second row of the table is not a completelist of advanced C assignment operators. Others like *=, /= can be converted toPROMELA statements in the same way.

Note two subtle di�erences between EAST-ADL semantics and Promela se-mantics. First, EAST-ADL is deterministic. At a state where multiple exit transi-tions are de�ned, EAST-ADL must deterministically choose one when more thanone transitions are executable, whereas PROMELA nondeterministically chooses avalid branch. Second, EAST-ADL is nonblocking. By the run-to-completion seman-tics, if no transition is executable at a state, the EAST-ADL behavior model willterminate the current running instance, whereas the SPIN model will be blocked.To reconcile the con�ict, we enforce that (1) the guards of all outgoing transitionsof a state must be mutually exclusive and (2) in case of no guard is valid, thedefault transition to the �nal state is executable.

We formalize a behavior constraint prototype as a 7-tuple, BEHCONS =(ST AT E , s0, sf , T RANS,AT T , AT T 0,RWEVT OC), where� ST AT E is the �nite set of discrete states as de�ned by De�nition 6, ands0, sf ∈ ST AT E are the initial and the �nal states, respectively. Each state


Table 2 The mapping between the related concepts in EAST-ADL and PROMELA.

EAST‐ADL Concept

EAST‐ADL Meta‐Class

PROMELA Comment

BEHCONS BehaviorConstraint Proctype, which is the key word to declare a process definition

The abstract definition of a process describes the execution of an atomic SW component

ATTQ AttributeQuantificationConstraint

PROMELA expression The expression must comply with PROMELA language grammar

ATT Attribute PROMELA data, e.g., Boolean, byte, integer, communication channel

Floating point datatype is not naturally supported by SPIN. The communication channel is employed for asynchronous communication between processes

TEMP TemporalConstraint PROMELA statements within the process

Temoral constraints such as sequence, precedence, synchronization, and consequence are specified within the process definition

COMP ComputationConstraint

PROMELA expression Promela supports only basic arithmetic calculations

QUANT Quantification PROMELA expression

LTC Positive integer As a logic model checker, SPIN does not directly support time, but the clock ticks can be counted by an integer

RWEVTOC EventOccurrence Read or write the message channel

The operation is nonblocking

STATE State The separator “;” or “‐ ” between two statements

TRANS Transition The statement In PROMELA, each statement corresponds to one transition

4.2.2.3. Algorithm:

Input: A system behavior constraint Output: A SPIN model

Table 3 The mapping between C and PROMELA

C PROMELA++var var++- -var var- -

var += expr var = var + exprvar -= expr var = var - expr

expr1 ? expr2 : expr3 (expr1 -> expr2 : expr3)

if(cond1) ifstatement1; :: cond1 -> statement1

else if(cond2) :: cond2 -> statement2statement2; :: else -> statement3

else fistatement3;

while(cond) do{ :: cond ->

statement; statement} :: else -> break

od


s ∈ ST AT E has an invariant condition de�ned by the function SINV(s) =(QI, TI), where QI ⊆ QUANT , T I ⊆ LT C. As usual, the two sets can beimplicitly represented by two predicates PQI ,PTI . The invariant at state s ishence PQI ∧ PTI . If SINV(s) = true, then the invariant condition at thisstate is omitted from the model.

� T RANS is the �nite set of discrete transitions as de�ned by De�nition 8. Forconvenience we de�ne the functions guard : T RANS → QG × T G, effect :T RANS → EFF , to : T RANS → ST AT E to retrieve respectively the guardcondition, the e�ect function, and the target state of the transition. Similarto the state invariant condition, a guard condition is also represented as theconjunction of a state invariant and a time invariant.

� AT T as de�ned by De�nition 3 is the set of data objects used in the behaviorconstraint prototype and AT T 0 ⊆ AT T the subset of the externally visibleattributes so as to initialize the prototype.

� RWEVT OC is the set of event occurrences reading or writing the messagebu�ers. Because EAST-ADL prescribes precise semantics of the message bu�er,as in De�nition 14, and the semantics is di�erent from the message channelin SPIN, we have written dedicated PROMELA scripts to realize the seman-tics [15].

For automatic PROMELA conversion, we order the states in ST AT E so thatthe initial state s0 has the smallest index and the �nal state sf the largest. De�nethe index function:

index : ST AT E → {0, 1, · · · , n},

where n = |ST AT E| − 1, index(s0) = 0, and index(sf ) = n. Here |S| denotes thecardinality of the set S. We also de�ne the function

exit : ST AT E → 2T RANS : s 7→ {(s, e, s′) ∈ T RANS}

to determine all exit transitions at state s.The execution trigger of a behavior constraint prototype is modeled as a syn-

chronization channel trigger 6∈ AT T ∪ RWEVT OC between the process and adispatcher process. To dispatch a process, the dispatcher simply sends a triggeringsignal to the channel trigger.

Finally we sketch the algorithm to convert the behavior constraint prototypeBEHCONS to a SPIN process process_P. In Algorithm 1, the notation � [x]�means that the whole string should be replaced by the actual value of x in thetext context, where x is an expression that may return an integer, a text string,or a set of data objects. For instance, if x = 1, then � N_[x]� represents �N_1�. Thenotation �\n� switches the text to a new line.

5 Case study

The case study presented is a cooperative driving scenario where the velocities oftwo vehicles driving in the same lane are synchronized so that a constant timegap between these vehicles are maintained automatically. In the scenario, eachvehicle periodically broadcasts its own position and velocity and listens to theother. It then compares its own information with the other's and locally decidesits own role in the cooperation, i.e., either as the leader or as the follower when


Algorithm 1: Model Transformation

Input: A behavior constraint prototypeBEHCONS = (ST AT E, s0, sf , T RANS,AT T , AT T 0,RWEVT OC)

Output: A SPIN process process_P1 Let n := ||ST AT E|| − 1;2 Write the process declaration:�proctype process_P(chan [RWEVT OC]; [AT T 0])\n {\n�;

3 Declare local data objects: �[AT T −AT T 0];\n�;4 Specify the trigger: �end: do\n :: triggerP ? 1->\n�;5 for k=1 to n do /* Do nothing for s0 */6 Let a ∈ ST AT E with index(a) = k;7 if ‖exit(a)‖ > 1 or guard(tran) 6= �� then /* a has multiple exit transitions

or the guard of the transition is not empty */8 Start the selection: �S_[k]: if\n�;9 foreach tran ∈ exit(a) do

10 Write the line: �:: [guard(tran)] ->\n�;11 Write the line: �[effect(tran)];\n goto S_[to(tran)]\n�;12 end13 Write the line: �::else -> goto S_[n]�;14 Terminate the selection: �fi;\n�;15 else if a == sf then /* a is the final state */16 Do nothing: �S_[n]: skip;\n�;17 Complete and rewind the process: �od\n�;18 else /* a has one exit transition whose guard is always true */19 Commit the action: �S_[k] : [effect(tran)] ;\n�;20 Let x = to(tran);21 if index(x) 6= k + 1 then22 Write the line: �goto S_[index(x)];\n�;23 end24 end25 end26 Terminate the process declaration: �}\n�;

certain conditions are met. When a leader-follower relationship is established, thefollower must set its desired velocity identical to that of the leader. For eachvehicle, the cooperative driving feature is supported by a control function on topof the ordinary adaptive cruise control (ACC). To avoid unnecessary complexityfor tractable model checking computation, we assume that the positions of thevehicles are within the range of [0, 16] and the velocities are within [0, 5]. Eachnumber is a symbolic representation of a range of actual values.

We complete the EAST-ADL model with the software MetaEdit+ and im-plement the EAST-ADL to SPIN conversion algorithm with the script languageprovided by the software. The top level behavior constraint model of the cooper-ative system is given in Fig. 14, showing the communication of components. Themodel contains the behavior constraint prototypes of two vehicles, left and right,and the environment, bottom. Each vehicle behavior constraint prototype ful�llsthe active cooperation function and decides the control action on engine torque.The environment model contains the elementary kinematics model of the vehiclecapturing the causal relationship between the requested engine torque and thevehicular velocity. The environment model also maintains the absolute position ofthe two vehicles. The two vehicle prototypes receive the velocity and the position


from the environment model. It then broadcasts the information and the vehicleID to the adjacent vehicle.

<<AnalysisFunctionPrototype>>

ajID

ajPos

ajVel

PosGPSVehicleSpeed

ID

Pos

Vel

RefSpeed


ajID

ajPos

ajVel

PosGPS

VehicleSpeed

IDPos

Vel

RefSpeed


V1pos

RefSpeedV1

id1

V1pos

V1vel

id2V2posV2vel

vehicleSystem1 vehicleSystem2

V2pos

V1vel V2vel

functionalAnalysisArchitecture

RefSpeedV2

<<Environment>>

vehicleOperationEnvironment

CooperativeDrivingSystem

InstantiatedParameters:1. Vehicle1 (id1, RefSpeedV1, V2pos, V1pos, V2vel, V1vel)2. Vehicle2 (id2, RefSpeedV2, V1pos, V2pos, V1vel, V2vel)

3. Environment (RefSpeedV1, RefSpeedV2, V1vel, V2vel, V1pos, V2pos)


IO O

I

I

I

I

I I

I

I

I

O

O

O

O I

O

O

O

O

<<SystemModel>>

O OI

environmentModel

Fig. 14 EAST-ADL Behavior Constraint Model of the Cooperative System

Fig. 15 illustrates the state machine model of the vehicle cooperation behaviorprototype vehicleSystem1. The expressions are speci�ed in C language. At stateVehFunCompSegment, for example, if the vehicle successfully receives signals fromthe adjacent vehicle, it decides its role locally. The vehicle is the leader if it is aheadof the other and the distance is small, i.e., 0 < pos−ajPos < EffectiveDist. If it isthe leader (at state TakeLeaderRole) or the cooperation function is inactive (stateTakeNoRole), the normal cruise control function autonomously adjusts its velocity.Owing to the space limit, we skip the details of other prototypes in Fig. 14.

Requirements on the system design are expressed as both assertions and LTLstatements, and can be veri�ed by SPIN. Algorithm 1 transforms all prototypes toSPIN proctype declarations. The transformation procedure also creates the SPINinit process that initializes the active objects of all proctype and issues triggersto them. A list of requirements and the veri�cation results with SPIN version 6.2.2are given below. All computations use the partial order reduction algorithm.

1. Free of deadlock. The requirement is satis�ed. SPIN veri�cation visits 15, 564,894 states, consumes 497.84 MB memory, and takes 17 seconds on a PC withan Intel Core i7 2.4 GHz processor and 8 GB RAM.

2. There can be at most 1 leader at any time, i.e., �[(asLeader[0] & asLeader[1])== 0]. The property is veri�ed through the assertion highlighted in Fig. 15. Itis valid only if the two actions at the exit transition of state TakeLeaderRole

are atomic. The veri�cation is performed together with the veri�cation of re-quirement 1.


readSens(pos, vel) get_adjVeh(ajID, ajPos, ajVel) ajPos – pos >0 &&

ajPos – pos <=EffectiveDist

asLeader[id] = 0

refVel = ajVel

assert((asLeader[0] & asLeader[1])==0)

refVel will be decided by the driver

else

asLeader[id] = 0

cmdACC(refVel) send_adjVeh(ID, pos, vel)

ReadFromChannelsAndSensors

VehFunCompSegment TakeFollowerRole

TakeLeaderRole

TakeNoRole

PerformFollowACC

PerformNormalACC

ActAndComm

asLeader[1 – id ] = 0 asLeader[id] = 1

pos – ajPos >0 && pos – ajPos <=EffectiveDist

Check

Fig. 15 Prototype of Component vehicleSystem1

3. When a leader is elected and maintained, the two vehicles will eventually havethe identical velocity. Let predicate p be asLeader[0]|asLeader[1] and q bevel1 == vel2. Then the LTL statement of the property is �(p→ ♦(!p‖q)). Thereason to include !p within the ♦ term is that the leader-follower relationshipmay break before the two vehicles converge to the identical velocity. SPIN �ndsno error after 30 seconds computation and consumes 1.5 GB memory.

4. The vehicle velocity is always in range [0, 5], i.e., �(vel1 >= 0 && vel1 <= 5).The requirement is speci�ed as another assertion in the model and veri�edpositively together with requirements 1 and 2.

6 Related work

The EAST-ADL support for explicit behavior description is fundamentally a hy-brid system model as de�ned in [14]. Unlike other approaches to hybrid systemmodeling, our work emphasizes the provision of a practical modeling language forprecisely annotating various behavioral concerns in system development as well asfor managing the descriptions of such concerns together with the speci�cations ofrequirements, system design and constraints, and veri�cation and validation caseson a common information basis. [8] presents an important application scenario ofthe EAST-ADL behavior modeling support. The paper elaborates the industrialneeds on model-based safety analysis and introduces some early concepts of the


language support, which helps two major problems in industrial practices: (1) howto facilitate the collaborations of safety engineers and other system developers,and (2) how to promote the usage of formal methods for eliciting and specifyingsafety requirements.

As an early exploration of the appropriate language annotation, paper [15] sug-gests a restriction of the UML activity diagram to capture the execution logic offunction components. Instead of this, the Behavior Description Annex elaboratedin this paper is based on hybrid automata extended with explicit quanti�cationand computation speci�cation. The language design used in the two papers is dif-ferent, but the behavioral semantics for the logical and sequential relationship isidentical. Correspondingly the algorithm for translating an EAST-ADL behaviormodel to a SPIN model is reformulated to the new annotations. Paper [16] in-vestigates the realization mapping from the EAST-ADL design model to softwareimplementation conforming to AUTOSAR. The contribution is not on new def-initions of behavior constraints or new types of analysis support. The behaviorspeci�cations used in this paper are about the EAST-ADL annotations of modesand execution constraints on the implementation of functional components (e.g.,triggering). Such EAST-ADL annotations focus on system con�guration and arehence not part of the Behavior Description Annex.

The work presented in [17] investigates possible mapping schemes from thetemporal constraint annotations of EAST-ADL Behavior Description Annex totimed automata used in UPPAAL and introduces a transformation algorithm.The principles of the mapping and the algorithm are very similar to those in theSPIN transformation, but the algorithm enables new analysis support on timingconstraints, which can be more e�ectively veri�ed by UPPAAL than SPIN orNuSMV. Moreover, the technical support for model transformation from EAST-ADL to other analysis techniques has been studied in [18,19]. In summary, eachof the previous publications contributes to a strict subset of the de�nitions andanalysis supports of the Behavior Description Annex.

As an ADL facilitating the development and information management of au-tomotive embedded systems across the boundaries of enterprises and engineeringdomains, EAST-ADL aims to bene�t from existing technologies for systems mod-eling and analysis and also to in�uence emerging approaches. The language can beused to relate or merge many related approaches and technologies in the context ofautomotive embedded system lifecycle. For example, the component model devel-oped in SPEEDS [20], referred to as HRC (Heterogeneous Rich Components), al-lows the de�nition of component behavior and contract based on hybrid automatamodel. With the EAST-ADL language enhancement for explicit behavior descrip-tion, a more seamless integration of this component model through EAST-ADL forcomponent speci�cation and analysis of automotive embedded systems becomespossible. Such an integration can be compared to the work realized in [21], whereEAST-ADL and HRC are being integrated into the CESAR meta-model (CMM)for tool interoperability, but instead allows a more precise and more �ne-grainedintegration of structural and analytical artefacts.

AUTOSAR [3] represents a consensus of European automotive industry onthe design and con�guration of embedded software systems in vehicles. EAST-ADL, together with its support for precise description of behavioral concerns,complements AUTOSAR in regard to requirements engineering, model-based sys-tem design, functional safety, and variability, etc. The EAST-ADL support for the


declaration of timing constraints on execution events of system functions (e.g.,data age, end-to-end delay, the frequencies and precedences of function triggering)is aligned with the results of TIMMO [22]. EAST-ADL also provides explicit mod-eling support for safety engineering according to ISO26262 [7]. The descriptionsof estimated failure logic are currently based on a Boolean algebra according tothe HiP-HOPS technology [23] for safety analysis (e.g., fault-tree analysis). TheEAST-ADL enhanced support for behavior description promotes also a system-atic exploitation of a range of other emerging formal safety analysis methods andtools [24�26], for the safety engineering of automotive systems becomes possible.

EAST-ADL complements UML [6] and SysML [5] with abstraction levels anda model structure tailored for automotive usage through several lifecycle phases.A harmonization is also being carried out, for example through the EU FP6ATESST2 project (www.atesst.org), with a view to releasing the EAST-ADL pro-�le as an annex to MARTE [27]. A related e�ort on standardized system descrip-tion is the SAE "Architecture and Analysis Description Language" (AADL) [28],which has its roots in the avionics domain. Compared to EAST-ADL, the AADLsupport has a narrower scope, e.g., not covering the descriptions and analysis ofrequirements, system environment, functions at higher level, and test case spec-i�cation, as well as the related variability and traceability issues. Speci�cs forautomotive systems such as distributed hardware platform are also weakly sup-ported. There are also other ADL approaches that could be useful for the designof software based systems.

For instance, Darwin [29] is a component-based ADL supporting both struc-tural and behavioral modeling of parallel software systems. The structural modelconsists of the hierarchical composition of primitive and composite componentsconnected via well-de�ned interfaces. A primitive component is supplemented bythe behavior model using Labeled Transition Systems (LTS) or equally the processalgebra of Finite State Processes (FSP) [30�32]. The formalisms have the identi-cal expressive and analytical power of �nite state automata. The compositionalbehavior of the components is computed by synchronous product of �nite stateautomata. Various system properties expressible via �nite state automata and Lin-ear Temporal Logic (LTL) can be formally analyzed through model checking usingthe LTSA analysis tool.

The behavioral speci�cation of Darwin is limited to discrete-event formalismand LTL properties. It has no direct support to real-time properties or advancednumerical constraints. For example, Darwin cannot specify the dynamics of thestate of charge (SoC) of a battery according to the current through it. This typeof information is simply out of the scope of Darwin. Darwin has no modeling arti-facts for hardware architecture or network topology. Therefore, the critical designalternatives of software to hardware allocation cannot be speci�ed or analyzedwith Darwin. This decision, however, is a major challenge in the development ofcomplex software-intensive embedded systems.

CHARMY [33] is a design and veri�cation framework for checking the poten-tial design inconsistencies between the behavior speci�cations of individual compo-nents and the logical constraints on the interactions of the components. Adaptedfrom UML notation, CHARMY has incorporated rigorous semantics into state di-agrams and sequence diagrams [34]. The former are used to specify the componentbehavior and the latter to specify the logical/sequential constraints on componentcommunication. The semantics is tightly aligned with Promela and LTL, so the


CHARMY model can be readily converted into Promela code and simulated andformally veri�ed by the SPIN model checker [35]. CHARMY can also automaticallygenerate Java code from the architectural model.

The objective of CHARMY is identical to our work on the transformationfrom EAST-ADL model to SPIN model for formal veri�cation. We admit that thecomplexity and maturity of CHARMY are superior to ours. Our work, however,is concentrated on the limited behaviors of components and their communicationsprescribed by EAST-ADL, which is dedicated to the automotive embedded sys-tems. The restriction on the behavioral freedom is judiciously determined by thedevelopers of EAST-ADL according to the state of the art in automotive industry.For instance, the behavior of the elementary function must be deterministic and thecommunication must be asynchronous data transfer. These restrictions in EAST-ADL greatly simplify the complexity of SPIN transformation. Moreover, SPINtransformation is just one branch of the analysis supports to EAST-ADL enabledby our behavior constraint speci�cation. The formalism introduced in this paper isbased on hybrid automata encompassing both state transitions and continuous- ordiscrete-time dynamics. The formalism admits a wide scope of analysis supports,e.g., logical model checking, timing analysis, hazard analysis, numerical simulation,etc.

SAM [36,37] is a general formal framework for visualizing, specifying, andanalyzing software architectures. The behavior of components and connectors isspeci�ed by the Petri net model and the system properties speci�ed by tempo-ral logic. The analysis methods supported by SAM include simulation, symbolicmode checking using SMV, and theorem proving, using STeP. Applying di�er-ent variants of Petri nets and temporal logic, SAM can verify both functionaland extra-functional (non-functional) properties such as real-time schedulabilityand security. A notable advantage of SAM is its capability of verifying timingconstraints by model checking, which requires an additional variable to explic-itly count the time tick. This treatment may greatly scale up the complexity ofthe analysis. The timing analysis support to EAST-ADL, in contrast, exploits themore e�cient real-time model checker UPPAAL [38] , which implicitly encodestime as a small number of zones and hence substantially reduces the state size ofthe veri�cation model. Our approach is more suitable for model checking real-timeconstraints.

There are also many other architecture description languages or developmentframeworks supporting the formal speci�cation and analysis of software archi-tecture. For example, Wright [39] is based on CSP to perform formal veri�ca-tions including deadlock detection and behavioral re�nement. SaveCCM [40] isa component-based modeling language tailored for automotive embedded controlapplications. Exploiting the real-time model checker UPPAAL, the language andits tool support are particularly e�ective for specifying and verifying real-timeconstraints. While helpful for developing automotive embedded systems, these ap-proaches are limited to software aspect and hence lack the formal support to thedesign of complex software intensive embedded systems in a broader perspective,which further requires the information of requirements, functional design, hard-ware architecture, resource constraint, communication relationship, and softwareto hardware binding. On the contrary, facilitating system integration in the con-text of automotive OEMs is the strength of EAST-ADL. Moreover the behaviorconstraint speci�cation of EAST-ADL is not bound to one analysis tool. It is


comprehensive and �exible for utilizing various mature analysis tools with com-plementary objectives, such as Simulink, SPIN, UPPAAL, and HiP-HOPS.

7 Conclusion

Traditionally EAST-ADL concentrates on the communication and management ofmultileveled system architecture speci�cation while delegating the formal de�ni-tions of the execution behavior of application functions to external modeling andanalysis software, e.g., Matlab/Simulink, UML, and C code. This coarse-grainedstrategy soon became insu�cient and unmanageable owing to the increasing com-plexity and extra-functional concerns. The ADL support for more precise reason-ing and �ne grained traceability of behavioral information across requirements,architecture design, and analytical models plays a key role for the success of en-gineering activities related to requirements, dependability, componentization, de-sign veri�cation and validation, etc. This paper presents the recent enrichment ofEAST-ADL language for explicit behavior descriptions. Such an enrichment aimsnot only to enable modeling and analysis of complex software-intensive embeddedsystems through mature formal techniques, but also to integrate di�erent modelsand manage the system wide concerns in a common context of system develop-ment for requirements engineering, architecture design and re�nements, analysisof extra-functionality, and testing, etc.

Along with its bene�ts for architectural deign, information exchange and man-agement, EAST-ADL also constitutes a basis for the integration of state-of-the-art analysis methods and techniques from computer science, electronics&electricalengineering, and other related disciplines. We believe this approach presents animportant step in merging the gap between mature formal techniques and theneeds of correct-by-construction design and systematic software veri�cation andvalidation in a multidisciplinary engineering context. Our e�orts on the analyt-ical leverage of EAST-ADL are well justi�ed not only by the language's uniquesupport for the management of speci�cations throughout the entire developmentlifecycle, but also by the language's alignments to key industrial standards suchas ISO26262 and AUTOSAR.

To the best of our knowledge, none of the existing ADLs with the same levelof maturity covers the same scope as EAST-ADL with respect to the develop-ment lifecycle, extra-functional concerns, and engineering activities, albeit someADLs emphasize formal analysis and V&V support for software design. Moreover,primarily developed as an ADL for the automotive industry, EAST-ADL stresseson the elicitation and standardization of domain-speci�c modeling concepts andmethodology. Therefore it has in particular a greater potential as the modelingframework for the development of automotive software-intensive embedded sys-tems than any other ADLs.

Future work will concentrate on further evaluation of the approach, developingsystematic support for integrating several relevant analysis techniques, and con-sidering optimization with respect to viewpoints in system and component design.Another direction is to assess how the proposed approach is applicable throughother formal techniques.


References

1. Philippe Cuenot, DeJiu Chen, Sébastien Gérard, Henrik Lönn, Oliver Reiser, David Servat,Ramin Tavakoli Kolagari, Martin Törngren, Matthias Weber. Towards Improving Depend-ability by Using an Architecture Description Language. Lecture Notes in Computer Science,Volume 4615, Series: Architecting Dependable Systems (ADS) IV - Programming and Soft-ware Engineering, Pages 39-65. Springer Berlin / Heidelberg, 2007.

2. ISO International Organization for Standardization: ISO/DIS 26262 (2011)3. AUTOSAR - AUTomotive Open System ARchitecture. http://www. autosar.org (2012)4. EAST-ADL Domain Model Speci�cation, Version M.2.1.9 2011-01-30.http://www.maenad.eu/ public/ EAST-ADL-Speci�cation. (2011)

5. SysML (Systems Modeling Language), Object Management Group, OMG. http://omgsysml.org (2012)

6. UML (Uni�ed Modeling Language), Object Management Group, OMG, http: //www.uml.org (2012)

7. DeJiu Chen, Rolf Johansson, Henrik Lönn, Hans Blom, Martin Walker, Yiannis Papadopou-los, Sandra Torchiaro, Fulvio Tagliabo, Anders Sandberg: Integrated Safety and ArchitectureModeling for Automotive Embedded Systems. e&i - elektrotechnik und informationstechnik,Volume 128, Number 6, Automotive Embedded Systems. Springer Wien (2011)

8. Anders Sandberg, DeJiu Chen, Henrik Lönn, Rolf Johansson, Lei Feng, Martin Törngren,Sandra Torchiaro, Ramin Tavakoli-Kolagari, Andreas Abele: Model-based Safety Engineeringof Interdependent Functions in Automotive Vehicles Using EAST-ADL2. Lecture Notes inComputer Science, Volume 6351, Series: Computer Safety, Reliability, and Security (SAFE-COMP), Pages 332-346. Springer Berlin / Heidelberg (2011)

9. Nidhal Mahmud, Martin Walker, Yiannis Papadopoulos: Compositional synthesis of Tempo-ral Fault Trees from State Machines. ACM SiGMETRICS Performance Evaluation Review,Volume 39 (4):79-88. ACM New York, NY, USA. (2012)

10. Richard Anthony, DeJiu Chen, Mariusz Pelc, Magnus Persson, Martin Törngren: Context-Aware Adaptation in DySCAS. Electronic Communications of the EASST, Volume 19:Context-Aware Adaptation Mechanism for Pervasive and Ubiquitous Services (CAMPUS).2009. European Association of Software Science and Technology (EASST) (2009)

11. G.J. Holzmann, The SPIN Model Checker:Primer and Reference Manual, Addison Wesley(2003)

12. SPIN Website, http://spinroot.com, April 201213. The Motor Industry Software Reliability Association, MISRA-C:2004 Guidelines for theUse of The C Language in Critical Systems. MIRA Limited, October 2004. (2004)

14. J. Lygeros, C. Tomlin, and S. Sastry, Controllers for reachability speci�cations for hybridsystems, Automatica, Special Issue on Hybrid Systems, 1999. (1999)

15. Lei Feng, DeJiu Chen, Henrik Lönn, and Martin Törngren. Verifying System Behaviors inEAST-ADL2 with the SPIN Model Checker. IEEE International Conference on Mechatronicsand Automation. Xi′an, China, August 4-7, 2010. (2010)

16. T. N. Qureshi, D. Chen, H. Lönn, M. Törngren. From EAST-ADL to AUTOSAR SoftwareArchitecture: A Mapping Scheme, Proceedings of the 5th European Conference on SoftwareArchitecture, 13-16 September, 2011, Essen, Germany. (2011)

17. Tahir Naseer Qureshi, DeJiu Chen, Henrik Lönn and Martin Törngren, From EAST-ADLto AUTOSAR Software Architecture: A Mapping Scheme, The 5th European Conference onSoftware Architecture, 13-16 September, 2011, Essen, Germany (2011)

18. Matthias Biehl, DeJiu Chen, Martin Törngren, Integrating Safety Analysis into the Model-based Development Toolchain of Automotive Embedded Systems, ACM SIGPLAN NO-TICES, Volume: 45 Issue: 4 , Pages: 125-131. ACM 2010. (2010)

19. Carl-Johan Sjöstedt, Jianlin Shi, Martin Törngren, David Servat, DeJiu Chen, ViktorAhlsten, Henrik Lönn, Mapping Simulink to UML in the Design of Embedded Systems:Investigating Scenarios and Structural and Behavioral Mapping. OMER 4 Post WorkshopProceedings - April 2008. (2008)

20. SPEEDS (Speculative and Exploratory Design in Systems Engineering) project, EU FP6.http://www.speeds.eu.com (2012)

21. Eric Armengaud, Markus Zoier, Andreas Baumgart, Matthias Biehl, DeJiu Chen, GerhardGriessnig, Christian Hein, Tom Ritter, Ramin T. Kolagari. Model-based Toolchain for theE�cient Development of Safety-Relevant Automotive Embedded Systems. SAE 2011 WorldCongress, April 2011, Detroit, USA (2011)

22. TIMMO(TIMing Model)project, ITEA2, http://www.timmo.org (2012)


23. Y. Papadopoulos, and C. Grante,Evolving car designs using model-based automated safetyanalysis and optimisation techniques, Journal of Systems and Software, vol. 76(1), pp. 77-89.Elsevier Science, 2005. (2005)

24. Marc Herbstritt, Ralf Wimmer, Thomas Peikenkamp, Eckard Böde, Michael Adelaide,Sven Johr, Holger Hermanns, Bernd Becker, Analysis of Large Safety-Critical Systems: Aquantitative Approach. REPORTS of SFB/TR 14, AVACS - Automatic Veri�cation andAnalysis of Complex Systems, 2006. (2006)

25. M. Bozzano, A. Villa�orita, et al., ESACS: an integrated methodology for design andsafety analysis of complex systems, ESREL European Safety and Reliability Conference,Balkema, Pages: 237-245, 2003. (2003)

26. A. Arnold, A. Gri�ault, G. Point, A. Rauzy, The Altarica formalism for describing con-current systems. Fundamenta Informaticae 40, Pages: 109-124, 2000. (2000)

27. MARTE (Modeling and Analysis of Real-time and Embedded systems), Object Manage-ment Group, OMG, http://omgmarte.org (2012)

28. AADL (Architecture Analysis and Design Language), SAE standard, http://www.aadl.info/ aadl/ currentsite (2012)

29. Darwin (An Architectural Description Language), http:// www-dse.doc.ic.ac.uk / Soft-ware/ Darwin (2012)

30. D. Giannakopoulou, Model Checking for Concurrent Software Architectures. PhD Thesis,Imperial College of London, London, U.K.1999. (1999)

31. J. Kramer, J. Magee, and S. Uchitel, Software Architecture Modeling and Analysis: ARigorous Approach, Formal Methods for Software Architectures, LNCS, Volume 2804, pp.44-51, 2003.(2003)

32. J. Magee, J. Kramer, and D. Giannakopoulou, Behaviour Analysis of Software Archi-tectures, in Software Architecture, Partrick Donohoe (editor), pp. 35-49, Kluwer AcademicPublishers, 1999. (1999)

33. CHARMY (Checking ARchitectural Model consistencY), http:// www.di.univaq.it /charmy/ (2012)

34. P. Pelliccione, P. Inverardi, and H. Muccini, CHARMY: A Framework for Designingand Verifying Architectural Speci�cations, IEEE Transactions on Software Engineering,35(3):325-346, 2009. (2009)

35. P. Inverardi, H. Muccini, and P. Pelliccione, Automated Check of Architectural ModelsConsistency using SPIN, in Proceedings of the 16th IEEE International Conference on Au-tomated Software Engineering, pp.346-349, 2001. (2001)

36. X. He, J. Ding, and Y. Deng, Model Checking Software Architecture Speci�cations inSAM, in Proceedings of the 14th International Conference on Software Engineering andKnowledge Engineering, pp. 271-274, Ischia, Italy, 2002. (2002)

37. X. He, H. Yu, T. Shi, J. Ding, and Y. Deng, Formally Analyzing Software ArchitecturalSpeci�cations using SAM, The Journal of Systems and Software, 71(1-2):11-29, 2004. (2004)

38. UPPAAL, http://www.uppaal.org. (2012)39. R. Allen and D. Garlan, A Formal Basis for Architectural Connection, ACM Transactionson Software Engineering and Methodology, 6(3): 213-249, 1997. (1997)

40. H. Hansson, M. Åkerholm, I. Crnkovic, and M. Törngren, SaveCCM - A Component Modelfor Safety-Critical Real-Time Systems, in Proceedings of the 30th EUROMICRO Conference,pp.627-635, 2004. (2004)

An architectural approach to the analysis, verification and validation of software intensive...

Documents

Transcript of An architectural approach to the analysis, verification and validation of software intensive...