Extending Model Based System Engineering to Utilize 3D Virtual Environments

1. Extending Model Based System Engineering to Utilize 3D Virtual Environments Peter Korfiatis Stevens Institute of Technology

2. Research Problem • There is often a disconnect between what the warfighter or analyst needs a system to do, and what developers think the system needs to do • Artifacts created during the Early Systems Engineering phase are often not referenced throughout the rest of the development lifecycle • Model Based System Engineering is advancing in certain phases of development but there is little connection between MBSE artifacts across the entire development lifecycle

3. Research Need There is a need to: • quickly and graphically articulate a CONOPS for new missions and systems that will allow a diverse group of stakeholders to reach a shared mental model of the mission and potential solutions. • make the CONOPS available as a model so that the true needs of stakeholders can be conveyed to future system developers. • use model based artifacts to drive model based system architecting • allow future system developers to easily alter a CONOPS to mirror current state of the system.

4. Research Questions • Can the use of a virtual environment enhance stakeholders' ability to collaborate to reach a shared mental model and to develop a model based CONOPS? • Does real-time collaboration between distributed stakeholders improve the CONOPS development? • Can amodel based artifact of a CONOPS be used to drive Analysis of Alternatives and other Pre-Milestone A analysis activities? • Can the results of model based CONOPS be used by system architects to develop a system that better reflects the needs of the stakeholders. • Can an integrated model based approach to Concept Engineering and Architecture and Design be enhanced by the use of virtual environments and will this new process improve system quality?

5. Sources for CONOPS Guidance Title page Revision chart Preface Table of contents List of figures List of tables 1. Scope 1.1 Identification 1.2 Document overview 1.3 System overview 2. Referenced docum ents 3. Current system or situation 3.1 Background, objectives, and scope 3.2 Operational policies and constraints 3.3 Description of the current system or situation 3.4 Modes of operation for the current system or situation 3.5 User classes and other involve d personnel 3.6 Support environment 4. Justification for and nature of changes 4.1 Justication of changes 4.2 Description of desired changes 4.3 Priorities among changes 4.4 Changes considered but not included 5. Concepts for the proposed system 5.1 Background, objectives, and scope 5.2 Operational policies and constraints 5.3 Description of the proposed system 5.4 Modes of operation 5.5 User classes and other involved personnel 5.6 Support environment 6. Operational scenarios 7. Summary of impacts 7.1 Operational impa cts 7.2 Organizational impacts 7.3 Impacts during development 8. Analysis of the proposed system 8.1 Summary of improvements 8.2 Disadvantages and limitations 8.3 Alternatives and trade - offs considered 9. Notes Appendices Glossary • ANSI/AIAA G-043-1992 – guide from American National Standards Institute • IEEE 1362-1998 – IEEE guide for CONOPS document • DI-IPSC-81430 – DoD data item description for CONOPS document IEEE ANSI

6. Model Based Systems Engineering

7. Model Based System Architecting • Major advances have been made by INCOSE, OMG and other organizations to strengthen the model based approach during System Architecture and Design • The primary input to the architecting phase are the system requirements.

8. Challenges with MBSA Today CONOPS Architect System Architecture Requirements • Model is an abstract representation of the real world, subject to biases of the model constructor and model viewer • Requirements are passed to architects on paper or through a tool • Architects need to discern what the stakeholder needs the system to do from the requirements • Incorrect understanding of the requirements can lead to architects designing a system that does not meet the stakeholders’ needs

9. Proposed Approach • An approach and toolset to allow system developers to create models at the onset of systems engineering activities that can • Be developed directly by the end user • Accurately reflect the needs of future users • Be used to analyze proposed systems early in the SE lifecycle • Easily be adapted to reflect changing requirements and design • Automate the transfer of requirements and specifications to system architects • Be useful throughout the SE lifecycle Assessment of current model based and visualization tools has pointed to the use of Gaming and Virtual Environments as high potential development environments

10. Virtual and Gaming Environments • Virtual Immersive Environments have long been used by engineers to: • Solve difficult problems that require 3D visualization • Train and Educate personnel • Analyze the impact of systems on environment and users • Present concepts to customers

11. Development Using Unity 3D • Unity is a popular IDE for creating 3D games. • Extensive support community • Cross platform deployment • Rapid deployment and testing • Interoperability of programming languages • Database and networking support • Currently being used by: • Building Construction Architects to model buildings • Defense contractors to develop training simulations • Process Engineers to model complex processes • Biologists to model complex biological behavior

12. Integrated Concept Engineering System Vision Concept Engineers and Stakeholders will enter the tool through a virtual lobby. They will select their Avatar of choice. As the team comes together in the ICES Lobby, each participant will select their individual role - developer or author. The tool then provides guidance and navigation help through the process of integrating tools and developing the CONOPS. Once the team agrees on the concepts, the scenario(s) can be put into motion for observation and analysis. The scenario(s) can be modified, or stored for later sharing with others for approval CONOPS Navigator

13. Developing a CONOPS Using ICES

14. ICES High Level Architecture

15. Current Development Efforts • Using Unity 3D, a leading game development engine, as development environment • Building interfaces between popular Early Systems Engineering analysis tools • Building an interface for CONOPS personnel • Creating MBSA artifacts to give architects an accurate representation of user needs

16. Proof of Concept Prototype CONOPS Author Partial Textual CONOPS Concept Engineering System Graphical Scenario Descriptor Primitive Developer MBSA Artifacts

17. Prototype Workshop New Agency scenarios for initial testing and feedback on CES Tool • Simple limited primitive scenario– run as demo • Author viewpoint • Extended scenario– run as demo • Developer viewpoint – create new primitives, change attributes on existing primitives • Author viewpoint – import new primitives, modify existing scenario to include new primitives • Multi-player (user and observer) – run as exercise • User Scenario – Flexible to allow users to stretch CES – run as exercise • Author Viewpoint • Developer Viewpoint • Gathering Metrics– run as exercise • Split into teams and try to collect metrics related to OCNOPS creation with and without CES

18. Future Work • Move from a limited functionality, proof of concept prototype to highly functional prototype • Build out application infrastructure • Implement Executable Scenarios • Develop CONOPS and ICES development workflow to assist users in tool use • Build primitive libraries for multiple domains relevant to sponsor’s operating environments • Automate translation of graphical CONOPS output to MBSA input

19. For more information • Peter Korfiatis • pkorfiat@stevens.edu • Dr Robert Cloutier, PI • Robert.cloutier@stevens.edu • Stevens Visualization, Modeling and Computation Lab • www.stevens.edu/vmc