roadmap for research in model-based sos engineering

Grant Agreement: 287829

Comprehensive Modelling for Advanced Systems of Systems

Roadmap for Research in Model-Based SoSEngineering

Deliverable Number: D11.4

Version: 1.0

Date: September 2014

Public Document

http://www.compass-research.eu

D11.4 - COMPASS Roadmap (Public)

Contributors:

Claire Ingram, UNEW

Editors:

Claire Ingram, UNEWAlexander Romanovksy, UNEW

Reviewers:

Adrian Larkham, ATEGORichard Lloyd Stevens, INSIELJan Peleska, BREU

2


Document History

Ver Date Author Description0.1 19-06-2014 Claire Ingram Initial document version0.2 23-08-2014 Claire Ingram Second version - incorporate output

from roadmapping workshops0.3 12-09-2014 Claire Ingram Third version - ready for internal re-

view1.0 30-09-2014 Claire Ingram Final version - internal review com-

ments integrated

3


Abstract

In this deliverable we present a research roadmap outlining how COMPASSparticipants view the future of modelling and simulation for SoSs. We haveorganised our roadmap as a selection of ‘product features’ that will be neededto build and design dependable SoSs in the future. We then connect theseto a selection of enabling technologies which are needed in order to see theproduct features realised in tools of the future.

The product features and enabling technologies were originally elicited in aseries of workshops held across the project, with all project partners well-represented. These proposals were refined by a subsequent ‘requirements-pull’ effort, which has seen different domains associated with COMPASSsurveyed and their modelling and simulation needs elicited and linked to theproducts and technologies originally proposed. The major product featureswe recommend for future research are:

• Verification of emergent behaviour

• Verification of non-functional SoS properties

• Analysis and verification of security properties of an SoS (we view secu-rity as an important example of a non-functional property, with somespecial requirements)

• Analysis and verification of SoSs with process mobility

• Analysis of performance optimisation and possible design trade-offs

• Analysis of human behaviours and interactions with an SoS

• Heterogeneous cross-domain, cross-disciplinary analysis

• Tool interoperability across sectors

• Accessible and intuitive front-ends for formal verification techniques

• Analysis of stochastic events, and their effects

• Mature architectural guidelines and patterns based on experience andprevious case studies

• Analysis and verification of autonomous decisions

• Analysis and verification of dynamic reconfiguration of an SoS

4


Acknowledgements

Thanks to reviewers who have kindly provided comments, suggestions andfeedback, including members of the CIG (particular thanks to Dave Ban-ham for suggestions and critiques) and to participants from all COMPASSpartners for their input during roadmapping sessions.

5


Contents

1 Introduction 81.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.2 Stakeholders and intended roadmap audience . . . . . . . . . . 8

2 COMPASS Roadmapping Approach 102.1 Roadmap goals and objectives . . . . . . . . . . . . . . . . . . 112.2 Customising the roadmapping process . . . . . . . . . . . . . . 112.3 Roadmap structure . . . . . . . . . . . . . . . . . . . . . . . . 122.4 Roadmap Layers . . . . . . . . . . . . . . . . . . . . . . . . . 132.5 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.6 Timescales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.7 Technology readiness levels . . . . . . . . . . . . . . . . . . . . 14

3 Systems of systems 163.1 Systems of systems . . . . . . . . . . . . . . . . . . . . . . . . 163.2 Cyber-physical systems . . . . . . . . . . . . . . . . . . . . . . 173.3 Other systems . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 General Roadmap 194.1 Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2 Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5 Emergency Response and Disaster Relief 615.1 Characterising the domain . . . . . . . . . . . . . . . . . . . . 615.2 Market Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6 Home Entertainment and Home Automation 696.1 Characterising the domain . . . . . . . . . . . . . . . . . . . . 696.2 Market needs . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

7 Transport 757.1 Characterising the domain . . . . . . . . . . . . . . . . . . . . 757.2 Market needs . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

8 Energy 838.1 Characterising the domain . . . . . . . . . . . . . . . . . . . . 838.2 Market needs . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

9 Contribution of this Roadmap 889.1 DANSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

6


9.2 T-AREA-SOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 889.3 ROAD2SoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919.4 CPSoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 949.5 CyPhERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

10 Conclusions 97

7


1 Introduction

This deliverable presents the COMPASS roadmap, which outlines recom-mendations for future research programs to progress the field of model-baseddevelopment of systems of systems - with particular emphasis on develop-ments which continue to build on COMPASS’s outputs.

Roadmapping falls under Task 1.1.5; roadmapping efforts were concentratedin Phases III, IV and V of the project. The final roadmap presented in thisdeliverable is based on inputs from all project partners, collected during in-teractive brainstorming sessions at which all partners were represented, heldduring convergence and plenary workshops in Phases III-V. Inputs have alsobeen sought and collected from industrial collaborators, including membersof the COMPASS Interest Group (CIG) - observers outside the project whoprovide feedback and evaluation - and from existing roadmaps pertainingto range of SoS-domains (e.g., energy, transport, smart cities, etc.) as wellas from other relevant SoS-related research projects, covering areas such assystems of systems (SoSs) and cyber-physical systems (CPSs).

The contribution made by the COMPASS roadmap and relationship withother roadmaps is discussed in Section 9, and the relationship between SoSsand CPSs is discussed in Section 3.

1.1 Scope

The roadmap concentrates on model-based tools and techniques for the de-velopment of SoSs. Other SoS challenges or development aspects fall outsidethe scope of this roadmapping effort.

COMPASS aims to develop and evaluate languages, methods and tools tosupport model-based SoS engineering. These take a contract-based approachwhereby the reliances and guarantees of constituent systems are recordedexplicitly in a formal language (the COMPASS Modelling Language CML),and analysed by new tools that exploit the formality of the CML semanticsto assist trade-off analysis and assurance of global SoS properties.

1.2 Stakeholders and intended roadmap audience

Here we identify the stakeholders with interests in the COMPASS roadmap,the target audience, and the COMPASS roadmapping objectives.

8


At the second convergence workshop in Trieste (Phase III), the followingstakeholders for the COMPASS roadmap were identified and agreed upon:

• Potential tool users. This includes constituent system (CS) owners anddevelopers, and SoS owners and developers.

• Tool developers working in related areas, including development of for-mal analysis tools or architectural modelling tools.

• Researchers working in related fields, such as SoS and CPS architec-tures, modelling and simulation fields, formal methods and case studies(see Section 3 for a more on CPSs and SoSs).

• Research funding bodies with relevant interests in CPSs and SoSs,model-based engineering techniques and formal/automated analysis tech-niques, and architectural tools and methods

For the COMPASS roadmap, we have adopted researchers and researchfunding bodies as the intended target audience for the roadmap, and there-fore the roadmap presents a series of recommended future research directions,making clear the links between different research areas, and the returns thatthe COMPASS researchers perceive each may bring. The roadmapping ap-proach we have adopted allows us to address the needs of all the above listedstakeholders in a structured way. This is achieved through linking the pro-posed research directions (outlined in Section 4.1) to various SoS domainsand their needs. We also link proposed research directions to potential newtools and products (outlined in Section 4.2).

9


2 COMPASS Roadmapping Approach

The roadmap has been compiled based upon ideas and plans generated byCOMPASS participants during interactive roadmapping sessions at which allpartners have been well-represented. Outputs from these sessions have beenrefined and validated by broad cross-sections of COMPASS researchers, infurther plenary sessions.

Roadmapping activities have included:

• An initial brainstorming session on roadmapping during the kick-offmeeting in 2011

• An interactive session co-ordinated by Christian Albrecht, represent-ing the research project ROAD2SoS1, at the COMPASS convergenceworkshop in Trieste in March 2013

• Further roadmapping session at COMPASS’s plenary workshop in New-castle in June 2013, to validate and build on inputs generated in Trieste

• Three interactive roadmapping workshops involving brainstorming andplanning activities involving personnel from across the project, in New-castle in June 2014

• An interactive session to consolidate initial roadmaps at the conver-gence workshop in Bremen in August 2014

• A session to present initial roadmap outputs to the CIG members andcollect their feedback at the CIG workshop in London in September2014

• An invited talk to present COMPASS’s roadmapping outputs at the3rd CyPhERS workshop in Stockholm in September 2014

These activities have resulted in a wide-scale study of the potential futuredirections and uses of modelling and simulation techniques to support SoSsin the future, including contributions from industrial SoS owners and partic-ipants as well as academic researchers.

1http://www.road2sos-project.eu/

10


2.1 Roadmap goals and objectives

Each organisation requires a customised roadmapping process, that ade-quately fits its needs and resources [LP05]. This requires clear goals to bearticulated [LP05]. The key goals for the COMPASS roadmap are:

• Ensure that COMPASS’s outputs are built upon and integrated intofuture research developments.

• Provide plans for future research projects relevant to development ofresilient SoS, motivated by clearly traced requirements needed to realisethe demand for SoSs in the future.

These goals will be met by satisfying the following objectives:

• Identify and characterise SoSs that are expected by project membersto operate in the future; these will provide motivating examples andpractical suggestions for future developments and necessary research.

• Characterise current state of the art in model-based engineering of SoSs,including current state of the COMPASS outputs.

• Propose relevant research areas which are needed in order to build onthe final outputs of the COMPASS project and thus advance the stateof the art.

• Describe tools and features that will be enabled by different researchdirections recommended here, linking them to the motivating examplesto demonstrate their utility in different SoS domains.

2.2 Customising the roadmapping process

The COMPASS project has produced this roadmap as a strategy for futureresearch and development that will build on COMPASS’s final outputs. Theroadmap therefore focuses on COMPASS’s key remit of modelling and sim-ulation for SoSs. We follow an approach to roadmap development that isderived from the ‘Fast-Start’ approach [PFP13]. This approach recommendsfour half-day workshops, each with a different focus: [PFP13, Vla10]:

1. Market drivers or opportunities for the future.

2. Potential product features to meet the opportunities presented by themarket drivers.

11


3. Potential enabling technologies needed for developing the above prod-ucts.

4. ‘Charting’ - beginning the process of linking the market drivers, poten-tial products and enabling technologies [PFP13].

In the list above, ‘technology’ can be interpreted as process, technique orknowledge base [PFP04]. COMPASS follows a process adapted from this,building on relevant outputs from external researchers where possible, andbrainstorming workshop sessions focussing on these topics were held duringconvergence workshops in Newcastle in June 2014. The final roadmap pre-sented in this report is intended to form a ‘composite’ plan [Pet08], thatidentifies strategic links between market drivers, products and technologicalsolutions.

2.3 Roadmap structure

A general roadmap is presented first of all in Section 4. This general roadmappresents technologies and methods identified by COMPASS participants asimportant future research directions for modelling and simulation in SoS.We indicate potential dependencies between these technologies, as well assuggesting some product features and future modelling capabilities that couldbe enabled by these technologies.

Organisations which employ roadmapping as a planning activity typicallyneed to ensure that roadmaps are appropriately customised to suit the do-main’s requirements and technological and socio-technical challenges. There-fore, after presenting a general roadmap, we then consider in Sections 5-8 arange of SoS domains, and for each, we demonstrate how the general COM-PASS roadmap could be customised to suit the likely future requirements ofthe given domain. These customised domain-specific roadmaps have beenrefined following feedback from the COMPASS CIG group members as wellas COMPASS industrial partners.

We separate the roadmap into general and domain-specific versions becausea general roadmap that covers all domains is impossible to construct, giventhat some domains have challenges and obstacles that others do not. Forexample, one domain may require products that implement n challengingenabling technologies, whereas another domain does not require all the sameenabling technologies, and could accept and make use of a similar productat a much earlier stage.

12


2.4 Roadmap Layers

The ‘Fast-Start’ approach [PFP13] advocates a roadmap format that presentsfive ‘layers’ of information:

1. Target markets which have been identified for the future

2. Products which can be aimed at these target markets

3. Enabling technologies, which must be developed in order to implementthese products

4. Research and development programmes which will be necessary in orderto develop these enabling technologies

5. Funding that will be necessary to run these research and developmentprogrammes

We interpret ‘target markets’ as the SoS domains in the future, and the en-gineers who will be developing them using model-based methods. The ‘prod-ucts’ will be the model-based techniques and tools that they employ.

The final versions of the COMPASS roadmap presented in this document donot include recommendations for research and development programmes, orfunding, as these factors are outside of COMPASS control.

The general roadmap presented in Section 4 does not include details of tar-get markets; these are included on domain-specific roadmaps presented inSections 5-8, as instances of motivating examples from SoS domains. Re-moving target markets from the general roadmap simplifies the resultingpicture (which is already complex). It also allows the general roadmap to bepresented as a guiding template ready to be tailored to each domain. Thedomain-specific roadmaps presented in Sections 5-8 provide demonstrationsof how to tailor the roadmap.

2.5 Methodology

COMPASS has followed the example set by other roadmap outputs (suchas [Roa13a]) in combining two types of roadmapping methodology.

• A ‘technology-push’ roadmapping approach begins by examining cur-rent state of the art and building on this to consider future technologies.

13


• A ‘requirements-pull’ roadmapping approach begins by examining somerequirements, and working backwards to identify technologies that willbe needed.

On COMPASS, identification of technologies has been generated by brain-storming current state of the art (including COMPASS’s final outputs), tobuild on a technology-push approach for the general roadmap (see Section 4).However, the general roadmap has been significantly refined by an additionalrequirements-pull effort, which examines the needs in a number of differentSoS domains and tailors the roadmap to demonstrate how these needs canbe met (customised roadmaps are presented in Sections 5-8). The result is aroadmap that has been generated by considering both perspectives.

2.6 Timescales

We have taken the decision not to provide timescales on the general roadmap.This is because different challenges and research areas may be closer to com-pletion in some domains than others. It’s possible, for example, that somedomains which do not require some specific features may be able to launchtools and techniques earlier than others, not having to wait for difficult chal-lenges to be conquered and enabling technologies to be implemented.

We provide non-specific timescales on the domain-specific roadmaps in Sec-tions 5-8 (i.e., we identify technologies as achievable in the short-term, medium-term and long-term, not annotated with specific estimated years).

