François Xavier Dormoy

SCADE 6 A Model Based Solution For Safety Critical Software Development

Keywords: Model-driven-design, formal-methods, SCADE, safety-critical, Synchronous Languages

SCADE Version 6 is both a language and a Safety Critical Development Environment that brings a new Unified Modeling Style that provides a seamless and safe flow from system to software engineering. This flow relies on strong foundations where safety is considered at each step that allows engineers to focus on key issues whilst removing a significant part of the burden of the development process. SCADE6 is a model based tool that has been designed to cope with engineers needs together with safety constraints expressed in several standards such as D0178-B, EN50128 or IEC 61508. This paper presents SCADE version 6 and points out the key factors we have addressed during the language definition, modelling environment and code generation development in order to cope with a safety critical development flow.

Introduction

1.1 Safety Critical Software challenges Avionic, railway and automotive systems have become very complex to develop without the assistance of a design environment tool that eases the engineering process. Complex applications such as cockpit display systems, guidance systems, engine controls, autopilots or interlocking systems require a seamless and safe transition from abstraction to implementation. Model-Based Design delivers those benefits that include:

• Addressing the complexities inherent in control systems designs, • Starting software design before physical systems are available, • Verifying the system prior to the implementation, so that errors in the specification of requirements can be detected and eliminated earlier in the development cycle,

• Creating a structure for software reuse that allows a reliable and cost effective upgrade path for established designs.

Overview of SCADE SCADE (Safety Critical Application Development

Environment) is both a language and a toolset that was specifically developed to describe and implement safety critical applications. SCADE is the result of a collaboration between Verimag, Aérospatiale (now Airbus), Merlin Gerin (now Schneider Electric) and Verilog. It relies on the theory of synchronous languages for real-time applications and, in particular, on the Lustre and Esterel languages as described in [START_REF] Halbwachs | Synchronous Programming of Reactive Systems[END_REF],[9] and [START_REF] Berry | The Foundations of Esterel[END_REF], [START_REF] André | Representation and Analysis of Reactive Behaviors: A Synchronous Approach[END_REF].

The synchronous approach is a cycle-based execution model of SCADE. This is a direct computer implementation of the ubiquitous samplingactuating model of control engineering. It consists of performing a continuous loop of the form illustrated in Figure 1 below. In this loop, there is a strict alternation between environment actions and application actions. Once the input sensors are read, the cyclic function starts computing the cycle outputs. During that time, the cyclic function is blind to environment changes. When the outputs are ready, or at a given time determined by a clock, the output values are fed back to the environment, and the program waits for the start of the next cycle. SCADE addresses the applicative part of hard realtime software, as illustrated in Figure 2. This is usually the most complex and changeable aspect of software, containing complex decision logic, filters, and control laws. It typically represents 60% to 80% of the software embedded in an airborne computer.

Figure 2: SCADE addresses the applicative part of software SCADE represents a bridge between Control Engineering and Software Engineering because it provides a common, rigorous graphical and textual language for both communities that reflect control engineering constructs:

• Its data flow structure fits the block diagram approach.

• Its time operators fit the z operator of control engineering. For instance, z-1, the operator of control engineering (meaning a unit delay), has an equivalent operator called "pre" in SCADE. SCADE is now used for critical control software in aircraft, helicopters, nuclear power plants and railway switching systems. SCADE modelling capabilities cover designing, verifying and optimising complex algorithms, control intensive applications, and graphic interfaces. Furthermore, the SCADE automatic Code Generator has been qualified to produce a portion of the evidence mandated by certification authorities, supporting a safety-critical process in a cost effective manner.

SCADE 6: Unified Modelling Style

SCADE Version 6 is a new version of the SCADE language that keeps the foundation (formal and synchronous execution, strong typing, explicit initialization of data flows, explicit management of time, simple expression of concurrency) and extends the modelling capabilities towards several directions:

• Data flow extensions that improve the control part (reset, activate, merge)

• Control features expressed in terms of statemachines

• Safe loop features implemented using higher order iterators

• Other modelling features that improve the connection to the environment (Sensor) and ease the reusability with a better encapsulation of data (Package) and polymorphism

Data flow extension toward control

Work performed [START_REF] Colaço | A Conservative Extension of Synchronous Data-flow with State Machines[END_REF] started with defining an extension of the data flow part with several constructs that will be the support for state machine extension.

restart is a higher-order operator that allows to retrieve the initial state. This construct is very useful in dataflow model in order to implement reset feature without modelling this with inputs, wires and if/switch constructs.

The syntax of a restart instantiation is:

(restart N every c)(e). The second extension is about introducing a merge operator that builds a flow on top of complementary clocked flows. merge takes, as first argument, a clock identifier h used to select one of its other inputs. This operator evaluates first the value of its clock expression. Depending on this value, the corresponding expression is defined at the current cycle and its value is the result of its evaluation as shown in figure 9. The third main extension is about improving the imperative features in Data flow. In SCADE previous versions, when and mainly condact were the only way to control computation. In SCADE version 6, the control feature is extended toward 2 directions: Control activation of an operator: activate on operator is a higher order constructs providing 3 usages:

• activate <N> every <clock_expr>: N is activated when clock expression is true. The result is clocked in sync with <clock_expr>. This is equivalent to : N((e1, ... ,en) when c);

• activate <N> every <expr1> default <expr2>: This construct is a variant of the previous one without memorization of the result of N when <expr1> is false. N is activated when <expr1> is true.

• activate <N> every <expr1> initial default <expr2>: This construct is equivalent to condact in the previous SCADE versions. N is activated when expr1 is true. When expr1 is false, the result is initialized with <expr2> and after one computation of N, the result sustains the last result of N. Control activation of a set of equations: activate on a set of equations is now possible in SCADE 6 in order to make conditional computations. This is possible through Boolean conditions (activate if) or through enumerated conditions (activate when match). These constructs are called clocked_blocks.

Example of activate initial default:

• activate [<id>] if <expr> then <equation_set1> else <equation_set2>: if <expr> is true <equation_set1> is computed, this set of equations could contain other clocked block.

• When the application is data-flow dominated (e.g., regulation systems), it will naturally go for block diagram formalisms as it is provided in SCADE for years. On the contrary, when the application is more control dominated (e.g., cockpit displays), imperative or state-machine based formalisms as the ones provided by StateCharts [10], the Sync-Chart [START_REF] André | Representation and Analysis of Reactive Behaviors: A Synchronous Approach[END_REF] or Esterel [START_REF] Berry | The Foundations of Esterel[END_REF], [START_REF] Berry | The Esterel synchronous[END_REF] will certainly be better choices. Nonetheless, real systems rarely fall into one category and are often a mix of both styles.

The extension provided in SCADE 6 allows to mix both styles in a conservative way [START_REF] Colaço | A Conservative Extension of Synchronous Data-flow with State Machines[END_REF], [START_REF] Colaço | Mixing Signals and Modes in Synchronous Data-flow Systems[END_REF] meaning that all new state-machine features are translated (compiled) to basic clocked data flow. In that way the state-machines bring useful syntactical facilities but do not break the data-flow principles.

Let us explain the main principle through an example. We choose the same example as in [11] that illustrates how a data can be computed in several ways according to modes. In textual : A state can be flagged as final by using the keyword final before the keyword state. Any state can be final (even the initial one) and a State Machine is not limited to only one final state.

Given a state S containing several sub-State Machines running in parallel, if at the next cycle all these sub-State Machines are in a state marked as final, then a synchronization transition can be fired from state S. The target state becomes active the cycle after but the actions on the transition are activated within the cycle (as for weak transitions).

Example:

The example illustrated bellow (Figure 24) shows a state-machine that detects two events (A and B) independently of the way it occurs, A before B or B before A or A and B simultaneously. When both events are detected, F_A and F_B are active then the synchronisation transition is fired and OSig signal is emitted. R is a preemption transition that resets the state-machine. In textual :

