Formal Verification of Complex Systems based … Verification of Complex Systems based on SysML...

12
Formal Verification of Complex Systems based on SysML Functional Requirements Hoda Mehrpouyan 1 , Irem Y. Tumer 2 , Chris Hoyle 2 , Dimitra Giannakopoulou 3 , Guillaume Brat 3 1 TSYS School of Computer Science, Columbus State University, Columbus, GA, USA mehrpouyan [email protected] 2 School of Mechanical, Industrial, and Manufacturing Engineering, Oregon State University, Corvallis, OR, USA [email protected], [email protected] 3 NASA Ames Research Center, Moffett Field, CA, USA [email protected], [email protected] ABSTRACT As modern systems continue to increase in size and complex- ity, they pose increasingly significant safety and risk manage- ment challenges. A model-based safety approach is an effi- cient way of coping with the increasing system complexity. It helps better manage the complexity by utilizing reasoning tools that require abstract models to detect failures as early as possible during the design process. This paper develops a methodology for the verification of safety requirements for design of complex engineered systems. The proposed ap- proach combines a SysML modeling approach to document and structure safety requirements, and an assume-guarantee technique for the formal verification purpose. The assume- guarantee approach, which is based on a compositional and hierarchical reasoning combined with a learning algorithm, is able to simplify complex design verification problems. The objective of the proposed methodology is to integrate safety into early design stages and help the system designers to con- sider safety implications during conceptual design synthesis, reducing design iterations and cost. The proposed approach is validated on the quad-redundant Electro-Mechanical Actu- ator (EMA) of a Flight Control Surface (FCS) of an aircraft. 1. I NTRODUCTION In recent years, technological advancements and a growing demand for highly reliable complex engineered systems, e.g., space systems, aircrafts, and nuclear power plants have made the safety assessment of these systems even more important. Moreover, the growing complexity of such systems has made it more challenging to achieve design solutions that satisfy Hoda Mehrpouyan et al. This is an open-access article distributed under the terms of the Creative Commons Attribution 3.0 United States License, which permits unrestricted use, distribution, and reproduction in any medium, pro- vided the original author and source are credited. safety and reliability requirements (Wiese & John, 2003; Zio, 2009; N. Leveson, 2011). Hollnagel et al. (Hollnagel, Woods, & Leveson, 2007) recognize the fact that safety violation in complex systems is not necessarily a consequence of com- ponents’ malfunction or a faulty design. Rather it could be a result of a network of ongoing interactions between all the components and subsystems that introduce undesired behav- ior. For this reason, Baroth et al. (Baroth et al., 2001) recom- mends the Prognostic and Health Management System (PHMS) as a new technology to replaces the traditional build-in test (BIT) with intelligent prognostics tools to predict the occur- rence of unexpected faults. However, given the local safety properties of each component, it is not a trivial matter to infer the safety and reliability of the whole system (N. G. Leve- son, 2009). Well-specified verification formalism and rea- soning tools are needed to study the emerging behavior and to perform exhaustive verification of safety properties. A se- ries of safety standards emerged in recent years that recognize this issue and strongly recommended the use of formal veri- fication methods to control the complexity of safety-critical systems, i.e., the international standard on safety related sys- tems (IEC, 1998) and the SAE & EUROCAE standards in the avionic industry (ARP4761, 1996; ARP4754, 1996). How- ever, these standards do not specify how to implement formal approaches throughout the design process. Strategies for engineered system design emerge from a pro- cess of requirement decomposition and transforming require- ment models into the conceptual models (Blanchard, 2012; Buede, 2011). Requirement models, noted R, capture the de- sign problem being solved and conceptual models, noted S, represent the specific solution for the design problem. There- fore, the first step in specifying and formulating a complex system is to capture its requirements R and decompose it into the requirements of its sub-systems and components, noted 1

Transcript of Formal Verification of Complex Systems based … Verification of Complex Systems based on SysML...

Formal Verification of Complex Systems based on SysMLFunctional Requirements

Hoda Mehrpouyan1, Irem Y. Tumer2, Chris Hoyle2, Dimitra Giannakopoulou3, Guillaume Brat3

1 TSYS School of Computer Science, Columbus State University, Columbus, GA, USAmehrpouyan [email protected]

2 School of Mechanical, Industrial, and Manufacturing Engineering, Oregon State University, Corvallis, OR, [email protected], [email protected]

3 NASA Ames Research Center, Moffett Field, CA, [email protected], [email protected]

ABSTRACT

As modern systems continue to increase in size and complex-ity, they pose increasingly significant safety and risk manage-ment challenges. A model-based safety approach is an effi-cient way of coping with the increasing system complexity.It helps better manage the complexity by utilizing reasoningtools that require abstract models to detect failures as earlyas possible during the design process. This paper develops amethodology for the verification of safety requirements fordesign of complex engineered systems. The proposed ap-proach combines a SysML modeling approach to documentand structure safety requirements, and an assume-guaranteetechnique for the formal verification purpose. The assume-guarantee approach, which is based on a compositional andhierarchical reasoning combined with a learning algorithm,is able to simplify complex design verification problems. Theobjective of the proposed methodology is to integrate safetyinto early design stages and help the system designers to con-sider safety implications during conceptual design synthesis,reducing design iterations and cost. The proposed approachis validated on the quad-redundant Electro-Mechanical Actu-ator (EMA) of a Flight Control Surface (FCS) of an aircraft.

1. INTRODUCTION

In recent years, technological advancements and a growingdemand for highly reliable complex engineered systems, e.g.,space systems, aircrafts, and nuclear power plants have madethe safety assessment of these systems even more important.Moreover, the growing complexity of such systems has madeit more challenging to achieve design solutions that satisfy

Hoda Mehrpouyan et al. This is an open-access article distributed under theterms of the Creative Commons Attribution 3.0 United States License, whichpermits unrestricted use, distribution, and reproduction in any medium, pro-vided the original author and source are credited.

