Pascal Lejeune
email: pascal.lejeune@siemens.com

Françoise Dufour

Eric Chenu

Session 5A: Hardware & Software Architectures DIGISAFE® XME: High Availability Vital Computer

INTRODUCTION

During the 1980s, progress achieved in automation systems led us to computerize functions that had hitherto used hard wired or relay logic. This especially included system safety related functions which previously used hardware based systems. The safety of these functions was based on a "failsafe" principle: any failure placed the equipment in a non dangerous state. This property is unfortunately no longer guaranteed with computer based systems: an anomaly in a compiler, a failure in a computer memory can all lead to a dangerous situation that must be detected and inhibited. This article presents a computer that meets these safety goals: the DIGISAFE® XME computer. This system represents the third generation of this technology in 15 years.

The safety principles that apply to the DIGISAFE® XME vital computer is based on coding information. Compared with other designs based on computer redundancy (requiring complex reliability studies), this principle offers the advantage of reducing the amount of hardware used and simplifying the safety demonstration which is grounded in solid mathematical bases and is independent of the computer used.

A vital functions application is a cyclic one. A processing integrity check is run at the end of every cycle, when refreshing the vital function's logical outputs. This check is performed safely by specific vital part equipment. If the coding is not compliant, the logical outputs are forced to a restricted state (a state that is not dangerous for the system).

In the latest version of this system, the design has been improved in order to send all vital checks to a dedicated digital system board, making it possible to use a standard computer for the nonvital parts of the processing work.

From a single source program, the way an application runs on the DIGISAFE® XME is automatically split into two parallel executions: data processing performed by the standard computer board and control codes processed by a coprocessor (located on the dedicated digital board), bringing the benefit of heterogeneous hardware redundancy while retaining coding advantages.

The coding technology used guarantees that there is no common mode shared by both processes, protecting from both errors in the compilation sequence as well as hardware failures.

To improve availability, the DIGISAFE® XME computer can be installed in a redundant layout and comprises a hot redundancy (software) protocol ensuring that the redundant system remains safe [START_REF] Essamé | PADRE: a protocol for asymmetric duplex redundancy[END_REF]. This article presents the general principles used in vital systems and the computer's hardware and software architecture. It describes how to ensure the safety of vital application processing and of vital inputs/outputs (On/Off and messages) and presents related hardware implementations.

Source code

Run non-vital processing

Run vital processing

Safety check (dynamic controller)

Output supply

ARCHITECTURE 2.1. Principle

Ensuring the dependability of DIGISAFE® XME computer processing is based on a probabilistic approach to safety. The high level of safety is obtained by combining: arithmetic coding, signature checks and hardware checking measures. Every data item (called a non-vital value hereinafter) is protected by coded redundancy (called code hereinafter) which integrates arithmetic data coding, a data identification signature and a dynamic signature ensuring validity in time (called date hereinafter).

This safety approach guarantees the execution of the vital system software, the exchange of inter-equipment messages, binary On/Off I/O and the acquisition of specific sensor data (speed measurements, beacons,…). It does not guarantee the validity of the application source code. This needs to be done by an analysis of this source code by an independent team who may possibly be assisted by the use of formal proving tools (B language). This approach is presented in [START_REF] Behm | Météor: a successful Application of B in a Large Project[END_REF].

The inter-equipment messages are protected by the same code as the internal data, except for the dynamic signature which is replaced by a protocol which handles the management of asynchronism aspects between equipment. This coding makes it possible to ensure the validity of messages received and retain independence from the transmission media.

The vital On/Off inputs are provided by specific failsafe electronic boards which guarantee that the code corresponding to an input is permissive only if the input really is. A restrictive input state leads to restrictive application behavior (for example: door closed is false, so the vehicle is not allowed to run). A permissive input state may lead to a permissive action by the application (for example: door closed is true, so the vehicle may run).

The On/Off outputs generated by the application are checked for safety by specific electronic boards designed for vital operation. If the coding of one of the outputs is incorrect or if an output that should be restrictive is set to a permissive state, then all of the outputs are forced to the restrictive state. Remark: an output's restrictive state corresponds to a state that can never be contrary to safety requirements (for example: train running permission is false). A permissive output state may be dangerous to the system and is only generated where there is no risk involved (for example: permission to run is true).

Positioning is determined by associating spot beacons and a mechanism for measuring travel and speed. A beacon is a transponder which returns its identity in the form of coded data when an interrogation antenna passes over it. Travel is measured by counting the number of teeth on a wheel mounted on the vehicle axle or by an optical speed measurement sensor (OSMES), by correlating images from the rail, an extremely precise and accurate approach. With the exception of OSMES [START_REF] Alves | A speckle correlation speed sensor: Special addition of the Instrumentation, measurement and metrology magazine: Sensors and signal processing in guided transportation systems -Hermes science publication[END_REF], a standalone sensor that uses the inter-equipment protocol, the digital processing performed for other sensors dates and codes the data, as far upstream as possible, in a format that is directly usable by the computer.

An overall signature for vital processing is periodically checked by an independent device: the dynamic controller. Should an error occur, this circuit places the computer in a safe state: all On/Off outputs set to the restrictive state and their power supply cut.

Hardware Architecture

The XME computer uses a single processor open architecture based on a cPCI bus. The non-vital part comprises standard "off the shelf" boards covering the CPU, network (Ethernet,…), non-vital I/O, serial link and power supply functions along with all of the other standard functions available on the market. There are no safety constraints affecting this standard part of the computer.

In the current version, the processor used is a 500 MHz Pentium III. Without any need for further development, the CPU clock frequency can be increased and if the software is ported, other processors could be used (PowerPC, MIPS,...). Using a standard Pentium processor board makes it possible to benefit from a PC environment with its VGA interfaces, keyboard, Ethernet, Com1 serial port, floppy disk drive as well as a flash disk type hard disk.

In addition to those available from the standard CPU, serial links are provided by VHDL modules and can support UART and HDLC communications. It is possible to use seven full duplex links.

Ensuring vital computer operation is achieved by adding a specific digital board (called CTN_P). This board handles the following functions.

• Digital processing that is coded to ensure safe software processing are performed by a math coprocessor mounted on an extension board. This circuit calculates the execution signature for vital software execution.

• Managing the DIGISAFE® XME network of vital On/Off I/O that enables the transfer, dating and coding of vital On/Off I/O. The DIGISAFE® XME network is a synchronous ring network.

