state of the art v3

Document No TAREA-PU-WP2-D-LU-9 Internal/External External Status Final Version 3.0 Date 15th July 2013

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 Revised version

Prepared by Dr. Vishal Barot, Prof. Michael Henshaw, Prof.

Carys Siemieniuch, Dr. Murray Sinclair, Dr. Soo Ling Lim, Ms. Sharon Henson, 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 © 2013

State of the Art on Systems of Systems Management and Engineering

Release Date: 15 July 2013 © Loughborough University Page | 2

SUMMARY This updated version of the 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 is divided into 4 main parts: Part A provides the scope of the report and sets the overall SoS context; Part B details the areas that have been selected for review within this report; Part C describes the identification of critical advances required in SoS operation through case study analysis carried out in the period November 2011 to February 2012; and Part D describes the process of identifying the SoS Research Priorities to be implemented in the Strategic Research Agenda (Deliverable 5.2 due to be delivered in July 2013 entitled ‘The Systems of Systems Engineering Strategic Research Agenda’). The report concludes with a summary and a new appendix, which provides a review of standards relevant to the SoS domain. In terms of the content of the report Part A provides an introduction to Systems of Systems in the domains of interest (Chapter 3) and has tried to differentiate between Systems and Systems of Systems. Chapter 4 takes account of Global Drivers which SoS must take into account and where SoSE can contribute a great deal of value added. In Part B a range of research areas were selected based on the expertise of the authors, literature reviews and most importantly the input from the evolving expert community. This review dealt with 6 key high level problem SoS problem areas in Chapter 5 before moving on to cover specific identified areas of SoS and SoSE in Chapters 6 to 19 as detailed below: • Trade-off • Standards • SoS Architectures • The Open Approach to SoS Engineering • SoS Modelling and Simulation • SoS Network Enablement • SoS Validation and Verification • SoS Qualification and Assurance • Management, Control and Operation of SoS • Complex Socio-Technical Features of SoS • SoS Performance Measurement • SoS Technical and Engineering Governance • Risk Mitigation in SoS • Training Finally in Chapter 20 in Part C the document presents the case study research that was carried out to complement the State of the Art review in Part D, which is followed by an overview of how the project identified the SoS research priorities that are


encapsulated in the Strategic Research Agenda to be delivered later in the project life-cycle (Chapter 21).

The content of the SoA has been fed into the overall process for the generation of the Strategic Research Agenda and as a result of that process and on-going consultation with expert community both in Europe and USA this second revised version of the SoA has been published.

The contents of this document have been taken forward via a range of workshops and key elements from it have been crystallised in the final deliverable to the EU entitled ‘The Systems of Systems Engineering Strategic Research Agenda”, Deliverable D5.2 published in July 2013.


Table of Contents Part A: Scope of the Report and Setting the Sos Context 9

1 Introduction 9 1.1 Background to the T-AREA Project 9 1.2 Objectives of the Study and Scope 9 1.3 Report Structure 10 1.4 Glossary of Key Terms used in this Report 10

2 Process for the Generation of the SOA Report 13 2.1 Overall Process for the Generation of the Strategic Research Agenda 14

3 Introduction to System of Systems (SoS) 18 3.1 Definition and Characteristics of SoS 18

3.1.1 A Manufacturing Unit 19 3.1.2 An Energy Supply SoS 20 3.1.3 An Integrated Transport SoS 20 3.1.4 A Service and People-Oriented SoS 21

3.2 SoS Boundary Considerations 22 3.3 Types of SoS 23 3.4 SoS Application Domains 24 3.5 Differences between Systems and Systems of Systems 25 3.6 Ultra-large Scale Systems (ULSS) 27 3.7 Cyber-Physical Systems 29

4 Global Drivers for SOS/SOSE 32 4.1 A ‘doom and gloom’ Scenario 32 4.2 Avoiding the doom and gloom’ Scenario 32 4.3 Key Global Drivers for Research into SoS/SoSE 33

4.3.1 Population Demographics 34 4.3.2 Food Security 34 4.3.3 Energy Security 35 4.3.4 Resource Utilisation and Re-utilisation 36 4.3.5 Emissions and Global Climate 37 4.3.6 Community Security and Safety 38 4.3.7 Transportation 39 4.3.8 Globalisation of Economic and Social Activity 40

4.4 Summarising the Global Drivers 40

Part B: Areas for Review 42

5 Discusion on High level SoS Problem Areas 48 5.1 Safety, Security and Integrity 48 5.2 Emergence 50 5.3 Interoperability 53 5.4 Agility 54 5.5 Reconfigurability 56


5.6 Reuse 57

6 Trade-off 57

7 Standards 60 7.1 General Comments on Standards and SoSE 60 7.2 Specific International Standards of Relevance to SoSE 61

8 SoS Architectures 63 8.1 The Role of SoS Architecting 63 8.2 Challenges in Architecting SoS 64 8.3 Architecture Analysis 65

9 The Open Approach to SoS Engineering 67 9.1 UK MoD Systems of Systems Approach (SoSA) 68

10 SoS Modelling and Simulation 71 10.1 Role of Modelling and Simulation 71 10.2 Challenges of an Emerging Discipline 72

11 SoS Network Enablement 73 11.1 NEC Themes 73 11.2 Impact of NEC on Systems Engineering 75

11.2.1 SoS Architecting 76 11.2.2 Design Across all Defence Lines of Development 77 11.2.3 Design for NEC 77 11.2.4 Managing Evolving Requirements 78 11.2.5 Life Cycle Models for NEC Systems 78 11.2.6 Dependability and Qualification of NEC Systems 79 11.2.7 Organisational Learning Strategies 79 11.2.8 Collaboration 79

12 SoS Validation and Verification 80 12.1 Challenges 80

13 Sos Qualification and Assurance 81 13.1 Research Challenges 81

14 Management, Control and Operation of SoS 83 14.1 SOS Types and Hierarchy 83 14.2 Control of SoS 83 14.3 Decision Making and Control Methods 84 14.4 SOS Decision, Control and Management in ATS: Applications 85

14.4.1 Airline/FMC Modeling and Solution 86 14.4.2 ATS Modeling and Solution 87

15 Complex Socio-Technical Features of SoS 90 15.1 Human and Organisational Aspects of SoS 90

15.1.1 Enterprise Architectures and Enterprise Architecture Frameworks 90 15.1.2 Enterprise Modelling (EM) 91


15.2 Socio-Technical Boundaries for SoS 92 15.3 Organisational Systems Engineering in SoS 93

15.3.1 Government 95 15.3.2 Strategic 95 15.3.3 Policy 96 15.3.4 Operations 97 15.3.5 Transactions 99 15.3.6 Summary 99

15.4 The Effects of Organisational Complexity on SoS 100 15.4.1 Approaches to Complexity and Resilience in SoS 101

15.5 Decision Making in SoS 103 15.5.1 Authority, Responsibility & Autonomy 103 15.5.2 Decisions & Decision-Making at the SoS Level 104

15.6 Legal and Ethical Implications for Societal Acceptance 105

16 SoS Performance Measurement 108 16.1 Concept of MoE 108 16.2 Some Challenges in Measuring SoS Performance 108

17 SoS Technical and Engineering Governance 110 17.1 Background 110 17.2 Aims of Technical and Engineering Governance 111 17.3 Possible Model of Technical and Engineering Governance (TEG) 113 17.4 TEG Framework for Implementation 115

18 Risk Mitigation in SoS 116 18.1 Risk and its Ownership 116

19 Training 118 19.1 Training Need 118 19.2 SoSE Training Focus 118

Part C: Case Study Analysis 121

20 Case study Investigation 121 20.1 Defence Sector 121

20.1.1 Tactical Data Link 121 20.1.2 AMC 123

20.2 IT Sector 123 20.2.1 Human Tracking 123 20.2.2 NPfIT 125

20.3 Transport Sector 127 20.3.1 AMC 127 20.3.2 ATS 129 20.3.3 Fleet Level 131 20.3.4 SESAR 132

20.4 Manufacturing Sector 134 20.4.1 SCADA DCS 134


20.5 Other Sectors 136 20.5.1 Emergency Response (EM) 136 20.5.2 Water Management (WM) 137

20.6 Investigation Summary 138

Part D: Setting the SoS Research Priorities 142

21 SoS Research Priorities 142 21.1 Expert Workshop Activity 142

21.1.1 Workshop Format 142 21.2 Findings from the Expert Workshop 143

21.2.1 Single Transferable Vote 149 21.2.2 Workshop Conclusion 150

21.3 Comparison of Workshop and Case Study Outcomes 150

22 Summary 153

23 References 154

24 APPENDIX 1: REVIEW OF STANDARDS 160 24.1 Part 1: IT-relevant International Standards Grouped into Usage Clusters 160 24.2 Part 2: Selected International Standards for Organisations involved in SoS 163


PART A: SCOPE OF THE REPORT AND SETTING THE SOS CONTEXT

1 INTRODUCTION

1.1 Background to the T-AREA Project T-AREA-SoS is a 24-month Support Action (SA) with the primary purpose of formulating a Strategic Research Agenda (SRA) for Systems of Systems Engineering (SoSE). 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 which will support the identification of key enablers for European competiveness and societal improvement from Systems of Systems (SoS) contributions to the Horizon 2020 Programme. 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 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 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 4 main parts: Part A (Chapters 1 to 4) provides the scope of the report and sets the overall SoS context; Part B (Chapters 5 to 19) details the areas that have been selected for review within this report; Part C (Chapter 20) describes the identification of critical advances required in SoS operation through case study analysis carried out in the period November 2011 to February 2012; and Part D (Chapter 21) describes the process of identifying the SoS Research Priorities to be implemented in the Strategic Research Agenda (Deliverable 5.2). The report concludes with a summary and a new appendix which provides a comprehensive review of standards relevant to the SoS domain. 1.4 Glossary of Key Terms used in this Report The definitions which follow are gleaned largely from the Guide to the Systems Engineering Body of Knowledge (SEBoK) version 1.0.1 which was released 30 November 2012 and can be found at: http://www.sebokwiki.org/1.0.1/index.php?title=Main_Page The partners in T-AREA-SoS were contributors to this guide along with 80+ experts in the area. In addition a more complete glossary of terms to which the authors of this report subscribe can be found at: http://www.sebokwiki.org/1.0.1/index.php?title=Glossary_of_Terms Given that a Glossary of Terms is being defined by the SE and SoSE communities, the authors have only highlighted certain key terms for this document. TERM EXPLANATION Complex Adaptive System

System where the individual elements act independently but jointly behave according to common constraints and goals. In the natural world, a flock of geese is a Complex Adaptive System (CAS). Human-intensive systems can also be seen as CASs since each human in the organised system is independent. (Weaver 1948, 536; Jackson, Hitchins, and Eisner 2010, 41; Flood and Carson 1993; Lawson 2010).


http://www.sebokwiki.org/1.0.1/index.php?title=Main_Page

http://www.sebokwiki.org/1.0.1/index.php?title=Glossary_of_Terms

http://www.sebokwiki.org/1.0.1/index.php?title=System_(glossary)

http://www.sebokwiki.org/1.0.1/index.php?title=Constraint_(glossary)

Cyber-Physical Systems (CPS)

CPSs are physical systems that are controlled by embedded software (http://www.sei.cmu.edu/cyber-physical/index.cfm).

Enterprise System A complex, (adaptive) 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. (Giachetti 2010).

Interoperability Degree to which two or more systems, products or components can exchange information and use the information that has been exchanged. (ISO/IEC 2009).

System A combination of interacting system elements organized to achieve one or more stated purposes. (ISO/IEC/IEEE 2008). Elements in this sense may include hardware, software, firmware, people, information, techniques, facilities, services, related natural artifacts and other support elements. This definition should be restricted to engineered systems that are created with a purpose which provides value to one or more beneficiaries.

Systems Engineering

An interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem: (INCOSE 2012).

System of Systems 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). 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 systems in a co-ordinated way for specific goals such as robustness, cost, efficiency, etc.

SoSE The evolving, designed combination of systems to form a system of systems in networks that are safe, secure, efficient and able to respond to changing requirements and operational situations.

Socio-Adaptive Systems

Socio-Adaptive Systems are systems in which human and computational elements interact as peers.

Socio-technical system

An engineered system which includes a combination of technical and human or natural elements (Created for SEBoK).

SoS Architecture The technical framework for the systems comprising the SoS including how the systems will be employed by the users in an operational setting (sometimes called the Concept of Operations or CONOPs), the internal and external relationships and dependencies among the constituent systems and their functions and, finally, the end-to-end functionality and data flow as well as communications among the systems.


http://www.sei.cmu.edu/cyber-physical/index.cfm

http://www.sebokwiki.org/1.0.1/index.php?title=System_Element_(glossary)

http://www.sebokwiki.org/1.0.1/index.php?title=Engineered_System_(glossary)



Ultra-large-scale systems (ULSS)

ULSS are systems of systems of unprecedented scale in some of the following dimensions lines of code, amount of data stored, accessed, manipulated, and refined, number of connections and interdependencies, number of hardware elements, number of computational elements, number of system purposes and user perception of these purposes, number of routine processes, interactions, and emergent behaviors, number of overlapping policy domains and enforceable mechanisms, and number of stakeholders (http://www.sei.cmu.edu/uls/).


http://www.sei.cmu.edu/uls/

2 PROCESS FOR THE GENERATION OF THE SOA REPORT The first version of this report was produced in May 2012 and presented for review in October 2012. At the time of its delivery it was seen as part of a sequence of reports that would culminate in the delivery of a Strategic Research Agenda in SoS and SoSE to the EU Commission due in July 2013. The ‘areas for consideration’ and reporting within the initial SoA report were initially generated from the following sources: • A workshop with participants from the EU and other projects funded in the SoS

area held in April 2012 to support the EC’s information needs in support of the formulation of the Horizon 2020 which highlighted some key areas of concern.

• Literature review and the current research focus and expertise of the authors. • Analysis of issues identified in the recent and current groupings of EU funded

projects working in this area e.g. COMPASS, DANSE, ROAD2SOS etc. • Consultation with the emerging expert community (currently having 80+

members). • Analysis of historical and current case studies gleaned from the literature and

from the expert community and reported in Parts B & C of this report. It was intended that this report would feed into the High Level Requirements Report (D3.2) and the Gap Analysis Report (D3.1) and, after further research, discussion and analysis with EU and US experts would contribute to the creation of the initial Strategic Research Agenda (D5.1) and the final Strategic Research Agenda (D5.2) due to be submitted in July 2013. At the review in October 2012 the reviewers made the following comments:

“Due to that narrow investigation perspective, as well as due to a missing systematic approach for accessing the emerging field of SoS/SoSE, the preparation of an appropriate state of the art report (SoA Report, D2.1) is just partly achieved. The quality of the report is insufficient.”

Below is a summary of the main points made by the reviewers together with an indication in italics of how and where in this revised version these points have been addressed: • The introduction to and characterisation of SoS and SoSE appears diffuse and

incomplete. Fundamental terminology and glossary terms are missing or incompletely captured, especially in defining the relation or differentiation of SoS to the concepts of Ultra-large Scale Systems (ULSS), Cyber-Physical Systems or Complex Systems and its software and systems engineering. Glossary now included as are sections on ULSS, CPS and CS.

• As consequence, the derived problem areas with SoS are incomplete and diffusely described. This now addressed in Part B

• All in all, we miss a systematic approach to investigate and span the emerging field of SoS, SoSE and its related challenges and open issues………… Process of generating SRA and SoA now included and links between


deliverables

• Therefore, major challenges and research questions for SoS and SoSE are missing: e.g. the need for advanced methods/approaches in problem analysis, requirements modelling/engineering; the extended requirements on assuring functional safety or privacy; as well as further major challenges (and opportunities) that come along with the open networked and interactive nature of SoS. Major challenges as described above have evolved as the project progresses and are reported in the SRA deliverables in WP5. Summaries of these are included in this document at section 2. In addition a section on global drivers which set the overall context for SoS and SoSE has been included.

• Especially the consideration of SoS as socio-technical systems with

corresponding societal and end user needs is not addressed anywhere in the report (D2.1). This is found in Chapter 15 in Part 2.

• There are missing, misleading or conflicting concepts, terminology and inadequate approaches summarized. Report proof read and edited.

• References to important standards for software and systems engineering, for assessing and assuring system quality (quality in use, quality of service, internal and external quality) and towards building up important interoperability platforms are missing. An in-depth Appendix 1 on a full range of standards has been created for this report

• The structure of the document lacks clarity. Especially various introductory sections to challenges, concepts or approaches miss a clear structure that makes them readable. Document reorganized.

• Partly, the report contains confused text, unwanted repetitions of paragraphs or paragraphs that just don’t go along with the title. Many figures, tables or shortcuts are insufficiently introduced or described. Document proof read.

This revised version of the report is an attempt to address the comments of the reviewers but also to set the report within the overall context of the project and one of its key outputs i.e. the SRA which is described in the following section. 2.1 Overall Process for the Generation of the Strategic Research

Agenda Figure 1 illustrates the process by which T-AREA-SoS has generated the final common vision and strategic research agenda. As shown, the expert community (established as part of the T-AREA-SoS action) drives the industrial as well as academic requirements through which research initiatives have been generated. A workshop (W1) was held to support the EC’s information needs in support of the Release Date: 15 July 2013 © Loughborough University Page | 14

formulation of the Horizon 2020, and thus was one of the sources of input for the generation of the state of the art (D2.1), which provides an integrated perspective of current SoS capabilities in a range of sectors. The activities that contributed to the state of the art provided a prioritised list of research themes in SoSE, which formed the basis of the gap analysis activity (D3.1). This activity identified innovation gaps in operational or design aspects of SoS. A thesaurus approach (D4.1) has been created for various key identified terms and concepts from the state of the art and the gap analysis activities. Two international expert panel sessions (W2) were held which further refined the innovation gaps identified as part of the gap analysis, and generated additional key terminologies for the SoSE thesaurus consideration. A high-level requirements specification (D3.2) has been produced for developing future European SoSE research and development agenda. These requirements and gaps were initially developed and validated through the first expert exchange workshop held in the US (W3) which formulated SoSE research initiatives as it stands in December 2012, generating the first draft of the common vision and strategic research agenda (D5.1, this report). The research items from this agenda will be an input to the subsequent workshops to be held in Europe (W4 and W5) at which the Strategic Research Agenda will be further developed, and the final common vision and SRA (D5.2) will be produced in April 2013. The final version of this report was presented at the EU presentation workshop (W6) in June 2013. The SoSE thesaurus (W4) is expected to support the analysis of both versions of the SRA report. As can be seen from this explanation areas originally selected for consideration in the SoA report have been reviewed, analysed and edited several times over the duration of the project to the stage where a series of key research themes and individual research elements are emerging. These are summarised briefly below as they stand after the EU workshop (3 of 4) that was held in Brussels in January 2013: • Theoretical Foundations for SoS • Characterisation and Description of SoS • Predicting and Managing Emergence • Measurement and Metrics • Multi-Level Modelling • Evaluation of SoS • Energy Efficient SoS • Trade Off • Prototyping SoS • Definition and Evolution of SoS Architecture • Human and Organisational Aspects • Dependability and Security Within each of the above themes a series of 70+ research elements have also been identified and cross referenced across themes with the aim of prioritising the critical research issues in the final deliverable of the SRA.


Therefore in terms of re-issuing this report the authors have addressed the concerns of the reviewers (e.g. glossary of terms, process adopted, links to ULSS and Cyber-Physical Systems, revised introduction to the report, a section on Global Societal and Economic Drivers for SoS/SoSE research etc). However it is felt that the ‘missing challenges’ have been identified in the work done since the original report was written and these will be encapsulated in the Final Strategic Research Agenda and the Workshop Reports that precede it.


Fig 1: Process of Generating SRA

D5.2 Final Common SoSE and Strategic Research Agenda

W6

D5.1 First Draft Common SoSE Vision and Strategic Research Agenda

W4

W5

Statements of Gaps in Operational / Design Aspects

of SoSE

Input Source W3

Input Source

Innovation Gaps from Prioritised SoSE Themes

Key SoSE Terminologies

Review and Feedback

D3.2 High Level Requirements Specification

D2.1 State of the Art

D3.1 Gap Analysis

D4.1 SoSE Thesaurus

D2.2 Expert Community W1

T-AREA-SoS: SRA Generation Process

Expertise, Knowledge and Advice



Analysis of the SoSE Research Agenda

W2

W1: Additional Workshop for Generation of State of the Art (Brussels, 2012) W2: Panel Sessions at INCOSE (Rome, 2012) and IEEE SoSE (Genoa, 2012) W3: First Expert Community Exchange Workshop (US, 2012) W4: Second Expert Community Exchange Workshop (EU, 2013) W5: Expert Community Validation Workshop (Virtual) (EU, 2013) W6: SRA Presentation Workshop (EU, 2013)


3 INTRODUCTION TO SYSTEM OF SYSTEMS (SOS)

3.1 Definition and Characteristics of SoS System of systems engineering (SoSE) has been 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 a different 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. (Jamshidi, 2009)

The above definition seems to adequately encapsulate the various definitions that have been offered for SoS and will be useful for the remainder of this document. 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. Firesmith (2010) has argued that systems exhibit a set of characteristics that could be measured on a subjective scale such that SoS are those systems that have high scores against the following characteristics: • Complexity, where SoS tend towards ultra-complex • Evolution, where SoS tend towards constantly evolving • Emergence, where SoS tend and single systems may be more or less towards

negative emergence (as compared to positive emergence) • Size, where SoS tend towards ultra-large-scale • Variability, where SoS tend towards ultra-large amounts of variability

He also notes that the component systems (termed by Firesmith, subsystems) have the following characteristics:

• Autonomy, where those of SoS tend towards operationally independent • Governance, where those of SoS tend towards independently governed • Heterogeneity, where those systems of SoS tend towards completely

heterogeneous • Physically distributed, where those of a SoS maybe distributed or not • Reuse, where those of a SoS tend towards 100% reuse

The above characteristics are clearly derived from those of Meyer (1998), but recognise that any particular arrangement may exhibit behaviours that are more or less typical of either a single system or a SoS.

Some examples follow, to indicate the scope of the concepts above, and to highlight some of the interfacing issues that are endemic in SoS. 3.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’. 3.1.2 An Energy Supply SoS For example, consider the provision of electrical energy in some region, such as the north-eastern 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. 3.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, such as the complex nature of the interfaces between systems, the constraints imposed by legacy systems, and the inefficiencies that emerge as the EU27 community evolves (Figure 2 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.”

Fig 2: Representation of an Integrated Transport SoS (based on (TRKC, 2010)) to illustrate the wide-ranging nature of SoS, its information needs and the timeliness of these, and the co-ordination issues

involved

3.1.4 A Service and People-Oriented SoS For example, consider a hospital, funded by a 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 and between the systems. 3.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 systems. 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)). 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: see Figure 3.