A typical timescale to adopt for a technology roadmap might be a total 3-6years. We assume that timescales in our domain could be considerably longerthan this, largely because the evolution of very large scale SoSs tends to beslower than the development of specific technology products (e.g., strategicplans drawn up by the T-AREA-SOS project extrapolated from trends upto approximately 2050 [TAS12]. This longevity makes it difficult to generateaccurate estimates.

2.7 Technology readiness levels

A number of different enabling technologies are proposed in the roadmap.We make the assumption that ‘completion’ or ‘delivery’ of an enabling tech-nology means it has been validated in an academic or research-based environ-ment, and is ready for demonstration, testing and integration in industrial

14


environments. This is approximately equivalent to a Technology ReadinessLevel (TRL) 4-52. However, we assume that considerable flexibility can beadopted as each organisation or domain tailors the roadmap to their specificrequirements.

Note that the COMPASS approach to TRLs suitable for modelling work isoutlined in COMPASS deliverable D11.3 [COM14b].

2We use the TRL scale provided by the European Commission at http:

//ec.europa.eu/research/participants/data/ref/h2020/wp/2014_2015/annexes/

h2020-wp1415-annex-ga_en.pdf

15

http://ec.europa.eu/research/participants/data/ref/h2020/wp/2014_2015/annexes/h2020-wp1415-annex-ga_en.pdf




3 Systems of systems

The scope of this roadmap is restricted to model-based techniques for SoSs.In this section we very briefly define ‘systems of systems’ for the purposesof the roadmap. In particular, the roadmap may also be applicable to someother types of system (such as some cyber-physical systems); we describethis overlap here.

3.1 Systems of systems

An SoS is generally regarded as a system composed of constituent systems(CSs), each of which is independently owned or operated in its own right.There is not yet a widely accepted single definition for SoS. The most well-known [Mai98] describes five properties associated with SoSs: operationaland managerial independence; evolutionary development; emergence (theSoS performs functions that do not reside in any individual CS); and dis-tribution. The general concepts of independence, continuous evolution andemergence have been quite widely adopted, and variations of these propertiesfeature in subsequent definitions of SoS (e.g., Fisher [Fis06], Abbott [Abb06],Boardman & Sauser [BS06] and Baldwin & Sauser [BS09]). The latter twoalso reference heterogeneity typically seen between CSs within an SoS andthat that a CS must accept the need to adapt.

The independence, evolution and heterogeneity of the CSs present challengesfor the SoS engineer, such as:

• ‘blurred’ system boundaries

• long life-cyles and the inclusion of COTS/legacy components

• the need to cope with volatile environments whilst delivering high faulttolerance or high availability

• lack of disclosure between CSs

• the difficulty of verifying accurately all the possible emergent behaviour

• CSs withdrawing from the SoS as it now longer coincides with theirgoals

• CSs deploying updates without taking the needs of the SoS into account

These challenges have been described in more detail elsewhere (e.g., [COM14c,COM14a]).

16


3.2 Cyber-physical systems

A cyber-physical system (CPS) comprises a collection of interacting, net-worked embedded systems, that include elements of software and elementsto interact with or control the physical environment[Bro13, FPG12]3. Typ-ically, such systems are cross-domain and can include diverse CSs such asnetworked embedded systems, control systems, communication networks andphysical systems; they often involved expensive deployment costs and com-plex network interactions [GRSS11, FPG12].

Recent advancements have seen an interest in considering systems that ex-hibit both cyber-physical and systems of systems characteristics, with thewidespread adoption of networked collection of autonomous cyber-physicalsystems, collaborating together to produce a desired emergent, global be-haviour [BCG12]. This type of CPS may be said to conform to MarkMaier’s [Mai98] widely-cited definition of an SoS: they may have CSs whichexhibit managerial and/or operational independence; emergent behaviourwhich cannot be produced by any individual CS; continuous evolution; andgeographical distribution, resulting from the distributed network. For thisreason many issues and outstanding challenges relating to modelling of SoSsand of networked CPSs overlap; the two fields see many common challenges,such as dynamic reconfiguration, substantial heterogeneity in modelling ap-proaches, and coping with distribution and communications [Bro13].

Many of the research directions identified in this roadmap could be appliedto both SoSs and a subset of CPSs which also conform to the definitionof SoS. We identify research directions which may be particularly helpful forCPSs in Section 4, in which we describe the general roadmap, and in relevantdomain-specific roadmaps in Sections 5-8.

3.3 Other systems

COMPASS deploys the term ‘system of systems’ to describe a subclass ofsystems, which may have a number of features in common. These systemsare capable of learning from each other and identifying best practice and/orcases or poor practice based on experiences of other, similar systems. Someof the systems which can learn from SoS case studies, or leverage COM-PASS tools and techniques, may strictly conform to the definition of a sys-

3Although the term ‘cyber-physical system’, is associated with several different defini-tions - see [CyP14b] for a more comprehensive summary.

17


tem of systems, but may still experience challenges posed by their widelydistributed constituents, emergent behaviour, a high degree of complexity,heteroegeneous components or continuous evolution. For example, large andcomplex engineering projects such as shipbuilding, automotive industru oraircraft design may fall into this category. Although they may not be SoSs,such projects may find the outputs from COMPASS useful, including thesuggestions in this roadmap.

18


4 General Roadmap

In this section we present a general roadmap for modelling and simulation inSoS. This roadmap presents a vision of research directions, technologies andmethods which has been developed during roadmapping sessions executed atinternal COMPASS workshops. Roadmapping sessions have been interactiveand well-attended, with all COMPASS partners well-represented. Outputsfrom these sessions have in turn been refined and validated at further conver-gence workshops. We are therefore confident that the vision presented hereis an accurate representation of the combined views of the COMPASS par-ticipants. We present versions of this roadmap tailored to specific domainsand challenges in later sections.

We present first of all some high level research goals, which have been ex-trapolated from studying ‘products features’ that will be needed by SoSs ofthe future. These research goals have been identified and validated throughbrainstorming sessions with all project partners. Eleven research goals havebeen identified; they are:

1. Heterogeneity and tool interoperability

2. Accessibility of verification methods

3. SoS architectures

4. Verification of emergent behaviour

5. Fault tolerance

6. Dynamic reconfiguration

7. Process mobility

8. Security

9. Performance optimisation

10. Stochastic behaviours

11. Evolution

Following the structure of the ‘Fast-Start’ approach [PFP13] that we areadopting, we structure the roadmap by presenting ‘products’ that will beneeded in the future, and ‘enabling technologies’ that, when achieved, willadvance the state of the art and move closer towards implementing the de-sired product feature. Section 4.1 describes desirable product features for SoSengineers in the future, and Section 4.2 then examines each of the product

19


features in more detail, characterising the current state of the art and present-ing recommended enabling technologies which should be investigated.

Sections 4.1 and 4.2 present a generalised version of the roadmap, and shouldbe tailored to the individual needs and environment of each domain; we willpresent examples of the roadmap customised to specific SoS domains in latersections.

In later sections we present customised roadmaps that demonstrate how theproducts and technologies we suggest here can be linked to specific futureSoS ‘markets’ (where we assume that our future ‘markets’ will be SoSs ofthe future, and their likely requirements for modelling and simulation sup-port).

20


4.1 Products

In this section we examine each of the eleven research goals, translating eachinto product features that tools and methods in the future will offer to SoSengineers.

1. Tools to provide support for heterogeneous cross-domain andcross-discipline analysis techniques, and integration of toolsacross sectors of the SoS are needed. Many SoSs are implemented bycommercial organisations that collaborate either short-term, or long-term, to produce interoperating CSs. A lack of tools that support col-laborative engineering of dependable SoSs across organisational bound-aries can be a substantial barrier to this type of work.

CSs in many SoS and CPS domains involve heterogeneous systemtypes, with different domains, functions, data types, and underlyingconcepts [VF13]. For example, SoS domains such as assisted living,medical SoSs with wearable medical devices, or automated homes, re-quire CSs that can interact with the physical world. This is achievedvia appropriate sensing (e.g., gathering information about the user’shealth or home), and actuators for effecting changes in the environ-ment [Pro10] (e.g., altering the thermostat temperature in the house,or alerting a medical professional of a health problem). Frameworksfor standardised interactions are needed; e.g., there is a lack of do-main models, open architectures and standardised systems for sensingdata [Pro10].

Mixtures of CSs that implement software-based logic and controllerswith hardware-oriented sensors and/or acuators provides good exam-ples of one particular particular challenge of collaborative developmentand verification of large SoS, which is that these CSs will frequently bedesigned using different description formalisms with different seman-tics. As a consequence, sub-models with heterogeneous representationand interpretation need to be integrated in mega models allowing totransport theories and facts elaborated in one formalism to equivalentrepresentations in other formalisms. Typical ‘facts’ would be assertionsabout contracts to be observed by a given CS described in formalismF1 : in order to understand the implications of these assertions for an-other CS modelled by another formalism F2, the assertions have to betranslated into equivalent ones expressed in F2.

Tools and techniques to support large-scale domain-appropriate dis-

21


tributed control approaches, and large-scale deployment of new tech-nologies will also be needed. It’s important to ensure too that datarepresentation must be understood by both participants in a two-waydata exchange.

2. Tools and methods to make formal approaches available andaccessible to engineers from a range of disciplines would behelpful for SoSs, and for CPSs. This would allow, for example, differentengineering disciplines to visualise the reliance that can justifiably beplaced upon software or embedded elements of the system, and therationale behind this reasoning. A variety of engineering disciplinesare involved in the engineering of many SoSs (and CPSs). Formalapproaches that are used to verify the correctness of software systemshave been well demonstrated within computer science, but are littleknown in many other engineering domains.

3. Architectures suitable for SoSs and systems of interconnecteddevices need further development [RR09, VF13]. There is a clearneed for improved architectural guidance for SoSs [TAS13a, KJTF01].SoSs present a number of challenges which may be tackled, at leastin part, by appropriate architectural choices, but there has been lit-tle published so far on architectures specifically for SoS, however, andhow the architectures selected may have an impact on options for e.g.,evolution, resilience, security or dynamic reconfiguration. SoS archi-tectures need to cope with problems such as: heterogeneity betweenCSs; coping with volatile environments; lack of disclosure between allthe CSs; long lifecycles; long term evolution; CSs evolving without tak-ing the needs of the SoS into account; lack of central decision makingauthorities; and a high degree of technical and managerial complexity.

4. Tools and techniques are needed to verify the emergent be-haviour and non-functional properties of an SoS. On COMPASSwe define ‘emergent’ behaviour as the behaviour which is produced bycollaborations of CSs, and cannot be reproduced by one CS workingalone. Emergent behaviour may be deliberately engineered, or it maybe an unexpected side effect of bringing a particular selection of CSstogether, and in fact may be unwanted. It’s a challenge to analyse andverify the emergent, or global, SoS behaviour in advance, because:

• There may not be full disclosure between CSs, which may havecommercial reasons not to share internal data with other CSs,independently operated, and in some cases even potential or directcompetitors

22


• The possibilities of checking all possible emergent behaviours thatcould arise is prohibitively time-consuming

SoSs are typically large, and the involvement of many third party CSsmakes it difficult in many cases to create realistic test-beds. Sometimesa real deployment may be the first opportunity to verify that global,emergent behaviour is correct, and that no undesirable behaviour isproduced by the SoSs. For this reason, there is a strong motivation toattempt to verify the design of the SoS at an earlier stage wheneverpossible, to ensure that emergence is confined to desired behavioursonly. Formal analysis techniques are one way to build confidence inthe SoS design through simulation and analysis techniques, withoutneeding to build test systems or wait until deployment.

5. Methods and tools to support fault modelling across an SoS areneeded. SoSs are commonly required to deliver high levels of availabilityand resilience, whilst operating in challenging environments where CSsmay become uncontactable or unreliable without warning. Techniquesfor reasoning about the identification of faults, errors and failures fromthe point of view of the SoS are needed (noting that a system failureat the level of a CS becomes a fault at the level of the SoS). Detectionof faulty behaviour and the design and implementation of recoverybehaviour can involve the collaboration of multiple CSs, making fault-tolerance a global emergent property that can be difficult to verify forcorrectness. Identification at an early stage can help with negotiations,if some CSs may be required to implement expensive recovery strategiesas a result of faults introduced by third parties.

6. Tools and techniques to support reasoning about dynamic re-configuration and/or autonomous decision making are necessaryfor SoSs. Many SoSs have significant requirements for fault tolerance,resilience and robust communications, but at the same time inhabitchallenging physical environments where connectivity problems or lackof full disclosure can lead to the sudden withdrawl of a CS, or de-graded service levels [COM14h]. SoS engineering presents some com-plexity in terms of reasoning about faults, errors and failures, becauseof the multiple levels of abstraction that can be adopted, even at thesystems-level. For example, CSs may experience complete or partialservice failures, which then are viewed as internal faults at the levelof the SoS. Dynamic reconfiguration and autonomous decision makingform one possible strategy for coping with problems such as loss of a CS,or poor service quality at unpredictable intervals. Methods and tools

23


that support analysis at design time can be used to begin negotiatingwhich CSs have responsibilities for identifying faults and implement-ing recovery, whilst tools and methods for reasoning about this duringruntime can be used to identify cases that require action, such as mon-itoring the SoS performance and making optimisations, or enactingdynamic reconfiguration policies. The dynamicity of SoS requires test-ing of changed SoS configurations at runtime: each new configurationmay lead to some emergent properties being no longer available to theirfull extent, while new services might be offered by the new configura-tion. For large SoSs it will be infeasible to verify the correctness of allrelevant configuration changes in advance. Therefore mechanisms areneeded to verify the conformance of each new configuration to essentialemergent properties while the SoS is operative [COM14h].

7. Modelling and simulation techniques are needed for engineer-ing and reasoning about emergent behaviour in SoSs thatexhibit mobility Both processes and processing in SoSs that orientaround embedded devices may be highly distributed [VF13]. In ad-dition to location awareness, tools and methods for reasoning aboutcorrectness and reliability in an SoS with mobile or highly distributedprocess are needed.

8. Guidance is needed on ensuring privacy and security [Pro10]in wirelessly connected systems, or and how to ensure that se-cured data remains secure, even when being handled by separate,independent CSs. Security can be an issue for wirelessly connecteddevices (addressed by many sources e.g. [RR09, VF13, Ayo07]). Wire-lessly connected devices are found in SoSs in many domains, including:medical SoSs; SoSs around the home; manufacturing and agriculture;emergency rescue (e.g., distributed rescue crews’ vehicles and commu-nications devices and search and rescue drones); urban planning; andtransport. When deploying wireless sensors, members of the publicmust have confidence that personal data is not being collected for nefar-ious purposes. However, balanced with this the SoS must be collectingenough data that it can fulfil its purpose, and for some SoSs (e.g., pro-viding health monitoring in the home) this may mean communicatingsensitive information to an outside agency.

9. Methods and guidelines for verifying optimisation strategieswill be needed. A key requirement for most SoSs is to achieve an opti-mised performance. Furthermore, many SoSs operate in domains withhighly complex environments where an ‘optimal’ level of SoS service is

24


required, but where the definition of ‘optimal’ can vary substantially fordifferent stakeholders. For example, in a traffic management system,‘optimal’ performance could be interpreted as: achieving the lowestpossible number of road-related injuries/deaths; or the lowest air pol-lution; or the lowest average time for drivers. It can be very difficult toanalyse current performance and reason about achieving optimisationsin cases where each CS makes a partial contribution towards the finaloutcome and/or could negatively affect other outcomes.

10. Tools and techniques for modelling dependable human-centredSoSs of the future need to model stochastic events and humanbehaviour. Many SoSs exist to monitor and respond to a variety ofenvironmental stimuli, including human behaviour (e.g., traffic man-agement systems, emergency response, smart cities). Modelling andsimulation of non-repeating events such as traffic accidents, naturaldisasters affecting widely dispersed areas and/or the likely reactionof humans in the vicinity will benefit from this functionality. Thesetechniques need to be integrated into existing modelling notations andtechniques easily.

11. Tools and methods for reasoning about and analysing SoSsthrough a series of configurations or versions over a periodof time are needed. Many researchers noted that SoSs constantlyevolve (e.g., [Mai98, Abb06]). This poses challenges relating to trace-ability and for reasoning about correctness. There is a need to modeland plan migration strategies and possibilities for a phased transition.Models must ensure backward compatibility without comprising futureevolution of a system [FMXY11]. As suggested earlier with regard todynamic reconfiguration, it is not feasible to verify all potential con-figuration changes in advance for correctness, and so mechanisms areneeded to verify the conformance of each new configuration with keyemergent properties while the SoS is operative [COM14h].

25


4.2 Technologies

In this section we begin the process of identifying enabling technologies whichwill be necessary to implement the desirable products which are listed above.In this section we address each of the products identified in Section 4.1,characterising for each the current state of the art and our recommendedfuture research directions.

Our recommendations for future research directions are presented graphicallyin Figures 1-7. This figures are intended to indicate general dependencies be-tween major research areas, and how they can, together, contribute towardsdesirable product features.

4.2.1 Heterogeneity and tool interoperability

Tools to support heterogenous cross-domain and cross-discipline analysis tech-niques, and integration of tools across sectors

The lack of cross-discipline tools suitable for use by varied CSs across anSoS is a problem, not only in SoS engineering, but also in other engineer-ing scenarios such as supply chains. There are several key issues to tacklehere:

• There is a lack of standardised data formats for engineering models, andtherefore tool interchange is not routinely available. The wide varietyof pre-existing data formats (which may be proprietary) in differentdomains (e.g., transportation, energy, urban planning etc) complicatesthis situation.

• Modelling paradigms from different engineering disciplines typicallyneed to represent quite different concepts and reason about them indifferent ways. These differing concepts and models often do not allowready mappings from one type of model to another.

State of the art

We consider firstly the problem of identifying formats for information ex-change between tools. Some general purposes interoperability frameworks arealready available, such as the European Interoperability Framework (EIF),which aims to to ensure user-centred eServices are provided in Europe throughinteroperable services and systems [Com10]. One approach to tool inter-operability has been the proposed use of a taxonomy for classifying Elec-tronic System-Level Design (ESL) tools [DSVP06] based on features and ap-

26


proach; once categorised (into ‘bins’) an ESL designer can examine the binsof tools and select appropriate combinations for each step of their process, ‘tomap...design flow scenarios onto the tool landscape’ [DSVP06]; although thisaids with design process planning, the underlying problem of facilitating tooldata exchange still remains. The OSLC project (Open Services for LifecycleCollaboration)4 develops specifications for integrating softwar, which havebeen implemented to varying degrees by tools such as IBM Rational DOORsand Microsoft SharePoint5. OSCL’s goal is to allow independent software andproduct lifecycle tools to integrate data and workflow, for better support forend-to-end lifecycle processes [fLCO], although the project concentrates onfacilitating exchange between tools, not standardising behaviour.

Previous projects have begun to address the challenge of tool interoperabil-ity in some specific domains, particularly in the field of embedded systemsand CPS. This field commonly features multiple teams with different engi-neering specialisms, and multiple commercial partners organised in a supplychain wishing to share more of their modelling data down/upstream. As aresult, there is strong motivation within this domain to address problems ofinterchange and interoperability in detail. The state of the art in this fieldincludes outputs from the following projects:

• SPEEDS (Speculative and Exploratory Design in Systems Engineer-ing)6 was a European Project (2006-2010), part of the ARTEMIS7

Joint Undertaking which co-ordinates Embedded Computing Systemsresearch. SPEEDS aimed to ‘reduce product development time andcost of complex embedded systems in key European industrial sec-tors’ [SPE09b]. This included research into concurrent design teamsin a multi-disciplinary environment and cross-organisational develop-ments. The project produced a design process and chain of integratedtools to support it [SPE08] in cross-domain and multi-dimensionalteams. SPEEDS tackles tool integration by developing a HeterogeneousRich Components (HRC) model, which relies on a common interchangeformat that can be read and written by a variety of design tools. Thisis represented as the ‘SPEEDS bus’; each integrated tool communicateswith the bus and is therefore required to implement the SPEEDS API.

HRC modelling in the SPEEDS project demonstrated that it is pos-sible (although not trivial) for design aspects from different teams to

4http://open-services.net/5http://open-services.net/software/6http://www.speeds.eu.com/7http://www.artemis-ju.eu/

27

http://open-services.net/

http://open-services.net/software/

http://www.speeds.eu.com/

http://www.artemis-ju.eu/


be integrated into a merged model; it has been claimed that this ap-proach decreases of information losses when converting models betweenformats and tools [SPE09a]. However, there is considerable effort toachieve integration if all tools must implement a common API; each toolmay only be integrated if its development team accepts this. SPEEDSoperates in an embedded systems domain, where many developmentsdepend on the success of a supply chain, incentivising greater integra-tion. Not all SoSs will see the same motivating factors.

• CESAR (Cost-efficient methods and processes for safety relevant em-bedded systems)8 was a European project (2009-2012), also in con-junction with ARTEMIS9. Many design and modelling tools or meth-ods employed by the safety critical embedded systems industry addressonly one system aspect (e.g., safety), and are not integrated into acoherent process or interoperable with other tools. CESAR’s majorfocus was on redressing this ‘lack of open and common interoperabilitytechnologies supported by the different tools that generate and pro-vide access to the data’, specifically in safety critical embedded systemdevelopment [Pro12]. The project developed a ‘Reference TechnologyPlatform (RTP)’ to act as a standardisation initiative and to enableintegration or interoperation of existing tools and technologies, specif-ically focussing on enabling data sharing.

• CRYSTAL (CRitical sYSTem engineering AcceLeration)10 is a projectin conjunction with ARTEMIS11, and began 2013. The project willbuild on previous ARTEMIS work in safety critical embedded systems,focusing on quality, cost-effectiveness and architecture platforms witha primary project goal of improving reusability of technologies and pro-cesses for safety-critical embedded systems development in the trans-portation domain. This will involve establishing workflows throughanalysis tools, and developing a new technological ‘brick’ that will fa-cilitate reuse12. CRYSTAL will employ as an interoperability standardthe Reference Technology Platform (RTP) developed by the CESARproject.

• DANSE (Designing for Adaptability and evolutioN in Systems of sys-

8http://www.cesarproject.eu/9http://www.artemis-ju.eu/

10http://www.crystal-artemis.eu/11http://www.artemis-ju.eu/12http://www.artemis-ia.eu/project/index/view?project=46

28

http://www.cesarproject.eu/


http://www.crystal-artemis.eu/


http://www.artemis-ia.eu/project/index/view?project=46


tems Engineering)13 is a project focusing on the development of amethodology to support evolving SoSs. DANSE provides lifecycle mod-els based on a formal semantics and a tool suite for analysis and sim-ulation. The DANSE tool chain approaches tool interchange by useof a common ‘hub’ (implemented by IBM Jazz14) [DAN13c]. Modelsgenerated using varied tools in different notations are transformed atdifferent levels of commonalities, building on the concept of ‘semanticmediation’, developed by the SPRINT15 project. This method allowstools to be shared and translated between tools, so that users can chooseto work in their own familiar environment [DAN13c]. ‘The transfor-mation works by first enriching the input model with concepts fromthe target ontology.. resulting in a rich, yet ambiguous model, servingtwo languages that are related... The next step would be to filter outfrom this rich model only the concepts that are legal in the target on-tology... there is no master direction of flow, and this process can bedesribed[bilaterally]’ [DAN13c]. The transformation relies on some ex-tent of common semantic overlap between models and their ontologies.The hub-and-spoke architecture adopted by DANSE is more flexiblethan a tool chain, as it makes no assumptions about sequence of tooluse or participation by other tools. The tools integrated into the hubwill include: tools to support architectural description and analysis,dynamic generation and optimisation of architectures, all described inarchitectural frameworks (DANSE uses UPDM by default as a frame-work, although NAF and SysML can also be used); description andanalysis of CSs, including simulation modelling; and tools for analysisof behaviour [DAN13a].

• iFEST (Industrial Framework for Embedded Systems Tools) aimed toproduce a specification for, and develop, a ‘tool integration frameworkfor hardware/software co-design of heterogeneous and multi-core em-bedded systems’16 . iFEST was a three year project which concludedin 2013, running in conjunction with ARTEMIS. The iFEST approachcentred on an integration framework to establish two prototype toolchains, one focused on industrial control, and one focused on datastreaming. The integration technology developed was intended to betool independent, and meta-modelling approaches were used to auto-matically implement necessary chain interfaces for embedded systems.

13http://www.danse-ip.eu/home/index.php14http://jazz.net15http://www.spring-iot.eu16http://www.artemis-ifest.eu/

29

http://www.danse-ip.eu/home/index.php

http://jazz.net

http://www.spring-iot.eu

http://www.artemis-ifest.eu/


The iFEST integration framework is designed to work on common en-gineering assets and concepts, and ensures that the integration of anew tool requires a one-time only development effort. iFEST has re-sulted in a number of recommendations and potential tools which aresuited to the development of heterogeneous embedded systems, witha number of verification activities evaluated using the new chain bythe iFEST project [iFE13]. These experiences and developed productsfrom iFEST can be expanded upon for future work in the field of het-erogeneous co-development of embedded systems, and could be builton further to enable verification of systems of independent, distributedCSs such as is found in an SoS.

There are several possible approaches that could be adopted to facilitate toolinterchange. The first is to establish a common interchange data format, andexpect that all tool vendors and partners in the chain/SoS implement anduse it, and/or provide wrappers to implement data exchange. This is theapproach which has generally been adopted and developed by the previousprojects described above (e.g., SPEEDS has adopted a common ‘bus’ andDANSE a common ‘hub’), and it is an approach recommended by the Eu-ropean Commission in the European Interoperability Framework [Com10],which notes that individual, peer-to-peer transformation between individ-ual pairs of tools ‘requires as many communications as there are partners,resulting in less efficiency and higher costs. On the other hand, if each ofthe interoperating partners adopts the same set of agreements for interop-erability solutions, each of them can reap the benefits of a single solutionthat is developed once and fits the needs of all’ [Com10]. This approach hassome advantages in supporting the development of open platforms and toolchains. There may be, however, some complex analysis and modelling toolswhich require fine-grained details or data which are neglected in the commonformat.

An alternative approach allows individual tools to exchange data directlyusing their own custom-designed interchange methods. This could see a re-quirements modelling tool, for example, using a unique interchange methodto exchange requirements information with a design tool, and the same designtool using a custom-built method to exchange design details with a testingtool. This allows tool vendors to ensure that data they require is fully trans-mitted to and received from their immediately neighbours in a design toolchain, but there is a strong possibility that data needed downstream will notbe propagated effectively right along the tool chain. Collaborators wouldonly be able to exchange data with a partner if the vendors have foreseenthe need and agreed an exchange mechanism. There is also substantial de-

30


velopment effort needed to implement separate exchanges, and open toolsplatforms and chains find more obstacles using this method. For this reasonmost research projects (as well as projects such as OSLC) studying the prob-lem have recommended and adopted a common exchange format, usuallyembedded in recommended project design methods.

COMPASS also advocates a common framework for capturing the semanticsof the different modelling languages to facilitate the evolution of an openmodelling platform. The common framework used by COMPASS to expressthe semantics of the CML language is Hoare & He’s Unifying Theories ofProgramming (UTP) [HJ98].

In addition to the practical problems of tool interchange, there are specificproblems associated with exchanging model data between different engineer-ing disciplines. CSs within one SoS may be described and modelled in differ-ent notations, with requirements to reason about and analyse different con-cepts, which may not be easily mapped onto each other. Although many SoSsface this problem, it is a particular challenge in the field of CPS, where thereis considerable semantic heterogeneity between the modelling paradigms em-ployed by the hardware and software design teams [FPG12]. For example,hardware-oriented models (such as continuous-time models) must deal withdifficult, ‘noisy’ input data and environmental constraints, whilst softwaremodels (such as discrete-event models) typically abstract away the details of‘noise’ in input data. The difficulty of bridging the gap between modellingparadigms that may encapsulate quite different concepts means that the twoaspects of the CPS, implemented separately in software and hardware, maynot be tested or simulated together until a relatively late stage in the designprocess. And the cross-disciplinary nature of CPSs can lead to significantmisunderstandings between the respective design teams and introduce de-lays for system development [FPG12, ZB13] (of course, these disadvantagesapply to many SoSs, not only to CPSs, although CPSs present a very spe-cific example of a generalised problem). The SoS community may be able tolearn lessons from the embedded systems community, and possibly also ex-tend embedded systems approaches to tackle more general SoS heterogeneityproblems.

A common semantics (described above) capable of expressing a range ofconcepts, and incorporating heterogeneous modelling paradigms, are neededfor verification of the emergent behaviour of SoSs, and especially CPSs. Inaddition, a co-modelling or co-simulation approach allows multiple modelsdeveloped by different design teams to be executed, analysed or verified col-laboratively. Teams can exchange models and/or their outputs, or run joint

31


‘co-simulations’, to gather immediate feedback on the overall SoS-level de-sign. As a result, a co-modelling approach can result in a shorter develop-ment cycle [FPG12], where design flaws are detected earlier and a designthat is optimal for all teams more likely to be reached. The state of the artin model-based tools and methods to support a holistic approach to CPSdesign include some of the following approaches17:

• Techniques designed for modelling ‘hybrid’ systems, including hybridstatecharts [KP92, MMP92] and hybrid automata [ACH+95]. Other,recently-proposed languages include Stateflow/Simulink, as well as Mod-elica [FE98] and HyVisual [LZ05]. These ‘hybrid’ approaches typicallyadvocate use of a single language to express and reason about both dis-crete event control behaviour as well as continuous dynamic behaviours.

• Techniques that combine the two modelling paradigms in simulations.This approach retains the power of paradigm-specific notations whilesupporting holistic models that capture global behaviour. For exam-ple, Ptolemy II [EJL+03] supports heterogeneous simulation in thismanner, where a computation mode must be specified for each dia-gram [DGG+99].

• Techniques facilitating co-simulation, in which separate tools are con-nected together during simulation, with time and data synchronisedbetween two or more models. For example, the Vanderbilt model-based prototyping tool chain [MSE04] targets the automotive domainwith the Functional Mockup Interface (FMI), a protocol for a co-simulation bus to exchange data between models during simulation18.The Crescendo [FLV14] approach20 supports creation and co-simulationof co-models that contain a discrete-event controller model, and acontinuous-time model representing a plant. A contract defines datasynchronised between the models during co-simulation. Crescendo sup-ports DE models [LBF+10] written in the well-established formal methodVDM (Vienna Development Method) supported by the Overture21 tool,and the 20-sim22 tool [Bro97] for building, simulating and visualising

17We describe here a selection of approaches suitable for collaborative design of het-erogeneous systems; a wider range of approaches currently employed in CPS design ispresented in [CyP14b]

18https://www.fmi-standard.org/; whilst the SPEEDS19 HRC metamodel cansupport co-modelling and co-analysis of multiple models in the transportation do-main [CyP14b]

20http://www.destecs.org/21http://www.overturetool.org/22http://www.20sim.com/

32

https://www.fmi-standard.org/

http://www.destecs.org/

http://www.overturetool.org/

http://www.20sim.com/


CT models.

It’s important to recognise that although all these techniques tackle a prob-lem that SoS engineers would recognise (heterogeneity), most of these meth-ods are targeted at single-system CPSs and may require some work (e.g., todevelop guidelines, recommended development processes, or tool extensions)to make them suitable for SoS engineering scenarios.

Recommendations for future work

Recommendations for future work are summarised in Figure 1. Commonontologies and reference frameworks should be developed to enable tool in-terchange:

• Ontologies that cross engineering discipline boundaries will be neces-sary for building open tool platforms and permitting a variety of engi-neering disciplines to begin leveraging existing verification tools.

• Domain-specific ontologies (e.g., for describing items around a home)would allow SoSs with a common environment to adopt a standardisedapproach which supports interoperability, and would also allow new CSdevelopers to build on previous work by adopting standardised ontolo-gies and tools that support them. Guidance on how to apply and/orcustomise ontologies and frameworks whilst retaining interoperabilitywill be needed for ensuring consistency within and across domains.

COMPASS has already produced patterns and architectural frameworks torecommend best practice in modelling processes (e.g., see [COM12, COM13b,COM14c]). Patterns and reference frameworks are needed that specificallyaddress the problems of integrating heterogeneous models in a CPS context,and of integrating models from separate CSs and/or teams.

Further work on the use of the UTP is needed to identify concepts capturedand expressed by differing engineering disciplines, and potentially for differ-ing domains (e.g., transportation, city planning, emergency response, homeautomation, agriculture, etc.). Facilitating the standardisation of tools andanalysis techniques across different domains would allow different domains toshare best practice and learn from each other, although the common seman-tics used for this (COMPASS advocates the use of the UTP for this purpose)must be capable of expressing concepts necessary in the different domains.With a well-developed collection of analysis techniques and tools available,all expressed in the UTP, teams using a variety of formalisms can leverageCOMPASS tools (e.g., model-checker, refinement calculator, theorem prover)as long as a semantics for the new formalism can be expressed in UTP.

33


Figure 1: Roadmap: Heterogeneity and tools interoperability

34


A number of authors have called for better modelling notations for CPS in-cluding Lee [Lee08, Lee] and Broy [BCG12]. Bauer [Bau12] suggests thatan approach to modelling CPSs should fulfill certain requirements: it mustmodel interaction between discrete controllers and their continuous envi-ronments; have a precise operational semantics; and have a semantics thatsupports automated analysis [ZJKK14]. We believe that co-simulation ap-proaches such as those offered by Crescendo offers a promising approachtowards future extension of holistic CPS and heterogenous SoS design pro-cesses; Crescendo tools are already supported by an operational semanticsthat gives strong confidence in the results of simulations. Currently, how-ever the Crescendo co-simulation approach is targeted at CPSs - primarilysingle-level systems incorporating diverse models, and not for SoSs domains.A Crescendo-type approach could be adapted to suit SoSs that incorpo-rate mixed models, particularly some which have continuous time modellingparadigms, using one of the following approaches:

• Formal discrete-event models representing CSs could participate inCrescendo co-simulations. We would suggest the use of CML, a for-mal notation designed explicitly for SoSs; this would allow co-modelsto use the combined state- and process-based nature of CML. However,this solution removes the ability to make use of the higher-level featuresof CML that allow the combination of multiple CSs to be described andemergent behaviour verified.

• Co-models (which incorporate both a continuous-time element and adiscrete-event element) could be employed to represent CSs in COM-PASS models. This maintains the top-level features of the COMPASSapproach, including the path from requirements through SysML toCML models. A prototype for co-simulation already exists in the Sym-phony tool, which could be used to connect to Crescendo and allowco-models to represent CSs.

Crescendo currently only supports co-simulation approaches. Further workcould identify opportunities to extend the co-modelling approach of Crescendowith access to rich collection of static and dynamic analysis methods e.g., forproviding automated verification and analysis of co-models. Further researchinto the extension of co-modelling and co-simulation techniques, which arecurrently aimed at single-level CPSs only, into tools capable of offering ad-vanced reasoning and analysis of SoSs is needed. This should include thedevelopment of guidance for developers using this type of approach, and rec-ommended design processes. This should also include work to extend existingontologies to ensure that concepts are captured in a standardised way.

35


Co-modelling support for heterogeneous SoSs (such as those in the field ofassisted living or home automation) requires support for real time fidelity,such support for a ‘time bands’ theory. A real-time system is one in whichthe correctness of the behaviour ‘depends not only on the logical results ofthe computations, but also on the physical time when those results are pro-duced’ [Kop11]. Some real-time modelling requirements can already satisfiedby existing notations. However, these may not be easily ported to modelsof SoSs which require modelling of state as well as process synchronisation.A real-time interface has been proposed for the SPEEDS framework [BS10],motivated by the need for real-time modelling in the automotive sector whichis the focus of the SPEEDS project, allowing the language of contracts to ex-press real-time concepts, although the proposal has some limitations whichresult in information loss [BS10]. The CML should be extended to sup-port hard real-time requirements [COM14e] to support accurate SoS andCPS modelling. This requires that a real-time semantics is incorporated intoCML. Patterns employed by COMPASS for contractual specification needextension to ensure that the technique currently recommended by COM-PASS as best practice take the timing concepts into account. Tools providedby COMPASS (e.g., model-checker, theorem prover) need updates to ensurethat appropriate analysis techniques are supported.

4.2.2 Accessible verification techniques

Tools and methods to make formal approaches available and accessible toengineers from a range of disciplines

There has been a body of research to examine the reasons why formal meth-ods are not more widely adopted in industrial applications (e.g., see [DCC+13,DPL13, KDGN97, WLBF09]). Many researchers have suggested some un-derlying reasons, including a perception (perhaps an erroneous one) amongstpractitioners that formal methods lack adequate tool support [DCC+13,KDGN97, WLBF09] and/or require advanced training or mathematical rea-soning [DCC+13, KDGN97]. Integration of formal verification and analy-sis tools with other industry standard design and engineering tools is vi-tal [DPL13]. We argue that better tool support must involve efforts to im-prove a user’s ability to visualise the process of formal verification, and howto interpret the results. [WLBF09] argue that ‘wherever possible, proof toolsneed to disappear, so that they are fully hidden behind the other tools foranalysis, testing, and design automation’.

State of the art

36


Notations that support visualisation of SoSs and/or SoS models for differentstakeholders or CS domains can be helpful, particularly for allowing engi-neers to visualise CSs which require verification in part (not every componentwithin a system may require full verification [WLBF09]). Using notations ortools that can present intuitive, graphical representations of the SoS and theformal verification of its behaviour will help to make verification technologiesmore accessible to a wider range of engineering disciplines. This would al-low design teams trained in the concepts and requirements of one discipline,to understand the impact of their design choices on another design teamwithout requiring an in-depth understanding of their underlying formalisms.Domain-agnostic, intuitive notations are needed to achieve this goal. SysMLis a possible candidate to fulfil this role; it is widely used in many engineeringdomains and, with an intuitive graphical notation, is suited for representingarchitecture of an SoS at the system level. In addition, many existing engi-neering tools support SysML modelling approaches.

The COMPASS project has already published methods and architecturalframeworks for the use of SysML coupled with some aspects of formal veri-fication for SoSs (e.g., see examples in [COM14c, COM12, COM13b]). TheCOMPASS project has also begun to develop a tool that can automaticallygenerate a formal model (in the CML language) from models created inSysML, which is suitable for automatic verification and analysis. Currentlya subset of SysML features can be translated into CML [COM13c]. Somework has been completed already on produced more accessible user interfacesfor formal techniques, and/or automatic generation of code or models (seetools from Escher technologies23 as an example).

Libraries of patterns, defined in a consistent way, suitable for SoS mod-els and/or SoS live systems is a possible strategy to help to reduce thelearning curve and development times involved in developing a formally ver-ified system. The notion of patterns to help achieve best practice in de-sign is already widely accepted in software engineering. Software patternshave been influenced by work in the field of architecture; ‘describes a prob-lem which occurs over and over again in our environment, and then de-scribes the core of the solution to that problem, in such a way that you canuse this solution a million times over, without ever doing it the same waytwice’ [AIS+77]. This approach was proposed to software engineers in the1990s [Hay96, Fow97, GHJV95] and is widely accepted as best practice inmany programming domains. COMPASS has begun to identify and describepatterns relevant to SoS engineering in various domains. For example, archi-

23http://eschertech.com/products/index.php

37

http://eschertech.com/products/index.php


tectural patterns are detailed in [COM14c], as are ‘enabling patterns’ whichdefine collections of modelling elements designed to enforce a consistent ap-proach on a modelling process with a designated aim.


Recommendations for future work are summarised in Figure 1.

Further work is needed to couple CML and SysML. SysML could potentiallybe adopted as an accessible and intuitive ‘front-end’ for visualising some as-pects of the verified SoS. Translation tools allowing automatic generation ofCML from architectural models can facilitate tool interchange (see above) aswell as making formal methods accessible to a wider variety of engineeringdisciplines, by relieving design engineers of the need to be fluent in the under-lying CML. It will be easy to visualise which CSs or subsystems within theSoS have been formally verified, due to the graphical representation of thesystem’s topography. Further into the future, tools should offer a ‘round-trip’ verification process, in which engineers can quickly construct SysMLmodels which reflect system architecture and behaviour, automatically gen-erate formal models (e.g., in CML) for verification, and generate code. Wepropose that code generation can be considered in several steps; an initialstep could involve generating abstract syntax trees (ASTs) as an interme-diary step. From this, code can be generated into common general purposeprogramming languages, and/or into domain-specific languages. In this case,it would be possible to offer a rich collection of verification and analysis toolsto engineers, without requiring them to be fluent in the underlying CMLformalism, as well as swift generation of executable code, using SysML as ausable ‘front-end’ for visualising the SoS and its CSs, and interactions withanalysis techniques. Ergonomic profiling in SysML can also help to improvemodel comprehension.

Patterns and semi-completed templates, populated with domain-appropriateconcepts, are needed to help reduce the learning curve and development timeassociated with the adoption of formal methods. Formal methods are par-ticularly associated with a higher investment at the specification and designstages; partially-completed templates and patterns could reduce this over-head, as well as helping engineers by presenting formal models as a seriesof recognisable pattern elements. Future work must produce guidance forthe application of verified methods to an architectural model, including: er-gonimic profiling; architectural patterns or templates in SysML, supportedby tools; design processes for incorporating formal analysis with SysML mod-elling techniques; and appropriate ontologies where necessary.

38


4.2.3 SoS architectures

Architectures suitable for SoSs and systems of interconnected devices needfurther development

We discussed analysis techniques for heterogeneous CSs above; here we con-centrate on the issue of architectures suitable for SoSs. This has been iden-tified as key research problem area by the T-AREA-SOS project [TAS12].Architectures need to take into account the heterogeneity between the CSsas well as problems such as lack of full disclosure between CSs and deal-ing with evolution, legacy CSs, a volatile environment and high complexity.Architectural approaches can aid with many of these. For example, use ofarchitectural patterns can help to reduce complexity, by encouraging parti-tioning of a large and complex system into more manageable CSs, and de-signing and modelling these using recognisable patterns or units that bringfamiliarity. Some architectural techniques may be more amenable to dy-namic reconfiguration, which is potential strategy for coping with volatility.Information hiding approaches encourage collaboration across organisationalboundaries.

State of the art

Patterns appropriate for high-level architectures - referred to as ‘architec-tural styles’ - have been proposed and extended [GS94, MKMG97] previously.There is not a clear distinction for many researchers between ‘patterns’ and‘styles’, but in general a pattern addresses relatively low-level problems andsolutions [MKMG97] whilst architectural styles present system-wide views.The COMPASS view does not distinguish between the two but does con-sider patterns at varying levels of abstraction. Patterns at the architecturallevel are gradually being adopted from software engineering into the widersystems engineering community. For example, [Wei97] suggest patterns fordistributed systems.

The COMPASS project has published an initial collection of architecturalpatterns for SoS [COM14c, IPP+14], which is the first collection of patternsexplicitly for the SoS engineering community to our knowledge. This col-lection includes both patterns in the sense of an architectural style, whichinfluences the SoS’s structure and/or behaviour, and also ‘enabling patterns’which define modelling elements which, when populated, guide for the processof modelling an architecture; the enabling patterns include a pattern for con-tracts modelling, for example, and another for traceability [COM14c].

Describing systems in terms of architectural style supports reasoning about

39


a system’s design, by providing a set of high-level structural properties, avocabulary to describe them, and some assumptions and constraints on howthey should be employed [Gar00]. The design is easier to understand ifit conforms to a pattern [MKMG97] (we suggested other ways to improveaccessibility of SoS modelling techniques in Section 4.2.2) and similaritiesto previous systems allow for ‘lessons learned to be leveraged’ [Sha01]. Inparticular, researchers have argued for the use of recognised architecturalstyles in order to encourage the development and adoption of standardisedarchitectural frameworks [MKMG97]. Employing a recognised style and anaccompanying standardised framework facilitates the adoption of specialisedreasoning or analysis to be applied [MKMG97].

The component-based software engineering (CBSE) community concentrateon techniques suitable for on single-level systems, but standards and frame-works suitable for CBSE can be leveraged by SoS engineers. For exam-ple, some component-based SoS engineering frameworks have been proposedby [LRSM11], concentrating on providing support for a heterogeneous archi-tecture description processing, although a homogenous design methodologyis required for its adoption; and a domain-specific development infrastructureis proposed by [EM08]. Incorporating domain-specific analysis into tool sup-port and architectural analysis ‘allows architects to describe their systems interms of design elements defined by the reference architecture’ [EM08]. Thesetechnologies are not yet ready for deployment; a suite of reference architec-tures which can be harnessed to capture and express the domain-specificconcepts needed by industrial case studies is needed.

Notations suitable for the description and analysis of SoS architectures areneeded. Architecture description languages (ADLs) already supply this func-tionality at a single system level. Different ADLs may be in use to describevaried CSs within one CS. A few ADLs already can support features associ-ated with SoSs. For example, ACME [LRSM11] supports ADL interchange,although it does not support greatly heterogeneous CSs; xADL [DvdHT02,DvdHT05] provides an infrastructure for developing new, domain-specificADLs that share some fundamental concepts, although it lacks advancedtool support [LRSM11]; and the toolset proposed by [LOQS07]. SysML isone candidate which can be used for describing a system architecturally; as adomain-neutral, easily extensible notation which is widely used by engineersfrom varying disciplines, COMPASS advocates its use as a possible ADL forSoS engineers. ADLs for the future engineering of SoSs must be able to cap-ture important SoS properties, such as evolution, process mobility and con-tractual interfaces for CSs which are black-, white- or grey-boxes [COM13a],for example.

40


For the future, whole-lifecycle traceability will be important, including be-tween elements of architecture with requirements and decision rationale.Techniques and tools to support this will be needed. COMPASS has pro-duced techniques spanning the SoS lifecycle, including SoS requirements en-gineering [COM12] and a generic traceability pattern which can be used toimplement traceability between architectural elements (including elementsrepresented in SysML requirements diagrams) [COM14c]. Domain-speificarchitectural frameworks can be used to capture key SoS properties. Forexample, COMPASS has produced architectural frameworks for capturingfault tolerance concepts [COM14d].

The DANSE project proposes the use of simulation tools for optimisingarchitectures[DAN13a]. The DANSE tool-net will support generation of al-ternative SoS architectures, and, using a Rhapsody plug-in, the SoS architec-ture can be exported to XML for import into DESYRE (DANSE’s simulationplatform) [DAN13a].



We described approaches to formal modelling and simulation of diverse mod-els in Section 4.2.1; here we concentrate on architectural approaches. Despitethis, there are clear arguments to be made for the need to reason about func-tionality, quality of service, and architecture, alongside each other. For exam-ple, reasoning about current and possible architectures as well as delivery offunctions can be used for verifying emergent behaviour and proposed new dy-namic configurations. ADLs of the future need to address specific domainsand modelling challenges and be incorporated into models that representfunctionality, process mobility, evolution, dynamic reconfiguration, synchro-nisation and aspects of non-functional behaviour. One technique is to usea domain-agnostic, cross-discipline notation such as SysML as a general-purpose ADL, and to develop appropriate reference frameworks and guide-lines to accompany these to ensure that important domain-specific conceptsare captured.

A library of patterns/architectural styles available partially-completed, ex-pressed in reusable and easily adapted notations (e.g., SysML), supportedby modelling tools, would greatly aid design teams to achieve optimal de-signs. The publication of SoS-appropriate patterns from a variety of disci-plines would also allow teams from disparate engineering disciplines to sharebest practice in in tackling general engineering problems. Further work isneeded to develop guidelines for the selection of appropriate patterns/styles,

41


Figure 2: Roadmap: Dynamic reconfiguration, evolution and architecturalpatterns

42


and customise them in line with appropriate ontologies. Ready-made orpartially-completed models and templates could be developed, to be madeavailable for specific domains and/or engineering disciplines.

4.2.4 Verification of emergent behaviour

Tools and techniques are needed to verify the emergent behaviour and non-functional properties of an SoS

State of the art

Development of theories for controlling emergence (predicting emergent be-haviour, and minimising unwanted emergence) has been identified as a keyresearch problem area by the T-AREA-SOS project [TAS12]. SoSs of thefuture will have a need to deploy automated tools to achieve verification ofcorrectness of emergent24. COMPASS’s tools for verification [COM14f] in-clude the COMPASS tool suite, Symphony, and the new COMPASS formallanguage, CML [COM14e], which is the first formal language developed forSoSs. CML is based on existing well-developed formalisms, and permits thecapturing and analysis of both state and process synchronisation. Analysistools provided as part of the COMPASS tool suite include a model-checker, aproof obligation checker, a theorem prover and a refinement calculator.

Modellers from collaborating autonomous organisations sometimes wish tohide the internal details of models (for commercial reasons), whilst simul-taneously revealing enough information to permit a collaborative design ef-fort to proceed. A contract-oriented style of development provides a po-tential strategy: ‘contracts are descriptions of the constituent systems of aSoS given in terms of their expectations and the obligations placed on theirbehaviour’ [PF10]. Contractual approaches have been employed by formalmethods communities for many years, such as ‘design by Contract’ [Mey92]and rely-guarantee principles [Jon83]. A design by contract approach for-malises interactions between components: the contract formally guaranteesthat, ‘given a state and inputs which satisfy the precondition, the operationwill terminate and will return a result that satisfies the post-condition andrespects any required invariant properties’ [PF10].

A contractual specification also supports other desirable features:

24On COMPASS, we define ‘emergent’ behaviour as that functionality which can onlybe achieved when the assembled CSs collaborate together; this functionality cannot beachieved by any of the CSs acting in isolation [COM14b].

43


• The existence of contracts describing behaviour and service support dy-namic monitoring and automated regulation of CS performance, or forchecking that CSs comply with regulations. This is useful for dynamicreconfiguration.

• Substitution of one CS for another becomes easier, because contractsof potential CSs can be compared for some minimum level of ser-vice/functionality [PF10].

• CSs can evaluate services before using them through analysis of con-tracts [BJPW99].

• The collected CS contracts can be verified as a representation of theSoS emergent behaviour.

Cutting edge technology for the use of contractual specification in SoSsinclude the COMPASS approach[COM14i], which permits contractual de-scriptions and monitoring (passive testing) of CSs participating in an SoS,and provides frameworks and ‘enabling patterns’ [COM14c] to support thiswork.

DANSE also employs a contractual approach to specification of SoS and CSbehaviour [DAN13a]. The DANSE toolsuite will offer the ability to ver-ify aspects of the SoS[DAN13a]. DANSE defines GCSL (Goal and ContractSpecification Language) [DAN13b] for capturing SoS and/or CS requirementsformally. Probabilities are assigned to the requirements, which can be auto-matically verified using the statistical Model Checker PLASMA [DAN13a].The UPDM profile (used by DANSE to describe architectures) includes viewsrepresenting scenarios, activities and block diagrams for representing inter-actions between CSs, and therefore for capturing elements of emergent be-haviour [DAN13a].



The COMPASS tools need some extension in order to support a completeverification of emergent behaviour. Currently COMPASS analysis tools andthe CML language have some constraints. For example, the model-checkerneeds to support a wider range of modelling elements [COM14e]. With acomplete implementation of contractual specification, then it will be possi-ble to verify all possible emergent behaviours by comparing the contractualinterfaces of all CSs. This requires that the verification tools incorporatesome notion of the architectural configuration of the SoS; some architectural

44


Figure 3: Roadmap: Verification of emergent SoS behaviour

45


configurations prevent some interactions between CSs. For example, a cen-tralised or blackboard architectural pattern requires all CSs to communicatewith a central hub or repository, so the number of possible communicationsbetween CSs is limited, whilst a service-oriented architecture permits anyCSs to communicate with each other as long as one is providing a service,and the other consuming it [IPP+14, COM14c].

Improved guidance is needed on best practice when representing an SoS usingCML, and on the use of the tools to verify aspects of the SoS behaviour. Forexample, guidance and demonstrations of the use of the refinement calculatoris also needed.

Application of the COMPASS tools in SoS case studies drawn from varieddomains has demonstrated that different types of contract may be required,in order to permit the capturing of constraint relationships in a much moreintuitive way, and that the COMPASS contracts model should be able toinclude contracts that are not implemented specifically by a CS, but maystill enforce some constraints on emergent behaviour [COM14e]. This wouldrequire extending the COMPASS Contract Pattern [COM14c].

Future research should include the development of tools for automaticallygenerating an appropriate contractual description of a CS’s interface. Thiswill support collaborative design efforts that cross organisational boundaries;a design team can generate contractual descriptions their system for shar-ing with other teams, retaining confidence that the internal dependencies oftheir CS remain confidential. Contractual approaches make possible auto-matic monitoring of conformance. With the ability to automatically generate(or infer) a contractual specification, it will be possible warn SoS engineersautomatically if a newly deployed change, or a propose change, to one CS willcause it to alter its contractual specification, and/or cause ‘change ripples’that impact on other CSs in the SoS.

Future research should also investigate the development of semantics andappropriate tools to permit non-functional properties to be captured andverified. For example, this could include properties such as availability orsecurity. This work requires the development of appropriate ontologies andreference architectures, operational semantics and tool support. COMPASSadvocate expressing these types of extensions using the UTP, to maintain thesame approach to common formal semantics and approaches to heterogeneityand tool interchange are maintained. An example of a non-functional prop-erty that would benefit from the application of formal analysis techniques issecurity; we provide a discussion of future research directions that could beapplied to reason about security in Section 4.2.8. Many other non-functional

46


properties could be supported with similar extensions.

4.2.5 Fault tolerance

Methods and tools to support fault modelling across an SoS

Traditional approaches to fault tolerance may be difficult to implement andguarantee in an SoS, particularly one where dyanamic reconfiguration maybe employed as a strategy or where continuous evolution of the CSs, overwhich we may have little control, can affect delivery of fault tolerant behavi-ouor.

State of the art

SoSs often deliver complex and critical functionality in challenging environ-ments, and therefore vulnerability analysis and resilience planning is impor-tant for many SoSs. Architectural approaches using domain-agnostic nota-tions such as SysML are helpful for visualising and tracing the progressionof threats through an SoS. In an SoS, where CSs may find themselves re-sponsible for detecting a fault introduced by a third party, and possibly alsoresponsible for implementing costly recovery strategies to protect SoS-levelgoals [AIP+14, IRF+14, IAPP14], so reasoning and negotiating about this atan early stage is important.

Current state of the art in this field includes the COMPASS Fault Mod-elling Architectural Framework (FMAF), described in a number of publica-tions [AFPR13, AIP+14, IRF+14, IRF+14, COM14d]. This is a notation-agnostic architectural framework that proposes a series of views which, whenfully populated, identifies faults, errors and failures; track their progressionacross an SoS; locate the CSs which are capable of introducing, detecting andrecovering from each; and specifies cross-CS recovery behaviours. A furtherframework, the Fault Analysis Architectural Framework (FAAF) [COM14d]includes a series of views which, when fully populated, can generate outputfor analysis in a third party fault tree analaysis tool, HiP-HoPS25.

CPS systems already employ techniques such as ‘sensor fusion’ (amalgamat-ing data from several sensors, in order to generate a more accurate measure-ment [CyP14b]) in order to detect faults, such as sensors producing unac-ceptable readings.


25http://www.hip-hops.eu/

47



Figure 4: Roadmap: Stochastic models and fault tolerance

48


Better guidance is needed on the use of the two COMPASS fault reasoningframeworks, particularly on how to best export data from a COMPASS-supported tool into HiP-HoPS. COMPASS’s existing work has been vali-dated using case studies supplied by industrial partners, but further testingand validation is required, with a wider range of case studies, in order toproduce ‘best practice’ guidelines based on experience. Case studies at thisstage should include more complex scenarios, such as multiple SoSs that areintegrated or communicating. The FMAF and FAAF frameworks are notyet integrated together and future work should concentrate on developing ameta-model approach that can incorporate the appropriate approaches, aswell as extending COMPASS techniques to include better support for anal-ysis of degraded levels of service.

Future research directions in this area will benefit from greater support fromformal analysis techniques, to improve confidence in the correctness of an SoS.This is helpful for dealing with the challenge of reasoning about fault tolerantbehaviours in emergent behaviour, which is composed by the interaction ofa number of separate CSs, and does not reside in one single CS. Tools andmethods to support adaptive fault tolerance are needed, particularly for SoSswhich will exhibit significant evolution (see Section 4.2.11) and/or dynamicreconfiguration (see Section 4.2.6). This is required because a system thatreconfigures at runtime to cope with some degraded conditions will still needto be able to deliver fault tolerance, with possible recovery scenarios identifiedand prioritised.

Future modelling tools and techniques for SoSs and CPSs will require im-proved support for stochastic modelling and analysis [COM14e]. For ex-ample, stochastic formalisms already exist, with tool support; CML syn-tax, semantics and analysis tools can be extended with similar features.Alternatively, translation to external tools such as PEPA26, MRMC27 orPRISM28 could provide some of this functionality. This permits reason-ing about stochastic faults, or unpredictable human behaviour, for example.Guidance is needed on the use of techniques and patterns for identifying andanalysing both real-time properties and timing properties. In particular, ap-proaches to modelling temporal fault trees (ordered sequences of faults thatcan contribute to a failure) in SysML could be extended [COM14e]. For ex-ample, SysML does not feature useful ordering concepts such as ‘same time’or ‘before’. Architectural frameworks are needed that can capture these con-

26http://www.dcs.ed.ac.uk/pepa/27http://www.mrmc-tool.org/trac/wiki28http://www.prismmodelchecker.org

49

http://www.dcs.ed.ac.uk/pepa/

http://www.mrmc-tool.org/trac/wiki

http://www.prismmodelchecker.org


straints in SysML, and translate them into the formal notation CML foranalysis. These should be accompanied by patterns, guidance and standard-ised ontologies (to capture the necessary concepts) are needed.

Techniques to support contractual specification of fault handling are needed.A major target is the development of a notation that can capture fault tol-erance and resilience concepts explicitly at the contractual interface. Thiswould require extension of COMPASS fault analysis ontologies and referenceframeworks as appropriate, and the development of a semantics to supportexplicit reasoning about fault modelling. The COMPASS recommendationis that semantics are expressed using the UTP.

There needs to be a way to capture in an explicit way the fault tolerancerequirements for each CS, or for the SoS. At times alternative fault toleranceapproaches may be avaialble, but selection between them requires designtrade-offs to be considered carefully. An architectural approach to modellingof fault tolerance is one way to begin capturing this at a high level. Ar-chitectural notations which are accessible to different design teams can helpwith documentation of fault tolerance requirements and the reason for se-lection of specific designs. Simulation or verification techniques may provideone way to evalute the effectiveness or practical trade-offs imposed by dif-ferent choices. Simulations incorporating multiple input types may improvethe SoS’s ability to read patterns in low quality input data which is oftenprovided by low-cost, low-powered or lightweight sensors.

4.2.6 Dynamic reconfiguration

Tools and techniques to support reasoning about dynamic reconfiguration andautonomous decision making

Dynamic reconfiguration is one technique which can be deployed to cope withthe withdrawl of a CS from the SoS, or a sudden degradation in the qualityof service it can deliver. It typically involves replacing one CS with anotheroffering a similar of equivalent service, or changing the architecture of theSoS to optimise current levels of service in other ways.

State of the art

As touched upon several times in this chapter, contractual approaches canaid with dynamic reconfiguration by providing contractual specifications ofthe expected functionality and quality of service of current and/or potentialCSs, meaning that monitoring current conformance and identifying poten-

50


tial substitutes is a more straightforward task. Contractual specificationsmay be able to aid with the challenge of providing verification and validationof dynamically reconfiguring systems. The state of the art in contractualspecification was described in Section 4.2.4. COMPASS has produced a col-lection of architectural patterns, many of which are discussed in terms oftheir suitability for SoSs applying dynamic reconfiguration [COM14c]. TheCOMPASS approach to dynamic monitoring of contracts in evolving SoSs issummarised in [COM14i].

It’s important that any dynamic reconfiguration which takes place doesnot compromise important SoS-level properties, such as safety. A num-ber of approaches for reasoning about faults, failures and system recov-ery have emerged from safety-critical domains. For example, the Model-Based Safety Analysis (MBSA) approach is an approach that builds onexisting model-based development activities, incorporating safety analysisactivities [JHMW06]. A number of approaches can be leveraged to imple-ment this approach; for example, a varying range of architectural descrip-tion languages or notations could be used to model the system behaviour,and a number of possible techniques or tools could be used to provide de-tailed fault analysis alongside this. Tools available for analysis of faulty be-haviour include the well-documented Altarica29 [APGR99, BCS02, BBC+04,JHMW06], which formally specifies the behaviour of systems with faultybehaviour, as well as other approaches such as MeDISIS (based on SysMLand AltaRica concepts) [DVK10]; FSAP (Formal Safety Analysis Platform)30

coupled with NuSMV-SA; and HiP-HOPS31. COMPASS provides integrationbetween the COMPASS Symphony tool suite and HiP-HOPS; discussion ofCOMPASS’s integration with various static fault analysis tools is presentedin [COM14g].

Dynamic reconfiguration is related to the field of ‘autonomous’ computing, inwhich systems actively participate in some aspect of self-management; con-cepts from this field are relevant for SoS reconfiguration. ‘Self-management’may include all or some of: self-configuration; self-monitoring; self-healing;and self-adaptation. For example, ‘self-organising’ occurs when componentswithin a system collaborate, with no central authority, to determine con-figuration changes, and then collectively take the necessary steps to enactthis. Researchers have previously identified methods for self-healing, whichbegins with identifying the source of an identified problem and perhaps re-

29https://altarica.labri.fr/forge/30https://es.fbk.eu/tools/FSAP/31http://hip-hops.eu

51

https://altarica.labri.fr/forge/

https://es.fbk.eu/tools/FSAP/

http://hip-hops.eu


placing it [Kep05]. Heterogeneity is a problem here; disparate CSs in a self-autonomous system need to monitor their own behaviour and that of theirpartners, and select appropriate responses to performance issues, althoughCSs may each have quite different metrics and concepts for assessing ‘perfor-mance’ [Kep05]. In order to achieve dynamical performance optimisations,the system needs a ‘context awareness’, which is an ability to evaluate itsown operational context, internal resources and environment [CyP14b].



Tools and techniques are needed for: reasoning about correctness of newconfigurations; planning migrations from one configuration to another; andensuring traceability over time through multiple configurations of the system.The COMPASS ‘Epoch Pattern’ [COM14c] presents one possibility for mod-elling a series of configurations over a period of time. Further work is neededto ensure that ‘epochs’ can be captured in both SysML and CML, and thatreasoning can be applied to different epochs. Architectural approaches canbe helpful for planning staged or gradual migrations from one configurationto another, although SoSs which have requirements for high dependability orhigh availability may need formal verification techniques as well. There areseveral issues to consider:

• There may be a need to identify atomic transactions within the SoS, andensuring that they are not compromised by a dynamic reconfigurationarising in parallel with servicing the action.

• The dynamic reconfiguration must not compromise the system’s adher-ence to a recognisable architectural style [GMK02], or have a negativeeffect on any of the SoS-level emergent properties which might be guar-anteed by adherence to a particular architectural pattern.

We recommend future work including ontologies, SysML patterns, semi-completed formal templates and the extension of CML with any necessarysemantics to provide the ability to reason about the safety of dynamicallyreconfiguring, as well as reasoning about the possible effects on the SoS per-formance as a result of the reconfiguration. It should be possible to reasonin a formal way about the integrity of the currently selected architecture toensure these properties.

Achieving an autonomous SoS brings several challenges. Future work mustaddress the development of theories for control performance of distributedsystems, including problems such as ensuring consistent decisions; arbitration

52


and conflicts in decision-making; and ensuring control stability [CyP14b].Architectural patterns capable of delivering collaborative decision making,with and without central decision-making authority within the SoS, areneeded. SoSs of the future will require assurance that decisions made dy-namically (regarding architecture, for example, or performance optimisa-tion) do not violate non-functional properties such as security, safety or re-silience [CyP14b].

4.2.7 Process mobility

Modelling and simulation techniques are needed for engineering and reasoningabout emergent behaviour in SoSs that exhibit mobility

In systems featuring distributed CSs, it may be desirable to be able to movecode or running processes between CSs, as well as moving data. For example,instead of one CS running a process can collecting data from many otherCSs and (for example) producing a summary report, the process itself couldmigrate from CS to CS, incrementally gathering data and tracking runningtotals for the summary report as it goes. This may help to reduce networktraffic, if it removes the need to transfer large amounts of data. It cantake advantage distributed nature of the SoS and introduce some parallelprocessing, in some situations [COM14e]. An SoS that requires dependableprocessing requires tools and techniques to verify such behaviour.

State of the art

A theory of mobile processes that is suitable for refinement, and a devel-opment method, is provided in [COM14e], using a stepwise developmentprocess by analogy with Morgan’s refinement calculus [Mor98] for sequen-tial programs [COM14e]. The theory put forward in [COM14e] could noteasily be implemented in the COMPASS tool suite Symphony, however.The approach requires higher-order UTP which is not supported in thecurrent version of Isabelle/UTP, although it has been implemented else-where [ZC13, ZSCS14].

Different notations and approaches have different levels of support for rea-soning about mobile processes in a distributed system, such as an SoS or aCPS. In occamM [BW03], channels have mobility, for example [COM14e].Channel variables (which reference one of the channel-bundle ends) can bepassed around a network.


53



Figure 5: Roadmap: Process mobility and performance optimisation

54


Future work should include formalising the notion of channel-ends mobilityin the UTP, and study of its refinement calculus, as proposed in [COM14e].An implementation of higher-order UTP may be needed to support the im-plementation of the proposed theory in Symphony.

Process mobility can have effects on SoS optimisation, as suggested above.There are trade-offs to be considered: whether the effort of process mobilityoutweighs data transfers; whether the replacement of network communica-tions with local communications outweighs the extra effort, for example.Tools and techniques are required to support advanced reasoning about this,to ensure that design decisions can be made supported by analysis of thedesign trade-offs. Further patterns and techniques are required to analysethe possibilities here, resulting in guidance for SoS designers on dependable,optimised SoSs. Standardised ontologies to capture the necessary conceptsand share them across domains and disciplines may be required, along witha formal semantics if necessary to reason about the trade-offs. There needsto be a way to reason formally about the currently selected architecture ofthe SoS or CPS in order to assess performance benefits.

Process mobility can introduce challenges regarding governance of the processas it moves across organisational boundaries. This can involve the processporting variable values from CS to CS, which can have implications for se-curity and control of data access. There needs to be a way to reason aboutsecurity of data alongside process mobility. We address issues of security inSection 4.2.8. Ontologies for capturing concepts related to mobility shouldinclude security concepts, particularly for concepts relating to verifiably se-cured data and/or certifying ‘security’ or ‘privacy’ non-functional propertiesassociated with individual CSs.

4.2.8 Security

Guidance is needed on ensuring privacy and security in wirelessly connectedsystems, or and how to ensure that secured data remains secure

This can be regarded as a special example of the general problem of rea-soning about non-functional properties of an SoS, which was discussed inSection 4.2.4.

State of the art

Security implementation in SoS has been identified as key research problemarea by the T-AREA-SOS project [TAS12] as well as a key problem area for

55


cyber-physical systems [OTH13, LLBN14].

There is a substantial body of work in the field of formal modelling andverification of security concepts, such as exchanging encryption keys. Ademonstration of the use of CML for a well-known problem of this typeis provided in [COM14e]. Some key questions to address in implementingsecurity in an SoS include the verification or certification of individual CSsas ‘secured’, and ensuring that secured data is not transferred to non-securedCSs. There is an aspect of regulation and/or monitoring conformance inassessing the current security of a given CS and/or SoS. We discussed stateof the art in active contract monitoring for assessing contract conformancein Section 4.2.4.

Security for cyber-physical systems has traditionally not been widely consid-ered. As a result, some vulnerabilities in industrial control systems have beenexploited in recent years [LLBN14]. Recent work has attempted to resolvethis problem [OTH13]. For example, Homeland Security has created a Cy-ber Security Evaluation Tool (CSET) [Sec14], which can identify some majordeficiencies in cyber-security systems based on a tailored questionnaire in aguided self assessment.

Appropriate systems-level approaches are currently under active research fortackling security problems in both distributed CPSs and SOSs. ‘Secure De-sign Patterns’ have been suggested by the Carnegie Mellon’s Software Engi-neering Institute [DSS+09], including some architectural-level patterns. TheCyber Security Modeling Language (CySeMoL) [SEH13] which adopts anenterprise-level systems architectures approach for modelling system vulner-abilities, using a probabilistic interference engine to assess probability thatattacks on the system will succeed [SEH13]. Lemaire et al [LLBN14] presentan approach for capturing security concepts in SysML, using the InductiveDefinition Programming Framework (IDP) [WMD08], where a logic sys-tem automatically considers vulnerabilities; this approach could be suitablefor distributed heterogeneous systems. Some previous work using UML orSysML to describe security concepts and concerns is summarised by [OTH13],who argue that SysML is better suited for modelling control logic that othernotations. There are advantages to the use of SysML to produce a system-wide, security-aware model, such as better integration into existing tools andmodels, and SysML’s use in many different engineering disciplines.


Recommendations for future work are summarised in Figures 6 and 7.We discuss specific security issues here, although we regard security as a

56


Figure 6: Roadmap: Security and non-functional properties

57


Figure 7: Roadmap: Non-functional properties

specialisation of the more general problem of non-functional properties. Thestarting point for moving towards verification of non-functional properties istypically the development of usable semantics, frameworks and ontologies forcapturing key concepts and reasoning about them. We suggest a collection ofpossible non-functional properties (e.g., security, dependability etc.) undera general umbrella term of ”non-functional properties”. Figure 7 presents aview of the general concept of non-functional properties, with sub-researchtopics.

Modelling approaches provided already by COMPASS require extension toinclude general models of an attacking intruder - using a domain-specific ar-chitectural framework, for example. Standardised ontologies for capturingthe necessary concepts would be needed, and patterns may also be identifiedfrom the existing security domain to provide guidance. SysML pattern are re-quired, allowing users to define security protocols and properties of intruders.Such a pattern requires a defined semantics in CML; the CML language andsupporting analysis tools should be extended to check properties which wouldbe required to, for example, discover an attack on a protocol [COM14e].

SysML patterns and templates designed to describe security-domain concepts

58


such as intruders and security protocols, would help to support visualisationof security concepts associated with the SoS and individual CSs. SysML pat-terns capable of generating the CML needed for a protocol would provide aconsiderable step forward. This would allow users to verify and reason aboutprotocols without needing fluency in the underlying formalism, encourag-ing the expansion of formal verification and analysis techniques to a widerrange of engineering and design teams [COM14e]. This does require furtherwork on the SysML-CML translation tools to ensure that SysML securitymodels defined using the new security pattern can be translated into CML.Other Symphony tools may also require extension; for example, the CMLproof obligation generator could also be extended to generate proof obliga-tions about security protocols, assuming that appropriate properties can becaptured; the proof obligations then form an input for an extended theoremprover. Techniques that allow reasoning about the security requirements as-sociated with the contractual interface of CSs is an area that requires furtherresearch - for example, in cases where an external interface is connected toand exploited in ways that were not anticipated at design time. We’d like tosee a complete life-cycle approach which is capable of recording and reason-ing about security concepts at all analysis stages, to ensure that security isconsidered as a core aspect of the Sos design.

Security concepts may intersect with fault analysis - for example, in caseswhere SoS faults are triggered by potential security breaches (whilst detec-tion of security breaches is also an area for future research). There is a needpotentially to be able to model recovery behaviours for recovering from adetected security breach as well as recovering from an SoS fault. Trade-offsmay be necessary in these types of scenarios, and so architectural approacheswhich allow high-level concepts and requirements to be considered, capturedand stored as design rationale are needed. Structured and - where possi-ble - automatic approaches for identifying security vulnerabilities should bedeveloped; work by [LLBN14] is relevant here, although a contractual speci-fication as recommended by COMPASS, complete with explicit modelling ofsecurity concepts at the system boundary, could also be fruitful for automaticdetection of some security problems at design time. This approach could beparticularly useful for CPS-oriented systems, where multiple design teamswith different design specialisms need support for identifying cross-cutting,SoS-level security attacks and vulnerabilities.

Finally, standards are needed for certifying the security of individual CSswithin an SoS. Patterns, architectural frameworks and guidelines should bedeveloped to model how secured data can propagate across an SoS. We rec-ommend implementing this type of pattern in SysML; this presents engineers

59


with a domain-agnostic, system level visualisation of where secured data isstored in the system, and possible routes which could lead to its propagationto unsecured CSs. Frameworks for modelling these concepts in SysML shouldbe integrated with the extended CML tools, capable of reasoning about se-curity and privacy-related concepts explicitly, for verification. Patterns andframeworks relating to securing data within an SoS should take into accountintegration techniques, so that integration plans can be analysed and veri-fied.

4.2.9 Performance optimistion

Methods and guidelines for designing optimisation strategies will be needed

State of the art

SoSs are typically very large, and significant quantities of run-time data maybe produced. Effort must be put into management of internal resources,energy management, computation and communication resources required asquantities of data to collect, manage and process increase [CyP14b]. Thereis considerable demand for SoSs to be able to identify patterns automati-cally in efficient ways, as the quantity of input data becomes too large to bemanaged by humans. For example, automatic license plate detection maybe deployed by law enforcement agencies, involving automatic recognition ofletters and numbers on images of cars, whilst traffic management systemscould employ video cameras to automatically detect presence of vehicles inparticular lanes on a highway for identifying cases where warnings need tobe issued about slow traffic ahead, for example. Techniques for identificationand classification of patterns are needed increasingly, particularly for dealingwith extremely diverse types of input data such as those typically associ-ated with CPS (e.g., input from sensors for detecting light/dark, colours,temperature, humidity, radar or infra-red reflections, images etc.) Existingstate of the art in statistical pattern-recognition includes processing on rathermore complex input data, such as identifying and recognising speech patternsfrom an incoming acoustic waveform, or synthesising incoming sensor datainto weather predictions [Web03]. SoS engineering can leverage existing al-gorithms and techniques for areas of pattern recognition including ‘clusteranalysis, classification, regression, and sequential analysis’ [CyP14b]. Datafrom small and/or inexpensive sensors which are used in many SoSs to gatherinformation about the environment may be ‘noisy’ or unreliable [VF13]. CPSsystems already employ techniques to achieve apparent improvements in thequality of input data from such sensors, such as ‘sensor fusion’ [CyP14b],

60


which involves ‘fusing’ data from separate sensors in order to generate moreaccurate estimates of measurements, or for detecting sensor problems.

We have already discussed the necessity for many SoSs of self-monitoring(for example, to detect failures or degradations in service or identify oppor-tunities to reconfigure) in Section 4.2.6. Optimisation strategies may referto design optimisations or runtime performance optimisations. We have al-ready discussed possible optimisations for reasoning at design time aboutsecurity (see Section 4.2.8) and fault tolerance (see Section 4.2.5) which canbe regarded as examples of non-functional properties that require analysis atdesign time in order to achieve optimal solutions. Techniques proposed forreasoning about security or fault tolerance (e.g., development of appropriatepatterns) could also be adapted to reason in a similar way about other non-functional properties. We discuss methods for reasoning about architecturaloptimisation in Section 4.2.3, and suggest some types of optimisation thatwe may wish to reason about in Section refsec:mobility in order to analyseperformance savings brought by mobile processes.

A common technique for achieving design or performance optimisations andexploring design options in embedded systems and other engineering dis-ciplines centres on modelling and simulation to compare a range of possi-ble design parameters and constraints in a simulated run-time environment.We discussed approaches to simulation in Section 4.2.1, including the co-simulation approach offered by the Crescendo tool that allows discrete-eventmodels and continuous-time models to be simulated in parallel, synchronisingon data and timing information specified in a contract. The Crescendo ap-proach to design space exploration is documented in [DES12]. The DANSEproject proposes simulation tools for optimising architectures[DAN13a]. TheDANSE tool net will support optimisation through the use of DESYRE,which is the simulation platform used by DANSE. SoS architectural descrip-tions should be imported to the simulation platform, alongside behaviouraldescriptions of CSs, which can be created in DANSE’s integrated Rhapsodytool or in any other tool that supports the FMU format (e.g., OpenModel-ica) [DAN13a].



Ontologies and reference frameworks are needed to identify and plan possi-ble optimisations, whether for design optimisations at design time or perfor-mance optimisation at runtime. The concepts which the SoS engineer wishesto reason about need to be captured in a standardised way. For some com-

61


mon optimisation concepts (e.g., time, computational effort etc.) it may bepossible to develop semantics that allow engineers to capture their require-ments formally. The COMPASS tool suite Symphony could be extended withsimulation functionality that permits exploration of design options in a sim-ilar way to Crescendo. Appropriate guidance is required for users, includingappropriate enabling patterns and/or architectural frameworks.

Tools and techniques are needed to plan data processing, for detecting sim-ilar patterns and identifying ‘good’ or desirable system reactions, as wellas ‘undesirable’ reactions [Eng14]. Techniques for pattern-recognition anddata-mining are often currently employed with human expertise to calibratethe pattern-matching [CyP14b]. Future work should concentrate on improv-ing the pattern-matching of autonomous systems, such that patterns can beidentified from highly complex and heterogeneous data sources, automat-ically and with confidence. Identification of domain-appropriate patterns,creation of run-time data pattern libraries and methods for reasoning aboutthem and identifying possible optimisations are needed, including domain-specific ontologies (since input data ‘patterns’ will vary greatly from domainto domain) and reference frameworks for handling data and wide applica-tion of case studies. Much (not all) pattern recognition involves analysisof data gathered from input sensors in a CPS. Therefore, this work shouldinclude tools and techniques to model the identification and management ofunreliable or ‘noisy’ data.

4.2.10 Stochastic behaviours

Tools and techniques for modelling dependable human-centred SoSs of thefuture need to model stochastic events and human behaviour.

A system of systems is typically multi-disciplinary and encompasses a rangeof socio-technical issues. It’s common for humans to play an important rolein an SoS, either as operators which perhaps act as ‘glue’ allowing differentCSs to interact, or acting as end users for the SoS. Some SoSs exist to monitorhumans and attempt to influence their behaviour (e.g., transportation SoSs,emergency response etc.)

State of the art

Techniques for modelling human behaviour present a specialisation of theproblem of dealing with heterogeneous models - i.e., the problem of integrat-ing models from different domains that represent quite different conceptswhich are difficult to map. We described techniques for integrating con-

62


ceptually diverse models in Section 4.2.1. Co-modelling and co-simulationtechniques supporting the integration of human behaviours into models andsimulation may be helpful for some domains in the future, whilst existingco-modelling techniques could be expanded to different domains, includinghuman behaviour analysis.

The DANSE tool suite will offer statistical model-checking facilities[DAN13a].Once CS and/or SoS requirements have been expressed formally in DANSE’slanguage GCSL, probabilities are assigned to the requirements. The statisti-cal Model Checker PLASMA can automatically verify them [DAN13a].



In Section 4.2.5 we described the need to incorporate techniques, patterns,ontologies and semantics for reasoning about stochastic events into the COM-PASS tool suite. Human behaviours can be represented by stochastic andprobabilistic reasoning techniques. Future work should include developmentof semantics to capture these requirements and the behaviours formally andreason about them usefully.

Simulation techniques can be important for considering human behavioursand reactions to stochastic events; this allows exploration of design optionsand performance optimisation (see Section 4.2.9). We describe co-simulationtechniques and future possible work in this area in Section 4.2.1. There maybe significant design choices to be made for SoSs which involve dealing withhuman behaviour or stochastic events, including trade-offs such as weighingup the relevant merits of achieving optimal performance in ‘normal’ condi-tions, but losing some ability to respond quickly to unexpected incidents, orallowing some compromises to be made to performance achieved in ‘normal’conditions, which allow some improvements to be achieved in the ability toreact quickly to unusual events. For example, in a traffic management sys-tem, designers may opt to preserve one lane (a ‘hard shoulder’) for the useof emergency vehicles, allowing them to reach the occasional traffic accidentsquickly. Or, alternatively, the designers may opt to allow traffic to use the‘hard shoulder’ during peak hours, which would improve ‘normal’ perfor-mance during peak hours, but make it more difficult to reach the occasionalaccident quickly. SysML patterns and guidelines to aid with modelling thesetypes of design decisions at the SoS level would be very helpful.

63


4.2.11 Evolution

Tools and methods for reasoning about and analysing SoSs through a seriesof configurations or versions over a period of time

It has been noted many times previously that SoSs typically exhibit con-tinuous evolution (e.g., see [Abb06, Mai98]). Verifying the architecture andbehaviour of an SoS as it changes over a period of time is a key require-ment.

State of the art

Some challenges and issues relevant to the modelling of evolution were de-scribed in Section 4.2.6, where we described the modelling of dynamicallyreconfiguring versions of an SoS.

Some can be leveraged from the field of enterprise engineering. This hasbeen defined as ‘applying holistic thinking to conceptually design, evaluateand select a preferred structure for a future state enterprise to realise its valueproposition and desired behaviours’ [NR07]. The new approach of mergingthe two ‘involves applying the principles of systems engineering to the enter-prise itself, as a complex entity including the product system(s)’ [RRN09].Key SoS challenges in enterprise architectures include [RRN09]:

• adding or removing constituent systems

• changes in the socio-technical environment

• shifts in the enterprise profile

An epoch-based analysis method has been proposed previously for evaluatingenterprise architectures in a changing environment [RRN09]. System lifespanis represented by a series of ‘epochs’, each of which represents a period whensystem needs and context are stable. A change in context or needs resultsin a new epoch. This approach ‘provides insight into decisions, for example,when in the evolution of the SoS new constituent systems should be added,and when investments should be made in new technology’ [RRN09]. Theepoch-based analysis begins with defining potential epochs and approximatedurations. Rather than a traditional, systems-level approach to architecturewhere the system moves towards some vision of how the system should look ata single future point in time, epoch-based architecture approaches encouragesthinking about the environments of the SoS.

COMPASS has built on this work to produce an ‘epoch pattern’ [COM14c].This is an enabling pattern, a collection of modelling elements designed to

64


support specific design aims. The pattern involves identifying points in timethat serve as ‘baselines’. Each point in time identified in this way is then con-sidered to represent one epoch of the continually evolving system. Analysistechniques are applied to the baselined versions of the epoch. Relationshipsbetween the different epochs must be defined, so that evolution can be ex-plored. Different system characteristics may be modelled in the epochs, andcompared between versions.



Recommendations for modelling successive versions of a dynamically recon-figuring system are also relevant here (see Section 4.2.6). For example, thecurrent epoch modelling patterns could be extended, to include guidance,extended patterns and templates for reasoning about staged migrations fromone system version to another. Recommendations for future work in perfor-mance optimisation (see Section 4.2.9) may also be relevant here. In manycases, modellers will want to collect performance information about differentsystem versions, to support reasoning about evolution of the system. Forsome cases performance data may be stored as rationale justifying evolutionor re-architecting of the system.

Evolution may include not only system topography, and functional behaviour,but also certain SoS policies (e.g., rule-based policies for ensuring optimi-sation, dynamic reconfiguration or security). Patterns and frameworks forreasoning about the evolution of rule-based policies will be needed, as well asautomated verification tools for checking that new policies continue to con-form to SoS-wide constraints and/or CS-level contractual obligations.

There need to be patterns available to support advanced traceability betweenversions of the system, from requirements through to design options andtesting patterns. This may require complex levels of traceability if a CS isreplaced by a collection of other CSs; traceability from one CS to several CSsneeds to be maintained.

65


5 Emergency Response and Disaster Relief

In this section we tailor the generate roadmap, presented in Section 4, toa roadmap specific to the emergency response and disaster relief domain.The COMPASS case study supplied by COMPASS partner Insiel [COM14j]addresses modelling and simulation in an emergency response SoS. There are,of course, many drivers and socio-political factors at work in these domains,but we limit our scope of consideration of some major challenges in the fieldof modelling and simulation. A useful companion roadmap with a widerscope can be found in [Roa13a].

We regard ‘emergency response’ as those procedures used by public sector au-thorities and private providers on a regular basis for responding to emergencycalls. We also widen our scope to consider opportunities for SoS model-basedtechniques in the field of disaster relief, which we define as those plans andprocedures created by non-governmental organisations (NGOs) and nationalgovernments for responding to larger, rarer disasters, running for much longertime-periods. Both types of SoS involve co-ordinating a large number of dis-tributed public and private sector agencies to provide medical and structuralaid and protection.

5.1 Characterising the domain

Maintaining inter-organisational links with other NGOs, governmental ac-tors or military peacekeeping and aid workers needs to be balanced carefullywith an NGO’s key mission of remaining independent [MRH05]. Differentorganisations may have different requirements and expectations as to whatinformation is important and requires sharing, so establishing protocols sup-ported by rationale is important. Inter-organisational sharing and protocolsare equally important in emergency response SoSs as well as disaster relief;organisations must be aware of and accept each other’s ‘missions, structuresand styles of operation, the capabilities and limitations of the communica-tion system and the mechanisms for coordinating the allocation of scarceresources to different functional areas of the emergency response’ [PL03].Agreeing responsibilities and protocols for each constituent system can bedifficult. It’s important that reporting structures are clear at all times andhuman operators understand who to report to [Roa13a].

Provision of communications infrastructure in emergency or disaster scenar-ios is a priority [Man07], and can be complicated if existing systems have

66


been subject to disruption or distributed agents on the ground are unclearabout the correct protocol or hardware to use [Roa13a]. For example, thiscan be a problem in mountainous areas where emergency personnel rely onradios for communication (some areas will experience ‘shadow’ where radiosignals are blocked by local topology [COM13d]), or it may be a problem indisaster-afflicted areas where internet or phone available may be only par-tially available [AFPR13, Man07].

It can be very difficult to build a clear picture of the situation in the veryearly stages of a major response, due to disparate information arriving inan un-structured way from separate parties. This can lead to overestimatesor underestimates of the scale of an emergency. In contrast, the speed ofcommunications and swift responses can become safety-critical properties.Speed can be increased by improving warning systems, and/or enabling au-tomated detection and reporting of potential problems. Many emergencyresponse and disaster relief fields are, by definition, tightly integrated withstochastic events such as volcanic eruptions, wildfires, tsumanis, hurricanesand other storms, floods etc. Networks of sensors are capable of providingenvironmental data [Roa13a] can be integrated to provide sufficient informa-tion that advance warnings can be provided for some of this risks. Modellingtools and techniques are needed for integrating heterogenous types of inputdata and analysis (e.g., advanced pattern recognition). Integrating modelsof the SoS with stochastic modelling capabilities is needed, to permit anal-ysis and simulations of various probable scenarios and how humans mightrespond.

Architectural models may be one solution to help integrate processes quickly,communicating to the different agencies the agreed procedures and whattypes of ‘faults’ to look for, how to identify them and what action to take.This type of information sharing is important for cases where one agencymay be required to look out for, and react to, faults introduced by a thirdparty CS in a domain that is not well-understood.

Challenges can be posed by the need to communicate with dispersed mem-bers of the public, in addition to the need for aid workers to communicatewith each other. For example, this was a challenge in the aftermath of Hur-ricane Katrina in the USA [VNTB07]. This may involve identifying isolatedareas where people may be sheltering; communicating with cut-off commu-nities who have reduced access to standard mass communication channelssuch as radio and/or television; and also addressing the content and phas-ing of the messages being broadcast to the public [VNTB07]. One tactic isto deploy autonomous systems such as airborne drones to locate survivors

67


in remote areas, and potentially deliver emergency supplies or communica-tions. Drones can be used for more purposes than this in these domains,however. For example, airborne drones can also be used to spot and trackthreats such as floods, eruptions or wildfires, to investigate leaks or eruptionsunderwater, or to detect earthquakes and/or tsumanis. Advance warningsprovided by sensor networks or drones could help to reduce the impact ofa natural disaster as well as helping communities to cope afterwards. Ourexpectation is that future disaster relief and emergency response systems willsee an increasing use of drones to provide early warnings, tackle threats inremote locations and save lives in the aftermath of an emergency. Deployingcollections of drones safely, however, will require advanced modelling andsimulation tools. Drones require advanced context awareness, pattern recog-nition and the ability to make autonomous decisions - e.g., small adjustmentsto routes in response to weather conditions. Collections of drones need to becertifiably resilient, and make correct autonomous decicions, to the extentthat we have confidence drones will not suffer failures and fall onto propertyor people, for example.

Emergency response and disaster relief domains can both face problemsof triage for casualties. Medically trained personnel need to assess casu-alties swiftly and identify those who need help most urgently [LMFJ+04].Overtriage is a common problem which ties up valuable, trained staff inissues of conducting triage and subsequently tracking casualties and medi-cal staff status [LMFJ+04]; wireless sensor networks (WSNs) could be onesolution [LMFJ+04] to this problem.

A number of tools and modelling or simulation approaches are employed inemergency response and disaster relief domains, although a systems approachis also needed for ensuring that separate, standalone outputs from differentagencies are integrated (e.g., a framework for this is outlined by [JM03]).Models can include: emergency response planning tools for evaluating alter-native strategies; disaster impact projections; and training simulations [JM03].

5.2 Market Needs

We suggest here some market needs that present opportunities for model-based tools and techniques to support future SoS development. In each casewe briefly demonstrate how these opportunities each provide motivating ex-amples for the COMPASS ‘product’ features, described in Section 4.1.

• Identify problems early and adapt to cope quickly. There are

68


significant requirements for resilience and robust communications inthis domain, as a failure (for example) in the SoS’s globally emergentservice could result in loss of human life. However, the separate CSstypically retain substantial independence. Recognising problems earlyenough can be difficult, particularly if it’s necessary to share swiftly-emerging information across organisational boundaries. This is notonly about designing systems that can deliver advanced warning (e.g.,of a storm, tsunami or flood) but also for anticipating problems thatundermine rescue or relief plans that are already underway. For ex-ample, firefighting crews need as much advance warning as possible foranticipating sudden changes in direction of a wildfire. Once firefightershave received data that allows them to detect changes in the situationthat may be unexpected and unplanned for, they need to have proce-dures in place for sharing this with other services so that updated planscan be updated together. For example, in the case of wildfires, policeor military personnel may be working to evacuate civilians in the pathof the fire; plans for tackling and containing the fire need to plannedalongside plans for ensuring public safety.

Relevant products Satisfying this market need requires effort on sev-eral research areas. An ability to identify problems early is greatlyaided by the use of sensor networks to collect appropriate data. Forexample, systems of distributed smoke detectors and wildfire trackingsystems can help with the two example situations above. Successfulimplementation of these is discussed under the market need ‘produceaccurate warnings’. However, there is also an element of facilitatingspeedy changes in procedures and plans. This requires advanced plan-ning tools and support. Dynamic configuration is one possible strategyfor coping with these types of problems, although dynamic configu-ration in this particular domain is frequently considered undesirable.There is a need to ensure that personnel on the ground always under-stand who to report to and who to receive instructions from, but there’sa risk that dynamic reconfiguration carried out ’in the field’ could leadto situations where there is insufficient accountability and a confusedcommand structure. Tools to support advanced performance optimi-sation may be helpful, for identifying run-time variables that shouldbe monitored in order to be able to identify problems, and possibletrade-offs. Research into architectural models coupled with notions ofresilience, building redundancy and/or alternative plans at the designstage, may be one approach, coupled with frameworks and semanticsto reason about non-functional properties.

69


• Produce accurate advance warnings. For many environmentalproblems, this can include gathering input from very different domains.For example, tracking and predicting the course of wildfires may involvemeteorological data, outputs from simulations, data from a wide areasensor network, and readings from airborne drones working in an area.We need a way to be able to incorporate all this data and produceaccurate predictions in advance of an emergency situation, or better,more targeted advice during and after an emergency.

Relevant products This market requirement can be satisfied by sev-eral approaches: one approach is to produce complex models that inte-grate heterogeneous types of data; and a second option is to integratedmultiple domain-specific models, each accepting domain-appropriatedata. A key advantage of the second approach - integrating heteroge-neous models - is that it allows modellers from each domain to continueworking in their preferred tools, with no loss of data and no need toalter the level of abstraction to enable analysis or simulation. This isuseful in a domain where each of the CSs needs to retain strict indepen-dence. This approach requires sufficient levels of tool interoperability.SoSs comprising autonomous systems such as drones require an abilityto verify emergent behaviours, including cases with distributed control;this requires research into theories of distributed control, and develop-ment of appropriate ontologies, reference frameworks and semantics.

• Easy and swift integration of multiple communications sys-tems, without compromising chain of command. There can bea problem here if several organisations which are not regularly workingtogether are responding to a major emergency (e.g., military personnelworking alongside ambulance crews). It needs to be clear to distributedagents on the ground what hardware and what protocols to use for com-municating, and who they are reporting to. Two organisations workingside by side need to be able to accommodate each other’s communica-tions hardware and also procedures.

Relevant products Satisfying this market need requires communica-tions CSs which could be certified as secured to some minimum stan-dard. This is because for many SoSs, some of the CSs have requirementsfor secure communications (e.g., disaster relief areas where there are se-curity threats to personnel on the ground, or CSs dealing with medicaldata). Trusted procedures for integrating cross-organisational commu-nications will also be needed, to ensure private data remain private evenwhen two organisations begin to collaborate on shared communications

70


channels. An ability to automatically detect the contractual specifica-tion of a communications CS would greatly aid situations where severalorganisations are beginning to collaborate in a new locale for the firsttime; those CSs with special communications requirements (e.g., highsecurity) can examine the contracts and use them to verify the overallbehaviour of the integrated communications.

Architectural frameworks for modelling procedures and protocols mayalso be required.

• Reliable, secure and safe autonomous systems. Autonomoussystems have great potential for emergency response and disaster man-agement scenarios. Drones can produce early warning systems, under-water repair systems and airborne search and rescue efforts, either inthe open country, in isolated or cut-off areas, or in smoke-filled build-ings (for example). We need to be sure that they are safe, make sound,correct decisions and will not fall onto people or property. They needto be certifiably secure from malicious attackers.

Relevant products This market requirement motivates research intoadvances for cyber-physical systems of systems. For example, develop-ment of autonomous, independent drones that can react appropriatelyto their environment requires: an ability to reason about safety andsecurity, and verify these properties; verify the emergent behaviourof the SoS of drones; and excellent tools supporting multi-discipline,multi-domain engineering teams.

• Real-time simulation of responses to emergency situations,such as terrorist attacks or major natural disasters. Modelscan be used to simulate how humans react to different threats andscenarios - such as, making predictions about flows of crowds or traffic.If accurate simulations can be executed at real-time, with appropriateinputs from varied organisations, it would greatly aid decision-making,and the ability of the agencies involved to react quickly to events on theground. This is particularly useful in this particular domain, becausea large number of external factors, such as current weather conditions,day of the way, special events, disasters such as storms or earthquakes,etc. An ability to model, simulate and analyse ‘standard’ behavioursalongside various stochastic inputs would be helpful here.

Relevant products Simulation tools for many domains are alreadyavailable, but are not often integrated with run-time decision mak-ing. Satisfying this market need requires significant optimisation of

71


modelling tools, in order to produce useful model outputs in a realis-tic timescale using real-time data. Data may be drawn from varyingdomains, so approaches for tackling heterogeneity are appropriate. Al-lowing organisations or teams to create their own models in their ownpreferred tools, and then linking these heterogeneous tools in a co-modelling or co-simulation effort, will allow teams to leverage the opti-misations that have already been achieved in their own domain specifictools. Solutions (encompassed both/either tools and techniques) thatare capable of analysing multiple proposed solutions for an emergencysituation, and making recommendations for properties that have beenmodelled stochastically could be helpful. Stochastic models require tobe integrated into existing SoS-appropriate modelling tools, such asCML, along with notions of performance.

• Help with identifying and refining appropriate non-functionalrequirements, such as security or resilience. It can be difficult toidentify cases where requirements need to be placed on non-functionalproperties. Security is particularly important for emergency responsedomains, which may be handling medical data.

Relevant products Studying potential non-functional properties willbe a good starting point, by providing a framework for capturing re-quirements in these areas as well as a semantics for beginning to rea-son about them. This applies not only security, but potentially other,unanticipated non-functional SoS properties as well. Simulations canbe executed at the design stage, incorporating models (and thereforebehaviours) from all the CSs to provide realistic projections of the SoSbehaviour. These design-stage simulations can be a helpful aid for iden-tifying design choices associated with unacceptable results in the de-livery of some non-functional property (e.g., availability, or usability).Generated during the design stage, this information becomes useful in-formation that can inform the cross-disciplinary, cross-organisationaldesign efforts to achieve an optimal design choice for the SoS.

• Provide guidance on appropriate architectural choices. Ar-chitectures can be important for enabling (or limiting) information-sharing, dynamic reconfiguration and fault handling (for example). Itwould be useful to be able to select and establish an appropriate ar-chitecture quickly, particularly in situations such as major disaster re-lief where a new cross-organisational task force may be deployed veryquickly in a new location, needing to establish appropriate proceduresand communications quickly. Better advice on what types of architec-

72


ture have been successful in the past would be useful.

Relevant products Work to study architectural patterns, and theirimpact on the delivery of required non-functional properties or theverified emergent systems, is needed here.

73


6 Home Entertainment and Home Automa-

tion

In this section we tailor the generate roadmap, presented in Section 4, toa roadmap specific to the home automation domain. The COMPASS casestudy supplied by COMPASS partner Insiel [COM14j] addresses modellingand simulation in an emergency response SoS. There are, of course, manydrivers and socio-political factors at work in these domains, but we limit ourscope of consideration of some major challenges in the field of modelling andsimulation.

The COMPASS case study supplied by COMPASS partner Bang & Olufsenaddressed modelling and simulation issues in the field of audio-visual SoSs,although we widen the scope of our roadmap to include opportunities in therelated field of assisted living and home automation.


There is a competitive and innovative industry centred around home elec-tronics for leisure activities, such as home entertainment systems that sup-port online activity, gaming, music and television. SoSs in this domain aretypically constructed from separate interoperating devices (e.g., speakers,storage, games consoles, internet-enabled televisions, tablets, smart-phonesetc.) from a variety of manufacturers. An SoS installed in the home can de-liver a wide range of functions, however, in addition to home entertainment.Home security and energy efficiency can be improved by controlling heating,lighting, window blinds/curtains and security cameras. A a wide variety ofdevices can be linked to provide ‘assisted living’ services, particularly impor-tant for the elderly or disabled who live in their own homes. Assisted livingwill become increasingly important in Europe as the population is projectedto live longer [Pro10]. Assisted living can include intelligent collections ofdevices that co-operate to support quality of life, safety and security, with anumber of high-level goals: [Pro10]:

• Preventing falls and accidents by detecting overflowing water, and con-trolling water temperature or cooking appliances

• Supporting personal hygiene (e.g. helping with dressing/undressingand washing)

• Identifying gas, smoke or carbon monoxide leaks

74


• Managing medications and reminders about important tasks

• Monitoring health conditions

• Supporting household food shopping and management

• Improving security e.g. through electronic locks

• Supporting mobility, e.g., through smart wheelchairs, improved publictransport services and navigation aids

• Providing interactive games and communications to alleviate isolation

In fact, assisted living and many aspects of home security and entertainmentSoSs begin to overlap with the notion of ‘Internet of Things’ (IoT) - devicesconnected via the internet.

6.2 Market needs

Major challenges in the field of home SoSs assisted living include the fol-lowing. For each of the market needs listed below, we also suggest someproposed future products that could advance the state of the art.

• Cope with unfamiliar household objects in a sensible way, andif necessary ‘learn’ their context and physical details. Homesare typically filled with huge numbers of objects of wildly varying phys-ical dimensions, even for objects fulfilling very similar functions. Thereis not an approach to ‘numbering spaces’ for different types of objectsencountered in a real-world human-centred environment [VF13]. Forexample, common household products which could be managed auto-matically (such as food) are not labelled and packaged in a standardisedway, which greatly complicates efforts to designs systems to supportthis [Pro10]. Better ability for SoSs to learn and cope with unfamiliarobjects is needed.

Relevant products Devices and systems to be integrated typicallyinvolve heterogeneous types, with different domains, functions, datatypes, and underlying concepts [VF13] (e.g. some CSs deliver environ-mental sensing, some decision making, and some for interacting withusers [Pro10]) so an ability to integrate heterogeneous models is help-ful. Architectures and designs for heterogeneous CSs and intercon-nected and wireless devices need further development [RR09, VF13].Frameworks for standardised interactions and conceptual models are

75


needed. For example, there is a lack of domain models, open archi-tectures and standardised systems for sensing data [Pro10]. We wouldsuggest that this would form one domain that should be subjected tothe development of semantics, frameworks and ontologies.

• Tools for ensuring security is preserved in in SoSs which em-ploy wirelessly-connected CPS CSs around the home. Securitycan be an issue for wirelessly connected devices (this is discussed inmany places e.g. [RR09, VF13, Ayo07]). Users must have confidencethat personal data is not being collected for nefarious purposes. How-ever, balanced with this the SoS must be collecting enough data that itcan fulfil its purpose, and for some SoSs (e.g., providing health monitor-ing in the home) this may mean communicating sensitive informationto an outside agency.

Relevant products There is a lack of guidance on privacy and secu-rity [Pro10]. Development of appropriate frameworks and ontologiesare a good start in this direction. Appropriate architectural patternsfor secure, wirelessly-connected components are needed. Standards forverifying a ”secured” CS, supported by verification tools, would help,as would standards regarding appropriate architectural choices and in-tegration techniques. Developers need to be able to reason explicitlyabout management of secured data, and ensure that neither data it-self, not metadata describing it is not revealed through communicationsbetween wirelessly connected CSs. Guidelines on the verification of se-curity (as an example of a non-functional property) are needed, seman-tics for capturing and reasoning about it, and theories on controllingthe propagation of secure data in a wirelessly-connected SoS. WirelessCPS devices incorporated into an SoS may include low-powered devices,which were not designed to meet modern network security standards,are difficult to patch, and not equipped with resources (e.g., memory,computing power) capable of supporting standard network protectionssuch as firewalls [Ste14]. Attacks on these devices may include not onlyattempts to reveal data, but also denial-of-service attacks, in which re-peated messages quickly wear down the battery on low-powered devicesand remove it from the SoS [Ste14]. Future work in this area should in-clude reserach into performance optimisation issues and heterogeneoussimulations capable of modelling such attacks, their effects and possibledefenses at the SoS level.

• Produce an SoS which is sensitive to important signals, buttolerant of poor quality or ‘noisy’ data. Fault tolerance and

76


resilience are important for SoSs. The procedures to be adopted whensomething goes wrong (e.g., whether a call will be placed to a healthcareworker or police station if an intruder is detected) must be clear [Pro10].Data from small and/or inexpensive sensors in a real-world environmentis typically ‘noisy’, or even unreliable - an SoS must be capable ofidentifying and dealing with unreliable data [VF13].

Relevant products Future work for modelling faults is helpful here.This is particularly needed for future analysis of input data gatheredfrom a wide variety of sources. Sensor fusion is a technique currentlyemployed to improve the quality of decisions made as a result of poten-tially unreliable input data; data from heterogeneous sources and/ormodels can also be integrated. Stochastic modelling is also needed, forconsidering system reactions under varied conditions.

• Systems must adapt easily to changes. Systems must adapt easilyto changes, e.g., a system for monitoring an elderly person’s health mustbe able to adapt to the changes in their condition [Pro10], or even otherchanges [Pro10] such as a person moving around their home and gardenor going temporarily outside the home environment.

Relevant products Dynamic configuration is typically needed in thisdomain. Advice on appropriate architectural approaches is needed.We typically expect that dynamic reconfiguration would involve somemonitoring activity, for detecting when changes may be called for. Inthis case, the SoS must have the capability to monitor the resident intheir environment. Ontologies and frameworks are needed to expressa range of appropriate concepts, to which the SoS should be able torespond. These will need to be considered in advance; architecturalapproaches can be helpful here, for cross-organisational collaboratorswho are developing an integrated solution that depends on differentcollections of CPS devices networked around the home. Architecturalmodels will allow developers to jointly agree unambiguously on theappropriate behaviours for the SoS in given situations.

• Tools and techniques to aid with power management and en-ergy consumption. These can be issues [VF13], particularly for de-vices (e.g., smoke detectors, worn health monitoring devices) whichwould need to be charged regularly, and which must not be too heavyif worn. Methods for harvesting energy effectively are needed, and/orlow-powered devices [RR09].

Relevant products This is a problem that occupies cross-disciplinary

77


design teams, and so techniques that support cross-disciplinary, col-laborative designs would be helpful here. For example, design spaceexploration exercises for CPS-oriented SoSs could (and should) includeexploration of various design options on power consumption issues,which we treat as a specific example of a performance optimisationproblem. Frameworks, ontologies and appropriate semantics are neededthat could help to support reasoning about this aspect of the SoS andthe important concepts. There are some systems-level techniques thatcould be considered at the design stage which might help to reducepower consumption or data transmissions, which is to employ processmobility. There’s a possibility that a mobile process moving from CSto CS around the network could reduce some demands on CSs by usinglocal data connections, reducing large transmissions over the network,and freeing up resources on each of the CSs.

• SoSs that can ‘learn’ the normal gait and/or behaviour ofa user could be helpful for assisted living. This is useful foridentifying cases where the user is not moving around in their usualmanner [Pro10]. Some home SoSs rely heavily on complex analysis,probabilistic reasoning and pervasive computing [Pro10, VF13] (e.g.,health monitoring SoSs, or SoSs that track user’s movements).

Relevant products Advanced pattern recognition is needed for SoSsthat monitor and protect users in their own home; it’s clearly not rea-sonable or realistic to expect users to adapt their behaviour to suitthe SoS in their home environment, and so the SoS must be capableof adapting to very wide variety of behaviours as ‘normal’ and alsoidentify unusual behaviour correctly. We wish to have a high degree ofconfidence in the SoS’s autonomous decision-making skills in this re-spect. Data from very heterogeneous sensors may be required, meaningthat the points about integrating heterogeneous modelling paradigmsapply here.

• Support highly distributed processes and processing. Both pro-cesses and processing in an automated home SoS may be highly dis-tributed [VF13].

Relevant products There are some siginificant challenges imposedby this situation. For example, we have already discussed how securityand power consumption may be affected by a highly distributed system.Other non-functional properties may be affected also. Frameworks, on-tologies and semantics can be used to capture key concepts, reasonabout them, and ultimately to begin verifying non-functional aspects

78


of the highly distributed system. A particular problem for distributedCPS-oriented SoSs like a home automation SoS is the problem of syn-chronising the events and behaviour of the the devices. This is partic-ularly important for devices that interact with the user’s environmentin some safety-critical way - e.g., devices for controlling temperatureof hot water or switching off kitchen devices if it is detected the userhas forgotten about them - because these functions can become safety-critical. Semantics and frameworks are needed for reasoning about thereal-time requirements in distributed system like this, and techniquesand analysis tools capable of verifying the real-time behaviour of thesystem are needed. This is important because a key requirement forsafety-critical features is that when a decision is made by a controllerthat (for example) the hob must be switched off immediately, the hobactuator reacts within some specified maximum time. Distributed con-trol is a big challenge in this area; a theory of distributed control isneeded, alongside appropriate frameworks and ontologies, to begin toreason about this. Unexpected emergent behaviour can arise whencontrol decisions are distributed; techniques for verifying the absenceof unexpected emergence are also needed.

79


7 Transport

In this section we consider opportunities for modelling and simulation tech-niques for SoS within the domain of transport.


Transport is a domain capable of delivering substantial economic benefits(e.g., by reducing the time and costs of transporting goods and people),and also environmental benefits (through reducing fuel usage, as well as airand noise pollution) [Eur10, Roa13d]. Transportation systems are typicallyin constant (slow) evolution as authorities strive to achieve these long-termgoals. The COMPASS challenge problem supplied by CIG partner Westaddresses SoS modelling challenges in the field of traffic management systems,but in discussing transportation systems here we include train, bus, tramsand other urban forms of mass transport as well as road networks.

Road networks are commonly partitioned along geographical lines into sep-arate Traffic Management Systems (TMSs), with each separate TMS fallingunder the control of a local authority. Many CSs will have varying typesof roads, e.g., urban, interurban, or provincial, with different needs andgoals (e.g., improving safety is important for provincial roads, whilst maximalthroughput a priority for interurban highways, and environmental concernsaffect urban roads). Populations around Europe are increasingly mobile, withcorrespondingly large demands placed on the road network [oT08, Eur10,Con11, Tra12]. This results in congestion which causes increased costs, pol-lution and fuel. Constructing new roads (or widening existing routes) isfrequently not a feasible option due to budgetary constraints and lack ofavailable land [Tra12]. As a result, over the last few decades traffic manage-ment has evolved from a reactive process that deals with isolated problemsto a proactive system that plans ahead using a variety of ‘Integrated TrafficSolutions’ (ITS) to manage traffic loads, introduce flexibility and reduce con-gestion. The European Union has identified this as an area for investmentin the near future; for example EC Directive 2010/40/EU outlines plans fordeveloping ITS 2010-2017 [Eur10].

A sustainable vision for the future of the transportation system sees a muchgreater use of public transport (e.g., this is addressed in [Eur10]) and trav-ellers relying less on their car for all their transport needs. Reducing carusage helps to reduce the road congestion which causes inefficient travel with

80


unpredictable travel times, wasted fuel, and increases in fuel and costs for thetraveller. Achieving this vision of travellers who readily adopt multi-modaltransport relies on the wide availablity of well-integrated mass transport thatcompetes favorably with a car for convenience, time and cost. This is not afully realised goal. For example, many locations still own fragmented trans-portation sectors [Eur10], with buses, trams, roads and trains (for example)owned and operated independently. A fragmented sector like this may seelimited or no sharing of information, and operators espousing little accep-tance of interdependencies with other transport providers. Our future visionsees integrated, real-time travel information available which permits move-ment of travellers from one transportation mode to another, and ticketingand timetabling to support this. This requires substantial increase of themulti-modal information available to travellers [Con11] and an acceptanceon the part of each operator of some dependence on their peers; for exampleif a train is delayed then the connecting bus waiting to depart may need towait for it to arrive.

A report on transport in the Netherlands quotes research suggesting that upto 35% of travellers are prepared to change their schedule when presentedwith real-time information [Con11]. To encourage travellers to switch mode,news of, for example, traffic jams can be communicated to drivers upstream,along also with directions to the nearest intermodal exchange, estimates ofjourney times via different transport modes and up-to-date timetables. Thereare some initial efforts to install this type of service in many cities with‘park and ride’ schemes, that allow drivers to park and use a dedicated busservice into urban areas, although this is not usually integrated into the publictransportation network and not available to support onward journeys.

A well-documented vision for the future anticipates a widespread adoption ofin-car devices that enable direct, two-way communication between a driverand a traffic management system(e.g., see [Tra12]). This would open up newpossible services. For example, the TMS could deliver personalised, real-timewarnings of hazards or congestion ahead, or personalised recommendationsto take advantage of excess capacity on alternative roads [Tra12]. Such asystem could be integrated with public transport options, to provide traveldata described above. In-car devices can also provide up-to-date informationon current travel times. This would remove much of the need for the TMSto install dynamic message boards by the roadside, or complex distributedmonitoring systems to monitor current travel times; actual current traveltimes could be reported to the TMS by in-car devices themselves. In-car de-vices could also reduce the costs and delays in handling incidents by allowinga vehicle to summon help automatically if a collision is detected [Con11],

81


and support efficient tracing of freight movements, identifying and sharingspace capacity [Con11]. However, there are challenges to overcome: main-taining personalised two-way communications with a large number of vehiclespresents a clear scalability problems; widespread social acceptance of such asystem would require privacy and anonymity to be protected [Eur10]; andcross-border data management strategies are needed.

7.2 Market needs

Key challenges in the transportation domain include the following. For eachof the market needs listed below, we also suggest some proposed future prod-ucts that could advance the state of the art.

• Open, extensible architectures are needed. SoS architecturalstyles and patterns are not yet well understood. Open, extensible anddistributed architectures are called for in transport [Eur10, Roa13d].For example, current traffic management architectures do not scalewell and rely heavily on centralisation, with a central decision-makinghub (the Traffic Control Centre (TCC)) analysing all the region’s traf-fic and travel data, and broadcasting decisions. An architecture whichsupported negotiation between distributed devices (e.g., dynamic speedlimits) without the involvement of the TCC would reduce the complex-ity of the TCC architecture and allow for greater scalability. This mayalso allow for better management of incidents that straddle regionalor international borders, since local devices could communicate andnegotiate across the border.

Relevant products Architectural patterns should be studied and doc-umented, along with case studies that can clearly link successes orproblems with previous implementations of different patterns. Systemswhich are decentralised and highly distributed can encounter partic-ular challenges, such as: ensuring security; verifying the absence ofunexpected emergence in the presence of distributed controllers; andthe difficulty of ensuring that physically distributed devices are cor-rectly synchronised in hard real time (where necessary). We discusseda range of similar issues in Section 6 (on home automation), which arenot duplicated here.

• Security and privacy are concerns. This is particularly true whenpresenting personalised recommendations for individual vehicles or pas-sengers or collecting information about travel times based on actual

82


traveller movements [Eur10]. A particular challenge is posed by thefuture plans to incorporate large numbers of in-car devices, support-ing communications from vehicle-to-vehicle and between vehicle andinfrastructure.

Relevant products Finally, appropriate ontologies, frameworks andsemantics will be needed for capturing notions of security and privacyexplicitly. Theories for controlling the propagation of private data in ahuge SoS that supports peer-to-peer connections between in-car deviceswill be needed. We have already addressed some security and privacyconcerns in an SoS that is highly distributed and consisting of largenumbers of CPSs inter-networked, in a discussion of home automation(see Section 6).

• Manage large quantities of data about traffic movements ef-fectively. The quantity of data being generated about movementsof vehicles on the road, and the sheer number of possible communi-cations between passing vehicles and roadside devices raises questionsof scalability and synchronisation. Integrating road data with inter-modal transport data increases the system complexity further [Con11].There are also implications for security and privacy with the exchangeof data between in-car devices, or between in-car devices and the trafficmanagement infrastructure.

Relevant products Clearly performance optimisation is a key issuefor this market need. Efficient pattern recognition is needed for process-ing large quantities of data and identifying from it some useful patterns.Frameworks, ontologies and semantics are required which address therequirements of the traffic domain specifically, to reduce ambiguitiesand make it possible to reason explicitly about key optimisation crite-ria.

Some techniques that maybe applicable can help to reduce the need tocentralise and store large quantities of data. For example, mobile pro-cesses may help to alleviate the need to share data over the network.Location-aware processing can make it possible to use vehicle-to-vehicledevices to share data between themselves (e.g., warnings about icy con-ditions ahead), data which is discarded as soon as the vehicle leaves thearea. This mean that large amounts of location-specific informationare stored only as long as each vehicle is in the specific area, and notstored anywhere else on the network. This type of approach requiresdomain appropriate semantics and ontologies, so that the overall de-sired emergent behaviour (all vehicles in an icy area are informed, no

83


vehicle outside the area is carrying the information) can be verified.By ‘domain appropriate’ we mean to indicate both ‘location aware’ se-mantics, as well as ‘mobile processing’ semantics, for tackling this typeof problem.

Computation and data sharing in the cloud [Roa13d] presents a possi-ble option for managing large quantities of data. Domain-appropriateontologies and reference frameworks should be drawn up for reason-ing about appropriate concepts when verifying interactions over thecloud. Security and privacy are concerns here; reference architecturesand ontologies for reasoning about security and privacy concepts (orother non-functional SoS properties, such as availability or timelienessrequirements, which could be affected by cloud computing) should beincorporated into cloud-specific frameworks.

• More work can be done to improve safety on roads, and par-ticularly where multiple modes of transport intersect. For ex-ample, techniques for detecting and warning about slow or stationarytraffic can be improved, as can safety sensors warning buses or trucksabout cyclists in their blind spot [Con11].

Relevant products There have been many proposals for the use ofsensors in various configurations to warn of pedestrians, cyclists orother vehicles in a ‘blind spot’. This type of work firstly needs toconsider the quality of the sensors used. It typically requires light-weight, low-powered and inexpensive sets of sensors; sensor fusion maybe needed to cope with low-quality inputs. Also a busy road rep-resents a very ‘noisy’ environment with high potential for incorrectinputs and misreadings, so fault analysis verification to demonstratethat the systems producing such warnings are sufficiently fault toler-ant. These types of systems could benefit from an SoS approach toco-modelling, that allows many CSs in an SoS to co-exist in a co-modelor co-simulation.

• Dependability difficult to guarantee. An integrated transport SoSmay be composed of multiple SoSs itself (e.g., separate SoSs to providedifferent transport modes, or serve different geographical sectors), socomplexity is high.

Relevant products Appropriate techniques for tackling complexitycould include architectural approaches, which are capable of represent-ing multiple levels of abstraction and decomposition of models. Con-tractual specification encourages a highly modular approach, another

84


way to control complexity. An ability to compose models and verifysystem-level behaviour with needing to include a detailed model of eachCS could be one way to model and analyse formally with a manageablelevel of complexity.

• It should be possible to deliver a up-to-date ‘systems’ viewof a fully integrated, multi-modal transportation system. Cur-rently this systems level view is difficult to generate. Currently, thereare challenges involved in delivering a systems view of the current stateof the separate transportation systems alone. Data standards may beapplied inconsistently - e.g., updates may be collected at different inter-vals or employ different methods for map referencing [Con11], such thatdata collected around Europe is inconsistent. Data is distributed andthere is significant heterogeneity that impedes collation of informationin joint simulations and/models. Inter-modal transportation optionsare implemented by, and reliant upon data from, a varied collection ofstate-operated and privately-operated service providers [Roa13d], suchas bodies responsible for road and rail infrastructure; and bus, tramand train service operators. There are not standards in place for shar-ing data to facilitate inter-modal transport between private operators,many of whom are in direct competition and not willing to share in-ternal data. A truly inter-modal system in which travellers are alwaysinformed about the best ways to travel at the current time [Roa13d]relies on the availability of this systems view based on real-time data.

Relevant products Ontologies, reference frameworks specific to thetransportation industries are needed, as a preliminary basis to con-structing standards for exchanging current service information. Cur-rently service providers support a wide variety of ticketing and moni-toring options, such as: swipe cards and electronic contactless passespreloaded with credit; cash payments with paper tickets issued bydrivers/conductors or issued by machine; e-tickets paid for and storedon mobile phones; internet payment options coupled with identificationto be carried by passengers, etc. There is substantial heterogeneity interms of the real-time data that these options can provide, and thereare technical challenges to overcome in terms of transmitting real-timedata about current passenger loads and demands from buses, tramsand trains to generate real-time systems overview of passenger move-ments. Mobile processes may be one option to ease the load on acentral server of generating systems-levels views, and further work isneeded for appropriate architectures to support this. Frameworks canbe helpful for modelling and designing communications infrastructures

85


to support exchange of data. Contractual approaches are one-way topermit an information-hiding approach, whereby providers can revealthe information mandated by standards but keep internal data private.

Finally, dealing with the heterogeneity of data and models is a keychallenge to overcome in this sector [Roa13d]. Tools interoperability,and standardised contractual interfaces to enable this, are particularlyimportant here.

• Real time distributed control systems are needed. The intro-duction of vehicle-to-vehicle communications between in-car deviceshas the potential to deliver substantial improvements in traffic man-agement [Tra12, Roa13d]. Two types of communications would bepossible with the widespread adoption of in-car devices: vehicle-to-infrastructure (and the reverse); and vehicle-to-vehicle. As SoS whichleverages in-car devices for either (or both) types of communicationwill incorporate huge numbers of peer nodes and communications. Adecentralised architecture is required to support this, accompanied byreliable distributed control systems. The problem of distributed controlidentified as a key challenge facing the transportation sector [Roa13d].As a safety-critical function that interacts with vehicles of various types,a transportation SoS needs to deliver verifiably correct decisions whilstoperating with decentralised control. ‘Verifiably correct’ requires anal-ysis of correct behaviour as well as correct timing; an ability to reasonabout, as well as deliver, hard real-time requirements and functionalityin a widely-distributed system will be needed. It is not sufficient thatthe SoS delivers correct decisions; they must also be delivered withina time deadline. For example, if a traffic management system detectsstationary or slow-moving traffic in one lane of a high-speed trunk road,it has a requirement to warn vehicles approaching at high speed to slowdown, which will decrease the risk of collisions as vehicles moving atspeed encounter stationary vehicles ahead (this activity is called ‘queuetail detection’). The nearest traffic control centre calculates locationswhere the warnings should be displayed. However, the decision to issuewarnings to slow down is only useful if the warnings are issued quickly -a short delay in enacting the decision could render the warnings useless.

Relevant products Architectural patterns should be developed todecentralised architectures with distributed control, along with suffi-ciently well-developed case studies to document previous experience ofvarious decentralised and distributed control patterns in the past. Anarchitecture like this should also be accompanied also by theories and

86


semantics for reasoning about distributed control, so that the behaviourof the SoS under distributed control can be verified. The requirementto deliver verifiably correct decisions in hard real time requires seman-tics and ontologies for reasoning about real-time requirements [Roa13d].Decision-making in cloud services is an approach that should be consid-ered here; we have discussed the need for domain-appropriate ontologiesand frameworks for working in the cloud elsewhere in this Section.

• Dynamic negotiation supported by accurate simulations basedon real-time data. Static modelling and simulation techniques arecurrently used for analysing traffic loads for planning and negotiationpurposes. Greater use could be made of dynamic analysis. For example,in many countries owners of different TMSs and/or private transportoperators negotiate in advance the diversion routes to be used in theevent of major incidents, acceptable management strategies and thresh-olds at which they can be applied. Flexibility could be increased if TMSowners can negotiate these dynamically, perhaps to adapt to excess ca-pacity elsewhere. Improving the adaptability of the network to absorbextra traffic at peak times, react quickly to changing situations[Roa13d]and to reduce the impact of non-recurring incidents such as accidentsare key strategies goals for TMS operators to improve capacity [Tra12].

Relevant products An ability to run simulations and reason aboutthe best action to take, in real-time with up to data data, would beextremely helpful for managing stochastic events such as accidents dur-ing peak hours. We discussed a similar requirement to run simulationsusing data from varied sources in real time, to analyse a range of possi-ble options and make recommendations for the next step, for managingemergency responses (see Section 5).

87


8 Energy

In this section we consider opportunities for modelling and simulation tech-niques for SoS within the domain of energy. The COMPASS challenge prob-lem supplied by CIG partner Grid Manager addressed issues in modellingand simulation for smart grids.


There is an increased awareness in the energy sector that future solutionsneed to be cross-disciplinary and that a holistic, systems-based approachis needed. The power generation industry has previously developed as anSoS designed to transport energy generated by a few large power stationsto large numbers of smaller consumers such as homes, offices, industries andbusinesses [ASM09, FMXY11]. This model is beginning to shift, as largenumbers of small-scale producers begin to join the network (e.g., small busi-nesses and homes with small amounts of excess power from installed powerturbines or solar panels).

Congestion and load management is a problem in many regions of the world.Demand placed on the system has increased in recent decades, and is pro-jected to increase further [Fou09] due to social changes, such as increasedusage of electronic devices and significant increases in the number of single-person households [Tor12]. Sustainable approaches to heating, and a greateradoption of electric vehicles, will also result in greater reliance on electricityin the future; the European Commission target a ‘completely decarbonisedelectrity production by 2050’ [TCttEPCtCoR09, Fou09]. World demand ispredicted to increase by 45% [fSS09] 60% [BLHP09] between 2009 and 2030.Renewable sources introduce some complexity, as many renewable sources ofpower experience fluctations [Roa13b] (e.g., due to high winds in an an areawith dense wind farms). Most grids experience times of surplus power whichhas to be consumed; some European countries have even used negative pricingas an incentive to help manage surpluses. Demand Side Management (DSM)strategies like this represent one approach to help manage loads [Tor12].DSM involves influencing consumer demand to suit the grid’s supply, sothat peaks and troughs in demand can be smoothed. Typical DSM strate-gies include: major energy consumers (e.g., industrial plants and furnaces)agreeing to participate in grid-designated down-periods;and reduced pricingmodels for consuming power at off-peak times and premiums applied duringpeak periods, for either/both residential and commercial properties.

88


One vision for the future is a ‘smart grid’ [FMXY11] which is flexible, re-silient and can cope with many small and large scale producers as well aswith variations in demand, and which can link consumers and suppliers overlarge distances. ‘Plans for a “smart grid” envision a system that seeks outand overcomes reliability issues by digitally connecting energy consumersand producers and automating many of the grid functions that are currentlymanually operated’ [fSS09]. Smart grids rely on a bi-directional flow of in-formation and/or energy, and may apply intelligent strategies to ensure anyor all of: improved grid reliability; improved control; or improved infras-tructure for generation, transmission, metering and consumption [FMXY11].In contrast traditional grids are unidirectional. Smart grids may be imple-mented by combining one or several techologies: smart metering which sup-port two-communication [Roa13b] between a node and the central system;smart monitoring for assessing grid status; and phasor measurement units toensure reliable power transmission [FMXY11].

A smart grid is typically seen as a small scale solution. An alternativesolution to manage congestion and demand/supply disparity is to createmuch larger grids which are capable of delivering surplus from one areaover very large distances, allowing the large area to absorb differences indemand hour-by-hour and smooth the differences in demand over the wholegrid [BLHP09, Roa13b]. A proposed European ‘super’ grid could connectEuropean and North African countries in a large scale grid that could relievelocalised congestion by supplying power over large distances, between re-gions with different peak times [BLHP09, Tor12]. The European energy SoSis currently divided into five interlinked (via subsea cables) but separately-managed grids: British; Nordic; Baltic; Irish; and continental Europe [Pri10].Each grid may be further partitioned into national areas of control. Conges-tion is a significant problem at many borders [Pri10] where interconnectioncapacities are limited [Fou09]. A more closely integrated grid across Europewould allow excess supply (e.g., by localised high winds) to be distributedmore effectively.

Climate change will present significant challenges to be dealt with by thepower generation industry [ABM08, fSS09, Pri10]. The industry must facethe multiple challenges of reducing emissions to meet politically agreed tar-gets and reducing the risk of environmental harm [TCttEPCtCoR09], whilstmanaging a long-term migration away from limited carbon-based sourcestowards renewable generation techniques [fSS09], and finally also buildingresilience into the system to cope with projected environmental effects ofclimate change.

89


8.2 Market needs

Key challenges in the transportation domain include the following. For eachof the market needs listed below, we also suggest some proposed future prod-ucts that could advance the state of the art.

• Methods are need to ensure load management, reliability, se-curity and stability of smart grids. Load management is an in-creasing challenge, particularly when energy production methods arediversified and renewables (which deliver fluctating power [BLHP09,TCttEPCtCoR09]) are increasingly exploited [ASM09]. DSM policiesare currently not exploited as much as they could be. Deploying apan-European smart grid (SG) brings scalability problems: ‘a deployedlarge-scale commercial SG may have tens of millions of nodes. So farwe have little experience in large-scale distributed control approachesto addressing the complex power system component interactions, andlarge-scale deployment of new technologies’ [FMXY11]. Data mod-elling is important for smart grid implementations: large quantities ofdata can be produced, and a standardised data representation must beunderstood by both participants in a two-way data exchange. Modelsmust ensure backward compatibility without comprising future evolu-tion [FMXY11]. Methods are need to ensure load management, relia-bility, security and stability of smart grids utilising two-way meters anddecentralised generation and distribution. Grid infrastructures must becapable of coping with diversified supply chains. The topology of thecurrent European grids is predicated on a few large producers supplyinglarge numbers of mostly small consumers. New, sustainable techniquesfor generating power do not always conform to this model [ASM09].For example wind or solar power typically involves larger numbers ofdistributed, smaller generators. Grid infrastructures must be capableof coping with supply chains where many participants may be eitherconsumers or producers and a bi-directional flow is needed. There arefew metrics and standards for describing and comparing disparate en-ergy sources and integrating them [ASM09].

Relevant products Energy-sector frameworks and ontologies can sup-port modelling in this area in a formal way. The energy sector, like anyspecialist domain, has its own non-functional constraints and prop-erties (e.g., maintaining supplies between some maximum and min-imum thresholds); being able to capture and express these formallywill facilitate modelling and simulation attempts. An ability to verify

90


the non-functional properties across the SoS would be helpful, as longas appropriate non-functional properties are captured. SoS modellingtools will need an ability to reason about real-time concepts in order tosupport verification and formal analysis in this domain. Tools whichare capable of simulations representing accurate behaviours of manyheterogeneous CSs would be helpful, allowing suppliers to execute sim-ulations with the same energy supply parameters and a wide varietyof different demands and/or load management decisions. Integratingstochastic models into formal models would allow verification of thedesired non-functional properties of the SoS, alongside non-repeatingevents (such as a storm or damage to infrastructure) with different im-pacts, so that the SoS non-functional properties can be verified up toand incuding some event with a given level of severity.

• It should be possible to develop a systems view in real time ofcurrent demands, supplies, pricing models and DSM in effect.Models for planning and understanding the implications for the widerregion for decision-making and cost-benefit analysis are needed [Fou09].Currently it is difficult to develop a real-time systems view, or to un-derstand the impact of pricing models. An ability to implement areal-time view would enable pricing models to adapt dynamically tomeet demand [Roa13b]. Widespread adoption of smart meters will fa-cilitate this, as pricing models dyanmically updated and communicatedto smart meters would allow consumers to respond better to changes inpricing. An anticipated increase in the use of sensors within infrastruc-tures [Roa13b] will mean more information can be made available toplanners and decision makers. Models and simulation tools that inte-grate stochastic reasoning would enable planners and decision makersto execute simulations with a variety of parameters, to make predic-tions based on data supplied in real time, to achieve better and morefinely-grained ability to manage demand through adjustments to pric-ing.

Relevant products. We have discussed the products needed for cre-ating a systems view of an SoS, integrating real-time heterogeneousdata, in Section 7), on a discussion about transportation SoSs, whichwe will not duplicate here.