safety and reliability requirements (Wiese & John, 2003; Zio,2009; N. Leveson, 2011). Hollnagel et al. (Hollnagel, Woods,& Leveson, 2007) recognize the fact that safety violation incomplex systems is not necessarily a consequence of com-ponents’ malfunction or a faulty design. Rather it could bea result of a network of ongoing interactions between all thecomponents and subsystems that introduce undesired behav-ior. For this reason, Baroth et al. (Baroth et al., 2001) recom-mends the Prognostic and Health Management System (PHMS)as a new technology to replaces the traditional build-in test(BIT) with intelligent prognostics tools to predict the occur-rence of unexpected faults. However, given the local safetyproperties of each component, it is not a trivial matter to inferthe safety and reliability of the whole system (N. G. Leve-son, 2009). Well-specified verification formalism and rea-soning tools are needed to study the emerging behavior andto perform exhaustive verification of safety properties. A se-ries of safety standards emerged in recent years that recognizethis issue and strongly recommended the use of formal veri-fication methods to control the complexity of safety-criticalsystems, i.e., the international standard on safety related sys-tems (IEC, 1998) and the SAE & EUROCAE standards in theavionic industry (ARP4761, 1996; ARP4754, 1996). How-ever, these standards do not specify how to implement formalapproaches throughout the design process.

Strategies for engineered system design emerge from a pro-cess of requirement decomposition and transforming require-ment models into the conceptual models (Blanchard, 2012;Buede, 2011). Requirement models, noted R, capture the de-sign problem being solved and conceptual models, noted S,represent the specific solution for the design problem. There-fore, the first step in specifying and formulating a complexsystem is to capture its requirements R and decompose it intothe requirements of its sub-systems and components, noted

1

ANNUAL CONFERENCE OF THE PROGNOSTICS AND HEALTH MANAGEMENT SOCIETY 2014

R = {R1, R2, ..., Rn}. The second step is to create a re-lationship between design requirements and the system thatconsists of heterogenous sub-systems, i.e., electrical, mechan-ical, and software ..., noted S = {S1, S2, ..., Sm}. However,this relationship between the set of design requirements andthe set of sub-systems and components is a non bijective re-lationship. A commonly used formalism to address this prob-lem is to focus on discrete event system dynamics. This for-mulation is extended (Hirtz, Stone, McAdams, Szykman, &Wood, 2002; Nagel, Stone, Hutcheson, McAdams, & Don-ndelinger, 2008; Kurtoglu & Campbell, 2009) by consideringother system features such as structures and functions, so thatthe predicate (S1 ∧ S2 ∧ ... ∧ Sm ⇒ Design’s Objective) ispreserved and satisfied throughout the design process. So theformulation can be summarized as below:

Si ⇒ {Rk}k∈[1..n] Si satisfies a sub-set of

requirements.{Sk}k∈[1..m] ⇒ Ri Ri satisfied by sub-set of

sub-systems or components.

The process of identifying and proving the correctness of theserelationships with regards to design safety requirements isthe objective of this paper. The remainder of this paper isstructured as follows: section 2 discusses the system orientedapproaches and their ability in modeling multi-domain com-plex engineered system and being exploitable for safety anal-ysis. Furthermore, formal verification methods and the def-inition of compositional reasoning and its commonly usedterminologies and operators are introduced as a complemen-tary technique to design requirement analysis. In section 3an overview of the step-by-step implementation of the com-positional reasoning algorithm on the components of the de-sign architectures is explained. Further, section 3 outlinesthe application of the proposed methodology in the analysisand verification of the safety properties of the quad-redundantElectro Mechanical Actuator (EMA) system design. The pa-per ends with conclusion.

2. RELATED WORK

Different standards, e.g., (IEEE1220, 2005; ISO-IEC15288,2002) have defined system design as a multidisciplinary col-laborative process that defines, develops, and verifies a sys-tem solution which satisfies different stakeholders’ expecta-tions and meets public safety and acceptability. Therefore,identification and analysis of the system requirements anddesigning a system according to the identified requirementsare the two inter-correlated and complementary processes ofsystem design. While these standards precisely specify theprocesses involved in the design of a safety critical systems,Lundteigen et al. (Lundteigen, Rausand, & Utne, 2009) agreethat they do not provide methods and tools for efficient design

of complex engineered systems. This highlights the need forappropriate methods and tools to support the integration ofsafety into the design solution.

2.1. SysML for Complex Engineered Systems

Traditional methods and tools used by system engineeringare mostly based on a formalism that capture a variety ofsystem features, i.e., requirements engineering, behavioral,functional, and structural modeling, etc. Those with particu-lar focus on requirements engineering are the Unified Model-ing Language (UML) (OMG, 2007) to support various aspectof system modeling, Rational Doors (IBM, 2010) to expressthe requirements, and Reqtify (GeenSys, 2008) to trace therequirements through design and implementation. UML isdeveloped by the Object Management Group (OMG) in co-operation with the International Council of Systems Engi-neering (INCOSE). UML is an Object-oriented modeling lan-guage that allows hierarchical organization of system compo-nent models, which in turn results in easier reuse and main-tenance of the system model. However, UML was originallydeveloped for software engineers and its primary applicationis software-oriented; therefore it does not meet all the systemengineer’s expectations. For example, UML does not providea notion to represent continuous flows exchanged within thesystem, i.e., Energy, Material, and Signal (EMS). The analy-sis of EMS flows are crucial in system design safety verifica-tion for identifying the failure propagation path and identify-ing the common failure modes. For this reason, the SysMLprofile was developed borrowing a subset of the UML lan-guage to meet the requirements of a general purposed lan-guage for system engineering.

SysML is an efficient modeling language for constructing mod-els of complex, multidisciplinary, and large-scale systems.SysML enables the designers of a complex system to modelthe system requirements, structures, behaviors, and paramet-ric values for a more rigorous description of a system underconsideration. SysML focuses on the global features of ar-chitectural views, whereas other modeling languages such ashe Architecture Analysis and Design language (AADL) ad-dresses the more detailed platform-oriented and physical as-pects of such systems. Nevertheless, the wide variety of no-tations provided by SysML lacks formal and detailed seman-tics required for requirements verification. The goal of thispaper is to bridge the gap between semi-formal approaches,e.g., SysML and formal verification methods, e.g., model-checkers to provide the system designers an integrated methodto manage and verify the safety properties of complex engi-neered systems.

2.2. Model Checking and Formal Verification

