CPS Applications Heechul Yun Note: Some slides are adopted from - - PowerPoint PPT Presentation

CPS Applications

Heechul Yun

1

Note: Some slides are adopted from Prof. Pellizzoni

Outline

• Avionics
• Automotive Systems
• Other CPS Applications

2

Avionics

• Electronic systems on an aircraft

– Avionics = Aviation + electronics – Multiple subsystems: communications, navigation, display, flight control, management, etc.

• Modern avionics

– Increasingly computerized

• Safety culture

– Safety critical; conservative; regulated (FAA, EASA)

3

Fly-by-wire

• Modern aircrafts rely on computers to fly
• Pilots do not directly move flight control surfaces

(ailerons, elevator, rudder)

• Instead, Electronic Flight Control System does.

4

FCS

Yoke Control surfaces

Autopilot

• Specify desired track: heading, course,

waypoints, altitude, airspeed, etc.

5

FCS

Yoke Control surfaces

Increasing Complexity

6

Example: F-22

• In 2007, 12 F-22s were

going from Hawaii to Japan.

• After crossing the IDL, all

12 experienced multiple crashes.

– No navigation – No fuel subsystems – Limited communications – Rebooting didn’t help

• F-22 has 1.7 million lines of

code

F-22 Raptor

Verification and Validation (V&V)

• Validation

– “Are we building the right system?” – Check if the system meet the requirements

• Verification

– “Are we building the system right?” – Check if the system meets the specification

• It is possible the a system is verified

correct but not useful (not valid)

8

requirements specification implementation

V & V Cost

9

Image credit: Dr. Guillaume Brat NASA Ames Research Center

Certification

• Convincing the certification authority that the

validation process is correct

• Largely process driven

– Shows that you followed a good process – Document everything – Review everything (with independence)

• Evidence driven

– Use formal methods and automated tools (model checkers, theorem provers, …) in place of independent reviewers

10

DO-178 B/C

• Software Considerations in Airborne Systems and

Equipment Certification

• A document used by certification authorities (FAA,

EASA) to certify avionics software

• Basic idea

– Access the safety implications of failure modes – Map failure modes to 5 safety levels (A to E)

• A: catastrophic – failure may cause a crash
• B: hazardous – failure has a negative impact on safety/perf.
• …

– Must satisfy a set “objectives” (with independence)

• E.g., algorithms are accurate, software partitioning is confirmed,

source code complies low-level requirements, …

11

DO-178C and Formal Methods

12

Image credit: Dr. Lucas Wagner, Honeywell

Avionics Architecture

• Federated architecture

– A function = a computer (box) – More functions  more boxes (computers)

• flight management, fuel management, flight

envelope protection, collision avoidance…

– Each box is uniquely designed for each specific aircraft

• custom hardware/software
• 100s km cabling

13

Image credit: ARTIST2 - Integrated Modular Avionics A380

Avionics in Airbus

14

Image credit: ARTIST2 - Integrated Modular Avionics A380

Integrated Modula Avionic (IMA)

• Use a set of standard computers
• Use a standard OS (ARINC 653)
• Use standard data communication network

(AFDX)

• Multiple applications can be executed on the

same computer

• Each computer can be configured to partition its

resources to serve multiple functions

15

Image credit: ARTIST2 - Integrated Modular Avionics A380

ARINC 653

• Avionics Application Standard Software

Interface (think POSIX for avionics)

• The software base of IMA
• Main idea: integrate software partitions with

different criticality levels on the same/communicating computational node.

• A set of OS/Hypervisor provisions for safe

partitioning and associated API.

16

ARINC 653

• Time partitioning

17

Image credit: http://www.cotsjournalonline.com/articles/view/100736

What about multicore?

• ARINC653 and time partitioning was designed

single-core systems in mind.

• Problems of executing multiple partitions in

parallel on multiple cores

– Cache, memory, bus are shared. – Isolation is not guaranteed – A critical partition may be delay by low critical partitions on different cores

18

Denial-of-Service Attack

• Delay execution time of time sensitive code

– E.g., real-time control software of a car – Observed >21X execution time increase on Odroid XU4 (*)

• Even after cache partitioning is applied

– Observed >10X increase on RPi 3 (**)

• Of a realistic DNN-based real-time control program

19

LLC Core1 Core2 Core3 Core4

bench co-runner(s)

(*) Prathap Kumar Valsan, Heechul Yun, Farzad Farshchi. “Taming Non-blocking Caches to Improve Isolation in Multicore Real-Time Systems.” In RTAS, IEEE, 2016. Best Paper Award (**) Michael Garrett Bechtel, Elise McEllhiney, Minje Kim, Heechul Yun. “DeepPicar: A Low-cost Deep Neural Network-based Autonomous Car.” In RTCSA, IEEE, 2018

Denial-of-Service Attack