node The flow state_sel carries the notion of selected state, state_act, the notion of activated state, and state_next, the notion of the next cycle's selected state. The equation defining state_act uses state_sel and the strong transition part of the automaton's states. The equation defining state_next uses state_act and the body and the weak part of the automaton. These variables belong to an enumerated type that represents the states of the automaton (one enumerator per state). Since only one transition must be fired during a cycle, the knowledge of already fired strong transition in the selected state must be used before firing a weak transition in the active one. A type enumerating all possible transitions is used therefore. Repeating a computation for large array data or computing vectors or matrices is very common in embedded systems. The challenge for a modeling language addressing safety critical systems is to provide safe loop constructs. The principle in SCADE version 6 is to provide several predefined iterators scheme. We present in this paper the main ones.

Iterators are again higher order operators with the following general syntactic form: The fold operator also allows applying a node successively to array arguments. But contrary to map operator, it does not build an array of the same size as its arguments: it provides an element belonging to the basic type of the arrays (called accumulator) which is initialized in the called parameter then passed from one array element to the next one. The result is the accumulator provided by the N applyed to the last element.

Example Sum of the elements of an array: Other iterators exist such as mapfold which is a combination of map and fold, others iterators allow to get access to the index of the computation (mapi, foldi, …).

Other modelling features

Assume and guarantee:

Design-by-contract is a clean and safe software engineering principle. A contract is a specification of the condition of use and the expectations of a function (or a node).

This contract is made of a pair of observers.

• one corresponding to condition of use: assume,

• one corresponding to ensured properties: guarantee.

Assume and guarantee do not impact the semantic of the model, they are part of the model for proof purpose.

Sensor:

A sensor defines a global flow that can be read anywhere by the model, and is a model input. A sensor is semantically very close to a constant but with the ability to be updated between each cycle. A sensor should remain stable during all the cycle computation.

Package:

The package (or module or namespace) mechanism is a software engineering feature provided by many program languages. It makes the design and the usage of libraries easier.

A package definition is a block of declarations starting with the keyword package and the name of the package and ended with the keyword end followed by a semicolon. package Integer type T = int ; const ZERO : T = 0 ; function plus (x,y: T) returns (z: T) z = x+y; end; Polymorphism: SCADE provides a way to define generic nodes, also called polymorphic nodes. Genericity is expressed by using type variables written as quoted ident. The quoted ident 'T represents a type variable: a, b and c can be of any type. The only constraint they have to fulfil is that they belong to the same type. If more than one type variable is required in a node profile, one has to use a different quoted ident.

Safety apply to SCADE 6 itself

3.1 Framework safety principles SCADE 6 is a model based framework made of several tool addressing Safety critical systems. In this section, we address some of the key points that contribute to the safety of the complete tool chain. The question we want to answer here is: "what are the characteristics that can make a tool chain suitable in safety-critical context?" First, the language (or the formalism) is one major point. In the first part of the paper we have presented it and let's recall the main characteristics:

• formal, deterministic and documented • graphical and textual (with a mapping between both)

• simple and powerful (the tradeoff is very difficult to tune) • precise and concise Derived from these principles: o Causality check Then, once the language is formally defined, the main goal of the approach is to generate code out of the description (model) of the system. Currently the most appropriate approach is the certification approach according to standards like DO-178B and IEC 61508 and EN 50128. In the future, the proof of the correctness of the code generator should be very suitable and for the time being, this approach is only experimented in academics [13]. The code generator takes as input files containing the description of the model according to language concrete syntax. The graphical editor has to generate these files (storage file) with a clear separation between the graphical data and the semantical data. The graphical data should only contain drawing data (positions, size, etc) and shall not impact the semantics. The editing feature is generally out of the scope of the certification but the tool should be intuitive and should avoid source of errors. The constraint to address is to be able during edition to save the model in a correct syntactic form (wrt to language) in order to be able to load it afterward to continue the modeling work. This has a huge impact on all editing principles

Standards

It's important that the same standard requested by the application is fulfilled by the tool. For that reason, the Code generator has been developed according to standards such as DO178-B, EN 50128, IEC 61508. Several other tools like MTC (Model Test Coverage), CVK (Compiler verification Kit) and the Reporter has been qualified according to DO178-B as verification tool.

3.3 Design and developments SCADE 6 has been used to model and code some complex part of the SCADE 6 simulator. The simulator needs to handle several modes with a complex logic containing pre-emption. Figure 23

Acknowledgement

My sincere thanks to following people:

• Jean Louis Colaço and Bruno Pagano: Authors of SCADE 6 language

• G. Berry, N. Halbwachs P. Caspi : SCADE 6 Synchronous foundations with Lustre and Esterel

• SCADE 6 team: The people that make it real!

Figure 1 :

 1 Figure 1: The cycle-based execution model of SCADE Suite

Figure 3 Figure 4 :

 34 Figure 3: Count Node

Figure 7 :Figure 8 :

 78 Figure 7: Sample Node

FigureFigure 11

 11 Figure 9: merge semantics

Figure 12 :

 12 Figure 12: two_instance node behavior

  Figure 13: node two_instance_2

  Figure 15: node two_instance_3

Figure 16 :

 16 Figure 16: two_instance_3 node behaviour

Figure 17 :

 17 Figure 17: two_instance_4 node behaviour

Figure 18 :

 18 Figure 18: Node UpDown

  Figure 24: Node ABRO

Figure

  Figure 20: Node N

  Figure 21: Node Sum_Scalar

  Figure 22: Node Array_sum s = Sum_scalar ( Sum_scalar ( sum_scalar (0, t[0]) , t[1]) , t [2]) ;

  node sample_generic (a,b: 'T) returns (c: 'T) var flag : bool ; let flag = true -> not (pre flag ) ; c = if flag then a else b ; tel

