Scheduling in SDL simulation. Application to Future Air Navigation Systems. Frédéric Boutet1, Gilles Rieux2, Yves Lejeune1 and Eric Choveau2 1 Telelogic. www.telelogic.com Frederic.Boutet | Yves.Lejeune@telelogic.com 2 Aerospatiale Matra-Airbus. 316 route de Bayonne 31060 Toulouse Cedex 03, France Gilles.Rieux | Eric.Choveau@airbus.aeromatra.com This paper deals with scheduling at early protocol verification stage. We address real- time applications whose implementation require specific scheduling policies. In the Future Air Navigation System developed by Aerospatiale Matra-Airbus, scheduling is not only required in low-level implementation but also makes system modelling more deterministic, facilitating verification and certification. To be truly confident in specification models, we should prove that behaviors in simulation get closer to generated code behaviors. SDL and MSC models can be used to specify and verify such systems. A weak point of SDL is the lack of scheduling policies. The SDL FIFO queue-based semantics is not enough at simulation steps since implemented scheduling algorithms will not always choose the first message in the queue nor run every process instance in parallel. This paper reports what has been done with ObjectGeode Simulator for Aerospatiale Matra-Airbus. Keywords: Deployment, Simulation, Scheduling, FANS. I. Motivation Protocols are becoming more and more present in industries such as Avionics or Automotive. Non telecom industrial groups use formalisms such as SDL & MSC for building specific applications. The Aerospatiale Aircraft Division for instance reported the first use of SDL in (Goudenove and Doldi. 1995). Non Telecom groups also tends to play a role in the definition of the new common standard UML since this formalism aims at bringing together pure telecom and real-time development processes. Since scheduling is a specific feature of real-time systems, the ordering of events in SDL is an actual problem, especially when SDL-2000 is chosen as a semantics for real-time UML. Today, the SDL standard does not provide real-time features such as the possibility to set up scheduling policies. This was pointed out in (Alvarez & al. 1999) for example. The main question is, at which level of the design process scheduling principles can be introduced ? Alvarez and his colleagues propose an embedded software development process in which Rate Monotonic Analysis techniques come to fill the gap between real-time-specific constraints and SDL modelling. With this approach, SDL is modified so that real-time constraints can be taken into account. Moreover, preemptive scheduling with fixed priorities is used. The overall procedure is to get an SDL-like formalism that fits the real-time modelling requirements up to specific details in the architecture. In this paper, we will not follow this idea but rather focus on early design steps. Introducing scheduling principles in SDL will only aim at getting the modelling language closer to the one that will be produced by the application. This was required by Aerospatiale Matra Airbus. They were using the ObjectGeode simulator for the development of the ATSU (Air Traffic System Unit) computer. Under integrating scheduling, they wanted to completely suppress parallelism in SDL agents so that only one transition can be fired in every state. We address a method in which an SDL model: - defines what the application should do, so as a specification language does; - is used as a support for generating the code. In Aerospatiale Matra-Airbus, two different teams are responsible for these jobs, one for specification, one for implementation. SDL acts as a formal communication language between the two teams. If people involved in the realization of multi-tasks systems (the second team) have specific requirements in the definition of scheduling policies, they should be able to express them in the common communication language. On the other side, the first team specifying good and bad behaviors will require ordering event rules since they need to perform protocol verification by simulation. In this context, we will see that the FIFO queue associated with each process instance in SDL will not be enough to build up a bridge between these two teams. This is especially true when strong certification constraints must be taken into account in the process. This paper addresses the problem of ordering SDL message inputs. Scheduling should reduce the level of non-determinism without modifying the SDL semantics. If there is no other possibility, any semantic modification generates questions: - are we still able to generate new behaviors using classical SDL constructions ? - what are the implications on usual tools such as code generators, verification tools, MSC generators,… In this paper, new behaviors will be generated and these questions will be addressed in time. In the second section, a general framework for introducing scheduling policies in SDL is presented. For some event ordering rules, SDL-96 semantics has to be modified and we show the implication of these modifications. One set of rules used by Aerospatiale Matra-Airbus, called the multi-node scheduler, is described in details. In the third section, we show how this set of rules has been implemented in ObjectGeode simulator. The last section reports the use of this SDL extension by Aerospatiale Matra-Airbus. II. SDL & Scheduling. This section presents concepts and methods for introducing scheduling principles in SDL as a specification language. II.1 A general framework The ordering of events in SDL is non-deterministic. When several processes have input messages, no rule defines which message will be treated the first. We aim at making the ordering of events strictly or partially deterministic (total or partial order). We first need to map an SDL structure into a set of nodes. A node may have several meanings, depending on which scheduling will be used. A node can represent a Unix process. It can be a task without any implementation details too. It may have either a physical or a functional meaning. In Telelogic Tau Deployment Editor, nodes are called components and they are used to define the generated application (physical meaning). In ObjectGeode Code Generator, the mapping stands for the same definition. In this paper, we present a way of integrating this general concept into the ObjectGeode SDL simulator (functional meaning). Node : a node is a SDL agent (agent comes from the SDL-2000 terminology) which is either a system, a block or a process. Belongs to : Let us consider two agents e1 and e2 that can be nodes in a SDL model. We say that e1 belongs to e2 if and only if either e2 belongs to the hierarchy of e1 or e1=e2. Mapping : Let us denote S the set of SDL agents that define the hierarchical structure of a SDL model (S only contains process, blocks and one system). A mapping is a function that maps S into a set of nodes M. M is a subset of S such that no node belongs to another (for each pair of nodes (n1,n2), n1 does not belong to n2), and every process belongs to a node. Example: From the above ATM structure, we can define mappings such as (Netware, CentralManager, CashPoints) or (ATM). But (CentralManager) and (CashPoints,CardReader) are not mappings. The first does not cover every process definition. The second defines nodes inside nodes. In ObjectGeode, nodes may be graphically defined using the SDL Editor (as shown at Figure 2). Their priority level is put between parenthesis immediately after the #node action. Nodes may be associated with attributes. The most common one will be the priority attribute. Nodes may also contain methods (c.f. the concept of class in Object Oriented languages). For instance, the following method has been widely used in the FANS project: is_external : signal_in_queue -> boolean Assuming signal_in_queue is a valid signal, this method returns true if the sender belongs to the same node as the receiver (we say that the signal is external to the receiving node). Figure 2. Example of node priority definition Giving a mapping M, an Intra-node scheduling policy is a set of rules that defines how are ordered concurrent events inside a node. An inter-node scheduling policy is a set of rules that define how are ordered concurrent events of distinct nodes. For defining these scheduling policies in details, we need to specify what an event is. Our solution refers to the ObjectGeode Simulator (ObjectGeode SM. 1999). With this approach, « the smallest execution step is the elementary transition, i.e. instruction sequences located between one declared or intermediate state and another declared or intermediate state ». Therefore, an event is the execution of an elementary transition. This approach is applied within the Aerospatiale Matra- Airbus ATSU application too. Finally, at the language level, we need queue data types for specifying scheduling policies. Specific FIFO queues may be associated with nodes. These queues will be special node attributes. For example, in the ATSU project, the rule « each node has a unique FIFO queue for external messages » came in addition to the usual SDL semantics. In conclusion to the presentation of this general framework, resources for integrating scheduling in SDL are : - mapping functions from SDL hierarchies into nodes, - node attributes (priorities or queues for example), - node methods (operating on attributes for example), - intra-node scheduling rules, and - inter-node scheduling rules. II.2 Fixed node-priority scheduling Given a mapping M, each node receives a fixed priority level. When SDL transitions belonging to different nodes are fireable, the ones whose node have the highest priority level are fired the first. This simple rule has no serious consequences on the SDL-96 semantics. It comes after every SDL rules have been verified and only reduces the level of non- determinism. Still, non-determinism may be present: - when a node is a block or a system (and there are more than one process in this node), - when two nodes have the same priority level, - and when several transitions are fireable in the same process state. The reduction of the state graph size may sometimes be significant. Let us consider for example the case of two processes reacting to the same stimulus and acting on a third process in a different way. Considering the situation where both processes can process the shared stimulus, setting up a strict priority between the processes makes the graph size divided by two. It is worth using such underlying mechanism at simulation time when the application normally behaves so. Since no modification of the SDL semantics is needed, it is the responsibility of a classical SDL simulator to order scheduled events upon node priorities. This will be detailed at section III.1. II.3 Scheduling based on node-external/internal events Giving a node, we define an external event as an event that has been initiated by a process belonging to another node. So, an internal event is an event being initiated by a process of the same node. In the case of input events, external means that the sender belongs to a node which is not the receiver’s one. In the case of create events, external means that the create request belongs to a node which is not the created process node. An intra-node scheduling policy that was needed by Aerospatiale Matra-Airbus was the following: giving a node N, - internal signals must be handled before external ones, - signals coming from the environment are external, - timeout signals are external signals, - internal signals are handled in order of arrival, - external signals are handled in order of arrival. This specification can also be resumed by the rules: « an external event is handled when there is no internal action left to do » and « old internal events are handled before new internal events ». Two configurations have been studied: - the system itself is one node and has no environment node (single-node scheduler), - there are several nodes (multi-node scheduler). For the single-node configuration, every signal which is not a timeout is considered as internal and processed with the SDL semantics. The important point is that for each global state, when a transition is fired, it would have been fireable without the scheduling policy, provided no timeout happens. As for the fixed node-priority policy, it is the responsibility to an SDL simulator to make external events fireable according to the scheduling policy. This also means that the single- node scheduler does not modify the SDL semantics. However, the multi-node scheduler requires a modification of the SDL semantics. Each node must respect the single-node scheduling. So each node Ni is associated with two virtual queues (figure 3): - a FIFO queue Fiint that stores internal events, and - a FIFO queue Fiext that stores external events. F1int F1ext Node 1 Fiint Fiext Node i Fnint Fnext Node n Figure 3. Multi-node configuration The problem is the following: when a process instance receives an external signal and then receives an internal signal, its SDL FIFO will contain the two input signals but their ordering can not respect both SDL semantics and the scheduling policy at the same time. Although the internal message is not at the head of the FIFO, it should be handled first. We see there that the semantics has to be modified at the language level so as to take into account the node configuration of the system. Two kinds of modification are possible : - use a new function output(signal,where,pid) that puts the new message signal at a specific place where in the FIFO queue of the specified process instance, or - apply a re-ordering algorithm to FIFO queues after a message is inserted. We chose the second solution because we did want to keep basically unchanged the ObjectGeode Simulator functional behavior (cf. section III.). The problem of choosing the re-ordering algorithm will not be addressed here. Various sorting algorithms can be applied. We propose one of them that is quadratic (simple but could be optimized): Dcl nb_ext,i integer; Dcl Fext SDL_message; Foreach queue F do nb_ext number_of_external_in_queue(F) For i=1 to nb_ext do Fext Search_first_external_in_queue(F) Move_to_end_of_queue(F,Fext) Endfor Endfor Example: Figure 4 shows an example of the application of the above algorithm. FIFO queues are modified so that internal messages are always handled before external ones, whatever the node concerned by the arrival of a message. node int3 ext3 int4 int2 ext4 ext1 int1 ext2 Re-ordering node ext3 ext2 ext1 int3 ext4 int4 int2 int1 Figure 4. Re-ordering of internal/external events With the re-ordering algorithm applied each time a message is inserted in a queue, an SDL simulator can simulate the multi-node scheduler by applying the single- node scheduler to each node. But the SDL semantics modification generates new behaviors, i.e. scenarii that would not have been possible without the re-ordering algorithm. New behaviors arise when : - a process receives external events before internal ones, and - this process would have been able to process internal messages if they were available in the FIFO queue. This means that this process is in a state where several input messages are possible. Let us come back in the past and consider the events that make the external and the internal messages sent in this order. We want to describe in details what are the consequences of the application of the re-ordering algorithm. - We remark first that output statements that produce the internal and the external events cannot be executed in the same SDL elementary transition. A process cannot send an internal and an external message to the same process (as the receiver is either internal or external). - Let us denote Tint and Text the transition that ouputs the internal and the external message, respectively. Let us denote Text<Tint the fact that Text is fired before Tint. Either Text<Tint is true by construction of the SDL specification (case 1), or these transitions may have been fired in the opposite order because they were concurrently fireable (case 2). node node P_ext P_int P m External_m Internal_m Figure 4. Scenario leading to SDL semantics modification - Case 1: figure 4 shows a scenario for which there is the strict causal relationship Text<Tint if in the SDL modelling , the reception of m implies the output of Internal_m. Text outputs a message m that will make Tint fireable. Text also outputs the message that should be re-ordered. The message m is external since the receiver will output an internal message to P. This is a typical case for which new behaviors will be generated. - Case 2: the second case is also illustrated with figure 4 in which the message m has no meaning for that case. Tint and Text are just concurrent. The application of the re-ordering algorithm means that Text<Tint and Tint<Text lead to the same state. This state is defined by the reference sequence Tint<Text. There is no « new » state since it is reachable by changing the order of Tint and Text. In that case, the re-ordering algorithm implicitly performs a reduction of the state graph size. In conclusion to these detailed considerations, we can say precisely what are the SDL constructions that do not act as if the SDL semantics was applied and how they behave. III. Implementation in ObjectGeode simulator Usually, scheduling questions arise at Code Generation phases. Most applications run on operating systems that provide primitives to define and handle communicating tasks. Code generators usually provide means to define how a SDL model is mapped into tasks. This is also possible at simulation phases. Let us see how. III.1 ObjectGeode Simulator overview. The ObjectGeode SDL Simulator has three simulation modes: interactive, random and exhaustive. Introducing scheduling in the three modes was possible due to the presence of two features : - the filter mechanism, that allows the user to prevent some transitions to be fireable, - the GOAL language (Geode Observation Automata Language) that allows the user to observe the execution of an SDL modelling and to monitor this execution. III.2 Goal language. The GOAL language has been developed for verifying SDL modelling (Algayres & al. 1995). A scheduler is a GOAL observer that: - observes events (input, output, create events), - maintains data required for scheduling, - sets a boolean variable to true if the occurrence of an event does not respect the scheduling policy. So a GOAL observer implements a scheduling policy. For example, the node internal/external policy was implemented from its specification with the following principles: - a GOAL observer retrieves required information from the simulator using a number of operators (in_same_node for instance returns true if two process instances belong to the same node); - for each node, the observer maintains two lists of events, one for external events, one for internal events; - when the observer detects an output execution, it updates the corresponding node list with the message; it also apply the re-ordering algorithm; - when it observes an input execution, it checks if there are no other transition of higher priority; if so, it sets up the boolean variable scheduling_error to true. From the ObjectGeode 4.0 release, such a GOAL observer can be found, in the folder $(install_dir)/examples/geode_sm/scheduling in the distribution. It implements the single-node scheduling policy. III.3 Filtering An important feature of the ObjectGeode Simulator is the filter command. It takes a boolean expression E as a parameter. In interactive mode, before letting the user decide which transition will be fired, the Simulator silently executes each fireable transition. During this execution, if the expression E becomes true, then the fired transition is removed from the list of fireable transitions. We say that the transition is filtered. This mechanism is used together with the scheduler observer to avoid the firing of a transition that violate the scheduling policy. When we set up a filter to the boolean variable scheduler!scheduling_error, every transition that does not respect the scheduling is filtered. Then, the simulator can only fire transitions according to the scheduling policy. IV. Application in Aerospace IV.1 The avionics context : The Future Air Navigation System (FANS) is under development at Aerospatiale Matra-Airbus. This system will be soon integrated in A340 AIRBUS aircraft to a first exploitation in the south pacific area. It introduces datalink exchange between Air Traffic Control (ATC) and aircraft. Aerospatiale Matra-Airbus has developed a new on-board computer to implement FANS functions: the ATSU (Air Traffic System Unit). In this computer, a large part of embedded software is derived from SDL specifications. For safety reasons, FANS applications must be carefully developed, validated and verified before their commercial exploitation. Before introduction of the new system into producted aircraft, ATSU computer must be certified. For that, Aerospatiale Matra-Airbus has to prove the quality of the product, the quality of its development, and a high level of test during the development to the airworthiness authorities. FANS SDL specifications are derived from high level requirements specifications. Firstly, FANS system requirements are specified in natural language in a high specification level. Then, ATSU functional architecture is specified. In this one, detailed specification components are defined. These components exchange data inside ATSU to perform FANS functions. At the end, each component introduced in the ATSU architecture document, is specified using several languages . A large part of ATSU detailed components are specified using SDL and MSC languages. After these three specification phases, Aerospatiale Matra-Airbus design office delivers final detailed specifications to the ATSU equipment manufacturer (a division of Aerospatiale Matra-Airbus). Detailed specifications are converted into software which is implemented into ATSU computer. IV.2 The ATSU computer This computer manages air/ground communications. It implements ATC functions (datalink applications between ATC and aircraft). It implements AOC (Airline Operation Control) functions (datalink applications between airline centers and aircraft). Three main steps are identified to specify ATSU functions. Aerospatiale Matra-Airbus has a long experience of formal languages in their specifications. With ATSU computer, it is the first time that SDL and MSC languages are used to specify avionic applications. Formal languages are chosen to : - specify without ambiguities ATSU detailed specifications, - get a high level control of application specifications, and - be reactive for functions evolutions. Telelogic tools has been chosen to specify, validate and verify SDL specifications. Aerospatiale Matra-Airbus has a functional approach to validate and verify ATSU functions. V&V strategy on FANS project identifies two test levels based on ObjectGeode simulations for SDL specifications: - A system level test where all SDL detailed specifications are coupled into a unique SDL model for a « global simulation » of the FANS functions. - A component level test where each SDL detailed specification is isolated to complete the « global simulation». ATSU manufacturer has performed choices to convert automatically SDL specifications into software. These choices have consequences on ATSU computer behavior and so design office takes into account these choices in the SDL specifications simulation tests. This is possible with the ObjectGeode scheduler. With the help of the scheduler, a real progress has been performed to validate and verify SDL specifications : - SDL specifications behavior is closer of software behavior on real ATSU computer and so Aerospatiale Matra-Airbus takes credit of the different SDL specifications simulations performed early in the development cycle. - Non determinism of SDL specifications has been reduced and so the number of test cases to be considered has been also reduced. - Using scheduler associated to ObjectGeode random mode has allowed automation of test sequences with a black box approach of the considered SDL system. - Using scheduler associated to ObjectGeode interactive mode gives an efficient debugging tool to the SDL specifiers. IV.3 Conclusions Today, Aerospatiale Matra-Airbus applies automatic test sequences on each component of the SDL detailed specifications. These tests follows black box philosophy for the SDL model to be tested (one component). This strategy is applicable because the intra-node scheduler has been added to ObjectGeode simulation tools. The inter-node scheduler of Telelogic is under evaluation at Aerospatiale Matra- Airbus design office. After its validation, it will be used for “global simulation” tests. ObjectGeode scheduler has increased efficiency of FANS SDL specifications simulations. Aerospatiale Matra-Airbus takes credit of these tests results to validate and verify specifications and ATSU computer. V. Conclusion This paper reported the use of SDL & scheduling in the design process of new on- board computer ATSU for A340 Airbus aircrafts. Still in avionics, number of improvements have to be done to the certification process that uses SDL. If SDL behaviors get closer to the application code behavior, it is not complete yet. Interruptions or exceptions for example should be handled by ObjectGeode. The new generation of UML, SDL & MSC tools should have serious features to help aircraft manufacturers bringing efficiently together real-time application and communication system design processes. One challenge for that will be to unify deployment definitions at simulation and code generation steps. Acknowledgements: Thank you to Alain Kerbrat and Anders Ek for their comments about this paper The authors would like to acknowledge Claude Aubry for his initial work on the scheduler. References (Alvarez & al. 1999) J. M. Alvarez, M. Diaz, L. M. Llopis, E. Pimentel and J. M. Troya. Integrating Schedulability Analysis and SDL in an Object-Oriented Methodology for embedded Real-time Systems. In SDL’99. Elsevier. pp 241-256. 1999. (Algayres & al. 1995) B. Algayres, Y. Lejeune and F. Hugonnet. GOAL: Observing SDL Behaviors with GEODE. SDL’95. Elsevier. pp. 223-230. 1995. (Goudenove and Doldi. 1995) F. Goudenove and L. Doldi. Use of SDL to specify Airbus Future Air Navigation Systems. In SDL’95. Elsevier. pp. 359-370. 1995. (ObjectGeode SM. 1999) ObjectGeode SDL Simulator Reference Manual. (ObjectGeode). 2000. (ObjectGeode) www.telelogic.com. VERILOG page. ObjectGeode Product. 2000 (Telelogic Tau) www.telelogic.com. SDL suite product. 2000.
Pages to are hidden for
"Scheduling with SDL"Please download to view full document