A S Chazel

R Delajudie

S El-Fassi

J Y Danic

High Availability Train To Wayside Communication System For Subway Application Using 802.11X

Keywords:

Wireless transmission for train to wayside communication is now a reality, including for the train control application.

However subway applications entail specific constraints, such as environment, high speed mobility, need for a rugged data communication system with very high availability of the links and specific requirements in terms of quality. In addition, the operation of such system requires more throughputs for offering additional new services such as video or other data communication for other sub-systems. Finally, the life of the system shall be at least of 30 years.

The challenge is to design a whole system and an architecture integrating products from the 802.11 family (WiFi). These products should be available on the market and they still have to meet all the requirements mentioned above. The present approach focuses on modularity, redundancy architecture and control of the link budget. Dedicated optimized algorithms address mobility features.

Introduction

In advanced automatic train control systems such as Communications-based Train Control (CBTC), the safety of train movements, including collision avoidance, no longer relies on the detection of the occupancy of track circuits, but rather on the onboard computer's knowledge of the track layout, of the location and of the relative speed of trains. Indeed, a CBTC system relies on the three following features:

High-resolution train location determination, independent of track circuits; Continuous, high-capacity, bi-directional track-to-train data communication; Onboard and wayside processors performing vital functions.

A reliable bi-directional transmission system offering high availability is therefore essential for achieving CBTC performances.

The information exchanged between wayside and onboard equipment is of various types:

Track layout information is sent to the onboard equipment. This information includes fixed data describing the geographical features of the track and varying data such as the occupancy status of the track circuits ahead of the train, position of switches, speed limits etc. Necessary information for computation of the "Movement Authority Limit" such as position and speed of the trains on the track and stopping points. The refreshment rate is rather high in order to meet the safety requirements and the headway requirements. Remote control and monitoring data exchanged between the onboard equipment and the OCC (Operations Control Center) to support operation and maintenance. Critical information for driverless train operation, sent to the CBTC to execute safety functions such as authorizing train departure from stations, passenger transfer at the station and train evacuation management in case of failures, functions normaly performed by the human driver.

Since the early Automatic Train Control (ATC) systems, there has been a constant trend to transfer intelligence from wayside systems to onboard systems, putting even more emphasis on the data transmission system.

In the very first generation of ATC systems, there was no need for data transmission as the safety of train movement was ensured by the train driver himself through compliance with line-side signals.

The location of trains was detected by wayside equipment. The second generation of ATC systems relied on minimal track-to-train transmission. Speed codes were calculated by the wayside equipment and transmitted to the onboard equipment. An alternative design was for onboard equipment to read speed profiles inscribed in the transmission lines installed in the track. In the latest generation, track-to-train transmission is more sophisticated. Information about track circuit states is transmitted from the wayside to the onboard equipment. Then, the onboard control unit estimates its own speed curve.

In the CBTC generation, continuous and bidirectional transmission is fundamental. The train estimates its own location and speed which is sent to the wayside equipment. The wayside equipment then transmits to each single train its target point. The first CBTC relied on data communication systems based on transmission lines installed in the track.

Advances in free-propagation radio technology, particularly in the military field, provided the opportunity for significant progress in the transportation field.

High Availability needs

As said above, ATC needs a continuous transmission of data, in time and in space to achieve safe operation and meet system performance requirements.

-In time by guarantying that the data communication is uninterrupted and current. In case of lack of communication between train controllers and wayside equipment, all trains of the area shall be stopped to preclude any safety hazard, which makes a great loss of system availability.

-In space by guarantying good communication coverage between train controllers and wayside equipment over the entire line. A train can potentially stop anywhere along the line. Safe operation cannot rely on an approximation, but on the precise position of each train, especially with very short vehicle headway,

The CBTC has been developed for guarantying the high safety level and the high performance required in terms of headway and system availability. To avoid any weak point on the system architecture, the data communication system shall be very reliable using proven transmission technology. The main goal is not to maximize the throughput but rather to optimize a given channel for very low packets losses and guarantied data transmission. Another aspect of the availability is to offer, for each message, latency small enough to meet message refresh rate requirements.

These types of requirements might appear in contradiction with the use of a radio channel, as the radio propagation is a probabilistic phenomenon.

As it is now well documented, in railway environments, in tunnels, due to reflections and diffractions on the environment (wall, floor, obstacles…) free propagation of radio air create multipaths between the transmitter and the receiver. Recombination of these paths on the receiver side is more likely to impact negatively on the level of the received signal. Mathematic models can help predict the mean level of the radio signal received. That prediction takes into account not only the transmitter and receiver position as well as the description of the environment. The impact of fading however can't be described more precisely than by using a probability law.

Radio propagation in the metro is highly variable, due to the train's motion and crowd movements in the stations… It's obvious that all the operational situations lead to various and unpredictable scenarios of propagation. In such condition it's almost impossible to define a precise model that can be verified by measure or computation.

In addition, to provide the continuity of the transmission services, we have to deal with the reliability of any piece of equipment. The availability of the system shall be preserved including with theinevitable-breakdowns of the hardware used.

Other specifics constraints

High speed and high speed mobility

One advantage of wireless equipment is to be free of any physical link and therefore the mobility is drastically improved. But when mobility is used in this context, it's more or less a convenient way to get connectivity from one location to another; one can imagine someone in an office, moving from a place to another with his/her personal computer. Such wireless equipment installed in a train will move at higher speed! Therefore impact of the velocity on the quality of the transmission has to be verified. Moreover, the radio coverage of a wayside radio equipment is limited to a few hundred meters. Consequently a large part of the time is lost while the train radio is switching from a wayside radio to the next. And, last but not least, since a train must be reached anywhere along the line, the routing process must be seamless. As the train is moving, the network routing has to be dynamically updated in accordance with the actual configuration of the network.

In summary WLAN are currently designed for a "nomad" use of wireless equipment. Nevertheless, thanks to dedicated configuration settings it is possible to achieve our application requirements and to have a reliable and fast mobile use.

Life duration of the system

A subway system is designed to be used during a very long time. The oldest subway networks are more than one hundred years old… Of course it doesn't mean that each particular device has to be in operation during all this time. Hardware failures are inevitable. But it means that it must be possible to repair or to exchange a device when necessary. And when exchange becomes impossible because of hardware obsolescence, the function must be still fulfilled when the defective part is replaced. This lifetime duration is clearly not the one of the WLAN technology.

Radio standards are still in a fast evolution phase. Since the first publication of the 802.11 standard in 1999, three amendments about the physical layer have been published or are to be published in the next months (802.11a/h, 802.11b, 802.11g, 802.11n). The data rate has been dramatically improved, and a new bandwidth has been allocated for the RLAN application. In addition some amendments about the protocol have been published.

High availability requirements

Every hardware device, even the most reliable canand will-fail. The equipment reliability is characterized by its MTBF (Mean Time Between Failure). This figure is the result of the assessment based on tables giving the reliability of each individual component in several environmental conditions (temperature, vibrations...). These elementary figures are derived from the past experience. The more devices are used in a transmission chain, the more often this chain should be interrupted by a failure. If a function needs N equipments to be performed, the MTBF of the whole function will be (assuming that equipment failure are independent) :

1/MTBF=1/MTBF 1 +1/MTBF 2 ….+1/MTBF N [1]
For the data communication system of the subway, a failure in a single train or in a single wayside radio, even for a few minutes, has often operational consequences for all the line, and for a long time.

The system architecture must thus guarantee that a single failure won't have any functional consequences.

The answers to these constraints

