Safely Embedded Software for State Machines in Automotive Applications

Currently, both fail safe and fail operational architectures are based on hardware redundancy in automotive embedded systems. In contrast to this approach, safety is either a result of diverse software channels or of one channel of specifically coded software within the framework of Safely Embedded Software. Product costs are reduced and flexibility is increased. The overall concept is inspired by the well-known Vital Coded Processor approach. There the transformation of variables constitutes an (AN+B)-code with prime factor A and offset B, where B contains a static signature for each variable and a dynamic signature for each program cycle. Operations are transformed accordingly.


Introduction
Currently, both fail safe and fail operational architectures are based on hardware redundancy in automotive embedded systems.In contrast to this approach, safety is either a result of diverse software channels or of one channel of specifically coded software within the framework of Safely Embedded Software.Product costs are reduced and flexibility is increased.The overall concept is inspired by the well-known Vital Coded Processor approach.There the transformation of variables constitutes an (AN+B)-code with prime factor A and offset B, where B contains a static signature for each variable and a dynamic signature for each program cycle.Operations are transformed accordingly.
Mealy state machines are frequently used in embedded automotive systems.The given Safely Embedded Software approach generates the safety of the overall system in the level of the application software, is realized in the high level programming language C, and is evaluated for Mealy state machines with acceptable overhead.An outline of the comprehensive safety architecture is given.
The importance of the non-functional requirement safety is more and more recognized in the automotive industry and therewith in the automotive embedded systems area.There are two safety categories to be distinguished in automotive systems: • The goal of active safety is to prevent accidents.Typical examples are Electronic Stability Control (ESC), Lane Departure Warning System (LDWS), Adaptive Cruise Control (ACC), and Anti-lock Braking System (ABS).
• If an accident cannot be prevented, measures of passive safety will react.They act jointly in order to minimize human damage.For instance, the collaboration of safety means such as front, side, curtain, and knee airbags reduce the risk tremendously.
Each safety system is usually controlled by the so called Electronic Control Unit (ECU).In contrast to functions without a relation to safety, the execution of safety-related functions on an ECU-like device necessitates additional considerations and efforts.
The normative regulations of the generic industrial safety standard IEC 61508 (IEC61508, 1998) can be applied to automotive safety functions as well.Independently of its official present and future status in automotive industry, it provides helpful advice for design and development.
In the future, the automotive safety standard ISO/WD 26262 will be available.In general, based on the safety standards, a hazard and risk graph analysis (cf.e. g. (Braband, 2005)) of a given system determines the safety integrity level of the considered system functions.The detailed safety analysis is supported by tools and graphical representations as in the domain of Fault Tree Analysis (FTA) (Meyna, 2003) and Failure Modes, Effects, and Diagnosis Analysis (FMEDA) (Boersoek, 2007;Meyna, 2003).
The required hardware and software architectures depend on the required safety integrity level.At present, safety systems are mainly realized by means of hardware redundant elements in automotive embedded systems (Schaueffele, 2004).
In this chapter, the concept of Safely Embedded Software (SES) is proposed.This concept is capable to reduce redundancy in hardware by adding diverse redundancy in software, i.e. by specific coding of data and instructions.Safely Embedded Software enables the proof of safety properties and fulfills the condition of single fault detection (Douglass, 2011;Ehrenberger, 2002).In a recently published generic safety architecture approach for automotive embedded systems (Mottok, 2006), safety-critical and safety-related software components are encapsulated in the application software layer.There the overall open system architecture consists of an application software, a middleware referred to as Runtime-Environment, a basic software, and an operating system according to e. g.AUTOSAR (AUTOSAR, 2011;Tarabbia, 2005).A safety certification of the safety-critical and the safety-related components based on the Safely Embedded Software approach is possible independently of the type of underlying layers.Therefore, a sufficiently safe fault detection for data and operations is necessary in this layer.It is efficiently realized by means of Safely Embedded Software, developed by the authors.
The chapter is organized as follows: An overview of related work is described in Section 2. In Section 3, the Safely Embedded Software Approach is explained.Coding of data, arithmetic operations and logical operations is derived and presented.Safety code weaving applies these coding techniques in the high level programming language C as described in Section 4. A case study with a Simplified Sensor Actuator State Machine is discussed in Section 5. Conclusions and statements about necessary future work are given in Section 6.

