3.6.1 Methodology Overview
An automated tool was selected for use that was capable of supporting requirements, functional analysis, architecture, M&S and T&E functions, as well as to improve response time to changes, minimizes manual efforts to update and sustain engineering artifacts and improve verification and validation efforts through traceability of data. Key characteristics for selection of a tool include aspects such as compatibility with programming language, artifact production, technical usability, and portability to receive and output from other tool sets. As mentioned previously, CORE was the tool provided for this project.
3.6.2 CORE
The process for conducting analysis as a total integrated approach was based on evaluation and traceability of artifacts and their respective data within CORE. Each functional area developed artifacts, which were inputted into CORE based on the overall approach. Analysis was conducted to determine if the artifacts satisfied data input requirements. For example, an initial set of requirements was developed using SysML. During review and analysis, it was identified that a scenario was required to develop the EFFBD artifact. The requirements generation process was then reviewed and modified allow development of data using existing or new artifacts, based on the specific data required. During the initial development of the EFFBD, it was identified that a ConOps document would be required resulting in an additional first pass deliverable to develop the OV-1, which was the end state artifact identified for Level 0.
The originating set of documents used to develop the planned use of CORE was based on CORE system user guidelines and experimentation. The major CORE steps followed the top-level process described in section 3.1.
3.6.3 DoDAF – Use of Common Artifacts to Represent Architecture
The DoDAF was established as a guide for the development of architectures and as a way of improving communications among all stakeholders during the design of complex systems.
The DoDAF provides the guidance and rules for developing, representing, and understanding architectures based on a common denominator across DoD, Joint, and multinational boundaries. It provides insight for external stakeholders into how the DoD develops architectures. The DoDAF is intended to ensure that architecture descriptions can be compared and related across programs, mission areas, and, ultimately, the enterprise, thus, establishing the foundation for analyses that supports decision- making processes throughout the DoD. (DoD 2007)
Dam describes the use of DoDAF as a methodology to develop and define architecture requirements from an integrated aspect. A select set of DoDAF views is required for new acquisition programs, which include All Views (AV), Operational Views (OV), System Views (SV) and Technical Views (TV). Although this approach has been used to create Navy Network Warfare Command (NETWAR) and C4I centric systems, it can also be used to provide a basis for combat systems. The primary consideration for selecting a model approach was a standard set of models and an understanding of data relationships, which allow traceability from a top-down or bottom-up approach. The DoDAF views are developed in an iterative manner from a mission need to a detailed component need. The views are capable of being supported when using SysML and provide a graphic depiction. The views are also capable of supporting an iterative or agile approach that allows decomposition to the level needed.
The process for development was based on review of existing models from external Programs of Record, papers written by Systems Engineering Institute (SEI) and literature by S. Dam, PhD.
3.7 SUMMARY
In this chapter, we have described the planned MBSE methodology to be used in developing complex system architectures. The methodology uses an agile approach to achieve high iteration/low duration development sequences, and integrates M&S to optimize design throughout development. It further integrates and provides a method for integrating supportability requirements into the system architecture. Finally, it uses a tool set to improve the validation and verification effort throughout the engineering developmental stage, which reduces manual efforts related to generation of engineering and programmatic artifacts. The method is based on using SysML, which will provide traceability in a top-down approach using MBSE principles regardless of tool selection.
In the following chapter, the methodology will be demonstrated using a PRA requirement
for developing an AAW combat system. It will include artifacts developed to meet engineering and architecture development processes. It will provide a baseline of expected versus actual results, and capture lessons learned which occurred during the learning phase.
4 METHODOLOGY APPLICATION AND VALIDATION
This chapter summarizes efforts executed in support of the proposed methodology described in Chapter 3. It documents and examines the results of applying the process to develop an Anti-Air Warfare (AAW) architecture to meet stakeholder requirements. The following sections provide detailed findings associated with the major process steps and products.Current Navy acquisition efforts use a variety of low and high fidelity models to design and modernize systems. The collaboration of users, owners, design engineers/logisticians, marketing organizations and acquisition offices produce system requirements. Requirements data is normally provided in the form of text files, graphics, tables, etc. Systems engineering uses the requirements data to generate a set of specifications, which need to be captured in different views that the community of interest can use with minimal misinterpretation.
Naval AAW systems have three primary functions: detect, control and engage (also referred to as Detect to Engage (DTE)). The AAW mission is complex and multi- faceted. AAW mission requirements were scoped down to address Surveillance, Self Defense (SD) and Limited Area Defense (LAD). A first order engineering analysis was performed to define the mission scope. Using the requirements and constraints, a functional architecture was developed using SysML, and a CORE model was developed to perform a proof of concept of the methodology.
Application of the methodology was affected by both the schedule and learning curves for the computer tools that were used. Due to schedule constraints, there were parallel efforts to develop SysML products, a proposed architecture, and DoDAF artifacts in CORE. This led to inconsistencies in the artifacts produced. Despite these
inconsistencies, the nodes of the system are consistent in that DTE is completed through Search, Detect, Command and Control (C2) and Engage functions.