HAL Id: hal-00794329https://hal.inria.fr/hal-00794329

Submitted on 25 Feb 2013

HAL is a multi-disciplinary open accessarchive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come fromteaching and research institutions in France orabroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, estdestinée au dépôt et à la diffusion de documentsscientifiques de niveau recherche, publiés ou non,émanant des établissements d’enseignement et derecherche français ou étrangers, des laboratoirespublics ou privés.

Design-driven Development of Dependable Applications:A Case Study in Avionics

Quentin Enard, Stéphanie Gatti, Julien Bruneau, Young-Joo Moon, EmilieBalland, Charles Consel

To cite this version:Quentin Enard, Stéphanie Gatti, Julien Bruneau, Young-Joo Moon, Emilie Balland, et al.. Design-driven Development of Dependable Applications: A Case Study in Avionics. PECCS - 3rd Interna-tional Conference on Pervasive and Embedded Computing and Communication Systems, Feb 2013,Barcelona, Spain. �hal-00794329�

Design-driven Development of Dependable Applications:A Case Study in Avionics

Quentin Enard1,2, Stéphanie Gatti1,2, Julien Bruneau2, Young-Joo Moon2, Emilie Balland2

and Charles Consel21Thales Airborne Systems

2INRIA / University of Bordeaux, Francefirst.last@inria.fr

Keywords:Generative programming, Error handling, QoS Monitoring, Real-time systems, Software architecture

Abstract:Making an application dependable demands that its functional and non-functional requirementsbe stringently fulfilled throughout its development process. In this context, a design-drivendevelopment approach has the key advantage of enabling requirements to be traced from theirhigh-level design forms to the resulting executable artifact. However, because such approachesare mostly general purpose, they provide little design guidance, if any. This situation makesunpredictable the coherence and the conformance of an application with respect to its requirements.To address this situation, we propose an approach that leverages a design-driven developmentprocess dedicated to a specific paradigm. This approach guides the verification of the coherenceand conformance of an application throughout its development. We demonstrate the benefits ofour approach by applying it to a realistic case study in the avionics domain.

1 Introduction

Dependability of a system is the ability toavoid service failures that are more frequent andmore severe than is acceptable [Avizienis et al.,2004]. This generic concept includes attributessuch as availability, integrity and reliability. De-pendable systems are now pervasive in a range ofdomains (e.g., railway, avionics, automotive) andrequire a certification process. The main goal ofcertification is to demonstrate that a system isconform to its high-level requirements, resultingfrom functional and safety analyses.

Software plays an increasingly important rolein dependable systems; software development isthus required to be certified. In particular, thestakeholders have to pay attention to the coher-ence of the functional and non-functional aspectsof an application to demonstrate the conformanceof the software with the high-level requirements.Non-functional aspects of a system refer to con-straints on the manner in which this system imple-ments and delivers its functionality (e.g., perfor-mance, reliability, security) [Taylor et al., 2009].

Coherence. Because functional and non-functionalaspects are inherently coupled, ensuring theircoherence is critical to avoid unpredicted fail-ures [Littlewood and Strigini, 2000]. For example,fault-tolerance mechanisms may significantly de-teriorate the application performance. Generally,this kind of issues are detected at the late stagesof the development process, increasing the devel-opment cost of applications [Amey, 2002].Conformance. Ensuring that an application is inconformance with its high-level requirements istypically done by tracing their propagation acrossthe development stages. In practice, this processis human-intensive and error prone because it isperformed manually [Lasnier et al., 2009].

Certifying a development process requires avariety of activities. In industry, the usual pro-cedures involve holding peer review sessions forcoherence verification, and writing traceabilitydocuments for conformance certification. In thiscontext, design-driven development approachesare of paramount importance because the designdrives the development of the application andprovides a basis for tracing requirements [Volter

et al., 2006]. However, because most existing ap-proaches are general purpose, their guidance islimited, causing inconsistencies to be introducedin the design and along the development process.This situation calls for an integrated developmentprocess centered around a conceptual frameworkthat allows to guide the certification process in asystematic manner. In response to this situation,we proposed a design-driven development method-ology, named DiaSuite [Cassou et al., 2011], whichis dedicated to the Sense/Compute/Control (SCC)paradigm [Taylor et al., 2009]. As demonstratedby Shaw, the use of a specific paradigm providesa conceptual framework, leading to a more disci-plined engineering process and guiding the verifi-cation process [Shaw, 1995]. An SCC applicationis one that interacts with a physical environment.Such applications are typical of domains such ashome/building automation, robotics and avionics.