Related work
In 1989, the Vital Coded Processor (Forin, 1989) was published as an approach to design typically used operators and to process and compute vital data with non-redundant hardware and software.One of the first realizations of this technique has been applied to trains for the metro A line in Paris.The Vital technique proposes a data mapping transformation also referred to in this chapter.The Vital transformation for generating diverse coded data x c can be roughly described by multiplication of a date x f with a prime factor A such that x c = A * x f holds.The prime A determines the error detection probability, or residual error probability, respectively, of the system.Furthermore, an additive modification by a static signature for each variable B x and a dynamic signature for each program cycle D lead finally to the code of the type x c = A * x f + B x + D. The hardware consists of a single microprocessor, the so called Coded Monoprocessor, an additional dynamic controller, and a logical input/output interface.
The dynamic controller includes a clock generator and a comparator function.Further on, a logical output interface is connected to the microprocessor and the dynamic controller.In particular, the Vital Coded Processor approach cannot be handled as standard embedded hardware and the comparator function is separated from the microprocessor in the dynamic controller.
The ED 4 I approach (Oh, 2002) (Rebaudengo, 2003).These treated program flow faults occur when a processor fetches and executes an incorrect instruction during the program execution.The effectiveness of the proposed approach is assessed by several fault injection sessions for different example algorithms.
Different classical software fail safe techniques in automotive applications are, amongst others, program flow monitoring methods that are discussed in a survey paper (Leaphart, 2005).
A demonstration of a fail safe electronic accelerator safety concept of electronic control units for automotive engine control can be found in (Schaueffele, 2004).The electronic accelerator concept is a three-level safety architecture with classical fail safe techniques and asymmetric hardware redundancy.
Currently, research is done on the Safely Embedded Software approach.Further results were published in (Mottok, 2007;Steindl, 2009;?;Mottok, 2009;Steindl, 2010;Raab, 2011;Laumer, 2011).Contemporaneous Software Encoded Processing was published (Wappler, 2007).This approach is based on the Vital transformation.In contrast to the Safely Embedded Software approach it provides the execution of arbitrary programs given as binaries on commodity hardware.

Overview
Safely Embedded Software (SES) can establish safety independently of a specific processing unit or memory.It is possible to detect permanent errors, e. g. errors in the Arithmetic Logical Unit (ALU) as well as temporary errors, e. g. bit-flips and their impact on data and control flow.SES runs on the application software layer as depicted in Fig. 1.Several application tasks have to be safeguarded like e. g. the evaluation of diagnosis data and the check of the data from the sensors.Because of the underlying principles, SES is independent not only of the hardware but also of the operating system.
Fig. 2 shows the method of Safety Code Weaving as a basic principle of SES.Safety Code Weaving is the procedure of adding a second software channel to an existing software channel.In this way, SES adds a second channel of the transformed domain to the software channel of the original domain.In dedicated nodes of the control flow graph, comparator functionality is added.Though, the second channel comprises diverse data, diverse instructions, comparator and monitoring functionality.The comparator or voter, respectively, on the same ECU has to be safeguarded with voter diversity (Ehrenberger, 2002) or other additional diverse checks.
It is not possible to detect errors of software specification, software design, and software implementation by SES.Normally, this kind of errors has to be detected with software quality assurance methods in the software development process.Alternatively, software fault tolerance techniques (Torres-Pomales, 2000) like N version programming can be used with SES to detect software design errors during system runtime.
As mentioned above, SES is also a programming language independent approach.Its implementation is possible in assembler language as well as in an intermediate or a high programming language like C. When using an intermediate or higher implementation language, the compiler has to be used without code optimization.A code review has to assure, that neither a compiler code optimization nor removal of diverse instructions happened.Basically, the certification process is based on the assembler program or a similar machine language.
Since programming language C is the de facto implementation language in automotive industry, the C programming language is used in this study exclusively.C code quality can be assured by application of e. g. the MISRA-2 (MISRA, 2004).A safety argument for dedicated deviation from MISRA-2 rules can be justified.

