experiences with canoe-based fault injection for...

Experiences with CANoe-‐Based Fault-‐Injec;on for AUTOSAR Patrick E. Lanigan ([email protected])

Patrick E. Lanigan, Priya NarasimhanElectrical & Computer Engineering

Carnegie Mellon University

Experiences with CANoe-based Fault Injection for AUTOSAR

Thomas E. FuhrmanResearch & DevelopmentGeneral Motors Company

1

mailto:[email protected]



WHAT TO EXPECT

• A brief overview of automotive systems / tools– AUTOSAR

– FlexRay

– Vector CANoe

• A description of a proof-of-concept software-implemented fault-injection framework

• An example application of the framework

• A qualitative discussion of the what worked well, as well as what did not work so well.

2




WHAT NOT TO EXPECT

• A dependability evaluation of the...– AUTOSAR specification

– AUTOSAR implementation

– FlexRay protocol

– demo application

• A discussion of specific fault-models• A coverage assessment

• A quantitative analysis

3




ROADMAP

• Introduction– Overview of automotive systems

– Motivation

– Goals

• Fault-injection framework

• Runtime evaluation

• Conclusion

4




AUTOMOTIVE SYSTEMS

• What is an “automotive system”?– Many mechanical, hydraulic and electrical (incl. hardware and

software) components interact to perform vehicle functions

– Operates in a dynamic environment (other vehicles, pedestrians, animals, etc)

• Our focus is on the embedded computing architecture– Electronic Control Units (ECUs) and software

– Distributed, serial communication(e.g. CAN, FlexRay)

– Sensors and actuators

5




Electronics account for significant and increasing proportion of innovation as well as cost.

BACKGROUND: AUTOSAR

• Standard software-architecture for automotive applications– Encourage reuse of software

– Reduce development costs

• Layered architecture– Basic Software (BSW) layers

provide hardware abstractions

– Application layer implements high-level functionality

– Runtime Environment (RTE) layer enables information exchange

6

Page 13 - AUTOSAR Confidential -

Layered Software ArchitectureV2.2.2

R3.1 Rev 0001

Document ID 053

Part 2 – Overview of Software Layers ID: 02-02 Layered View: Coarse

ComplexDrivers

Microcontroller

Microcontroller Abstraction Layer

Services Layer

Application Layer

AUTOSAR Runtime Environment (RTE)

ECU Abstraction Layer

Source: AUTOSAR Layered Software Architecture, Document ID 053, p. 13.http://www.autosar.org/download/R4.0/AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf



http://www.autosar.org/download/R4.0/AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf

http://www.autosar.org/download/R4.0/AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf


BACKGROUND: FLEXRAY

• High-speed, synchronous serial communication protocol– Communication schedule is divided into equal-length time slots

and executed periodically

– Slots are statically assigned to nodes

– Support for dual channels (up to 10 mbps each)

• FlexRay nodes are synchronized to a global time-base

7

FlexRay Protocol Specification

Version 2.1 Revision A 15-December-2005

Chapter 5: Media Access Control

Page 102 of 245

The media access procedure is specified by means of the media access process for channel A. The nodeshall contain an equivalent media access process for channel B.

5.1.3 Static segmentWithin the static segment a static time division multiple access scheme is applied to coordinate transmis-sions.

5.1.3.1 Structure of the static segmentIn the static segment all communication slots are of identical, statically configured duration and all framesare of identical, statically configured length.For communication within the static segment the following constraints apply:1. Sync frames shall be transmitted on all connected channels.2. Non-sync frames may be transmitted on either channel, or both.3. Only one node shall transmit a given frame ID on a given channel.56

4. If the cluster is configured for single slot mode, all non-sync nodes shall designate a frame as the sin-gle slot frame.

5.1.3.2 Execution and timing of the static segmentIn order to schedule transmissions each node maintains a slot counter state variable vSlotCounter forchannel A and a slot counter state variable vSlotCounter for channel B. Both slot counters are initializedwith 1 at the start of each communication cycle and incremented at the end boundary of each slot.Figure 5-3 illustrates all transmission patterns that are possible for a single node within the static segment.In slot 1 the node transmits a frame on channel A and a frame on channel B. In slot 2 the node transmits aframe only on channel A57. In slot 3 no frame is transmitted on either channel.