In this paper, we show the benefits of DiaSuitefor the development of dependable SCC applica-tions. This approach is applied to a realistic casestudy in the avionics domain, in the context of twonon-functional aspects, namely time-related per-formance and reliability. The DiaSuite design lan-guage, named DiaSpec, offers declarations cover-ing both functional and non-functional dimensionsof an SCC application [Cassou et al., 2011,Mer-cadal et al., 2010,Gatti et al., 2011]. However,so far, the DiaSuite methodology has only beenused to study each dimension in isolation, leavingopen the problems of coherence and conformancewhen considering multiple dimensions. This pa-per integrates all these dimensions, enabling thegeneration of validation support. More precisely,the paper makes the following contributions:Design coherence over functional and non-functional dimensions. We use the DiaSpeclanguage to describe both functional and non-functional aspects of an application and applythis approach to a realistic case study. A DiaSpecdescription is verified at design time for coherenceof its declarations. This verification is performedwith respect to a formal model generated from aDiaSpec description.Design conformance through the development pro-cess. At design time, we provide verificationsupport to check the conformance between thespecification and the formalized form of the high-level requirements. At implementation time, weguarantee the conformance between the applica-tion code and the previously verified requirements.This process is automatically done by leveragingthe generative approach of DiaSuite. As some

of the high-level requirements cannot be ensuredat design time (e.g., time-related performance),we provide further testing support to validate theimplementation with respect to these remainingrequirements. This support leverages a realisticflight simulator, namely FlightGear [Perry, 2004].Validation in avionics. We validate our approachby developing a realistic case study in avionics.Following the DiaSuite methodology, we have de-veloped an aircraft flight guidance system andtested it on FlightGear. Additionally, we haveduplicated this case study in the context of a com-mercial drone system, namely Parrot AR.Drone.1

2 Background

We first present an overview of the DiaSuitedevelopment methodology. Then, we introducethe working example used throughout this paper,namely an application for aircraft flight guidance.

2.1 Overview of DiaSuite

DiaSuite is a design-driven development methodol-ogy dedicated to the SCC paradigm [Cassou et al.,2011]. This paradigm originates from the Sense/-Compute/Control architectural pattern, promotedby Taylor et al. [Taylor et al., 2009]. This patternideally fits applications that interact with an ex-ternal environment. Such applications are typicalof domains such as home/building automation,robotics, automotive and avionics.

Environment

act on

sensed by

contextdata

raw data

orders

Contexts

Controllers

Sources

Actions

Entities

Figure 1: The SCC paradigm

As depicted in Figure 1, this architectural pat-tern consists of three types of components: (1)entities correspond to devices, whether hardwareor software, and interact with the external en-vironment through their sensing and actuatingcapabilities; (2) context components refine (filter,aggregate and interpret) raw data sensed by theentities; (3) controller components use this refinedinformation to control the environment by trigger-ing actions on entities.

1http://ardrone.parrot.com

Execution platform back-end

Programming framework

Designers Testers Developers

DiaSpecCompiler

ApplicationDesign

Implementation Support

1

Simulation Application

2

4 3

5

Figure 2: The DiaSuite tool-based methodology

As depicted in Figure 2, the DiaSuite toolsuite leverages the SCC paradigm to support eachstage of the development process, from designto deployment. At the design stage, the Dia-Spec language provides SCC-specific declarationconstructs (stage À in Figure 2). These constructscover both the functional aspects of an application,such as data and control flows [Cassou et al., 2011],and the non-functional aspects, such as QoS [Gattiet al., 2011] and error handling [Mercadal et al.,2010].

From a DiaSpec description, a programmingframework is generated to guide and support theprogrammer (stages Á and  in Figure 2). Addi-tionally, the DiaSpec compiler generates testingsupport, targeting a simulator specific to a givendomain (stage à in Figure 2). Finally, DiaSuiteoffers support for deploying an application usingseveral distributed systems technologies such asWeb Services, RMI and SIP (stage Ä in Figure 2).More details about DiaSuite can be found in ourprevious publications [Cassou et al., 2009,Cassouet al., 2011].

2.2 Flight Guidance Application

To illustrate the DiaSuite development methodol-ogy for dependable SCC applications, we choosean application of aircraft flight guidance. Becauseit is safety critical, this application has to respectstringent high-level requirements.

The flight guidance application is in charge ofthe aircraft navigation and is under the supervi-sion of the pilot [Miller, 1998]. For example, thepilot can directly specify parameters during theflight (e.g., the altitude) or define a flight plan thatis automatically followed. Each parameter is han-dled by a specific navigation mode (e.g., altitudemode, heading mode). Once a mode is selectedby the pilot, the flight guidance application is incharge of operating the ailerons and the elevatorsto reach the target position. For example, if the

pilot specifies a heading to follow, the applicationcompares it to the current heading, sensed by de-vices such as the Inertial Reference Unit (IRU),and maneuvers the ailerons accordingly. Eachnavigation mode is generally associated to a func-tional chain, representing a chain of computations,from sensors to actuators [Windsor and Hjortnaes,2009].