•

The dynamic controller function that cyclically checks the code produced by the vital software as well as the DIGISAFE® XME output codes. It provides the commands for the vital power supply used for the DIGISAFE® XME outputs. If an operating failure occurs, the dynamic controller cannot provide the right commands to the vital power supply which will drop out and place the system in a safe state (On/Off outputs in a restrictive condition).

• A safe clock time base that performs a drift check comparing two independent crystal oscillators. Any drift that exceeds the tolerated level will cause the vital power supply to drop out. This time base provides the synchronization signals for the software and hardware applications, a check on DIGISAFE® XME I/O dates and on the software via the dynamic controller, guarantees that the computer is correctly aligned with its time base.

• An interface with the positioning boards for the on-board version.

These safety functions are performed in VHDL and represent the complexity of 2.4 million FPGA gates (the FPGAs used are ALTERA 10K and 20K).

Specific boards can be added, depending on requirements, for vital I/O. Another one can be used for analog processing and the electrical interface of positioning devices. The vital power supply board provides the power required by the output boards.

Software Architecture

The software is written in C and Ada languages and is run in a multitask real-time environment. There is one cyclically awakened vital task and a number of non vital tasks that awaken cyclically or triggered by an event (serial links,…) for application and immediate services purposes. The frequency of cyclic activation of the vital task and DIGISAFE® XME network tasks is determined by interrupts generated by the dynamic controller. A specific interrupt makes it possible to maintain a cyclic non-vital task, synchronized with the vital task cycle. The data transfers between the tasks use a mailbox mechanism.

The vital task sequencing is as follows. At the start of the cycle, the vital application software processes the inputs provided by the DIGISAFE® XME vital I/O network's immediate services, the inter-computer messages, if any, and the positioning data. This information is processed to calculate the appropriate system response, then the vital task generates the vital outputs which are sent over the DIGISAFE® XME vital I/O network at the end of the cycle and prepares the inter-computer messages to be sent. This cyclic operation is repeated ad-infinitum.

Keyboard

Standard computer

Figure 2 DIGISAFE® XME computer dynamic architecture

The data along with the vital I/O are coded and dated with a date that is incremented by each iteration of the vital cycle. This makes it possible to identify data from successive cycles.

At the end of each cycle, the dynamic controller checks the static and dynamic signatures that result from running the vital software.

The validity of the vital inputs, the positioning data and the inter-computer messages is indirectly checked by them being accepted at the start of the cycle by the vital software.

The vital outputs are cyclically checked at a higher frequency. This check is handled by the hardware (dynamic controller), as the software's role is to provide, at the slower application cycle rate, a checksum that reflects the controlled output states.

A Modular and Configurable Architecture

The DIGISAFE® XME advanced vital computer is modular and configurable.

•

Processing is secured by a generic coprocessor board called MSCA.

• On/Off I/O are managed by the DIGISAFE® XME vital I/O network and by boards that are configurable according to cycle time and the number of I/O.

•

Positioning inputs are acquired by a dedicated board. Two positioning configurations are available: DIGISAFE® XME beacons plus phonic wheel or DIGISAFE® XME beacons plus optical speed measurement (OSMES).

Vital digital functions are clearly separated from operating ones and confined to just one board whose configuration can be downloaded by the processor. The content of the FPGAs is programmed on power up by the CPU board, making it possible to configure the computer's digital hardware functions simply by updating the software.

There is no safety constraint affecting the software except for the vital application source code. All of the software drivers are non-vital ones.

The software layers use standard programming languages (Ada, C) and a standard RTOS (currently VxWorks) so that they are portable.

The same applies for digital hardware functions that are entirely described in VHDL.

These modularity and configurability properties make it possible to produce optimized computers ensuring vital safety limited to certain functions only, for example:

• The vital processing unit that only secures software processing and inter-equipment messages. It is implemented simply by placing a PMC extension board onto a standard computer. The complete assembly operates transparently, as seen by the application tasks and the DIGISAFE® XME drivers, just like a computer that integrates the two functions. Nevertheless, the ability to manage a configurable number of I/O modules must be added to the concentrator computer.

To guarantee proper operation of the complete assembly, the I/O modules are synchronized by the network concentrator via synchronization messages sent over the Ethernet network.

VITAL PROCESSING

Data Coding

Protection against errors likely to corrupt data during exchanges and processing is based on the association of a separable arithmetic code and a signature check. This coding makes it possible to detect:

• Operand and operation errors, and more generally any instruction sequencing errors. Actual sequencing is compared with preset, expected, sequencing. This pre-determinability aspect is fundamental to the approach to securing processing because it is at the heart of the mechanism used for validating processing system operation.

• Calculation errors. The principle used for securing processing does not of course allow pre-determining calculation results, but coding is used so as to make validation impossible should an error occur.

This approach makes it possible to achieve an overall level of safety for the system, that is not dependant on either the complexity, nor the technology of the hardware used (processor and transmission media) but which is however dependant on the size of the data redundancy.

All vital data therefore comprises two fields:

• an information field, which forms the useful part of the data.

• a control field made up of the arithmetic sum of three terms:

-the remainder of the integer division of the information field by the code key. If A is the code key (a large prime number chosen randomly), x the useful data and k an arbitrary number such as 2 k > A, then the remainder r kx of the division of 2 k x by A is used. This coding forms the fundamental error detection mechanism for securing processing.

-a static signature B x which characterizes the data identity. For all coded operators (both arithmetic and logic operators, conditional branching...), the static signature of the result depends on that of the operands and the operator itself. This can be predetermined as it is not dependent on the values taken by the data and it forms a trace of their antecedents.

-a dynamic signature D, common to all data, which guarantees the validity of the information in time. This signature is incremented by a constant value on every application cycle as well as on each iteration in the internal loops.

The data item is therefore finally coded in the form X = 2 k x -r kx +B x +D as shown by the (x, -r kx +B x +D) pair, where x represents the information field (non vital value) and -r kx +B x +D the control field.

In the remainder of this article, we will use the notation X F for the information field and X C for the control field of secure data X. A data item X is said to be in-code if its control field X C is correct and its static signature takes the expected value. It is said to be out-code if not.

Thanks to this coding, we show that the probability of failing to detect errors is lower than 1/A regardless of its origins: hardware failures or compiler/linker errors. In other words, the technology used to implement processing does not affect the safety demonstration.

