architectural verification of control systems using csp

Federal University of Pernambuco – UFPE Center of Informatics – CIn

Software Reliability Group – SRG

Architectural Verification of

Control Systems Using CSP

Joabe Jesus, Alexandre Mota, Augusto Sampaio (UFPE/INES)

Luiz Grijo (EMBRAER) [email protected]

13th International Conference on Formal Engineering Methods 24th October 2011

Components (Software/Hardware)

Equipments

Product

Systems

1. Context: Complex Dynamic Systems

• Challenge: correct design and implementation

• Solution: INCOSE System Engineering Process (V-Model) – Problems: How to reduce code defects, identify defects early and

reduce change cycles?

2

Time Specification leg Integration leg

V-Model Validation

and Verification

1. Context: Problems and Solutions

2. Background: Simulink and CSP

3. Contribution: Our Proposed Strategy

4. Case Study: Fly-By-Wire Elevator Control System

5. Conclusions and Future Work

Flight Simulators

Facilities (Iron Bird)

Acceptance Tests

Joabe Jesus ([email protected])

IntegrationTests

Component/ Unit Tests

Flight Tests


Equipments

Product

Systems

1. Context: Complex Dynamic Systems

• Problems: reduce code defects, identify defects early and reduce change cycles

• Solution: Y-Model (improved V-Model) – Model-Driven Development (MDD)

– Code Generators

3

Time

Gain

V-Model Y-Model






Specification leg Integration leg

Improvements to help industry to reach the “time-to-market”



Product

Systems

Equipments

1. Context: Our Proposal

• Architectural Verification of Control Systems Using CSP – Advantage: find defects early and reduce change cycles

4

Simulink (MDD)

V-Model Y-Model

Time Specification leg Integration leg






Formal CSP

Specification

Dev.

Phase

Defects

found

Y-Model

V-Model


2. Background: Control Systems

• Many dynamic systems need control

• Methods and Techniques – Control Theory – Helps defining Control Laws

• Mathematical Models

• Block Diagrams (Control Law Diagrams)

• Tools: Matlab/Simulink and SCADE

5

Lei de Controle (modelo Simulink)







2. Background: CSP

• Communicating Sequential Processes (CSP)

– Process Algebra defined by Hoare in 1978

• Specification: events and processes (equations)

• Tools

– Failure-Divergence Refinement (FDR)

• Machine readable CSP (CSPM) – channel declarations, datatypes, functional constructs

– Process Analysis Toolkit (PAT)

– CSP-Prover

6







RF01

3. Contribution: Proposed Strategy

7

UserModel.mdl

RF01

L N

L 1

RF 01

A

B

Requirements

Block diagrams

UserModel.csp

Translate

Normalise 1

UserModel

Normalised.mdl

L K

L N

L 1

C

Block diagrams

2 E

Specify Equipment Items

+

Properties

D 3

FDR

Abstraction

Composition

4

5

Verification

Engineer’s rework 7 Approved

System Design

I

6

Counterexamples?

Complete

System

Specification

F

H

Abstracted

System

Specification

G

YES NO






Reduced change cycle Find defects early


Types.csp

Block.csp

BlockLibrary.csp

Prelude.csp

3. Strategy: Step 2. Translation

• Bottom-Up

– Hierarchical translation

• Use our Infrastructure

• Compositional Rules

– Signals, Connections, Elementary Blocks, Reference Blocks

– Subsystems, Diagrams, ...

– Model

8







• Tool Support: Sim2CSP

– Automatically translate Simulink model files to CSPM specification scripts

simple_monitor.csp

(CSPM Specification) …

M_simple_monitor =

let Battery1(...) = let ... CS = {...} within B_Subsystem(CS)

I_Battery1 = Battery1(...) [[ ... ]]

Battery2(...) = let ... CS = {...} within B_Subsystem(CS)

I_Battery2 = Battery2(...) [[ ... ]]

Terminator = B_Terminator(...)

Monitor(...) = let ... CS = {...} within B_Subsystem(CS)

I_Monitor = Monitor(...) [[ ... ]]

CS = {(I_Battery1,{|…|}), (I_Battery2,{|…|}),

(Terminator,{|…|}), (I_Monitor, {|…|})}

within B_System(CS)

, ,

=

=

M_simple_monitor =

let

CS = { (I_Battery1, {|…|}), (I_Battery2, {|…|}), (Terminator, {|…|}), (I_Monitor, {|…|}) }

within B_System(CS)

,

,

,

, ,

Rule 3

Map Block (uses Rule 5 and 7)

Rule 3.1 Map Subsystem

(uses Rule 2, 5, 7 and 8)

Rule 5 Map Argument

Rule 6 Map Connection

Rule 7 Map Connection End

Rule 8 Map MaskVariable

Rule 1 Map Model (uses Rule 2)