Fig 3: View of Interdependence both within and between domains in Societal SoS, and illustrating some

of the difficulties of establishing the boundary of a SoS

3.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 other1, 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. 3.4 SoS Application Domains Application of SoS (as defined in the section 3.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 that 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.

1 Note that some practitioners have indicated difficulties in distinguishing between acknowledged and collaborative Release Date: 15 July 2013 © Loughborough University Page | 24

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

3.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.

Systems Engineering

Systems of Systems Engineering

Management and Oversight System Physical

engineering Socio-technical management and engineering

Stakeholder Involvement Clear set of stakeholders

Multiple levels of stakeholders with mixed and possibly competing interests

Governance Aligned management and funding

Added levels of complexity due to management and funding for both SoS and systems; SoS does not have control over all constituent systems

Operational Environment Operational focus (goals) Designed and

developed to meet common objectives

Called upon to meet new SoS objectives using systems whose objectives may or may not align with the SoS objectives

Implementation Acquisition/Development Aligned to

established acquisition and development processes

Cross multiple system lifecycles across asynchronous acquisition and development efforts, involving legacy systems, developmental systems, and technology insertion

Process Well established Learning and adaptation Test and evaluation Test and

evaluation of the system is possible

Testing is more challenging due to systems' asynchronous life cycles and given the complexity of all the parts

Engineering and design considerations


Systems Engineering

Systems of Systems Engineering

Boundaries and interfaces

Focuses on boundaries and interfaces

Focus on identifying systems contributing to SoS objectives and enabling flow of data, control and functionality across the SoS while balancing needs of the systems. OR Focus on interactions between systems Difficult to define system of interest

Performance and Behaviour

Performance of the system to meet performance objectives

Performance across the SoS that satisfies SoS use capability needs while balancing needs of the systems

Metrics Well defined (e.g. INCOSE handbook)

Difficult to define, agree, and quantify

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 (Souza-Poza, et. al., 2008) that is being tackled through funded research activity in the US and, more recently, in Europe. 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; for example the NSF Program Directors in the area of cyber-physical systems have expressed a strong desire to identify how system of systems relates to, complements, and enables advances in a 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 borrows 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 Part B of this report. The following two sections of the report consider the relationship between SoS/SoSE and two other major classes of systems: Ultra-large Scale Systems (ULSS) and Cyber-Physical Systems. 3.6 Ultra-large Scale Systems (ULSS) Ultra-large-scale systems (ULSS) are defined by CMU as (CMU SEI, 2006) systems of systems of unprecedented scale in some of the following dimensions:

• lines of code • amount of data stored, accessed, manipulated, and refined • number of connections and interdependencies • number of hardware elements


• number of computational elements • number of system purposes and user perception of these purposes • number of routine processes, interactions, and “emergent behaviors” • number of (overlapping) policy domains and enforceable mechanisms • number of people involved in some way

Based on this definition, all systems of systems are ultra-large-scale systems, and many ULSS are SoS. An example of a ULSS that is not a SoS is a massive standalone system that has an unprecedented amount of code. However, Firesmith (2010) has noted that the cost of ULSS mean that, in practice, they must be constructed from pre-existing, independently governed systems, thus exhibiting SoS characteristics. It is important to note that ULSS is specific to the software domain and does not include physical systems as component systems. Many ULSS hold the characteristics of systems of systems, such as operationally independent sub-systems; managerially independent components and sub-systems; evolutionary development; emergent behavior; and geographic distribution (Northrop 2006). The scale of ULSS gives rise to many problems that are common to SoS. For example, similar to SoS, some ULSS may be developed and used by many stakeholders across multiple organizations, often with conflicting purposes and needs. Some ULSS they may be constructed from heterogeneous parts with complex dependencies and emergent properties. Many ULSS will be continuously evolving, and the verification and validation of such systems are challenging. Similar to SoS, traditional approaches to engineering and management are inadequate to handle the complexity of a ULSS (Northrop 2006), i.e., ULSS are too large for current design, development, management, and interaction practices. Security, trust, and resiliency of such systems are also difficult to guarantee. The premise underlying research in ULSS is that beyond certain complexity thresholds, a traditional centralized engineering perspective is no longer adequate nor can it be the primary means by which ultra-complex systems are developed. This shifts the traditional systems perspective into that of a social-technical ecosystem. Like a biological ecosystem, a ULSS comprises a dynamic community of interdependent and competing organisms (in the case of a ULSS, people, computing devices, and organisations) in a complex and changing environment. The concept of an ecosystem connotes complexity, decentralized control, hard-to-predict effects of certain kinds of disruptions, difficulty of monitoring and assessment, and the risks in monocultures, as well as competition with niches, robustness, survivability, adaptability, stability, and health. Many existing literature (e.g., Sullivan 2010, Northrop 2006) do not provide clear distinction between SoS, ULSS, and complex IT systems and use those terms interchangeably. These challenges have prompted researchers and practitioners in ULSS to ask similar questions to the ones frequently asked in the SoS community, such as:


• What new quality attributes arise due to scale? • What types of analyses are required to understand and design (at all levels)

systems at scale? • Are new architecture design principles needed? • What new strategies are needed to control, predict, and bound the behavior

of systems at scale? To address some of these questions, researchers in ULSS have worked on Socio-Adaptive Systems, which are systems in which human and computational elements interact as peers2. The behavior of the system arises from the properties of both types of elements and the nature of how they collectively react to changes in their environment including mission, and the availability of the resources they use. The elements of human factors and emergent system behaviours from human and system interaction are also a major concern to the SoS community2. These properties and interactions give rise to new quality attributes that will influence the structure of ULSS systems. Socio-Adaptive Systems Project is thus created in SEI in order to help enable effective, adaptive, mission-aware use of resources2. The goal is to automatically, continuously, and effectively allocate scarce network capacity to users based on their own accurately reported needs. The ULSS community aims to establish a new approach for designing adaptive socio-technical systems in which people, networks, and computer applications can determine locally how to respond when the demand for resources outstrips supply, while guaranteeing the best use of available capacity2. Salient contributions in this area include the use of computational mechanism design (CMD) to elicit changing mission needs and compute an optimal allocation of resources, and the use of decentralized quality-of-service (QoS) optimization to optimally respond to changes in emergency resource capacity2. The researchers at SEI are developing a distributed version of the QoS resource allocation model (Q-RAM) (Lee et al 1999) to allocate emergency resources to applications requiring them. Distributed Q-RAM (D-Q-RAM) is novel in that it does not require a centralized aggregator of application QoS information, nor does it require explicit knowledge of the capacity of emergency resources. D-Q-RAM provides a vehicle for expressing mission needs incrementally: different levels of QoS are associated with expressions of mission utility or value. CMD will rely on D-Q-RAM to compute an optimal lower level allocation based on responder input2 (Northrop 2006). 3.7 Cyber-Physical Systems Cyber-Physical Systems (CPS) are physical systems that are controlled by embedded software (http://www.sei.cmu.edu/cyber-physical/index.cfm). CPSs require software to control many individual systems as well as to control the complex coordination of those systems. Examples of CPS include integrated avionics systems, interacting medical devices, and distributed power systems in the Smart

2 http://www.sei.cmu.edu/uls/research/socio-adaptive/index.cfm Release Date: 15 July 2013 © Loughborough University Page | 29

Grid. All CPSs are control systems3, however, many SoS are more than just control systems. Cyber-physical systems (CPSs) are a natural consequence of the increased connectedness and autonomy of real-time embedded systems. Like real-time embedded systems, CPSs are characterized by a high degree of coupling between computations and physical processes. Because of this coupling, safety and timeliness properties, among others, are critical. CPSs also generally allow physically separated devices and vehicles to coordinate in ways not previously possible. However, increased distribution and scale make it much harder to guarantee such properties. CPSs aim to dramatically increase the autonomous capabilities of a collection of systems. When each of the system in the collection becomes entirely independent, the CPS is also an SoS. Traditional tools and techniques that have been used to qualify systems for use by ensuring the timeliness and correctness of software are costly and ineffective when applied to CPSs4 (Sha et al. 2009). CPSs share similar challenges with SoS and ULSS. For example, uncertainty in the environment, security attacks, and errors in physical devices and in wireless communication pose a critical challenge to ensure overall system robustness, security, and safety (Sha et al. 2009). In addition, two cyber-physical systems may never interact directly but may be coupled by human behaviour, and as such, there is the need to understand the nature of such interactions and reason about safety as a global, not local, property (Sha et al. 2009). CPS systems are distributed and hybrid real-time dynamic systems, with many loops of different degree of application criticality operating at different time and space scales. As such, techniques for compositional system modelling, analysis, synthesis and integration for such systems are much needed for the successful development of CPSs (Sha et al. 2009). There is a high possibility that techniques developed for CPSs could be adopted for use in certain SoS. However, some methods may be CPS specific, such as, formal verification techniques and tools to assure critical system properties for CPSs, real-time analysis techniques to determine if critical system timing properties will be satisfied, and design and implementation guidance for real-time CPSs. Researchers in the area of CPS propose that incremental improvements to traditional systems engineering such as formal verification, emulation and simulation techniques, certification methods, software engineering processes, design patterns, and software component technologies will help in the development of CPSs (Lee 2008). However, to fully realise the potential of a CPS, new technologies will need to be developed and more importantly, the core abstractions of computing will need to be reconsidered. This is because effective orchestration of software and physical processes requires semantic models that reflect properties of interest in both (Lee 2008).

3 http://cyberphysicalsystems.org/ 4 http://www.sei.cmu.edu/cyber-physical/index.cfm Release Date: 15 July 2013 © Loughborough University Page | 30

CPSs are characterized by a high degree of coupling between computations and physical processes, which means that safety and timeliness properties are critical. However, increased distribution and scale make it much harder to guarantee such properties. Thus CPSs suffer from similar problems of measurement and metrics and evaluation as faced by SoS. Contributions to the field of CPS that is relevant to the SoS community include the use of formal verification techniques and tools to assure critical system properties for CPS, the application of real-time analysis techniques to determine if critical system timing properties will be satisfied, and the provision of design and implementation guidance for real-time, cyber-physical systems. Many research areas in CPS coincide with those studied in SoS5. For example, in specification, modelling (Derler et al. 2012), and analysis, hybrid and heterogeneous models (Lee et al. 2010, Goderis et al. 2009), interoperability and time synchronization are critical research areas in CPS. Another similarity between CPS and SoS is in the study of methods to interface with legacy systems. In validation and verification, simulation, certification, safety assurance and stochastic models are important elements for CPS. The term SMART (as in SMART Grid, SMART City, etc.) is becoming associated with CPS and generally implies an environment in which physical infrastructure must be accompanied by sophisticated social and communication infrastructure. Much of the research in CPS is intended to enable more efficient environments through the inclusion of increasingly autonomous embedded systems within the infrastructure.

5 http://cyberphysicalsystems.org/ Release Date: 15 July 2013 © Loughborough University Page | 31

4 GLOBAL DRIVERS FOR SOS/SOSE In this section we discuss some global drivers of change to society that lead eventually to the need and content of the Strategic Research Agenda (SRA). These drivers are currently active; they are interconnected, and operating in parallel. Consequently, it would not be sensible to address these individually, since they form a complex set. SoSE may provide the best paradigm to address this set, but our current state of knowledge about this technology and its techniques is insufficient, hence the need for the SRA for SoS/SoSE. The section commences by describing a ‘doom and gloom’ scenario based on the set of environmental drivers; this is followed by an outline of how SoSE could be the best way to avert this scenario. The sections after this describe in more detail each of the eight global drivers identified below. 4.1 A ‘doom and gloom’ Scenario In a slim volume, ‘The collapse of complex societies’ (Tainter 1988) it is argued that social complexity, when faced with widespread change in economic and/or environmental conditions, causes that society to collapse. Tainter took an historical/anthropological stance, and looked at several significant civilisations of the past; the Romans, the Maya, the inhabitants of Chaco Canyon and others. Each had a strong culture and a complex society, advanced technology for their times, and yet, fairly quickly, after centuries of existence they collapsed, scattering their citizens. He concluded that they collapsed because of their societal sophistication; when stress comes, such societies have become too inflexible, too brittle, to respond. In effect, they become a huge, interlocking, dependent network of roles, responsibilities and functions, not readily amenable to change (Bianconi & Barabasi 2001; Barabasi 2002). Furthermore, even when moderate adjustments could be made, they tended to be resisted, because any rearrangement discomfits elites and other significant constituencies in those societies (e.g. Oreskes &Conway, 2010). . This ‘collapse’ perspective has support from other authors writing from different perspectives for example (Diamond 2011, Sachs 2011), whose writings have a latter-day resonance with our current global situation; our societies are certainly very complex and layered; we rely heavily on the environment about us for sustenance and sustainment; we are faced with global challenges as outlined in the sections below; and as our newspapers attest, there has been strong resistance to change from some of our elites, particularly in the energy and financial sectors. It does not follow that we are therefore in danger of inevitable societal collapse, but it does indicate a plausible risk that needs to be addressed. 4.2 Avoiding the doom and gloom’ Scenario Fortunately, we have two resources not available to previous civilisations; firstly, Information Technology, and secondly much better knowledge about the world, Release Date: 15 July 2013 © Loughborough University Page | 32

especially in science and engineering that is more widely distributed. These twin resources enable us to educate our populations about the future and the changes it will bring, and then hopefully implement the necessary changes with the least pain and least cost, so that we may achieve a sustainable world. Given these twin resources, they must be utilised effectively. It is here where a sound understanding of SoS technology and methods (which we have not yet acquired) will be necessary. All of the drivers discussed in the sections below are affecting us all concurrently, and they all overlap with each other forming what might be termed a ‘perfect storm’; in less emotive and more technical language, a ‘wicked problem’, best addressed by systems of systems thinking (Rittel and Webber 1973; Daw 2007; Sousa-Poza, Kovacic et al. 2008; Ring and Tenorio 2012). More accurately, it would be best addressed had we a better understanding of this technology. For this reason, a Strategic Research Agenda is proposed to develop both the System of Systems technology, and its distributed understanding. But to provide some background for the SRA, the global drivers are described briefly below. 4.3 Key Global Drivers for Research into SoS/SoSE In considering global drivers for a Strategic Research Agenda (SRA) in Systems of Systems (SoS) and Systems of Systems Engineering (SoSE) it is worth taking a near- 50-year perspective (i.e. until 2060). The rationale for this is that this timescale includes our grandchildren, it covers the period within which some control over the global drivers must be established if we are to sustain a properly habitable world, and it embraces the viewpoint of the European Commission as expressed by its current leader: “It is less expensive to protect the planet now than to repair it later” (J.M. Barroso, President, European Commission, quoted in EU Focus, March 2010) Based on this perspective, and focussing on the EU, the following key global drivers for the SRA can be identified: • Population demographics, especially growth and aging • Food security • Energy security • Resource utilisation and re-utilisation • Emissions and global climate • Community security and safety • Transportation • Globalisation of economic and social activity Taken together, these drivers imply a ‘perfect storm’ of change for the EU over the 50-year period above and it is the contention of the authors of this report that implementation of SoS thinking and SoSE methods and approaches may be a) the most efficient, cost-effective, and expeditious means of managing this inevitable change, and b) may be the least likely to encounter resistance from those most closely affected by the change. Release Date: 15 July 2013 © Loughborough University Page | 33

We discuss the characteristics of these drivers below, acknowledging, as do the experts, that drawing firm conclusions from incomplete measures and perspectives of extremely complex systems is a dubious exercise, as is evident from the differences in interpretations of these experts. 4.3.1 Population Demographics Projections of global populations give a point estimate of 9 billion people and a concomitant range of 8-11 billion in 2050, compared to about 7 billion in 2012 (Wilbanks, Lankao et al. 2007; Sulston 2012; World-Bank 2012), with each extra person requiring the same access to resources, education, energy, health, home life etc. as the others in the region. However, this population growth will be unevenly distributed; for the European Union (EU27) as a developed region, the estimate is that the current population of around 500 million will rise to a peak of 526 million in 2040, and then decrease to 517 in 2060 (Eurostat 2011), due to deaths exceeding births by 2030. However, the implied aging demographics allied to internal migration among the states of the EU27 will require large adjustments in societal resources; for example, Poland is expected to show a decline in population of about 15% from 38 million to 32 million by 2050, whereas the UK may become the most populous country in the EU27 at 79 million, compared to 62 million currently; a 27% increase (Eurostat tps00002). Exacerbating this is the aging effect; compared to the working population (aged 15-64), the aged (65+) population across the EU27 is estimated to rise from 25% to 52% in 2050, with Romania and Poland at 65% and Ireland and Iceland at about 33% in 2050. It is difficult to escape the conclusion that both national governments and the EU Commission face a period of intense demand for concerted action to address the inevitable societal imbalances that may be foreseen in these numbers. But it will not be governments alone that will need to be involved; private organisations will be the agents of delivered continuous change, likely in SoS configurations. 4.3.2 Food Security Self-evidently, if the global population is going to increase by about 30% by 2050, there will be a concomitant demand for foodstuffs. This will be met in three ways. Two of these are inputs: increases in cropland (including aquaculture), and improvements in sustainable yield from that cropland (e.g. better husbandry; better genomes). The third comes from elimination of needless losses (e.g. rats, mice, locusts in developing countries) and waste (e.g. “Rich countries waste about the same amount of food as poor ones, up to half of what is produced, but in quite different ways … very roughly, 100kg per person per year … a result of personal habit and law” – The Economist, 24/02/2011). Cropland increases are possible in several parts of the world, but this is minimal in the EU. Instead, the increases must come from improvements in crops and techniques, and from assurance of food from the rest of the world. For the EU, the rate of improvement is about sufficient to maintain current levels of internal food Release Date: 15 July 2013 © Loughborough University Page | 34

http://epp.eurostat.ec.europa.eu/portal/page/portal/

security; however, given population growth elsewhere, the current rate globally appears insufficient, and either or both of increases in cropland and reductions in waste will be necessary to maintain food sufficiency. For the EU27, food security is a matter of trade; overall imports and exports are roughly in balance but not in commodities; the EU imports more raw materials, and exports more finished products. This situation is unlikely to change, and the EU is dependent on the global situation. Fortunately, the UN Food and Agriculture Organisation (UN-FAO 2009) and the Sulston report (Sulston 2012) have both pointed out that food security for the next 50 years is achievable, as long as global population growth is contained, climate change is addressed, and the problems of food provision, distribution, utilization and consumers’ dietary perceptions are addressed. However, there are obvious resource allocation issues with forestry as a source of sustainable materials, cropland as a source of biofuels, and ecological reserves to preserve species diversity. This is self evidently a SoS problem that will require new SoSE approaches, techniques, tools and thinking. 4.3.3 Energy Security The dependence of the EU27 on energy supplies from elsewhere, coupled with the drive by all countries to a state of low-carbon energy supply mean that the EU27 must contemplate a big shift away from the traditional procurement and distribution of energy within the Community. As the EU’s energy policy (SEC(2011)1022 Final) outlines succinctly, in the fossil fuel domain, the EU imports over 60% of its gas and over 80% of its oil, but it has strengths in renewable energy supply (wind, water, tidal, geothermal, solar, etc.). Complementing this, the “Energy Roadmap 2050” (COM(2011) 885 final) indicates how the EU27 could reach the target of the European Council (2009) to reduce greenhouse gas emissions to 80-95% below 1990 levels by 2050, assisted by other efforts in resource re-utilisation and in more efficient industrial processes, as discussed briefly below. The achievement of this target has many uncertainties; intergovernmental politics, the creation of appropriate market conditions and business models to encourage the creation and uptake of low-carbon technologies, and not least the engagement of the public to achieve popular acceptance for the costs and degrees of change that are required in society. These changes are likely to be far-reaching; investments in renewable sources of electrical energy and a smart supply grid are likely to increase cost from about 10% of GDP in 2005 to about 15% in 2050 – a 50% increase, which will be noticed by all consumers. Furthermore, the target will require a major shift (with associated investment) to low-carbon vehicles, durable energy-consuming goods, energy-efficient manufacturing methods (Allwood, Ashby et al. 2011) and processes, etc. There will be a consequential shift in jobs within manufacturing, services, construction transport and agricultural sectors of the economy. Much of this will represent drivers for research and development and will provide opportunities for EU industry and service providers to satisfy this change in demand, but there are also possibilities for dislocations in the paths to a low-carbon future, particularly since all this transformation must happen in parallel, and in a relatively short window of time. This points to a need for resilience and agility in the realisation of this degree of Release Date: 15 July 2013 © Loughborough University Page | 35