Model checking is one of the approaches to formal verifica-tion of finite state hardware and software systems (Henzinger,

2

ANNUAL CONFERENCE OF THE PROGNOSTICS AND HEALTH MANAGEMENT SOCIETY 2014

Mechanical Linkage Which can be disengaged

LoadSensor

2

LoadSensor

1

Diagnostics

Controller

Position Sensor 1

Position Sensor 2

Position Sensor 3

Position Sensor 4

LoadSensor

3

LoadSensor

4

Position Response

Position Response

Driv

e C

urre

nts

Posi

tion

Com

man

d

Load

Actuator 1

Actuator 2

Actuator 3

Actuator 4

Figure 1. Quad-Redundant EMA Scheme.

Ho, & Wong-Toi, 1997; Henzinger, Nicollin, Sifakis, & Yovine,1994). In this approach, a design will be modeled as a statetransition system with a finite number of states and a set oftransitions. The design model is in essence a finite-state ma-chine, and the fact that it is finite makes it possible to ex-ecute an exhaustive state-space exploration to prove that thedesign satisfies its requirements. Since there is an exponentialrelationship between the number of states in the model andnumber of components that make up the system, the compo-sitional reasoning approach is used to handle the large state-space problem. The compositional reasoning technique de-composes the safety properties of the system into local prop-erties of its components. These local properties are subse-quently verified for each component. However, Barragan etal. (Barragan, Roth, Faure, et al., 2006) emphasizes the dif-ficulty of transforming the global system requirements intomulti-level sub-system and component’s local safety proper-ties that need to be verified by a model checker for the designof large scale complex engineered systems. More specifi-cally, the decomposition of complex engineered systems intomulti-domain sub-systems involving electrical, mechanical,and software components makes the refinement and traceabil-ity of the global safety properties very difficult. Therefore, asystematic approach is required to acquire abstract require-ments along with safety properties, and map them to sys-tem components (Evrot, Petin, & Mery, 2006). Followingthe work of many researchers, it is concluded that the earlystages of system design are the most critical in ensuring thatthe designed system satisfies its safety requirements (Tumer,Stone, & Bell, 2003; Stone, Tumer, & Stock, 2005; Kurtoglu& Tumer, 2008; Tumer & Smidts, 2011), this paper aims ataddressing this challenge using the system-oriented SysML-based modeling approach combined with formal verification

technique.

2.3. Case Study

As depicted in Fig. 1, a quad-redundant Electro-MechanicalActuator (EMA) (Balaban et al., 2009) for the Flight Con-trol Surfaces (FCS) of an aircraft, developed in a programsponsored by NASA, is used to illustrate and validate the pro-posed approach. The positions of the surfaces, A, C, and D,in Fig. 2, are usually controlled using a quad-redundant actu-ation system. The FCS actuation system responds to positioncommands sent from the flight crew, B in Fig. 2, to move theaircraft FCS to the command positions.

Figure 2. Basic Aircraft Control Surfaces.

The EMAs are arranged in a parallel fashion; therefore, eachactuator is required to tolerate a fraction of the overall load.To meet safety requirements, each actuator is required to takeon the full expected load from the FCS in the extreme casewhere all three of the four actuators become non-operational.In addition, the design should also consider other issues suchas the possibility of the actuators becoming jammed. If oneactuator becomes jammed in this parallel arrangement, it willprevent the other ones from moving. Therefore, a mechanism

3

ANNUAL CONFERENCE OF THE PROGNOSTICS AND HEALTH MANAGEMENT SOCIETY 2014

Figure 3. Requirements Decomposition.

Figure 4. Requirements Mapping.

to disengage faulty actuators from the rest of the system isrequired to avoid the faulty actuators from becoming dead-weights. Once an EMA is disengaged from the system it can-not be re-engaged automatically. It is envisioned that this willhappen on the ground, once the aircraft has landed.

In order for the design to be reliable, additional redundanciesin other components of the system, such as load and positionsensors are required. Thus, a fully quad-redundant scheme isenvisioned, as depicted in Fig. 1. As illustrated, the designfeatures redundancy in the EMAs and the sensor feedbacksignals. The position command is fed to the control loop,while the load from the FCS is shared by the EMAs. Theindividual load, current, and position response signals fromeach EMA are used to perform separate diagnostics on eachEMA. Therefore, faults are isolated to the individual actua-tors, which facilitates adaptive on-the-fly decisions on discon-necting degraded EMAs from the load. A dedicated diagnos-tics block performs actuator health assessments, and makesdecisions on whether or not to disengage any faulty actuatorsfrom the flight control surface. The disengagement is madepossible by mechanical linkages, which can be disconnectedfrom the output shaft coupling.

3. METHODOLOGY

Design requirements are the specification of safety constraintsinitially defined in the design. Requirements are modeled atdifferent levels of abstractions. For example, a higher level ofabstraction is used when expressing the global system prop-erties and a low level of abstraction is used when expressingthe required features for each system component, i.e. the bar-riers and materials to be used. Managing this set of specifica-tions is based on iterative decomposition and substitution ofthe abstract requirements by the requirements that are moreconcrete.

3.1. Safety Requirements Modeling Using SysML

A SysML requirement diagram enables the transformation oftext-based requirements into the graphical modeling of the re-quirements which can be related to other modeling elements.Fig. 3 depicts the decomposition of a single abstract require-ment into several more explicit ones. A study by Blaise etal. (Blaise, Lhoste, & Ciccotelli, 2003) confirms the effective-ness of such diagrams to facilitate the structuring and man-agement of requirements that are traditionally expressed innatural languages.

The next step in the requirement analysis phase consists ofmapping the requirements to the corresponding system com-ponents or functions. System components are modeled as

4

ANNUAL CONFERENCE OF THE PROGNOSTICS AND HEALTH MANAGEMENT SOCIETY 2014

part of the structural design of a system. The structural de-sign model corresponds to the system hierarchy in terms ofsystems and subsystems, which are modeled using the BlockDefinition diagram (BDD). SysML blocks are the best mod-eling elements to model multi-disciplinary systems and areespecially effective during system specification and design.They are effective because blocks are not only able to modellogical or physical decomposition of a system, they also en-able designers to define specification of software, hardware,or human elements.