3 (

 3 Figure 23: SCADE 6 simulator mode state-machine <SimulatorStateMachine>


R Natarajan

Architecture for Multiprocessor Systems for Distributed Computing

Keywords: Software architecture, node, multiprocessing, "by-wire" system, fault tolerance, redundant system, safety-critical system. 1. Introduction

The growth in technology and the new developments in the semiconductor domain resulted in the transition of software from an auxiliary role to a primary role in implementing critical systems in vehicles. This resulted in an increasing trend towards the usage of electronic systems in vehicles. The usage of software for precise control and implementation of new features is gaining momentum in both automotive and avionics domain. As a result the number of processing units are fast increasing and systems are becoming more and more complex. The use of distributed computing and the complex requirements demands the need for unique software architecture. The biggest challenge faced by system designers is to have software architecture to maximize the utilization of the computing resources. This paper presents a comprehensive architecture to utilize the power of multi processor systems and high-speed fault tolerant communication protocols, in implementing a distributed computing platform for next generation of systems in avionics and automotive domain.

multiprocessor computing framework and mechanisms for fault tolerance. The architecture is made configurable and scalable to address multi cores/ multi processors in a single board collaborating on a communication network (distributed computing nodes) The suggested architecture for distributed processing enable the OEMs and Tier-1 manufacturers to develop and deploy several features in the vehicles with considerably less effort in a cost-effective manner with high degree of fault tolerance.

Architecture

The proposed Multi Node Software Framework is presented in the figure 1 given below. The Multi Node Manager (MNM) manages the hardware resources, and provides set of interfaces that can be employed in developing application tasks. The MNM has two major functionalities: 1. To provide an environment for application task execution 2.For communicating between different nodes in a network.

Definitions:

Node: Any processing unit that forms part of a distributed system. The node may contain single or multiple processors. In case of multiple processors, the processors can be linked with each other by a link-port. Node can be imagined as a single entity with one or more processors, which does a specific functionality and communicate with similar nodes using a communication port.

Link-port: An interconnection between two or more processors within a node (local). It can be highspeed link bus or a shared memory.

Communication-port:

The communication port enables a node to be connected with other nodes (Remote) (e.g. TTP, CAN or similar bus architectures). Messages: Message is any piece of information exchanged between processing units within a node or between nodes. There are two classes of messages namely System messages and Data messages. The System messages are OS control information & OS data, exchanged between processing units within a node (Local) or between nodes (Remote). The Data messages are information data that are passed locally or remotely

System Features:

The main features of the proposed MNM task execution module are: support of multitasking fixed number of tasks, pre-emptive task scheduling by static priority, inter-task/processor communication and synchronization via semaphores, messages, and queues. The application tasks can utilize MNM services using the library interface provided. The MNM implements kernel threads for managing the system. These threads communicate with each other using system messages. The main functionalities of the MNM threads are listed below • Task scheduling

• Command execution • Communication
• Fault detection and Handling

• Resource management

The services provided by the MNM are of two types: local services and remote services. An application task can generate a call to a function of the kernel, e.g., to manipulate a semaphore or any other resource, which can be either a Local call, which is executed at the local processor or a Remote call, which is executed in another processor. Calls are either local or remote depending on the location of the resources being manipulated in the call. The application task execution environment is implemented by scheduler, which supports both Single Processor and Multi processor task execution. In Single Processor configuration the MNM scheduler behaves more or less similar to a commercial RTOS. But in Multi Processor configuration it enables multi processing between different processors in a node interconnected by link -port. The OS resources for multi processing are shared between the different processors using the supported link mechanism. The link ports provide high-speed and bi-directional data transfer between system nodes. Processing units within a node communicate asynchronously through a link. Links can be used to form a network of processing units. Each processing unit in a node has an identifier, which makes it possible for other components to uniquely identify particular processing unit/node in the system. The processing units communicate through the exchange of messages. Each message can be characterized by a Source & destination id, message priority and data/command. Processing units maintain a static routing table for routing of messages.

The second major functionality is to provide an infrastructure for data exchange between different nodes in a communication network. The communication network can be Time triggered or Event triggered network that helps in information exchange. The data messages are transferred using the above mechanism. The following sections present the main components of the proposed MNM.

Scheduler

Each application task has a corresponding Task Control Block (TCB), which is a data structure where the task information is stored. A TCB contain the task identification, task priority, the context, task state, and handles of resource object used by the task. All kernel threads can access the TCBs, but they are used mainly for multitasking. The proposed system use pre-emptive task scheduling based on static priority as scheduling policy. The kernel uses two parameters to perform multi tasking: the running task and the next task ready to execute. When a task is running, the two parameters indicate the same task. If an operation that causes the suspension of the running task happens, the thread that executes this operation invokes the Scheduler thread in order to schedule the next task. Another way could be to raise the priority of the next task than the running task in which case the Scheduler thread schedules this task. Scheduler thread when called saves the machine context in the TCB of the task being suspended and restores the status of the task being scheduled for execution.

Communication Router

The communication router module manages three threads • Local Command Handler (LCH)

• Remote Command Handler (RCH)

• Data copy Handler Calls generated by the application tasks can be either a local call, which is executed at the local processor or a remote call, which is executed in another processor (node). The decision of remote or local call is determined by the location of the resources being manipulated in the call. When the local processor encounters a remote call, the call is encapsulated in a command message, and this message is sent to the destination processor. At the destination node, the kernel of this processor decodes the command and executes the corresponding call. Some calls return information to the application tasks that generate them. The application task that executes the call is blocked waiting for the call to return.

Local Command Handler

The Local Command Handler thread handles the execution of the local calls. After a call is issued, LCH decodes and executes the call. The execution of a call may trigger the scheduling of another task. In this case, LCH requests the Scheduler thread to schedule this new task for execution.

Remote Control Handler

The Remote Command Handler thread handles the execution of calls received from other processors. RCH is similar to LCH, except for that LCH only receives one call at a time, while RCH can receive multiple calls.

Data Copy Handler

The Copy handler copies data blocks from the processor memory to external node using the sender thread services. After receiving a copy request, Copy handler provides the required data transfer by copying data blocks from the system memory and forwarding these blocks to the Sender thread. When the transfer finishes, Copy handler sets the task waiting for the copy to be completed as ready to execute. This task may be either a local or a remote task. The copy handler also manages the data messages transmission and reception to the other nodes. In case of data messages the copy handler sends the message to the corresponding node using the link interface & communication driver services. The received data messages from other nodes are transferred to the task(s) configured for reception.

Link Interface

Link interface provides a standard interface for the kernel threads to communicate with other processors and nodes within the system. The proposed system uses link ports for inter processor communication. The communication ports are used for the data message exchange between nodes. The link interface also implements a suitable routing algorithm.

Sender & Receiver

The Sender and Receiver threads handle the sending and receiving of messages through processor link ports and node communication ports. Sender follows a store and forward policy: After receiving a remote request from another thread it sends the message to the link interface. Incoming messages are transferred by the link interface to the receiver thread. After receiving a message, Receiver checks the message destination. In case the destination is the local processor, either a data message copied to the destination address, or a command message is forwarded to RCH, depending on whether data or command messages are received. In case the destination is a remote processor, Receiver requests the appropriate Sender thread to forward the message to the destination. Each message gets the same priority as the application task that generates the message. The messages with higher priorities are sent before (overtake) messages with lower priorities. In case of data messages the sender module transmits the data using the communication driver. The received data messages are transferred to the data copy handler for forwarding to the configured application tasks.

Time Manager

The time manager monitors the passage of time and manages the timers. This thread handles the system tick used for scheduling. Timers are kept in a timing linked list. When a timeout occurs, i.e., the number of pending ticks for a certain timer equals zero, the timer is removed from the list, the task associated with the timer gets an indication of the occurrence of the timeout, and Scheduler is called in order to schedule the task for execution.

The time manager can also be configured to synchronize all the timing parameters with respect to the network time. This is essential in TTP communication where tasks are configured based on the network time. The scheduler using the schedule tables manages the execution of the tasks. The time manager provides the network time for the schedule management.

Resource Manager

This module manages all the kernel objects used by the kernel threads, this include semaphore objects, TCBs, memory pools etc. The capabilities provided by the proposed MNM OS module allow the application tasks to create and manipulate structures such as tasks, semaphores, queues, messages, and timers.

Fault Manager

The fault manager is responsible for fault detection and management. In case of fail safe system the fault manager triggers the execution of the fail-safe algorithm and manages the system states. In failoperational configuration, this module is responsible for the faulty node detection algorithm and fault recovery mechanism.

Realization of the concept from automotive perspective

The concept was practically realized by building an automotive by-wire system. The system was realized using FlexRay communication protocol as communication backbone. The system was first designed using six nodes, two master nodes (Master and Redundant slave) and four actuator nodes. The Freescale S12X processor ® was selected for this. The Freescale MFR 4300 FlexRay controller ® was used as the communication interface. The multi processing features was addressed using Tiger SHARC processors from Analog Devices. Two processors were linked using the LVDS link to form a two-processor node. One Tiger SHARC processor was interfaced with MFR 4300 controller (memorymapped) for communication interface. The following sections describe the system that was used to prove the proposed MNM architecture.

By-wire Systems

A "by-wire" system refers to a control system that designed to replace the traditional mechanical or hydraulic linkages with electronic linkages. This bywire concept was originally adopted in the aerospace industry. But now by-wire technology has made its entry into the ground vehicles as well. Automotive by-wire includes three categories: throttle by-wire, steer by-wire (SBW), and brake by-wire (BBW). Consider a simple BBW system in a car. This consists of two brake pedal sensors and four brakeactuator nodes at the four wheels.

The Right-Front (R FRONT) and the Left-Rear (L REAR) actuator nodes accept the brake pedal pressure from one fail-silent brake pedal sensor. The Left-Front (L FRONT) and Right-Rear (R REAR) actuator nodes accept the brake pedal pressure from the other fail-silent brake pedal sensor.

R FRONT L FRONT R REAR L REAR

Figure 3:Brake by-wire system Every wheel node informs all other nodes about its view of the brake pedal sensors, performs a distributed algorithm to allocate the brake force to each wheel and controls the brake at its local wheel.

Brake by-wire system using MNM architecture

The system shown in Figure 3 was realized using the MNM architecture with focus on a centralized control centre with redundancy. This is represented in Figure 4. The control centre had two nodes with single processor each, which implements the braking control algorithms. One node in control centre acted as the master and the other node as the slave. The master and the slave control centres are connected to four simulated actuator nodes on a fault-tolerant communication network like FlexRay. Both the nodes in the control centre process the data acquired from the different actuator nodes through the communication network. The control actions to be taken are sent through the communication network, which are in turn used by the simulated actuator nodes.

Control Centre

The actuator nodes are configured to accept commands from only one node of the control centre and the commands from the other node are ignored. This makes use of adequate fault-tolerant redundancy mechanisms. Hence each node in the control centre will be a mirror of each other and keep a check on the other one in order to ensure the faulttolerance of the system.

Task Scheduler and Time Manager

The MNM scheduler was configured in a time triggered way with schedule tables to execute the feature tasks (braking force calculation, vehicle slip calculation and vehicle velocity calculation).

Communication Interface

FlexRay communication was used for network over which the messages are passed. The interface configures the bus for the wake-up, start-up and actives modes of operation. The two nodes of the control centre are configured as coldstart nodes.

Sender and Receiver

The Sender and Receiver handle two types of messages: data messages from the actuator nodes (for brake force information) and data messages to the actuator nodes containing control action information.

Communication Router

System messages are local and are handled by the LCH. The data messages are routed based on the whether it was internal message (vehicle velocity input for slip calculation task) or remote message (brake force for each actuator nodes).

Fault Manager

The control algorithm residing inside the control centre computes the required control force and commands the actuator nodes for actuation In case of a failure of one of the actuator nodes, the algorithm executes the intended function by redistributing the braking forces to the remaining functional actuators. The fault management module of the MNM can detect the fault from the fact that there is no braking force available at one of the actuators and can trigger the execution of the algorithm for the corrective procedure that is to be undertaken. The fault management module compares the states of the replicated control centre nodes Master and Slave. If the master fails, it is discarded and the Slave takes its place. The system employed for this node only focussed on the fail-safe behaviour. In order to provide enhanced fault tolerance, TMR may be adopted for the Control centre. The faulty unit could be recognized by the majority voting which would be removed from the system.

Multi processing using MNM architecture

The multi processing capability of the MNM architecture was also studied for the brake by-wire application.

The control centre had only one node with two processing units interconnected using LVDS link-port processor, which implements the braking control algorithms. One processing unit of control centre node is connected to four simulated actuator nodes on FlexRay network. This node processes the data acquired from the different actuator nodes through the communication network and executed vehicle slip calculation and vehicle velocity calculation tasks. The other processing unit was assigned with the braking force calculation. In this configuration MNM was handling both local and remote data and system messages. The system message was internal as well as external, since it is a multi processor realization of the control node. The MNM scheduler was configured in a time triggered way with schedule tables to execute the feature tasks in both the processing units of the node The system messages are of local and remote type.

The system messages were employed for synchronization of the tasks running on both the processing units as well as for passing the required data between the processing units. The braking force information was passed to the processing unit with FlexRay interface using system message and the same is transmitted to the actuator nodes as data messages.

The fault handling feature in this system was examined by simulating a failure in one of the brake actuators. Simulation of right front brake actuator failure results in no braking force at the right front wheel. So application of brake results in reduction of total braking force and the total deceleration below the desired values. The proper correction in the algorithm for the redistribution of braking forces was observed.

The system was studied using this configuration to analyse the MNM multi-processing configuration.

Using the LVDS link the two processing units performed as expected.

Realization of the concept from avionics perspective

Fly-by-wire has been a byword in the avionics field for a considerable period now. We attempt to show the architecture of a distributed system that implements a Flight Control System for an aircraft. The system was conceived and implemented with dual redundancy, and in hot standby mode, for the safety critical nodes. Triple modular redundancy was also employed in the areas of inertial sensor data acquisition. The major nodes in the system are the sensor nodes (like the Inertial Navigation unit and the Air Data system), the Flight Control Computer (FCC) for guidance and autopilot, the Actuator Control nodes. In addition the Display Controller node handles the Head Up Display system. Figure 5 shows the architecture of the Fly-by-wire system for flight control. Each node in this system employed two processors, one of these handling the link port and the other the number crunching and processing. The MIL-STD-1553B bus was used as the link between the various nodes. The deterministic nature of this time division multiplexed bus supports the hard real-time requirements of the system. Dual redundancy was achieved by duplicating the nodes, viz., by having two chains of operational nodes. Full node connectivity was provided in each chain and between chains cross-connectivity was provided.

In the system, tasks run with static fixed priorities, and follow definite periodicities. Each node was allotted a set of functions that it must execute within a deadline. Also, there exists a precedence relationship between tasks executed in the different nodes. A good example is that sensor data acquisition would need to precede the navigation task. Communication between the nodes via the 1553B bus also used a time-driven mechanism. The protocol itself supports destination id, data/command messages, as well as a parity check. Message integrity was enhanced by providing an application software layer over the protocol. This layer uses several message validation mechanisms like CRC checks, parity checks etc. for establishing fault free communication.

MNM support for fly-by-wire 4.1.1 Scheduler & Time Manager

The scheduler in each node maintains its Task Control Block (TCB) and the Time Manager triggers the execution of each task. For instance, the sensor Acquisition Node acquires information from the sensors, runs sensor-specific compensation algorithms and executes a voting algorithm for sensor data validation before communicating to the Flight Computer. In addition as low-priority task, the node also executed a periodic health check task. The MNM scheduler in these nodes checks that deadlines have been met, and when violated raises appropriate flags. Both local and remote messages are used in these nodes. Some nodes may operate solely on messages passed to them by the FCC. The MNM scheduler in such cases was event driven rather than time triggered. In order to support real-time execution of functions in the distributed architecture, tight synchronism among the various nodes was required. The Time Manager executes this function. Real time in each of the nodes is maintained by its own clock. To maintain synchronism among them special system messages are passed over the link ports and the relative skews among the nodes was brought down to the required levels by applying time correction.

Communication Interface

The system uses the MIL-STD-1553B bus for data and system message exchanges. Each node was configured to handle several types of messages corresponding to its functionality. They include the protocol defined BC-RT, RT-BC, RT-RT messages. In addition it also implemented the routing over the appropriate bus. For example, in the FCC it takes the form of accepting inputs from the sensor nodes in the two chains and of communicating control data to the actuator nodes.

Sender and Receiver

The Sender thread in the node, formats and stores the various messages. On receiving a request from another thread, say, the communication task in the TCB, it sends the message to the link interface. The Receiver thread receives messages from the link interface and routes it to the LCH for an internal command or to the RCH for an external command. For example, the sender in the FCC formats messages to all other nodes for system as well as data messages. Its MNM Receiver routes mostly to the LCH, however in some cases where data needs to be sent between two other nodes, then it would be routed to the RCH.

Communication Router

As explained in the earlier section, the FCC executes calls to both the RCH and the LCH. Several nodes in this system execute calls to the LCH only. Examples are the HUD and the actuator nodes, wherein the message is received from the FCC.

Fault manager and redundancy management

The distributed, dual redundant architecture was provided with enough connectivity to ensure that the overall function is executed even if one or several of the nodes develops a failure. To elaborate on this, two nodes are employed for carrying out the functions of the Air Data system: viz., calculating parameters like altitude, altitude rates, airspeed, etc using data from the air-pressure sensors. The information from these nodes is sent to both the Flight Control nodes as inputs. Even if one of the Air Data systems were to fail, connectivity is such that both the FCCs would still be provided with valid data. This kind of architecture ensures that the system meets the high reliability figures demanded. The fault manager in the node has the task of identifying any system faults and containing them as far as possible. Several software schemes like maintaining recovery blocks, or multiple data copies are resorted to for fault containment. If successful, these ensure that the system functions in its primary mode, thereby guaranteeing full function execution. If the fault is such that this is not possible, then the fault manager indicates its fault to the other nodes. In this case, the overall MNM architecture is organised to re-configure the system so that full function is executed as far as possible. In the event that this is also not possible, the MNM then resorts to falling back to a salvage mode of operation wherein the node supports enough functionality for a safe operation. The overall architecture thus supported a tightly synchronised fault tolerant distributed system and was highly flexible, amenable to any kind of avionics system. The MNM architecture also supported a hierarchical tree structure for the communication link, making it possible to include other systems like display and recording systems. Validation of such a distributed system was a challenging task, but the MNM architecture enables the software architecture to be validated easily. The main reason for this is that the software components across nodes are common.

5. Advantages of the architecture MNM is a comprehensive architecture to utilize the power of multi processor systems and high-speed fault tolerant communication protocols, in implementing a distributed computing platform for next generation of vehicles. MNM can cater to the requirements of distributed computing. Multi processing nodes with high processing power can reduce the number of computing nodes. With the computational power of multi processor systems the number existing nodes can be drastically reduced. This can be achieved by developing fewer computational nodes (High load centres), which are connected to the actuator/sensor nodes (Low load centres) through a high-speed communication network. This concept simplifies the testing and diagnostics requirements by virtue of its distributed nature. Providing hardware redundancy can be treated merely as an extension to the distributed architecture, which in turn improves reliability. The other important features of this concept are composability and extensibility. Addition of a node to provide a new feature or to implement a new algorithm is achieved in a cost effective manner and with less effort. These features are attractive both in the avionics as well as the automotive space. This concept improves the verification and validation procedures, by allowing more standardized procedures, effectively reducing the development cycle time. Actuator/sensor nodes need only ECUs of lesser computational capabilities. Hence the attempt to employ redundancy at the input/output ends becomes very much cost effective. Also, having both processor and sensor capabilities on the same chip would result in greater expense. The centralized approach can lead to the scenario where sensors and actuators are separated from the controllers processing the algorithms. This in turn will increase the yield of the discrete sensor and actuator ICs. This brings about reasonable advantages from the chip design and fabrication point as well. As the number of computing nodes increases, the effort required for software configuration management increases significantly. From the software configuration management perspective reduction in the number of computing nodes makes it easier to maintain the integrity of the system. In distributed architecture certain nodes will be not utilizing the system resources to full extent. The MNM can be used to design a centralized computing scheme to utilize the full capabilities of the computing platform. This concept also reduces the amount of redundant code that goes into system.

All computing nodes make use of basic software layer (MNM and drivers), which is functionally common for all. The basic software component can be a licensed software component that comes from a vendor. Reducing the number of nodes can reduce the license fee for these basic software components that make a node. Another advantage of this concept is the reduction in bus communication, since the implementations of the different sub-systems are in the same computational centre. The signals required for these sub-systems can be implemented as local data messages. The local data messages can improve the deterministic nature of the system, which is an important characteristic of active safety systems.

6. Limitations It is challenging to convince the users the applications of proposed framework. Carmakers will have to find ways to make the users feel that such systems are equally desirable. Multi processing techniques and communication protocol like FlexRay is yet to be qualified in extreme environment conditions. The suggested architecture is not drawn in line with any existing standards. In automotive domain emerging framework like AUTOSAR address distributed computing and the required software infra structure to implement this. But AUTOSAR currently does not address multi processing and safety features. The proposed architecture can be used to complement such standards to address symmetric multiprocessing and safety features.

Conclusion

The discussed architecture can address processing using multiple processors to multi tasking using a single processor. The architecture also takes into account the requirements of connectivity, which is vital for distributed computing from a vehicle perspective. Currently the multi processing is envisaged using high-speed link-ports and shared memory, but in future the communication network protocol can support high data rates. This enables the usage of such networks for multi processing thus avoiding current high-speed processor link mechanisms. The MNM architecture is designed in a way to address this, since it is independent of the underlying physical connection scheme employed for multi processing.

The volume of software that goes into a vehicle is enormous. Hence the software that goes into the system will determine the major share of the vehicle cost. The MNM architecture is a unique framework that can address multi processing control centres with low computational power actuator/sensor interconnected using a standard bus communication protocol. This approach as discussed can reduce the software components that go into the vehicle when compared with pure distributed computing. This will avoid duplicating the same software components in different nodes. This could reduce the total software license costs too. Hence this paper presents a novel approach for cost-effectiveness in automotive and avionics domain in future.

Glossary

Figure 1 :

 1 Figure 1: Multi Node Software Framework

Figure 2 :

 2 Figure 2: Multi Node Management Modules

Figure 4 :

 4 Figure 4: Brake by wire (Control Centre and Actuator nodes)The control centre had two nodes with single processor each, which implements the braking control algorithms. One node in control centre acted

Figure 5 .

 5 Figure 5. Fly by wire Flight Control SystemCommunication between the nodes via the 1553B bus also used a time-driven mechanism. The protocol itself supports destination id, data/command messages, as well as a parity check. Message integrity was enhanced by providing an application software layer over the protocol. This layer uses several message validation mechanisms like CRC checks, parity checks etc. for establishing fault free communication.4.1 MNM support for fly-by-wire 4.1.1 Scheduler & Time ManagerThe scheduler in each node maintains its Task Control Block (TCB) and the Time Manager triggers the execution of each task. For instance, the sensor Acquisition Node acquires information from the sensors, runs sensor-specific compensation algorithms and executes a voting algorithm for sensor data validation before communicating to the Flight Computer. In addition as low-priority task, the node also executed a periodic health check task. The MNM scheduler in these nodes checks that deadlines have been met, and when violated raises appropriate flags. Both local and remote messages are used in these nodes. Some nodes may operate solely on messages passed to them by the FCC. The MNM scheduler in such cases was event driven rather than time triggered. In order to support real-time execution of functions in the distributed architecture, tight synchronism among the various nodes was required. The Time Manager executes this function. Real time in each of the nodes is maintained by its own clock. To maintain synchronism among them special system messages are passed over the link ports and the relative skews among the nodes was brought down to the required levels by applying time correction.4.1.2 Communication InterfaceThe system uses the MIL-STD-1553B bus for data and system message exchanges. Each node was configured to handle several types of messages corresponding to its functionality. They include the protocol defined BC-RT, RT-BC, RT-RT messages. In addition it also implemented the routing over the appropriate bus. For example, in the FCC it takes the form of accepting inputs from the sensor nodes in the two chains and of communicating control data to the actuator nodes.4.1.3 Sender and ReceiverThe Sender thread in the node, formats and stores the various messages. On receiving a request from another thread, say, the communication task in the TCB, it sends the message to the link interface. The Receiver thread receives messages from the link

MNM Framew ork Link Driver(Link-port/Shared Memory) Comm unication Driver(CAN/ FlexRay) Link Interface Sender Receiver Scheduler Fault Manager Re m ote Com m and Handler Local Com m and Handler Communication Router Data Copy Handler Tim e Manager Resource Manager

Acknowledgement

This work is supported by TATA ELXSI IP development programme. The authors would like to thank the management for supporting their work and for stimulating discussions.


Ingo Stürmer

Certification of Model-based Code Generators -Open Problems and Possible Solutions

Keywords: Tool certification, qualification, modelbased development, test suite, guidelines, checks

Model-based development and automatic code generation have become an established approach in embedded software development for both the automotive and avionics sectors. The use of a code generator can lead to significant improvements in productivity in the software implementation phase. Moreover, early quality assurance at the model level can lead to a higher level of code quality. However, automotive or avionic software is very often deployed in safety-critical systems and as a result, may not contain errors. In this context it is crucial that the use of a code generator and its tool chain (editor, compiler, linker, loader, etc.) does not incorporate errors in the target system and leave them undetected. In general, this cannot be fully avoided even when using a code generator proven to be 'correct-by-construction'. Inappropriate modeling or the faulty configuration of the code generator could, for example, lead to erroneous generated code. This paper discusses how code generators and generated code can be safeguarded by means of tool certification (also termed qualification in the avionics sector) in respect to safety standards that are relevant for the automotive and avionics sectors. Specific, toolrelated problems will be discussed and illustrated with practice-relevant examples; possible solutions for safeguarding model-based code generators will be presented.

Model-based Code Generation

In model-based development (MBD), the seamless use of executable models is characteristic of function and control system design and the subsequent implementation phase. This means that models are used throughout entire control system development: from the preliminaries to the detailed design. Such models are designed using popular graphic modeling languages, such as Simulink and Stateflow from The MathWorks [1]. In the first design stage, a physical model is created, which is derived from the requirements specification (see Fig. 1). The physical model describes the behavior of the control function to be developed, containing transformation algorithms related to continuous input signals as well as incoming events or states. These algorithms are usually described using floating-point arithmetic. Since the physical model focuses on the design of the control function and on checking its functional behavior with regard to the stated requirements, it cannot serve directly as a basis for production code creation. Implementation details, which are the prerequisite for automatic coding, are not considered here. Therefore the physical model needs to be manually revised by implementation experts with regard to the requirements of the production code (e.g. function parts are distributed between different tasks). For example, in order to enhance the model from a realization point of view, the floating-point arithmetic contained in the physical model is adjusted to the fixed-point arithmetic used by the target processor. If fixed-point arithmetic is used, the model must be augmented with necessary scaling information in order to keep imprecision in the representation of fixed-point numbers as low as possible. Apart from the change in the type of arithmetic, it may be necessary to substitute certain model elements that are not part of the language subset supported by a particular code generator. Furthermore, it is often necessary to restructure the behavioral model with regard to a planned software design. The result of this evolutionary reworking of the physical model is what we call an implementation model. The implementation model can be used as a basis for (A) manual coding by a software developer (not shown in Fig. 1), or (B) automatic code generation with a code generator (see Fig. 1). The implementation model contains all the information that is needed for code generation and enables the creation of efficient C code by the code generator. Code efficiency is vital, due to the limited resources of the embedded system running the generated code. Code generators that are capable of translating MATLAB Simulink and Stateflow models into efficient production code include TargetLink [START_REF]TargetLink 1.3p2: Production Code Generator[END_REF] 1 and the Real-Time Workshop/Embedded Coder [1]. Depending on the development stage and purpose, the code is generated for the development computer, in most cases a standard PC (Fig. 1, right). In this case, a classical compiler / linker combination is used to translate the generated code into an executable. For the target hardware (typically an evaluation board similar to the embedded system), a cross-compiler is required. Here a linker and loader build and load the binary code onto the embedded device. The tool chain established by the modeling tool (editor and simulator), the tools for model-tocode translation (e.g. code generator, (cross-) compiler, linker, loader), and finally the target hardware itself make up the code generation tool chain (Fig. 1). Individual studies have shown a reduction in software development time by up to 20% through code generation [START_REF] Ueda | Trends of Future Powertrain Development and the Evolution of Powertrain Control Systems[END_REF]. If the manual verification process at the code level can also be reduced, savings of up to 50% are reported. This conforms with internal information provided by other users. In summary, productivity can increase by up to 50% compared with traditional manual coding. Moreover, the level of quality gained by early quality assurance at the model level can lead to high quality code, provided that the code generator works reliably. As a result of these characteristics, there is a strong industrial demand for code generators. Some people still express reservations about using a code generator for safety-related software development. This may be due to the fact that code generators are not as mature as established C or ADA compilers. The technological risk of a code generator can be high, because they (1) are used by a relatively small group of developers, and (2) face a high rate of technological innovation causing new versions to appear in short cycles. As a result, formal proof of code generator correctness is unfeasible in practice. For this reason, productivity improvements that can be achieved with model-based code generation tools cannot be fully exploited. The generated code must still be checked with the same time and cost-intensive effort as manually written code, even though intensive quality measures have already been spent on the model. A survey of quality assurance methods for model-based development with code generation is provided in [START_REF] Stürmer | Overview of Existing Safeguarding Techniques for Automatically Generated Code[END_REF]. Model-based code generation is a new paradigm that makes new demands on the development process and poses additional questions concerning the certification of systems. An important and generally accepted approach for increasing confidence in code generation is to use a certified or qualified code generator. Apart from correctness aspects, there are many benefits to be expected from using a certified code generator: • Higher quality of generated code (number of errors, readability, traceability) in comparison to manual code. • Consistent level of code quality.

• Consistency between specification and software.

• Reusability of executable specifications in subsequent projects. • Internal development of software in organizations / departments with an insufficient number of implementation specialists.

• More efficient realization of the implementation phase in software development. Code generation relies on software that can obviously never be completely free from faults or errors. This is the main reason for the ongoing debate regarding the use of code generation for safety-related systems. However, the use of code generators is recommended from the point of view of the development process, and there is some advice to be found in the different safety standards (elaborated in Chapter 4). We will, however, first focus on specific model design problems, which directly influence the quality of the code generated from the implementation model.

Problems with Model-based Code Generation

There are many sources of error that can be identified within the model-based code generation process. One example are design errors, which are caused by inappropriate design of the (physical) model with respect to its functional requirements or due to misunderstandings regarding the semantics of the modeling language (a survey on all possible errors in the model-based code generation tool chain is provided in [START_REF] Fey | Quality Assurance Methods for Model-based Development: A Survey and Assessment[END_REF]). The misuse or misunderstanding of a modeling language used for code generation will be discussed next. The following two realizations of a buzzer exemplify the need for quality assurance methods on the model design level. The first realization (Figure 2) was created at an early development stage of a typical embedded software development project for an automotive system. The model contains several problems that are not obvious at first glance (especially for flowchart novices). However, the two possible and semantically comparable realizations of a buzzer are presented in Figure 2 After t_tON the flag is turned back to false (0). The buzzer beeps three times. In variant A, which was created at an early development stage of the project, the buzzer is realized as a flowchart diagram that typically consists of transitions and connective junctions. A connective junction defines a decision point between possible paths of a transition, whereas a transition can bear a complex label for checking specific conditions (e.g. runs > 0) and for performing actions (e.g. counter++;). This modeling paradigm is comparable to if-then-else control structures used in e.g. C. The appropriate use of flowcharts for automatic controller code implementation often produces efficient C code with little overhead. Modeling with flowcharts, however, allows quasi free C code programming. The assignments in the curly braces, for example, can contain an arbitrary number of C statements. As a consequence, classical programming errors can occur, such as the faulty use of a bitwise AND (&) instead of a logical one (&&). Such human sources of error are often neglected or underestimated in the literature, e.g. [START_REF] Edwards | The Use of Automatic Code Generation Tools in the Development of Safety-Related Embedded Systems[END_REF]. Inappropriate modeling must be considered as an additional error source. Timing behavior, for example, such as the fractions of time the buzzer is activated or disabled, is realized by incrementing the local counter variable. This kind of modeling temporal behavior is often used by Stateflow novices. However, when using the model for production code generation, such modeling of temporal behavior implies intrinsic errors. Timing is no longer independent of the processor's execution speed or the time for computations assigned by the operating system respectively. In variant A, the flowchart realization of the buzzer is more technical rather than intuitive, since the functionality of the buzzer is, in principle, state-based. Essentially, the expected improvements in efficiency on the code level are largely compensated for by the aforementioned disadvantages. The realization of the buzzer as a Stateflow state machine (Figure 3) is easier to understand intuitively. In variant B, temporal behavior is modeled by using Stateflow's after operator, which allows a precise definition of how long a state is activated, e.g. when the transition from state On to Off is executed. Timing is 'incremented' by using the Stateflow CLK event. In doing so, timing is independent of the processor's execution speed or resource allocations of the operating system. In contrast to variant A, this variant is easier to parameterize (e.g. for double beeps). In summary, we can see that on the one hand, modeling by using states and events increases the understandability and readability of the model, while on the other hand, the use of states and events is problematic in projects where resource consumption (e.g. required RAM/ROM size) is of decisive importance, since both produce a large overhead.

For the reasons stated above, a compromise between understandable modeling and code efficiency must be found. Modeling guidelines must clarify the advantages and disadvantages of different modeling techniques and patterns. It is also advisable to use a 'safe-subset' of the modeling language in order to prevent problematic patterns in generated code, which cannot be fully avoided even when using a code generator that is considered to be 'correct-byconstruction'. An example for this statement is given next. As we can see, the code generator generated a correct, but not optimized, code pattern that identically reflects the behavior of the model. Only analytical quality assurance methods on code level, e.g. structural testing or a code review, can detect such problematic patterns on code level. This means that even having a correct or certified code generator does not imply that quality assurance methods on code level can be fully omitted. A typical solution to prevent the use of such modeling patterns is the application of modeling guidelines and checking the models with regard to modeling guideline compliancy (elaborated in Chapter 5.2).

Code Generation for Safety-related Systems

The trend towards increasing model-based application development also extends to safetyrelevant systems. However, more stringent developmental requirements must be fulfilled if such systems should be subject to certification. The principal expectation is that the methods used to design the system are all state-of-the-art, thus everything possible has been done to ensure that safety is guaranteed. General requirements on the development of safety-related systems are usually summarized in standards, such as DO-178B for avionic software, or IEC 61508 for E/E systems. In addition to providing certification of the system under development, these standards serve to define more or less specific demands for using specific tools for automating development steps. Both software tools and development tool chains offer potential sources of error. Normally errors produced by development tools have no direct influence on the product itself. However, this is not the case for tools like compilers and code generators. When developing safety-relevant systems, it is particularly important to ensure that the use of a code generator and its tool chain (editor, compiler, linker, loader, etc.) does not incorporate errors into the target system and leave them Figure 5: Code pattern generated from Figure 4 undetected. Certification institutions therefore never certify source code on its own, but only in connection with the corresponding machine codes and usually when integrated in the whole system.

Advantages of Code Generator Certification

This is not sufficient reason to dispense with code generation in the first place. Other reasons, especially those relating to process improvement and development efficiency, underscore the need for qualified code generators: 1. We are faced with continual tool improvement: this means a high rate of updates, since code generation for production is a relatively new technology. 2. Taking this into account, the generated output of the tool has to be checked with the same timeconsuming effort as code that has been written manually, even though the types of errors produced by code generation are completely different to those found in manual coding.

This drastically reduces potential improvements

in productivity that can be brought about by automatic code generation. In general, the qualification of a software tool has the objective of compiling evidence of the tool's highquality output, thus ensuring the use of the tool in the development of systems with safety-related aspects. Advantages that can be expected from the application of a qualified code generator, provided that a 'safe subset' of the modeling language is used(!), are as follows:

• Decreased overall effort spent on verification and validation activities, e.g. (a) eliminating source code reviews for generated code parts, and (b) eliminating or minimizing the effort needed for unit testing. • Improved productivity of software development, especially in the software implementation phase. • Ensuring the controllability of rapid iterations in development.

• Consistent or higher code quality despite the aforementioned points. How should we therefore safeguard the deployment of a code generator in the model-based development process? In such a way that allows errors induced into the development product to be discovered or completely circumvented, without resulting in a considerable reduction in efficiency of the development process. This is answered in part by existing safety standards, such as IEC 61508 [START_REF]Functional Safety of Electrical /Electronic/Programmable Electronic Safety-Related Systems[END_REF] and DO-178B [START_REF]Software Considerations in Airborne Systems and Equipment Certification[END_REF]. However since additional measures should be considered for safeguarding code generation, this is discussed in the next chapter.

Safety Standards Applicable for Tool Certification

The various applicable safety standards that we use today were published some time ago, so they give no explicit guidance for the application of modelbased development and the utilization of code generation. Future versions such as RTCA/DO-178C will be expanded with respect to this development paradigm. In any case, the general requirements with respect to product certification or development tool qualification can be adopted. The latter aspect is of major interest here. 4.1 RTCA/DO-178B RTCA/DO-178B (Software Considerations in Airborne Systems and Equipment Certification Requirements) is an international standard, which is mandatory in all avionic software development. This standard focuses on the software development process. The qualification of a development tool can be handled in a similar way to the certification of the application software itself. In other words, qualifying a development tool such as a code generator does not mean proving its correctness. Instead, it is merely important to gain sufficient confidence in its correctness. In this context, the prerequisite for qualification is an assessment, which shows the conformance of the tool development process with the development requirements of the standard. Tool qualification is closely connected to the development and certification of a system and its criticality. This means that a tool that is issued with all its development documents in conformity with the standard could be seen as a qualifiable tool.

IEC 61508

The International Electrotechnical Commission (IEC) has submitted the international safety standard IEC 61508 [START_REF]Functional Safety of Electrical /Electronic/Programmable Electronic Safety-Related Systems[END_REF], which is primarily concerned with safety-related control systems incorporating electrical / electronic / programmable electronic safety-related systems (E/E/PES). It also provides a framework, which is applicable to safety-related systems, irrespective of the technology on which those systems are based (e.g. mechanical, hydraulic, or pneumatic). For specific demands, the standard has been adapted to a particular industry as is currently the case in the automotive industry for certifying safety-related (software-based) E/E/EPS parts. In the context of IEC 61508, only compilers (translators) have so far been regularly subject to tool certification procedures. Compilers are assessed in two different ways: (1) the compiler or translator is certified against its respective language or process standards, (2) compilers or translators are assessed by their increased confidence from use (fitness for purpose). In general, however, compilers are not certified in any way with regard to safety2 .

Examples of tool Certification w.r.t. Safety Standards

Qualifiable code generators w.r.t. DO-178B, such as SCADE, which endorse a certification of the application software, do exist. They make it possible to reduce the total amount of the verification activities, without allowing them all to be omitted completely. However, their source language is not as popular as Simulink / Stateflow, and they perform only a limited number of optimizations. The latter is crucial for the automotive sector, where developers must deal with strict resource limitations ASCET-SD [LBB+97], developed by ETAS, is the first code generator for automotive embedded control systems that is certified as being fit for its purpose for SIL 3 according to IEC 61508 [START_REF] Junker | Guaranteed Product Safety According to the IEC 61508 Standard[END_REF]. To gain this certificate, TÜV inspectors performed an indepth analysis of the ETAS tool chain to understand the purpose of its use and the tool's development process. Based on this knowledge, the inspectors created a test plan according to IEC 61508 SIL 3. This test plan aims to access the 'fitness for purpose' of the code generator and includes, for example, formal characteristics of the documentation, software requirements specification, the test as part of design, development and integration, verification and validation (V&V). Following this test plan, the tool developer could show, for instance, "the existence of conclusive evidence for correct code generation."

Possible Solutions for Code Generator Certification

Certification authorities such as the technical supervisory agencies TÜV (Technischer Überwachungsverein / German Technical Inspection Authority) or the British Standards Institution generally consider the qualification of an optimizing compiler for safety-relevant software as sophisticated. On one hand, it is a particularly complex tool and on the other, its behavior when applied to optimizations cannot be clearly comprehended. Code generators can be viewed in the same way, since the main focus of their work is on code optimization, at least in automotive applications. Moreover, code generators are not as mature as established compilers, which have been proven to be reliable in use and whose correct functioning is constantly validated by numerous programmers. Challenges from the tool supplier and the development management point of view are as follows:

• At present, insufficient regulations and a lack of common rules for tool qualification hinder the tool supplier in defining an approved, long-term validation strategy. • A prerequisite for a valid qualification process is that all development information must be available. However, tool suppliers are usually unwilling to make their internal know-how public. • The focus of a tool supplier's work is on the development itself and not on qualification procedures. • The qualification procedure is conducted for a particular tool. This means that qualifying a code generator does not consider the compiler, linker, etc. These tools either need to be qualified themselves or their results have to be checked manually each time they are used. • The costs of a qualification procedure are fairly high, at least when following the RTCA DO-178B approach. Considering the aforementioned qualification issues, there is obviously a need to define different approaches to efficiently safeguard code generation. 5.1. Code Generator Certification via a Test Suite Since the use case of code generators is quite similar to that of compilers, it could be helpful to adapt the current practice for compiler validation. The utilization of test suites for the certification of compilers has been proven in use for Ada and C compilers. Although this does not fulfill the qualification requirements stipulated in DO-178B, it appears to be an efficient way of facilitating sufficient compliance with quality and reliability requirements. A general approach for validating a code generator (including examples) is documented in [START_REF] Stürmer | Systematic Testing of Model-based Code Generators[END_REF]. This approach could be used, for example, to generate those parts of such a test suite, which focus on optimization criteria. An important initiative of automotive manufacturers and suppliers are currently working on a test suite for code generators, see [START_REF] Beine | Quality Assurance Aspects and Activities in Automotive Model-based Development[END_REF]. The advantages of utilizing a test suite as a qualification approach for code generators are as follows:

• Cost-effective qualification and validation approach. • Modification and patches of the tool can be handled; 'Delta Certificates' can be assessed more easily and at lower cost compared to a complete qualification. • The input language of the code generator must not necessarily be considered completely. A subset can be defined and incrementally expanded. • A common view of the content and application of the test suite could emerge. At least if the major constraints and a basic set of tests become public and even standardized. 5.2. Use of a 'Safe Subset' IEC 61508-3, for example, highly recommends the use of a language subset for software development in accordance with SIL3 and SIL4. However, since IEC 61508 was written with traditional, (hand-coded) software development processes in mind, the standard does not cover advanced embedded software development technologies such as modelbased design and production code generation. A "safe subset" for modeling languages such as Simulink or Stateflow is often defined in general accepted model design guidelines such as those defined by the MathWorks Automtoive Advisory Board [START_REF]Control Algorithm Modeling Guidelines Using MATLAB, Simulink, and Stateflow[END_REF]. However, the MAAB guidelines do not directly address model patterns for code generators. Publicly available guidelines such as the MAAB guidelines are often supplemented by in-house sets of modeling guidelines, for example the Daimler Model-based Development Guidelines [START_REF]Daimler Model-based Development Guidelines[END_REF]. These are are hosted via the e-Guidelines Server [16], a web-based infrastructure for publishing and centrally administering different sets of guidelines. The Daimler guidelines provide a sound basis for checking the models used for production code generation. The adoption of such guidelines can significantly improve the efficiency of generated code. Apart from having guidelines for model-based development available, it is also important to check and ideally repair models with regard to guideline compliancy automatically. Static model analysis tools exist for the automatic verification of models with respect to modeling guideline compliancy. The purpose of these tools is to establish a framework in which to perform checks. The check itself is a program that verifies a particular guideline. Commercial static model analysis tools that are available for MATLAB Simulink, Stateflow, and TargetLink models are the Simulink Model Advisor [START_REF]Simulink Model Advisor[END_REF], MINT [START_REF] Ricardo | MINT[END_REF], or the Model Examiner (M-XAM) [START_REF]The Model Examiner M-XAM[END_REF]. With such tools, model analysis is carried out by executing a selection of MATLAB M-scripts. The checks either come with the tool or can be supplemented as user-written checks. The results of model verification using the checks are compiled into reports. These show all detected guideline violations linked to the model. In a final step, the faulty model patterns must be investigated and, where necessary, corrected by the developer: a highly time-intensive and error-prone task. Case Studies have shown, that this task can be significantly reduced up to 50% by using automatic model repair functionality with tools such as the Model Examiner or MATE [START_REF] Ameluxen | Checking and Enforcement of Modeling Guidelines with Graph Transformations[END_REF]. Up to 90% of model rework with regard to modeling guidelines compliancy can be saved by using automatic repair functions with user feedback (so far only available with tool such as MATE). Advantages of using and enforcing modeling guidelines for production code generation are:

• Deveopers can built upon expert know-how proven to be feasible in practice • It is ensured that a safe subset of the modeling language is used • Increase comprehensibility (readability) of a model • Facilitate maintenance • Ease testing, reuse, and expandability • Simplify the exchange of models between OEMs and suppliers

Code Generation in Practice

Model-based development of automotive applications has proved its effectiveness over the last 10 to 15 years. Furthermore, the utilization of code generation has begun to become established for series production in conjunction with the further development of optimizing code generators. Although the use of code generation appears natural in model-based development, project experience has shown that it cannot be considered a pure 'push button' approach; rather the whole development process has to be adjusted towards the aim of production code generation. This starts with the availability of appropriate modeling and design guidelines as well as company and project-specific guidelines, and ends with sophisticated quality assurance measures, cf. [START_REF] Fey | Quality Assurance Methods for Model-based Development: A Survey and Assessment[END_REF]. Two major aspects must be taken into account when moving towards production code generation:

• A consummate physical model is not necessarily an implementation model suitable for code generation. However, the physical model usually matches the structure of the specification of the function to be implemented. • Code safety/efficiency is strongly dependent on the use of appropriate modeling constructs. Thus, a conflict between comprehensibility and code efficiency arises. In practice, a compromise between both important aspects must be found in each specific project. Essentially, experts who are skilled with respect to the modeling paradigm are required. The influence of their knowledge on the quality of developed code is comparable to the influence of the programmer's experience in code-based development. Overheads of generated code compared with manual code are usually caused by improper modeling or incorrect configuration of the code generator. As a result, the application of code generation for safety-critical systems is a feasible option, even when there is no general means of qualification at hand.

Conclusions

Since model-based development began to become widespread in the application development of different automotive domains, code generation has become more and more common. This trend has thrown up a number of questions, which address the whole application development, especially when safety-critical systems are under development. More specifically, we are faced with the question as to whether tools used for automating manual transformation work need to be qualified or somehow validated in accordance with a defined procedure. At present, safety standards like DO-178B only request this if a verification of the generated results is omitted. The definition of a dedicated test suite for code generator validation in combination with the use and enforcement of a safe subset for model design appears another promising approach. In any case, it is reasonable to implement further measures to safeguard code generation. The main challenge facing the use of code generation is not qualification of the tool, but still a combination of process adoption and project member training.

Figure 1 :

 1 Figure 1: Model-based code generation Model-based code generation is one of the principal advantages of model-based development. The use of a code generator leads to significant productivity improvements in the software implementation phase.Individual studies have shown a reduction in software development time by up to 20% through code generation[START_REF] Ueda | Trends of Future Powertrain Development and the Evolution of Powertrain Control Systems[END_REF]. If the manual verification process at the code level can also be reduced, savings of up to 50% are reported. This conforms with internal information provided by other users. In summary, productivity can increase by up to 50% compared with traditional manual coding. Moreover, the level of quality gained by early quality assurance at the model level can lead to high quality code, provided that the code generator works reliably. As a result of these characteristics, there is a strong industrial demand for code generators. Some people still express reservations about using a code generator for safety-related software development. This may be due to the fact that code generators are not as mature as established C or ADA compilers. The technological risk of a code generator can be high, because they (1) are used by a relatively small group of developers, and (2) face a high rate of technological innovation causing new versions to appear in short cycles. As a result, formal proof of code generator correctness is unfeasible in practice. For this reason, productivity improvements that can be achieved with model-based code generation tools cannot be fully exploited. The generated code must still be checked with the same time and cost-intensive effort as manually written

Example 1 Figure 2 :

 12 Figure 2: Buzzer realized as a flowchart (variant A)

  (flowchart, variant A) and Figure 3 (Stateflow, variant B). The generation of an acoustic warning (beep) is controlled by the flag BEEP_flag_beep. When initially activated, the flag for beep activation BEEP_flag_buzzer is turned to true (1) during t_tON.

Figure 3 :

 3 Figure 3: Buzzer realized in Stateflow (variant B)

Example 2 Figure 4 :

 24 Figure 4: Stateflow chart with potential 'dead' transition path Figure 4 shows a simplified detail of a complex Stateflow chart. This chart consists of 2 super states (A and B) as well as two sub-states (B1. and B.2). There are several transition paths originating from state A. One path goes from state A to sub-state B.2 (highlighted with a red dashed line). Within this pathway, two conditions are checked whether the condition flag equals two. At first glance, this way of modeling a control flow does not seem problematic. But a correct code generator translates the pattern shown in Figure 4 into the code pattern shown in Figure 5.

TargetLink uses its own graphical notation for code generation (TargetLink blockset), which is based on the Simulink modeling language.

[START_REF]Functional Safety of Electrical /Electronic/Programmable Electronic Safety-Related Systems[END_REF], part 7, Appendix C4.3