In the avionics domain, safety analyses are con-ducted to identify hazardous situations, resultingin safety requirements [ARP-4761, 1996]. Here aresome examples of high-level requirements for theflight guidance application, as defined by domainexperts:Req1. The execution time of the functional chain

associated with the heading mode must notexceed 650 ms.

Req2. The freshness of the navigation data usedby the application must be less than 200 ms.

Req3. The malfunction or failure of a sensor mustbe systematically signaled to the pilot, within300 ms.

Req4. A navigation mode should be deactivatedsafely if a sensor involved in its computationfails.Translating these requirements into a coherent

design and ensuring their traceability across thedevelopment process is mandatory for the certifi-cation, strongly suggesting an integrated design-driven development methodology like DiaSuite.

3 Design

This section presents our design approach fordependable SCC applications and the validationsupport generated at the design stage. These con-tributions are illustrated with the heading modeof the flight guidance application, introduced inSection 2.2.

3.1 Our Approach

Like a programming paradigm, the DiaSuite de-sign paradigm provides SCC-specific concepts andabstractions to solve a software engineering prob-lem. However, these concepts and abstractionsare dedicated to a design style, raising the levelof abstraction above programming. In this pa-per, we propose to use this paradigm to uniformlydescribe both the functional and non-functionalaspects of an application. As shown in Figure 3,our approach consists of layering the design of an

application into the logic of the functional planeand the supervision of the non-functional aspects.When a non-functional situation is detected at thefunctional layer (e.g., a device failure), an eventis raised, giving control to the supervisory layer.

ComputeControl

Sense

Supervisory

Functional Environment

Compute

Control

Sense

Figure 3: Layered view of the SCC paradigm

This layered design allows to factorize the su-pervisory treatments such as error recovery. Forexample, the Req4 requirement entails to deac-tivate the navigation modes that rely on faultysensors. In this case, if a navigation sensor fails,an event (i.e., an error) is raised, giving controlto a supervisory chain of operations, aimed todeactivate the dependent navigation modes.

The design of the flight guidance applicationcan thus be decomposed into several functionaland supervisory chains: one functional chain foreach navigation mode and one supervisory chainfor each supervisory treatment (e.g., reconfigura-tion, logging, pilot warning). In the rest of thissection, we focus on the functional chains of theheading mode and the supervisory chain dedicatedto deactivating the dependent navigation modes.

3.2 Functional Layer

Following the SCC paradigm, the DiaSpec designlanguage provides specific declarations for entities,context and controller components. An entity isdefined as a set of sensing and actuating capa-bilities. Figure 4 presents the taxonomy of theentities used by the heading mode of the flightguidance application. The IRU entity senses theposition, the heading and the roll of the planefrom the environment, as indicated by the sourcekeyword. The NavMMI entity abstracts over thepilot interaction and directly provides the targetheading set by the pilot. The Aileron entityprovides the Control interface to act on the en-vironment, as indicated by the action keyword.The high-level nature of the entity declarationfacilitates the integration of Commercial Off-The-Shelf (COTS) components: any implementationcomplying with the entity declaration can be usedby an application.

device IRU {source heading as Float [ frequency 200 ms ] ;source p o s i t i o n as Coordinates ;source r o l l as Float ;. . .action D e a c t i v a t e ;r a i s e s F a i l u r e E x c e p t i o n ;

}device NavMMI {

source targetHeading as Float ;. . .action DisableMode ;action Display ;

}action Control {

i n c l i n e ( t a r g e t R o l l as Float ) ;}device A i l e r o n {

action Control ;}

Figure 4: Extract of the flight guidance taxonomy

This design can be enriched with QoS anderror-handling declarations. For example, in Fig-ure 4, the IRU entity is declared as raising anerror of type FailureException. Figure 4 spec-ifies that the IRU entity produces the headinginformation with a frequency of 200 ms. For moredetails about these non-functional declarations,the reader can refer to previous publications [Mer-cadal et al., 2010,Gatti et al., 2011].

Using this taxonomy of entities, the specifi-cation of an application is defined using contextand controller components. For example, in thedesign of the heading mode, the IntHeading con-text component computes an intermediate headingfrom the current plane heading given by the IRUentity and the target heading given by the NavMMIentity. From this intermediate heading and thecurrent plane roll (i.e., its rotation on the longi-tudinal axis) given by the IRU entity, the Target-Roll context component computes a target roll.This target roll is used by AileronController tocontrol the ailerons and reach the target heading.

The specification of an SCC component is il-lustrated in Figure 5. This DiaSpec fragmentdeclares the IntHeading context component asproducing an intermediate heading of a Floattype from values of two input entities, declaredwith the source keyword. The control flow ofthis process is specified by an interaction contractintroduced by the interaction clause. It declaresthat, when IntHeading receives a heading infor-mation from the IRU entity, it may access thetargetHeading value provided by the NavMMI en-tity. The always publish clause specifies thatthe context systematically publishes a value onceit receives a heading information. Alternatively,a context component can be declared as eithermaybe or never publishing a result.

