SYSTEM-OF-SYSTEMS (SOS) WORKSHOP 3 SICS & INCOSE

Transcription

1 SYSTEM-OF-SYSTEMS (SOS) WORKSHOP 3 SICS & INCOSE

2 AGENDA : Introduction Short presentation of everyone Background: The SoS Agenda project : Summary and analysis of WS1-2 + discussion : Introduction to example : Work on example : Lunch : Work on example (cont.) : Strategic research and innovation agenda introduction (Johan Schubert) : Discussion on content of SoS agenda : Summary of the WS and next steps

3 PURPOSE OF WORKSHOP Dig deeper into challenges in SoS Identify topics to include in a SoS agenda Continue to build a network of individuals interested in SoS

4 SOS AGENDA PROJECT Objective: Formulate a strategic research and innovation agenda for the area SoS Duration: Jan-June 2015 Funding: Vinnova Expected outcomes: An agenda document, with the preliminary title System-av-system för gränsöverskridande innovation i det digitala samhället: En strategisk forsknings- och innovationsagenda Side effect: creation of an expert network

5 PARTNERS SICS (project leader) Saab Aeronautics FOI Volvo Cars Volvo Technology Volvo Construction Equipment Syntell Decisionware INCOSE Sweden And everyone who is interested in joining!

6 PROJECT PARTS Actors Current status Potential and future challenges Common concerns Mainly executed as a series of workshops Research Current status in Sweden and Internationally Synthesis Identify actions Document in agenda

7 ANALYSIS OF WS1

8 WHAT IS AN SOS? And is it even a meaningful concept? Or are normal SysEng practices enough to handle them? An SoS is a system It is being composed of elements, etc. The elements are called constituent systems Implication: Generic SysEng practices should apply But not all systems are SoS Implication: Specific practices for SoSEng are required Intuitive definition of SoS = independent interacting collaborating systems ( oberoende samverkande system ) A completely precise definition is harder to give, but some characteristics can be identified

9 SOS CHARACTERISTICS Maier, 1996 Boardman & Sauser, 2005 Operational independence Managerial independence Evolutionary development Emergent behavior Geographical distribution Autonomy Belonging Connectivity Emergence Diversity Two definitions from literature, with a large overlap The first four are core, the other two maybe not? A given SoS may exhibit these characteristics in various degrees, no strict definition For example, some constituent systems may be more independent than others

10 KEY FACTORS Lifecycle Ownership Value Emergence

11 LIFECYCLE The different constituent systems have different, unsynchronized lifecycles. This means that the SoS will evolve, and changes may occur on the fundamental structure of the SoS, including which constituent systems it consists of, and what the links are between them. Consequence 1: The architecture of the SoS must be focused on being open to changes, and evolve over time to encompass new situations. The architecture of potential constituent systems also should be targeted at flexibility, in particular in its interfaces. Consequence 2: There is a need for managerial principles to ensure that the purpose of the SoS can be upheld while the system is changing. Consequence 3: The traditional project oriented management models will most likely not work. Each constituent system is subject to its own ongoing change projects, and these must interconnect with the evolution of the SoS.

12 OWNERSHIP The different constituent systems may have different owners, who are stakeholders in both their own system and in the SoS. Consequence 1: Decisions about the design of the SoS will in most cases result in negotiations across organizational borders. Solutions must be found that does not restrict the autonomy of any individual system, but still makes it possible to fulfil the purpose of the SoS. Consequence 2: The liability of the SoS is shared between the organizations behind its constituent systems.

13 VALUE In an SoS, the constituent systems do not give up their autonomy to be part of the system, but they partly modify their behavior to gain benefits. The original purposes thus remain, and can be pursued inside or outside the SoS. Consequence: There will always be a need for requirements trade-offs between the purposes of the constituent systems, and the purpose of the SoS. There must be a value created for all constituent systems, as well as for those who choose to create the SoS. The tension is both vertical (between the system level and the element level), and horizontal (there can be conflicts of interest between different constituent systems, that appear as they are brought together in the SoS).