20

[C] Michael Garrett Bechtel and Heechul Yun. Denial-of-Service Attacks on Shared Cache in Multicore: Analysis and Prevention. IEEE Intl. Conference

• n Real-Time and Embedded Technology and Applications Symposium (RTAS), IEEE, 2019. (to appear)

> 300X slowdown !!!

Multicore and Certification

• CAST32

– A position paper by FAA, EASA, and other certification agencies on multicore certification – Not a definite rule or guideline, but – Discuss “interference channels” of multicore – State objectives to meet for certification

21

MCP_Planning_1

• Identify the specific MCP processor
• Identify the number of active cores,
• Identify the MCP software architecture
• Identify dynamic features in software
• Identify whether the MCP is for IMA
• Identify whether the MCP support “Robust

Resource/Time Partitioning”

• Identify the methods and tools used for software

development/verification

22

MCP_Planning_2

• Describe how MCP shared resources will be

used, allocated, verified to avoid contention

• Identify hardware dynamic features

23

MCP_Resource_Usage_3

• The applicant has identified the interference

channels that could permit interference to affect the software applications hosted on the MCP cores, and has verified the applicant’s chosen means of mitigation of the interference.

– Two cases: MCP w/ or w/o Robust Partitioning

24

Robust Resource Partitioning

• Software partitions cannot contaminate

storage space for the code, I/O, data of other partitions (MMU, VM)

• Software partitions cannot consume more

than allocated resources

• Failures of hardware unique to a software

partition cannot cause adverse effect on the

• ther software partitions.

25

Robust Time Partitioning

• No software partition consumes more than its

allocated execution time on the core(s) on which it executes, irrespective of other partitions on different cores.

26

MCP_Resource_Usage_3

• Case 1: MCP Platforms With Robust Partitioning

– “…may verify applications separately on the MCP and determine their WCETs separately. “

• Case 2: All Other MCP Platforms

– “ … should be tested on the target MCP with all software components executing in the intended final configuration, …” – “… WCET should be determined by analysis and confirmed by test on the target MCP with all software components executing in the intended final configuration.”

27

MCP_Resource_Usage_4

• The applicant has identified the available

resources of the MCP and of its interconnect in the intended final configuration, has allocated the resources of the MCP to the software applications hosted on the MCP and has verified that the demands for the resources of the MCP and of the interconnect do not exceed the available resources when all the hosted software is executing on the target processor.

• NOTE: The need to use Worst Case scenarios is

implicit in this objective.

28

MCP_Software_1

• The applicant has verified that all the software

components hosted by the MCP comply with the Applicable Software Guidance. In particular, the applicant has verified that all the hosted software components function correctly and have sufficient time to complete their execution when all the hosted software is executing in the intended final configuration.

– TL;DR: Need logical and temporal correctness

29

MCP_Software_2

• The applicant has verified that the data and

control coupling between all the individual software components hosted on the same core or

• n different cores of the MCP has been exercised

during software requirement-based testing, including exercising any interfaces between the applications via shared memory and any mechanisms to control the access to shared memory, and that the data and control coupling is correct.

– TL;DR: need system-level testing

30

MCP_Error_Handling_1

• The applicant has identified the effects of

failures that may occur within the MCP and has planned, designed, implemented and verified means (which may include a ‘safety net’ external to the MCP) commensurate with the safety objectives, by which to detect and handle those failures in a fail-safe manner that contains the effects of any failures within the equipment in which the MCP is installed.

31

Safety-Net

• Assumption: MCP can fail
• Goal: “fail-safe” operation

– can safely fly and land, but not at 100% performance

• How?

– passive monitoring functions – active fault avoidance functions – control functions for recovery

32

Multicore and Certification

• Major research topic
• Research goal

– A) Achieve time predictability and isolation – B) Maximize throughput (as long as A. is met) – For multicore based real-time embedded systems – So that such systems can be certifiable

33

Outline

• Avionics
• Automotive Systems
• Other CPS Applications

34

Recap: Multicore and Certification

• CAST32

– A position paper by FAA, EASA, and other certification agencies on multicore certification – Not a definite rule or guideline, but – Discuss “interference channels” of multicore – State objectives to meet for certification

• Robust Resource/Time Partitioning

35

Automotive Systems

• 100s of processors (ECU)

36

Image credit: Simon Fürst, BMW, EMCC2015 Munich, adopted from OSPERT2015 keynote

Automotive Systems

• ECUs, sensors, actuators
• Many subsystems

– Anti-lock breaking systems, Electronic stability control, Adaptive cruise control, Adaptive light control, Lane departure warning, infotainment, … – For comports and safety

37

Image credit: Prof. Brandenburg

Increasing Complexity

• Today’s cars depend on software/computers

– Safe, dependable software is hard

38

