System of Systems Dependability for LOSA · 2015-11-02 · SoS Dependability for LOSA - Final Report Preface This is the nal report resulting from the feasibility study on System

System of Systems Dependability for LOSA

Final Report

Date: 2015

Authors:

Richard Payne – [email protected] Bryans – [email protected] Fitzgerald – [email protected]

Centre for Software ReliabilityNewcastle University

NE1 7RUhttp://www.ncl.ac.uk/computing/

SoS Dependability for LOSA - Final Report

Preface

This is the final report resulting from the feasibility study on System of Sys-tems Dependability for LOSA. The report forms two parts. Part 1 describesthe rationale, approach and conclusions of the study, including assessmentand recommendations for model-based design technologies in the LOSA con-text. Part 2 provides a supporting detailed description of the models de-veloped and analyses performed on the illustrative example defined in thestudy.

The project reported in this document was funded from the DE&S Technol-ogy Office.

2

Contents

1 Part 1: Rationale, Approach and Conclusions 51.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.1.1 Description of Project and Contribution . . . . . . . . 61.1.2 Outline of Report . . . . . . . . . . . . . . . . . . . . . 7

1.2 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.2.1 Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 81.2.2 Model-based SoS Engineering for LOSA . . . . . . . . 91.2.3 LOSA Ontology . . . . . . . . . . . . . . . . . . . . . . 11

1.3 Illustrative Example . . . . . . . . . . . . . . . . . . . . . . . 131.3.1 Feasibility Example Structure . . . . . . . . . . . . . . 131.3.2 Feasibility Example Scenario . . . . . . . . . . . . . . . 14

1.4 Dependability Properties . . . . . . . . . . . . . . . . . . . . . 151.4.1 Assessing Dependability . . . . . . . . . . . . . . . . . 16

1.5 Modelling and Analysis Results . . . . . . . . . . . . . . . . . 181.5.1 Model-based Ontology . . . . . . . . . . . . . . . . . . 181.5.2 Context-based Requirements Engineering . . . . . . . . 191.5.3 Architectural Modelling: Interface Contract Pattern . . 191.5.4 Model Analysis . . . . . . . . . . . . . . . . . . . . . . 19

1.6 Conclusions and Future Work . . . . . . . . . . . . . . . . . . 211.6.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 211.6.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . 21

2 Part 2: Modelling and Analyses 232.1 Model-based System of Systems (SoS) Design in LOSA . . . . 232.2 Architectural Modelling . . . . . . . . . . . . . . . . . . . . . 25

2.2.1 Interface Contracts . . . . . . . . . . . . . . . . . . . . 252.2.2 Modelling Power Flows . . . . . . . . . . . . . . . . . . 322.2.3 Assessing Dependability . . . . . . . . . . . . . . . . . 37

2.3 Formal Modelling . . . . . . . . . . . . . . . . . . . . . . . . . 392.3.1 SoS Structure . . . . . . . . . . . . . . . . . . . . . . . 39

3


2.3.2 Soldier Interface Contract (IC) Behaviour . . . . . . . 402.3.3 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 422.3.4 Assessing Dependability . . . . . . . . . . . . . . . . . 44

2.4 Fault Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . 462.4.1 Identifying Faults, Errors and Failures . . . . . . . . . 462.4.2 Threat Chains . . . . . . . . . . . . . . . . . . . . . . . 472.4.3 Behavioural Views: Nominal, Erroneous and Recovery 482.4.4 Assessing Dependability . . . . . . . . . . . . . . . . . 52

2.5 Requirements Engineering . . . . . . . . . . . . . . . . . . . . 542.5.1 Defining Requirements . . . . . . . . . . . . . . . . . . 542.5.2 Requirements in Context . . . . . . . . . . . . . . . . . 552.5.3 Assessing Dependability . . . . . . . . . . . . . . . . . 57

2.6 Co-modelling and Co-simulation . . . . . . . . . . . . . . . . . 592.6.1 Co-modelling . . . . . . . . . . . . . . . . . . . . . . . 592.6.2 Co-simulation . . . . . . . . . . . . . . . . . . . . . . . 632.6.3 Assessing Dependability . . . . . . . . . . . . . . . . . 64

A Feasibility Study LOSA SoS Verification and Assurance Stages 72

B Complete CML Model 74

4

Chapter 1

Part 1: Rationale, Approachand Conclusions

1.1 Introduction

A wide range of capabilities in both civil and defence domains are deliveredby the collective operation of systems that are independent of one another.For example, successful completion of a specific military mission may involvepower and data networks, logistical systems, vehicles and units that mayhave evolved separately and may not have been conceived with collectiveoperations in mind at all. As reliance comes to be placed on the performanceof these groups of systems, they merit consideration as systems in their ownright [17]. Such systems are termed SoSs, and their successful creation,integration and maintenance presents considerable challenges [7].

Dependability is of increasing importance both at the level of each SoSas a whole and in the integration and interoperability of the individualConstituent Systems (CSs) making up the SoS. It is therefore vital thatstakeholders involved in system requirements, design, verification and assur-ance have evidence that increases their understanding of the interdependen-cies in an SoS, and thus their confidence in their trade-off decisions. For LandOpen System Architecture (LOSA) as an approach by which to develop, en-sure and assure coherence across the Land Environment this requirement isparticularly acute in the development of the security, safety and reliabilitycases where the appetite for risk caused by uncertainty of SoS dependenciesis particularly low.

5


1.1.1 Description of Project and Contribution

Challenges in SoS engineering arise because of the limited information avail-able about CSs, the need for clear descriptions of interactions between them,and the need for rigorous analysis of the SoS behaviour that emerges fromthese interactions. Model-based techniques are increasingly seen as a way ofmitigating these complexities by encouraging the precise description of SoSarchitectures and CS interfaces, as well as providing means for systematicand possibly automated analysis of dependability properties.

The study reported here examines the feasibility of a sequence of model-based verification and assurance activities as a pragmatic means of providingstakeholders with the evidence needed to increase confidence in the way inwhich the complex security, safety and reliability dependencies are addressedwithin a given programme or project. The statement of work for the studyproposes a potential sequence of verification and assurance activities (repro-duced in Appendix A) as a basis for evaluation. It also anticipates that theresults of the study should “inform the ongoing research, experimentation,development and implementation programmes for LOSA”.

A stakeholder workshop “SoS Dependability for LOSA” was held at DTACaerwent on 20th October 2014, and a project meeting was held with DE&Sstakeholders at Newcastle University 16th December 2014. The purpose ofthese events was to obtain input from industry and DE&S stakeholders onboth the selection of model-based techniques that could be used to implementthe proposed sequence of verification and assurance activities, and an illus-trative example that could be used to explore their feasibility. The workshopfeedback obtained suggested that the study should:

• consider stakeholder roles;

• allow the modelling of physical phenomena such as power, and not onlydigital phenomena;

• demonstrate the ability to analyse SoS-level properties;

• allow modelling of “what-if” scenarios.

Given these factors, we consider the use of a collection of design-time model-based techniques, which together might form a pragmatic method addressingthe concerns above. We use these to assess the feasibility of the sequence ofactivities proposed in the statement of work. In Section 1.2.2, we provide anoverview of the technologies used, and highlight at what point in the sequenceof activities they may be used. In Section 1.5 we consider their applicability

6


and maturity for LOSA.

1.1.2 Outline of Report

This report is presented in two parts. This part (Part 1) reports the study, itsbackground, methodology and results. Part 2 provides supporting documen-tation consisting of the detailed models developed, and analyses conductedon them. The remainder of Part 1 is structured as follows. Section 1.2 detailsthe approach taken in the feasibility study; Section 1.3 provides an outline ofthe illustrative example used in the feasibility assessment of the technologies;representative dependability properties are described in Section 1.4; conclu-sions are drawn in Section 1.5 and in Section 1.6 areas of future work areidentified.

7


1.2 Approach

Section 1.2.1 describes the basic concepts and terminology used throughoutthe study. Section 1.2.2 outlines the relationship between the sequence ofactivities proposed in statement of work (Appendix A) and the collection oftechniques that we bring to bear. Section 1.2.3 presents the ontology thatunderpins all the work that we carry out.

1.2.1 Basic Concepts

In this section we introduce the basic terms and concepts employed thisreport.

A system is considered to be a combination of interacting elements (for ex-ample hardware, software, data, humans) organised to achieve one or morestated purposes [16]. There is a boundary between a system and its environ-ment, defining the scope and context of the system [12].

A System of Systems (SoS) is a system in which the interacting elements arethemselves systems. The elements of an SoS are referred to as ConstituentSystems (CSs). Systems and SoSs offer functionality to their environmentthrough interfaces defined at the system boundary. An IC is a descriptionof (some part of) a CS in terms of the expectations and obligations placedon its behaviour [4]1. Cyber Physical Systems (CPSs) are systems withdiverse interacting components from physical and computational domains.The interaction with the environment may range from embedded systemswith sensors and actuators to networked systems [3].

A system or SoS is dependable if it is able to deliver a service that can justifi-ably be trusted [2]. The characteristics of dependability include availability,reliability, safety, integrity and maintainability. System security, closely re-lated to dependability, adds confidentiality to this list.

The architecture of a system or SoS describes the system behaviour and thecomposition, connections and communications of the internal elements [21].An architectural framework is a collection of related views on an architecture.It has an underlying meta-model, a defined syntax and consistency rules.Architectural frameworks may describe the whole architecture of a system ora specific facet (e.g., the Fault Modelling Architectural Framework for fault

1In some previous work we refer to ICs simply as contracts. We prefer the term IChere.

8


modelling [1]). They may also be domain-specific (e.g., MODAF [18] for theUK defence domain).

A model is a more-or-less abstract representation of a system of interest.In this report, we distinguish semi-formal models, which are often diagram-matic, from formal models, which have a well-founded mathematical seman-tics and are often presented textually.

1.2.2 Model-based SoS Engineering for LOSA

This study examines a collection of design-time model-based techniques thatmay be used to implement a sequence of activities, forming the basis of apragmatic method to enable the assessment of dependability in the contextof LOSA. Few if any single existing methods are able to deliver this wholesequence of activities while satisfying the requirements raised by our stake-holder groups. We therefore consider several techniques, using notations andmethods from the SoS engineering and CPS engineering disciplines. Thesetechnologies considered are:

• SoS Engineering– Architectural modelling– Formal modelling and analysis– Fault modelling– Requirements engineering

• CPS Engineering– Co-modelling and Co-simulation

To carry out the SoS engineering, we used SysML [20, 13], a semi-formal mod-elling language supported by industrial strength tools, and the experimentalformal language CML [22], designed during the recent SoS project COM-PASS2 and supported by the prototype Symphony tool platform [6].

To carry out the CPS engineering, we used the Crescendo tool [10], whichuses the languages VDM [8] and 20-sim 3.

Given the initial sequence of activities outlined in the statement of work(Appendix A), we use these techniques as summarised in Figure 1.1 anddetailed below:

2www.compass-research.eu3http://www.20sim.com

9

www.compass-research.eu

http://www.20sim.com


Figure 1.1: Techniques applied to the sequence of activities

1. Clarify and formally define the relationships between archi-tectures, standards and implementations – We use a model-basedontology [13] to identify key concepts in LOSA; including real systemelements, standards, implementation details and modelling concepts.

2. Understanding stakeholder roles to allow definition of whatLOSA compliance means to stakeholders [...] – The study demon-strates a requirements engineering technique developed for SoS, (SoS-ACRE [14]) that allows the identification of stakeholders and the plac-ing of LOSA SoS requirements in context. This technique may becombined using traceability links throughout an architectural model.

3. Define the architectural framework representations requiredin support of stakeholder roles [...] including formal clarifica-tion of system boundaries within LOSA – The use of architecturalmodelling techniques, and in particular a pattern for defining InterfaceContracts (the Interface Contract pattern [4, 5]), allows an SoS to bedefined in terms of its CSs. Defining the interfaces between the CSs en-ables the explicit description of the interactions between CSs and alsothe interfaces with the SoS’s environment. Defining these interfacestogether with the SoS enables the clarification of the SoS boundary.

4. [...] enable assessment and measurement of the dependen-cies between system boundaries to deliver evidence and confi-dence of the understanding of SoS behaviours and limitationsto inform security, safety and reliability cases – The model-based

10


techniques employed (SysML and CML) have associated analysis tech-nologies which produce results we can use. The analysis technologieswe used in project (formal model simulation [6], fault modelling [1] andco-simulation [10]) vary in their ease of use, and offer varying degreesof confidence to the user.

5. Develop generic reference models for platform interoperabil-ity and platform integration – A contractual style of architecturalmodelling, advocated in the IC pattern, is a candidate for defining ref-erence models, useful in integration and reasoning about interoperabil-ity. The pattern encourages the definition of an SoS model in terms ofthe assumptions and guarantees which are placed on the CSs, enablingthe analysis of integrating new CSs into the SoS. Regarding their usein reference models, by defining the SoS contractually, the CSs whichform the SoS simply need to conform to those ICs – and may do thisin which ever way they choose.

6. Use models to deliver evidence and confidence for use in se-curity, safety and reliability case developments as requiredthroughout the lifecycle – The models and analysis results may beused to provide evidence and confidence to an SoS engineer. Whetherthese may be used in security, safety and reliability cases requires fur-ther investigation.

The modelling effort is described in detail in Part 2 of this report. In thisdocument we outline the key concepts using a model-based ontology.

1.2.3 LOSA Ontology

We begin by explicitly defining the relationships between concepts fromLOSA, SoSs and the IC Pattern [5] (a contractual model-based engineeringpattern) in an ontology. This ontology is presented as an Ontology Defini-tion View (ODV)4 in Figure 1.2. The ODV includes three main categories ofconcept: in blue – Defence Standards; green – Land Environment concepts;and in brown – SoSs and ICs.

The ontology describes standards to which the different Land Platforms5 ina Land Force conform. For example, a Vehicle Platform conforms to the

4The ODV is a view from the COMPASS AF Framework [15] – a framework for thedefinition of architectural frameworks.

5Platform is the generic term for the “type” of the physical entity.

11


Figure 1.2: Ontology Definition View for LOSA concepts

Generic Vehicle Architecture standard. A Land Force may consist of severalBase Platforms, Vehicle Platforms and Soldier Platforms. Each platformexposes one or more Common Open Interface for Land (COI(L)) Interfaceswhich conform to the COI(L) standard. The COI(L) Interface may be adata or flow-based interface – in this work, we consider the data and powerinterfaces. We do not explicitly state the relationship between the variousgeneric architecture standards and the COI(L) standard. Given these LOSAconcepts, we define the correspondence relations to concepts used in the SoSengineering domain. In the ODV, we state that the Land Force correspondsto a System of Systems and the different platforms correspond to ConstituentSystems. A Constituent System therefore exposes COI(L) Interfaces. Giventhe IC Pattern [5], the ODV states that a Constituent System may conform toseveral Interface Contracts each of which also expose COI(L) Interfaces. Thecomposition of a collection of Interface Contracts is defined as an IC-definedSystem of Systems. The System of Systems conforms to an IC-defined Systemof Systems. Finally, an SoS-level Contract governs the IC-defined System ofSystems.

12


1.3 Illustrative Example

Given the ontology described above, we provide a brief illustrative exampleof a LOSA SoS and a collection of corresponding CSs and ICs. The purposeof the example is for us to define the scope of interest in this project, andtherefore we abstract from concrete implementation details. In this simpleexample, we depict the LOSA experiment conducted at a recent LOSA C-DISC Integration meeting, as illustrated in an extract from a presentation inFigure 1.3.

Figure 1.3: Overview of the Feasibility Example

1.3.1 Feasibility Example Structure

For the purposes of this study, we make some simplifications, as shown inthe SysML Block Definition Diagram (BDD) in Figure 1.4. The Feasibility

13


Example SoS comprises a Mounted Soldier, a Dismounted Soldier, a Vehicleand a Patrol Officer.

Figure 1.4: Block Definition Diagram showing composition of FeasibilityExample SoS

1.3.2 Feasibility Example Scenario

We propose a simple scenario in which the different CSs communicate in orderto achieve some SoS-level objective. It should be noted that communicationsare either high bandwidth or low bandwidth.

1. Patrol requests area to be checked; sends message to the Vehicle

2. Vehicle forwards message to Mounted Soldier

3. Mounted Soldier requests the scan function of the Vehicle

4. Mounted Soldier requests a Dismounted Soldier to investigate

5. Dismounted Soldier replies with all clear; message sent back to Patrol.

14


1.4 Dependability Properties

As mentioned in Section 1.2.1, we employ an established definition of de-pendability [2] which divides the topic into: (i) the attributes which comprisedependability; (ii) the threats to dependability; (iii) the means that may beemployed to ensure a system’s dependability (Figure 1.5).

. Fault prevention means to prevent the occurrence orintroduction of faults.

. Fault tolerancemeans to avoid service failures in thepresence of faults.

. Fault removal means to reduce the number andseverity of faults.

. Fault forecasting means to estimate the presentnumber, the future incidence, and the likely con-sequences of faults.

Fault prevention and fault tolerance aim to provide theability to deliver a service that can be trusted, while faultremoval and fault forecasting aim to reach confidence inthat ability by justifying that the functional and thedependability and security specifications are adequate andthat the system is likely to meet them.

2.5 Summary: The Dependability and Security Tree

The schema of the complete taxonomy of dependable andsecure computing asoutlined in this section is shown inFig. 2.

3 THE THREATS TO DEPENDABILITY AND SECURITY

3.1 System Life Cycle: Phases and EnvironmentsIn this section, we present the taxonomy of threats that mayaffect a system during its entire life. The life cycle of asystem consists of two phases: development and use.

The development phase includes all activities frompresentation of the user’s initial concept to the decision thatthe system has passed all acceptance tests and is ready todeliver service in its user’s environment. During thedevelopment phase, the system interacts with the develop-ment environment and development faultsmay be introducedinto the system by the environment. The developmentenvironment of a system consists of the following elements:

1. the physical world with its natural phenomena,2. human developers, some possibly lacking competence

or having malicious objectives,3. development tools: software and hardware used by the

developers to assist them in the developmentprocess,

4. production and test facilities.

The use phase of a system’s life begins when the systemis accepted for use and starts the delivery of its services tothe users. Use consists of alternating periods of correctservice delivery (to be called service delivery), serviceoutage, and service shutdown. A service outage is caused bya service failure. It is the period when incorrect service(including no service at all) is delivered at the serviceinterface. A service shutdown is an intentional halt ofservice by an authorized entity. Maintenance actions maytake place during all three periods of the use phase.

During the use phase, the system interacts with its useenvironment and may be adversely affected by faultsoriginating in it. The use environment consists of thefollowing elements:

1. the physical world with its natural phenomena;2. administrators (including maintainers): entities (hu-

mans or other systems) that have the authority tomanage, modify, repair and use the system; someauthorized humans may lack competence or havemalicious objectives;

3. users: entities (humans or other systems) that receiveservice from the system at their use interfaces;

4. providers: entities (humans or other systems) thatdeliver services to the system at its use interfaces;

5. the infrastructure: entities that provide specializedservices to the system, such as information sources(e.g., time, GPS, etc.), communication links, powersources, cooling airflow, etc.

6. intruders: malicious entities (humans and othersystems) that attempt to exceed any authority theymight have and alter service or halt it, alter thesystem’s functionality or performance, or to accessconfidential information. Examples include hackers,vandals, corrupt insiders, agents of hostile govern-ments or organizations, and malicious software.

As used here, the term maintenance, following commonusage, includes not only repairs, but also all modificationsof the system that take place during the use phase of systemlife. Therefore, maintenance is a development process, andthe preceding discussion of development applies to main-tenance as well. The various forms of maintenance aresummarized in Fig. 3.

It is noteworthy that repair and fault tolerance arerelated concepts; the distinction between fault tolerance andmaintenance in this paper is that maintenance involves theparticipation of an external agent, e.g., a repairman, testequipment, remote reloading of software. Furthermore,repair is part of fault removal (during the use phase), andfault forecasting usually considers repair situations. In fact,repair can be seen as a fault tolerance activity within alarger system that includes the system being repaired andthe people and other systems that perform such repairs.

14 IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 1, NO. 1, JANUARY-MARCH 2004

Fig. 1. Dependability and security attributes.

Fig. 2. The dependability and security tree.Figure 1.5: Attributes of, threats to, and means of ensuring dependabilityand security [2]