14 EMERGENCE The purpose of the SoS is fulfilled by the emergent behavior and properties resulting from letting the constituent systems interact. Consequence: There is a need to understand principles for controlling the constituent systems behavior to align that with the SoS purpose. Those principles may only exercise limited restrictions on the constituent systems autonomy, limitations which are less severe than the benefits those systems gain from being part of the SoS. Appropriate mechanisms need to be identified and understood, which can include both regulating mechanisms to minimize inappropriate behavior, and awarding mechanisms to encourage desirable conduct.

15 ARCHETYPES Directed: SoS built for specific purpose Central management Constituent systems retain individual capability but are normally subordinated Acknowledged: SoS built for specific purpose (similar to directed) Central management, but constituent systems are not normally subordinated (similar to collaborative) Typically, a result of building an SoS out of a combination of existing and new systems Evolution is a result of collaboration between the constituent systems owners Collaborative: SoS has agreed purpose Central management, but with limited power; constituent systems collaborate voluntarily to fulfil agreed upon purposes Virtual: No agreed upon SoS purpose No central management, SoS behavior is emergent, not caused by explicit mechanisms Over time, a specific SoS may change its archetype evolutionary References: Maier (1996, 1998), Dahmann & Baldwin (2008)

16 ARCHETYPES VS CHARACTERISTICS (SKETCH) Directed Acknowledged Collaborative Virtual Operational independence Managerial independence Evolutionary development Emergent behavior Low Low Medium High Low Medium Medium High Low Medium High High Medium Medium High High Neither archetypes nor characteristics have precise enough definitions

17 OTHER ASPECTS/CHALLENGES SoS are (always?) socio-technical systems The enabling systems of the constituent systems will also form an enabling SoS Describing SoS modeling, simulation, etc Architecture Properties: Resilience: Safety, Security, Robustness,... Privacy

18 INTERNATIONAL RESEARCH

19 SWEDISH RESEARCH FOCUS Applications Interoperability Military applications Space applications Power applications Automotive applications Health care applications... applications Sustainability Dependability SoS Engineering? Systems engineering Security... Properties Control systems System architecture Communication Systems / SW engineering Modeling & simulation... Foundation

20 ANALYSIS OF WS2

21 Session 1: G1: Green G2: Yellow G3: Purple G1 G3 G4 G5 Session 2: G4: Orange G5: Red G6: Blue G2 G5 G6 G6 G6

22 7 KEY QUESTIONS IN THE LIFE OF AN SOS 1. Why is the SoS created? 2. Whose system is the SoS? 3. Which are the stakeholders? 4. What should it do? 5. How much should it perform? 6. How should it be organized? 7. When does it change?

23 WHY? Why is the SoS created? For a specific purpose, to provide a set of capability Those capabilities provide the value of the SoS The capabilities are emergent properties, not possible to provide by any constituent system in isolation Two cases in which an SoS is formed: Reactively, to meet an existing need, such as an incident Proactively, to meet a future need or opportunity through an innovative combination Usually, some constituent systems already exist. Which are they? What are the degrees of freedom and constraints in modifying them? It is a mixed top-down/bottom-up process, with more emphasis on integration than in traditional SysEng

24 WHOSE? Whose system is the SoS? This is the organization (or group of organizations) that take ownership throughout the lifetime, coordinating its development and evolution It could be the same as the originator organizations who took initial action to form the SoS, but also others (such as a standardization group) Some patterns: An organization forms an SoS by making contracts with other organizations to include their systems (military) A group of organizations come together and form a consortium which owns the SoS through standards An existing system provides a platform with open service interfaces which an(other) organization uses to build their systems on top of it (web service) The SoS owner owns 0..n-1 of the n constituent systems A system can be a consituent of several SoS The owner organization must implement the necessary mechanisms for decision making about the SoS

25 WHICH? Which are the stakeholders of the SoS? The SoS owner The owner of each constituent system Beneficiaries of the SoS capabilities (could be the owner, or its clients, or the constituent systems if the SoS improves their capabilities) All stakeholders of the constituent systems, since they may be affected (+/-) by the system being modified to fit the SoS Other actors who are affected by the formation of the SoS The owners of the SoS and of the constituent systems are the ones who jointly develop the SoS What are the relations between the stakeholders? Includes monetary flows, acquierer/supplier