Figure 5-3: Structure of the static segment.

The number of static slots gNumberOfStaticSlots is a global constant for a given cluster.

56 This requirement applies to the entire operation of the cluster, as opposed to only a single cycle. For example, it is not acceptable to configure a cluster such that different nodes transmit in the same slot/channel combination in different cycles.

57 Analogously, transmitting only on channel B is also allowed.

channel A

channel B

frame ID 1

frame ID 1

frame ID 2

static segment containing gNumberOfStaticSlots static slots

static slot 1 static slot 2 static slot 3

t

1

1

2

2

3

3

slot counter channel A

slot counter channel B

Reg

iste

red

copy

for p

atric

k.e.

lani

gan@

gm.c

om

Source: FlexRay Consortium, FlexRay Protocol Specification, V2.1, p 102http://www.flexray.com



http://www.flexray.com

http://www.flexray.com


An increasing amount of control and autonomy is being delegated to embedded computing architectures.

AUTOMOTIVE SYSTEMS (CONT.)

• Adaptive cruise control

• Forward collision warning

• Curve speed control

• Side blind zone alert

• Lane keeping / lane centering control

• Cross traffic collision avoidance

8




MOTIVATION FOR OUR FRAMEWORK

• AUTOSAR is likely to be a key enabler of functional safety systems

• Fault-injection plays an important role in the dependability analysis of such systems– “Highly recommended” by upcoming ISO 26262 standard

• Hardware-based fault injection requires specialized equipment (e.g., TTXDisturbance node)– Availability, cost, complexity can limit applicability

– Cannot accurately target specific software modules

• How far can we go with existing software tools (e.g., Vector CANoe)?

9




BACKGROUND: VECTOR CANOE

• CANoe is a simulation and evaluation environment for automotive applications

• Supports a variety of bus protocols (e.g., FlexRay)

• The behavior of simulated nodes can be defined in multiple ways– External DLL using CANoe programming interface

– CAPL scripting language

• Provides graphical and text-based output windows

10

3/2

CANoe 7.2The Development and Test Tool for CAN, LIN, MOST, FlexRay, Ethernet and J1708

CANoe is an all-round tool for the development, testing and anal-ysis of entire ECU networks and individual ECUs. It supports theuser during the entire development process – from planning tostartup of entire distributed systems and their individual ECUs.CANoe’s versatile functions and configuration options are used bynetwork designers, development engineers and test engineers atOEMs and suppliers.At the beginning of the development process CANoe is used tocreate simulation models that emulate the behavior of the ECUs.Over the course of ECU development these models serve globallyas a foundation for analysis, testing and integration of bus sys-tems and ECUs. This lets you detect and correct problems early.Both graphic and text-based evaluation windows are available foryou to evaluate the results.CANoe contains the Test Feature Set for easy and automated exe-cution of tests. It is used to model and execute sequential testflows with automatic generation of a test report. Also available inCANoe is the Diagnostic Feature Set for diagnostic communicationwith the ECU.

FunctionsThe basic functions of CANoe are:> Use of network describing data bases (e.g. DBC, FIBEX, LDF,

NCF, MOST Function Catalog)> Simulation of complete systems and remaining bus simulation

via modelling> Analyzing the bus communication> Test entire networks and/or individual ECUs> Diagnostic communication via KWP2000 and UDS and use as a

full-fledged diagnostic tester> User programmable with integrated C-like CAPL programming

language to support simulation, analysis and testing> User-customized interfaces can be created to control the

simulation and tests or display analysis data

The CANoe user interface with control and display panels, analysis windows and the TestExecution dialog

CANoe supports the following bus systems and protocols> Bus systems: CAN, LIN, MOST, FlexRay, Ethernet, J1708> CAN-based protocols: J1939, NMEA 2000, ISO 11783,

CANopen, MCNet, GMLAN, CANaerospace