In this initially limited study, rather than contrive an example to cover thefull range of dependability properties, we have concentrated on a selectedsubset, in particular availability, reliability and safety. However, in a LOSASoS, we have CSs with both digital and physical phenomena, and so we pro-pose dependability properties related to computation/networks and physicalissues.

Beginning with discrete conditions and transitions of the feasibility examplescenario in Section 1.3.2, we identify a set of three representative depend-ability properties:

• Availability: What behaviour should we expect if the high bandwidthinterface is not available?

• Reliability: What if the low bandwidth channel loses a message? Arethe individual logs recorded by the Soldiers and the Vehicle consistent?

15


• Safety: Can we distinguish between safe and unsafe states? (e.g patrolmoving before receiving an ‘All Clear’ message)

The next set of properties are in terms of a continuous variable, namelyelectrical power. This allows us to explore the techniques available to an-swer questions related to continuous time. We consider only availability andreliability in the context of continuous time properties:

• Availability: What is the system behaviour if power goes below 9v?

• Reliability: If power goes below 9v, will mission logs remain equal?

1.4.1 Assessing Dependability

In Part 2 of this report, we consider a range of modelling and analysis tech-niques, as outlined in Section 1.2. For each technique, we consider the dif-ferent dependability properties outlined above and discuss how it may beapplied to assess dependability in a LOSA SoS. In this section, we providea summary of those findings.

In Figure 1.6 we list the five dependability-related questions across the top,and the various techniques considered in this feasibility study on the left-hand side. Broadly speaking, the discrete techniques (the first five) are mostapplicable to the initial versions of the questions (columns 1, 3 and 5) and theco-modelling/co-simulation techniques are most applicable to the versions ofthe questions that involve power considerations.

Using the different discrete techniques (architectural modelling, formal mod-elling, formal analysis and fault modelling), we can model systems beingunavailable, unreliable communications media and distinguish between safeand unsafe states. Using simulation of a formal model, we may explore theconsequences of a LOSA SoS which is not dependable. Fault modelling allowsus to explore the threats to dependability in a SoS and understand the rela-tionships between faults in a SoS (due to CSs being unavailable/unreliable)and the failures which may occur as a consequence.

Co-modelling and co-simulation techniques allow us to model continuous vari-ables – relating to power, for example – in notations that are able to representcontinuously changing values, and explore the interaction between digital andphysical phenomena. This technique allows us to consider dependability andfault tolerance in a network-connected SoS in which both data and powerare present and interact.

16


Figure 1.6: Techniques / Dependability properties matrix

17


1.5 Modelling and Analysis Results

In this study, we identified and assessed the use of several modelling technolo-gies. This assessment is to establish the feasibility of a pragmatic method ofassessing security, safety and reliability dependencies of an SoS in the LOSAcontext. The result of this study is that such a method is feasible.

In this section, we provide an overview of the different technologies (repro-duced in Figure 1.7) along with a brief assessment of their suitability in theLOSA context. We do this by assessing the technologies available to assist inthe steps in the sequence of activities, reproduced below. Part 2 of this reportgives more detail on the work that was carried out for each technology.

Figure 1.7: Techniques applied to the sequence of activities

1.5.1 Model-based Ontology

The model-based ontology using an Ontology Definition View in Section 1.2.3has proved to be a valuable tool. At the commencement of the project wewere able to clarify and formally define the relationships between architec-tures, standards and implementations. This clarity proved useful throughoutthe project and was a useful communication tool. Although by itself an on-tology does not allow the assessment of SoS dependencies, it formed a basisfor the rest of the work.

18


1.5.2 Context-based Requirements Engineering

We demonstrated a requirements engineering technique that allows require-ments to be placed in the context of SoSs – SoS-ACRE. Although the tech-nique is somewhat cumbersome, top-level requirements can be broken downinto their implications for individual stakeholders, and these can be analysedvisually for any conflicts between stakeholders. Identifying such conflicts iscan help avoid the failure to meet SoS-level requirements.

Model-based requirement engineering techniques also allow trace links fromrequirements through to model elements. This provides the possibility ofdeveloping methods for dependability-specific requirement engineering.

1.5.3 Architectural Modelling: Interface Contract Pat-tern

We demonstrated the use of semi-formal modelling technologies – namely theInterface Contract pattern in SysML.

The use of SysML, and in particular adherence to the Interface Contract pat-tern provides many advantages: consistency checking of the defined modelallows for rigorous, consistent models and in general semi-formal models, de-fined using diagrammatic notations have good potential as a communicationmechanism. Semi-formal models also have the advantage of being readilyunderstandable by engineers. Furthermore, the (potentially automated) linkto formal notations provide the option for advanced analysis techniques suchas model checking and theorem proving. Whilst the SysML language andtool support is mature, the IC technique has been demonstrated only usingpilot studies. Further investigation is needed to take this technology to ahigher TRL.

The architectural modelling allowed the assessment of the dependability ofthe LOSA SoS using model review and exploration. In our case this reviewwas conducted informally.

1.5.4 Model Analysis

We demonstrated a formal version of the feasibility example using CML,and used it to simulate the scenario behaviour, in order to ensure that SoSwas capable of executing the scenario, and to increase our confidence in

19


the original SoS design. The simulator of the Symphony tool platform wasused.

Whilst formal techniques are improving, they are not of high enough TRLfor deployment in their “raw” form. Full integration with some establishedmodelling techniques (e.g., SysML) is vital, in order to take advantage ofsystematic analysis of dependability properties. Furthermore, they are typi-cally designed for and applied in discrete domains. We did not apply modelchecking or theorem proving in this project.

The Fault Modelling Architectural Framework (FMAF) helps the SoS engi-neer to understand ‘what if’ scenarios in the same modelling framework asthe architecture models produced with the IC pattern. This is due to the factthat the FMAF has been incorporated into the SoS engineering approach,via a fault modelling SysML profile. The FMAF proved valuable in identify-ing and managing causal chains leading to potential system and SoS failures,in understanding the consequences of dependability threats and in designingrecovery strategies.

Co-modelling allows engineers from different domains to model an SoS andthe CSs in their own notations and, along with co-simulation, enables trade-off analysis, design space exploration and fault modelling. This project usedVDM-RT for modelling software, 20-Sim for modelling physical systems andthe Crescendo tool for co-simulation. The technology used in this studyis used primarily in embedded and cyber-physical system modelling. Fullyincorporating it into an SoS engineering approach will require more effort,with multi-tool chain and diverse notations suitable for different stakehold-ers.

The co-modelling and co-simulation techniques have the potential to aidanalysis and assessment of dependability properties, especially in contextswhich integrate discrete and continuous domains. This is of great importancewithin LOSA, where the CSs of the SoS are connected with both data andphysical interfaces.

20


1.6 Conclusions and Future Work

1.6.1 Conclusions

The SoS and CPS engineering techniques we have shown form a feasible basisfor a pragmatic approach to assessing security and reliability dependencies,although the different elements are at different levels of maturity.

• SysML is a mature technology, and is supported by industrial-strengthtools. The IC pattern and the fault-modelling profile are extensions ofSysML, and are relatively immature, being still in development.

• Formal model analysis is a specialist area, and the challenge is to makethe analysis techniques available to non-specialists. The language weused, CML, has academic tool support available in the Symphony tool6.

• Co-modelling is a relatively recent innovation, and still the subject ofacademic study. In this project we made use of the academic toolCrescendo7.

Further investigation would be needed to incorporate the different technolo-gies into different frameworks for use in LOSA. For example, it may bepossible to incorporate the approach into MODAF. This would be helped bythe already consistent definitions and use of viewpoints and ontology.

1.6.2 Future Work

Having established the feasibility of an approach comprising various mod-elling technologies, we can consider several areas in which the ongoing re-search and experimentation programmes for LOSA may be directed. Weoutline these areas in this section.

1. In this study, we concentrated on technologies produced in the COM-PASS8 and DESTECS9 EU projects. A further study will comparethese model-based technologies with potential alternatives. This com-parison must also take into account cost-effectiveness and usability di-mensions. This comparison and evaluation will aid in understanding

6www.symphonytool.org7www.crescendotool.org8www.compass-research.eu9www.destecs.org

21

www.symphonytool.org

www.crescendotool.org

www.compass-research.eu

www.destecs.org


the impact of incorporating new technologies in normal SoS engineeringpractice in LOSA.

2. An assessment is required to determine the potential to integrate withrelevant engineering processes and standards (such as MODAF) in thedefence industry and to input to future LOSA and COI(L) standardsand LOSA joining rules.

3. The modelling techniques investigated used a simple feasibility exampleand in cases, notably requirements engineering, was only able to providea partial treatment of the technologies. A full treatment of stakeholderrequirements modelling including requirements that span both DE andCT elements of a LOSA SoS is required.

4. The co-modelling technologies assessed do not provide a contractualstyle of modelling as demonstrated in the architectural modelling tech-niques, deemed useful in SoS engineering. An integrated method forcontractual modelling and co-modelling in LOSA would be valuable.It would allow a unified approach to representation and simulation ofmodels of systems which have both software and physical properties atthe SoS-level.

5. Several methodological approaches are available with co-modelling, in-cluding design-space exploration (DSE). The application of DSE inLOSA should be considered to aid in understanding power require-ments over the life time of system, and may be useful for maintenanceand cost models of LOSA SoSs.

6. The various modelling technologies provide analysis results in the formof simulations, semi-formal model review, formal analysis and co-simulation.These results need to be placed in the context of safety cases in LOSAto determine how model-based techniques may be used as evidence insafety, security and dependability cases.

22

Chapter 2

Part 2: Modelling andAnalyses

2.1 Model-based SoS Design in LOSA

This study uses a collection of design time model-based techniques that mightbe used to realise the proposed activity sequence in Appendix A. In this docu-ment, therefore, we consider the feasibility of several model-based techniques,using variety of notations and methods from the SoS engineering and CPSengineering disciplines.

These technologies are:

• SoS Engineering

– Architectural modelling

– Formal modelling and analysis

– Fault modelling

– Requirements engineering

• CPS Engineering

– Co-modelling and Co-simulation

This document describes the modelling performed in this project, describingthe use of the various technologies, and summarising their use in understand-ing dependability in the context of a LOSA-based SoS. In Section 2.2 we

23