Securing Operations

The following basic principle applies. Every coded operation has a corresponding signature evolution law that is specific to it. The control field for the result of a coded operation is securely calculated from the input operand control fields. In both of the above error cases, the result signature is incorrect.

Execution errors are detected by a coded data item that is internal to the coded operations. This data item is called a "tracer" and its notation is S. The tracer is dependent on all of the operations performed since the application was initialized. It does not have an information field, but it also has a signature that can be pre-determined. It evolves so that there cannot be any error compensation in case of multiple malfunctions. The output control fields (On/Off and messages) must be tracer dependent.

After every coded operation, the tracer evolves in line with the formula:

S n+1 = α (Z C + r k (Z F ) -D + S n ) ≡ α (B z + S n )
α is a constant. The implementation guarantees that it is impossible to store tracer values, so the tracer is not dated.

Branching

In line with the way coding is used, as defined previously, when a conditional branching function is used, care must be taken to ensure that the branch followed is the right one, and if not, cause a tracer "out-code condition" (a signature different from the expected signature).

Furthermore, the tracer signatures and the updated variables change differently, depending on which branch is followed (as the operations are branch dependent). And to ensure pre-determination of signatures after branching, these signatures need to be independent of the branch followed.

To guarantee these two points, the following processing is performed.

Test operations send back a non-vital Boolean value that will allow branching and change the tracer differently in the two branches so that correct branch execution can be checked. More precisely, tracer comes to include the control field for test marker X (which is "-r k (true) + B x + D" in the then branch, and "-r k (false) + B x + D" in the else branch): S n+1 = α ( X C -D + S n ).

At convergence (where branching ends), the tracer is added to the variables that are modified during divergence so that the signatures are dependent on the test marker. All of these variables, as well as the tracer, are compensated (by adding a constant) so that they can be brought back to a pre-determinable value regardless of which branch is followed. Should a branching error occur, the tracer before convergence is out-code by α n .(r k (true)-r k (false)).

At the end of convergence, a tracer compensation error can never bring back an out-code tracer back to in-code.

Constants for compensating the tracer and the variables modified during divergence are called compensations. They are pre-calculated by a host tool, the Signature Pre-determination Tool (OPS). They are stored in tables, the compensation tables.

Loops

For repetitive structures (loops), care must be taken to ensure that the number of iterations performed is correct. Furthermore, the tracer signatures and the variables updated in the loop must be independent of the number of iterations performed. The principle is similar to that of branching (marking by a test variable and compensation at the end of the iteration). At any given point in the loop, the signatures are the same regardless of the iteration. It is the date that makes it possible to guarantee the validity of data in time.

Result Check

The result check comprises checking that the static signatures for the On/Off outputs and the tracer are the same as the pre-determined values and that the dynamic signature (date) evolves correctly during each cycle.

The check is preceded by a compacting operation, to ensure that for each cycle only a final signature bearing the trace of all of the operations performed and any errors that may have occurred is checked.

The check must be performed as a vital function by the Dynamic Controller board. If the final signature is incorrect, the On/Off outputs are forced to a restrictive state without taking into account the results obtained.

Double System Principle

The secure processing principle makes it possible not only to protect against execution errors, but also against compiler/link editor errors that may impact software safety.

The compensation tables generated by the OPS are used during execution. If the program that is executed is different from the one analyzed by the OPS, the vital application is in the out-code condition. It is the OPS that defines all of the signatures, especially the one that should validate execution and which is checked by the Dynamic Controller board. Redundancy between the software generation system and the Signature Pre-determination Tool is built-in.

Coding Information is transparent to the Applications

The vital applications are coded in Ada language (with the option of extending to other languages).

Data coding is transparent to the vital applications. They use conventional operators such as +, -, and, ≥, … (using Ada overloading), table read/write services, divergence, convergence…. These are the coded operators that are tasked with handling the various processing functions on the data fields and on the coded part.

Hardware Implementation

The vital software is run by the standard processor board that sends, via the cPCI bus, a trace of its execution to the vital digital control board: instruction code, parameter addresses and calculation results. A calculation coprocessor then handles the related coded calculations in line with the algorithms described above.

This coded calculations coprocessor comprises a hundred pipeline layers. The way the algorithms are implemented has been optimized to eliminate looping back. This ensures that a basic instruction is executed every clock cycle without emptying the pipeline.

To reduce the size of the circuit, calculations on 48 bit code has been multiplexed into two 24 bit calculations.

Some complex operations (convergence, reading and writing array elements) require sequential processing which blocks the pipeline. An input FIFO is used to stack 128 instructions awaiting processing, so that the coprocessor never makes the processor wait and it can catch up thanks to its processing speed when performing basic operations.

Some calculations are performed without dating. Precautions are taken to avoid any dangerous storage of this information as well as unplanned date information removals. The conversion of logical inputs from sensors into coded values is handled by a failsafe type vital board. An input signal can only be sent as permissive (high logic state) if it is truly so for the entire acquisition duration. If not or if a failure occurs, it is provided as restrictive.

The control field obtained for n inputs is provided compacted by the formula: Redundancy = ( )