Detectable faults by means of safely embedded software
In this section, the kind of faults detectable by means of Safely Embedded Software is discussed.For this reason, the instruction layer model of a generalized computer architecture is presented in Fig. 3. Bit flips in different memory areas and in the central processing unit can be identified.
Table 1 illustrates the Failure Modes, Effects, and Diagnosis Analysis (FMEDA).Different faults are enumerated and the SES strategy for fault detection is related.
In Fig. 2 and in Table 1, the SES comparator function is introduced.There are two alternatives for the location of the SES comparator.If a local comparator is used on the same ECU, the comparator itself has also to be safeguarded.If an additional comparator on a remote receiving ECU is applied, hardware redundancy is used implicitely, but the inter-ECU communication has to be safeguarded by a safety protocol (Mottok, 2006).In a later system FMEDA, the appropriate fault reaction has to be added, regarding that SES is working on the application software layer.
The fault reaction on the application software layer depends on the functional and physical constraints of the considered automotive system.There are various options to select a fault reaction.For instance, fault recovery strategies, achieving degraded modes, shut off paths in the case of fail-safe systems, or the activation of cold redundancy in the case of fail-operational architectures are possible.

Coding of data
Safely Embedded Software is based on the (AN+B)-code of the Coded Monoprocessor (Forin, 1989) transformation of original integer data x f into diverse coded data x c .Coded data are data fulfilling the following relation: The duplication of original instructions and data is the simplest approach to achieve a redundant channel.Obviously, common cause failures cannot be detected as they appear in both channels.Data are used in the same way and identical erroneous results could be produced.In this case, fault detection with a comparator is not sufficient.1. Faults, errors, and their detection ordered by their area of action.(The labels correspond with the numbers presented in Fig. 3.) The prime number A (Forin, 1989;Ozello, 1992) determines important safety characteristics like Hamming Distance and residual error probability P = 1/A of the code.Number A has to be prime because in case of a sequence of i faulty operations with constant offset f , the final offset will be i * f .This offset is a multiple of a prime number A if and only if i or f is divisible by A.I fA is not a prime number then several factors of i and f may cause multiples of A. The same holds for the multiplication of two faulty operands.Additionally, so called deterministic criteria like the above mentioned Hamming distance and the arithmetic distance verify the choice of a prime number.
Other functional characteristics like necessary bit field size etc. and the handling of overflow are also caused by the value of A. The simple transformation x c = A * x f is illustrated in Fig. 4.
The static signature B x ensures the correct memory addresses of variables by using the memory address of the variable or any other variable specific number.The dynamic signature D ensures that the variable is used in the correct task cycle.The determination of the dynamic signature depends on the used scheduling scheme (see Fig. 6).It can be calculated by a clocked counter or it is offered directly by the task scheduler.
The instructions are coded in that way that at the end of each cycle, i. e. before the output starts, either a comparator verifies the diverse channel results z c = A * z f + B z + D?, or the coded channel is checked directly by the verification condition (z c − B z − D) mod A = 0? (cf.Equation 1).
In general, there are two alternatives for the representation of original and coded data.The first alternative is to use completely unconnected variables for original data and the coded ones.The second alternative uses a connected but separable code as shown in separable code, the transformed value x c contains the original value x f .Obviously, x f can be read out easily from x c .
The coding operation for separable code is introduced in (Forin, 1989): Separable coded data are data fulfilling the following relation: The factor 2 k causes a dedicated k-times right shift in the n-bit field.Therefore, one variable can be used for representing original data x f and coded data x c .
Without loss of generality, independent variables for original data x f and coded data x c are used in this study.
In automotive embedded systems, a hybrid scheduling architecture is commonly used, where interrupts, preemptive tasks, and cooperative tasks coexist, e. g. in engine control units on base of the OSEK operating system.Jitters in the task cycle have to be expected.An inclusion of the dynamic signature into the check will ensure that used data values are those of the current task cycle.
Measures for logical program flow and temporal control flow are added into the SES approach.
One goal is to avoid the relatively high probability that two instruction channels using the original data x f and produce same output for the same hardware fault.When using the transformation, the corresponding residual error probability is basically given by the z e ?"4 m ,"z h -"*Î4 m ,"z h +"oqf"C -"D z -"F eqpfkvkqpu< 4 m @"*"C Î3"+"-"D z -"F."D z -"F">"C Fig. 5. Separable code and conditions for its application.
reciprocal of the prime multiplier, A −1 .The value of A determines the safe failure fraction (SFF) in this way and finally the safety integrity level of the overall safety-related system (IEC61508, 1998).