Special functions> For critical real time relevant simulations, CANoe operation

is distributed between two PCs, whereby the simulationand test core runs under Windows XP Embedded.

> Numerous auxiliary modules simplify adaptation to OEM-specific services and protocols (Transport Protocols,Network Management, Interaction Layer, etc.).

> Diagnostics is parameterized by ODX 2.0.1 or 2.2.0. Physical and functional addressing are also supported. The integrated OBD-II tester enables quick standard diagnostics.

Vector Katalog Design Test_EN 15.02.2010 10:02 Uhr Seite 3/2

More Information: www.vector.com/contact

Sour

ce: V

ecto

r Pr

oduc

t C

atal

og, p

. 32




THE “-ILITIES”

11




THE “-ILITIES”

11

Functionality

(1) Exercise error handling (2) Runtime configuration(3) Runtime visualization




THE “-ILITIES”

11

Functionality


Controllability

Repeatable scenarios with respect to time, location

and duration.




THE “-ILITIES”

11

Functionality


Controllability


and duration.

Observability

Distinguish masked faults from faults with no effect.




THE “-ILITIES”

11

Functionality


Controllability


and duration.

Observability


Portability

Minimize changes required to existing codebase(s).




THE “-ILITIES”

11

Functionality


Controllability


and duration.

Observability


Portability


Flexibility

Support a wide range of scenarios, faults and

errors.




THE “-ILITIES”

11

Functionality


Controllability


and duration.

Observability


Portability


Flexibility

Support a wide range of scenarios, faults and

errors.

Avoid Probe Effects

Fault-injection process should not produce

unintended side effects.




ROADMAP

• Introduction• Fault-injection framework– Architecture

– Fault-injection hook locations

– Example use of fault-injection hooks

• Runtime evaluation

• Conclusion

12




FAULT-INJECTION STRATEGY

• Hooks are inserted into AUTOSAR functions– Manipulation hooks modify function arguments

– Suppression hooks cause functions to return error codes

• Fault-injection scenarios are defined by six parameters

13