context IntHeading as Float {source heading from IRU ;source targetHeading from NavMMI;interaction {

when provided heading from IRU ;get targetHeading from NavMMI

in 100 ms [ mandatory catch ] ;always publish ;

}}

Figure 5: Specification of IntHeading

In the interaction contract of IntHeading,the response time of NavMMI has to be at most100 ms. The [mandatory catch] annotation in-dicates that the IntHeading context must com-pensate the errors when accessing targetHeadingdata. In contrast, the [skipped catch] annota-tion indicates that a context is not allowed tohandle the errors.

3.3 Supervisory Layer

Figure 6 summarizes the design of the headingmode by a data-flow directed graph, where a nodeis an SCC component and the edges indicate dataexchange between the components. This figureshows another QoS declaration: a Worst Case Ex-ecution Time (WCET) is specified on the Aileroncontroller to cope with the Req1 requirement.

Alongside the application logic, supervisorytreatments can be specified in DiaSpec using sep-arate SCC chains. In the avionics domain, thesetreatments typically involve monitoring the appli-cation and triggering reconfigurations, as requiredby the Req3 and Req4 requirements expressedin Section 2.2. Specifically, these treatments allowto (1) inform the pilot in case of a device failure orunavailable data, (2) deactivate the modes that de-pend on unavailable data, and (3) log informationfor maintenance purposes. For example, the rightpart of Figure 6 depicts the supervisory chain cor-responding to the deactivation of the dependentnavigation modes.

These supervisory chains are specified withrespect to non-functional information defined inthe taxonomy and the application design. Forinstance, errors raised by entities or violations oftiming constraints are used as sources of informa-tion for the supervisory treatments. In Figure 6,the availability of IRU data is checked throughthe DataAvailability context component and isthen used by the ModeController component toenable/disable navigation modes and deactivatethe faulty sensors.

AileronControl

ModeController

AileronController

TargetRoll

DataAvailability

IntHeading

ExceptionalEvent

Data access

Data publishing

IRU

roll

IRU

Deactivate

NavMMI

DisableMode

[200ms]

[200ms, skipped]

[100ms, mandatory]

NavMMItargetHeadingheading

[650ms WCET]

IRU

Figure 6: Extract of the flight guidance applicationdesign

3.4 Verification Support

Because the DiaSpec design language makes flowinformation explicit, a range of properties can bechecked at design time. Indeed, a formal modelcan be generated from a DiaSpec specification,allowing the early verification of coherence andconformance. Unlike our previous work [Cassouet al., 2011], we now generate models expressedwith timed automata, capturing time-related dec-larations. A DiaSpec specification is translatedinto a network of timed automata where eachautomaton describes the behavior of a DiaSpeccomponent.2 The resulting network of timed au-tomata allows to verify safety properties usingmodel-checking techniques. Here, we use UP-PAAL, an integrated tool environment dedicatedto modeling, validation and verification of net-works of timed automata [Behrmann et al., 2004].To illustrate this early verification process, wepresent examples of coherence and conformanceverifications on the design of the flight guidanceapplication.

Coherence verification. Incoherence betweenthe time-related constraints can be automaticallydetected by the UPPAAL model checker. Time-related properties depend on communication as-sumptions (e.g., asynchronous/synchronous com-munication, data buffering). These assumptionsare expressed in terms of parameters of the gener-ated UPPAAL model. In the model of the headingmode, we specify that the components have nobuffer and thus consume values immediately. Inthis case, a deadlock state is detected if the NavMMItakes more than 200 ms to answer to a requestfrom the IntHeading context component. Indeed,this context component is not able to handle the

2A detailed presentation of this translation can befound at http://diasuite.inria.fr/validation.

heading data published every 200 ms by the IRUentity. This verification has led us to enrich thedesign with a timing constraint indicating thatthe response time of NavMMI has to be at most100 ms. A more complex example is the interac-tion between the TargetRoll context componentand the IRU entity. A deadlock is detected whenthe pulling process takes more than 300 ms. Theshortest counter-example includes three data re-quests and thus cannot be easily identified byhand.

Conformance verification. We use propertiesbased on temporal logic to express high-levelrequirements and check them on the design ofthe application. The UPPAAL model checkerrelies on a subset of TCTL (Timed Computa-tion Tree Logic) [Henzinger et al., 1994]. Anexample of TCTL properties is “IRU.Failure NavMMI.DisableMode”, corresponding to theReq4 requirement. When the IRU automatonis in the IRU.Failure state, the NavMMI automa-ton will eventually be in the NavMMI.DisableModestate, which corresponds to the deactivation of thenavigation modes that depend on the IRU sensor.