Coding of operations
A complete set of arithmetic and logical operators in the transformed domain can be derived.The transformation in Equation ( 1) is used.The coding of addition follows (Forin, 1989) whereas the coding of the Greater or Equal Zero operator has been developed within the Safely Embedded Software approach.
A coded operator OP c is an operator in the transformed domain that corresponds to an operator OP in the original domain.Its application to uncoded values provides coded values as results that are equal to those received by transforming the result from the original domain after the application OP for the original values.The formalism is defined, such that the following statement is correct for all x f , y f from the original domain and all x c , y c from the transformed domain, where x c = σ(x f ) and y c = σ(y f ) is valid: Accordingly, the unary operators are noted as: In the following, the derivation steps for the addition operation and some logical operations in the transformed domain are explained.

Coding of addition
The addition is the simplest operation of the four basic arithmetic operations.Defining a coded operator (see Equation ( 3)), the coded operation ⊕ is formalized as follows: Starting with the addition in the original domain and applying the formula for the inverse transformation, the following equation can be obtained for z c : The Equations ( 5) and ( 6) state two different representations of z c .A comparison leads immediately to the definition of the coded addition ⊕:

Coding of comparison: Greater or equal zero
The coded (unary) operator geqz c (greater or equal zero) is applied to a coded value x c .geqz c returns TRUE c , if the corresponding original value x f is greater than or equal to zero.It returns FALSE c , if the corresponding original value x f is less than zero.(This corresponds to the definition of a coded operator (see Definition 3) and the definition of the ≥ 0 operator of the original domain.) Before deriving the transformation steps of the coded operator geqz c , the following theorem has to be introduced and proved.
The original value x f is greater than or equal to zero, if and only if the coded value x c is greater than or equal to zero.Proof.
The goal is to implement a function returning TRUE c , if and only if the coded value x c (and thus x f ) is greater or equal to zero.Correspondingly, the function has to return FALSE c , if and only if x c is less than zero.As an extension to Definition 8, ERROR c should be returned in case of a fault, e. g. if x c is not a valid code word.
By applying the ≥ operator according to Equation ( 9), it can be checked whether x c is negative or non-negative, but it cannot be checked whether x c is a valid code word.Additionally, this procedure is very similar to the procedure in the original domain.The use of the unsigned modulo function umod is a possible solution to that problem.This function is applied to the coded value x c .The idea of this approach is based on (Forin, 1989): In order to resolve the unsigned function, two different cases have to be distinguished:

Conclusion of these two cases:
Result of case 1: Result of case 2: Remark: The index n represents the minimum number of bits necessary for storing x c .I fx c is stored in an int32 variable, n is equal to 32.
It has to be checked, if in addition to the two implications ( 10) and ( 11) the following implications hold.These implications are only valid and applicable, if the two terms B x + D and (B x + D + (2 n mod A)) mod A are never equal.In the following, equality is assumed and conditions on A are identified that have to hold for a disproof: Since A ∈ N + and 2 n is only divisible by powers of 2, k has to be a power of 2, and, therefore, the same holds for A. That means, if A is not a number to the power of 2, inequality holds in case 1.

42
Embedded Systems -Theory and Design Methodology www.intechopen.com

Global (logical) program flow monitoring.
This technique includes a specific initial key value and a key process within the program function to assure that the program function has completed in the given parts and in the correct order (Leaphart, 2005).An alternative operating system based approach is given in Raab (2011).
6. Temporal program flow monitoring.Dedicated checkpoints have to be added for monitoring periodicity and deadlines.The specified execution time is safeguarded.8. Safety protocol.Safety critical and safety related software modules (in the application software layer) communicate intra or inter ECU via a safety protocol (Mottok, 2006).Therefore a safety interface is added to the functional interface.9. Safe communication with a safety supervisor.Fault status information is communicated to a global safety supervisor.The safety supervisor can initiate the appropriate (global) fault reaction (Mottok, 2006).
The example code of Listing 1 is transformed according to the rules 1, 2, 4, and 5 in Listing 2. The C control structures while-Loop, do-while-Loop, for-Loop, if-statement, and switch-statement are transformed in accordance with the complete set of rules.It can be realized that the geqz c operator is frequently applied for safeguarding C control structures.

