Application of A Model-Based Systems Engineering Approach to Architecting an Intelligence, Surveillance and Reconnaissan

1. Application of A Model-Based Systems Engineering Approach to Architecting an Intelligence, Surveillance and Reconnaissance (ISR) Exercise Fred Rojek Booz Allen Hamilton HRA INCOSE Requirements Management & Analysis Seminar November 4, 5

2. Objective Understand key features of a model-based systems engineering (MBSE) approach to architecting a complex system

3. Agenda • Why a Model Based Approach is Needed Barriers to successful system engineering • MBSE Features How MBSE works to overcome the barriers • MBSE Application Architecting an ISR Exercise

4. Model Based Methods in Software Development Formal methods developed to address the challenges of complex software development • Model Driven Engineering (MDE) • Model Driven Architecture (MDA)1,2 • Model Driven Development (MDD)1,2 • Model Based Application Development1 • Model Based Programming1 • Rational Unified Process for Systems Engineering3 • Object Oriented Systems Engineering Method (OOSEM)1 Models bridge the communication gap between stakeholder and software engineer 1. Object Management Group (OMG) trademarks; 2. MDA & MDD are implementations of MDE; 3. IBM Rational trademark

5. Why a Model Based Approach is NeededBarriers to successful systems engineering

6. Systems Engineering Objectives • Translate user objectives into a system solution that works* • Within constraints (cost, schedule, environmental, safety, ilities…) • Document the solution • Needed to design, test, manufacture, operate, support the system • Consistent with operational system *Sustainable, operational system that satisfies documented User needs

7. Barriers to Successful Systems Engineering • Time • Distance • Language • Complexity

8. Multiple program and project offices often with competing program/project objectives Multiple contractors (often worldwide) often with competing program/project objectives Multiple & diverse technical disciplines Customers, operators, maintainers, suppliers… great domain expertise, little engineering expertise (and vice versa) Ambiguous, continually changing requirements Totality of requirements in the thousands Poorly documented & not traceable Layered systems employing multiple technologies Lengthy, drawn out development periods Schedule delays Integrating leading edge with legacy systems Numerous issues and risks to resolve or mitigate Time Distance Language Complexity Typical Barriers to Successful SE

9. MBSE FeaturesHow MBSE works to overcome the barriers

10. MBSE Employs a Central, Unifying System Model • Well defined, unambiguous language or framework • Understood by all stakeholders • Communicates multiple system aspects/views • Requirements, Behavior, Structure, Performance, Verification, etc. • Integrated/Traceable; Complimentary • Maintained on automated tool(s) (single tool, ideally) • Accessible to development team and stakeholders • collaborative engineering environment “…model-based [systems] engineering is about elevating models in the engineering process to a central and governing role in the specification, design, integration, validation, and operation of a system.” Estefan, J.A., Survey of Model Based Systems Engineering Methodologies, INCOSE MBSE Focus Group

11. Essential Tool Features • Supports the selected modeling language or framework • Capable of generating needed system views • Maintains horizontal and vertical traceability • Maintains a central repository for model data • Supports automated product & document generation • Drawn from the central model repository • Formal documents include: System/Segment Specification (SSS); Interface Requirements Specification (IRS); Test & Evaluation Plan (TEP); Software Requirements Specification (SRS)... • Other work products include individual system views

12. MBSE Connects SE Processes Systems Engineering Process Model Requirements Analysis Requirements View Functional Analysis & Allocation Behavioral View To Next Development Level Design/Synthesis Physical View Safety Analysis Human Factors RAM Analysis Logistic Analysis EMI Analysis … Assessment Assessment View . . . System Analysis & Control* * Trade-off Studies, Risk Management, Interface Management, Configuration Management…

13. Multiple System Views Example Requirements Hierarchy (System Traceability) Operations & Logical/Functional (System Behavior) Physical Hierarchy (System Structure) Verification Requirements Physical Block Diagram (System Interconnection)

14. Traceability Between Views trace to allocated to verified by functional I/O implemented by Additional views used as required to communicate other relevant system characteristics

15. MBSE Connects Development Levels Operational Test Concept Validation Requirements Validation Results Verification Requirements System Integration & Verification System Design Verification Results Product Design Product Integration & Verification Verification Requirements Verification Results Verification Requirements Subsystem Design Subsystem Integration & Verification Verification Results Verification Requirements Model Development & Maintenance Component Design Component Integration & Verification Verification Results Model Development . . . . . .

16. Sys Sys … … Prod 1 Prod 2 Prod 3 Prod 1 Prod 2 Prod 3 … … … … … … SyS Subsys 1.1 Subsys 1.2 Subsys 3.1 Subsys 3.2 Subsys 1.2 Subsys 3.1 Subsys 3.2 Subsys 1.1 … … … Prod 1 Prod 2 Prod 3 Comp 1.1.1 Comp 1.1.2 Comp 3.1.1 Comp 3.1.2 Comp 3.1.3 Comp 1.1.2 Comp 3.1.1 Comp 3.1.2.a Comp 1.1.1 … Sys … Prod 1 Prod 2 Prod 3 … … Subsys 1.1 Subsys 1.2 Subsys 3.1 Subsys 3.2 Accumulated System Data (History) MBSE Connects Development Phases Concept Refinement Advanced Development Engineering Design Integration & Evaluation Production Operation & Support Increasing Model Complexity