Even if conformance and coherence cannot befully guaranteed at design time, providing suchvalidation support guides the design with regardto the high-level requirements. Indeed, when aproperty is not satisfiable, a counter-example isgenerated by UPPAAL, helping the designer toimprove the DiaSpec specification. Moreover, ourgenerative approach ensures that the implemen-tation is conform to the design, preserving theseproperties in the subsequent stages of the devel-opment process.

4 Implementation

When developing dependable applications, akey goal is to preserve the high-level requirementsthroughout the development process. To do so,the DiaSuite approach relies on a compiler thatgenerates a dedicated programming frameworkfrom a DiaSpec design. As depicted in Figure 2,the compiler takes as input the DiaSpec specifica-tion of the application and generates a dedicatedJava programming framework that ensures theconformance between the design and the imple-mentation [Cassou et al., 2011].

For example, Figure 7 shows the abstractclass generated from the specification of the Int-Heading context component. This abstract class

guides the developer by providing high-level op-erations for entity binding and component inter-actions. Additionally, our strategy to generate anabstract class relies on the Java language and itstype system to enforce the declared interactioncontracts. As shown in Figure 8, when extend-ing the AbstractIntHeading abstract class, thedeveloper is required to implement the onHeading-FromIRU abstract method to receive a value pub-lished by this device. In addition to this value,this method is passed support objects to requestdata from a device (binding).

public abstract c l a s s AbstractIntHeading {public abstract Float onHeadingFromIRU (

Float heading , Binding binding ) ;. . .

}

Figure 7: Extract of the AbstractIntHeading class

public c l a s s IntHeading extendsAbstractIntHeading {

public Float onHeadingFromIRU ( Float heading ,Binding binding ) {

NavMMI mmi = binding . navMMI ( ) ;Float targetHeading = mmi . getTargetHeading (

new TargetHeadingContinuation ( ) {public Float onError ( ) {

return DEFAULT_VALUE; } } ) ;return

c o n t r o l l e r P I D . compute ( heading ,targetHeading ) ;

}}

Figure 8: Extract of the IntHeading context imple-mentation

The inversion of control principle is uniformlyapplied to an SCC-generated programming frame-work to guarantee that the interaction between thecomponents is conform to the design. Specifically,the abstract methods to be implemented by thedeveloper are only called by the framework, ensur-ing that a DiaSpec software system is compliantwith its DiaSpec design.

Similarly, the non-functional declarations aretraceable throughout the implementation stage bygenerating dedicated programming support. Forexample, the IRU entity was declared in the tax-onomy (Figure 4) as raising FailureExceptionerrors. Consequently, a specific method is gen-erated in the corresponding entity abstract classto allow error signaling to be introduced by thedeveloper when implementing an instance of thisentity [Mercadal et al., 2010]. Another exam-ple is the mandatory catch declaration in theIntHeading interaction contract presented in Fig-ure 5. This declaration imposes the IntHeadingimplementation to handle potential errors when

requesting the targetHeading data from NavMMI.As shown in Figure 8, this mandatory error han-dling is enforced by introducing a continuationparameter in the method supplied to the devel-oper to request the targetHeading data (i.e.,getTargetHeading). This continuation providesa default value in case of an error.

Timing constraints specified at design timeare also traceable in the generated programmingframework. Indeed, these constraints are auto-matically monitored in the programming frame-work [Gatti et al., 2011]. For instance, this mon-itoring layer measures the time spent by theIntHeading context component to retrieve thetargetHeading data. If this time is greater than100 ms (as specified in Figure 5), an error is auto-matically raised by the framework.

As shown in Section 3, the supervisory treat-ments are handled independently from the func-tional treatments. This separation of concernsallows a developer to focus on a specific non-functional aspect. For example, the developerof the DataAvailability context component canconcentrate on implementing algorithms to detectdata availability. Because of the programmingframework support, the developer does not needto mix supervisory operations, to detect and han-dle errors, with the functional treatments.

5 Testing

The implementation of each SCC chain can betested independently. For example, the functionalaspect of the application can be tested using asimulated external environment. The taxonomydefinition allows to validate the functional imple-mentation using mock-up entities that rely on thesimulated environment. This is done without anyimpact on the rest of the application.

public c l a s s SimulatedIRU extends AbstractIRUimplements S i m u l a t o r L i s t e n e r {

public SimulatedIRU ( FGModel model ) {model . a d d L i s t e n e r ( this ) ;

}public void s imulationUpdated ( FGModel model ) {

p u b l i s h P o s i t i o n ( model . g e t I n e r t i a l P o s i t i o n ( ) ) ;}

}

Figure 9: Extract of the simulated IRU class

In avionics, it is required to verify the behaviorof the application in specific environmental con-ditions. Because some scenarios are difficult tocreate (e.g., extreme flight conditions), we providea testing support that relies on a flight simulator,

namely FlightGear [Perry, 2004], to simulate theexternal environment.

