This document discusses improving the dependability of embedded software systems using a technique called fault bypass modeling (FBM). It begins by providing background on embedded systems and their increasing complexity. It then discusses the importance of reliability testing using fault injection techniques. However, injecting faults into closed-loop system models can produce unrealistic outputs. FBM aims to address this by ensuring any signal used to control environmental parameters is fault-free. An example of applying FBM to an anti-lock braking system model demonstrates how it can prevent unrealistic feedback during fault injection testing. FBM shows promise for more effective closed-loop testing of safety-critical embedded software.

1. Improving Dependability of Embedded
Software Systems using Fault Bypass
Modeling (FBM)
Rakesh Rana
Computer Science and Engineering
Chalmers | University of Gothenburg

2. Embedded Software
Image source: http://itsallaboutembedded.blogspot.com/2013/03/what-makes-embedded-system-called-as.html

3. This Car Runs on Code
“It takes dozens of mircroprocessors running 100 million lines of code to get a
premium car out of the driveway, and this software is only going to get more
complex” -ieee spectrum
Ref: http://spectrum.ieee.org/green-tech/advanced-cars/this-car-runs-on-code

4. This Car Runs on Code
Size & Complexity: >1 GB of software distributed over ~100 ECUs.

5. Embedded Software
Image source: http://itsallaboutembedded.blogspot.com/2013/03/what-makes-embedded-system-called-as.html
Low Time
to Market

6. Vehicle
Requirements
System
Design
Sub-System
Design
ECU
Specification
Implementation,
SW on ECU
Unit
Testing
Sub-System
Integration & Testing
System Integration
& Verification
Vehicle
Validation
Automotive Software Development (V-model)

7. Vehicle
Requirements
System
Design
Sub-System
Design
ECU
Specification
Implementation,
SW on ECU
Unit
Testing
Sub-System
Integration & Testing
System Integration
& Verification
Vehicle
Validation
Automotive Software Development (V-model)

8. Fault Injection
• Fault injection is an important and widely used technique for
experimental dependability evaluation of computer systems.
• These techniques has been traditionally used for testing
dependability of the both hardware and software systems.
*Reliability and dependability are very important features of any
computer system.
*So how can we enhance reliability in automotive software?
Reliability

9. ISO 26262 recommendation for using
fault injection techniques
ISO/DIS 26262 Chapter Reference to recommendation
4 Hardware-software
integration and testing
•Table 5 — Correct implementation of technical safety requirements at the hardware-software
level.
•Table 8 — Effectiveness of a safety mechanism’s diagnostic coverage at the hardware-software
level.
System integration and
testing
•Table 10a — Correct implementation of functional safety and technical safety requirements at
the system level
•Table 13b — Effectiveness of a safety mechanism's failure coverage at the system level
Vehicle integration and
testing
•Table 15 — Correct implementation of the functional safety requirements at the vehicle level
•Table 18 — Effectiveness of a safety mechanism's failure coverage at the vehicle level
5 Hardware integration and
testing
•Table 11 — Hardware integration tests to verify the completeness and correctness of the safety
mechanisms implementation with respect to the hardware safety requirements
6 Software unit testing •Table 10 — Methods for software unit testing
Software integration and
testing
•Table 13 — Methods for software integration testing

10. Testing in open loop model configuration
Scripts are used to provide recorded data as input, while the output is saved as data file
and compared to reference/expected output.
The major limitation with such testing is that it’s limited by the availability of
recorded sensors data as well as need to have the correct output for reference
purposes.
Thus it cannot test systems under conditions where the input and output data is not
available
Or if a new functionality is developed or existing system configuration changed such
that the input/output data do not match to previous instance, this type of testing is
unfeasible.
Closed loop continuous models do not suffer from these limitations.

11. Testing in closed loop model configuration
Environment Model
SW system Model
Out_1
Output
Inp_2
Inp_1
Out_2
Natural/State
parameter(s)