change, which is likely to be best delivered in the context of appropriately-designed SoS, rather than being left to the Unseen Hand of the Marketplace. There is a second reason for making such changes. At present, about 50% of the world’s population relies on coal or biomass for domestic energy, and about 20% have no access to electricity; this includes nearly all of the world’s poor (WETO-H2 2006). A goal of the UN Conference on Sustainable Energy for All (2012) is to move as far as possible to electrical energy by 2030 in order to enable the world’s poor to escape poverty; given that the technology to do this necessarily will be developed within the EU in order to meet its own targets, a significant export opportunity seems likely. However, since the recipients of this new energy supply are not likely to be able to afford this change, there is scope for a series of government-industry initiatives to deliver this. Again, there is a role for SoS and SoSE in developing this global market. 4.3.4 Resource Utilisation and Re-utilisation We refer to global mineral resources and carbon-based fuels (rather than renewable resources such as forestry and other biomass which are discussed briefly elsewhere). For most minerals, a well-established view is that the world’s lithographic resources (such as iron, titanium, uranium, etc) are limited, and that inevitably these will run out; there will be a period of ‘Peak-X’, thereafter there will be a steady reduction in provision of these resources and an accompanying rise in prices. However, a more recent, extended perspective has largely replaced this older view; it includes notions of recycling and re-use, as well as the growth of technology permitting miniaturisation, dematerialisation and substitution of diminishing resources. At the beginning of the resource utilisation process, the new viewpoint includes the side-effects of accessing diminishing resources; the disposal of associated minerals such as arsenic, thorium, and other noxious elements in the lower-grade ores, and the associated extra costs of accessing more hidden or remote ores (particularly where land-use conflicts and community factors are involved); all precluding their full exploitation and limiting what can be retrieved (e.g. (Prior, Giurco et al. 2011). Further into this utilisation process, the developments in technology around the world will ensure a diminishing use of resources per item, but the total demand may grow because of increased populations and increased expectations per person. This could be addressed by improved re-use of products and by recycling. Much of this re-use may occur by transferring goods in the developed world to the less developed world, where they will still be useful after they have been discarded or replaced in the developed world. Recycling, a much more complex process, holds several benefits, among which are reductions in costs, in emissions, in landfill, and in toxic side- effects. Figure 4 shows a generic process for this.


Fig. 4: A generic process for recycling and reuse. The goal is to make the acquisition of resources and

the use of landfill as close to zero as possible, while ensuring process safety, security, efficiency, etc.

However, while it is evident that re-use, recycling and reductions in landfill are eminently desirable outcomes, they do demand an economic landscape in which business models can be created that will induce appropriate investment and entrepreneurship to create the necessary processes for this recycling SoS to be successful and profitable. The EU27 have made considerable strides towards this; for example, there is the Waste Framework Directive (Directive 2008/98/EC), and further mandated requirements for particular sectors. However, there is still a need for further action at both EU levels and internationally to create a more incentivised environment for business partnerships and processes to flourish, and to ensure that current legislation, regulation and approaches to design, manufacture and disposal include the consideration of reuse and recycling. There is a long way to go in the provision of an infrastructure and processes for the comprehensive conservation of resources through recycling and reuse, and it is likely that these will be brought into existence faster and more economically through the involvement of SoSE. 4.3.5 Emissions and Global Climate As the sequence of reports from the Intergovernmental Panel on Climate Change (IPCC) emphasise, anthropogenic effects on the natural environment and on global climate are significant, and the prognosis is catastrophic unless remedial action takes place (Wilbanks, Lankao et al. 2007). This message is reinforced by the recent reports on ‘People and the planet’ (Sulston 2012) and ‘Turn down the heat’ (World-


Bank 2012). For some nations, the effects are likely to be terminal (e.g. Tuvalu, Kiribati), but all nations will have consequences affecting agriculture, industry, economic performance (especially for coastal cities), health and social security as well as the ecological effects on natural habitats, food chains and ultimately biodiversity (Hsiang 2010; Zivin and Niedell 2010; Harvey 2012). The rise in average temperature alone will eventually have severe consequences (Meadows, Meadows et al. 1972; McMichael and Dear 2010; Sherwood and Huber 2010); more immediate effects, arguably established statistically by national meteorological agencies, may arise from the greater variation in severe climatic events (Hansen 2012; Hansen, Sato et al. 2012). Within the EU27, considerable effort is being spent on climate change initiatives, such as the Climate Change Programme (ECCP), the Emissions Trading scheme (ETS), legislation regarding the minimum renewables content in energy supplies, the promulgation of insulation and energy-efficiency targets and support for the development of carbon capture and storage (CCS). The result is that most of the easy, direct methods for reducing emissions have been taken, and are yielding good results. But in the timeframe of this section, until 2060, it is now necessary to move to the more extensive, interconnected approaches to get closer to the targets set for the EU27. As an example, the recycling and re-use of most of the purchases that consumers and organisations make in the EU27 would help greatly in reaching the targets set at the Lisbon Council, but there are many obstacles of many types to be removed (from politics to investment to regulatory regimes to public acceptance of new ways of thinking) before the full benefits will accrue (Allwood, Ashby et al. 2011, Lee, Preston et al. 2012). One could foresee that interconnected SoS would be needed to produce a solution more quickly over time, since these could provide pervasive channels in parallel for the communication and instantiation of the necessary changes in the conduct of the affairs of the EU27. Moreover, through the medium of trade, and the entrainment of knowledge and technology transfer that this would enable, the EU27 could influence greatly the move towards a world of reduced harmful emissions. 4.3.6 Community Security and Safety The drivers discussed above, even if they are addressed effectively, are still likely to exacerbate tensions and disruptions within communities at both intrastate and interstate levels. These tensions and disruptions may be under the categories of terrorism, social identity, organised crime (cyber-crime and trafficking included), public health crises, loss of established rights and customs (including water rights), and large-scale environmental crises, among others. All regions of the world, including the EU27, face these crises, and they may come in combination, rather than singly. As was mentioned earlier, the concomitant brittleness that is associated with an increasingly interlocked and interdependent society means that these issues take on an added level of importance. While the EU27 as a whole has an enviable record for security and safety of its citizens and institutions, it is also evident that the nature of the threats faced are Release Date: 15 July 2013 © Loughborough University Page | 38

much more likely to be mitigated by a EU27-wide co-ordinated, higher standard of security, involving national states, cities, and organisations. That so much of the critical infrastructure for the lifestyle, health, transport, feeding and security of the citizenry of Europe is dependent on information technology that can be attacked from anywhere in the world is a pointer to the need for co-ordinated action. If one adds in the effects of extreme weather (which recognises no borders), it is clear that pan-EU27 safety and security systems are essential. Given their necessarily distributed yet connected and integrated nature, SoS technology will evidently be important. The discussion above is at national and supra-national level; it is also necessary to consider some of the issues at an individual level, too. An obvious concern is individual privacy and security of data, but there are other concerns as well; as more and more information disappears into the cloud and into organizational databases, issues of access to this by legitimate individuals becomes more regimented and confusing by the design and implementation of IT applications and security barriers. Furthermore, the loss of support for older media and applications after a short period of time means that data may well become inaccessible, and the legions of staff in support centres around the world may not be able to do anything about this (Boehm 1988, Charette 2005, Charette 2012). 4.3.7 Transportation It is a given that transportation is fundamental to the global economy and to society as a whole, and it is also a fact that transportation contributes significantly to emissions. Therefore there is a requirement for all regions to attend to the twin problems of both improving and integrating their transportation capabilities and their utilisation, and to reducing their emissions in so doing. This amounts to the following needs: • Improving the transportation networks in all domains (air, land, sea) and

increasing the level of intelligence within them • Improving the integration of these networks, and smoothing the usage of them

mainly by better implementation of IT resources • Moving to non-carbon energy sources to power transport • Shrinkage, minimisation, miniaturisation and dematerialisation of goods (as far as

possible) • Through other policies, and using the resources of IT, bringing transportation

sources and sinks into closer geographical proximity. • Insofar as it is practical, ‘take the work to the workers, instead of the workers to

the work’. This is a complex set of needs. Fortunately, the European Commission has adopted a comprehensive Roadmap for Transport (EC2011 2011), whose goals can be described appropriately as ‘stretch targets’, which will address most of the needs above. If the nation states of the EU27 can act in co-ordination to create the economic environment for businesses to come together to achieve these targets, a very significant step to preservation of the planet will be achieved. But, among the


many steps required, it is evident that SoS technology will be a fundamental component; a piecemeal approach is unlikely to deliver much benefit. 4.3.8 Globalisation of Economic and Social Activity The term’ ‘globalisation’ has many different meanings to many different people. For economists, industrialists and service providers it refers to world trade in goods and services; for most people it refers to the availability of these, and to others it includes aspects such as climate change, people migration, job security and job loss, energy security, world poverty, and potential clashes in cultural values. Nevertheless, on balance globalisation has brought benefits, though there have been losses as well. For example, the Multifibre Agreement of 1974 has arguably resulted in a gradual spread of manufacturing and business links to less-developed parts of the world, encouraging many of those regions to move away from a mono-culture economy, while preventing a rush to least-cost locations. This has resulted in reduced prices for clothing around the world, but has also led to the negative effect of severe job losses in localised areas in some EU27 countries with consequent economic issues for governments to address. The latter points to the need for globalisation agreements to incorporate essential labour standards for health and safety, and for actions to ease the difficulties created by industrial relocation, including measures to mitigate the use of child labour. It is to the credit of the EU27 that is has taken a leading role both in creating the benefits of globalisation (for example in the Kyoto and Doha agreements) and in mitigation of its potential local negative effects (for example in the European Structural Fund and the European Globalisation Fund). Nevertheless, these globalisation changes will continue, and may be more pervasive than in the example above, so there will still be a strong need for a smooth approach to change; created by government economic, regulatory and Incentivisation actions to create ‘level playing fields, and business to exploit the opportunities so created. Both of these activities will be assisted greatly by SoS technology, again because of the need to take a comprehensive approach rather than an issue-by-issue one. 4.4 Summarising the Global Drivers As said earlier, in concert, they may create a ‘perfect storm’ of change for society, with likely resistance and possible dissent on the part of the citizenry of the EU27, unless the changes are introduced with care and co-ordination. The likely migration patterns within the EU27 have strong implications for individual states; those that will grow will have all the issues associated with immigrants; extra housing, energy, education, health and welfare, jobs, etc. with implications for urban planning and renewal, transportation, energy and so on. On the other hand those states likely to lose significant numbers of their population will lose them mainly in the working-age bracket, exacerbating the problems of care for their aged populations, allied to potentially severe economic and fiscal disruptions. In both cases, early countervailing action by the EU27 to attenuate the effects of transfer of people will be required. Because of the concentration required among the different strands of this


action (jobs, urbanization, transport, etc.), it is likely that SoS engineering will be at a premium in order to deliver the necessary co-ordinated changes to the infrastructures and ways of working to sustain a developed, civilized society within a fairly short timeframe. Furthermore, the necessary, concomitant changes to energy consumption, work processes and the nature of jobs driven by the needs of energy conservation and sustainability, emissions control, recycling/reuse and transportation drivers will likely reduce feelings of income security and social cohesion, and perhaps trust in government, especially as prices inevitably rise. Since the drivers of resource depletion, environmental protection and emissions control are likely to make recycling and reuse of prime societal importance, the need to change general perceptions about recycling and consumerism will become paramount. But this change must be in parallel with investment in recycling technology and processes, changes in design and manufacturing processes in general, and the creation by governments of appropriate investment and regulation regimes to enable and encourage this major change in social behavior. While these changes imply considerable opportunities for investment and for job creation, they also imply considerable job losses and disinvestments, with both regional and urban implications. These simultaneous changes have great potential for social upheaval, and unquestionably, a co-ordinated approach will serve the EU27 better than a nation-based, potentially conflicting set of initiatives, and the co-ordinated approach will undoubted be assisted by systems of systems thinking. In short, paraphrasing Heracleitus, as far as the citizenry and business are concerned ‘nothing stays the same’, and because of the role of government in ensuring the inevitable, fairly radical, changes both occur and succeed, our rulers should act to justify the comment by Oliver Wendell Holmes, Jr: “I don’t mind paying taxes; it is how I buy civilization’. Such an outcome would be better than any alternative.


PART B: AREAS FOR REVIEW The review in Part B is split into two main sections. Section 5 considers those areas which might be described as critical attributes or properties of SoS: • Safety, Security and Integrity • Emergence • Interoperability • Agility • Reconfigurability • Reuse Sections 6- 19 considers a particular selection of other SoS/SoSE areas which were derived from discussions with expert community, the case studies reported in Part C and the literature review. Figure 5 shows an overview of those areas selected for the SoA review in the first version of the SoA report.

Fig 5: Selected SoS Areas reviewed in the original State-of-the-Art Report

Table 2 (reprinted from the Common Vision and Strategic Research Agenda, Work Package 5, Deliverable D5.1, April 2013) shows those areas currently indicated by the expert community as being of particular interest for further research. Note that these areas are currently undergoing prioritisation. Therefore it can be seen that on-going work since the original SoA did not, interestingly highlight many other new areas for consideration, although a key theme missing from the original review is that of Trade Off which is discussed further below in Section 6. Network Enablement, Qualification and Assurance, Risk Mitigation, Open Approach to Engineering have not emerged as key SoS themes in their own right but appear either as individual SoS research elements under one or more themes or as area to which SoS research in other key themes/elements will contribute.

System Design

Architectures Open Approach to Engineering

Modelling and Simulation

Network Enablement

Validation and Verification

Qualification and Assurance

Management, Control and Operation Socio Technical Issues

Performance Measurement

Technical and Engineering

Risk Mitigation

Training

Selected Critical Areas for SoS Review


Research Theme

Research Element

Theoretical Foundations The basis for analyzing and understanding SoS and for predicting their operational behaviour

The generation of a generally agreed framework for SoS theories

Identification of fundamental principles for SoS

Establish the paradigm (conceptualisation) for SoS and hence SoSE

Construction of models to aid the development of the theories

Validation of the theories against practical applications.

Identification of fundamental principles for SoS

Characterisation & Description of SoS Finding a way for all disciplines to describe the structure of a SoS and its operational behaviour, both for intended and emergent cases

Elucidate a coherent characterisation of SoS, boundary of SoS, goal of SoS, etc

Understanding the consequences of interactions in the network of contracts between the component systems of a SoS (e.g. service level agreements, their interactions and the consequences of these)

Characterising the evolutionary aspects of SoS and its environment (including 'immortal' systems such as energy and healthcare)

Establishing common terms and definitions for characterising SoS and SoSE

Characterising Governance structures and processes for different types of SoS

Multi-level Modelling Creating and joining stand-alone models together, both vertically across levels, and horizontally along a level, to obtain a better understanding of the characteristics of a SoS

Specifying interfaces between models in sematic and temporal terms - vertical and horizontal integration (issues of heterogeneity)

How to build a single set of compatible models for a given purpose (including the integration of models of black boxes)

Development of methodologies for the model-based SoS approach and the development of skills for architecting and for interpreting of architectures

The development of processes for model building and evolution from purpose through conceptualisation to the final detailed model which is applied

Elaboration of tools and methods for the visualisation of 'big data'


Emergence Identifying, analysing and understanding SoS behaviour that is not expected, then exploiting ‘good’ behaviour and reducing ‘bad’ behaviour

Development of a scientific understanding of how and why emergence occurs (causes of emergence)

Development & compilation of a toolkit and strategies to deal with positive and negative emergent behaviour (e.g. prediction of emergence, prevention through design and operation, amelioration of negative emergent behaviour, and exploitation of desirable emergent behaviour)

Enhancement of modelling and visualisation methodologies and techniques for emergence prediction and assessment of consequences

Compilation of a catalogue of real-life cases providing examples of emergence

Identification of competences required to deal with emergence and the encapsulation of these in training and educational programmes

Measurement & Metrics Developing appropriate metrics and associated methods to measure SoS

Accumulation and development of metrics and associated methods to enable the coherent characterisation of SoS, boundary of SoS, goal(s) of SoS, other important attributes of SoS

Which of the characteristics can be measured and how, and when, and how often?

Development of techniques for matching the metrics required with key decision points in the design and operation of an SoS

Implications of context dependency on metrics (e.g. when should a given metric not be used?)

Understanding the impact of different stakeholder perceptions of value on the operation of the SoS and hence which metrics should be used and when?

Development of decision support systems that incorporate the output of the range of metrics and measurements used to create more useful indicators (derived measures)

How to measure the rate of change of the SoS environment and its impact on the operation of the SoS

Auditability of, traceability of, and confidence in metric construction and application

How do you measure interoperability?

Evaluation of SoS Finding ways to combine metrics to assess the performance of a

Development of formal definitions for the scope and purpose of SoS evaluations and the boundary between these and measurement


SoS

What are the different classes/combinations of evaluation models for different types of SoS and their different purposes

How do you evaluate SoS in relation to a range of global drivers (e.g. food security, emissions, population change.) and in different domains

Development of methods for SoS evaluation over time periods and in different contexts

How do you validate SoS evaluation models, both singularly and in combination with regard to confidence levels, observability etc

Energy-efficient SoS Providing the knowledge, methods and tools to enable the builders, operators and users of Smart Grids to optimise their work

Compilation of a catalogue of cases providing examples

Exploration of the current situation in the implementation of SoS in order to clarify the problem space, to achieve consensus on what to tackle when and to provide a full range of use cases

How can academics and other researchers gain access to smart grid commercial systems or facilitate a public-private partnership e.g. starting a micro grid on campus

Creation of regional demonstrator projects

This is a global problem – how to build international collaboration, agreements, standards, regulations, operations, etc

Need to study, understand and integrate the various communities of interest at different levels e.g. consumers, energy generators, distributors etc

How do you engineer 'Auctions' to manage the behaviour of the energy market?

How to integrate legacy systems into smart grids

Understanding energy management for cloud data centres. Prediction of demand is important in understanding how to configure the cloud

Compilation of a catalogue of cases providing examples

Exploration of the current situation in the implementation of SoS in order to clarify the problem space, to achieve consensus on what to tackle when and to provide a full range of use cases

Trade-off Developing ways to enable decision-makers to create

Development of techniques and approaches for constructing and analysing the trade-space

Development of the methods, tools and metrics for


different SoS versions for a given purpose, and then to choose the ‘best’ one

visualisation / presentation of the trade-space

Ensure decision makers have a consensus view on the established paradigm (conceptualisation) for SoS and hence SoSE

Execute research into the identification and description of criteria for trade-off decisions

Develop understanding of how to create an effective SoS trading environment (including trust, transparency, ownership, commitment, etc

Prototyping SoS Addressing the issues involved in attempting to prototype a SoS

How and when to prototype an SoS?

What are the boundaries of effective prototyping (e.g. what can you achieve with prototyping, and what do you miss?)?

How do you represent inaccessible parts of the SoS that you are trying to prototype?

How do you guarantee the scalability of the prototype?

How do you incorporate context, evolution and likely emergent behaviour into an SoS prototype?

Definition & Evolution of SoS Architecture Extending and elaborating the Systems Engineering approach to the SoS environment

Development of holistic model based approaches for architecting SoS

How do you get convergence of different architectures and models used within a SoS?

How do you create an SoS enterprise architecture incorporating Views such as security, cost, human factors etc?

Development of common methodologies / interoperability mechanisms e.g. description and assessment

Developing new architecture frameworks or evolving / extending existing ones

How to develop executable architectures?

Developing mechanisms to handle dynamic evolution of SoS architectures

Develop an understanding of the role and limitations of open architectures

How do you determine SoS 'ilities' from SoS architectures

Architecting for non-data items e.g. semantic interoperability between humans


Development of holistic model based approaches for architecting SoS

How do you get convergence of different architectures and models used within a SoS?

Security Ensuring that the physical, ethical and cyber aspects of safety and security of the SoS, its people, its end-users, and its social and physical environment are properly addressed

How to ensure that any regulatory environment within states and between states both assists security and does not interfere with security (e.g. for international SoS)?

How to ensure secure co-operation between SoS to enable security to be enhanced?

How to ensure the safety and security of end-users and the environment for SoS where AI-based systems and other non-ethical decision systems are involved (e.g. preventing terrorist action-at-a-distance, across state boundaries)?

How to develop co-ordinated strategies for continuous cyber security and physical security (e.g. by using experience in banking, mobile phones, etc.)?

Development of methods and metrics for 'health monitoring' of cyber security and physical security (e.g. secure computers, but no control over who uses them)

Human Aspects Including human aspects such as culture, knowledge, roles and experience are included in SoS design and operation

How to keep knowledge about the SoS current with the evolution of the SoS (includes distribution of knowledge)?

Development of tools and methods for models of human and organisations: identify and prioritise what we need to/can model to improve the design and operation of SoS

How to deliver dynamic training services in accordance with an evolving SoS: how to go from prototypes to a real training facility

Develop and integrate situation awareness indicators at individual / group / organisational level in an SoS

How do you create an SoS enterprise architecture incorporating Views such as security, cost, human factors etc

Develop an understanding of business models and contracts within an SoS and how they incentivise how an SoS operates

Create models of group behaviour e.g. emergencies, group-think

Achieve an understanding of how to do architecting for non-data items e.g. semantic interoperability between humans


How to keep knowledge about the SoS current with the evolution of the SoS (includes distribution of knowledge)?

Table 2: Extracted Set of Research Elements from the emerging SRA

5 DISCUSION ON HIGH LEVEL SOS PROBLEM AREAS

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. Six areas in particular emerged (based on literature reviews, the case studies and consultation with the expert community) as worthy of review. • Safety, Security and Integrity • Emergence • Interoperability • Agility • Reconfigurability • Reuse

5.1 Safety, Security and Integrity These three topics are inter-related, and occasionally in conflict with each other. A widely-used 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 (Section 3.1), in Boundaries (Section 3.2), and in Reconfigurability (Section 5.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 inter-organisational, 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 inter-organisational knowledge sharing, both within the 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 in 1986 had very deleterious effects on farmers in Britain, who could not sell their livestock for years thereafter because of radioactive fall-out on their land, and the ash plume from the Eyjafjallajokull volcano in Iceland in 2010 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, and is of a separate design, 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 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. 5.2 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 once 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 thqt is unexpected or cannot be predicted by 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 within the SoS itself, 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: Release Date: 15 July 2013 © Loughborough University Page | 51

• 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. Fig shows this problem. Figure 6 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.

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


Fig 6: Illustration of barriers to the communication of useful Information and knowledge in a supply

chain system of systems. An explanation of this diagram will be found in the adjoining text

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. 5.3 Interoperability Firstly, 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). Secondly, noting the socio-technical nature of many SoS, it is clear that interoperability must be achieved at many levels and not just at the software 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 o Semantic interoperability o 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. 5.4 Agility The NECTISE6 research programme defined agility as follows:

6 Network Enabled Capability Through Innovative Systems Engineering Release Date: 15 July 2013 © Loughborough University Page | 54

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 Figure 7 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 UK defence ‘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 or resilient (two 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 (very costly). 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.

Fig 7: 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. Fortunately this is well understood as a prime function of SoS engineering, though methods and tools for assuring this are lacking. 5.5 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 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. 5.6 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). 6 TRADE-OFF Very little research has been carried out by the project into this area: what is reported below emerged out of discussion with the expert community in US in November 2012 and Brussels in January 2013. What is clear is that there is a significant need for research in this area. While tools and techniques exist (Keeney and Raiffa 1976, Ling, Mathieson et al. 2006, Alexander, Hall-May et al. 2007, McDonald 2008), their base assumptions, internal processes and offline nature limit their effectiveness, and better approaches are necessary. The first problem area that was identified is the issue of trade-off within SoS and within the environment/context within which the SoS is operating. Stakeholder identification and their sometimes-conflicting criteria as well as the need to include evolutionary decision-making among the criteria for trade-off are also important. Techniques for comprehensive and comprehensible trade-space analysis are required, capable of handling the feedback loops inherent in SoS, and of


intelligible presentation to the human analysts. Furthermore, socio-technical issues such as trust and transparency are not modelled well; these are important in practice as well, since the knowledge and information that may be involved in trade-off studies is of commercial significance and may be confidential. The answer to this may be to have distributed tools and methods, but there are none known at present. Finally, global drivers always need to be taken into account in future. When considering the potential value to industry of addressing this issue a range of potential benefits were identified: • SoS is rarely a greenfield activity; it is almost always a brownfield activity

involving the integration of new systems with legacy systems • The ability to carry out trade-offs efficiently and effectively would allow industry to

achieve greater service capability, with the added benefit of greater system robustness and addressing a range of ‘–ilities’ e.g. In turn, this will deliver Cost and Performance benefits

• Better relationships in the Business Environment and improved business models • Less risky integration with legacy systems • Re-use and sustainability would be included • Improved customer and stakeholder relationships • The existence of modelling applications would provide a lever to achieve

Government Action The groups also identified several areas of knowledge or expertise that it felt were required if the problems identified were to be addressed effectively: • Techniques for variance analysis (i.e. which are best?) • Blending approaches: construction of the options • Ability to construct the (complex) trade-space • Visualisation and understanding the results of modelling The groups identified the following existing baseline knowledge which might be of useful: • Multi-objective optimisation methodology • Scenario Planning expertise • Knowledge of Hybrid systems • The HYCON2 project • TOGAF ADM: one phase of this is dedicated to trade-off • Sustainability: IPCC and ‘People and the Planet’ reports (and others); also

domain-specific approaches such as the ESA Concurrent Design Facility, and the UK MoD Niteworks facility

Finally the groups felt that the key elements that should be included as critical items on the Strategic Research Agenda were: • Development of techniques and approaches for constructing and analysing the

trade-space • Visualisation/presentation of the trade-space based on the above


• Mind-set within decision makers (i.e. changing the paradigm to include, for instance, the global drivers)

• Identification and clear description of criteria for the trade-off • Creation of effective trading environments • Improve our understanding of trade-offs and side-effects


7 STANDARDS This section is divided into two parts: 7.1 discusses some general aspects of standards in relation to SoS engineering and operation; 7.2 outlines the current situation with SoSE-relevant international standards, and the standards themselves are listed in Appendix 1. 7.1 General Comments on Standards and SoSE 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 written for SoS or SoSE products, processes, management, or other aspects or endeavours; however, current efforts to harmonise existing standards do address SoS and SoSE issues. In this regard, important standards are ISO/IEC 12207, ISO/IEC 15288, ISO/IEC 24748, ISO/IEC 24765 and ISO/IEC 16337. Brief descriptions of these will be found in Appendix 1. 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 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. 7.2 Specific International Standards of Relevance to SoSE Accepting the dictum that it is by means of standards that engineers intercommunicate efficiently and interlink their work, the standards listed in Appendix


1 are likely to be of use in the engineering and operation of SoS. The standards in the Appendix are internationally accepted; there are many more national standards that would be applicable in national states; these have not been included on the grounds that in the EU it is the international standards that matter most. The nature of standards is evolving too. It is now recognised that there are four main clusters of standards; as the British Standards Institute has expressed it: • Specifications, which are prescriptive standards setting out detailed absolute

requirements. A specification is commonly used for product safety purposes or for other applications where a high degree of certainty and assurance is required by its user community.

• Codes of practice recommend sound good practice as currently undertaken by competent and conscientious practitioners. They are drafted to incorporate a degree of flexibility in application, whilst offering reliable indicative benchmarks. They are commonly used in the construction and civil engineering industries.

• Methods are also highly prescriptive, setting out an agreed way of measuring, testing or specifying what is reliably repeatable in different circumstances and places, wherever it needs to be applied. A Vocabulary is a set of terms and definitions to help harmonize the use of language in a particular subject or discipline.

• Guides are published to give less prescriptive advice which reflects the current thinking and practice amongst experts in a particular subject.

Most of the standards in the Appendix fall into the latter categories; this is because of the nature of SoS engineering, in that leverage is mainly at the interfaces, and reflects the modern trend in standard-setting to address principles rather than practice. The Appendix comprises several parts. Firstly, there is a list of European Directives relevant to SoSE. These have a direct impact on SoSE; there will be others odf relevance too, but more indirect. Next, there is a table listing standards clustered according to IT usage in organisation. Finally, the is a listing of individual standards, in numerical order, with brief descriptions of each standard. These are mainly ISO standards, but with additions from the IEC, ITU, and the IEEE.


8 SOS ARCHITECTURES 8.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 Release Date: 15 July 2013 © Loughborough University Page | 63

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. 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. 8.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 participation in an (sic) SoS seen as a net gain from the viewpoint of single-system 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. 8.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 net-centric 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.


9 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 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. 9.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 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 Release Date: 15 July 2013 © Loughborough University Page | 69

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. 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 on-going 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.


https://www.aof.mod.uk/aofcontent/tactical/engineering/content/tech_process/modaf_views.htm

10 SOS MODELLING AND SIMULATION 10.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. Models always represent an abstraction in which the complexity of a real system is reduced by selecting only the most significant system effects in order to understand the behaviours of the system. Some models have the purpose of enabling understanding (conceptual models), whereas others have the purpose of predicting behaviours from a set of boundary and/or initial conditions (e.g. simulations). The difficulty faced by the modellers of SoS is that a priori selection of important effects is problematic because of the highly non-linear nature of such systems, and because the removal of what may be regarded as insignificant interactions for the purposes of abstraction may cause erroneous non-linear or linear modelling effects to masquerade as real behaviours. Furthermore, SoS have both technical and non-technical characteristics (see section 3.1). This means that models must include behaviours described by more than one discipline and, possibly, from more than one philosophical position in order to represent the most complex types of SoS. Models could be vertically integrated, in the sense of creating a set of consistent models that offer more detail through integration of a hierarchical set of system levels. Models could be horizontally integrated in the sense of combining different types of models to represent different discipline based effects. Currently, this is only beginning to address the complexity that will be required for effective prediction. Of course, modelling approaches for SoS exist. A good model should incorporate judicious trade-off 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.


10.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 multi-agent systems using discrete event simulation tools (INCOSE, 2006; 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


11 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. 11.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 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 8) 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.

Fig 8: The NECTISE NEC-readiness Themes

Interoperability

Dependability

Agility

Availability

Affo

rdab

ility

Collaboration

Knowledge Mgmt


11.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. 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 9) 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.


Fig 9: Summary of the Impact of NEC on Required Systems Engineering

11.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). 11.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. 11.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 non-human 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.


