Systems Modeling with EAST-ADL forFault Tree Analysis through HiP-HOPS ?

DeJiu Chen ∗ Nidhal Mahmud ∗∗ Martin Walker ∗∗ Lei Feng ∗

Henrik Lönn ∗∗∗ Yiannis Papadopoulos ∗∗

∗ KTH Royal Institute of Technology, SE-100 44 Stockholm, Sweden,(e-mail: {chen, leifeng}@md.kth.se).

∗∗ University of Hull, Hull HU6 7RX, UK, (e-mail: {N.Mahmud,Martin.Walker, Y.I.Papadopoulos}@hull.ac.uk)

∗∗∗ Volvo Group Trucks Technology, Gothenburg, Sweden, (e-mail:henrik.lonn@volvo.com)

Abstract:EAST-ADL is a domain-specific modeling framework with methodology and language supportfor the engineering of automotive embedded systems. In regard to functional safety, it aims toprovide the maximum possible support for ISO 26262 so that all safety related information can beconsolidated seamlessly in a common system model together with the requirements specification.This paper describes the EAST-ADL support for the modeling of plausible error behaviors as anorthogonal system view. We introduce in particular an integration of such EAST-ADL modelswith the HiP-HOPS method for automated temporal fault tree analysis.

Keywords: Embedded systems, System Engineering, Error Modeling, Formal Specification,Behavior, Safety Analysis

1. INTRODUCTION

Embedded electronics/electrical (E/E) systems are nowa-days widely used in automotive vehicles for the realizationof advanced functionality such as active safety, optimal fuelconsumption, and cooperative behaviors. While account-ing for a large portion of innovations and value-added ofautomotive vehicles, the E/E systems are inherently safetycritical as their anomalies can cause harm or property loss.In the development, functional safety represents one keyquality concern, referring to the part of system safety thatdepends on the correctness of a system itself in performingits intended functionality. In this regard, ISO 26262 rep-resents the domain consensus on the preferred approach.See ISO26262 (2010).

There is a wide range of methods and tools aiming to sup-port safety analysis. However, experience tells us that chal-lenges remain in maintaining the assumptions and analysisresults in terms of error behaviors, safety requirements andsolution concepts along with the nominal system design,refinement, and evolution. Approaches relying on social ortextual means for the information exchange between safetyengineers and other system stakeholders are insufficient foreffective safety engineering.

To promote a systematic approach, EAST-ADL focuseson the provision of methodology and modeling supportallowing all safety related information according to ISO26262 to be captured and managed seamlessly along withthe nominal system design specification. See Chen et al.(2011). For the correctness of decisions, EAST-ADL also? This work is supported by the projects MAENAD (EU FP7, Grant260057) and MBAT (ARTEMIS-JU, Grant 269335).

provides the support for formalizing all behavior concerns,such as relating to requirements and plausible anomalies.This makes it possible to fully utilize the leverage of state-of-the-art technologies for automated safety analysis.

There are several well-known approaches to automatedsafety analysis. See Chen et al. (2008) for a discussion.Some of these approaches infer the effects of componentfailures on the overall system by means of model-checkingand simulation techniques, such as the approaches de-scribed in Arnold et al. (2000) and Bozzano et al. (2003).These approaches can be computationally expensive dueto their inductive nature (i.e. from causes to effects), espe-cially when combinations of failures need to be considered.Instead, a deductive approach (i.e. from effects to causes)can often be more efficient. One example is the HiP-HOPSmethod, originally described in Papadopoulos&McDermid(1999) for a static safety analysis, but recently extendedin Walker et al. (2009) and Mahmud et al. (2010, 2012)for a temporal analysis.

This paper studies the integration of formal error behaviordescriptions in EAST-ADL with the HiP-HOPS methodfor fault tree analysis. Such error models annotate theestimated failure modes, their transitions to/from otherstates, and their propagation within the target systems.Through EAST-ADL, all behavioral definitions are man-aged in a traceable way to requirements and design solu-tions. The paper is organized as follows: We first introducesome key EAST-ADL concepts for system description andbehavior modeling. Next we present the EAST-ADL meta-model for formal error modeling and the method for safetyanalysis. Thereafter, we elaborate the integration of HiP-

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