Image source: https://hbr.org/resources/images/article_assets/hbr/1006/F1006A_B_lg.gif

Safety Challenge

• Unintended acceleration

– Caused several fatal accidents

• e.g., Aug. 2009 accident in California

– Toyota settled to pay $1.2B

• Potential causes

– Memory corruption – Unsafe software design

39

Safety Challenge

40

Automotive System Development

• Each subsystem (function)’s software and

hardware is built by a vendor (contractor)

• Car manufacturers (e.g., GM) integrate and

validate

• Problems

– Size, weight, and power issue – Lack of standards – Difficult to interoperate, share code, refine

41

Size, Weight, and Power (SWaP)

• Maximum performance with minimal resources

– Cannot afford too many or too power hungry ECUs

42

Figure source: OSPERT 2015 Keynote by Leibinger

AUTOSAR

• AUTOSAR – AUTomotive Open Systems

ARchitecture

• Same motivation: cope with complex with

standardization

• Define standard interfaces for software

independent of hardware ECU

43

AUTOSAR

• Improve interoperability

44

Image credit: AUTOSAR tutorial at autosar.org

AUTOSAR RTE

• POSIX for AUTOSAR.

– Define services and APIs for applications

45

Image credit: AUTOSAR tutorial at autosar.org

46

slide credit: AUTOSAR tutorial at autosar.org

Controller Area Network (CAN)

• Multi-master serial bus for connecting ECUs

– Up to 1Mbps

• De-factor comm. standard in automotive
• Safety critical controls

– E.g.) steering, breaking, throttle, …

47 Image credit: https://en.wikipedia.org/wiki/CAN_bus

CAN Networks and Vulnerability

• Set of ECU connected by CAN buses.
• CAN buses are designed for real-time (fixed priority messages), but not

security…

• Broadcast with no authentication field: any ECU connected to a CAN bus

broadcasts to all other ECU on the same bus. No way to determine the sender.

• Weak Access Control: there is a challenge-response sequence but the

codes must be known by all service centers to perform diagnostic = they are out in the open.

• ECU Firmware Update: the firmware of any ECU can be updated over

the CAN bus.

• Bridge nodes: there are different CAN buses (critical / non-critical), but

they are bridged by dedicated ECU nodes.

• Result: if you can hack any ECU, you can re-flash any other ECU…

48

External I/O Channels

49 Comprehensive Experimental Analyses of Automotive Attack Surfaces, USENIX Security, 2011

Autonomous Car

50

https://www.latimes.com/business/autos/la-fi-waymo-self-driving-california-20181030-story.html

Levels of Automation (SAE J3016)

• L1

– Some cars today

• L2

– Tesla

• L3

– Uber

• L4

– Waymo

• L5

– None

51

(SAE, "Taxonomy and Definitions for Terms Related to On- Road Motor Vehicle Automated Driving Systems.")

52

• S. Kato, E. Takeuchi, Y. Ishiguro, Y. Ninomiya, K. Takeda, and T. Hamada. ``An Open Approach to Autonomous

Vehicles,'' IEEE Micro, Vol. 35, No. 6, pp. 60-69, 2015. Link

Autoware

53

https://www.youtube.com/watch?v=zujGfJcZCpQ

Autoware

• Open-source software stack for self-driving

54

https://github.com/CPFL/Autoware

Autoware

55

https://youtu.be/gq8El7-36z0?t=896

56

https://arxiv.org/abs/1901.08567

Autoware

• Limitations

– Require detailed 3D map – Require accurate localization (~cm) in the map – Heavily rely on expensive Lidar sensor

• Cameras are supplementary

– Not the way human drives

57

Outline

• Avionics
• Automotive Systems
• Other CPS Applications

58

FDA regulation and medical devices

• Federal Drug Administration regulations are somehow

lacking compared to other federal agency (ex: FAA).

• April 2010 push: “Infusion Pump Improvement Initiative”

59

• Patient-controlled analgesia

– Nurses are expensive – Patient feels bad, press button, gets a shot of morphine – What if he presses the button too often?

Example: Ventilator

• Patient on ventilator (mechanically operates lungs)

during surgery.

• Surgeon asks assistant to take x-ray.

– Can’t take x-ray while lungs are moving (doctor always ask you to stop breathing…). – Anesthesiologist stops ventilator. – Assistant has trouble with x-ray – room is a cable mess.

60

• Anesthesiologist go help with

x-ray.

• Nobody turns the ventilator

back on…

Heart and Pacemaker

61

Modern Pacemaker?

62

Heart and Pacemaker Models

high-fidelity fitting Medtronic’ erified satisfies fice finite fluid flo erification

• rk’

Stateflo erification erification certification, erified specification Stateflo Stateflo Stateflo

63

Multiple Models

64

Timed Automata

• Example of verification tool: UPPAAL
• Based on the theory of Timed Automata
• Adds variables and channels.