17. MBSE Application Examplearchitecting an intelligence, surveillance & reconnaissance exercise

18. Requirement for an ISR Exercise • Adequate Intelligence, Surveillance and Reconnaissance (ISR) Capabilities are essential to warfighter success • Existing systems employing ISR technologies have grown increasingly complex and stove piped • DoD mandate for systems interoperability, and migration toward network-centric capabilities* • New, highly capable technologies require operational testing with existing systems to assess capability *will allow warfighters to take full advantage of all available information and bring all available assets to bear in a rapid and flexible manner

19. Why ISR Capabilities Matter to The Warfighter An Arsenal of UAV's The military heavily relied on unmanned aerial vehicles, or UAV's, like the Shadow and the Predator drones. Military officials say the drones have vastly improved since the 2003 invasion of Iraq.

20. ISR Functionality Synchronize & Integrate intelligence gathering resources Collect required intelligence information Transform information into forms suitable for analysis Integrate, evaluate & interpret information Present information to military & national decision-makers

21. Integrating ISR Capabilities Graphic from Coalition Integrated Air Picture Architecture, Charles Dickerson, Mark Sabins, INCOSE Insight, Oct 2002

22. The Task Design an architecture for a live ISR exercise that will: • Demonstrate emerging ISR technology capabilities • Advanced sensors • Information processors (for data correlation and fusion) • Data displays and decision support tools • Demonstrate system interoperability • Demonstrate the capability of the integrated, exercise system to meet urgent warfighter objectives in an operationally representative environment

23. The Development Environment • Participants/Stakeholders • All military services; National Agencies; Combatant Commands; Coalition Forces; Defense Contractors (large & small) • Existing systems • Over 50 nodes connected by multiple, legacy networks & data links • Located throughout the U.S. • Space, Ground, Surface systems • Over 40 new systems (supporting all ISR functions) • Each with its own unique capability to be demonstrated • 18 month development period

24. The Systems Engineering Model Requirements Analysis Requirements View Functional Analysis & Allocation Behavioral View Design/Synthesis Physical View Assessment Assessment View System Analysis & Control

25. The Development Model * Exercise System Concept will be documented as an integrated set of architectural products traceable to Objectives & Validation Requirements; maintained as part of the System Model.

26. The SE Tool • CORE • Supports the systems engineering/architecting process • Single tool, integrates all needed views • Maintains vertical & horizontal traceability • Single data repository • DoDAF 1.5 compliant • Automated product & document generation • All DoDAF views • Capture associated risks & issues • associated with any model element • Capture and associate other critical data • doctrine, guidance, standards • Built-in assessment capability

27. Building The Exercise Architecture One Capability at a Time

28. Architecting Process Inputs Test Environment Guiding Doctrine Existing Systems Warfighter Objectives (15) Exercise Architecture Concept New Capability n . . . New Capability 3 New Capability 2 New Capability 1

29. Warfighter Objectives Analysis . . .

30. Capability Analysis Sensor Existing Networks Shooter Shooter Target Tactical Node with handheld system New Capability 1: Demonstrate capability of a handheld/laptop system to receive intelligence data from sensors, and provide targeting data to weapon in near real time.

31. Scenario Development Scenario 1 demonstrates the capability of new system to receive and correlate sensor data, and generate target aim point

32. Architecture Synthesis Allocate scenario activities to exercise systems, define the interfaces

33. Maintaining Traceability Objectives demonstrated by demonstrated by Scenarios decomposed by Activities performed by Systems connected to Needline

34. Architecture Description Document Generated by CORE, drawing model data from central repository

35. MBSE Features Summary • Employs a Central, Unifying System Model • Maintained on automated tool(s) • Accessed in a collaborative engineering environment • Connects SE Processes • Connects Development Levels • Connects Development Phases Models are the primary means of communication with clients, builders, and users; models are the language of the architect. The Art of Systems Architecting, Maier, M., Rechtin, E., CRC Press, 2002

36. Questions?

37. Backup Slides

38. System Structure Modeled by a Block Definition Diagram (SysML)

39. System Structure Modeled by a PhysicalHierarchy Diagram

40. DoDAF Products as System Views Requirements View OV-1,2,4,5,6 Requirements Analysis Behavioral View SV- 3(a,b,c),4(a,b,c),5 Functional Analysis & Allocation Physical View OV-2,3; SV-1,2,6; TV-1 Design/Synthesis Assessment View OV-6c; SV-7,10 Assessment See Dickerson, Soules, Sabins, Charles, Using Architectures for Research, Development & Acquisition, ASN(RDA) for more information