HOPS support for temporal fault tree analysis through acase study. We conclude with a short discussion.

2. AN OVERVIEW OF THE EAST-ADL LANGUAGE

EAST-ADL represents one approach to multi-viewed sys-tem description with the aim of promoting separation-of-concerns and thereby effective quality management.See EAST-ADL (2011). The language is highly modular,consisting of packages as shown in Fig. 1. The core ofsystem description is the System Model that specifies thestructural design in multiple levels of abstraction. Theselevels are: Vehicle Level, Analysis Level, Design Level, andImplementation Level. The mappings across these multiplelevels of system description are specified and managedby Realization links. For requirement engineering, EAST-ADL allows each requirement to be traced to the relateddesign solutions, verification and validation cases, as wellas to other interdependent requirements.

The vehicle level model provides the topmost specificationof an embedded system by capturing the externally visiblefunctionalities. For safety engineering, such a top-level sys-tem specification also constitutes the basis for the elicita-tion and analysis of safety goals during preliminary hazardanalysis (PHA), also referred to as Hazard analysis andRisk assessment (H&R). A vehicle level system model is

Fig. 2. An EAST-ADL model showing a Functional DesignArchitecture for a vehicular embedded system, calledDA. The parts of DA are given by prototypes.

refined by an analysis level model, which captures the un-derlying system functional architecture consisting of I/Ofunctions (e.g. for plant monitoring and actuation) andcontrol functions (i.g. for feedback dynamic control). Forsafety engineering, an analysis level model constitutes thebasis for reasoning about the functional anomalies therebyfor the mapping of system safety goals to more detailedfunctional safety requirements. For a more detailed systemspecification, an analysis level model is refined througha logical design step, where the choices of computationand communication technologies are specified and takeninto consideration. Such a logical design step is supportedby the design level system model, representing the Func-tional Design Architecture that defines the grouping andpartitioning of functions and the Hardware Design Archi-tecture that characterizes the target hardware platform,and an allocation matrix that specifies the binding ofthe abstract functions to the platform. As a FunctionalDesign Architecture specifies the structuring of systemfunctions to be implemented, it constitutes the basis forreasoning about the error behaviors of software and hard-ware components and thereby the refinement of functionalsafety requirements to some more detailed technical safetyrequirements. The implementation level model providesa detailed specification of software components and thearchitecture configuration according to AUTOSAR (seeAUTOSAR (2013)). In regard to safety engineering, thetechnical safety requirements are further refined at thislevel into software and hardware requirements. See Fig. 2for an example of the structural design specification.

In system development, behavior modeling and analysisplay a key role for assuring the correctness of decisions inregard to requirements engineering, architectural designand refinement, and the design of verification&validationtasks. EAST-ADL allows the developers to explicitly cap-ture various behavioral concerns through a recently devel-oped language package, referred to as Behavior Descrip-tion Annex (Chen et al. (2013)). The support is funda-mentally a hybrid system model (Lygeros et al. (1999)),while emphasizing the provision of a practical modelinglanguage for annotating and managing various behavioralconcerns together with the specifications of requirements,design solutions, and other work products on a commonbasis. In EAST-ADL, a behavior annotation, referred toas behavior constraint, can get different roles dependingon the declared target associations. For example, such abehavior constraint can be used to capture the bounds ofthe acceptable behaviors of a system function. A behaviorconstraint can also be used to refine the textual statementsof requirements including assumed system operational sit-uations. Moreover, a behavior constraint can be introducedto provide a formalization of error annotations, furtherexplained in Section 3.

3. ERROR MODELING WITH EAST-ADL

Through its Dependability package, EAST-ADL allowsa wide range of functional safety related concerns (e.g.hazards, faults/failures, safety requirements) to be de-clared and structured seamlessly along with the lifecycle ofnominal system development. Based on such a structureddescription, EAST-ADL also provides necessary modeling

Fig. 3. An overview EAST-ADL meta-model concepts forerror description.