describe the architectural modelling effort using a contractual style of mod-elling, complemented in Section 2.3 by formal modelling. Section 2.4 showsthe use of a fault modelling technique to aid in reasoning about ‘what if’-typescenarios. A requirements engineering technique used to place requirementsin the context of stakeholders is shown in Section 2.5, and in Section 2.6 weuse co-modelling to understand the interaction between digital and physicalphenomena.

24


2.2 Architectural Modelling

We propose the use of modelling patterns and frameworks when definingLOSA architectural models. The first – the Interface Contract pattern –promotes a contractual approach to defining the CSs in terms of the obliga-tions and reliances they may place on the other members of the SoS. Thispattern typically considers only data in this contractual style. Therefore inSection 2.2.2 we extend the IC pattern to consider how flow-based properties– in this case electrical power – may be modelled and used to enrich thecontractually defined CSs.

2.2.1 Interface Contracts

The IC pattern is intended to allow the SoS engineer to specify limited in-ternal behaviours to which CSs are required to conform, in order for themto a part of the SoS. CSs may conceivably conform to multiple ICs (and notnecessarily ICs of the SoS of interest), and may conform to the IC in anyway they wish. Defining the SoS using this pattern allows the engineer toanalyse, and maintain, global emergent properties under SoS evolution andintegration.

The pattern defines several related viewpoints, which we demonstrate here:

Interface Contractual SoS Definition Viewpoint identifies ICs compris-ing the Contractual SoS.

Interface Contract Identification Viewpoint details the ICs in termsof its ports and interfaces and the collection of state and operationvariables.

Interface Contract Conformance Viewpoint defines the conformancerelationship between CSs and ICs.

Interface Contract Connections Viewpoint shows how ICs are connectedthrough their interfaces.

Interface Contract Definition Viewpoint defines ICs in terms of theirstate variables, state invariants and operations they may provide.

Interface Contract SoS Behaviour Viewpoint describes an example sce-nario which the ICs take part in.

Interface Contract Protocol Definition Viewpoint defines any Proto-cols to which an IC must conform.

In the remainder of this section, we describe the application of this patternto the Feasibility Example.

25


Interface Contractual SoS Definition Viewpoint

The Interface Contractual SoS Definition Viewpoint (ICSDV) identifies theICs of the study, shown in Figure 2.1. The Figure shows that the Feasibil-ity Example comprises three IC types; a Patrol IC, a Vehicle IC and twoSoldier ICs.

Figure 2.1: Interface Contractual SoS Definition Viewpoint for FeasibilityExample

The ICSDV also identifies a global SoS-level constraint. In this feasibilitystudy, we do not define this constraint further. We believe it may provevaluable for SoSs design, but it requires further investigation and develop-ment.

Interface Contract Identification Viewpoint

For each IC in the ICSDV above, we identify the ports and interfaces theyrequire and provide to their environment. In Figure 2.2 we show the threeICs, with their standard ports labelled, in an Interface Contract IdentificationView (ICIV).

Each port is typed by the interface they provide. For example, the Vehicle IChas four ports: the HiCommsPort port provides and requires the HiComm IFinterface, the ScanPort port provides and requires the Scan IF interface, andthe LowCommsPort provides and requires the LoComm IF interface.

We consider two main types of communication interface - HiComm and Lo-Comm. The intuition here is to abstractly model different bandwidth com-munication mechanisms, which may allow different data to be transmitted.For example, a HiComm interface may allow data and voice communication,whilst LoComm interfaces may only allow voice communication. It is beyond

26


Figure 2.2: Interface Contract Identification Viewpoint for Feasibility Exam-ple

the scope of this study to model such mechanisms in detail. The model maybe extended to include explicit representing of the communication media ifrequired.

The figure also includes the operations provided by each IC, which are fur-ther defined in Interface Contract Definition Views described in the nextsection.

Interface Contract Conformance Viewpoint

In the Interface Contract Connections View (ICConfV) in Figure 2.3, wedefine how the CSs of the SoS conform to the defined ICs. In this example,the conformance relationships are relatively straightforward. In previouswork, we have described how such conformance relationships may be verified,though this is beyond the current state of the art [5].

Interface Contract Definition Viewpoint

Interface Contract Definition Viewpoints (ICDVs) enable the contractual de-scription of the IC’s state and operations. Each IC has an ICDV defined forit, as shown in Figures 2.4, 2.5 and 2.6.

Figure 2.4 shows the ICDV for the Vehicle IC, with its five operations. Eachoperation may have a precondition and postcondition, which describe the

27


Figure 2.3: Interface Contract Conformance Viewpoint for Feasibility Exam-ple

requirements and obligations of the operations. For example the loCommand hiComm operations both have a postcondition which states that anylow and high communications are logged.

Figure 2.4: Interface Contract Definition Viewpoint for Vehicle IC

28


The Soldier IC IC depicted in Figure 2.5 has an invariant (a condition thatmust hold through the life of the IC), which states that each soldier has aunique identifier. The createOrder and createAllClear operations both havepostconditions which restrict their use to only include some nominated ‘safelocation’. The createOrder operation also has a postcondition which ensuresthat the order being sent to is for the correct location and one that ensuresthat that the order includes the scan image.

Figure 2.5: Interface Contract Definition Viewpoint for Soldier IC

The Patrol IC IC is significantly more simple – with an invariant to ensureit has a different identifier from the Vehicle IC. The loComm operation has apostcondition which restricts the order in which the messages are being sentto comply with the scenario.

29


Figure 2.6: Interface Contract Definition Viewpoint for Patrol IC

Interface Contractual Connections Viewpoint

The Interface Contract Conformance Viewpoint (ICCV) presented in Fig-ure 2.7 shows how the different ICs are connected.

Figure 2.7: Interface Contractual Connections Viewpoint for Feasibility Ex-ample

The view also identifies the different instances of the Feasibility Example ICsrelated to the different CSs of the Feasibility Example SoS.

Connections are made between the ports of the ICs in terms of the providedand required interfaces. In this study, Figure 2.7 shows that the DismountedSoldier is connected to the Mounted Soldier, which is connected to the Ve-hicle. Finally the Vehicle is connected to the Patrol.

30


Interface Contract SoS Behaviour Viewpoint

The Interface Contract SoS Behaviour View (ICSBV) is not a part of theoriginal IC pattern. We have added this view in this project, so as to betterdescribe the example scenario in the Feasibility Example study. By defin-ing ICSBVs, we can explore the possible permitted and faulty behavioursafforded by the SoS in terms of example scenarios.

Figure 2.8 depicts one such ICSBV for the Feasibility Example study inwhich the different ICs communicate in order to check if a particular locationis clear. The ICSBV shows a set of steps – communications and internaloperations – which the different ICs perform.

Figure 2.8: Interface Contract SoS Behaviour Viewpoint for Feasibility Ex-ample

This view may also be used to describe test cases – that is the collection ofpermitted interactions between the CSs. These test cases can be checked forconsistency with the expected behaviours of each IC. In the final part of theIC definition below, we detail such behavioural diagrams.

Interface Contract Protocol Definition Viewpoint

The final collection of IC pattern views defined as part of the FeasibilityExample study are the Interface Contract Protocol Definition Viewpoints

31


(ICPDVs). These views, shown in Figures 2.9, 2.10, and 2.11, are shown asSysML state machine diagrams. We use CML expressions and statements(we describe CML in more detail in Section 2.3) to define the transitionsbetween states.

Figure 2.9 shows the ICPDV for the Patrol IC. The view shows that a Pa-trol IC begins in a ready state until it sends a verbal message on the lo-Comm in signal (the use of ‘!’ is CML notation corresponding to outputson the signal) to the Vehicle IC. The Patrol IC waits until they receive amessage (the ‘?’ corresponds to inputs being received on a signal). If thatmessage is a verbal standby, they wait for another message. Once an all clearmessage is received, the Patrol IC has finished their duties.

Figure 2.9: Interface Contract Protocol Definition Viewpoint for Patrol IC

In Figure 2.10, the ICPDV for the Soldier IC allows for multiple differentbehaviours, depending upon the message received. The Soldier IC may:receive an order to check an area and issue an ‘All Clear’ message in reply;request a scan from the Vehicle IC ; or inform the Patrol IC that the area isall clear.

The final ICPDV in Figure 2.11, is for the Vehicle IC. The Vehicle IC willeither: process requests to perform a scan operation and return the result;forward a loComm message as a hiComm message; or receive a hiCommmessage and forward as a loComm message. Once one to these optionsis performed, the Vehicle IC is able to perform any of those behavioursagain.

2.2.2 Modelling Power Flows

The IC pattern is focused on the data-based phenonoma of SoSs – it enablesthe definition of data, operations to change data and the means to describe

32


Figure 2.10: Interface Contract Protocol Definition Viewpoint for Soldier IC

communications. In LOSA SoSs, it is important to consider the various flow-based interfaces between CSs. These include: power, fuel, water and waste.The interfaces required differ between the different CS types.

In this project we consider the feasibility of modelling such flows along withthe contractual description used in the IC pattern. We consider extendingthe IC pattern to model:

• Power-related values and inputs/outputs of CSs

• Flow of power between CSs

• Behavioural constraints based on physical properties

• Relationships between power-related values.

Identifying Power-related Properties, Inputs and Outputs

Taking the ICIV defined earlier, we extend the view to include power-relatedproperties. In Figure 2.12, we refer to these values as CT..., i.e. CTVoltage-Out in the Vehicle IC IC. ICs also have flow ports which correspond to theflow of a physical ‘material’ into and out of the IC. Each flow port is typedby the type of matter flowing into or out of the IC: the powerOut flow port

33


Figure 2.11: Interface Contract Protocol Definition Viewpoint for Vehicle IC

dictates that material of type PowerFlow flows out of the IC – relating toelectrical power.

Figure 2.12: Interface Contract Identification Viewpoint for Feasibility Ex-ample, including power values

Flow of Power

Having identified the points at which power may flow in and out of the ICsof the SoS, we extend the ICCV to include connectors with item flows. InFigure 2.13, we depict the flow of power from the Vehicle IC to the Mount-edSoldier Soldier IC.

In addition to this, we demonstrate the use of constraints to correspond tothe requirement on external power identified in the Generic Soldier Architec-

34


Figure 2.13: Interface Contractual Connections Viewpoint for Feasibility Ex-ample, including power flows and constraints.

ture standard [19]. Whilst this may be better suited as a uniquely definedrequirement, we feel that representing this directly on the ICCV is also use-ful.

