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) jbjj@cin.ufpe.br

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?

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 (jbjj@cin.ufpe.br)

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

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

Simulink (MDD)

V-Model Y-Model

Time Specification leg Integration leg

Formal CSP

Specification

Defects

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

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

3. Contribution: Proposed Strategy

UserModel.mdl

Requirements

Block diagrams

UserModel.csp

Translate

Normalise 1

UserModel

Normalised.mdl

Block diagrams

Specify Equipment Items

Properties

Abstraction

Composition

Verification

Engineer’s rework 7 Approved

System Design

Counterexamples?

Complete

System

Specification

Abstracted

System

Specification

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

• 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 =

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

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

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]

events of

interest

4. Case Study

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

Horizontal Stabilizer

Flight Control Computers

Actuators

Sidestick Actuator Control

Eletronics (ACE)

Inertial Sensor

Architecture Overview

4. Case Study: Architecture

analog

Surface Position

analog

Command

Sidestick

Button

Priority

Horizontal Stabiliser

Elevator

Hinge Solenoide Valve

Servo Valve

Primary ACE

analog

Surface Position

analog

Arinc 429 BUS

Command

Button

Priority

digital

A/D x3

PCU x2

Elevator

Servo Valve

Primary ACE

Sidestick x2

analog

Surface Position

analog

Arinc 429 BUS

Command

Button

Priority

digital

A/D x3

AD IRU

Elevator

FS-ACE

Servo Valve

Primary ACE

Sidestick x2 MAU

analog

Surface Position

analog

Arinc 429 BUS

Command

x4 LVDT

Button

Priority

digital

A/D x3

AD IRU

Elevator

FS-ACE

Servo Valve

Primary ACE

x4 Sidestick x2 MAU

4. Case Study: Control Logic

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

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

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

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

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

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

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) jbjj@cin.ufpe.br

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

architectural verification of control systems using csp

Documents

light that is right...2018 first edition latest from light...

specifics of worldwide csp emerging markets · source: csp...

performance verification of linear fresnel on the example...

dlms introductory training module 7 – enterprise...

csp program summit 2016 - energy.gov › sites › prod ›...

verification of architectural memory models by model...

exams mlc; afe; apmv; fete; csp-rc; dp-rc; csp-ru; csp-iu

csp-428 & csp-1248 - full compass

csp csp csp csp csp csp csp csp csp csp csp csp … ·...

formal verification and testing of software architectural

architectural development and functional verification of...

bedienungsanleitung csp-170 csp-150 - piano-fies.de ·...

top 3 in csp by : belén gallego csp today

csp strategic

draft csp moradabad csp

opn programming guide v4.3 - download.microsoft.com ·...

isa 763 security protocol verification csp semantics we...

fitcher csp

model csp - greenheck · model csp qd units ... csp-262...

cadence csp