• Grids must be resilient to faults and disruptions. This includesunpredictable events such as storms or floods that threaten infrastruc-ture, with redundancy built efficiently into the system.

Relevant products Fault modelling approaches include architectural

91


approaches. Current archiectural frameworks for modelling faults adopta generic, systems-level view, but domain-specific models of infrastruc-ture may be needed. These could be made available with appropriateenergy-sector ontologies, semantics and frameworks as semi-completedtemplates, since the very many operators within the sector will havesimilar requirements for fault tolerance and resilience, with similar con-straints and requirements for redundancy in the architecture. Stochas-tic models integrated into the verification and analysis tools will allowunusual events to be simulated and analysed.

92


9 Contribution of this Roadmap

In this section we characterise the position of this roadmap in relation to otherroadmapping efforts produced by European research projects. We considera selection of recent and contemporary research projects which concentrateon the SoS and CPS fields:

• DANSE

• T-AREA-SOS

• ROAD2SoS

• CPSoS

• CyPhERS

9.1 DANSE

DANSE32 (Designing for Adaptability and evolutioN in Systems of systemsEngineering) focuses on the development of methodologies and tools to sup-port evolving SoSs, using a formal semantics and a contractual approach formodelling SoSs, CSs and emergent behaviour. DANSE has produced a num-ber of outputs so far, including deliverables detailing the project’s approachto architectural principles of SoS design, the DANSE methodology and toolinteroperability model, and specifications of the project’s Goal and ContractSpecification Languague (GCSL). Our survey of the current state of the artfor each of the research directions identified in Section 4.2 reflects DANSEcontributions.