Using a Java library that interfaces with Flight-Gear, the testers can easily implement simulatedversions of entities. Figure 9 presents an extractof the implementation of a simulated IRU.

The SimulatedIRU entity is implemented byinheriting the AbstractIRU class, provided by theprogramming framework. To interact with thesimulated environment, the entity implements theSimulatorListener interface. This interface de-fines a method named simulationUpdated, whichis called periodically by the simulation library.The model parameter allows to read/write thecurrent state of the FlightGear simulator. InFigure 9, the position of the plane is publishedby calling the publishPosition method of theAbstractIRU class.

Figure 10: Screenshot of a simulated flight

Once the simulated entities are implemented,the flight guidance application is tested by con-trolling a simulated plane within FlightGear. Anexample of testing scenarios is to provide a desiredheading via the autopilot interface of the flightguidance application and to verify that the appli-cation controls the ailerons of the simulated planeas expected. Figure 10 presents a screenshot ofour testing environment. In the main window, theFlightGear simulator allows to control and visual-ize the simulated plane. In the top-left corner, theautopilot interface allows testers to select a navi-gation mode. In this case, the "Route Manager"mode is selected to follow the flight plan definedvia the map displayed in the bottom-left corner.

The simulated environment is also useful fortesting the supervisory SCC chains. Device fail-ures can be directly simulated using FlightGear.We also provide a simple testing support to injecterrors from the simulated entities as illustratedby the FaultInjector window in the top-rightcorner. Then, the window in the bottom-rightof the screenshot displays the errors monitoredby the application. This particular testing sup-

port eases the verification of the conformance withthe requirements such as the Req3 requirementpresented in Section 2.2

Finally, it is required to realize integration test-ing on a test bench to ensure that the applicationbehaves correctly for a specific deployment config-uration. An advantage of our simulation supportis that simulated and real entities can be com-bined in a hybrid environment. Indeed, as bothreal and simulated versions of an entity extend thesame abstract class, the nature of an entity hasno impact on the rest of the application. Deploy-ing an application on a test bench is a dauntingtask that has to be repeated each time an error isdetected. Testing by simulation may avoid someunnecessary deployments.

6 Assessment

We now outline the benefits of our approach,focusing on the coherence and conformance verifi-cation. As shown in the previous sections, we havedeveloped an avionics flight guidance applicationand tested it on a realistic flight simulator, namelyFlightGear [Perry, 2004]. Additionally, we haveduplicated this case study in the context of thecommercial Parrot AR.Drone system.3

6.1 Coherence

To ensure coherence at design time, the DiaSuitemethodology relies on a unique design language.Unlike independent views (e.g., the collection ofUML diagrams), DiaSpec integrates functionaland non-functional declarations, contributing toprevent most inconsistencies. For example, thecoherence between error-handling declarations canbe statically checked as they directly refine theinteraction contracts describing the control flow.If the designer declares an entity as raising anexception, compile-time verifications ensure thatthere is an error-handling declaration for eachcomponent requiring data from this entity. Con-cerning the QoS declarations, their coherence isdirectly verified on the formal model generatedfrom the DiaSpec specification. Indeed, any incon-sistencies between the timing constraints result ina deadlock, as shown in Section 3.

At implementation time, the coherence be-tween the error-handling declarations is auto-

3The DiaSpec specification and a video demonstrat-ing this application are available at http://diasuite.inria.fr/avionics/ardrone.

matically preserved thanks to the generated pro-gramming framework. Indeed, the support gen-erated for error handling, such as in the Data-Availability context component presented inSection 4, prevents developers from implementingad-hoc code for error propagation. Concerningthe QoS declarations, the generated support con-sists of monitors integrated in the programmingframework. These guards do not ensure coherenceby themselves but guide the coherence verificationat runtime. Indeed, when a QoS contract is notfulfilled, a specific exception is raised, pinpointingthe involved component.

6.2 Conformance

To ensure the conformance with respect to thehigh-level requirements, we provide validation sup-port along the development process. We illustratehow this support guides the conformance verifica-tion using the Req3 requirement. This require-ment indicates that the malfunction or failure ofa sensor must be systematically signaled to thepilot, within 300 ms.

At design time, this requirement leads to thespecification of an SCC supervisory chain dedi-cated to the signaling of the failure to the pilot.The early-verification support presented in Sec-tion 3 allows to statically verify that an excep-tional event raised by the IRU entity systematicallyresults in the triggering of the Display action onthe NavMMI entity.

At implementation time, the generation ofa programming framework ensures the confor-mance of the application with the data and controlflow specifications as demonstrated in previouswork [Cassou et al., 2011]. However, the time-related aspect of the Req3 requirement cannot beverified at design time as it depends on runtimespecificities (e.g., the properties of the executionplatform). To ease the verification of such re-quirements, the programming framework providesdedicated monitors to detect the violation of thetime-related constraints during the testing stage.Moreover, the generated testing support provideserror-injection capabilities, allowing to validatethe Req3 requirement, even if the IRU entity isnot yet implemented.