Manipula(on parameters

Suppression parameters

Loca;on

Argument Mask Offset Opera;on

Loca;on

Ac;ve




FAULT-INJECTION FRAMEWORK

CANoe

Node 1

Node 3 Node 4

Node 2

14





CANoe

Node 1

Node 3 Node 4

Node 2

AUTOSAR library

14





CANoe

Node 1

Node 3 Node 4

Node 2

CAPL scriptAUTOSAR library

14





CANoe

Fault-injection library Node 1

Node 3 Node 4

Node 2


14





CANoe


Node 3 Node 4

Node 2


Fault-injection parameters

14





CANoe


Node 3 Node 4

Node 2



Fault-injection hook implementations

14





CANoe


Node 3 Node 4

Node 2



Fault-injection hook implementations

CAPL extensions

14




HOOK LOCATIONS IN AUTOSAR

Application layer


Complex DriversECU Abstraction Layer

Microcontroller (ECU)

Services Layer

Microcontroller Abstraction Layer

15





Application layer


System Services Complex DriversMemory Services Communication Services


Microcontroller Drivers

Memory Drivers Communication Drivers

I/O Drivers


15





Application layer






I/O Drivers


WdgM

15





Application layer






I/O Drivers


ComWdgM

15





Application layer






I/O Drivers


ComWdgM

Fr

15




EXAMPLE HOOK USAGE

16

if (SWIFI_Suppress_Fr_Tx()) {return E_NOT_OK;

}

If the suppression hook is active, immediately return an error code.

Pass target arguments by reference for manipulation inside the hook. Arguments are only modified if the current location is active.

SWIFI_Hook_Fr_Tx(&channel, &slotId, &baseCycle, &cycleRep, &frameStatus,(uint16 *)&Fr_LSduLength, (uint8 *)Fr_LSduPtr);

CANoeAPI_SendFlexRayMessage(Fr_CtrlIdx, channel, slotId, baseCycle,cycleRep, frameStatus, Fr_LSduLength, Fr_LSduPtr);




EXAMPLE HOOK IMPLEMENTATIONS

17

EXPORT_C int SWIFI_Suppress_Com_Write() { return (gFi_Location == SWIFI_LOC_COM_WRITE) && gFi_Suppress;}

Suppression hooks return a boolean value that indicates whether or not the instrumented function should abort.

Modifiable arguments (id, buffer) are passed by reference, while non-modifiable arguments (bLength) provide additional context.EXPORT_C int SWIFI_Hook_Com_Write(uint16 *id, uint16 bLength, uint8 *buffer) { if ((gFi_Location == SWIFI_LOC_COM_WRITE) && (gFi_Operation != SWIFI_OP_NONE)) { switch(gFi_Argument) { case SWIFI_ARG_PAYLOAD: apply_mask(buffer, bLength, gFi_Mask, gFi_Offset, gFi_Operation); return 1; case SWIFI_ARG_SLOTID: apply_mask((uint8 *)id, sizeof(uint16), gFi_Mask, gFi_Offset, gFi_Operation); return 1; default: return 0; } }

return 0;}




ROADMAP

• Introduction• Fault-injection framework

• Runtime evaluation– Configuration interface

– Demo application

– Example scenarios and fault manifestations

• Conclusion

18




CONFIGURING A FAULT-INJECTION SCENARIO

19





Select how the mask is applied to the

argument.

19






argument.

Activate a suppression hook.

19






argument.


Select the target argument.

19






argument.



Define the mask...

...and offset.

19






argument.



Define the mask...

Select the target location.

...and offset.

19




DEMO APPLICATION

• The framework was applied to a “by-wire” application– Sensing ECU reads throttle and brake inputs

– Front and rear ECUs calculate wheel speed independently

– Front ECU is the target of fault injection

• Originally developed as a simple CANoe demonstration– No fault-tolerance mechanisms

– No application-level error handling

20

Sensor ECU(CAPL)

Can / FlexRay Gateway(CAPL)

Front Wheel Speed ECU(AUTOSAR)

Rear Wheel Speed ECU

(CAPL)

CAN

FlexRay




EXAMPLE FAULT-INJECTION SCENARIOS

21





21

No active faults.





21

No active faults.

Front & rear wheel speed changes equally with application of throttle.




EXAMPLE FAULT-INJECTION SCENARIOS (CONT.)

22





22

Suppression hook is active.





22

FlexRay frame reception function is the target.






22

Front wheel speed no longer responds to changes in throttle application.

FlexRay frame reception function is the target.






23





23


Com signal reception function is the target.





23


Com signal reception function is the target.

Front wheel speed drops immediately and no longer responds to changes in throttle application.




ROADMAP

• Introduction• Fault-injection framework

• Runtime evaluation• Conclusion– Lessons learned

– Summary

– Questions

24




THE “-ILITIES” (LESSONS LEARNED REMIX)

25





25

✓ Excercise AUTOSAR fault-handling mechanisms

✓ Observe application-level manifestationsFunctionality





25



✓ Fault-injection logic is modularized away from application code

✓ Requires no changes to existing configuration files or autogenerated codePortability





25





✓ Good control of fault location by layer, component, function, data structure

X Manual control makes duration and time of faults very difficult to controlControllability





25







X Observability is limited to application-level behaviorObservability





25








X Protocol-level errors cannot be injected directly because the simulated communication controller is not accessible from software

Flexibility





25









Flexibility

X Certain faults cannot be isolated to simulated nodes (e.g., memory-access faults crash the entire simulation)

Avoid Probe Effects





25





Flexibility


Avoid Probe Effects

Implementation limitations





25





Flexibility


Avoid Probe Effects

Environment limitations

Implementation limitations




SUMMARY

26

• CANoe is a suitable environment for fault-injection, provided that the faults injected fall within the level of abstraction provided by the simulation.

• This proof-of-concept framework shows promise for rapid-prototyping of new applications.

• A combination of techniques are likely required for a robust analysis.




QUESTIONS?

27

Patrick E. [email protected]





experiences with canoe-based fault injection for...

Documents