DANSE and COMPASS both espouse a contractual approach to modellingof SoSs, and support a common semantic framework to support tool interop-erability. As such, the two projects address broadly similar challenges.

9.2 T-AREA-SOS

T-AREA-SOS33 (Trans-Atlantic Research and Education Agenda on Sys-tems of Systems) concentrates on improving European competitiveness andsocietal impact of SoS, through development of a EU-US research agenda.

32http://www.danse-ip.eu/home/33https://www.tareasos.eu/

93

http://www.danse-ip.eu/home/

https://www.tareasos.eu/


The T-AREA-SOS project has developed a research agenda [TAS12] thatidentifies global drivers motivating developments in SoS engineering and acollaborative trans-Atlantic research agenda. These drivers include socio-technical factors such as: predicted propulation changes placing pressureson infrastructures; issues in food security and traceability; energy security;sustainability and climate change and resultant impact on industries suchas agriculture. We have drawn on these drivers to identify key domains forfurther roadmapping detail in Sections 5-6.

Based on these drivers, the T-AREA-SoS project outputs include a high levelSoS research agenda [TAS12] that identifies some research themes, listed be-low. These research themes broadly follow the major challenges and researchdirections presented in the COMPASS roadmap. Although the scope of T-AREA-SOS’s research agenda is not limited to modelling and simulation ofSoS, the same broad challenges are still experienced in other aspects of SoSengineering. The COMPASS roadmap makes recommendations which canspecifically advance the field of modelling and simulation for SoS in eachresearch area.

• Challenges in characterising and describing SoSs, including identify-ing boundaries and goals of SoSs, establishing common terminologies,understanding contractual interactions between CSs, and governancestructures. These topics have been partially addressed over the courseof the COMPASS project; future recommendations are discussed inSection 4.2.4.

• Theoretical foundations for SoS, including developing frameworks forSoS theories and fundamental principles for SoS engineering. This re-search theme is not addressed directly by the COMPASS roadmap, butinstead is addressed by many of the COMPASS research directions.Frameworks, for example, are recommended as appropriate for futurework in many areas, including heterogeneity (see Section 4.2.1) andarchitectures (see Section 4.2.3). COMPASS recommends adoption ofa contractual approach as a general principle for SoS engineering (seeSection 4.2.4).

• Emergence, verifying emergent behaviour and limiting undesirable emer-gent behaviour. COMPASS’s detailed research recommendations forfuture directions in verification of emergent behaviour are presented inSection 4.2.4.

• Multi-level modelling, and development of methodologies for model-based SoS approach and architecting of SoSs. COMPASS adopts an

94


architectural approach for modelling, which permits composition as atechnique for handling complex and multi-level modelling. COMPASSstate of the art and approaches to architectures for SoS are discussedin Section 4.2.3.

• Measurement and metrics in SoSs, and evaluation of SoSs. In termsof modelling and simulation techniques, measurement and evalutionare important aspects for achieving performance optimisation (see Sec-tion 4.2.9)and dynamic reconfiguration (see Section 4.2.6).

• Evolution of SoS architecture. We discuss COMPASS recommenda-tions for future directions in research of SoS architectures (see Sec-tion 4.2.3), evolution (see Section 4.2.11) and dynamicity (see Sec-tion 4.2.6).

• Prototyping, and techniques for generating emergent behaviours in pro-totypes. COMPASS does not at yet address prototyping techniques.T-AREA-SOS note key challenges for prototyping, including the diffi-culty of establishing prototypes for SoSs on an appropriate scale andwith all independently CSs adequately represented, and of generat-ing and testing emergent behaviours in a prototype. To tackle thesechallenges, COMPASS advocates approaches that for identifying de-sign problems and undesirable emergent behaviours during the designstage if possible. This includes: the use of model-based techniques forsimulation, including co-simulation and co-modelling techniques(see inSection 4.2.1); contractual descriptions of CSs to enable information-hiding in cross-organisational collaborations and formal verification ofemergent behaviours (see in Section 4.2.4); and design-stage fault mod-elling at an architectural level (see in Section 4.2.5).

• Design trade-offs. We discuss model-based techniques for approachingdesign trade-offs in Section (see Section 4.2.10)

• Security. See Section 4.2.8. We treat security as a special example of ageneral requirement to improve modelling of non-functional properties(see Section 4.2.4).

• Human aspects. Modelling of human behaviours for SoS is addressedby COMPASS through the recommendation that stochastic and similartechniques are integrated with existing model-based engineering meth-ods (see Section 4.2.10) . We treat this as an example of the generalrequirement to support modelling and simulation with heterogenousmodel types(see Section 4.2.1).

95


• Energy-efficient SoSs. COMPASS recommendations suggest some ar-eas where model-based techniques can contribute towards optimisation(see Section 4.2.9). We discuss this in particular reference to processmobility (see Section 4.2.7), as an example of a specific area whereperformance gains may be achieveable.

T-AREA-SOS and COMPASS have identified some common interests in theissue of developing notions of common concepts; this work aligns with thedevelopment of the concept base in COMPASS ([COM14b]) and the the-saurus definitions for T-AREA-SOS [TAS13b]. COMPASS provided inputas members of the SoSE community for T-AREA-SOS’s thesaurus devel-opment, and representatives of T-AREA-SOS met with COMPASS staff topresent the thesaurus and its concepts in December 2012.

9.3 ROAD2SoS

ROAD2SoS34 is A support action aiming to develop strategic roadmaps inSoS engineering and their application in the industrial context. Road2SoSdoes not concentrate on modelling and simulation for SoS, but instead hasa wider view of SoS domains, their key drivers and ambitions. The projectproduced a number of roadmaps which are geared specifically to a numberof SoS domains, including:

• Multi-site manufacturing [Roa13c]

• Multi-modal traffic control [Roa13d]

• Emergency and Crisis management [Roa13a]

• Distributed energy generation and smart grids [Roa13b]

Input from visions of the future, drivers and current state of the art fromthese four domain-specific roadmaps has informed the development of rele-vant domain-specific roadmaps in this document (see Sections 5-6).

Road2SoS also produced a general report which summarised commonalitiesbetween these domains and made some recommendations [Roa13e]. Com-monalities are distilled into ‘priority themes’ [Roa13e] which are found inmultiple domains. We list these below, and indicate where to find COM-PASS recommendations on how to advance these themes specifically in thefield of modelling and simulation:

34http://road2sos-project.eu/

96

http://road2sos-project.eu/


• Ensuring channel communication speed and energy-efficient connectiv-ity. Some of the challenges raised under this topic fall outside the scopeof model-driven engineering techniques for SoS and is more directlyrelevant to specific low-level engineering disciplines. However, relatedissues are discussed in the COMPASS roadmap alongside the questionsof performance optimisation (see Section 4.2.9) and (see Section 4.2.7).

• Real-time, low latency communication. Issues in dealing with heteroge-nous systems (e.g., some requiring some notion of real time, and somenot) is discussed in Section 4.2.1. We also discuss the related field offault modelling (see Section 4.2.5).

• Interoperability among heterogenous systems. These are major topicsfor the COMPASS roadmap; heterogeneity is discussed in Section 4.2.1and problems of interoperability in tools and processes, across hetero-geneous engineering disciplines, is discussed in Section 4.2.2.

• Smart sensors and sensor fusion data. The number of sensors in useworldwide is already leading to vast quantities of data which requiresto be analysed effectively and efficiently. We discuss issues relatingto the collation and processing of sensor data in Section 4.2.1 andSection 4.2.9, including problems of pattern recognition and analysis of‘big data’.

• Efficient handling of big data and big-data-based decision making. Wedescribed approaches to big data in Section 4.2.9, where we discussedstatistical models for pattern-recognition.

• Improved forecasting. The COMPASS roadmap has not addressed fore-casting directly.

• Autonomous decision-making. Recommendations for advancing thestate of the art in self-* systems (e.g., self-healing or self-adapative)are discussed in Section 4.2.6. ‘Context awareness’ is necessary for ap-propriate decision-making [Roa13e]; this is discussed in Sections 4.2.1(on heterogeneity) and Section 4.2.9 (on performance optimisation).There is also a need for confidence in the reliability of decisions takenin this way [Roa13e]. We discuss possible approaches to extendingmodel-based verification of SoSs in Section 4.2.4.

• Collaboration platforms and tools for coordinated planning and deci-sion making. There is a need for information to be shared across or-ganisational boundaries. COMPASS advocates a contractual approachto SoS description. This allows support for information hiding and

97


cross-organisational planning at design-time as well as at run-time. Wediscuss this in Section 4.2.4. Cross-domain and cross-organisationalcollaboration requires some standardisation, common semantic frame-works and common ontologies. COMPASS recommends the use of theUTP as a common semantic framework to aid with heterogeneity in de-sign tools (see Section 4.2.1). The development of appropriate referenceframeworks and ontologies are recommended for most of the researchdirections identified in this roadmap.

• Modelling and Simulation. This area is one sub-topic for the Road2SoSreport, which has a scope of examining general engineering of SoSs.Specific steps for modelling and simulation of SoSs are recommendedthroughout this report.

• Understanding emergence. Some progress has been made in this fieldalready. We discuss state of the art and recommendations for advance-ments in Section 4.2.4.

• Measurement and metrics. We discuss state of the art and recommen-dations for advancements in Section 4.2.9.

• Architectural patterns. Some progress has been made in this field al-ready. We discuss state of the art and recommendations for advance-ments in Section 4.2.3.

• Engineering for resilience, adaptability, and flexibility. Some progresshas been made in this field already. These areas are separated in ourroadmap into fault modelling approaches (see Section 4.2.5), dynamicreconfiguration (see Section 4.2.6) and performance optimisation (seeSection 4.2.9).

• Alleviation of concerns with pervasive IT systems by means of demon-stration. Concerns that are often expressed in connection with SoSsinclude [Roa13e] stability (e.g., how much reliance can be placed onstable service) and safety. COMPASS does not address these topicsdirectly, but recommendations are made in the field of improving ver-ification of emergence (see Section 4.2.4) and simulation techniques(see Section 4.2.1), both of which are modelling techniques designed toimprove reliability of a system by supporting advanced reasoning andanalysis of ssytem design. We address issues relevant for ‘stability’ inSection 4.2.9 and Section 4.2.5.

• Investment associated with sos and risk-benefit ratio. COMPASS doesnot address modelling and simulation in this area directly.

98


• Multiple Ownership, Governance and SoS-appropriate business models.Multiple ownership imposes a number of technical and organisationalchallenges. The contractual approach advocated by COMPASS allowsfor some verification of integrated collections of systems, even whensome are owned by third parties (see Section 4.2.4). COMPASS doesnot directly address business models.

• Education of SoS owners and users. COMPASS advocates the use of in-tuitive architectural models (e.g., implemented in SysML) for reasoningabout many aspects of SoS behaviour (e.g., security (see Section 4.2.8)and fault modelling (see Section 4.2.5). These types of models produceintuitive, graphical models that are suitable for forming the basis ofdiscussions and negotiations with users and owners of SoS. For exam-ple, we have recommended that SysML models for fault modelling canform the basis of negotiations of which CS owners will be responsiblefor implementing recovery scenarios [IRF+14].

• Human machine interfaces (HMI) for SoS interaction. The field ofhuman-computer interaction is a large one, many existing techniquescould be adapted and employed for SoS. COMPASS has not directlyaddressed the question of modelling and simulation for HMI interfaces,although clearly much could be done.

9.4 CPSoS

CPSoS35 (Cyber-Physical Systems of Systems) provides a platform for bring-ing together knowledge from the SoS and CPS communities. CPSoS is stillin the relatively early stages. However, by bringing together research outputsand researchers from CPS and SoS domains, CPSoS allows SoS researchers toconsider some new research challenges. As a forum for exchange, COMPASSresearchers have had input into CPSoS project future research directions(e.g., through participation in a collaborative workshop in September 2014),alongside other projects with different specialisms.

9.5 CyPhERS

CyPhERS36 (Cyber-Physical European Roadmap and Strategy) builds onembedded and mobile computing expertise to develop a strategic research

35http://www.cpsos.eu/36http://cyphers.eu/project/related

99

http://www.cpsos.eu/

http://cyphers.eu/project/related


agenda for CPS. CyPhERS focusses on CPS, and therefore has an overlap-ping interest with COMPASS. COMPASS has had input into the CyPhERSresearch agenda (e.g., through participation in a collaborative workshopin September 2014). CyPhERS has produced outputs including surveysof the state of the art in CPS [CyP14b] and current methods and tech-niques [CyP14a]. Not all of this material is directly relevant to COMPASS,as it is not always directly linked to the COMPASS roadmap scope of mod-elling and simulation in SoS. However, the CyPhERS survey of the stateof the art [CyP14b], and indications of outstanding challenges in CPS, hasserved as an input for the COMPASS roadmap. We list below some researchareas considered by Cyphers [CyP14b], and indicate where to find COM-PASS recommendations for advances in these areas relevant to modellingand simulation for SoSs:

• Basic properties for CPS, including context awareness, cognitive com-putation and autonomy. These topics are generally applicable for SoSs,not only for CPSs. ‘Context awareness’ includes an awareness of envi-ronmental surroundings, particularly relevant for CPSs which typicallyinclude a range of sensors or other devices to collect information aboutthe CPS environment. This is also important for many SoSs, althoughdata may not always be collected from hardware sensors and so chal-lenges may not be exactly the same as those experienced by CPSs,which need to deal with problems such as ‘noisy’ data from input sen-sors. We address COMPASS recommendations for advancing this areain discussions on heterogeneity (see Section 4.2.1) and on performanceoptimisation (see Section 4.2.9).

• Technologies for CPS. This topic has less direct relevance for SoSs, al-though because CPSs form an important subtype of SoS, we do addresssome of the types of technical issues that CPSs need to tackle in theCOMPASS roadmap. For example, see discussions on performance op-timisation (Section 4.2.9), and tool interoperability and collaborativedevelopments (Section 4.2.2).

• Engineering processes for CPS. We do not address engineering pro-cesses directly, although we do touch upon methods for improvingcross-team collaboration in model-driven engineering in Section 4.2.2and Section 4.2.1).