The case study: Simplified sensor actuator state machine
In the case study, a simplified sensor actuator state machine is used.The behavior of a sensor actuator chain is managed by control techniques and Mealy state machines.
Acquisition and diagnosis of sensor signals are managed outside of the state machine in the input management whereas the output management is responsible for control techniques and for distributing the actuator signals.For both tasks, a specific basic software above the application software is necessary for communication with D/A-or A/D-converters.As discussed in Fig. 1, a diagnosis of D/A-converter is established, too.
The electronic accelerator concept (Schaueffele, 2004) is used as an example.Here diverse sensor signals of the pedal are compared in the input management.The output management provides diverse shut-off paths, e. g. power stages in the electronic subsystem.
Listing 2. Example code after applying the rule 1, 2, 4 and 5.The input management processes the sensor values (s1 and s2 in Fig. 6), generates an event, and saves them on a blackboard as a managed global variable.This is a widely used implementation architecture for software in embedded systems for optimization performance, memory consumption, and stack usage.A blackboard (Noble, 2001) is realized as a kind of data pool.The state machine reads the current state and the event from the blackboard, if necessary executes a transition and saves the next state and the action on the blackboard.If a fault is detected, the blackboard is saved in a fault storage for diagnosis purposes.
Finally, the output management executes the action (actuator values a1, a2, a3, and a4 in Fig. 6).This is repeated in each cycle of the task.
The Safety Supervisor supervises the correct work of the state machine in the application software.Incorrect data or instruction faults are locally detected by the comparator function inside the state machine implementation whereas the analysis of the fault pattern and the initiation of a dedicated fault reaction are managed globally by a safety supervisor (Mottok, 2006).A similar approach with a software watchdog can be found in (Lauer, 2007).
The simplified state machine was implemented in the Safely Embedded Software approach.The two classical implementation variants given by nested switch statement and table driven design are implemented.The runtime and the file size of the state machine are measured and compared with the non-coded original one for the nested switch statement design.
The measurements of runtime and file size for the original single channel implementation and the transformed one contain a ground load corresponding to a simple task cycle infrastructure of 10,000,000 cycles.Both the NEC Fx3 V850ES 32 bit microcontroller, and the Freescale S12X 16 bit microcontroller were used as references for the Safely Embedded Software approach.

NEC Fx3 V850ES microcontroller
The NEC Fx3 V850ES is a 32 bit microcontroller, being compared with the Freescale S12X more powerful with respect to calculations.It runs with an 8 MHz quartz and internally with 32 MHz per PLL.The metrics of the Simplified Sensor Actuator State Machine (nested switch implemented) by using the embedded compiler for the NEC are shown in Table 2.The compiler "Green Hills Software, MULTI v4.2.3C v800" and the linker "Green Hills Software, MULTI v4.2.3A V800 SPR5843" were used.Sensors Actuators

Scheduling Scheme
Task Cycle D=i+2 Fig. 6.Simplified sensor actuator state machine and a scheduling schema covering tasks for the input management, the state machine, the output management and the safety supervisor.The task cycle is given by dynamic signature D, which can be realized by a clocked counter.

Freescale S12X microcontroller
The Freescale S12X is a 16 bit microcontroller and obviously a more efficient control unit compared to the NEC Fx3 V850ES.It runs with an 8 MHz quartz and internally with 32 MHz per PLL.The processor is exactly denominated as "PC9S12X DP512MFV".The metrics of the Simplified Sensor Actuator State Machine (nested switch implemented) by using the compiler for the Freescale S12X are shown in

Results
The results in this section are based on the nested switch implemented variant of the Simplified Sensor Actuator State Machine of Section 5.The two microcontrollers NEC Fx3 V850ES and Freescale S12X need roundabout nine times memory for the transformed code and data as it is necessary for the original code and data.As expected, there is a duplication of data segement size for both investigated controllers because of the coded data.