support for precisely defining the related error behaviorsfor safety analysis. See Chen et al. (2011).

Fig. 3 shows the key modeling concepts of EAST-ADLto support a well-structured error description. The Error-Model is a language construct for associating the annota-tions of error descriptions to the targeted system entitiesand thereby for maintaining the traceability. See Fig. 4for a modeling example. Different error models can becomposed through prototypes (Prototype), representingthe instantiations of an error model in particular contexts,such as due to the composition within the correspondingnominal system design. See Fig. 5 for a modeling example.Within each ErrorModel, there are declarations of variousplausible anomalies (Anomaly) in terms of faults and fail-ures. While the fault ports (FaultInPort) declare whichfaults the targeted system entity can receive from its envi-ronment, the failure ports (FailureOutPort) declare whichfailures may occur and propagate to the environment. Suchports are analytical and can be traced to the correspondingcommunication ports of functions or components. An In-ternalFault represents an internal condition that can causeerrors only when being activated. A ProcessFault refersto a permanent systematic fault (e.g. incorrect design).Within each error model, there is a declaration of error be-havior (ErrorBehavior) relating output failures of a systemfunction or component with its faults. The exact formalismdepends on the choice of analysis methods. The actualvalue of an anomaly is declared with the FaultFailure onthe basis of an enumeration type, such as {omission, com-

Fig. 4. An error model associated to the architecture DA.The failure out port braking_failure_DL representsthe combinatorial failure modes of all braking actua-tors, to which some safety constraints are applied.

Fig. 5. A composite error model with prototypes and errorpropagations. The error behavior is described usingthe original Boolean logic expression of HiP-HOPS.

mission}. For the error propagations across error modelsdue to communication or allocation, a PropagationLinkconnects an output failure port with an input fault portbased on the semantics of shared-variable. The declarationof SafetyConstraint defines the qualitative bounds on thefault and failure values in terms of safety integrity level(ASIL) as defined by ISO26262 (2010). See Papadopouloset al. (2010) for a concept on how to effectively assignsafety constraints to system parts.

A state-machine (SM) based definition of error behaviorsis achieved through the EAST-ADL temporal behaviorconstraint specification. As a part of the EAST-ADLBehavior Description Annex (Chen et al. (2013)), thetemporal constraint specification 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 be-havior to be satisfied by a system or its environment,ST AT E = {s0, . . . , sk}, k ∈ N.• EVT OC denotes the event occurrences taken into

consideration. An event occurrence denotes the actualhappening of certain logical, execution, and erroneousconditions.• T RANS denotes the set of discrete transitions be-

tween discrete states because of the occurrences ofdiscrete events or the violations of a state invari-ant in time or in value quantification. T RANS ⊆ST AT E × EVT OC × QG × T G × EFF × ST AT E ,with ST AT E denotes the from and to discrete states,QG denotes the possible value guards, T G denotesthe possible time guards, EVT OC denotes the eventoccurrences of concern, EFF denotes the effects of theoccurrence of the logical transformations associatedto the transition.• s0 ∈ ST AT E is the initial state.• LT C denotes a set of time intervals that constitute

the logical time basis.

Fig. 6 shows an error behavior description with the failurelogic in SM. The target is a system control functionwith two internal parts func_a and func_b. The initialstate is AB to indicate that the internal parts are bothworking. If func_b fails first, the system changes its stateto AX, then to DEGRADED upon a subsequent failure

Fig. 6. A state-machine based error logic description.

of func_a. However, the other sequence of failures ismore severe, i.e., if func_a fails first, the system changesits state to XB, then to a complete failure FAILEDupon a subsequent failure of func_b. These definitionsare summarized as follows: ST AT E = {AB, XB, AX,FAILED, DEGRADED}; EVT OC = {A_Fails, B_Fails};T RANS = {(AB, A_Fails, XB), (AB, B_Fails, AX ),(AX, A_Fails, FAILED), (XB, B_Fails, DEGRADED)};s0 = AB ; LT C = ∅ for this example SM.

