Documents

Lucas Automotive -- Safety-related Design in Microprocessor-based Automotive Applications

Description
The use of computers in safety-related applications has increased greatly in the last five years. Wider awareness and public concern and the implications of various government directives have placed safety-critical assessment high on the agenda of computing design. At a recent lEE colloquium on 'Safety critical software in vehicle and traffic control (London, UK, 13 February 1990) some of the key issues on this agenda were raised within the particular context of automotive and traffic control applications. To widen this debate this topical feature presents edited extracts from three presentations given at the colloquium which focus on the use of microprocessors in such systems: one a hardware architectural approach, and two advocating the use of formal methods for the design of 'correct software.
Categories
Published
of 3
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Transcript
   pdate Safety-related design in microprocessor-based automotive applications Designers of increasingly complex automotive control systems are considering ways to maintain the safety record of these systems. In this feature three contributors consider hardware and formal methods-based software approaches to this problem The use of computers in safety-related applications has increased greatly in the last five years. Wider awareness and public concern and the implications of various govern- ment directives have placed safety-critical assessment high on the agenda of computing design. At a recent lEE colloquium on Safety critical software in vehicle and traffic control (London, UK, 13 February 1990) some of the key issues on this agenda were raised within the particular context of automotive and traffic control applications. To widen this debate this topical feature presents edited extracts from three presentations given at the colloquium which focus on the use of microprocessors in such systems: one a hardware architectural approach, and two advocating the use of formal methods for the design of 'correct software. microsystems safety-critical computing automotive control software design formal methods SYSTEM ARCHITECTURES FOR SAFETY CRITICAL AUTOMOTIVE APPLICATIONS John Millward Microprocessor-based control systems are now common- place in vehicles. They have traditionally been employed in systems where a failure will cause inconvenience but the consequential hazard potential is low (except perhaps automatic braking systems). These systems usually have a well defined safe state. Many manufacturers and com- ponent suppliers are now experimenting with systems whose failure can have much more serious consequences such as: control by wire and supervisory systems, which can override the driver s inputs; and complex inter- connected systems where one failure can effect several others. The safety record of automotive electronic systems has been very good, but to maintain this situation the safety and reliability attained by these systems must increase at a rate equal to their complexity. Lucas Automotive, Advanced Engineering Centre, Dog Kennel Lane, Shirley, Solihull, West Midlands B90 4JJ, UK Sources of failure Random failures. Random failures of electrical com- ponents, connections, wiring and mechanical devices are amenable to statistical prediction. Although the task is not simple, due to the number of components and in some cases the lack of data on which to base the predictions, failure probabilities can be produced. These figures together with an FMEA analysis can be used to estimate the hazard potential and hence the acceptability of the system. Improved computer assistance with these processes together with a pool of freely available predicted and achieved reliability data would be of benefit. Systematic errors. Systematic errors can occur in the system requirements, the hardware design orthe software design. They are not random: given the same input conditions the same incorrect behaviour will occur. They are the result of human error in the design process or the design of the tools used in the process, and therefore render the supplier morally and legally liable for any consequences. There is no adequate method for pre- dicting the probability of such failures in typical auto- motive control systems and it is therefore a question of engineering udgement as to how much effort, and hence cost, is incurred in trying to prevent their occurrence. This judgement may have to be defended (in court), causing pressure to always use the best possible practices regardless of the immunity of the system to random and interference type failures. The adoption of an inter- nationally agreed standard on classification of systems (for example by hazard analysis) and the procedures necessary for each class seems the best current option. Adherence to these standards would then be cited as a defence in liability claims. Intermittent failures. Intermittent failures, particularly those caused by EMC problems are difficult to predict and also depend on factors outside the supplier s control, such as the environment in which the vehicle will operate. Again an internationally agreed test standard, adherence to which can be used as a defence in liability claims, seems the best current solution. 0141-9331/90/05318-7 © 1990 Buttena/orth-Heinemann Ltd 378 Microprocessors and Microsystems   pdate System architectures for systems with a safe state The classic approach to achieving the required system safety level is to provide redundancy in some form. This improves safety at the expense of reliability. A typical architecture for a dual redundant system is shown in Figure 1. This system uses two identical channels, each of which performs exactly the same function. The outputs of the two channels are then compared and if they are found to be different the system is shut down into its fail-safe state. This architecture is very effective at identifying com- ponent failures within the ECU. It will also identify intermittent faults which affect only one channel, but since the channels are identical there is a significant risk of a common mode type of failure. A systematic fault in the hardware design will produce identical but incorrect outputs on both channels and hence will not be detected. The same argument is true for software errors and errors in the system specification. This type of architecture can give the fastest and most reliable detection of random component failures but its use places very high demands on the integrity of all stages of the system design. A variation on this architecture is to use different types of microprocessor for each channel. The software for each channel can also be written by different teams, thus reducing, although not eliminating, the possibility of common software errors. This architecture reduces the likelihood of common mode failures but since the internal processing of the data may be different, thus preventing direct comparison of intermediate results, both the time taken and the reliability of failure detection can be adversely affected. It is for this reason that some very high integrity systems (e.g. A320 fly-by-wire system) use a combination of both architectures. It is important to note that this architecture offers no protection against an error in the srcinal system requirements or specifications; in this case both channels will agree on the incorrect action. It is this author s belief that specification error is the most serious problem facing the designers of future automotive systems. Improvements have taken place in the translation of specifications into hardware and software but the problems of specifying the correct outputs, for every combination of inputs, in every possible scenario, of complex interconnected systems have still to be resolved. An altemative architecture is shown in Figure 2. This architecture has two dissimilar channels. Moreover these channels perform very different functions, as is explained below, and therefore the chance of a common mode specification, software, hardware or interference failure should be greatly reduced. This diversity is obtained by dedicating each channel to a different task. The main processor is designed to carry out the control function, in the same way as a single channel system, whilst the second channel, or safety processor , is used to monitor the system and ensure it never enters an unsafe state. The npãuts ~ Control Micro 1 Safety ritical Control Micro Safety Critical Figure 1. Duplex processor system Actuator Inputs Control Micro ts Fail-Safe Non Safety Critical Actuator Interrogation ~ ~ Bus - Watchdog Micro / Safety Critical .......... Figure 2 Main and monitor system POWER two channels communicate to exchange data and to check that each channel is functional. The second channel monitors both the system inputs, outputs and as many intermediate variables as are considered necessary to provide acceptable failure detection time. The safety processor does not repeat the control calculations of the main processor, but determines from its input data whether or not the system is in a safe state. For example, in a closed-loop throttle control system the main processor will determine the required actuator drive signal, whereas the safety processor could ensure that the direction of the drive signal is appropriate and that the integral of the error signal is below a certain threshold. The task of specifying the function and the unsafe states for the safety processor is not simple, but it is a valuable task for checking the requirements for the main processor. The functionality required from the safety processor should be less than that required from the main processor since it may not need to perform all the control calculations. More importantly, the safety processor will be easier to design as a deterministic synchronous system since the precise timing constraints required for control can be relaxed. This could allow formal methods to be used effectively in its design and implementation. The precise mathematical notation of formal methods appear well suited to the task of describing states and behaviour that a system should not exhibit. To prove that such a system is safe, it would be necessary to prove that the operation of the safety processor was logically correct and that all random errors in the safety processor could be detected by the main processor. Logical proof of the control function is not necessary for safety, although of course it is necessary for Vol 14 No 5 June 1990 319   pdate reliability. This is an important point because the author is unaware of any techniques for formally proving the correctness of typical automotive control systems with their complex realtime structures. System architectures for systems without a safe state Figure 3 shows the classic triple redundant system. This type of system has been used for many years in aerospace applications, but it does admit the possibility of common mode failures. Previous experience with these systems was gained on systems where the control strategy and implementation were relatively simple. As the complexity of the hardware, software and system requirements increases so must the danger of a common error. Using dissimilar hardware and software for each channel becomes more difficult as the number of channels increases due to the availability of suitable components and provides no protection against specification error. An alternate implementation which should reduce the chances of a common mode error, and which is also potentially cheaper to produce, is shown in Figure 4. This is basically a duplex version of Figure 2 with some .... i Control Micro 1 [ / _ Inputs i , v Sa|ely Critical L I Salety Critical tLsã Fail-Safe )u Voter ~ Actuator Figure 3. Triplex dependable system Inputs Inputs Figure 4. POWER ntetrogationBus ~ =i ~ ...... Safety Critical O ts Actuator Failsafe Voter Safety C~ Actuator N tw....oo f afety Cdtcal .... 1 POWER Two channel dependable system additional logic to prevent both channels relinquishing control at the same time. Dissimilar hardware and software could again be used. Safety could again be improved by having different requirements for each channel. The first channel would perform the full functionality and would operate until a failure was detected by its safety processor or the second channel failed. The second channel would provide a reduced functionality, but safe, back-up system. The second channel would therefore be designed against a different specification, thus providing some diversity. It should also be simpler, easier to validate and hence cheaper. An example of this approach could be an electrically operated braking system where the first channel provides many sophisticated features, such as anti-skid, anti-spin and hill-holding. The second channel would merely provide a braking force proportional to the driver s pedal force. Conclusion As electronic control systems increase in both complexity and control authority there must be a commensurate increase in our ability to design and implement these systems safely. The use of common specifications, hardware and software are all seen as potentially hazardous for very high integrity systems. Diversity is regarded as the best approach for providing the safety levels required and the preferred approach is to provide this by utilizing checking and back-up systems which are designed against a different requirement, and have less functionality than the main control system. In this way the integrity of these systems can be kept high at a reasonable cost. ON THE DEVELOPMENT OF A FORMAL METHODS-BASED SOFTWARE DESIGN METHODOLOGY FOR AUTOMOTIVE APPLICATIONS S Tran J Cullyer E Hines and K Marks Microprocessor systems are beginning to be used in a variety of safety-critical applications in the automotive industry. Throttle, brake and steering systems are changing from mechanically-controlled systems to electrical systems. Thus there is a need for safe and reliable actuators and controllers. The issue of reliability should be considered by the customer from a system viewpoint, since it is affected by both hardware and software. There already exist stringent standards for hardware design, such as the German TUV standard, but there remains a need for rigorous standards to produce more reliable software. Software is the key to a successful or disastrous micro- processor-based circuit design. Poorly developed software Department of Engineering, Warwick University, Coventry CV4 7AL, UK 320 Microprocessors and Microsystems
Search
Tags
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks