ACM/IEEE 17th International Conference on
Model Driven Engineering Languages and Systems
September 28 – October 3, 2014 Valencia (Spain)
ACVI 2014 – Architecture Centric Virtual Integration Workshop Proceedings
Julien Delange and Peter Feiler
Published on Sept 2014 v1.0
© 2014 for the individual papers by the papers’ authors. Copying permitted for private and academic purposes. Re-publication of material from this volume requires permission by the copyright owners.
Organizers
Julien Delange (co-chair) Carnegie Mellon Software Engineering Institute Peter Feiler (co-chair) Carnegie Mellon Software Engineering Institute
Program Committee
Canals Agusti C-S
Etienne Borde TELECOM ParisTech
Matteo Bordin Adacore
J¨ orgen Hansson University of Sk¨ ovde, Sweden
Jerome Hugues ISAE
Emilio Insfran Universitat Politcnica de Valncia
Akihito Iwai DENSO Corporation
Alexey Khoroshilov ISPRAS
Bruce Lewis US ARMY
Oleg Sokolsky University of Pennsylvania
Jean-Pierre Talpin INRIA
Steve Vestal Adventium Labs
Bechir Zalila National School of Engineers of Sfax
Table of Contents
Preface . . . . 1 Opening Keynote: The Story of AADL . . . . 3
Peter FeilerContract-based specification and analysis of AADL models . . . . 4
Ernesto Posse, Juergen DingelAn Extension for AADL to Model Mixed-criticality Avionic Systems Deployed on IMA architectures with TTEthernet . . . .
14
Robati Tiyam, Amine El Kouhen, Abdelouahed Gherbi, Sardaouna Hamadou, John MullinsA Discrete-event Simulator for Early Validation of Avionics Systems . . . . 28
Denis Buzdalov, Alexey KhoroshilovMulti-core Code Generation from Polychronous Programs with Time-Predictable Properties . . . .
39
Zhibin Yang, Jean-Paul Bodeveix, Mamoun FilaliModeling Shared-Memory Multiprocessor Systems with AADL . . . . 49
Stphane Rubini, Pierre Dissaux, Frank SinghoffExecutable AADL: Real-Time Simulation of AADL Models . . . . 59
Pierre Dissaux, Olivier MarcAutomatic Derivation of AADL Product Architectures in Software Product Line Development . . . .
69
Javier Gonzalez-Huerta, Silvia Abrahao, Emilio InsfranTowards an Architecture-Centric Approach dedicated to Model-Based Virtual Integration for Embedded Software Systems . . . .
79
Huafeng Yu, Jean-Pierre Talpin, Sandeep Shukla, Prachi Joshi, Shin’Ichi Shi- raishiPreface
New real-time systems have increasingly complex architectures because of the intricacy of the multiple interdependent features they have to manage. They must meet new require- ments of reusability, interoperability, flexibility and portability. These new dimensions favor the use of an architecture description language that offers a global vision of the sys- tem, and which is particularly suitable for handling real-time characteristics. Due to the even more increased complexity of distributed, real-time and embedded systems (DRE), the need for a model-driven approach is more obvious in this domain than in monolithic RT systems. The purpose of this workshop is to provide an opportunity to gather researchers and industrial practitioners to survey existing efforts related to behavior modelling and model-based analysis of DRE systems.
Cyber-Physical systems (CPS) combine many challenges to meet requirements for reusability, interoperability, flexibility or dependability. The use of architecture description language helps to integrate components before implementing the system. Such integra- tion approach eases system design analysis and implementation, detects design errors and potential defects before development efforts, avoiding re-engineering costs and making the system more robust and safe. This first edition of this workshop seeks contributions from researchers and practitioners interested in architecture-centric methods and their use to design and analyze systems. The conference topics of interest are:
– Modeling Notations: new languages, inter-operability between languages – Architecture Centric Analysis Tools
– Virtual Integration Process and Tools
– Definition of extensions for the design of specific systems (e.g. avionics) or support of a particular analysis (e.g. safety)
– Automatic Code Generation from Models – Model Transformation
– Model Analysis Methods
– Support of Certification (e.g. DO178C) using Models – Industrial experiences of use of Model-Based technologies
The Architecture-Centric Virtual Integration Workshop is colocated with the ACM/IEEE 17th International Conference on Model Driven Engineering Languages and Systems.
September 2014 Julien Delange and Peter Feiler
Keynote
The Story of AADL
Peter Feiler
Carnegie Mellon Software Engineering Institute
5 years ago the SAE AS-2C subcommittee started to work on the Archi- tecture Analysis & Design Language (AADL) standard. AADL was targeted to address issues in mission and safety critical software-reliant systems, aka. Cyber- physical systems. AADL addresses the increasing challenges of such systems - the exponential increase in verification related software rework cost. Industry studies show that 70% of defects are introduced in requirements and architec- ture design, while 80% are discovered post-unit test. After a short history and summary of the challenges, the presentation highlights the expressive, analyt- ical, and auto-generation capabilities of the AADL core language as well as several of its standardized extensions to address multiple quality dimensions and do so incrementally at different levels of fidelity. The presentation then illustrates these capabilities on several realistic industrial examples. The presen- tation concludes by outlining a four part improvement strategy: architecture-led requirement specification to improve the quality of requirements, architecture refinement and incremental virtual system integration to discover issues early, compositional verification through static analysis to address scalability, and in- cremental verification and testing throughout the life cycle as assurance evidence.
Peter Feileris a 29 year veteran and Principal Researcher of the Architecture Prac- tice (AP) initiative at the Software Engineering Institute (SEI). His current research interest is in improving the quality of safety-critical software-reliant systems through architecture-centric virtual system integration and incremental life cycle assurance to reduce rework and qualification costs. Peter Feiler has been the technical lead and main author of the SAE Architecture Analysis & Design Language (AADL) standard. He has a Ph.D. in Computer Science from Carnegie Mellon.
Contract-based specification and analysis of AADL models
?Ernesto Posse Juergen Dingel {eposse,dingel}@cs.queensu.ca
School of Computing – Queen’s University Kingston, Ontario, Canada
Abstract. We describe an approach to the specification, analysis and verification ofAADLmodels using assume/guarantee behavioural con- tracts specified with the Property Specification Language (PSL). This approach aids the development process by 1) supporting the reuse and replacement of components based on their contracts rather than only their interface or their implementation and thus reducing the need for re-engineering; 2) providing early discovery of behavioural inconsistencies that may pose problems with integration; and 3) allowing an incremen- tal and flexible application of specification and verification instead of requiring an all-or-nothing approach. It also helps improving the prod- uct itself by detecting safety and liveness problems via model-checking.
We also briefly discuss a prototype plug-in forOSATE supporting an annex language which we callAGCL.
1 Introduction
The development of distributed, real-time embedded systems (DRE) presents multiple challenges born out of their inherent complexity. In order to address the complexity of these systems and their design, component-based and model- driven approaches are often used. Such approaches often rely on modelling and architecture description languages such as the Architecture Analysis and Design Language,AADL[6], which provides the means to describe systems in terms of interacting components and their composition.
Complex patterns of interaction between components pose a challenge to de- velopers, making it difficult to understand how a system behaves and whether it satisfies its requirements and behaves correctly,e.g., satisfying safety and live- ness constraints. In order to provide some relief to the developer, automatic formal verification techniques such as model-checking can help to analyze a sys- tem’s behaviour. Nevertheless, formal verification often faces the so-calledstate- explosion problem, whereby adding a component multiplies the number of states in a system, resulting in an exponential growth in the state-space which provides a challenge to verification techniques and tools.
?This work was financed in part by Edgewater Computer Systems Inc., Ontario Cen-
An approach to deal with the state-explosion problem is the use ofcomposi- tional analysiswhich leverage the structure of the system. In these techniques, the analysis of a composite system is reduced to the analysis of its parts. A main advantage of such techniques is that if a single component changes, there is no need to reanalyze the whole system, only the portion directly affected. This provides the basis forincremental analysis, which aids development by focusing verification only on the components on which the developer is working.
A well-known compositional approach is based on assume/guarantee con- tracts where each component is annotated with a contract consisting of an as- sumptionspecifying how the component expects its environment to behave, and a guarantee specifying the behaviour guaranteed by the component if the as- sumptions hold. Contract-based specification facilitates integration not only by making expectations and assurances explicit, but also by ensuring preservation of correctness when a component with a given contract is replaced by another com- ponent whose contract conforms to or refines the first. Contract-based analysis uses the contracts to automatically establish whether a composition of compo- nents satisfy the contract of the composite component to which they belong.
Most approaches to assume/guarantee analysis (e.g., [3]) limit the scope of assumptions to component inputs and guarantees to component outputs. Fur- thermore, in many approaches the form of a contract is of the form “assuming these inputs, we guarantee these outputs”. These are two big limitations. As- sumptions and guarantees are supposed to capturebehaviour, not just individual inputs and outputs. Furthermore, both assumptions and guarantees should de- scribe “conversations” between a component and its environment, with assertions about information flowing both ways. For example, a component may assume that whenever it sends a particular output to its environment, the environment will send back some particular message as input to the component.
In this paper we address these shortcomings by we proposing anAADLan- nex sub-language for annotating components with assume/guarantee contracts and a prototype verifier that performs compositional analysis. In this sublan- guage we use the Property Specification Language,PSL, an IEEE Standard [4]
which allows the specification of behaviour combining the expressive power of ω-regular expressions and linear temporal logic (LTL), and in which both as- sumptions and guarantees can refer to inputs and outputs.
Another shortcoming of many formal approaches to analysis is that they usu- ally require an all-or-nothing commitment on the part of the developer, for ex- ample requiring a full, formal account of all components’ behaviours. We address this by supporting the notion ofviewpoints. A viewpoint represents a particular set of requirements distributed across components. The designer may annotate any given component with several contracts. All contracts sharing the same name across different components form a viewpoint. For example, the designer can define some safety viewpoints separately from some liveness viewpoints. This allows the developer to add contracts and viewpoints as the design progresses.
This notion of viewpoint is simpler than that found in [2] where the developer is required to explicitly use more complex operators to combine contracts.
2 AGCL: a sublanguage for assume/guarantee contracts
Consider the model shown in Figure 1 depicting a system consisting of a client and a server which itself consists of a front-end or mediator, and a back-end. In this common pattern, the client may issue requests via a channelreqand expects an answer on channelans. The front-end of the server receives these requests, may perform some preprocessing, and delegates the requests to the back-end server via the internal_reqchannel. When the back-end server responds on the internal_ans channel, the front-end may do some post-processing, and deliver the final answer to the client.
(a) composite (b) server
Fig. 1.A simple client-server architecture with a mediator process.
To annotate components with contracts we need to declare viewpoints, which is done at the package-level annex library as shown below (using theviewpointkey- word). Theenforcekeyword is used to inform the tool which viewpoints should be analyzed.1
1package client_server_mediator
2public
3annex AGCL {**
4 viewpoint normal_operation;
5 viewpoint alternative_operation;
6 enforce normal_operation;
7**};
8-- etc.
9end client_server_mediator;
1To keep the presentation of our example simple we show only the annex for each classifier. We also ommit the specification of the top-level process, the client and focus on the server only, and we ommit the thread type declarations with ports
2.1 Contracts for atomic components (threads)
Figure 2 shows the backend server. Its annex has abehaviourclause describing the behaviour of the actual implementation, and a contract clause defining a contract for this component within the normal_operation viewpoint. The behaviour states that whenever the server receives a request (aninevent on the reqport with some signals1), then it will produce an output on the ansport in the next state or cycle. The contract in this case has no assumptions and therefore it is simplytrue. The guarantee is that whenever the backend receives a request, it will eventually produce an answer. In this case, it should be fairly trivial that the beahviour satisfies the contract.
1 thread implementation BackendServer.impl1
2 annex AGCL {**
3 behaviour always (in req:s1 -> next out ans:s2);
4 contract normal_operation
5 assumption TRUE;
6 guarantee always (in req:s1 -> eventually out ans:s2);
7 end normal_operation;
8 **};
9 end BackendServer.impl1;
Fig. 2.Backend server.
Note that the guarantee can talk about both inputs and outputs. The same is true for assumptions. A guarantee represents an obligation on the component, whereas an assumption represents an obligation on its environment. Hence, when a guarantee states an atomic proposition labeledin, it is stating the component’s obligation to accept or receive an input. When ainatomic proposition appears in an assumption, the input direction is stated from the point of view of the component but it actually represents an output obligation from the component’s environment to the component. Similarly, anoutin a guarantee is an obligation for the component to produce output, whereas anoutin an assumption, while stated from the point of view of the component, actually represents an obligation on the environment to accept or receive input coming from the component.
Figure 3 shows the frontend. Its behaviour clause specifies that whenever an external request arrives (from the client), eventually it will reach a state where it will send a request to the backend (through the internal_req port) and from that point onwards, whenever it receives an answer from the backend, it will eventually forward the answer to the client on theexternal_ansport. The contract clause specifies as assumption that whenever it sends a request to the backend server, it will get an answer from it eventually. The guarantee states that whenever it receives an external request from the client, it will eventually send an internal request to the backend, and whenever it gets a response from the backend it will eventually send an answer back to the client. In this case it
is less trivial that the behaviour satisfies the contract, but this follows from the formal semantics ofPSL.
In general, for threads, a behaviourB satisfies a contractC = (A, G)with assumptionA and guarantee G, if the formula B∧A⇒G is valid. Intuitively, the behaviour and the assumptions must be enough to imply the guarantee. A (linear) temporal logic formula (includingPSL) isvalid if it holds in all possi- ble paths for every possible model. In our case, the premise of this implication captures the model: the guarantee will be required to be true only on those models with behaviourB, if the assumption Ais true as well. The validity of PSLformulas can be established with a model-checker (see Section 4).
1 thread implementation Frontend.impl1
2 annex AGCL {**
3 behaviour always (in external_req:s1
4 -> eventually (out internal_req:s1
5 & always (in internal_ans:s2
6 -> eventually out external_ans:s2)));
7 contract normal_operation
8 assumption always (out internal_req:s1
9 -> eventually in internal_ans:s2);
10 guarantee always (in external_req:s1
11 -> eventually out internal_req:s1)
12 & always (in internal_ans:s2
13 -> eventually out external_ans:s2);
14 end normal_operation;
15 **};
16 end Frontend.impl1;
Fig. 3.Server frontend (mediator).
AnAGCLannex can contain multiple contracts, which can be verified inde- pendently. This allows the developer to add contracts as the design progresses, and define contracts which focus only on particular aspects of interest.
2.2 Contracts for composite components (thread groups)
Figure 4 shows the server combining frontend and backend. In this case, the thread group does not have a behaviour specification, but only a contract. It’s contract doesn’t make any assumptions, but it states the guarantee that when- ever an external request comes from the client, eventually it will answer it.
The problem in this case is the following: if we already know that the subcom- ponents satisfy their respective contracts, how do we establish if the composition (theServer.impl1) satisfies its contract? This can be established as follows: let C1= (A1, G1)and C2= (A2, G2)be contracts for the two subcomponentsK1
andK2of a composite component K with contractC = (A, G). Assuming that K1 satisfies C1, and K2 satisfies C2, then K satisfies C if the following two PSLformulas are valid:
1. G0⇒GwhereG0def= G1∧G2, and
2. A⇒A0 whereA0def= (G2⇒A1)∧(G1⇒A2)
Intuitively the first one states that the guarantees of the subcomponents together must imply the guarantee of the composite. The second one states that the assumption of the composite must be enough to ensure that 1) the guarantee of the second must imply the assumption of the first, and 2) the guarantee of the first component implies the assumption of the second. This is because the subcomponents may be connected and information may flow both ways between them, and they are part of each other’s environments: the behaviour of K1’s environment is given byK2’s guaranteesG2together withK’s environment given byA. Hence, Aand G2 must implyA1. Similarly forK2. To be precise, there is a little processing that needs to be done on the formulasGi and Ai, namely we need to replace port references ocurring in atomic propositions by connector references so that they refer to the same entity, and we need to flip the direction (in/out) of those atomic propositions in assumptions for the same reason. For composite components withn subcomponents, the formulas are generalized to G0def= G1∧G2∧ · · · ∧Gnand A0def= ∧ni=1((∧j6=iGj)⇒Ai)respectively. In other words, the guarantees of all subcomponents must imply the guarantee of the composition, and the assumption of each subcomponent must be implied by the guarantees of all other subcomponents. This later requirement can be relaxed in that it is only needed that the assumption of each subcomponent must be implied by the guarantees of only those subcomponents connected to it.
In our example, K1 and K2 are Backend.impl1 andFrontend.impl1, and K isServer.impl1. As before, we establish the validity of the formulas above with a model-checker (see Section 4), and in this case they happen to be true.
1 thread group implementation Server.impl1
2 subcomponents
3 backend : thread BackendServer.impl1;
4 frontend : thread Frontend.impl1;
5 connections
6 client_req : port req -> frontend.external_req;
7 client_ans : port frontend.external_ans -> ans;
8 server_req : port frontend.internal_req -> backend.req;
9 server_ans : port backend.ans -> frontend.internal_ans;
10 annex AGCL {**
11 contract normal_operation
12 assumption TRUE;
13 guarantee always (in external_req:s1
14 -> eventually out external_ans:s2);
15 end normal_operation;
16 **};
17 end Server.impl1;
Incremental analysis is supported in the following way: if one component changes its behaviour, for example the frontend, we only need to check whether this behaviour satisfies its contract(s). If the result of this analysis is positive, then there is no need to check other components, or the validity of the composite formulas, as the contract has not changed and therefore the validity of formulas 1 and 2 is preserved. If the result of this analysis fails, then the developer needs to either modify the behaviour or the contract for the component in question. If the contract for a component changes then one must re-analyze that component (recursively if it is a composite component) and then re-evaluate the implications G0⇒G and A⇒A0 as above, but there is no need to re-analyze components which have not changed or whose contract has not changed, as they would not change the validity of these formulas.
2.3 Conformance
Contracts can annotate not only implementations but also types. This opens a set of closely related problems that need be addressed. The first one is this: if we have a component implementationK of typeT and K has a contractCK= (AK, GK) andT is annotated with contract CT = (AT, GT), how do we know thatCK conforms toCT? This can be answered by checking two implications:
GK⇒GT andAT⇒AK. Note that the implication is covariant on guarantees and contravariant on assumptions. For guarantees, this is because the guarantee of the type must be a guarantee of any of its implementations: the set of possible observable behaviours described inGK must be a subset if the set of behaviours defined by GT, otherwise there would be at least one behaviour guaranteed by the implementation which does not conform to what the type prescribes. For assumptions the direction is contravariant because the set of behaviours specified byAT must be a subset of the set of behaviours specified byAK. If this wasn’t required, there would be at least one environment behaviour acceptable byAT
but not byAK which would entail that componentK would not be able to be placed in some composite components expecting typeT.
The other related problems occur when an implementation extends another implementation or a type extends a type and both have contracts in the same viewpoint. These cases can be handled as the above: ifK0 (orT0) has contract C0 = (A0, G0)and it extends K (resp.T)with contractC = (A, G), then con- formance can be established by checking the validity ofG0⇒G andA⇒A0.
3 Relation between PSL sequences and AADL behaviours
A key issue in the use of a specification language or temporal logic such asPSLto describe behaviours and contracts ofAADLmodels is the correspondance be- tween the semantics ofPSLexpressions and the behaviour of theAADLmodel which they intend to describe. However, there is a fundamental obstacle: the core AADLstandard doesn’t define a unique way of specifying behaviour. It is up to annexes or external languages to provide the implementation of a component and
therefore it is not possible to define a general correspondance, but only consider specific types of implementation. One such possibility is to use the behaviour annex where the implementation is defined as a kind of (hierarchical) state ma- chine. In this paper we do not assume any particular formalism, annex or type of implementation. Nevertheless, if behaviour is specified with the behaviour annex or a similar state-based formalism, we can infer thePSL behaviour specifica- tion from such state machine using standard transformations (e.g., automata to regular expression, [7]) and then apply the analysis algorithms as described. Al- ternatively, we could use the behaviour clause itself to infer an automaton that implements it, using well-known algorithms that can transform such expressions and formulas into automata (e.g., [7,8]).
Another way of relating thePSLspecifications with the behaviour ofAADL components is to establish a correspondance with the thread semantics defined by theAADLstandard ([6] Subsection 5.4).
APSLexpression is evaluated with respect to a path or sequence of states labelled with the atomic propositions which are true in such state. Given a sequence, a PSL expression may hold strongly, hold, be pending or fail. The expression holds strongly when it contains no bad states, all future obligations have been met, and the expression holds on all extensions to the sequence. The expression holds (but does not hold strongly) when it contains no bad states, all future obligations have been met, and the expression may or may not hold on any given extension of the path. The expression is pending when it contains no bad states, but future obligations have not been met, and the expression may or may not hold on any given extension of the path. Finally, the expression fails when there is some bad state in the path, future obligations may or may not have been met and the expression will not hold on any extension of the path.
Additionally, a PSL expression is evaluated with respect to a clock context, a boolean expression that determines in which cycles the expression is to be evaluated. ThePSLstandard does not specify any particular time granularity or what counts as a cycle or clock tick. It is up to verification tools to decide.
The default context is true so that the expression is evaluated at every cycle.
There are several alternative ways to establish a correspondance between these paths and cycles and the states of anAADL thread. One possibility, is to consider a cycle every time the thread is dispatched. This is the natural choice when the thread is periodic. For aperiodic threads it is also possible to consider a cycle when the thread is dispatched, but in this case the dispatch occurs only when an event arrives at a port. For sporadic, timed or hybrid threads, the cycle would occur either by an event or by the specified period. If one adopts such convention, then the designer must be aware that the meaning of thePSLexpressions depend on the type of thread. For example, the formula a∧Xbasserting thataholds in the current cycle andbholds in the next cycle means, for a periodic thread, thataholds at the current timetaccording to the clock, andbholds at timet+pwherepis the thread’s period. On the other hand, for an aperiodic thread the formula would mean that when an event arrives to one of the thread’s ports, holds, and will hold the next time an event arrives.
If we are using the behaviour annex to specify implementations, the choice of associating cycles with dispatches may lead to the traditional interpretation of temporal operators with respect to automata, where “next” does really mean the next state. Since the behaviour annex allows for hierarchical state machines, by
“state” we would mean a state in the flattened state machine, with a particular assignment of variables to values.
Another possibility is to treat all kinds of threads in the same way, as peri- odic threads,i.e., assuming that there is an underlying periodic clock, even for aperiodic threads. In this case, there must be a way for the verification tool to obtain the current state of a thread at any timetof this underlying clock.
Since there are several possibilities, none of which seems to bea priori any more fundamental than the others, it is up to the developer to decide which interpretation ofPSLexpressions is more suitable.
4 An AGCL analysis tool
We have implemented a prototype of theAGCL annex and the analyses out- lined in the previous sections as a plugin forOSATE. The tool allows the user to apply the analyses outlined in this paper, providing results sorted by either view- point or by component. When the result of a particular analysis fails, a counter- example is generated by the model checker. Our plug-in uses theNuSMVmodel- checker to check the validity of the formulas in question, but the underlying architecture can easily be extended to support other model-checkers.
A model-checker receives as input a model and a specification (temporal logic formula) and decides whether the model satisfies the formula or not. A model- checker can be used to check validity by checking the formula against auniversal model for the formula, this is, a model that contains all possible states and tran- sitions about which the formula could talk. For example, if a formula contains three atomic propositions, the universal model has three boolean variables and therefore eight states, all of which are initial, and all possible transitions be- tween them. Such universal model contains every possible model of the formula embedded in it, and therefore every possible path. A linear temporal formula is valid if it holds in every path of every model, hence, it is valid if it holds in every path of the universal model. On the other hand, if there is at least one path in the universal model for which the formula doesn’t hold, then there exists at least one model for which the formula doesn’t hold and therefore the formula is not valid.
In terms of complexity, dealing with universal models might appear un- tractable, but the size of such models depends only on the size of the formulas (the number of atomic propositions) and not on the size of the state space of the components themselves. This observation combined with the fact that contracts don’t need to describe all aspects of behaviour, and can be specified in separate viewpoints and analyzed independently makes the technique feasable.
5 Final remarks
We have sketeched an approach to specify and verify assume/guarantee con- tracts forAADLcomponents and briefly discussed the kinds of analyses that can be performed and discussed our prototype implementing these. Given the space limitations we are unable to provide here the actual algorithms and their proof of correctness, but these are available in detail as a technical report [5].
The theory behind this work is based on [1] which developed a generic theory of contract-based reasoning applicable to a wide range of specification formalisms.
In our technical report we extended and specialized that theory toPSL, show- ing in particular that when using PSL we can compose contracts, the basis for the compositional analysis. Our approach differs from other compositional techniques such as [3] in that we do not restrict assumptions to inputs and guar- antees to outputs. Furthermore, with viewpoints, we make it possible to divide requirements into sets of smaller contracts, providing the developer with flexi- bility as well as making automatic verification more feasible. While this work is preliminary and we have yet to test the plugin on large-scale models, we be- lieve our early results show promise, and contract-based analysis can provide a fundamental support to the development process of DRE systems.
References
1. S. S. Bauer, A. David, R. Hennicker, K. G. Larsen, A. Legay, U. Nyman, and A. Wasowski. Moving from specifications to contracts in component-based design.
In Juan de Lara and Andrea Zisman, editors,Fundamental Approaches to Software Engineering - 15th International Conference, FASE 2012, Held as Part of the Euro- pean Joint Conferences on Theory and Practice of Software, ETAPS 2012, Tallinn, Estonia, March 24 - April 1, 2012. Proceedings, volume 7212 ofLecture Notes in Computer Science, pages 43–58. Springer, 2012.
2. A. Benveniste, B. Caillaud, A. Ferrari, L. Mangeruca, R. Passerone, and C. Sofronis.
Multiple viewpoint contract-based specification and design. In Frank S. de Boer, Marcello M. Bonsangue, Susanne Graf, and Willem P. de Roever, editors,FMCO, volume 5382 ofLNCS, pages 200–225. Springer, 2007.
3. D. D. Cofer, A. Gacek, S. P. Miller, M. W. Whalen, B. LaValley, and L. Sha.
Compositional verification of architectural models. In Alwyn Goodloe and Suzette Person, editors,NASA Formal Methods, volume 7226 ofLecture Notes in Computer Science, pages 126–140. Springer, 2012.
4. IEEE Computer Society. IEEE Standard for Property Specification Language (PSL). IEEE Standard 1850TM-2010, June 2012.
5. E. Posse. Contract-based compositional analysis for reactive sys- tems in RTEdgeTM, an AADL-based language. Tech. Rep. 2013- 607, School of Computing – Queen’s University, August 2013.
http://research.cs.queensu.ca/TechReports/Reports/2013-607.pdf.
6. SAE International. Architecture Analysis & Design Language (AADL). SAE Stan- dard AS5506b, 10 September 2012.
7. M. Sipser. Introduction to the Theory of Computation. PWS Publishing, 1997.
8. P. Wolper. The Tableau Method for Temporal Logic: An Overview. Logique et Analyse, 28(110–111):119–136, June–September 1985.
An Extension for AADL to Model
Mixed-criticality Avionic Systems Deployed on IMA architectures with TTEthernet
Tiyam Robati1, Amine El Kouhen1, Abdelouahed Gherbi1, Sardaouna Hamadou2, and John Mullins2
1 Dept. of Software and IT Engineering, ´Ecole de Technologie Suprieure, Canada {tiyam.robati.1@ens.etsmtl.ca, amine.elkouhen@etsmtl.ca,
abdelouahed.gherbi@etsmtl.ca}
2 Dept. of Computer and Software Eng, Ecole Polytechnique de Montreal, Canada {firstname.lastname@polymtl.ca}
Abstract. Integrated modular avionics architectures combined with the emerging SAE TTEthernet standard provides a strong infrastructure for the deployment of mixed-critical avionic applications having stringent safety, reliability and performance requirements. The integration of such systems is a very complex and challenging engineering task. Therefore, a model-based approach, which endows system engineers with a method- ology and the supporting tools to cope with this complexity, is of a paramount importance. In this research paper, we present an extension for the standard architecture and analysis modeling language AADL to enable modeling integrated multi-critical avionic applications deployed on TTEthernet-based IMA architectures. In particular, we present a metamodel which extends the core AADL metamodel with concepts and constraints relevant for this domain, we define the concrete textual syn- tax for this extension and we outline the implementation of this extension using the Open Source AADL Tool Environment (OSATE). Finally, we illustrate our AADL extension using a case study based on the Flight Management System.
Keywords: AADL, Time-Triggered Ethernet, AFDX, IMA
1 Introduction
On-board avionic systems are safety-critical systems which should meet strict safety, reliability and performance requirements. These systems have tradition- ally been engineered using what is called a federated architectures approach, where each function is designed and deployed to use its exclusive resources. This approach is however costly in terms of equipments and wiring. The Integrated Modular Avionics (IMA) architecture is an alternative approach, which is based a consolidation of resources [22]. This is achieved through resources sharing between functionalities. With IMA different avionic functions having different criticality levels (e.g. control functions and comfort functions) share the same
hardware resources leading to mixed-criticality systems. Moreover, IMA archi- tectures are distributed using a communication infrastructure, which should also be able to meet the same level of safety and performance requirements.
Ethernet is a widely used standard network (IEEE 802.3) which is not only used as infrastructure for classic office systems but is increasingly supporting industrial and embedded systems due to the high bandwidths it provides. How- ever, Ethernet does not meet strict time and safety critical applications. Several extensions to enhance the predictability of Ethernet have been developed. One of these extensions is the Avionic Full Duplex AFDX standard ARINC 664 [11].
AFDX is a deterministic real-time extension of Ethernet based on an static bandwidth scheduling and control using the concept of virtual links. The SAE standard TTEthernet [3] is the most recent Ethernet extension based on the time-triggered communication paradigm [14] [19] to achieve bounded latency and low jitter. A TTEthernet network implements a global time using clock synchronisation and offers fault isolation mechanisms to manage channel and nodes failures. TTEthernet integrates three data flow: Time-Triggered (TT) data flow which is the higher priority traffic; Rate Constrained (RC) traffic, which is equivalent to AFDX traffic, and Best Effort (BE) traffic. This makes TTEth- ernet suitable for mixed-criticality applications such as avionic and automotive applications where highly critical control functions such as a flight management system cohabit with less critical functions such as an entertainment system.
The focus of this research work is on avionic applications deployed on IMA architectures interconnected using TTEthernet. The advantages of this infras- tructure are numerous. First, the IMA modules enable the resource sharing.
Second, the combination of IMA and TTEthernet enables the error isolation provided not only at the level of the modules through the partitioning but also the level of the network using different data traffics and the concept of virtual links. Third, TTEthernet enable the safe integration of data traffics with dif- ferent performance and reliability requirements. However, these systems are on the other hand complex and the integration of diverse applications with mixed- criticality levels having strict real-time requirements is very challenging. In order to control the complexity of such systems, a model-based approach, which pro- vides the systems engineers with a methodology and the supporting tools to accomplish correctly and efficiently this integration, is required. A key element of such approach is a modeling language which allows the engineers to express the system at a convenient level of abstraction and to interface with sophisti- cated formal analysis techniques to verify safety and performance properties of the system.
AADL is a well-established standard modeling language in the domain of real- time critical systems. AADL has been extended to support the modeling of IMA with an Annex ARINC 653 [2]. However, there is no support for AADL to model the networking of IMA modules through the recent technology TTEthernet.
We present in this paper an extension for AADL to support the modeling of IMA architectures interconnected using TTEthernet. In particular, we present a metamodel for the domain of IMA and TTEhernet. We provide a concrete
textual syntax based on this metamodel, which enables the system engineers to describe a full IMA-based avionic systems interconnected with TTEthernet. We have implemented this extension in the framework of the Open Source AADL Tools (OSATE2)[5] . We illustrate the expressiveness of this extension through it application to model a subsystem of the the Flight Management System [18].
This paper is organized as follows: In Section 2, we introduce the concepts of IMA and the main features of the TTEthernet standard. We describe in Section 3 the main components of the proposed extension metamodel and discuss the rational behind its design. We outline the implementation of the proposed extension in the framework of OSATE in Section 4. We show the application of the proposed extension with an illustrative example in Section 5. In Section 6, we succinctly review the most close related research works to ours. We conclude the paper and outline our ongoing and future research work in Section 7.
2 Background
In order to make this paper as self-contained as possible, we briefly introduce in this section the main concept of IMA and TTEthernet.
2.1 Integrated Modular Avionic Architecture (IMA)
The main idea underlying the concept of IMA architecture [22] is the sharing of resources between some functions while ensuring their isolation to prevent any interference between them. Resource sharing reduces the cost of large volume of wiring and equipment while the non interference guarantee is required for safety reasons. The IMA architecture is a modular real-time architecture for avion- ics systems defined in the standard ARINC653 [12]. Each functionality of the system is implemented by one or a set of functions distributed across different modules. A module represents a computing resource hosting many functions.
Functions deployed on the same module may have different criticality levels. For safety reasons, the functions must be strictly isolated using partitions. The par- titioning of these functions is two dimensional: spatial partitioning and temporal partitioning. The spatial partitioning is implemented by assigning statically all the resources for the partition being executed in a module and no other partition can have the access to the same resources at the same time. The temporal par- titioning is rather implemented by allocating a periodic time window dedicated for the execution of each partition.
2.2 Time-Triggered Ethernet (TTEthernet)
The new SAE Time-Triggered Ethernet standard (TTEthernet) [3] specifies time-triggered services extending the Ethernet IEEE standard 802.3. TTEther- net is based on the Time-triggered communication paradigm [13] and therefore establishes a system-wide time base implemented through a synchronisation of the clocks of the end systems and switches. This results in bounded latency and
low jitter. TTEthernet integrates both time-triggered and event-triggered com- munication on the same physical network. TTEthernet limits latency and jitter for time-triggered (TT) traffic, limits latency for rate constrained (RC) traffic, while simultaneously supporting the best-effort (BE) traffic service of IEEE 802.3 Ethernet. This allows application of Ethernet as a unified networking infrastruc- ture. It supports therefore the deployment of mixed-criticality applications at the network level.
3 Metamodel Extending AADL capability to model TTEthernet
In this section, we present the metamodel for our extention to AADL in order to support the modeling of TTEthernet, which will henceforth be called the AADL-TTEthernet metamodel. This meta-model captures the main concepts and characteristics of the TTEthernet standard. The AADL-TTEthernet meta- model will enable building a set of tools to perform the design and analysis of distributed IMA architectures using TTEthernet as communication infrastruc- ture. We have designed the AADL-TTEthernet metamodel using the Eclipse Modeling Framework (EMF), which is also used to specify the AADL Core metamodel. This allows for a seamless integration of the AADL-TTEthernet in OSATE2 environment [5] in terms of dependencies and embedded Java API.
On the other hand, using the same mechanism (i.e. Ecore) to specify the two metamodels eases the expression of the domain concepts dependencies and sim- plifies the navigation between them. This mechanisim also has been used in other works [17] aim at implementing new annex and extension to AADL. Our
AadlTTE
Aadl2 AADLcMeta-Modelc(EMF)
AADL-TTEthernetcMeta-Modelc(EMF) AnnexSubClause NamedElement
TTEthernetAnnex TTEthernetNamedElement
AnnexSubClausec javacclass
TTEthernetAnnex javacclass
extends produces
Fig. 1.AADL-TTEthernet meta-model dependencies
AADL-TTEthernet metamodel describes the structural aspect of a distributed IMA systems interconnected using TTEthernet and makes explicit all concepts
specified by this standard. The EMF framework generates automatically the Java implementation classes corresponding to the metamodel objects as it is shown in Figure 1. In order to extend AADL with our metamodel it is required to attach a TTEthernet model to an AADL component and to link the objects of our TTEthernet extension with AADL core objects. This is achieved by the implementation of the OSATE2 extension mechanism, which requires to link the TTEthernetAnnex concept in our metamodel to the AnnexSubclause concept of the AADL core as it is shown in Figure 1. This figure shows also how we use the EMF/Ecore inheritance mechanism to express the dependencies between the two metamodels. Consequently, aTTEthernetAnnex extends anAnnexSubclause and anTTEthernetNamedElementextends aNamedElement. In the metamodel, the TTEthernetAnnex concept, which links as shown in Figure 2 the metamodel to the AADL core metamodel, represents the overall model of a TTEhernet- networked IMA system which will undergoes different analysis to verify safety and performance properties. The global information about the network elements and the underlying implementation is described in the TTEthernetAnnex con- cept. TheTTEthernetAnnex is composed of the following (Figure 2):
ProcessingResource Channel
TTEthernetAnnex
Scheduler VirtualLink
NamedElement RfromDaadl2) TTEthernetNamedElement
AnnexSubClause RfromDaadl2)
SynchronizationDomain domains 1..*
channels
0..* 0..*virtualLinks
processingResources0..*
scheduler 1 Connection
RfromDaadl2) connections 0..*
1 1
source destination
Fig. 2.AADL-TTEthernet meta-model overview
1. TheSynchronization domainsconcept of TTEthernet standard. TTEthernet supports system-of-system communication by introducing Synchronization domains andSynchronization priorities as shown in Figure 3.Synchroniza- tion domainsspecify independent subsystems with respect to their synchro- nization. All the resources configured to belong to the same synchronization domain should synchronize with each other and components belonging to different synchronization domains in one TTEthernet network do not syn- chronize their local clocks.
2. The Scheduler is the entity in TTEthernet that is capable of producing a schedule, which should be compliant with the scheduling constraints of TTEthernet. These constraints are depicted in figure 3. The scheduler of TTEthernet request specific constraint which are presented mathematically
in [21]. These constraints are mentioned in figure 3 as constraints type which is related to constraint class.
3. The Processing Resources represent active hardware components in a net- work. They can beComputing Resources such asModules(i.e. end systems) or Networking Resources such as switches as shown in Figure 4. All pro- cessing resources havefeatures which can be parameters, access to physical buses, or ports (i.e, interfaces for frames inputs and outputs). A processing resource can be a synchronization master and can then transmits its local time to synchronize the whole network as shown in Figure 3. Several process- ing resources can be aggregated into logical groups called clusters as shown in Figure 4. ACluster is associated with one synchronization domain. Each single cluster can establish and maintain synchronization by itself.
ConstraintType BoundedSwitchMemory EndToEndTransmission ApplicationLevel DomainSpecific PathDependent SimultaneousRelay ContentionFree ProtocolControlFlow
<<enumeration>> Scheduler
scheduler 1
Constraint Type<:<ConstraintType
constraints 0..g
Schedule 1..g
schedules
ProcessingResource processingResources TTEthernetAnnex SynchronizationDomain 0..g
SynchronizationPriority level<:<Integer
priorities 1..g
domains synchronizationMaster<:<Boolean 1..g
compressionMaster<:<Boolean
schedule 1
Fig. 3.Synchronization elements
The AADL-TTEthernet metamodel captures the different possible links between the components of a TTEthernet Network. These links can be either physical ones such as connections or logical ones such as channels or virtual links.
– A Connection is a link between two physical ports, usually realized as a copper or optical fiber cable. A connection may be unidirectional or bidirec- tional.
– A Channel is a logical connection from one source processing resource to another processing resource destination. A Channel is defined to map multi- cluster architectures.
– AVirtual Link is a logical link defined by ARINC 664 standard [11]. Each virtual link is associated with a dedicated maximum bandwidth, specified
ProcessingResource
Switch
ComputingResource
Cluster
NetworkingResource
processingResources 0..*
Module
partitions 0..*
Partition protocolX:XProtocolType
ProtocolType TTP AFDX
<<enumeration>>
Fig. 4.Processing resources
by the minimum frame interval, called bandwidth allocation gap, and the maximum frame length.
TheSchedulable Resources represents all the elements which are managed using the network scheduler. These resources can be the partitions hosted by module, the data transferred through the network (i.e, Frames), the networks commu- nication channels or the virtual links as shown in Figure 5. A Frame is unit
SchedulableResource Schedule
Frame
Channel VirtualLink Partition
schedulableResources 0..*
virtualLink frames 0..1
0..* frames
0..*
Fig. 5.Schedulable resources
of transmission, a data packet of fixed or variable length, encoded for digital transmission over a communication link as depicted in Figure 6. Considering its order of priority, a frame could be Protocol Control Frame (PCF), TT frame, Rc frame orBE frame.
4 Implementation of the TTEthernet Extension for AADL
4.1 Textual Syntax for the TTEthernet Extention for AADL
The definition of a textual syntax is provided by a grammar (i.e, a set of rules which define the composition of a language). In order to translate the textual syntax to its corresponding model, a lexer, a parser as well as a component for the semantical analysis (type checking, resolving of references, etc.) are required.
Frame lengthw:wInteger periodw:wInteger multicastw:wBoolean
BestEffortFrame RateConstrainedFrame TimeTriggeredFrame ProtocolControlFrame offsetw:wInteger
transmissionRatew:wInteger typew:wPCFType
PCFFType ColdStart ColdStartAcknowledge Integration
<<enumeration>>
Fig. 6.Frame kinds
The backward transformation, from model to text, is provided by an emitter. All the components can be generated using the grammar⇐⇒meta-model mapping definition [10]. Figure 7 demonstrates the selected framework to define textual syntax of our extension. It employs the data provided by the mapping definition used to generate the parser, emitter and an editor for the corresponding language to the metamodel. This editor can then use the generated parser and emitter to modify the text and the model. Therefore it is responsible for keeping the text and the model in sync, e.g., by calling the parser upon any changes on the text. Based on this mapping definition, several features of the editor can be generated, such as syntax highlighing, autocompletion or error reporting. To
Editor Emitter
Metamodel
Model Grammar
TextDArtifact
TextualDSyntaxDFramework
LexerDDDDDDDDDParserDDDDDDAnalyzer GeneratedDTextualDSyntaxDTools
reads
generates
references MappingDDefinition references
reads
manipulates reads manipulates
parses creates/
updates reads
emits
instanceDof
instanceDof
Legend artifact activeDcomp.
r/wDaccess dependency instanceDof communication
Fig. 7.General structure of a textual syntax framework
build the textual editor tool for our AADL-TTEthernet extension, we used the xText framework [8]. It implements the textual syntax according to an extended BNF. Figure 8 shows an excerpt of this xText grammar. In this xText framework, the AADL-TTEthernet metamodel concept is mapped to a Java implementation, where the TTEthernet objects names are used as class names. All attributes are implemented as private fields and public get- and set- methods. The composition relationships are realized in the same way as attributes and contribute to the constructor of the class. All classes support the Visitor pattern [9] to traverse the abstract syntax along the composition relationships [15].
The analyzer module scans the Abstract Syntax Tree (AST) and checks the semantics of the AADL-TTEthernet model. First, it proceeds to a resolution phase (e.g, naming resolver), which links TTEthernet objects to their corre- sponding AADL objects. In order to achieve this phase, we use the visitors (e.g, java classes) provided by OSATE2 to retrieve AADL objects. For the sake of the implementation of our AADL-TTEthernet extension, we have developed the visitors required to navigate through the AADL-TTEthernet AST. This phase adds information to the AST and makes its use easier.
1 grammar o r g . o s a t e . t t e t h e r n e t . x t e x t . A a d l t t e 2
3 import ” h t t p : / / ca . e s t m t l . a a d l 2 / a a d l t t e / 1 . 0 ” 4 import ” h t t p : / / a a d l . i n f o /AADL/ 2 . 0 ” as a a d l 2
5 import ” h t t p : / /www. e c l i p s e . o r g / emf /2002/ Ecore ” as e c o r e 6
7 P a r t i t i o n returns P a r t i t i o n : 8 ’ P a r t i t i o n ’ name = ID
9 ’ f r a m e s ’ ’ : ’ f r a m e s += Frame∗ 10 ’ end ’ ID ’ ; ’ ;
11 Frame :
12 RateConstrainedFrame | TimeTriggeredFrame | B e s t E f f o r t F r a m e
| P r o t o c o l C o n t r o l F r a m e 13 ;
14 S y n c h r o n i z a t i o n P r i o r i t y returns S y n c h r o n i z a t i o n P r i o r i t y : 15 ’ S y n c h r o n i z a t i o n P r i o r i t y ’ name = ID
16 ’ l e v e l ’ l e v e l = I n t e g e r ’ ; ’ 17 ’ end ’ ID ’ ; ’ ;
Fig. 8.xText grammar overview for AADL-TTEthernet
4.2 Integration of the AADL-TTEthernet Compiler to OSATE2 Sublanguages are included into AADL specifications as annex subclauses. The latter may be inserted into AADL component types and AADL component im- plementations of an AADL model. OSATE2 currently provides four extension points that can be used to integrate a sublanguage into the tool environment.
These extension points are designed to support parsing, unparsing, name reso- lution / semantic checking, and instantiation of annex models. From the AADL- TTEthernet EMF meta-model in the EMF framework, we generate the AADL- TTEthernet builder factory to build and manipulate TTEthernet objects used in the compiler. The compiler plug-in contains two modules: a parser/lexer and an analyzer. The integration of the AADL-TTEthernet plug-in is a two-steps pro- cess. First, we link the AADL-TTEthernet plug-in to the OSATE2 annex plug-in
using the Eclipse extension points mechanism. The annex plug-in defines exten- sion points which allow to plug-ins be connected together as depicted in Figure 9. Second, we have to register our parser in the OSATE2 annex registry. As the AADL-TTEthernet metamodel becomes a part of the AADL description and the AADL-TTEthernet textual syntax tool is connected to OSATE2 registry, the AADL-TTEthernet plug-in is directly integrated and driven by OSATE2.
Legend plug-in active2comp.
extends compliant extension
Unparser222222Parser222222Analyzer AADL-TTEthernet2Metamodel
Unparser222222Parser222222Analyzer AADL22Metamodel AADL-TTEthernet
OSATE2
Fig. 9.AADL-TTEthernet plug-in integrated to OSATE2
5 An Example: A Model of a Subsystem of the Flight Management System
In this section, we illustrate the modeling of a distributed IMA system based on TTEthernet as a communication network using our extension for AADL. In or- der to do so, we use as a subsystem of the Flight Management System presented in [18]. This subsystem controls the display of static navigation information in the cockpit screens. The structure of the considered FMS subsystem in terms of modules and the partitions they host is shown in Figure 10. In the original ver- sion of the system considered in [18], the system is interconnected using AFDX.
In our context, the modules are instead interconnected using TTEthernet. The AFDX data traffic in the original system corresponds to the RC traffic in the TTEthernet context. Table 1 shows a subset of the virtual links used in the FMS subsystem with their corresponding characteristics including the Bandwidth Al- location Gap (BAG), the sender modules of the VLs and the corresponding receiver modules. This subsystem can be modeled using our TTEthernet ex- tension for AADL as follows. The extension is a sub-language for AADL, which can be included in system implementation of the AADL model of this system.
The concrete textual syntax of AADL-TTEthernet extension provides several new reserved words, which correspond to the main concepts of the metamodel described previously, such as module, switch, partition, connection, virtual link,
Fig. 10.A Subsystem of the Flight Management System Virtual Link Source Destination BAG Direction
V L1 KU1 F M1, F M2 32 {S1, S2},{S1, S3} V L2 KU2 F M1, F M2 32 {S1, S2},{S1, S3} V L3 F M1 M F D1 8 {S2, S1}
Table 1.Virtual Links details
Time-triggered frame, Rate Constraint frame and Best Effort frame. An excerpt of the model of the FMS subsystem using our AADL-TTEthernet is shown in Figure 11. The full specification of the model can be downloaded at [20].
6 Related Work
AADL presents two extension mechanisms, namely the property sets and the sublangues (i.e. annex). Several AADL extensions based on these mechanisms are now standardized as official annexes. These include the Data modeling annex, ARINC653 annex, the AADL Behavor Annex [2] , and Error Model Annex [1].
In addition, some research work have focused on extending the language using these extension mechanisms or investigating alternative ways. The most close research works to ours are reported in [7] and [17] . J. Delange et al. [7] present an approach based on AADL, which covers the the modeling, verification and implementation of ARINC653 systems. The authors describe in the work the modeling guidelines elaborated in the ARINC653 annex of the AADL standard.
This approach is supported by a tool chain composed of Ocarina AADL toolsuite, AADL/ARINC653 runtime POK and Cheddar scheduling tool. G Lasnier et al.
[17] present an implementation of the AADL behavior annex as an extension plug-in to the OSATE 2. We have implemented our AADL TTEthernet extension using similar techniques. M. lafaye et al. [16] define a modeling approach based
Fig. 11.Flight Management Subsystem Model using AADL TTEthernet Extension
on AADL and SystemC, which aims at the design and dynamic simulation of a IMA-based avionics platform. This is component-based approach, which can be used to dimension the architecture taking into consideration the application to be deployed while achieving early platform validation. De Niz and Fieler discuss in [6] how to extend the AADL language to include new features for the separation of concerns (i.e. Aspects). Based on this research work, it seems that the AADL extension mechanisms do not support the separation of concerns and new aspect- like constructs and mechanisms are then investigated. G. Brau et al. present in [4]
a model of a subsystem of Flight Management System using AADL and show how to establish important parameters in the AADL model including the virtual links characteristics for instance. To the best of our knowledge, there is no published research work, which addresses the modeling of the TTEthernet standard as networking infrastructure for IMA architecture, which is the contribution of this work.
7 Conclusions and Future Work
The IMA architecture combined with the new SAE standard TTEthernet as communication infrastructure provide a strong platform for the deployment of distributed avionic applications. The integration of mixed-criticality applications on such platforms is a complex and challenging engineering activity. A model-
based approach based on the SAE standard architecture language AADL pro- vides the system engineers with the tools to cope with this complexity. Modeling TTEthernet infrastructure using AADL is the research gap that we are target- ing in this work. We have presented in this paper our contribution to address this issue, which consists in an extension for the standard architecture and anal- ysis modeling language AADL to enable modeling integrated mixed-criticality avionic applications deployed on TTEthernet-based IMA architectures. In our ongoing research work, we aim at formalizing this extension in the form of a new annex through the SAE standardization process. Moreover, we aim at defining a formal semantics for our extension to allow transforming the AADL models built using our extension to models that are suitable for analysis techniques that can be used to verify relevant safety and performance properties.
References
1. SAE Aerospace. SAE Architecture Analysis and Design Language (AADL) Annex Volume 1: Annex A: Graphical AADL Notation, Annex C: AADL Meta-Model and Interchange Formats, Annex D: Language Compliance and Application Program Interface Annex E: Error Model Annex,AS5506/1, 2011.
2. SAE Aerospace. SAE Architecture Analysis and Design Language (AADL) Annex Volume 2: Annex B: Data Modeling Annex Annex D: Behavior Model Annex Annex F: ARINC653 Annex, AS5506/2, 2011.
3. SAE Aerospace. Time-Triggered Ethernet, sae as6802 edition, 2011.
4. Guillaume Brau, J´erˆome Hugues, and Nicolas Navet. Refinement of aadl models using early-stage analysis methods: An avionics example. Technical Report TR- LASSY-13-06, Laboratory for Advanced Software Systems, 2013.
5. CMU/SEI. Open source aadl tool environment (osatev2). http://www.aadl.info, 2014.
6. Dionisio De Niz and Peter H Feiler. Aspects in the industry standard aadl. In Proceedings of the 10th international workshop on Aspect-oriented modeling, pages 15–20. ACM, 2007.
7. Julien Delange, Laurent Pautet, Alain Plantec, Micka¨el Kerboeuf, Frank Singhoff, and Fabrice Kordon. Validate, simulate, and implement arinc653 systems using the aadl. InACM SIGAda International Conference on Ada, pages 31–44. ACM, 2009.
8. S. Efftinge. Xtext reference documentation.
http://www.eclipse.org/gmt/oaw/doc/4.1/r80xtextReference.pdf, 2006.
9. Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Pat- terns: Elements of Reusable Object-oriented Software. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1995.
10. Thomas Goldschmidt, Steffen Becker, and Axel Uhl. Classification of concrete textual syntax mapping approaches. In Ina Schieferdecker and Alan Hartman, editors,Model Driven Architecture - Foundations and Applications, volume 5095 ofLecture Notes in Computer Science, pages 169–184. Springer Berlin Heidelberg.
11. Aeronautical Radio Incorporated. ARINC Report 664P7-1 Aircraft Data Network, Part 7, Avionics Full-Duplex Switched Ethernet Network. AEEC, Maryland, USA, 2009.
12. Aeronautical Radio Incorporated.ARINC Report 653P0 Avionics Application Soft- ware Standard Interface, Part 0, Overview of ARINC 653, 2013.
13. G. Kopetz, Hermann; Bauer. The time-triggered architecture. volume vol.91, no.1, pp.112,126. Proceedings of the IEEE, 2003.
14. Hermann Kopetz and G¨unther Bauer. The time-triggered architecture.Proceedings of the IEEE, 91(1):112–126, 2003.
15. Holger Krahn, Bernhard Rumpe, and Steven Vlkel. Integrated definition of ab- stract and concrete syntax for textual languages. In Gregor Engels, Bill Opdyke, DouglasC. Schmidt, and Frank Weil, editors,Model Driven Engineering Languages and Systems, volume 4735 of Lecture Notes in Computer Science, pages 286–300.
Springer Berlin Heidelberg.
16. Micha¨el Lafaye, David Faura, Marc Gatti, and Laurent Pautet. A new modeling approach for ima platform early validation. InProceedings of the 7th International Workshop on Model-Based Methodologies for Pervasive and Embedded Software, pages 17–20. ACM, 2010.
17. Gilles Lasnier, Laurent Pautet, J´erˆome Hugues, and Lutz Wrage. An implemen- tation of the behavior annex in the aadl-toolset osate2. InIEEE ICECCS, pages 332–337. IEEE Computer Society, 2011.
18. M.Lauer. Une m´ethode globale pour la v´erification d’exigences temps r´eel- application ´a l’avionique modular intgr´ee, 2012. Thse de Doctorat, Institut Na- tional Polytechnique de Toulouse.
19. Roman Obermaisser. Event-triggered and time-triggered control paradigms, vol- ume 22. Springer, 2004.
20. Tiyam Robati, Amine El Kouhen, and Abdelouahed Gherbi. Flight management subsystem model using aadl ttethernet extension.
http://profs.etsmtl.ca/agherbi/ima.aadl, 2014.
21. W. Steiner. An evaluation of smt-based schedule synthesis for time-triggered multi-hop networks. volume vol., no., pp.375,384. Real-Time Systems Symposium (RTSS), IEEE 31st, 2010.
22. Christopher B Watkins and Randy Walter. Transitioning from federated avionics architectures to integrated modular avionics. InDigital Avionics Systems Confer- ence, 2007. DASC’07. IEEE/AIAA 26th, pages 2–A. IEEE, 2007.