47
Safely Embedded Software for State Machines in Automotive Applications

www.intechopen.com
There is a clear difference with respect to the raise of runtime compared to the need of memory.The results show that the NEC handles the higher computational efforts as a result of additional transformed code much better than the Freescale does.The runtime of the NEC only increases by factor 6 whereas the runtime of the Freescale increases by factor 10.

Optimization strategies
There is still a potential for optimizing memory consumption and performance in the SES approach: • Run time reduction can be achieved by using only the transformed channel.
• Reduction of memory consumption is possible by packed bit fields, but more effort with bit shift operations and masking techniques.
• Using of macros like inline functions.
• Using initializations at compile time.
• Caching of frequently used values.
• Using efficient assembler code for the coded operations from the first beginning.
• First ordering frequently used cases in nested switch(Analogously: entries in the state table ).
• Coded constants without dynamic signature.
In the future, the table driven implementation variant will be verified for file size and runtime with cross compilers for embedded platforms and performance measurements on embedded systems.

Comprehensive safety architecture and outlook
Safely Embedded Software gives a guideline to diversify application software.A significant but acceptable increase in runtime and code size was measured.The fault detection is realized locally by SES, whereas the fault reaction is globally managed by a Safety Supervisor.
An overall safety architecture comprises diversity of application software realized with the nine rules of Safely Embedded Software in addition to hardware diagnosis and hardware redundancy like e. g. a clock time watchdog.Moreover environmental monitoring (supply voltage, temperature) has to be provided by hardware means.
Temporal control flow monitoring needs control hooks maintained by the operation system or by specialized basic software.
State of the art implementation techniques (IEC61508, 1998; ISO26262, 2011) like actuator activation by complex command sequences or distribution of command sequences (instructions) in different memory areas have been applied.Furthermore, it is recommended to allocate original and coded variables in different memory branches.
Classical RAM test techniques can be replaced by SES since fault propagation techniques ensures the propagation of the detectability up to the check just before the output to the plant.
A system partitioning is possible, the comparator function might be located on another ECU.In this case, a safety protocol is necessary for inter ECU communication.Also a partitioning of different SIL functions on the same ECU is proposed by coding the functions 48 Embedded Systems -Theory and Design Methodology www.intechopen.comwith different prime multipliers A 1 , A 2 and A 3 depending on the SIL level.The choice of the prime multiplier is determined by maximizing their pairwise lowest common multiple.
In this context, a fault tolerant architecture can be realized by a duplex hardware using in each channel the SES approach with different prime multipliers A i .In contrast to classical faul-tolerant architectures, here a two channel hardware is sufficient since the correctness of data of each channel are checked individually by determination of their divisibility by A i .
An application of SES can be motivated by the model driven approach in the automotive industry.State machines are modeled with tools like Matlab or Rhapsody.A dedicated safety code weaving compiler for the given tools has been proposed.The intention is to develop a single channel state chart model in the functional design phase.A preprocessor will add the duplex channel and comparator to the model.Afterwards, the tool based code generation can be performed to produce the required C code.
Either a safety certification (IEC61508, 1998;ISO26262, 2011;Bärwald, 2010) of the used tools will be necessary, or the assembler code will be reviewed.The latter is easier to be executed in the example and seems to be easier in general.Further research in theory as well as in practice will be continued.

Fig. 3 .
Fig. 3. Model of a generalized computer architecture (instruction layer).The potential occurrence of faults are marked with a label.

FigFig. 4 .
Fig. 4. Simple coding x c = A * x f from the original into the transformation domain.

7 .
Comparator function.Comparator functions have to be added in the specified granularity in the program flow for each task cycle.Either a comparator verifies the diverse channel results z c = A * z f + B z + D?, or the coded channel is checked directly by checking the condition (z c − B z − D) mod A = 0?.

Table 2 .
Metrics of the Simplified Sensor Actuator State Machine (nested switch implemented) using the NEC Fx3 V850ES compiler.

Table 3 .
Metrics of the Simplified Sensor Actuator State Machine (nested switch implemented) using the Freescale S12X compiler.