41. DoD Architecture Framework (DoDAF)a very brief introduction • What • Provides the guidance and rules for developing architectures • Ensures architecture descriptions can be compared, related, integrated • Establishes the foundation for architecture analyses & decision-making • How • Provides a framework for representing architecture descriptions • Defines a set of products for visualizing an architecture • OV-1, 2, 3…; SV-1, 2, 3…; etc. DoDAF Vol 1 link: http://www.defenselink.mil/cio-nii/docs/DoDAF_Volume_I.pdf

42. DoDAF Representations of the System Model*(putting DoDAF to work) • Operational Concept: Representation of the operational concepts proposed to demonstrate allocated capabilities (within the operational/test environment). Used to clearly communicate proposed concepts. • OV-1, 2, 4, 5, 6/6(c) • System Functional Mapping. Representation of the physical systems and allocated functionality required to demonstrate capabilities (within the operational/test environment). Used to clearly communicate proposed concepts. • SV-4, 5, 3 • System Interface Mapping. Representations of the required connectivity between physical systems. Used to validate system interoperability! • OV-2,3; SV-1,2,6; TV-1 • Architecture Performance & Behavior: Representations of Architecture performance. Used to validate architecture performance! • OV-6c; SV-10, SV-7 *integral to the System Model -- i.e. DoDAF products (OVs and SVs) and System Model representations (thread, activity, node, needline, link…) are composed of the same data.

43. Definitions • Architecture – The structure (in terms of components, connections and constraints) of a product, process, or element.1 • Architecting – The processing of creating and building architectures.1 • Complexity – A measure of the numbers and types of interrelationships among system elements. Generally speaking, the more complex a system, the more difficult it is to design, build and use.1 • Model – A model is a mapping of the system-of-interest onto a simpler representation which approximates the behavior of the system-of-interest in selected areas. Models may be used to represent the system under development, the environment in which the system operates, or interactions with enabling systems and interfacing systems.2 1.The Art of Systems Architecting, Maier, M., Rechtin, E., CRC Press, 2002 2.Systems Engineering Handbook, version 3, INCOSE,June 2006

44. Definitions • System • A combination of interacting elements [things] organized to achieve one or more stated purposes.1 • A system is a construct or collection of different elements that together produce results not obtainable by the elements alone. The elements, or parts, can include people, hardware, software, facilities, policies, and documents; that is, all things required to produce systems-level results. The results include system level qualities, properties, characteristics, functions, behavior and performance. The value added by the system as a whole, beyond that contributed independently by the parts, is primarily created by the relationship among the parts; that is, how they are interconnected (Rechtin, 2000). • System of Interest – The system whose life cycle is under consideration.1 • System-of-Systems • System of systems applies to a system-of-interest whose system elements are themselves systems; typically these entail large scale inter-disciplinary problems with multiple, heterogeneous, distributed systems.1 • A set or arrangement of independent systems that are related or connected to provide a given capability. The loss of any part of the system will degrade the performance or capabilities of the whole.2 1.Systems Engineering Handbook, version 3, INCOSE,June 2006; 2. DoDD 4630.5. Contained in DoD Architecture Framework, version 1.0, Feb 2004

45. Definitions • DoDAF - Department of Defense Architectural Framework – “provides the guidance and rules for developing, representing, and understanding architectures based on a common denominator across DoD, Joint, and multinational boundaries.” • Battlespace – (DOD) The environment, factors, and conditions that must be understood to successfully apply combat power, protect the force, or complete the mission. This includes the air, land, sea, space, and the included enemy and friendly forces; facilities; weather; terrain; the electromagnetic spectrum; and the information environment within the operational areas and areas of interest. See also electromagnetic spectrum; information environment; joint intelligence preparation of the battlespace.1 • NCW represents a powerful set of warfighting concepts and associated military capabilities that allow warfighters to take full advantage of all available information and bring all available assets to bear in a rapid and flexible manner. The tenets of NCW are:2 • A robustly networked force improves information sharing. • Information sharing enhances the quality of information and shared situational awareness. • Shared situational awareness enables collaboration and self-synchronization, and enhances sustainability and speed of command. • These, in turn, dramatically increase mission effectiveness. 1. DOD Dictionary of Military and Associated Terms, As amended through 26 August 2008, http://www.dtic.mil/doctrine/jel/doddict/index.html 2. Luddy, J., The Challenge and Promise of Network-Centric Warfare, Feb 2005, Lexington Institute, www.lexingtoninstitute.org

46. Definitions • Collaborative Engineering Environment (CEE) – An environment built with a set of tools to facilitate data/information exchange and collaboration among engineers, scientists, users and managers at multiple distributed locations for the purpose of defining, developing and evaluating a capability. The Collaborative Engineering Environment is composed of at least two environments:1 • Engineering Environment : The engineering environment includes tools for requirements management, functional modeling and architecture modeling, Computer Aided Design and Drafting (CADD), human form and behavior modeling, metrics, capability and system cost modeling, and both constructive and virtual simulations. These tools will be integrated using commercial-off-the-shelf products, resulting in linked datasets, producing a distributed Integrated Engineering Environment to support capability engineering. • Decision Support Environment : The decision support environment includes tools to provide data management, document sharing and workflow management. It is a Web-based capability to interact and share information. 1. http://www.capdem.forces.gc.ca/html/definitions_e.html