construction of sfican: a star-based fault-injection infrastructure for the controller area network

Construction of sfiCAN: a star-based fault-injection infrastructure for the Controller Area Network

Alberto Ballesteros

SupervisorsJulián Proenza y Manuel Barranco

Universitat de les Illes Balears

2

What is the Controller Area Network ?

Introduction

3

• The Controller Area Network (CAN) is a field buscommunication protocol

IntroductionCAN

4

• CAN is widely used in distributed embedded control systems

– In-vehicle communication

– Factory automation

– Robotics

• Main benefits

– Low cost– Good resilience to electromagnetic interferences

– Good real-time features

IntroductionCAN

5

IntroductionCAN

• Error frame

• Overload frame

• Remote frame

• Data frame

6

• CAN has been traditionally used in applicationsin which faults can have very negative effects

• It is mandatory to evaluate the capacity ofthese applications for dealing with faults

IntroductionCAN

7

A widely used technique to evaluatehigh -dependable systems is fault injection ,

which allows to observe efficientlythe response of the system

when errors do occur

Introduction

8

IntroductionFault injection

• Generic architecture of a fault-injection system

9

Already available fault injection systems for

CAN present some limitations

Introduction

10

• Low spatial resolution

• Low time resolution

• Traffic restrictions

• Modifications on the nodes

IntroductionLimitations of previous CAN fault-injection systems

11

Why is it so important to provide a fault-injection

system that does not show those limitations ?

Introduction

12

• CAN is being incorporated in safety-related systems

• New technologies are being developed to improve dependability of CAN

IntroductionMotivations for an adequate CAN fault-injection systems

13

GOAL

To build a new fault-injection infrastructure

capable of reproducing complex fault scenarios and,

thus, to test the response of CAN-based applications

and protocols when these faults do occur

Introduction

14

To achieve this goal we developed a

physical fault-injection system called sfiCAN

Introduction

15

• Hub

– Coupling

– Fault injection

– Logging

• Node

– Execute software

– Logging

• PC

– Management

sfiCANArchitecture

16

• Simplex star topology

– Dedicated links for the nodes

– Standard link for the PC

sfiCANArchitecture

17

• Requirements

• Design

• Implementation

• Test of sfiCAN

• Conclusions

• Articles and potential impact

Outline

18

• Requirements

• Design

• Implementation

• Test of sfiCAN

• Conclusions


Outline

19

Requirements

• The user must be capable of specifying the fault scenario by means of an intuitive fault-injection specification language

• The user must be capable of retrieving the data collected during a test

• SfiCAN must be able to force dominant and recessive values, as well as the inverted value of the coupled signal

• SfiCAN must be able to reproduce scenarios involving several simultaneous erroneous bit-patterns

• SfiCAN must be able to inject cascading erroneous bit-patterns

• SfiCAN must be able to inject faults without a previous knowledge of the traffic

20

Requirements

• SfiCAN must be able to inject simple erroneous bit-patterns

• SfiCAN must provide enough spatial resolution to independently affect the signal each node transmits/receives

• SfiCAN must provide enough time resolution to independently modify the value of every single bit

• SfiCAN must be able to inject permanent and temporary faults, including transient and intermittent ones

• SfiCAN must collect enough information during a test to allow the user to check the behaviour of the system

21

Requirements

• SfiCAN must be able to inject simple erroneous bit-patterns

• SfiCAN must provide enough spatial resolution to independently affect the signal each node transmits/receives

• SfiCAN must provide enough time resolution to independently modify the value of every single bit

• SfiCAN must be able to inject permanent and temporary faults, including transient and intermittent ones

• SfiCAN must collect enough information during a test to allow the user to check the behaviour of the system

22

• Requirements

• Design

• Implementation

• Test of sfiCAN

• Conclusions


Outline

23

Design

sfiCAN is constructed froma set of independent modulesthat carry out different tasks

related to the injection

24

DesignsfiCAN architecture

• Modules of sfiCAN

– Centralized Fault Injector (CFI)– Hub Logger (HL)

– Node Logger (NL)

• Fault-Injection Management

Station (FIMS)

• Communication FIMS - modules

– Protocol on top of CAN (NCC protocol)

25

Design

How we carry out an experiment ?

26

DesignPhases of a fault-injection experiment

27


user

28


user

fault-injectionspecification

nodes’workload

29


userstart experiment

30


userstart experiment

31


32


userend experiment

33


userend experiment

34


userreport

35

Design

Which types of faults can sfiCAN inject ?

36

• Transient

• Permanent

• Intermitent

DesignTypes of faults

37

• Fault-injection modes

– Single-shot → transient

– Continuous → transient and permanent

