www.compass-research.eu

Foundations for Model-based Engineering of Systems of Systems

John Fitzgerald

John.Fitzgerald@ncl.ac.uk

Peter Gorm Larsen, Jim Woodcock

SoS Theory

“There’s nothing more practical than a good theory” Kurt Lewin, 1952

2

Agenda

1. Systems of Systems Engineering

2. COMPASS: a Model-based Approach

i. Technical Foci: contracts, verification, heterogeneity

ii. Tools

iii. “Emergent” leader election

3. Towards Cyber-Physical Systems

Systems of Systems (SoS)

Multiple content forms, providers, DRMs

Multiple environments & delivery forms

Bang & Olufsen: Can we show consistent “SoS experience” as devices, content, DRM, etc., change?

Background

A/V/Home Automation: • Multiple content sources, DRMs, • Multiple devices • Mobile and concurrent systems Bang & Olufsen: Can we ensure consistent “user experience” as devices, content, DRM, etc., change?

Smart Grid: • Many stakeholders with

different needs • Frequent changes to equipment

and stakeholder needs. • Safety cannot be guaranteed

centrally Service Provider: Can we ensure continuity of service and safety in the presence of change and faults?

Traffic Management: • Wide variety of constituent systems:

some legacy, some new • Harsh physical environment • Complex integration of new systems

and architectures • Faults & Fault Tolerance West Consulting: How can we add new/evolved constituent systems, and be sure that they will integrate seamlessly?

Emergency Response: • Stakeholders (patients to

government departments). • Human intervention required for

many interactions. • Assurance of global performance

and security properties Insiel: Can we manage evolution to a decentralised SoS while gaining assurance of global properties?

Systems of Systems (SoSs) • Assembly of

independent systems that collectively offer a new (“emergent”) service

• … on which value and reliance is placed!

• Independence

• Distribution

• Evolution

• Emergence

5

SoS Engineering

• SoS don’t “just happen”, neither are they often developed ab initio

• SoS Engineering – Not new

– Not always recognised

– Now an active area of research

• Model-based techniques for managing the engineering risk?

6

Kemp et al., Steampunk System of Systems Engineering: A case study of successful System of Systems engineering in 19th century Britain, INCOSE Intl . Symp, 2013.

SoS Engineering – Challenges

7

H. Kopetz, in Directions in Systems of Systems Engineering. European Commission, Communications Networks, Content and Technology Directorate- General Unit A3-DG CONNECT, July 2012

COMPASS “providing and evaluating advanced model-based methods and tools for development and analysis of SoS.”

8

Key outputs:

• Guidelines & patterns for SoS Requirements, Architectures and Integration

• A modelling language (CML) with formal semantics, developed specifically for SoS Engineering problems

• An open tools platform providing computer-assisted analysis of global properties, and test generation and management

• Industry evaluation of methods and tools based on case studies.

• Collaborative SoS Modelling by Formal Contracts – independence and autonomy of constituent systems

– contractual (assume, commit) interface specification

• Verification of Emergence – complexity of confirming/refuting SoS-level properties

– refinement for engineering of emergent properties; simulation tools allow exploration for unanticipated behaviours.

• Semantic Heterogeneity – multiple facets of multi-disciplinary SoS models

– theory to combine the semantics of heterogeneous models in an extensible way (allowing us to add new paradigms)

9

Technical Foci

Formal Modelling Language • CML allows representation of behavioural semantics of the SoS • Supports contract specification • Describes functionality, object-orientation, concurrency, real-time, mobility. • Can be extended to new paradigms

actions MERGE1(r) = (dcl e: set of ERUId @ e := findIdleERUs(); (do e = {} -> DECISION2(r) | e <> {} -> (dcl e1: ERUId @ e1 := allocateIdleERU(e, r); MERGE2(e1, r)) end)) … process InitiateRescue =

CallCentreProc [| SEND_CHANNELS |] RadioSystemProc [| RCV_CHANNELS |] ERUsProc

CC : Call Centre

: Start rescue

: Find idle ERUs

: Allocate

idle ERU

: Divert ERU

: Log diversion

: Start rescue

: Wait

: Send rescue

info to ERU

: Radio System

: Process

message

«Fault Activation»

: Fault 1 activation

«erroneous»

: Drop message«Error Detection»

: Error 1 detection

«Failure Event»

: Target not attended

«Start Recovery»

: Start Recovery 1

ERU1 : ERU

: Service

rescue

: Receive

message

«End Recovery»

: End Recovery 1

Initiate Rescue Fault Activation [Fault 1]

«Fault Activation View» {faultsOfInterest = Complete Failure of the Radio System}