4. SUPPORT FOR SAFETY ANALYSIS

For the analytical leverage of EAST-ADL, HiP-HOPS isbeing used as one underlying method and tool for depend-ability analysis and optimisation. See Walker et al. (2013).When performing fault tree analysis with SM based failurelogic or behavior descriptions, the order in which failureevents occur has to be considered, as this affects the over-all outcome. To this end, a novel compositional method,SAFORA 1 , has been developed (see Mahmud (2012)).The method, through HiP-HOPS, generates temporal faulttrees (TFTs) for an entire system from SMs describing theerror behaviors of individual functions and components.A central issue on which SAFORA relies is the composi-tional modeling of the system behavior. This consists of ahighly abstract SM which describes the monolithic failurebehavior of the system at the top-level of the hierarchy andthe SMs of components (and sub-components) at the lowerlevels (see Fig. 7). Typically, each event of the abstract SMof the system is synchronized with at least one event in acomponent SM (i.e., an expandable event).

To transform a SM to a fault tree, each SM state thatrepresents a system failure state becomes the head of acorresponding fault tree. All paths through the SM to sucha state become a disjunction of causes (one cause per path)of the failure event, and each cause is represented as aconjunction of all events in its corresponding path whichhave caused the system, or the component, to fail. Eachconjunction represents one cut set of the fault tree, andif it contains no redundancies, then it is a minimal cutset (MCS). To correctly capture the sequence-dependentfailures, Safora uses the Pandora TFTs (Walker et al.(2009)). Pandora provides additional gates like Priority-AND gate (PAND, symbol ‘<’) and the Priority-OR gate(POR, symbol ‘|’) to express the temporal characteristicsof error events, such as ‘A fails’ before ‘B fails’ and1 It stands for State Automata to Fault trees, possibly extendedwith temporal information (ORA in Greek).

Fig. 7. Overview of the Safora method.

‘B fails’ before ‘A fails’ depicted in Fig. 6. A PANDgate represents a sequence of events typically from leftto right, while a POR gate models a priority situationwhere one event (leftmost) must occur first and otherevents may or may not occur subsequently. To supporta qualitative analysis, Pandora defines a set of temporallaws for identifying and removing redundant sequences ofevents. For example, (A|B).B ⇔ A<B, where the left handconjunction expression using ‘|’ (A must occur first, but Bmust also occur) is equivalent to the right hand expressionusing ‘<’ (A occurs before B, both events have to occur).

Generation of the fault tree works backwards by startingwith generating preliminary TFTs of the system failures(i.e., total failures as top events). Thereafter, for each eventthat is derived from the component failures, the Saforasynthesis expands the preliminary system TFTs with thefault trees of the components. From the individual SMsthat form the basis of component fault trees, necessaryPandora failure expressions are generated, capturing thetemporal dependency between a final state that leadsdirectly to some failures and other states in the pathsleading to such a final state. The generation of system faulttrees is done through a synthesis algorithm that mergesthese component expressions. Minimization can take placeduring the synthesis wherever possible.

5. CASE STUDY

We use a generic triple-module redundant (GTR) system,shown in Fig. 8, for studying the integrated analytical

Fig. 8. A snapshot of the internal structure of GTR system.

support. In the system, the components A, B and Cimplement a replicated system function. The component Ais the primary backed up by the components B and C. S1and S2 are two monitoring functions for detecting omissionfailures of A and B respectively and then activating thebackup functions. If S1 detects an omission failure of A itshould activate B, and if S2 detects an omission failure ofB it should activate C. D is simply an output filter.

For the safety analysis, we set up an error model as shownin Fig. 9, where the error behaviorGTR_System_ErrBehavdeclares a highly abstract description of the monolithicerror behavior of the entire system. The content ofGTR_System_ErrBehav is shown in Fig. 10. Note thatthe O-I event is a single point of failure that affect theentire system. As a modeling choice, we allow that theevent O-I to be modeled only at the system level.

Fig. 9. The error model for the GTR system.

Fig. 10. The monolithic error behavior of the GTR system.

