Model-based engineering of widgets, user applications and servers compliant with ARINC 661 specification

International audienceThe purpose of ARINC 661 specification [1] is to define interfaces to a Cockpit Display System (CDS) used in any types of aircraft installations. ARINC 661 provides precise information for communication protocol between application (called User Applications) and user interface components (called widgets) as well as precise information about the widgets themselves. However, in ARINC 661, no information is given about the behaviour of these widgets and about the behaviour of an application made up of a set of such widgets. This paper presents the results of the application of a formal description technique to the various elements of ARINC 661 specification within an industrial project. This formal description technique called Interactive Cooperative Objects defines in a precise and non-ambiguous way all the elements of ARINC 661 specification. The application of the formal description techniques is shown on an interactive application called MPIA (Multi Purpose Interactive Application). Within this application, we present how ICO are used for describing interactive widgets, User Applications and User Interface servers (in charge of interaction techniques). The emphasis is put on the model-based management of the feel of the applications allowing rapid prototyping of the external presentation and the interaction techniques. Lastly, we present the CASE (Computer Aided Software Engineering) tool supporting the formal description technique and its new extensions in order to deal with large scale applications as the ones targeted at by ARINC 661 specification

On Negotiation as Concurrency Primitive

We introduce negotiations, a model of concurrency close to Petri nets, with multiparty negotiation as primitive. We study the problems of soundness of negotiations and of, given a negotiation with possibly many steps, computing a summary, i.e., an equivalent one-step negotiation. We provide a complete set of reduction rules for sound, acyclic, weakly deterministic negotiations and show that, for deterministic negotiations, the rules compute the summary in polynomial time

Comparing Petri Net and Activity Diagram Variants for Workflow Modelling:A Quest for Reactive Petri Nets

Petri net variants are widely used as a workflow modelling technique. Recently, UMLa ctivity diagrams have been used for the same purpose, even though the syntax and semantics of activity diagrams has not been yet fully worked out. Nevertheless, activity diagrams seem very similar to Petri nets and on the surface, one may think that they are variants of each other. To substantiate or deny this claim, we need to formalise the intended semantics of activity diagrams and then compare this with various Petri net semantics. In previous papers we have defined two formal semantics for UMLact ivity diagrams that are intended for workflow modelling. In this paper, we discuss the design choices that underlie these two semantics and investigate whether these design choices can be met in low-level and high-level Petri net semantics. We argue that the main difference between the Petri net semantics and our semantics of UML act ivity diagrams is that the Petri net semantics models resource usage of closed, active systems that are non-reactive, whereas our semantics of UMLact ivity diagrams models open, reactive systems. Since workflow systems are open, reactive systems, we conclude that Petri nets cannot model workflows accurately, unless they are extended with a syntax and semantics for reactivity