Fig. 4 illustrates how a single requirement can be satisfiedby a set of sub-systems and components. The requirementdiagram is connected to the structure diagram by a cross con-necting element known as satisfy. A requirement can be sat-isfied by a component or subsystem. Furthermore, the de-tailed modeling of sub-systems and components are possiblethrough the use of Internal Block Diagram (IBD). In addi-tion, blocks are a reusable form of description that can be ap-plied throughout the construction of system modeling if nec-essary. Another advantage of using blocks during the designprocess is their ability to include both structural and behav-ioral features, such as properties and operations that representthe state of the system and behavior that the system may dis-play.

Including properties as part of the requirement modeling isspecifically important when verifying safety requirements. AsMadni. (Madni, 2007) demonstrated, safety is a changing char-acteristic of complex systems that, once integrated into thedesign, is not preserved unless enforced throughout systemoperation. Hollnagel et al. (Hollnagel et al., 2007) also con-firms that safety is a feature that results from what a systemdoes, rather than a characteristic that the system has. There-fore, the proof of safety is provided by the absence of fail-ures and accidents. For this reason, ”safety-proofing” a sys-tem design is never absolute or complete. Consequently, theproposed approach does not guarantee safe system operation,instead provides formal proof that certain very specific be-havioral parameters will be achieved. It is for this reason thatin this paper safety is viewed as a system property.

A complete proof of safety is possible through a formal def-inition of different properties that are linked to each high-level abstract and low-level detailed requirements. Fig. 5 rep-resents how a requirement, property, block, and behavioralmodel are connected to one another. For example, allocateas a cross connecting principle in SysML is used to connect abehavior to a component in a structure diagram.

In the proposed approach, individual components’ behaviorin the system are modeled as Labeled Transition Systems(LTSs), LTSs basically represent a finite state system. Theproperties of the LTSs make it ideal for expressing the be-havioral model of system components. The LTS model is ex-pressed graphically, or by its alphabet, transition relation, and

Figure 5. Requirements Traceability.

states including single initial state. The LTS of the system isconstructed from the LTS of its subsystems, and is verifiedagainst safety properties of the design requirements (Fig. 5).

3.2. Safety Requirements Verification

A model-based verification approach is proposed based on thebehavioral models of design components, where behavioralspecifications are associated with each component. Thesespecifications are then used to analyze the overall design ar-chitecture. In this approach, a design will be modeled as astate transition system with a finite number of states and aset of transitions. The design model is in essence a finite-state machine, and the fact that it is finite makes it possibleto execute an exhaustive state-space exploration to prove thatthe design satisfies its requirements. Since there is an ex-ponential relationship between the number of states in themodel and number of components that make up the system,the compositional reasoning approach is used to handle thelarge state-space problem. The compositional reasoning tech-nique decomposes the safety properties of the system into lo-cal properties of its components. These local properties aresubsequently verified for each component. The combinationof these simpler and more specific verifications guaranteesthe satisfaction of the global safety of the overall system ar-chitecture design. It is important to note that, the safety re-quirements of the components are satisfied only when explicitassumptions are made on their environment. Therefore anassume-guarantee (Cobleigh, Giannakopoulou, & Pasareanu,2003; Giannakopoulou, Pasareanu, & Barringer, 2005; Nam& Alur, 2006; Chaki, Clarke, Sinha, & Thati, 2005) approachis utilized to model each component with regards to its in-teraction with its environment, i.e, the rest of the system andoutside world.

Since, the LTSs are based on graphical modeling, they caneasily become unmanageable for large complex systems. There-fore, an algebraic notation known as Finite State Process (FSP)(Rodrigues, 2000) is used to define the behavior of processesin a design. FSP is a specification language as opposed to amodeling language, with semantics defined in terms of LTSs.Every FSP model has a corresponding LTS description andvice versa. An example FSP and LTS model of the Elec-tro Mechanical Actuator (EMA) unit of the quad-redundant

5

ANNUAL CONFERENCE OF THE PROGNOSTICS AND HEALTH MANAGEMENT SOCIETY 2014

EMA of Fig. 1 is provided in Table 1 and Fig. 6 respectively.

Table 1. FSP Description of EMA

1 : EMA = (recLoad→ ApplyLoad→ (allLoadsCompleted→ EMA2 : | jam→ block→ Jammed)),3 : Jammed = (recLoad→ Jammed4 : | disengage→ unblock→ Disengaged),5 : Disengaged = (recLoad, allLoadsCompleted, timeout → Disen-gaged).

Figure 6. LTS Model of the EMA Subsystem.

In the defined model, a EMA receives the load commandfrom the controller and carries out the operation. The Elec-tro Mechanical Actuator is modeled in Table 6 with Jammedand Disengaged as part of its definition. If during the timeof maintaining the specified torque or load the EMA func-tions according to specification, the signal ”all loads are com-pleted” is sent to the controller. Otherwise, the EMA is con-sidered non-operational or jammed. In the jammmed mode,the EMA is incapable of maintaining the required load andprevents the rest of the EMAs from moving. Therefore, itneeds to be disengaged from the system.

After system modeling, the actual analysis of the models iscarried out utilizing the Assume Guarantee Reasoning (AGR)verification technique. In the assume-guarantee methodol-ogy, a formula contains a triple 〈A〉M 〈P 〉, where M is de-fined as a component, P is a safety property, and A is anassumption or constraint on M ’s environment. The formulais proven correct if whenever M is a component within a sys-tem satisfying A, then the system also guarantees P .

The simplest assume guarantee rule for checking a safetyproperty P on a system with two components M1 and M2

can be defined as following (Henzinger, Qadeer, & Rajamani,1998; Chaki et al., 2005):Rule ASYM

1 : 〈A〉M1 〈P 〉2 : 〈true〉M2 〈A〉

〈true〉M1 ‖M2 〈P 〉

The first rule is checked to ensure that the generated assump-tion restricts the environment of component M1 to satisfyP . For example, the assumption A is that there is no Elec-tromagnetic Interference (EMI) or Radio Frequency Interfer-ence (RFI) in the environment where component M1 oper-ates; hence, P is satisfied. The second rule ensures that com-ponent M2 respects the generated assumption. For example,