Regarding all of these constraints, the choice of the radio technology for providing an answer to the point to point link is important but not sufficient in itself to comply with all requirements.

Individual physical link

Even if the propagation condition can't be totally controlled, the knowledge of the typical parameters to be taken into account allows to take the right level of margin in the transmission in order to guaranty a very high rate of successful transmission.

These parameters include:

-the different environments of propagation (tunnel or outside tracks) governing the attenuation laws,

-the specific influence of the curves in tunnels, -the fading repartition, depending on the bandwidth used, -the influence of the location of the other trains, including when they are "blocking" the tunnel.

The figure below shows the typical level of received signal by 2 onboard radios installed at both ends of the train, while the train is moving from one side of the wayside radio to the other. In addition, the behaviour of the different type of modulations may have an impact on the propagation conditions (speed, multipath pattern in tunnel…). Therefore introducing a new type of modulation requires some verification.

Seamless handover and roaming

In order to optimize the radio coverage, one WLAN client is used at each end of the train. Only one is transmitting at any given moment. The transmitting WLAN client is qualified as Active. The other WLAN Client exchanges management frames with Access Points along the track, in the frame of the "Association Process", but is not used for communication purposes.

The Trainborne Router controls this diversity, and Wayside Routers have to update the Wayside Network routes accordingly.

The Active WLAN client is the one who has the higher RF signal quality. This signal quality is quantified by the RSSI obtained through SNMP (Simple Network Management Protocol) periodic requests (for instance every 300ms). The RSSI based routing algorithm handles as follows:

o The Trainborne Router sends SNMP periodic requests to both WLAN Clients.

o The Trainborne Router chooses as the Active WLAN the one that has the best RSSI.

o In order to deal with RF fading and avoid unnecessary route changes, it is possible to take into account several successive RSSI reports and to apply an algorithm (e.g. hysteresis law) before making the decision to switch from an active WLAN client to the other . o The radio coverage is significantly improved so the distance between the Access Points on the line can be increased.

o Due to clearance issues in Mass Transit tunnels, it is typically impossible to fit an antenna above the train roof for increasing the radio coverage. The antennas are installed at each end of the train. The client diversity is a good design solution to address this issue.

Redundancy

To answer to the high availability requirement, each hardware device has to be doubled, but it is not enough. The redundancy question is to determine how both redundant equipments will work together. A simple solution is to have two independent chains side by side. One is used at a time, and if a failure is detected, traffic is switched on the other chain. But this doesn't provide a correct answer to our problem because failure detection time and reconfiguration process will last too long time to be considered as fully transparent.

To achieve the redundancy switching in a full transparent mode, the redundancy architecture principle has to be tolerant to a single failure. Our preferred solution is to provide 2 independent chains transmitting in parallel two copies of each message (at least for the CBTC traffic which communication availability is a must, video and voice application require lower availability).

Built in test equipment

The redundant architecture allows being tolerant to a single failure. The probability of a second failure at the same place, before the first one has been fixed, is assumed to be very low, so the MTBFF (mean time between functional failure) is high, and the availability figure specified can be reached But this assumption is correct only if the first failure is detected in order to be fixed. As this failure has no functional consequence, it had to be done by a specific function of supervision and alarm. This function has to be precise enough to allow efficient corrective maintenance. As the hardware equipments (especially the radio) are distributed all along a subway line, and in order to be efficient, that function determines exactly the location of the broken-down equipment. Thus, the time to fix the failure is optimized and the time to repair goals might be adjusted accordingly.

But this type of built-in test equipment is quite specific and doesn't exist natively in the products.

Conditions for a controlled evolution

Architecture modularity

To manage obsolescence of some part of the system, and benefit from the constant evolutions of the radio technology, it is necessary:

To define elementary functional blocs with standardized interfaces. It must be possible to change the way to implement a functional bloc without changing its interfaces, in order to allow independent evolutions of the blocs. This evolution can be done with the same performances or with enhancement of performances (for example, for the radio link : higher throughput…) In that case, the other blocs of the chain must be well dimensioned to be able to draw part of this enhancement (typically, if the radio link throughput is increased, the wired link at both side must also support higher throughput…)

To determine precisely which features and performances are completely described in the standards: they should be met in every implementation. Other characteristics should vary from one supplier to another.

To be able to add or remove some wayside radio without modifying everything.

Test plan

Since off the shelf devices are used and evolve frequently, it's important to determine a comprehensive test plan to be sure that all the functions of the whole system are still meet the requested performances

How WIFI radio can be used?

The various criteria listed here-below can be checked:

-Is radio technology suited for a transmission with trains (regarding multipaths, speed …)? It has been tested and the results have been found suitable up to the 802.11g family. The 802.11n seems to bring also new and very interesting features.

-Are interfaces well defined by standards in order to get more flexibility in the choice of supplier?

The answer is yes, as the WiFI alliance goal is to assure the interoperability between suppliers. On the other end, the use of specific feature not governed by standards shall be done knowingly and always after deep analysis -Are performances clearly guarantied in all cases? What are the impacts on the other parameters, as implementation might have influence, for example, on the sensibility of the receiver, or the time it takes to perform the association… Comprehensive tests have to be carried out, and some parameters of the system have to be adjusted.

-Is there a stable and well defined functional breakdown? Yes and no. Functions are well described in the standard, but the different amendments have progressively added new functions. Typically some "quality of service" functions have been introduced in the standard by the 802.11e. It's possible that the future 802.11r amendment will solve the seamless handover and roaming question…

Conclusion

As a conclusion, we would like to point out the fact that building a radio communication system with the specific constraints of the train to wayside subway application is much more than to choose a radio technology well suited for propagation in tunnels. Since radio technology is quickly evolving, it might be interesting to draw part of these evolutions by upgrading only some components without having to replace the whole communication system. For that, two necessary conditions are highlighted: -The modularity of the architecture of the system, with a clear function breakdown of the system, using standardized interfaces between elementary functions, -The definition of a comprehensive non regression plan to be able to assess the impact of the change of one piece of the puzzle on the overall performances required at the system level.

Acknowledgement

The authors acknowledge the contribution of their colleagues to this work namely Regis Lardennois, and the attendees of the 2007 test campaign.

Figure 1 :

 1 Figure 1 : Received signal level by a radio at each end of a train

Figure 2 :

 2 Figure 2: Carborne and wayside architecture for a seamless handover and roaming

  point ATC : Automatic Train Control CBTC: Communication Based Train Control IP ; Internet Protocol MTBF : mean time between failure MTBFF : mean time between functional failure WLAN : Wireless Local Area Network


Jean-Yves Pierron
email: jean-yves.pierron@cea.fr

Michel Sall
email: michel.sall@trialog.com

Nicolas François
email: nicolas.francois@trialog.com

Philippe Robin
email: philippe.robin@trialog.com

AGATHA / TTS: from UML modeling to test case generation and execution

Keywords: symbolic execution, test case generation, test automation, TTCN-3, UML modelling

This paper presents the results of a work done in the Software Factory / MoDriVal project which is part of the French System@tic cluster.

The MoDriVal project focuses on the verification of complex systems at various stages of the development cycle from specification and modelisation to final product acceptance.

The paper highlights the work performed in the MoDriVal project on the combined utilisation of a UML-based test case generator and a TTCN-3 compliant test engine. The test case generator is the AGATHA tool from CEA LIST research lab. AGATHA tool implements a method for analysing UML models of requirements and for identifying the test cases corresponding to the requirements. This method uses the symbolic execution technical approach and a constraint-solver to generate numeric tests.