12. FBM principle is described as following:
• “If a signal injected with faults or its derivative is
used to calculate/control any natural environment
parameter(s), the part of signal or its derivative
which is used to calculate/control the
environment parameter(s) should be made fault
free to break the unrealistic feedback loop”
Natural Environment Parameter here refers to such a parameter which is
not a property of system but needs correct value from system to define
its correct state/value.
Fault Bypass Principle

13. Case Study: Self-driving miniature vehicle

14. Sensor Layout
Vehicle Camera
Infrared
Ultra sonic
Infrared
Infrared
Camera: Logitech C525 HD
Ultra sonic: SRF08
Infra red: GP2D120
Accelerometer & gyro: Razor 9DoF (optional)
Odometer: Built-in (optional)
ODO
A&G
L
L
L
L
L
L
L
L

15. Model-based system-environment model capable of simulating
vehicle-environment model in virtual space
UDP
multicast
vehicleS CamGen irus
lanedetector
M
driverMmonitor
DesigntimeRun-time
A B
C D
Scenario
modeling GUI
Reference
vehicle
position
Generating
OpenGL
scene
Sensor
para-
meters
Generating
distances
from
obstacles

16. Miniature vehicle running in open/closed-loop condition
lanedetector
driverM
Camera
Vehicle Speed
Sensor Vi
θi
Steering
Wheel
Accelerator
/Brakes
Vd
θd
V0
θ0pos0
vehicleSCamGen
lanedetectorM
driverM
V0
θd
Vi
θi
V0
θ0pos0
Vd
Open Loop
Closed Loop (simulation mode)

17. Injecting fault into the system
Consider a simple scenario, where we simulate how the vehicle would
act in the case of a faulty speed sensor (sensor output is zero).
vehicleSCamGen
lanedetectorM
driverM
V0
θd
Vi
θi
V0
θ0pos0
Vd
0

18. Injecting fault into the system
Consider a simple scenario, where we simulate how the vehicle would
act in the case of a faulty speed sensor (sensor output is zero).

19. Vehicle simulation closed loop testing using FBM
vehicleSCamGen
lanedetectorM
driverM
V0
θd
Vi
θi
V0
θ0pos0
Vd
0

20. CASE: ABS (Anti-Lock Braking) System

21. 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
0
10
20
30
40
50
60
70
Time in sec
SpeedinRPM
Vehicle and wheel speed with & without ABS
Vehicle Speed without ABS
Vehicle Speed with ABS
Wheel Speed without ABS
Wheel Speed with ABS
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
0
20
40
60
80
100
120
140
160
180
200
Time in sec
Distanceinm
Stopping distance with & without ABS
Without ABS
With ABS
CASE: ABS (Anti-Lock Braking) System

22. 0 1 2 3 4 5 6 7 8 9 10
0
20
40
60
80
100
120
140
Time in sec
SpeedinRPM
Vehicle and wheel speed with fault injection
Vehicle Speed
Wheel Speed
Fig: ABS system-environment model representation in
Simulink with fault injector setup.
CASE: ABS (Anti-Lock Braking) System

23. Why ABS model breaks under Fault Injection setup?

24. ABS: modeling using FBM principle
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
0
10
20
30
40
50
60
Time in sec
SpeedinRPM
Vehicle and wheel speed with fault injection (FBM)
Vehicle Speed
Wheel Speed
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
0
20
40
60
80
100
120
140
160
Time in sec
Distanceinm
Stopping distance with & without fault injection (FBM)
ABS, without FI
ABS, with FI

25. Conclusions
• There is significant need for using closed loop testing of embedded software
systems in many domains and applications.
• Fault injection can be used to enhance the effectiveness of closed loop testing
(dependability evaluation of the system in early development stages.)
• But injecting faults into closed loop configurations can generate outputs that are
unreliable and unrealistic.
• To overcome this problem, a framework referred to as fault bypass modeling is
demonstrated with a simple case study.
• Although the example discussed here is very simple, the use of closed loop
testing is most often needed for testing of safety critical applications!

26. For more details
Contact: Rakesh Rana
rakesh.rana@gu.se