Constraining behaviour

We demonstrate how the power-related value may be used in the contractualdescription of the CSs. In Figure 2.14, we see the use of the power value,obtained through the port powerIn, in an ICPDV. In this view, the Soldier ICmay only make a request for scan functionality when the incoming powermeets certain requirements – with a minimum current and voltage.

Whilst this is a simple example, we consider the use of flow-based values inICPDV to be a valuable tool for reasoning about the behaviour of CSs inthe presence, and absence, of power, fuel, water and waste – vital elementsof COI(L) interfaces. We could consider, for example modelling the range ofbehaviours when the supply of power is interrupted during normal operation,which would inform such a contractual specification.

35


Figure 2.14: Interface Contract Protocol Definition View for Soldier IC show-ing use of power value

Parametric Diagrams

In Figure 2.15, a BDD, we include two SysML constraint blocks. These blocksown ‘parametric equations’ which describe the relationships between differ-ent ‘parametric parameter’ values. In Figure 2.15, we show two constraintblocks relating to two power-related physical laws. The first block, ParallelJunction, relates to a parallel junction in an electrical circuit, where voltageis the same on both parallel junctions, but where the incoming current isshared.

Figure 2.15: Block Definition Diagram showing power-related constraintblocks

36


The second constraint block, Power Equation, shows the equation requiredto show the relationship between incoming voltage, current and power inWatts.

Having defined the two constraint blocks, we show how these may be usedin a Parametric Diagram (PD) in Figure 2.16. This diagram relates valuesdefined in the ICs in Section 2.2.1 with respect to various physical laws. Thisdiagram allows us to model the ways in which power may be used in the SoSand ultimately reason about the power usage in such a SoS.

Figure 2.16: Parametric Diagram showing use of constraint blocks


Architectural modelling allows an SoS engineer to assess the dependability ofa LOSA SoS using informal model review and exploration. We summarise thetypes of dependability properties which may be assessed in Figure 2.17.

Properties related to availability – such as when certain behaviour (in termsof operations) is not be available – may be modelled in ICPDVs. Using a fullydefined SoS we may explore the situations in which functionality is not avail-able and the effects this may have on the other ICs in the SoS. Similarly, wemay model faulty communications when representing communication media

37


Figure 2.17: Assessing Dependability – Architectural Modelling

explicitly and, using ICPDVs and ICSBVs, explore the outcomes of messagesbeing lost or other faults on the SoS.

In an ICDV, we may identify states which an IC may enter which can be con-sidered to be ‘unsafe’. We may in turn distinguish which transitions may leadto these ‘unsafe’ states and design measures to prevent such transitions.

Finally, by modelling physical properties as continuous variables, we mayexplore their effects on behaviours in transition guards in ICPDVs to under-stand the reliance and dependancies on such physical properties to providethe expected behaviour.

38


2.3 Formal Modelling

Given a semi-formal, diagrammatic, model of the Feasibility Example SoSarchitecture, we consider the use of formal notations, which afford the useof formal analysis. In this study, we propose the use of CML (COMPASSModelling Language) [22]. This notation is based on well-established formallanguages (VDM [9] and CSP [11]) with a formal mathematical semantics.The language allows the modelling of data, functionality, event ordering andcommunication, and is extensible. The language, developed in the COM-PASS project, has an associated tool platform, Symphony1, containing abroad range of formal analysis techniques. Prototype tool support has beendeveloped for translating models from SysML into CML.

In this section we show how the SysML model may be described in the formalmodelling notation CML, following the approach to translation taken in [4].We go on to show how the resultant model may be analysed. The completemodel is presented in Appendix B, and in this section we provide a briefdescription of key parts of the model.

A CML model consists of a number of processes, each encapsulating scopedstate variables and a description of process behaviour. The process definitioncomprises: a set of typed values (its state variables), operations which mayaccess and modify state, and a set of interconnected actions describing theordering of operation calls and data communications. CML provides com-binators to describe a wide variety of activity, including choice, sequencing,parallel activity, and timeouts and interrupts.

The CML model is derived from the SysML model outlined in Section 2.2. Wedid not use the SysML-CML translation tool, currently in development, toperform this translation; the CML model derivation is performed manually.To give a flavour of the model, we concentrate on the overall structure of theCML model and the actions of the Solider IC.

2.3.1 SoS Structure

We use the ICSDV in Figure 2.1 and the ICCV in Figure 2.7 to define thestructure of the CML model in terms of the required processes and howthey communicate. We begin by defining processes for the four ICs: Patrol,

1www.symphonytool.org

39



DismountedSoldier, Vehicle and MountedSoldier, as shown below (the pa-rameters are defined as test values in the model for analysis purposes).� �process Patrol = Patrol_IC(pId , vId)

process DismountedSoldier = Soldier_IC(disId , mId , vId)

process Vehicle = Vehicle_IC(vId , mId , pId)

process MountedSoldier = Soldier_IC(mId , disId , vId)� �Given the definition of these four processes, we combine them using the CMLsynchronisation operator – using defined chansets (sets of communicationchannels), which correspond to the interfaces used in the ICCV in Figure 2.7.We obtain the process FeasibilityExample IC below.� �FeasibilityExample_IC =

Patrol

[| loComm_IF |]

(

(Vehicle ||| DismountedSoldier)

[| hiComm_IF union scan_IF |]

MountedSoldier

)� �In the next section, we describe the Soldier IC process in more detail todescribe how the behaviour of the CML model is modelled.

2.3.2 Soldier IC Behaviour

We use the combination of the ICDV in Figure 2.5 and the ICPDV in Fig-ure 2.10 to define the Soldier IC process.

A CML process may include state and operations, which we omit from thisdescription as they are derived directly from the ICDV. The full modelappears in Appendix B. We concentrate here on the behaviour of the IC interms of the ordering of operation calls and communications with the otherICs in the Feasibility Example. This ordering is defined in a CML processas actions. We use the ICPDV and map SysML states to CML actions withthe same name.

The Soldier IC process begins by behaving as the MessageIn action, and

40


waits to receive a message on the hiComm In channel addressed to this pro-cess (the statement hiComm in?i.myId?m corresponds to the process identi-fied by myId receiving a message m on channel hiComm In from a processwith id i). It then calls the hiComm operation and behaves as the actionNewMessage.� �MessageIn = hiComm_in?i.myId?m -> (hiComm(i, myId , m);

NewMessage(m))� �The NewMessage action uses the message received in the previous actionand checks the type of message to determine the action to be taken. If themessage contains coordinates, the process behaves as the ScanRequest action,if the message is an order, the process behaves as the IncomingOrder actionand finally if the message is ‘all clear’, then it behaves as InformPatrol.� �NewMessage = m : Msg @

[is_Coords(m)] & ScanRequest(m)

[]

[is_Order(m)] & IncomingOrder(m)

[]

[is_AllClear(m)] & InformPatrol(m)� �When behaving as the ScanRequest action, the Soldier IC communicateswith its environment (in this case with the Vehicle IC ) and sends the coor-dinates to be checked on the scanReq in channel. Subsequently, it receivessome result on the scanReq out channel and behaves as the IssueOrder ac-tion. This action creates Order and Standby messages which are sent on thehiComm in channel to the DismountedSoldier and Vehicle respectively. Theprocess then behaves as the initial MessageIn action.� �

ScanRequest = c : Coords @

scanReq_in!c -> scanReq_out?s -> IssueOrder(s,c)

IssueOrder = s : Scan , c : Coords @

(dcl o : Order := createOrder(s,c) @ hiComm_in.myId.

otherId!o ->

(dcl sb : Standby := createStandby(c) @

hiComm_in.myId.vId!sb -> MessageIn))� �The InformPatrol action simply sends the incoming ‘all clear’ message to theVehicle IC on the hiComm in channel and then behaves as the MessageIn

41


action.� �InformPatrol = ac : AllClear @ hiComm_in.myId.vId!ac ->

MessageIn� �Finally, the IncomingOrder action uses the incoming order, and first checksthat the coordinates of the order are in a designated safe location (using theguarded action [((o.c) not in set unsafeLocs)] & ...) then recordsan image with the recordImage operation and then behaves as the Location-Clear action. This action creates an ‘all clear’ message which is sent to theMountedSoldier and then behaves as the initial MessageIn action.� �

IncomingOrder = o : Order @

[((o.c) not in set unsafeLocs)] &

(dcl i : Img := recordImage(o.c) @

LocationClear ((o.c),i))

LocationClear = c : Coords , i : Img @

(dcl a : AllClear := createAllClear(c,i) @

hiComm_in.myId.otherId!a -> MessageIn)� �In the next section we describe the analyses available to an SoS engineerusing the formal CML notation.

2.3.3 Analysis

The Symphony tool platform2 provides a collection of analysis tools to vali-date and verify a CML model3:

• the Interpreter and RT-Tester used for requirement validation,

• the Theorem prover and Model checker may be used for property ver-ification,

• the Static Fault Analysis plugin allows FMEA and fault tree analysis(from SysML models),

• and external links allow distributed SoS engineering.

2www.symphonytool.org3Analysis plugins are at a varying level of maturity (discussed further in Part 1 of this

document).

42



In this project, we use the interpreter to test the CML model. Figure 2.18shows the Symphony tool platform running a simulation of the FeasibilityEx-ample IC model. The model is visible in the top left pane, and the eventsthat have already been performed are visible in the top right. The user se-lects the next event from the pane below that, and the current status of theanalysis run is visible at the bottom.

Figure 2.18: Symphony Simulator

Using the simulator, we were able to replicate the SoS behaviour given inFigure 2.8. The simulator output is shown in Figure 2.19, and the tracecarried out is visible in the top right-hand pane of the Figure 2.19.

Simulation can be partially automated by developing CML processes thatembody specific tests, and running these in parallel with the system undertest. This allows us to conduct both positive and negative tests (ones in-tended to test the absence of incorrect behaviours), and these processes canbe derived directly from figures such as Figure 2.8.

43


Figure 2.19: Simulating behaviour with Symphony


Using the analysis techniques described above, we may consider how depend-ability properties may be verified. Figure 2.20 provides an overview of thosedependability properties and how they may be assessed using the formalmodelling carried out in this study.

