Innovations Syst Softw Eng (2008) 4:107–122 DOI 10.1007/s11334-008-0044-5
ORIGINAL PAPER
Automatic framework generation for hard real-time applications Irfan Hamid · Bechir Zalila · Elie Najm · Jérôme Hugues
Received: 17 December 2007 / Accepted: 26 December 2007 / Published online: 31 January 2008 © Springer-Verlag London Limited 2008
Abstract The communication and tasking infrastructure of a real-time application makes up a significant portion of any modern embedded control system. Traditionally, the tasking and communication constructs are provided by a fullfledged real-time operating system. We present an approach to automatically generate a robust framework for an application from its architectural description. This framework sits atop a Ravenscar-compliant runtime as opposed to a standard real-time operating system. We also present an extension of our approach to support code generation for high-integrity distributed applications. Keywords Ada · Ravenscar · AADL · Real-time · Code generation · Model transformation
1 Introduction Control systems deployed on air and space platforms represent one of the most safety-critical categories of software. There are stringent standards of code review and certification [19] that must be met before deployment onboard the platform. Guaranteeing the schedulability and safety properties of the application is one of the costliest aspects of this certification process. The Ada programming language provides a rich set of tasking as well as inter-task communication constructs and is well-suited to real-time systems development. Furthermore, the Ravenscar Profile [8] defines a subset of Ada that provides schedulability and safety guarantees by restricting the I. Hamid (B) · B. Zalila · E. Najm · J. Hugues ENST, 46 rue Barrault, 75013 Paris, France e-mail:
[email protected]
features of the language, making Ada even more amenable to the development of such systems. The Architecture Analysis and Design Language [20] is an architecture description language targeted to real-time, safety-critical embedded systems. AADL (as it will be referred to hereon in this article) is an evolution of MetaH [25] and uses system design constructs such as processes, tasks, processors and communication channels to model an application. This model may be analyzed for semantic correctness, schedulability, the violation of certain safety properties as well as the generation of application code. In this paper we present our work on the generation of Ada Ravenscar code from AADL models. The guidelines given in the programming language and API annex of the AADL standard [21] assume the presence of an AADL executive. This executive should expose a certain API which would be used to access the services required by the code as given in these guidelines. We, on the other hand, present a method of automatically creating an executable framework corresponding to the AADL system model that runs on top of a Ravenscar-compliant kernel. Once this framework is automatically generated the functional behaviour—the only missing element—can be plugged into the framework to create a working application. An open source Eclipse plugin has been developed that implements these code generation rules.1 We are also developing a light distribution middleware for high-integrity systems—PolyORB-HI—which provides mechanisms for the construction of distributed Ravenscar applications. The rest of the paper is structured as follows, in Sect. 2 we give an introduction to AADL. Section 3 provides an overview of the Ada Ravenscar Profile. Section 4 surveys previous and related work in the same field. In Sect. 5 we explain 1
Available at http://aadl.enst.fr/arc/.
123
108
how we generate a Ravenscar framework for a single-node real-time system. Section 6 presents a case study we carried out using our approach. Section 7 gives an overview of how this approach can be extended for generating distributed realtime systems. Finally, in Sect. 8 we state our conclusions and give the future directions of our work.
I. Hamid et al.
− − − −
2 An overview of AADL The AADL is an architecture description language for the modeling of safety-critical, real-time embedded systems. It uses a component-centric model to define the system architecture, i.e., a system is a collection of inter-connected components. It allows the modeling of software components (processes, threads, data and subprograms) as well as execution platform components (hardware such as processors, memories, buses and devices). Only non-functional aspects of the component specifications may be given in AADL, e.g., their interfaces and how they are inter-connected. Behavioural or functional properties of components must be given separately. This implies giving the source code for software components in a programming language. There is also a proposed behaviour annex to the AADL standard.2 The AADL standard [20] defines a textual as well as graphical representation of the language. An XMI serialization is also defined to facilitate model interchange between tools. 2.1 Components Components are elements that require and offer services according to a given specification. AADL differentiates among component types and component implementations. Component types define the interface (features in AADL), along with properties of the component. Component implementations define the internals of a component; the subcomponents it contains and the connections among the features of those subcomponents etc. For every component type there may be one or more implementations. We give a brief description of each of the AADL component categories. − Process represents a virtual address space. Process components may contain threads, data and thread-groups − Thread represents the basic unit of execution and schedulability in AADL. Threads may contain data and subprogram subcomponents, as well as call sequences − Data represents either a data type (if it is in the declarative part) or a data instance (if it is a subcomponent of another component). Data components may contain data as subcomponents and subprograms as part of their 2
Available at the AADL website www.aadl.info.
123
−
−
interface which model access procedures for composite types Subprogram is an architecture-level abstraction of the procedure from imperative languages Processor represents a microprocessor together with a scheduler for dispatching the threads it hosts Memory represents a storage space (RAM/ROM or disk) Bus represents a hardware communication channel that links other execution platform components together Device represents a hardware with a known interface that can interact with the environment and/or the system under consideration (used to model sensors/actuators etc.) System is a hybrid component with no semantics that is used to englobe the entire architecture model.
2.2 Component interfaces As stated, component types in AADL may declare features. These are the interface points that the component exposes, and the only means by which it may communicate with its environment or other components. Different types of features are possible in AADL, here we describe them briefly. − Ports are data or control transfer-points. A data port is used to transfer only data. An event port is used to transfer only control; they send events, akin to UML signals with no associated data type ([17, Sect. 13.3.24]). Event data ports transfer control with accompanying data; akin to UML signals with an associated data type. Furthermore, ports may have Ada-like directional qualifiers for the flow (in, out or in out) − Parameters can be declared as features of subprograms − Data accesses represent access to a data subcomponent by an external component. This feature is used to model shared data among distant components. Data accesses may be provided or required − Subprograms in the features of a data component represent access procedures (similar to methods of a class), in the features of a thread they represent RPCs. Figure 1 shows an example AADL process consisting of two threads that are communicating with each other over a
Fig. 1 A simple AADL architecture model
Automatic framework generation for hard real-time applications
data connection. The corresponding AADL source code is given in Listing 1. thread Src_Thread features out_p : out data port ; end Src_Thread; thread Dst_Thread features in_p : in data port ; end Dst_Thread; process Partition end Partition ; process implementation Partition . Impl subcomponents Src : thread Src_Thread; Dst : thread Dst_Thread; connections Conn_Name : data port Src . out_p −> Dst . in_p ; end Partition . Impl ; Listing 1 The AADL source code corresponding to Fig. 1
2.3 Properties Properties are name/value tuples that can be applied to any component type, implementation, instance (subcomponent), connection or port. The AADL has a rich property mechanism, where properties are used to define aspects of the system entities that cannot be expressed otherwise. Examples of properties include Dispatch_Protocol and Period for threads; Source_Name and Data_Type for data; as well as Queue_Size and Compute_Entrypoint for ports. AADL contains a pre-defined set of standard properties. If an aspect needs to be expressed for which a standard property does not exist, the language contains the capability to describe new properties. These properties are project or tool specific and their semantics and interpretation is up to the designer. Properties may be applied to almost all AADL entities (components, subcomponents, features, and connections etc.), providing a rich spectrum of overriding possibilities. 2.4 Modes AADL provides modes that represent dynamically changing system configurations. Modes represent the active states of the software and the execution platform components of a system. An initial mode is specified for a component and subsequent target modes are given as a consequence of reception over some (or all) event ports in the component features. Thus, a component’s modes represent a deterministic, finite automaton whose alphabet is the set of all event ports of the component.
109 Table 1 Ada tasking features and their POSIX equivalents Ada
POSIX
Task
Thread
Protected object w/o entry
Semaphore
Protected object w/ entry
Semaphore w/ conditional variable
Suspension object
Conditional variable
Rendezvous
N/A
Threads can be activated/deactived in different modes, property values can be changed depending upon the current mode and connections can also be activated/deactivated as a function of the containing component’s mode.
3 The Ravenscar Profile The Ravenscar Profile [8] restricts the rich tasking features of Ada to ease schedulability analysis and furnish certain safety properties like the absence of deadlock and bounded priority inversion times. The tasking capabilities provided by the Ada runtime and their equivalents in the POSIX API are summarized in Table 1. 3.1 Ada tasks Ada tasks ([1, Sect. 9.1]) are akin to POSIX threads, they are independently executed in the address space of the host process. Associated with each task is its priority as well as the size of its stack. 3.2 Protected objects An Ada protected object ([1, Sect. 9.4]) is akin to a C++ class, in that it exposes operations and contains private data. The major difference being that its operations are concurrencysafe and are the only means of accessing its internal data. A protected object may expose three types of operations; functions, which cannot change the internal state but can return a value, procedures, which may change the internal state and may also return a value and entries, which may change the internal state and may return a value.3 In addition, an entry has a boolean barrier which must evaluate to true before that entry can be executed. If the barrier evaluates to false then the task calling the entry is suspended and is put on the entry queue. Furthermore, these barriers must be composed of variables that are part of the private data of the protected object, implying that a procedure of the protected object must be used to change the private data that unblocks the entry. 3
Procedures and entries can return values through their out or in out parameters.
123
110
3.3 Ravenscar restrictions The Ravenscar Profile seeks to simplify the analysis of realtime systems developed with Ada. Constructs such as rendezvous, task entries and protected objects with multiple entries are prohibited. Tasks and protected objects must be statically declared at library level and tasks may not terminate. Tasks may be either periodic or sporadic. Periodic tasks being those that are dispatched as a function of time; sporadic tasks being those that are dispatched upon reception of an event, with a minimum inter-arrival time between successive events. This ensures a static execution model that can be analyzed a priori for schedulability using either RMA [24] or RTA [7]. Access to protected objects must be based upon the priority ceiling protocol [23]. This ensures absence of deadlock and also provides an upper bound for priority inversions within the system. In a Ravenscar system, all communication among tasks must be done through protected objects. Only asynchronous communication is allowed, since a request/reply mechanism would cause cascading from the server task’s execution towards the client task’s worst-case execution time. The consequence of these restrictions is that a runtime compliant with the Ravenscar profile is much simpler to construct and much smaller than a standard Ada runtime. Aonix RAVEN [2] is a commercial implementation, whereas we use the open source ORK [18] implementation. The major difference between a traditional RTOS or executive and a Ravenscar runtime is that in the former threads, semaphores, conditional variables etc. are created using service calls; whereas in the latter they are part of the programming language runtime and are manifested in the source code rather then abstracted away in API calls.
4 Related work Real-time application code generation from models is not limited to AADL. In fact, real-time and high-integrity systems are probably the domain which has the most maturity when it comes to model-driven engineering. In this section we will sum up the major model-driven approaches to system development in the real-time domain. 4.1 HOOD, HRT-HOOD and HRT-UML Hierarchical Object Oriented Design (HOOD) is a design/ architecture language developed under contract by the European Space Agency for real-time systems [9]. The major goal of this methodology was to introduce notations specific to object based development directly into the design language. The method provided a graphical as well as textual notation for describing systems. Primarily targeted to the generation
123
I. Hamid et al.
of Ada83 code, it was later extended to incorporate code generation to Ada95 and C++ as well. HRT-HOOD (Hard Real-Time HOOD) is an enhancement of the traditional HOOD approach which incorporates some object types that are necessary to the real-time domain [6]. This extension also proposes a software development lifecycle in addition to the semantic enhancements. Both HOOD and HRT-HOOD are Domain Specific Languages; on the other hand, recently a UML profile was released that allows modeling HRT-HOOD applications via UML tools. Called the HRT-UML, this profile uses stereotypes to extend the semantics of standard UML classes [16]. However, the underlying semantics remain the same as those for HRT-HOOD. In [4], the authors describe a mapping from HRT-UML (and thus from HRT-HOOD) to Ada Ravenscar. But extensive use of generic packages in this approach results in significantly increased code complexity (which is also true for HRT-HOOD to Ada code generation). Stood, a tool developed by Ellidiss Software [10], allows users to model their real-time applications using AADL or the HOOD method [6]. Stood allows the transformation of an AADL model to HOOD, and there exists a mapping from HOOD to Ada. Therefore, users can generate code Ada code from AADL models, but it also suffers from increased code complexity due to the underlying similarity of mapping from model to code as that for HRT-HOOD. 4.2 MARTE UML profile Modeling and Analysis of Real-Time and Embedded Systems is a new UML profile (MARTE) [12]. Defined by industrial manufacturers, tool vendors and academics, MARTE allows the modeling of software and hardware aspects of real-time systems. The primary area of concern for MARTE is the expression of non-functional properties upon the system; timing properties of threads, network properties of links, fault tolerance properties etc. However, it is not clear what their code generation strategy would be since they intend to support multiple component models (including AADL). 4.3 Simulink and synchronous languages Simulink is an addon for Matlab which allows the modeling of data-flow using graphical notations and allows C code generation for various real-time operating systems. Simulink generates “synchronous” code [13]; i.e., it is assumed that environmental events are coming in at a much slower rate than the computation time for the response of those events. As a consequence, all threads are periodic in this paradigm and all threads are harmonic: all periods are integer multiples of the fastest period or base rate. This paradigm is implemented by setting a timer callback equal to the fastest period and then calling the other tasks’
Automatic framework generation for hard real-time applications
functions based on the periods of those other tasks. The disadvantages of this approach are (a) no sporadic/aperiodic threads, (b) all periods must be multiples of the base rate and (c) computation power is wasted. 4.4 The AADL code generation annex Annex D of AADL [21] describes some coding guidelines to translate the AADL software components into source code (Ada and C). These rules are not complete mapping specifications, but they provide guidelines for those who want to generate code from AADL models. Some of these rules are compliant with the Ravenscar Profile; we integrate them in our code generation rule set. However, these guidelines assume that an “AADL executive” is present to which the generated code makes calls for creating runtime entities that correspond to the model entities.
5 Generated execution framework Conventionally, real-time applications have been created on top of real-time operating systems. The RTOS provides services such as threads, communication primitives, mutexes, semaphores etc. as a set of APIs. This situation is shown in the left half of Fig. 2, where the application programs sit on top of the RTOS which runs on a processor. Listing 2 is an example of how to create a thread in this framework. This approach is perfectly applicable and mature. However, it cannot be applied to the development of a Ravenscar system. In a Ravenscar system all the tasks (threads) and protected objects (semaphores) must be declared at library level, i.e., statically declared and defined at compile-time. Therefore, an API that creates these constructs on-the-fly is invalid. Listing 3 shows how a periodic task must be declared in Ravenscar. As is evident, the periodic nature of the task must be programmed explicitly using Ada language
APP1
APP2
T1
T2
API RTOS/Executive
Ravenscar Executive
Processor
Processor
Fig. 2 A traditional RTOS-based approach (left) where processes use exposed APIs access services; and a Ravenscar-based approach (right) where an application is defined as a single process with tasks and communication constructs instantiated inside it
111
constructs which are translated and compiled to the entities of the Ada runtime.
... / ∗ Create a periodic thread ∗ / t i d = create_periodic_thread ( priorit y , period,&worker ) ; ... void worker (void ∗data) { / ∗ Periodic response code ∗ / ... } Listing 2 C code to create a thread
task body Periodic_Task is Period : Ada.Real_Time.Time_Span; Next_Dispatch : Ada.Real_Time.Time; begin Next_Dispatch := Ada.Real_Time. Clock ; loop delay until Next_Dispatch ; −− Periodic response code Next_Dispatch := Next_Dispatch + Period ; end loop; end Periodic_Task ; Listing 3 Periodic task in Ada Ravenscar
5.1 AADL as a design vehicle It is apparent from Listing 3 that it is difficult to build a nontrivial Ravenscar system by hand. The chance for error is significant, added to that is the ungainly nature of the exercise: application-level constructs to implement every task and inter-task communication entity. Fortunately, architecture description languages provide an easy-to-use method of modeling these constructs. Hence an appropriate architecture description language coupled with a custom-built code generator that produces Ravenscar-compliant code seems to be an attractive alternative. We explored this using the AADL as the architecture description language and found it to be a viable approach. AADL has been selected as the most natural candidate for describing Ravenscar system architectures because: Domain specificity: It is geared toward real-time embedded systems. Thus it is much simpler than for example UML which carries major baggage due to its legacy as the Swiss army knife of modeling Suitability to Ravenscar: It has a similar concept space as the Ravenscar Profile. AADL software components such
123
112
I. Hamid et al.
Fig. 3 An overview of the ARC toolchain
as process, thread, data, and subprogram can be mapped conveniently to the Ada constructs of application, task, data type/instance, and procedures Industrial acceptance: It is being designed by a consortium of industry and academia for the industry, and was expected to—and is experiencing—large-scale industrial acceptance
5.2 Tool architecture Our code generator called ARC (Ada to Ravenscar Converter) is implemented as an Eclipse plugin. The ARC tool relies upon the OSATE AADL toolkit [22] to parse AADL models. The OSATE toolkit is itself a set of Eclipse plugins that uses the Eclipse Modeling Framework [5] to represent the abstract syntax of the AADL model that is parsed. In our tool, instead of directly generating Ada code from the AADL model, we chose to implement an intermediate meta-model to represent the Ravenscar system. The “front-end” transforms the AADL model to an instance of this meta-model. The code generator then traverses this model to generate Ada code. This intermediate model is called the Ravenscar MetaModel (RMM). There are two obvious advantages to this approach: − AADL is a complex language, its meta-model is correspondingly complex. Direct traversal of it for code generation would be expensive − An intermediate representation facilitates the writing of code generators to other languages. A new code generator now only has to be written to traverse the RMM Due to the AADL’s complexity, not all systems described via it can be logically transformed to source code in conformity with the Ravenscar Profile. Therefore, before carrying out a model transformation from the AADL model to an instance of the Ravenscar Meta-Model, it is verified against a set of OCL rules. In case of inconsistencies in the
123
AADL model, the inconsistency is annotated, otherwise the transformation to an RMM instance is carried out. Figure 3 shows the overall flow in the ARC toolchain.
5.3 Ravenscar building blocks Reduction of the amount of generated code is a major aim of any code generation approach. Factorizing common components into a library and/or runtime reduces the complexity of the code generator. However, the static nature of the Ravenscar Profile prohibits a traditional component library/runtime where generating function calls to services according to the software architecture creates executable entities. To circumvent this problem, we make use of Ada generic packages to create a set of reusable components. We instantiate these generic packages with parameters corresponding to our system model. The instantiated packages, while being static elements, are nonetheless a form of meta-API. However, extensive use of generic components results in code bloat, and increases the size of the resulting executable. It is, therefore, a tradeoff, and we try to strike a balance between code reuse and performance by using generic components only for tasks and event [data] port constructs.
5.4 AADL to Ravenscar Profile transformations The static nature of the Ravenscar Profile fits well with the static existence model of AADL, which itself does not allow the modeling of the creation/destruction of components at runtime. However, there are certain semantic impacts from the Ravenscar Profile towards AADL, below we list some of the major ones:
− Threads may only be sporadic or periodic − Thread priorities remain constant − No synchronous communication among threads
Automatic framework generation for hard real-time applications
− The use of protected objects to implement data ports impacts the dynamic semantics of data ports defined in the AADL standard ([20, Sect. 9.1.1]) − The scheduler must be that defined by the Ada standard’s specification for FIFO_Within_Priorities − All shared data must have the ceiling priority protocol
113
the second to a vector and the third to a record. The Ada code after the transformation is shown in Listing 5. −− Integer data Int_Type properties Data_Type => Integer ; end Int_Type ;
In this section we present the transformation rules from AADL towards Ravenscar-compliant Ada source code. The AADL model that serves as a source for the transformation must conform to certain constraints. There must be no RPC constructs—as only asynchronous communication is allowed—which restricts the use of provides subprogram access and requires subprogram access clauses in the features section of threads, processes and systems. A valid AADL source model for a single-node Ravenscar application consists of a single system implementation. This system implementation must contain a single process implementation which represents the sole partition that executes. The process implementation must contain at least one thread subcomponent and zero or more data subcomponents. The various threads may have any combination of (in | out | in out) [event] [data] port clauses in their features, (provides | requires) data access clauses in thread features are also legal, as they represent access to shared data declared in the heap of their process.
−− Integer vector data Int_Vector properties Length => 10; Element_Type => reference Int_Type ; end Int_Vector ;
5.4.1 Data components
−− Record type Angular_HMS is record Hour : Int_Type ; Min : Int_Type ; Sec : Int_Type ; end record;
The rules for transforming AADL data components to Ada data types and data subcomponents to variables in the source code are the same as described in [26], but we give a brief overview here. Data components are transformed via analysis of their properties: − Data_Type: an enumeration that takes a value from the set {Integer, Boolean, Character}; it defines the primitive Ada type corresponding to this data component − Length: an integer to specify the length of an array if the data component is to be transformed to a vector − Element_Type: a property that designates the element type of an array, it is a data component reference − Concurrency_Control_Protocol: this is an enumeration that takes a value from {None Specified, Priority_Ceiling}, specifies whether a data component has protected access or not. Listing 4 gives the AADL code for three different data components, one of which is transformed to a primitive type,
−− Data structure data Angular end Angular ; data implementation Angular .HMS subcomponents Hour : data Int_Type ; Min : data Int_Type ; Sec : data Int_Type ; end Angular .HMS; Listing 4 AADL definition of an Integer and a vector of Integers
−− Int_Type type Int_Type is new Integer ; −− Int_Vector type Int_Vector is array (1..10) of Int_Type ;
Listing 5 Ada data types for the AADL data components
5.4.2 Processes A process component is transformed to an Ada main unit. The sole purpose of this compilation unit is to include the packages that declare the Ravenscar tasks and the communication constructs. The application entrypoint simply goes into an infinite loop. As it is the lowest priority thread, it serves also as the system background task. 5.4.3 Threads Each AADL thread subcomponent of the sole process implementation is transformed to an Ada task. The AADL property Dispatch_Protocol can be Periodic or Sporadic.
123
114
For a thread with property Periodic the generic package Ravenscar_Periodic is instantiated; for threads with property Sporadic the package Ravenscar_ Sporadic is instantiated. Other thread properties are used to parameterize the instantiation of the generic package. Source_Stack_Size parameterizes the thread’s stack size; Thread_Priority is used to give an explicit priority for the thread (if left unspecified the code generator automatically assigns the correct priority according to RMA/RTA); Deadline specifies an explicit deadline (if not specified it indicates that the deadline is the same as its period). The Period property represents the period for a periodic task or the minimum inter-arrival time of dispatching events for a sporadic task. The thread’s Compute_Entrypoint property gives the name (as a string) of the procedure to call upon dispatch of the thread. This property is only valid for periodic threads, for sporadic threads it has no effect since they must be given one entrypoint per incoming event [data] port. 1 2 3 4 5 6 7 8 9 10 11 12
generic Period_P : Ada.Real_Time.Time_Span; Deadline_P : Ada.Real_Time.Time_Span; Priority_P : System. Any_Priority ; Stack_Size_P : Natural ; with procedure Dispatch ; package Ravenscar_Periodic is task Task_Instance is pragma Priority ( Priority_P ) ; pragma Storage_Size (Stack_Size_P ) ; end Task_Instance ; end Ravenscar_Periodic ;
13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
package body Ravenscar_Periodic is task body Task_Instance is use Ada.Real_Time; Period : Ada.Real_Time.Time_Span; Next_Dispatch : Ada.Real_Time.Time; begin Period := Period_P ; Next_Dispatch := Ada.Real_Time. Clock ; loop Dispatch ; Next_Dispatch := Next_Dispatch + Period ; delay until Next_Dispatch ; end loop; end Task_Instance ; end Ravenscar_Periodic ; Listing 6 The Ravenscar_Periodic package specification
The Ravenscar_Periodic generic package is given in Listing 6. The Ravenscar_Sporadic is almost similar, except that at each job of the task, it simply calls a generated procedure which dispatches control to the entrypoint of the event [data] port over which the activating event was received, and also implements the minimum inter-arrival time separation. For details consult Sect. 6.3.
123
I. Hamid et al.
Fig. 4 A periodic AADL thread transformed to a Ravenscar task
Listing 6 contains both the package specification and body. The package specification contains instantiation parameters, which parameterize the generic package; here on lines 2–6. The priority and stack size are specified via Ada pragma declarations. Lines 22–26 implement the periodic behavior of the task, with line 23 calling the thread’s entrypoint (here specified as the Dispatch procedure parameter). Figure 4 shows an example of how a periodic task would be transformed under this framework. The dashed parallelogram is the standard graphical notation of a thread in AADL. The property associations given inside the thread are for clarity, it is not part of the standard graphical notation. 5.4.4 Data subcomponents Data subcomponents in threads or processes are transformed to shared variables. For data subcomponents of a thread, we declare a variable having the name of the subcomponent and the type mapped from the corresponding data component. For data subcomponents of a process component, the corresponding variable is declared in a package that is visible to all tasks in the application. This approach works well for monolithic applications. For distributed applications, and due to the restrictions of the Ravenscar Profile, the transformation of shared variables has to be amended (see Sect. 7). 5.4.5 Ports AADL provides data ports, event ports and event data ports. Data ports and event data ports have an associated data type, called a classifier in AADL terminology. This classifier may be a data component type, or a data component implementation. Ports can be connected to other ports (or left unconnected). Connections are legal between two data ports, between two event ports or between two event data ports. Furthermore, for data and event data ports the classifier (their data type) must be the same. We call the peer of a port the port(s) to which the former is connected. In addition to being divided into the three
Automatic framework generation for hard real-time applications
115
categories described, ports are also qualified with a direction (in, out or in out). An in port may be connected to an out port or an in out port. An out port may be connected to an in port or an in out port. An in out port may be connected to any compatible port irrespective of its directional qualifier. Data ports A connected data port in AADL represents a state. Writing a value on an out data port transfers the value to the peer in data port. A data port does not have a queue, i.e., two successive writes without an intervening read means the first value written is lost for the destination thread. It is for this reason that multiple incoming connections (fan-in) to data ports are illegal. We transform two connected data ports on co-located threads to an exchanger. An exchanger is defined to be an Ada protected type without an entry and two procedures, Get_ Value and Set_Value. The system model is traversed and an exchanger type is generated for each data port. For each in/in out data port of a thread an exchanger of the correct type is instantiated. The private data part of the exchanger contains a single variable of the same type as the classifier of the data port it represents. The specification of an Integer exchanger is given in listing 7. It serves as a 1-place exchange buffer for an Integer. An auxiliary internal variable Fresh keeps track of whether the current update—a consequence of the last invocation of Set_Value—has been read. The parameter Priority_P specifies the ceiling priority of this exchanger. protected type Integer_Exchanger ( Priority_P : System. Any_Priority ) is procedure Set_Value (D : in Data_Type) ; procedure Get_Value (D : out Data_Type; F : out Boolean ) ; private pragma Priority ( Priority_P ) ; Data : Integer ; Fresh : Boolean := False ; end Integer_Exchanger ; protected body Integer_Exchanger is procedure Set_Value (D : in Data_Type) is begin Data := D; Fresh := True; end Set_Value ; procedure Get_Value (D : out Data_Type; F : out Boolean) is begin D := Data; F := Fresh ; Fresh := False ; end Get_Value; end Integer_Exchanger ; Listing 7 The Integer_Exchanger generated type
Fig. 5 AADL data ports transformed to exchangers and accessor stubs
We instantiate an exchanger with a unique name for each in data port of a thread together with an accessor stub named Get_. For the thread with the peer out data port, a stub Set_ is generated that writes to the exchanger. An example of such a transformation is shown in Fig. 5. The standard graphical notation for a data port is . Event and event data ports A connected event [data] port in AADL represents a channel for control-flow. Event ports transfer events asynchronously from the source to the destination thread. Event data ports transfer events and associated data from the source to the destination thread. Only sporadic threads may have incoming event [data] ports, and must have at least one to enable dispatching. For each sporadic thread, an enumeration is generated that names every in event [data] port in its features section. A variant Ada record type is also generated, with a discriminant Port whose variant parts are all the event types the sporadic thread may receive. We call this variant record the event interface block (EIB) for the task. An example of this transformation is depicted in Fig. 6. Event ports are shown as and event data ports as . For each sporadic thread a single synchronizer is instantiated in the framework. We define a synchronizer to be a generic Ada package containing a single protected object that has one entry Await_Event and a procedure named Send_Event. Its specification is given in Listing 8. A synchronizer has an n-place circular buffer as internal data that stores the events (and associated data for event data ports) received for its associated sporadic task. The barrier to the entry Await_Event is true whenever there is at least one event in the internal event queue. The sporadic task will call the Await_Event of its synchronizer as its first statement and thus is released only if an event is available. It must be noted that only a single behaviour may be attached to periodic threads at the AADL model level. This is either the unique call sequence given for the thread or the
123
116
I. Hamid et al.
− Calls the Await_Event entry of its task’s synchronizer − If there is a call sequence corresponding to the dispatching event, its procedures are called − If no corresponding call sequence is defined, then the procedure given as the Compute_Entrypoint property of the event [data] port that dispatched the task is called − Suspends itself until dispatch_time + interarrival_ time. For an example of the Ada code of a generated dispatch procedure, refer to the case study in Sect. 6. 5.4.7 Modes
Fig. 6 A sporadic thread with in event ports and its equivalent after transformation to Ada Ravenscar
procedure given as the Compute_Entrypoint property of the thread. However, a sporadic thread may have separate behaviours attached to each of its in event [data] ports. This is accomplished by setting the Compute_ Entrypoint property of each incoming event [data] port to the appropriate procedure that should be called upon its reception. generic Q_Length : Integer ; Is_Hot_Overflow : Boolean; −− EIB : Event Interface Block type EIB is private ; package Ravenscar_Synchronizer is type Q_Type is array ( 0 . .Q_Length−1) of EIB; protected Synchronizer is procedure Send_Event(Event_Data : in EIB ) ; entry Await_Event(Event_Data : out EIB ) ; private Event_Queue : Q_Type; Head : Integer := 0; Tail : Integer := 0; Event_Present : Boolean := False ; end Synchronizer ; end Ravenscar_Synchronizer ; Listing 8 Spec of the Synchronizer generic component
5.4.6 Dispatch procedures A procedure named _Dispatch is generated for each sporadic thread. This procedure is called at every dispatch of the task, it takes the following actions on reception of an event:
123
AADL operational modes (see Sect. 2.4) model dynamically changing configurations in AADL components. The AADL standard is quite permissive regarding modes: it allows the definition of modes for practically all categories of components, and allows these modes to drive the change of most component aspects (disabling/enabling call sequences, subcomponents, properties, etc.). Each subclause that one wants to be “active” in a set of particular modes will be assigned an in modes clause to its declaration (see Listing 9).
thread Worker features Work_Normally : in event port ; Emergency_Occurred : in event port ; Everything_Is_Cool : in event port ; end Worker; thread implementation Worker. Impl modes Normal_Mode : i n i t i a l mode; Emergency_Mode : mode; Lazy_Mode : mode; Normal_Mode, Lazy_Mode −[Emergency_Occurred]−> Emergency_Mode; Normal_Mode, Emergency_Mode −[Everything_Is_Cool]−> Lazy_Mode; Emergency_Mode, Lazy_Mode −[Work_Normally]−> Normal_Mode; properties Compute_Entrypoint => "Repository .CE_Normal_Handler" in modes (Normal_Mode) ; Compute_Entrypoint => "Repository .CE_Emergency_Handler" in modes (Emergency_Mode) ; Compute_Entrypoint => "Repository .CE_Lazy_Handler" in modes (Lazy_Mode) ; end Worker. Impl ; Listing 9 Example of use of AADL modes
Automatic framework generation for hard real-time applications
In the context of HI systems we cannot afford this permissiveness. Thus, restrictions have to be applied on the use of modes. In particular, AADL modes cannot be used to drive aspects that may affect the static analysis of the system and its conformance to the Ravenscar Profile, such as the period or the priority of a thread or the enabling/disabling of a thread subcomponent in an AADL process. The use of AADL modes has been reduced to only thread components, and these modes may only modify the behavior of these threads (either through selecting the proper call sequence for the thread or through multiple mode-specific values for the Compute_Entrypoint property). Concretely, modes are mapped into: − An enumeration type (one enumerator for each mode) − A variable, local to the thread, that indicates the current mode and that is initialized to the initial mode value − After the call to Await_Event, and depending on the received event port and the current mode value, the value of the variable may be updated. This can simply be done by nesting as many case switches (on the current mode value) as necessary into a case switch on the triggered event port value (see Listing 10). − Depending on the updated value, the corresponding behaviour of the thread is selected (using a switch case on the current mode value). −− The call to Await_Event provided the value −− of the event port in variable ’ Port ’ case Port is when Work_Normally => case Current_Mode is when Emergency_Mode | Lazy_Mode => Current_Mode := Normal_Mode; when others => null ; end case; when Emergency_Occurred => case Current_Mode is when Normal_Mode | Lazy_Mode => Current_Mode := Emergency_Mode; when others => null ; end case; ... end case;
117
The Listings 10 and 11 show portions of Ada code that implement the mode support for the thread shown in Listing 9. These code generation rules are currently supported in the Ocarina code generator [11] and will soon be supported in ARC as well.
6 Case study We provide a case study to illustrate the approach. We design a simplified version of a flight computer in AADL. Our code generator gives us the source code of the Ravenscarcompliant framework. We then flesh out the framework with hand-written behavioral code. 6.1 Problem statement We describe a hypothetical aerial platform that has three sensors. One sensor updates the climb-rate of the platform every 20 ms. Another sensor gives the angle-of-attack— angle between the long axis of the fuselage and the direction of airflow, abbreviated AoA—every 20 ms. The third sensor raises an interrupt in case of engine failure. The platform has a landing gear subsystem. This subsystem can be sent an event which causes it to raise or lower the landing gear. When the gear is raised/lowered and locked, it sends an event confirming the action. An aircraft is said to be in a stall when there is a loss of effectiveness of the aerodynamic control surfaces. In our platform, the flight management computer should sound a stall warning when: − AoA > 40◦ (soft stall) − AoA > 22◦ and climb rate < 10 feet/s (hard stall) The operator has an HCI system that consists of: − A button to raise/lower the landing gear − An LED that blinks while the landing gear is in transit − An audio alarm that sounds with different frequencies in case of a soft stall, hard stall or engine failure − A button to mute the alarm when it sounds 6.2 Design
Listing 10 Example AADL modes mapping −− Call the thread compute entrypoint case Current_Mode is when Normal_Mode => Repository .CE_Normal_Handler ( Port ) ; when Emergency_Mode => Repository .CE_Emergency_Handler ( Port ) ; when Lazy_Mode => Repository .CE_Lazy_Handler ( Port ) ; end case; Listing 11 Example AADL modes use
A graphical representation of the AADL system architecture is shown in Fig. 7. A data port is represented by , an event port by and an event data port by . Stall_Monitor is a periodic thread that monitors the data from the AoA and climb-rate sensors. It has a period of 20 ms and receives the data through two data ports; AoA and Climb_Rate, both of type Integer. The functional unit of this thread—defined as its Compute_Entrypoint— carries out the calculations according to the conditions defined in the problem statement. In case of a soft stall it
123
118
I. Hamid et al.
Fig. 7 The flight management system architecture
raises an event on the Stall_Warn port with 1 as the Integer argument, for a hard stall with 2 as the Integer argument. HCI is a sporadic thread that manages the display and audio alarm system. It is a sporadic thread with a minimum inter-arrival time of 10 ms for events. An Integer event data is received on Stall_Warning, with the value set according to the severity of the stall (hard or soft). An event is received on Engine_Failure if the sensor raises an interrupt. Gear_Cmd is the event received from the operator whereas Gear_Req and Gear_Ack are the event interfaces with the landing gear subsystem. As this is a sporadic thread, each in event [data] port has a unique Compute_ Entrypoint. Landing_Gear represents the landing gear subsystem. It is a sporadic thread with a minimum inter-arrival time of 3 s for events. When it receives an event on the event port Req it starts the landing gear raising/lowering operation. Upon completion of the operation it sends an event Ack back to HCI (after 3 s). Sensor_Sim is a periodic thread that simulates the sensors by updating the sensor data every 20 ms. This thread also has an out event port that simulates the engine failure sensor. Similarly the thread Operator simulates the pilot. It is a periodic thread with a period of 10 s, at each dispatch it sends the order to raise/lower the landing gear via its event port Gear_Cmd. We assign a deadline D equal to the period (for periodic threads) or inter-arrival time (for sporadic threads) to each thread except Sensor_Sim, which is assigned a deadline of 15 ms while it has a period of 20 ms. Table 2 summarizes the tasking configuration. The code generator automatically assigns priorities according to the deadline monotic approach. Code is generated for the ERC32 processor where a higher numeric value denotes a higher priority. The sensor simulation and monitoring threads have the same period yet we give a higher priority to the sensor simulation thread (via an earlier deadline) so that it sends new data to the stall monitoring thread at every cycle. WCETs for the sensor and the operator simulation threads are minuscule.
123
Table 2 Priorities and computation times for tasks Task
Cycle
Deadline
Priority
WCET
HCI
10 ms
10 ms
240
3 ms
Sensor_Sim
20 ms
15 ms
239
7 ns
Stall_Monitor
20 ms
20 ms
238
1 ms
Landing_Gear
3s
3s
237
3s
Operator
10 s
10 ms
236
3 ns
Cycle gives the period for periodic tasks and the minimum inter-arrival time for dispatching events for sporadic tasks −− Stall_Monitor entrypoint −− procedure On_Stall_Monitor is −− [ proc On_Stall_Monitor decls ] START CR : Integer ; AoA : Integer ; Fresh : Boolean; −− [ proc On_Stall_Monitor decls ] STOP begin −− [ proc On_Stall_Monitor code] START Get_Climb_Rate (CR, Fresh ) ; Get_AoA (AoA, Fresh ) ; i f AoA > 40 then Raise_Stall_Warn (2); elsif AoA > 22 and then CR < 10 then Raise_Stall_Warn (1); end i f ; −− [ proc On_Stall_Monitor code] STOP end On_Stall_Monitor ; Listing 12 Procedure called when Stall_Monitor is dispatched
6.3 Generated code We obtain a number of source files when we pass the AADL model through our code generator. These files constitute the generated framework as well as the holes (callbacks) where the system designer plugs in his/her functional code. These holes manifest themselves as the skeletons of the various procedures declared as the Compute_Entrypoint of threads and event [data] ports. The _Funit package contains the entrypoint(s) for the given thread. As an example, the Ada code for the entrypoint procedure of the Stall_Monitor thread is given in Listing 12. The
Automatic framework generation for hard real-time applications
skeleton is generated automatically, the code inside the procedure is written by the system designer. The various comments of the form [xxx] START/STOP allow the code generator to save the state of the edits between successive code generation operations. The listing also shows the use of the generated stubs to manipulate the ports this thread has. Another important generated package is for the dispatchers of sporadic threads. Dispatch procedures are not meant to be edited by the system designer. But the code of the HCI dispatch procedure shown in Listing 13 clarifies how the EIB (event interface block) and event [data] ports are used to dispatch events. The EIB—an example of which is shown in Fig. 6—is both an enumeration of event types and a variant record structure that can store any of the event data types received by the thread. In Listing 13, line 6 waits on the synchronizer’s entry. Line 7 calculates the next dispatching time as a function of current time and the minimum inter-arrival time. The rest of the procedure dispatches control to the appropriate entrypoint depending upon the Port enumeration of the received EIB, with line 19 enforcing the minimum inter-arrival time between two successive jobs. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
procedure HCI_Dispatcher is S : Task_Features.HCI_T_EIB; Next_Dispatch : Ada.Real_Time.Time; use Ada.Real_Time; begin HCI_Synchronizer . Synchronizer . Await_Event(S) ; Next_Dispatch := Clock + Milliseconds (10); case S. Port is when Task_Features. Engine_Failure => HCI_Funit . On_Engine_Failure ; when Task_Features.Gear_Cmd => HCI_Funit .On_Gear_Cmd; when Task_Features.Gear_Ack => HCI_Funit .On_Gear_Ack; when Task_Features. Stall_Warning => HCI_Funit . On_Stall_Warning (S. Stall_Warning ) ; end case; delay until Next_Dispatch ; end HCI_Dispatcher ; Listing 13 The dispatcher procedure for the HCI task
The Local_Comm package contains the generated communication infrastructure. An exchanger is instantiated for each in data port and a synchronizer for each sporadic thread. Table 3 gives the names of the Ada source artifacts generated and their corresponding AADL artifacts.
119 Table 3 Communication and tasking artifacts (in Ada and AADL) Source code artifact
AADL artifact
Stall_Monitor_AoA
data port AoA
Stall_Monitor_Climb_Rate
data port Climb_Rate
HCI_Synchronizer
HCI thread
Landing_Gear_Synchronizer
Landing_Gear thread
blocked by a lower priority task due to priority inversion. If both are known, then the well-known result of Eq. 1 can be used to compute the response time R, where the summation term gives the interference time. Ri Cj (1) Ri = Ci + Bi + Tj j∈hp(i)
For a system with a priority ceiling protocol, the term Bi can be calculated using Eq. 2. Where usage(k, i) = 1 if resource k is used by at least one task with a priority less then task i and at least one task with a priority greater then or equal to task i; otherwise usage(k, i) = 0. C(k) is the WCET of critical section k. K
Bi = max (usage(k, i) × C(k)) k=1
(2)
We calculated the execution times for exchangers and synchronizers. The two exchangers in the system are of type Integer, conformant to the classifiers of the two data ports. The WCET for an Integer exchanger Set operation is 2 × 10−3 ms. For an integer exchanger Get operation it is 2.5 × 10−3 ms. For both Send_Event and Await_Entry operations of the two synchronizers (for both the threads HCI and Landing_Gear) WCET is 2.5 × 10−3 ms1 .4 These obtained WCET values are applied as properties to the various AADL entities to enable detailed, automatic schedulability analysis. We define a new AADL property set Ravenscar, which includes (among others): − Read_WCET/Write_WCET: applies to data components and gives the WCET for a Get/Set operation on an exchanger (data port) of this type − Send_Event_WCET and Receive_Event_WCET: applies to threads and gives the WCET for a Raise_ Event and Await_Event operation respectively on the thread’s synchronizer
6.4 Schedulability analysis We perform schedulability analysis on the given task-set according to the Response Time Analysis (RTA) methodology described in both [8] and [7] (pp 475–479). The interference time I for a task is the time spent executing higher priority tasks when the task in question is ready. The blocking time B of a task is the time a task may be
Using these properties, the code generator will be able to perform a precise response time analysis. If the task set is not schedulable the analyzer will be able to pinpoint the task(s) that will not meet their deadlines. 4
Values were obtained as max of 1,000,000 calls on the ERC32 simulator.
123
120
7 Extending to distributed systems
I. Hamid et al.
In this section we give the the extension of the Ravenscarcompliant code generation rules for constructing distributed applications from their AADL models. The distributed application will rely on our middleware for HI (high-integrity) systems, PolyORB-HI.
We implement this model in PolyORB-HI, which is a core that contains the distribution features required for asynchronous distributed applications. PolyORB-HI is structured in several layers (transport, protocol, applicative aspects) but without any dynamic creation of components. This results in a small memory footprint (200Kb including the realtime kernel using GNAT for the ERC32 target).
7.1 Distribution model for HI systems
7.2 Code generation rules for HI distributed applications
HI distributed systems have to be designed with respect to a set of requirements:
Most of the rules to generate code for monolithic distributed applications have been created with the distributed case in mind. This means that the code generated for a distributed HI application is similar to the code generated for a monolithic one and compliant with the Ravenscar Profile and the high integrity systems restrictions defined in the Annex H of [1]. In this section, we give the code generation rules that reflect the distributed aspect of an HI application.
− Language constructs: all language constructs used in PolyORB-HI are compliant with the Ravenscar Profile − Memory model: in a HI system, dynamic memory allocation must be avoided to protect the system from exhausting memory at runtime and the non-deterministic behavior of memory allocators − Tasking and concurrency model: a major portion of the Ravenscar Profile addresses tasking issues. The compliance to the Ravenscar Profile ensures static analyzability and the absence of deadlocks, unbounded priority inversion and non-deterministic scheduling − Transport layer: this part of the HI system is out of the scope of the Ravenscar Profile. However, the lowlevel transport layer should not affect the application properties obtained by respecting the Ravenscar Profile: in particular, it should bound priority inversion when accessing the communication channels, all communication channels must be created at initialization time and be non-terminating. PolyORB-HI will use the SpaceWire protocol which ensures all these properties. From the requirements above, we derive a distribution model: the system is made of pairs of “caller/callee” tuples, each located on a different node. − The caller marshalls the data, retrieves the end-point to the callee, and sends the data through the low-level transport layer − A protocol handler task is awaken on the callee side. It receives the data, unmarshalls it and calls the corresponding processing code This model is notionally similar to typical RPCs, with the following limitations imposed to avoid blocking: − There is one communication channel per caller/callee couple, and one handler task per transport end-point − Requests are asynchronous − Data size is bounded and known at compile time.
123
7.2.1 Data exchange Data have to be converted into a representation suitable for network transfer. The reader should note that the data transfer between nodes is request-oriented, i.e.: all message sending in the AADL model is mapped to request invocations in the generated Ada code. In order to be compliant with the Ravenscar Profile, the request invocation must be asynchronous. For each distributed application, a discriminated record data type is generated. The discriminant of this record is the operation that is called by a node. For each operation that could be invoked remotely in the distributed application, a list of components corresponding to the operation parameters is added to the request type. A generic marshalling package is instantiated that provides platform-neutral data conversion operations for transmission over the network, these operations are deterministic (O(data si ze)). 7.2.2 Communication channels and request dispatching All aspects of the system must be statically known at compile time to conform to HI requirements. Therefore, the entire task-set and all communication channels between nodes have to be created at system initialization. To achieve this, a deployment package is generated for each node and contains the deployment information this node has concerning other nodes. This information constitutes, in conjunction with the generated naming table, the means for a node to send or receive invocations from another node. This mechanism is completely static and does not use dynamic component creation (component factories in the CORBA Component Model [3]). The deployment package contains two Ada enumeration types:
Automatic framework generation for hard real-time applications
− Node_Type: for each node we create an enumeration literal that lists all nodes reachable by the application. A literal is allocated for the local node (My_Node) − Port_Type: for each in port, we declare an enumeration literal (see 5.4.5). The naming table is statically generated from the topological information of connections among the components present in the AADL model. It contains information for each node to establish a connection with and to send/receive requests to/from another node. As this table is statically generated it avoids dynamic fetching of connection end-points and thus enforces compliance to HI system requirements. 7.2.3 Client side remote activities Communication among nodes can be subsumed to method calls: the endpoint of a data port connection or an event data port connection is generally a procedure parameter. Hence we can transform the message sending into a call to a stub that builds a request from the parameters, marshalls these data in the request and transmits it through the network to the receiver subprogram. For a single instance of interaction, the caller side is seen as a client; the called node a server. Furthermore, the compliance to the Ravenscar Profile reduces the invocation call protocol set to the single asynchronous method. Therefore, our code generator produces an asynchronous stub for each “method call”. It also checks that the data flow between components is suitable for asynchronous communication (remotely invoked subprograms must not have out/in out parameters). However, the single use of asynchronous communication is not sufficient to guarantee correctness of distributed applications sharing data across nodes. We are also designing a Ravenscar-compliant consensus algorithm between the different nodes to guarantee data consistency. 7.2.4 Server side remote activities The receiver of a request is usually a sporadic AADL thread. Sporadic threads are mapped to sporadic Ada tasks. Each dispatch of a sporadic task can be seen as the invocation of a request handler. As stated in [14], an extra task plays the role of a protocol handler and dispatches the incoming requests to their respective handlers. The generated code for the request handler consists of an instantiation of a generic package as the work of all sporadic tasks is similar and a lot of code can be factorized. Generic instantiation does not cause significant overhead in our case because we use it only to create tasks and data (un)marshallers.
121
7.2.5 Assessments We tested our middleware and code generator by performing a case study similar to the one described in Sect. 6. We generated the code, compiled it to the target using the GNAT compiler and simulated it locally using the tsim simulator for ERC32. The total size of the executable, including real-time kernel, middleware and the application is 310 kB. It fits the requirements for minimal embedded systems, and is clearly under the typical memory range for API-based middleware, such as nORB or microORB, which are above 450 kB.
8 Conclusion and future work We presented a method of generating a customized framework for hard real-time applications. A case study was presented to illustrate the approach with a concrete example. Finally we showed how our approach can be extended to generate code for distributed, hard real-time systems that are Ravenscar-compliant. A clear advantage of the approach is the separation of concerns between the non-functional architecture of the real-time system and the functional or behavioural part. It gives system designers a block modeling approach to their problem with clear and well-defined interfaces among those blocks. The behaviour of the individual blocks is given separately. The automatic generation of code ensures conformance to interfaces and non-functional properties as a result of their direct transformation from the model towards code. We have developed ARC,5 an open source Eclipse plugin that implements the code generation rules for a singlenode application. The tool is based on the OSATE AADL parser, which represents the AADL abstract syntax tree as an EMF meta-model. We have also defined our own Ravenscar domain model. The tool translates the AADL model to an instance of the internal Ravenscar domain model. Code generation is done by traversal of the Ravenscar domain model instance. This will facilitate the writing of code generators to other Ravenscar-compliant languages, such as RavenscarJava [15]. As it is described in the case study, response time analysis is being implemented in ARC. We also described our work on PolyORB-HI, which will be used as a light-weight middleware to generate Ravenscarcompliant code for distributed applications. Future directions for our work include the detailed exploration of distribution for Ravenscar-compliant applications and the amount of coupling we can achieve with them. Also, since the code generation rules provide a complete bijection among the model and code, we intend to implement a hypertext reporting system that gives complete traceability 5
Available at http://aadl.enst.fr/arc/.
123
122
between the code generated and the model element that it is a consequence of, and vice-versa. This traceability documentation is very useful for obtaining certification for flight software. Acknowledgments The research work on which this paper is based was carried out in the ASSERT project (IST-FP6-2004 004033) funded by the European Commission as part of the 6th Framework Programme.
I. Hamid et al.
13.
14. 15.
References 16. 1. Ada Working Group (2005) Ada Reference Manual. ISO/IEC, available at http://www.adaic.com/standards/05rm/RM-Final. pdf 2. Aonix (2006) Real-Time RAVEN, http://www.aonix.com/pdf/ RAVEN-aon.pdf 3. Barros MC, Madeira ER, Sotoma I (2003) An experience on CORBA component deployment. In: Proceedings of the 6th international symposium on autonomous decentralized systems (ISADS’03) 4. Bordin M, Vardanega T (2005) Automated model-based generation of ravenscar-compliant source code. In: ECRTS ’05: Proceedings of the 17th Euromicro conference on real-time systems (ECRTS’05), IEEE Computer Society, Washington, DC, USA, pp 59–67, http://dx.doi.org/10.1109/ECRTS.2005.9 5. Budinsky F, Steinberg D, Merks E, Ellersick R, Grose T (2004) Eclipse modeling framework. Addison-Wesley, Reading 6. Burns A, Wellings AJ (1994) HRT-HOOD: a structured design method for hard real-time systems. Real-Time Syst 6(1):73–114, http://dx.doi.org/10.1007/BF01245300 7. Burns, A, Wellings, A: Real-time systems and programming languages, 3rd edn. Addison-Wesley, Reading (2001) 8. Burns A, Dobbing B, Vardanega T (2004) Guide for the use of the Ada Ravenscar profile in high integrity systems. Ada Lett XXIV(2):1–74, http://doi.acm.org/10.1145/997119.997120 9. Carmichael AR (1992) Defining software architectures using the hierarchical object-oriented design method (HOOD). In: TRI-Ada ’92: Proceedings of the conference on TRI-Ada ’92, ACM, New York, USA, pp 211–219, http://doi.acm.org/10.1145/ 143557.143721 10. Ellidiss Software (2007) Stood, http://www.ellidiss.com/stood. shtml 11. ENST (2006) Ocarina: An AADL model processing suite, http:// ocarina.enst.fr, URL http://ocarina.enst.fr 12. Espinoza H, Dubois H, Gérard S, Medina J, Petriu DC, Woodside M (2006) Annotating UML models with non-functional properties
123
17. 18.
19.
20. 21. 22. 23.
24.
25.
26.
for quantitative analysis. Satellite Events at the MoDELS 2005 Conference 3844/2006, pp 79–90 Halbwachs N (2005) A synchronous language at work: the story of lustre. In: MEMOCODE ’05: Proceedings of the proceedings. Second ACM and IEEE international conference on formal methods and models for Co-Design, 2005. MEMOCODE ’05., IEEE Computer Society, Washington, DC, USA, pp 3–11, http://dx.doi. org/10.1109/MEMCOD.2005.1487884 Hugues J, Zalila B, Pautet L (2006) Middleware and tool suite for high integrity systems Kwon J, Wellings A, King S (2005) Ravenscar-Java: a highintegrity profile for real-time Java. Concurr Comput Pract Exp, 17(5–6): 681–713 Mazzini S, D’Alessandro M, Natale MD, Lipari G, Vardanega T (2003) Issues in mapping HRT-HOOD to UML. ecrts 00:221, http://doi.ieeecomputersociety.org/10.1109/EMRTS.2003. 1212747 Object Management Group (2007) Unified modeling language: superstructure. OMG, 2nd edn de la Puente JA, Ruiz JF, Zamorano J (2000) An open Ravenscar real-time kernel for GNAT. In: Ada-Europe 2000: Proceedings of the 5th Ada-Europe international conference on reliable software technologies, Springer, London, pp 5–15 RTCA, EUROCAE (1992) DO-178B, software considerations in airborne systems and equipment certification. RTCS and EUROCAE SAE (2004) Architecture analysis & design language (AS5506). Available at http://www.sae.org SAE (2005) Language compliance and application program interface. SAE, the AADL Specification Document Annex D SEI (2006) Open Source AADL Tool Environment, http://la.sei. cmu.edu/aadl/currentsite/tool/osate.html Sha L, Rajkumar R, Lehoczky J (1990) Priority inheritance protocols: an approach to real-time synchronization. IEEE Trans Comput 39(9):1175–1185, http://doi.ieeecomputersociety. org/10.1109/12.57058 Sha L, Klein MH, Goodenough JB (1993) Rate monotonic analysis for real-time systems. Computer 26(3):73–74, http://dx.doi. org/10.1109/2.204696 Vestal S (1998) Software programmer’s manual for the Honeywell Aerospace Compiled Kernel (MetaH Language Reference Manual). Honeywell Technology Center, Minneapolis Zalila B, Hamid I, Hugues J, Pautet L (2007) Generating distributed high integrity applications from their architectural description. In: 12th international conference on reliable software technologies Ada-Europe 2007, pp 155–167