11.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 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. 11.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 10).

Fig 10: Agile Development of Capability, from Lie, et al., 2008c


11.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). • 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 Accidents7).

• 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. 11.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. 11.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.

7 ‘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: 15 July 2013 © Loughborough University Page | 79

12 SOS VALIDATION AND VERIFICATION 12.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).


13 SOS QUALIFICATION AND ASSURANCE 13.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 networks8, 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

8 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: 15 July 2013 © Loughborough University Page | 81

shared information on obstacle and terrain clearance and aircraft-to-aircraft separation. 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 fault-analysis 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.


14 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. 14.1 SOS Types and Hierarchy Systems of systems are composed of numerous independent systems. Following table 3, 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 3: Lexicon for Describing SoS

14.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 Release Date: 15 July 2013 © Loughborough University Page | 83

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 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. 14.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 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. 14.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 3), 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. 14.4.1 Airline/FMC Modeling and Solution

Fig: 11a AND 11b: 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 11a); the results are used as function evaluations in a much smaller top-level 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 11b). 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 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. 14.4.2 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 yet-to-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 Release Date: 15 July 2013 © Loughborough University Page | 87

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.

Fig 12: 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 12). 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.


Fig 13: Simulation Results of Network Saturation under Infrastructure Provide Behaviours

An example outcome from this simulation approach, presented in (DeLaurentis and Ayyalasomayajula 2009) appears in figure 13. 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.


15 COMPLEX SOCIO-TECHNICAL FEATURES OF SOS 15.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.

15.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 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. 15.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. 15.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, 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’.


15.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.

• 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 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. Release Date: 15 July 2013 © Loughborough University Page | 94

15.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 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. 15.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 Release Date: 15 July 2013 © Loughborough University Page | 95

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. 15.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 inter-organisational 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 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.

15.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.

• 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 service-oriented 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."

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 14 below, from (Gover 1993) illustrates this:


Fig 14: 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. 15.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. 15.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.


15.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. • 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. 15.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


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 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. 15.5 Decision Making in SoS 15.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 crowd-control 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. 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. 15.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 decision-makers (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 Release Date: 15 July 2013 © Loughborough University Page | 104

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. 15.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. 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 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


http://en.wikipedia.org/wiki/International_Covenant_on_Civil_and_Political_Rights

http://en.wikipedia.org/wiki/International_Convention_on_the_Suppression_and_Punishment_of_the_Crime_of_Apartheid

http://en.wikipedia.org/wiki/International_Convention_on_the_Suppression_and_Punishment_of_the_Crime_of_Apartheid

http://en.wikipedia.org/wiki/International_Covenant_on_Economic,_Social,_and_Cultural_Rights

http://en.wikipedia.org/wiki/Convention_Relating_to_the_Status_of_Refugees

http://en.wikipedia.org/wiki/Protocol_Relating_to_the_Status_of_Refugees

http://en.wikipedia.org/wiki/Protocol_Relating_to_the_Status_of_Refugees

http://en.wikipedia.org/wiki/Convention_on_the_Rights_of_the_Child

http://en.wikipedia.org/wiki/United_Nations_Convention_Against_Torture

http://en.wikipedia.org/wiki/Convention_on_the_Elimination_of_All_Forms_of_Racial_Discrimination

http://en.wikipedia.org/wiki/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 • 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.


http://en.wikipedia.org/wiki/International_Convention_on_the_Protection_of_the_Rights_of_All_Migrant_Workers_and_Members_of_Their_Families

http://en.wikipedia.org/wiki/International_Convention_on_the_Protection_of_the_Rights_of_All_Migrant_Workers_and_Members_of_Their_Families

http://en.wikipedia.org/wiki/Convention_on_the_Prevention_and_Punishment_of_the_Crime_of_Genocide

http://en.wikipedia.org/wiki/Convention_on_the_Rights_of_Persons_with_Disabilities

http://en.wikipedia.org/wiki/International_Convention_for_the_Protection_of_All_Persons_from_Enforced_Disappearance

http://en.wikipedia.org/wiki/International_Convention_for_the_Protection_of_All_Persons_from_Enforced_Disappearance

http://en.wikipedia.org/wiki/Indigenous_and_Tribal_Peoples_Convention,_1989

http://en.wikipedia.org/wiki/Charter_of_Fundamental_Rights_of_the_European_Union

http://en.wikipedia.org/wiki/Convention_on_Action_against_Trafficking_in_Human_Beings

http://en.wikipedia.org/wiki/European_Charter_for_Regional_or_Minority_Languages

http://en.wikipedia.org/wiki/European_Convention_on_Human_Rights

http://en.wikipedia.org/wiki/European_Convention_for_the_Prevention_of_Torture_and_Inhuman_or_Degrading_Treatment_or_Punishment

http://en.wikipedia.org/wiki/European_Convention_for_the_Prevention_of_Torture_and_Inhuman_or_Degrading_Treatment_or_Punishment

http://en.wikipedia.org/wiki/European_Social_Charter

http://en.wikipedia.org/wiki/Framework_Convention_for_the_Protection_of_National_Minorities

http://en.wikipedia.org/wiki/American_Convention_on_Human_Rights

http://en.wikipedia.org/wiki/Inter-American_Convention_to_Prevent_and_Punish_Torture

http://en.wikipedia.org/w/index.php?title=Inter-American_Convention_on_Forced_Disappearance_of_Persons&action=edit&redlink=1

http://en.wikipedia.org/w/index.php?title=Inter-American_Convention_on_the_Prevention,_Punishment,_and_Eradication_of_Violence_against_Women&action=edit&redlink=1

http://en.wikipedia.org/w/index.php?title=Inter-American_Convention_on_the_Prevention,_Punishment,_and_Eradication_of_Violence_against_Women&action=edit&redlink=1

http://en.wikipedia.org/wiki/Inter-American_Convention_on_the_Elimination_of_All_Forms_of_Discrimination_against_Persons_with_Disabilities

http://en.wikipedia.org/wiki/Inter-American_Convention_on_the_Elimination_of_All_Forms_of_Discrimination_against_Persons_with_Disabilities

16 SOS PERFORMANCE MEASUREMENT 16.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,000-nautical-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. 16.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. 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).


17 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. 17.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, Release Date: 15 July 2013 © Loughborough University Page | 110

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 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.

17.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-and-them’ 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.

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

The table 4 below attempts to present an initial draft set of objectives for a baseline TEG framework: Board/Enterprise

Level Business Unit Level Project Level

Management 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

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

Process Working Groups provide a framework of processes tailored to the

Process Users Allow for tailoring of processes to specific projects.


Board/Enterprise Level

Business Unit Level Project Level

engineering processes. Monitor process performance Monitor standards performance

specific business. Aid process improvement. Aid decision making traceability. Provide a series of value-added metrics.

Ensure engineers use all mandated processes. Ensure metrics are used where they would aid a process.

Technology Engineering/IT Director Ensure IT and communication networks enable quality engineering. Direct R&T activities to ensure provision of SoA tools and methods

Tools/Methods WGs Provide Tools that enable quality engineering Provide Training Ensure Tools/Process /Roles match.

Engineers Ensure appropriate tools and technologies are used. Ensure feedback on any tool changes is acknowledged.

Table 4: Baseline Set of Objectives for the Introduction of a TEG Governance Framework.

17.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 15. 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.

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.


Fig 15: Framework for Engineering Governance

17.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 16 aims to demonstrate this.


Fig 16: 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. 18 RISK MITIGATION IN SOS 18.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.


19 TRAINING 19.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. 19.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 5 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/courses/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

Cranfield University http://www.cranfield.ac.uk/cds/postgraduatestudy/index.html Have SoS embedded into their MSc programmes


http://www.sosece.org/

http://www.lboro.ac.uk/study/postgraduate/courses/departments/eleceng/systemsengineering/

http://www.lboro.ac.uk/study/postgraduate/courses/departments/eleceng/systemsengineering/

http://www.ncsose.org/

http://www.cranfield.ac.uk/cds/postgraduatestudy/index.html

http://www.cranfield.ac.uk/cds/postgraduatestudy/index.html



support DoD with training, evidenced by recent Navy contract on website based at Old Dominion University (ODU).

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 engineers although case studies may be military-based.

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

SyntheSys Systems Engineers


https://www.ncoic.org/home/

http://seari.mit.edu/

https://engineering.purdue.edu/ProEd/courses/credit_courses?course=AAE56000&semyr=SP2012&crn=58863%20



Provides an established course at the University of Texas San Antonio on SoSE.

Provide practioner-level training courses in 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.

Table 5: SoSE Training Focus Across the US and the UK

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.


http://www.aticourses.com/systems_of_systems.htm

PART C: CASE STUDY ANALYSIS 20 CASE STUDY INVESTIGATION Part C describes the identification of critical advances required in SoS operation through case study analysis carried out in the period November 2011 to February 2012. 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 20.1 to section 20.5. An investigation analysing the identified issues across these case studies is then summarised in the section 20.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. 20.1 Defence Sector Within the defence sector, 2 case studies have been analysed namely “Tactical Data Link” and “AMC”. 20.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

Short-term

2015

2020

2030

Table 6: Critical Advances Needed by Specified Time Periods from Tactical Data Link Case Study Release Date: 15 July 2013 © Loughborough University Page | 121

Example Key: D1: Codification and agreement on universal operating procedures for coalition

forces in a given theatre of operation e.g. BML, common RoEs. 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.

Fig 17: Impact vs Implementation Relationship – Tactical Data Link Case Study


20.1.2 AMC Since AMC spans across 2 domains (i.e. Defence and Transport), analysis of this case study is summarised in the section 20.3.1 of this report. 20.2 IT Sector Within the IT sector, 2 case studies have been analysed namely “Human Tracking” and “NPfIT”. 20.2.1 Human Tracking

Any Other


IT3

IT5, IT6

SoS Techniques

IT1

Societal Context


IT1

IT6

Technology

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.

Fig 18: Impact vs Implementation Relationship – Human Tracking Case Study


20.2.2 NPfIT

Any Other


IT2

IT1, IT7

IT5

SoS Techniques

IT8

IT3

Societal Context


IT7

Technology

IT8

IT1, IT6

IT4, IT3

Short-term

2015

2020

2030

Table 8: Critical Advances Needed by Specified Time Periods from NPfIT Case Study 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.

Fig 19: Impact vs Implementation Relationship – NPfIT Case Study


20.3 Transport Sector Within the transport sector, 4 case studies have been analysed namely “AMC”, “ATS” “Fleet Level” and “SESAR”. 20.3.1 AMC

Any Other


T3, T4, T8

T7

SoS Techniques

T1, T2

Societal Context

T4, T8

T5

T7


T1, T2, T8

T7

Technology

T8

T6, T5

T7

Short-term

2015

2020

2030

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.

Fig 20: Impact vs Implementation Relationship – AMC Case Study


20.3.2 ATS

Any Other


T3, T4

T10

SoS Techniques

T1, T2

Societal Context

T4

T10


T1, T2, T9

T6

T10

Technology

T5, T6, T8, T7

T10

Short-term

2015

2020

2030

Table 10: Critical Advances Needed by Specified Time Periods from ATS 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 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

Fig 21: Impact vs Implementation Relationship – ATS Case Study


20.3.3 Fleet Level

Any Other

A1


SoS Techniques

T1

T4, T5

T2, T3, T4, T5

Societal Context

T7

T6, T7

T6


T6

Technology

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: Development of realistic aircraft models (this relates to simulation and

modelling challenges). T2: Validation of the interaction between various elements of the SoS. T3: Development of tools to optimise resource allocation. T4: Development of predictive models (past trends should be used as input but

what happens in the past may not continue in the future). T5: Development of governance tools for analysing and monitoring the SoS. T6: Understanding of how variation in external factors affects aviation. T7: Technology to understand/assess the environmental impact of transportation

systems. IT1: High performance computing to speed up simulation time in order to speed up

the assessment of different scenarios. A1: 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).


Fig 22: Impact vs Implementation Relationship – Fleet Level Case Study

20.3.4 SESAR

Any Other


T8

T1, T4, T6, T7

SoS Techniques

T8

T2

T3

Societal Context


T9

T4, T7

Technology

T2, T9

T1, T3, T5

Short-term

2015

2020

2030

Table 12: Critical Advances Needed by Specified Time Periods from SESAR 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 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.

Fig 23: Impact vs Implementation Relationship – SESAR Case Study


20.4 Manufacturing Sector Within the Manufacturing sector, 1 case study has been analysed namely “SCADA DCS”. 20.4.1 SCADA DCS

Any Other


M2

M6, M8

M1, M7

SoS Techniques

M4

Societal Context


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

data-independent 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 multi-domain 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.

Fig 24: Impact vs Implementation Relationship – SCADA DCS Case Study


20.5 Other Sectors In other sectors, 2 case studies have been analysed namely “Emergency Response” and “Water Management”. 20.5.1 Emergency Response (EM)

Any Other


A8

A1, A8, A9

SoS Techniques

A4, A5, A7

A5, A6, A10

Societal Context


Technology

A2

A7

A3, A10

Short-term

2015

2020

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.


Fig 25: Impact vs Implementation Relationship – Emergency Response Case Study

20.5.2 Water Management (WM)

Any Other


A4

A2

SoS Techniques

A3

Societal Context


A4

A4

Technology

A1

A4

Short-term

2015

2020

2030

Table 15: Critical Advances Needed by Specified Time Periods from Water Management Case Study Release Date: 15 July 2013 © Loughborough University Page | 137

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. 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

Fig 26: Impact vs Implementation Relationship – Water Management Case Study

20.6 Investigation Summary This section analyses the above case study outcomes (section 20.1 to section 20.5) to identify critical research issues emerging across various domains for effective operation of SoS. The commonalities are summarised in table 16 below.


Critical Advances Needed / Issues with Effective SoS Operation

Applicable Domain

Defence

Energy

ICT

Manufacturing

Transport

Others

1) Effective Interoperation between component systems & with external systems (including between different physical platforms and legacy system integration).

AMC, Tactical

Data Link

Human Tracking,

NPfIT

SCADA DCS

AMC, ATS, SESAR

ER, WM

2) Design, publish and / or apply agreed interface & interoperability standards.

Tactical Data Link

Human Tracking,

NPfIT

SCADA DCS

ATS, Fleet Level,

SESAR

ER, WM

3) Performance modelling and metrics for assessment and optimisation.

AMC,

Tactical Data Link

Human

Tracking, NPfIT

