CC532 Collaborative System Design

Transcription

1 CC532 Collaborative Design Part I: Fundamentals of s Engineering 4. s Interoperation/Integration

2 DoD Architecture Framework (DoDAF) 2 of 24 Architecture of a system The fundamental organization of a system embodied in its environments, their relationships to each other, and to the environment, and the principles guiding its design and evolution. [ IEEE (Sept 21, 2000) ] AF: Specification of fundamental organization of a system DoDAF v1.0, Aug 2003 : Broaden of C4ISR AF v2.0 (1997) to all areas DoDAF v1.5, April 2007: Incorporation of Network Centric concepts DoDAF specifies architecture in three consistent views Operational View Tasks, activities Operational elements Information exchange Service/system View Platforms/Components Data flows Interfaces Networks Technical View Standards Rules Conventions

3 Three Views in DoDAF Operational View : 7 items OV-1: High Level Operational Concept Graphic OV-2 : Operational Node Connectivity Description. OV6c : Operational Event-Trace Description OV-7 : Logical Data Model Service/ View : 11 items SV-1 : Interface Description SV-2 : s Connectivity Description SV-3 : s-s Matrix.. SV-10c : s Event-Trace Description SV-11 : Physical Schema Technical View : 2 items TV-1 : Technical Standard Profile TV-2 : Technical Standard Forecast 3 of 24

4 Principles of Architecture What is good architecture? Satisfaction to stakeholders (users) Allowing maintenance, evolution, further development, embedding per users requests Elegant Intellectually clean of unnecessary complexities Feasible implementation Cost-effective structures that can be buildable in limited time and budget Principles of architecture Robust functionality derives essential complexity All design process should involve iteration Only customer judges quality Holistic thinking Modularity 4 of 24 Identity KISS (Keep It Simple, Stupid) Conceptual brilliance doesn t blind the lasws of physics Standardized process improvement Early defect elimination Value is identified outside * Adapted from ESD.34 system architecture at MIT

5 SoS( of s) Concept 5 of 24 SoS Collection of disparate systems, each being efficient for achievement of its own specialized requirement, which are integrated to satisfy new requirements in functionality and performance Each participating system Operational / Managerial independence Evolutionary development Emergent behavior Heterogeneous, Large-scale, Concurrent and geographically distributed Being efficient for achievement of its own specialized requirement EX: C4ISR system (Military system) Computer, Communication, Command, Control, Information (C4I) SoS Engineering Surveillance, Reconnaissance Methodology for defining, modeling, and analyzing SoS problems

6 Integration vs Interoperation 6 of Processes 2 People 3 Database 2 3 Processes People Database Mediation Processes people Database

7 Integration vs. Interoperability 7 of 24 Integration Two or more systems that cooperatively form a solution Interoperability The ability of two or more systems or components to exchange information and to use the information that has been exchanged. Driven by Issues Advances in communication technology Recognition of common areas of functionality in related systems Increased awareness of how enhanced information access can lead to improved capability Communication Media - Secure, Reliable Messaging and Security - Network management, Protocol standards Data Management - Data mining, data consistency, data privacy and data conversion Computer Applications - Real-time Analysis, reliability, efficiency, service, safety and compliance

8 Integration vs Interoperation: Comparison(1) 8 of 24 Autonomy / Independency of participants Interoperation of systems Maintain autonomy and independency Integration of systems Lose autonomy and independency Coupling mechanism Loosely coupled Tightly coupled Interaction rule Soft coded allowing rule-base configuration of participants Hard coded not allowing configuration of participants Data locality Local data maintained Data being globalized Information sharing Sharing via mediation Sharing directly between systems Advantage Reusability Composability Efficiency *Adapted from J.T. Pollock, R. Hodgson, Adaptive Information, Wiley-interscience, 2004.

