Part 3: Functional Safety Demonstration project - Cruise Control in panic mode
- Jan. 20, 2016
- Marcel Romijn
In this demonstration project BRACE has selected the Functional Safety competence as a central topic. In co-operation with the HAN University of Applied Science a demonstration project has been setup. The project is executed by a thesis student of the HAN and an intern student of the TU/e. In the previous blog articles, BRACE pointed out the importance of functional safety in passenger vehicles.
BRACE approached the problem in a phased manner. To support in the setup of the functional safety analysis a Simulink model of a vehicle (plant) and a cruise control system (controller) was built and the behaviour of various components of the system was studied. The Simulink model was confronted with failure injection to study the failure reaction behaviour.
While at this time still mainly functional level is considered the Simulink model contains some assumptions on the appearance of the cruise control system. The outcomes of the Simulink model failure behaviour therefore have to carefully interpreted. They do support however in this analysis phase.
The failure injections into the Simulink model, combined with the functional safety analysis, also provided a direction of what should be tested on a real vehicle.
A small number of failure were tested in real-life on a Volvo vehicle. Based on our earlier functional safety analysis a safety concept was setup. The test on a vehicle in which we did not design the cruise control acts more as a verification of our analysis approach this time than an actual determination on whether the car is functionally safe. If we come up with a number of failure injections that are in general critical (regardless of technical implementation) and the associated safety concept we can state what we expect as a test outcome. Taking the Volvo (or any other car) and doing the same we can check if the tests have the same outcome as we imagined. That would show that we at least got to the same understanding as Volvo, while staying at functional level.
The following failure modes were selected to be tested:
Throttle valve fault –Fixing the throttle position physically
Brake system fault – Disconnection of brake status sensor
Vehicle Speed signal fault – Manipulation of CAN messages from ABS to the rest of the vehicle
The disconnection and blockage are easy to implement. The CAN error is implemented in the system using an STM32-E407 development board, programmed through the Matlab/Simulink environment. BRACE participates in the HAN SMARTcode project and its predecessor and therefore this toolchain was selected. The development toolchain creates software and the created software is able to influence the CAN-Bus message content (like the vehicle speed and wheel speed sensor data). By only changing the content a wrong vehicle speed signal can be simulated inside the vehicle without having go the extreme lenghts in building an actual malfunction. To be able to do so first the CAN system of the Volvo with regards to vehicle speed information was reverse engineered.
Some Test results:
Implementation of the CAN modified vehicle speed signal showed that the Volvo system was very keen on correct reception rate of the CAN message. When this information arrived late, the ECU at times brought the vehicle to a state in which it would not allow cranking of the engine. This is interpreted as an excellent safety response by the car. In this test we have found a small bug in the auto-generated code that prevented us from further testing; closer to our original test plan. We will return to this topic in subsequent projects.
Other tests involving physical manipulation of components showed more results. For example, disconnection of the brake light switch showed that the vehicle system was capable of detecting a fault and was moving to a default mode of operation (cruise control system unavailable). A limitation here is that when the brake pedal is not used the fault on the switch was not seen. Our concept was a bit more strict in that at functional level we assumed any failure at any time of the brake status had to be detected .
A partial blockage of the throttle valve was also used. In this setup the cruise control system is confronted with a limitation of engine performance to meet or hold the requested speed. The throttle valve system was already considered a safe system as it follows a certain redundancy and closed loop control. This is based on the E-gas concept. Expectation was that as soon as a certain amount of throttle position was requested beyond the blockage and the closed loop control error increased, a fault should be detected. The test showed that in different types of driving modes this is exactly what was observed. Small changes in throttle and small openings as forced by either driver or cruise control stayed undetected. As soon as they increased a fault was detected and not only did the cruise control switched off but also the throttle pedal control went into a default “limp-home” mode.
The demonstration project showed in general that many elements of functional safety can be analysed at a higher functional level and even the vehicle validation can be organised as such. This supports in the application of functional safety in architectures with many subsuppliers and also helps in saving effort when the same function has different technical implementations.
A demonstration project such as this, ran by students, provides BRACE with the chance to play-around with some ideas and suggestions to better serve our customers.