The paper presents the method of analysis and how it was extended in the course of the MoDriVal project. The test case script generator of AGATHA was adapted in order to deliver scripts written in TTCN-3 test language. The test engine is TTS, a test technology developed by TRIALOG, a system and software engineering company which was coresponsible of the integration of AUTOSAR Basic Software Validator 2.

The paper presents shortly the TTS technology, how it was extended to support TTCN-3, a standardized test language designed to support conformance and interoperability testing and how both AGATHA and TTS tools were used jointly to generate and run test cases on two actual use cases: an Internet gateway and an automotive basic software module.

Introduction

Section 2 of the paper presents an overview of AGATHA test case generator and of the underlying principles. Section 3 presents shortly the TTCN-3 test standard and introduces the TTS test execution engine. Then sections 4 and 5 focus on the use cases and on the return of experience from the joint utilisation of AGATHA and TTS for generating and executing test cases.

Overview of AGATHA

1.1. Overview of UML models used UML formalisms are more and more used by the industry. Our case study is based on a subset of OMG UML2 standard [START_REF]Unified Modeling Language: Superstructure, V2.1.1[END_REF]. We model our systems with class diagrams and activity diagrams. The class diagrams describe the data and the activity diagrams describe the behaviour of the system. We chose to model the behaviour with activity diagrams in order to connect our approach with Accord Action Language [START_REF] Dubois | Un Langage d'Action pour le développement UML de systèmes embarqués temps reel[END_REF] which is based on these diagrams.

In a class diagram, the classifiers which can be used are Class, Interface and Signal. The attribute types can be a Primitive Type like Integer and Boolean, a Classifier or an Enumerate type. Active classes contain operations whose methods are defined by an activity. We support the following actions of the activity diagrams: Accept Event Action, Call Operation Action, Broadcast Signal Action, Read Extent Action, Send Object Action and an Opaque Action (for affectation).

The communication between activities or between the system and its environment are modelled by called operations, or events (signal or object broadcast and reception). Symbolic execution has been introduced in [1] and in [START_REF] Gallois | AGATHA, un outil de simulation symbolique[END_REF] to construct structural tests for sequential programs. The principle of the symbolic execution is to evaluate the model behaviour with symbolic values for the system input data. In this case, we can consider this technique as symbolic simulation. The symbols correspond to the set of numerical values which could be taken by the variables and the system input parameters. The values of output parameters are computed with the symbols. The result of simulation is a symbolic behaviour graph (or tree). This graph is made out of states and transitions. The states match with the activity nodes and include symbolic affectations of the system variables. The transitions include logical constraints on the symbolic input data. Constraints are computed with control flow guards. We call these constraints path conditions because they correspond to the conjunction of the encountered guards to reach a symbolic node.

Activity Diagram Symbolic Behaviour Tree

AGATHA tool uses the symbolic execution for extended automata. The fundamental bases of this tool are described in [10]. One of AGATHA originalities is to associate a redundant evaluation detection mechanism with the classical symbolic execution method. This approach can reduce, in certain cases, the combinatorial explosion. Figure 1 shows the redundancy elimination on D1 and D2 states of the behaviour tree. Indeed, the executions from D1 and D2 states are redundant with the executions from the D0 state, because the system variables (x and y) are more constrained in D1 or D2 than in D0. We can say that the variable domains of D1 or D2 are included in the one of D0.

In order to compute inclusion procedures, AGATHA works with the Omega Library1 for specifications based on Presburger Arithmetic [START_REF] Presburger | Über die Vollständigkeit eines gewissen Systems der Arithmetic[END_REF].

During AGATHA computation, the symbolic expressions of variables and path conditions may rapidly grow. To solve this problem a simplification procedure must be applied "on the fly" in order to shorten expressions and detect useless paths. The procedure is based on rewriting techniques. AGATHA uses Brute rewriting engine which is part of the CafeOBJ toolset2.

Test case creation

Prior to this project, some work has been realised on test case creation with AGATHA from UML models. The work is described in [1], [START_REF] Bigot | Une proposition de formalisme orienté composant -Application de méthodes d'exécution symbolique pour la validation de systèmes à base de composants[END_REF] and [START_REF] Lugato | Validation and automatic test generation on UML models : the AGATHA approach[END_REF] and has led to industrial study cases described in [START_REF] Bigot | Automatic Test Generation on a (U)SIM Smart Card[END_REF] and [START_REF] Lugato | Automated Functional Test Case Synthesis from THALES industrial Requirements, RTAS 2004[END_REF]. One of the added values of the work is to use the activity diagrams of OMG UML2 standard [START_REF]Unified Modeling Language: Superstructure, V2.1.1[END_REF].

AGATHA input language is based on communicating state transition graphs. In brief, these graphs are encapsulated into state machines which contain variables and communicating ports. The variable types can be boolean, integer, enumerated or structured in a record. TTCN-3 numerical test case creation with AGATHA can be summarised in four steps as described below.

The first step in creating test cases consists in translating UML diagrams into AGATHA input language. In our translation, we distinguish two types of classes: the passive classes which do not contain The second step consists in generating symbolic test cases. From the symbolic execution tree generated by AGATHA, we consider each behaviour path as a symbolic test case. Each symbolic test represents an equivalence class of numerical tests.

The third step consists in solving constraints to generate numerical test cases. AGATHA uses Omega constraint solver. We choose to generate one numerical test for each symbolic test. A test case is made of one input / output message sequence. Each message contains numerical parameters.

The fourth step consists in translating numerical test cases into TTCN-3. In our approach, we consider that the main test component of TTCN plays the role of all environment actors. The input messages (output messages respectively) are translated into send messages (receive messages respectively). But as we will see later ( § 5.3.2) this translation may depend on the role played by the tester.

Overview of TTS test technology

The TTCN-3 standard

The Testing and Test Control Notation Version 3 (TTCN-3) is the third part of the Conformance Testing Methodology and Framework (CTMF) standard for the specification of test suites for conformance testing [START_REF]ETSI: Methods for Testing and Specification (MTS), The Testing and Test Control Notation version 3 -Part 1: TTCN-3 Core Language[END_REF].

An important feature of TTCN-3 is its enhanced communication concept that includes both a procedure -based communication scheme that supports synchronous communications and a message -based communication scheme that supports asynchronous communications. In addition, other features have been introduced in order to provide a better control and a better organisation of test cases. New data types have been added too,

Black-box testing using TTS

The black box testing approach considers the test object from an external viewpoint. These tests can be functional or non-functional, though usually functional. The test designer selects valid and invalid inputs and determines the correct expected outputs. He/she has no knowledge of the test object internal structure 3 .

Figure 3: Test system vs SUT

TTS test environment is composed of a test execution engine (TTS = Trialog Test Software) which is actually the core of the environment and of stubs and proxies that support the interactions of TTS with the SUT through PCOs4 (see Figure 3). For example all the messages specified in a TTCN-3 test suite are sent or received through these PCOs. The stubs and proxies are specifically developed for a given SUT and are plugged into TTS through an API. AGATHA uses its own input/output language. Thus in order to translate UML models into AGATHA input language and to translate AGATHA output language into TTCN-3 test cases, we have defined metamodels for AGATHA and TTCN-3 languages and we have applied model-to-model translation techniques based on UML2 and EMF repository plug-ins. The translation rules are implemented in Java.

Joint utilisation of AGATHA and TTS

The third element of the tool chain is TTS translator which translates TTCN-3 scenarios into byte code executable by TTS execution engine. Eclipse plug-ins have been developed for managing TTCN3 projects and launching TTS translator.

The various translators are identified on Figure 2 above. AGATHA translator supports the transformation of UML2 models into AGATHA input language.

TTCN-3 translator supports the transformation from AGATHA language into TTCN-3 language. TTS translator supports the transformation from TTCN-3 language into TTS internal byte code.

The fourth and last element of the tool chain is TTS execution engine which reads and executes the byte code generated by TTS translator. During the execution of a test case, messages are exchanged between TTS and SUT through the port specified in the test case using the stubs and proxies (see Figure 3).

In order to verify AGATHA capabilities concerning the automatic generation of test cases, we elaborated two use cases. The first use case is relevant to the telecom domain and the second to the automotive domain.

Use case #1: Internet gateway for domestic appliances

Overview of architecture and requirements

In the first use case, we want to test an Internet gateway to the home. The gateway (namely PIPE) allows a user to remotely control domestic appliances. The appliances and the gateway are interconnected through a power line network (cpl) using the EHS 6 protocol (see Figure 4).

Figure 4: PIPE architecture

The test architecture is depicted on Figure 5. TTS is connected to the gateway through the Internet and

Description of UML model -activity diagrams

As said before we have modelled PIPE in UML using class and activity diagrams. The class diagram contains the description of all the classes that compose the application and the description of all the messages that PIPE exchanges with the environment. In the activity diagrams we have described the behaviour of PIPE upon receiving a message. The gateway was modelled only partially. The resulting model is composed of one class diagram and five activity diagrams.

Return of experience

During this experimentation we have discovered a certain number of issues that we describe below.

Null object not supported

The first issue is about the absence of null object. For example one of the five activities modelled verifies that the "Instance Id" contained in the incoming http_frame corresponds to an EHS object actually known by the gateway. We wanted the activity to return the device descriptor of the corresponding EHS object if it finds a match and null if no match is found. But AGATHA does not manage the null object.

Therefore we had to introduce (somewhat artificially) a specific device object (i.e. device_null) which stands for the null object where a device object is expected. And we had to do the same for other classes (i.e. http_frame_null and ehs_frame_null).

For the sake of clarity we created a new activity and put the initialisation of these pseudo-objects in this activity.

The sequencing of messages in TTCN-3 test cases

The second issue concerns the translation from AGATHA to TTCN3. In order to illustrate this problem, we will use the communication sequence of Figure 6. Send a http frame receive http frame receive an ehs frame receive an ehs frame receive a smtp frame This issue can be easily solved. In the description of the gateway we add a description of the different actors 7 . Then we indicate to the translator the role played by the tester and we specify if this role is passive or active. In our experimentation, the tester will act as a passive ehs actor (it only receives ehs frames). But if want to test the gateway without connecting it to the EHS network, the tester will act as an active ehs actor. In other words, it can send ehs frames to the gateway when needed.

The generation of verdicts

The third issue concerns the generation of the verdict. In a way it is linked to the second issue. Let have a look at it through the previous example (see Figure 6). TTCN-3 translator inserts a set-timer instruction in TTCN-3 test cases, before each waiting-for-message instruction, and a timeout instruction alternative after the waiting instruction. If the first ehs_frame does not arrive in due time or is incorrect, a fail verdict is generated. No problem. But for the second ehs_frame, this is not correct. Since the second frame is not sent by the gateway, we cannot consider the gateway to be responsible for the fact that the expected message is not received or is incorrect. An inconclusive verdict must be generated instead of a fail verdict.

The solution to the issue described in § 5.3.2 will help in solving this issue as well. With the knowledge that TTS is a passive observer on EHS network, TTCN-3 translator will be able to generate the correct verdict.

PIXIT

It may happen that the value of an attribute in a frame is not known at specification time, because it depends on the equipment manufacturer or on the implementation. The idea is then to use the concept of PIXIT. Briefly, a PIXIT is a symbol that will receive a value at test execution time. In our test case, this would be very useful to define the "Instance Id" of the http_request frame and the addresses of the EHS equipment as PIXIT.

The current version of AGATHA does not support this PIXIT concept.

Preamble and postamble

The fifth issue concerns the well known preamble and postamble subsets of a test case. When we write manually a test suite, we are used to add a preamble before a test case for setting the SUT in the state required for the test case to be executed and to add a postamble after the end of the test case for setting the SUT back to the initial state.

But AGATHA proceeds in a different manner. It takes the different activities as a whole and generates all the necessary test cases in order to traverse all the branches it has detected. Finally at execution time the result is more or less the same as the one we would have achieved manually. The only drawback is that in the test suite generated by AGATHA, there are many repetitions (no factorisation is performed actually). But this might be considered as just a purist's point of view.

Enumeration

An attribute might accept only a short list of values (for example an enumeration type attribute). In this case, we want to be able to verify that the SUT effectively can accept each value of the list (or enumeration), that the SUT behaviour is as expected and that the SUT rejects values which are not in the list.

AGATHA picks up just one value out of the list and therefore generates only one test case with this value and another test case with a value that does not belong to this list. This is not sufficient. 5.3.7. About the abusive usage of literals TTCN-3 language supports the concepts of constants and templates. A template can be viewed as a structured constant in the sense that it is a record whose fields are all valued. TTCN3 translator does not use these concepts. Instead, it uses a literal each time a string message must be printed and passes all the values of a record each time a send or receive action is called with this record as parameter. But TTCN-3 translator generates all the test cases in the same file. When the same literal is used in multiple test cases, it is not factorised by TTCN-3 translator. This causes a lot of object creations (when an object is sent or received, or when a message is displayed by the test case).

For example, when a ehs_frame is received, a string is printed for the user. The same string is used for each test case in the same situation. But because a literal is used instead of a constant, a variable is generated for each test case and its value is duplicated. Continuing with the example of the ehs_frame reception, we have about 20 literals, all with the same value "an ehs_frame has been successfully received".

One could argue that a solution to this problem is to switch TTCN-3 translator in a non verbose mode but this does not work for the record values since send / receive actions must be used.

However for the telecom domain, creating a lot of objects would not really be an issue because test suites consist generally of several megabytes. But TTS was designed as a technology for embedded testers and the memory space it can manage is limited.

Conclusion

Some of the issues we have described above are due to the fact that we have developed the UML model of the PIPE application with the objective that it could be used for the development rather than for the test of this application. In other words we did not try to facilitate the work of AGATHA in specifying a model devoted to test. More precisely we did not want to have two UML models, one for developing the application and the other one for testing it because managing two UML models would raise the problem of maintaining their consistency. Nevertheless all the test cases generated by AGATHA have been successfully compiled by TTS translator and executed by TTS execution engine after the PIXIT issue has been corrected manually.

Use case #2: CAN Bus Off Recovery

Overview of requirements

Our second use case to test AGATHA and TTS is inspired by AUTOSAR [1] which is an international consortium founded in 2003 by automotive manufacturers and suppliers to develop a de-facto standard for automotive electrical and electronic architectures. The reason for selecting this use case is that the specifications produced by AUTOSAR are based on UML and that the conformance tests for AUTOSAR basic software modules shall be written in TTCN-3.

Our goal was to derive a test case for a basic software module from the set of specifications for the module. We selected for that purpose a part of a software module dedicated to the detection, confirmation, report, and recovery of a network error on a CAN bus ("CAN bus off").

Description of UML model -activity diagrams

The first step of the test engineering process was to describe the interface of the system and to specify how the system interacts with its environment (API calls, callbacks, notification, etc.). This first step is modelled as a Class diagram.

Our class diagram contains one class which corresponds to the system under test (SUT) and other smaller classes used for the communication with the environment: object for the communication to a central event repository, communication with the bus driver. We used different properties in the main class for instantiating these objects which have to be passed to or received from the environment, or for defining some constants used to describe the system behaviour.