M2 will not generate any EMI and RFI while operating. Ifboth rules hold then it is concluded that the composition ofboth components also satisfies property P (〈true〉M1 ‖M2 〈P 〉).

Model Checking

Learning Algorithm 1. AiM1 P

2. trueM2 Ai

Ai

True

False

Failure Propagation Path – Strengthen the Assumption

P is satisfied in  ||

Failure?

False

True

P is violated in  ||YesNo

Failure Propagation Path – Weaken the Assumption

Figure 7. An Overview of the Algorithm that Generates As-sumptions.

In this research, the algorithm in (Giannakopoulou, Pasare-anu, & Cobleigh, 2004) is used to automatically generateassume-guarantee reasoning at the component, subsystem, andsystem level. The objective is to automatically generate as-sumptions for components and their compositions, so that theassume-guarantee rule is derived in an incremental manner.The framework of Figure 7 depicts the steps involved in per-forming automated assume-guarantee reasoning while gener-ating the assumptions. If rule (1) is violated, it means that theassumption is too weak, so it does not prevent M1 from reach-ing its failure state. Based on the generated failure propaga-tion path, the algorithm learns a new assumption with morerestriction on the environment which makes the assumptionstronger than the previous one. The iteration continues untilthe first rule of 〈A〉M1 〈P 〉 is addressed. The next step is tocheck the second rule 〈true〉M2 〈A〉. If the rule still holds,then it is concluded that 〈true〉M1 ‖M2 〈P 〉. If the checkfails, the algorithm performs analysis on the returned failurepropagate path to determine the reason for the failure. If theanalysis reveals that A is not the weakest assumption, i.e.,elimination of both EMI and RFI is not necessary and onlythe elimination of EMI suffices to satisfy P, then the learningalgorithm will generate a new assumption. If the rules are notsatisfied with the generated assumptions, it is concluded that〈true〉M1 ‖M2 〈P 〉 violates the property P.

4. APPLICATION ON THE CASE STUDY

In the case study of Fig. 2, the Flight Control Surface (FCS)must meet rigorous safety and availability requirements be-

6

ANNUAL CONFERENCE OF THE PROGNOSTICS AND HEALTH MANAGEMENT SOCIETY 2014

Table 2. Requirement Mapping.

Requirement Component(s)Safety Requirement 1 quad-redundant EMAsSafety Requirement 1.2 quad-redundant EMAsSafety Requirement 1.2.1 DiagnosticsSafety Requirement 1.2.2 EMAsSafety Requirement 1.2.3 Controller, Position Sensor, and Shaft

fore it can be certified. The FCS has two types of dependabil-ity requirements:

• Integrity: the FCSs must address safety issues such asloss-of control resulting from aircraft system failures, orenvironment disturbances.

• Availability: the system must have a high level of avail-ability.

Therefore, it is critical for the FCS to continue operation with-out degradation following a single failure, and to fail safeor fail operative in the event of a related subsequent failure.The movement of the FCS is controlled by a quad-redundantEMAs. A block diagram of the quad-redundant EMAs is de-picted in Fig. 8. As seen from the figure, the model consistsof an EMA block which is an hierarchical representation offour independent EMAs. Each EMA is modeled via the In-ternal Block Definition diagram (IBD). The individual EMAlegs receive the common position command, but act indepen-dently of each other and share the flight control surface loadamong themselves.

Fig. 9 depicts a set of high-level requirements. To facilitatethe verification process, each level of requirements are asso-ciated with a formal FSP using property stereotype in SysML.Therefore, satisfying a property P1 is the same as satisfyingproperties P1.1, P1.2, and P1.3.

The next phase consists of identifying the design architecture(Fig. 8), including sub-systems and components to map eachrequirement to a traceable source. As depicted in Fig. 4, re-quirements mapping are made possible by using the satisfyrelationship to link a single or set of blocks to one or morerequirements. The requirements mapping of quad-redundantEMAs is presented in Table. 2.In order to transform the requirements and the design archi-tecture presented in Fig. 8 into a finite model, we use FSP. Asan example, consider the following FSP model of a controllersubsystem of the quad-redundant EMAs: The controller getsthe load command from the command unit and actively reg-ulates the current to each EMA at every time step. The dif-ference between the external load and the total actuator loadresponse is used to accelerate or decelerate the output shaft. Ifthe controller perceives that the output shaft position responseis falling behind the commanded position, it will increase thecurrent flow to the EMAs. As depicted in Table 3, in the FSP

description of the controller, a repetitive behavior is definedusing a recursion. In this context, recursion is recognized as abehavior of a process that is defined in terms of itself, in orderto express repetition.

Table 3. FSP Description of Controller

1 : Controller = (getLoad[l:L]→ Controller[l]),2 : Controller[t:L] = (timeout→ Controller3 : | sendLoad→allLoadsCompleted→getShaftPosition[x:Positions]4 : →if (x ≥ t) then (missionComplete→Controller)5 : else Controller[t]).

The partial LTS model of the controller is depicted in Fig. 10.The controller performs action <getLoad[l..4]>, and thenbehaves as described by <Controller[l]>. Controller[l] isa process whose behavior offers a choice, expressed by thechoice operator ”|”. Controller[l] initially engages in either<timeout> or <SendLoad>. The action <timeout> isperformed when all actuators fail, otherwise <SendLoad>is utilized. Subsequently, after sending the required load toeach EMA, feedback signals are sent to inform the controllerof completion of tasks by labeling the action with <all LoadsCompleted>. This results in the controller to perform the ac-tion <get Shaft Position>. At this stage, the controller com-pares the new position with the required shaft position, if theshaft has reached the required position then the <mission iscompleted>. Otherwise, the behavior is repeated until theshaft reaches the required position.

getLoad[4] sendLoad

timeout

allLoadsCompleted getShaftPosition[4]

missionCompleted

getShaftPosition[0..3]

Figure 10. LTS Model of the Controller Subsystem.

