Analysis Contracts for CPS

Presenter: Dionisio de Niz1

dionisio@sei.cmu.edu

CPS V&V Workshop

Team: Ivan Ruchkin2, Sagar Chaki1,

David Garlan2

1Software Engineering Institute & 2School of Computer Science

2

Copyright 2014 Carnegie Mellon University This material is based upon work funded and supported by the Department of Defense under Contract No. FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the United States Department of Defense. NO WARRANTY. THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN “AS-IS” BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT. This material has been approved for public release and unlimited distribution except as restricted below. This material may be reproduced in its entirety, without modification, and freely distributed in written or electronic form without requesting formal permission. Permission is required for any other use. Requests for permission should be directed to the Software Engineering Institute at permission@sei.cmu.edu. Carnegie Mellon® is registered in the U.S. Patent and Trademark Office by Carnegie Mellon University. DM-0001998

3

Motivation

The development of Cyber-Physical Systems (aircrafts, cars, trains, robots, etc.) increasingly relies on many types of analyses from different disciplines for assurance purposes

• Control stability, scheduling, logic, thermal, power, aerodynamics, etc.

Large CPS are integrated out of components developed by suppliers that use their own analysis methods and make their own assumptions

Analysis assumption mismatches are discovered late in the system integration phase

• Difficult and costly to solve

4

Boeing 787 Suppliers

Kawasaki

Spirit

Saab

Goodrich

Rolls Royce

Boeing Australia

Mitsubishi

Boeing US Alenia

Alenia

KAL-ASD

Latecoere

Source: Boeing / Reuters

5

Inter-Domain Analyses Interactions

Cha

rge

Dis

ch

arg

e

Source: National Renewable Energy Laboratory

main(){

for(i=0;;)

…

}

main(){

for(i=0;;)

…

}

main(){

for(i=0;;)

…

}

Scheduling +

Frequency

Scaling

Battery Recharge Scheduling

Selected

Voltage Cell Interconnects

Thermal Runaway Analysis

6

Analysis Contracts

Sensor

Sampling

PID

Controller

Actuator

Controller

Sensor

Board CPU

Actuator

Board

Comm Protocol (reliable/unreliable)

Control Stability Schedulability

Pow

er

Exec T

ime

Frequency Scaling

Discharge Charge

Battery Sched

Tem

p

Thermal runaway

Assumption

Guarantee

Read/write Read/write

Read/w

rite

R

ead/w

rite

deadlock

Model checking

Read/write

AADL

7

Analysis Contracts Structure

AADL Model

Domain (e.g. in SPIN)

Analysis

Plugin Analysis

Plugin

Domain (e.g. in SMT)

Analysis

Plugin Analysis

Plugin

Contract

(Annex) Contract

(Annex)

Contract

(Annex)

Contract

(Annex)

8

Contract Semantic Basis

Domain (𝒜, 𝒮, ℛ, 𝒯, ⋅ 𝜎)

• Sorts 𝒜 = 𝐴1, 𝐴2, … , e.g. Booleans, Integers, Threads, Priorities

• Static Properties : 𝒮 = 𝑆𝑖 , 𝑆𝑖: 𝐴1 × ⋯ × 𝐴𝑗 ↦ 𝐴𝑘

— Design-time invariants, Regular operators: (∧, ℬ × ℬ ↦ ℬ)

• Runtime Properties : ℛ = 𝑅𝑖 , 𝑅𝑖: 𝐴1 × ⋯ × 𝐴𝑗 ↦ 𝐴𝑘

— Evolving valuation at different states q: q(𝑅𝑖)

• Domain execution semantics: 𝒯

— Infinite sequence of assignments to runtime properties (executions)

• Domain interpretation of sorts/static properties: ⋅ 𝜎

— E.g. allowed schedulers, some left uninterpreted

Architectural Model Interpretation: ⋅ 𝑀 on 𝒜, 𝒮, 𝒯

• E.g. threads and periods: 𝑇 𝑀 = 𝑡1, 𝑡2 ; 𝑃𝑒𝑟 𝑀 = {𝑡1 ↦ 10, 𝑡2 ↦ 20}

Executions of system defined by M: 𝒯 𝑀

• Combining ⋅ 𝜎 , ⋅ 𝑀 into ⋅

• Each state q in possible states Q maps 𝑅𝑖 to function 𝑞 𝑅𝑖 : 𝐴1 × ⋯ × 𝐴𝑗 ↦ 𝐴𝑘