9 Integration vs Interoperation: Comparison(2) 9 of 24 Integration v 1 v 2 global data Participant 1 v 1 foo1 P2.foo2( ) P2.foo2 P1.foo1 Participant 2 v 2 foo2 P1.foo1() Efficiency hard coded interaction tightly coupled Participant 1 local data Participant 2 Interoperation v 1 soft coded interaction foo1 mediator ( ) mediator mediator v 2 P1.foo1 P2.foo2 Communication Mediator foo2 mediator ( ) loosely coupled (Part1, Part2.foo2) (Part2, Part1.foo1) Reusability Composability

10 Hard Coded Interaction No reusability 10 of 24 Module i calls a function in Module k M-i M-i M-k (infor) end M-i M-k M-k(infor). end M-k Module i calls a function in Module m M-i M-i M-m (infor) end M-i M-m M-m(infor). end M-m M-i changes its destination of interaction Problems in reusability of M-i as a library component Change of a call of M-i from M-k to M-m Change of source code in M-i Change of source code recompiliation No reuse in binary form

11 Soft Coded Interaction Reusability 11 of 24 Module i calls a function in Module m M-i M-i M-m (infor) end M-i M-m M-m(infor). end M-m Approach to reusability: Soft coded interaction remove direct connection Mediator (communication engine) Deliver(infor) for each element in (sender, receiver) list if src = sender receiver (infor) end Deliver Deliver(infor) M-k(infor) (Sender, Receiver) list Sender Receiver M-i M-k M-i M-j M-k M-m... Rule for Soft coded interaction M-i(infor) Deliver(infor-i); end M-i M-k(infor) Deliver(infor-k); end M-k Each module sends a message to mediator engine Mediator delivers a message to its destination Change of destination needs to change of Rule for soft connection, but no change of source code in M-i.

12 General Form of Soft Coded Interaction: Bus 12 of 24 Deliver(infor) M-i(infor) M-i Deliver(infor-i); end M-i Mediator (communication engine) Deliver( infor) for each element in (sender, receiver) list if src = sender receiver (infor) end Deliver Deliver(infor) M-k(infor) M-k(infor) Deliver(infor-k); end M-k Deliver(infor) M-n(infor) M-n(infor) Deliver(infor-n); end M-n (Sender, Receiver) list Sender M-i M-i M-k. Receiver M-k M-j M-m.. Standard I/F (BUS) required M-i M-k M-n Reusable Library

13 Integration in s Life Cycle 13 of 24 Process Preliminary Architectural Design Development Planning Detailed Design Subsystem/Component Design Synthesis and Evaluation Trade-off Studies and Evaluation of Alternatives Development of Prototype Models Configuration/Clearness Design Developmental Test and Evaluation Product Specification/Drawing/Planning Manufacturing Specification integration and product Development Integration and Test Production and Construction of Components Qualification Test Production Acceptance Test Assessment Manufacturing/Delivery the Product and Maintenance Operation in the User Environment Sustaining Maintenance and Logic Support Modifications for Improvement

14 Integration 14 of 24 Definition Bringing together component subsystems into one system and ensuring that the subsystems function together as a system [Wikipedia Encyclopedia] Issues of Integration Ensure assembled modules, each working fine in isolation, work together Attempt to find interface faults and validate requirements Identify and manage interfaces Plan a timely, cost-effective and operationally focused system Implementation/upgrade/change/removal Integrate and interpret analyses Verify that requirements are met

15 Integration in s Engineering 15 of 24 User Requirements & Concept of Operations Requirements & Architecture Integration Demonstration & Validation Integration & Test s Engineering Expertise for specific domain Sub- Design Sub- Integration & Test Sub- Design Procure, Fabricate, & Assemble Parts Implementation of each component * Adapted from INCOSE presentation

16 Implementation 16 of 24 Function Allocation and Mapping Component Component 1 Component 2 Component 3 Function A Function B Function C Function D Development and Integration Component 4 Function E Function F Component Development Component1 Sub-A Sub-B Component2 Component1 Component2 Component3 Component4 Component3 Component4