After modeling the behavior of each component and sub-system,the design is described by a composition expression. In thecontext of system design engineering, the term compositionis similar to the coupled model. The coupled model defineshow to couple several component models together to form anew model, similarly, composition groups together individualstate machines. Such an expression is called a parallel com-position, denoted by ”‖”. The ”‖” is a binary operator thataccepts two LTSs as an input argument. In the joint behaviorof the two LTSs, the transition can be performed by any ofthe LTS if the action that labels the transition is not sharedwith the other LTS. Shared actions have to be performed con-currently. Table 4 depicts the FSP of the joint behavior ofEMA and controller. The composed LTS model of the twosubsystems consists of 161 states and 62 transitions. Theshared action between the two models is the <sendLoad>action from the controller and the <recLoad> action from

7

ANNUAL CONFERENCE OF THE PROGNOSTICS AND HEALTH MANAGEMENT SOCIETY 2014

Figure 8. Structural Model of the Quad-redundant EMAs.

Figure 9. Quad-redundant EMAs High-Level Requirements.

the EMA, therefore, these two are required to be performedsynchronously. In order to change action labels of an LTS, therelabeling operator ”/” is used, e.g., { recLoad / sendLoad }.

Table 5 presents some of the state transitions (or sequenceof actions) produced by the composed model. Two possibleexecutions under the EMA’s nominal and faulty conditionsare considered. In nominal mode, the EMA receives a re-quest from a controller to provide two unit loads. At each

8

ANNUAL CONFERENCE OF THE PROGNOSTICS AND HEALTH MANAGEMENT SOCIETY 2014

Table 4. Parallel Composition of EMA (Table 1) and Con-troller (Table 3)

1 : ‖ Leg = ( EMA ‖ Controller ) / { recLoad / sendLoad }.

time step, EMA performs one unit load and repeats until theoutput shaft reaches the required position that is when the<missionComplete> actions is performed. In the failedmode, initial actions are the same as in nominal mode until anEMA jams. The jammed EMA blocks the rest of the systemfrom moving until it is disengaged. The process is followedby the <Unblock> action which unblocks the shaft allowingthe rest of the system to be freed. By this time, the EMA hasprovided one unit load before being disconnected from therest of the system. Since, the <ShaftPositionIS> showsthe current position of the shaft being one instead of two, theEMA is required to perform one more unit of load. However,the disengaged EMA is incapable of doing so resulting in a<timeout>. The <timeout> occurs only when there are noEMAs to perform the required load.

Table 5. Leg Subsystem: Two Possible Transitions

EMA: Nominal Mode EMA: Failure Mode1 : ctrl getLoad.2 1 : ctrl getLoad.22 : EMA recLoad 2 : EMA recLoad3 : EMA performLoad 3 : EMA performLoad4 : LoadsCompleted 3 : EMA jam5 : ShaftPositionIs.1 4 : Shaft block6 : EMA recLoad 5 : EMA Disengage7 : EMA performLoad 6 : Shaft Unblock8 : LoadsCompleted 7 : LoadsCompleted9 : getShaftPosition.2 8 : ShaftPositionIs.110 : EMA performLoad 9 : timeout11 : missionComplete –

So far, we provided the basis for decomposing and modelingthe system based on the modular description of the designcomponents and subsystems. In the next phase, the processof expressing the desired safety properties in terms of a statemachine or LTS is described. The advantage is that both thedesign and its requirements are modeled in a syntacticallyuniform fashion. Therefore, the design can be compared tothe requirements to determine whether its behavior conformsto that of the specifications. In the context of this work, theproperties of a system are modeled as safety a FPS. A safetyFPS contains no failure states. In modeling and reasoningabout complex systems, it is more efficient to define safetyproperties by directly declaring the desired behavior of a sys-tem instead of stating the characteristics of a faulty behavior.In a FSP, the definition of properties is distinguished fromthose of subsystem and component behaviors with the key-word property.

Based on the requirement decomposition model of Fig. 9, thecomposition model of the properties P1.1, P1.2, and P1.3 ispresented by the following generic (or parameterized) safetyproperty with the following constants and a range definitionsis used:

• const N =4 \\ number of faulty EMAs 1

• const M =4 \\ number of EMAs

• range EMAs = 1..M \\ EMA identities

In order to prevent the system from reaching the catastrophicevent of <timeout>, it is essential to complete the missionand provide the required loads based on the command signal.The property of Table 6, maintains a count of faulty EMAswith the variable f . To model the fact that every commandsignal must be followed by a <missioncomplete>, propertyP1, the processes in lines 3 and 8 are required to constrainthe number of faulty EMAs (f ) to a number defined by theparameter of the property (e.g. N=4).

Table 6. FSP Model of Safety Property

1 : property2 : Fault Tolerance(N=4) = Jammed[0],3 : Jammed[f : 0..M] =(when(f≤N)commandLoad[L]→CompleteMission[f]4 : |when (f>N) commandLoad[L]→ Jammed[f]5 : |d[EMAs].jam→ Jammed[f+1]6 : |missionComplete→ Jammed[f]),7 : CompleteMission[f:0..M] = (missionComplete→ Jammed[f]8 : |when (f<N ) d[EMAs].jam→ CompleteMission[f+1]9 : |when (f==N) d[EMAs].jam→ Jammed[f+1]).

If the above property is predefined with N = 2, permittingonly two out of four EMAs to fail during the system opera-tion, the verification algorithm of Fig. 7 verifies that the safetyproperty is satisfied.

However, when the property is instantiated allowing four EMAsto fail, the safety analysis verifies that the property is violatedand a failure propagation path is produced. Therefore, thegeneric safety property modeled in Table 6 verifies that thesystem never reaches the failure condition of total loss if andonly if N ≤ M-1 where N is the number of faulty EMAs andM is the total number of EMAs.

From the result of case study: the characterization of the sys-tem architecture by its subsystems and components improvesrequirements specification, tracking, and modeling. In addi-tion, the FSP annotation of the failure behavior of each ofcomponent, and the system level safety analysis based oncomponents’ interaction lead to achieving a manageable veri-fication procedure. As the compositional reasoning approachsignificantly reduces the number states to be explored, ex-haustive checking of the entire state space is made feasiblewithout the need for a exhaustive search. This is especiallyimportant where the exhaustive simulation is too expensiveand non-exhaustive simulation can miss the critical safety vi-olation.

5. CONCLUSION

There is a growing demand for formal methods and tools thatfacilitate the specification and verification of complex engi-

1by default is set to 4 but it can be redefined during the instantiation process.