• With all infinite sequence of states 𝑄𝜔

• 𝒯 𝑀 ⊆ 𝑄𝜔

9

Contract Language

Contract formulas

• Given domain 𝜎 = (𝒜, 𝒮, ℛ, 𝒯, ⋅ 𝜎),

• ℱ𝜎 ∷= ∀ 𝑣1, … , 𝑣𝑗 ⋅ 𝜙 ∃ 𝑣1, … , 𝑣𝑗 ⋅ 𝜙 ∀ 𝑣1, … , 𝑣𝑗 ⋅ 𝜙: 𝜓|∃𝑣1, … , 𝑣𝑗 ⋅ 𝜙: 𝜓

— 𝑣𝑖: 𝐴𝑖, 𝜙: static (first order) formula

— 𝜓 : LTL formula

Contract 𝐶 = (𝐼, 𝑂, 𝐴, 𝐺)

• 𝐼 ⊆ (𝒜 ∪ 𝒮): Sorts and properties read by the analysis

• 𝑂 ⊆ (𝒜 ∪ 𝒮): Sorts and properties written by the analysis

• 𝐴 ⊆ ℱ𝜎: assumptions: must be true in input

• 𝐺 ⊆ ℱ𝜎: guarantees: must be true in output

10

Contract Verification

Given model M and set of analyses 𝒜𝒩 = {𝐴𝑛𝑖}:

• For 𝐴𝑛𝑖 . 𝐶 = 𝐼, 𝑂, 𝐴, 𝐺 : M application to 𝐴𝑛𝑖 iff

— ∀ 𝑎 ∈ 𝐴 ⋅ 𝑀 ⊨ 𝑎, ∀ 𝑔 ∈ 𝐺 ⋅ Ani M ⊨ 𝑔

Valid analysis ordering: no dependencies from later analysis

• Contract (& analysis) dependency: d Ci, Cj : Ci. I ∩ 𝐶𝑗 . 𝑂 ≠ ∅

Contract Formulas

• First order: in SMT (Z3)

• LTL : Model checker

• FOL + LTL: Generate all solutions for FOL, check LTL in each

11

Example: Surveillance Aircraft

Analysis

Security: tasks of different level

to different processor

Scheduling: meet all deadlines

Freq. Scaling: minimize power

Logic: no deadlocks or race

conditions

Battery scheduling: meet

battery lifetime

Battery thermal: no runaways

main(){

for(i=0;;)

…

}

main(){

for(i=0;;)

…

}

main(){

for(i=0;;)

…

}

Security: Top Secret Security: Secret

Battery

Software

Processors

12

Surveillance Aircraft Contracts

Security Analysis

• 𝐴𝑛𝑠𝑒𝑐 . 𝐶: 𝐼 = 𝑇, 𝑇ℎ𝑆𝑒𝑐𝐶𝑙 , 𝑂 = 𝑁𝑜𝑡𝐶𝑜𝑙𝑜𝑐 , 𝐴 = ∅, 𝐺 = {𝑔}

— 𝑔: ∀ 𝑡1, 𝑡2 ⋅ 𝑇ℎ𝑆𝑒𝑐𝐶𝑙 𝑡1 ≠ 𝑇ℎ𝑆𝑒𝑐𝐶𝑙 𝑡2 ⇒ 𝑡1 ∈ 𝑁𝑜𝑡𝐶𝑜𝑙𝑜𝑐(𝑡2)

Multiprocessor scheduling: (Binpacking + scheduling)

• 𝐴𝑛𝑠𝑐ℎ𝑒𝑑 . 𝐶: 𝐼 = 𝑇, 𝐶, 𝑁𝑜𝑡𝐶𝑜𝑙𝑜𝑐, 𝑃𝑒𝑟, 𝑊𝐶𝐸𝑇, 𝐷𝑙𝑖𝑛𝑒 , 𝑂 = 𝐶𝑃𝑈𝐵𝑖𝑛𝑑 , 𝐴 = ∅, 𝐺 = {𝑔}

— 𝑔: ∀ 𝑡1, 𝑡2 ⋅ 𝑡1 ∈ 𝑁𝑜𝑡𝐶𝑜𝑙𝑜𝑐 𝑡2 ⇒ 𝐶𝑃𝑈𝐵𝑖𝑛𝑑 𝑡1 ≠ 𝐶𝑃𝑈𝐵𝑖𝑛𝑑(𝑡2)