∑ = - + 1 - n 0 i i i i i ).Sfalse δ (1 .Strue δ +D
where δ i equals 1 if input i is true (permissive), and 0 if it is false (restrictive), Strue i and Sfalse i are the codes returned by the board for input i true and false. For logical outputs (example: permission to move), it is necessary to ensure that the processing routines have not produced false permissive outputs (by checking their control field and the tracer), that the restrictive outputs are indeed restrictive (checking output state read back) and that the dynamic signature evolves correctly at every iteration. It doesn't matter when an output was incorrectly generated as restrictive or when a permissive output is set to restrictive as these two cases are not dangerous ones.

After the logic outputs (On/Off) are generated by the vital application, their control fields and that of the tracer are compacted into a single dated sequence. The sequence obtained in this way is provided, for checking, to the Dynamic Controller.

The sequence obtained for n outputs is provided by the formula: Redundancy = ( )

∑ = - + 1 - n 0 i i i i i ).Sfalse δ (1 .Strue δ + S + D
where δ i equals 1 if output i is true, and 0 if it is false, Strue i and Sfalse i are the codes corresponding to output i at true and at false. The non-vital output values serve to control output actuators in a non vital way. It is therefore necessary to ensure that a restrictive command does indeed correspond to a restrictive action at actuator level and has not been incorrectly transformed into a permissive output (clearly not a safe situation). To do so, all of the outputs are read back. Just like for inputs, output read back data is returned in coded format by a failsafe device. This board guarantees that a read back code is restrictive (set to false) only if the output is truly set this way. If not, or if a failure occurs, this code is the default code (set to true). The codes returned by this board complement the codes supplied by the application: Strue i for a false output, and Sfalse i for a true output.

The sequence obtained for read back is: Read back = ( )

∑ = - + 1 - n 0 i i i i i ).Strue δ (1 .Sfalse δ + D
The Dynamic Controller adds the data read back to the sequence supplied by the vital application, then it compares the sequence obtained with the expected dated signature. If they are different, then all of the outputs are forced to the restrictive state (low logic state), irreversibly. Remark: as the output code and output code read back are complementary, their sum equals a constant that is independent of the output's value (Strue i + Sfalse i ). The expected signature is therefore truly a pre-determinable constant. The I/O are secured by failsafe circuits which guarantee the following behavior:

•

The input interface circuit allows the transfer of a binary sequence only if the input is supplied (supplied = true).

•

The output interface circuit lets a binary sequence pass only if no power is transferred from the vital power supply to the outputs.

These binary sequences are transformed into Strue and Sfalse control codes by the digital circuits on the vital Input/Output boards. They are transferred to the vital software and the dynamic controller via the DIGISAFE® XME network. The codes are compacted on transmission, avoiding any saturation of network bandwidth.

The input codes are checked by the vital software. The output codes (Redundancy and Read back), the vital software static and dynamic signatures (dated tracer) are cyclically checked by the dynamic controller.

Receiving correct data lets the dynamic controller supply, via the safe time base clock, coherent commands to the vital power supply which produces the necessary power for validating outputs. The slightest error causes this power supply to drop out and consequently the vital outputs become passive ones.

Inter-equipment Messages

The vital inter-equipment messages are sent in compacted form: only one control field, that is called redundancy, for the entire message.

The redundancy depends on the non-vital values of the message information as well as on the tracer ( the tracer includes all processing errors that may occur ).

This type of coding makes the choice of transmission media a transparent one. In reception mode, redundancy is only in the code if the processing that led to generating message data was performed without errors and only if transmission did not alter the message.

Given that the equipment is not synchronized, message redundancy cannot be dated. A vital logical time value is necessary to guarantee the freshness of the data exchanged. This time value is a coded value that changes with every vital application cycle. It is attached to the data in every message. The receiving application has to use a vital function to check the freshness of the logical time of each message.

All of the occurrences of a given message have the same signature (whether they are sent by the same sender at different clock cycles, or whether they are sent by different senders of the same type). As redundancy depends on the message data values, it guarantees integrity (it is impossible to mix the data from two occurrences of the message without damaging their signatures).

The vital functions do not protect against message loss. The applications are designed to be message loss tolerant. If this protection is necessary, it should be implemented at the application level (acknowledgement).

PERFORMANCE LEVELS AND CHARACTERISTICS

Performance Levels

The cycle duration of the applications developed to date are between 48 and 360 ms. This application cycle is split into message subcycles of 6 to 20 ms depending on the programming.

The table below shows the maximum delay, guaranteed by the vital system, after which the system will be placed in a restrictive state (dynamic controller drop out) following a failure: The XME architecture is now a mature one and will follow technological evolutions. The natural gain is estimated to be a factor 2 progression every 3 to 4 years. XME technology was developed in 2000. Now in 2003, the technologies are available to increase performance by a factor of two: Pentium 1.5 GHz, cPCI 32 bits/66 MHz and FPGA ALTERA Stratix.

Limits on Use

Independently of its performance and characteristics, the XME computer imposes some limitations in terms of its operation. The vital software especially uses a sub-set of Ada language close to that of certified computers. The main limitations are:

Characteristics

The DIGISAFE® XME computer meets the applicable standards for operating in a railway environment in mechanical, thermal and EMC terms.

• Mechanical: EN 61373: Railway Applications -Rolling stock equipment shock and vibration tests.

• Thermal: EN 50155: Railway applications electronic equipment used on rolling stock, EN 50125-1: Railway applications environmental conditions for equipment, Class T3 (-25°C to +85°C ambient).

AVAILABILITY: BUILT-IN REDUNDANCY

Introduction

To improve system availability, a redundant layout implementing two identical hardware and software, inherently safe, units is used. A failure affecting one of them should not affect the system's overall availability.

Ensuring the safety of the complete system poses a major problem: the two vital applications are inherently safe, but as they are independent, they may apply antagonistic commands affecting the environment (if their dynamic contexts are incoherent or diverge); the result can therefore be behavior that is on the whole anti-dependable.

A simple principle that will correct this problem is to ensure that the computers are perfectly identical at all times, ensuring especially that their data contexts are rigorously equal [START_REF] Essamé | PADRE: a protocol for asymmetric duplex redundancy[END_REF]. Implementing this principle is however difficult and takes up a lot of processing time and bandwidth on the inter-computer communications link. This is why DIGISAFE® XME's built-in redundancy protocol has been adapted to improve the performance achieved.

Processing

Of the two units, one is said to be active (sending messages) and the other passive. From a vital point of view, the guarantee is that at most one of the units is active. Each unit's vital function knows whether it is active or passive.

The two units are linked by a two-way link allowing message exchanges.

In redundant mode, the two units run the following protocol:

• Acquire their own local vital inputs (On/Off, phonic wheel, beacons…) and remote ones (messages); The local outputs from the two units are in a hardware OR configuration. Only the active unit sends its remote outputs.

Two operating modes are defined:

• Redundant mode: when the system is operating normally (no failures, no divergence, …), the two units apply the protocol; • Isolated mode: when system operation is ensured by only one unit, the active one. It uses its own inputs and applies its outputs. The passive unit simply acquires its own inputs, retrieves the active unit's operating context so that it can prepare its own reintegration and applies On/Off outputs in the restrictive state. To change state and/or operating mode, actions may be taken by the units:

• initialization: after a reset, one unit is in isolated mode. If the two units are initialized, one becomes active and the other passive. If only one unit is reset, and the other is active, it will restart in passive mode; • reintegration: used to changes from the isolated mode to the redundant mode.

The non-operational unit functionally aligns its dynamic context with that of the active unit. When the contexts are validated as identical in vital terms, the unit is deemed to be reintegrated. The computer then returns to the standard redundant operating mode. • switching: in the event of an active unit failure, switching changes a unit to the passive state, and can then switch the redundant unit to the active state. Non vital switching is used; • passivizing: lets the active unit change the passive one to non operational mode (the active unit then runs in isolated mode). Data exchanges between the two units are performed using vital messages. The logical time mechanism is used to guarantee the freshness of the information exchanged (loosing On/Off inputs, using inputs that are too old, … is forbidden). The logical time also allows a software check to ensure synchronization between the two units.

As the built-in redundancy protocol is safety critical, it uses vital processing techniques.

Built-in Redundancy Software

The built-in redundancy software comprises on the one hand, generic services, and on the other hand a host software making it possible to automatically create the redundancy code that is specific to the vital application, from its I/O and its dynamic context as provided by the Signature Predetermination Tool. This specific code calls on the generic services.

Only a very few of the application's specific parameters need to be filled-in manually should they differ from the default values.

Figure 0

 0 Figure 0 DIGISAFE® XME computer operating principle

Figure 1 DIGISAFE® XME computer hardware architecture 2

 12 Figure 1 DIGISAFE® XME computer hardware architecture

•

  The I/O module comprising only the DIGISAFE® XME I/O and dynamic controller functions. I/O module operation is coupled with a vital processing unit via a standard network. The vital processing units are then used as I/O concentrators. This allows implementing a distributed I/O network with the capacity to remotely locate I/O many kilometers away thanks to the use of a fiber optic Ethernet network. If necessary, to ensure availability, sets of I/O, managed by a concentrator, are duplicated.

For a coded

  operation Op (X, Y): Z = (X F op Y F , G op (X, Y) ) (securely calculated result with X C and Y C ) G op (X, Y) = ( -r k (X F op Y F ) + F op (B x ,B y ) + D ) modulo A The addition example shows how to understand the mechanism: F plus (B x , B y ) = (B x + B y ) modulo A, G plus (X, Y) = (X C + Y C -D) modulo A Detecting operand and operator errors using the pre-determinable signature: Using operand T in place of Y in "Z=X+Y", yields: Z = ( X F + T F , -r k (X F + T F ) + B x + B t + D ) Using operation op in place of the addition, yields: Z = ( X F op Y F , -r k (X F op Y F ) + F op (B x , B y ) + D )

Figure 2

 2 Figure 2 IF-THEN-ELSE branching

  Figure 2 Double system principle

Figure 3

 3 Figure 3 Control sequence for DIGISAFE® XME I/O and the vital software

•

  Fig. 3 Redundant architecture

•

  Typing restricted to integer and Boolean values, arrays of integer and Boolean values, floating point calculations not available • No reentrance nor recursivness • Only one cyclic task is run by the vital software (multi-tasking was available in the previous version but not used) • The maximum number of vital On/Off I/O that can be handled by a computer, excluding an I/O concentrator, is limited to 72 boards (one input board = 8 inputs, one output board = 7 outputs) or for example 384 vital inputs and 168 vital outputs (a set of I/O managed by a concentrator in its maximum configuration could reach up to eight times more I/O).

-22 -23 January 2004

CERTIFICATION

The latest version of the DIGISAFE® XME advanced vital computer is SIL4 certified by TUV. This means that it ensures that events with catastrophic consequences are made "impossible".

The previous version of this computer (the version used on Line 14 of the Paris metro) is RATP (Paris transport authority) validated and SIL4 certified by TUV.

The safety level achieved by the DIGISAFE® XME computer is better than the target of 10 -11 undetected failures per hour, a level required of the most demanding systems. This level of safety can be proven.

The aim is to ensure that the hourly rate of occurrence for dangerous failures remains below 10 -11 per hour: Pdangerous_Error ≤ 10 -11 / h.

The absolute probability P abs of not detecting an error is linked to the size of the coding used: P abs = 1/code_size = 1/2 48 = 3.55.10 -15 .

If λ is the average failure rate per hour affecting the entire system, we can show that: Pdangerous_error ≤ λ × P abs .

It is therefore enough to have: λ × P abs ≤ 10 -11 / h. This is largely the case, as the realistic values for λ are some 10 -2 /h for a controlled system and 10 -3 /h for an automatic system.

The validation approach is a different one from conventional fault injection approaches. As safety is independent of the hardware used (microprocessor, memories, transmission media, bus…), of the computer system platform (real-time monitor), the production system (compiler, link editor), the DIGISAFE® XME computer is validated by simply analyzing its specifications and the VHDL implementation (subject to implementation constraints).

As vital processing functions are isolated in specific hardware (Inputs/Output boards, dynamic controller, coprocessor), computer validation is restricted to the analysis of this equipment.

CONCLUSION

Digitizing vital functions our control systems led to the development of the DIGISAFE® XME computer. Vital safety functions rely on data coding so that failures can be detected independently of the hardware used.

The computer has evolved significantly since; the latest version. The main improvements cover:

• Performance: a gain in excess of 80 since the first version of DIGISAFE® XME.

•

Openness to standards: a standard CPU board, a cPCI bus. This openness will allow the computer to evolve further in terms of performance in line with technology.

• Availability: DIGISAFE® XME proposes a generic and transparent redundancy management protocol for vital applications. It almost entirely eliminates the need for redundancy related system security studies and simplifies the coding of redundant applications.

• Modularity and versatility: adapting DIGISAFE® XME to different usage configurations: secure processing unit, remote I/O module and complete computer with high performance positioning functions.

With the latest generation of computer, DIGISAFE® XME technology has achieved a level of performance and availability that ensures that it can meet the needs of even the most demanding applications. Its open architecture means that it can take advantage of on-going improvements to processors, busses and communications. Through this open architecture, the DIGISAFE® XME computer is usable in any field where stringent safety and availability demands are made.


O Notebaert
email: olivier.notebaert@astrium.eads.net

Arnaud Stransky

Vinh-Quy Ribal

Hans Corin

Torbjorn Hult

Session 5A: Hardware & Software Architectures Ariane 5-ALF: an HW/SW Architecture driven Data Handling System evolution

In the coming years, the Ariane 5 On-Board-Computer (OBC) will handle missions and performances enhancements together with the need for significantly reducing costs and the replacement of obsolescent components. The OBC evolution is naturally driven by these factors, but also needs to consider the SW system compliance. Indeed, it would be a major concern that the necessary change of the underlying HW should imply new development of the flight software, mission database and ground control system.

The Ariane 5 SW uses ADA language, which enables verifiable definition of the interfaces and provides a standardized level of the real-time behavior. To enforce portability, it has a layered architecture that clearly separates application SW and data from the lower level software. In addition, the on-board mission data is managed thanks to the extraction of an image of the systems database located in a structured memory area (the exchange memory). Used for all interchanges between the system application software and the launcher's subsystems and peripherals, the exchange memory is the virtual view of the Ariane 5 system from the flight SW standpoint. Thanks to these early architectural and structural choices, portability on future hardware is theorycally guaranteed, whenever the exchange memory data structures and the service layer interfaces remains stable. The ALF working group has defined and manufactured a mock-up that fulfils these architectural constraints with a completely new on-board computer featuring improvements such as the microprocessor replacement as well as an advanced integrated I/O controller for access to the system data bus. Lower level SW has been prototyped on this new hardware in order to fulfill the same level of services as the current one while completely hiding the underlying HW/SW implementation to the rest of the system. Functional and performance evaluation of this platform consolidated at system level will show the potential benefits and the limits of such approach.

Ariane 5 Data Handling Subsystem

The Ariane 5 Data Handling is part of the launcher's electrical system, which is required to remain operational in case of failure of any of its equipment. Additionally, the allowed autonomous reconfiguration time is limited, especially during the most critical mission phases. The Data Handling Subsystem has been therefore organised as dual redundant chain of sensors and actuators (Fig. 1).

The communication system (SdC for Système de Communication) is implemented with Mil-std-1553B standard components and is the only data link between the computer pool and the equipments. This computer system operates in a hot active/standby configuration: in nominal situation, the Master computer (OBC1) controls the communications on both buses and executes the flight software. The Backup computer (OBC2) monitors the bus traffic in parallel and maintains the flight dynamic data context running the same algorithms. The flight software is able to control and monitor any nominal or redundant remote unit and to eliminate faulty items from the functional chain. In addition, the Master computer has the capability to self-detect any abnormal local situation, electrically isolate itself from the communication bus and trigger a switchover to the other computer. In such situation, the Backup computer is able to take over the flight control in a very limited time frame.

On-Board Computer

The choice of using a standard serial bus as the backbone for the avionics system communication has driven the internal architecture of the On-Board-Computer. Indeed, in the late eighties, the best way to organize the system communication scheme with strong low-level synchronization constraints was to control a standard 1553B I/O device by a dedicated SW driver. In addition, the performance needed for the flight software required to de-couple the data acquisition and distribution function from the flight control application. The OBC has been therefore designed with three functional blocks (Fig. 2): A Power supply (APS), an application processor board (UT) and an I/O controller (UES) providing access to exchanged data in memory. Both processor boards are implemented around 68020 microprocessors that meet the Ariane 5 standard radiation requirements.

On-Board Software

The Ariane 5 Flight Software is responsible for the launcher's flight control. Its properties have been enforced by the usage of the HOOD method (Hierarchical Object Oriented Design) during its development, in particular the layered architecture.

On the application processor, the flight control layer (LN3) and the launchers electrical equipments management layer (LN2) constitute the Flight Program Software (FPS) that can be mission dependant (Fig. 3).

The service layer (LN1) provides mission independent operating system and services environment. The flight program ensures functions such as mission sequencing, flight control, guidance, navigation and electrical system monitoring, failure management and reconfiguration. It is mostly written in ADA and uses the Alsys ARTK® run-time and ADA environment. The LN1 is implemented as a library, which provides access to all resources of the data-handling subsystem.

On Board Computer Evolution

Rationale for HW evolution

The current launcher system has to face different goals to remain competitive. In this framework, the Ariane 5 launcher still continues to evolve, offering new services at lower costs (mainly launch of heavier payloads, at higher orbits). This includes more constraints on the different sub-systems -including avionics -that may be summed up as:

Decrease of the costs: this has led in the OBC to mainly reduce the components and boards numbers, and to enhance the production, tests and validation tools to gain efficiency.

Increase of the mission duration: this impacts both the avionics behaviour and global performances (provide same quality during a longer mission), as well as the radiation aspects (higher particles rates in the different atmosphere layers during longer duration).

Management of obsolescence: to provide a better reusability of sub-systems to various missions and strategies, the new architectures shall reduce dependence on components or technologies.

Increase the processing capability both to improve CPU load margin, which is currently very low, and to be able to offer new functions.

The current OBC shall be upgraded according to these requirements and with the constraint of risk minimisation.

Studies are currently performed in order to quantify and minimise these risks but one good way to validate the architecture is to develop a mock-up and analyse the system impacts from it.

Impacts of changes on flight SW

As some of the computer parts change, it is not possible to strictly preserve the same whole flight software within a new design. At least, the lower level SW including the Board Support package (BSP) and possibly the operating system interface needs to be adapted to the new target. Within a layered SW architecture, the lower layer software can implement all necessary adaptations so as to present an unmodified interface at the upper layer level. To this aim, the following constraints on SW porting have been identified from existing design to ensure best compatibility:

Mission data is structured in the OBC memory to be managed by both low-level and high-level software, and is an output of the mission database. To preserve these structures is mandatory.

Low-level services interfaces shall be kept, as well in terms of syntax as in terms of minimal performances and global behaviour.

Ground-Board communication protocol: though this is a part of the ground benches, this protocol may have many impacts on the software structure, and has to be preserved.

Real-time structure: as a critical embedded software, the real-time tasking is a precious asset to be preserved.

Test systems should be kept equivalents in order to achieve reusability of the validation and qualification external equipments as well as test scenarios. However, impacts cannot be avoided for tools that are machine dependent (e.g. µP emulators).

On the static and logical level, applying these rules should allow to recompile the existing application SW and being able to run and qualify it on the new target. However, for a real-time application that has specific dynamic constraints, it probably requires special attention towards the stability of the dynamic behaviour when upgrading the HW target to another one, even more powerful.

Engineering Approach

In order to allow a system efficient use of new computer technology on Ariane, the ALF 1 Working group has been setup by the French Space Agency (CNES). DHS specialists at system, SW and HW level form a co-engineering working group that trades-off and proposes architectural and technological evolutions with respect to the assigned objectives (costs, functions, obsolescence treatment, system compatibility). The group approach is to validate proposed designs by prototyping the solutions and eventually trading-off the consequences at the launcher's system level. The primary objectives of the new OBC baseline are:

Replacement of its obsolescent 68020 processor;

OBC cost to be reduced (objective 50%);

Processing power to be enhanced (objective 400%);

No impact on external interfaces;

Porting effort of application SW reduced to minimum.

In response to the obsolescence of its processor and to the need for increased performance, the ERC32SC processor has been selected. This choice is compatible with the European Space Agency (ESA) microprocessor policy and allows for further technology upgrade with SW compatibility (e.g. future Leon processor and System on Chip).

For cost reduction and also as a contribution to an increased performance, a single processor board interfaced with a dedicated advanced I/O electronics has been selected instead of the current double processor architecture. Hence, the OBC I/O board (UES) including its processor and software is to be replaced by an ASIC (called IOK for I/O Kernel). The LN1 SW, responsible for handling the communication with the former UES board, needs to be modified in order to cope with the new hardware interface and to hide this new implementation to the upper software layer.

1

The ALF working-group, created within CNES R&T activity, prepares technology evolution of launcher avionics and data-handling system. The ALF R&D working group members are CNES, EADS-ST, EADS-Astrium and Saab-Ericsson Space (supported by the Swedish National Space Board).

In order to provide an equivalent testability level, an "emulator" connector has been implemented on the evaluation Mock-up. This connection allows plugging a Microprocessor Interface Adapter (EADS-Astrium MIA product) to monitor and control the CPU activities. The MIA is the closest you can get to a classical In-Circuit Emulator, where the user has full control over the target system to be debugged.

In order to demonstrate the system compatibility of the new OBC concept and to allow evaluating the achieved performance of the integrated system, the OBC and lower level SW system has been prototyped.

The OBC prototype

A prototype processor board has been designed (Fig. 5) in order to represent the future target computer, the I/O Kernel being implemented in an FPGA. The I/O Kernel is actually the key technological part of the new OBC. It makes it possible to take a significant step in reducing the amount of software and hardware needed, like going from a triple-board computer to a single-board computer, while at the same time reducing mass and power consumption.

As the I/O Kernel implements all the functions earlier performed by a complete CPU-based I/O processor it is structured in a similar way, comprising the following main functional blocks (Fig. 6 As the 1553 Protocol Engine is a generic existing IP module, there is a need to have some kind of translation from the 1553 message data structure used in the Ariane programme to the message structure used by the 1553 module.

An additional specific support function is the On-Board Timer that is used by the Protocol Manager to trigger bus transfers at specific intervals and to date completion of certain transfers. The On-Board Timer also includes a set of programmable timers that are used for scheduling purposes by the Application Software. This represents a significant simplification to lower level SW dated functions including higher precision since such services now rely on HW clocks with no added SW counter handling.

In addition to the 1553 Protocol Engine, the CPU interface and Exchange Memory Interface modules are reused from existing SAAB-Ericsson-Space ASIC designs that are also reused, for instance, in the Herschel/Planck satellites and the Vega small launcher. This has been a significant cost saving for the ALF study and clearly shows the advantages of having basic technology, like for processor and data buses, common between many programmes.

The SW prototype

Since the concept is to hide the underlying HW changes by the lower layer software (LN1), only the LN1 formally requires re-coding and evaluation. The upper layers source code will be ported and checked as a second step.

Lower level software

There are two low level software products that have to interface to the underlying I/O kernel of the new OBC: the LSSI Init and the LN1 (Fig. 7).

The PROM based LSSI Init SW is responsible for uploading the flight software into the launchers OBC's during the countdown operations. It is a critical software product for mission achievement but it is a standalone product without any upper layer software: the ground-board protocol will need to be preserved by a future OBC in order to remain compatible with the ground support equipment, but this has not been identified as a critical feasibility issue requiring preliminary prototyping.

The SW effort has therefore been concentrated on the LN1 prototyping, which is the key item to insert the new hardware in the system with limited impact while providing significant performance increase. The LN1 provides several services to LN2 and LN3 such as time and delays management, mode control, data communications, monitoring, reconfiguration management and initialisation.

Software development approach an tools

The development has been performed in two steps.

The LN1 SW has been first quickly prototyped using COTS development and test tools and operating system (Vxworks®, Tornado® and NetRom®). This preliminary version was aimed at quickly develop the Board Support Package and set-up the first SW to HW communications with the version 1 of the IOK that implemented the SW interfaces for bus control but with limited functionalities. This environment was convenient to start and learn from the HW and eventually update the IOK specification in order to optimise for overall best performance of the LN1+IOK services.

On a second step, the LN1 has been ported on the target Ada environment and adapted to ADA I/F with a second IOK version (V2) that supports the full set of requirements. The choice on the ERC32SC ADA compilers and runtime was driven by the system compatibility requirements: the selected baseline for the ADA compiler and runtime is the AONIX T-SMART (SAE®) tool. In order to preserve the capability of the LN1 library to suspend and resume calling tasks, a patch providing the RESUME, SUSPEND and get task ID has been implemented by Alsys. Utilisation of a GNAT environment was also foreseen but not selected.

The C cross compiler, also provided by AONIX in the AdaWorld environment has also been used for LN1. An ADA interface for interface compatibility with the application layer has been provided as an independent SW package. The use of C on the lower SW layer is not visible to application.

SW Communications with the I/O Kernel

From the design standpoint, the handling of data communications and error reporting (Fig. 8) has been quite simplified in comparison with the previous two-processors hardware. Indeed, the large number of control and monitoring signals that can be made available on a device like the IOK makes a direct interface with the board management software much easier. For instance, message passing from SW to IO device is handled through data queues instead of interruption as per previous design. As a result, we expect an improved performance of LN1 services by a higher factor than the pure estimated microprocessor ratio of 4 -when no task re-scheduling has to be done. 21 -22 -23 January 2004

Data structures compatibility

On the Ariane 5 program, the on-board data structures are elaborated from a database through the flight SW system generation tool (OML). This tool allows for extraction of data from the database and for generation of 68020 assembly packages. All data structures useful for the launcher mission are described in the system database and need to be stored into the exchange memory: individuals transfer, series, frames, configuration tables… These packages are loaded during launch operations through the 1553 interface.

The constraint was to keep this memory structure unmodified for data interface with the IOK for best compatibility. To this aim, a tool allowing converting the 68020-assembly code in SPARC assembly code was developed in AWK language.

To each 68020 assembly module corresponds a SPARC assembly module. Each SPARC file are compiled and can be loaded in the IOK memory and a ".h" library file includes all these definition to get them visible to the LN1 software (Fig. 9).

Mock-Up Evaluation

Evaluation objectives

The objective of the performance evaluation is to demonstrate the validity of the ALF concept, i.e. that the developed technology brings an improvement of the LSSI (LN1+IOK) performances that enhances the CPU resources for the application layer with a stable interface. In order to achieve this, four evaluations levels have been defined:

Characterization of the ALF Mock-up performance at LN1 service interface to application; Evaluation of the ALF Mock-up performance in a flight software representative situation and comparison with the current A5 DHSS (OBC+LSSI); Evaluation of the porting effort for application software; Demonstration that the Alf Mock-up is compatible with the Ground I/F.

Test environment

Performance evaluation with the current Ariane 5 OBC is performed with the Software Development Models (SDM98) that allow connection of two Lauterbach® 68020 CPU emulators (one on each CPU board) providing full nonintrusive debug and measurement access to the microprocessor instruction level. For the ERC32SC processor, an emulator does not exist off the shelf, so the ERC32 MIA based test equipment was developed in parallel with the ALF study and supports similar non-intrusive debug and test capabilities. A 1553B bus monitor and simulator has also been synchronized to the MIA test equipment thus sharing the same clock reference: precise measurements of transit time from application call to transfer on the communication bus can therefore be measured with an accuracy better than 2µs.

For comparison and compatibility tests, the old and new OBC's test configurations are coupled on the communication bus (Fig. 10). One computer plays the role of the Master OBC and the other one plays the role of the Backup OBC in standby/monitoring mode. This way, the OBC's are in the same configuration as on the real launcher. For these tests, the master OBC runs the so called golden frame that represents the traffic on the Ariane 5 communication bus at the end of the booster phase, which is considered to be one of the most critical phase from a SW application performance standpoint.

Test activity

In order to measure the performance of the LN1 services, full tracking of SW calls and data through the different layers transitions has been performed (Fig. 11). This activity has provided values to the end-to-end service access time and also a very good view of the performances costs within SW layers (interfaces, ADA-run-time, re-scheduling, queues handling…) and in HW (memory accesses, bus transfers…).

For the evaluation of the ALF mock-up in a flight representative situation and the comparison with the present OBC, the application SW is derived from the robustness tests that have been already used on the present Ariane 5 OBC. It has been ported for the Sparc environment and adapted in order to reproduce the same type of access to the LN1 as the flight SW. Exchange memory accesses are added on top of this traffic in order to simulate high application data usage and to test the limits of the computer processing capability. The performances of the ALF computer can be compared with the present OBC, thus providing a good view of the enhanced processing capability of the new platform and the improved frame transfers accuracy. Switching the OBC roles allows evaluating and comparing the achieved performance in both the master and the standby/monitoring mode.

Tests results

At this stage of the activities, the evaluation has not yet been completed but some preliminary results are available which show a good performance improvement with the ALF mock-up. Some typical measurements on the ALF Mockup latency time (TD1 on Fig. 11) compared with current OBC are displayed below on table 1: The ALF working group approach provided a real and evaluated case showing that an ad-hoc strategy, applied at first HW/SW development stage, eases the evolution of a complex system with reasonable constraints on the HW and SW definition. Moreover, it showed that joint engineering efforts of customer, system, SW, test equipment and HW design actors, organized into a common working group, enforces the coherence of the overall designed system.

Type of Measurement

Fig. 1 :Fig. 2 :

 12 Fig. 1: Ariane 5 Electrical Communication Chains

Fig. 3 :

 3 Fig. 3: Ariane 5 Data Handling Software architecture

FigFig. 4 :

 4 Fig. 5: The ALF ERC32 single board OBC

  Fig. 6: The New OBC I/O kernel Architecture

Fig

  Fig. 8: SW communications with the I/O Kernel

Fig. 9 :

 9 Fig. 9: Conversion of data structures into Sparc memory loadable file

Fig. 10 :

 10 Fig. 10: The ALF performance evaluation test in full configuration

  Fig. 11: LN1 services timing decomposition

Table 1 : Preliminary figures for typical performance improvement

 1

-22 -23 January 2004

System Level Evaluation

In the first phase, a theoretical evaluation of the flight program behaviour is performed within the ALF framework, focused on analysing the global performances of the computer from the ALF mock-up evaluation results given at the LN1 level. But the final validation of the mock-up will be done on the Flight Program Software (FPS) in real conditions. Indeed, the evaluation performed on the ALF mock-up i.e.: for LN1 replacement: measurement of LN1 services performance;

for Real-time kernel replacement: measurement of tasking performance (task commutation, IT handling…), shared variables services (semaphores, timers…); for I/O system replacement: measurement of I/O unitary services, global I/O rate, synchronous and asynchronous messages management performances; for mathematical library replacement: all mathematical functions, global mathematical algorithms; for CPU replacement: logic algorithms, memory access algorithms and benchmarks with representative parts of the flight program code;

is not sufficient to guarantee the full portability of the operational FPS. What is currently envisioned for 2004 task is therefore to verify the correct operation of the ported FPS prototype on the ALF mock-up.

The used FPS will be a qualified generic version of the A5ECA FPS (ECA 3.2 software version) and the most stringent flight phases will be verified (ground and EAP boosters phases).

The points that will especially be under review are: Check-out of the SAE runtime operation with FPS tasks (ARTK is currently used); Verification of LN1 services operation in an operational context; CPU load measurement during ground and EAP phases for an operational nominal flight case.

The following tasks require to be performed with a new development environment:

Update of LN2 and LN3 to remove 68020 assembler; Update LN3 to take into account the real time kernel change and, as a consequence, jitters and delays adaptation;

Generation of an exchange memory for the ERC32 target (Sparc V7 type);

Compilation with a new compiler of the whole FPS (over 50000 Ada code lines); Update of the FPS production procedures. These tasks will assess the compatibility of the ALF mock-up with the Ariane 5 programme needs on A5ESCA or A5ESCB launchers.

Conclusion & Perspectives

At the end of the current phase, the ALF Mock-up will be ready for evaluation of the flight program software porting on this environment. The evaluated concept and I/O Kernel will also be a basis for further evolutions such as, for instance, the evolution of the microprocessor toward the Leon processor or system on chip.