Safety-Critical Architectures for Automotive Applications - CiteSeerX

12 downloads 203265 Views 137KB Size Report
Abstract—Advances in embedded system technology have enabled automotive ... associate of the Control and Systems Group (e-mail: [email protected]). ... appear, since they are flexible enough to provide a degree of fault tolerance by ...
47

ELECTRONIC SYSTEMS AND CONTROL DIVISION RESEARCH 2003

Safety-Critical Architectures for Automotive Applications Emmanuel Touloupis, James A Flint and David D Ward

Abstract—Advances in embedded system technology have enabled automotive manufacturers to design electronic systems that introduce new features to the vehicles, improve their performance and increase safety. Following the successful use of fly-by-wire systems in aircraft, the introduction of drive-bywire is expected in an increasing number of new vehicles. The electronic components used in these systems need to provide high levels of reliability and availability. This is achieved by using fault-tolerant techniques both in hardware and software design. Hardware fault-tolerance is based on the use of redundant components. The objective of this project is to design a fault-tolerant system-on-chip (SoC) architecture suitable for drive-by-wire and other safety-critical applications that will reduce the cost and component count in a fault-tolerant design, while maintaining the high levels of reliability and availability of the system.

use redundancy for fault-tolerance and have a fail-safe operation. Brake-by-wire systems [1, 2] are the next to appear, since they are flexible enough to provide a degree of fault tolerance by the fact that the braking force can be applied on all four wheels and there is no single point of failure. The most challenging of the three seem to be the steer-by-wire systems [3, 4, 5]. The architecture of drive-by-wire systems has the form of a distributed real-time computer system (Figure 1). Several sensor, actuator and control nodes communicate through a duplicated fault-tolerant real time network such as the Controller Area Network (CAN) [6], the Time Triggered Protocol (TTP/C) [7], the Time Triggered CAN (TTC) [6], ByteFlight [8], or FlexRay [9]. The general practice to achieve fault tolerance is to duplicate or triplicate the nodes.

Index Terms—Error detection and masking, Fault-tolerant embedded systems, Redundant systems, System safety.

I. INTRODUCTION

T

HE successful use of fly-by-wire systems in aviation along with the positive experience of drive-by-wire systems with mechanical backup for braking and power steering have led to increased interest in the development of full authority drive-by-wire systems. These systems have the potential to reduce the cost of the vehicle, are lighter and are able to provide better passive safety to the passenger. On the other hand it is very clear that the hazard severity of a failure in such a system increases considerably over common systems. For that reason there are some acceptability issues from both consumers and legislative bodies, since the fault behavior of electronic and electrical components is different when compared to mechanical components. Drive-by-wire systems can be defined as electronic or electrical systems or subsystems, which have direct control of the vehicle. This can be implemented to control a particular function, e.g. braking, or can be a global system strategy as in full-vehicle drive-by-wire systems. The three basic by-wire systems in the automotive industry are throttleby-wire, brake-by-wire and steer-by-wire. Throttle-by-wire systems that are already available in conventional vehicles

This work was supported by MIRA Ltd. under the STAR program. E. Touloupis is a research PhD student in the Control and Systems Group (e-mail: [email protected]). J. A. Flint is a member of the Applied Signal Processing Group and an associate of the Control and Systems Group (e-mail: [email protected]). D. D. Ward is Manager of Advanced Engineering in MIRA’s Electrical Group and a Visiting Research Fellow (e-mail: [email protected]).

(a)

(b)

Fig. 1. Drive-by-Wire architectures. (a) Brake-by-Wire: four computer nodes (FL, FR, RL, RR) control the brake actuators in each wheel while node P transmits the data measured from the brake pedal sensor; (b) Steerby-Wire: Node SW transmits the data from the angle sensor on the steering wheel and controls the motor that provides the torque feedback. Node W controls the rack motor and transmits the data concerning the road force on the wheels. Node C is the central controller.