The error model prototypes in a system error modelallow the error behaviors of components to be composed.Declared within the prototype a:A_Err, the component Ahas an error behavior as shown in Fig. 11, where the statetransition is assumed to be triggered only by the internalfailure ‘a_fails’.

Fig. 11. The error behavior of component A.

The error behaviors of B and C are maintained withinb:B_Err and c:C_Err and defined as shown in Fig. 12and 13. These components have multiple states that leadto omission failures. The state Permanently OFF meansthat the components will never be activated when S1 or S2has prematurely failed. In C, the state Failed is reachedwhen A and B have failed in sequence, and C has alsofailed (caused by the event c fails). The error behaviorof component D is declared within the model prototypec:D_Err, shown in 14. Note that A and D are each initiallyin state ON, i.e. the GTR system is initially working withits primary component, and the output is being delivered

by the system. Backup components have their initial statesset to OFF and sensors are initially set to Monitoring.

Fig. 12. The error behavior of component B.

Fig. 13. The error behavior of component C.

Fig. 14. The error behavior of component D.

The functions S1 and S2 have the error behaviors declaredwithin the prototypes s1:S1_Err and s1:S1_Err respec-tively. The definitions are shown in Fig. 15 and Fig. 16.We distinguish between two types of failures from B. Theevent O-B Not Severe represents a detectable omissionwhich occurs when B has been already activated by S1upon failure of A, but fails afterward. It is the effect ofentering the state Safely Failed, which allows S2 to activateC assuming S2 itself has not yet failed. The omission O-B Severe is an undetectable failure caused by either adormant failure of B or a premature failure of S1 ; eithercase means that S1 is unable to activate B upon failureof A. This omission is the effect of B entering the stateSeverely Failed or the state Permanently OFF and willlead the system to a total failure.

Fig. 15. The error behavior of S1.

With these error definitions, a set of preliminary TFTexpressions are generated. For the overall system, wehave the expression FAILED=O-I+O-D, where the non-atomic event O-D depends on the O-D event of componentD. Such a dependency allows a further search in the

Fig. 16. The error behavior of S2.

system error model for underlying event generators. Forthe component D, we have two expressions: Failed =d_fails and OFF = O-C + O-B Severe. Since the failureexpression leading to O-D is the disjunction of these twoexpressions, we have O-D =d_fails + O-C + O-B Severe.Therefore, at this stage, the top level system TFT can beexpressed as follows:

FAILED = O-I + d_fails + O-C + O-B Severe

Here, the O-C and O-B Severe are two non-atomicevents to be traced through error propagation links tothe corresponding component error behaviors (see alsoFig. 9). For B, we have: Permanently_OFF = O-S1 ;Severely_Failed = b-on.(b_fails|b_on). Accordingly, thecorresponding TFT definition becomes: O-B Severe = O-S1 + b-on.(b_fails|b_on). This expression can be furtherreduced to: O-B Severe = O-S1 + b_fails<b_on. ForC, we have: Permanently_OFF = O-S2 ; Failed = c-fails.c_on, and thereby O-C= O-S2 + c-fails.c_on. Asa result, a more expanded system TFT at this stage is:

FAILED = O-I + d_fails + O-S2 + c-fails.c_on +O-S1 + b_fails<b_on

At this level, one non-atomic event is O-S2, caused bya severe failure of the monitoring function S2. The errorbehavior is: O-S2 = (O-B Not Severe).s2_fails|(O-B NotSevere), which can be reduced to: O-S2 = s2_fails<(O-BNot Severe). The c_on event 2 is traced to the functionS2 with: c_on = O-B Not Severe. In a similar way as forother functions, the O-B Not Severe can be defined as: O-B Not Severe = b_on <b_fails, where b_on = O-A due tothe function S1. For the non-atomic event O-S1, we haveO-S1 = O-A.s1_fails<O-A = s1_fails<O-A. Accordingto the definition of A, O-A = a_fails. The full system TFTis therefore refined to:

FAILED = O-I + d_fails + s2_fails<(a_fails<b_fails)+ c-fails.(a_fails<b_fails) + s1_fails<a_fails +