17 Integration Tools 17 of 24 : Manage and compare the budget and schedule within Integration StopLight Chart Radar Chart (Spiderweb Chart) Months Project Start Task I: Mid-level Coordination for Mode Switching and Reconfigurable Control A. Mode Switching / Reconfiguration Develop nonlinear control algorithms Testing and validation in a simulation environment Optimization and final code development B. Fault Tolerant Control Adapt diagnostic routines to the UAV bed Develop fault-tolerant algorithms Test and validate diagnostics and fault tolerant routines C. Integrate control algorithms for reconfiguration and fault tolerant control Domain analysis to identify core, generic, reusable structure of each module Record design patterns during integration Integrate with toolkit developers Task II: Control Integration and Simulated Demonstration A. Development of intelligent computing-architecture and run-time infrastructure B. Integrate high-level, mid-level and low-level controllers, and sensor processing modules C. Simulation of Intelligent VTOL UAV via Hardware in-the-loop simulation D. integration and flight ing Task Network Task III: VTOL UAV Demonstration A. Infrastructure development B. Flight development and support C. Flight demonstration Timeline Chart

18 Integration Strategies and Integration Test 18 of 24 Integration Strategies Big bang or Incremental(Top-down/Bottom-up) Horizontal or Vertical Order of integration impacts efficiency First come first integrated? Foundational components with long lead time? Objective of Integration Test Test = Verification + Validation Ensure assembled modules, that work fine in isolation, work together Attempt to find interface faults Several different strategies can be used for integration ing. Comparison criteria: Effort needed (for stubs and drivers) Degree of ing of modules achieved Possibility for parallel development 814/

19 Integration Test level 19 of 24 Design specifications Integrated Units Integrated Units Component Component Integration Integrated Components functional requirements Performance requirements Customer requirements specification User environment Integrated Units Integrated Units Component Component Integration Integrated Components Function Functioning system Performance Verified, validated system Acceptance Accepted system Installation SYSTEM Delivery

20 Big Bang Integration and Test 20 of 24 Sub-A Non-incremental strategy Unit each module in isolation Integrate as a whole Advantages Sub-B Convenient for small systems Disadvantages Sub-C Component1 Component2 Component3 SubsystemA SubsystemB SubsystemC Component1 Component2 Component3 Integration ing can only begin when all modules are ready Easy to miss interface faults, A, B, C Component 1,2, 3

21 Top-down Integration and Test 21 of 24 Sub-A Sub-B Sub-C, A, C Component1 Component2 Component3 Incremental strategy Start by including highest level modules and integrate these modules leave modules not ready to later Advantages Few or no drivers needed Possibility to obtain an early prototype Different order of ing/implementation possible Disadvantages Inadequately integration in bottom modules, A, C, Component1, 2, 3, A, B, C Component1, 2, 3

22 Bottom-up Integration and Test 22 of 24 Sub-A Sub-B Sub-C Component1 Component2 Component3 Componet1 Componet2 Componet3 Component1, 2,A B C,Component3, A, B, C Component 1, 2, 3 Incremental strategy Test low-level modules Modules calling them until highest level module Advantages Logic modules ed thoroughly Testing can be in parallel with implementation Disadvantages High-level modules (that relate to the solution logic) ed in the last No concept of early skeletal system

23 Horizontal Integration and Vertical Integration 23 of 24 Horizontal Integration Vertical Integration Sub-A Sub-B Sub-N Component1 Component2 ComponentN Component1 Component2 ComponentN Sub-Components Vertical Integration Compare Components in a Subsystem and Synthesize Components Integration among various Components Horizontal Integration Compare Subsystems and Synthesize Subsystems Integration among various Subsystems

24 Airplane Integration Example 24 of Collect Hardware Components 2. Integrate Hardware Platform 3. Integrate Software on Target Hardware Test Interfaces Configurations Stress Qualification Product Acceptance 4. Integration on Human s 1. Collect Software Components