CC : Call Centre

: Start rescue

: Find idle ERUs

: Allocate

idle ERU

: Divert ERU

: Log diversion

: Start rescue

: Wait

: Send rescue

info to ERU

CC : Call Centre

: Start rescue

: Find idle ERUs

: Allocate

idle ERU

: Divert ERU

: Log diversion

: Start rescue

: Wait

: Send rescue

info to ERU

: Radio System

: Process

message

«Fault Activation»

: Fault 1 activation

«erroneous»

: Drop message«Error Detection»

: Error 1 detection

«Failure Event»

: Target not attended

«Start Recovery»

: Start Recovery 1

: Radio System

: Process

message

«Fault Activation»

: Fault 1 activation

: Process

message

«Fault Activation»

: Fault 1 activation

«erroneous»

: Drop message«Error Detection»

: Error 1 detection

«Failure Event»

: Target not attended

«erroneous»

: Drop message«Error Detection»

: Error 1 detection

«Failure Event»

: Target not attended

«Start Recovery»

: Start Recovery 1

ERU1 : ERU

: Service

rescue

: Receive

message

«End Recovery»

: End Recovery 1

ERU1 : ERU

: Service

rescue

: Receive

message

«End Recovery»

: End Recovery 1

[idle ERU]

[no idle

ERU]

[higher

criticality]

[lower

criticality]

SysML modelling • Guidelines for Requirements, Architecture, Integration, Systems Eng. • SoS Modelling profiles, e.g. Fault-Error-Failure • Architectural patterns and extensible frameworks.

COMPASS Technology f1

