Systems Engineering for Systems of Systems

Transcription

1 Systems Engineering for Systems of Systems Sound engineering solutions for complexity This slide set is a summary of the topics of a 3-day course available from Honourcode. Systems Engineering Training Courses Process Improvement Eric Honour +1 (850) ehonour@hcode.com Version 1.0 Jan 08 Summary Version SE for SoS 1

2 SoS Example: a Military Force Component systems Aircraft, ground vehicles, ships, submarines Each with unique sensors, communications, weapons Soldiers with instrumented personal equipment Many communications systems Command/control (C 2 ) Functions Force projection Battle superiority Command/control Development Vehicles, C 2, equipment, sensors, comms, weapons Each system developed separately Developments occurred over decades of time SE for SoS 2

3 SoS Example: a Modern Airport Component systems Aircraft, support/maintenance, baggage handling Air traffic control, ground control, taxiways, runways Ticketing, reservations, gate control, boarding bridges Transportation security Parking, auto traffic control Shopping, pedestrian control Functions Passenger transportation Flow control Enjoyable experience Development Some systems developed together when airport built Others developed separately over decades of time Different customers, different developmental control SE for SoS 3

4 SoS Example: Supply Chain Mgmt Component systems Production management systems Inventory systems Transportation tracking systems Internet for connectivity Functions Reduce inventory costs Just-in-time inventory production Development Each system developed separately Little coordination Systems upgraded separately SE for SoS 4

5 Agenda Systems of Systems Challenges Systems of Systems Defined Complexity Issues Paradigm Shift Architecture Solutions Architecture Defined, Architecture Frameworks Top-Down Architecting Evolutionary Re-Architecting Bottom-Up Dynamic Optimization Integration Solutions Interface Design, Effects of Coupling Open Systems, COTS, Legacy Systems Question/answer sessions after each segment SE for SoS 5

6 Systems of Systems Defined What s the difference between a system and a system of systems? SE for SoS 6

7 SoS Characteristics A System is a System of Systems if: Operational independence - component systems have purpose even if detached Managerial independence - component systems are developed and managed for their own purposes Evolutionary development - functions and purposes are added, removed and modified in an ongoing way Emergent behavior - SoS performs functions not achievable by the independent component systems Geographic distribution - geographic extent forces the elements to exchange information in a remote way - Mark Maier SE for SoS 7

8 Impacts of SoS Characteristics Operational Independence Component systems change; little insight into their structure Managerial Independence Lack of control of the SoS; limited effect of guidance SoS System Control is a significant challenge Stakeholders want assurance of the emergent behavior Emergent Behavior Difficult technical control of timing, interfaces Constant revision, integration issues Evolutionary Development Geographic Distribution SE for SoS 8

9 Complexity Issues What is complexity? Why does it matter? SE for SoS 9

10 Some Effects of Complexity Attractors Patterns Emergent properties Self-organization These effects (and others) are normal in complex systems, and they present difficult challenges to engineer. For each of these, we will show what it is, an SoS example, and design methods usually attempted SE for SoS 10

11 Conclusion Systems Engineering is the engineering of complexity! and it always has been Today, SoS and complexity are affecting Systems Engineering: New methods appearing Old methods used in new ways SE for SoS 11

12 Paradigm Shifts in Engineering Complexity Nexus of development as significant as the industrial revolution and the computer revolution! Complex adaptive systems design methods Internet, data access, system integration Networking revolution 2000s Mechanical systems design methods trains, automobiles, agriculture, devices Electronic & computer systems design methods radar, space travel, comms Computer revolution 1900s Industrial revolution 1800s Historical Time Each paradigm fuels a rapid growth and then stagnates as it tries to handle more complex products SE for SoS 12

13 System Engineering Solutions What are systems engineers doing today to solve the challenges? SE for SoS 13