– Iterative → intermittent


38


• Fault-injection modes

– Single-shot → transient

– Continuous → transient and permanent

– Iterative → intermittent

···

39

DesignTypes of faults – Single-shot

··· ···

aim fire cease

Id data crc

40

DesignFault-injection specification language

41

DesignFault-injection specification language

[fault injection 1]

value_type = inverse

target_link = port1dw

mode = single-shot

aim_filter = 0

aim_field = idle

aim_link = coupled

aim_count = 2

fire_field = data

fire_bit = 2

cease_bc = 1

42

• Requirements

• Design

• Implementation

• Test of sfiCAN

• Conclusions


Outline

43

ImplementationDevelopment environment/platform

sfiCAN’s prototype is based on a previous

ReCANcentrate prototype

44


• Hub hardware

– Xilinx XSA-3S1000 FPGA board

– Xilinx Spartan-3 XC3S1000 FPGA chip

• Implementation environment– VHDL

– Xilinx ISE (Integrated Software Environment)

45


• Nodes hardware

– Microchip dsPICDEM 80-pin Starter Development Board

– Microchip dsPIC30F6014A

• Implementation environment– C

– Piklab + MPLAB C30

46


• PC hardware

– Linux-based PC

– Peak System-Technik PCAN-PCI

• Implementation environment– shell script / C++

– GCC

– SocketCAN

47

ImplementationImplementation of the fimCfgExecuter

48


49


• Hub Core

50


• Hub Core

51


• faultInjectionModule

52


• faultInjectionModule

53


• fimExecuter

54


• fimExecuter

55


• fimCfgExecuter

56

• Requirements

• Design

• Implementation

• Test of sfiCAN

• Conclusions


Outline

57

Test of sfiCANTestbed setup

• Experimental platform

58

Test of sfiCANRealized tests

• Bit-flipping (single-shot)

• Recessive Downlink Message Omission (continuous)

• Iterative Integrity Error (iterative)

• Inconsistent Message Omission (single-shot)

• Unfair Primary Error (iterative)

59

Test of sfiCANRealized tests

• Bit-flipping (single-shot)

• Recessive Downlink Message Omission (continuous)

• Iterative Integrity Error (iterative)

• Inconsistent Message Omission (single-shot)

• Unfair Primary Error (iterative)

60

Test of sfiCANBit-flipping

• The value of a bit is inversed

[fault injection 1]

value_type = inverse

target_link = port1dw

mode = single-shot

aim_filter = 0

aim_field = idle

aim_link = coupled

aim_count = 2

fire_field = data

fire_bit = 2

cease_bc = 1

61

• Oscilloscope screenshot


Transmitted

Received

62


• Loggers dump

Node 0 Node 1 Hub

1 Tx 123#00 Rx 123#00 Ok 123#00

2 Er 123#01 Er 123#01 Er AckD(0)

3 Tx 123#01 Rx 123#01 Ok 123#01

4 Tx 123#02 Rx 123#02 Ok 123#02

Time

Transmitter Receiver

63

• Requirements

• Design

• Implementation

• Test of sfiCAN

• Conclusions


Outline

64

Conclusions

We achieved the goal , we developed a physicalfault-injection system capable of reproducing

complex fault scenarios to test the response ofCAN-based applications and protocols

65

Conclusions

• Fault model

– Global/local faults

– Bit granularity

– Transient, permanent and intermittent

– Simple/complex scenarios

• Semantic faults to some extent

66

• Requirements

• Design

• Implementation

• Test of sfiCAN

• Conclusions


Outline

67

Articles and potential impactArticles

D. Gessner, M. Barranco, A. Ballesteros, and J. Proenza,Designing sfiCAN: a star-based physical fault injec tor for CAN ,in 16th IEEE International Conference on Emerging Technologies and Factory Automation, 2011.

D. Gessner, M. Barranco, J. Proenza, and A. Ballesteros,sfiCAN : a Star-based Physical Fault Injector for CAN networks , 2011.

68

Articles and potential impactPotential impact

• sfiCAN has generated interest in a particular company involved in the evaluation of high dependable systems

• Part of CANbids project

– CANcentrate

– ReCANcentrate

– Aggregated Error Flag Transmitter (AEFT)

Construction of sfiCAN: a star-based fault-injection infrastructure for the Controller Area Network

Alberto Ballesteros

SupervisorsJulián Proenza y Manuel Barranco

Universitat de les Illes Balears

construction of sfican: a star-based fault-injection infrastructure for the controller area network

Technology

faultinjection experimentuser

requirements sfican

design sfican

patterns sfican

atest sfican

construction of sfican

node transmitsreceives

intermittent ones sfican