Using the interpreter of the Symphony tool platform, we may simulate themodel and explore the consequences of function interfaces not being avail-able – whereby ICs do not offer the opportunity to communicate due to notsynchronising on events. In a similar method to the architectural modelling,we may simulate lost messages and explore the consequences of unreliablecommunications.

In addition, we use invariants which dictate properties of processes whichmust hold through the life of that process, corresponding to safe states.Violation of an invariant during simulation may indicate that SoS behaviourresults in an unsafe state.

Finally, there are other analysis techniques available, but not demonstratedin this study, which may be used to strongly verify dependability proper-

44


Figure 2.20: Assessing Dependability – Formal Modelling

ties. Having a formal mathematical-based semantics allows the use of formalanalysis techniques – the Symphony tool platform has plugins for the Isabelletheorem prover4 and the Microsoft Formula model checker5. The use of thesetools is, however, not in a mature state – and thus we do not consider theiruse for LOSA.

4http://isabelle.in.tum.de5http://research.microsoft.com/en-us/projects/formula/

45


2.4 Fault Modelling

One possible means of achieving dependability is in the ability for a systemto tolerate faults. In SoS, this is a nascent area of research, however in theCOMPASS project a Fault Modelling Architectural Framework (FMAF) hasbeen developed which allows engineers to consider how the different elementsin a SoS may fail and the possible consequences of those failures. The FMAFalso allows an engineer to design redundancy into a SoS and consider recoverystrategies. The FMAF uses terminology widely accepted in the dependabilitycommunity [2], but lifts these concepts to the SoS-level6. In this section, weprovide an example of its use in the Feasibility Example study.

2.4.1 Identifying Faults, Errors and Failures

In applying the FMAF, we begin by identifying and describing the possiblefaults which my occur in the SoS. The Fault/Error/Failure Definition View(FEFDV) in Figure 2.21, provides unique identifiers to each fault, error andfailure identified, along with a textual description. In previous work, we havealso considered how we may provide traceability links to requirements, whichwould be of use when identifying faults, errors and failures.

6We consider a SoS failure to be the deviation of service provided by the SoS from theexpected behaviour. An error is the state of the SoS that may lead to the failure, and afault is the adjudged or hypothesised cause of an error. It is important to note, that afailure from the point of view of a single CS becomes a fault from the point of view of theSoS.

46


Figure 2.21: Fault/Error/Failure Definition View for Feasibility Examplestudy

The figure identifies six faults – relating to failures of the CSs and theircomponents parts. The five errors relate largely to services or funcrionalitieswithin the SoS being unavailable. The one identified failure of the FeasibilityExample SoS is considered to be that the chosen target is not given the allclear.

2.4.2 Threat Chains

Having defined these faults, errors and failures for the Feasibility Examplestudy, we may consider the causal chains which lead to ultimate SoS failure.For each possible fault, we define a Threat Chain View (TCV). Figure 2.22is one such TCV for Fault 6 – Scan Request Equipment Failure. A completetreatment would define a TCV for all threat chains obtained from the faults,errors and failures in the FEFDV.

47


Figure 2.22: Threat Chain View for Fault 6

Fault 6 corresponds to the scan equipment owned by a soldier – in this casethe mounted soldier – no longer working as expected. In this situation, anerror state is entered in which the soldier is unable to request scans, whichmeans that the patrol is not able to receive an all clear message.

2.4.3 Behavioural Views: Nominal, Erroneous and Re-covery

In order to understand how faults, errors and failures may manifest them-selves, we first define the SoS nominal behaviour Process View (PV) using aSysML activity diagram, as in Figure 2.23. This view describes the ‘searchand provide all clear’ scenario, as previously shown in the ICSBV in Fig-ure 2.8.

48


Figure 2.23: Process View for nominal behaviour

Given the nominal behaviour PV, we define a Fault Activation View (FAV)in Figure 2.24. This view details the point in the SoS behaviour at which afault may manifest, the resultant erroneous behaviour and finally the failureevent. We use stereotyped model elements to represent these fault modellingprinciples. In Figure 2.24, the activation of Fault 6 occurs when the MountedSoldier attempts to request a scan. An interruptible region in SysML is usedto denote the place in which the fault may occur. Given the fault occurrence,the erroneous behaviour may lead to a failure event, unless this is interruptedby the error detection by the Mounted Soldier. In this case, the recoverystrategy is enacted.

49


Figure 2.24: Fault Activation View for Fault 6

Before defining the recovery strategy, the redundancies in the SoS are given,which may be used to provide this recovery. In Figure 2.25, a Soldier ICis defined as being able to act as redundancy for another Soldier IC. InFigure 2.26 we define the required change in connections – showing that theredundant Soldier IC connects to the Vehicle IC.

50


Figure 2.25: Fault Tolerance Structure View detailing the CS redundanciesin the case study

Figure 2.26: Fault Tolerant Connection View detailing the connections re-quired for CS redundancies in the case study

The final view of the FMAF is the Recovery View (RV). This view, as

51


shown in Figure 2.27, shows the SoS behaviour to recover from the erroneousbehaviour. The proposed recovery strategy sees the two soldiers swappingroles, with the dismounted solider performing scans and the mounted soldierperforming the visual checks of the area. The same SoS-level behaviour isobserved.

Figure 2.27: Recovery View for Fault 6 with Soldiers switching roles


Modelling threats to dependability in an architectural model has the po-tential to be a useful tool for understanding and communicating about de-pendability and the consequences of threats in a LOSA SoS. In Figure 2.28,we provide an overview of the application of the FMAF in assessing LOSAdependability.

52


Figure 2.28: Assessing Dependability – Fault Modelling

Using the FMAF, we may represent threats to dependability – whether theyare threats to availability, reliability or safety – and investigate their conse-quences leading to potential SoS failures. Using this technique at the archi-tectural level is very powerful in that it helps us understand possible criticalelements of the SoS, design recovery strategies, make explicit the causes ofSoS failures and be used as a tool for discussing fault tolerance requirementsacross multiple stakeholders.

53


2.5 Requirements Engineering

Understanding stakeholder roles, requirements and the stakeholder perspec-tives on those requirements is a key concern in SoS engineering in LOSA.In addition, the ability to trace requirements from their source, throughto model elements and analysis results is also of importance in complexSoSs.

We consider the use of a model-based technique for requirements engineer-ing, using SysML requirements diagram in a modelling approach to helpunderstand requirements and the contexts in which they may be considered.The technique used in this project is SoS-ACRE [14] – the SoS Approach toContext-based Requirements Engineering.

2.5.1 Defining Requirements

We first identify and describe all requirements for the feasibility example ina Requirements Description View (RDV) in Figure 2.29.

Figure 2.29: Requirements Description View of feasibility example require-ments

54


In the RDV in Figure 2.29, There is a single top-level requirement – Feasibil-ity Example Requirement with several sub-requirements. These requirementsrelate to the scenario we use in this study, and therefore are not intended tocorrespond directly to the complete set of requirements typical in a SoS in theLOSA context. The top-level requirement may be decomposed into three re-quirements: Allow IC-IC communication, Generic soldier power requirementand Provide ‘All Clear’ on a location. These requirements are decomposedfurther, as shown in the figure. Each requirement has a description and aunique identifier (the identifier is not shown on the diagram).

2.5.2 Requirements in Context

In addition to the description of the requirements and the identification ofthe different CSs of the SoS, as shown in Figure 1.4, the SoS-ACRE approachproposes the identification of stakeholders for the SoS. These stakeholders, asshown in the Stakeholder Definition View (SDV) in Figure 2.30, are definedas being either a User, External or Stakeholder (there may be other types inthe SoS).

Figure 2.30: Stakeholder Definition View of feasibility example

In this study, we identify the following stakeholders: user – Local popula-

55


tion; external – Government, Foreign government, Standards body and Me-dia; and supplier – Vehicle manufacturer, Communications manufacturer,Soldier equipment manufacturer and Scan manufacturer.

Having identified the study requirements, CSs and stakeholders, we mayplace the requirements in context. SoS-ACRE advocates analysing the re-quirements in the context of each separate CS, and then combining themon a separate, SoS-level view, the Context Interaction View (CIV). This isseen as a key part of SoS requirements engineering by providing an expandedview of requirements, presented in their separate contexts, for the entire SoS.This may be the first time that requirement and contexts are analysed to-gether, and is helpful for identifying conflicts, inconsistencies and duplicatedfunctionality.

In this feasibility study, SoS requirements are analysed in the context of thedifferent CSs and stakeholders in Figure 2.31 and Figure 2.32 respectively. Inthese diagrams, requirements are represented as use cases, and the CSs andstakeholders as ‘users’. Where a stakeholder or CS has some involvement orinterest in a requirement, there is a link between the stick figure and a usecase.

Figure 2.31: Context Interaction View of requirements – CSs

56


Figure 2.32: Context Interaction View of requirements – Stakeholders

Figure 2.31 depicts the requirements in the context of the different CSs of theSoS. Some requirements are in the context of only one CS; for example Pro-vide visual check on location is in the context of only the Dismounted Soldier.However, there are some requirements, such as Log all communications andevents, which are in the context of several CSs and, considering Figure 2.32too, several stakeholders. In such a case, the requirement must be examinedfrom the perspective of each party to ensure they hold a common under-standing and there are no conflicts in interpreting the requirement.


Requirements engineering as a technique is not immediately relevant withrespect to assuring dependability in a LOSA SoS, as such we do not relatedthis technique to the dependability properties. However, if this model-basedtechnique is used in combination with the various SysML techniques, LOSASoS engineers can take advantage of traceability links from requirementsthrough to model elements in the architectural models. This approach, asshown in [1], allows the tracing from fault tolerance requirements to elementsin a model defined using the FMAF.

57


For this technique to be more suited to SoS dependability, a clearer methodis required for identifying, capturing and specifying requirements specificallyrelated to dependability. This may be achieved through the use of SysMLstereotyping and defined traceability link types. These traceability links willconnect dependability-specific requirements to stereotyped elements in thevarious model-based techniques and analysis results.

58


2.6 Co-modelling and Co-simulation

2.6.1 Co-modelling

In a co-model, we model both the software and hardware elements of theLOSA SoS. The software elements are modelled using a discrete-event (DE)notation (we use VDM-RT), and hardware using continuous-time (CT) no-tation (such as differential equations).