26 WHAT? What should the SoS do? This is the functionality needed to create the capabilities Requirements of the SoS. How are they communicated between those stakeholders that need to take actions to create the SoS? In practice, these are often vague formulations of objectives rather than crisp requirements Trade-offs against the requirements of the constituent systems How is V&V of the SoS organized? Rules for participating, entering, leaving the SoS

27 HOW MUCH? How much performance should the SoS have? This includes a number of generic qualities: Resilience Dependability Robustness Safety Security Privacy... Trade-offs between qualities on SoS level vs. on constituent system level What are the acceptable risks for the SoS? For the constituent systems? The constituent system s risk can increase (dependencies on others) but also decrease (redundancy leading to resilience) How can measurable levels be achieved, for verification purposes, from the vague objectives?

28 HOW? How should the SoS be organized? This must include enabling systems, social systems, etc. Architecture is a key factor. Different organizational structures: Federations Peer-to-peer Common supersystem Keystone defining a common platform Breakdown of what to each constituent system (some more can be added in the process) Mechanisms to ensure fulfilment of requirements, i.e. to get the desired emergent properties: Monitoring of constituent systems Actions to assign responsibilities, and handle identified deviations Legal structures (e.g., contracts)

29 HOW (CONT D)? Technical interfaces and adjustments to existing ones Service oriented interfaces, with well defined (ideally standardized) definitions Interoperability on different levels, such as syntactic (protocol), semantic, and pragmatic Federation level agreements (FLA) for federations Service level agreements (SLA) for services Ontologies to achieve interoperabilitiy Managerial principles how to run the SoS development? Will traditional project models suffice? Descriptions: Modeling and simulation

30 WHEN? When should the SoS change? This is focusing on the evolution of the SoS How to create, and maintain, trust among the participants in an evolving SoS? The SoS must be built to handle dynamic situations Outside the SoS (environment/context) Inside the SoS (changes to constituent systems, add/remove constituents)

31 WORK ON EXAMPLE

32 ASSIGNMENTS Purpose: To exemplify and extend our understanding of SoS through an example Work with the 7 key questions! What are major challenges in the engineering of the SoS? Which of these are specific to SoS (and not just any system)? Remember: Objective is not to solve these problems, but to generate insights into SoS. If you lack information, just make an assumption! One or two groups? One or two examples?

33 EXAMPLE 1: PLATOONING

34

35 EXAMPLE 2: INTEGRATED CARE

36 SOS AGENDA CONTENT

37 TYPICAL CONTENT OF AN AGENDA DOCUMENT Based on 8 randomly selected agenda documents (out of approximately 70 completed so far, 136 projects have started!): Motivation of the area s importance Identification of a number of topics that require attention (which are specific to the area of the agenda) Proposal of a number of actions (which are mostly quite generic)

38 AGENDA DOCUMENT: TYPICAL GENERIC PROPOSALS Funding Research, especially long-term Development and innovation projects Knowledge and competency, education Regulations Harmonization and standardization Legislation Platform for cooperation, with a driving actor Creating meeting space Exchange information Create common goals Collect statistics Lobbying Follow up, develop and update the agenda Cross-cutting activities Demonstrator projects Access to infrastructures Participation in EU programs

39 CONTENT OF AN SOS AGENDA? Specific topics: What are the key topics? How do we achieve gränsöverskridande innovation? Generic actions: Funding Research, especially long-term Development and innovation projects Knowledge and competency, education Regulations Harmonization and standardization Legislation Platform for cooperation with a driving actor Creating meeting space Exchange information Create common goals Collect statistics Lobbying Follow up, develop and update the agenda Cross-cutting activities Demonstrator projects Access to infrastructures Participation in EU programs

40 WRAP UP

41 NEXT STEPS Actions after this WS: Synthesis of data from different sources Continue with a deeper analysis of common challenges and needs to be addressed in a research and innovation agenda Write texts Future events: No more workshops in this format planned 1st Swedish Workshop on Engineering of SoS (SWESOS) May 27 Academic style workshop with focus on research presentations But everyone is welcome to submit quality papers and attend!

42