SCADA DCS

AMC, ATS, Fleet Level,

SESAR

WM

4) Distributed / linked simulation and modelling capabilities (including visualisation, mapping and trade space) for decision making.

AMC, Tactical

Data Link

Human Tracking

SCADA DCS


SESAR

ER

5) Dealing with evolution / re-configuration of component systems + SoS in general including enabling modifications to SoS during on-going operations (may include autonomy).

AMC, Tactical

Data Link

Human Tracking,

NPfIT

AMC, ATS, Fleet Level

ER



Applicable Domain

Defence

Energy

ICT

Manufacturing

Transport

Others

6) Effective stakeholder management (includes distributed control of SoS between stakeholders and their legal interactions).

AMC

Human Tracking,

NPfIT

SCADA DCS

AMC, ATS

ER, WM

7) Plan and agree on the application of operating procedures / regulations.

Tactical Data Link

Human Tracking,

NPfIT

SCADA DCS

ATS

WM

8) Governance tools for analysing and monitoring whole or part SoS behaviours, to detect when problems are emerging, both externally and internally.

AMC

NPfIT

SCADA DCS

AMC, ATS, Fleet Level

WM

9) Technology to solve bandwidth problems for communication and network management (physical and virtual systems).

AMC

Human Tracking

SCADA DCS

AMC, ATS

WM

10) Enterprise system architecture for describing the operating characteristics of any participating enterprise system within the SoS.

AMC

Human Tracking

SCADA DCS

AMC, ATS



Applicable Domain

Defence

Energy

ICT

Manufacturing

Transport

Others

11) Impact analysis on society / environment

AMC


SESAR

12) Open source connectivity (including open architectures)

Human Tracking,

NPfIT

SCADA DCS

Table 16: Case Study Analysis Summary Across Domains


PART D: SETTING THE SOS RESEARCH PRIORITIES 21 SOS RESEARCH PRIORITIES This section reports on SoS research priorities as at May 2012. Since then further work has been carried out in developing the Strategic Research Agenda: full details of the current research priorities and the process of defining the Strategic Research Agenda can be found in Deliverable 5.1 due to be delivered in May 2013 entitled ‘Common Vision and Strategic Research Agenda’. This document is not publically available at the time this revised State of the Art Document was published. 21.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 21.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 Release Date: 15 July 2013 © Loughborough University Page | 142

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. 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. 21.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: 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.

Fig 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 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 Release Date: 15 July 2013 © Loughborough University Page | 145

how to interpret the results from such systems of models. This theme is related to ‘multi-notation approaches’ which forms an important enabler for multi-heterogeneous 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? 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. Release Date: 15 July 2013 © Loughborough University Page | 146

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 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. Release Date: 15 July 2013 © Loughborough University Page | 147

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.

Fig 26: Impact vs Implementation Relationship – Expert Workshop Findings

A1 Techniques for validation of interoperability A2 Metric identification/validation; global metrics A3 Trade-off techniques for integration of legacy; evolution A4 Multi-heterogeneous modelling A5 Enterprise SoS, governance & policy A6 How to prototype SoS? A7 Qualification of safety or security critical SoS B1 Multi-notation approaches


B2 Security of SoS implementation B3 Capabilities / processes and competencies B4 Scenario-based simulation and analysis B5 Architecture patterns for SoS B6 Dynamic SoS B7 Engineering for emergence B8 Goals and expectations in SoS B9 Multi-level infrastructure consistency 21.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 ‘multi-heterogeneous 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

21.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. 21.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.


Research Priorities [from workshop

outcome – section 19.2.1]

Critical Advances Applicable ( ◙ ) Across Domains [from case study

analysis – chapter 18.6]

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

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

◙

◙

◙

◙

◙

◙

◙

◙

◙

How to Prototype SoS?

◙

◙

◙

◙

◙

◙

◙

◙


Table 17: Comparison of Workshop and Case Study Outcomes

Scenario-based Simulation and Analysis

◙

◙

◙

◙

◙

◙

◙

◙

◙

◙

Dynamic SoS

◙

◙

◙

◙

◙

◙

◙

◙

◙

Security for SoS Implementation

◙

◙

◙

◙

◙

◙

◙

◙

◙

◙

Capabilities / Processes and Competencies

Techniques for Validation of Interoperability

◙

◙

◙

◙

◙

◙

◙

◙

◙

◙

Qualification of Safety or Security Critical SoS

◙

◙

◙

◙

◙

◙

◙

◙

◙

◙

Multi-level infrastructure consistency

◙

◙

◙

◙


22 SUMMARY The aim of this second issue of the State of the Art was 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 included work carried out in the IT and Defence sectors which were believed to represent state of the art in terms of current practice. The report has provided an introduction to Systems of Systems in the domains of interest (section 3) and has tried to differentiate between Systems and Systems of Systems. It has described Global Drivers which SoS must take into account and where SoSE can contribute a great deal of value added. In Part B a range of research areas were selected based on the expertise of the authors, literature reviews and most importantly the input from the evolving expert community. This review dealt with 6 key high level problem SoS problem areas in section 5 before moving on to cover specific identified areas of SoS and SoSE. These included: • Trade-off • Standards • SoS Architectures • The Open Approach to SoS Engineering • SoS Modelling and Simulation • SoS Network Enablement • SoS Validation and Verification • SoS Qualification and Assurance • Management, Control and Operation of SoS • Complex Socio-Technical Features of SoS • SoS Performance Measurement • SoS Technical and Engineering Governance • Risk Mitigation in SoS • Training Finally the document presents the case study research that was carried out to complement the State of the Art review in Part C. The authors do not claim complete coverage of all possible SoS areas of research but have been guided by their own expertise and by the evolving expert community. The content of the SoA has been fed into the overall process for the generation of the Strategic Research Agenda and as a result of that process and on-going consultation with our expert community both in Europe and USA this second revised version of the SoA has been published.

The contents of this document have been taken forward via a range of workshops and key elements from it have been cristalised in the final deliverable to the EU entitled ‘Common Vision and Strategic Research Agenda”, Deliverable D5.1 due to be published in June 2012.


23 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. (2011). The agility advantage, US DOD Command & Cpontrol research Program.

Alexander, R. D., M. Hall-May and T. P. Kelly (2007). Certification of Autonomous Systems under UK Military Safety Standards. 25th International System Safety Conference. Baltimore MD.