Frequency Scaling

• 𝐴𝑛𝑓𝑟𝑒𝑞𝑠𝑐 . 𝐶: 𝐼 = 𝑇, 𝐶, 𝐶𝑃𝑈𝐵𝑖𝑛𝑑, 𝐷𝑙𝑖𝑛𝑒 , 𝑂 = 𝐶𝑃𝑈𝐹𝑟𝑒𝑞 , 𝐺 = ∅, 𝐴 = {𝑎}

— 𝑎: ∀𝑡1, 𝑡2 ⋅ 𝐶𝑃𝑈𝐵𝑖𝑛𝑑 𝑡1 = 𝐶𝑃𝑈𝐵𝑖𝑛𝑑 𝑡2 : 𝐺(𝐶𝑎𝑛𝑃𝑟𝑚𝑝𝑡 𝑡1, 𝑡2 ⇒ 𝐷𝑙𝑖𝑛𝑒 𝑡1 < 𝐷𝑙𝑖𝑛𝑒(𝑡2)

Model checking periodic program (REK):

• 𝐴𝑛𝑟𝑒𝑘. 𝐶: 𝐼 = 𝑇, 𝐶, 𝑃𝑒𝑟, 𝐷𝑙𝑖𝑛𝑒, 𝑊𝐶𝐸𝑇, 𝐶𝑃𝑈𝐵𝑖𝑛𝑑 , 𝑂 = 𝑇ℎ𝑆𝑎𝑓𝑒 , 𝐺 = ∅, 𝐴 = {𝑎1, 𝑎2}

• 𝑎1: ∀𝑡 ⋅ 𝑃𝑒𝑟 𝑡 = 𝐷𝑙𝑖𝑛𝑒 𝑡 , 𝑎2: ∀𝑡1, 𝑡2 ⋅ 𝐺(𝐶𝑎𝑛𝑝𝑟𝑚𝑝𝑡 𝑡1, 𝑡2 ⇒ 𝐺 ¬𝐶𝑎𝑛𝑃𝑟𝑚𝑝𝑡 𝑡2, 𝑡1 )

Thermal runaway:

• 𝐴𝑛𝑡ℎ𝑒𝑟𝑚 . 𝐶: 𝐼 = 𝐵, 𝐵𝑎𝑡𝑅𝑜𝑤𝑠, 𝐵𝑎𝑡𝐶𝑜𝑙𝑠, 𝑉𝑜𝑙𝑡𝑎𝑔𝑒 , 𝑂 = 𝐾 , 𝐴 = ∅, 𝐺 = ∅

Battery Scheduling

• 𝐴𝑛𝑏𝑠𝑐ℎ𝑒𝑑 . 𝐶: 𝐼 = 𝐵, 𝐵𝑎𝑡𝑅𝑜𝑤𝑠, 𝐵𝑎𝑡𝐶𝑜𝑙𝑠 , 𝑂 = 𝐵𝑎𝑡𝐶𝑜𝑛𝑛𝑆𝑐ℎ𝑒𝑑𝑃𝑜𝑙, 𝐻𝑎𝑠𝑅𝑒𝑞𝐿𝑖𝑓𝑒𝑡𝑖𝑚𝑒, 𝑆𝑒𝑟𝑖𝑞𝑙𝑅𝑒𝑞, 𝑃𝑎𝑟𝑎𝑙𝑅𝑒𝑎 , 𝐴 = ∅, 𝐺 ={𝑔}

• 𝑔: 𝐺(𝐾 0 × 𝑇𝑁 0 + 𝐾 1 × 𝑇𝑁 1 + 𝐾 2 × 𝑇𝑁 2 + 𝐾 3 × 𝑇𝑁 3 ≥ 0)

13

Satisfying Assumptions in Specific System: Frequency Scaling

𝑎: ∀𝑡1, 𝑡2 ⋅ 𝐶𝑃𝑈𝐵𝑖𝑛𝑑 𝑡1 = 𝐶𝑃𝑈𝐵𝑖𝑛𝑑 𝑡2 : 𝐺(𝐶𝑎𝑛𝑃𝑟𝑚𝑝𝑡 𝑡1, 𝑡2 ⇒ 𝐷𝑙𝑖𝑛𝑒 𝑡1 < 𝐷𝑙𝑖𝑛𝑒(𝑡2)

P D

P=D

P=D

P=D

DMS≠RMS

DMS=RMS

EDF≠RMS

EDF=RMS

P=D, Harmonic, Sync

14

Satisfying Assumptions in Specific System: Battery Scheduling Assumption

𝑔: 𝐺(𝐾 0 × 𝑇𝑁 0 + 𝐾 1 × 𝑇𝑁 1 + 𝐾 2 × 𝑇𝑁 2 + 𝐾 3 × 𝑇𝑁 3 ≥ 0)

Cells w 1 neighbors TN(1)

Cells w 2 neighbors TN(2)

Cells

w 3

neig

hbors

TN

(3)

Ratio of cells with 0,1,2,3 neighbors: 1 ⋅ 𝑇𝑁 1 − 1 ⋅ 𝑇𝑁 2 + 10 ⋅ 𝑇𝑁 3 ≥0

1 ⋅ 4 − 1 ⋅ 10 + 10 ⋅ 2 = 14 ≥ 0 1 ⋅ 2 − 1 ⋅ 14 + 10 ⋅ 0 = −12 < 0

15

ACTIVE Tool

Plugins for OSATE that consist of

Contract Annex Sublanguage (Parser)

• Captures analysis contracts within AADL models

ACTIVE Executer

• Interprets contracts and identifies valid execution schedules

ACTIVE Verifier

• Identifies and run contract verification engines

16

Analysis Contract Annex

package Contracts

public

with Contract_Properties, SEI, Deployment_Properties;

annex contract {**

name SecureAllocationAnalysis

input thread, thread.SecurityLevel

output thread.Not_Colocated

guarantees

forall x1: thread, x2:thread :

x1 != x2 -> (x1.SecurityLevel = x2.SecurityLevel) || x1 in x2.Not_Colocated

…

**};

end Contracts;

package AircraftPackage

public

with Contract;

system implementation AircraftSystem.i

…

annex contract {**

use contracts::SecureAllocationAnalysis,

contracts::BinPackingAnalysis,

…

**};

end AircraftSystem.i;

end AircraftPackage;

17

Analysis Contract Annex Examples

name LlrekAnalysis

input thread, thread.Period, thread.Deadline,

thread.Source_Text, thread.Priority,

thread.Compute_Execution_Time,

thread.Priority,

thread.Actual_Processor_Binding

output system.Is_Thread_Safe

assumes

forall t: thread : t.Period = t.Deadline

assumes

forall t1:thread, t2: thread | t1 != t2 :

G (CanPreempt(t1, t2) =>

(G!CanPreempt(t2, t1)))

name BatterySchedulingAnalysis

input device, device.Cell_Rows,

device.Cell_Cols, device.K0, device.K1,

device.K2, device.K3,

processor.Current_Frequency

output device.Serial_Req, device.Paral_Req,

device.Bat_Scheduler

guarantees

forall b: device :

G (b.K0 * b.TN(0) + b.K1*b.TN(1) +

b.K2*b.TN(2) + b.K3*b.TN(3) >= 0 )

18

ACTIVE Executer

Responsibilities

• Parse “use” subclauses in scope

• Retrieve referred contracts from

libraries

• Create dependency graph

* no cycle support

• Correct sequence of execution

of analysis and verifiers

• Plugin wrappers to prevent

compiling dependencies

+ Monitors plugin completion

19

ACTIVE Verifier

Decompose contract formulas into segments verifiable by single verifier

1. <Quan><Var><Predicate Expression>

— e.g.: forall t:thread | t.Period = t.Deadline

— sent to SMT solver. Each solution is later blocked to get all solutions

— Identifies part of model that should be verified

2. <LTLExpression>

— Identify domain atoms and functions: e.g. thread, CanPreempt()

— Select verifier that can interpret all atoms, functions, and operators

— Translate AADL model into verifier data (e.g. threads, periods,

scheduler, etc.)

— Run verifier

— Interpret and put results back into AADL model

20

Conclusions

Analyses from multiple domains are key for development of CPS

• But inconsistent assumptions may compromise results

Analysis contracts to automatically verify assumptions

• Analysis contract language & verification framework

• Implementation in AADL sub-annex

ACTIVE (Analysis ContracT Integration VErifier) Tool

• Extensible

• ACTIVE Executer + ACTIVE Verifier

Tested on two domains and five analyses