9

ANNUAL CONFERENCE OF THE PROGNOSTICS AND HEALTH MANAGEMENT SOCIETY 2014

neered systems design. Also, safety standards for the de-sign of safety-critical systems strongly recommend the use offormal verification approach as part of the certification pro-cess. However, these standards do not specify how formalapproaches can be implemented. Alternatively, system engi-neering semi-formal techniques for elicitation and structuringthe requirements of complex engineered systems are essentialpart of the design for electing the conceptual design that sat-isfies the identified requirements.

In this paper, we have proposed a system modeling and verifi-cation approach that combines these apparently contradictoryviews. The semi-formal SysML techniques based on require-ment and block diagrams combined with formal verificationmethods based on the assume-guarantee reasoning are usedto prove that the behavior of sub-systems and componentssatisfies the design requirements. The proposed approach isbased on the mapping between the hierarchical decomposi-tion model of the requirements and properties to be satisfied,functions and behaviors to be realized, and sub-systems andcomponents to be implemented.

The future work will continue in verifying more sophisti-cated system, while taking into consideration safety proper-ties that are formulated using the temporal operators, i.e., un-til, before, or after. More complex temporal properties willbe tested. In the case of temporal properties, satisfying thesystem property is not always equivalent to satisfying a localcomposition of sub-properties. The modified verification al-gorithm will use linear temporal logic (LTL) as a specificationformalism.

REFERENCES

ARP4754, S. (1996). Certification considerations for highly-integrated or complex aircraft systems. Society of Au-tomotive Engineers Inc.

ARP4761, S. (1996). Guidelines and methods for conductingthe safety assessment process on civil airborne systemsand equipment. SAE International, December.

Balaban, E., Saxena, A., Goebel, K., Byington, C., Watson,M., Bharadwaj, S., . . . Amin, S. (2009). Experimen-tal Data Collection And Modeling For Nominal AndFault Conditions On Electro-mechanical Actuators. InAnnual conference of the prognostics and health man-agement society (pp. 1–15).

Baroth, E., Zakrajsek, J., Powers, W., Fox, J., Prosser, B., Pal-lix, J., & Schweikard, K. (2001). Ivhm (Integrated Ve-hicle Health Management) techniques for future spacevehicles. In 37th joint propulsion conference.

Barragan, I. S., Roth, M., Faure, J.-M., et al. (2006). Obtain-ing temporal and timed properties of logic controllersfrom fault tree analysis. In Proceedings of the 12th ifacsymposium on information control problems in manu-facturing, incom 2006, saint-etienne, france.

Blaise, J.-C., Lhoste, P., & Ciccotelli, J. (2003). Formali-sation of normative knowledge for safe design. SafetyScience, 41(2), 241–261.

Blanchard, B. S. (2012). System engineering management(Vol. 64). Wiley. com.

Buede, D. M. (2011). The engineering design of systems:Models and methods (Vol. 55). John Wiley & Sons.

Chaki, S., Clarke, E., Sinha, N., & Thati, P. (2005). Au-tomated Assume-guarantee Reasoning for SimulationConformance. In Computer aided verification (pp.241–246).

Cobleigh, J. M., Giannakopoulou, D., & Pasareanu, C. S.(2003). Learning Assumptions For Compositional Ver-ification. In Tools and algorithms for the constructionand analysis of systems (pp. 331–346). Springer.

Evrot, D., Petin, J.-F., & Mery, D. (2006). Formal spec-ification of safe manufacturing machines using the bmethod: Application to a mechanical. In Informationcontrol problems in manufacturing (Vol. 12, pp. 281–286).

GeenSys. (2008). Reqtify. www.geensys.com.Giannakopoulou, D., Pasareanu, C. S., & Barringer, H.

(2005). Component Verification With AutomaticallyGenerated Assumptions. Automated Software Engi-neering, 12(3), 297–320.

Giannakopoulou, D., Pasareanu, C. S., & Cobleigh, J. M.(2004). Assume-guarantee verification of source codewith design-level assumptions. In Proceedings of the26th international conference on software engineering(pp. 211–220).

Henzinger, T. A., Ho, P., & Wong-Toi, H. (1997). Hytech:A Model Checker for Hybrid Systems. Electronics Re-search Laboratory, College of Engineering, Universityof California..

Henzinger, T. A., Nicollin, X., Sifakis, J., & Yovine, S.(1994). Symbolic Model Checking for Real-time Sys-tems. Information and Computation, 111(2), 193-244.

Henzinger, T. A., Qadeer, S., & Rajamani, S. K. (1998). Youassume, we guarantee: Methodology and case studies.In Computer aided verification (pp. 440–451).

Hirtz, J., Stone, R. B., McAdams, D. A., Szykman, S., &Wood, K. L. (2002). A Functional Basis For Engi-neering Design: Reconciling And Evolving PreviousEfforts. Research in engineering Design, 13(2), 65–82.

Hollnagel, E., Woods, D. D., & Leveson, N. (2007). Re-silience engineering: Concepts and precepts. AshgatePublishing, Ltd.

IBM. (2010). Rational doors. Available from: http://www-01.ibm.com/software/awdtools/doors.

IEC. (1998). 61508 functional safety of electri-cal/electronic/programmable electronic safety-relatedsystems. International electrotechnical commission.

IEEE1220. (2005). IEEE standard for application and man-

10

ANNUAL CONFERENCE OF THE PROGNOSTICS AND HEALTH MANAGEMENT SOCIETY 2014

agement of the systems engineering process. IEEE NewYork, NY, USA.

ISO-IEC15288. (2002). Systems engineering system life cy-cle processes. International Standardization Organiza-tion.

Kurtoglu, T., & Campbell, M. I. (2009). Automated Synthe-sis Of Electromechanical Design Configurations FromEmpirical Analysis Of Function To Form Mapping.Journal of Engineering Design, 20(1), 83–104.

Kurtoglu, T., & Tumer, I. Y. (2008). A graph-based fault iden-tification and propagation framework for functional de-sign of complex systems. Journal of Mechanical De-sign, 130(5), 051401.

Leveson, N. (2011). Engineering a safer world: Systemsthinking applied to safety. MIT Press.