7 Related Work

Several design-driven development approachesare dedicated to dependable applications.

In the domain of architecture description lan-guages, the Architecture Analysis & Design Lan-guage (AADL) is a standard dedicated to real-timeembedded systems [Feiler, 2006]. AADL provideslanguage constructs for the specification of soft-ware systems (e.g., component, port) and theirdeployment on execution platforms (e.g., thread,process, memory). Using AADL, designers specifynon-functional aspects by adding properties on lan-guage constructs (e.g., the period of a thread) orusing language extensions such as the Error ModelAnnex.4 The software design concepts of AADLare still rather general purpose and give little guid-ance to the designer. At the expense of generality,our approach makes explicit domain-specific con-cepts in the design specification of dependableapplications, namely sensors, contexts, controllers,actuators. This approach enables further devel-opment support for the design, programming andtesting stages.

As AADL is a standard, a lot of research hasbeen devoted to provide it with analysis and de-velopment tool support. For example, Dissauxet al. present performance analysis of real-timearchitectures [Dissaux and Singhoff, 2008]. Theypropose a set of AADL design patterns to modelreal-time issues, such as thread synchronization.For each pattern, they list a set of performancecriteria (e.g., the bounds on a thread waitingtime due to access data) that can be checkedwith a performance analysis tool [Singhoff et al.,2004]. In comparison, our approach allows to spec-ify timing constraints on component interactions,enabling the verification of time-related proper-ties at a higher level of abstraction. As AADLmainly focuses on deployment concerns, it is com-plementary to our approach and could be usedfor the deployment specification and analysis ofapplications designed with DiaSpec. While mostADLs provide little or no implementation support,the Ocarina environment allows the generationof programming support dedicated to an AADLdescription [Hugues et al., 2008]. However, thisprogramming support consists of glue code fora real-time middleware and does not guide norconstrain the application logic implementation.

In model-driven engineering, several ap-proaches focus on dependable applications. Forexample, Burmester et al. propose a develop-ment approach dedicated to mechatronic sys-tems [Burmester et al., 2004]. This approach isbased on a domain-specific extension of UML for

4The Error Model Annex is a standardized AADLextension for the description of errors [Vestal, 2005].

real-time systems. To allow the formal verifica-tion of a whole mechatronic system, the authorspropose to develop a library of coordination pat-terns that define specific component roles, theirinteractions and real-time constraints. Then, thecomponents of the application are built using thislibrary of patterns by specifying their roles and ad-ditional behavior details. The approach comprisestool support for the specification, verification andsource code synthesis as a plug-in for the Fujabatool suite [Burmester et al., 2005]. The use ofcoordination patterns can be seen as a paradigmthat guides the design of mechatronic systems.Contrary to ours, their approach does not pro-vide support for error handling but focuses on thetime-related aspects.

Another development methodology for depend-able applications is SCADE (Safety Critical Ap-plication Development Environment) [Dion, 2004].SCADE is based on a synchronous language andrelies on hierarchical state machines for the speci-fication of dependable applications. An applica-tion is specified using state machines, enablingthe verification of coherence at design time. Thesynchronous paradigm ensures by constructionthe determinism of a specification, and thus easesthese verifications. The approach abstracts overphysical time allowing real-time properties to beverified at the code level. Our design methodologyis similar to this approach but lifts constraintsinherent to the determinism of the specification.SCADE could be used to specify more preciselythe internal behavior of critical DiaSpec compo-nents.

8 Conclusion and Future Works

In this paper, we have shown the benefits ofthe DiaSuite methodology for the developmentand the verification of dependable applications.We have applied this methodology to a realisticcase study in the avionics domain and covered theentire development process, from design to testing,leveraging an existing flight simulator.

We are currently working on the specificationof fault tolerance strategies to improve the gener-ated support for error handling. Another direc-tion concerns the deployment stage. We plan onreusing existing avionics deployment technologiesto provide deployment support.

REFERENCES

Amey, P. (2002). Correctness by Construction: BetterCan Also Be Cheaper. CrossTalk: the Journal ofDefense Software Engineering, 2:24–28.

ARP-4761 (1996). ARP-4761, Guidelines and Methodsfor Conducting the Safety Assessment Process onCivil Airborne Systems and Equipment (SAE).

Avizienis, A., Laprie, J., Randell, B., and Landwehr,C. (2004). Basic Concepts and Taxonomy ofDependable and Secure Computing. Dependableand Secure Computing, IEEE Transactions on,1(1):11–33.

Behrmann, G., David, A., and Larsen, K. (2004). ATutorial on Uppaal. Formal methods for thedesign of real-time systems, pages 33–35.

