Document No
Internal/External
Status
Version
Date
Project Title
Trans-Atlantic Research and Education Agenda
in Systems of Systems (T-AREA-SoS)
Project
Number
287593
Title
SoA Report
Work Package 2, Deliverable D2.1
Prepared by
Dr. Vishal Barot, Ms. Sharon Henson, Prof.
Michael Henshaw, Dr. Carys Siemieniuch, Dr.
Murray Sinclair, Dr. Soo Ling Lim, Prof. Mo
Jamshidi, Dr. Daniel DeLaurentis.
Approved by
This final report is approved for release outside
of the T-AREA-SoS project consortium or the
European Commission.
Summary
The report summarises key areas of importance
for Systems of Systems (SoS) research through
discussion of a series of SoS features and
aspects of SoSE which have been identified as
critical to the design and performance of SoS.
Loughborough University © 2012
TAREA-PU-WP2-R-LU-9
External
Final
2.0
4 May 2012
TAREA-PU-WP2-R-LU-9
State of the Art on Systems of Systems
Management and Engineering
Release Date: 4th May 2012
© Loughborough University 2012
Page | 1
TAREA-PU-WP2-R-LU-9
EXECUTIVE SUMMARY
This report on the State of the Art (SoA) in Systems of Systems (SoS) focuses mainly on
research in the EU and the US in the area of Manufacturing, Transport, Energy, IT, and
Defence sectors. The body of work is so vast that it is not possible to provide a
comprehensive and complete analysis, but rather to prioritise those aspects of the SoS
operations where research is urgently needed. The choice of sectors reflects an assessment
of opportunities for Europe to advance its State of the art in this area of Info-Socio-Technical
systems through high quality applied research.
The report begins with a brief introduction to the T-Area-SoS Project, SoS and SoS
Engineering (SoSE), but is then divided into two streams (Part A: State of the Art Review
and Part B: Analysis of Case Studies). The two parts are summarised below:
•
•
Part A: Review and discussion of a series of SoS features and aspects of SoSE
which have been identified as critical to the design, instantiation, and performance of
SoS.
Part B: An on-going case study approach targeting each of the exemplar industrial
sectors revealing to what extent SoSE activities, research, tools, techniques and
approaches are currently applied successfully or otherwise, and what initiatives are in
place or planned to address identified problems and issues in the development and
management of large complex SoS.
Both streams attempt to cover what is currently happening in the EU and US, mainly in
terms of research. Three appendices summarise SoS-associated research projects in the
EU and US in tabular form for reference.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 2
TAREA-PU-WP2-R-LU-9
Table of Contents
1
2
Introduction .....................................................................................7
1.1
Background to the T-AREA Project ........................................................... 7
1.2
Objectives of the Study and Scope ........................................................... 7
1.3
Report Structure.......................................................................................... 7
Introduction to System of Systems (SoS) .....................................8
2.1
Definition and Characteristics of SoS ....................................................... 8
2.1.1
2.1.2
2.1.3
2.1.4
A Manufacturing Unit ....................................................................................... 9
An Energy Supply SoS .................................................................................... 9
An Integrated Transport SoS ......................................................................... 10
A Service and People-Oriented SoS .............................................................. 11
2.2
SoS Boundary Considerations ................................................................ 11
2.3
Types of SoS ............................................................................................. 13
2.4
SoS Application Domains......................................................................... 14
2.5
Differences between Systems and Systems of Systems ...................... 14
Part A – Review and Discussions ...................................................... 17
3
4
5
6
Critical Problem Areas with SoS .................................................. 17
3.1
Safety, Security and Integrity ................................................................... 17
3.2
Emergence ................................................................................................. 19
3.3
Selected SoS Areas .................................................................................. 21
System Design for SoS ................................................................. 23
4.1
Interoperability .......................................................................................... 23
4.2
Agility ......................................................................................................... 24
4.3
Reconfigurability ....................................................................................... 25
4.4
Reuse ......................................................................................................... 26
4.5
Standards................................................................................................... 26
SoS Architectures ......................................................................... 29
5.1
The Role of SoS Architecting ................................................................... 29
5.2
Challenges in Architecting SoS ............................................................... 30
5.3
Architecture Analysis ............................................................................... 31
The Open Approach to SoS Engineering .................................... 32
6.1
UK MoD Systems of Systems Approach (SoSA) .................................... 33
Release Date: 4th May 2012
© Loughborough University 2012
Page | 3
TAREA-PU-WP2-R-LU-9
7
SoS Modelling and Simulation ..................................................... 36
7.1
Role of Modelling and Simulation............................................................ 36
7.2
Challenges of an Emerging Discipline .................................................... 36
8
SoS Network Enablement ............................................................. 38
8.1
NEC Themes .............................................................................................. 38
8.2
Impact of NEC on Systems Engineering ................................................. 39
8.2.1
8.2.2
8.2.3
8.2.4
8.2.5
8.2.6
8.2.7
8.2.8
9
SoS Architecting ............................................................................................ 41
Design Across all Defence Lines of Development .......................................... 42
Design for NEC .............................................................................................. 42
Managing Evolving Requirements.................................................................. 42
Life Cycle Models for NEC Systems .............................................................. 43
Dependability and Qualification of NEC Systems ........................................... 43
Organisational Learning Strategies ................................................................ 44
Collaboration.................................................................................................. 44
SoS Validation and Verification.................................................... 45
9.1
10
Challenges ................................................................................................. 45
Sos Qualification and Assurance .............................................. 46
10.1
11
Research Challenges............................................................................. 46
Management, Control and Operation of SoS ............................ 48
11.1
SOS Types and Hierarchy ..................................................................... 48
11.2
Control of SoS ........................................................................................ 48
11.3
Decision Making and Control Methods ................................................ 49
11.4
SOS Decision, Control and Management in ATS: Applications......... 50
12
Complex Socio-Technical Features of SoS .............................. 55
12.1
12.1.1
12.1.2
Human and Organisational Aspects of SoS ........................................ 55
Enterprise Architectures and Enterprise Architecture Frameworks................. 55
Enterprise Modelling (EM).............................................................................. 56
12.2
Socio-Technical Boundaries for SoS ................................................... 56
12.3
Organisational Systems Engineering in SoS ...................................... 57
12.3.1
12.3.2
12.3.3
12.3.4
12.3.5
12.3.6
12.4
12.4.1
Government ................................................................................................... 59
Strategic ........................................................................................................ 60
Policy ............................................................................................................. 60
Operations ..................................................................................................... 61
Transactions .................................................................................................. 63
Summary ....................................................................................................... 64
The Effects of Organisational Complexity on SoS.............................. 64
Approaches to Complexity and Resilience in SoS .......................................... 65
Release Date: 4th May 2012
© Loughborough University 2012
Page | 4
TAREA-PU-WP2-R-LU-9
12.5
12.5.1
12.5.2
12.6
13
Decision Making in SoS ........................................................................ 67
Authority, Responsibility & Autonomy ............................................................ 67
Decisions & Decision-Making at the SoS Level .............................................. 68
Legal and Ethical Implications for Societal Acceptance .................... 68
SoS Performance Measurement ................................................ 72
13.1
Concept of MoE...................................................................................... 72
13.2
Some Challenges in Measuring SoS Performance ............................. 72
14
SoS Technical and Engineering Governance ........................... 74
14.1
Background ............................................................................................ 74
14.2
Aims of Technical and Engineering Governance................................ 75
14.3
Possible Model of Technical and Engineering Governance (TEG).... 77
14.4
TEG Framework for Implementation .................................................... 78
15
Risk Mitigation in SoS ................................................................ 80
15.1
16
Risk and its Ownership ......................................................................... 80
Training ....................................................................................... 81
16.1
Training Need ......................................................................................... 81
16.2
SoSE Training Focus ............................................................................. 81
17
Current / Emerging Gaps in Critical Areas ............................... 84
Part B – Case Study Analysis ............................................................ 87
18
Case study Investigation ........................................................... 87
18.1
18.1.1
18.1.2
18.2
18.2.1
18.2.2
18.3
18.3.1
18.3.2
18.3.3
18.3.4
18.4
18.4.1
18.5
18.5.1
Defence Sector ....................................................................................... 87
Tactical Data Link .......................................................................................... 87
AMC .............................................................................................................. 88
IT Sector ................................................................................................. 88
Human Tracking ............................................................................................ 89
NPfIT ............................................................................................................. 90
Transport Sector .................................................................................... 91
AMC .............................................................................................................. 92
ATS ............................................................................................................... 93
Fleet Level ..................................................................................................... 95
SESAR .......................................................................................................... 96
Manufacturing Sector ............................................................................ 98
SCADA DCS .................................................................................................. 98
Other Sectors ....................................................................................... 100
Emergency Response (EM) ......................................................................... 100
Release Date: 4th May 2012
© Loughborough University 2012
Page | 5
TAREA-PU-WP2-R-LU-9
18.5.2
18.6
19
Water Management (WM) ............................................................................ 101
Investigation Summary ....................................................................... 102
SoS Research Priorities ........................................................... 105
19.1
19.1.1
19.2
19.2.1
19.2.2
19.3
Expert Workshop Activity ................................................................... 105
Workshop Format ........................................................................................ 105
Findings from the Expert Workshop .................................................. 106
Single Transferable Vote ............................................................................. 112
Workshop Conclusion .................................................................................. 113
Comparison of Workshop and Case Study Outcomes ..................... 113
20
Summary ................................................................................... 116
21
References ................................................................................ 119
22
Appendices……………………………………………………….….126
Release Date: 4th May 2012
© Loughborough University 2012
Page | 6
TAREA-PU-WP2-R-LU-9
1 INTRODUCTION
1.1
Background to the T-AREA Project
T-AREA-SoS is a 24-month Support Action (SA) that addresses the target outcome: to
analyse international research agenda to prepare concrete joint R&D initiatives for
international collaboration, particularly with the USA in the area of System of Systems (SoS).
The SA exploits established networks in the EU and US, and develops new ones, to explore
and evolve SoS Research and Development themes and priorities to support the EU
Commission in the formulation of research strategy in FP7 and Horizon 2020. It also seeks
to identify areas of common interest with the USA that will be the basis for future
collaboration. It is a basic premise of this T-AREA-SoS that SoS engineering includes, as a
central component, the consideration of societal needs and issues within the management of
large, socially-significant system of systems. It is also understood that SoSE is an emerging
discipline that deals with ultra large systems that include many heterogeneous systems that
may be independently owned and/or operated, distributed, evolutionary in nature and which
exhibit emergent behaviours. The outputs from this SA will be a strategic research agenda
that will create the environment for the development of concrete research initiatives through
which the EU and the US will collaborate to enhance existing research programmes and set
the scene for future programmes. These outputs will be supported by an analysis of the state
of the art and high level definition of research requirements in SoSE, and a thesaurus to
enable concepts to be shared across industrial sectors and technical disciplines.
1.2
Objectives of the Study and Scope
The objective of this State of the Art study is to analyse SoS management and SoS
Engineering research in general, but with a focus on the chosen exemplar industrial sectors
of Energy, Transport and Manufacturing in both the US and EU. The study also includes the
IT and Defence sectors which are believed to represent state of the art in terms of current
practice. This study includes those areas of SoS management and engineering in which it is
believed research is required. This report includes analysis of numerous case study
information collected by the project and incorporates inputs from an evolving expert
community that has been established by the T-AREA-SoS.
1.3
Report Structure
The report is organised into 21 chapters and an appendix section. Chapter 1 and chapter 2
provide brief description about the T-Area-SoS project, SoS and SoSE in general before
moving into the essential chapters 3 to chapter 20 (divided into 2 parts). Part A (chapter 3 to
chapter 17) reviews and discusses series of SoS features and aspects of SoSE which have
been identified as critical to the design and performance of SoS. Part B (chapter 18 to
chapter 20) analyses a series of case studies from each of the exemplar industrial sectors
(IT, Defence, Manufacturing and Transport) to identify the issues in the development and
management of large complex SoS, and summarises the results. Chapter 21 provides a list
of references for further investigation. An appendix section summarises some of the key
activities currently being addressed through numerous EU and US projects.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 7
TAREA-PU-WP2-R-LU-9
2 INTRODUCTION TO SYSTEM OF SYSTEMS (SOS)
2.1
Definition and Characteristics of SoS
System of systems engineering (SoSE) is seen by many (Keating et al, 2006) as an
emerging discipline developing ‘as an attempt to address integrating complex metasystems’.
It is also regarded as an opportunity for the systems engineering community to define the
complex systems of the 21st Century (Jamshidi 2009a, 1). While systems engineering is a
fairly established field, SoSE represents a challenge for the present systems engineers at
the global level. In general, SoSE requires considerations beyond those usually associated
with engineering to include socio-technical and sometimes socio-economic phenomena as
well as consideration of dynamic contextual variables and constraints.
There are many definitions of System(s) of Systems, some of which are dependent on the
particularity of an application area. Maier (1998) postulated five key characteristics of SoS:
• Operational independence of component systems
• Managerial independence of component systems
• Geographical distribution
• Emergent behaviour
• Evolutionary development processes
Jamshidi (2009) has reviewed more than seven potential definitions of SoS and, although
not all are universally accepted by the community, the following has received substantial
attention:
• A SoS is an integration of a finite number of constituent systems which are
independent and operable, and which are networked together for a period of time to
achieve a certain higher goal.
It should be noted that according to this definition, formation of a SoS is not necessarily a
permanent phenomenon, but rather a matter of necessity for integrating and networking
them in a central way for specific goals such as robustness, cost, efficiency, etc. DeLaurentis
(DeLaurentis, 2004) has added to the five SoS criteria above for SoS Engineering to include:
inter-disciplinarily, heterogeneity of the systems involved, and networks of systems. Not all
SoS will exhibit all of the characteristics, but it is generally assumed that a SoS is
characterised by exhibiting a majority of the Maier criteria. Although the individual systems in
a SoS are usually considered to have independent operational viability, it is sometimes the
case that the SoS must contain some systems the only purpose of which is to enable the
interoperation of the other component systems; i.e. the enabling systems cannot operate
outside of the SoS.
Combining these various contributions together, we arrive at the following definition, useful
for the rest of this document:
“A SoS is an integration of a finite number of constituent systems which are
independent and operable, and which are networked together for a period of
time to achieve a certain higher goal” (Jamshidi, 2009)
Release Date: 4th May 2012
© Loughborough University 2012
Page | 8
TAREA-PU-WP2-R-LU-9
Some examples follow, to indicate the scope of the concepts above, and to highlight some of
the interfacing issues that are endemic in SoS.
2.1.1 A Manufacturing Unit
This will usually comprise a central process to deliver a physical product. In current and
future times, this is likely to be a mechatronic device, requiring the integration of electronic
and mechanical systems. The process itself will require machines and people working
together, each one of which can be considered to be a system. In turn, each of these will
require supporting systems; in the case of machines, they will require maintenance and
process management systems, waste management systems, and power systems. Humans
will require these too, albeit of a different character. Then there are the office functions,
requiring access to money management systems, information systems and the like.
An unexpected situation that emerged in such units in the last century was the ‘best in class’
syndrome, where the owner of the manufacturing unit might purchase ‘best in class’ systems
from different suppliers to perform particular classes of manufacturing functions, and then
discover that there were difficulties in networking these systems into an SoS; each system
may be shown by the supplier to ‘conform to all relevant standards’, but they would not
interoperate. The problem was in the individual interpretations of the standards, and the
required solution was usually costly for the owner. More recently, IT – OT (operational
technology) integration has been highlighted as a key challenge associated with real time
handling of vast quantities of data (Gartner, 2011).
Croom and Bachelor (1997) have provided the insightful observation that Capabilities are not
elemental rather they are contextualised by the supply chain. In short, they are concerned
with Inter-organisational capabilities and recognise a stronger system of systems emergence
perspective for industrial capabilities that they summarise as: ‘capabilities reveal
themselves’.
2.1.2 An Energy Supply SoS
For example, consider the provision of electrical energy in some region, such as the northeastern states of the United States. A considerable proportion of this energy originates in
Canada, in huge hydroelectric stations. These will require similar classes of systems as in
the manufacturing unit example above. Then the power generated by these stations must be
transmitted to the United States through networks of transmission lines, requiring
maintenance and transmission switching stations, power management systems and costing
systems, into localised distribution networks within the US.
The history of power failures in this SoS in the last century is indicative of the unexpected
weaknesses that can exist in such systems (for instance, a power surge caused by a solar
storm, or a short circuit on a high-power transmission caused by the branch of a tree
(Kappenman and Albertson 1990; Andersson, Donalek et al. 2005; Laprie, Kanoun et al.
2007; Peerenboom and Fisher 2007). These are rare, ‘black swan’ events (Taleb 2008;
leMerle 2011), but their consequences are indeed memorable.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 9
TAREA-PU-WP2-R-LU-9
2.1.3 An Integrated Transport SoS
In 2010, the Transport Research Knowledge Centre (TRKC) consortium on behalf of the
European Commission’s Directorate-General for Mobility and Transport published a report
entitled “Towards an Integrated Transport System – Freight Focus: Research contributing to
integration and interoperability across Europe”. An extract from the executive summary
makes it clear this type of SoS also exhibits some of the characteristics referred to
previously (Figure 1 is a simplified representation of an integrated transport SoS):
“One of today’s main policy challenges for the European Union is improving the
functioning of a transport system that is still patchy. Currently, rather than a truly
European transport system, several barriers exist to the seamless movement of
passengers and goods across borders.
There are operational barriers stemming from diversity in regulations, technical
barriers from incompatible technologies, infrastructure barriers due to the
incomplete network of major cross- border links across the continent, and legal
barriers because of the lack of pertinent European legislation.
… Major issues which are of interest to both freight and passenger transport are
examined, such as the development of the Trans-European Transport Networks
(TEN-T), with the attendant European traffic management and information
systems on the networks of the various modes.
…In addition, issues specific to freight transport are addressed…
• barrier-free international road and rail transport
• the opening of these markets to competition
• the interoperability of electronic fee collection across European road networks,
which is of particular interest to Heavy Goods Vehicles (HGVs)
• logistics solutions based on harmonized communication framework conditions
• Information and Communication Technologies (ICT) platforms, which are key to
intermodality and comodality.”
Release Date: 4th May 2012
© Loughborough University 2012
Page | 10
TAREA-PU-WP2-R-LU-9
Figure 1: Representation of an Integrated Transport SoS (based on (TRKC, 2010))
2.1.4 A Service and People-Oriented SoS
For example, consider a hospital, funded by the national state. In essence, this comprises a
patient-processing system where initial triage defines the path each patient will take through
the specialties and functions that are resident in the hospital; X-ray, neurosurgery,
physiotherapy, ward management, nutrition, waste management, patient records, etc.
Unfortunately such a SoS is susceptible to many disturbances; for example, political
interference, patients whose proposed sequence of treatments must be altered, localised
disease outbreaks within the hospital such as MRSA or Legionnaire’s disease, and flow
problems such as ‘bed blocking’ (Williams 2010), where some wards become full and
patients are moved elsewhere in the hospital, occluding the usual smooth flows of patients
through the hospital SoS and occasionally getting ‘lost’ in the systems.
2.2
SoS Boundary Considerations
Where one chooses to place the boundary of a SoS is of primary importance, and influences
much of the discussion in the rest of this document. Classically, the boundary is chosen to
include the systems directly concerned in meeting the goals of the SoS, as expressed by the
relevant stakeholders. However, there is a danger that this will omit infrastructural systems
on which the primary systems depend and without which they could not function effectively;
energy, waste treatment, legal, and education systems are examples of these. Figure 2
presents a very simplified view of how some of these types of SoS can be interdependent in
society at large (Courtesy of Professor Brian Collins CB, FREng, Chief Scientific Adviser
Department for Transport (2008 - 2012), Department for Business Innovation and Skills:
Presentation entitled “Needs and Challenges for Systems Thinking (2011)).
Release Date: 4th May 2012
© Loughborough University 2012
Page | 11
TAREA-PU-WP2-R-LU-9
Often, these are taken to be givens, in stable societies; however the risks involved in this
assumption are not always considered. Recent examples include flooded IT factories in
Thailand, and the 2011 earthquake in Japan that has disrupted many supply chains. In the
words of leMerle:
"Recently, for example, Apple’s supply of lithium-ion batteries, used in iPods,
suddenly dried up. Unfortunately, as Apple quickly discovered, almost all its
suppliers purchased a critical polymer used to make the batteries from the
Kureha Corporation, a Japanese company whose operations were disrupted by
the March 11 earthquake. In fact, Kureha’s share of the global market for
polyvinylidene fluoride, which is used as a binder in lithium-ion batteries, is 70
percent. This is why analysts must also map second-order relationships (the
suppliers of the company’s suppliers). In some critical cases, even third-order
relationships should be mapped." (leMerle 2011)
In real sense, SoS boundaries are dynamic meaning it is very complex to manage risks as
organisations can be involved in multiple SoS, which may reduce the agility we might desire
for our SoS due to contractual and other managerial considerations. There is no easy
solution to the issues involved in this section. It is an area in which some research is
required, to clarify the kinds of decisions needed, and who is in a position to make which
decision under which set of circumstances, and how knowledge is to be marshalled within
the SoS to deliver an appropriate response.
Figure 2: View of Interdependence in Societal SoS
Release Date: 4th May 2012
© Loughborough University 2012
Page | 12
TAREA-PU-WP2-R-LU-9
2.3
Types of SoS
SoS can take different forms. Based on a recognized taxonomy of SoS, there are four types
of SoS (Maier 1998); (Dahmann and Baldwin 2008):
•
Directed. Directed SoS are those in which the system-of-systems is created and
managed to fulfil specific purposes and the constituent systems are subordinated to the
SoS. The component systems maintain an ability to operate independently, but their
normal operational mode is subordinated to the central managed purpose. This class of
SoS is best accomplished within a single organisation, which has the authority and
common standards and protocols to act as the foundations of the SoS.
•
Acknowledged. Acknowledged SoS have recognised objectives, a designated
manager, and resources for the SoS; however, the constituent systems retain their
independent ownership, objectives, funding, and development and sustainment
approaches. Changes in the systems are based on cooperative agreements between the
SoS and the system. This class of SoS is best suited where the component systems are
owned by different organisations, but there is a single, large, dominant organisation
among these which can, or is obliged to, take on a leadership role. Integrated project
teams, tasked with the provision of SoS to a customer, are an example of this class.
•
Collaborative. In collaborative SoS the component systems interact more or less
voluntarily to fulfil agreed upon central purposes. The central players collectively decide
how to provide or deny service, thereby providing some means of enforcing and
maintaining standards. This class of SoS is best suited to those SoS where the
component systems are ‘owned’ by different organisations, all of whom are in fairly equal
positions and there is no dominant organisation. The automotive and aviation industries
provide examples of this, where different, potentially competing companies come
together to agree standards and protocols for processes and products within the
industry.
•
Virtual. Virtual SoS lack a central management authority and a centrally agreed upon
purpose for the system-of-systems. Large-scale behaviour emerges - and may be
desirable - but this type of SoS must rely on relatively invisible mechanisms to maintain
it. The world-wide-web is often cited as an example of this.
This characterisation offers a framework for understanding SoS based on the origin of the
SoS capability objectives and the relationships among the stakeholders for both the SoS and
the systems. However, a note of caution is necessary for this classification; while the classes
are mostly well-distinguished from each other 1, in practice there are a few cases which can
be categorised as belonging wholly to one class or another; more often, and especially in the
case of SoS which have very wide-ranging boundaries, it becomes evident that different
parts of the SoS can be fitted into different parts of this classification. Such mixed-class SoS
are common in most industrial domains, leading to fairly complex organisation and
management solutions, as the examples in the previous section 2.1 have indicated.
1
Note that some practitioners have indicated difficulties in distinguishing between acknowledged and
collaborative
Release Date: 4th May 2012
© Loughborough University 2012
Page | 13
TAREA-PU-WP2-R-LU-9
2.4
SoS Application Domains
Application of SoS (as defined in the section 2.1) is broad and expanding into almost all
walks of life. Originally addressed in military applications, the defence sector has provided a
base for some initial approaches to conceiving and engineering SoS which offer intellectual
foundation, technical approaches and practical experience to this field. However, SoS is far
from limited to defence. In fact, as one looks at the world through a SoS lens it becomes
clear that SoS concepts and principles apply across other governmental, civil and
commercial domains.
These include:
• Transportation: e.g. integrated ground transportation, cargo transport, air traffic, highway
management, space systems.
• Energy: e.g. smart grid, smart houses, integrated production/consumption.
• Manufacturing: e.g. extended / federated supply chains, global distribution of design and
manufacturing facilities.
• Health Care: e.g. regional facilities management, emergency services, personal health
management.
• Natural Resource Management: e.g. global environment, regional water resources,
forestry, recreational resources.
• Disaster Response: e.g. forest fires, floods, terrorist attacks.
• Consumer Products: e.g. integrated entertainment, household product integration.
• Media: e.g. film, radio, television.
2.5
Differences between Systems and Systems of Systems
There are significant differences between large complex system (such as an aircraft) and
SoS (such as an integrated transport system). Understanding the environment in which a
system or SoS will be developed and employed is central to understanding how best to
apply existing SE principles or emerging SoSE approaches within that environment.
Observations regarding differences between individual or constituent systems and SoS are
listed in the table 1 (Dahmann and Baldwin 2008; (Neaga, Henshaw et al. 2009)). In each
case, the degree of difference varies in practice and with complexity of current systems and
system development environments – indeed many of the SoS characterisations may apply to
systems in certain circumstances.
Differences between Systems and Systems of Systems as they apply to Systems
Engineering
System
Stakeholder Involvement
Governance
Systems
Systems of Systems Engineering
Engineering
Management and Oversight
Physical
Socio-technical management and engineering
engineering
Clear set of
Multiple levels of stakeholders with mixed and
stakeholders
possibly competing interests
Aligned
Added levels of complexity due to management and
Release Date: 4th May 2012
© Loughborough University 2012
Page | 14
TAREA-PU-WP2-R-LU-9
Differences between Systems and Systems of Systems as they apply to Systems
Engineering
Systems
Systems of Systems Engineering
Engineering
management and
funding for both SoS and systems; SoS does not
funding
have control over all constituent systems
Operational Environment
Operational focus (goals) Designed and
Called upon to meet new SoS objectives using
developed to meet
systems whose objectives may or may not align
common objectives with the SoS objectives
Implementation
Acquisition/Development Aligned to
Cross multiple system lifecycles across
established
asynchronous acquisition and development efforts,
acquisition
involving legacy systems, developmental systems,
and technology insertion
and development
processes
Process
Well established
Learning and adaptation
Test and evaluation
Test and
Testing is more challenging due to systems'
evaluation of the
asynchronous life cycles and given the complexity
system is possible
of all the parts
Engineering and design considerations
Boundaries and
Focuses on
Focus on identifying systems contributing to SoS
interfaces
boundaries and
objectives and enabling flow of data, control and
interfaces
functionality across the SoS while balancing needs
of the systems. OR Focus on interactions between
systems Difficult to define system of interest
Performance and
Performance of the Performance across the SoS that satisfies SoS use
Behaviour
system to meet
capability needs while balancing needs of the
systems
performance
objectives
Metrics
Well defined (e.g.
Difficult to define, agree, and quantify
INCOSE
handbook)
Table 1: Differences between Systems and SoS as they Apply to Systems Engineering
As stated in the original T-AREA-SoS proposal (Henshaw, 2010) The difference between
systems engineering and systems of systems engineering has been pithily stated on
Wikipedia (2012):
“Whereas Systems Engineering focuses on building the system right, Systems
of Systems Engineering focuses on choosing the right system(s) and their
interactions to satisfy the requirements”
Thus, SoSE requires a different set of skills and, to a significant extent, involves different
stakeholders from traditional systems engineering. SoSE is an emerging discipline (SouzaPoza, et. al., 2008) that is being tackled through funded research activity in the US and,
more recently, in Europe.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 15
TAREA-PU-WP2-R-LU-9
However the majority of funded work in the EU quite rightly targets the design and operation
of SoS rather than targeting SoSE per se. By definition many of the current EU funded
projects are looking at a range of SoSE techniques in the following areas:
• Validation and Verification
• Simulation and Modelling
• Control
• Certification
• Control of Autonomous Systems
• Monitoring and Control
• Application of SoS architectures, etc.
But there is a gap in the development of SoSE methods and tools to form a recognizable
and required engineering discipline and the creation of tools, techniques, approaches,
methods, etc. than can be applied to a range of SoS in different domains.
The same is largely true (currently) in the US with the possible exceptions as follows:
• Purdue University - Modelling and analysis methods for design in systems of systems
context,
with
extensive
applications
to
transportation
and
capabilities
development/acquisition (funded by NASA, FAA, NSF, US Air Force) at the System-of
Systems Laboratory.
• Old Dominion University - The National Centres for Systems of Systems Engineering
(NCSoSE) is an enterprise research centre at Old Dominion University focused on
complex systems problems. The centre develops and tests theory, methods,
technologies, tools, and provides focused training to more effectively deal with complex
system problem domains. Funded by the Department of Homeland Security and US
Navy, among others (http://www.ncsose.org/)
• University of Southern California and MIT- Researchers are examining new approaches
for systems engineering and architecting in the context of system of systems problems.
This activity is funded by both defence organisations and private industry
Some further ground work is in hand e.g. the NSF program directors in the area of cyber
physical systems have expressed strong desire to identify how system of systems relates to,
compliments, and enables advancements in network of cyber physical systems.
It is perhaps worth noting that some of the traditional approaches and techniques from
Systems Science, e.g. (Bertalanffy, 1950), are relevant, though insufficient in a practical
sense, to address the challenges of SoS.
Hence the overall picture for SoSE is that of an emerging, somewhat fragmented, discipline
that still tends to borrow heavily from the more widely recognised area of Systems
Engineering. Indeed many of the basic tenets of SE hold good for SoSE such as the need
for a holistic approach understanding stakeholders and their full range of requirements, the
need for constant iteration through the design process etc. However the basic issue remains
- true SoS are not designed from scratch. Rather they are configured for a specific purpose
over a given period of time and it is this aspect that requires a new approach, the elements
of which are addressed in chapters 4 through 16 of this report.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 16
TAREA-PU-WP2-R-LU-9
PART A – REVIEW AND DISCUSSIONS
3 CRITICAL PROBLEM AREAS WITH SOS
SoS problems often exhibit many of the characteristics of so-called wicked problems (Rittel
and Webber 1973) - problems that are extremely complex and not bounded or stable; they
do not have unique, right solutions, but rather solutions that are either better or worse than
others, and they do not have a definitive formulation; SoS requirements are often volatile
with changing constraints and moving targets; stakeholders have different views; and
understanding the whole context is difficult (sometimes deliberately made so, to preserve
confidentiality, for example) and critical. SoS problems relate to both hard (mechanical,
electronic, software) and soft (people, organisations, regulatory) systems considerations and
research must nowadays include mixed methods and approaches (Conklin 2006) that
include both quantitative and qualitative techniques, making this a very challenging area
intellectually.
3.1
Safety, Security and Integrity
These three topics are inter-related, and occasionally in conflict with each other. A widelyused example of this is the ‘safety-door’ example. Imagine a building complex containing
several organisations combining on a large, complex project. Each has separate offices, but
with a common R&D area accessed by a door from each set of offices. The R&D area is
restricted to certain employees in each organisation. Given an alarm, safety considerations
indicate that the all the R&D doors should rest in an open state; security considerations
indicate they should all rest in a closed state, and integrity considerations indicate that
whatever is the best state, all R&D doors should behave the same way.
In respect of SoS, some immediate problems emerge due to the indeterminate nature of
many SoS, as is exemplified in the discussion about the definition of an SoS (Chapter 2.1),
in Boundaries (Chapter 2.2), and in Reconfigurability (Chapter 4.3).
Arguably, most security risks are to do with information, or are data-related in some way,
and this class provides the majority of risk. However, other classes of risk can be identified;
from a safety perspective, for instance, the majority of risk is physical; uncontrolled energy,
entropy, and loss of system integrity being the main classes. However, all these classes of
risk tend to occur in conjunction with socio-technical risks, where the organisation’s
structure, management, and processes, and its personnel have some role in the occurrence
of unwanted emergent behaviour. However, while there is considerable research and
discussion across the globe regarding risks, there seems to be something of a blind spot in
relation to the risks associated with SoS, mainly in the areas of poor dissemination of
knowledge and information within SoS. Two examples of this (among many) are the ‘Gimli
Glider’ (Lawson 2005), and ‘Air Alaska flight ‘261’ (NTSB 2003) in both of which interorganisational, interface and intra-system events combined to cause significant crashes. In
both cases, decisions that led to the accidents were distributed among different groups of
people in different organisations with different systems, over a time period time, none of
whom had a full complement of the knowledge and information necessary to eliminate the
path to the accidents. This issue of interorganisational knowledge sharing, both within the
Release Date: 4th May 2012
© Loughborough University 2012
Page | 17
TAREA-PU-WP2-R-LU-9
SoS and with its environment, is one which, from a safety and security perspective, needs
further investigation.
On the amelioration of risks, there is again a copious literature, largely occasioned by the
major disasters of which we are all aware; examples are: Piper Alpha (Cullen 1990), Bhopal
(Shrivastava 1987), Tenerife (CIAIC 1978), Seveso (HSE 1980), Challenger (NASA 1986),
and many more, extending into the insurance industry, standards activity, codes of practice
and government regulations. The practical effects of these can readily be seen in the
planning and operational control of processes in most responsible organisations; typically,
risks are divided into 2 classes. The first is ‘known risks’, which can be identified by
management and other professionals within the organisations and these are then met by
appropriate action by the organisation. The second class is ‘unknown risks’, which by
definition is of unknown size and scope, and no pre-planned, targeted responses are
available. Nevertheless, the collective probability of one of these risks occurring is
appreciable, and the general response of organisations and industries to this is ‘defence in
depth’. In some industries (e.g. petrochemicals, pharmaceuticals, energy) considerable effort
goes into this, in part driven by regulations (e.g. Seveso II in the European Union) and the
demands that accrue from safety case analyses and certification requirements.
‘Defence in depth’ is usually delivered by some combination of the following principles,
expressed in the systems architecture, and managed operational processes. The generally
accepted principles are:
• Uncoupling. The principle here is to separate functional parts of the system under
consideration, so that any failure in one part is not propagated to other parts in a
cascade, which have to fail because they are so closely linked to the initial failed part.
At a SoS level, this is assured, because of the characterising criteria for SoS (Maier
1998). However, the principle should extend to within-system levels as well.
• Separation/isolation. The principle is to separate systems and their parts so that a
failure of one part is not propagated. Typically, this is a physical environment issue;
for example, an explosion or fire in one process within a system should not cause
damage to other parts (a major issue in the Piper Alpha disaster). At a SoS level, this
tends to happen anyway because of the Maier criteria, but there can be long-distance
effects too; for example, the Chernobyl disaster had very deleterious effects on
farmers in Britain, who could not sell their livestock because of radioactive fall-out on
their land, and ash plume from the Eyjafjallajokull volcano in Iceland disrupted civil
aviation across Europe and beyond.
• Redundancy. Technically, this principle refers to having duplicate (triplicate…)
circuits or processes to carry out the same function. Usually the attempt is made to
ensure that each process is independent of the others, for added reliability. However,
at the SoS level, this itself can cause a problem. A characteristic of SoS is that when
they are composed of systems owned by separate organisations, the SoS
necessarily operates in a state of incomplete knowledge and information, due to
intellectual property rights, protection of competitive advantage, and respect for
confidentiality with regard to other organisations. This is exacerbated by parallel
paths, and is a known enabler of emergent behaviour (Gregg 1996).
• Socio-technical aspects. It is a fact that most accident and disaster analyses in the
literature find it possible to allocate blame to the humans involved in the path to the
Release Date: 4th May 2012
© Loughborough University 2012
Page | 18
TAREA-PU-WP2-R-LU-9
•
3.2
accident/disaster. However, as several authors have pointed out cogently (Rochlin,
LaPorte et al. 1987; Reason 1989; Reason 1998; Reason 2001; Reason 2001;
Roberts and Bea 2001; Woods and Hollnagel 2006), this is usually as a result of the
design and management of system architecture and/or operational processes, and
as the authors above discuss, humans often demonstrate heroic recoveries from
imminent disaster – more often than disasters happen. A literature has sprung up
that discusses the characteristics and design of high-reliability socio-technical
organisations that is applicable at the SoS level (Rochlin, LaPorte et al. 1987; Bigley
and Roberts 2001; Reason 2001; Weick and Sutcliffe 2001; Hollnagel, Woods et al.
2006; Leveson, Dulac et al. 2006), but further work is needed to produce codes of
practice and a more complete understanding of the constraints involved for SoS,
including the needs for self-governance and for governmental governance by
regulation.
Safety and security are frequently addressed through regulation; a theme to which
authors return in chapter 10.
Emergence
Readers who are interested in the history and development of Emergence as a concept are
directed to “Conceptual Foundations of Emergence Theory” (Clayton 2006). According to
Clayton, Emergence as a concept has been around since Aristotle, but it is generally
accepted that the English philosopher, George Henry Lewes, was the scholar whose use of
the term ‘emergence’ was responsible for the explosion of emergence theories in the early
twentieth century (see Lewes, 1875). In recent times the concept of Emergence is closely
aligned with Complexity Theory and there is much debate and disagreement about both the
nature and causes of Emergent Behaviour.
Natural emergent behaviour is found in species such as crickets (synchronisation of mating),
migrating birds (flocking), ants and other insects (working collaboratively to forage or build).
Humans themselves are said to exhibit so-called emergent behaviour e.g. slowing of traffic
before the entry to a tunnel even if there are no traffic signals to post the speed limit,
although there are other explanations provided for this behaviour.
However, as far as this report is concerned the focus of Emergence within a Systems or
System of Systems context is on any (desirable or undesirable) emergent behaviour that
cannot clearly be explained by the behaviour of individual components of a system or the
influence of some external factors. Therefore, given an SoS is made up of a configuration of
individual systems, emergent behaviour of a SoS is the behaviours that are due either to the
internal relationships among the parts of the SoS and/or as a response to its external
environment.
Because of the strong element of humans and organisations in SoS, emergent behaviour in
a SoS can result from changes in the way systems are employed by users now that they are
operating in a new or expanded context.
Consequences of any emergent behaviour may be viewed as negative/harmful,
positive/beneficial, or neutral/unimportant by stakeholders of the SoS. There is much
concern about emergent behaviour which is unexpected or cannot be predicted by
Release Date: 4th May 2012
© Loughborough University 2012
Page | 19
TAREA-PU-WP2-R-LU-9
knowledge of the system’s constituent parts. For the purposes of a SoS, unexpected means
unintentional, not purposely or consciously designed-in, not known in advance, or surprising
to the developers and users of the SoS. In a SoS context, not predictable by knowledge of
its constituent parts means the impossibility or impracticability (in time and resources) of
subjecting all possible logical threads across the myriad functions, capabilities, and data of
the systems to a comprehensive SE process.
Emergent behaviours of themselves are not a bad thing in SoS indeed many would say that
emergent behaviour which can only result from a particular configuration of systems into an
SoS is necessary for SoS performance: emergency services, disaster relief and the internet
could be seen as examples of this. Emergence can be the facilitator that enables a SoS to
overcome problems of interoperation and to achieve levels of adaptability, scalability, and
cost- effectiveness not possible in traditional systems, but unfortunately, today’s systems
engineering practitioners do not have the methods and tools they need (Hsu 2009). SoS do
not exhibit the same static hierarchies or groupings of component systems that are often
found in large systems such as aircraft and therefore functional decomposition feeding from
and to requirements generation and analysis is much more difficult. Validation and
Verification of the emerging SoS is almost impossible until the system is operational due to
the size, complexity and time limits on configuration.
Hsu (2009) suggests two key options for dealing with Emergence in SoS:
• Flexible and adaptable open system architecture – which should be modularized and
therefore easily modified to account for the newly discovered emergent behaviours.
• The integration of agent- based modelling and neural network methodology with
SysML.
However, it must be borne in mind that open system architecture is essentially a commercial
proposition, rather than a technical one, and brings with it some important commercial
challenges (Henshaw et. al., 2011b). A particular source of emergence which requires
further exploration is the intersection of intellectual property rights, the protection of
competitive edge, and respect for the confidentiality of others. In combination, it is possible
for these to guarantee that a SoS operates continually in a state of insufficient knowledge
and information. Figure 3 shows this problem.
Figure 3 also illustrates a supply chain in the ‘Fast-Moving Consumer Goods’ domain. At the
right are two competing companies, Comp A and Comp B, selling to consumers. In the
middle is a manufacturer, OEM, supplying both of these companies. There is a consultant
company advising the manufacturer and Comp A. Finally, there is a supplier of components
to the manufacturer. The text boxes illustrate some of the difficulties that may arise:
• OEM will be informed of the competitive marketing plans of Comp A and Comp B, but
must keep them from each other.
• These plans may involve changes in the supply to Comp A and Comp B; there is a
dilemma here, since this information, given to the companies, is competitive
information.
• Similarly, the consultant must be careful to keep information about the OEM and
Comp A safe and separate.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 20
TAREA-PU-WP2-R-LU-9
•
Any of the organisations in the supply chain can institute changes to their systems
without much notice, citing the needs for confidentiality and the protection of
competitive advantage.
Figure 3: Illustration of Barriers to the Communication of Useful Information and Knowledge
Consequently, there are many barriers to the proper sharing of information across the SoS.
This indicates the need for trust among the organisations, which in turn implies the need for
trustworthy behaviour by each organisation. In turn, because of the significance of trust in
organisations and their behaviour, and the difficulty of building this, there may be a tendency
always to turn to the same trusted organisations in future SoS which, from a national or
global economics perspective, may imply a creeping growth of inefficient rigidities and a loss
of competition. Research is required into the governance issues associated with this
situation.
3.3
Selected SoS Areas
The following figure 4 shows an overview of the critical areas selected for the SoA review.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 21
TAREA-PU-WP2-R-LU-9
Architectures
Open Approach to
Engineering
System Design
Modelling and Simulation
Training
Risk Mitigation
Network Enablement
Selected Critical Areas
for SoS Review
Validation and
Verification
Technical and
Engineering Governance
Performance
Measurement
Qualification and
Assurance
Socio Technical Issues
Management, Control
and Operation
Figure 4: Selected SoS Areas to be Reviewed in this State-of-the-Art Report
Please refer to the appendix sections for a summary of current EU / US projects
currently addressing critical problem areas of SoS.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 22
TAREA-PU-WP2-R-LU-9
4 SYSTEM DESIGN FOR SOS
4.1
Interoperability
Interoperability of the software components of a SoS is one of the critical challenges in any
SoS. Interoperability within a SoS implies that each system can communicate and interact
(control) with any other directly-connected system regardless of their hardware and software
characteristics or nature. This implies that each constituent member of a SoS should be able
to communicate with others without compatibility issues such as operating systems,
communication hardware, and so on. For this ideal case, a SoS needs a common language
the SoS’s software-based systems can speak. Without having a common language, these
systems cannot fully operate functionally and the SoS cannot be adaptive in the sense that
new components cannot be integrated to it without major effort. Integration also implies the
control aspects of the SoS because systems need to understand each other in order to take
commands or signals from other SoS systems (Cloutier et. al. 2009). Challenges here are to
work towards a common language for exchange of information and data among systems of a
SoS. Examples of such languages are XML (Extensible Markup Language), as one potential
environment (Jamshidi, 2009a).
However, noting the socio-technical nature of many SoS, it is clear that interoperability must
be achieved at many levels and not just at the data network level. There are a number of
frameworks that describe the levels of interoperability. From military applications, the NCOIC
(Network Centric Operations Industry Consortium) Interoperability Framework (NCOIC 2008)
covers three broad levels of interoperability, subdivided into nine more detailed levels:
• Network Transport
o Physical interoperability
o Connectivity and network interoperability
• Information Services
o Data/object model interoperability
o Sematic/information interoperability
o Knowledge/awareness of actions interoperability
• People, Processes and Applications
o Aligned procedures
o Aligned operations
o Harmonised strategy/doctrine
o Political or business objectives
This so-called spectrum of interoperability levels, from straightforward physical compatibility
through to the human compatibility in a strategic sense, requires appropriate coherence at
each level consistent with the SoS shared goals.
There exist interoperability frameworks in other fields of activity, such as business and
commercial endeavours and the European Interoperability Framework (European
Commission 2004), which focus on enabling business (particularly e-business)
interoperability and has four levels within a context:
• Political context
o Legal interoperability
o Organisational interoperability
Release Date: 4th May 2012
© Loughborough University 2012
Page | 23
TAREA-PU-WP2-R-LU-9
o
o
Semantic interoperability
Technical interoperability
The interoperability between the systems of a SoS is a fundamental design consideration for
SoS which may be managed through the application of standards.
4.2
Agility
The NECTISE 2 research programme defined agility as follows:
Agility is the ability to decide upon and enact a course of action on a timescale
appropriate to achieve a desired outcome
Similarly, a definition of agility has been offered by Alberts (Alberts 2011):
“Agility is the ability to cope successfully effect, cope with, and/or exploit
changes in circumstances.”
As he goes on to say, agility is an umbrella term, encompassing notions of responsiveness,
robustness, flexibility, resilience, adaptability, and innovativeness. A little thought on these
definitions indicates an important variable implicit in most of these terms; that of time. The
inclusion of this is essential, as is brought out in the figure 5 diagram illustrating the linkages
between flexibility, the supply chain, and the time, according to Mackley (Mackley, Barker et
al. 2007; Mackley 2008). The diagram represents the development of a simulation facility for
the UK military. Across the top are the ‘lines of development’ required for the facility to be a
success. Down the side is a timescale. The diagram illustrates that if the facility is to be
flexible (one of the components of agility), then it must be designed-in at an early stage of
the development, and this will be costly. If the flexibility required is greater than that
designed-in, then time will be required in order to provide it, by ‘reaching back’ down the
supply chain as far as necessary to generate and deliver the flexibility. If this need for
flexibility is foreseen sufficiently early, then it will be ready when required. The latter, of
course, depends on the predictability of the future, allied to the rate of change of situational
circumstances.
2
Network Enabled Capability Through Innovative Systems Engineering
Release Date: 4th May 2012
© Loughborough University 2012
Page | 24
TAREA-PU-WP2-R-LU-9
Figure 5: Diagram Illustrating the Linkages Between Flexibility, the Supply Chain, and Time,
According to Mackley (Mackley, Barker et al. 2007; Mackley 2008).
From a SoS perspective, the implication is that the organisations that own the different
systems involved in the supply chain SoS must have the capability to carry out these tasks,
must be able to maintain this capability perhaps over many years, and must maintain their
collaborative links to assure the communication of information to support these tasks. As
Heracleitus expressed it, 2,500 years ago, “You cannot stand in the same river twice”
(colloquially, ‘nothing stays the same’), and given the complexity of modern society, the
requirement to be able to deliver agility in SoS is an imperative.
4.3
Reconfigurability
Reconfiguration is one way of delivering agility, as discussed in the section above. For SoS,
it implies that the component systems are capable of being re-arranged into a new
configuration to deliver some new capability. For the purposes of this document, we include
the notion of replacing component systems as well, perhaps with upgrades to the previous
system, enhanced systems, or different systems. This reflects the possible classes of
environment in which the stakeholders expect the SoS to operate.
We borrow from the classification outlined by De Meyer, Loch & Pich to illustrate this
(deMeyer, Loch et al. 2002). They defined four classes of projects (for which we may
assume SoS are required):
• Variation (orthodox management suffices; very little change in the SoS). This is
typical of end-market SoS, where all the innovation has happened, conditions are
stable, and most effort goes into cost minimization.
• Foreseen uncertainty (it is known that a competitor SoS are going to bring out an
innovative product and our SoS will have to react to whatever it is). Agility is required,
helped best by market foresight to identify the likely innovations.
• Unforeseen uncertainty (in other words, there is no Plan B. Graphene is an example;
originally an interesting exercise in chemistry, but its discovered properties indicate it
can revolutionise many aspects of electronics). The implication is that SoS
Release Date: 4th May 2012
© Loughborough University 2012
Page | 25
TAREA-PU-WP2-R-LU-9
•
stakeholders need to be flexible orchestrators, networkers, and ambassadors. Trust
between the SoS’ organisations is critical. Organisations need to scan horizons
continuously, and sign flexible contracts.
Chaotic environments (where rapid change is the norm – in western nations, the toy
trade leading into the Christmas period, with the fads that can suddenly develop, is
an example). SoS stakeholders should concentrate on entrepreneurship and
knowledge management. Given that rapid change in the products delivered by the
SoS will be necessary, its success depends critically on having long-term
relationships beyond individual products and their supply chains, enabling
reconfiguration. SoS relationships must be based on trust and handshakes, rather
than contractual obligations, with plans lasting only to the next temporal decision
point.
Clearly, reconfigurability is a very important issue, spanning all levels of an SoS from
interconnection and interoperability through to contractual relationships. There is a need for
further cross-disciplinary research in this area, to provide guides and guidelines for
businesses and government organisations.
4.4
Reuse
Reuse involves creating new software systems from existing software rather than building
the systems from scratch (Krueger 1992). Reuse has been practised since the start of
software development. Salient ideas include systematic reuse, reuse design principles,
module interconnection languages, commonality and variability analysis, and domain
specific generators (Frakes and Kang 2005).
Although significant progress has been made on software reuse, most progress focuses on
small-scale reuse and significant problems remains when applying reuse to SoS. One
problem is related to the production of sufficient formal specification of architectures to
support automated or semi-automated construction of very large systems. Another important
issue relates to how to make best use of reusable components for SoS (Frakes and Kang
2005). For SoS, better representation mechanisms for all software assets, including means
for specification and verification, are needed before large-scale reuse can be possible. There
is also the need for support and enforcement of behavioural contract specifications for
components, such as a movement from design to interfaces to design by contract (Frakes
and Kang 2005).
A key element in the success of reuse is the ability to predict needed variability in future
assets but with SoS, prediction is challenging. For reuse to be possible, components should
be able to adapt at compile time or runtime. In this respect, research into self-adaptive
software, reconfigurable context-sensitive software and self-healing systems is needed
(Cheng, Giese et al. 2009).
4.5
Standards
There are currently no standards specifically written for SoS or SoSE products, processes,
management or other endeavours (Johnson 2009); however, there are many standards
which address aspects of interoperability such that they may be considered relevant to SoS.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 26
TAREA-PU-WP2-R-LU-9
The term ‘standard’ has a both general and specific meaning within the realm of
contemporary standards. In general, a standard represents a document produced by a
standards body, organisation, or entity. A specific standard represents either a part of a
document or the whole document that is required, recommended, or permitted to be used as
practices, processes, formats, contents, etc.
Standards are found in every arena of human endeavour. Representative examples are
found in technical specifications, methods of measurement, medical diagnostics, judicial
procedures, management processes, power distribution, building codes, information
production and categorization, food production and processing, and financial transactions. .
Clear standards usually benefit all the players in a given field or industry; however, there are
times when a standard may allow one group to compete effectively against another, even
though their product may be inferior (e.g. Matsushita VHS versus Sony Betamax) (Johnson
2008 and Fung 2008). One current example of the competition for standard supremacy in
the digital video realm is between High Definition (HD) and Blue-ray. Currently, there are no
standards specifically related to SoS or SoSE products, processes, management, or other
aspects or endeavours.
Much of the current work in SoS is being done in engineering and acquisition; within
engineering the concept of a universally agreed-upon set of guidelines for interoperability is
important. Such guidelines provide four levels of standardization: compatibility,
interchangability, commonality, and reference, which are relevant to the SoS environment
through the creation of compatibility, similarity, measurement, and symbol and ontological
standardisation. As the various disciplines relevant to SoS mature, standards will be required
to ensure these four levels of the SoS standardization are met (Jamshidi 2009b).
Future standards for SoS will most likely mimic current systems oriented standards by
incorporating extensions for SoS perspectives and needs. An important need for systems is
adaptability, and this will be even more important for SoS due to the uncertainties,
technologies, systems, stakeholders, organisations, and other entities that may be a part of
future evolution of the SoS. The other key area of standardisation is interoperability and one
effort to provide a semantic and syntactic interoperability standard is the development by US
DoD C4ISR organisation’s Levels of Information System Interoperability (DoD 1998). It has
been noted that modelling and simulation will play a key role in the development of SoS and
it is noted that standard approaches to modelling and simulating systems, processes,
interactions, and other SoS activities is an important area in which standards for SoS may
evolve. Model-based standards may also be a significant area of future development in this
topic.
Standards, as with any other component of the system of systems journey, must be
considered in the early stages. Where appropriate or adequate standards and/or guidelines
are unavailable, new ones should be developed. Due to the desire for adaptability in all
areas of system of systems, these should, at a minimum, be developed as standards that
are “open” to any entity participating or impacted by the SoS. Adaptability is necessary in a
SoS since the membership or configuration is or can be dynamic and the relationships
among all of the systems in the SoS may not always be known. The key to enabling the
ability to be adaptable is interoperability from semantic, syntactic, and organizational
Release Date: 4th May 2012
© Loughborough University 2012
Page | 27
TAREA-PU-WP2-R-LU-9
perspectives/considerations. Standards of SoS is a long process which would necessarily
need to involve many engineering technologies such as modelling, control, communication,
computing, intelligence, sensing, etc. Aerospace industry in the US and US Department of
Defense are well aware of this need and efforts towards an ISO approach to SoS.
Overall, though, open standards are viewed as an effective way to reduce the risks
associated with lack of interoperability in SoS. An open standard is a standard that is
consensus-based amongst a community of interest, and is published by and freely available
within that community of interest (Henshaw, Lister et al. 2011a). This has been emphasized
in the software domain, for instance (Hall 2007) as a strategy for DoD to adopt open IT
standards and to influence these appropriately through participation in relevant standards
developing organisations and/or standards setting organisations in the area of information
and communications technologies.
One of the initiatives that will come out of the ICSOS effort is the instantiation of a technical
committee for SoS standards and sub/technical committees to address discipline sub area
standards. The processes for developing and instantiating SoS standards will follow many
of today’s processes and approaches with some addition considerations as described in the
GEOSS description with its “special arrangements”. These considerations shall encompass
the inclusion of practically all arenas of human activities that may impact the SoS
development, application, and management or vice versa (Johnson 2008 and Jamshidi
2008).
However, in light of previous comments in this document, the authors point out that
standards by themselves are not enough; one must include the interpretation of these by the
utilisers of these standards. Codes of practice, guidelines and exemplars will also be
required.
Please refer to the appendix sections for a summary of current EU / US projects
currently addressing system design issues for SoS.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 28
TAREA-PU-WP2-R-LU-9
5 SOS ARCHITECTURES
5.1
The Role of SoS Architecting
Along with defining a problem domain or a dimension, one of the most important tasks for a
systems engineer is to partition the problem into smaller but manageable sub-problems and
make critical decisions about the possible solutions. One of the most critical decisions is the
architecture. A key part of the SoSE task is to establish a technical framework for composing
systems to meet SoS needs, including possible changes in systems functionality,
performance or interfaces, and evolving the SoS over time to meet changing SoS objectives.
This technical framework is essentially an overlay to systems which comprise the SoS, and
is often referred to as the architecture for the SoS. Notably, a SoS architecture does not
address the details of the individual systems; rather, it defines the way the systems work
together to meet user needs and addresses the implementation of individual systems only
when their functionality is key to crosscutting issues of the SoS. Developing and evolving the
SoS architecture is core to the engineering of a SoS.
Architecture is the structure of components, their relationships, and the principles and
guidelines governing their design evolution over time (IEEE Std 610.12). The architecture of
a SoS is a persistent technical framework for governing the evolution of a SoS over time.
Architecture for a SoS includes:
• Concept of operations (CONOPs), how the systems will be employed by the users in
an operational setting
• Systems, functions, and relationships and dependencies, both internal and external
• End-to-end functionality and data flow as well as communications
The architecture of a SoS is constrained by the structure and content of the individual
systems, particularly the extent to which changes in those systems are affordable and
feasible, since systems will typically need to continue to function in other settings in parallel
with participation in the SoS. Architecture data on constituent systems can be an important
input to SoS architecture development. Developing a SoS architecture requires analysis and
assessments of trades among different options. Architecture analysis may be supported by
different assessment approaches. Available architecture frameworks (e.g. (Zachman 1987);
DoDAF; MoDAF, etc) provide tools to collect and organise information to support SoS
architecture development and represent architecture decisions.
Having described the user CONOPs or business process, then functionality or services that
the individual systems contribute to the SoS can be described in a functional architecture
that puts the key functions in order, thereby sequencing the SoS tasks from the viewpoint of
the SoS individual and organisational users. While for directed SoS, major changes in the
systems may be possible, in other types of SoS where systems continue to meet current and
changing user needs, constraints on the SoS to accommodate current systems operational
or business processes and supporting systems may be very strong. The functional
architecture provides a functional picture of the system. It details the complete set of
functions to be performed within the SoS as well as the relationships among the functions.
The output of the design process is the design of the SoS, or the physical architecture that
defines the physical components (constituent systems) of which the SoS will be composed.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 29
TAREA-PU-WP2-R-LU-9
The variability in the execution of these functions when SoS is deployed also needs to be
understood and factored into the SoS architecture.
In most cases, because of the nature of SoS as an overlay on multiple existing systems, the
migration to an architecture of a SoS will be incremental. Ideally the architecture of a SoS
will persist over multiple increments of SoS development, allowing for change in some areas
while providing stability in others. This ability to persist and provide a useful framework in
light of changes is a core characteristic of a good architecture. Over time, the SoS will face
changes from a number of sources (e.g., capability objectives, actual user experience,
changing concepts of operations and technology, and unanticipated changes in systems)
which may all affect the viability of the architecture and may call for changes. Consequently
the SoS systems engineer needs to regularly assess the architecture to ensure that it
supports the SoS evolution.The role of architectures within SoS is not as clearly defined as
might be expected. Wilkinson, et. al. (Wilkinson, King, James, Emes, & Bryant, 2010) have
identified to clear and belief systems for systems architecting: the forward architecting belief
system (as discussed in the above paragraphs) in which architecture is regarded as the
design for systems to be built, and the reverse architecting belief system, in which ‘the
purpose of architecting is to understand existing parts of the environment as systems.’
Future research activities in systems architecting for SoS should be cognisant of these belief
systems in terms of how the discipline develops.
5.2
Challenges in Architecting SoS
In the case of a new system development, the systems engineer can begin with a fresh,
unencumbered approach to architecture. However, in a SoS, the systems contributing to the
SoS objectives are typically in place when the SoS is established, and the SoS systems
engineer needs to consider the current state and plans of the individual systems as
important factors in developing an architecture for the SoS. This, along with the fact that
constituent systems may be complex systems in their own right, leads to a set of challenges
to architecting SoS.
Firstly, as noted above, in most types of SoS, the fact that constituent systems are
managerially and operational independent entities serving other users concurrently with the
SoS, representing the constituent systems can pose major challenges for the SoS
architecture. Because systems are likely to continue to face new functional requirements and
the need for technology upgrades independent of the SoS, there is an advantage to a SoS
architecture which is loosely coupled - that is, it has limited impact on the individual systems,
allowing for changes in functionality and technology in some systems without impact on
others or on the SoS objectives.
Secondly, the independence of the constituent systems also means that these systems are
typically focused on optimising their performance and other attributes at the system level,
which may not be supportive of SoS objectives. In the area of trust for example, a system
may severely constrain access to services to provide a level of security when a SoS may
depend on free exchange of those services. (Rebovich 2009) has articulated this difficulty as
a fundamental problem of SoS:
From the single-system community's perspective, it’s part of the SoS capability
represents additional obligations, constraints and complexities. Rarely is
Release Date: 4th May 2012
© Loughborough University 2012
Page | 30
TAREA-PU-WP2-R-LU-9
participation in an (sic) SoS seen as a net gain from the viewpoint of singlesystem stakeholders.
Thirdly, as introduced in emergence section 3.2, there are risks associated with unexpected
or unintended behaviour resulting from combining systems with complex behaviour of their
own. These become serious in cases where safety, for example, is threatened through
unintended interactions among services provided by multiple constituent systems in a SoS.
Finally, the development and implementation of a SoS architecture may be significantly
constrained by a reluctance to make changes or invest in the constituent systems, which in
many cases are very mature (e.g. in sustainment) or currently productively supporting other
systems, to support the SoS. In this case, approaches such as gateways and wrapping may
be used to incorporate these systems into the SoS without making significant changes in the
other systems.
5.3
Architecture Analysis
There has been a growing recognition that significant changes need to be made in
government agencies and large industries, especially in the aerospace and defence areas
(Sahin, Jamshidi et al. 2007). Nowadays major aerospace and defence manufacturers
include some version of large-scale systems integration as a key part of their business
strategies. In some cases, these companies have even established entire business units
dedicated to systems integration activities. In parallel, there is a growing interest in SoS
concepts and strategies. The performance and functioning of groups of heterogeneous
systems has become the focus of various applications including military, security,
aerospace, distributed energy, healthcare, and disaster management systems (Lopez 2006;
Wojcik and Hoffman 2006). There is an increasing interest in achieving synergy between
these independent systems to achieve the desired overall system performance (Azarnoush,
Horan et al. 2006).
Modelling and simulation is conducted to analyse architecture effectiveness and to verify
architectural features. In the literature, researchers have addressed the issues of
coordination and interoperability in a SoS (Abel and Sukkarieh 2006; Sahin, Jamshidi et al.
2007). In order to study SoS characteristics and parameters, one needs to have realistic
simulation frameworks properly designed for system of systems architecture. There are
some attempts to develop simulation frameworks for multi-agent systems using Discrete
Event Simulation tools (Zeigler, Kim et al. 2000). In these research efforts, the major focus is
given to DEVS architecture with JAVA. In (Zeigler, et. al. 2000), DEVS is combined with
Service-Oriented Architecture (SOA) to create the DEVS/SOA architecture. In (Mittal 2007)
the DEVS state machine approach is introduced. Finally, DEVS Modelling Language
(DEVSML) is developed by using XML based JAVAL in order to simulate systems in a netcentric way with relative ease (Zeigler, et. al. 2000). (Sahin et. al., 2007) have recently
introduced a discrete event XML based SoS simulation framework based on DEVS and
JAVA.
Please refer to the appendix sections for a summary of current EU / US projects
currently addressing architectures for SoS.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 31
TAREA-PU-WP2-R-LU-9
6 THE OPEN APPROACH TO SOS ENGINEERING
The critical challenge of moving from SoS as a concept to the engineering SoS is that the
technological, human, and organisational matters are very different to each other and that
these differences are very significant when considering system of systems engineering and
management (Wells and 2009b) 2008). A potential approach to engineering of SoS can be
the open systems approach to SoSE (Azani 2008). This can be viewed as meaning that SoS
exist within a continuum that contains ad-hoc, short-lived, and relatively speaking simple
SoS on one end, and long lasting, continually evolving, and complex SoS on the other end
of the continuum. Examples from nature are biotic systems (e.g., bacteria and ant colonies)
that are ad-hoc, simple, and short lived SoS, while galactic and more sophisticated biotic
systems (e.g., ecosystem, human colonies) are examples of SoS at the opposite end of the
SoS continuum.
The engineering approaches of galactic SoS are at best unknown and perhaps forever
inconceivable but biotic SoS seem to follow, relatively, less complicated engineering and
development strategies allowing them to continually learn and adapt, grow and evolve,
resolve emerging conflicts, and have more predictable behaviour. It is apparent that these
systems employ robust reconfigurable architectures enabling them to effectively capitalise
on open systems development principles and strategies. The open systems principles listed
by Azani (Azani 2009) are:
• Open interface principle: open systems have permeable boundaries that allow them
to exchange mass, energy, and information with other systems.
• Synergism principle: the co-operative interaction between constituent systems so that
their combined effect is greater than the sum of the individual parts. Essentially, this
is what gives rise to emergence.
• Self-government principle: this implies that the SoS maintains and develops its
internal order without interference from external sources. This could be through
cybernetic control, homeostasis, or self-organisation.
• Emergence principle: in this case, this refers to the occurrence of novel and coherent
structures, patterns, and properties during the self-organization of the SoS.
• Conservation principle: energy and mass (material) are conserved within the SoS.
• Reconfiguration principle: the SoS reconfigures and adapts itself to sustain itself
against changes in its environment.
• Symbiosis principle: the systems within the SoS have a symbiotic relationship to
each other; more transparently, the successful development and sustainment of a
SoS depends on symbiotic collaboration between the stakeholders of the systems of
which it is comprised.
• Modularity principle: each level and each system is to some extent independent of
others. In SoS design, the development of independent modular systems that
interoperate with each other through standardized interfaces enables greater
flexibility to promote better evolution of the SoS.
Azani (Azani 2009) has elaborated the open systems development strategies and principles
utilised by biotic SoS, discussed their implications for engineering of man-made SoS, and
introduced an integrated SoS development methodology for engineering and development of
adaptable, sustainable, and interoperable SoS based on open systems principles and
Release Date: 4th May 2012
© Loughborough University 2012
Page | 32
TAREA-PU-WP2-R-LU-9
strategies. (Hitchins 2003) has expressed the principles of open systems rather differently, in
the context of systems life cycles, as the seven principles of system reactions, system
cohesion, system adaptation, connected variety, limited variety, preferred patterns, and
cyclic progression. This description takes a systems dynamics approach to show how open
systems evolve.
The enablers of openness include open standards and open specifications, which draw from
consensus amongst a community of interest, and are published by and freely available
within that community. An open specification should be at a level of detail sufficient to be
implementable by independent parties. Compliance with open standards is intended to
ensure consistent results (Henshaw, et. al., 2011b). These support the notion of open
systems architecture, which is an open specification of the architecture of a system or
system of systems for the purpose of acquiring specified capabilities. As a general feature of
good design (for SoS), an open system architecture should allow for easy improvement and
update of system capabilities by adding or changing components.
6.1
UK MoD Systems of Systems Approach (SoSA)
Within defence, there have been some efforts to achieve SoS coherence through guidelines
and mandation. In the US, the Systems of Systems Guide (DoD, 2008) has been in use for
some time, a more recent effort in the UK has been the SoSA; this is an initiative that we use
as an example of such approaches.
The UK MoD Systems of Systems Approach (SoSA) represents a major step forward in the
management of SoS. It addresses the problem that: “Too many projects are delivering
products that do not work together due to the lack of shared understanding or relationships,
requirements and constraints in generating capability. Without this shared understanding
decisions are being made that do not consider the wider impact.” [ref: SoSA Rulebook]
Through a set of guiding principles, exemplar project approaches, underpinning architectural
approach, and education/training, MoD is seeking to change the behaviour of its own staff
and that of suppliers. The SoSA Rulebook recognises that many of the issues that cause
degradation of performance of, and within, SoS are due to human behaviours, as opposed to
technical difficulties. The SoSA focuses, mainly, on acquisition and its principles and
guidance are aimed at both customer and supplier personnel.
SoSA introduces nine SoSA principles; whilst these are not formally mandated, they form a
basis for bid assessment and so they are effective in defining common processes and
agreed standards through which delivery of defence systems can be governed to maximise
appropriate interoperability within the defence SoS.
The nine SoSA principles are:
P1:- Unifying the Defence Enterprise
This principle is concerned with governance and seeks to project common business and
operational goals by the MoD and assignation of authorities to direct the delivery teams. It
seeks to extend collaboration across the extended defence enterprise in the delivery and
support of defence systems.
P2:- Driving business and operational effectiveness
Release Date: 4th May 2012
© Loughborough University 2012
Page | 33
TAREA-PU-WP2-R-LU-9
This principle concerns the application of an holistic approach to defence acquisition. It is
designed to ensure that all Defence Lines of Development (Training, Equipment, Personnel,
Information, Doctrine/concepts, Organisation, Infrastructure, Logistics, and Interoperability)
are considered in development of defence systems. It is also concerned with the through-life
dimensions of concept, design, development, use and support, and disposal are properly
planned and managed. The specific dimensions that the principle identifies for consideration
are: Financial , Exportability, Performance , Assurance , Reliability , Security , Safety ,
Sustainability , End-to-end military integrity , Business continuity , Supportability. ,
P3:- Minimising Diversity
A challenge to a major procurer of systems is that different projects will seek optimise the
systems they procure for their specialist tasks, which leads to multiple bespoke procured
systems. This type of approach tends to encourage diversity in the SoS that a) reduces the
opportunity for effective interoperability between systems, and b) increases the overall costs
of procurement through additional design and specialist manufacturing costs. This principle
encourages compromise on optimisation at the individual systems level to enable better
optimisation at the SoS level.
P4:- Designing for Reuse
Whilst primarily focused on cost through the reuse of solutions, this addresses aspects of
knowledge management to ensure that long-lived systems are understood into the future.
Reuse covers both the temporal aspects of recycling solutions and the immediate use of
solutions in more than one project or more than one SoS. This principle also supports P3
concerning reduction of diversity.
P5:- Building with Proven Solutions
This principle is concerned primarily with using so-called Off The Shelf (OTS) components
and systems. Once again, this is largely driven by cost concerns, but it is also associated
with reducing risk through the use of proven systems for which market forces will maintain
availability. This approach does, however, have significant implications for the approach to
design, emphasising the need for modularity, clearly defined architectures, and use of
standard interfaces. The use of OTS may have performance and robustness implications for
the resulting Systems and SoS.
P6:- Ensuring Commonality of Services across the Defence Enterprise
This also focuses on the cost of diversity; its aim is to increase staff mobility across the
enterprise by having them provide the same service many times over without the need for
new, or specialist training to service each new project. However, interoperability of services
can also be viewed as a key enabler of effective SoS.
P7:- Designing for Flexible Interoperability
Modularity is a very important aspect of composing SoS. Henshaw et. al. (2011b) have
identified the need for research in the area of modularity to achieve better linkages between
SoS architecture and benefits sought. This principle is established to enable greater agility in
system update and development and also to increase the procurement agility of the
customer by enabling greater competition.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 34
TAREA-PU-WP2-R-LU-9
P8:- Adopting Open Standards
Defence necessarily has some restrictions, associated with security, on the use of
standards, but it is recognised that use of open standards increases competition and,
furthermore, improves the overall interoperability of systems.
P9:- Treating Information and Data as an Asset
Although this may seem a rather fatuous expression of a principle, this actually recognises
the complexity of the extended enterprise in defence, in a sense treating the enterprise itself
as a SoS, and the importance of information being accessible from any part of that SoS.
To support the principles, the UK MoD is developing resources to enable acquirers,
engineers and designers to implement them in a consistent fashion. The SOSA Rulebook
has five main components:
• Lists of Services.
• Policies and Rules for the services that provide functionality of the systems of
interest.
• Standards to which products or services must adhere.
• An explanation of the SOSA Domains, Authorities and Disciplines.
• Links to the MOD Architecture Framework (MODAF).
The SoS used in defence fall broadly into the Directed, Acknowledged, and Collaborative
types. SoSA represents a state of the art approach to governance within SoS. It is an ongoing and developing initiative, which is supported by a gathering together of good practice
from industry and government and by on-going research. There remain significant research
challenges associated with the specification of services, the architecting – and especially
metrication of architecture – at the SoS level, and optimisation. The long term implications of
the principles are a subject of debate.
Please refer to the appendix sections for a summary of current EU / US projects
currently addressing open approach to engineering SoS.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 35
TAREA-PU-WP2-R-LU-9
7 SOS MODELLING AND SIMULATION
7.1
Role of Modelling and Simulation
In a SoS, constituent systems and/or subsystems often interact with each other because of
interoperability and over all integration of the SoS (Jamshidi, 2008). A common attribute that
differentiates a SoS from a single monotholic system is interoperability. In the literature,
researchers have addressed the issues of coordination, emergence, interoperability, etc. in
SoS (Sage and Cuppan, 2001; Sage, 2001; Sahin, 2007; Jamshidi, 2009). Among numerous
open challenges in the field of SoSE, one that requires immediate attention is the concept of
modelling and simulation of SoS. In this section, the authors focus less on SoS issues per se
than on the role that modelling and simulation can play in helping to address SoS problems.
Modelling produces a model, representing the construction and operation of some system of
interest within the SoS. Modelling activity enables one to predict the effect of the changes to
the SoS. A good model should incorporate judicious tradeoff between realism and simplicity
(Law, 2005). On the other hand, a simulation of SoS is the operation of its models through
validation techniques under known input conditions such that its output is compared with the
expected / actual SoS output. The model can be reconfigured and experimented with;
usually, this is impossible, too expensive or impractical to do in a SoS it represents. The
operation of the model can be studied, and hence, properties concerning the behaviour of
the actual SoS or its constituent systems can be inferred. In its broadest sense, simulation is
a tool to evaluate the performance of a SoS, existing or proposed, under different
configurations of interest and over long periods of real time. In practical scenarios, simulation
focuses on the implementation of SoS models as executables, usually represented in the
form of computer programs.
7.2
Challenges of an Emerging Discipline
Modelling a system with emergent properties is a big challenge due to lack of its verifiability,
where it is not known if the designed (or emerged) SoS can reliably solve a particular
problem. It is just not enough to ask how to observe variables in a complex emergent system
as much as it is to know what to observe in the first place. One may justify solving these
issues using modelling tools ideal for functional design approaches such as using Unified
Modelling Language (UML); however, the problem with UML for SoS is that the process
capturing behaviour of response between actors is too specific. It is not setup to handle
complex emergent dynamics. UML is useful when the design process is functional and thus
cannot handle any changes that are not previously specified by the designer (i.e.
complexities and emergent properties).
As an emerging discipline, SoS modelling and simulation needs establishment of a body of
knowledge that comprises engineering methods in support of standard operations.
Frameworks and methods are necessary to capture and document simulation systems
(Wang 2009).
In order to study SoS characteristics, one needs to have realistic simulation frameworks
properly designed for the SoS architecture. There are some attempts to develop simulation
frameworks for multiagent systems using discrete event simulation tools (INCOSE, 2006;
Release Date: 4th May 2012
© Loughborough University 2012
Page | 36
TAREA-PU-WP2-R-LU-9
DOD 2004; Maier, 2006). In these research efforts, the major focus is given to Discrete
Event System Specification (DEVS) architecture with JAVA. In (INCOSE, 2006), DEVS
modelling is presented and discussed in detail. In (Maier, 2006), DEVS is combined with
Service Oriented Architecture (SOA) together to create the DEVS/SOA architecture. Finally,
DEVS Modelling Language (DEVSML) is developed by using XML-based JAVAL in order to
simulate systems in a net-centric way with relative ease.
It is rare that a single model or single modelling approach will adequately capture all the
necessary behaviours that the designer or analyst would wish to examine. SoS modelling
frequently requires the combination of models from different disciplines, with different
purposes, and with different levels of fidelity, etc. These must be integrated into a system of
models. Furthermore, not all aspects of a SoS model are necessarily under the control of, or
available to, the modeller; thus, rational and valid assumptions need to be made for
unmodelled or unavailable system behaviours
Please refer to the appendix sections for a summary of current EU / US projects
currently addressing simulation and modelling activities within SoS.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 37
TAREA-PU-WP2-R-LU-9
8 SOS NETWORK ENABLEMENT
Network Enabled Capability (NEC) is a military concept with applicability across a range of
other sectors, especially those associated with emergency response, search and rescue,
and logistics. It exemplifies the nature of SoS as the combination of communications
technology and the human and organisational behaviours required to exploit it effectively.
Network enablement is essentially the effective movement of people, goods, and
information, but it is the latter (information) that is the main focus of NEC and related
themes. Both NEC (European) and NCO (Network Centric Operations, American), whilst
being slightly different approaches have, as their primary operational aim, the objective of
exploiting the information age more effectively to achieve agility. In the seminal book, Power
to the Edge (Alberts & Hayes, 2003), the authors recommend changes in command and
control to accompany more effective distribution of information, such that decision making is
conducted more locally (rather than centrally) in order to respond to the local conditions,
while being cognisant of the wider operation. That is to say, decision making power is
moved to the edge. This is equally important whether it is concerned with military decision
making, or that of the civilian authorities. The UK MoD benefits chain (MoD, 2005), modified
by (Court, 2007) asserts that mature command and control (C2) is a prerequisite for
successful NEC and confirms the importance of information sharing systems as enablers of
agile military operations.
NEC can be defined as (Henshaw & Urwin, 2009):
..the enhancement, or realisation, of military capability achieved through effective
information sharing between geographically and/or temporally distributed
sensors, decision makers, effectors, and support services
The principal characteristic of NEC is the distributed networking of sensors, decision makers,
effectors, and support services in space, time or both. The achievement of operational
agility relies on effective systems engineering of the contributing systems; the challenges
associated with Systems Engineering for NEC have been assessed by the research
programme: NECTISE (Henshaw, Gunton, & Urwin, 2009). Whilst network enablement is
applicable in military and civilian domains, the analysis below focuses on military capabilities
and is based on the findings of the NECTISE programme.
8.1
NEC Themes
NEC assumes that agility is enabled by better use of information and, in particular, by
providing more reliable information sooner to decision makers. This requires highly
interoperable systems, but interoperability must be understood to be context dependent and,
in general, it is the areas of organisational and human interoperability that appear to require
the greatest improvement (rather than data links).
With all military systems, dependability is an attribute that is both designed for and tested
(perhaps through qualification; e.g. safety, security, reliability). The sharing of information in
NEC, the confidence with which it is done, and how it is used, must be dependable. In terms
of both the information that is used by commanders and the assets that they may choose to
Release Date: 4th May 2012
© Loughborough University 2012
Page | 38
TAREA-PU-WP2-R-LU-9
task, availability is a key parameter. Put simply, the asset, sensor, munitions, etc. must be
available when required. The customer must be able to afford the proposed systems, and
the supplier must be able to afford to develop and deliver the systems. Thus, affordability is
the fifth NEC-readiness theme. It is critical, as the others (interoperability, availability, and
dependability) are limited by the cost of achieving them.
The NEC-readiness themes are: Agility, Interoperability, Dependability, Availability, and
Affordability. Whether these are considered in the (military) operational or (supply chain)
organisational context, collaboration underpins them; that is to say, the effectiveness of
collaboration between the systems’ stakeholders constitutes a significant enabler or barrier
in the development and use of the systems. Finally, it is asserted that managing the
systems over the course of their lifetime requires effective management of knowledge
among the contributing parties.
The relationships between these themes (figure 6) are important; the effectiveness of the
systems deployed is determined to a large extent by the trading that is done between the
five main themes. The systems engineering developments reported below can all be
characterised through these themes.
Collaboration
Agility
Availability
Affordability
Interoperability
Dependability
Knowledge Mgmt
Figure 6: The NECTISE NEC-readiness Themes
8.2
Impact of NEC on Systems Engineering
NEC poses some key challenges, which are only partially resolved. Chief amongst these is
the question of qualification for, at least, safety and security. These are primarily due to the
emergent nature of SoS and appear to demand a completely new approach, based largely
on assurance, rather than qualification per se. This is because it is impossible to test all the
possible configurations, as is usually the case with qualification.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 39
TAREA-PU-WP2-R-LU-9
One implication of Interoperability is the need to integrate legacy systems effectively (in
some cases this may prove impossible) and the corollary is the need to design new systems
that are sufficiently flexible to remain viable as the other (newer) systems with which they
must interoperate are created in the future. Thus interoperability, which is so often traded out
as project progress, must be prioritised. The maintenance of interoperability over long
periods of time implies that new models of life cycle should be considered. Open
architectures, whilst not being the solution to interoperability, certainly form a vital need in
the creation of interoperable systems fit for NEC.
Drawing together the discussion above (figure 7) a set of five priority considerations for
managing NEC-ready systems is derived to be:
•
•
•
•
•
Interoperability considerations for all design.
Design must be carried out for proactive participation in NEC; i.e. design of systems
must take account of their role in the network.
Particular attention must be paid to the qualification of new systems (and old systems)
within the network context; this is an area of especially high research importance at
present.
The importance of life cycle and legacy implications is heightened by the need to ensure
continued interoperability within the NEC.
New systems take account of, and also contribute to, all the defence lines of
development.
From these priority considerations a set of seven changes to systems engineering practice is
implied. These are:
•
•
•
•
•
•
•
Systems of Systems Architecting
Design across all DLODs
Manage evolving requirements
New life cycle models for NEC contributing systems
Apply SoS strategies to dependability and qualification
Specifically address organisational learning strategies
Interface with collaborating organisations
These seven implications are explained in more detail in the following sub-sections.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 40
TAREA-PU-WP2-R-LU-9
Figure 7: Summary of the Impact of NEC on Required Systems Engineering
8.2.1 SoS Architecting
NEC is a SoS problem, as stated above, and the effective management of interoperability
between contributing systems requires effective architecting. There is currently a significant
programme underway in UK MoD to develop the SOSA (Systems of Systems Architecture),
but this is using input from industry. As stated by the MoD in (UK MoD(DG DE&S) 2008), the
MoD is the owner of the SOSA, but recognises the need to draw on industry skills to develop
and support it. It is worth noting that the lack of such an architecture was identified
(Quintana 2007) as a major cause of industry’s failure to engage in the NEC ambition; a
conclusion supported by NECTISE research (Maytorena 2008).
The MoD Architecture framework (MODAF) has been put in place to support interoperability
management and acquisition. As such, there is a requirement for industry to provide
architectures that are MODAF-compliant (note that it is not mandated). But MODAF is not a
design tool and whilst it provides a link to the SoSA, industry requires a number of other
tools and architectures to design the systems that contribute to NEC. These have been
identified in (Russell, Irvin et al. 2007) as: Process, Visualisation, Cost and Trade-offs,
Human Factors, Information Management, Interoperability, Responsibilities, Safety, Security,
Deploy, Support, Withdraw, Experimentation, Assessment of the Architecture. The latter
challenge of assessment of architecture has been addressed by (Henshaw M. J., 2011).
Release Date: 4th May 2012
© Loughborough University 2012
Page | 41
TAREA-PU-WP2-R-LU-9
8.2.2 Design Across all Defence Lines of Development
Capability is delivered across the Defence Lines of Development (DLOD) (UK MoD 2006).
This statement is not specific to NEC, but is a fundamental tenant of the UK MoD’s approach
to capability delivery. Industry cannot contribute fully to all the DLODs (Yue, Henshaw
2009), because some parts will always remain the sole responsibility of MoD (e.g. Doctrine
and Concepts). Nevertheless, industry must clearly understand its contributions to the
DLODs and must also develop solutions that consider all the DLODs. The Defence Lines of
Development are (UK MoD 2009): Training, Equipment, Personnel, Information, Concepts
and Doctrine, Organisation, Infrastructure, Logistics.
Whilst NEC is advanced by the physical systems that are deployed, its true potential is
realised only through changes in the behaviour of service personnel. Although all DLoDS
must be considered, it is worth highlighting the importance of changes to training (Vallerand,
et al. 2009), and Doctrine and Concepts (Alberts, Hayes 2005). The implications of, and on,
these must be explicitly considered during the design of new, or upgraded, equipment.
8.2.3 Design for NEC
A further reflection, with respect to the systems designers’ mindset, is that in the design of
systems specific consideration should be given to design for network activities. For
example, this might suggest the inclusion of a particular type of sensor on a new platform
that would provide data to the wider network rather than only to the specific platform under
design consideration. This would need to be linked explicitly to the interoperability design
criteria.
An additional consideration for design is the effect of change propagation, not only within the
immediate system being designed, but within the wider system of systems to which it
contributes. Being able to accurately predict the effects of change from part of the system to
other, interlinked, parts can mean the difference between delivering on time and to budget
and complete project failure. There exist a number of change prediction tools e.g. that of
Clarkson (2004) computes combined change risks between components to identify ‘hidden’
indirect change dependencies. This is a significant challenge in the case of complex
monolithic systems, but becomes even more challenging in the case of dynamically
changing systems of systems that characterise NEC. In this case, the modelling of change
propagation must also pay attention to social networks (which includes both human and nonhuman agents).
Keller et. al. (2008a; 2008b) has provided some initial modelling approaches for systems of
systems and the tools that can be derived there from should become an important
component for design for NEC.
8.2.4 Managing Evolving Requirements
The traditional approach to requirements management assumes that a set of atomised
requirements can eventually be derived that will then hold true for the development and
delivery of the solution. Indeed the well-known V-model assumes precisely this truth in
terms of verification and validation (e.g. Blanchard, Fabrycky 2006, pg. 34). NEC amplifies
the problem of requirements creep, so that one could describe them as being in a state of
constant evolution. The evolutionary nature of requirements must be accommodated; it is
Release Date: 4th May 2012
© Loughborough University 2012
Page | 42
TAREA-PU-WP2-R-LU-9
related to the notions of agility and adaptability and requires flexibility in design and careful
analysis of the effects of change on the system under consideration and the wider system of
systems in which it likely sits.
8.2.5 Life Cycle Models for NEC Systems
The systems of systems nature of NEC drives the need for a new consideration of life cycle;
a NEC will be realised through a number of delivered projects and programmes that must be
co-ordinated over time and are likely to include multiple rapid updates (individually) as
technology develops (Mendham 2006). Essentially, there is a need to manage and integrate
many systems with asynchronous life cycles, in which these asynchronous life cycles have
varying uncertainty and change.
The life cycle models for NEC must, therefore, consider not the individually developed
systems only, but the manner in which systems are integrated. Architectural approaches
can address these considerations: service oriented architectures, with late binding of
services, is one such approach, or with feedback in an agile development (Liu, 2008c) is
another (figure 8).
Figure 8: Agile Development of Capability, from Lie, et al., 2008c
8.2.6 Dependability and Qualification of NEC Systems
There are many issues associated with dependability for systems of systems, but the chief
amongst them is the adequate assurance of safety for networked systems. For NEC-ready
systems a number of fundamental approaches to the safety assessment are no longer
guaranteed to be valid; these are:
•
Identification of hazards arising from systems interactions (emergence).
Release Date: 4th May 2012
© Loughborough University 2012
Page | 43
TAREA-PU-WP2-R-LU-9
•
•
•
Inadequacy of current HAZOPs methods for interaction between multiple monolithic
systems.
Failure of the compositional safety analysis proposition. It cannot be assumed that
systems that behave correctly individually will behave correctly collectively (leading to
so-called Normal Accidents 3).
Event sequencing is not possible to achieve reliably in the analysis. Generally, the
sequence in which an initiating failure develops into other failures is a fundamental part
of the safety analysis, but in a SoS the sequence my no longer be a relevant property of
the failure.
This particular concern is a major problem for delivery of NEC-ready systems and is the
subject of considerable ongoing research in both Government and Industry. The challenges
it poses appear to indicate that a fundamental change in thinking is required to address the
qualification problem. A move away from certification to assurance is being investigated by
researchers in both the UK and the US (Dahmann, 2008), but resolution still seems to be
some way ahead.
8.2.7 Organisational Learning Strategies
The NEC-readiness themes (as illustrated in the figure 6) are surrounded by knowledge
management; this is meant to imply that the management of agility, interoperability,
dependability, affordability, and availability require effective management of both information
and knowledge. This concern might be expressed as ‘enterprise’ rather than ‘organisational’
learning strategies, as it is a concern for the whole systems of systems, regardless of the
organisations from which the individual systems emanate.
8.2.8 Collaboration
NEC places an additional constrain of interoperation of systems that may not initially have
been designed to work together. The multi-organisation delivery of systems creates a
business environment in which the contributing organisations must collaborate at some level;
in the longer term, collaboration will be necessary between the organisations that make-up
the defence supply chain in order that the systems they deliver may be NEC-ready with the
minimum cost to both the customer and the suppliers.
Please refer to the appendix sections for a summary of current EU / US projects
currently addressing network enablement for SoS.
3
‘Normal Accident’ is a term applied to the situation in which all the systems in a SoS behave as they should,
but a realised unsafe state is created due to their failure to interoperate correctly.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 44
TAREA-PU-WP2-R-LU-9
9 SOS VALIDATION AND VERIFICATION
9.1
Challenges
Verification and validation (V&V) is one of the most important steps for systems engineering,
especially for safety critical systems. Validation ensures that the system specifications are
appropriate and verification ensures the implemented system satisfies its specifications
(Wallace 1989).
Systems of systems are highly dynamic and complex. Although V&V methods exist for
tackling individual dimensions of the design space such as environment simulation, software
validation, software verification, hardware verification, safety analysis, a lack of consistent
modelling methods meant that it is challenging to combine these within a single design
environment (www.project-advance.eu). SoS are composed of heterogeneous systems
consisting of integrations of communication, electronic, mechanical, power and software
systems, and their functionality relies on the interaction and interoperability between
hardware and software systems, people and other physical domains.
To achieve the required reliability, robustness and quality of SoS, mastering the
heterogeneous behaviour across domains is the most essential part during the development
process (www.verdi-fp7-eu). Construction, maintenance and management of different types
of models are costly and challenging activities. The research challenges include ensuring
consistency between the different models, verifying the correctness of the models, and
managing the evolution of the models.
Verification requires that some assumptions be made on the behaviour of the environment in
which the system is intended to operate. If the actual operating environment violates these
assumptions, the system may fail despite successful verification (Kern and Greenstreet
1999). The complexity of SoS means that it is extremely difficult to ensure that the
assumptions about the actual operating environment are correct.
Modelling in a variety of forms plays a central role in tackling these design dimensions.
Software verification relies on models such as test sets and formal models against which to
verify designs and implementation. Testing is the most common verification technique but
formal verification tools, such as model-checking (Berard et al. 2010), automata-theoretic
techniques (Kupferman, Vardi and Wolper 2000), automated theorem proving (Fitting 1996),
and approaches that integrate the above methods, also play a role and that role is increasing
especially for critical applications. Simulation models of planned physical systems play a vital
role in identifying and validating requirements and constraints on embedded software in
early stages of development. Safety validation relies on models for analysing hazards and
providing safety cases (www.verdi-fp7-eu).
Please refer to the appendix sections for a summary of current EU / US projects
currently addressing validation and verification activities within SoS.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 45
TAREA-PU-WP2-R-LU-9
10 SOS QUALIFICATION AND ASSURANCE
10.1 Research Challenges
This section focuses on safety qualification and assurance, although it is acknowledged that
security is a significant issue in this respect as well. Safety concerns can, of course, be an
important element of any SoS, but it is in the area of transport that much attention has been
focused. The nature of regulation to ensure safety is different according to domain; for
instance, it is generally true that regulation for air travel is more detailed and examined than
that for land or sea. Similarly, the regulation applied to railways is different to that applied to
road transport. However, the regulation is primarily focused on vehicles, rather than the
networks 4, and this has led to speculation that, as the level of distributed decision making
that uses networked information increases, standards for qualification may need to change
to better reflect the need to consider the network as part of a safety case.
The following problems may arise in the operation of transport SoS:
• Interoperability between systems may be compromised because older (legacy)
systems have been built to different standards than more recent systems.
• Quality and/or source of information may be unknown to decision makers; hence
levels of trust in information may be inappropriate (too much trust in bad data, or
insufficient trust in good data).
• Network failure or disruption may cause systems to suddenly become vulnerable
• Integration of engineered autonomous systems within networks may introduce risks
of unexpected decision making.
• Normal accidents (Perrow, 1984) are more likely. In particular, accidents in which all
systems are working as they should but due to interoperability failure or information
misinterpretation a bad emergent behaviour occurs.
Of course, the above are all relevant to domains other than transport; for instance, nuclear
energy is a frequently quoted example of normal accident theory.
Using the aviation as an example: The International Civil Aviation Organisation (ICAO)
provides standards that cover all aspects of aviation, with Annexes 6 (Operation of aircraft),
8 (Airworthiness), and 16 (Environmental Protection) being the most relevant for safety
aspects. Airworthiness is concerned with the vehicle only; however operation of aircraft
covers the rules for safe operation (e.g. separation distances, passenger information, flight
planning, etc.). Annex 6 does not cover network aspects of operation, although it does
address the rules and constraints necessary to cope with the complex network of flight
routes etc.
In the first of a new series of annual reports on aviation safety, ICAO (ICAO, 2011) has
noted a significant increase in the adoption of Performance-based Navigation systems.
These seek to provide aircrew with greater situational awareness through shared information
on obstacle and terrain clearance and aircraft-to-aircraft separation.
4
Of course, there is regulation for the operation of networks, such as railways, but it does not necessarily take
a SoS perspective on emergent behaviours.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 46
TAREA-PU-WP2-R-LU-9
Alexander et. al. (Alexander, Hall-May, & Kelly, 2004) have argued that traditional safety
analysis is simply not possible for SoS, because it is impossible to identify all possible
configurations in a SoS and, thus, impossible to exhaustively test all conditions, as is
required by conventional safety qualification. For instance, a well-known and extensively
used technique for safety analysis: HAZOP (Kletz, 2006) analyses deviations of single
information flows, whereas in a SoS there are multiple flows.
In the military world, in which assets are networked specifically to enhance capability (see
chapter 8); qualification of SoS is, nonetheless, inadequately dealt with. An analysis of
relevant UK safety Standards (Iwu & Kelly, 2009) JSP553 (air), JSP454 (land), and JSP430
(maritime) indicated that none addressed the issues of integration of platforms.
Aspects associated with qualification of autonomous systems have been investigated in the
ASTRAEA programme (ASTRAEA, 2011); although significant advances have been made,
the goal of qualification of Unmanned Aerial Systems for operation in civil airspace remains
a distant aspiration.
Despite fairly substantial investment in research into SoS qualification in both Europe and
US in recent years, this remains a major challenge in the realisation of the benefits that
networked systems can provide. It has been suggested (Kelly, 2009) that a new paradigm is
needed that seeks to base safety decisions on assurance, rather than the traditional faultanalysis based approaches that are used for certification. SoS qualification is a high priority
for effective research, coupled to realistic discussions with certification authorities and
standards bodies.
Please refer to the appendix sections for a summary of current EU / US projects
currently addressing SoS qualification and assurance.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 47
TAREA-PU-WP2-R-LU-9
11 MANAGEMENT, CONTROL AND OPERATION OF SOS
The following chapter content is adapted from established literature (DeLaurentis, Crossley
and Mane 2011) to reflect the management, control and operation of SOS aspects of the
paper.
11.1 SOS Types and Hierarchy
Systems of systems are composed of numerous independent systems. Following table 2,
resources are the physical entities representing independent systems; stakeholders, the
nonphysical entities. The design of an SOS requires that analysis methods be appropriate to
the type of entities that constitute the system of systems. Some SOS consist predominantly
of technological systems: independently operable mechanical (hardware) or computational
(software) artifacts. Technological systems have no purposeful intent; i.e., these resources
require operation by, programming by, or activation by a human or organization. Other SOS
consists predominantly of humans and human enterprise systems: a person or a collection
of people with a definitive set of values/skills. While these systems are physical entities, they
primarily act as operators of the technological systems, as service providers (both with and
without the support of the technological systems), and/or as consumers of services. Each
SOS lies on a spectrum between wholly technological and wholly human enterprise. The air
transportation system (ATS) SOS, for example, embraces large numbers of both types of
systems. The aircraft, airports, airways, information systems, etc., constitute the
technological systems, while the aircraft designers, air traffic controllers, maintenance
technicians, pilots, etc., and contribute the human or human enterprise systems.
Table 2: Lexicon for Describing SoS
11.2 Control of SoS
The SOS dimension is the degree of control of authorities, in an SOS, over the entities or the
autonomy granted to the entities is related to (Maier 2005) discussion of operational
independence and managerial independence of systems within an SOS. Emphasizing the
importance of control/autonomy, (Sage and Cuppan 2001) refer to a collection of systems
with operational, but limited managerial, independence as a system of systems and a
collection of systems with little central authority as a federation of systems. This also follows
from Krygiel’s classification (Krygiel 1999). Theoretically, the military has a chain of
command, and there is a single high-level set of objectives/capabilities/needs described by
Release Date: 4th May 2012
© Loughborough University 2012
Page | 48
TAREA-PU-WP2-R-LU-9
some high-level decision-maker for an SOS. The constituent systems in a defense SOS, for
example, have independence (an air vehicle and a ground vehicle operate without direct
linkage to each other or without requiring explicit instructions for every move), but strategic
SOS decisions are made at a high level. Ultimately, someone is responsible for directing the
military SOS to provide the capabilities.
The Department of Defense (DOD) system-of-systems engineering guide (DOD 2011)] helps
here by identifying four types of SOS based on the degree of centralized management (in
order from most to least centrally directed): directed, acknowledged, collaborative, and
virtual. Most DOD SOS problems are acknowledged or collaborative. In air transportation, for
example, each airline is seeking to make profit by providing air transportation, while following
the requirements of safety imposed by regulations and policy; however, one airline cannot
directly control or make decisions for another airline. The Internet, however, contrasts with
the central authority exhibited by a defense SOS. Information exchange uses a set of
protocols that most users agree upon, but no entity enforces adherence to these protocols.
Individual computers connect into local area networks that have administrators, but the
individual systems that comprise the Internet are very loosely connected, and there is no
clear chain of command or central controlling authority. Arguably, this provision of autonomy
(or lack of control) allows the Internet to successfully provide the services requested of it.
The Air Transportation System (ATS) application, lies between the extremes of the defense
and Internet examples. A subset of resources, mostly at the α-level, is centrally controlled
[an airline controls the operations (scheduling, maintenance, and crew assignment) of the
aircraft in its fleet], whereas other systems, typically stakeholders at the β-level and above,
operate with a high degree of autonomy. Further, and perhaps most important, the intent of
these stakeholders vary with time; both as individuals and societies, our motivations and
priorities shift, often faster than existing SOS can respond.
11.3 Decision Making and Control Methods
Decision-making and control methods span from hierarchical (centralized) control to hybrid
schemes to a fully distributed approach in which each system contains the logic and
authority to choose its own actions. In any of these, optimization plays a crucial role.
However, the applicability of a particular optimization type depends on location with respect
to the three dimensions of connectivity, control and system type, and especially upon the
degree of autonomy in a majority of systems. For example, decomposition-based methods
appear applicable when autonomy and connectivity are low. Alternately, performing
optimization for a system-of-systems design problem with a γ-level objective but with a
majority of autonomous systems at the α-level will likely be overwhelmingly difficult due both
to computational complexity from the large search space size and to uncertainty in behaviors
with exogenous inputs. Further, such SoS problems are often multi-objective, containing
multiple stakeholders with possibly conflicting objectives. In this latter case, optimization can
serve as the backbone for predicting behavior of individual systems at the lower levels,
which then feeds models for autonomous behavior at the higher levels. The implications of
two autonomous systems interacting with each other can be understood via application of
methods related to optimization - e.g. competitive games, cellular autonoma, and related
methods. In cases of both cooperative and non-cooperative situations, the ability to estimate
Release Date: 4th May 2012
© Loughborough University 2012
Page | 49
TAREA-PU-WP2-R-LU-9
optimal decisions among interacting players is crucial. However, the specification of
outcomes may be difficult to accomplish computationally at the α-level. Such decision games
become more relevant at the β-level and above.
11.4 SOS Decision, Control and Management in ATS: Applications
Literature in (Mane 2008, Mane, Crossley and Nusawardhana 2007) presents two
experiments to commingle tools from operations research and Multidisciplinary Design
Optimization (MDO) into a system-of-systems design method. The motivation to look for
operations research and MDO tools in these applications follows the preceding discussions
of SOS characteristics. The first experiment, concurrent aircraft design and resource
allocation with new aircraft design for airline operations, seeks to determine the
characteristics of a new aircraft for allocation along with an airline’s existing fleet to meet
passenger demand (providing transportation is a capability). The problem must consider the
use of both new and existing/legacy aircraft along with the implications that this entails. The
second experiment, concurrent aircraft design and resource allocation with new aircraft
design for operations of a fractional management company (FMC), also seeks to determine
the characteristics of a new aircraft for allocation, but demand is uncertain and is expressed
as a probability distribution of trips between city pairs.
The problems view the airline and the FMC as the sole top-level entities. Because of this,
centralized control exists; the airline’s management can make decisions about which aircraft
types and how many of each type to assign to each route and the FMC’s management
can decide how many aircraft to own, how many charter flights to use, and how these aircraft
will fly the demanded trips. Centralized control implies that the management has objectives
that it wishes to minimize or maximize. There may be many objectives, but the location of
the airline and FMC SOS on the control axis implies that optimization is applicable to
formulate the problems (as opposed to when only satisfaction or equilibrium are applicable
when there is high autonomy).
(DeLaurentis and Ayyalasomayajula 2009) presents a second air transportation design study
that was guided via the SOS lexicon and taxonomy. This problem concerns a means to
assist decision-makers attempting to transform the ATS to a state that can satisfy growing
demand with greater levels of efficiency. The methodology objectives of this problem are to
generate a design solution space at a higher level of aggregation than the previous problem
and to consider two distinct time scales. Further, as indicated from the lexicon (table 2), an
SOS approach for ATS considers not only the technical aspects, but it also incorporates
policy, socioeconomic and alternative transportation system considerations into one
framework. Because such an objective is overwhelmingly complex if pursued at the lowest
levels of detail, a system of system modeling approach is necessary in order to model
alternative air transportation architectures at appropriate levels of abstraction in a hierarchy.
For problems focused on higher levels in the hierarchy, the individual systems models are
basic enough to enable the higher level analysis to identify good solutions (e.g., simple
airport models used to determine the best network topology, configuration of nodes and
links). The final product of such an analysis is a concept consisting of a set of rules of
behavior and network structure that satisfies the transportation goals. Further, the high
impact rules (policies) that accomplish those goals are identified by allowing agents in the
system to do the right thing naturally.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 50
TAREA-PU-WP2-R-LU-9
Airline/FMC Modeling and Solution
Figure 9: FMC and Airline Decomposition Frameworks
Given that an optimization approach seems applicable for the concurrent aircraft design and
aircraft allocation problems, and the nature of the connectivity (Mane 2008, Mane, Crossley
and Nusawardhana 2007) pose these as mixed-integer nonlinear programming (MINLP)
problems. The optimization seeks to minimize the expected daily operating cost of the FMC
while determining the optimal aircraft design (e.g., design requirements and aircraft
characteristics) and the optimal operations (e.g., aircraft assignment to routes and number of
aircraft to be owned and operated). However, the size of the MINLP problems is such that
solving all but the most simplistic versions is impractical. Because connections between the
constituent systems are few, a decomposition approach allows solution to these problems.
For the airline problem, the aircraft design and aircraft allocation problems are solved as a
nonlinear programming (NLP) problem and an integer programming (IP) problem,
respectively, (figure 9a); the results are used as function evaluations in a much smaller toplevel IP problem (IP because passenger capacity is the integer variable). A similar approach
solves the FMC aircraft design and aircraft allocation problem. However, because demand is
uncertain and is expressed as a distribution, a Monte Carlo simulation is performed for every
function evaluation of the top-level NLP problem. The top-level problem is an NLP problem,
because the multidisciplinary design variables are continuous variables for the FMC
problem: namely, aircraft design range and cruise velocity (figure 9b).
In one example application for the airline problem, using a 31-route structure and an existing
aircraft fleet consisting of seven different aircraft types, the optimization strategy via
decomposition resulted in a new aircraft design and its allocation along with existing aircraft
that reduced the airline’s daily operating costs by nearly 13%. Similarly, in an example
application of the FMC problem, serving demand between 10 (uniformly) randomly selected
cities, the optimization resulted in the design of a new aircraft that, when allocated in concert
with charter aircraft, reduced the daily expected cost of operations by nearly 1% with respect
to operating an existing aircraft on the routes and using charter aircraft. The new aircraft had
a design range of 1549 n mile, shorter than the longest demand trip (1600 n mile). As a
Release Date: 4th May 2012
© Loughborough University 2012
Page | 51
TAREA-PU-WP2-R-LU-9
result, the newly designed aircraft would not be able to serve all demanded trips, but the
FMC must rely on charter aircraft that have longer range to satisfy all demand.
ATS Modeling and Solution
The control exhibited by the service and infrastructure providers (encapsulated in the
operations, economic, and policy dimensions) must be addressed. To achieve this, it is
necessary to employ modeling methods that reflect the competition and cooperation driving
the stakeholder behavior and determine the implications of their interactions and
manipulation of resources within the SOS. This represents a departure point from current
design theory where the emphasis often lies only on representing the preferences of a user/
operator, rather than including actual behaviors. SOS analysis must incorporate human
preference and behavior patterns explicitly inside the problem boundary along with the yetto-be-designed systems. Agent-based modeling (ABM) has emerged as an approach of
choice in this setting. ABM employs a collection of autonomous decision-making entities
called agents imbued with simple rules of behavior that direct their interaction with each
other and their environment. Agent functionality is quite flexible, with behavior types ranging
from simply reactive (change state or take action based on fixed rules) to learning/adaptive
(change state or take action after updating internal logic schema via learning). If a given
environment has multiple, diverse agent types, it is described as a multi-agent simulation
(MAS). However, it is good modeling practice to limit the complexity of a MAS to only that
required to answer specific questions; as modeling complexity increases, so too does the
effort of verification and validation. Employing ABM for SOS problems in which distinct
decision-making entities exert control has a challenge: how to validate that the agent models
properly reflect real human/organizational behavior. This is a critical question aimed at the
trustworthiness of simulation results. The literature on this subject within the ABM domain is
growing. The most common approach uses as much historical data as possible to validate
the individual agent behavior models and to then trust that the emergent behavior from agent
interactions will be realistic. In this air transportation example, calibration of the agent
behavior rules relied upon historical airline.
The combination of agent-based modeling and network theory provides the core of the air
transportation SOS simulation. The method constitutes a nondeterministic approach, which
means that it fundamentally asks and answers different questions than deterministic models.
The nondeterministic method is necessary primarily due to the marriage of human systems
with technological ones in a partially unknown set of future worlds. The goal is to simulate
how the SOS, human, and technological components combined, evolve. Observing these
simulations allows understanding of this process. The simulation makes significant use of
actual data from today’s transportation system obtained from the Bureau of Transportation
Statistics. Once initialized, a validation exercise confirmed that the simulation could
represent the reality of today’s system, within the bounds on fidelity.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 52
TAREA-PU-WP2-R-LU-9
Figure 10: Simulation Environment of Example Problem [DeLaurentis and Ayyalasomayajula 2009]
The overall framework for the integrated simulation is as follows: stakeholder agents (e.g.,
service providers, infrastructure providers) act to evolve an initialized air transportation
capacity network under various scenarios (figure 10). Each agent employs its logic to guide
its decisions and actions. In subsequent time steps, the agent sees consequences from the
environment and updates its behaviors. As this process unfolds, the magnitude and shape of
the mobility network (demand) also changes, and the actions of agents must respond by
manipulating the capacity network topology. Thus, a family of new network topologies is
created over time, and their structure and network-theoretic analysis tracks their behavior.
The key question is as follows: Do the evolved networks exhibit good performance in terms
of capacity? To address this question, a network evaluator compares the evolved networks
to topologies that do exhibit preferred behaviors. Using this method, the evaluator can
function as the search direction generator for a design/optimization problem.
Figure 11: Simulation Results of Network Saturation under Infrastructure Provide Behaviours
Release Date: 4th May 2012
© Loughborough University 2012
Page | 53
TAREA-PU-WP2-R-LU-9
An example outcome from this simulation approach, presented in (DeLaurentis and
Ayyalasomayajula 2009) appears in figure 11. This result indicates the average saturation of
airport nodes in the network as both the amount of nodal capacity (x axis) and time needed
to implement nodal capacity increase (y axis) are varied. For this study, the intent was to
provide a visualization of the decision space so that a decision-maker(s) can consider
options given the boundaries of behavior change. Selecting a singular optimum from this
decision-space analysis was not intended here. If subsequently desired, the behavioral
rules, connectivity structure, and engineered system capability can act as design variables to
explore the generation of preferred outcomes over an ensemble of plausible scenarios. This
particular result from the ABM showed that a distinct regime of desired behavior emerged
from the interactions between the airline agents growing and restructuring their routes and
the varying capability of the infrastructure agent to keep up via capacity addition.
Please refer to the appendix sections for a summary of current EU / US projects
currently addressing management, control and operation of SoS.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 54
TAREA-PU-WP2-R-LU-9
12 COMPLEX SOCIO-TECHNICAL FEATURES OF SOS
12.1 Human and Organisational Aspects of SoS
SoS contain many types of systems among which are what are often termed, Enterprise
Systems (Chen et. al. 2008). There are many different definitions of enterprise: within a SoS
environment an enterprise system could be described as a complex, socio-technical system
that comprises interdependent resources of people, processes, information, and technology
that must interact with each other and their environment in support of a common mission.
Examples of emerging ‘soft’ issues critical to the design and operation of Systems of
Systems can be identified as follows (see Hubbard et. al. 2010):
• Decision making in SoS, including issues in autonomy, authority, responsibility and
ethics.
• Measures of Enterprise SoS performance.
• Impact of culture and cultural attributes on multinational and multicultural team
performance.
• Systems of Systems Ethics, Governance, and Regulation.
• Shared/distributed situational awareness.
• Alternative approaches to training e.g. virtual reality, gaming.
• SoS lead and lag ‘soft’ metrics e.g. improved mental and physical workload
measurement techniques.
• Enterprise System Agility and resilience e.g. dynamic allocation and reallocation of
function, the human in the loop.
• Enterprise SoS Leadership and motivational issues.
• System of systems sustainability over long time scales.
12.1.1 Enterprise Architectures and Enterprise Architecture Frameworks
The holy grail of being able to look into the future by evaluating the likely effectiveness,
impact or added value of alternative enterprise system configurations, prior to deployment, is
still a long way off. Such a capability would greatly enhance an enterprise’s ability to
dynamically (re-)configure appropriate systems (people, process, and technology) to achieve
the performance required to produce designated capability in different contexts and to avoid
enterprise structures that are susceptible to undesirable emergent behaviour, including
adverse circumstances such as accidents or disasters. Enterprise System models not only
provide the means to visualize, represent, and analyse the inner workings of an Enterprise
SoS, but can also constitute the building blocks of an Enterprise SoS Architecture (EA).
An Enterprise Architecture (EA) is architecture of an organization that supports strategy,
analysis, and planning by stakeholders to determine how the organization can most
effectively achieve its current and future objectives.
An Enterprise Architecture Framework (EAF) provides an enabling methodology to describe
how an EA is organized, structured, and operates in terms of people, processes, product, IT
and resources in order to achieve its goal (Vernadat 1996; Bernus, Nemes et al. 2003;
Chen, Doumeingts et al. 2008). Existing models and enterprise system architectures and
Frameworks (e.g. Zachman, CIMOSA, GRAI, GERAM, VERAM, ToVE, PERA DODAF,
MODAF and TOGAF) tend to deal with enterprise elements such as Resources, Information
Release Date: 4th May 2012
© Loughborough University 2012
Page | 55
TAREA-PU-WP2-R-LU-9
Flows and Functions well, but a) within a process framework and b) they do not show a
sufficient capability to include soft enterprise characteristics such as policies, culture,
competencies, decision making structures etc. within dynamic models. Hence, changes in
one or more of these characteristics are not shown in overall organisational system
performance. The following points can be made with reference to EAs/EAFs:
• Architecture is foundational for managing modern enterprises and planning
enterprise integration.
• An EAF is an organized collection of ingredients (tools, methodologies, modeling
languages, models, etc.) necessary to architect or re-architect whole or part of an
enterprise.
• For a given enterprise, the EA describes the relationships among the mission
assigned to the enterprise, the work the enterprise does, the information the
enterprise uses, and the physical means, human labor, and information technology
that the enterprise needs.
The prime advantage of an EA is to provide a common view (in the form of models) of the
enterprise, and what is supposed to be happening within it, to relevant actors or
stakeholders of the enterprise. The second significant advantage of an EA is that it captures
in available form much of the knowledge of the enterprise and thus provides a sound basis
for the management of change that occurs throughout the life cycle of the enterprise.
Vernadat (1996) combines the two methodologies of enterprise modelling and enterprise
integration and advocates a systematic engineering approach called Enterprise Engineering,
for modelling, analysing, designing and implementing integrated enterprise systems.
12.1.2 Enterprise Modelling (EM)
Enterprise modelling (EM) is concerned with the representation and specification of the
various aspects of enterprise operations; namely, functional aspects to describe what are the
things to be done and in which order; informational aspects to describe which objects are
used or processed; resource aspects to describe what or who performs things and according
to which policy; and organisational aspects to describe the organisational structure and the
responsibility frame within which things are being done. These Enterprise System models
can be combined within an EA framework to provide a dynamic overview of the enterprise
system.
Although there are several models available to assess the structure and performance of
organisations (e.g. Castka 2001; Curtis et. al. 2001; Tannenbaum et. al. 1996), few if any of
these models provide sufficient and robust quantitative and qualitative measures of
performance and none are truly able to provide a direct multi-point, measurable cause and
effect link between the various soft attributes of an enterprise system and its performance
patterns. It is clear, though, that success factors from a human perspective do centre upon
the structure of communication (stakeholder management) and decision making processes
and systems within the overall System of Systems.
12.2 Socio-Technical Boundaries for SoS
There is a particular difficulty in defining the boundaries of a System of Systems when a
socio-technical perspective is adopted, arising from the fact that people are now included. It
is the capacity of people to operate as thinking, decision-making, responsibility-accepting,
Release Date: 4th May 2012
© Loughborough University 2012
Page | 56
TAREA-PU-WP2-R-LU-9
goal-seeking entities that makes them of fundamental importance to organisations, and their
needs for a support network (sustenance, accommodation, training, recompense, etc.) which
significantly widens the boundaries to include many more systems. In relation to
boundaries, time is of significance. For SoS of short duration (e.g. a year or less), many
support systems can be ignored, because nothing much will change within that period. For
longer-lasting systems, perhaps with an expected duration of 50 years or more (in effect,
‘immortal’), issues of sustainability immediately emerge. It is also observable that most of
the long-life SoS are essential to the continuity, safety, security and well-being of citizens in
all the nations of the world, and that many of these SoS are global in extent.
Technically, there will be upgrades to the SoS at various intervals, occasioned by new
technical developments, competitive pressures, and changes in goals for the SoS. Socially,
for the people in these SoS, there is the inevitable churn over time; as pointed out earlier,
within 10 years of operation of a SoS it is likely that some 30% of its human operators and
managers are likely to have been replaced, and all of them will have been replaced within 50
years. It is worth mentioning that the issues discussed in this section also apply to short-lived
(days, weeks) SoS as well, though usually to a lesser extent.
Furthermore, because humans have cognitive skills far exceeding the capabilities of
technical systems in their scope and subtlety, including the ability to know what they don’t
know, the boundaries of a SoS may have to be widened to include sources of information,
knowledge and understanding such as professional societies, web-based networks, and
even more amorphous ‘communities of practice’ (Wenger, McDermott et al. 2004) and
‘megacommunities’ (Napolitano 2010), in which SoS organisations may pass information to
external organisations in other SoS for their benefit, without necessarily having a formal
agreement to do so. In passing, this is a different arrangement to a Japanese keiretsu
because there are no cross-holdings of shares to entrain stability and influence.
Naturally, the definition of SoS boundaries becomes even more difficult when one
appreciates that, for example, other members of the community of practice are probably
protagonists in other SoS; where then are the boundaries? It is clear that some degree of
pragmatism is required, using some stopping rule such as ‘the system and its owner is within
the socio-technical boundary if it is accessed more than 10 times per week, else it is outside
the SoS’.
12.3 Organisational Systems Engineering in SoS
It is reasonable to argue that the kind of organisational systems engineering that is adopted
depends on the class of SoS. (Dahmann and Baldwin 2008) have classified SoS within the
military domain, and have arrived at four classes; Directed, Acknowledged Co-operative, and
Virtual. However, while these classes are conceptually distinct, in practice almost every real
SoS has characteristics of each of these classes somewhere in the enterprise. For brevity,
and in recognition of this fact, we treat SoS as a complex of these classes, distinguishing
between them only when necessary.
The prime purposes of Organisational SoS Engineering (OSoSE) are:
• Maintain the purposes of the SoS, including the strategies and policies that enable
the purposes to be reached.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 57
TAREA-PU-WP2-R-LU-9
•
•
•
•
•
•
Ensure that the SoS configuration is fit for purpose.
Ensure interoperability of the systems that comprise the SoS enterprise.
Ensure that the SoS, and the systems within it, are resilient and agile with respect to
foreseeable risks (Provan and Milward 1995; Barabasi 2002; deMeyer, Loch et al.
2002).
Ensure compliance with legal and regulatory requirements.
Assure distributed situation awareness to minimise the likelihood and consequences
of emergent SoS behaviour.
Enable evolution of the SoS to occur with minimum disruption.
In this section we leave aside considerations of intra-organisational systems engineering in
order to concentrate on inter-organisational systems engineering, albeit recognising the very
close links between the two. Furthermore, we leave aside the networking issues addressed,
for example, by the Network-Centric Operations Industry Consortium (NCOIC 2006),
recognizing that it is the organizational level of communications and structures that is of
interest. Inter-organisational systems engineering is concerned with the ‘fitness’ of the
collection of organisational systems which comprise or own the SoS, the design of the
interfaces between these, and the processes to maintain the fitness of the SoS as time
passes and circumstances change. Whereas the engineering of systems have many criteria
which can be optimised (e.g. agility, economy, performance, etc.), of particular importance
for SoS engineering are resilience and adaptability.
We give three examples; the first is a military example, in which the USAF B52 bomber,
which entered service in 1955 as a high-altitude, nuclear-capable strategic bomber. It is still
in service nearly 60 years later, but is now adapted for a role as a high-altitude, close air
support capability for ground troops, with an appropriately-reconfigured support network
(Willis 2005; Willis 2005). This example demonstrates the evolutionary issue for SoS;
furthermore, it is noteworthy that given the near 60 years’ service lifetime of this aircraft type,
there will be nobody actively involved in the support of its capability who was there at the
beginning – the longevity issue.
The second example comes from software engineering; as Yang et al. have commented
regarding a real-world IT system: “In one case, we observed an outsourced application with
120 COTS products, 46% of which were delivered in a vendor-unsupported state.” (Yang,
Boehm et al. 2005). This indicates an important resilience issue for SoS engineering.
The third example is from the automotive industry (Sheffi 2005). In the 1990s, Toyota
supplier Aisin Seiki made P-valves for brake systems. These anti-skid valves regulate
pressure across the brake system, and this company supplied 99% of all Toyota models.
Factory No.1, manufacturing these valves, caught fire; 506 machine tools were destroyed.
Toyota’s alternate supplier was Nishin Kogyo, making 1%, and unable to ramp up production
fast enough. Toyota at this time was running at 115% of normal production, as a
commercial response to impending legislation.
Because of just-in-time processes, Toyota had only a few hours' stock of valves, with trucks
on the road carrying another 2 day's capacity. Aisin salvaged some tools, replaced others
and was in production in 2 weeks, making 10% of requirements and 60% after 6 weeks, and
Release Date: 4th May 2012
© Loughborough University 2012
Page | 58
TAREA-PU-WP2-R-LU-9
100% after 2 months. Both Aisin and Toyota, in their respective keiretsus, asked for help. 22
organisations from the Aisin keiretsu and 36 from the Toyota keiretsu replied. Within 5 days,
Aisin had made available blueprints and process expertise and production had been
allocated. Notably, Denso, a major Toyota supplier, outsourced their own production to free
up tools and processes to produce these P-valves (as did others), and helped to develop
alternative processes for the valves using different precision tools in other smaller suppliers.
Within 2 days some valves were delivered by these alternate suppliers; within 9 days of the
fire, all Toyota plants were functioning as normal again.
During this period, a neither financial nor legal negotiation took place, nor was pressure
applied to Aisin Seiki to prioritise Toyota over other customers such as Hino trucks.
However, Aisin eventually covered the direct costs - labour, equipment, materials involved
for these suppliers, and Toyota gave their Tier 1 suppliers 1% of their respective sales to
Toyota for the January-March quarter as an appreciation gesture. These firms passed on
the benefit pro rata to their suppliers, and so on.
The examples have been chosen to highlight some of the important issues concerning SoS;
the need for adaptability, resilience and evolutionary planning. These examples are not
unique; other similar (and dissimilar) cases are known around the globe, in different
industries in different countries. Altogether, there are many more aspects influencing
organisational SoSE which seem to be in common, and have been discussed in the
professional literature; for example, (Keating, Rogers et al. 2003; Fisher 2006; Schaeffer
2006; DOD 2008; Rebovich 2008; Sousa-Poza, Kovacic et al. 2008; Jamshidi 2009). We
discuss a selection of the issues below, using the convenient GSPOT classification, with the
classes of Government & legal, Strategic, Policy, Operations and Transaction, while bearing
in mind the common threads across this classification; bounded knowledge, continuous
change, longevity, and the need for resilience.
12.3.1 Government
At this level, the three main considerations are the legal framework that ensures competition,
the governance of SoS, and the implications for society in general should any (or several)
critical SoS fail. The competition issue arises when in a given industry, various groups of
organisations band together to form SoS that are more able to meet market demands, and
thus secure a competitive advantage. At a simplistic level, if most of the organisations
involved become components of various SoS, the net effect is to reduce the number of
competitors in that market. Furthermore, if some of the SoS are larger than others, they may
also accrue an advantage merely due to their size.
For example, a major clothing retailer in Europe was in a position where most national
suppliers to it sent about 30% of their production, making that retailer the major customer
whose contract was critical to the survival of the supplier. This meant that the retailer was in
a very powerful position to control the supply chain. Over a number of years, because of its
size and buying power, the retailer moved into the purchase of raw materials for its supply
chain, with the acquiescence of its suppliers. This evolutionary move meant that the retailer
had control of input to its suppliers, and control over the suppliers’ output, and in principle
resulted in a highly anti-competitive SoS. Fortunately, the retailer was very ethical in its
dealings, so the practical outcome was that the suppliers were buffered from the vagaries of
Release Date: 4th May 2012
© Loughborough University 2012
Page | 59
TAREA-PU-WP2-R-LU-9
the market very well, and goods for this retailer were produced at lower cost compared to the
same goods for other retailers.
In a competitive, capitalist economy, this amounts to a loss of competition, which may lessen
the benefits that society is expected to gain from such an economy. While this argument is
indeed simplistic and somewhat purist, it does point to a role for governmental oversight and
for a legal basis for intervention. Both of these require suitable metrics and trigger points for
governmental action, and these are probably best addressed by the establishment of a SoS
as a legal entity responsible for its actions and the provision of a governance framework for
any such SoS, with provision for measuring the attributes discussed below.
This becomes especially important when a SoS is of critical importance for the security of
society in general; one may consider energy SoS and food distribution SoS as examples of
these. For these, resilience in a changing world is of great importance, and government
policy and legislation may be required to ensure that sufficient resilience is built-in, through
appropriate EU and national government mechanisms.
12.3.2 Strategic
This level is concerned with the strategy of the SoS itself. Its strategy will depend on its
environment, the volatility of that environment, its geographic spread across different
legislations in different states, and the nature of its business domain and its perceived risks
(deMeyer, Loch et al. 2002; Hammer 2002; Tranfield, Denyer et al. 2004; Sheffi 2005; Fisher
2006; Woods and Hollnagel 2006; Sinclair 2007; Siemieniuch and Sinclair 2008; Taleb
2008). There are two important aspects to this; firstly the operational processes that deliver
capability or services that meet the purpose of the SoS, and secondly the maintenance of
the SoS itself as it transforms itself over its lifetime to meet extant exigencies, both expected
and unexpected.
For SoS that may be classed as Directed or Acknowledged, it may be possible to set up
Steering Committees and Management Committees (or equivalents) to manage the strategic
and policy issues that will arise. For co-operative and virtual SoS, it is largely left to the
constituent systems to manage these, through their interfaces. For all of these, and
particularly the Co-operative and Virtual SoS, they will flourish best on a ‘level playing field’
delineated and supervised by governments.
12.3.3 Policy
This general level is more concerned with how the SoS regulates and constrains what and
how it executes its business. It is at this level where considerations such as interorganisational trust, partnering, service level agreements, and contracts are important.
Various fundamental issues such as the potential clash between lean operations and the
need for resilience must be addressed, and plans for risk mitigations are prepared. Of
particular importance in these is the issue of SoS complexity, considered in more detail in
the next section, because of the likely occurrence of unwanted emergent behaviour
characteristic of systemic complexity.
The issue of inter-organisational trust is critical. Because of the bounded-knowledge
problem, most SoS operate with incomplete knowledge most of the time. This implies that
organisations in the SoS must behave with integrity and fairness, in order that other
Release Date: 4th May 2012
© Loughborough University 2012
Page | 60
TAREA-PU-WP2-R-LU-9
organisations may predict with some accuracy the likely behaviour, and operate accordingly.
Some reassurance will be generated by the terms of contracts, service-level agreements
and other formal arrangements; however, unexpected disruptions and other emergent
behaviour is always likely (consider the Aisin-Toyota example above), and it is trust in the
promises and performance of others that enables co-operative solutions to be found quickly.
The intra-organisational conditions for the building of trustworthy behaviour have been
discussed elsewhere (Siemieniuch and Sinclair 2000; Siemieniuch and Sinclair 2002);
however, some implications for the organisational interfaces within the SoS are discussed
below, since they apply to SoS in government, military and civilian domains.
•
•
•
In many inter-organisational interfaces within the SoS, it is the relationship and
authority of the roles on each side of the interface that is important. Authority over
resources is also important, to obtain the swift response necessary to deal with the
day-to-day disturbances and the occasional ‘black swans’ that are characteristic of
SoS operations within noisy environments. An implication of this is that the
interfacing roles should not have long chains of approvals above them in order to
obtain appropriate reactions to events, and maintain the resilience of the SoS.
However, in order for delegation of authority and responsibility to work well, there are
a number of other issues to be addressed; situation awareness, communications,
knowledge and information dissemination being three of these, In other words, the
interfaces should be seen as ‘thick’ interfaces; not just about the transfer of
information and products, but reaching further into the organisations to include their
cultures and ways of working.
Many of the interactions that happen across such interfaces are small-scale
problems that require solutions that are not envisaged in the formal agreements
between organisations, or may require some ‘bending’ of the rules on both sides of
the interface for efficient, swift resolution of the problem. For such exercises to work
well, each organisation must have an appropriate culture; good, distributed
knowledge of operations, ‘work around’ and events; and devolved authority and
responsibility. It also helps if the personnel involved across the interface know each
other well, so that they may trust each other during the rule-bending phase.
One organisation may have several interfaces with another organisation within the
SoS, each managed independently of the other interfaces (e.g. operations,
maintenance, financial, etc). This can create a confused image of each organisation,
depending on the quality of the interfaces. This points to the need for a strong
organisational culture of co-operation, so that the important characteristics for the
SoS are dominant. These are usually honesty, integrity, rapid and effective
response, the willingness to share both benefits and pain, and respect – in short, the
usual characteristics of partnering. These may differ for different SoS, but, whatever
the set, they should be demonstrated across all the interfaces.
12.3.4 Operations
It is at this level where organisational and ITC considerations overlap. The ideal for the SoS
is smooth operations within the established strategic and policy constraints of each of the
individual organisations and of the SoS in which they are embedded. The quality of each
interface between the organisations is critical in achieving this ideal, and we discuss some
issues below; firstly for ITC, and then organisational.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 61
TAREA-PU-WP2-R-LU-9
•
For ITC, the use of well-established open architectures, standards, codes of practice
and agreed terminology is essential. Nevertheless, there remains the problem of
local interpretation of these by the designers of software systems, which in the past
has resulted in different ‘best in class’ systems, supposedly designed in accordance
with the same interface standards, failing to interoperate as consistently as required.
The resilience requirements of SoS indicate that there should be provision within
each interface of sufficiently-skilled personnel to devise suitable ‘work-around’ to
allow the SoS to keep operational until a more complete solution is devised. Since
these failures of interoperation are likely to occur when unusual circumstances
pertain, there is a need for some careful resource planning for this.
•
For the organisation that is contributing a system to a SoS, there are some structural
considerations for resilience and smooth operations within the SoS. A serviceoriented organisational architecture is a good option in most cases, since its priorities
fit the needs of organisations within a SoS. Whatever structure is adopted by an
organisation to suit its circumstances, it is likely that a particular issue will have to be
addressed; the potential clash between process integrity and process delivery.
There will always be pressures, driven by the changing environment of the
organisation; to adjust processes to fit a given SoS needs more economically, or
more effectively. However, if the process also services other SoS, or there are
duplicate processes for other SoS, any such adjustment can result in a loss of
process integrity and resilience. There appears to be no generalised solution to this
issue; each organisation must find its own best solution.
•
There is one other organisational issue related to operations; the organisation may
be running several SoS-oriented processes in parallel, and may be operating them
continuously. On the other hand, its structure may be optimised for clarity in respect
of authority and responsibility; a good business management principle, but not
necessarily a good business efficiency principle. The following quotation is
illustrative (Vaill 1998):
"For example, there was nothing I could do, I learned sometimes painfully, that
did not have its own rhythms and pacings, pauses and accelerations,
beginnings and endings. And time was not a matter of merely academic
interest; it was central to whether I got anything done at all. Furthermore, there
was the problem of the intrusiveness of events: things did not occur one at a
time; no competence could be practiced in pristine singularity. Instead, at any
moment I was flowing with the multiple, disjointed time streams of the various
projects in which I was involved. ... The multiple time streams were, of course,
not co-ordinated in space; they competed for my attention. ... Everything was
interactive. ... I simply had to learn to understand myself in a spatio-temporal
field of relationships, flowing and shifting. It was a field of multiple players, each
of whom had his or her own schedules, expectations of the rates at which things
ought to proceed, and resistances to being sidetracked by other people's
temporal perceptions and priorities."
Release Date: 4th May 2012
© Loughborough University 2012
Page | 62
TAREA-PU-WP2-R-LU-9
The reader may recognize this situation. The growth of the business management
consultancy domain attests to its ubiquity and need for localized solutions. It represents a
continuous tension between the classical drive towards centralization, which imparts
conformity and commonality, and a more decentralized, distributed approach, which
provides greater responsiveness and resilience.
•
•
In addition, there is the issue of potential incompatibilities of operations within the
SoS.
Figure 12 below, from (Gover 1993) illustrates this:
Figure 12: Illustration of Different Organisational Drivers, given the State of Maturity of the Market
It may be that different organisations within a single SoS are at different stages of lifecycle
maturity of the market, as shown in figure 12 above and hence have different drivers and
management styles appropriate to these. Clearly this could present incompatibilities on each
side of an inter-organisational interface. Equally clearly, the possible existence of these
incompatibilities indicates the importance of the considerations discussed above, necessary
to ameliorate these incompatibilities.
12.3.5 Transactions
At this level, ITC plays a critical part. From an organisational perspective, the goal for
transactions is to deliver at the interface(s) the content of the transaction (product, capability,
information, etc) on time, in full, and at acceptable quality, according to service level
agreements. Organisationally, this requires attention to all of the matters discussed above in
this section. From an ITC perspective, this implies attention to architectures, networks,
protocols, taxonomies, and security issues, all of which are discussed elsewhere in this
document. No additional comments are required here.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 63
TAREA-PU-WP2-R-LU-9
12.3.6 Summary
This section has discussed a number of impediments to the efficient and effective operations
of an SoS. These impediments occur at a number of levels, ranging from the super-SoS
level where governmental and regulatory issues are addressed, down to the level of
transactions, which are the real-world expression of the functionality of the SoS.
12.4 The Effects of Organisational Complexity on SoS
Having mentioned the term, ‘complexity’, in the discussions above, it is timely to ensure
clarity of meaning for the term, from an organisational perspective. The significance of this
topic is that, by the very nature of the SoS concept, it suffuses all aspects of the SoS.
Sometimes, complexity within the SoS comes to the aid of the purpose and operations of the
SoS; more often complexity manifests itself in emergent behaviour that is detrimental to the
smooth functioning of the SoS.
Unfortunately, there are a number of definitions, some of which are included below.
• “The complexity of a system corresponds to all possible expressions of
relationships that are available to a system that also preserve its identity, including
those that it actually expresses at any given time (i.e., its order).” (Kuras and
White 2005).
• "A complex adaptive system is formally defined as a system of independent
agents that can act in parallel, develop “models” as to how things work in their
environment, and most importantly, refine those models through learning and
adaptation.[Pascale 2000]” (Sheard 2005).
• “Complexity is a behavioural characteristic of the network of agents and
relationships that make up the system. It is not decomposable to individual
elements or relationships.” (Siemieniuch and Sinclair 2002).
• “Complexity is really just reality without the simplifying assumptions that we make
in order to understand it.” (Allen, Boulton et al. 2005).
• "Roughly, by a complex system I mean one made up of a large number of parts
that interact in a non-simple way. In such systems the whole is more than the
sum of its parts, not in an ultimate, metaphysical sense but in the important
pragmatic sense that, given the properties of the parts and the laws of their
interaction, it is not a trivial matter to infer the properties of the whole. ” (Simon
1981).
Characteristics of an organisation/SoS that define it as complex are (Gregg 1996). :
• Many agents, of different kinds.
• Some degree of behavioural autonomy for agents.
• Multiple steady states for agents.
• Interactions between agents in an environment.
• Lots of connections between agents.
• Communicating in parallel.
• Effects of an evolving environment.
• Effects of evolving agents.
• Interactions between different goals within an agent.
• Interactions between agents with different goals.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 64
TAREA-PU-WP2-R-LU-9
•
Language/culture differences.
As Gregg pointed out, “If several of these are present, the global behaviour of the system is
likely to be unpredictable, long-term”. Before going on to discuss some of the managerial
implications of this, there is one other factor to mention. This is the ‘Law of conservation of
complexity’, attributed to (Woods and Hollnagel 2006):
"Complexity is conserved under transformation and translation".
This does indeed appear to be a law as observed empirically and is in accordance with the
definitions given above. However, there are two loopholes; firstly, it seems to be possible to
translate complexity to different parts of the SoS which provide a more amenable
environment where managerial action can ameliorate the effects of complexity more easily
and more effectively. Secondly, it is necessary to distinguish between two types of
complexity; induced and intrinsic. Intrinsic complexity is in the nature of the problem being
addressed, and conforms to the law above. Induced complexity, on the other hand, arises
from the way in which the SoS (or its component organizations) organize themselves to
address the situation. Induced complexity can be reduced, or even near-eliminated, by
appropriate organizational design, and the considerations discussed in the section above will
assist in this.
Complexity per se is not a problem; it is only when one desires to operate an organization or
SoS effectively, economically, smoothly, according to lean principles, etc. that the problems
occur. These problems are due to emergent behaviour, typically arising from the
characteristics listed above. Since at least several are endemic to all organizations, it
follows that resilience, particularly in SoS, is a critical attribute for a SoS to possess. We
turn now to a discussion of resilience.
12.4.1 Approaches to Complexity and Resilience in SoS
Two portmanteau concepts encountered in discussions of SoS are Agility, and Resilience.
Depending on the author, each can include the other. For the purposes of this section, we
assume that one cannot be resilient unless one has agility. The definition of resilience, then,
is as follows:
"…the capacity of a system to absorb disturbance and reorganize while
undergoing change so as to still retain essentially the same function, structure,
identity, and feedbacks". (Walker 2004).
Organisationally, several characteristics are required to be resilient:
• Organisational coherence is critical, and implies:
o better design of the organisation to reflect the needs and purposes of the SoS roles, responsibilities, authority, resources, rewards, etc.
o shared values, culture and goals
o open access to information and knowledge
• Process measurement is critical
• Acceptance of organisational replacement both within organisation and within the SoS
• Conflict management is a necessary skill for all middle and top-level managers
Release Date: 4th May 2012
© Loughborough University 2012
Page | 65
TAREA-PU-WP2-R-LU-9
Unfortunately, providing solutions to these requirements is not trivial. Adapting Alberts in his
discussion of complexity and agility (Alberts 2011):
• Because emergent behaviour is a major characteristic of complexity, it removes the
use of reductionism as an approach to understand SoS problems. Instead,
understanding must come from experience and simulations, through the recognition
of patterns
• Because we cannot predict the long-term future, we cannot determine whether an
envisaged solution is good or bad, long-term. This implies that resilience is a critical
attribute for SoS, together with close attention to the trajectory of the SoS in time, so
that the patterns and associated lessons from the past are not repeated.
• Adopting an incremental change approach as an alternative way forwards is unlikely
to work all the time, because it may encounter emergent discontinuities in SoS
behaviour, due to discontinuities or alternative attractors in the SoS overall response
surface. Nevertheless, given a resilient SoS and an environment of lower rugosity, it
is one of the more safe ways to evolve the functionality and performance of the SoS.
• Because of the inherent characteristic of bounded knowledge in the SoS, it is
probable that problem solvers will face situations that they do not completely
understand and most probably cannot hope to understand. Simulation may help in
this, as will the avoidance of decisions that cannot be undone, since recovery from
terminal decisions that turn out to be bad ones may not be possible.
• Because emergent behaviour tends to be local, with possible global consequences, a
centralized, top-down organizational approach to design and operation of a SoS is
unlikely to succeed. The best that one can hope for is to exert some leadership to
keep behaviours within acceptable bounds, to ensure that the organization is agile
with well-informed people, to ensure that decision-making is devolved rather than
centralized, and then rely on resilience to maintain progress.
This last list is something of an exercise in doom and gloom; fortunately, it should be noted
that SoS vary in the stability of their environments and internal characteristics, so that for
some SoS, a standard approach will work well. For others, this is not so, and it is useful to
consider other managerial approaches. Adapting (deMeyer, Loch et al. 2002), we may offer
the following classification of approaches:
• Stable environments (i.e. ‘normality’ is an achievable, recognisable state). Orthodox
managerial approaches are sufficient
• Foreseeable uncertainty (i.e. likely disturbances and changes are foreseeable, but not
their timing). This environment requires risk management techniques, decision trees and
preparatory planning, to enable appropriate, agile adjustments to whatever happens.
• Unforeseeable uncertainty (i.e. there is no Plan B). Managers are required to be flexible
orchestrators, networkers, and ambassadors. Trust within and between organisations is
critical. Scan horizons continuously, and sign flexible contracts. It is worth noting that
although most disturbances will fall into the above two classes, there will be occasions
when the SoS will find itself faced with something unforeseen, as in the Aisin-Toyota
example discussed earlier.
• Fast-changing or chaotic environments (for example, due to disasters). Managers must
be entrepreneurs and knowledge managers. Resilience depends critically on having
long-term relationships beyond individual SoS lifecycles.
Inter-organisational
relationships must be based on trust and handshakes, rather than formal negotiations
Release Date: 4th May 2012
© Loughborough University 2012
Page | 66
TAREA-PU-WP2-R-LU-9
and legal documents. Continuous, ruthless concentration on go/no-go decisions will be
required, with planning horizons limited to the next identifiable decision point.
Fortunately, the issues and recommendations in the previous section, with a few changes in
emphasis, will provide the means to deliver these different managerial approaches.
12.5 Decision Making in SoS
12.5.1 Authority, Responsibility & Autonomy
There is an established classification of SoS (Dahmann and Baldwin 2008) with the following
four classes (as stated in the chapter 2.3): Directed, Acknowledged, Collaborative, Virtual.
While this is a convenient abstract classification, it should be understood that real-life,
instantiated SoS have lifecycle considerations, and that when lifecycle and infrastructural
needs are included, an SoS may have attributes of more than one of these classes. Since
this is the common case, the rest of the discussion in this section will be directed at this
case.
‘Authority’ in this section is defined as the assigned power to entrain identified resources, to
organize them to achieve a given purpose, and to and to control the operation/utilization of
these resources. Authority may be delegated to lower-level entities (people, systems …), or
may be handed over completely at the interface to another organization.
‘Responsibility’, on the other hand, is the state of being held to account for the exercise of
authority, and, under current legal conventions, is a characteristic of humans, not of devices.
‘Autonomy’ implies the right and the authority to make independent decisions; however,
there may be constraints on the kinds of decisions, and the scope of autonomy; for example,
a police robot (as a component of a SoS) may have the restrictions that it can use its crowdcontrol weapons over there, but not here, and can use non-lethal weapons such as water
sprays autonomously but must seek authorization before using potentially-lethal weapons.
These constraints within SoS arise because there is some higher authority which has
delegated authority to a lower-level entity, or because of contractual arrangements. As an
aside, because of the legal situation regarding responsibility, it is difficult to conceive of any
scenario in which a device would be completely autonomous; in fact, as Sheridan et al. have
recommended, devices should not have delegated autonomy greater than level 5 or 6 on
their 10-point scale (Parasuraman, Sheridan et al. 2000).
Bringing together the paragraphs above, the operation of a SoS will be subject to
combinations of authority, responsibility, and resultant autonomy. Authority may be
distributed across the SoS by delegation and hand-overs; this distribution and the
constraints attached will define which resources can be used for what purposes under which
conditions for what period of time. Delegation implies the allocation of responsibility, but only
to humans. Hand-overs pass all responsibilities to another organisation, or to another
system within the same organization. If a system (or SoS) behaves with any degree of
autonomy, then, to adopt the military convention, the responsibility for its activities currently
rests with the last person to authorise the action of the system. This particular responsibility
may then be traced up the responsibility chain that is defined by the delegation of authority,
depending on the legal circumstances.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 67
TAREA-PU-WP2-R-LU-9
Dependent upon the scale and complexity of interactions between contributing systems in a
SoS, issues of governance may arise. The abstract principles discussed above may be
confounded by these complexities in the case of instantiated (rather than idealized) SoS.
There is a need for research to develop theory and practical approaches for ensuring
resilience of SoS and the associated safe and secure operation.
12.5.2 Decisions & Decision-Making at the SoS Level
At the SoS level, three characteristics of the SoS that are important for decision-making are
the imprecision of the SoS boundaries (“do we know where the effects and side-effects of
decisions end?”), the inevitable bounds on information and knowledge available to decisionmakers (IPR constraints, conservation of competitive edge, condensation and timeliness of
data, evolution/retirement of knowledge within SoS organisations, understanding of societal
patterns, …), and the complexities of SoS operations. Together, these three characteristics,
save for the special case of directed SoS, imply that decision-making will occur sequentially
in a dynamic environment, that sequences of decisions will occur in parallel, that these
decisions will be made with partial information, and that there will be a non-zero likelihood of
emergent, unwanted side-effects. Insofar as this description is correct, it implies that
decisions should always be made with a horizon in mind, and that terminal, irretrievable
decisions should be avoided whenever possible.
Since complexity considerations imply that there may be discontinuities in the response
surface resulting from a decision, and that local effects of a decision may propagate globally
over time, there is an implication that decisions should be more in the nature of goals,
guidelines, and co-ordination needs rather than directives and commands, so that
implementations of these are delegated to the organisations that own the component
systems. By delegating the implementations, it is more likely that local circumstances will be
taken into account, thus likely reducing the unwanted side-effects. Conversely, there could
be a loss of co-ordination and of efficacy of the implementations, and even more importantly,
a loss of clarity on the delegation of authority, and a corresponding loss of clarity regarding
responsibility chains. While there has been a significant interest in simulation tools that can
be used to explore this area, there would seem a need to carry out further exploration and
analysis of this area.
Useful work has been carried out in the realms of decision-making, albeit without direct
commentary regarding the SoS context. Following (Alberts 2011), it is likely that at the level
of SoS, trade-space analyses (Ross, Hastings et al. 2004; Roberts, Richards et al. 2009)
would be beneficial within a MBSE environment as a front-end process for simulation
studies. In turn, particularly for SoS of critical importance, the outputs of these studies may
be used in organizations designed in accordance with the principles of high reliability
organizations (Rochlin, LaPorte et al. 1987; Weick, Sutcliffe et al. 1999; Weick and Sutcliffe
2001; Robertson 2005) to reduce the likelihood of disastrous decisions.
12.6 Legal and Ethical Implications for Societal Acceptance
Consider a fictitious example, abstracted in abbreviated form from (Wallach and Allen 2009):
“Monday, 23 July 2012 starts like any ordinary summer day, with peak electricity demand
expected to be high. Energy costs are high and speculators have driven up the spot price of
oil, which stands at $300 per barrel.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 68
TAREA-PU-WP2-R-LU-9
At 10.15 the price of oil drops slightly on reports of an oil find near the Bahamas. Software
at an investment bank calculates that it can turn a profit by emailing 25% of its customers
with a ‘buy’ recommendation, while selling futures short to the rest of its customers. This is
unethical, caused by different software programs interacting in ways not understood by the
bank staff. The ‘buy’ emails work too well, and the spot price rises fast. Software controlling
New Jersey‘s power grid calculates that a transfer to coal-fired stations is required; however,
one of the stations suffers an explosion while running at peak capacity and black-outs
cascade across the east coast, affecting Wall Street and closing the oil market. However,
the SEC software has reported the unethical behaviour and during the blackout the news
spreads. It is clear that the spot market will unwind fast, with losses of $millions for
investors.
Detecting the spreading black-outs as a possible terrorist action, security screening software
at Reagan International Airport raises the threat status to maximum, and rescans its data on
current travellers with enhanced criteria. It detects a cluster of 5 passengers bound for
London on a single flight who might be terrorists. The software triggers a ‘lock-down’ on the
airport just before the flight leaves, and a Homeland Security team heads for the departure
gate. There is a scuffle, and shots are fired. This causes an alert from the Dept. of
Homeland Security to all airlines that a terrorist action may be occurring. Airlines tell their
planes to land, and there is a collision between two planes at O’Hare airport in Chicago,
killing 157 passengers.
This adds to the confusion, and a full alert goes out. This results in automatic guns on the
US-Mexico border being given autonomy to fire. One of these detects an off-road vehicle
coming from near the border and opens fire, killing a group of US citizens.”
This example can be classified as a hierarchical, combined Directed/ Acknowledged SoS
utilising advanced, semi-autonomous automated systems, which exhibits considerable
emergent behaviour with cascading effects, and significant unethical consequences for
society as a whole. It is indeed fictitious, but recognisable as a possible, plausible future.
There are two implications that are evident in this exemplar:
•
The cascading effects are caused at least in part by transfers of data, without
accompanying context and meaning. This allows different organisations with access
to the data to use different criteria to reach their conclusions, and then act
accordingly. It points to the dangers of linking networks, but not organisations and
their knowledge – a known problem under the heading of ‘shared awareness’. There
may be security or legislative reasons for this gap, which in turn indicates a need for
a guidebook for SoS issues that deals with the full range of GSPOT issues,
problems, and classes of solutions, especially where safety-critical SoS are
concerned.
•
The harmful effects resulting from the SoS processes are distributed and involve
many people who have no connection with the SoS other than happening to be within
its sphere of influence, and in principle these effects could occur under markedly
different jurisdictions. As Asaro has pointed out (albeit in a context of criminality),
under World Trade Organisation rules, if the servers and software involved in the
Release Date: 4th May 2012
© Loughborough University 2012
Page | 69
TAREA-PU-WP2-R-LU-9
SoS are located in different jurisdictions to those where the effects happen, there is
little that can be done to redress the situation (Asaro 2011), and experience indicates
that whatever can be done will take some time to be done. Many initiatives regarding
inter-governmental co-operation and protocols are under way; it is hoped that they
will address these issues as well.
While the discussion above is concerned with legal aspects, there are ethical aspects as
well. These are more complicated, because what is considered ethical differs for different
cultures (for example, the cultural status of women around the world), is open to debate
within those cultures, and is not well documented. The closest there is to a global set of
ethics are the following, signed by sufficient states to have become customary law (i.e. they
apply, irrespective of whether a state has signed them):
• International Covenant on Civil and Political Rights
• International Convention on the Suppression and Punishment of the Crime of Apartheid
• International Covenant on Economic, Social, and Cultural Rights
• Convention Relating to the Status of Refugees and Protocol Relating to the Status of
Refugees
• Convention on the Rights of the Child
• Convention Against Torture
• Convention on the Elimination of All Forms of Racial Discrimination
• Convention on the Elimination of All Forms of Discrimination Against Women
• International Convention on the Protection of the Rights of All Migrant Workers and
Members of Their Families
• Convention on the Prevention and Punishment of the Crime of Genocide
• Convention on the Rights of Persons with Disabilities
• International Convention for the Protection of All Persons from Enforced Disappearance
• Indigenous and Tribal Peoples Convention, 1989
There are regional conventions, too; within the European Union (signed by most states),
there are:
• Charter of Fundamental Rights of the European Union
• Convention on Action against Trafficking in Human Beings
• European Charter for Regional or Minority Languages
• European Convention on Human Rights
• European Convention for the Prevention of Torture and Inhuman or Degrading
Treatment or Punishment
• European Social Charter, and Revised Social Charter
• Framework Convention for the Protection of National Minorities
In the Americas (some of which have not been signed by the United States), there are:
• American Convention on Human Rights
• Inter-American Convention to Prevent and Punish Torture
• Inter-American Convention on Forced Disappearance of Persons
• Inter-American Convention on the Prevention, Punishment, and Eradication of Violence
against Women
Release Date: 4th May 2012
© Loughborough University 2012
Page | 70
TAREA-PU-WP2-R-LU-9
•
Inter-American Convention on the Elimination of All Forms of Discrimination against
Persons with Disabilities
However, it should be pointed out that generally, conventions exist to protect individuals
against actions of the state, rather than regulating inter-personal or person-entity
relationships. It may be appropriate for the European Union to consider the need for a
formal statement embodying more completely some form of the ‘do no harm’ principle in
respect of the behaviour of SoS of whatever class.
Please refer to the appendix sections for a summary of current EU / US projects
currently addressing complex socio-technical features for SoS.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 71
TAREA-PU-WP2-R-LU-9
13 SOS PERFORMANCE MEASUREMENT
13.1 Concept of MoE
The concept of performance measurement has long been part of designing SoS. Advances
in the field of ICT have enabled formalised methods to become part of design efforts for
most single complex systems. When addressing a single complex system, most design
strategies focus on minimising or maximising an objective while meeting several constraints.
These objectives and constraints typically characterise the performance of an individual
system; however, these design strategies rarely address the impact of performance of a
larger SoS, nor do they usually address the dynamic, evolving environment in which the SoS
must act (Crossley 2004).
In SoS context, performance measurement is more appropriately known as “Measure of
Effectiveness” (MoE). In a single system, performance describes what a system does
whereas the effectiveness describes what SoS do in relevant context or scenario. For
example, if an aircraft flies 1,000 nautical miles at 40,000 feet, this is a performance
statement. The same aircraft has different effectiveness at completing a mission if the 1,000nautical-mile distance is over water or over a hostile country. Therefore the MoE is a
criterion used to assess changes in system behaviour, capability, or operational environment
that is tied to measuring the attainment of an end state, achievement of an objective, or
creation of an effect (Jamshidi 2008). As SoS evolve through its acquisition and deployment
phases, management defines and derives these effectiveness measures, where data can be
taken from a variety of sources such as testing, simulations, and experimentation.
These measures can be expressed in terms of critical themes (features) such as Agility,
Interoperability, Dependability, Availability, and Affordability (Urwin, Gunton, Reay Atkinson,
& and Henshaw, 2011). Whether these are considered in the operational (defence) or
organisational context (supply chain), collaboration underpins them; that is to say, the
effectiveness of collaboration between the systems’ stakeholders constitutes a significant
enabler or barrier in the development and use of the systems. Finally, it is asserted that
managing the systems over the course of their lifetime requires effective management of
knowledge among the contributing parties. The relationships between these themes are
important; the effectiveness of the systems deployed is determined to a large extent by the
trading that is done between the five main themes as described in detail within the chapter
8.1.1.
13.2 Some Challenges in Measuring SoS Performance
A number of challenges exist when considering performance metrics of SoS. Firstly, due to
the emergent nature of SoS, it is almost impossible to test all the possible configurations
such as safety and security requirements. The other most important aspect of SoS is the
need to integrate legacy systems effectively and design new systems that are flexible
enough to provide an accepted level of interoperability within the SoS. Thus, Interoperability
must be prioritised when designing and progressing through a SoS project.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 72
TAREA-PU-WP2-R-LU-9
Currently no universally agreed and general set of metrics for measuring SoS performance
exists; indeed, it is not clear that such a set is possible as the inputs to the systems within
SoS are unknowable or unclear due to its emergence property. It is a challenging task to
have a comprehensive and complete set of apparent performance metrics prior to the SoS
deployment for operation. Extensive research is needed to determine: what MoEs exist for
SoS (if any); general metrics and the tailoring process for specific applications; metrics that
are composed of heterogeneous systems attributes; associated measurement techniques. In
fact, the whole process of metric selection, measurement collection, analysis, storage, and
its disposal should be understood for effective SoS management and operation (Perl 2005).
Please refer to the appendix sections for a summary of current EU / US projects
currently addressing SoS performance measurement.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 73
TAREA-PU-WP2-R-LU-9
14 SOS TECHNICAL AND ENGINEERING GOVERNANCE
Across all domains (e.g. industrial, health, government, transport, manufacturing, defence
etc.) there is an exponential growth in the complexity of the systems and System of Systems
(SoS) at work in our industrialised society. The developed nations in particular now depend
critically on a wide range of engineered SoS for their integrity and even survival, let alone the
creation of value. Furthermore these SoS are pervasive throughout our societies and are
increasingly interlinked in a global and distributed fashion. Upgrades or new systems are
required to fit into this complex SoS environment - rarely will they be standalone - and
current engineering, governance and control strategies need reconsideration in order to
cope with the resultant degrees of uncertainty and unpredictable emergent behaviour that is
endemic in the design and operation of these SoS.
Despite the fact that our safety, health, education, security, etc. depends on the steady,
reliable functioning of these SoS, we do not understand much about the multiple, non-linear
connections and dependencies among component systems nor of the way that they may
self-organise and co-evolve within a constantly changing environment over a lifetime.
Certainly, we often have in depth expertise and knowledge about the characteristics and
behaviour of individual component systems within an SoS and significant strides have been
made at the lower levels of systems in terms of the safe, efficient and reliable operation of
tasks and procedures (what could be termed individual ‘system awareness’), but we still do
not properly understand or have models of higher level contextual factors that would
constitute what might be termed overall ‘SoS situation awareness’, which is essential to SoS
technical and engineering governance (TEG) required to maintain ‘normal, safe operations’
of the overall SoS.
14.1 Background
Complex systems and SoS are usually developed by complex supply chain systems,
comprising single and multi-disciplinary teams, often globally distributed. The distributed
nature of these teams, allied to the parallel design streams, and the number of different
levels of hierarchy that usually exist, make it imperative to maintain good control in order to
meet contractual obligations for the delivery of component systems of a SoS.
Corporate governance aims to assure shareholders of the financial state of a company and
the level of (good) control imposed over it by the board. It has become a core topic in recent
years illustrated by the collapse of Enron and the ensuing Sarbanes-Oxley Act of 2002. In
the EU, we can point to the Nimrod report (Haddon-Cave 2009) and the recent and on-going
crises in the Banking world and European economies.
Now that some transparency of control has been established over the financial aspects of an
enterprise, it becomes necessary for other aspects of an enterprise that involve risk to be
governed. Companies where engineering is a major activity, face a tremendous amount of
risk to their business, and this risk is multiplied where a number of different added factors
are taken into account. Such factors include:
• Businesses that have recently been consolidated. Multiple processes from different
legacy organisations will continue to be applied (both formally and informally) for some
time within the business. Even when some degree of uniformity is brought about, the
Release Date: 4th May 2012
© Loughborough University 2012
Page | 74
TAREA-PU-WP2-R-LU-9
•
•
•
•
people involved will operate these from legacy cultures and viewpoints. How can this
situation be governed effectively?
Businesses that are involved in collaborative projects or extended supply chains.
Increasingly, large engineering contracts are being awarded to consortiums of (possibly)
multinational partner organisations. How should distributed engineering activities in this
type of context be governed to ensure that engineering quality and requirements are
met?
Organisations that are engaged in many different projects at the same time are working
at different stages in the SoS engineering lifecycle. How is it possible to govern
engineers that are (concurrently) working at multiple lifecycle stages?
Supply chains will vary in size, content and influence over the life cycle of an SoS. How
can governance be maintained throughout an entire supply chain under these
circumstances?
In essence, TEG addresses the twin questions, “Are we doing the right things?” and “Are
we doing those things right?”. TEG is focussed on the control that is present through the
hierarchy of the supply chain system with respect to the engineering function. This
control is an important lever for the SoS ‘owners and operators’ who want to assure
customers, stakeholders and shareholders that a delivered SoS will meet its
requirements in a safe, effective and efficient manner.
14.2 Aims of Technical and Engineering Governance
Any kind of Technical and Engineering Governance (TEG) framework should aim to control
and monitor the engineering function in an effective way, but with the prime aim of not stifling
innovation which is necessary to retain a competitive edge. The following are an initial
proposed series of objectives that a TEG framework should aim to achieve:
•
•
•
•
•
Manage the engineering function along the SoS lifecycle effectively and efficiently in
order to meet or comply with all requirements placed upon it from the
customer/stakeholders, other internal business functions (e.g. finance) and any
external usage, safety or other constraints in the SoS environment.
Comply with any associated engineering legislation that may impact on the design or
operation of the SoS. An example of this would be airworthiness requirements.
Ensure that the engineering function is flexible and adaptive to change since SoS
requirements from customers/stakeholders are likely to change over the life-cycle of
the SoS, dependent on need and changes in the SoS environment.
Ensure that the engineering function is acting in support of the overall enterprise
system delivering the SoS. In some enterprise systems there is a large wall between
the engineering function and the rest of the business which can breed an ‘us-andthem’ attitude which is counter-productive for the enterprise. Therefore the
engineering function should be transparent, decisions should be traceable and clear
communication links and interfaces with other key functions of the enterprise system
should be established.
The engineering function should be aware that SoSE risks can have a large impact
on the enterprise as a whole. Engineering should manage and control these risks so
as not to impact on the rest of the business.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 75
TAREA-PU-WP2-R-LU-9
•
Deploy ‘best practice’ processes in the different engineering areas and ensure that
key decision making roles are clearly identified. The engineering function should
ensure that the configuration of competences among its staff is optimal, and deploy
those competent staff to roles in the most effective and flexible way.
Table 3 attempts to present an initial draft set of objectives for a baseline TEG framework:
Management
Board/Enterprise
Level
Corporate Governance
Evaluate all business
risks.
Set overall business
strategy
Assign
responsibility
throughout.
Select
independent
auditors.
Enforce a code of
conduct.
Reward employees.
Provide
shareholder
value.
Be accountable for
social response
Business Unit Level
Project Level
Board Level
Ensure Engineering is
managed
to
meet
business strategy.
Ensure the efficiency of
engineering
is
maximised.
Ensure
sufficient
resources are allocated
to engineering.
Project Manager
Ensure
regulations
are met.
Ensure
relevant
standards are met.
Ensure requirements
are achieved
People
HR Director
Ensure
remuneration
and pension’s policy is
in place.
Set a Health and
Safety policy (avoid
corporate
manslaughter)
Promote a company
culture that rewards
commitment
and
learning.
Ensure
suitable
managers are recruited
and promoted.
Ensure a company
training strategy is set.
BU HR manager
Ensure engineering is
communicating with the
other functions.
Deploy engineers in an
effective and flexible
way.
Recruit suitably skilled
engineers.
Ensure suitable training
is available.
Line manager
Ensure engineers are
aware of their roles
and responsibilities.
Ensure engineers are
reviewed
against
roles
and
responsibilities.
Ensure
engineers
have
relevant
training.
Process
Engineering Director
Provide
a
comprehensive
framework
of
engineering processes.
Monitor
process
performance
Monitor
standards
performance
Process
Working
Groups
provide a framework of
processes tailored to the
specific business.
Aid
process
improvement.
Aid decision making
traceability.
Provide a series of
value-added metrics.
Process Users
Allow for tailoring of
processes to specific
projects.
Ensure engineers use
all
mandated
processes.
Ensure metrics are
used
where
they
would aid a process.
Technology
Engineering/IT Director
Tools/Methods WGs
Engineers
Release Date: 4th May 2012
© Loughborough University 2012
Page | 76
TAREA-PU-WP2-R-LU-9
Board/Enterprise
Level
Ensure
IT
and
communication
networks enable quality
engineering.
Direct R&T activities to
ensure provision of SoA
tools and methods
Business Unit Level
Project Level
Provide
Tools
that
enable
quality
engineering
Provide Training
Ensure Tools/Process
/Roles match.
Ensure
appropriate
tools
and
technologies
are
used.
Ensure feedback on
any tool changes is
acknowledged.
Table 3: Baseline Set of Objectives for the Introduction of a TEG Governance Framework.
14.3 Possible Model of Technical and Engineering Governance (TEG)
The context of governance at different sites involves several issues including TEG goals and
strategy, policies, existing TEG processes and any recognised TEG problems or risks. Work
on an EPSRC Innovative Manufacturing and Construction Research Centre Project at
Loughborough University (Nendick, Siemieniuch et al. 2006) proposed a To Be Model for
Engineering Governance which is provided in figure 13. Three key components are
fundamental to this model:
•
•
Governance Agents are the people involved in some way with governance flows.
Agents include top-level executive management who govern the engineering
function, line managers, right through to engineers and technicians who work along
the supply chain system. The structure of the relationships between the various
agents is complex, varied and sometimes informal. Therefore, the modelling of
agents and the structures of relationships between them is a crucial step to
understanding the current state of TEG within a particular supply chain system.
Governance Mechanisms define the actual implementation of TEG through the
business. Different enterprise systems are likely to use a different array of
mechanisms depending on the specific circumstances or the nature of the SoS that is
being delivered. It has been established that there are 8 main classes of mechanisms
commonly in use throughout engineering organisations. The 8 classes, with
examples are:
o External drivers – These are standards such as ISO-9000 that may be
mandated through customer requirements.
o Internal drivers – Initiatives such as CMMI.
o Regulations – Laws with regard to product safety, the environment etc. that
individuals are responsible for complying with.
o Structure – Including the engineering management hierarchy and Roles and
Responsibilities of agents.
o Process – Systems engineering and lifecycle processes that specify how
certain activities should be carried out.
o Tools – The tools, such as software packages, that support other
mechanisms.
o Groups – Groups such as committees, working/steering groups and peer
reviews.
o Informal – Other informal mechanisms such as management styles and
culture.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 77
TAREA-PU-WP2-R-LU-9
Two critical issues will immediately be apparent: the existence of these mechanisms is not
enough- it is in the execution of these that governance resides, and this depends on the
disciplined, motivated approach of the personnel involved; secondly a disciplined, motivated
approach to any organisational goal depends on the company culture, structure of authority,
and leadership. If engineering governance is to be assured, then these issues must be
addressed as well. The development of an overall control subset within the engineering
governance framework will be key to this.
• Governance Feedback is crucial to gauging the effectiveness of the TEG strategy at
any one time. All enterprise and supply chain systems will employ some kind of
governance feedback, whether aware of this or not. Examples of governance
feedback include:
o Audits – Full assessment of the state of governance (mechanisms).
o Whistle-blowing channels – Give those at the bottom of the management
structure a link to the top for important matters.
o Metrics – Special metrics to evaluate aspects of governance.
o Meetings – Hold meetings with agents at different levels.
Figure 13: Framework for Engineering Governance
14.4 TEG Framework for Implementation
An ‘ideal’ implementation of engineering governance would enable engineering
management to assure the board of the company that the engineering function will not
produce any surprises and will manage risk effectively. This assurance can then be included
with all of the normal reporting that the board has to make to shareholders with respect to
corporate governance. Figure 14 aims to demonstrate this.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 78
TAREA-PU-WP2-R-LU-9
Figure 14: An Outline of TEG Delivery Structures
A particular issue that must be considered here is the effect of complexity. As outlined
above, the conditions exist for unpleasant surprises (or emergent properties) to occur in the
SoS being delivered, even in an environment of dedicated engineers, doing their best to
meet their goals. These could be due to many factors, apart from cutting-edge issues in
engineering. These include such things as different groups reaching different levels of
maturity in the design of inter-related components or systems, unexpected interactions
between unrelated components or systems, different interpretations of documents and
drawings, and so on. Because of the nature of complexity, it precludes top-down control, and
demands a degree of self-government throughout the engineering enterprise. The delivery of
organisational structures and training that encourage this, are important. It then becomes
necessary to deliver governance structures, through the considerations outlined above, that
will ensure wide-spread engineering situational awareness so that the undesirable emergent
behaviours that are a characteristic of complexity can be minimised.
Please refer to the appendix sections for a summary of current EU / US projects
currently addressing SoS technical and engineering governance.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 79
TAREA-PU-WP2-R-LU-9
15 RISK MITIGATION IN SOS
15.1 Risk and its Ownership
The enterprise nature of Systems of Systems creates some challenges in terms of where
risk may lie in the development and operation of systems of systems. At the level of major
infrastructure projects, which by their very nature can be considered to be SoS, Flyvbjerg, et.
al. (Flyvbjerg, Bruzelius, & Rothengatter, 2003) have argued that risk is inadequately
understood and often deliberately underestimated in order to win contracts. It is certainly the
case that uncertainty is frequently confused with risk, leading to poor decision making (De
Meyer, Lock, & Pich, 2002). Uncertainties within SoS lead to risks which can be handled by
mitigations, which hopefully lead to desired outcomes. Risks are created by the uncertainties
that are specific to a SoS in question (McManus 2006).
It has been argued that the traditional models and methods for calculating risk are flawed for
complex situations (Hubbard, 2009); it is certainly true that where a project has a great many
unlikely, but high impact risks, the likelihood of at least one of them occurring is greater than
traditional risk calculations indicate. Taleb (Taleb 2008) has argued persuasively that
statistical methods currently employed in risk assessment can mislead stakeholders.
It seems likely that the risk management strategy adopted by a participant in a SoS may
need to be different according to whether the SoS is characterised as directed,
acknowledged, collaborative, or virtual. It may be that acknowledged and collaborative SoS
represent the types that are most difficult to estimate risks to individual stakeholders or
organisations.
There are a number of areas in which research into risk associated with SoS will be
valuable. Primarily these would be concerned with developing more reliable models and
mathematical techniques for risk estimation. However, there is also a need to enable
stakeholders to better understand the risks present during SoS operation; that is to say that
improved situational awareness and shared situational awareness must include better
knowledge of prevailing risks during SoS design and operation. This may also raise certain
issues of ethics in relation to SoS operation.
Please refer to the appendix sections for a summary of current EU / US projects
currently addressing risk mitigation within SoS.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 80
TAREA-PU-WP2-R-LU-9
16 TRAINING
16.1 Training Need
An effective SoS training activity is necessary to ensure that personnel who plan, implement,
operate and manage systems within SoS have the skills needed to perform their
responsibilities according to the agreed policies and procedures. Moreover, effective training
and education enables one to deal with complex system problem domains within SoS.
Training needs at the various levels of the organisation are task specific. Senior and line
management can benefit from training to help understand the structural concepts, and
operating principles of the SoS. Technical personnel can benefit from training to help
development and testing of various theories, methods, technologies and tools necessary to
fulfil the overall requirements of SoS.
16.2 SoSE Training Focus
It has been stated in the literature (Daw 2007) that:
• SoSE is a multi-disciplinary exercise and
• Has the characteristic of a ‘wicked problem’. (Rittel and Webber 1973)
The creation and management of systems within SoS requires a workforce with appropriate
systems skills and knowledge e.g. training programmes in SoSE (Sousa-Poza, Kovacic et al.
2008). Research is required to help define the training and education needed to equip the
EU workforce for future SoS challenges. Currently, there is little training that is dedicated to
SoSE. The large majority of training courses available provide training in SE, and can also
be domain specific. Those that have been identified as having at least some focus on SoSE
in the US and the UK have been summarised in the table 4 below.
SoSE Training Courses : US
SoSE Training Courses : UK
SoS Engineering Center of Excellence
http://www.sosece.org/
This group may have recently disbanded.
Loughborough University
http://www.lboro.ac.uk/study/postgraduate/course
s/departments/eleceng/systemsengineering/
Have a full range of SE programmes - MEng,
MSc and EngD - of which the taught modules
can also be taken as short courses. Engineering
for SoS appears specifically in: Engineering and
Management of Capability module.
National Center for Systems of Systems
Engineering (NCSOSE)
http://www.ncsose.org/
They are more of a research group that seeks to
support DoD with training, evidenced by recent
Navy contract on website based at Old Dominion
University (ODU).
Cranfield University
http://www.cranfield.ac.uk/cds/postgraduatestudy
/index.html
Have SoS embedded into their MSc programmes
of which the modules can also be taken as short
courses. These are largely focussed at MoD and
defence industry customers at present although
they have identified an increasing market for non
MoD customers. SoS appears in the Capability
Engineering block (module) and Systems
Architecture block, which are relevant to all
Release Date: 4th May 2012
© Loughborough University 2012
Page | 81
TAREA-PU-WP2-R-LU-9
SoSE Training Courses : US
SoSE Training Courses : UK
engineers although case studies may be militarybased.
NETWORK
CENTRIC
OPERATIONS
INDUSTRY
CONSORTIUM
https://www.ncoic.org/home/
Through conferences and meetings of members,
they essentially perform a training function by
sharing best practices.
University College London
Provides an MSc and short courses in Systems
Engineering Management, again in SE and not
specifically SoSE.
MIT SEARi Group
http://seari.mit.edu/
They have several short courses in systems
architecture that covers SE and SoSE (though not
exclusively). These are typically during the
summer and vary in scope.
University of Bristol Systems Centre
Provides an MSc, MRes and EngD in Systems
Engineering, again in SE and not specifically
SoSE.
INFORMS
The largest Operations Research community. The
annual informs conference covers an extremely
large array of topics across the span of
operations research. Again, depending on the
year and context, there are occasionally some
workshop sessions on SE (and potentially SoSE).
Most of the exposure comes from individual
presentations at speaker sessions though.
Atego Global Services
Provide training courses mainly in the area of
systems engineering, enterprise architecture
modelling and tools and are mapped to the
INCOSE Systems Engineering Competencies
Framework.
Professor Dan DeLaurentis
Provides SoSE course at the University of Purdue
https://engineering.purdue.edu
This is a dual level course - available to upper
level undergrads (typically seniors) and
postgraduate students.
BMT Hi-Q Sigma
Provide public and bespoke training courses in
enterprise architecture.
Professor Mo Jamshidi
Provides an established course at the University
of Texas San Antonio on SoSE.
SyntheSys Systems Engineers
Provide practioner-level training
systems engineering.
Private Group: ATI Inc.
Provides private short courses to engineering
professionals for all scopes of engineering and
provide
in
house
training
as
well.
www.aticourses.com/systems_of_systems.htm
Tutorials, workshops and seminars are run by
local INCOSE groups, although these would
cover all aspects of SE and are organised on a
more ad-hoc basis. INCOSE has chapters in
several EU countries including Finland, France,
Germany, Italy, Norway, Poland, Sweden,
Switzerland, the Netherlands and Turkey.
courses
in
Table 4: SoSE Training Focus Across the US and the UK
Release Date: 4th May 2012
© Loughborough University 2012
Page | 82
TAREA-PU-WP2-R-LU-9
Following the “Strategic Defence and Security Review”, a significant number of changes
have been made to the training systems of the MoD. Training has been rationalised,
balancing supply and demand; and where large-scale bespoke systems where the norm,
these have been replaced by training systems using COTS (commercial of-the-shelf) and
GOTS (Government of-the-shelf). These individual training systems (air, fast air, land etc.)
are being developed with a common architecture and brought together as a SoS to deliver
an integrated training system for MoD personnel. This represents an interesting use of SoS
in the delivery of training to workforces.
As can be seen there are more opportunities in the US for training in SoS. This is
understandable since it has already been identified that SoS has developed further in the US
than in the EU. In conclusion, the training in SoS appears to be embedded in some courses,
but not taught explicitly as a discipline. This report has not addressed SoS training in
mainland Europe as it has been difficult to identify what is available due to language barriers
and the geographically large area.
Please refer to the appendix sections for a summary of current EU / US projects
currently addressing training programmes within SoS.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 83
TAREA-PU-WP2-R-LU-9
17 CURRENT / EMERGING GAPS IN CRITICAL AREAS
The workshop on Systems of Systems (DG INFSO, 2009) noted that:
Through the integration of private and public systems at all levels and scales
there is the potential to offer improved societal impact. Societal impact may be
direct or indirect, at the level of the individual or at larger scales; increasing
efficiencies and producing new techniques and methods and approaches to
working.
This statement reveals both the benefits that investment in SoS research may realise and
the risks and vulnerabilities that failure to invest may create. The highly, and increasingly,
connected nature of modern society means that the existence of SoS is an unavoidable
factor of modern life, driving the need for better techniques to analyse, design for, manage,
and retire SoS and the individual systems that contribute to SoS. In essence, the challenge
is to predict and manage emergence of increasingly complex and complicated SoS. Gaps in
knowledge of how to do this exist at all levels and scales and, importantly between levels
and simultaneously at several scales.
Based on the literature reviewed in part A of this report, knowledge gaps have been
identified below (table 5). In the case of almost every identified gap, successful research
would lead to improved positive societal impact as well as avoiding negative impact. There is
overlap between many of the areas identified below.
SoS Knowledge Gap
System Identification
Action at a Distance
Information Security
Assurance of Intellectual
Property Rights and
Competitive Advantage
Description
The concept of system identification is not well-defined for Systems
of Systems, but an obvious cause of unexpected (and generally
undesirable) emergent behaviour is failure to correctly identify the
system of interest by the system designers. This is an area for
fundamental research in SoSE.
As (Asaro 2011) has pointed out, SoS allows for unethical and
criminal behaviour at a distance from the perpetrators, especially
when crossing legislative jurisdictions. This raises detection,
regulatory and prosecutorial issues that need to be resolved (e.g.
how is responsibility to be allocated?). This is especially a challenge
in the cyber domain.
Loss or corruption of information due to benign and malicious attacks
on IT systems. The cost of conducting a cyber-attack is very low, but
the cost of protection is very high.
Related to Information Security; a major problem for efficiency and
efficacy of large-scale SoS is the protection of information for
commercial reasons. The result is that the SoS may operate under
conditions of imperfect, incomplete information most of the time.
There seems to be a requirement for better mechanisms to protect
IPRs, etc., so that protagonists in a SoS feel more able to divulge
information without material loss of competitive value.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 84
TAREA-PU-WP2-R-LU-9
SoS Knowledge Gap
Distributed Risk
Automation and
autonomy
Ethical Behaviour of SoS
Safety of SoS Operations
Governance and
Regulation
Invariant Partial
Architectures for SoS
(Maier 2005)
Variability and ‘Tipping
Points’ (Tainter 1996;
Rudolph and Repenning
2002; Maier 2005)
Problems of Distributed
Intelligence in SoS
Description
The interdependencies between component systems can lead to
complex relationships in terms of risk ownership and liability.
Furthermore, redistribution of risk because of SoS interdependencies
may distort the market for future provision of products and services.
Research is needed into the nature of risk ownership in SoS.
A SoS may have component systems that have no humans involved
in their operations, and have a significant degree of autonomy in
decision-making, with direct effects on particular segments of society
(e.g. robots for assisted living scenarios). Issues of safety,
certification, maintenance and responsibility are raised.
In an environment in which participants in a situation cannot fully
comprehend the wider implications of their actions and where SoS
behaviours may be the emergent properties of many seemingly
independent actions, the possibility of unethical behaviours can arise.
Action at a distance has strong implications for safety. These range
from different conceptions of safety in different jurisdictions, different
expectations for the operational behaviour of SoS, different
understanding of the risks of SoS operational behaviour, etc.
A significant theme in this problem is better understanding of how to
create shared awareness.
Given that many SoS are of critical importance for the safety and
security of society (e.g. health, policing, emergency, etc.), their
integrity and security of structure and operations is a paramount
consideration (Maier 2005). Appropriate internal governance
systems and external regulatory oversight must be developed.
For most SoS, it is believed that portions of their architecture will
remain almost invariant over time, although other portions may be
labile. It may be that there are commonalities over types of SoS for
these invariant portions that will permit standardisation and operating
efficiencies to be obtained. The potential benefits indicate that this
should be explored.
Theoretically, there are conditions under which SoS behaviour may
collapse (a form of emergent behaviour). For example, there is the
variability issue, where although the average rate of response of the
SoS is within design limits, there may be occasions where the
required rate is beyond these limits and the SoS fails catastrophically.
This latter condition may arise because of the extent and complexity
of the SoS itself, which inadvertently builds in rigidities that result in
collapse as the only available behaviour of the SoS. As the ‘Internet
of things’ becomes a reality, and as governments interlink their
services, the possibility of collapse becomes ever more critical, and
requires better understanding of its characteristics.
Although distributed intelligence within SoS is a desirable goal for
effective, efficient and speedy response to local conditions, there are
potential problems when conflicting plans are developed dynamically.
While these issues are well understood for Directed SoS (Dahmann
and Baldwin 2008), the solutions for other classes of SoS are less
obvious, and need development. While there is always the option of
legal redress, it is not the best solution to the problem.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 85
TAREA-PU-WP2-R-LU-9
SoS Knowledge Gap
Description
Tools and Techniques for
Understanding, Designing
and Upgrading SoS
Behaviour
Many authors have pointed to this lack, in relation to SoS. In
particular, there is a severe lack of easy-to-use, effective and efficient
tools that convey easy-to-understand meaning for tool users faced
with some particular class of SoS problem. This should be
addressed as a matter of urgency.
Knowledge and Skills
Gaps
Many authors have stated that (a) SoS engineering is a multidisciplinary exercise, and (b) has the characteristics of a ‘wicked
problem’ (Rittel and Webber 1973; Daw 2007). The creation and
management of component systems within SoS requires a workforce
with appropriate systems skills and knowledge. E.g. Training
programmes in SoS engineering (Sousa-Poza, Kovacic et al. 2008).
Research is required to help define the training and education
needed to equip the EU workforce for future SoS challenges.
Table 5: Current / Emerging SoS Knowledge Gaps based on Literature Review
Release Date: 4th May 2012
© Loughborough University 2012
Page | 86
TAREA-PU-WP2-R-LU-9
PART B – CASE STUDY ANALYSIS
18 CASE STUDY INVESTIGATION
This chapter describes the identification of critical advances required in SoS operation
through case study analysis. The case studies analysed have been drawn from Defence, IT,
Transport, Manufacturing and sectors like Emergency Response and Water Management.
Although specific case study data is confidential, the case studies themselves and the
general issues identified from them are not. The analysis per sector is summarised in the
section 18.1 to section 18.5. An investigation analysing the identified issues across these
case studies is then summarised in the section 18.6.
Critical advances and the time period by which they are needed are represented in tabular
formats. Furthermore, prioritisation of critical advances is achieved by plotting time on two
dimensions: Impact and Implementation complexity.
18.1 Defence Sector
Within the defence sector, 2 case studies have been analysed namely “Tactical Data Link”
and “AMC”.
18.1.1 Tactical Data Link
Any Other
D7
Governance and
Control
D3
D1
SoS Techniques
D4, D5, D10
D1, D9
Societal Context
D9
Policy and
Regulation
D3
D1,
Technology
D2, D4, D5, D10
D6, D8
2015
2020
Short-term
2030
Table 6: Critical Advances Needed by Specified Time Periods from Tactical Data Link Case Study
Example Key:
D1: Codification and agreement on universal operating procedures for coalition forces in a
given theatre of operation e.g. BML, common RoEs.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 87
TAREA-PU-WP2-R-LU-9
D2.
Developments of a “Universal” plug in to ensure interoperability between different
physical platforms and legacy systems, including; data links, equipment, logistics.
D3: More international standards agreed and applied across all layers of the NCOIC
interoperability framework.
D4: Development of interactive modelling capability for alternative network system
architectures.
D5: Tied into D4, the availability of lead and lag metrics to measure system performance.
D6: Autonomous re-configuration of data link networks.
D7: Integrated systematic MoD acquisition system addressing both DLODs and future
doctrine and strategy.
D8: Automatic, instant translation between coalition languages.
D9: Cultural diversity assessment tools.
D10: Dynamically reconfigurable security systems and technologies.
Figure 15: Impact vs Implementation Relationship – Tactical Data Link Case Study
18.1.2 AMC
Since AMC spans across 2 domains (i.e. Defence and Transport), analysis of this case study
is summarised in the section 18.3.1 of this report.
18.2 IT Sector
Within the IT sector, 2 case studies have been analysed namely “Human Tracking” and
“NPfIT”.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 88
TAREA-PU-WP2-R-LU-9
18.2.1 Human Tracking
Any Other
Governance and
Control
IT3
SoS Techniques
IT5, IT6
IT1
Societal Context
Policy and
Regulation
Technology
IT1
IT6
IT7
IT1, IT2, IT4
IT5
Short-term
2015
2020
2030
Table 7: Critical Advances Needed by Specified Time Periods from Human Tracking Case Study
Example Key:
IT1: Gear towards an agreement on possible approaches to architectural design and
decision making tools / techniques for complex SoS environments.
IT2: Technology for simulating and visualising component communication efficiencies over
geographically distributed networks.
IT3: Improving approaches to managing stakeholders for successful SoS operation.
IT4: More support for integration of legacy systems and platform-independent (i.e. open)
solutions for data interoperations.
IT5: Modelling of well-defined interfaces within the SoS to foresee accommodation of
additional changes.
IT6: Develop, agree and apply integration and operational standards among component
systems to maintain individual functionalities and adhere to originally planned
performance metrics.
IT7: Detailed investigation and careful design of efficient protocols for large data
communication over networks with high latencies.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 89
TAREA-PU-WP2-R-LU-9
Figure 16: Impact vs Implementation Relationship – Human Tracking Case Study
18.2.2 NPfIT
Any Other
Governance and
Control
IT2
SoS Techniques
IT8
IT1, IT7
IT5
IT3
Societal Context
Policy and
Regulation
Technology
IT7
IT8
IT1, IT6
IT4, IT3
Short-term
2015
2020
2030
Table 8: Critical Advances Needed by Specified Time Periods from NPfIT Case Study
Release Date: 4th May 2012
© Loughborough University 2012
Page | 90
TAREA-PU-WP2-R-LU-9
Example Key:
IT1: Introducing more flexibilities at the interface level of component systems catering future
enhancements at the SoS level. Moreover, it is required to partition an interface to
support services of variable standards from a single component system.
IT2: Improving stakeholder and operational management of the SoS especially when
interests and viewpoints of its operation conflict.
IT3: Performance and cost-estimation modelling (integrating risk management features) is
strongly needed through system lifecycle.
IT4: Better requirements engineering and information management tools / techniques
applicable to complex systems engineering environments are a must.
IT5: Effective system training plans and procedures required for gradually introduced
components within the SoS.
IT6: Flexibility in accessing information without relying on specialised hardware or software
is needed.
IT7: Agreement on operating procedures (in terms of component systems procurements,
legacy system integration and its support, etc.) is required.
IT8: Proper system tools and techniques for evaluation of functional and non-functional
requirements when component systems interoperate and collaborate.
Figure 17: Impact vs Implementation Relationship – NPfIT Case Study
18.3 Transport Sector
Within the transport sector, 4 case studies have been analysed namely “AMC”, “ATS” “Fleet
Level” and “SESAR”.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 91
TAREA-PU-WP2-R-LU-9
18.3.1 AMC
Any Other
Governance and
Control
T3, T4, T8
SoS Techniques
T1, T2
Societal Context
T4, T8
Policy and
Regulation
T1, T2, T8
Technology
T8
T6, T5
T7
2015
2020
2030
Short-term
T7
T5
T7
T7
Table 9: Critical Advances Needed by Specified Time Periods from AMC Case Study
Example Key:
T1: Tools to map and visualise the trade-space for the SoS (or the individual
system/organisation) to aid decisions on regulation and operation of military and
civilian Air space and slot allocation.
T2: MBSE techniques & standards for creating distributed models (e.g. linking together
individual models developed independently for each participating system/organisation),
and to feed T1 above. Note that an appropriate technique must condense big models,
and develop dependency metrics for the results of model combination.
T3: Standardised framework or enterprise architecture for categorising the operating
characteristics of any participating civilian enterprise system within the SoS.
T4: Governance tools for analysing and monitoring whole or part SoS behaviours, including
pattern recognition, to detect when problems are emerging, both externally and
internally.
T5: Technology for ‘Intelligent Transportation’ integrated systems for real-time management
of destination-to-destination travel across all travel types, addressing congestion,
weather issues, crashes, etc including simple interfaces for soldiers to efficiently plan
travel for themselves or their unit.
T6: Technology to solve bandwidth problems for communication and network management.
T7: Autonomous control of transport vehicles, and node loading/unloading.
T8: Integrated civilian and military flight scheduling systems capable of responding to volatile
demand and need for scalability.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 92
TAREA-PU-WP2-R-LU-9
Figure 18: Impact vs Implementation Relationship – AMC Case Study
18.3.2 ATS
Any Other
Governance and
Control
T3, T4
SoS Techniques
T1, T2
Societal Context
T4
Policy and
Regulation
T1, T2, T9
Technology
Short-term
2015
T10
T10
T6
T10
T5, T6, T8, T7
T10
2020
2030
Table 10: Critical Advances Needed by Specified Time Periods from ATS Case Study
Release Date: 4th May 2012
© Loughborough University 2012
Page | 93
TAREA-PU-WP2-R-LU-9
Example Key:
T1: Tools to map and visualise the trade-space for the SoS (or the individual
system/organisation) to aid decisions on regulation and operation of Air space and slot
allocation.
T2: MBSE techniques & standards for creating distributed models (e.g. linking together
individual models developed independently for each participating system/organisation),
and to feed T1 above. Note that an appropriate technique must condense big models,
and develop dependency metrics for the results of model combination.
T3: Standardised framework for describing the operating characteristics of any participating
enterprise system within the SoS, perhaps using the Quality Model from the EFQM as
a basis.
T4: Governance tools for analysing and monitoring whole or part SoS behaviours, including
pattern recognition, to detect when problems are emerging, both externally and
internally.
T5: Air Traffic Management (ATM) systems to optimise use of airspace, globally (e.g.
‘Single European Sky’), including passenger marshalling.
T6: Technology to reduce environmental impact of transportation systems
T7: Technology for ‘Intelligent Transportation’ integrated systems for real-time management
of destination-to-destination travel across all travel types, addressing congestion,
weather issues, crashes, etc..
T8: Technology to solve bandwidth problems for communication and network management
T9: More coherent and effective regulations for traffic safety, passenger equity, and goods
certification, at both national and international levels
T10: Autonomous control of transport vehicles, and node loading/unloading
Figure 19: Impact vs Implementation Relationship – ATS Case Study
Release Date: 4th May 2012
© Loughborough University 2012
Page | 94
TAREA-PU-WP2-R-LU-9
18.3.3 Fleet Level
Any Other
A1
Governance and
Control
SoS Techniques
T1
T4, T5
T2, T3, T4, T5
Societal Context
T7
T6, T7
T6
Policy and
Regulation
Technology
T6
IT1, T1
IT1
Short-term
2015
2020
2030
Table 11: Critical Advances Needed by Specified Time Periods from Fleet Level Case Study
Example Key:
T1:
T2:
T3:
T4:
T5:
T6:
T7:
IT1:
A1:
Development of realistic aircraft models (this relates to simulation and modelling
challenges).
Validation of the interaction between various elements of the SoS.
Development of tools to optimise resource allocation.
Development of predictive models (past trends should be used as input but what
happens in the past may not continue in the future).
Development of governance tools for analysing and monitoring the SoS.
Understanding of how variation in external factors affects aviation.
Technology to understand/assess the environmental impact of transportation systems.
High performance computing to speed up simulation time in order to speed up the
assessment of different scenarios.
Information availability (In this project, airlines’ ticket pricing methods are varied and not
available in public domain and so an in-house method had to be developed).
Release Date: 4th May 2012
© Loughborough University 2012
Page | 95
TAREA-PU-WP2-R-LU-9
Figure 20: Impact vs Implementation Relationship – Fleet Level Case Study
18.3.4 SESAR
Any Other
Governance and
Control
T8
SoS Techniques
T8
T1, T4, T6, T7
T2
T3
Policy and
Regulation
T9
T4, T7
Technology
T2, T9
T1, T3, T5
2020
2030
Societal Context
Short-term
2015
Table 12: Critical Advances Needed by Specified Time Periods from SESAR Case Study
Release Date: 4th May 2012
© Loughborough University 2012
Page | 96
TAREA-PU-WP2-R-LU-9
Example Key:
T1: Tools to map and visualise the trade-space for the SoS (or the individual
system/organisation) to aid decisions on regulation and operation of Air space and slot
allocation.
T1: Methods to improve data quality and interoperability.
T2 : Improved techniques to define and determine quality of service for SoS.
T3 : Methods to ensure that the SoS meets the quality of service requirements.
T4 : Certification of individual systems.
T5 : Development of a globally accepted aeronautical information exchange format.
T6 : Interoperability between civil and military systems.
T7 : The establishment of data normalisation and standardisation.
T8 : Framework for explicit modelling of information to be exchanged.
T9: Technology to reduce environmental impact of transportation systems.
Figure 21: Impact vs Implementation Relationship – SESAR Case Study
Release Date: 4th May 2012
© Loughborough University 2012
Page | 97
TAREA-PU-WP2-R-LU-9
18.4 Manufacturing Sector
Within the Manufacturing sector, 1 case study has been analysed namely “SCADA DCS”.
18.4.1 SCADA DCS
Any Other
Governance and
Control
M2
SoS Techniques
M6, M8
M1, M7
M4
Societal Context
Policy and
Regulation
M3
M8
M1
Technology
M3, M5
M4, M6, M9
M7
Short-term
2015
2020
2030
Table 13: Critical Advances Needed by Specified Time Periods from SCADA DCS Case Study
Example Key:
M1: System components evolution to be compliant with the expected behaviour and agreed
service standard within the SoS, effectively managing its emergence.
M2: Stakeholders management especially their legal interaction process.
M3: Improve transparency and establish trusts within a collaborative ecosystem for dataindependent SOA interoperation.
M4: Linked to M3, gearing towards open architectural technologies to enable collaborative
automation through SoS lifecycle.
M5: Security management procedures against data access compromisation within the SoS
implementation.
M6: Better requirements engineering and identification of dependencies operating in a multidomain environment.
M7: Modelling / simulation and testing of SoS architectures / infrastructures.
M8: Provide legacy system support and support its migration to SoS collaborative
automation.
M9: Improved wireless bandwidth constraints and real-time performance metrics for service
optimisation.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 98
TAREA-PU-WP2-R-LU-9
Figure 22: Impact vs Implementation Relationship – SCADA DCS Case Study
Release Date: 4th May 2012
© Loughborough University 2012
Page | 99
TAREA-PU-WP2-R-LU-9
18.5 Other Sectors
In other sectors, 2 case studies have been analysed namely “Emergency Response” and
“Water Management”.
18.5.1 Emergency Response (EM)
Any Other
Governance and
Control
A8
SoS Techniques
A1, A8, A9
A4, A5, A7
A5, A6, A10
A2
A7
A3, A10
Short-term
2015
2020
Societal Context
Policy and
Regulation
Technology
2030
Table 14: Critical Advances Needed by Specified Time Periods from Emergency Response Case
Study
Example Key:
A1: Methods to determine chain of command - who assumes responsibility ?
A2: Development of simulation/modelling tools to support rapid execution of virtual
experiments.
A3: Development of methods to validate a constantly evolving system.
A4: Representation of incomplete systems knowledge at a SoS level.
A5: Integration of legacy system architectures.
A6: SoS representation methods.
A7: Information representation/interaction.
A8: Improve effectiveness in stakeholder management.
A9: Better organisational management between agencies.
A10: Decision support tool to identify optimal solutions.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 100
TAREA-PU-WP2-R-LU-9
Figure 23: Impact vs Implementation Relationship – Emergency Response Case Study
18.5.2 Water Management (WM)
Any Other
Governance and
Control
SoS Techniques
A4
A2
A3
Societal Context
Policy and
Regulation
A4
A4
Technology
A1
A4
Short-term
2015
2020
2030
Table 15: Critical Advances Needed by Specified Time Periods from Water Management Case Study
Example Key:
A1: Computational limitations on real-time processing of vast amounts of data.
A2: Highly independent but connected subsystems use diverse formats to organise data.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 101
TAREA-PU-WP2-R-LU-9
A3: SoS techniques are being applied to analyse emergent behaviour in the real system.
A4: Georeferenced databases from the various subsystems requires additional work to make
the data usable
Figure 24: Impact vs Implementation Relationship – Water Management Case Study
18.6 Investigation Summary
This section analyses the above case study outcomes (section 18.1 to section 18.5) to
identify critical research issues emerging across various domains for effective operation of
SoS. The commonalities are summarised in table 16 below.
Applicable Domain
Critical Advances
Needed / Issues with
Effective SoS
Operation
1) Effective
Interoperation between
component systems &
with external systems
(including between
different physical
platforms and legacy
system integration).
Defence
AMC,
Tactical
Data
Link
Release Date: 4th May 2012
Energy
ICT
Manufacturing
Transport
Others
Human
Tracking,
NPfIT
SCADA DCS
AMC, ATS,
SESAR
ER,
WM
© Loughborough University 2012
Page | 102
TAREA-PU-WP2-R-LU-9
Applicable Domain
Critical Advances
Needed / Issues with
Effective SoS
Operation
Defence
Energy
ICT
Manufacturing
Transport
Others
ER,
WM
2) Design, publish and /
or apply agreed
interface &
interoperability
standards.
Tactical
Data
Link
Human
Tracking,
NPfIT
SCADA DCS
ATS, Fleet
Level,
SESAR
3) Performance
modelling and metrics
for assessment and
optimisation.
AMC,
Tactical
Data
Link
Human
Tracking,
NPfIT
SCADA DCS
AMC, ATS,
Fleet Level,
SESAR
WM
AMC,
Tactical
Data
Link
Human
Tracking
SCADA DCS
AMC, ATS,
Fleet Level,
SESAR
ER
AMC,
Tactical
Data
Link
Human
Tracking,
NPfIT
AMC
Human
Tracking,
NPfIT
Tactical
Data
Link
Human
Tracking,
NPfIT
4) Distributed / linked
simulation and
modelling capabilities
(including visualisation,
mapping and trade
space) for decision
making.
5) Dealing with
evolution / reconfiguration of
component systems +
SoS in general
including enabling
modifications to SoS
during on-going
operations (may
include autonomy).
6) Effective stakeholder
management (includes
distributed control of
SoS between
stakeholders and their
legal interactions).
7) Plan and agree on
the application of
operating procedures /
regulations.
AMC, ATS,
Fleet Level
ER
SCADA DCS
AMC, ATS
ER,
WM
SCADA DCS
ATS
WM
8) Governance tools for
analysing and
Release Date: 4th May 2012
© Loughborough University 2012
Page | 103
TAREA-PU-WP2-R-LU-9
Applicable Domain
Critical Advances
Needed / Issues with
Effective SoS
Operation
monitoring whole or
part SoS behaviours, to
detect when problems
are emerging, both
externally and
internally.
9) Technology to solve
bandwidth problems for
communication and
network management
(physical and virtual
systems).
10) Enterprise system
architecture for
describing the
operating
characteristics of any
participating enterprise
system within the SoS.
11) Impact analysis on
society / environment
Defence
Energy
ICT
Manufacturing
Transport
Others
AMC
NPfIT
SCADA DCS
AMC, ATS,
Fleet Level
WM
AMC
Human
Tracking
SCADA DCS
AMC, ATS
WM
AMC
Human
Tracking
SCADA DCS
AMC, ATS
AMC
12) Open source
connectivity (including
open architectures)
AMC, ATS,
Fleet Level,
SESAR
Human
Tracking,
NPfIT
SCADA DCS
Table 16: Case Study Analysis Summary Across Domains
Release Date: 4th May 2012
© Loughborough University 2012
Page | 104
TAREA-PU-WP2-R-LU-9
19 SOS RESEARCH PRIORITIES
19.1 Expert Workshop Activity
A workshop was held in Brussels on April 4 2012. The objective of the workshop was to
address the question of research priorities for SoS with particular reference to:
• research priorities in System of Systems Engineering for future EU investment (i.e.
Horizon 2020, addressing the creation of a Strategic Research Agenda)
• opportunities for EU-US collaboration in System of Systems Engineering research
The experts were selected for their acknowledged expertise in the area of SoS and included
both academics and industrials, most of whom were also involved with existing FP7 projects.
The experts were as follows:
Armando Colombo, Schneider Electric (Manufacturing); IMC-AESOP EU FP7 Project
John Fitzgerald, University of Newcastle (IT); COMPASS EU FP7 Project
Jon Holt, Atego Systems (Defence)
Gerrit Muller, Buskerud University College (Healthcare and IT)
Ursula Rauschecker, Fraunhofer IPA (Manufacturing); ROAD2SOS EU FP7 Project
Also in attendance were:
Vishal Barot, Loughborough University, T-AREA-SoS
Michael Henshaw, Loughborough University, T-AREA-SoS
Sharon Henson, Loughborough University, T-AREA-SoS
Alkis Konstantellos, European Commission
Soo Ling Lim, Bournemouth University, T-AREA-SoS
Cornelius Ncube, Bournemouth University, T-AREA-SoS
Werner Steinhögl, European Commission
Joining in from the US:
Mo Jamshidi, UTSA
Dan DeLaurentis, Purdue University
19.1.1 Workshop Format
Prior to the workshop, experts were asked to complete a short exercise on what are the
critical advances that need to be in place by each of the time periods specified to ensure
effective operation of SoS? Their comments were analysed and informed the introductory
presentation to the workshop. In addition, the findings to date of the analysis of the case
studies (described in the chapter 18) were presented, in order to initiate discussion. The
workshop also included colleagues from the US who joined in to the introductory session
from their homes in the USA. The workshop structure was as follows:
Session 1
Introductions and overview of the aims and purposes of the workshop.
Session 2
A presentation of the initial analysis based on the information received, by individual
domains and across domains and the case studies analysed so far.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 105
TAREA-PU-WP2-R-LU-9
Session 3
The experts (in Brussels) were divided into 2 groups and each group was asked to revisit the
analysis and further consider the SoS advances needed.
Session 4
Feedback from the groups including a presentation from the experts in America on what
advances were needed.
Session 5
Each expert group (in Brussels) studied the combined data to identify 6 key research areas
that need to be included in the Horizon 2020 programme.
Session 6
Each expert group (in Brussels) presented their recommendations.
Session 7
Summary of findings were discussed.
19.2 Findings from the Expert Workshop
While the groups were asked to focus on the top six key research areas, this seemed too
constrained so it is noted that all the recommendations deemed a priority have been
included:
Group A
1. Techniques for validation of interoperability
2. Metric identification/validation; global metrics
3. Trade-off techniques for integration of legacy; evolution
4. Multi-heterogeneous modelling
5. Enterprise SoS, governance & policy
6. How to prototype SoS?
7. Qualification of safety or security critical SoS
Group B
1. Multi-notation approaches
2. Security of SoS implementation
3. Capabilities / processes and competencies
4. Scenario-based simulation and analysis
5. Architecture patterns for SoS
6. Dynamic SoS
7. Engineering for emergence
8. Goals and expectations in SoS
9. Multi-level infrastructure consistency
As can be seen, there were 16 areas deemed by the experts as key areas for research in
SoS. These are expanded as follows:
Release Date: 4th May 2012
© Loughborough University 2012
Page | 106
TAREA-PU-WP2-R-LU-9
Techniques for Validation of Interoperability
Interoperability is a fundamental property of systems of systems. In its broadest
interpretation, interoperability is the property of one system to work with other systems; that
is, to inter-operate with another system. Interoperation between systems requires adequate
disclosure of interfaces of the inter-operating systems, but ‘adequate’ is very often context
dependent. There are a number of frameworks for interoperability, which cover largely the
same categories of interoperation, but generally weighted according to the community at
which they are directed. In general, information interoperability between systems is
considered to require both syntactic interoperability (ability to exchange data/information)
and sematic interoperability (ability of receiving system to automatically interpret exchanged
information meaningfully). A helpful interoperability framework has been provided by
NCOIC; whilst directed at military network centric operations, it is generally applicable. It
has three broad layers, and nine sub-layers of interoperability, as shown in the figure 25
below.
Figure 25: NCOIC Interoperability Framework (2008)
With the range of interoperability requirements (from physical, data, etc. to human and
political), it is clear that testing adequacy is a complex problem. There is, therefore, a need
for research into suitable techniques for making categorical and well-founded measurement
and validation of interoperable systems. This includes, not only assessment of systems to
interoperate with extant systems, but also their potential for interoperation with future, as yet
incompletely defined systems.
Metric Identification/Validation; Global Metrics
Currently, as identified in the chapter 13.2, no universally agreed and general set of metrics
for assessment of systems of systems exists; indeed, it is not clear that such a set is
possible. Inadequate performance of SoS may be recognised through post hoc analysis, but
a comprehensive and complete set of relevant metrics is not necessarily apparent prior to
deployment of operation of a SoS. For the case of SoS, it is more meaningful to speak of
measures of effectiveness (MoE) and the metrics that contribute to them. Research is
required to determine: whether a set of universal MoEs exist for SoS and if so, what they
are; general metrics and the tailoring process for specific applications; metrics that are
Release Date: 4th May 2012
© Loughborough University 2012
Page | 107
TAREA-PU-WP2-R-LU-9
composed of heterogeneous systems attributes; associated measurement techniques. The
whole process of metric selection, measurement collection, analysis, storage/duration, and
disposal should also be understood.
Trade-off Techniques for Integration of Legacy; Evolution
Depending on the nature (type) of SoS under consideration, participant system owners or
operators must make decisions about participation in a SoS and the interactions between
the various systems within the SoS. There is, therefore, a need to understand the trade-offs
that must be made in order to achieve appropriate benefits (at a particular time and
instantiation of the SoS) and minimise any limitations or drawbacks associated with the
operation of the SoS. Evolutionary development is a property of SoS, and a particular area
of concern is the combination of legacy systems with each other and with new systems,
because in general they will not have been designed with inter-operation in mind. Thus, this
theme refers to the research needed into techniques to ensure robust SoS where new and
legacy systems combine, and also how to maintain and evolve these SoS, noting that
evolution may be rapid or slow.
Multi-heterogeneous Modelling
SoS are characterised by their composition from heterogeneous systems and it is worth
noting that SoS also exhibit manifold heterogeneous behaviours across the interoperability
spectrum (see previous figure 25). It is rare that a single model or single modelling approach
will adequately capture all the necessary behaviours that the designer or analyst wishes to
examine. SoS modelling frequently requires the combination of models from different
disciplines, with different purposes, and with different levels of fidelity, etc. These must be
integrated into a system of models. Furthermore, not all aspects of a SoS model are
necessarily under the control of, or available to, the modeller; thus, rational and valid
assumptions need to be made for unmodelled or unavailable system behaviours. Research
is required to understand how to choose and combine heterogeneous models economically
and reliably, and how to interpret the results from such systems of models. This theme is
related to ‘multi-notation approaches’ which forms an important enabler for multiheterogeneous modelling.
Enterprise SoS, Governance & Policy
The distributed ownership and/or operation of the individual systems within a SoS implies
that careful consideration of enterprise relationships and governance is required for
successful operation. Enterprise, in this context, means multiple collaborating enterprise
systems. In general, the enterprise relationships vary according to the type of SoS (directed,
acknowledged, collaborative, virtual). It is considered that composition and operation of SoS
require the organisation and contractual arrangements to be designed appropriately.
Research in enterprise system design is needed to support systems owners/operators at all
levels of an enterprise system relevant to SoS. This would cover matters of stakeholder
identification and management, standards, conflict resolution, governance, IP, and policies in
individual systems in a SoS.
How to Prototype SoS?
Is it possible to prototype SoS?
Release Date: 4th May 2012
© Loughborough University 2012
Page | 108
TAREA-PU-WP2-R-LU-9
Prototyping of systems and products is an important part of development, but its meaning in
the case of SoS is significantly compromised. The challenges associated with this theme
cover the question: what does it mean to prototype SoS? Furthermore, what different
approaches are required for rapid and slow composition of SoS? Given that SoS
engineering is frequently associated with choosing the appropriate systems and their
interactions, rather than building the systems themselves, does prototyping have a different
form from simulation?
Qualification of Safety or Security Critical SoS
How is safety and security assured in a SoS? This is an urgent research area associated
with the operation of networked systems. Where safety or security depends on the network,
then new approaches to qualification are needed to achieve affordable solutions. The
urgency of this problem is different in different sectors, with the aviation sector driving the
most significant effort in research, particularly where the combination of autonomous
systems is also included.
Multi-notation Approaches
For there to be successful modelling and simulation of SoS, there has to be means for
managing multiple sets of notations. However, multi-notation approaches extend beyond
modelling to the consideration of combining different categories (e.g. models, events, and
actions) so that distinct categories can be semantically linked.
Security of SoS Implementation
In contrast to the qualification theme above, this refers to the challenge of achieving
increased interoperation while protecting intellectual property in SoS and issues around
sharing information.
Capabilities / processes and Competencies
In order for a SoS to operate successfully, organisational processes need to work within the
SoS which includes a competent workforce. The workforce and the processes need to be
SoS-aware. This theme is largely concerned with the necessary skills and competences
within an organisation to enable it to be an effective SoS participant.
Scenario-based Simulation and Analysis
Scenario based planning and experimentation is a well-established technique for
investigating complex, socio-technical situations. Interpretation of results tends to be
subjective in nature. There is a need for research into the use of scenarios (from creation
through to analysis) to ensure consistent approaches may be used in experimentation and
greater metrication of results can be achieved for improved SoS design. The scenario-based
techniques need to be linked more effectively to notions of emergence and design for
emergence.
Architecture Patterns for SoS
This issue covers both physical system and enterprise system architectures. Architecting is a
key skill and technique for development of SoS; however, at present there is little by way of
reliable assessment of different architectures at the design stage. It is believed that better
understanding of architecting and architectures will lead to better SoS behaviours and the
Release Date: 4th May 2012
© Loughborough University 2012
Page | 109
TAREA-PU-WP2-R-LU-9
discovery of patterns will reduce the development costs associated with systems
engineering for SoS. Specific and proven architecture patterns are required for SoS.
Dynamic SoS
The nature of SoS is to be constantly changing, though the characteristic time for change
may vary significantly between different types of SoS. Once a SoS is operational, the
challenges associated with dynamic SoS refers to development of coping strategies
associated with reconfiguration in an evolving SoS, the autonomous behaviour of the
elemental systems within the SoS and, if required, dynamic (re)allocation of function within
the SoS.
Engineering for Emergence
The task of systems engineering is, in essence, the task of engineering for emergence.
However, there is significant development required in the development of formalised and
formal techniques to predict emergence or, at any rate, determine the likelihood of various
emergent behaviours arising. This theme is wide ranging, but essentially points towards the
need for more effective tools and techniques.
Goals and Expectations in SoS
This refers to the management of multiple stakeholders in individual systems in an SoS while
continuing to achieve the aims of the SoS. It also incorporates aspects such as situational
awareness, leadership, and management of information and assessment.
Multi-level Infrastructure Consistency
In a SoS where there are operational subsystems within subsystems with individual
infrastructures, this refers to the issues that arise from different interfaces in the SoS, and
how information is consistently represented at the SoS level.
Once the top 16 research priorities were identified, each group went on to plot these on a
graph (shown in the figure 26). The y axis on the graph represents the impact of the
research from low to high and the x axis represents implementation complexity from easy to
hard.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 110
TAREA-PU-WP2-R-LU-9
Figure 26: Impact vs Implementation Relationship – Expert Workshop Findings
A1
A2
A3
A4
A5
A6
A7
Techniques for validation of interoperability
Metric identification/validation; global metrics
Trade-off techniques for integration of legacy; evolution
Multi-heterogeneous modelling
Enterprise SoS, governance & policy
How to prototype SoS?
Qualification of safety or security critical SoS
B1
B2
B3
B4
B5
B6
B7
B8
B9
Multi-notation approaches
Security of SoS implementation
Capabilities / processes and competencies
Scenario-based simulation and analysis
Architecture patterns for SoS
Dynamic SoS
Engineering for emergence
Goals and expectations in SoS
Multi-level infrastructure consistency
Release Date: 4th May 2012
© Loughborough University 2012
Page | 111
TAREA-PU-WP2-R-LU-9
19.2.1 Single Transferable Vote
The experts were asked to rank in order of preference, their own personal top 6 from the list
of the top 16 research priorities. The responses were fed into a spread sheet that calculated
a hierarchy based in the principles of the single transferable vote:
The top research priorities were as follows:
1. Engineering for emergence
2. Enterprise SoS, governance & policy
3. Multi-heterogeneous modelling
4. Architecture patterns for SoS
5. Multi-notation approaches
6. Trade-off techniques for integration of legacy; evolution
7. Metric identification/validation; global metrics
8. How to prototype SoS?
9. Scenario-based simulation and analysis
10. Dynamic SoS
11. Security of SoS implementation
12. Capabilities / processes and competencies
13. Techniques for validation of interoperability
14. Goals and expectations in SoS
15. Qualification of safety or security critical SoS
16. Multi-level infrastructure consistency
Note: It was the project team’s opinion that there were similarities between ‘multiheterogeneous modelling’ and ‘multi-notation approaches’ as well as ‘Enterprise SoS,
governance and policy’ and ‘goals and expectations in SoS’. Combining in these results in
this list give the following outcome:
1. Engineering for emergence
2. Enterprise SoS, governance and policy & Goals and expectations in SoS
3. Multi-heterogeneous modelling & Multi-notation approaches
4. Architecture patterns for SoS
5. Trade-off techniques for integration of legacy; evolution
6. Metric identification/validation; global metrics
7. How to prototype SoS?
8. Scenario-based simulation and analysis
9. Dynamic SoS
10. Security of SoS implementation
11. Capabilities / processes and competencies
12. Techniques for validation of interoperability
13. Qualification of safety or security critical SoS
14. Multi-level infrastructure consistency
Release Date: 4th May 2012
© Loughborough University 2012
Page | 112
TAREA-PU-WP2-R-LU-9
19.2.2 Workshop Conclusion
It was agreed that the workshop had shown promise in identifying research priorities in
System of Systems Engineering for future EU investment (i.e. Horizon 2020)
Furthermore, the workshop signified the start of the establishment of the T-AREA-SoS
Expert Community.
19.3 Comparison of Workshop and Case Study Outcomes
The table 17 compares the workshop outcome (14 identified research priorities) to the
analysis of the case study (chapter 18) to identify common emerging issues across various
sectors.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 113
TAREA-PU-WP2-R-LU-9
Critical Advances Applicable ( ◙ ) Across Domains [from case study
analysis – chapter 18.6]
Research Priorities
[from workshop
outcome – section
19.2.1]
Key: ER – Emergency Response
FL – Fleet Level
HT – Human Tracking
Manf – Manufacturing
TDL – Tactical Data Link
WM – Water Management
Defence
Transport
Manf
IT
Others
TDL
AMC
ATS
FL
SESAR
SCADA
DCS
HT
NPfIT
ER
WM
for
◙
◙
◙
◙
◙
◙
◙
◙
◙
◙
Enterprise
SoS,
Governance and Policy
&
Goals
and
Expectations in SoS
◙
◙
◙
◙
◙
◙
◙
◙
◙
◙
Multi-heterogeneous
Modelling
&
Multinotation Approaches
◙
◙
◙
◙
◙
◙
◙
◙
◙
◙
◙
◙
◙
◙
◙
◙
◙
Engineering
Emergence
Architecture
for SoS
Patterns
Trade-off Techniques
for
Integration
of
Legacy; Evolution
◙
◙
◙
◙
◙
◙
◙
◙
Metric
Identification/Validation;
Global Metrics
◙
◙
◙
◙
◙
◙
◙
◙
How to Prototype SoS?
◙
◙
◙
◙
◙
◙
◙
Scenario-based
Simulation
Analysis
◙
◙
◙
◙
◙
◙
◙
◙
◙
◙
◙
◙
◙
◙
◙
◙
◙
◙
◙
Dynamic SoS
and
Release Date: 4th May 2012
© Loughborough University 2012
◙
◙
Page | 114
TAREA-PU-WP2-R-LU-9
TDL
AMC
ATS
FL
SESAR
SCADA
DCS
HT
NPfIT
ER
WM
◙
◙
◙
◙
◙
◙
◙
◙
◙
◙
Security
for
Implementation
SoS
Capabilities
Processes
Competencies
/
and
Techniques
Validation
Interoperability
for
of
◙
◙
◙
◙
◙
◙
◙
◙
◙
◙
Qualification of Safety
or Security Critical SoS
◙
◙
◙
◙
◙
◙
◙
◙
◙
◙
◙
◙
◙
◙
Multi-level
infrastructure
consistency
Table 17: Comparison of Workshop and Case Study Outcomes
Release Date: 4th May 2012
© Loughborough University 2012
Page | 115
TAREA-PU-WP2-R-LU-9
20 SUMMARY
Table 18 presents a consolidated list of the important areas that have been identified
through literature review, case study, and expert workshop. The areas for research have
been grouped against the topics identified by the expert group, but clearly there is a good
deal of overlap between the various topics. Unquestionably, there are urgent research needs
in the area of Systems of Systems Engineering and it is recommended that the order agreed
by the expert group provides the priority in terms of research areas. The top six areas for
research are:
1.
2.
3.
4.
5.
6.
Engineering for Emergence
Enterprise SoS, Governance and Policy & Goals and Expectations in SoS
Multi-heterogeneous Modelling & Multi-notation Approaches
Architecture Patterns for SoS
Trade-off Techniques for Integration of Legacy; Evolution
Metric Identification/Validation; Global Metrics
Release Date: 4th May 2012
© Loughborough University 2012
Page | 116
TAREA-PU-WP2-R-LU-9
Workshop
Engineering for Emergence
Literature review
Case Studies
System Identification
Effective
stakeholder
management
(includes
distributed control of SoS
between stakeholders and their
legal interactions).
Distributed Risk
Enterprise SoS, Governance
and Policy & Goals and
Expectations in SoS
Ethical Behaviour of SoS
Plan and agree on the
application
of
operating
procedures / regulations.
Governance
Regulation
Governance tools for analysing
and monitoring whole or part
SoS behaviours, to detect when
problems are emerging, both
externally and internally.
and
Multi-heterogeneous
Modelling & Multi-notation
Approaches
Architecture Patterns for SoS.
Impact analysis on society /
environment.
Invariant Partial Architectures
for SoS (Maier 2005)
Enterprise system architecture
for describing the operating
characteristics
of
any
participating enterprise system
within the SoS.
Open
source
connectivity
(including open architectures).
Trade-off
Techniques
for
Integration
of
Legacy;
Evolution.
Metric Identification/Validation;
Global Metrics.
Tools and Techniques for
Understanding,
Designing
and
Upgrading
SoS
Behaviour.
Dealing with evolution / reconfiguration
of
component
systems + SoS in general
including enabling modifications
to
SoS
during
on-going
operations
(may
include
autonomy).
Performance modelling
metrics for assessment
optimisation.
and
and
How to Prototype SoS?
Release Date: 4th May 2012
© Loughborough University 2012
Page | 117
TAREA-PU-WP2-R-LU-9
Scenario-based
and Analysis
Simulation
Dynamic SoS
Distributed / linked simulation
and
modelling
capabilities
(including visualisation, mapping
and trade space) for decision
making.
Variability
and
‘Tipping
Points’
(Tainter
1996;
Rudolph and Repenning
2002; Maier 2005)
Technology to solve bandwidth
problems for communication and
network management (physical
and virtual systems).
Information Security
Security
for
Implementation
Qualification of Safety
Security Critical SoS
SoS
Assurance of Intellectual
Property
Rights
and
Competitive Advantage
or
Capabilities / Processes and
Competencies
Safety of SoS Operations
Problems
of
Distributed
Intelligence in SoS
Knowledge and Skills Gaps
Effective Interoperation between
component systems & with
external
systems
(including
between
different
physical
platforms and legacy system
integration).
Techniques for Validation of
Interoperability
Design, publish and / or apply
agreed
interface
&
interoperability standards.
Multi-level
consistency
infrastructure
Action at a Distance
Automation and autonomy
Table 18: Research Areas Identified through Literature Review, Case Study and Expert Workshop
Release Date: 4th May 2012
© Loughborough University 2012
Page | 118
TAREA-PU-WP2-R-LU-9
21 REFERENCES
Abel, A. and S. Sukkarieh (2006). The coordination of multiple autonomous systems using information
theoretic political science voting models. Proc. IEEE International Conference on System of
Systems Engineering, Los Angeles.
Alberts, D. S., & Hayes, R. E. (2003). Power to the Edge. Washington: CCRP.
Alberts, D. S. (2011). The agiity advantage, US DOD Command & Control Research Program.
Alexander, R., Hall-May, M., & Kelly, T. (2004). Characterisation of Systems of Systems Failures.
Proceedings of the 22nd International System Safety Conference.
Allen, P. M., J. Boulton, et al. (2005). The implications of complexity for business process and
strategy. Managing organisational complexity:
philosophy, theory and application. K.
Richardson. Mansfield, MA, ISCE Publishing: 397-418.
Andersson, G., P. Donalek, et al. (2005). "Causes of the 2003 major grid blackouts in North America
and Europe, and recommended means to Improve system dynamic performance." IEEE
Transactions on Power Systems 20(4): 1922-1928.
Asaro, P. M. (2011). "Remote-control crimes." IEEE Robotics & Automation 18(1): 68-71.
ASTRAEA.
(2011).
ASTRAEA.
Retrieved
March
2012,
from
ASTRAEA:
http://www.astraea.aero/index.html.
Azani, C. H. (2008). System of systems architecting via natural development principles. IEEE
International Conference on System of Systems Engineering, 2008. SoSE '08. Singapore,
IEEE: 1-6.
Azarnoush, H., B. Horan, et al. (2006). Towards optimization of a real-world robotic-sensor system of
systems. Proc World Automation Congress (WAC), Budapest.
Barabasi, A.-L. (2002). Linked. Cambridge, Mass, Perseus Publishing.
Berard, B. M. Bidoit. A. Finkel, F. Laroussinie, A. Petit, L. Petrucci, P. Schnoebelen. (2010). Systems
and Software Verification: Model-Checking Techniques and Tool. Springer Publishing
Company.
Bernus, P., L. Nemes, et al., Eds. (2003). Handbook on enterprise architecture. Heidelberg, Springer
Verlag.
Bertalanffy, L. v. (1950). An Outline of General System Theory. The British Journal for the Philosophy
of Science, 1(2), 134-165.
Bigley, G. A. and K. H. Roberts (2001). "The incident command system: high reliability organizing for
complex and volatile task environments." Academy of Management Journal 44(6): 1281-1299.
Chen, D., G. Doumeingts, et al. (2008). "Architectures for enterprise integration and interoperability:
Past, present and future." Computers in Industry 59(7): 647-659.
Cheng, B. H. C., H. Giese, et al. (2009). Software engineering for self-adaptive systems: a research
road map. Hot Topics on Software Engineering for Self-Adaptive Systems. B. H. C. C. et and
al., LNCS vol. 5525.
CIAIC (1978). A-102/1977 y A-103/1977 Accidente Ocurrido el 27 de Marzo de 1977 a las Aeronaves
Boeing 747, Matrícula PH-BUF de K.L.M. y Aeronave Boeing 747, matrícula N736PA de
PANAM en el Aeropuerto de los Rodeos, Tenerife (Islas Canarias). Madrid, Comision de
Investigacion de Accidentes e Incidentes de Aviacion Civil, Ministerio de Fomento, Espana.
Clayton, P. (2006). Conceptual foundations of emergence theory. The re-emergence of emergence.
P. Clayton and P. Sheldon-Davies. London, Oxford University Press.
Conklin, J. (2006). Dialogue mapping: building shared understanding of wicked problems. New York,
J. Wiley & Sons.
Court, G. (2007). Validating the NEC Benefits Chain. 11th ICCRTS(12).
Croom, S. and Batchelor, J. (1997) The development of strategic capabilities – an interaction view
Integrated Manufacturing Systems 8/5, 299–312.
Crossley, W. A. (2004). System of systems: An introduction of Purdue University schools of
engineering's signature area, Engineering systems symposium, Cambridge, MA.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 119
TAREA-PU-WP2-R-LU-9
Cullen, W. D. (1990). Report of the Official Inquiry into the Piper Alpha Disaster. London, Her
Majesty's Stationery Office.
Daclin, N., D. Chen, B. Vallespir. Enterprise interoperability measurement – Basic concepts,
Enterprise Modeling and Ontologies for Interoperability, Luxemburg, 2006.
Dahmann, J. and K. Baldwin (2008). Understanding the Current State of US Defense Systems of
Systems and the Implications for Systems Engineering. . 2nd Annual IEEE Systems
Conference. Montreal.
Daw, A. J. (2007). Keynote: On the wicked problem of defence acquisition. 7th AIAA Aviation
Technology, Integration and Operations Conference: Challenges in Systems Engineering for
Advanced Technology Programmes. Belfast, N.I., AIAA: 1-26.
DeLaurentis, D. and R. K. Callaway. 2004. “A System-of-Systems Perspective for Public Policy
Decisions.” Review of Policy Research 21(6): 829-837.
DeLaurentis, D., and Ayyalasomayajula, S., "Exploring the Synergy Between Industrial Ecology and
System-of-Systems to Understand Complexity: A Case Study in Air Transportation," Journal of
Industrial Ecology, 13 (2), April 2009, pp. 247-263.
DeLaurentis, D., Crossley,W.,Mane, M., "Taxonomy to Guide System-of-Systems Decision Making in
Air Transportation Problems." Journal of Aircraft 48(3) May-June 2011.
deMeyer, A., C. H. Loch, et al. (2002). "Managing project uncertainty: from variation to chaos." Sloan
Management Review 43(2): 60-67.
DG INFSO G3, Report of a Workshop on Systems of Systems, contribution to ICT work programme
2011+, Brussels, Sept. 21st 2009.
DOD, U. (2008). Systems engineering guide for systems of systems. Washington, DC, US
Department of Defense, Office of the Deputy Under Secretary of Defense for Acquisition and
Technology.
DOD (2011) Systems Engineering Guide for System-of-Systems, http://www.acq.osd.mil/se/docs/SEGuide-for-SoS.pdf [retrieved 12 Jan. 2011].
Fisher, D. A. (2006). An emergent perspective on interoperation in systems of systems, CarnegieMellon University.
Fitting, M. (1996). First-Order Logic and Automated Theorem Proving. Springer.
Flyvbjerg, B., Bruzelius, N., & Rothengatter, W. (2003). Megaprojects and risk - an anaotomy of
ambition. Cambridge: Cambridge University Press.
Frakes, W. B. and K. Kang (2005). "Software engineering research: status and future." IEEE
Transactions on Software Engineering 131(7): 529-536.
Fung, V., W. Fung, and Y. Wind, “Competing in a Flat World: Building Enterprises for a Borderless
World”, Wharton School Publishing, NJ, 2008.
Gartner. (2011). Integrate Operational Technology and IT for Business Success. Retrieved April 2011,
from http://www.youtube.com/watch?v=QQgeQbcGl6s.
Gover, J. E. (1993). "Analysis of US semiconductor collaboration." IEEE Transactions on Engineering
Management 40(2): 104-113.
Gregg, D. (1996). Emerging challenges in business and manufacturing decision support. The Science
of Business Process Analysis, ESRC Business Process Resource Centre, University of
Warwick, Coventry, UK, ESRC Business Process Resource Centre.
Haddon-Cave, C. (2009). The Nimrod review: An independent review into the broader issues
surrounding the loss of the RAF Nimrod MR2 Aircraft XV230 in Afghanistan in 2006. London,
The Stationery Office.
Hall, J. (2007). "Openness – an important principle for the stewardship of DoD IT standards." DSPO
Journal(Jan/Mar): http://www.dsp.dla.mil/app_uil/content/newsletters/journal/DSPJ-01-07.pdf.
Hammer, M. (2002). The Getting and Keeping Of Wisdom - Inter-Generational Knowledge Transfer in
a Changing Public Service. Ottawa, Research Directorate, Public Service Commission of
Canada.
Henshaw, M., Gunton, D., & Urwin, E. (2009). Collaborative, academic-industry research approach for
advancing systems engineering. 7th CSER Proceedings. Loughborough, Leics.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 120
TAREA-PU-WP2-R-LU-9
Henshaw, M. J., & Urwin, E. N. (2009). Demonstrating through-life and NEC requirements for defence
systems. (RTO-MP-SAS-80), Paper 11.
Henshaw, M. J. d., P. Lister, et al. (2011a). Capability engineering – an analysis of perspectives.
International Council on Systems Engineering (INCOSE) 21st International Symposium,
Denver, US.
Henshaw, M. (ed.) ...et al. (2011b) Assessment of open architectures within defence procurement
issue 1: systems of systems approach community forum working group 1 - open systems and
architectures. London: Crown owned copyright.
Hitchins, D. K. (2003). Advanced systems thinking, engineering and management. Norwood, MA.
Hollnagel, E., D. D. Woods, et al., Eds. (2006). Resilience engineering. Aldershot, UK, Ashgate
Publishing Ltd.
HSE (1980). ltalian Parliament Commission of Enquiry, Seveso - final report. London, Health & Safety
Executive.
Hsu, J. C. (2009). Emergent behaviour of systems-of-systems. INCOSE 2009 Conference. Los
Angeles.
Hubbard, D. (2009). The failure of risk management: Why it's broken and how to fix it. New Jersey:
John Wiley & Sons.
ICAO. (2011). 2011 State of Global Aviation Safety. Quebec: ICAO.
INCOSE Technical Board, (2006). Systems Engineering handbook. International Council on Systems
Engineering, INCOSE-TP-2003-002-03, Version 3.0, June 2006.
Iwu, F., & Kelly, T. (2009). Private Communication.
Jamshidi, M., Ed. (2008), Systems of Systems Engineering: Principles and Applications, CRC Taylor
& Francis, Boca Raton, FL.
Jamshidi, M., Ed. (2009). System of systems engineering - innovations for the 21st century, J. Wiley &
Sons.
Johnson, M. A. “System of Systems Standards,” Systems of Systems Engineering: Principles and
Applications, Chapter 18, (M. Jamshidi, ed.), CRC Taylor & Francis, Boca Raton, FL, 2008.
Johnson, M. (2009). System of systems standards. Systems of systems engineering - principles and
applications. M. Jamshidi. Boca Raton, FL, CRC Press.
Kappenman, J. G. and V. D. Albertson (1990). "Bracing for the geomagnetic storms." IEEE
Spectrum(March): 27-33.
Keating, C., R. Rogers, et al. (2003). "System of systems engineering." Engineering Management
Review 36(4): 62-75.
Kelly, T. (2009). Assurance Cases, Argumentation and Patterns. Retrieved May 2012, from
http://www.asq509.org/ht/a/GetDocumentAction/i/42037.
Kern, C. and Mark R. Greenstreet (1999). Formal verification in hardware design: a survey. ACM
Transactions on Design Automation of Electronic Systems (TODAES). 4(2). Pp.123-193.
Kletz, T. (2006). Hazop and Hazan. (4th Edition ed.): Taylor & Francis.
Krygiel, A. J., "Behind the Wizards Curtain: An Integration Environment for a System of Systems,"
Office of the Assistant Secretary of Defense Command and Control Research Program,
Washington D.C., 1999.
Kupferman, O. Moshe Y. Vardi, and Pierre Wolper. 2000. An automata-theoretic approach to
branching-time model checking. J. ACM 47, 2 (March 2000), 312-360.
Kuras, M. L. and B. E. White (2005). Engineering enterprises using complex-system engineering.
INCOSE 2005, Rochester NY, INCOSE.
Laprie, J.-C., K. Kanoun, et al. (2007). Modelling interdependencies between the electricity and
information infrastructures. Lecture Notes on Computer Systems. S. N. Oster, Springer. 4680:
54-67.
Law, A.M., and W. D. Kelton (2005). Simulation modelling and analysis, McGraw-Hill.
Lawson, D. (2005). Engineering Disasters - Lessons to be Learned, ASME Press.
LeMerle, M. (2011). How to prepare for a black swan. Strategy+Business, Booz & Co. 64.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 121
TAREA-PU-WP2-R-LU-9
Leveson, N., N. Dulac, et al. (2006). Engineering resilience into safety-critical systems. Resilience
engineering: concepts and precepts. E. Hollnagel, D. D. Woods and N. Leveson. Aldershot,
UK, Ashgate: Ch.8, pp. 95-123.
Lopez, D. (2006). Lessons learned from the front lines of the aerospace industry - balancing
complexity and risk.
Lopez, D. (2006) Digital Object Identifier:
IEEE/SMC International Conference on System of
Systems Engineering, Los Angeles, IEEE.
Mackley, T., S. Barker, et al. (2007). Concepts of agility in Network Enabled Capability. The NECTISE
project. Cranfield, Cranfield University, UK 8.
Mackley, T. (2008). Concepts of agility in Network Enabled Capability. Realising Network Enabled
Capability. Oulton Hall, Leeds, UK, BAE Systems.
Maier, M. W. (1998). "Architecting principles for systems-of-systems." Systems Engineering 1(4):
267-284.
Maier, M. W. (2005). Research challenges for system-of-systems. IEEE International Conference on
Systems, Man and Cybernetics, 2005. 4: 3149-3154.
Maier, M. W. (2006). Architecting principles for systems of systems. Proceedings of the Sixth Annual
International Symposium, International Council on Systems Engineering, Boston, MA.
Mane,M., Crossley, W.A., and Nusawardhana, "System-of-Systems Inspired Aircraft Sizing and
Airline Resource Allocation via Decomposition," Journal of Aircraft, 44 (4) July-August 2007, pp.
1222-1235.
Mane, M., "Concurrent Aircraft Design and Trip Assignment Under Uncertainty as a System-ofSystems Problem," Ph.D. Dissertation, Purdue Univ., School of Aeronautics and Astronautics,
West Lafayette, IN 2008.
McManus, H., and D. Hastings (2006). A framework for understanding uncertainty and its mitigation
and exploitation in complex systems. IEEE Engineering Management Review, 34(3): 81-94
Mittal, S. (2007). DEVS unified process for integrated development and testing of service oriented
architectures. Ph.D., University of Arizona.
MoD, U. (2005). Network Enabled Capability. http://www.mod.uk/NR/rdonlyres/E1403E7F-96FA4550-AE14-4C7FF610FE3E/0/nec_jsp777.pdf: JSP 777.
MoD, U. (2005). UK MOD, 2005. Network Enabled Capability (JSP 777). London: Crown.
Morris, E., P. Place, et al. (2006). System-of-systems governance: new patterns of thought.
Pittsburgh, PA, Carnegie-Mellon University.
Napolitano, F. (2010). The megacommunity approach to tackling the world’s toughest problems.
Strategy+Business. 60.
NASA (1986). Report of the Presidential Commission on the Space Shuttle Challenger Accident.
Washington, DC, National Aeronautics & Space Administration.
NCOIC
(2006).
NCOIC
Interoperability
Framework
(NIF(R)).
https://www.ncoic.org/technology/deliverables/nif/,
Network-Centric
Operations
Industry
Consortium.
Neaga, E. I., M. J. d. Henshaw, et al. (2009). The influence of the concept of capability-based
management on the development of the systems engineering discipline. . 7th Annual
Conference on Systems Engineering Research. Loughborough, UK.
Nendick, J. V., C. E. Siemieniuch, et al. (2006). Ergonomic aspects of ‘good engineering governance’
in the design process. Contemporary Ergonomics. P. Bust. London, Taylor & Francis: 62-66.
NTSB (2003). Loss of Control and Impact with Pacific Ocean, Alaska Airlines Flight 261, McDonnell
Douglas MD-83, N963AS, About 2.7 Miles North of Anacapa Island, California, January 31,
2000. . Washington, DC., National Transportation Safety Board.
Parasuraman, R., T. B. Sheridan, et al. (2000). "A model for types and levels of human interaction
with automation." IEEE Transactions on Systems, Man & Cybernetics 30(3): 286-297.
Peerenboom, J. P. and R. E. Fisher (2007). Analyzing cross-sector interdependencies. Proceedings
of the 40th Hawaii International Conference on System Sciences. Hawaii, IEEE Computer
Society: 112-119.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 122
TAREA-PU-WP2-R-LU-9
Perl, R. (2005). Combating Terrorism: The Challenge of Measuring Effectiveness, DTIC Document.
Perrow, C. (1984). Normal Accidents: Living with high-risk technologies. New Jersey: Princeton
University Press.
Provan, K. G. and H. B. Milward (1995). "A Preliminary Theory of Interorganizational Network
Effectiveness: A Comparative Study of Four Community Mental Health Systems."
Administrative Sciences Quarterly 40(1): 1-33.
Reason, J. T. (1989). Human Error and the problem of causality in analysis of accidents, invited
paper for Royal Society meeting on human factors in high risk situations.
Reason, J. (1998). "Achieving a safe culture: theory and practice." Work and Stress 12(3): 293.
Reason, J. (2001). Heroic compensations: The benign face of the human factor. Flight Safety
Australia: 28-41.
Reason, J. (2001). Managing the risks of organisational accidents, Ashgate.
Rebovich, G. (2008). Enterprise system of systems. Systems of systems engineering - principles and
applications. M. Jamshidi. Boca Raton, CRC Press: 169-190.
Rittel, H. W. J. and M. M. Webber (1973). "Dilemmas in a general theory of planning." Policy Sciences
4: 155-169.
Roberts, C. J., M. G. Richards, et al. (2009). Scenario planning in dynamic multi-attribute tradespace
exploration. SysCon2009 – IEEE International Systems Conference. Vancouver, BC, IEEE.
Roberts, K. H. and R. Bea (2001). "When Systems Fail." Organizational Dynamics 29(3): 179-191.
Robertson, D. A. (2005). Agent-based models to manage the complex. Managing organisational
complexity. K. A. Richardson. Greenwich,CT, USA, Information Age Publishing: 419-432.
Rochlin, G., T. D. LaPorte, et al. (1987). "The self-designing high-reliability organisation: aircraft
carrier flight operations at sea." Naval War College Review 40: 76-90.
Ross, A. M., D. E. Hastings, et al. (2004). "Multi-attribute tradespace exploration as front end for
effective space system design." Journal of Spacecraft and Rockets 41(1): 20-28.
Rudolph, J. W. and N. P. Repenning (2002). "Disaster dynamics: understanding the role of quantity in
organizational collapse." Administrative Science Quarterly 47(1): 1-30.
Sage, A. P.,and Cuppan, C. D., "On the Systems Engineering and Management of Systems of
Systems and Federations of Systems," Information, Knowledge, Systems Management, 2(4),
2001 pp. 325-345.
Sage, A. P., (2007). From engineering a system to engineering an integrated system family, from
systems engineering to system of systems engineering, 2007, IEEE International Conference
on System of Systems Engineering (SoSE). April 16-18th, 2007, San Antonio, Texas.
Sahin, F., M. Jamshidi, et al. (2007). A discrete-event XML-based simulation framework for system of
systems architectures. Proceedings of the IEEE International Conference on System of
Systems Engineering, San Antonio, TX, IEEE.
Schaeffer, M. D. (2006). System of Systems, Systems Engineering Guide: considerations for systems
engineering in a system of systems environment. Washington DC, Department of Defense.
Sheard, S. A. (2005). Practical applications of complexity theory for systems engineers. XV
International Symposium of the International Council on Systems Engineering (INCOSE),
Rochester, NY, INCOSE.
Sheffi, Y. (2005). The resilient enterprise: overcoming vulnerability for competitive advantage. Boston,
MA, MIT Press.
Shrivastava, P. (1987). Bhopal: anatomy of a crisis. Cambridge(Mass.):, Ballinger.
Siemieniuch, C. E. and M. A. Sinclair (2000). "Implications of the supply chain for role definitions in
concurrent engineering." International Journal of Human Factors and Ergonomics in
Manufacturing 10(3): 251-272.
Siemieniuch, C. E. and M. A. Sinclair (2002). "On complexity, process ownership and organisational
learning in manufacturing organisations, from an ergonomics perspective." Applied Ergonomics
33(5): 449-462.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 123
TAREA-PU-WP2-R-LU-9
Siemieniuch, C. E. and M. A. Sinclair (2008). "Using corporate governance to enhance `long-term
situation awareness' and assist in the avoidance of organisation-induced disasters." Applied
Ergonomics 39(2): 229-240.
Simon, H. A. (1981). The sciences of the artificial., MIT Press.
Sinclair, M. A. (2007). "Ergonomics issues in future systems." Ergonomics 50(12): 1957 - 1986.
Sousa-Poza, A., S. Kovacic, et al. (2008). "System of systems engineering: an emerging
multidiscipline." International Journal of Systems Engineering 1(1-2): 1-17.
Tainter, J. A. (1996). Complexity, problem solving, and sustainable societies. Getting down to Earth:
practical applications of ecological economics, Island Press.
Taleb, N. N. (2008). The black swan: the impact of the highly improbable. London, Penguin.
Tranfield, D., D. Denyer, et al. (2004). Management and development of High Reliability
Organisations. Bedford, UK, Cranfield University: 1-3.
TRKC. (2010). Towards an Integrated Transport System – Freight Focus: Research contributing to
integration and interoperability across Europe.
Urwin, E., Gunton, D., Reay Atkinson, S., & and Henshaw, M. (2011). Through-Life NEC Scenario
Development. Systems Journal, 5(3).
Vaill, P. B. (1998). The unspeakable texture of process wisdom. Organizational wisdom and executive
ocurage. S. Srivastva and D. L. Cooperrider. San Francisco, Jossey-Bass: 25-39.
Vernadat, F. B. (1996). Enterprise modelling and integration. London, Chapman & Hall.
Walker, B., Holling, C. S., Carpenter, S. R., Kinzig, A. (2004). "Resilience, adaptability and
transformability in social–ecological systems." Ecology and Society 9(2): 5.
Wallace, D.R (1989). Software verification and validation. IEEE Software 6(3): pp 10-17.
Wallach, W. and C. Allen (2009). Moral machines: teaching robots right from wrong. Oxford, UK,
Oxford University Press.
Wang, W., A. Tolk, et al. (2009). The levels of conceptual interoperability model: Applying systems
engineering priciples to M & S. Proceedings of the 2009 Spring Simulation Multiconference.
Weick, K. E., K. M. Sutcliffe, et al. (1999). " Organizing for high reliability: processes of collective
mindfulness." Research in Organisational Behaviour 21: 23-81.
Weick, K. E. and K. M. Sutcliffe (2001). Managing the unexpected : assuring high performance in an
age of complexity. San Francisco, Jossey-Bass.
Wells, G. D. and A. P. S. i. J. 2009b) (2008). Engineering of a system of systems. Systems of systems
engineering - principles and applications. M. Jamshidi.
Wenger, E., R. McDermott, et al. (2004). Cultivating communities of practice, Harvard Business
School Publications.
Wikipedia
(2012)
System
of
systems
engineering,
http://en.wikipedia.org/wiki/System_of_systems_engineering, accessed 28/2/12.
Wilkinson, M., King, P., James, A., Emes, M., & Bryant, P. (2010). Belief Systems in Systems
Architecting: Method and Preliminary Applications. 5th International Conference on System of
Systems Engineering. Loughborough: IEEE.
Williams, M. D. (2010). Learning about 'system resilience' from a hospital bed crisis. Contemporary
Ergonomics 2010. M. Anderson. London, Taylor & Francis: 605-613.
Willis, D. (2005). "Boeing's timeless deterrent, part 1: B-52 Stratofortress – from conception to Hanoi."
Air Enthusiast 119(Sept/Oct): 50-73.
Willis, D. (2005). "Willis, David. "Boeing's timeless deterrent, part 2: B-52 – the permanent spear tip."
Air Enthusiast 120(Nov/dec): 38-81.
Wojcik, L. A. and K. C. Hoffman (2006). Systems of systems engineering in the enterprise context: a
unifying framework for dynamic. IEEE/SMC International Conference on System of Systems
Engineering, IEEE.
Woods, D. D. and E. Hollnagel (2006). Joint cognitive systems: patterns in cognitive systems
engineering. Basingstoke, Taylor & Francis.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 124
TAREA-PU-WP2-R-LU-9
Yang, Y., B. Boehm, et al. (2005). A contextualized study of COTS-based e-service projects. 4th
International Conference on COTS-based Software Systems - ICCBSS 2005, Bilbao, Spain,
Springer.
Zachman, J. A. (1987). "A framework for information systems architecture." IBM Systems Journal
26(3): 276-292.
Zeigler, B. P., T. G. Kim, et al. (2000). Theory of modeling and simulation: integrating discrete event
and continuous complex dynamic systems. New York, Academic Press.
Release Date: 4th May 2012
© Loughborough University 2012
Page | 125
TAREA-PU-WP2-R-LU-9
APPENDICES
This chapter describes state-of-the-art in SoS by mapping the critical areas identified in the
Part A and the Part B of this report to various EU / US projects and any other organisations
addressing identified problems / issues in the development and management of large
complex systems. The appendix table 1 should be read in conjunction with the appendix
table 2 (elaborating on the EU FP7 project abbreviations and their application domains used
in the appendix table 1). The appendix table 3 describes summary of projects in the US.
Appendix 1: Summary of Key SoS Activities in the EU
SoS Areas
Project / Organisation
Current Research
Critical Problem Areas
(Chapter 3)
CERTAINTY
Introduce
a
disruptive
methodology for the design of
complex critical applications.
COMPASS
Augment existing industry tools
for SoS.
KARYON
Realise the various safety
classes defined in the standard
ISO 26262.
ROAD2SOS
Develop
research
and
engineering
roadmaps
to
identify
future
RTD
and
innovation (RTD+I) strategies
for Europe in the field of SoS.
VERDI
Contribute to increase the
safety and robustness, and to
meet the needs of upcoming
standards like ISO26262.
AGILE
Develop and evaluate an
integrated Large Scale Control
Systems (LSCS) – design
methodology
applicable
to
large-scale systems of arbitrary
scale,
heterogeneity
and
complexity and capable of being
intrinsically self-tuneable, able
to
rapidly
and
efficiently
optimise LSCS performance
when short-medium- and long-
System Design
(Chapter 4)
Release Date: 4th May 2012
© Loughborough University 2012
Page | 126
TAREA-PU-WP2-R-LU-9
SoS Areas
Project / Organisation
Current Research
time variations affect the large
scale system.
Release Date: 4th May 2012
CERTAINTY
New methodology and design
tools.
COMPASS
Develop a formal semantic
foundation, the first specifically
for SoSE to support the analysis
of global SoS properties.
DANSE
Develop new approaches for
the design and management of
the operation of SoS.
EC-SAFEMOBIL
Address the development of
new estimation/prediction and
cooperative
control
methodologies
and
their
practical application to highly
mobile
entities
such
as
unmanned aerial systems.
IMC-AESOP
The future “Perfect Plant” will
enable monitoring and control
information flow in a cross-layer
way. As such the different
systems including SCADA/DCS
will be part of a distributed
ecosystem, where components
can dynamically be discovered,
added
or
removed,
and
dynamically
exchange
information and collaborate.
KARYON
System solutions for predictable
and safe coordination of smart
vehicles that autonomously
cooperate and interact in an
open and inherently uncertain
environment.
SCUBA
Create a novel architecture,
services,
and
engineering
methodologies
for
robust,
adaptive, self-organising, and
cooperating monitoring and
control systems. This addresses
the
current
problems
of
heterogeneity
and
interoperability, installation and
commissioning complexity, and
adaptability and robustness in
the building monitoring and
control space.
© Loughborough University 2012
Page | 127
TAREA-PU-WP2-R-LU-9
SoS Areas
Project / Organisation
Current Research
VERDI
Verdi will have a share in
maintaining
Europe’s
competiveness in the field of
designing
electronic
components for heterogeneous
SoS.
Mission and Surveillance
Systems, Thales (Defence)
Architectures
(Chapter 5)
COMPASS
Develop a modelling framework
for SoS architectures.
DANSE
Develop approaches for SoS
architecture – continuous and
non-disruptive
system
component integration.
EC-SAFEMOBIL
Open Approach to Engineering
(Chapter 6)
Release Date: 4th May 2012
Develop
manned
and
unmanned platforms allowing
building a system of systems for
the military forces, making
those systems interoperable.
Develop
paradigms.
architectural
IMC-AESOP
Investigate a Service-oriented
Architecture (SOA) approach for
monitoring and control of very
large scale process control
systems (batch and continuous
process applications).
KARYON
Define safety architecture for
sensor-based
cooperative
systems.
SCUBA
Create a novel architecture,
services,
and
engineering
methodologies
for
robust,
adaptive, self-organising, and
cooperating monitoring and
control systems. This addresses
the
current
problems
of
heterogeneity
and
interoperability, installation and
commissioning complexity, and
adaptability and robustness in
the building monitoring and
control space.
AGILE
To ease implementation and
deployment of the AGILE
© Loughborough University 2012
Page | 128
TAREA-PU-WP2-R-LU-9
SoS Areas
Project / Organisation
Current Research
system
in existing openarchitecture
SCADA/DCS
infrastructures, a set of opensource interfacing tools are
being developed.
Modelling and Simulation
(Chapter 7)
Network Enablement
(Chapter 8)
Release Date: 4th May 2012
COMPASS
Build an open, extendible tools
platform
with
integrated
prototype plug-ins for model
construction, simulation, test
automation, static analysis by
model-checking, and proof, and
links
to
an
established
architectural
modelling
language.
ADVANCE
Use of a common formal
modelling language supported
by methods and tools for
simulation
and
formal
verification.
CERTAINTY
Extend modelling languages
semantic: This project will
advance the state of the art by
handling
criticality
levels,
composability
and
compositionality capabilities as
properties at a functional
description level.
DANSE
Novel supporting tools for
analysis,
simulation
and
optimisation.
KARYON
Simulation and mixed reality
techniques.
DANSE
Innovative architectures that
allow the dynamic affiliation of
components
so
that
the
behaviour of the ensemble is
not disturbed.
EC-SAFEMOBIL
Development of new distributed
methods for safe real-time
networked
cooperation,
coordination, and control.
IMC-AESOP
The
SoA-based
approach
proposed can, on one hand,
simplify the integration of
monitoring and control systems
© Loughborough University 2012
Page | 129
TAREA-PU-WP2-R-LU-9
SoS Areas
Project / Organisation
Current Research
on application layer. On the
other hand, the networking
technologies that are already
known to control engineers
could also simplify the inclusion
of or migration from existing
solutions and the integration of
the next generation SCADA and
DCS systems at network layer.
Validation and Verification
(Chapter 9)
Release Date: 4th May 2012
WIBRATE
Provide a complete end-to-end
solution for carrying out fully
automated
condition-based
maintenance for high vibration
environments,
thus
totally
eliminating the labour-intensive
process of periodic monitoring.
In
addition,
WIBRATE’s
continuous monitoring system
also
provides
proactive
maintenance capability, offering
detailed historical information
about the status of the
equipment in the event of a
failure.
ADVANCE
Develop a unified tool-based
framework for automated formal
verification
and
simulationbased validation of cyberphysical systems. Uniquely
addresses
simulation
and
formal verification in a single
framework.
AGILE
The integrated LSCS design
system to be developed within
this project along with the
interfaces will be extensively
tested and evaluated into two
real-life large-scale Test Cases.
COMPASS
Develop methods and tools that
support
the
design
and
validation of SoS using a
precise model-based approach.
DANSE
Validation
of
approaches by
cases.
VERDI
This will link simulation-based,
“pre-tape-out” system analysis
© Loughborough University 2012
new
SoS
real-life test
Page | 130
TAREA-PU-WP2-R-LU-9
SoS Areas
Project / Organisation
Current Research
and verification with system
validation and analysis of the
physical
prototype
using
measurement equipment.
Qualification and Assurance
(Chapter 10)
Management, Control and
Operation
(Chapter 11)
Release Date: 4th May 2012
WIBRATE
New SoSE techniques to help
create a synergy between
individual complex systems to
ensure optimal monitoring of the
overall vibration control system.
and
Using
self-learning
distributed strategies.
CERTAINTY
To be a key enabler of the
certification process for mixed
criticality embedded systems
featuring functions dependent
on information of varying
confidence.
OPENCOSS
Devise a common certification
framework that spans different
vertical markets for railway,
avionics
and
automotive
industries.
BALCON
Review the R&D priorities and
capacity in the area of
monitoring and control systems
and applications in the EU and
the West Balcon Countries to
assess
collaboration
opportunities.
COMPASS
Build an open, extendible tools
platform
with
integrated
prototype plug-ins for model
construction.
DANSE
Address the difficult technical,
management,
and
political
challenges to organisations
attempting to unify the strengths
of the numerous infrastructures
and objects made available by
the advances in communication,
sensing
computing
and
actuating capabilities.
EC-SAFEMOBIL
Develop new robust distributed
probabilistic
state
estimation/prediction and event
detection/tracking methods for
© Loughborough University 2012
Page | 131
TAREA-PU-WP2-R-LU-9
SoS Areas
Project / Organisation
Current Research
complex high mobility systems.
Complex Socio-technical
Features
(Chapter 12)
Release Date: 4th May 2012
IMC-AESOP
The
SoA-based
approach
proposed by this project can, on
one
hand,
simplify
the
integration of monitoring and
control systems on application
layer. On the other hand, the
networking technologies that
are already known to control
engineers could also simplify
the inclusion of or migration
from existing solutions and the
integration
of
the
next
generation SCADA and DCS
systems at network layer.
KARYON
Achieve a high availability of the
control
system
complex
investigating new ways of
achieving
fault-tolerant
distributed control that allow
maintaining a high performance
level in the presence of
uncertainties and failures.
DANSE
Design and management of
SoS
using
evolutionary,
adaptive and iterative SoS lifecycle model.
EC-SAFEMOBIL
Autonomous systems operation
& development of techniques to
support the exploitation of
unmanned platforms in nonrestricted areas.
KARYON
Autonomous systems, looking
for robust cruising strategies for
vehicles & system architecture
based on a small local safety
kernel to prevent dangerous
behavior.
ROAD2SOS
The need to enhance the
classical view of Complex
System Engineering towards
SoS Engineering & develop
advanced
research
and
engineering
roadmaps
to
identify
future
RTD
and
Innovation (RTD&I) strategies
for Europe in the field of SoS
© Loughborough University 2012
Page | 132
TAREA-PU-WP2-R-LU-9
SoS Areas
Performance Measurement
(Chapter 13)
Release Date: 4th May 2012
Project / Organisation
Current Research
Pragmatic EA ltd (Numerous)
Pragmatic family of Architecture
Frameworks (PEAT).
AGILE
Based on recent advances of its
partners on convex design for
LSCSs and robust and efficient
LSCS self-tuning, this project
will develop and evaluate an
integrated design methodology
proactive,
arbitrarily-close-tooptimal LSCS performance;
Being intrinsically self-tuneable,
able to rapidly and efficiently
optimize LSCS performance
when short- medium- and longtime variations affect the largescale
system;
Providing
efficient, rapid and safe faultrecovery
and
LSCS
reconfiguration; and, Achieving all
the above, while being scalable
and modular.
CERTAINTY
New methodology and design
tools, applicable in diverse
industrial sectors, will be
validated
in
an
avionics
application on a multi-core
architecture: an existing Flight
Management System will be
analysed using the analysis
tools to specify which part is at
which critical level redesigned
and composed according to the
methodology, to improve the
certification
process
while
safeguarding reliability. The
results will be measurable
(processing time, costs).
DANSE
Provide novel supporting tools
for analysis, simulation, and
optimization; organized in an
integrated environment.
EC-SAFEMOBIL
The aim is to precisely control
hundreds of entities efficiently
and reliably and to certify
developed
techniques
to
support the exploitation of
unmanned platforms in nonrestricted areas.
© Loughborough University 2012
Page | 133
TAREA-PU-WP2-R-LU-9
SoS Areas
Technical and Engineering
Governance
(Chapter 14)
Release Date: 4th May 2012
Project / Organisation
Current Research
IMC-AESOP
This project deals with several
key challenges that arise such
as real-time web services,
interoperability, plug and play,
self-adaptation, reliability, costeffectiveness,
energyawareness, high-level crosslayer
integration
and
cooperation, event propagation,
aggregation and management.
SCUBA
Create a novel architecture,
services,
and
engineering
methodologies
for
robust,
adaptive, self-organising, and
cooperating monitoring and
control systems to address the
current
problems
of
heterogeneity
and
interoperability, installation and
commissioning complexity, and
adaptability and robustness in
the building monitoring and
control space.
VERDI
Improve the design efficiency
and quality by developing
methods and tools to address
the design challenges related to
heterogeneous integration. It
will link simulation-based, pretape-out system analysis and
verification
with
system
validation and analysis of the
physical
prototype
using
measurement equipment.
WIBRATE
Control
operations
are
supported
by
WiBRATE’s
unique ultra-low power Digital
Enhanced
Cordless
Telecommunications
(DECT)
based technology that allows
robust,
real-time
wireless
communication even in harsh
industrial environments.
DANSE
Address the difficult technical,
management,
and
political
challenges to organisations
attempting to unify the strengths
of the numerous infrastructures
and objects made available by
the advances in communication,
sensing
computing
and
© Loughborough University 2012
Page | 134
TAREA-PU-WP2-R-LU-9
SoS Areas
Project / Organisation
Current Research
actuating capabilities.
OPENCOSS
Future embedded systems will
be comprised of heterogeneous
dynamic coalitions of SoS and
hence will be built to numerous
standards and regulations.
Risk Mitigation
(Chapter 15)
EC-SAFEMOBIL
Preserve safety and reliability
while optimising performance,
taking into account uncertainties
of sensor data and unreliability
of wireless data transmission
links.
Training
(Chapter 16)
BALCON
Organise
a
variety
of
networking,
training
and
awareness raising activities to
bring research and industrial
actors of the two regions closer,
thus preparing the ground for
concrete
EU-WBC
R&D
activities in the monitoring and
control area.
DANSE
Develop training material and
classes that help advance the
knowledge base of European
industry and government to
allow the creation of new
services and to substantially
improve existing ones to levels
of
efficiency
that
are
unthinkable today.
Appendix Table 1: Summary of Key SoS Activities in the EU
Release Date: 4th May 2012
© Loughborough University 2012
Page | 135
TAREA-PU-WP2-R-LU-9
Appendix 2: EU FP7 Project Abbreviations and Application Domains
Abbreviation
Description
Domain (Sector / Areas)
ADVANCE
Advance
Design
and
Verification
Environment for Cyber-physical System
Engineering.
Energy: (Unspecified systems)
Transport:
(Intelligent
Transport Systems)
AGILE
Rapidly-deployable,
Self-tuning,
SelfControl
reconfigurable,
Nearly-optimal
Design for Large-scale Nonlinear Systems.
Energy: (Building)
Transport: (Traffic Network)
Manufacturing:
(Process,
Discrete)
BALCON
Boosting EU-Western Balkan Countries
research Collaboration in the Monitoring and
Control area.
Numerous: (Unspecified)
Comprehensive Modelling
Systems of Systems
Numerous: (Unspecified)
COMPASS
CERTAINTY
for
Certification of Real Time
Designed for Mixed Criticality
Advanced
Applications
Transport: (Avionics)
DANSE
Designing for Adaptability and Evolution in
Systems of Systems Engineering
EC-SAFEMOBIL
Estimation and Control for Safe Wireless
High Mobility Cooperative Industrial Systems
IMC-AESOP
Architecture for Service-Oriented Process –
Monitoring and Control
Manufacturing: (Automotive)
KARYON
Kernel-based Architecture for Safety Critical
Control
Manufacturing: (Automotive)
Transport: (Avionics)
OPENCOSS
Open Platform for Evolutionary Certification
of Safety-critical Systems
Manufacturing: (Automotive)
Transport:
(Avionics,
Railways)
ROAD2SOS
Development of Strategic Research and
Engineering Roadmaps in Systems of
Systems Engineering and Related Case
Studies
Energy:
(Distributed
Generation and Smart Grids)
Manufacturing:
(Multi-site
Industrial Production)
Release Date: 4th May 2012
Transport: (Aerospace, Land
Systems)
Other: (Systems Engineering,
Water Treatment and Supply)
Transport: (Aeronautics)
Other:
(Security,
Warehousing)
© Loughborough University 2012
Page | 136
TAREA-PU-WP2-R-LU-9
Abbreviation
Description
Domain (Sector / Areas)
Transport: (Multi-modal Traffic
Control)
Other: (Emergency, Crisis
Management)
SCUBA
Self-organising, Cooperative, and Robust
Building Automation
Energy: (Management)
Transport: (Unspecified)
Other: (Security, Safety)
VERDI
Verification for Heterogeneous
Design and Integration
Manufacturing: (Automotive)
WIBRATE
Reliable
Wireless, Self-powered Vibration Monitoring
and Control for Complex Industrial Systems
Manufacturing: (Automotive)
Transport:
(Aerospace,
Railways)
Appendix Table 2: EU FP7 Project Abbreviations and Application Domains
Release Date: 4th May 2012
© Loughborough University 2012
Page | 137
TAREA-PU-WP2-R-LU-9
Appendix 3: Summary of Key SoS Activities in the US
SoS Areas
Project / Organisation
Current Research
Critical Problem Areas
(Chapter 3)
Purdue University
Project on SoS architecture with
missile defence agency.
Work of C. Keating, Old
Dominion University
Nature of emergence and
philosophical perspective in
SoS, operation, maintenance,
for
and
considerations
emergence in SoS.
University of Texas San Antonio
(UTSA)
Project on two smart microgrids for photovoltaic energy
with local utility company
researching on: (a) Network
control of smart grid. (b) Energy
management of a smart home.
(c) Electric car charging SoS.
NSF (National Science
Foundation)
Has a specific program in SoS
Engineering design. Numerous
projects are funded.
Work of M. Johnson
(Aerospace) and M. Jamshidi
(UTSA)
SoSE,
standards;
standardization; accreditation;
certification; registration; and
interoperability.
System Design
(Chapter 4)
NB: Aerospace Industry, US
DoD and UARC are putting
extensive efforts for an ISO
International Organization for
Standardization.
Architectures
(Chapter 5)
SERC / Purdue University (see
“Simulation and Modelling”
section later)
SERC / Purdue University (see
“Simulation
and
Modelling”
section later).
Open Approach to Engineering
(Chapter 6)
US DoD (Department of
Defence)
Numerous projects on open
interface,
synergism,
selfgovernment,
emergence,
conservation, reconfiguration,
symbiosis
and
modularity
principles.
Modelling and Simulation
(Chapter 7)
SERC (Systems Engineering
Research Centre)
RT-36 “Assessing the Impact
of Development Disruptions
and
Dependencies
in
Release Date: 4th May 2012
© Loughborough University 2012
Page | 138
TAREA-PU-WP2-R-LU-9
SoS Areas
Project / Organisation
Current Research
Analysis of Alternative of
System of Systems” being
performed
by
Purdue
University.
SoS architecture modeling
such
as
DODAF,
UML,
Bifurcated
Model-Continuity
Based Life-Cycle Methodology,
DEVS Unified Process and its
Service
Oriented
Implementation,
SoS
simulation for Heterogeneous
Mobile
Sensor
Networks,
Agent-Implemented
Test
Instrumentation System, etc.
Numerous locations in the US,
researching on architecture,
system architecture, enterprise
architecture, design principles,
design
patterns
and
architecture framework.
Network Enablement
(Chapter 8)
SERC (Systems Engineering
Research Centre)
Information
on
demand,
Services on Demand, Ubiquity
and Degrees of Connectivity,
Syntactic
and
semantic
interoperability,
Service
Oriented
Architecture,
Netcentric SOA, Role of the Human
in SOA, Documenting Netcentric Architectures, Common
Parts of a Net-centric SOA,
NCE
Architecting
Considerations,
Net-centric
System Architect.
US Aerospace industry /
Lockheed Martin, Boeing, etc.
Validation and Verification
(Chapter 9)
Release Date: 4th May 2012
Computer Science Faculty at
Naval Post-Graduate School.
Several navy funded projects in
software
validation
and
verification.
DARPA (Defence Advanced
Research Projects Agency)
Adaptive Vehicle Make program
addressing
revolutionary
approaches to the design,
verification, and manufacturing
of complex defence systems
and vehicles.
© Loughborough University 2012
Page | 139
TAREA-PU-WP2-R-LU-9
SoS Areas
Project / Organisation
Current Research
Purdue University
Verification and Validation of
SoS
models
for
Lunar
Command,
Control,
Communication,
and
Information
Architecture
in
Aerospace engineering.
UAV Laboratory at the
University of Kansas in
Lawrence
Design,
development
and
testing of flight vehicle and flight
control systems.
NSF (National Science
Foundation)
Has Cyber-Physical
Program.
Qualification and Assurance
(Chapter 10)
Management, Control and
Operation
(Chapter 11)
Work of Brian Sauser
Work of Ferat Sahin and
Collaborators
Complex Socio-technical
Features
(Chapter 12)
Performance Measurement
(Chapter 13)
Release Date: 4th May 2012
Systems
Control
Paradox
in
SoS
Management,
Autonomy,
Belonging,
Connectivity,
Diversity, and emergence.
Robot
SoS
intelligence.
for
swarm
Mitre Corporation
Several projects in the areas of
Cognition, Complexity, Complex
Systems, Complex Systems
Engineering,
Emergence,
Human-Centric, Mindset, MultiScale
Analysis,
Multi-View
Analysis, Organization, Scale,
Socio-Cognitive, SoS, System
of Systems, Surprise, etc.
MIT Engineering Systems
Division
Expanding an existing system
tradespace
exploration
methodology by adding SoSspecific design considerations.
School of Interactive
Computing, College of
Computing, Georgia Tech
Ethics in autonomous systems.
US Homeland Security at Old
Dominion’s NCSoSE (National
Centres for Systems of Systems
Engineering)
Numerous projects funded.
Work of Paul R. Garvey ChienChing Cho and Mitre Corp.
Measurement
of
SoS
performance risk, Individual
© Loughborough University 2012
Page | 140
TAREA-PU-WP2-R-LU-9
SoS Areas
Project / Organisation
Current Research
system’s technical performance
measures, Overall measure of
performance risk, Technical
Risk
Index
(TRI),
SoS
capability, etc.
Technical and Engineering
Governance
(Chapter 14)
SERC (Systems Engineering
Research Centre)
RT-25 “Requirements Definition
for Net-Centric Enterprises”.
Work of Sage and Jamshidi.
System of Systems, Federation
of Systems, Lead System
Integrator, Enterprise System
Engineering, Complex Systems,
Complex Adaptive Systems,
Motivation for SoSE, Federalist
Management
Principles,
Handy’s
Five
Principles,
Structural Approach, Develop
Framework
for
SoSE,
Challenges in SoSE, Vignette,
Information Flow in SoSE,
Among
the
Systems
Engineering Groups, Validation,
Principles
and
Axioms,
Engineering
Functional
Behaviour.
Risk Mitigation
(Chapter 15)
SERC (Systems Engineering
Research Centre)
“Early Identification of
Related Program Risks”.
Training
(Chapter 16)
US Homeland Security at Old
Dominion’s NCSoSE (National
Centres for Systems of Systems
Engineering)
Numerous projects funded such
as “Research & Training for
Next
Generation
SoS
Engineers”,
“Systems
of
Systems Engineering Education
st
Century Complex
for 21
Systems”, etc.
University of Texas San Antonio
Established courses on SoSE,
Network Control, etc.
SE-
Appendix Table 3: Summary of Key SoS Activities in the US
Release Date: 4th May 2012
© Loughborough University 2012
Page | 141