b_fails<a_fails

This temporal fault tree shows that the GTR system canfail with the following alternative scenarios: 1. Omissionof system input; or 2. Failure of output block D ; or 3. S2failing before A, and A failing before B ; or alternatively Afailing before S2, and S2 failing before B ; or 3. all threemain components A, B and C fail, with A failing beforeB ; or 4.S1 failing dormant before it detects failure of A; or5.B failing dormant before A fails, so C never activates.

6. CONCLUSION

We have presented the EAST-ADL approach to an inte-grated error modeling and system architecture description,2 This signal traverses through a communication link instead of errorpropagation.

with the analytical leverage given through HiP-HOPS.Along with its support for fault tree synthesis, the formal-ized behavior description also constitutes a basis for theintegration of other state-of-the-art analysis methods andtools. We believe that a combination of static analysis andmodel checking techniques through a modeling frameworklike EAST-ADL would be necessary for the effectiveness ofengineering. The actual choice depends on the availabilityof system details as well as on the roles of analysis (e.g.requirements engineering, identification of sensitive points,or detailed V&V of fault tolerance design).

REFERENCES

A. Arnold, A. Griffault, et al. The Altarica formalism fordescribing concurrent systems. Fundamenta Informati-cae, vol. 40, pp.109-124, 2000.

AUTOSAR. AUTOSAR, 2013. http://www. autosar.orgM. Bozzano, A. Villafiorita, et al. ESACS: an integratedmethodology for design and safety analysis of complexsystems. ESREL European Safety and Reliability Con-ference, Balkema, pp.237-245. 2003.

EAST-ADL. EAST-ADL Domain Model Specification,Version M.2.1.9. 2011. http://www.maenad.eu

D. Chen, R. Johansson, et al. Modelling Support for De-sign of Safety-Critical Automotive Embedded Systems.LNCS, vol. 5219, pp. 72-85. Springer. 2008.

D. Chen, R. Johansson, et al. Integrated Safety and Archi-tecture Modeling for Automotive Embedded Systems.e&i, vol. 128, Number 6. Springer. 2011.

D. Chen, L. Feng, et al. An Architectural Approach tothe Analysis, Verification and Validation of SoftwareIntensive Embedded Systems. Computing, Springer.DOI: 10.1007/s00607-013-0314-4. 2013.

ISO 26262. ISO 26262, International Organization forStandardization. 2010.

J. Lygeros, C. Tomlin, and S. Sastry. Controllers for reach-ability specifications for hybrid systems. Automatica,Special Issue on Hybrid Systems. 1999.

N. Mahmud, Y. Papadopoulos, M. Walker. A Translationof State Machines to Temporal Fault Trees. Proc.40th Annu. IEEE/IFIP Int. Conf. Dependable Syst. andNetw., pp. 45-51, Chicago, Illinois, 2010.N. Mahmud. Dynamic Model-based Safety Analysis:From State Machines to Temporal Fault Trees. Ph.D.dissertation, Univ. of Hull, UK. 2012.

N. Mahmud, M. Walker, Y. Papadopoulos. Compositionalsynthesis of Temporal Fault Trees from State Machines.ACM SiGMETRICS Performance Evaluation Review,Volume 39 (4):79-88. ACM New York, NY, USA. 2012.

Y. Papadopoulos, J.A. McDermid. Hierarchically per-formed hazard origin and propagation studies. LNCS,vol. 1698, pp.139-152. Springer. 1999.

Y. Papadopoulos, M. Walker, et al. Automatic allocationof safety integrity levels. ACM CARS2010 , pp. 7-10,Valencia, Spain, 27 April 2010.M. Walker, Y. Papadopoulos. Qualitative temporalanalysis: Towards a full implementation of the FaultTree Handbook. Control Eng. Practice, Vol. 17, pp.1115-1125. Oct. 2009.M. Walker, M.-O. Reiser, et al. Automatic Opti-misation of System Architectures using EAST-ADL.Journal of Systems and Software, Elsevier. DOI:10.1016/j.jss.2013.04.001. 2013.