The cost and packaging constraints in automotive industry make this technique impractical. The advances in embedded system technology can enable the design of system-on-chip solutions that could solve this problem by providing a multiple processor system with low unit cost and high integrity. II. SAFETY LIFECYCLE Drive-by-Wire falls into the category of safety critical systems the design of which is defined in various standards, with the most relevant being IEC 61508 [10]. There are also standards that have been defined by military authorities, and the railway and aerospace industries. A UK consortium of automotive companies published the MISRA guidelines [11,

Department of Electronic and Electrical Engineering, Loughborough University, LE11 3TU, UK

48 ELECTRONIC SYSTEMS AND CONTROL DIVISION RESEARCH 2003 12] specifically for vehicle-based systems. These guidelines suggest that a safety analysis must be performed at the early stage of the design, which will include a hazard analysis and a safety integrity assessment. The MISRA guidelines are primarily aimed at software requirements, however they also include a broader framework for assessing the safety of systems and offer useful advice about hardware. In this project a steer-by-wire system was considered, on which a Preliminary Safety Analysis (PSA) was performed. A more detailed safety analysis will follow on the embedded architecture. III. HARDWARE AND SOFTWARE FAULT TOLERANCE There are various techniques to achieve hardware fault tolerance. These include static redundancy structures that use fault masking, dynamic redundancy structures that rely more on fault detection and system reconfiguration and hybrid redundancy structures that use a combination of the two previous techniques [13]. Highly reliable real-time applications like aircraft or vehicle control usually employ static redundant techniques where a voting procedure takes place among the results produced by the redundant modules. Figure 2 depicts a typical TMR (Triple Modular Redundancy) system, where the output comes from a 2 out of 3 vote. More than three processors can be used making an NMR (N-Modular Redundancy) system. The great advantage of these systems is that in the event of a fault they produce a correct output without any delay, since this fault is masked, making them suitable for real-time safety-critical applications. Experience shows that the process of generating software is very susceptible to mistakes. Therefore, even on a system using multiple-redundancy hardware if all of the processors have an identical faulty software component, the system could fail. Two of the most common methods of software fault tolerance are the N-version programming where different software versions are used to implement the same specification, and recovery blocks where some sort of acceptance test is used on the output of small software modules [13]. It is also essential to use a robust process of design and validation that can be assisted by the use of static and dynamic checking tools [14]. This is important because the target system failure rate is extremely low, making exhaustive testing for faults extremely difficult.

Fig. 2. A Triple Modular Redundant (TMR) architecture.

which a PSA was performed. The next step will be to use a Hazard and Operability (HAZOP) study on the embedded architecture particularly that will help to identify the safety measures in more detail. B. Choice of processor Standard off-the-shelf processors and their respective IPblocks do not provide structural information and do not allow internal access and modifications. On the other hand, open source configurable processors allow internal modifications, such as use of parity bits, duplicating crucial parts etc. Such a processor is LEON [15] that is briefly presented here. The LEON microprocessor is a synthesisable VHDL (Very high speed integrated circuits Hardware Description Language) model of a 32-bit microprocessor with an instruction set according to the IEEE 1754 standard, which is compatible with the SPARC V8 instruction set. LEON is highly configurable by enabling the user to remove unnecessary parts and add other modules on the internal AMBA bus. C. Embedded architecture As discussed above, static systems provide an immediate response in case of a fault, which is a very desirable feature for this application, but they have large component count. Dynamic systems use fewer components but are only based on fault detection and cannot guarantee an immediate output when a fault occurs. Hybrid systems can provide high levels

IV. PROPOSED ARCHITECTURE Existing approaches in the design of drive-by-wire systems [1, 2, 3, 4, 5] use classic redundant techniques for hardware fault-tolerance, utilising commercial off-the-shelf components. In this project, we try to design a high integrity embedded architecture capable to achieve the safety level required in drive-by-wire systems. A. Safety analysis The MISRA guidelines call for a safety analysis to be performed and refer particularly to Preliminary Safety Analysis (PSA) that can be followed by a more detailed safety analysis during the implementation of the system. For that reason a steer-by-wire system was considered on Fig. 3. High-level block architecture of the embedded system. Department of Electronic and Electrical Engineering, Loughborough University, LE11 3TU, UK