14 A Solutions Framework Architecture Solutions Capability engineering Architecture frameworks Evolutionary re-architecting Dynamic optimization Patterns Integration Solutions Interface control Coupling & interoperability Open systems COTS integration Legacy system integration Collaboration Solutions Working w/ multiple teams Concurrent SE Program interfaces Collaboration tools Test & Eval Solutions Multiple levels of T&E Evaluating interfaces Validating functions Evaluating dynamics Evaluating emergence SE for SoS 14

15 Architecture Solutions How can we architect the structure of a system of systems? Capability engineering Architecture frameworks Evolutionary re-architecting Dynamic optimization SE for SoS 15

16 What Is an Architecture? The fundamental organization of a system embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution Conceptual Model Highest-level concept of a system in its environment Model to communicate and record Structure Shown in several views to support related sets of tasks Identifies system components (functional and physical) Defines relationships Embodies guiding principles of design concept evolution ANSI/IEEE System Block Diagram: a Simple Architecture SE for SoS 16

17 Capability Engineering One solution to defining and/or changing an SoS: the top-down approach SE for SoS 17

18 Capability Engineering The use of architecture-based methods to define and implement operational capabilities across a system of systems. Characterized by a top-down approach Define the desired capabilities Diagram the current architecture of systems Analyze the gaps from the current capabilities Architect a new arrangement of systems and functions Implement the capabilities in a phased approach Used primarily in US DoD Guided by evolving capabilities documents Greatest difficulty is in the implementation SE for SoS 18

19 SoS Capabilities Engineering Observe Discover problems or new missions Establish the requirements for the new capability Assess Perform a task analysis. Establish the new capability footprint. Analyze the systems touched by the footprint. Model & Architect Design the new capability in terms of systems/functions Build Re-engineer the component systems Verify and validate the new capability Repeat Assess Model & Architect Scope Observe Build SE for SoS 19

20 Architecture Frameworks A tool to organize complexity SE for SoS 20

21 Architecture Framework A resource that guides the development or description of an architecture. Elements Standard thought structure Standard views and view descriptions Standard data structure to retain and relate information Standard approach to develop architectures Benefits Communications among those who share the framework Accurate data interchange among models Automated/visual evaluation of architectures Assists decision making Lower cost, greater assurance Training and processes standardized SE for SoS 21

22 Frameworks Comparison USED BY STRENGTHS WEAKNESSES DODAF US DoD and others Rich set of views Operational definition Enterprise Acquisition Technical structure Business TOGAF Commercial Info Tech Enterprise mgmt Software engineering Enterprise security Architecture products Commercial license required to use Acquisition Zachman General Relatively complete set of viewpoints Classification schema No specific models No notation No methodology FEAF US CIO Multiple view levels Transition processes Architecture products Notation Enterprise processes and models Methodology SE for SoS 22

23 Evolutionary Re-Architecting Adaptive application of topdown thinking to a constantly changing SoS SE for SoS 23

24 Personal Music Player SoS Web Distribution System Artists & Content Providers Personal Music Player Personal Library Software SE for SoS 24

25 Evolutionary Developments Bright idea interactions Let s allow them to categorize their music! Legal impacts of Napster music delivery Storage of video, photos, computer files Competing MP3 players Competing personal libraries Podcast delivery Integration with iphone SE for SoS 25

26 Solution: Re-architecting Observe evolutions Identify what are the changes that matter! Assess impact of each change Technical and technology impacts Development timing impacts Product delivery impacts Team-of-teams impacts Maintain ongoing architecture Interaction models & diagrams Documentation: specs, agreements Build changes Assess New development items Revisions and auto-delivery Model & Architect Scope Observe Build SE for SoS 26

27 Dynamic Optimization Another method for defining and/or changing an SoS: bottoms-up from the needs of the component systems. SE for SoS 27

