Cyber-Physical Specification Mismatch Identification with ... · Cyber-Physical Specification...

transcript

Cyber-Physical Specification Mismatch Identification with Dynamic Analysis

Taylor T. Johnson

CPS V&V I&F Workshop 2014December 12, 2014

Acknowledgement: AFRL Visiting Faculty Research Program (VFRP)

Systems and Software Reuse

• Many CPS industries reuse existing designs in new products

• Automotive vehicles by model year and across models

• Medical devices leveraging prior FDA approvals

• Software by version number• Aerospace (pay $15 million per LOC

then proceed to Go/Jail…)• …

• Cyber upgrades• Physical upgrades

• System upgrades: mixture of cyber and physical upgrades

• Example problems: 1996 Ariane 5 flight 501, 2011 NHTSA recall of 2.5 million Honda vehicles, …

[http://www.arianespace.com/news-image_library/photo_library_files/ariane5/web/VA212-launch-lr.jpg]

Ariane 5 Cyber-Physical Specification Mismatches

• “The design of the Ariane 5 SRI [Inertial Reference System] is practically thesame as that of an SRI which is presently used on Ariane 4, particularly asregards the software.”

• “The value of BH [Horizontal Bias] was much higher than expected becausethe early part of the trajectory of Ariane 5 differs from that of Ariane 4 andresults in considerably higher horizontal velocity values.”

• “Ariane 5 has a high initial acceleration and a trajectory which leads to abuild-up of horizontal velocity which is five times more rapid than forAriane 4. The higher horizontal velocity of Ariane 5 generated, within the40-second timeframe, leads to the excessive value which caused the inertialsystem computers to cease operation.”

• “In Ariane 4 flights using the same type of inertial reference system therehas been no such failure because the trajectory during the first 40 seconds offlight is such that the particular variable related to horizontal velocitycannot reach, with an adequate operational margin, a value beyond thelimit present in the software.”

[ARIANE 5 Flight 501 Failure, Report by the Inquiry Board, Paris 19 July 1996, https://www.ima.umn.edu/~arnold/disasters/ariane5rep.html] 3

Ariane 4 vs Ariane 5

• Ariane 4• Thrust (stage 0): 3.034 MN• LEO Payload: 5Mg-7.6Mg

• Ariane 5• Thrust (stage 0): 12.940 MN• LEO Payload: 16Mg-21Mg

[http://en.wikipedia.org/wiki/Ariane_5] [http://en.wikipedia.org/wiki/Ariane_4]

Ariane 5 Specification Mismatch Result?

• “The reason for the threeremaining variables, includingthe one denoting horizontalbias, being unprotected wasthat further reasoning indicatedthat they were either physicallylimited or that there was alarge margin of safety, areasoning which in the case ofthe variable BH turned out to befaulty.”

[ARIANE 5 Flight 501 Failure, Report by the Inquiry Board, Paris 19 July 1996, https://www.ima.umn.edu/~arnold/disasters/ariane5rep.html]Image: [http://www.esa.int/spaceinimages/Images/2009/09/Explosion_of_first_Ariane_5_flight_June_4_1996]

Question: can we automatically identify cyber-physical specification mismatches from embedded software and physical models?

Can we find physical assumptions in software that are invalid?

Invalid assumption about physical specification made in software

(Non-Autonomous) Cars

Date: August 4, 2011Notice: #11V395Device: Honda Accord (2005-

2010), CR-V (2007-2010), Element (2005-2008)

Units: ~1.5 million US (~2.5 million globally)

Problem: “…may cause an engine stall and/or cause the vehicle to move when the gear selector is in park…”

Remedy: update to automatic transmission control module (TCM) software

[NHTSA, Recall Notice #11V395, http://www.safercar.gov/]

Image: [http://www.netcarshow.com/honda/2010-accord_crosstour/800x600/wallpaper_02.htm] 6

Cyber-Physical Defects

“…specifications for the secondary shaftbearing outer race material and shape weremodified in order to accommodateincreased engine torque. Thesemodifications, which improved the long-term durability of the component butreduced its resistance to shock, are notappropriately addressed in the automatictransmission control module software ofthe affected vehicles…”

[Defect Notice, Aug. 3, 2011, Part 573,

http://www-odi.nhtsa.dot.gov/acms/cs/jaxrs/download/doc/ACM17689918/RCDNN-11V395-2852.pdf]

Physical Specification

CyberSpecification

Outline

�𝓐𝓐 ⊨ �𝜑𝜑?(Model

Checker)

𝓐𝓐: Cyber-PhysicalModels

(Simulink)

Instrument(Hynger)

Execute/ Simulate

(Simulink)

�𝚽𝚽: Infer Candidate Invariants (Daikon)

�𝚽𝚽𝐏𝐏: Project �𝜑𝜑onto Physical

Variables (Hynger)

Cyber-Physical

Specification Mismatches

𝚽𝚽: Actual Invariants

𝚯𝚯: Test Suite / Initial

Conditions

Yes𝜑𝜑 ∈ 𝚽𝚽�𝜑𝜑 ∈ �𝚽𝚽

𝓐𝓐 �𝓐𝓐

θ ∈ 𝚯𝚯

𝚻𝚻

�𝜑𝜑 ∈ �𝚽𝚽,�𝓐𝓐

�𝜑𝜑P ∈ �𝚽𝚽𝐏𝐏,𝜎𝜎P ∈ 𝚺𝚺𝐏𝐏 �𝜑𝜑P ⇒ 𝜎𝜎P?

(SMT-Solver)

Outline

Checker)

(Simulink)

Instrument(Hynger)

Execute/ Simulate

(Simulink)

Variables (Hynger)

Cyber-Physical

Conditions

θ ∈ 𝚯𝚯

𝚻𝚻

(SMT-Solver)

Cyber-Physical Models and Variables

• Models do not necessarily disambiguate between cyber and physical components

• One idea is to do this: subtyping, e.g., double as physical, etc.typedef double physical;

typedef physical temperature;

//@ strong type invariant temp_in_celsius(temperature t) = t >= -273.15;

• Partition variables (and state space) of system into cyber and physical• Cyber variables: only functions of cyber variables (e.g., taint analysis

[transitive closure of dependency graph defined by transition relation] shows these are only functions of cyber variables)

• Physical variables: only functions of physical variables• Cyber-Physical variables: cyber variables that are functions of

physical variables and vice-versa

Cyber-Physical Specification Mismatches

• Assumption for our approach: specifications are invariants• ΣP: Physical specification (formulas over physical variables)

• Assumptions about physical environment• Examples: gravitational force, temperature bounds, time constants, …

• Requirements for physical system and components• Examples: motor torque limits, temperature bounds of components, sampling rates, …

• ΣC: Cyber specification (formulas over cyber variables)• Assumptions about software-physical interfaces

• Examples: ADC resolution, DAC resolution, sampling rates, …• Requirements for software system, components, software-software interfaces

• Examples: data formats, control flow, …

• Cyber-physical specifications (cyber + physical specs, and formulas over cyber-physical variables)

• Physical specification from the perspective of software• Hypothesis for mismatches: physical specification from perspective of

software implies actual physical specification (if not, mismatch)

Outline

Checker)

(Simulink)

Instrument(Hynger)

Execute/ Simulate

(Simulink)

Variables (Hynger)

Cyber-Physical

Conditions

θ ∈ 𝚯𝚯

𝚻𝚻

(SMT-Solver)

SLSF CPS Example: Buck Converter

Buck Converter Plant

Buck: 𝑽𝑽𝒐𝒐 ≤ 𝑽𝑽𝑺𝑺𝓐𝓐: �̇�𝑥 = 𝐴𝐴𝜎𝜎𝑥𝑥 + 𝐵𝐵𝜎𝜎𝑥𝑥 ∈ ℝ𝑛𝑛, 𝐴𝐴𝜎𝜎 interval matrix, 𝐵𝐵𝜎𝜎 input interval vector𝐼𝐼 ⊆ ℝ𝑛𝑛 set of initial states𝑃𝑃 ⊆ ℝ𝑛𝑛

Example 𝓐𝓐: buck-converter

𝑥𝑥 = 𝑖𝑖𝐿𝐿𝑉𝑉𝑐𝑐

,𝐴𝐴𝑐𝑐 = 𝐴𝐴𝑜𝑜 =0 −

1𝐿𝐿

1𝐶𝐶

−1𝑅𝑅𝐶𝐶

𝐵𝐵𝑐𝑐 =𝑉𝑉𝑠𝑠𝐿𝐿0

, 𝐵𝐵𝑜𝑜 = 00

𝑃𝑃: Output voltage always near setpoint

VSiL Vo

S open

S closed

Dynamics

Buck Converter SLSF Plant Model

Buck Converter Reachability in SpaceEx

• Parameter variation

• Reachable states

Ac = Ao = [0,0] [−21053,−19048][38095,42105] [−44321,−36281]

𝐵𝐵𝑐𝑐 = [19048,21053][0,0] , 𝐵𝐵𝑜𝑜 = [0,0]

[T. Johnson, Z. Hong, A. Kapoor, IEEE PECI 2012]

[S. Hossain, S. Dhople, T. Johnson, IEEE PECI 2013][L. Nguyen, T. Johnson, ARCH 2014]

Component Symbol RangeResistor 𝑅𝑅 [0.95, 1.05]ΩCapacitor 𝐶𝐶 [23.75, 26.25]𝜇𝜇𝐹𝐹Inductor 𝐿𝐿 [47.5, 52.5]𝜇𝜇𝐻𝐻

Buck Converter Reachability in HyCreate

Hysteresis Controller Model

Sensor Model

Outline

Checker)

(Simulink)

Instrument(Hynger)

Execute/ Simulate

(Simulink)

Variables (Hynger)

Cyber-Physical

Conditions

θ ∈ 𝚯𝚯

𝚻𝚻

(SMT-Solver)

Outline

Checker)

(Simulink)

Instrument(Hynger)

Execute/ Simulate

(Simulink)

Variables (Hynger)

Cyber-Physical

Conditions

θ ∈ 𝚯𝚯

𝚻𝚻

(SMT-Solver)

Motivating Example (C and ACSL [Frama-C])

// pre: n >= 0

// post: return s is the sum of b: s = sum j : 0 <= j < n : b[j]

// loop invariant: 0 <= i <= n and s = sum j : 0 <= j < i : b[j]

@ requires n >= 0; // at least 0 elements

@ requires \valid(b+ (0..n−1)); // all elements exist

@ assigns \nothing; // no side effects

@ ensures \result == \sum(0,n−1,\lambda integer j; b[j]);

@ ensures \result >= 0; // false, array may be negative

int sum_array(int b[], unsigned int n) {

int i;

int s = 0;

/*@ loop invariant \forall integer j;

(0 <= i <= n) ==> s == \sum(0,i-1,\lambda integer j; b[j]); */

for (i = 0; i < n; i++) {

s += b[i];

return s;

Daikon Trace Input Format

..sum_array():::EXIT0 // postconditionthis_invocation_nonce1b0x51fb0401b[..][ 3 1 2 0 3 0 1 2 4 1 2 2 0 4 3 1 0 1 2 1 1 3 2 4 2 0 2 3 2 0 4 2 2 3 4 2 3 1 1 2 4 3 1 4 4 2 3 4 0 0 3 1 1 0 1 3 2 0 1 1 0 0 4 2 1 0 1 4 3 2 4 0 2 0 4 2 4 4 3 0 2 3 1 3 3 4 3 1 4 4 2 0 1 3 4 2 1 1 4 4 ]1n1001return2041

[“Dynamically discovering likely program invariants to support program evolution” by Michael D. Ernst, Jake Cockrell, William G. Griswold, and David Notkin. IEEE Transactions on Software Engineering, vol. 27, no. 2, Feb. 2001, pp. 99-123.] 23

Daikon Output for Motivating Example

============== Precondition..sum_array():::ENTER::array_max == 1000b has only one valueb[] elements >= 0n == 100size(b[]) == 100============== Postcondition..sum_array():::EXIT::array_max == orig(::array_max)b[] == orig(b[])return == sum(b[])sum(b[]) == sum(orig(b[]))::array_max == 1000b[] elements >= 0

Problems using Daikon with C and CPS

• Daikon’s provided C instrumentation tool is Kvasir/Fjalar• Kvasir uses Valgrind to instrument binaries compiled from C

programs• Basically adding appropriate print statements for variable values

at function calls and returns• Problem: Valgrind has architectural assumptions (restricted to

x86/x86-64, DWARF binary format, best if no optimizations [-O0], …)

• Architecture independent solution: instrument Simulink/Stateflow diagrams

• May later be compiled for implementation to various platforms using code generation methods

• Added plus: SLSF blocks may represent arbitrary systems underneath (black box vs. white box) 25

Informal and Formal Models

• Internals abstracted away• Black box: unknown• White box: known

• Description defined entirely in terms of input-output relations

• One approach: SLSF block may be formally modeled as a hybrid input/output automaton (HIOA)

• Set of input variables, 𝑈𝑈• Set of output variables, 𝑌𝑌• Black box: unknown internals• White box: known internals

• Needed to check if candidate invariants are actual invariants

[Lynch, N.; Segala, R. & Vaandrager, F. Hybrid I/O automata Information and Computation, 2003, 185, 105-157]

HyLink: [K. Manamcheri, S. Mitra, S. Bak, M. Caccamo. A step towards verification and synthesis from simulink/stateflow models. HSCC 2011]

𝜏𝜏 clock𝑥𝑥 vector: voltage, current (and clock)𝐷𝐷 duty cycle𝑇𝑇 control/switching period

Outline

Checker)

(Simulink)

Instrument(Hynger)

Execute/ Simulate

(Simulink)

Variables (Hynger)

Cyber-Physical

Conditions

θ ∈ 𝚯𝚯

𝚻𝚻

(SMT-Solver)

Outline

Checker)

(Simulink)

Instrument(Hynger)

Execute/ Simulate

(Simulink)

Variables (Hynger)

Cyber-Physical

Conditions

θ ∈ 𝚯𝚯

𝚻𝚻

(SMT-Solver)

Hynger Overview

• Hynger: HYbrid iNvariant GEneratoR• Written in Matlab using Simulink/Stateflow (SLSF) APIs• Input: SLSF diagram• Output: instrumented SLSF diagram

• Simulation-loop callback function added that generates traces of executions in the input format of Daikon

Instrument(Hynger)

SLSF Block Preconditions and Postconditions

• Function calls• Precondition: state before call• Postcondition: state after call

• What is the SLSF analog to function calls?• Several ways to define this, but we use the following• Precondition: state before block execution (at time 𝑡𝑡)• Postcondition: state after block execution (after time advances, 𝑡𝑡′ = 𝑡𝑡 + 𝛿𝛿 )

• Time is defined as the simulation time and steps thereof• Dependent upon particular differential equation solver• Fixed time step• Adaptive time step

• SLSF diagrams support adding callback functions that are executed at each simulation time step

• Major time step• Minor time step

SLSF Block Callbacks

• Precondition callback• Called: “Before a block's Outputs method executes.”

add_exec_event_listener(blk, 'PreOutputs', @daikon_dtrace_callback_pre);

• Postcondition callback• Called: “After a block's Outputs method executes.”

add_exec_event_listener(blk, 'PostOutputs', @daikon_dtrace_callback_post);

[http://www.mathworks.com/help/simulink/slref/add_exec_event_listener.html]

[http://www.mathworks.com/help/simulink/sfg/how-s-functions-work.html ]

[http://www.mathworks.com/help/simulink/ug/simulating-dynamic-systems.html]31

SLSF Simulation Loop

[http://www.mathworks.com/help/simulink/sfg/how-s-functions-work.html ] 32

Buck Converter Daikon Trace - Quantizer

// Precondition

..Quantizer:::ENTER::time

3.3333e-05

47 // output1

::x_in1

47.9622

// Postcondition

..Quantizer:::EXIT0::time

3.3333e-05

48 // output1

::x_in1

47.9622

Buck Converter Inferred Invariant Examples

• Voltage Sample Sum Invariant• Sensor modeled as a sample and hold type• Moving average filter takes N samples, sums them, and averages• Daikon finds sum invariant within controller

..Controller:::EXIT ::sum == sum(::samples[])

• Voltage Output• Output voltage is within tolerance band• 𝑉𝑉𝑜𝑜 𝑡𝑡 = 𝑉𝑉𝑟𝑟𝑟𝑟𝑟𝑟 𝑡𝑡 ± 𝜖𝜖

Outline

Checker)

(Simulink)

Instrument(Hynger)

Execute/ Simulate

(Simulink)

Variables (Hynger)

Cyber-Physical

Conditions

θ ∈ 𝚯𝚯

𝚻𝚻

(SMT-Solver)

Outline

Checker)

(Simulink)

Instrument(Hynger)

Execute/ Simulate

(Simulink)

Variables (Hynger)

Cyber-Physical

Conditions

θ ∈ 𝚯𝚯

𝚻𝚻

(SMT-Solver)

Buck Converter Example Mismatch

• Physical Specifications ΣP• Converter dynamics and source voltage ripple determine hysteresis

band• Converter dynamics: RLC values• Source voltage 𝑉𝑉𝑠𝑠 has a given ripple, 𝛿𝛿: [𝑉𝑉𝑠𝑠 𝑡𝑡 − 𝛿𝛿,𝑉𝑉𝑠𝑠 𝑡𝑡 + 𝛿𝛿]• Output voltage within tolerance band 𝜖𝜖 of reference voltage:

𝑉𝑉𝑜𝑜 𝑡𝑡 = 𝑉𝑉𝑟𝑟𝑟𝑟𝑟𝑟 𝑡𝑡 ± 𝜖𝜖

• Compute controller hysteresis band 𝑉𝑉𝑡𝑡𝑜𝑜𝑡𝑡 based on these physical specifications

• Candidate Mismatch• Software may use wrong hysteresis band 𝑉𝑉𝑡𝑡𝑜𝑜𝑡𝑡 to achieve output

voltage (𝑉𝑉𝑜𝑜 𝑡𝑡 ) meets desired reference voltage and ripple

Hysteresis Controller Model

Dynamic Analysis Tradeoffs and Considerations

• More tests (increased coverage, etc.) implies increased likelihood that observed traces correspond to all program behaviors

• Candidate invariants versus actual invariants: One program trace example• Array has one set of elements• Sum is one particular value• Size is one particular value• Etc.

• Expense of more tests• Possibly more candidate invariants

• May still be useful, but may be highly redundant• More tests (potentially a manual process, or computationally expensive to generate)• More runtime

• In test generation and invariant inference• Runtime growth:

• quadratic in number of variables at a program point (linear in number of invariants checked/discovered)

• linear in number of samples or values (test suite size)• linear in number of program points

2nd International Workshop onApplied Verification for Continuous and Hybrid Systems

(ARCH), CPSWeek 2015Verification of continuous and hybrid systems is increasing in importance dueto new cyber-physical systems that are safety- or operation-critical. Thisworkshop addresses verification techniques for continuous and hybrid systemswith a special focus on the transfer from theory to practice.• Topics include, but are not limited to

• Proposals for new benchmark problems (not necessarily yet solvable)• Tool presentations• Tool executions and evaluations based on ARCH benchmarks• Experience reports including open issues for industrial success

http://cps-vo.org/group/ARCH/

The paper with the most promising benchmark results receives a prize of 500Euros sponsored by Robert Bosch GmbH, Germany. The winner is preselectedby the program committee and determined by an audience voting.

• Submission deadline: February 12, 2015

ARCH 2015 Hyst Tool for Executable Benchmarks

• ARCH contributors (and anyone) may use our Hyst tool (joint work with Stanley Bak and Sergiy Bogomolov): http://verivital.uta.edu/hyst/

• Large benchmark suite (and support for CIF via SpaceEx) and scripts to batch tool runs

Hyst Van Der Pol Example

Flow* HyCreate

Thank You

Checker)

(Simulink)

Instrument(Hynger)

Execute/ Simulate

(Simulink)

Variables (Hynger)

Cyber-Physical

Conditions

θ ∈ 𝚯𝚯

𝚻𝚻

(SMT-Solver)

• Acknowledgements• Steven Drager, AFRL• Stanley Bak, AFRL

• Taylor Johnson• Taylor.Johnson@uta.edu• http://www.TaylorTJohnson.com

Extra Slides

Invariants from Single Traces

• CPS typically involve the repeated application of a controller through a single execution

• Let 𝑢𝑢 represent the controller action (computation and update of actuators)• Periodically controlled / time-triggered (with period Δ)• Aperiodically controlled / event-triggered

• Can discover invariants over controller at each controller action 𝑢𝑢• Supposing controller consists of software, multiple functions, etc., can find

invariants over all these subcomponents

𝑢𝑢 𝑢𝑢 𝑢𝑢 𝑢𝑢 𝑢𝑢𝑢𝑢 𝑢𝑢

… …

Invariants from Multiple Traces

• Sometimes insufficient to consider single traces• Some functions / blocks may only be called once

• Example: finding invariants from unit tests, typically involve a single invocation of a function

• Simulink examples• Initial condition may be a constant• Nondeterminism allows for many valid executions, need to generalize from all these

… …𝑢𝑢 𝑢𝑢 𝑢𝑢 𝑢𝑢 𝑢𝑢𝑢𝑢 𝑢𝑢

… …

1.5 ≤ 𝑥𝑥 ≤ 2.52.3 ≤ 𝑥𝑥 ≤ 2.8

1.2 ≤ 𝑥𝑥 ≤ 1.61.5 ≤ 𝑥𝑥 ≤ 2.5

0.3 ≤ 𝑥𝑥 ≤ 3.11.5 ≤ 𝑥𝑥 ≤ 2.50.3 ≤ 𝑥𝑥 ≤ 3.1

Instrumentation Overhead

• Valgrind: 2x to 100x• Hynger: 10x to 1000x

SLSF Trace

Cyber-Physical Specification Mismatch Identification with ... · Cyber-Physical Specification...

Documents