Rule 2 Map diagram

Rule 4 Map Signal

(uses Rule 9)

Rule 9 Map Type

9

3. Strategy: Step 3. Specification

• Requirements (Architectural and Operational)

– Identifies System Equipment Items

• Items interact with the translated Simulink model (System Logic – usually Software) through a Control Computer

– Operation frequency and range

10

channel tock

Clock = tock -> tick -> Clock

aTick = {| tick |}

aClock = {| tick, tock |}

ControlComputer(model) = (model [| aTick |] Clock) \ aClock







3. Strategy: Steps 4, 5 and 6

Step 4. Compose; Step 5.Abstract; Step 6.Verify

TranslatedSimulinkMDL = ...

ControlComputer = ...

System = ... ControlComputer(TranslatedSimulinkModelProcess) ...

datatype DefectId = DEFECT_ID_1 | ... | DEFECT_ID_N

channel defectFound: DefectId

-- Comments: this is an Observer process

DefectK = receive events of interest ->

if validation/verification mechanism

then defectFound.DEFECT_ID_K -> STOP

else DefectK

assert (System [|{| |}|] DefectK) :[deadlock free]

11

events of

interest







4. Case Study

• Fly-By-Wire (FBW) Elevator Control System (ECS)

12

Horizontal Stabilizer

Flight Control Computers

Actuators

Sidestick Actuator Control

Eletronics (ACE)

Inertial Sensor






Architecture Overview


4. Case Study: Architecture

13

analog

Surface Position

analog

Command

Command

LVDT

Sidestick

Button

Priority

x4

x2

x3

PCU

Horizontal Stabiliser

x2

LVDT

Elevator

x3

Hinge Solenoide Valve

Servo Valve

Primary ACE








14

analog

Surface Position

analog

Arinc 429 BUS

ASCB

MAU

Command

Command

LVDT

Button

Priority

digital

A/D x3

x40

PCU x2

LVDT

Elevator

x3


Servo Valve

Primary ACE







Sidestick x2

x4


15

analog

Surface Position

analog

Arinc 429 BUS

ASCB

Command

Command

LVDT

Button

Priority

digital

A/D x3

x40

PCU

AD IRU

x2

LVDT

x3

Elevator

FS-ACE

WOW

x3


Servo Valve

Primary ACE







Sidestick x2 MAU

x4

x4


16

analog

Surface Position

analog

Arinc 429 BUS

ASCB

Command

Command

x4 LVDT

Button

Priority

digital

A/D x3

x40

x4

PCU

AD IRU

x2

LVDT

x3

Elevator

FS-ACE

x3


Servo Valve

Primary ACE







x4 Sidestick x2 MAU

WOW

x4

4. Case Study: Control Logic

17

Canal (Lane) do Controlador de Arfagem







4. Case Study: Step 1. Normalization

• Normalization Rules – Create/Delete

Empty Library

– Copy Block to Library

– Extract/Inline Reference

– Connect Unconnected Ports

18







4. Case Study: Step 2. Translation

• Generated Specification

– 286 calls to BlockLibrary.csp processes

– 30 local process definitions for Subsystems

– 539 references to channel sig

– 1 process to represent an Stateflow diagram

19







4. Case Study: Step 3. Specification

• Architectural Component Process

– SideStick, Sensors (ADIRU and WOW), Data Buses, FSACE, …

• Both Command Lane (COM) and Monitor Lane (MON) are ControlComputer processes

– They embed the Translated Simulink Control Logic

20







x4

4. Case Study: Steps 4, 5 and 6

• Desired Property – ECS only controls the pitch movement Elevator

surfaces move together to the same direction

• Verification Results – 1st Cycle: A1

• Redundant items

– 2nd Cycle: A2 • Removed some duplicates

21







5. Conclusions

• Contribution: unified verification during specification leg of Y-Model

– Architectural Requirements and Control Logic

– Find defects early and reduce change cycles

• Translation Rules from Simulink to CSP

• CSP Infrastructure

– Rich set of predefined constructs and functions

• Tool Support: Sim2CSP

22







5. Future Work

• Prove Soundness of our Rules (in progress)

• Improve Tool Support (Sim2CSP) (in progress) – User interface, performance, extensibility

• Investigate Abstraction Techniques

• Try other CSP tools – PAT and CSP-Prover (done and in progress)

• Integrate with Safety Assessment (in progress)

• Integrate with SCADE code generator

23







Federal University of Pernambuco – UFPE Center of Informatics – CIn

Software Reliability Group – SRG

Architectural Verification of

Control Systems Using CSP

Joabe Jesus, Alexandre Mota, Augusto Sampaio (UFPE/INES)

Luiz Grijo (EMBRAER) [email protected]

13th International Conference on Formal Engineering Methods 24th October 2011

architectural verification of control systems using csp

Documents