In simulation, DE models only represent points in time at which the statechanges, and provide good abstractions for software (e.g. data types, object-orientation, threading). However, they are less suited for physical systemmodelling. In contrast, in CT model simulation the state changes continu-ously through time. CT models have good abstractions for physical systemdisciplines (e.g. mechanical, electrical and hydraulic system elements) buttypically offer poor support for modelling software.

Using co-modelling techniques we can define both DE and CT models and de-fine a contract to allow them to be simulated together. We use the Crescendotool7 for co-modelling; taking advantage of the Overture tool8 and 20-Sim9

for DE and CT modelling respectively.

We alter the model slightly from the Feasibility Example used elsewherein this report; considering a LOSA SoS with one vehicle and two mountedsoldiers drawing power from the vehicle. The power use from the two soldierschanges over time.

Discrete Event Model

We define the software controller using the VDM-RT notation. Figure 2.33provides a high-level overview of the DE model using a UML class diagram.This figure shows that our DE model only considers the two mounted soldiers,with different types of controller: basic and complex.

The ‘basic’ controllers provide different operating modes for the Scan, Mapand GPS functionalities provided by the equipment worn by the mountedsoldier. Those different operating modes require varying power. We define ascenario which dictates when the different operating modes can be used.

7www.crescendotool.org8www.overturetool.org9www.20sim.com

59

www.crescendotool.org

www.overturetool.org

www.20sim.com


Figure 2.33: UML class diagram representing structure of DE model

A ‘complex’ controller is modelled for the battery charger policy on themounted soldiers. This controller will only allow the soldiers’ battery tobe charged when those mounted soldiers are not drawing too much power.The aim of this policy is to restrict the possibility of voltage drops.

Continuous Time Model

In the CT model we begin by defining a top-level block diagram in the 20-sim tool. This permits the composition of a model in terms of the differentLOSA SoS elements, and also the DE controller. This is shown in Fig-ure 2.34. It is important to note that in 20-sim, we model both effort andflow – corresponding to voltage and current as we are modelling the electricaldomain.

The top-level block diagram is subsequently decomposed into those differ-ent parts. Defining the vehicle in Figure 2.35, we take an abstract view,comprising; a source of effort (SE in the model) representing the batteryproviding power to the soldiers, some internal resistance (R) and step downtransformer (TF) to deliver the correct voltage and current to the soldiers. A‘zero’ junction (0) is used which corresponds to a parallel junction to each ofthe mounted soldiers.

The two mounted soldiers are very similar to each other; we present only

60


Figure 2.34: SoS-level 20-sim block diagram connected by signals and energybonds

Figure 2.35: Vehicle IC 20-sim bond graph

MountedSoldier IC1 here. The model of the soldier represents the differentfunctions (battery charging, scan, GPS and radio) as a changing resistancebased upon the power being used by those functions at any given time. Themodel defines this using an incoming port and an equation in the MR elementto determine the correct resistance. We use a collection of power meters (a’P’ surrounded by a circle) to monitor the power being drawn at differentpoints in the model, and sum these to provide the DE controller the currentpower being drawn by each mounted soldier.

Co-model Interface

Given the DE and CT models, we identify the monitored and controlledvalues in a co-model interface. This interface is defined from the perspectiveof the DE model, and is shown below:� �-- Monitored variables (seen from the DE controller)

-- MOUNTED SOLDIER 1 --

monitored real ms1CurrentPower;

61


Figure 2.36: MountedSoldier IC1 20-sim bond graph


monitored real ms2CurrentPower;

-- Controlled variables (seen from the DE controller)


controlled real ms1BatteryExpectedPower;

controlled real ms1ScanExpectedPower;

controlled real ms1GPSExpectedPower;

controlled real ms1RadioExpectedPower;


controlled real ms2BatteryExpectedPower;

controlled real ms2MappingExpectedPower;

controlled real ms2GPSExpectedPower;

controlled real ms2RadioExpectedPower;� �In the interface we state that the DE model will monitor the current powerusage from the two mounted soldiers, and will use those values in the con-trol logic. The DE model will subsequently change the values of the powerusage of the various functions on the mounted soldiers. We use the keywordsmonitored and controlled to denote the different type of values.

62


2.6.2 Co-simulation

Having defined the DE and CT models and the co-model interface, the modelscan be simulated. We use the Crescendo tool to enable this co-simulation. Weencode a simple scenario in the DE model which uses the different mountedsoldier function modes over time. The scenario can be summarised using thegraphical output in Figure 2.37. In the chart titled MS1 ScanFunction (lhsof , Figure 2.37) the power used changes as the Scan function changes mode:predicting coordinates (175W); turned off (0W); image processing (250W)and reviewing playback (125W).

Figure 2.37: Co-simulation results – MS1

In Figure 2.37, in the chart labelled MS1 GPSFunction, the function changesfrom standby mode (50W) to a relay position mode (175W) periodically. Thiscorresponds to the GPS unit sending the position to some central commandon a regular basis.

Given these scenario-based power uses, the ‘complex’ controller of the bat-tery charger will use power to charge the soldier’s battery (300W) when it isappropriate to do so. In this particular controller policy, we state that thebattery may be charged when the total power being consumed by other func-tions is less than 200W. This results in a power usage as shown in Figure 2.38,in the chart labelled MS1 BatteryCharge.

Figure 2.38: Co-simulation results – MS1

63


In the chart labelled MS 1TotalPower in Figure 2.38, we see the resultanttotal power usage. This chart displays the consequences of the different con-trollers in terms of the total power used by the mounted soldier. The designdecisions made result in a potentially unsatisfactory situation, where powerspikes are produced where the power being drawn temporarily increases to600W when all functions are being used, until the battery controller reacts,and stops charging the battery.

This is a powerful result in that the software designer may now better un-derstand the consequences of policy design at an early stage of developmentand may choose a different strategy; for example using forecasting, shortersensing periods, or some distributed control algorithms.

Finally, we may consider how this work may be taken into a SoS domain.This is beyond the scope of this project, but we may consider how controllerson different CSs may communicate to ensure global constraints are met; forexample controllers on the vehicle may communicate with software controllerson the mounted soldiers, which together alter the power usage. We revisitthis in the conclusions of the report.


As we can model continuous variables in a CT model, the use of co-modellingprovides us with the capability of assessing the dependability of continuousproperties. Figure 2.39 provides an overview of the dependability assessmentfor co-modelling.

Figure 2.39: Assessing Dependability – Co-modelling

In this study, we are able to model the electrical variables across a simpleLOSA example, and understand the impact of design decisions in software

64


on those electrical variables. In the small study, we were able to detectpower spikes resulting from the software controller allowing additional powerto be drawn before policy decisions are made by a reactive controller. Thismodelling technique allows an SoS engineer to observe these fluctuations incombined models and understand how dependable the system is in providingphysical properties.

By expanding the model, we may consider codifying requirements on electri-cal power as conditions in the model. This would enable us to detect placesin the simulation where the model violates those conditions. In our study,for example, we may wish to ensure that an individual soldier never drawsmore than 550 watts, in which case the tested controller would fail.

65


Acknowledgements

The project reported in this document was funded from the DE&S Technol-ogy Office.

66

Bibliography

[1] Z. Andrews, C. Ingram, R. Payne, A. Romanovsky, S. Perry, and J. Holt.Traceable engineering of fault tolerant soss. In INCOSE InternationalSysmposium on System Engineering. INCOSE, 2014.

[2] A. Avizienis, J.-C. Laprie, B. Randell, and C. Landwehr. Basic Conceptsand Taxonomy of Dependable and Secure Computing. IEEE Transac-tions on Dependable and Secure Computing, 1:11–33, 2004.

[3] M. Broy. Engineering Cyber-Physical Systems: Challenges and Foun-dations. In M. Aiguier, Y. Caseau, D. Krob, and A. Rauzy, editors,Complex Systems Design & Management, pages 1–13. Springer BerlinHeidelberg, 2013.

[4] J. Bryans, J. Fitzgerald, R. Payne, and K. Kristensen. MaintainingEmergence in Systems of Systems Integration: a Contractual Approachusing SysML. In INCOSE International Symposium (IS2014), 2014.

[5] J. Bryans, J. Fitzgerald, R. Payne, A. Miyazawa, and K. Kristensen.SysML Contracts for Systems of Systems. In IEEE 9th InternationalSystem of Systems Engineering Conference, 9-13 June 2014, Adelaide,June 2014.

[6] J. W. Coleman, L. D. Couto, K. Lausdahl, C. B. Nielsen, A. K. Malmos,P. G. Larsen, R. Payne, S. Foster, A. Miyazawa, U. Schulze, A. Cajueiro,and A. Didier. Fourth release of the COMPASS tool — user manual.Technical report, COMPASS Deliverable, D31.4a, September 2014.

[7] J. Dahmann. Systems of Systems Pain Points. In INCOSE InternationalSymposium on Systems Engineering 2014, april 2014.

[8] J. Fitzgerald and P. G. Larsen. Modelling Systems – Practical Tools andTechniques in Software Development. Cambridge University Press, TheEdinburgh Building, Cambridge CB2 2RU, UK, Second edition, 2009.ISBN 0-521-62348-0.

67


[9] J. Fitzgerald, P. G. Larsen, P. Mukherjee, N. Plat, and M. Verhoef.Validated Designs for Object–oriented Systems. Springer, New York,2005.

[10] J. Fitzgerald, P. G. Larsen, and M. Verhoef, editors. Collaborative De-sign for Embedded Systems – Co-modelling and Co-simulation. Springer,2014.

[11] C. Hoare. Communicating Sequential Processes. Communications of theACM, 21(8), August 1978.

[12] J. Holt and S. Perry. SysML for Systems Engineering. IET, 2008.

[13] J. Holt and S. Perry. SysML for Systems Engineering: A model-basedapproach. IET, 2nd edition: edition, 2014.

[14] J. Holt, S. Perry, M. Brownsword, D. Cancila, S. Hallerstede, andF. Hansen. Model-based requirements engineering for system of sys-tems. In System of Systems Engineering (SoSE), 2012 7th InternationalConference on, pages 561–566, July 2012.

[15] J. Holt, S. Perry, F. O. Hansen, S. Hallerstede, K. Kristensen, andS. Riddle. Final Report on Guidelines for Architectural Level SoS Mod-elling. Technical report, COMPASS Deliverable, D21.5, 2014. Availableat http://www.compass-research.eu/.