Leveson, N. G. (2009). The need for new paradigms in safetyengineering. In Safety-critical systems: Problems, pro-cess and practice (pp. 3–20). Springer.

Lundteigen, M. A., Rausand, M., & Utne, I. B. (2009). In-tegrating rams engineering and management with thesafety life cycle of iec 61508. Reliability Engineering& System Safety, 94(12), 1894–1903.

Madni, A. (2007). Designing for resilience. ISTI LectureNotes on Advanced Topics in Systems Engineering.

Nagel, R. L., Stone, R. B., Hutcheson, R. S., McAdams,D. A., & Donndelinger, J. A. (2008). Function De-sign Framework (FDF): Integrated Process And Func-tion Modeling For Complex Systems. In Asme 2008international design engineering technical conferences& computers and information in engineering confer-ence (idetc/cie 2008) (pp. 273–286).

Nam, W., & Alur, R. (2006). Learning-based SymbolicAssume-guarantee Reasoning With Automatic decom-position. In Automated technology for verification andanalysis (pp. 170–185). Springer.

OMG, O. (2007). Unified modeling language (omg uml).Superstructure.

Rodrigues, R. W. (2000). Formalising UML Activity Dia-grams Using Finite State Processes. In Proc. of the 3rdintl. conf. on the unified modeling language, york, uk.

Stone, R. B., Tumer, I. Y., & Stock, M. E. (2005). Link-ing product functionality to historic failures to improvefailure analysis in design. Research in Engineering De-sign, 16(1-2), 96–108.

Tumer, I. Y., & Smidts, C. S. (2011). Integrated design-stagefailure analysis of software-driven hardware systems.Computers, IEEE Transactions on, 60(8), 1072–1084.

Tumer, I. Y., Stone, R. B., & Bell, D. G. (2003). Require-ments for a failure mode taxonomy for use in concep-tual design. In Proceedings of the international confer-ence on engineering design, iced (Vol. 3).

Wiese, P. R., & John, P. (2003). Engineering design in themulti-discipline era: A systems approach. Wiley.

Zio, E. (2009). Reliability engineering: Old problems

and new challenges. Reliability Engineering & SystemSafety, 94(2), 125–141.

BIOGRAPHIES

Hoda Mehrpouyan Dr. Hoda Mehrpouyan is a Professor inTSYS School of Computer Science at Columbus State Uni-versity. Her research focuses on model-based systems en-gineering, resilience and safety analysis, information tech-nology, simulation and verification to support the design ofcomplex systems. She received her Ph.D. from Oregon StateUniversity in 2014 and holds a M.S. degree in Software En-gineering from Linkoping University in 2011. Prior to retur-nung to academia, She spent 7 years in industry as a systemdelivery consultant and programmer analyst.

Irem Tumer Dr. Irem Y. Tumer is a Professor in Mechan-ical, Industrial, and Manufacturing Engineering at OregonState University, where she leads the Complex EngineeredSystem Design Laboratory, and Associate Dean for Researchand Economic Development for the College of Engineering atOSU. Her research focuses on the overall problem of design-ing highly complex and integrated engineering systems withreduced risk of failures, and developing formal methodolo-gies and approaches for complex system design and analysis.Since moving to Oregon State University in 2006, her fundinghas largely been through NSF, AFOSR, DARPA, and NASA.Prior to accepting a faculty position at OSU, Dr. Tumer ledthe Complex Systems Design and Engineering group in theIntelligent Systems Division at NASA Ames Research Cen-ter, where she worked from 1998 through 2006 as ResearchScientist, Group Lead, and Program Manager. Dr. Tumerhas been Conference Chair for ASME Design for Manufac-turing and the Lifecycle conference in 2000, Program Chairfor IEEE Reliability Society?s Prognostics and Health Man-agement Conference in 2008, and Program Chair (2011) andConference Chair (2012) for ASME?s International DesignTheory and Methodology Conference; and is current Asso-ciate Editor for ASME Journal of Mechanical Design and theInternational Journal of Prognostics and Health Management,and guest editor for AEIDAM journal. She received her Ph.D.in Mechanical Engineering from The University of Texas atAustin in 1998.

Christopher Hoyle Dr. Hoyle’s research focuses on decisionmaking in engineering design, with emphasis on the earlydesign phase when uncertainty is high and the potential de-sign space is large. More specifically, he works in the areasof decision-based design (linking consumer preferences andenterprise-level objectives with the engineering design pro-cess), uncertainty quantification and management, and com-plex system design. Areas of technical expertise include un-certainty propagation methodologies, Bayesian statistics andmodeling, stochastic consumer choice modeling, optimiza-tion, and design automation. Prior to returning to academe,Dr. Hoyle spent 15 years in industry as a project engineer

11

ANNUAL CONFERENCE OF THE PROGNOSTICS AND HEALTH MANAGEMENT SOCIETY 2014

and engineering manager, concerned primarily with electron-ics packaging and with managing the trade-offs between per-formance, manufacturability, and cost.

Dimitra Giannakopoulou Dr. Giannakopoulou is a ResearchComputer Scientist with the NASA Ames Research Center,and a member of the Robust Software Engineering Group.Her work is concerned with applying modular and composi-tional formal verification techniques to autonomous systemsand architectures. Before joining Ames, she was a ResearchAssociate with the Department of Computing, Imperial Col-lege, University of London, UK, working on methods forthe specification and automatic verification of distributed sys-tems. She has graduated from the Dept of Computer Engi-neering and Informatics, University of Patras, Greece. Shehold an MSc with distinction from Imperial College, in ”Foun-

dations of Advanced Information Technology”, and since March1999, a PhD degree from Imperial College, University ofLondon.

Guillaume Brat Dr. Brat is employed by Carnegie-MellonUniversity and he conduct research in software verificationwithin the Robust Software Engineering group in the Intel-ligent Systems Division at NASA Ames. He received anM.Sc. and Ph.D. from the ECE Department at The Univer-sity of Texas at Austin. He is Principal Systems Scientist atCMU Silicon Valley serving as an IPA at NASA Ames Re-search Center. He has been the Assistant Area lead for RobustSoftware Engineering since October 2009. The group con-ducts research on new verification and validation techniques,mostly based on formal methods.

12