(SoS || STOP) [= LE(SoS) E

Tool-supported Analysis • Model-checker • Automated proof • Test generation • Simulation • Verifying conformance during evolution, and emergence • Exploration of design space

10

COMPASS Tool Architecture

11

Contractual Modelling • Enrich interface specifications:

– Rich state, operations (pre/post), interactions

• Contract (re-negotiation) needs to be supported.

– Information hiding

12

<< interface connectivity view >> icv ERSoS

<<block>> ERSoS

<<contract>> : ERU Device

<<contract>> : Comms Layer

<<contract>> : ERU Device

rec send

rec send

Verifying Emergence

• Global invariants:

– An “Olympian” abstract model embodies the key emergent properties.

– Check a formal refinement relation between distributed and Olympian model

13

process Card = val i: Index @ begin state value: nat operations Init: () ==> () …

Credit: nat ==> () …

Debit: nat ==> () … Debit(n) == value := value - n actions Transfer = pay.i?j?n -> ( [n > value] & reject!i -> Skip [] [n <= value] & transfer.i.j!n -> accept!i -> Debit(n) ) Receive = transfer?j.i?n -> Credit(n) Cycle = ( Transfer [] Receive ); Cycle @ Init(); Cycle end… process Cards = || i: Index @ [ {| pay.i, transfer.i, accept.i, reject.i |} union { transfer.j.i.n | j <- Index, n <- Money } ] Card(i) process Network = Cards \\ {|transfer|}

Verifying Emergence

• Global invariants:

– An “Olympian” abstract model embodies the key emergent properties.

– Check a formal refinement relation between distributed and Olympian model

14

process Card = val i: Index @ begin state value: nat operations Init: () ==> () …

Credit: nat ==> () …

Debit: nat ==> () … Debit(n) == value := value - n actions Transfer = pay.i?j?n -> ( [n > value] & reject!i -> Skip [] [n <= value] & transfer.i.j!n -> accept!i -> Debit(n) ) Receive = transfer?j.i?n -> Credit(n) Cycle = ( Transfer [] Receive ); Cycle @ Init(); Cycle end… process Cards = || i: Index @ [ {| pay.i, transfer.i, accept.i, reject.i |} union { transfer.j.i.n | j <- Index, n <- Money } ] Card(i) process Network = Cards \\ {|transfer|}

process Spec = begin state valueseq: seq of nat inv len(valueseq) = N sum(valueseq) = M operations Init: () ==> () Init() == valueseq := initseq(N) actions Pay = i,j: Index, n: Money @ pay.i.j.n -> if n > valueseq(i) then reject.i -> Skip else ( valueseq := subtseq(valueseq,i,n); valueseq := addseq(valueseq,j,n); accept.i -> Skip) Cycle = ( |˜| i,j: Index, n: Money @ Pay(i,j,n) ); Cycle @ Cycle end

Semantic Heterogeneity

• CML semantics use Unifying Theories of Programming

• UTP provides theoretical framework for unifying semantics of distinct kinds

• CML has – Denotational, Operational,

Axiomatic Semantics – Rich state, concurrency,

communication, discrete time, object orientation

• Semantics encoded in tools

15

Relations

Designs

OO Designs

Reactive processes

Timed Processes

OO Timed Processes

1..*

1..*

1

1

bdd [Package] SoS Structure«block»

B&O AV SoS

«block»

LE Device

«block»

Transport Layer

«block»

Grey-Box AV Device

«block»

Network

«block»

White-Box AV Device

1..*

1..*

1

1

Concurrent State

New

Undecided

do : changeClaim

Follower

do : changeClaim

Leader

do : changeClaim

do : incStrength

Controller

Ready

do : receive

Update

do : update

Off

[STM] LE Device behaviour Concurrent State

New

Undecided

do : changeClaim

Follower

do : changeClaim

Leader

do : changeClaim

do : incStrength

Controller

Ready

do : receive

Update

do : update

New

Undecided

do : changeClaim

Follower

do : changeClaim

Leader

do : changeClaim

do : incStrength

Undecided

do : changeClaim

Follower

do : changeClaim

Leader

do : changeClaim

do : incStrength

Controller

Ready

do : receive

Update

do : update

Ready

do : receive

Update

do : update

Off/init

/send_undecided

/

/on

flushState/off

flushState/

off

[leaders >1 or leaders=0]/send_undecided

[not isLeader]/send_follower

[leaders > 1]/send_undecided

[isLeader]/send_leader...

/

/

[leaders=1]/send_follower

[leaders = 1]/send_leader

process Node = i : nat @ begin state id : NODE_ID mem: map NODE_ID to CS inv dom mem = node_ids \ {id} and dom mem <> {} operations changeClaim: CLAIM ==> () changeClaim(newc) == (dcl currStr : STRENGTH := myCS.s @ myCS := mk_CS(newc, currStr)) pre myCS.c = <off> => newc = <undecided> and myCS.c = <undecided> => newc = <leader> or … actions Leader = changeClaim(<leader>);SendCS;Controller; ([leaders > 0] & Undecided [] [leaders = 0] & incStrength();Leader) end process TransportLayer = ... actions TransportLayer = (Reader [] Writer [] NodeMngt) end process ElectionHiddenComms = ll Nodes [|{|n_send,n_rec,on,off,init|}|] TransportLayer \\ {|n_rec,n_send|}

• Does integration of new devices lead to a loss of emergent leader election behaviour?

• “SoS Thinking” encouraged by COMPASS tech

• Model-checking of interaction between constitutent systems

• Integration of non-constituent systems in data streaming and rendering SoS.

• Improved handling of faulty devices (need for quiescence)

Example: emergent leader election

Results and Some Open Issues • www.compass-research.eu

• Guidelines: – Requirements Engineering, Architectural Modelling Framework,

Integration, SoS Engineering, implementing in Atego’s tools.

– COMPASS Architectural Framework Framework!

– are there “laws” for architectural refinement?

• Foundations: – Modelling Language Semantics

– extend to stochastic models, continuous time models, agent-based?

– Fault Analysis – extending the range of “abnormalities”

• Tool Support: – Tools platform & integrations – how will user interaction look ?

– Introductory examples and tools videos.

17

Forthcoming Events • COMPASS Interest Group

– 15 January, Amsterdam • Meeting on case studies • Led by Bang & Olufsen and Insiel

– Summer meeting (TBC, Aarhus?) • Meeting on new challenge

problems in traffic flow management & smart grid

• COMPASS Summer School – 16-20 June, Newcastle, UK – For students & early career

researchers – on model-based approaches to

SoS Engineering

18

Roke Manor Research Ltd Nokia GridManager West Consulting BV Rockwell Collins UNU-IIST Center for Electronic Governance 3SL Embraer TERMA Altran University of South Australia Jaguar Land Rover National Institute of Informatics, Japan Verified Systems International GmbH AGCO Corporation DSTL, UK

Towards Cyber-Physical Systems

• Requires convergence of: – Multi-paradigm modelling and co-

simulation

– Model-based design

– Architectural modelling

– Verification technology

www.destecs.org

Urban Cyber-Physical Systems Lab @ Newcastle

– CPS Lab focussing on design for dependability

– Smart grid, transport, devices, cloud labs

– Focus on urban sustainability.

– Collaborations sought!

20

Towards Cyber-Physical Systems

Concluding Remarks

• Practical Theory driven by application need

• Don’t ask “Is it an SoS or not?”

– Instead, “What are its SoS characteristics?”

• SoS Thinking:

– Addressing constituent system independence via explicit contractual specification

– Exploring & verifying emergent properties

– Multi-domain: embracing semantic heterogeneity

21