Allen, P. M., J. Boulton, M. Strathern and J. Baldwin (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.

Allwood, J. M., M. F. Ashby, T. G. Gutowski and E. Worrell (2011). "Material efficiency: a white paper." Resources, Conservation and Recycling 55: 362-381.

Andersson, G., P. Donalek, R. Farmer, N. Hatziargyriou, I. Kamwa, P. Kundur, N. Martins, J. Paserba, P. Pourbeik, J. Sanchez-Gasca, R. Schulz, A. Stankovic, C. Taylor and V. Vittal (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.

Andrews, J. D., R. Remenyte-Prescott and D. R. Prescott (2010). Reliability analysis of missions with cooperating platforms. Reliability and Maintainability Symposium (RAMS). San Jose, CA: 1-6.

Asaro, P. M. (2011). "Remote-control crimes." IEEE Robotics & Automation 18(1): 68-71. 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, P. Sridhar, A. M. Madni and M. Jamshidi (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. Bernus, P., L. Nemes and G. Schmidt, Eds. (2003). Handbook on enterprise architecture.

Heidelberg, Springer Verlag. Bianconi, G. and A.---L. Barabasi (2001). "Competition and multiscaling in evolving networks."

Europhysics letters 54: 436---442. 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.

Boehm, B. (1988). "A spiral model of software development and enhancement." Computer(May): 61-72.

Charette, R. N. (2005). "Why software fails." IEEE Spectrum 42(9): 36-43. Charette, R. N. (2012). "Cybercriminals hold Australian medical clinic electronic patient

records hostage." IEEE Spectrum Risk Analysis Blog http://spectrum.ieee.org/riskfactor/telecom/security/cybercriminals-hold-australian-medical-clinic-electronic-patient-records-hostage.

Chen, D., G. Doumeingts and F. V. F (2008). "Architectures for enterprise integration and interoperability: Past, present and future." Computers in Industry 59(7): 647-659.

Cheng, B. H. C., H. Giese, P. Inverardi and J. M. deLemos (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.


http://spectrum.ieee.org/riskfactor/telecom/security/cybercriminals-hold-australian-medical-clinic-electronic-patient-records-hostage

http://spectrum.ieee.org/riskfactor/telecom/security/cybercriminals-hold-australian-medical-clinic-electronic-patient-records-hostage

CMU SEI, (2006) Ultra-Large-Scale-Systems, Overview, http://www.sei.cmu.edu/uls/index.cfm [accessed 22/05/13].

Collins, B. (2011). Needs and Challenges for Systems Thinking London, UK, Department for Business Innovation and Skills, HM Government, UK.

Collins, B. (2012). Building resilience into complex systems. Loughborough University. Conklin, J. (2006). Dialogue mapping: building shared understanding of wicked problems.

New York, J. Wiley & Sons. Cullen, W. D. (1990). Report of the Official Inquiry into the Piper Alpha Disaster. London, Her

Majesty's Stationery Office. 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

deMeyer, A., C. H. Loch and M. T. Pich (2002). "Managing project uncertainty: from variation to chaos." Sloan Management Review 43(2): 60-67.

Derler, P., E. A. Lee and A. Sangiovanni-Vincentelli. (2012). "Modeling cyber–physical systems." Proceedings of the IEEE (special issue on Cyber-Physical Systems) 100(1): 13-28.

Diamond, J. (2011). Collapse: how societies choose to fail or survive. London, Penguin. 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.

EC2011 (2011). Roadmap to a Single European Transport Area --- towards a competitive and resource efficient transport system.

Eurostat (2011). EU27 population is expected to peak by around 2040. Eurostat. Brussels, Eurostat Press Office: 2.

Firesmith, D. (2010) Profiling Systems Using the Defining Characteristics of Systems of Systems (SoS), Technical note, CMU/SEI-2010-TN-001, Carnegie Mellon.

Fisher, D. A. (2006). An emergent perspective on interoperation in systems of systems, Carnegie-Mellon University.

Frakes, W. B. and K. Kang (2005). "Software engineering research: status and future." IEEE Transactions on Software Engineering 131(7): 529-536.

Goderis, A., C. Brooks, I. Altintas, E. A. Lee and C. Goblea (2009). "Heterogeneous composition of models of computation." Future Generation Computer Systems 25(5): 552-560.

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.

Hansen, J. (2012). Climate change is happening now --- a carbon price must follow. The Guardian. London.

Hansen, J., M. Sato, et al. (2012). "Perception of climate change." Proceedings of the National Academy of Sciences, USA 109(37): 2415---2423.

Harvey, F. (2012). Climate change is already damaging global economy, report finds. The Guardian. London, Guardian Trust.


http://www.dsp.dla.mil/app_uil/content/newsletters/journal/DSPJ-01-07.pdf

Henshaw, M. J. d., P. Lister, A.D. Harding, D. Kemp, A. J. Daw, Andrew Farncombe and M. Touchin (2011). Capability engineering – an analysis of perspectives. International Council on Systems Engineering (INCOSE) 21st International Symposium, , . Denver, US.

Hitchins, D. K. (2003). Advanced systems thinking, engineering and management. Norwood, MA.

Hollnagel, E., D. D. Woods and N. Leveson, Eds. (2006). Resilience engineering. Aldershot, UK, Ashgate Publishing Ltd.

HSE (1980). ltalian Parliament Commission of Enquiry, Seveso - final report. London, Health & Safety Executive.

Hsiang, S. M. (2010). "Temperarture and cyclones strongly associated with economic production in the Caribbean and Central America." Proceedings of the National Academy of Sciences 107(35): 15367---15372

Hsu, J. C. (2009). Emergent behaviour of systems-of-systems. INCOSE 2009 Conference. Los Angeles.

Jamshidi, M., Ed. (2009). System of systems engineering - innovations for the 21st century, J. Wiley & Sons.

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, R. Unal, D. Dryer, A. Sousa-Poza, R. Safford, W. Peterson and G. Rabadi (2003). "System of systems engineering." Engineering Management Review 36(4): 62-75.

Keeney, R. L. and H. Raiffa (1976). Decisions woith multiple objectives, preferences and value trade-offs. New York, J. Wiley & Sons.

Kuras, M. L. and B. E. White (2005). Engineering enterprises using complex-system engineering. INCOSE 2005, Rochester NY, INCOSE.

Laprie, J.-C., K. Kanoun and M. Kaâniche (2007). Modelling interdependencies between the electricity and information infrastructures. Lecture Notes on Computer Systems. S. N. Oster, Springer. 4680: 54-67.

Lawson, D. (2005). Engineering Disasters - Lessons to be Learned, ASME Press. Lee, B., F. Preston, J. Kooroshy, R. Bailey and G. Lahn (2012). Resource futures. London,

Royal Institue of International Affairs, Chatham House. Lee, C., J. Lehoczky, R. Rajkumar and J. Hansen (1999). A scalable solution to the multi-

resource QoS problem. Proceedings of the 20th IEEE Real-Time Systems Symposium., Phoenix, AZ, IEEE Computer Society Press.

Lee, E. A. (2010). Disciplined heterogeneous modeling. Model Driven Engineering Languages and Systems (13th International Conference, MODELS 2010, Oslo, Norway 3-8, 2010, Proceedings, Part II). D. C. Petriu, N. R. (17) and Ø. Haugen. Heidelberg, Springer Verlag.

leMerle, M. (2011). How to prepare for a black swan. Strategy+Business, Booz & Co. 64. Leveson, N., N. Dulac, D. Zipkin, J. Cutcher-Gershenfeld, J. Carroll and B. Barrett (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.

Ling, M., G. Mathieson, L. Bache, M. Selvestrel, O. S. Marr, G. Tidhar and M. Waters (2006). Developing a requisite analytic trade-space for assessing Agile Mission Grouping - problem definition for the development of the DARNSTORMS model. 11th ICCRTS - Coalition Command and Control in the Networked Era, Cambridge, UK, US DOD.

Lopez, D. (2006). Lessons learned from the front lines of the aerospace industry - balancing complexity and risk. IEEE/SMC International Conference on System of Systems Engineering, Los Angeles, IEEE.

Mackley, T. (2008). Concepts of agility in Network Enabled Capability. Realising Network Enabled Capability. Oulton Hall, Leeds, UK, BAE Systems.

Mackley, T., S. Barker and P. John (2007). Concepts of agility in Network Enabled Capability. The NECTISE project. Cranfield, Cranfield University, UK 8.

Maier, M. W. (1998). "Architecting principles for systems-of-systems." Systems Engineering 1(4): 267-284.


McDonald, N. (2008). Challenges facing Resilience Engineering as a theoretical and practical project. Proceedings of the Third Resilience Engineering Symposium. E. Hollnagel, F. Pieri and E. Rigaud. Juan-les-Pins, France, Presses des Mines: 205-210.

Meadows, D. H., D. L. Meadows, et al. (1972). The limits to growth: a report on the Club of Rome's project on the predicament of Mankind. London, Earth Island Ltd.

McMichael, A. J. and K. B. G. Dear (2010). "Climate change: Heat, health, and longer horizons." Proceedings of the National Academy of Science 107(21): 9483---9484.

Mittal, S. (2007). DEVS unified process for integrated development and testing of service oriented architectures. Ph.D., University of Arizona.

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)), Network-Centric Operations Industry Consortium.

Neaga, E. I., M. J. d. Henshaw and Y. Yue (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 and M. A. Sinclair (2006). Ergonomic aspects of ‘good engineering governance’ in the design process. Contemporary Ergonomics. P. Bust. London, Taylor & Francis: 62-66.

Northrop, L., P. Feiler, R. P. Gabriel, J. Goodenough, R. Linger, T. Longstaff, R. Kazman, M. Klein, D. Schmidt, K. Sullivan and K. Wallnau (2006). Ultra-Large-Scale Systems -- the software challenge of the future, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA 15213-3890, USA.

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.

Oreskes, N. and E. M. Conway (2010). "Defeating the merchants of doubt." Nature 465: 686-687.

Parasuraman, R., T. B. Sheridan and C. D. Wickens (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.

Prescott, D. R., R. Remenyte-Prescott and J. D. Andrews (2008). A system reliability approach to decision making in autonomous multi-platform systems operating phased missions. Reliability, Availability and Maintainability Conference (RAMS 2008). Las Vegas, IEEE.

Prior, T., D. Giurco, et al. (2011). Resource depletion, peak minerals and the implications for sustainable resource management. International Society for Ecological Economics (ISEE) 11th Biennial Conference. Oldenburg/Bremen, Germany.

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. (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. 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. Rebovich, G. (2008). Enterprise system of systems. Systems of systems engineering -

principles and applications. M. Jamshidi. Boca Raton, CRC Press: 169-190. Ring, J. and T. Tenorio (2012). "Systems of the third kind: distinction, implications, and

initiatives." INCOSE Insight 15(2): 9---12.


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, A. M. Ross, D. H. Rhodes and D. E. Hastings (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 and K. H. Roberts (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, J. M. Warmkessel and N. P. Diller (2004). "Multi-attribute tradespace exploration as front end for effective space system design." Journal of Spacecraft and Rockets 41(1): 20-28.

Rushby, J. (2008). Runtime certification. Eighth workshop on runtime verification: RV08. M. Leucker. Budapest, HU, Springer Verlag. Volume 5289, Springer-Verlag Lecture Notes in Computer Science: 21-35.

Sachs, J. (2011). The price of civilisation. London, The Bodley Head. Sahin, F., M. Jamshidi and P. Sridhar (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.

Sha, L., S. Gopalakrishnan, X. Liu and Q. Wang (2009). "Cyber-physical systems: a new frontier." Machine Learning in Cyber Trust: 3-13.

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.

Sherwood, S. C. and M. Huber (2010). "An adaptability limit to climate change due to heat stress." Proceedings of the National Academy of Sciences 107: 9552---9555

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.

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 and C. Keating (2008). "System of systems engineering: an

emerging multidiscipline." International Journal of Systems Engineering 1(1-2): 1-17. Sullivan, K., W. Knaus and R. Marks (2010). An ultra-large-scale systems approach to

national-scale health information systems. FoSER '10 Proceedings of the FSE/SDP workshop on Future of software engineering research, Santa Fe, New Mexico, USA, Association of Computing Machinery.

Sulston, J. (2012). People and the planet. London, The Royal Society. Tainter, J. (1988). The Collapse of Complex Societies. London, Cambridge University Press.

Taleb, N. N. (2008). The black swan: the impact of the highly improbable. London, Penguin.


Tranfield, D., D. Denyer and J. Marcos (2004). Management and development of High Reliability Organisations. Bedford, UK, Cranfield University: 1-3.

UN---FAO (2009). How to feed the world in 2050. 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. Wallach, W. and C. Allen (2009). Moral machines: teaching robots right from wrong. Oxford,

UK, Oxford University Press. Weick, K. E. and K. M. Sutcliffe (2001). Managing the unexpected : assuring high

performance in an age of complexity. San Francisco, Jossey-Bass. Weick, K. E., K. M. Sutcliffe and D. Obstfeld (1999). " Organizing for high reliability:

processes of collective mindfulness." Research in Organisational Behaviour 21: 23-81. Wells, G. D. and A. P. Sage (2008). Engineering of a system of systems. Systems of systems

engineering - principles and applications. M. Jamshidi. Wenger, E., R. McDermott and W. M. Snyder (2004). Cultivating communities of practice,

Harvard Business School Publications. WETO---H2 (2006). World energy technology outlook --- 2050. Brussels, Directorate Energy,

European Commission Wilbanks, T. J., P. R. Lankao, et al. (2007). Industry, settlement and society. Climate Change 2007: Impacts, Adaptation and Vulnerability. Fourth s avoided. Washington, DC, World Bank. 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.

Yang, Y., B. Boehm and D. Port (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 and H. P. H. (2000). Theory of modeling and simulation: integrating discrete event and continuous complex dynamic systems. New York, Academic Press.

Zivin, J. G. and M. J. Niedell (2010). Temperature and the allocation of time: the implications for climate change. Cambridge, MA, National Bureau of Economic Research.


24 APPENDIX 1: REVIEW OF STANDARDS This annex has the following two-part structure. Part 1 contains a table that conveniently clusters ISO standards into domains of use. The table is adapted from the website of IT Governance Ltd, Unit 3, Clive Court, Bartholomew's Walk, Cambridgeshire Business Park, Ely, CB7 4EH, United Kingdom, http://www.itgovernance.co.uk. This table does not directly address the issues of SoS; it is aimed mainly at governance within the IT domain within single organisations.

Part 2 is an ordered numerical listing of EU Directives, and standards from international agencies; mainly ISO, but also some from CEN/CENELEC, IEC, ITU-T, and IEEE. Many of the ISO inclusions are for issues beyond IT, concerned with the design and operation of organisations.

Neither the table nor the subsequent listings should be considered to be exhaustive; they are the result of web searches over several months. Finally, it will be noted that none of these standards addresses SoS directly, but they will influence the way that SoS are created and operated.

24.1 Part 1: IT-relevant International Standards Grouped into Usage Clusters

IT Service Management Standards

▪ ISO/IEC 20000-1:2011 (ISO 20000-1) ITSM Specification ▪ ISO/IEC 20000-2:2005 (ISO 20000-2) ITSM Code of Practice ▪ ISO/IEC 20000-3:2009 (ISO 20000-3) Guidance on Scope & Applicability ▪ ISO/IEC 20000-4:2010 (ISO 20000-4) Process Reference Model ▪ ISO/IEC 20000-5:2010 (ISO 20000-5) Exemplar Implementation Plan ▪ ISO15504-5 (ISO 15504-5) - Exemplar Process Assessment Model ▪ ISO15504-1 (ISO 15504-1) - Exemplar Process Assessment Model ▪ ISO15504-2 (ISO 15504-2) - IT Process Assessment ▪ ISO15504-3 (ISO 15504-3) - Guidance on Performing an Assessment ▪ ISO15504-4 (ISO 15504-4) - Process Improvement and Process Capability ▪ ISO15504-6 (ISO 15504-6) - Exemplar System Life Cycle Process ▪ ISO15504-7 (ISO 15504-7) - Assessment of Organisational Maturity ▪ ISO19011 (ISO 19011) - Guidelines for Auditing Management Systems ▪ ISO23988:2007 (ISO 23988) - IT in the Delivery of Assessments

Information Security Standards

• ISO/IEC 27000:2009 (ISO 27000) ISMS Overview & Vocabulary • ISO/IEC 27001:2005 (ISO 27001) ISMS - Requirements (revised BS 7799 Part

2:2005) • ISO/IEC 27002:2005 (ISO 27002) ISMS Code of Practice • ISO/IEC 27003:2010 (ISO 27003) ISMS Implementation Guidance • ISO/IEC 27005:2011 (ISO 27005) Information Security Risk Management • ISO/IEC 27006:2007 (ISO 27006) Requirements for ISMS Certification Bodies • ISO/IEC 27007:2011 (ISO 27007) ISMS Auditing • ISO/IEC 27008:2011 (ISO 27008) Guidelines for Auditors on Information Security

Controls. Release Date: 15 July 2013 © Loughborough University Page | 160

http://www.itgovernance.co.uk/

http://www.itgovernance.co.uk/shop/p-683.aspx






















• ISO/IEC 27010:2012 (ISO 27010) Infosec Communications. • ISO/IEC 27011:2008 (ISO 27011) Guidelines for ISM Implementation in

Telecommunications Organisations. • ISO/IEC 27013:2013 (ISO 27013) Integrated Implementation of ISO27001 and

ISO20000. • ISO/IEC 27031:2011 (ISO 27031) Guidelines for ICT Readiness for Business

Continuity • ISO/IEC 27032:2012 (ISO 27032) Guidelines for Cyber security • ISO/IEC 27035 (ISO 27035) – Information technology - Security incident

management. • ISO27799:2008 (ISO 27799) Guidelines for Managing Information Security in the

Health Sector • ISO13053-2 (ISO 13053-2) Six Sigma Tools and Techniques • ISO13053-1 (ISO 13053-1) Six Sigma DMAIC Methodology • ISO13335-1:2004 (ISO 13335-1) ICT Security Management Concepts and Models • ISO13569:2005 (ISO 13569) Information Security Guidelines • ISO22857:2004 (ISO 22857) Health Informatics - Guidelines on Data Protection • ISO30300:2011 (ISO 30300) Records Management Fundamentals and Vocabulary • ISO30301:2011 (ISO 30301) MSR Requirements

Network Security Standards

• ISO/IEC 27033-1:2009 (ISO 27033-1) Concepts and Guidance on Network Security.

• ISO/IEC 27033-2 (ISO 27033-2) Design and Implementation of Network Security. • ISO/IEC 27033-3 (ISO 27033-3) Reference Networking Scenarios. • ISO/IEC 27034-1:2011 (ISO 27034-1) Application Security Overview and Concepts • ISO/IEC 18028-3:2005 (ISO 18028-3) Using Security Gateways • ISO/IEC 18028-4 (ISO 18028-4) Securing Remote Access • ISO/IEC 18028-5 (ISO 18028-5) Securing Communications Across Networks • ISO/IEC 18043 (ISO 18043) IDS Selection, Deployment and Operations • ISO/IEC 18045 (ISO 18044) Methodology for IT Security • ISO24767-1:2008 (ISO 24767-1)IT Home Network Security Requirements

Risk Management Standards

• ISO/IEC 31010:2009 (ISO 31010) Risk Assessment Techniques • ISO31000:2009 (ISO 31000) Risk Management Guidelines • ISO Guide 73: 2009 (ISO 73 2009) Definitions of Generic Terms Related to Risk

Management

Business Continuity Standards

• ISO/IEC 27031:2011 (ISO 27031) Guidelines for ICT Readiness for Business Continuity

• ISO/IEC 22301:2012 (ISO 22301) BCMS Requirements • ISO/IEC 22300:2012 (ISO 22300) Societal Security Terminology • ISO/IEC 22313:2012 (ISO 22313) Societal Security – Business Continuity

Management Systems – Guidance • ISO/IEC 22320:2011 (ISO 22320) Requirements for Incident Response • ISO/IEC 22399:2007 (ISO 22399) Incident Preparedness and Operational

Continuity Management • PAS200:2011 (PAS 200:2011) Crisis Management Guidance and Practice • PAS25111:2010 (PD 25111) Human Aspects of Business Continuity • PAS25222:2011 (PD 25222) BCM for the Supply Chain Release Date: 15 July 2013 © Loughborough University Page | 161





































• PAS25666:2010 (PD 25666) BCM Exercising & Testing

Quality Management Systems Standards

• ISO9000:2005 (ISO 9000) Quality Management Systems - Fundamentals & Vocabulary

• ISO9001:2008 (ISO 9000) Quality Management Systems - Requirements • ISO9004:2009 (ISO 9000) Quality Management Systems - Performance

Improvement

Disaster Recovery Standards

• ISO24762 (ISO 24762) Disaster Recovery Service Guidelines

Environment and Energy Standards

• ISO14001:2004 (ISO 14001) Environmental Management Systems - Specifications • ISO14004:2004 (ISO 14001) Environmental Management Systems - Guidelines • ISO50001:2011 (ISO 50001) Energy Management Systems - Requirements

Software Standards

• ISO/IEC 19770-1:2006 (ISO 19770-1) - Software Asset Management Processes • ISO12207 (ISO 12207) - Software Life Cycle Processes • ISO15288:2008 (ISO 15288) - Systems and Software Engineering • ISO9770-1:2012 (ISO 97701) - Software Asset Management • ISO9770-2:2012 (ISO 97701-2) - SAM Part 2 - Software Identification Tag

Corporate Governance Standards

• ISO38500:2008 (ISO 38500) Corporate Governance - Code of Best Practice

Project Governance Standards

• ISO10006 (ISO 10006) - Guidelines for Quality Project Management • ISO10007 (ISO 10007) - Guidelines for Configuration Management • ISO15489-1 (ISO 15489-1) - Managing Records of Originating Organizations • ISO15489-2 (ISO 15489-2) - Implementation Guide for Record Management

Security

• ISO15408-1 (ISO 15408-1) Evaluation Criteria for IT Security • ISO15443-1 (ISO 15443-1) Framework for IT Security Assurance • ISO15947 (ISO 15947) IT Intrusion Detection Framework • ISO19092 (ISO19092) Biometrics Security Framework • ISO19791:2006 (ISO 19791) Security Assessment of Operational Systems • ISO22600-2 (ISO 22600) Privilege Management and Access Control • ISO24767-2:2009 (ISO 24767-2) Internal Security Services - SCPM

Other Standards

• ISO22000:2005 (ISO22000) Food Safety Management System (FSMS) Requirements

• ISO22003:2005 (ISO22003) Food Safety Management System (FSMS) Requirements for Auditing Bodies

• ISO22004:2005 (ISO22004) Application of ISO22000 2005 for FSMS Release Date: 15 July 2013 © Loughborough University Page | 162





























• ISO26000 (ISO 26000) Application of ISO22000 2005 for FSMS • ISO28000:2007 (ISO 28000) SMS for the Supply Chain • ISO28001:2007 (ISO 28001) Implementing Supply Chain Security • ISO28003:2007 (ISO 28003) Supply Chain SMS Requirements • ISO28004:2007 (ISO 28004) Guidelines for Implementation of ISO28000 • PAS2015:2010 (PAS 2015) Framework for Health Services Resilience • PAS55-1:2008 (PAS 55-1) Specification for the Optimised Management of

Physical Assets. • PAS55-2:2008 (PAS 55-2) Guidelines for the Application of PAS 55-1. • PAS99 (PAS 99) Specification of Common Management System Requirements as

a Framework for Integration 24.2 Part 2: Selected International Standards for Organisations involved in

SoS

Relevant EU Directives & regulations

89/391/EEC Directive on the introduction of measures to encourage improvements in the safety and health of workers at work. The Framework Directive. Effective from 31/12/92

89/392/EEC Directive on the safety of machinery

See also 91/368/EEC, amending this Note that this specifies different classes of standards: • A: cover fundamental aspects • B1: safety aspects of machines • B2: components used on a wide variety of machines • C: vertical stds that cover a specific type of machine.

89/654/EEC Directive concerning the minimum safety and health requirements for

the workplace. The Workplace Directive. Effective from 31/12/92 Contact: Michael Madeley 071--243-6391

89/655/EEC Directive concerning the minimum safety and health requirements for

the use of work equipment by workers at work. The Use of Work Equipment Directive. Effective from 31/12/92 Note amendments to this: Council Directive 95/63/EC, 2001/45/EC, 2007/30/EC, consolidated into this directive.

91/368/EEC Amendment to directive on the safety of machinery

See also 89/392/EEC. From 1/1/95 all machinery must have a CE mark. This requires conformity to European standards, the existence of a Technical Construction File for each and every machine, available at 48 hours notice, certification by third parties for some classes of machines, and possible type-examination by approved bodies. ‘Due diligence’ is required. Furthermore, machines cannot be updated without getting a CE mark. Note that the TCF requires drawings, safety test results, safety methods documented, certificates of conformity, operation and maintenance instructions, in the language agreed with the purchaser.











http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0063:EN:NOT

92/57/EEC Implementation of minimum safety & health requirements at temporary or mobile construction sites.Consolidated document, including later amendments

Directive 95/46/EC Protection of individuals with regard to the processing of

personal data and on the free movement of such data In current effect, but to be updated by the General Data Protection Regulation (GDPR), and expected to take effect in 2016

COM(2008) 886 final Action Plan for the Deployment of Intelligent Transport

Systems in Europe The main policy objectives arising from these challenges are for transport and travel to become cleaner, more efficient, including energy efficient & more safe and more secure.

1999/31/EC of 26 April 1999 on the landfill of waste

Consolidated document, including later amendment: Council Directive 2011/97/EU criteria for the storage of metallic mercury considered as waste.

Council Regulation (EC) No 2157/2001 of 8 October 2001 on the Statute for a

European company Setting up a European public limited-liability company (Societas Europae)

2005/32/EC Framework for the setting of ecodesign requirements for energy-using

products Amends 92/42/EEC, 96/57/EC & 2000/55/EC The framework directive defines the principles, conditions and criteria for setting environmental requirements for energy-using appliances (ecodesign). It makes no direct provision for mandatory requirements for specific products; this will be done at a later stage for given products via implementing measures.

2006/24/EC Retention of data generated or processed in connection with the

provision of publicly available electronic communications services or of public communications networks Amends 2002/58/EC, and informs telecoms companies on implementation of Directive 95/46/EC on personal data protection

COM(2008) 886 final Action Plan for the Deployment of Intelligent Transport

Systems in Europe The main policy objectives arising from these challenges are for transport and travel to become cleaner, more efficient, including energy efficient & more safe and more secure.

2008/98/EC Waste Framework Directive

establishes the legislative framework for the handling of waste in the EU. It defines key concepts such as waste, recovery and disposal and puts in place the essential requirements for the management of waste. See also 2012/19/EU

2009/101/EC & 2012/30/EU Co-ordination of safeguards for EU Companies (each

covering different aspects) To protect the interests of members and third parties, as required by Member States







2012/19/EU Waste electrical and electronic equipment

See also 2008/98/EC. Addresses the prevention of WEEE and, in addition, by the re-use, recycling and other forms of recovery of such wastes so as to reduce the disposal of waste and to contribute to the efficient use of resources and the retrieval of valuable secondary raw materials.

COM(2013) 48 final (2013/0027) Measures to ensure a high common level of

network and information security across the Union Will require the Member States to increase their preparedness and improve their cooperation with each other, and by requiring operators of critical infrastructures, such as energy, transport, and key providers of information society services (e-commerce platforms, social networks, etc), as well as public administrations to adopt appropriate steps to manage security risks and report serious incidents to the national competent authorities.

ISO Standards

SWIFT financial transfer protocols The Society for Worldwide Interbank Financial Telecommunication (SWIFT) provides a network that enables financial institutions worldwide to send and receive information about financial transactions in a secure, standardized and reliable environment. SWIFT also markets software and services to financial institutions, much of it for use on the SWIFTNet Network, and ISO 9362 bank identifier codes (BICs) are popularly known as "SWIFT codes". • ISO 9362: 1994 Banking—Banking telecommunication messages—Bank

identifier codes • ISO 10383: 2003 Securities and related financial instruments—Codes for

exchanges and market identification (MIC) • ISO 13616: 2003 International Bank Account Number (IBAN) Registry • ISO 15022: 1999 Securities—Scheme for messages (Data Field Dictionary)

(replaces ISO 7775) • ISO 20022-1: 2004 and ISO 20022-2:2007 Financial services—UNIversal

Financial Industry message scheme ISO 9000 family of Quality management systems.

See also ISO 26000 on social responsibility; ISO 14000 series on sustainability. ▪ ISO 9000:2005 - covers the basic concepts and language ▪ ISO 9001:2008 - sets out the requirements of a quality management system ▪ ISO 9004:2009 - focuses on how to make a quality management system

more efficient and effective ISO 9241:2006 Ergonomics of Human System Interaction

A revision of the original 9241:1997, and extended. It is a multi-part standard, with the following numbered sections: ▪ 100 series: Software ergonomics ▪ 200 series: Human system interaction processes ▪ 300 series: Displays and display related hardware ▪ 400 series: Physical input devices - ergonomics principles ▪ 500 series: Workplace ergonomics


http://en.wikipedia.org/wiki/Software

http://en.wikipedia.org/wiki/ISO_9362




http://en.wikipedia.org/wiki/IBAN



▪ 600 series: Environment ergonomics ▪ 700 series: Application domains - Control rooms ▪ 900 series: Tactile and haptic interactions Of particular interest from the SoS perspective is ISO 9241-210:2010 Human-centred design for interactive systems. Its focus is on computer-based systems.

ISO 9735:1988 Electronic data interchange for administration, commerce, and transport (EDIFACT) Application level syntax rules (amended 1990, 1992). In use world-wide outside North America

ISO/IEC 9945:2009 Information technology -- Portable Operating System Interface

(POSIX®) Base Specifications, Issue 7 Defines a standard operating system interface and environment, including a command interpreter (or "shell"), and common utility programs to support applications portability at the source code level. ISO/IEC/IEEE 9945:2008 is intended to be used by both application developers and system implementers.

ISO 10006:2003, Quality management systems - Guidelines for quality management

in projects Guidance on the application of quality management in projects. It is applicable to projects of varying complexity, small or large, of short or long duration, in different environments, and irrespective of the kind of product or process involved. This can necessitate some tailoring of the guidance to suit a particular project. ISO 10006:2003 is not a guide to "project management" itself. Guidance on quality in project management processes is discussed in this International Standard. Guidance on quality in a project's product-related processes, and on the "process approach", is covered in ISO 9004. A new "Project Management - Guide to project Management" ISO 21500 has been published in september 2012. Since ISO 10006:2003 is a guidance document, it is not intended to be used for certification/registration purposes.

ISO/IEC 10021:1990 Information technology - message handling systems (MHS)

ISO/IEC JTC 1/SC 18 A family of standards for message handling.

ISO 10075 Ergonomic principles related to mental workload This is a multi -part standard concerned with cognitive load, for example as experienced by operators in control rooms, drivers, and decision-makers in general. • ISO 10075-1:2000 General terms and definitions • ISO 10075-3:2004 establishes principles and requirements for the

measurement and assessment of mental workload and specifies the requirements for measurement instruments.

• ISO 10075-3:2004 provides information for choosing appropriate methods and provides information on aspects of assessing and measuring mental workload to improve communication among the parties involved.



ISO 10303:2010 Standard for the exchange of product model data (STEP).

Maintained by ISO/TC184. Has a huge number of Application Protocols, for different classes of device, so that if you use APx, then all others in that class can exchange files.

ISO 10667 Assessment service delivery — Procedures and methods to assess

people in work and organizational settings This wide-ranging standard covers workplace assessments from appraisals and coaching through psychological tests. The standard includes knowledge and skill quizzes, tests and exams in recruitment, training and compliance. The standard applies across the employment lifecycle including recruitment, personal development and selection for promotion; it includes assessments in all kinds of mediums – for instance verbal, paper and online. Typical users of the standard will be companies and government organizations that assess their employees, as well as service providers to these organizations. ISO 10667-1:2011 establishes requirements and guidance for the client working with the service provider to carry out the assessment of an individual, a group, or an organization for work-related purposes. ISO 10667-1:2011 enables the client to base its decisions on sound assessment results. It also specifies assessment methods and procedures that can be carried out for various work-related purposes made by or affecting individuals, groups or organizations. ISO 10667-2:2011 covers the requirements for service providers.

ISO 10746:1966 Reference model for Open Distributed Processing (RM-ODP)

RM-ODP consists of four basic ITU-T Recommendations and ISO/IEC International Standards: ▪ Overview (ISO/IEC 10746-1 | ITU-T Rec. X.901): Contains a motivational

overview of ODP, giving scoping, justification and explanation of key concepts, and an outline of the ODP architecture

▪ Foundations (ISO/IEC 10746-2 | ITU-T Rec. X.902): Contains the definition of the concepts and analytical framework for normalized description of (arbitrary) distributed processing systems. It introduces the principles of conformance to ODP standards and the way in which they are applied

▪ Architecture (ISO/IEC 10746-3 | ITU-T Rec. X.903): Contains the specification of the required characteristics that qualify distributed processing as open. These are the constraints to which ODP standards must conform. It also defines RM-ODP viewpoints, subdivisions of the specification of a whole system, established to bring together those particular pieces of information relevant to some particular area of concern.

▪ Architectural Semantics (ISO/IEC 10746-4 | ITU-T Rec. X.904): Contains a formalization of the ODP modeling concepts by interpreting each concept in terms of the constructs of the different standardized formal description techniques.

ISO 11064:2000 Ergonomic design of control centres

This standard covers design of control rooms, consoles, displays, controls, workstations, etc. Relevant to distributed control of processes, etc.

ISO/IEC 11581:2000 Information technology – User system interfaces and symbols

- Icon symbols and functions Release Date: 15 July 2013 © Loughborough University Page | 167

Developed by ISO/IEC JTC1/SC18/WG9, and being updated – new part 1 issued in 2011, shortly to come into effect; old part 1being merged into part 10.

ISO 11898 Road vehicles -- Controller area network (CAN)

ISO 11898-1:2003 specifies the data link layer (DLL) and physical signalling of the controller area network (CAN). This document describes the general architecture of CAN in terms of hierarchical layers according to the ISO reference model for open systems interconnection (OSI) established in ISO/IEC 7498-1 and provides the characteristics for setting up an interchange of digital information between modules implementing the CAN DLL with detailed specification of the logical link control (LLC) sublayer and medium access control (MAC) sublayer.

ISO 11898-2:2003 specifies the high-speed (transmission rates of up to 1 Mbit/s) medium access unit (MAU), and some medium dependent interface (MDI) features (according to ISO 8802-3), which comprise the physical layer of the controller area network.

ISO 11898-3:2006 specifies low-speed, fault-tolerant, medium-dependent interface for setting up an interchange of digital information between electronic control units of road vehicles equipped with the CAN at transmission rates above 40 kBit/s up to 125 kBit/s.

ISO 11898-4:2004 specifies time-triggered communication in the CAN. It is applicable to setting up a time-triggered interchange of digital information between electronic control units (ECU) of road vehicles equipped with CAN, and specifies the frame synchronisation entity that coordinates the operation of both logical link and media access controls in accordance with ISO 11898-1, to provide the time-triggered communication schedule.

ISO 11898-5:2007 specifies the CAN physical layer for transmission rates up to 1Mbit/s for use within road vehicles. It describes the medium access unit functions as well as some medium dependent interface features according to ISO 8802-2. This represents an extension of ISO 11898-2, dealing with new functionality for systems requiring low-power consumption features while there is no active bus communication.

ISO/TR 12100:1992 Safety of machinery - basic concepts, general principles for

design. Relevant to positioning of equipment, access for first-line maintenance, etc. Replaced earlier machinery safety standards. TC 199

ISO 12207:2008 Systems and software engineering - software lifecycle processes.

See also ISO 15288 System lifecycle processes, ISO/IEC 19760 Systems engineering guide, and ISO/IEC TR 24748 Systems and software lifecycles. Latter is a harmonisation standard intended to replace this one. ISO/IEC 12207:2008 establishes a common framework for software life cycle processes, with well-defined terminology, that can be referenced by the software industry. It contains processes, activities, and tasks that are to be applied during the


http://en.wikipedia.org/wiki/Data_Link_Layer

http://en.wikipedia.org/wiki/Signaling_(telecommunications)

http://en.wikipedia.org/wiki/Controller_Area_Network

http://en.wikipedia.org/wiki/OSI_model




http://en.wikipedia.org/wiki/Logical_Link_Control

http://en.wikipedia.org/wiki/Medium_Access_Control

http://en.wikipedia.org/wiki/Medium_Access_Control

acquisition of a software product or service and during the supply, development, operation, maintenance and disposal of software products. Software includes the software portion of firmware.

ISO/AWI 37101 Sustainable development and resilience of communities --

Management systems -- General principles and requirements Standard under development in ISO committee TC 268

ISO/DIS 37120 Sustainable development and resilience of communities --

Indicators for city services and quality of life Standard under development in ISO committee TC 268

ISO 14000 (family of Environmental management standards)

There is a long list of these. See also ISO 19011, ISO 9000 series. Helps organisations to demonstrate ‘due diligence’ in environmental, health and safety considerations.

ISO 14040:2006Environmental management. Life cycle assessment. Principles and framework specifies the requirements and the procedures necessary for the compilation and preparation of the definition of goal and scope for a LCA, and for performing, interpreting and reporting a Life Cycle Inventory analysis (LCI). ISO/TR 14105:2011 Document management -- Change management for successful

electronic document management system (EDMS) implementation ISO/TC 159; also CEN/TC 122. ISO/TR 14105:2011 provides a framework for understanding the basic issues and concepts of organizational and human factors associated with implementing EDMS technologies. It describes the principles of human factors and ergonomics in their application to usability criteria for the planning and implementation of EDMS technologies, to environmental and implementation issues, and to training for long-term productivity benefits.

ISO FDIS 14258:1998 Industrial automation systems - concepts and rules for

enterprise models. See also ISO TR 10314, CEN ENV 40003, ISO DIS 15704. Defines elements, concepts, and how these relate to model enterprises. Offers guidelines to relate real world to enterprise models - equivalent to CEN ENV 40003. Not having a happy gestation. Defines concepts and rules for enterprise models (see clause 3) with the intent to guide and constrain other standards or implementations that do or will exist on the topic. It accomplishes this by defining the elements to use when producing an enterprise model (see 3.2), concepts for life-cycle phases (see 3.3), and how these models describe hierarchy (see 3.4), structure (see 3.5), and behavior (see 3.6). The International Standard provides guidelines and constraints for enterprise models to anyone attempting to model an enterprise or to model processes (see 3.7).

ISO 14764:2006 information technology - Software lifecycle processes - maintenance ISOIEC JTC 1. ISO/IEC 14764:2006 describes in greater detail management of the Maintenance Process described in ISO/IEC 12207, including Amendments. It also establishes definitions for the various types of maintenance. ISO/IEC


14764:2006 provides guidance that applies to planning, execution and control, review and evaluation, and closure of the Maintenance Process. The scope of ISO/IEC 14764:2006 includes maintenance for multiple software products with the same maintenance resources. "Maintenance" in ISO/IEC 14764:2006 means software maintenance unless otherwise stated. ISO/IEC 14764:2006 provides the framework within which generic and specific software maintenance plans may be executed, evaluated, and tailored to the maintenance scope and magnitude of given software products. It provides the framework, precise terminology and processes to allow the consistent application of technology (tools, techniques and methods) to software maintenance.

ISO/IEC FDIS 14753:1999 Information technology - open distributed processing -

interface references and binding ISOTC159/SC4. Part of the RM-ODP. Defines the interfaces to enable document transfers..

ISO/IEC 14756:1999 Information technology - Measurement and rating of

performance of computer-based software systems ISO/IEC JTC 1/SC 7. This deals with precise measurement of system performance dealing with execution time, throughput and timeliness. This relates to some of the ISO/IEC 9126 external metrics.

ISO/IEC 14764:2006 Software Engineering -- Software Life Cycle Processes –

Maintenance ISO/IEC 14764:2006 describes in greater detail management of the Maintenance Process described in ISO/IEC 12207, including Amendments. It also establishes definitions for the various types of maintenance. ISO/IEC 14764:2006 provides guidance that applies to planning, execution and control, review and evaluation, and closure of the Maintenance Process. The scope of ISO/IEC 14764:2006 includes maintenance for multiple software products with the same maintenance resources. "Maintenance" in ISO/IEC 14764:2006 means software maintenance unless otherwise stated.

ISO/IEC 15026-2:2011 Systems and Software Engineering--Systems and Software

Assurance--Part 2: Assurance Case Specifies minimum requirements for the structure and contents of an assurance case to improve the consistency and comparability of assurance cases and to facilitate stakeholder communications, engineering decisions, and other uses of assurance cases. An assurance case includes a top-level claim for a property of a system or product (or set of claims), systematic argumentation regarding this claim, and the evidence and explicit assumptions that underlie this argumentation. Arguing through multiple levels of subordinate claims, this structured argumentation connects the top-level claim to the evidence and assumptions. Assurance cases are generally developed to support claims in areas such as safety, reliability, maintainability, human factors, operability, and security, although these assurance cases are often called by more specific names, e.g. safety case or reliability and maintainability (R&M) case. ISO/IEC 15026-2:2011 does not place requirements on the quality of the contents of an assurance case and does not require the use of a particular terminology or graphical representation. Likewise, it places no requirements on the means of physical implementation of the data, including no requirements for redundancy


or co-location. ISO/IEC 15288: 2008 Life cycle management - system life cycle processes

ISO/IEC JTC 1/SC 7/WG 7 See also ISO 9001, ISO/IEC 12207 and ISO/IEC TR 24748 Latter is a harmonisation standard intended to replace this one. ISO/IEC 15288:2008 establishes a common framework for describing the life cycle of systems created by humans. It defines a set of processes and associated terminology. These processes can be applied at any level in the hierarchy of a system's structure. Selected sets of these processes can be applied throughout the life cycle for managing and performing the stages of a system's life cycle. This is accomplished through the involvement of all interested parties, with the ultimate goal of achieving customer satisfaction.

ISO/IEC 15504 Information technology – process assessment

See also ISO/IEC TR 20000-4:2010. The ISO/IEC 15504 standard for Information technology, also known as SPICE (Software Process Improvement and Capability Determination) describes a generic framework for software process assessment. It has 4 parts: ISO/IEC 15504-1:2004 — Part 1: Concepts and vocabulary ISO/IEC 15504-2:2003 — Part 2: Performing an assessment ISO/IEC 15504-3:2004 — Part 3: Guidance on performing an assessment ISO/IEC 15504-4:2004 — Part 4: Guidance on use for process improvement and process capability determination ISO/IEC TR 15504-5:2012 — Part 5: An exemplar system life cycle process assessment model.

ISO 15704:2000 Requirements for enterprise - Reference Architectures and

methodologies Positions Reference Architectures in relation to each other - ARIS, CIM-OSA, GRAI/GIM, IEM, PERA, ENV 40003.

ISO/IEC 16085:2006 Systems and software engineering -- Life cycle processes --

Risk management ISO/IEC 16085:2006 defines a process for the management of risk in the life cycle. It can be added to the existing set of system and software life cycle processes defined by ISO/IEC 15288 and ISO/IEC 12207, or it can be used independently. ISO/IEC 16085:2006 can be applied equally to systems and software. Risk management is a key discipline for making effective decisions and communicating the results within organizations. The purpose of risk management is to identify potential managerial and technical problems before they occur so that actions can be taken that reduce or eliminate the probability and/or impact of these problems should they occur. It is a critical tool for continuously determining the feasibility of project plans, for improving the search for and identification of potential problems that can affect life cycle activities and the quality and performance of products, and for improving the active management of projects.

ISO/IEC DTR 16337 Systems Engineering -- Systems Engineering Handbook

Under development. Will provide guidance on system lifecycle processes and activities.

ISO/IEC TR 18018:2010 Information technology -- Systems and software


engineering -- Guide for configuration management tool capabilities Configuration management (CM) is a process central to the software engineering life cycle. CM has been established as an ISO/IEC standard life cycle process in ISO/IEC 12207:2008, Information technology — Software life cycle processes and ISO/IEC 15288: 2008, Information technology — System life cycle processes. ISO/IEC 12207:2008 and ISO/IEC 15288:2008 describe a comprehensive set of processes, activities and tasks to be performed when acquiring or developing software. However, these documents do not address the capabilities that a CM tool user can expect from a tool in order to support the CM process and other software engineering life cycle activities. There is a gap between CM process descriptions and corresponding CM process automation services which affects both tool users and tool suppliers. ISO/IEC TR 18018:2010 provides guidance in the evaluation and selection for CM tools during acquisition. CM tool evaluation by prospective users can be complex, time consuming, and expensive. ISO/IEC TR 18018:2010 helps to characterize what a CM tool can and cannot do in the CM process. ISO/IEC TR 18018:2010 provides guidance for tool manufacturers in implementing a minimum set of capabilities. The capabilities defined in ISO/IEC TR 18018:2010 are linked to ISO/IEC 12207:2008 and ISO/IEC 15288:2008, and will provide tool manufacturers with guidance on the characteristics their tools should support to meet these International Standards.

ISO 18185 Radiofrequency communication protocol for electronic seal for freight

containers Specifies a RF communication protocol between an electronic seal and its reader, in order to secure goods transported in containers, both to prevent theft and device insertion.

ISO TR 18529:2000 Ergonomics – Ergonomics of human system interaction –

human-centred lifecycle process descriptions ISO/IEC JTC1/SC 35. defines a “Usability Maturity Model”, a set of practices in the design lifecycle to be human-centered and involve appropriate evaluation. The standard defines individual components within these primary steps: • ensure human-centered design content in system strategy • plan and manage the human-centered design process • specify the stakeholder and organizational requirements • understand and specify the context of use • produce design solutions • evaluate designs against requirements • introduce and operate the system

ISO 19011:2002 Guidelines for quality and/or environmental management systems

auditing This standard provides specific guidance on internal and external management system audits.

ISO/IEC TR 19760:2003 Systems engineering -- A guide for the application of

ISO/IEC 15288 (System life cycle processes) This standard has been revised by: ISO/IEC TR 24748-2:2011. ISO/IEC

TR 19760:2003 is a Technical Report that provides guidance for application of the International Standard ISO/IEC 15288 Systems Engineering - System life


http://www.porttechnology.org/search/results/search&keywords=%22Electronic%20Seal%22

http://www.porttechnology.org/search/results/search&keywords=%22Electronic%20Seal%22

http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=54994

cycle processes in regard to systems and projects irrespective of size and type. ISO/IEC TR 19760:2003 can be used as a companion document to the International Standard by those who: • apply the International Standard within their organization • use the International Standard in regard to a specific system; • prepare organizational and domain specific standards based on the

International Standard. ISO/IEC 20000 Information technology -- Service management

ISO/IEC 20000 is the international standard for service management. Part 1 of the ISO/IEC 20000 standard lays out a specification for a service management system (SMS). Part 2 provides guidance on SMS implementation.

ISO 22301:2012Societal security -- Business continuity management systems ---

Requirements ISO 22301:2012 specifies requirements to plan, establish, implement, operate, monitor, review, maintain and continually improve a documented management system to protect against, reduce the likelihood of occurrence, prepare for, respond to, and recover from disruptive incidents when they arise. The requirements specified in ISO 22301:2012 are generic and intended to be applicable to all organizations, or parts thereof, regardless of type, size and nature of the organization. The extent of application of these requirements depends on the organization's operating environment and complexity.

ISO 22311:2012 Societal security -- Video-surveillance -- Export interoperability ISO 22311:2012 is mainly for societal security purposes and specifies a common output file format that can be extracted from the video-surveillance contents collection systems (stand alone machines or large scale systems) by an exchangeable data storage media or through a network to allow end-users to access digital video-surveillance contents and perform their necessary processing.

ISO 22313:2012 Societal security -- Business continuity management systems –

Guidance ISO 22313:2012 for business continuity management systems provides guidance based on good international practice for planning, establishing, implementing, operating, monitoring, reviewing, maintaining and continually improving a documented management system that enables organizations to prepare for, respond to and recover from disruptive incidents when they arise.

ISO/NP 22316 Societal security -- Organizational resilience -- Principles and

guidelines This standard is still under development. It is at the evaluation stage.

ISO 22320:2011 Societal security -- Emergency management -- Requirements for

incident response ISO 22320:2011 specifies the requirements for incident response, it covers command and control, operational information, coordination and cooperation within an incident response organisation. Coverage includes: • Command and control organisational structures and procedures • Decision support


• Traceability • Information management and interoperability The standard establishes requirements for operational information for incident response which specifies processes, systems of work, data capture and management in order to produce timely, relevant and accurate information. It supports the process of command and control as well as coordination and cooperation, internally within the organisation and externally with other involved parties, and specifies requirements for coordination and cooperation between organisations.

ISO/WD 22321 Essential information and data requirements for command and

control This standard is under development. Some important points: • An organization may be aware of the command and control necessary in the

handling of danger but there must also be emphasis on the cooperation and coordination among the organizations that hold command and control,

• Command and control is based on hierarchy, while cooperation and coordination between the horizontal across the organizations involved.

• The flow of information (submitted by whom, to do what, and received by whom) must be clear.

• Although an hierarchical organization will have organised command and control to address dangers, they will still be supported by external organizations. Hence, plans for the necessary cooperation and coordination must exist.

ISO/DIS 22322 Societal security -- Emergency management -- Public warning

Under development. ISO/DIS 22397 Societal security -- Guidelines for establishing partnering

arrangements Under development. Includes Public Private Partnerships

ISO/PAS 22399:20007 Guideline on Incident Preparedness & Operational Continuity Management (IPOCM) ISO/PAS 22399:2007 provides general guidance for an organization — private, governmental, and nongovernmental organizations — to develop its own specific performance criteria for incident preparedness and operational continuity, and design an appropriate management system. It provides a basis for understanding, developing, and implementing continuity of operations and services within an organization and to provide confidence in business, community, customer, first responder, and organizational interactions. It also enables the organization to measure its resilience in a consistent and recognized manner. ISO/PAS 22399:2007 is applicable to all sizes of public or private organizations engaged in providing products, processes, or services that wishes to: • understand the overall context within which the organization operates; • identify critical objectives; • understand barriers, risks, and disruptions that may impede critical

objectives; • evaluate residual risk and risk tolerance to understand outcomes of controls

and mitigation strategies; • plan how an organization can continue to achieve its objectives should a


disruptive incident occur; • develop incident and emergency response, continuity response and

recovery response procedures; • define roles and responsibilities, and resources to respond to an incident; • meet compliance with applicable legal, regulatory, and other requirements; • provide mutual and community assistance; • interface with first responders and the media; • promote a cultural change within the organization that recognizes that risk is

inherent in every decision and activity and must be effectively managed. ISO/PAS 22399:2007 presents the general principles and elements for incident preparedness and operational continuity of an organization.. ISO/PAS 22399:2007, however, excludes specific emergency response activities following an incident, such as disaster relief and social infrastructure recovery that are primarily to be performed by the public sector in accordance with relevant legislation. It is important, however, that coordination with these activities be maintained and documented.

ISO/IEC TR 24774:2010 Systems and Software Engineering-- Life Cycle

Management--Guidelines for Process Description An increasing number of international, national and industry standards describe process models. These models are developed for a range of purposes including process implementation and assessment. The terms and descriptions used in such models vary in format, content and level of prescription. ISO/IEC TR 24774:2010 presents guidelines for the elements used most frequently in describing a process: the title, purpose, outcomes, activities, task and information item. Whilst the primary purpose of ISO/IEC TR 24774:2010 is to encourage consistency in standard process reference models, the guidelines it provides can be applied to any process model developed for any purpose.

ISO/IEC TR 24748 Systems and software engineering -- Life cycle management Part 1: Guide for life cycle management provides information on life cycle concepts and descriptions of the purposes and outcomes of representative life cycle stages. It also illustrates the use of a life cycle model for systems in the context of ISO/IEC 15288 and provides a corresponding illustration of the use of a life cycle model for software in the context of ISO/IEC 12207. ISO/IEC TR 24748-1:2010 additionally provides detailed discussion and advice on adapting a life cycle model for use in a specific project and organizational environment. It further provides guidance on life cycle model use by domains, disciplines and specialties. It also gives a detailed comparison between prior and current versions of ISO/IEC 12207 and ISO/IEC 15288, as well as advice on transitioning from prior to current versions and on using their application guides. The discussion and advice are intended to provide a reference model for life cycle models, facilitate use of the updated ISO/IEC 15288 and ISO/IEC 12207, and provide a framework for the development of updated application guides for those International Standards. ISO/IEC TR 24748-1:2010 is a result of the alignment stage of the harmonization of ISO/IEC 12207 and ISO/IEC 15288. Part 2 Guide to the application of ISO/IEC 15288 (System life cycle processes): is a guide for the application of ISO/IEC 15288:2008. It addresses system, life cycle, process, organizational, project, and adaptation concepts, principally through reference to ISO/IEC TR 24748-1 and ISO/IEC 15288:2008. It then gives guidance on applying ISO/IEC 15288:2008 from the aspects of


strategy, planning, application in organizations, and application on projects. It is intentionally aligned with both ISO/IEC TR 24748-1 and ISO/IEC TR 24748-3 (Guide to the application of ISO/IEC 12207) in its terminology, structure and content. Part 3: Guide to the application of ISO/IEC 12207 (Software life cycle processes) is a guide for the application of ISO/IEC 12207:2008. It addresses system, life cycle, process, organizational, project, and adaptation concepts, principally through reference to ISO/IEC TR 24748-1 and ISO/IEC 12207:2008. It gives guidance on applying ISO/IEC 12207:2008 from the aspects of strategy, planning, application in organizations, and application on projects. ISO/IEC TR 24748-3:2011 is intentionally aligned with both ISO/IEC TR 24748-1 and ISO/IEC TR 24748-2 (Guide to the application of ISO/IEC 15288) in its terminology, structure and content.

ISO/IEC 24765-2010 Systems and software engineering -- Vocabulary Provides a common vocabulary applicable to all systems and software engineering work. It was prepared to collect and standardize terminology. ISO/IEC 24765:2010 is intended to serve as a useful reference for those in the information technology field, and to encourage the use of systems and software engineering standards prepared by ISO and liaison organizations IEEE Computer Society and Project Management Institute. ISO/IEC 24765:2010 includes references to the active source standards for each definition so that the use of the term can be further explored

ISO/IEC 25010:2011 Systems and software engineering -- Systems and software

Quality Requirements and Evaluation (SQuaRE) -- System and software quality models Replaces ISO 9126 & ISO 14598. Covers: • A quality in use model composed of five characteristics (some of which are

further subdivided into subcharacteristics) that relate to the outcome of interaction when a product is used in a particular context of use. This system model is applicable to the complete human-computer system, including both computer systems in use and software products in use.

• A product quality model composed of eight characteristics (which are further subdivided into subcharacteristics) that relate to static properties of software and dynamic properties of the computer system. The model is applicable to both computer systems and software products.

ISO 26000:2010 Guidance on social responsibility Among other issues, ISO 26000:2010 addresses corruption and bribery within and by the organisation, albeit only via general principles. It serves as a background document, underpinning other standards such as the ISO 9000, ISO 14000 series. It provides guidance to all types of organizations, regardless of their size or location, on: • concepts, terms and definitions related to social responsibility; • the background, trends and characteristics of social responsibility; • principles and practices relating to social responsibility; • the core subjects and issues of social responsibility; • integrating, implementing and promoting socially responsible behaviour

throughout the organization and, through its policies and practices, within its sphere of influence;

• identifying and engaging with stakeholders; and


• communicating commitments, performance and other information related to social responsibility.

ISO 26000:2010 is intended to assist organizations in contributing to sustainable development. It is intended to encourage them to go beyond legal compliance, recognizing that compliance with law is a fundamental duty of any organization and an essential part of their social responsibility. It is intended to promote common understanding in the field of social responsibility, and to complement other instruments and initiatives for social responsibility, not to replace them. In applying ISO 26000:2010, it is advisable that an organization take into consideration societal, environmental, legal, cultural, political and organizational diversity, as well as differences in economic conditions, while being consistent with international norms of behaviour.

ISO/IEC 26512:2011 Systems and software engineering -- Requirements for acquirers and suppliers of user documentation ISO/IEC 26512:2011 was developed to assist users of ISO/IEC 15288:2008 or ISO/IEC 12207:2008 to acquire or supply software user documentation as part of the software life cycle processes, particularly in agile environments. It defines the documentation process from the acquirer's standpoint and the supplier's standpoint. ISO/IEC 26512:2011 covers the requirements for information items used in the acquisition of user documentation products: the Acquisition Plan, Document Specification, Statement of Work, Request for Proposals, and the proposal. It provides an overview of the software user documentation and information management processes which may require acquisition and supply of software user documentation products and services. It addresses the preparation of requirements for software user documentation. These requirements are central to the user documentation specification and Statement of Work. It includes requirements for primary document outputs of the acquisition and supply process: the Request for Proposal and the Proposal for user documentation products and services. It also discusses the use of a Documentation Management Plan and a Document Plan as they arise in the acquisition and supply processes. ISO/IEC 26512:2011 is independent of the software tools that may be used to produce documentation, and applies to both printed documentation and on-screen documentation. Much of its guidance is applicable to user documentation for systems including hardware as well as software.

ISO/IEC 26702:2007 Systems engineering -- Application and management of the systems engineering process See also ISO/IEC 15288:2008. ISO/IEC 26702:2007defines the interdisciplinary tasks which are required throughout a system's life cycle to transform customer needs, requirements and constraints into a system solution. In addition, it specifies the requirements for the systems engineering process and its application throughout the product life cycle. ISO/IEC 26702:2007 focuses on engineering activities necessary to guide product development, while ensuring that the product is properly designed to make it affordable to produce, own, operate, maintain and eventually dispose of without undue risk to health or the environment.

ISO 26800:2011 Ergonomics -- General approach, principles and concepts

ISO 26800:2011 presents the general ergonomics approach and specifies basic


ergonomics principles and concepts. These are applicable to the design and evaluation of tasks, jobs, products, tools, equipment, systems, organizations, services, facilities and environments, in order to make them compatible with the characteristics, the needs and values, and the abilities and limitations of people. The provisions and guidance given by ISO 26800:2011 are intended to improve the safety, performance, effectiveness, efficiency, reliability, availability and maintainability of the design outcome throughout its life cycle, while safeguarding and enhancing the health, well-being and satisfaction of those involved or affected. The intended users of ISO 26800:2011 are designers, ergonomists and project managers, as well as managers, workers, consumers (or their representatives) and procurers. It also serves as a reference standard for standards developers dealing with ergonomics aspects.

ISO/IEC 27001:2005 Information technology -- Security techniques -- Information

security management systems – Requirements ISO/IEC 27001 is in the process of being revised. The standard, initially published in 2005, will be updated to address relevant issues and challenges which are faced by companies today. ISO/IEC 27001:2005 covers all types of organizations (e.g. commercial enterprises, government agencies, not-for profit organizations). It specifies the requirements for establishing, implementing, operating, monitoring, reviewing, maintaining and improving a documented Information Security Management System within the context of the organization's overall business risks. It specifies requirements for the implementation of security controls customized to the needs of individual organizations or parts thereof.ISO27001, together with the Code of Practice, ISO27002, provides an internationally recognised best-practice framework for addressing the entire range of cyber risks.

ISO/IEC/IEEE 29148:2011 Systems and software engineering -- Life cycle

processes -- Requirements engineering ISO/IEC/IEEE 29148:2011 contains provisions for the processes and products related to the engineering of requirements for systems and software products and services throughout the life cycle. It defines the construct of a good requirement, provides attributes and characteristics of requirements, and discusses the iterative and recursive application of requirements processes throughout the life cycle. ISO/IEC/IEEE 29148:2011 provides additional guidance in the application of requirements engineering and management processes for requirements-related activities in ISO/IEC 12207:2008 and ISO/IEC 15288:2008. Information items applicable to the engineering of requirements and their content are defined. The content of ISO/IEC/IEEE 29148:2011 can be added to the existing set of requirements-related life cycle processes defined by ISO/IEC 12207:2008 or ISO/IEC 15288:2008, or can be used independently.

ISO 31000:2009 Risk management -- Principles and guidelines

ISO 31000:2009 provides principles and generic guidelines on risk management. It can be applied throughout the life of an organization, and to a wide range of activities, including strategies and decisions, operations, processes, functions, projects, products, services and assets. ISO 31000:2009 can be applied to any type of risk, whatever its nature, whether having positive or negative consequences. It is intended that ISO 31000:2009


http://www.itgovernance.co.uk/iso27001.aspx

be utilized to harmonize risk management processes in existing and future standards.

ISO/IEC 38500 - International Standard for Corporate Governance of IT (IT

Governance) ISO38500 is the international standard for the corporate governance of information technology.ISO/IEC 38500 provides guidance to those advising, informing or assisting directors on the effective and acceptable use of Information Technology (IT) within the organisation.

ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture

description ISO/IEC/IEEE 42010:2011 replaces both ISO/IEC 42010:2007 and IEEE Std 1471:2000. The original IEEE 1471 specified requirements on the contents of architecture descriptions of systems. An architecture description (AD) expresses the architecture of a system of interest. An AD could be a document, a repository or a collection of artifacts used to define and document an architecture. ISO/IEC/IEEE 42010 adds definitions and requirements on architecture frameworks and architecture description languages (ADLs) as conformance cases. The focus of the Standard is on three classes of systems: software-intensive systems are systems in which software development and/or integration are dominant considerations (i.e., most complex systems these days). This includes computer-based systems ranging from individual software applications, information systems, embedded systems, software product lines and product families and systems-of-systems; general systems as defined in ISO/IEC 15288, Systems and software engineering — Systems life cycle processes; and software products and services as defined in ISO/IEC 12207, Systems and software engineering — Software life cycle processes.

ISO/DIS 55000 Asset management -- Overview, principles and terminology

The ISO 55000 series will comprise three standards: • ISO 55000 provides an overview of the subject of asset management and

the standard terms and definitions to be used. • ISO 55001 is the requirements specification for an integrated, effective

management system for assets. Note: 55001 defines requirements for a management system, in the same way as ISO 9001 specifies a quality management system, and ISO 14001 covers an environmental management system. ISO 55001 is not, therefore, a specification for an asset information management system (sometimes called "enterprise asset management" system). Such software systems are, however, recognised to be useful aids ('enablers') for good asset management.

• IS0 55002 provides guidance for the implementation of such a system.

CEN/CENELEC standards

EN 614:2006+A1:2009 Safety of machinery - ergonomic design principles See also ISO 6385. CEN/TC122/WG5. There is a long list of stds that put into effect EN 292 above. This is one of them; more will be found at: http://ec.europa.eu/enterprise/sectors/mechanical/files/machinery/guidance-



ergonomics_en.pdf.

IEC standards

IEC 61508:1998, Functional safety of Electrical/Electronic/Programmable Electronic safety-related systems Just covers the technical aspects. It covers possible hazards caused by failure of the safety functions to be performed by the E/E/PE safety-related systems (including lifecycle aspects), as distinct from hazards arising from the E/E/PE equipment itself (for example electric shock etc). It is generically based and applicable to all E/E/PE safety-related systems irrespective of the application. Can be used as a stand-alone exercise; however, Application Sector Standards are being written to cover industrial domains; e.g. IEC 61513, Nuclear power plants - Instrumentation and control for systems important to safety - General requirements for systems, was published in March 2001. Other application sector standards in development are IEC 61511 for the process sector and IEC 62061 for the machinery sector Codes of practice being generated. Note that control systems feature COTS core software that tends to comply with this standard, and plant-specific data that tends not to comply with this standard.

IEC 61511:1998, Functional safety of Electrical/ Electronic/ Programmable Electronic

safety-related systems IEC 61508 is intended to be a basic functional safety standard applicable to all kinds of industry. It defines functional safety as: “part of the overall safety relating to the EUC (Equipment Under Control) and the EUC control system which depends on the correct functioning of the E/E/PE safety-related systems, other technology safety-related systems and external risk reduction facilities.”

The standard covers the complete safety life cycle, and may need interpretation to develop sector specific standards. It has its origins in the process control industry.

ITU-T standards

X.400 standards are used in various parts of the globe, but SMTP is equivalent and more widely used in the EU and North America.

▪ ITU-T Rec. F.400/X.400 |ISO/IEC 10021-1 Message handling system and service overview

▪ ITU-T Rec. X.402 |ISO/IEC 10021-2 Message Handling Systems (MHS): Overall architecture

▪ ITU-T Rec. X.411 |ISO/IEC 10021-4 Message Handling Systems (MHS): Message Transfer System: Abstract Service Definition and Procedures

▪ ITU-T Rec. X.413 |ISO/IEC 10021-5 Message Handling Systems (MHS): Message store - Abstract service definition

▪ ITU-T Rec. X.419 |ISO/IEC 10021-6 Message Handling Systems (MHS): Protocol specifications

▪ ITU-T Rec. X.420 |ISO/IEC 10021-7 Message Handling Systems (MHS): Interpersonal Messaging System

▪ ITU-T Rec. X.435 |ISO/IEC 10021-9 Message Handling Systems (MHS): Electronic


http://en.wikipedia.org/wiki/Safety_life_cycle

http://www.itu.int/rec/T-REC-F.400-199906-I/en

http://www.itu.int/rec/T-REC-F.400-199906-I/en

http://www.itu.int/rec/T-REC-X.402-199906-I/en











data interchange messaging system ▪ ITU-T Rec. X.412 |ISO/IEC 10021-10 Message Handling Systems (MHS): MHS

routing ▪ ITU-T Rec. X.404 |ISO/IEC 10021-11 Message Handling Systems (MHS): MHS

routing - Guide for messaging systems managers

Transmission Control Protocol (TCP) and Internet Protocol (IP) TCP/IP provides end-to-end connectivity specifying how data should be formatted, addressed, transmitted, routed and received at the destination. It has four abstraction layers which are used to sort all Internet protocols according to the scope of networking involved.[1][2] From lowest to highest, the layers are:

▪ The link layer contains communication technologies for a local network. ▪ The internet layer (IP) connects local networks, thus establishing internetworking. ▪ The transport layer handles host-to-host communication. ▪ The application layer contains all protocols for specific data communications

services on a process-to-process level. For example, HTTP specifies the web browser communication with a web server. The TCP/IP model and related protocols are maintained by the Internet Engineering Task Force (IETF). There are other important standards that utilise this protocol such as FTP, SMTP, and LDAP.

Semantic web. A set of standards are in development to enable a web of data, rather than a web of documents. This set are known by their abbreviations:

• RDF (Resource Description Language. RDF is a standard model for data interchange on the Web. RDF has features that facilitate data merging even if the underlying schemas differ, and it specifically supports the evolution of schemas over time without requiring all the data consumers to be changed. RDF extends the linking structure of the Web to use URIs to name the relationship between things as well as the two ends of the link (this is usually referred to as a “triple”). Using this simple model, it allows structured and semi-structured data to be mixed, exposed, and shared across different applications

• OWL (Web Ontology Language. A Semantic Web language designed to represent rich and complex knowledge about things, groups of things, and relations between things.),

• SPARQL (Query language for RDF), • RDFa, (extracts XHTML structured data from documents and presents them in

RDF format) • SKOS, (Simple Knowledge Organisation Language. The SKOS data model

provides a standard, low-cost migration path for porting existing knowledge organization systems to the Semantic Web. SKOS also provides a lightweight, intuitive language for developing and sharing new knowledge organization systems. It may be used on its own, or in combination with formal knowledge representation languages such as the Web Ontology language (OWL)

• RDFS, (RDF schemas. RDFS is a general-purpose language for representing simple RDF vocabularies on the Web. Other vocabulary definition technologies, like OWL or SKOS, build on RDFS and provide language for defining structured, Web-based ontologies which enable richer integration and interoperability of data among descriptive communities).

• GRDDL, (Gleaning Resource Descriptions from Dialects of Languages. GRDDL





http://www.itu.int/rec/T-REC-X.404-199906-I/enn

http://www.itu.int/rec/T-REC-X.404-199906-I/enn

http://en.wikipedia.org/wiki/Transmission_Control_Protocol

http://en.wikipedia.org/wiki/Internet_Protocol

http://en.wikipedia.org/wiki/Routing

http://en.wikipedia.org/wiki/Link_layer

http://en.wikipedia.org/wiki/Local_area_network

http://en.wikipedia.org/wiki/Internet_layer

http://en.wikipedia.org/wiki/Internetworking

http://en.wikipedia.org/wiki/Transport_layer

http://en.wikipedia.org/wiki/Application_layer

http://en.wikipedia.org/wiki/HTTP

http://en.wikipedia.org/wiki/Internet_Engineering_Task_Force

http://en.wikipedia.org/wiki/Internet_Engineering_Task_Force

http://www.w3.org/2001/sw/wiki/RDF

http://www.w3.org/2001/sw/wiki/OWL

http://www.w3.org/2001/sw/wiki/SPARQL

http://www.w3.org/2001/sw/wiki/RDFa

http://www.w3.org/2001/sw/wiki/SKOS


http://www.w3.org/2001/sw/wiki/RDFS


http://www.w3.org/2001/sw/wiki/SKOS

http://www.w3.org/2001/sw/wiki/GRDDL

is a technique for obtaining RDF data from XML documents and in particular XHTML pages. Authors may explicitly associate documents with transformation algorithms, typically represented in XSLT, using a link element in the head of the document. Alternatively, the information needed to obtain the transformation may be held in an associated metadata profile document or namespace document.)

• POWDER, (Protocol for Web Description Resources. It provides a mechanism to describe and discover Web resources and provides a succinct way to define any number of predicates for those resources. POWDER is designed to facilitate incorporation of information in larger RDF-based systems. There are a variety of use cases: from providing a better means to describing Web resources and creating trustmarks to aiding content discovery, child protection and Semantic Web searches, describing copyright or licensing information to a family of resources.)

• PROV, (Provenance. PROV is a specification that provides a vocabulary to interchange provenance information. Users can do so by marking up their web page using the terms provided or by making available provenance information expressed as linked data. For example, you can make explicit that you quoted another web page by using prov:wasQuotedFrom in the blockquote of your html page. No specification available, yet.)

• RIF, (Rule Interchange Format. The goal of RIF is to define a standard for exchanging rules among rule systems, in particular among Web rule engines. RIF focuses on exchange; in contrast to other Semantic Web standards, such as RDF, OWL, and SPARQL, it was immediately clear that a sngle language would not cover all popular paradigms of using rules for knowledge representation and business modeling. The RIF Working Group is designing a family of languages, called dialects, with rigorously specified syntax and semantics. The family of RIF dialects is intended to be uniform and extensible.)

• SAWSDL, (Semantic Annotations for WSDL and XML Schema. It defines a set of extension attributes for the Web Services Description Language and XML Schema definition language that allows description of additional semantics of WSDL components. The specification defines how semantic annotation is accomplished using references to semantic models, e.g. ontologies. Semantic Annotations for WSDL and XML Schema (SAWSDL) does not specify a language for representing the semantic models. Instead it provides mechanisms by which concepts from the semantic models, typically defined outside the WSDL document, can be referenced from within WSDL and XML Schema components using annotations.)

• RDB2RDF. (Relational Databases to RDF. RDB2RDF comprises two Recommendations to map the content of Relational Databases to RDF. The two languages are the Direct Mapping and R2RML.They can be used to translate relational data into RDF which could be stored in a triple store. Or it could be used to generate a virtual mapping that could be queried using SPARQL and the SPARQL translated to SQL queries on the underlying relational data.)

This development work is within the World Wide Web Consortium (W3C). The output is Recommendations, to be adopted by the relevant Standards Organisations.

IEEE 802 networking standards

These are low-level standards (data transmission and physical layers of the ISO stack), restricted to networks carrying variable size packets. The table below lists the standards as of November 2012. Release Date: 15 July 2013 © Loughborough University Page | 182

http://www.w3.org/2001/sw/wiki/POWDER

http://www.w3.org/2001/sw/wiki/PROV

http://www.w3.org/2001/sw/wiki/RIF

http://www.w3.org/2001/sw/wiki/RDF


http://www.w3.org/2001/sw/wiki/SPARQL

http://www.w3.org/2001/sw/wiki/SAWSDL

http://www.w3.org/2001/sw/wiki/RDB2RDF

http://www.w3.org/2001/sw/wiki/Direct_Mapping

http://www.w3.org/2001/sw/wiki/R2RML

Name Description Note IEEE 802.1 Bridging (networking) and Network Management IEEE 802.2 LLC inactive IEEE 802.3 Ethernet IEEE 802.4 Token bus disbanded IEEE 802.5 Defines the MAC layer for a Token Ring inactive IEEE 802.6 MANs (DQDB) disbanded IEEE 802.7 Broadband LAN using Coaxial Cable disbanded IEEE 802.8 Fiber Optic TAG disbanded IEEE 802.9 Integrated Services LAN (ISLAN or isoEthernet) disbanded IEEE 802.10 Interoperable LAN Security disbanded IEEE 802.11 a/b/g/n Wireless LAN (WLAN) & Mesh (Wi-Fi certification) IEEE 802.12 100BaseVG disbanded IEEE 802.13 Unused[2] IEEE 802.14 Cable modems disbanded IEEE 802.15 Wireless PAN IEEE 802.15.1 Bluetooth certification IEEE 802.15.2 IEEE 802.15 and IEEE 802.11 coexistence IEEE 802.15.3 High-Rate wireless PAN IEEE 802.15.4 Low-Rate wireless PAN (e.g., ZigBee, WirelessHART, MiWi, etc.) IEEE 802.15.5 Mesh networking for WPAN IEEE 802.15.6 Body area network IEEE 802.16 Broadband Wireless Access (WiMAX certification) IEEE 802.16.1 Local Multipoint Distribution Service


http://en.wikipedia.org/wiki/IEEE_802.1

http://en.wikipedia.org/wiki/Network_bridge


http://en.wikipedia.org/wiki/Logical_Link_Control


http://en.wikipedia.org/wiki/Ethernet


http://en.wikipedia.org/wiki/Token_bus


http://en.wikipedia.org/wiki/Token_Ring


http://en.wikipedia.org/wiki/Metropolitan_area_network

http://en.wikipedia.org/wiki/Distributed-queue_dual-bus






http://en.wikipedia.org/wiki/Wireless_LAN

http://en.wikipedia.org/wiki/Wi-Fi

http://en.wikipedia.org/wiki/100BaseVG

http://en.wikipedia.org/wiki/Cable_modem


http://en.wikipedia.org/wiki/Wireless_PAN

http://en.wikipedia.org/wiki/IEEE_802.15.1

http://en.wikipedia.org/wiki/Bluetooth








http://en.wikipedia.org/wiki/ZigBee

http://en.wikipedia.org/wiki/WirelessHART

http://en.wikipedia.org/wiki/MiWi



http://en.wikipedia.org/wiki/Body_area_network


http://en.wikipedia.org/wiki/Broadband_Wireless_Access

http://en.wikipedia.org/wiki/WiMAX

http://en.wikipedia.org/wiki/Local_Multipoint_Distribution_Service

IEEE 802.17 Resilient packet ring IEEE 802.18 Radio Regulatory TAG IEEE 802.19 Coexistence TAG IEEE 802.20 Mobile Broadband Wireless Access IEEE 802.21 Media Independent Handoff IEEE 802.22 Wireless Regional Area Network IEEE 802.23 Emergency Services Working Group IEEE 802.24 Smart Grid TAG New (November, 2012) IEEE 802.25 Omni-Range Area Network Not yet ratified

Table 18: IEEE 802 Networking Standards (Low-level)








http://en.wikipedia.org/w/index.php?title=IEEE_802.23&action=edit&redlink=1



TAREA-PU-WP2-D-LU-9

IEEE 828-2012 Configuration Management in Systems and Software Engineering Description: This standard establishes the minimum requirements for processes for Configuration Management (CM) in systems and software engineering. The application of this standard applies to any form, class, or type of software or system. This revision of the standard expands the previous version to explain CM, including identifying and acquiring configuration items, controlling changes, reporting the status of configuration items, as well as software builds and release engineering. Its predecessor defined only the contents of a software configuration management plan. This standard addresses what CM activities are to be done, when they are to happen in the life cycle, and what planning and resources are required. It also describes the content areas for a CM Plan. The standard supports ISO/IEC/IEEE 12207:2008 and ISO/IEC/IEEE 15288:2008 and adheres to the terminology in ISO/IEC/IEEE Std 24765 and the information item requirements of IEEE Std 15939TM

IEEE 1278 Standard for Distributed Interactive Simulation This is a 4-part standard: IEEE 1278.1-2012 Application Protocols Description: Data messages, known as Protocol Data Units (PDUs), that are exchanged on a network among simulation applications are defined. These PDUs are for interactions that take place within specified domains called protocol families, which include Entity Information/Interaction, Warfare, Logistics, Simulation Management, Distributed Emission Regeneration, Radio Communications, Entity Management, Minefield, Synthetic Environment, Simulation Management with Reliability, Information Operations, Live Entity Information/Interaction, and Non-Real-Time protocol. IEEE 1278.2-1995 Communication Services and Profiles Description: Communication services to support information exchange between simulation applications participating in the distributed interactive simulation (DIS) environment are defined. These communication services describe a connectionless information transfer that supports real-time, as well as non-real-time, exchange. Several communication profiles specifying communication services are provided. IEEE 1278.3-1996 Exercise Management and Feedback Description: Guidelines are established for exercise management and feedback in distributed interactive simulation (DIS) exercises. Guidance is provided to sponsors, providers and supporters of DIS-compliant systems and exercises as well as to developers of DIS exercise management and feedback stations. The activities of the organizations involved in a DIS exercise and the top-level processes used to accomplish those activities are addressed. The functional requirements of the exercise management and feedback process are also addressed. This standard is one of a series of standards developed for DIS to assure interoperability between dissimilar simulations for currently installed and future simulations developed by different organizations. IEEE 1278.4-1997 Verification, Validation, and Accreditation Description: Guidelines are established for the verification, validation, and accreditation (VV&A) of distributed interactive simulation (DIS) exercises. "How-to" procedures for planning and conducting DIS exercise VV&A are provided. Intended for use in conjunction with IEEE Std 1278.3-1996, this recommended practice presents data flow and connectivity for all proposed verification and validation activities and provides rationale and justification for each step. VV&A guidance is provided to exercise users/sponsors and developers.

IEEE 1516-2010 Modeling and Simulation (M&S) High Level Architecture (HLA)--

Framework and Rules: This standard, describing the framework and rules of the High Level Architecture (HLA),


TAREA-PU-WP2-D-LU-9

is the capstone document for a family of related HLA standards. It defines the HLA, its components, and the rules that outline the responsibilities of HLA federates and federations to ensure a consistent implementation. Simulations are abstractions of the real world, and no one simulation can solve all of the functional needs for the modeling and simulation community. It is anticipated that technology advances will allow for new and different modeling and simulation (M&S) implementations within the framework of the HLA. The standards contained in this architecture are interrelated and need to be considered as a product set, as a change in one is likely to have an impact on the others. As such, the HLA is an integrated approach that has been developed to provide a common architecture for simulation. IEEE 1516.1-2010 - Federate Interface Specification. The High Level Architecture (HLA) has been developed to provide a common architecture for distributed modeling and simulation. The HLA defines an integrated approach that provides a common framework for the interconnection of interacting simulations. This document, the second in a family of three related HLA documents, defines the standard services of and interfaces to the HLA runtime infrastructure (RTI). These services are used by the interacting simulations to achieve a coordinated exchange of information when they participate in a distributed federation. The standards contained in this architecture are interrelated and need to be considered as a product set, when changes are made. They each have value independently. IEEE 1516.2-2010 Object Model Template (OMT) Specification Defines the format and syntax (but not content) of HLA object models. Simulations are abstractions of the real world, and no one simulation can solve all of the functional needs for the modelling and simulation community. It is anticipated that advances in technology will allow for new and different modelling and simulation (M&S) implementations within the framework of the HLA. The standards contained in this architecture are interrelated and need to be considered as a product set, as a change in one is likely to have an impact on the others. As such, the HLA is an integrated approach that has been developed to provide a common architecture for simulation. IEEE 1516.4-2007 Overlay to the High Level Architecture Federation Development and Execution Process This recommended practice defines the processes and procedures that should be followed to implement Verification, Validation, and Accreditation (VV&A) for federations being developed using the High Level Architecture (HLA) Federation Development and Execution Process (FEDEP). This recommended practice is not intended to replace existing VV&A policies, procedures and guidance, but rather is intended to focus on the unique aspects of VV&A of federations. It is a higher-level framework into which such practices can be integrated and tailored for specific uses. The VV&A Overlay provides implementation-level guidance to VV&A practitioners.

ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description

ISO/IEC/IEEE 42010:2011 replaces both ISO/IEC 42010:2007 and IEEE Std 1471:2000. The original IEEE 1471 specified requirements on the contents of architecture descriptions of systems. An architecture description (AD) expresses the architecture of a system of interest. An AD could be a document, a repository or a collection of artifacts used to define and document an architecture. ISO/IEC/IEEE 42010 adds definitions and requirements on architecture frameworks and architecture description languages (ADLs) as conformance cases.


state of the art v3

Documents