ELECTRONIC SYSTEMS AND CONTROL DIVISION RESEARCH 2003 of availability and also good level of fault detection. Figure 3 shows a block diagram of a highly available system. A fault tolerant processor handles all processing functions. All the functions that are characterised by a high integrity level are duplicated in a backup fault-tolerant system that is always ready to assume authority in case the main processor fails. One basic idea of this project is to implement a safetycritical system-on-chip. Regarding the architecture of Figure 3, a TMR backup system can be implemented on chip using multiple cores of LEON interconnected through the AMBA bus, along with a voting arrangement. The voting process must be carefully examined, since the existing techniques are based on discrete processor modules. The decision on which other parts of the processor (timers, I/O ports, etc.) need to be duplicated or triplicated is going to depend on the final result of the safety analysis.

49

[12] P. H. Jesty, K. M. Hobley, R. Evans, and I. Kendall, “Safety Analysis of Vehicle-Based Systems,” in Proceedings of the Eighth Safetycritical Systems Symposium, pp. 90-110, 2000. [13] N. Storey, Safety-Critical Computer Systems, New York: Addison Wesley Longman, 1996. [14] Guidelines for the Use of C Language in Vehicle Based Software, The Motor Industry Software Reliability Association, April 1998. [15] LEON2 Processor [Online]. Available: http://www.gaisler.com/

V. CONCLUSION The implementation of a TMR processor architecture on a single chip will aid the development of drive-by-wire systems, by reducing the cost and component count, while maintaining the required high safety integrity. The proposed architecture will be targeted on a high capacity FPGA (Field Programmable Gate Array), where it will be tested for correct operation. Several issues will need to be solved, like voting, synchronisation and memory management. Long-term plans include the investigation of testing and ways of injecting errors into the system, in order to evaluate it. The main goal is to create a prototype that will be used to demonstrate the feasibility of the concept. Since it is difficult to have more than one node in order to set a network, a PC will be used to generate CAN (or other) messages in order to simulate network traffic. REFERENCES [1]

R. Iserman, R. Schwarz, and S. Stölzl, “Fault-tolerant Drive-by-Wire Systems,” IEEE Control Systems Magazine, vol. 22, no. 5, pp. 64– 81, October 2002. [2] W. -D. Jonner, H. Winner, L. Dreilich, and E. Schunck, “Electrohydraulic Brake System – The First Approach to Brake-byWire Technology,” SAE Technical Papers, SAE 960991, Society of Automotive Engineers, 1996. [3] X-By-Wire Team, “X-By-Wire: Safety Related Fault Tolerant Systems in Vehicles,” Technical Report XbyWire-DB-6/6-24, November 1998. [4] T. Kaufmann, S. Milsap, B. Murray, and J. Petrowski, “Development Experience with Steer-by-Wire,” in 42 Volt Technology and Advanced Vehicle Electrical Systems, Society of Automotive Engineers, 1999. [5] D. Peter and R. Gerhard, “Electric Power Steering – The First Step on the Way to Steer-by-Wire,” in Steering and Suspension Technology Symposium 1999, Society of Automotive Engineers, 1999. [6] BOSCH’s Controller Area Network [Online]. Available: http://www.can.bosch.com/ [7] TTTech – Time-Triggered Technology [Online]. Available: http://www.tttech.com/ [8] ByteFlight [Online]. Available: http://www.byteflight.com/ [9] FlexRay [Online]. Available: http://www.flexray.com/ [10] Functional Safety of Electrical, Electronic and Programmable Electronic Systems, IEC Standard 61508, 1999. [11] Development Guidelines for Vehicle Based Software, The Motor Industry Software Reliability Association, November 1994.

Department of Electronic and Electrical Engineering, Loughborough University, LE11 3TU, UK