Then we had to model the intended behaviour of the system, based on the AUTOSAR textual specifications. The goal of the model is not to define a complete UML specification of an implementation, but only to define the behaviours of the system that we are willing to test. The formal specification in UML of the system would have been a much more complicated task. Our model was simpler because it relied on the expected behaviours defined by the requirements of the AUTOSAR basic software module specifications, with no architectural consideration.

We ended with an activity diagram of about 50 control flow transitions and actions, and AGATHA was able to derive 22 test cases from this activity diagram.

Return of experience

Building an UML model for AGATHA was much simpler than designing a complete implementation. The test designer only had to focus on the major requirements that have to be tested.

AGATHA needed an activity diagram while the original algorithm was based on a state machine. So we had to convert the original specification, but the formalisation in an activity diagram allowed us to find an issue in the specification.

Then AGATHA allowed us to define the tests required to cover the modelled algorithm completely. Some of the tests have an important depth and would have probably been forgotten with a manual definition of test cases.

Conclusion and perspectives

The work described in this paper resulted in a set of requirements for improving both the technology readiness level of AGATHA and TTS/TTCN-3.

The solutions to the issues described in the first use case (enumeration, sequencing and generation of verdicts) will be implemented soon in AGATHA. For the enumeration issue ( § 5.3.6) TTCN-3 translator will generate as many test cases as the number of values in the enumeration with the possibility for the test developer to use or not to use this mechanism. Concerning the sequencing issue ( § 5.3.2), TTCN-3 translator will generate the correct sequence of messages based on both the collaboration UML view and the information about the role played by the tester. For the verdict issue ( § 5.3.3) the correct verdict will correspond to the passiveness or activeness of the tester. Some more work and brain storming will be needed for the PIXIT issue. For the memory issue ( §5.3.7) a simple solution is to modify TTCN-3 translator or TTS translator for generating one test case per file and grouping these files in a test campaign.

UML is an object oriented language which offers the dynamic creation and deletion of objects. Currently AGATHA tool does not compute such mechanisms in its symbolic execution. It would be interesting to add them in future versions of the tool. Thus, we could support the dynamic process creation and the null object detection. Implementing such mechanisms in AGATHA implies some formal work in the symbolic execution domain.

Figure 1 :

 1 Figure 1: Symbolic Execution 2.1. The symbolic execution technical approach

Figure 2 :

 2 Figure 2: The test generation and execution tool chain behaviour and the active classes which contain behaviour. The passive classes are translated into record types and active classes are translated into state machines. Each operation is translated into two communicating ports. The first is used to exchange input parameter values and the second is used to exchange output parameter values. Each activity diagram of an active class is translated into a state transition graph where each activity node appears as a state. The communicating actions (AcceptEvent, CallOperation, BroadcastSignal, ReadExtent, SendObject) are translated by ports and by output or input messages on their respective ports. All ports are connected in order to support the modelled communication.

Figure 2

 2 Figure 2 depicts the architecture of our test generation and execution tool chain. The tool chain is plugged into the Eclipse platform. The Eclipse project provides repository plug-ins able to manipulate UML models. The Eclipse Modelling Framework (EMF) plug-in is a Java implementation of metamodels. UML2 plug-in uses EMF to implement the entire UML2 standard. AGATHA translator is based on these plug-ins in order to accept UML models created with modellers like Papyrus 5 or IBM Rational Software Architect.

Figure 5 :Figure 6 :

 56 Figure 5: The test architecture

  on the EHS network. sends requests to the gateway using HTTP protocol, receives acknowledgements with the same protocol and receives responses with SMTP protocol. And of course all the messages TTS receives from EHS domain use EHS protocol.

	observes what happens
			stimulation	Stubs & proxies
		s s
	T T	y y	PCO
	e e s s	s s t t	SUT
	t t	e m e m	PCO
			observation	Stubs & proxies
				6 European Home System

The Omega Library V1.1.0, University of Maryland, http://www.cs.umd.edu/projects/omega

Brute rewriting engine, GAIST, http://www.theta.theta.ro/cafeobj

See Wikipedia

With TTCN-3 the term PCO is no longer used. It has been replaced by PORT which is more generic. But some habits are difficult to loose.