• Scientific foundations for CPS. Many of the topics addressed here astopics relevant for CPS broadly mirror research directions identifiedin the COMPASS roadmap (e.g., dealing with heterogeneity (see Sec-tion 4.2.1) and contract-based design (see Section 4.2.4). Cyphers dis-

100


cusses a range of model-driven and system design approaches and tech-niques employed in CPS domains; we mention only a subset here in theCOMPASS roadmap.

CyPhERS has adopted a domain-driven approach to surveying the CPS do-main, and characterisations of various CPS domains have also influenceddomain-specific roadmaps in this document.

In general, all the SoS and CPS roadmaps serving as input for the COMPASSroadmap have broadly identified some similar key challenges, including:

• the problem of heterogeneity

• implementations of dynamic reconfiguration

• the need for frameworks and appropriate architectures

• consideration of co-modelling approaches and other cross-domain col-laborative techniques

• contractual approaches

In all of these areas, the COMPASS roadmap makes a unique contribution byproposing examples of how these high-level, general research challenges canbe advanced through specific activities in modelling and simulation relevantfor collections of autonomous and independent distributed systems.

101


10 Conclusions

In this deliverable we have presented a roadmap outlining how COMPASSparticipants view the future of modelling, simulation, verification and testingfor SoSs. This naturally incorporates some consideration of aspects of CPSs,since some types of CPSs are also conforming to the definition of SoSs, andshare the same challenges of heterogeneity, cross-discipline and cross-domainteams, collaboration across organisational boundaries, and the need for faulttolerance.

We have organised our roadmap as a selection of ‘product features’ thatwill be needed to build and design dependable SoSs in the future. We thenconnect these to a selection of enabling technologies which are needed inorder to see the product features realised in tools of the future.

The product features and enabling technologies were originally elicited in aseries of workshops held across the project, with all project partners well-represented. In this way we can argue that the original proposals were gen-erated in a ‘technology-push’ or ‘bottom-up’ approach, which centres on ex-amining the state of the art and considers how to advance it. However, theseproposals have been significantly refined by a subsequent ‘requirements-pull’effort, which has seen different domains associated with COMPASS surveyedand their modelling and simulation needs elicited and linked to the productsand technologies originally proposed. The final integrated result is presentedin this roadmap.

The domains associated with COMPASS, and discussed in this roadmap,include emergency response (see Section 5) and audio-visual SoSs (see Sec-tion 6). These domains are represented by COMPASS partners Insiel andBang & Olufsen, owners of the COMPASS emergency response case study(see [COM13e]) and the audio-visual SoS case study (see [COM14k]) re-spectively. In this roadmap we have widened the scope of each domain(e.g., to include disaster relief alongside emergency response, and automatedhomes/assisted living alongside home entertainment), in order to present amore general and abstracted view of the key domain challenges.

The final two domains represented in the roadmap are transportation andenergy. These two domain have been studied and modelled extensively onthe COMPASS project as part of the CIG-supplied ‘challenge problems’(see [COM14l]), supplied by West Consulting and GridManager respectively.

The domain-specific roadmaps for these four domains are presented in Sec-tions 5-8.

102


It’s not possible to produce a fully comprehensive list of the challenges in eachdomain and to elucidate and predict all possible modelling and simulationapproaches to all challenges, and so this roadmap necessarily concentrates onplanning future research which would ensure that COMPASS’s final resultscontinue to be built upon, with useful, usable results for real-world challengesin a variety of domains.

The end result has been presented to industrial partners and contacts (forexample, in a presentation to the COMPASS CIG group members) and theirfeedback elicited and incorporated. In particular, the major product featureswe recommend for future research are:

• Verification of emergent behaviour

• Verification of non-functional SoS properties

• Analysis and verification of security properties of an SoS (we view secu-rity as an important example of a non-functional property, with somespecial requirements)

• Analysis and verification of SoSs with process mobility

• Analysis of performance optimisation and possible design trade-offs

• Analysis of human behaviours and interactions with an SoS

• Heterogeneous cross-domain, cross-disciplinary analysis

• Tool interoperability across sectors

• Accessible and intuitive front-ends for formal verification techniques

• Analysis of stochastic events, and their effects

• Mature architectural guidelines and patterns based on experience andprevious case studies

• Analysis and verification of autonomous decisions

• Analysis and verification of dynamic reconfiguration of an SoS

103


References

[Abb06] Russ Abbott. Open at the top; open at the bottom; andcontinually (but slowly) evolving. In System of SystemsEngineering, 2006 IEEE/SMC International Conferenceon. IEEE, April 2006.

[ABM08] Kevin Anderson, Alice Bows, and Sarah Mander. Fromlong-term targets to cumulative emission pathways: Re-framing uk climate policy. Energy Policy, 36:3714–3722,2008.

[ACH+95] Rajeev Alur, Costas Courcoubetis, Nicolas Halbwachs,Thomas A. Henzinger, Pei-Hsin Ho, Xavier Nicollin, Al-fredo Olivero, Joseph Sifakis, and Sergio Yovine. Thealgorithmic analysis of hybrid systems. Theor. Comput.Sci., 138(1):3–34, 1995.

[AFPR13] Zoe Andrews, John Fitzgerald, Richard Payne, andAlexander Romanovsky. Fault Modelling for Systems ofSystems. In Proceedings of the 11th International Sym-posium on Autonomous Decentralised Systems (ISADS2013), pages 59–66, March 2013.

[AIP+14] Zoe Andrews, Claire Ingram, Richard Payne, AlexanderRomanovsky, Jon Holt, and Si Perry. Traceable Engi-neering of Fault-Tolerant SoSs. In Proceedings of theINCOSE International Symposium 2014, June 2014.

[AIS+77] C.S. Alexander, M. Ishikawa, M. Silverstein, M. Jacob-son, I. Fiksdahl-Ling, and S. Angel. A Pattern Language.Oxford University Press, 1977.

[APGR99] A. Arnold, G. Point, A. Griffault, and Antoine Rauzy.The altarica formalism for describing concurrent sys-tems. Fundamenta Informaticae, 34, 1999.

[ASM09] ASME. ASME Energy Grand Challenge Roadmap.Technical Report [Online] http://files.asme.org/

Strategy/20476.pdf [Last visited June 2014], Ameri-can Society of Mechanical Engineers, 2009.

104

http://files.asme.org/Strategy/20476.pdf

http://files.asme.org/Strategy/20476.pdf


[Ayo07] John Ayoade. Roadmap to solving security and privacyconcerns in rfid systems. Computer Law and SecurityReport, 23:555–561, 2007.

[Bau12] Kerstin Bauer. A New Modelling Language for Cyber-Physical Systems. PhD thesis, Kaiserslautern University,2012.

[BBC+04] Pierre Bieber, Christian Bougnol, Charles Castel, Jeanpierre Heckmann, Christophe Kehren, Sylvain Metge,Christel Seguin, P. Bieber, C. Bougnol, C. Castel,J. p. Heckmann, C. Kehren, and C. Seguin. Safetyassessment with altarica - lessons learnt based on twoaircraft system studies. In In 18th IFIP World Com-puter Congress, Topical Day on New Methods for Avion-ics Certification, page 26, 2004.

[BCG12] Manfred Broy, Maria Victoria Cengarle, and Eva Geis-berger. Cyber-Physical Systems: Imminent Challenges.In Radu Calinescu and David Garlan, editors, Large-Scale Complex IT Systems. Development, Operation andManagement, volume 7539 of Lecture Notes in ComputerScience, pages 1–28. Springer Berlin Heidelberg, 2012.

[BCS02] Pierre Bieber, Charles Castel, and Christel Seguin. Com-bination of fault tree analysis and model checking forsafety assessment of complex system. In In Proceedingsof the 4th European Dependable Computing Conference,Volume 2485 of LNCS, pages 19–31, 2002.

[BJPW99] A. Beugnard, J-M. Jzquel, N. Plouzeau, and D. Watkins.Making components contract aware. IEEE Computer,32(7):38–45, 1999.

[BLHP09] Antonella Battaglini, Johan Lilliestam, Armin Haas, andAnthony Patt. Development of supersmart grids fora more efficient utilisation of electricty from renewablesources. Energy Policy, 17:911–918, 2009.

[Bro97] Jan F. Broenink. Modelling, Simulation and Analysiswith 20-Sim. Journal A Special Issue CACSD, 38(3):22–25, 1997.

[Bro13] Manfred Broy. Engineering cyber-physical systems:Challenges and foundations. In Marc Aiguier, Yves

105


Caseau, Daniel Krob, and Antoine Rauzy, editors,Complex Systems Design & Management, pages 1–13.Springer, 2013.

[BS06] John Boardman and Brian Sauser. System of Systems– the meaning of “of”. In Proceedings of the 2006IEEE/SMC International Conference on System of Sys-tems Engineering, pages 118–123, Los Angeles, CA, April2006. IEEE.

[BS09] W.C. Baldwin and B. Sauser. Modeling the Character-istics of System of Systems. In System of Systems Engi-neering, 2009. SoSE 2009. IEEE International Confer-ence on, pages 1–6. IEEE, 2009.

[BS10] Purander Bhaduri and Ingo Stierand. A proposal forreal-time interfaces in speeds. In Design, Automationand Test in Europe (DATE’10), pages 441–446. IEEE,2010.

[BW03] Fred R. M. Barnes and Peter H. Welch. Prioritiseddynamic communicating and mobile processes. IEEProceedings—Software, 150(2):121–136, 2003.

[Com10] European Commission. Towards interoperability forEuropean public services - Communication from theCommission to the European Parliament, the Council,the European Economic and Social Committee and theCommittee of the Regions. Technical Report [Online]http://www.epractice.eu/en/library/5275072 [Lastvisited June 2014], European Commission, 2010.

[COM12] COMPASS. D21.1: Report on guidelines for sos re-quirements. Technical Report [Online] http://www.

compass-research.eu/deliverables.html [Last vis-ited June 2014], COMPASS Project, 2012.

[COM13a] COMPASS. D21.4: Report on guidelines for system inte-gration for sos. Technical Report [Online] http://www.compass-research.eu/deliverables.html [Last vis-ited June 2014], COMPASS Project, 2013.

[COM13b] COMPASS. D22.1: Initial report on sos architec-tural models. Technical Report [Online] http://www.

106

http://www.epractice.eu/en/library/5275072

http://www.compass-research.eu/deliverables.html








[COM13c] COMPASS. D22.4: Final report on combining sysmland cml. Technical Report [Online] http://www.


[COM13d] COMPASS. D41.1: Accident response case study - Ini-tial analysis using existing methods and tools. Tech-nical Report [Online] http://www.compass-research.eu/deliverables.html [Last visited June 2014], COM-PASS, 2013.

[COM13e] COMPASS. D42.1: A/V/HA Ecosystems Proto-type Using Current Methods and Tools. Techni-cal Report [Online] http://www.compass-research.

eu/deliverables.html [Last visited June 2014], COM-PASS, 2013.

[COM14a] COMPASS. D11.2: Convergence report 2. Tech-nical Report [Online] http://www.compass-research.eu/deliverables.html [Last visited June 2014], COM-PASS Project, 2014.

[COM14b] COMPASS. D11.3: Convergence report 3. Tech-nical Report [Online] http://www.compass-research.eu/deliverables.html [Last visited June 2014], COM-PASS Project, 2014.

[COM14c] COMPASS. D22.6: Final report on architecturalmodels. Technical Report [Online] http://www.


[COM14d] COMPASS. D24.2: Report on time fault tree analysis -fault modelling. Technical Report [Online] http://www.compass-research.eu/deliverables.html [Last vis-ited June 2014], COMPASS Project, 2014.

[COM14e] COMPASS. D24.3: Advanced Modelling and AnalysisTechniques for SoS. Technical Report [Online] http://www.compass-research.eu/deliverables.html [Lastvisited June 2014], COMPASS, 2014.

107




















[COM14f] COMPASS. D24.4: Report on compositional design ofcml models. Technical Report [Online] http://www.


[COM14g] COMPASS. D33.3: Static Fault Analysis Support -Technical Manual. Technical Report [Online] http://www.compass-research.eu/deliverables.html [Lastvisited September 2014], COMPASS, 2014.

[COM14h] COMPASS. D34.2: Specialised Test Strategies. Tech-nical Report [Online] http://www.compass-research.eu/deliverables.html [Last visited June 2014], COM-PASS, 2014.

[COM14i] COMPASS. D34.3: Contract Support for Evolv-ing SoS. Technical Report [Online] http://www.

compass-research.eu/deliverables.html [Last vis-ited June 2014], COMPASS, 2014.

[COM14j] COMPASS. D41.2: Accident Response Engi-neering Analysis Report using COMPASS methodsand tools. Technical Report [Online] http://www.

compass-research.eu/deliverables.html [Last vis-ited June 2014], COMPASS, 2014.

[COM14k] COMPASS. D42.1: A/V/HA Ecosystem Proto-type Using Compass Methods and Tools. Techni-cal Report [Online] http://www.compass-research.

eu/deliverables.html [Last visited June 2014], COM-PASS, 2014.

[COM14l] COMPASS. D43.3: Challenge Problem AnalysisUsing COMPASS Methods and Tools. TechnicalReport [Online] http://www.compass-research.eu/

deliverables.html [Last visited June 2014], COM-PASS, 2014.

[Con11] Connekt. Its in the netherlands. Technical Re-port [Online] http://www.connekt.nl/uploads/2011/09/its-in-the-netherlands.pdf [Last visited June2014], Ministerie van Infrastructure en Milieu, 2011.

[CyP14a] CyPhERS. Deliverable D4.1: Methods and Tech-niques. Technical Report [Online] http://cyphers.eu/

108















http://www.connekt.nl/uploads/2011/09/its-in-the-netherlands.pdf

http://www.connekt.nl/uploads/2011/09/its-in-the-netherlands.pdf

http://cyphers.eu/project/deliverables



project/deliverables [Last visited September 2014],CyPhERS project, 2014.

[CyP14b] CyPhERS. Deliverable D5.1: State of the Art. Tech-nical Report [Online] http://cyphers.eu/project/

deliverables [Last visited September 2014], CyPhERSproject, 2014.

[DAN13a] DANSE. D4.3: DANSE Methodology V.2. Technical Re-port [Online] http://www.danse-ip.eu/home/index.

php/info-material/deliverables [Last visited June2014], DANSE, 2013.

[DAN13b] DANSE. D6.3.2: Specification of the Goal andContract Specification Language. Technical Re-port [Online] http://www.danse-ip.eu/home/index.

php/info-material/deliverables [Last visited June2014], DANSE, 2013.

[DAN13c] DANSE. D8.1.3: Conceptual and Architectural Princi-ples of SoS Design and Semantic Interoperability of Sys-tems Platform and SoS Design Tool Net (3rd revision).Technical Report [Online] http://www.danse-ip.eu/

home/index.php/info-material/deliverables [Lastvisited June 2014], DANSE, 2013.

[DCC+13] Jennifer A. Davis, Matthew Clark, Darren Cofer, AaronFifarek, Jacob Hinchman, Jonathon Hoffman, Brian Hul-bert, Steven P. Miller, and Lucas Wagner. Study on thebarriers to the industrial adoption of formal methods.In Charles Pecheur and Miachael Dierkes, editors, Pro-ceedings of the 18th International Workshop on FormalMethods for Industrial Critical Systems (FMICS), vol-ume 8187 of Lecture Notes in Computer Science, pages63–77. Springer, 2013.

[DES12] DESTECS. D3.3a: Design Space Exploration ToolSupport. Technical Report [Online] http://www.

destecs.org/deliverables.html [Last visited June2014], DESTECS, 2012.

[DGG+99] J. Davis, R. Galicia, M. Goel, C. Hylands, E.A. Lee,J. Liu, X. Liu, L. Muliadi, S. Neuendorffer, J. Reekie,N. Smyth, J. Tsay, and Y. Xiong. Ptolemy-II: Heteroge-

109





http://www.danse-ip.eu/home/index.php/info-material/deliverables






http://www.destecs.org/deliverables.html

http://www.destecs.org/deliverables.html


neous concurrent modeling and design in Java. Techni-cal Memorandum UCB/ERL No. M99/40, University ofCalifornia at Berkeley, July 1999.

[DPL13] Jean-Christophe Deprez, Christophe Ponsard, and Re-naud De Landtsheer. Evidence-based assistance for theadoption of formal methods in the industry. In Alexan-der Romanovsky and Martyn Thomas, editors, IndustrialDeployment of System Engineering Methods, pages 237–259. Springer, 2013.

[DSS+09] Chad R. Dougherty, Kirk Sayre, Robert Seacord, DavidSvoboda, and Kazuya Togashi. Secure Design Pat-terns. Technical Report CMU/SEI-2009-TR-010 [On-line] http://repository.cmu.edu/cgi/viewcontent.

cgi?article=1049&context=sei [Last visited Septem-ber 2014], Carnegie Mellon Software Engineering Insti-tute, 2009.

[DSVP06] Douglas Densmore, Alberto Sangiovanni-Vincentelli, andRoberto Passerone. A Platform-Based Taxonomy forESL Design. IEEE Design & Test of Computers,23(5):359–374, 2006.

[DvdHT02] E.M. Dashofy, A. van der Hoek, and R. N. Taylor. AnInfrastructure for the Rapid Development of XML-basedArchitecture Description Languages. In Proceedings ofthe 24th International Conference on Software Engineer-ing (ICSE), 2002.

[DvdHT05] E.M. Dashofy, A. van der Hoek, and R. N. Taylor. Acomprehensive approach for the development of modularsoftware architecture languages. ACM Transactions onSoftware Engineering and Methodology, 14(2), 2005.

[DVK10] P. David, V.Idasiak, and F. Kratz. Reliability study ofcomplex physical systems using sysml. Reliability Engi-neering System Safety, 95(4):431–450, 2010.

[EJL+03] J. Eker, J.W. Janneck, E.A. Lee, Jie Liu, Xiaojun Liu,J. Ludvig, S. Neuendorffer, S. Sachs, and Yuhong Xiong.Taming Heterogeneity – the Ptolemy Approach. Proc. ofthe IEEE, 91(1):127–144, January 2003.

110

http://repository.cmu.edu/cgi/viewcontent.cgi?article=1049&context=sei

http://repository.cmu.edu/cgi/viewcontent.cgi?article=1049&context=sei


[EM08] G. Edwards and N. Medvidovic. A Methodology andFramework for Creating Domain-Specific DevelopmentInfrastructures. In Proceedings of the 23rd IEEE/ACMInternational Conference on Automated Software Engi-neering (ASE), pages 168–177, 2008.

[Eng14] Sebastian Engell. Cyber-physical systems of systems:Definition and core research and innovation areas.Technical Report [Online] http://www.cpsos.eu/

wp-content/uploads/2014/08/Cyber-physical-SoS_

Definitions_first-cluster-meeting.pdf [Lastvisited June 2014], CPSoS, 2014.

[Eur10] European Parliament and Council of the EuropeanUnion. Directive 2010/40/EU, 2010.

[FE98] Peter Fritzson and Vadim Engelson. Modelica - A Uni-fied Object-Oriented Language for System Modelling andSimulation. In ECCOP ’98: Proceedings of the 12thEuropean Conference on Object-Oriented Programming,pages 67–90. Springer-Verlag, 1998.

[Fis06] David A. Fisher. An Emergent Perspective on In-teroperation in Systems of Systems. Technical Report:CMU/SEI-2006-TR-003. Technical report, Software En-gineering Institute, Carnegie Mellon University, Pitts-burgh, PA, March 2006.

[fLCO] Open Services for Lifecycle Collaboration (OSLC).Oslc primer: Learning the concepts of oslc. TechnicalReport [Online] http://open-services.net/uploads/resources/OSLC_Primer_-_Learning_the_concepts_

of_OSLC.pdf [Last visited August 2014], OSLC.

[FLV14] John Fitzgerald, Peter Gorm Larsen, and Marcel Ver-hoef, editors. Collaborative Design for Embedded Sys-tems – Co-modelling and Co-simulation. Springer, 2014.In press.

[FMXY11] Xi Fang, Satyajayant Misra, Guoliang Xue, and DejunYang. Smart grid - the new and improved power grid:A survey. IEEE Communications Surveys and Tutorials,14(4):944–980, 2011.

111

http://www.cpsos.eu/wp-content/uploads/2014/08/Cyber-physical-SoS_Definitions_first-cluster-meeting.pdf



http://open-services.net/uploads/resources/OSLC_Primer_-_Learning_the_concepts_of_OSLC.pdf




[Fou09] European Climate Foundation. Roadmap 2050: APractical Guide to a Prosperous, Low-Carbon Europe.Technical Report [Online] http://www.roadmap2050.

eu/ [Last visited June 2014], European Climate Foun-dation, 2009.

[Fow97] M. Fowler. Analysis Patterns: Reusable Object Models.Addison-Wesley, 1997.

[FPG12] J.S. Fitzgerald, K. G. Pierce, and C. J. Gamble. A rigor-ous approach to the design of resilient cyber-physical sys-tems through co-simulation. In DSN workshops. IEEE,2012.

[fSS09] Centre for Strategic and International Studies. ARoadmap for a Secure, Low-Carbon Energy Economy:Balancing Energy Security and Climate Change. Tech-nical Report [Online] http://csis.org/files/media/csis/pubs/090204_energy_roadmap.pdf [Last visitedJune 2014], Centre for Strategic and International Stud-ies, 2009.

[Gar00] D. Garlan. Software architecture: A roadmap. In Con-ference on the Future of Software Engineering ICSE’00,pages 91–101, 2000.

[GHJV95] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. De-sign Patterns: Elements of Reusable Object OrientedSoftware. Addison-Wesley, 1995.

[GMK02] I. Georgiadis, J. Magee, and J. Kramer. Self-organisingsoftware architectures for distributed systems. In Pro-ceedings of the First Workshop on Self-Healing Systems(WOSS’02), pages 28–33, 2002.

[GRSS11] Holger Giese, Bernhard Rumpe, Bernhard Schatz, andJanos Sztipanovits. Science and engineering of cyber-physical systems (dagstuhl seminar 11441). Dagstuhl Re-ports, 1(11):1–22, 2011.

[GS94] David Garlan and Mary Shaw. An introduction to soft-ware architecture. Technical Report CMU/SEI-94-TR-21, Software Engineering Institute, Carnegie Mellon Uni-versity, 1994.

112

http://www.roadmap2050.eu/

http://www.roadmap2050.eu/

http://csis.org/files/media/csis/pubs/090204_energy_roadmap.pdf

http://csis.org/files/media/csis/pubs/090204_energy_roadmap.pdf


[Hay96] D. Hay. Data Model Patterns: Conventions of Thought.Dorset House, 1996.

[HJ98] C. A. R. Hoare and He Jifeng. Unifying Theories of Pro-gramming. Prentice Hall International Series in Com-puter Science. 1998.

[IAPP14] C. Ingram, Z. Andrews, R. Payne, and N. Plat. Sysmlfault modelling in a traffic management system of sys-tems. In Proceedings of the 9th IEEE International Sys-tems of Systems Engineering Conference (SoSE 2014),2014.

[iFE13] iFEST. D5.3: Consolidated Report on Verificationand Validation. Technical Report [Online] http://www.artemis-ifest.eu/Deliverables [Last visited August2014], iFEST, 2013.

[IPP+14] C. Ingram, R. Payne, S. Perry, J. Holt, F.O. Hansen,and L. D. Couto. Modelling patterns for systems of sys-tems architectures. In Proceedings of the InternationalSystems Conference (SysCon2014), 2014.

[IRF+14] C. Ingram, S. Riddle, J. Fitzgerald, A.H.L. Al-Lawati,and A. Alrbaiyan. Sos fault modelling at the architec-tural laevel in an emergency response case study. InWorkshop on Engineering Dependable Systems of Sys-tems (EDSoS), 2014.

[JHMW06] Anjali Joshi, Mats P. E. Heindahl, Steven P. Miller, andMike W. Whalen. Model-based safety analysis. TechnicalReport NASA/CR-2006-213953, NASA, 2006.

[JM03] Sanjay Jain and Charles McLean. A framework for mod-eling and simulation for emergency response. In Proceed-ings of the 2003 Winter Simulation Conference, 2003.

[Jon83] Cliff B. Jones. Specification and peeddesign of (parallel)programs. Information Processing, 83(9):321–332, 1983.

[KDGN97] John C. Knight, Colleen L. DeJong, Matthew S. Gib-ble, and Lus G. Nakano. Why are formal methods notused more widely? In Fourth NASA Formal MethodsWorkshop, 1997.

113

http://www.artemis-ifest.eu/Deliverables

http://www.artemis-ifest.eu/Deliverables


[Kep05] Jeffrey O. Kephart. Research challenges of autonomiccomputing. In Proceedings of the 27th International Con-ference on Software Engineering (ICSE’05), pages 15–22,2005.

[KJTF01] Roy S. Kalawsky, D. Joaanou, Y. Tuan, and A. Fayoumi.Using architecture patterns to architect and analyze sys-tems of systems. In Proceedings of the Conference onSystems Engineering Research (CSER’13), 201.

[Kop11] Hermann Kopetz. Real-Time Systems: Design Principlesfor Distributed Embedded Applications. Springer, secondedition, 2011.

[KP92] Yonit Kesten and Amir Pnueli. Timed and hybrid stat-echarts and their textual representation. In Jan Vy-topil, editor, Formal Techniques in Real-Time and Fault-Tolerant Systems, Second International Symposium, Ni-jmegen, The Netherlands, January 8–10, 1992, Proceed-ings, volume 571 of Lecture Notes in Computer Science,pages 591–620. Springer, 1992.

[LBF+10] Peter Gorm Larsen, Nick Battle, Miguel Ferreira, JohnFitzgerald, Kenneth Lausdahl, and Marcel Verhoef. TheOverture Initiative – Integrating Tools for VDM. SIG-SOFT Softw. Eng. Notes, 35(1):1–6, January 2010.

[Lee] Edward A. Lee. CPS foundations. In Proceedings of the47th Design Automation Conference, DAC ’10.

[Lee08] Edward A. Lee. Cyber physical systems: Design chal-lenges. Technical Report UCB/EECS-2008-8, EECS De-partment, University of California, Berkeley, Jan 2008.

[LLBN14] Laurens Lemaire, Jorn Lapon, Bart De Becker, and Vin-cent Naessens. A SysML Extension for Security Analysisof Industrial Control Systems. In Proceedings of the 2ndInternational Symposium for ICS and SCADA Cyber Se-curity Research, pages 1–9, 2014.

[LMFJ+04] Konrad Lorincz, David J. Malan, Thaddeus R.F.Fulford-Jones, Alan Nawoj, Anthony Clavel, VictorShnayder, Geoffrey Mainland, and Matt Walsh. Sensornetworks for emergency response: Challenges and oppor-tunities. Pervasive Computing, 3(4):16–23, 2004.

114


[LOQS07] M. Leclercq, A. E. Ozcan, V. Quema, and J. Stefani.Supporting Heterogeneous Architecture Descriptions inan Extensible Toolset. In Proceedings of the Interna-tional Conference on Software Engineering (ICSE07),pages 209–219, 2007.

[LP05] Sungjoo Lee and Yongtae Park. Customization of tech-nology roadmaps according to roadmapping purposes:Overall process and detailed modules. TechnologicalForecasting and Social Change, 72(5):567 – 583, 2005.

[LRSM11] F. Loiret, R. Rouvoy, L. Seinturier, and P. Merle.Software Engineering of Component-Based Systems-of-Systems: A Reference Fraemwork. In Proceedings ofthe 14th International ACM SIGSOFT Symposium onComponent-Based Software Engineering (CBSE-2011),June 2011.

[LZ05] Edward A. Lee and Haiyang Zheng. Operational se-mantics of hybrid systems. In Manfred Morari andLothar Thiele, editors, Hybrid Systems: Computationand Control, 8th International Workshop, HSCC 2005,Zurich, Switzerland, March 9-11, 2005, Proceedings, vol-ume 3414 of Lecture Notes in Computer Science, pages25–53. Springer, 2005.

[Mai98] Mark W. Maier. Architecting principles for systems-of-systems. Systems Engineering, 1(4):267–284, 1998.

[Man07] B.S. Manoj. Communication challenges in emergency re-sponse. Communications of the ACM - Emergency Re-sponse Information Systems: emerging trends and tech-nologies, 50(4):51–53, 2007.

[Mey92] Bertrand Meyer. Applying design by contract. IEEEComputer, 25(10):40–51, 1992.

[MKMG97] R.T. Monroe, A. Kompanek, R. Metlon, and D. Garlan.Architectural styles, design patterns and objects. IEEESoftware, 14(1):43–52, 1997.

[MMP92] Oded Maler, Zohar Manna, and Amir Pnueli. Fromtimed to hybrid systems. In J. W. de Bakker, CornelisHuizing, Willem P. de Roever, and Grzegorz Rozenberg,editors, Real-Time: Theory in Practice, REX Workshop,

115


Mook, The Netherlands, June 3–7, 1991, Proceedings,volume 600 of Lecture Notes in Computer Science, pages447–484. Springer, 1992.

[Mor98] Carroll Morgan. Programming from Specifications. Pren-tice Hall, second edition, 1998.

[MRH05] Christina Maiers, Margaret Reynolds, and MarkHaselkorn. Challenges to effective information and com-munication systems in humananitarian relief organiza-tions. In 2005 IEEE International Profession Commu-nication Conference Proceedings, 2005.

[MSE04] Pieter J. Mosterman, Janos Sztipanovits, and SebastianEngell. Computer-Automated Multiparadigm Modelingin Control Systems Technology. IEEE Trans. Contr. Sys.Techn., 12(2):223–234, 2004.

[NR07] D. J. Nightingale and D. H. Rhodes. Enterprise archi-tecting: Course notes. Technical Report MIT ESD-38J,MIT, 2007.

[oT08] US Department of Transportation. TransportationSystem Preservation: Research, Development, andImplementation Roadmap. Technical Report [On-line] http://www.csuchico.edu/cp2c/documents/

Library/nchrp_2010_roadmap_full_document.pdf

[Last visited June 2014], Federal Highway Administra-tion, 2008.

[OTH13] Robert Oates, Fran Thom, and Graham Herries.Security-Aware, Model-Based ystems Engineering withSysML. In Proceedings of the 1st International Sympo-sium for ICS and SCADA Cyber Security Research 2013,pages 78–87, 2013.

[Pet08] Irene J. Petrick. Developing and implementingroadmaps - a reference guide. Technical Re-port White Paper [Online] http://sopheon.

wpengine.netdna-cdn.com/wp-content/uploads/

WhitePaper-Petrick-RoadmappingReferenceGuide.

pdf [Last visited May 2014], Penn State, 2008.

[PF10] R. J. Payne and J. S. Fitzgerald. Evaluation of ar-chitectural frameworks supporting contract-based spec-

116

http://www.csuchico.edu/cp2c/documents/Library/nchrp_2010_roadmap_full_document.pdf

http://www.csuchico.edu/cp2c/documents/Library/nchrp_2010_roadmap_full_document.pdf

http://sopheon.wpengine.netdna-cdn.com/wp-content/uploads/WhitePaper-Petrick- RoadmappingReferenceGuide.pdf





ification. Technical Report Technical Report CS-TR-1233, School of Computing Science, Newcastle Univer-sity, 2010.

[PFP04] Robert Phaal, Clare J.P. Farrukh, and David R. Probert.Technology roadmapping - a planning framework for evo-lution and revolution. Technological Forecasting and So-cial Change, 71(1-2), 2004.

[PFP13] Robert Phaal, Clare Farrukh, and DavidR. Probert.Fast-start roadmapping workshop approaches. In Mar-tin G. Moehrle, Ralf Isenmann, and Robert Phaal, edi-tors, Technology Roadmapping for Strategy and Innova-tion, pages 91–106. Springer Berlin Heidelberg, 2013.

[PL03] Ronald M. Perry and Michael K. Lindell. Preparednessfor emergency response: Guidelines for the emergencyplanning process. Disasters, 27(4):336–350, 2003.

[Pri10] PriceWaterhouseCoopers. 100% Renewable Electric-ity: A Roadmap to 2050 for Europe and NorthAfrica. Technical Report [Online] http://www.pwc.com/sustainability [Last visited June 2014], PriceWater-houseCoopers, 2010.

[Pro10] AALIANCE Project. AALIANCE Assisted LivingRoadmap. Technical Report [Online] http://www.

aaliance2.eu/archive-files [Last visited June 2014],AALIANCE - The European Ambient Assisted LivingInnovation Platform, 2010.

[Pro12] CESAR Project. The cesar interoperability specifi-cation. Technical Report D SP1-R1.6 M4, [Online]http://www.cesarproject.eu/index.php?id=62, 2012.

[Roa13a] Road2sos3.3e. Deliverable d3.3: Roadmap for the do-main of emergency response and crisis management.Technical Report [Online] http://road2sos-project.eu/cms/front_content.php?idcat=12 [Last visitedSeptember 2014], Road2SoS project, 2013.

[Roa13b] Road2sos3.3g. Deliverable d3.3: Roadmap for the do-main of distributed energy generation and smart grids.Technical Report [Online] http://road2sos-project.

117

http://www.pwc.com/sustainability

http://www.pwc.com/sustainability

http://www.aaliance2.eu/archive-files

http://www.aaliance2.eu/archive-files

http://road2sos-project.eu/cms/front_content.php?idcat=12





eu/cms/front_content.php?idcat=12 [Last visitedSeptember 2014], Road2SoS project, 2013.

[Roa13c] Road2sos3.3m. Deliverable d3.3: Roadmap for thedomain of multi-site industrial production man-ufacturing roadmap. Technical Report [Online]http://road2sos-project.eu/cms/front_content.

php?idcat=12 [Last visited September 2014], Road2SoSproject, 2013.

[Roa13d] Road2sos3.3t. Deliverable d3.3: Roadmap for thedomain of multi-modal traffic control. TechnicalReport [Online] http://road2sos-project.eu/cms/

front_content.php?idcat=12 [Last visited September2014], Road2SoS project, 2013.

[Roa13e] Road2sos5.1. Deliverable d5.1 and d5.2: Re-port on commonalities in the four domains andrecommendations for strategic action. TechnicalReport [Online] http://road2sos-project.eu/cms/

front_content.php?idcat=12 [Last visited September2014], Road2SoS project, 2013.

[RR09] RFID Resource Network (RFID-RNET). Rfidcontribution to strategic research agenda smartsystems integration. Technical Report [On-line] http://www.rfid-rnet.com/documents/

Contribution%20to%20Strategic%20Research%

20Roadmap%20RFID-RNET%202009_V01.pdf [Last visitedJune 2014], RFID Resource Network (RFID-RNET),2009.

[RRN09] D. H. Rhodes, A. M. Ross, and D.J. Nightingale. Ar-chitecting the system of systems enterprise: Enablingconstructs and methods from the field of engineeringsystems. In In Proceedings of the 3rd Annual IEEEInternational Systems Conference (SysCon), Vancouver,Canada, March 2009. IEEE Systems Council.

[Sec14] Homeland Security. Cyber Security Evaluation Tool:Performing a Self Assessment. Technical Report [Online]https://ics-cert.us-cert.gov/sites/default/

files/DHS_CyberSecurity_CSSP-CSET-v4_0.pdf

[Last visited September 2014], Homeland Security, 2014.

118









http://www.rfid-rnet.com/documents/Contribution%20to%20Strategic%20Research%20Roadmap%20RFID-RNET%202009_V01.pdf



https://ics-cert.us-cert.gov/sites/default/files/DHS_CyberSecurity_CSSP-CSET-v4_0.pdf

https://ics-cert.us-cert.gov/sites/default/files/DHS_CyberSecurity_CSSP-CSET-v4_0.pdf


[SEH13] T. Sommestad, M. Ekstedt, and H. Holm. The cybersecurity modeling language: A tool for assessing the vul-nerability of enterprise system architectures. IEEE Syst.J., 7(3):363373, 2013.

[Sha01] Mary Shaw. The coming-of-age of software architectureresearch. In Proceedings of the 23rd International Con-ference on Software Engineering (ICSE’01), pages 656–664a, 2001.

[SPE08] SPEEDS. Speeds methodology - a white paper. Techni-cal Report SPEEDS White paper, Airbus DeutschlandGmbH, 2008.

[SPE09a] SPEEDS (Project No. 033471). SPEEDS: Component-Based Design using a Complete Virtual SystemModel. Technical report, Airbus Deutschland GmbH.[Online] http://www.speeds.eu.com/downloads/SpeedsSimpleShort.pdf, October 2009.

[SPE09b] SPEEDS (Project No. 033471). SPEEDS Lessons andBest Practices. Technical report, Airbus Deutsch-land GmbH. [Online] http://www.speeds.eu.com/

downloads/SPEEDS_Lessons_and_Best_Practices.

pdf, 2009.

[Ste14] Jean-Bernard Stefani. [presentation] a process calculusframework for dynamic component structures with shar-ing. 12th september, 2014. In Workshop on Tools andMethods for CPSoS. Towards a European Roadmap onResearch and Innovation in Engineering and Manage-ment of Cyber-Physical Systems of Systems., Bertinoro,Italy, 2014.

[TAS12] T-AREA-SoS. D3.1: Gap analysis report. TechnicalReport [Online] http://www.tareasos.eu [Last visitedJune 2014], T-AREA-SOS Project, 2012.

[TAS13a] T-AREA-SoS. D3.1: The systems of systems engineer-ing strategic research agenda. Technical Report [Online]https://www.tareasos.eu/results.php [Last visitedJune 2014], T-AREA-SOS Project )(Trans-Atlantic Re-search and Education Agenda in Systems of SystemsProject), 2013.

119

http://www.speeds.eu.com/downloads/SPEEDS_Lessons_and_Best_ Practices.pdf



http://www.tareasos.eu

https://www.tareasos.eu/results.php


[TAS13b] T-AREA-SoS. The sose thesaurus v3.0. Technical Report[Online] http://www.tareasos.eu [Last visited June2014], T-AREA-SOS Project, 2013.

[TCttEPCtCoR09] the European Economic The Commission to the Euro-pean Parliament, the Council, Social Committee, andthe Committee of Regions. Directive 2010/40/eu, 2009.

[Tor12] Jacopo Torriti. Demand side management for the euro-pean supergrid: Occupancy variances of european single-person households. Energy Policy, 44:199–206, 2012.

[Tra12] TrafficQuest. The Future of Traffic Management. Tech-nical Report [Online] http://www.traffic-quest.nl/images/stories/documents/State_of_the_Art/the_

future_of_traffic_management.pdf [Last visitedJune 2014], TrafficQuest: Centre for Expertise on TrafficManagement, 2012.

[VF13] Ovidiu Vermesan and Peter Friess. Internet of Things:Converging Technologies for Smart Environments andIntegrated Ecosystems. River Publishers, Algade 42, 9000Aalborg, 2013.

[Vla10] Kevin Vlaanderen. Technology Roadmapping - FastStart. Technical Report [Online] http://www.cs.

uu.nl/wiki/Spm/FastStart [Last visited May 2014],Utrecht University, Faculty of Science: Information andComputing Sciences, 2010.

[VNTB07] Marsha L. Vanderford, Teresa Nastoff, Jana L. Telfer,and Sandra E. Bonzon. Emergency communication chal-lenges in response to hurricane katrina: Lessons fromthe centers for disease control and prevention. Journalof Applied Communication Research, 35(1), 2007.

[Web03] Andrew R. Webb. Statistical Pattern Recognition. Wiley,2nd edition, 2003.

[Wei97] Charles Weir. Architectural styles for distribution: Us-ing macro-patterns for system design. In 1997 EuropeanPattern Languages of Programming Conference, 1997.

120

http://www.tareasos.eu

http://www.traffic-quest.nl/images/stories/documents/State_of_the_Art/the_future_of_traffic_management.pdf



http://www.cs.uu.nl/wiki/Spm/FastStart

http://www.cs.uu.nl/wiki/Spm/FastStart


[WLBF09] Jim Woodcock, Peter Gorm Larsen, Juan Bicarregui,and John Fitzgerald. Formal methods: Practice and ex-perience. ACM Computing Surveys, 41(4):1–40, 2009.

[WMD08] Johan Wittocx, Maarten Marien, and Marc Denecker.The IDP system: A model expansion system for an ex-tension of classical logic. In Marc Denecker, editor, Pro-ceedings of the 2nd Workshop on Logic and Search, Logicand Search, LaSh, Leuven, 6-7 November 2008, pages153–165. ACCO, November 2008.

[ZB13] X. Zhang and J. F. Broenink. A concurrent design ap-proach and model management support to prevent in-consistencies in multidisciplinary modelling and simula-tion. In Philippe Geril, editor, 19th European Concur-rent Engineering Conference, pages 21–28. EUROSIS,EUROSIS-ETI Publication, June 2013.

[ZC13] Frank Zeyda and Ana Cavalcanti. Higher-order UTP fora theory of methods. In Burkhart Wolff, Marie-ClaudeGaudel, and Abderrahmane Feliachi, editors, UnifyingTheories of Programming, 4th International Symposium,UTP 2012, Paris, France, 27–28 August 2012, volume7681 of Lecture Notes in Computer Science, pages 204–223. Springer, 2013.

[ZJKK14] Xi Zheng, Christine Julien, Miryung Kim, and SarfrazKhurshid. On the State of the Art in Verification andValidation in Cyber Physical Systems. Technical ReportTR-ARiSE-2014-001, The University of Texas at Austin,The Center for Advanced Research in Software Engineer-ing, 2014.

[ZSCS14] Frank Zeyda, Thiago L. V. L. Santos, Ana Cavalcanti,and Augusto Sampaio. A modular theory of object orien-tation in higher-order UTP. In Cliff B. Jones, Pekka Pih-lajasaari, and Jun Sun, editors, FM 2014: Formal Meth-ods — 19th International Symposium, Singapore, 12–16May 2014, volume 8442 of Lecture Notes in ComputerScience, pages 627–642. Springer, 2014.

121

roadmap for research in model-based sos engineering

Documents