28 Dynamic Optimization Example: Supply Chain Management (SCM) Suppliers Inventory SCM systems management systems Business problem: client relationships, assurance, rapid responsiveness invoicing Solution: Inventory mgmt linked to delivery clients parts transport demand Transportation Road Optimized equipment, road equipment drivers Business Full tracking problem: of deliveries Independence Business problem: of drivers client Solution: demand for GPS information tracking, logs Solution: GPS tracking, logs linked to clients Manufacturers Assembly lines using optimized JIT, SCM Large Small Business parts demand: inventories reduce costs, Financial Risk: more production competition problem: shortage excessive due to sunk parts Solution: cost supply Parts in inventories shortage tracking linked to Solution: part transport Just-In-Time Parts demand (JIT) software parts linked procurement to suppliers methods SE for SoS 28

29 Summary: Dynamic Optimization Stakeholder value Perceived differently by each stakeholder Intuitively or explicitly evaluated SoS changes decided by individual stakeholders Asynchronous and independent decisions Decisions often made at level of component systems Decisions often made based on local knowledge Component relationships change Result: a self-organizing, dynamic SoS with continual advancement Frequent conflicts among goals Negotiation among co-equal stakeholders SE for SoS 29

30 Integration Solutions How can we better integrate the component systems in a system of systems? SE for SoS 30

31 Integration in Classical SE Vee model - robust decomposition and checking Integration Right hand side of the Vee SE for SoS 31

32 Integration in the SoS Continuing Life Cycle of the SoS Driving Events SoS Concepts Development Systems Development Subsystems Development Integration is nearly constant Often occurs without planning SE for SoS 32

33 Interface Definition & Coupling Issues The interface: a powerful tool for managing complexity SE for SoS 33

34 Managing Complexity: A Key Role of Interfaces System 1 System Limit the interactions between system entities to defined behavior at specific locations / system boundaries. Limiting the need for a designer to participate in the design of co-functioning system components. SE for SoS 34

35 Dimensions of Coupling Dimension Coupled De-Coupled Material Connection Vendor & Platform Dependence Msg. Structure & format Interface Definition Interfaces extensible Interfaces Constrained Message Modes Binding Message Synchrony Human Adjustable Human Attention Yes Yes Fine grained, assumed format None No plan No Stateful & modal Early Synchronous No Flow Required No No Coarse-grained, self-describing, self-contained Well-defined Exts., Vers. Yes Stateless Late Asynchronous Yes Asynchronous SE for SoS 35

36 COTS, Open Systems, Legacy Systems How well-defined, widely-used versions of the component systems affect the SoS. SE for SoS 36

37 Designing COTS Success: Market Assessment Assessment of market range of variation: Size of market COTS Market Client Application Performance COTS COTS Vendor COTS Vendor COTS Component Cost Vendor... COTS Choices Reliability Interface Manageable rate of change in marketplace Compatible application with present and ongoing market capabilities Strategic approach to vendor relationships Willingness to walk away from a poor application. SE for SoS 37

38 Open Systems Approach Well-defined, widely-used, non-proprietary Interfaces Protocols Provisions for: Expansion Upgrade with new technology Commercial standards Industrial experts Open Systems Ahead Open Systems Proceed In Any Direction SE for SoS 38

39 Implementing Change No changes to baselines without CCB approval! Change in an SoS is a collaborative process Fleet Program office Engineering Logistics Plan implementation carefully Approach changes incrementally, if possible Measure carefully to detect emergent surprises SE for SoS 39

40 Bottom Up Integration: The Casual Carpool (Slugging) Transit planners: added HOV lanes - incentive to carpooling Drivers: wanted benefit of HOV lanes Observation: Riders: Spontaneously gathered to offer additional rider Drivers: Gained an additional passenger / HOV access Transit planners: Defined additional locations Placed signs Publicized opportunity SE for SoS 40

41 Systems Engineering for Systems of Systems Systems Engineering Training Courses Process Improvement Eric Honour +1 (850) Courses: SE for SoS 41