Papyrus is an open source project of UML modeller developed by CEA LIST. (http://www.papyrusuml.org)

in fact this is something we ought to have think about at the very beginning of the modelisation independently of the test

Acknowledgement

The authors acknowledge the contribution of Dorian Baranes for his precious help in TTCN-3 translator development.


Christian Charreyre

Using Linux for industrial projects -A return of experience

Keywords: Linux, embedded, real time, return of experience, porting from RTOS to Linux

This article describes industrial projects involving embedded and/or real time Linux. After an introduction dedicated to place Linux regarding the embedded software market, it explains the adoption process of Linux in our company, that was working will legacy RTOS since years. Then it emphasizes 3 aspects of using Linux in industrial projects : using Linux in an embedded device, using Linux in a real time context and porting an application from legacy RTOS to Linux. The article ends up with the problem of management in an industrial context of a software base that moves very quickly, and explains what philosophy to adopt regarding evolutions control.

Introduction

Regarding Operating Systems, the embedded software market has been for years divided into a lot of proprietary solutions offered by many specialized companies. The economic model of such offers is based on royalties paid by customers for each device including the O.S., plus development tools (integrated development environment, performance analysis tool etc….) that generally represent important costs, mainly for little companies.

Since a few years, Linux is a new and fast growing actor on this market. In March 2007, the French magazine 01 Informatique [1] stated in his article about RTS Embedded Systems 07 that Linux was now about 50% of the Embedded OS market.

The annual survey of the Web site linuxdevices.com [2] presents the same growing tendencies, and it appears that the couple of ARM processor with Linux OS is a great solution for low price mass market devices.

Our company is specialized since 1990 in software development for embedded and real time applications, and we have used the various legacy real time OS during years. At the beginning of 2000, Linux began to appear in the professional press, not as an embedded solution, but as a great OS for servers.

As the management of the company has worked with Unix solutions on workstations in aeronautics, we decided to invest in Linux technologies applied to embedded and real time projects. This choice was based on the idea that a Unix like solution useable on low prices devices such as PC based hardware, and with no royalty cost, would certainly be very interesting.

The adoption of this OS as the base of the great majority of our projects has been done into successive steps :

• Use of a Linux distribution on standard PC, then on more industrial form factor based on the PC architecture (PC104 stack, single board computers, Compact PCI racks). • Then replacement of the distribution by home made reduced embedded Linux. • As long-term real time OS users, Linux was not able to offer us the traditional performances of legacy solutions in term of hard real time, so use of real time extension coupled to Linux. • Then finally use of Linux on other architectures that are used in industrial projects, such as PowerPC (VME boards and racks) and Arm (mobile or low cost devices).

With such a step-by-step approach, we have succeeded in the adoption of Linux 1 for the whole spectrum of requirements and hardware architectures of the projects we develop. This adoption has been done progressively during 4 years, and today Linux represents merely 70% of our software development business.

In the next paragraphs, we will emphasize 3 aspects of Linux used for industrial projects :

• Using Linux for an embedded device • Using Linux in real time context

• Porting an application from legacy Real Time OS towards Linux.

Using Linux for an embedded device

2.1 Why does Linux fit to main design issues of an embedded device ?

When you start developing an embedded device, there are some basic characteristics that your software must comply with.

1 Alone or coupled with a real time extension

The first one is that your device will not necessarily be built with an Intel, AMD or whatever x86 derived processor. For many reasons (consumption, long term availability, cost etc…), many embedded devices are built with Arm, PowerPC processors, or even micro controllers.

So the software environment you use must be available on the processor you select, and if possible be usable on the maximum of processor architectures, so that the coupling between your application and your hardware is as limited as possible. If you think on long term, using a software environment that allows you to swap from one processor to another without changing the basic software is a good idea, because it allows you to easily follow the innovations on hardware without great impact on your software.

Linux is particularly adapted to this criterion, as it is available for a very important set of processor architectures, including those that are generally used in embedded devices.

The non exhaustive list of processors and micro controllers used in embedded devices, for which Linux ports exist in kernel 2.6, is :

• X86 architecture (Intel, AMD, Via etc…)

• Freescale 68K and PowerPC

• ARM (many sources)

• H8/300, SuperH

• AVR32

• v850

• Xtensa

• Blackfin

The 2.6.23 kernel offers about 24 distinct architectures 2 , and this number is increasing from version to version. The philosophy of the sources organization suits well with a broad support of processors. The sources content all the currently supported architectures in parallel, and it is at configuration and compilation time that the developer selects which processor he wants. With such a strategy, all drivers and features not related to a precise architecture of processor are shared among all, so the kernel improvements are available whatever processor you use. The adoption of a new architecture is limited to the files directly depending on the architecture. Even if these files are strategic ones, they represent a small percentage of the total kernel sources.

2 Some with little variants Another important point when you select an OS for an embedded device is that the hardware requirements of this OS regarding resources (memory and mass storage) must remain reasonable, much more tiny than those of a PC that currently offers hundreds of gigabytes of disk, and at least hundreds of megabytes of memory. On the embedded market, the size of memory and storage are generally in the range of few megabytes for both. And as embedded devices are sometimes built in very big volumes, each megabyte saved can save big amount of money, due to the number. Everyone who as already installed a Linux distribution can be sceptic, as Linux distributions generally install gigabytes of software components that require well-dimensioned memories. In fact, when you work with Linux for embedded device, you must not think to reuse a distribution (who is in any case available only for x86). The good method is to rebuild your Linux file system from scratch, just putting in your device what you really need for its dedicated functions. With such a strategy, you limit the number of processes that will run on the device, and in consequence the amount of memory that is necessary. You also limit the number of files in the Linux file system 3 , and so the size of the mass storage. A good idea is also to tailor the kernel itself to the precise characteristics of the hardware platform, so that you optimise the kernel requirements in term of memory, and the impact of the kernel and its components on the mass storage. By following these basic rules, it is possible to target sizes like typically 4 MB of mass storages, and 8 MB of memory, which is acceptable for many devices.

Regarding mass storage, embedded devices generally use Flash instead of rotating hard disks. There are two kinds of Flash disk :

• some that offer an IDE interface (CompactFlash, DiskOnModule), and so emulate an IDE hard disk. The normal IDE drivers of the kernel support them. Concerning the first one, the developer must tune the bootloader and eventually the BIOS to reduce their duration.

Concerning Linux itself, with a dedicated embedded distribution, start up duration targets from seconds to few tens of seconds are quite accessible (depending on processor speed, and quantity of basic services started).

In order to deal with switch off without proper shutdown, the Linux kernel offers file systems with journaling capabilities to reduce the risk of file system corruption. This solution is totally usable on a PC as it dramatically reduces the risk of problems, but it is not sufficient on an embedded device that must start in any case, without human intervention.

The solution is to work with a file system in RAM disk, so that even if the file system is corrupted during the switch off, the next boot regenerates it : the RAM disk is copied from mass storage to RAM at each start, and it is only the copy that can be altered at switch off.

In conclusion, Linux is able to answer to the main issues we need to deal with in embedded context, either basically or by an adequate strategy of use.

Ethernet redundancy solution based on Linux

We have used Linux to build the embedded software of a device that was designed to offer redundancy on Ethernet networks. The purpose of the device is to transparently duplicate Ethernet flux between distinct computers, without having to rewrite the existing software applications. So the devices are connected between the computers and the switches, and they duplicate Ethernet frames on the two redundant networks, and then filter the frames received twice.

They act at the Ethernet level of the TCP/IP stack, and they are completely ignored by the computers on the network, and by their software applications.

The customer requirements about the solutions were:

• Complete access to the source code of all the software components • Possibility to use distinct hardware architectures and form factors for the device • Use a software with performant and reliable TCP/IP stacks • Quick availability after power on

We have proposed Linux because all the software components are delivered under the GPL license, so it guarantees the accessibility to the OS sources. As the application was also developed as Open Source, the first requirement was met. The device possible first configurations used a X86 CPU in Compact PCI rack, and a PowerPC CPU in VME rack. Ethernet ports (3 ports needed per device) were located on the CPU itself, plus an additional multiport board with the same format than the rack. As Linux is available for both architectures and has a huge set of Ethernet drivers, it was also a great candidate for this requirement. It is well known that Linux TCP/IP stacks are very good, as Linux is the base of the majority of the servers of the Web. The quick availability after power on was reached thanks to the development of a very tiny embedded distribution, with just the loading of the Ethernet chips drivers, and the start of the Ethernet frames treatment application. So Linux succeed to build such a dedicated embedded application that acts like a firmware in the device, and allows very versatile configuration without application rewriting, the only change is to select the good Ethernet driver when we go from a configuration towards the over (and of course recompile the sources with the corresponding tool chain if the architecture changes).

Using Linux in real time context

What kind of real time for your project ?

For a company like us that has been for years working with many Real Time Operating Systems (RTOS), the use of Linux based solutions could not lead us to loose the level of determinism we need in our projects.

When we look back at projects built around legacy RTOS, some are just embedded development without real time characteristics, but some really need to rely on a hard real time environment.

When working with RTOS, as they are both designed for embedded and real time purposes, there was no question regarding the level of determinism that the project needed, in any case the RTOS could sustain any requirement.

With Linux, the developer must answer to the following question during the design phase : "Is the process simply an embedded device, or does it need soft real time performance, or hard real time performance ?".

Depending on the answer to such a question, the strategy to use Linux will be different.

For just embedded needs, Linux will be useable with the strategy explained in § 2.

If the requirements are soft real time, Linux can be used, but the developer will have to adopt an adapted strategy to get soft real time performances.

And if finally the process implies hard real time characteristics, Linux won't be the solution, but the couple Linux + real time extension will be.

The following paragraph will detail the positioning of Linux in term of real time capabilities.

A tour of real time solutions with Linux

Linux, like Windows, is a general purpose Operating System.

Its main mission is to manage a lot of concurrent processes on a machine (desktop or server), with a global time-sharing among all. The scheduler's basic strategy is not to advantage a precise process, but make all processes run on a sufficient large time scale, so that all are going head on a fair basis.

It is nevertheless possible to place selected processes in another class, called "real time" scheduling class. When attributed to this type of scheduling, the processes are placed above all standard processes in the scheduler's strategy to allocate the processor(s).

All processes with that class are ordered through increasing priorities. The process with the top priority always preempts processes with lowest priority. If many processes compete at the same level of priority, processes are managed according two policies :

• SCHED_FIFO : no reallocation until explicit release by the running process • SCHED_RR (Round Robbin) : time sharing among processes in the same priority level.

This kind of scheduling is similar to the scheduling principles of RTOS, so Linux can reach in term of scheduling the same functionality than RTOS, if the developer uses the right scheduling class. It does not mean at all that Linux is a RTOS, because the important factor is the time to take into account an interrupt, and to react to it at applicative level, in a well-known and limited duration.

Due to the internal nature of the kernel, it is not possible to guarantee in any case this duration, unless setting this limit to very high values, of course.

Until the arrival of kernel 2.6, the kernel code was not preemptible, so that means that when kernel code is currently executing, if an interrupt occurs, the interested process can not react to it until the end of the kernel code. As kernel code execution (drivers, system call etc…) before releasing the processor is not bounded throughout the kernel, there can be no guarantee in term of reaction latency.

In version 2.6 of the kernel, there is a possibility to make the kernel preemptible, through its configuration before compilation.

When this configuration option is selected, the kernel code can be pre-empted. This leads to best reaction latencies than with a not preemptible kernel.

Nevertheless, large portion of the kernel code are executed with interrupts masked, and there are not preemptible sections due to re-entrance problems, so even with preemptible kernel, one cannot guarantee bounded reaction latency.

That's the reason why a preemptible kernel coupled with SCHED_FIFO or SCHED_RR scheduling class can answer to soft real time needs only. In such a configuration, the average latency can be good, but potentially not the worst case. So the true hard real time performance remains impossible to Linux.

To deal with hard real time, the only solution is to work with a real time extension that is coupled to Linux.

The main real time extensions for Linux are : They are implemented as a set of kernel modules, and so rely on Linux for their startup. Once the extension is loaded, it takes precedence on Linux by distinct technical means (virtualization of interruptions in RTLinux and initial RTAI, ordered pipeline of interruptions with the new RTAI and Xenomai). The extension implements a fully deterministic RTOS. When there is no activity in the RTOS, the extension gives the processor to Linux world (Linux is the idle task of the RTOS). The extension offers an API to make IPC among tasks in the real time part, but also IPC between tasks in the RTOS and processes in Linux. When using such solutions, the developer has to split its application in 2 parts :

• The part that must be real time, which is implemented in the RTOS • The part that has no real time constraints, that is implement has legacy Linux process. For instance, in a data acquisition chain, the reception of the data and their time stamping would be done in the RTOS, with real time performances, and a graphical representation or a send to a storage server over a network would be done in Linux. The exchanges between the two parts would be done through exchange FIFOS. With such a design approach, the developer "put the right thing in the right place", but this leads to a more complicated design. It is necessary to assure that Linux will have the processor enough to avoid saturating the intermediate buffers through which the real time part sends data to Linux. So there is a trade off between the load of the global system, and the buffers size. Linux drivers are not available in the extension, so Inputs/Outputs done in the real time part necessitate a Real Time driver.

There are greatly fewer drivers directly available for the extensions than for Linux, but there is a framework to develop Real Time drivers (RTDM). Drivers are generally not built from scratch, but adapted to the extension from their Linux version. The real time part of the application can be built through 2 types :

• As kernel modules directly running in the RTOS, for the maximum of performance, but less comfort (no memory protection, debug less easy) • Or packaged as special Linux processes, that are not scheduled by Linux but by the RTOS. This allows protection by the MMU, and facilitates the debug process.

An example : numerical data recorder for automotive

One of our customers had to develop a new generation of data recorders to store the flux of information exchanged on numerical buses on modern vehicles.

The hardware platform was a PC104 stack with an Intel CPU, a CAN board and another board with DSP, who acts as a specialized co processor for the main CPU.

The requirements for the software were :

• Ability to precisely time stamp the data received on the CAN buses. • High bandwidth towards a hard disk used for storage. • Full determinism for the exchanges between the main CPU and the DSP coprocessor. To fulfil these requirements, it was decided to use a Linux based solution, coupled with RTAI to ensure complete determinism of the software. We have selected a 2.4 kernel. The project was made after arrival of 2.6 kernel, but for industrial applications, we generally adopt a very conservative approach. We generally start using a major kernel version only a quite long time after its release, so that a maximum of potential problems have been already solved. Another reason to choose kernel 2.4 is that Linux drivers for CAN and DSP boards were available for 2.4, and not for 2.6. Our job was to set up the basic software environment (Linux + RTAI base), and to deliver a skeleton of the final application. Due to the fact that CAN and DSP were managed by the real time part of the application, it was necessary to port the drivers. As there was a single task that would drive a board, we have not used RTDM model, but the existing Linux driver code was adapted and used as a hardware management library linked with the task. As the task was a kernel module, there was no trouble to access the hardware. The main job for this port was to remove things related to device nodes, and replace Linux kernel functions by their equivalent for RTAI. After installing and validating the Linux kernel, the RTAI extension and the ported drivers, we have built the skeleton of the application. The idea was to let the customer deal with the details of the application and to concentrate ourselves on what was related to RTAI :

• Global design between Linux processes and RTAI tasks • Implementation of IPC and synchronizations between these processes and tasks • Access to the CAN board and exchanges with the DSP This job was made thanks to the global requirements written by the customer. We finally delivered the platform with Linux and RTAI installed, and the skeleton developed. The customer finalized the development by himself : he added the final code round the templates of functions of the skeleton. Such a development approach allowed using Linux plus real time extension in the new device, with a good share were each company acts where she has the maximum added value.

Porting an application from legacy RTOS to Linux

In the industrial world, there are a lot of architectures built around 68K boards with VME interface towards Inputs/Outputs, and legacy RTOS. Due to the increase in computing needs, it is sometime necessary to replace this generation of boards by new ones, much more powerful. But in the history of RTOS, there have been great changes on the market. Some have disappeared, some still exist but their relative part has greatly decreased, so the drivers or BSP for these OS are not available for new hardware. When a complete software application exists and has been validated, and it is necessary to change the hardware, this can trigger the need to port this application towards the new Operating System. The idea to minimize the impact, and in consequence the costs, of such evolution is to try to preserve as much as possible the sources of the existing application, and to manage the port at the system level.

By remapping system calls of the old OS to the new one, and developing an emulation library when strict remapping is not possible, the application sources are very few impacted. In consequence, the validation phase is much more light than if the application was rewritten for the new environment, and the regression risk is minimized. This approach is possible only if the developer has good knowledge of the two OS : the old and the new one.

We have managed this kind of project for a port of a SNMP stack from OS9 towards Linux.

The initial stack was running on a 68K CPU, and the new hardware was a PowerQuick (PowerPC family). OS9 was not available for this new CPU, so it was quickly decided to use Linux.

The SNMP stack was just a part of the application, but the port was a mock up to evaluate both the feasibility and cost of the same port for the entire application.

As mentioned earlier in this article, the initial version used OS9 not for real time purposes, but just as an embedded OS on 68K boards, so there were no time constraints that could justify the need of a real time extension.

The initial sources of the application were written in Ansi C, a few years ago.

So the first problem we had to face was not directly due to Linux, but to the difference between the OS9 tool chain and the current Gnu tool chain : as modern compilers make much more controls than old ones, some syntax errors were detected when compiling for Linux, when there was no trouble when compiling for OS9. These difficulties must be taken into account when planning a port, even if they are not directly related to Linux, because they can necessitate hours of sources cleanup, if the old compiler was too tolerant.

With the Gnu tool chain, you can decrease the level of controls the compiler makes to avoid correcting the sources, but is it really a good solution ? The best thing is to rely on the compiler's check to get the cleanest sources, in order to avoid future problems.

That is what we have done regarding this point, even if this generated additional work. We faced to another difficulty also related to compilers. As some data structures were not correctly aligned in the initial sources, the old and new compilers did not manage these structures the same way. So there were some troubles when dealing with offsets of members of these structures, or computing their length. Like sources syntax, this point is not directly due to Linux, but it was important because such problems involved bad functionalities of the ported software, and were difficult to identify. An important difference between Linux and some RTOS is that RTOS may have a flat memory model, without any boundaries between global variables spared into different executables. With Linux, every executable has its own memory space, under the control of the MMU, and global variables of one executable are not seen by the others, except if the developer used dedicated shared memory API. Under OS9, it is possible to use flat memory model, or a segmented one with MMU. This is the developer's choice.

Unfortunately for the port we faced to, the initial developers used the flat memory model, with shared variables between the distinct executables of the SNMP stack.

An additional difficulty was that the shared global structures had members that were pointers on members on other data, so these pointers were shared between distinct executables.

With a flat memory model, there was no trouble, but with Linux, the pointer that had sense in the executable where the variable pointed to was located, had no sense for other executables.

To solve this, we had 3 solutions :

• Replacing the OS9 architecture with many executables, by a single multi threaded Linux process (convert OS9 executables to Linux threads). In this case, as all threads shared the same addressing space, the shared pointers would be correct in each thread. • Use the shared memory API to share all needed structures, and replace all pointers by offsets regarding the base of the related shared data, to avoid pointers that have no sense. • Use the shared memory API to share all needed structures, and try to map all data to the same address for each process, because the API allows to make a hint for the mapped address. The best possible solutions would have been to use a single multithreaded process, but we did not identify the use of pointers in shared structures early enough. So we started the port with a multi process architecture, and use of shared memory API. When during the test phase the pointers problem appeared, we preferred to map all the shared data to the same address for each process, to avoid to swap from multi processes to multi threads. Converting pointers to offset would have generated too much source rewriting, and after analysing the memory mapping of all processes, there were identical addresses ranges free for all. A hint on these addresses for all shared data were successful for each process, so with this technique, the original data shares were OK even on the Linux port.

The only penalty of this technique was that in case of software evolution, it would be necessary to check that the used address zone still remained available for each process. The last OS9 features that were not so easy to port were signals and alarms. In a multi process OS9 environment, developers often use a lot of signals to synchronize processes or trigger functionalities. OS9 signals are very reach, with a lot of values available for users. Linux signals are poorer, and they are not really intended to be the base of IPC between processes. To minimize the changes on the sources, we have developed some emulation of the OS9 signal API, based on the Linux SIGUSR1 signal, with associated data containing the value of the OS9 signal (OS9 users signal multiplexed to a single underlying Linux signal). As the original OS9 sources used a huge quantity of alarms running in parallel, we also needed to emulate the alarm API through the launch of alarm threads, one thread per alarm duration. Concerning other system aspects, it was quite easier to port them, mainly by simple remapping through an include file that was included by all sources. This file was redefining the OS9 system call in the equivalent one for Linux. For a few system calls, it was necessary to treat them in a simple compatibility library, mainly due to differences in the parameters between the two OS, that prevent simple remapping through the compatibility include file. In conclusion, for the majority of the system calls encountered, it was not so difficult to port them at system level, thanks to a good knowledge of both OS9 and Linux. Signals and alarms were a little bit challenging, due to the fact that they are very common tools in OS9, and very often used in the original sources, but less central in Linux, and so less easy to use in the Linux version. Memory model and compilers differences were the most difficult aspects to face to. Starting with a flat memory model is a point to check when porting to Linux, because of the consequences on data sharing. The difference between compilers, mainly if the original one is quite old, can lead to a lot of unforeseen job, because it can impact all the sources set, and potentially generate hours and hours of corrections. After treating these difficulties, the port was finally achieved and successful. The test campaigns demonstrated that the ported software features and performances were identical to the initial one. So this mock up reached its main goals : demonstrate the feasibility of a port of the whole application, help estimate the global cost, and point the main difficulties of such a job.

Evolutions management

In the industrial world, when an application has been successfully validated, there is generally no reason to change anything, unless bugs appear. In the opposite, Linux and open source software are constantly evolving, because project teams deliver new releases at high rates when projects are active. For instance, minor versions of Linux 2.6 kernel are released about every 2 or 3 months. That is clear that a company cannot afford to maintain the OS base of its product in phase with such a rhythm of new deliveries. So is the evolving world of open source software a bad thing regarding the adoption of Linux in industrial projects ? In fact not really, because you perfectly can "freeze" the situation to that particular version used to develop and validate the application or product. In our company, we do consider that both Linux kernel sources, basic GPL software used and the application itself we have developed are the distinct components of the project, and we manage them collectively as a whole, so that we are able to always restart with the same basic environment. And if we discover some problems in the OS or in basic GPL software used, we have more liberty than in RTOS world. With legacy RTOS, there are indeed less new releases. But when you face a bug or a problem with the current release of the RTOS, there is generally no solution but upgrading it to the new one that will correct it, as editors don't want to correct old releases. With open source software, you have much more solutions to choose from : • As with RTOS, the first one is to adopt the latest release, if it corrects the problem you face to. • The second one is to locate in changelogs, or by comparing sources, the precise corrections corresponding to your problem, and to selectively backport them into the version you used when developing. Even if it is not always easy, it can be a way to avoid revalidation process due to OS release change. • And finally, if the problem is still not corrected in the latest version, you can try to correct it by yourself, and then recontribute it to the project team.

Conclusions

In this article, we have browsed distinct aspects of using Linux in the kind of projects that our company is developing, with embedded, real time characteristics. Today, we can say that according to our point of view Linux is perfectly usable as a base for these kind of projects.

Figure 1 :

 1 Figure 1: The function of the device

  Pro). WindRiver has recently bought RTLinux to introduce it in is offer as RTCore, beside Linux and VxWorks offer. • RTAI was derived from the former RTLinux. The Dipartimento di Ingegneria Aerospaziale, Politecnico di Milano, develops it. It is and remains a GPL solution. • Xenomai has started in the RTAI environment has a new branch, and is now completely autonomous. It is the newest of the 3 extensions, and seems promising. It offers a neutral nucleus with skins API for many RTOS (VRTX, VxWorks, µITRON, RTAI), and a neutral one. It also offers a smooth migration path from Linux to real time and vice versa. All these extensions use the main rough principles.

	(RTLinux/
	• RTLinux was the first one, designed by the
	University of New Mexico. After a first phase
	where the product was GPL, it divided in 2
	products driven by a company, FSMLabs. The
	basic version of RTLinux was available under a
	free license (RTLinux/Free), and the performant
	one	became	a	commercial	product

  Linux comes with a lot of high quality software development tools, like versioning tools (CVS, SVN …), compilers (GNU chains), documentation tools (doxygen) etc…. Using open source software is interesting due to full access to the sources, absence of royalties for deploying products, or free availability of a lot of developing tools. Nevertheless, new adopters must have in mind that if buying costs are quite absent, it is necessary to invest in developers knowledge because of the adoption of a new technology, but also because using free software changes the way of working : you need to interact with a community of developers, instead of a supplier's maintenance team, for support, bugs correction etc… The interesting point is that you convert money that you used to buy software to reinvest it in your team's human skills, and we do think that it is a quite good investment !

		6. References
	[1]	01 Informatique, n° 1897, March 23	rd 07.
	[2]	www. linuxdevices.com/articles/
		AT7065740528.html
		7. Glossary
	API:	Application Programming Interface
	BSP:	Board Support Package
	GPL:	GNU Public License
	MMU:	Memory Management Unit
	RTOS : Real Time Operating System

.3 With Linux, there is not only the kernel image, but also a root file system that is filled with a Unix like directories structure 4 This point must nevertheless be checked before the flash choice.