[16] INCOSE. Systems Engineering Handbook. A Guide for System LifeCycle Processes and Activities. Technical report, International Councilon Systems Engineering, 7670 Opportunity Rd., Suite 220 San Diego,CA, January 2010.

[17] M. W. Maier. Architecting principles for systems-of-systems. SystemsEngineering, 1(4):267–284, 1998.

[18] MOD UK. MOD Architecture Framework. Technical report, Ministry ofDefence, UK, 2012. Available at https://www.gov.uk/mod-architecture-framework.

[19] MOD UK. Generic Soldier Architecture. Technical Report Issue 01,Ministry of Defence, June 2013.

[20] OMG. OMG Systems Modelling Language Version 1.3. Avail-able: http://www.omg.org/spec/SysML/1.3 (Accessed June 2013),June 2012.

[21] S. Perry, J. Holt, R. Payne, A. Miyazawa, J. Woodcock, F. O. Hansen,C. B. Nielsen, J. Iyoda, and M. Cornelio. Initial report on SoS architec-

68


tural models. Technical report, COMPASS Deliverable, D22.1, February2012. Available at http://www.compass-research.eu/.

[22] J. Woodcock and A. Miyazawa. Features of CML: a Formal ModellingLanguage for Systems of Systems. In Proceedings of the 7th IEEE Con-ference on System of Systems Engineering (SOSE 2012), Genoa, Italy,July 2012. IEEE.

69


Acronyms

CML COMPASS Modelling Language

SoS System of Systems

CS Constituent System

CPS Cyber Physical System

IC Interface Contract

SoSE System of Systems Engineering

GVA Generic Vehicle Architecture

GBA Generic Base Architecture

GSA Generic Soldier Architecture

LOSA Land Open System Architecture

COI(L) Common Open Interface for Land

BDD Block Definition Diagram

PD Parametric Diagram

ODV Ontology Definition View

ICSDV Interface Contractual SoS Definition Viewpoint

ICIV Interface Contract Identification View

ICCV Interface Contract Conformance Viewpoint

ICSBV Interface Contract SoS Behaviour View

ICDV Interface Contract Definition Viewpoint

ICPDV Interface Contract Protocol Definition Viewpoint

ICConfV Interface Contract Connections View

FMAF Fault Modelling Architectural Framework

FEFDV Fault/Error/Failure Definition View

TCV Threat Chain View

FAV Fault Activation View

FTSV Fault Tolerance Structure View

70


FTCV Fault Tolerance Connections View

RV Recovery View

PV Process View

RDV Requirements Description View

SDV Stakeholder Definition View

CIV Context Interaction View

DSE design-space exploration

71

Appendix A

Feasibility Study LOSA SoSVerification and AssuranceStages

Annex A from the Statement of Work identifies six verification and assurancestages to be examined in the feasibility study. This is reproduced below.

72


!

73

Appendix B

Complete CML Model

� �types

LoMsg = VerbalCoords | VerbalAC | VerbalStandby | <Error >

VerbalCoords :: c : token

VerbalAC = <VAllClear >

VerbalStandby = <VStandby >

Msg = Coords | AllClear | Order | Standby | <Error >

Coords :: c : token

AllClear :: c : Coords

i : Img

Order :: c : Coords

s : Scan

Standby :: c : Coords --sb : token

Id = token

Scan = token

Img = token

MissionLog = seq of (LoMsg | Msg)

CoordSet = set of Coords

channels

init

74


scanReq_in : Coords

scanReq_out : Scan

hiComm_in : Id * Id * Msg

loComm_in : Id * Id * LoMsg

chansets

scan_IF = {| scanReq_in , scanReq_out |}

hiComm_IF = {| hiComm_in |}

loComm_IF = {| loComm_in |}

----------------------------------------------------------

-- Soldier_IC. The interface contract for a soldier.

-- Has two high -level functions: to deal with requests for

-- checking locations sent via a vehicle; and to check a

-- scanned location.

----------------------------------------------------------

process Soldier_IC = mid , otherid , vid : Id @

begin

state

-- Ids of the soldier , other soldier and a vehicle

myId : Id := mid

otherId : Id := otherid

vId : Id := vid

-- Invariant to ensure the ids are unique

inv myId <> otherId and myId <> vId and otherId <> vId

missionLog : MissionLog := []

unsafeLocs : CoordSet := {mk_Coords(c1), mk_Coords(c3)}

operations

hiComm: Id * Id * Msg ==> ()

hiComm(-, -, m) == missionLog := missionLog ^[m]

post len missionLog = len missionLog~ + 1

createOrder : Scan * Coords ==> Order

createOrder(s,c) == return mk_Order(c,s)

pre c not in set unsafeLocs

post RESULT.s = s and RESULT.c = c

createStandby : Coords ==> Standby

createStandby(c) == return mk_Standby(c)

recordImage : Coords ==> Img

recordImage(c) == return mk_token("New Image")


75


createAllClear : Coords * Img ==> AllClear

createAllClear(c,i) == return mk_AllClear(c,i)


actions

MessageIn = hiComm_in?i.myId?m -> (hiComm(i, myId , m);

NewMessage(m))

NewMessage = m : Msg @

[is_Coords(m)] & ScanRequest(m)

[]

[is_Order(m)] & IncomingOrder(m)

[]

[is_AllClear(m)] & InformPatrol(m)

ScanRequest = c : Coords @

scanReq_in!c -> scanReq_out?s -> IssueOrder(s,c)

IssueOrder = s : Scan , c : Coords @

(dcl o : Order := createOrder(s,c) @ hiComm_in.myId.

otherId!o ->

(dcl sb : Standby := createStandby(c) @ hiComm_in.myId

.vId!sb -> MessageIn

)

)

InformPatrol = ac : AllClear @ hiComm_in.myId.vId!ac ->

MessageIn

IncomingOrder = o : Order @

[((o.c) not in set unsafeLocs)] &

(dcl i : Img := recordImage(o.c) @ LocationClear ((o.c

),i))

LocationClear = c : Coords , i : Img @

(dcl a : AllClear := createAllClear(c,i) @ hiComm_in.

myId.otherId!a -> MessageIn)

@

init -> MessageIn

end

----------------------------------------------------------

-- Patrol_IC. The interface contract for a local patrol

-- officer. Has functionality to request some action at a

-- specified location.

----------------------------------------------------------

process Patrol_IC = mid , vid : Id @

76


begin

types

Command = <StandbyCmd > | <AllClearCmd >

state

myId : Id := mid

vId : Id := vid

inv myId <> vId

lastCommand : [Command] := nil

verbC : VerbalCoords := mk_VerbalCoords(c0)

operations

loComm : Id * Id * LoMsg ==> ()

loComm(-, -, lM) ==

(

cases lM:

<VStandby > -> lastCommand := <StandbyCmd >,

<VAllClear > -> lastCommand := <AllClearCmd >,

others -> lastCommand := nil

end

)

post (is_VerbalStandby(lM) => lastCommand = <StandbyCmd >)

and

(is_VerbalAC(lM) => lastCommand = <AllClearCmd >)

actions

Ready = loComm_in!myId!vId!verbC -> MessageIn

MessageIn = loComm_in.vId.myId?m -> (loComm(vId , myId , m);

NewMessage(m))

NewMessage = m: LoMsg @

[is_VerbalStandby(m)] & Ready -- MessageIn

[]

[is_VerbalAC(m)] & Skip

@

init -> Ready

end

----------------------------------------------------------

-- Vehicle_IC. The interface contract for a vehicle. Has

-- functionality to scan a location and pass messages between

77


-- patrol and soldiers.

----------------------------------------------------------

process Vehicle_IC = mid , mountid , patrolid : Id @

begin

state

myId : Id := mid

mId : Id := mountid

pId : Id := patrolid

missionLog : seq of (LoMsg | Msg) := []

operations

loComm : Id * Id * LoMsg ==> ()

loComm(-, -, lm) == missionLog := missionLog ^ [lm]


hiComm : Id * Id * Msg ==> ()

hiComm(-, -, m) == missionLog := missionLog ^ [m]


-- converts lo to hi res communication

createHiMsg : LoMsg ==> Msg

createHiMsg(m) ==

(

cases m:

mk_VerbalCoords(coords) -> return mk_Coords(coords),

--Due to simple representaion of coordinates

others -> return <Error >

end

)

-- converts hi to lo res communication

createLoMsg : Msg ==> LoMsg

createLoMsg(m) ==

(

cases m:

mk_AllClear(-,-) -> return <VAllClear >,

mk_Standby (-) -> return <VStandby >,

others -> return <Error >

end

)

scanReq : Coords ==> Scan

scanReq(-) == return mk_token("New Scan")

actions

Ready = loComm_in.pId.myId?c -> (loComm(pId , myId , c);

78


(dcl m : Msg := createHiMsg(c) @ hiComm_in!myId!mId!m ->

Ready))

[]

scanReq_in?c -> (dcl rs : Scan := scanReq(c) @

scanReq_out!rs -> Ready)

[]

hiComm_in?s.myId?m -> (hiComm(s, myId , m); NewHigh

(m))

NewHigh = m : Msg @

[is_AllClear(m)] & (dcl lM :LoMsg := createLoMsg(m)

@ loComm_in.myId.pId!lM -> Ready)

[]

[is_Standby(m)] & (dcl lM :LoMsg := createLoMsg(m)

@ loComm_in.myId.pId!lM -> Ready)

@

init -> Ready

end

process MountedSoldier = Soldier_IC(mountId , dismountId ,

vehicleId)

process DismountedSoldier = Soldier_IC(dismountId , mountId ,

vehicleId)

process Vehicle = Vehicle_IC(vehicleId , mountId , patrolId)

process Patrol = Patrol_IC(patrolId , vehicleId)

process FeasibilityExample_IC = (Vehicle |||

DismountedSoldier) [| hiComm_IF union scan_IF |]

MountedSoldier

values

--identifiers for feasibility example

mountId : Id = mk_token("mounted soldier")

dismountId : Id = mk_token("dismounted soldier")

vehicleId : Id = mk_token("vehicle")

patrolId : Id = mk_token("patrol")

--test coordinate names

c0: token = mk_token("c0")



c3: token = mk_token("c3")� �

79

System of Systems Dependability for LOSA · 2015-11-02 · SoS Dependability for LOSA - Final Report Preface This is the nal report resulting from the feasibility study on System

Documents