– Main idea: reduce the number of states and simplify composition of automata

65

How are properties specified?

• Typically two ways:
• 1. Use another timed automata. Composed the two. Check

if you reach some state.

• 2. Use another formal language (ex: linear temporal logic).
• The verification engine is called a model-checker.

– Maintains a representation of states, clocks, variables (explicit

• r implicit)

– Compute which states can be reached from a given set of states (forward or backward)

66

Tissue Activation and Timed Automata Model

67

RRP

t<=Trrp

ERP

t<=Terp

t>=Trest t:=0 Act_path(i)! C(i):=1 Act_node(i)? t:=0 Act_path(i)! C(i):=1 Act_node(i)? Terp:=g(f(t)), C(i):=f(t) Act_path(i)! t:=0 t>=Terp t:=0 t>=Trrp t:=0 Rest

t<=Trest

defines ≥ defined defined ≥ erification define ∈ finishes modified. defined − profile

Path Model

Ante

t1<=Tante

Idle Retro

t2<=Tretro

Confilict Act_path(a)? Tante:=h(C(a)) t1:=0 Double Act_path(b)? Tretro:=h(C(b)) t2:=0 t1>=Tante Act_node(b)! t2>=Tretro Act_node(a)! Act_path(b)? Tretro:=h(C(b)) t2:=0 Act_path(a)? Tante:=h(C(a)) t1:=0

defines ≥ defined defined ≥ erification define ∈ finishes modified. defined − profile

68

Software Model

69

Other issues with medical equipment…

• 1. Interoperability

– Currently equipment of vendor X only works with other equipment of vendor X – Strong push for an open medical interoperability standard – Problem #1: if something goes wrong, who gets the blame (weak FDA regulations)? – Problem #2: equipment vendors have nothing to gain…

• 2. Wireless Communication

– Solve the cable mess – Problem: how to resist interference and jamming? – Some physical-layer techniques are promising (Ultra- Wide Bandwidth, Dynamic Frequency Selection…)

70

Other issues with medical equipment…

• General solution: stand-alone safety

– Design each component such that it is safe in isolation – Device must be able to maintain a safe state even if all communication is lost – Device must be able to maintain a safe state even if it receives incorrect information from other devices – Ex: ventilator should automatically turn on after a maximum amount of time!

71

Other CPS Examples

• Electric grid
• Manufacturing robots
• Nuclear plant control systems
• …

72

Automotive Systems

73

Image credit: Prof. Brandenburg

Example: Audi A4

• In 2014, Audi recalled 850,000 A4 cars due to

a software bug that prevented timely airbag deployment

74

http://www.autoblog.com/2014/10/23/audi-a4-airbag-recall/

What are the problems?

• 1. Lack of care

– Most attacks use conventional buffers overflow – Software simply isn’t checking for malicious inputs – People writing safety software are not used to think about security..

• 2. Interfaces are not clearly specified

– ECU development delegated to subsystem providers – Interfaces between components are not specified well- enough to check for malicious interaction

• 3. No separation among criticality levels

– Systems with different criticality are clearly isolated from a temporal perspective, but not a function one – Very hard to solve…

75

Autonomous Car

• Google, GM, ford, Audi, …

76

Source: http://on-demand.gputechconf.com/gtc/2015/presentation/S5870-Daniel-Lipinski.pdf

CAN Networks and Vulnerability

• Set of ECU connected by CAN buses.
• CAN buses are designed for real-time (fixed priority messages), but not

security…

• Broadcast with no authentication field: any ECU connected to a CAN bus

broadcasts to all other ECU on the same bus. No way to determine the sender.

• Weak Access Control: there is a challenge-response sequence but the

codes must be known by all service centers to perform diagnostic = they are out in the open.

• ECU Firmware Update: the firmware of any ECU can be updated over

the CAN bus.

• Bridge nodes: there are different CAN buses (critical / non-critical), but

they are bridged by dedicated ECU nodes.

• Result: if you can hack any ECU, you can re-flash any other ECU…

77

Car Hacking

• Comprehensive Experimental Analysis of Automotive Attack Surfaces
• Scary stuff: an attacker can very easily gain control over all electronics

systems in your car – Start/stop/rev up/rev down engine – Brake/disable braking – Open doors – Determine your position through GPS – Listen to whatever you say in the car (all without your knowledge)

• Infiniti Q50 has steer-by-wire, so an attacker can remotely start and

drive your car from your parking lot to his safehouse without moving from his couch…

• At least handbrake is completely manual…

78

High Computational Demand

• “Approximately 1 GB of data will need to be

processed each second in the car’s real-time

• perating system. This data will need to be

analyzed quickly enough that the vehicle can react to changes in its surroundings in less than a second.”

79

Intel, “Technology and Computing Requirements for Self-Driving Cars”