Burmester, S., Giese, H., Hirsch, M., Schilling, D.,and Tichy, M. (2005). The Fujaba Real-TimeTool Suite: Model-Driven Development of Safety-Critical, Real-Time Systems. In ICSE’05: Pro-ceedings of the 27th International Conference onSoftware Engineering, pages 670–671. ACM.

Burmester, S., Tichy, M., and Giese, H. (2004). Mod-eling Reconfigurable Mechatronic Systems withMechatronic UML. In Proceedings of Model-Driven Architecture: Foundations and Applica-tions (MDAFA 2004), Linköping, Sweden, pages155–169.

Cassou, D., Balland, E., Consel, C., and Lawall, J.(2011). Leveraging Software Architectures toGuide and Verify the Development of Sense/Com-pute/Control Applications. In ICSE’11: Pro-ceedings of the 33rd International Conference onSoftware Engineering, pages 431–440. ACM.

Cassou, D., Bertran, B., Loriant, N., and Consel,C. (2009). A Generative Programming Ap-proach to Developing Pervasive Computing Sys-tems. In GPCE’09: Proceedings of the 8th In-ternational Conference on Generative Program-ming and Component Engineering, pages 137–146. ACM Press.

Cassou, D., Bruneau, J., Consel, C., and Balland,E. (2011). Towards A Tool-Based DevelopmentMethodology for Pervasive Computing Applica-tions. Software Engineering, IEEE Transactionson, PP(99).

Dion, B. (2004). Correct-By-Construction Methods forthe Development of Safety-Critical Applications.SAE transactions, 113(7):242–249.

Dissaux, P. and Singhoff, F. (2008). Stood and Ched-dar: AADL as a Pivot Language for AnalysingPerformances of Real Time Architectures. InProceedings of the European Real Time Systemconference. Toulouse, France.

Feiler, P. (2006). The Architecture Analysis & DesignLanguage (AADL): An Introduction. Technicalreport, DTIC Document.

Gatti, S., Balland, E., and Consel, C. (2011). A Step-wise Approach for Integrating QoS throughoutSoftware Development. In FASE’11: Proceedings

of the 14th European Conference on FundamentalApproaches to Software Engineering, pages 217–231.

Henzinger, T. A., Nicollin, X., Sifakis, J., and Yovine,S. (1994). Symbolic Model Checking for Real-Time Systems. Inf. Comput., 111(2):193–244.

Hugues, J., Zalila, B., Pautet, L., and Kordon, F.(2008). From the Prototype to the Final Embed-ded System Using the Ocarina AADL Tool Suite.ACM Transactions on Embedded Computing Sys-tems, 7:1–25.

Lasnier, G., Zalila, B., Pautet, L., and Hugues, J.(2009). OCARINA: An Environment for AADLModels Analysis and Automatic Code Generationfor High Integrity Applications. Reliable SoftwareTechnologies–Ada-Europe 2009, pages 237–250.

Littlewood, B. and Strigini, L. (2000). Software Re-liability and Dependability: a Roadmap. InICSE’00: Proceedings of the Conference on TheFuture of Software Engineering, pages 175–188.ACM.

Mercadal, J., Enard, Q., Consel, C., and Loriant, N.(2010). A Domain-Specific Approach to Architec-turing Error Handling in Pervasive Computing.In OOPSLA’10: Proceedings of the Conferenceon Object Oriented Programming Systems Lan-guages and Applications, volume 45, pages 47–61.

Miller, S. (1998). Specifying the Mode Logic of aFlight Guidance System in CoRE and SCR. InFMSP’98: Proceedings of the Second Workshopon Formal Methods in Software Practice, pages44–53. ACM.

Perry, A. R. (2004). The FlightGear Flight Simulator.In Proceedings of the USENIX Annual TechnicalConference.

Shaw, M. (1995). Beyond Objects: A Software DesignParadigm Based on Process Control. SIGSOFTSoftware Engineering Notes, 20:27–38.

Singhoff, F., Legrand, J., Nana, L., and Marcé, L.(2004). Cheddar: a Flexible Real Time Schedul-ing Framework. ACM SIGAda Ada Letters,XXIV:1–8.

Taylor, R. N., Medvidovic, N., and Dashofy, E. M.(2009). Software Architecture: Foundations, The-ory, and Practice. Wiley Publishing.

Vestal, S. (2005). An Overview of the Architec-ture Analysis & Design Language (AADL) ErrorModel Annex. In AADL Workshop.

Volter, M., Stahl, T., Bettin, J., Haase, A., and Helsen,S. (2006). Model-driven Software Development:Technology, Engineering, Management. John Wi-ley and Sons Ltd.

Windsor, J. and Hjortnaes, K. (2009). Time andSpace Partitioning in Spacecraft Avionics. InSMC-IT’09: Proceedings of the 3rd IEEE Inter-national Conference on Space Mission Challengesfor Information Technology, pages 13–20. IEEE.