Scheduling with SDL by gvy99938

VIEWS: 7 PAGES: 14

									                       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.

								
To top