05S-SIW-106. Simulation and Software Development for Capabilities Based Warfare: An Analysis of Harmonized Systems Engineering Processes

Transcription

1 05S-SIW-106 Simulation and Software Development for Capabilities Based Warfare: An Analysis of Harmonized Systems Engineering Processes Sarah Trbovich Richard Reading VisiTech, Ltd. 535A East Braddock Rd. Alexandria, VA Keywords: Federation Development and Execution Process (FEDEP), Department of Defense Architecture Framework (DoDAF), Model Driven Architecture (MDA), Systems Engineering (SE) ABSTRACT: As the Navy shifts toward a capability-based vice platform-based military, the lines separating the development of systems, software, and simulation become blurred. An ever-closer connection between system software development and system modeling and simulation can make it difficult to distinguish a line of divergence between their respective engineering processes. However, multiple approaches and processes have already been codified for architecting Navy systems, software, and simulations. Correlating the systems engineering (SE) processes used to develop these Navy products is important for understanding capability composition and complete interoperability. Three examples of the different system engineering processes were chosen for analysis: the Federation Development and Execution Process (FEDEP), Department of Defense Architecture Framework (DoDAF) and Model Driven Architecture (MDA). FEDEP is an IEEE standard for interoperable simulation development, DoDAF is the U.S. Department of Defense common approach for architecture description and MDA is the Object Management Group s (OMG) process for software centric development. Each represents a different perspective of the systems engineering process and the associated products. It is important to understand how these processes can be aligned, and the relationships between their respective SE products, particularly in their early stages. A better understanding of the processes connections will enable a cleaner development process of modeling for interoperability. This paper will describe connections among MDA, DoDAF, and FEDEP and discuss ways to leverages those connections to move forward with a capabilities-based systems engineering process for the Navy. 1. The Navy s Movement The increasing improvement of technological capabilities in the past decade has surpassed the Navy s ability to stay current. The cost of developing and upgrading systems has penetrated the core of the American Government. With the cost of hardware decreasing, the cost of software is remaining constant. As unique hardware systems grow obsolete they are replaced by high-performance, generalpurpose hardware computing platforms. As hardware evolves into ubiquity, consequently concentration on software development has become the critical path for implementing a capability. Unfortunately, the increasing slope of industry technology is outweighing the Navy s maintenance capacity for its current software and computing systems. The Navy is faced with viciously intertwined oppositional factors: Capabilities-based warfare for post-cold war environments require flexible, composable operational capabilities that can be rapidly improved. Technology improvements continue at a fast pace. Technology improvements feed threat improvements that force development of new capabilities. Technology improvements should feed capabilities improvements that keep pace with threat developments.

2 But, right now: The Navy develops and deploys new/upgraded systems at a slow pace. The improvement cost of developing and upgrading systems is currently very large. Acquisition still revolves around physical platforms (ships, planes, subs), not capabilities. Currently, advancements in technology highly outpace the Navy s ability to develop and deploy new/upgraded systems. Yet, the Navy recognizes that technology improvements should be harnessed to achieve capability needs. The above issues are driving a need for change in the way software application development is approached. The Navy is therefore embarking on an essential adjustment to the way it adapts to technological changes. This adjustment will require interoperable software and open architectures. Operational needs must define how military capabilities will be composed and decomposed on a dynamic basis, particularly in-theater. In joint and coalition environments the challenge is greater; therefore, the need for open architectures is greater. To support these network centric operations, software creation must go beyond fabricating interoperability for platforms (e.g. ships, aircraft, submarines, UAVs), and create synergistic warfighter capabilities independent of their performance or execution platform. Unfortunately, the move toward interoperable software and open architectures is one of increased learning and inevitable cultural hardship. These changes will not happen overnight. 2. Systems Engineering for Capabilities Based Acquisition & Development The reality of implementing software with a systems engineering process is not a novel concept. It is, however, a significant paradigm shift when viewed from a perspective of capabilities vice platform based warfare. The Navy is shifting toward open architectures for software to realize capabilities that are (see Figure 1): independent of the military platform(s) on which they are implemented, to be operationally effective, independent of the computing platform(s) on which they are executed, to be cost effective. Figure 1. Warfare driving toward capabilities independent of performance and execution platform These requirements compel the systems engineering process to factor questions such as how will the functionality be distributed across platforms? and how will the warfighter capabilities be implemented independently? Fold into this environment an everincreasing reliance on simulation to explore, design, trade, exercise, and even test capabilities. Further recognize that the same technology improvements facilitating open architectures are also causing differences between system software and simulation software to blur; the line of

3 divergence for creating software vice simulation is becoming nominal. What is needed is a path for a clear SE process by which capabilities and subsequent functionalities are documented, understood, modeled, simulated and executed in a testing environment. The type of process required should include: articulation of problem space and warfighter requirements, illustration of requirements through uses cases, definition of functional domains and associated functions to achieve warfighter requirements, relationships of functions (dependencies, interoperability, clustering, etc.), a clear view of operational requirements and the success in implementing the operational requirements at any stage in the process (testing is key), an architectural vice platform focused design approach that allows functions to be realized independently of both military and computing platforms. Each of the items listed becomes vital to achieving the end goal of interoperable software. Furthermore, these products will inherently answer the question of what does interoperable software for the Navy entail? There are multiple variations on a systems engineering process that have been expressed for both software and simulation development. Without a clear delineation between system/simulation software, an obvious question is how well do these processes align? Many aspects of the implementing a capability problem have been addressed elsewhere. Therefore, the concentration for this paper is the front-end systems engineering. This is not the normal focus for software development; more development and headway has been made in the congruency of execution environments. Yet, it is the early-stage systems engineering where commonality and connectivity among capabilities, systems software, and simulation can be most easily discerned. To examine process and process-products alignment, we have selected three processes used for simulation, operational software and systems architecture. The representative processes are the Model Driven Architecture (MDA), Federation Development and Execution Process (FEDEP), and Department of Defense Architecture Framework (DoDAF). MDA and FEDEP are two accepted SE processes that focus on operational systems and simulation systems. DoDAF is broadly accepted in U.S. DoD community and provides a significant source of narrative requirements. This information follows a natural flow down to software and simulation developments that is advantageous to our analysis. DoDAF is not a process per se, but the representative products are very comparable with SE process products. More so, it was thought that the DoDAF products might yield some added glue for the comparison of front end SE processes for system/simulation software. With the line between operational software and simulation software dissolving, aligning DoDAF with both the MDA and FEDEP processes can reveal important commonalities. 2.1 The M&S Systems Engineering Process The Federation Development and Execution Process is a systems engineering process that supports development of distributed simulation systems that comply with the IEEE 1516 High Level Architecture (HLA) for simulation interoperability. The FEDEP guides the spiral development of the simulation system through phases of requirements, conceptual modeling, design, software development, integration, and execution.

4 Figure 2. FEDEP process connections The FEDEP in outline is portrayed in Figure 2 with a toplevel process diagram of the seven steps and the product relationships between them. However, for this analysis, the concentration will be on the early stage system engineering products represented by steps 1 and 2. Step 1 of the FEDEP defines the federation objectives, which include the identification of needs and the development of objectives for the federation environment. This step of the SE process documents what the federation is supposed to accomplish and defines the requirements for the federation. The output from Step 1 establishes the parameters for Step 2, the development of the federation conceptual model. The conceptual model is a key product in developing the federation. It involves documenting the test scenario and performing the conceptual analysis of the requirements in the defined problem space. It is noted that conceptual modeling products typically incorporate graphical representations. These can include UML based products that capture the federation requirements in the form of use cases. These use cases can verify the fidelity of the requirements articulated in Step 1. Hence, the early FEDEP stages include a flow from narrative descriptions to graphical descriptions of the federation s required functionality. 2.2 Model Driven Architecture (MDA) MDA is the Object Management Group s (OMG) process for software centric development. What separates MDA from other software development processes is its approach to IT system specification that separates the specification of functionality from the specification of the implementation of that functionality on a specific technology platform. [3] Model Driven is a means for using models to direct the course of understanding, design, construction, deployment, operation, maintenance and modification. [3] Therefore, the development of the system of systems is based on the requirements of each model, independent of the interconnections. Architecture is the system specification of the parts and connectors of the system and the rules for the interactions of the parts using connectors. [6] As a result, the architecture is driven by the individual development of the models rather than vice versa.

5 Figure 3. Customized MDA Process [7] In Figure 3, a customized MDA process shows a course for interoperable software development. It is worth differentiating the term platform in an MDA context from a warfighter s typical understanding of the word. In an MDA context, a platform is not a military machine (plane, ship, UAV), but rather is defined thusly: Platform is the specification of an execution environment for a set of models. [3] It can also be described as a set of subsystems/technologies that provide a coherent set of functionality through interfaces and specified usage patterns that any subsystem that depends on the platform can use without concern for the details of how the functionality provided by the platform is implemented (i.e. Java, C++). [5] The MDA process begins with a number of users [1 n], depending on who are operational users of the system. These users will verbalize the narrative requirements of the system which include a clear definition of the problem space and the operational requirements in textual form. These textual requirements are then developed in a graphical form to construct the Computational Independent Model (CIM) 1 and verified through testing. The CIM is a UML description of the system including 1 Computation Independent Model A view of a system focusing on the environment of the system and the requirements of the system. Sometimes called the domain model. [5] software, hardware and procedural items with no details of structuring or processing of the system. The CIM 2 commonly utilizes use cases to produce this description, but can be accompanied by sequence diagrams, etc. for further detail. This marks the systems engineering of the MDA process and the most critical piece to ensure the software fidelity. Yet, this portion of the MDA process is not explicitly explained nor is it explicitly carried forward as the primary focus for software development. Typically, the focus of MDA is more toward the software engineering of the textual and graphical requirements. The hardware and procedural items are set-aside as nonsoftware program requirements that will later be used as a foundation for the constraints of the system. The software requirements are documented in UML with class diagrams to form a description of the software focusing on the operation of the system; operation to include the attributes and behaviors of the models. Because this procedure is performed independent of the execution platform, this is called the Platform Independent Model 2 Use Case A use case defines a goal-oriented set of interactions between external users and the system under consideration or development. Use cases have become a widespread practice for capturing functional requirements in software design, especially in the object-oriented community where they originated, but their applicability is much wider. [5]

6 (PIM). 3 The validity of the PIM is verified through testing the class diagram descriptions with the use cases formed in the CIM. The final developmental piece of the MDA process is the Platform Specific Model (PSM). 4 This model combines the PIM with a focus on the detail of each specific platform of a system. The number of PSMs is not limited. One PIM is created and mapped according to the hardware and procedural constraints from the CIM to develop multiple PSMs. These models are tested again through verification and moved into implementation for code development. The implementation segment coincides with the number of PSMs. Each implementation is executed and tested for verification through the original user. Throughout the MDA process, testing is the focal point for success. Testing must be centralized to ensure the user s requirements match the software implementation. Note: Testing and verification is a key player in MDA. However, it must begin with the first stage to have success. Too often, the focus of developers is more concentrated in the software development of the tangible boxes starting with the PIM stage. To begin development and testing of the model in this stage starts a downward spiral in the process. Instead of testing the functionality of the system against the given operational requirements and problem space, it is too often a test of the software capabilities amalgamated with a requirements analysis (are the stated requirements even the right ones?) It is true that analysis of requirements will happen in latter stages; however, it should not be the primary focus. Emphasis in performing steps 1 and 2 will guide toward a higher fidelity in the model and increase confidence that the resulting software achieves the required military operational capability. Many different aspects of the software developmental process are currently being addressed. M&S within the Model Driven Architecture [4], is a good example of a successful analysis of the back-end fixes to communication between existing systems. All analysis to better develop or operate systems will have an impact on the software community. The consensus from this analysis is software development would greatly benefit from a concentration on the front-end documentation. The use of MDA can alleviate common problems in software development. One example is a common description of the problem. Language and development process differences between systems engineers and developers can cause discrepancies between requirements and implementation. MDA resolves this issue by using a Unified Modeling Language within one model from beginning to end. Another common problem is the creation of a persistent, evolved model for all stakeholders. Inconsistencies can arise when more than one model is used for development. With MDA, one model is utilized in development from the requirements thru implementation. The trick is to follow the process faithfully, focusing hard on early process stages and ensuring the one model is built/documented/tested starting at the requirements stage, not the PIM. 2.3 Department of Defense Architecture Framework (DoDAF) DoDAF is the United States Department of Defense common approach for architecture description. DoDAF is formally defined as a common approach for DoD architecture description development, presentation, and integration for both warfighting operations and business operations and processes. [5] DoDAF is characterized to ensure that architecture descriptions can be compared and related across organizational boundaries, including Joint and multinational boundaries. [5] Three views document the required information for an architectural description in DoDAF: Operational View, Systems View and Technical Standards View. Figure 4 displays the three views with relationship dependency to one another. 3 Platform Independent Model A model of a subject matter whose metamodel represents abstractions from more than one platform models; A model of a subsystem that contains no information specific to the platform, or the technology that it is used to realize it. [5] 4 Platform Specific Model A model that incorporates details about platforms; A model of a subsystem that includes information about the specific technology that is used in the realization of it on a specific platform, and hence possibly contains elements that are specific to the platform. [5]

7 Figure 4. DoDAF views and relationships Operational Architecture View The operational architecture view is a description of the tasks and activities, operational elements, and information flows required to accomplish or support a military operation. [8] In this view, you will find graphical and textual products that identify the operational requirements of architecture design. Also, the needs of operational nodes are recognized as well as the information flows required for exchanging information between nodes. The DoDAF description fully documents the activity, type, and all relevant information of the exchange. Systems Architecture View The systems architecture view is a description, including graphics, of systems and inter-connections providing for, or supporting, war-fighting functions. [8] This view illustrates an association to the Operational Views documentation with resources for system performance. The system view is thought to facilitate the exchange of information among operational nodes. [8] Technical Standards Architecture View The technical architecture view is the minimal set of rules governing the arrangement, interaction, and interdependence of system parts or elements, whose purpose is to ensure that a conformant system satisfies a specified set of requirements. [8] This view serves as the implementation guidelines including a collection of the technical standards, implementation conventions, standards options, rules, and criteria organized into profile(s) that govern systems and system elements for a given architecture. [8] The three views of DoDAF described above follow a standard systems engineering process involving: documentation of requirements in a textual and graphical form, identification of attributes and behaviors of those requirements, and development of a design to fulfill those requirements architecturally. Because DODAF is the U.S. application for architecture development, these products may already exist or partially exist for any proposed new or improved warfighting capability. 3. Processes connections The three systems engineering processes described in the previous section have been successful within their particular community. FEDEP, MDA, and DODAF are separate, but alignable developmental processes. Each follows a basic systems engineering process by analysis is done in the following areas: Definition of requirements Definition of attributes and behaviors through a functional analysis of the requirements Expression of requirements, functions and analysis in narrative and graphical form Design of the product Whether the product is a simulation federation, operational software, or systems architecture, the general process by which the end goal is accomplished particularly in the early stages is the same. Figure 5 below illustrates a mapping from DoDAF and FEDEP products to the process of MDA. Notice most of the work is pointing toward the Narrative Requirements and CIM boxes. With concentration on the first two stages of the development process, the rework percent will decline and the validity of the model will increase.

8 DoDAF MDA Alignment FEDEP MDA Alignment Figure 5. Relationship of MDA with DoDAF and FEDEP Merging the two diagrams of Figure 5, a harmonized SE process is illustrated in Figure 6 which includes all of the three processes products in an MDA customized format.

9 Figure 6. FEDEP, DoDAF and MDA connection User to Narrative Requirements The harmonized SE process begins with the user of the system. The user of the system will define the textual description of the problem space, which develops the narrative requirements. From DoDAF, this portion of the process is AV1 (scope, purpose, etc.), OV1 (textual description of the operational concept) and OV2 (information exchange need lines). Each one of these views gives insight to the description of the problem space. Similarly, the FEDEP aligns with the narrative requirements in its documentation (Federation Objectives Statement, planning documents such as a Test & Evaluation Master Plan or Capstone Requirements Document). In this step, the needs of the federation are declared. CIM Next, the narrative requirements are turned into a CIM, or a graphical description through use cases. DoDAF aligns to this section with OV2 (information exchange need lines), OV3 (information exchanged and attributes), OV4 (organizational role and relationships), OV6b (operational state transition description) and OV6c (operation eventtrace description). While all information may not be necessary, the documentation is useful in creating use cases to define the system. FEDEP aligns with the CIM with use case documentation in the System Engineering Concept Model devised federation requirements. PIM In MDA, the software program requirements are taken from the CIM and used to create the PIM. For DoDAF, this is a similar process, by which several OVs and SVs are utilized: OV7 (system data requirements and structural business process rules), SV1 (systems interface description), SV3 (systems of systems matrix), SV4 (systems functionality description) and SV10b (system state transition description). Notice, the functional allocation of the system is described in the PIM. The FEDEP uses the CIM use case information to create a model view PIM comprised of class diagrams depicting attributes and behaviors to be modeled in the federation. This process determines the required mathematical models and algorithms; however, functionality is not yet allocated to specific federates. Constraints Constraints in MDA are the hardware and procedural requirements that constrain the architecture development. Likewise, DoDAF has two views which fulfill the same function: OV6a (operational rules model) and SV10a (systems rules model). PSM The PSM in MDA involves mapping the PIM to specific execution computer platforms. For DoDAF, two views fall in alignment because the information produced is for system-specific and physical architecture: SV10c (systems event-trace description) and SV11 (physical schema). For the FEDEP, the PSM is the functional allocation of the federates. This is also where the FOM and Federation Agreements are devised. These documents develop specific federation guidelines. Implementation Because DoDAF is not implemented in a testing environment in the actual DoDAF process, it does not align with the Implementation portion of MDA. However,

10 FEDEP would align in the context of spiraled federate modifications that execute the developed PSMs. Implementation for FEDEP includes federation integration and execution. Testing Throughout the different steps of the customized MDA process, testing is essential to ensure fidelity of the models. Testing verifies and validates the narrative requirements from the user with the development of the CIM, PIM, PSM and the implementation of the model. 5. Summary & Way Ahead The U.S. Navy is responding to the post-cold-war coalition environment by moving to a capabilities based approach to warfighting. In the midst of this, the Navy is also battling to keep up with technology and losing. In response, it has shifted the acquisition focus toward more open architectures that rely on interoperable systems and modular software components. This tasking will require a clear SE developmental process to answer the important question of what does interoperable software for the Navy entail? To proceed successfully, it is necessary to have an understanding of current SE processes and the correlation of their products. Currently, system creation is habitually setback due to a lack of understanding of the problem space. This is exacerbated by the introduction of capabilities based development, which demands interoperability, modularity, platform independence, distributed processing, and composable capabilities. These requirements can be realized through an alignment of operational requirements documentation (DoDAF) with a simulation testing environment (FEDEP) in a platform independent development process (MDA). It is particularly apparent that commonalities in the front end systems engineering will be an extremely important leverage point for success. It is imperative that the developmental process be one concentrated on central knowledge of the required capability. Use of an aligned SE process will enhance communication between architectural developers and software experts. Furthermore, it will improve confidence that the software requirements are in sync with the actual operational warfighting requirements. Because software is conducive to testing in a simulation environment, aligning the simulation and software SE processes will enhance the probability that the requirements for the simulation are harmonized with the development requirements of the software. Therefore, testing software development in a simulation environment could prove advantageous in discovering developmental changes early in the process enabling design-for-interoperability as opposed to troubleshooting implemented software in later testing venues. References [1] IEEE 90 Institute of Electrical and Electronics Engineers. IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY: [2] IEEE Standard [3] OMG MDA Guide V pdf. [4] Andreas Tolk, James A. Muguira: M&S within the Model Driven Architecture, I/ITSEC 2004,Orlando, FL [5] Mellor, Stephen J., Scott, Kendall, Uhl, Alex, Weise Dirk, MDA Distilled: Principles of Model-Driven Architecture. Portland, OR: Book News, Inc., [6] Merriam-Webster Online. [7] Unpublished work by Stan Grigsby. grigsby@visitech.com. [8] DOD Architecture Framework Version 1.0, Volume II: Product Descriptions, DOD Architecture Framework Working Group, August Author Biographies SARAH TRBOVICH is an engineer with VisiTech, Ltd. She received a B.S. degree in Electrical Engineering from the Georgia Institute of Technology. She is currently providing technical leadership and support to HLA federation developments for U.S. Navy ship combat system testing, as well as other multi-national efforts applied to systems acquisition. RICHARD READING is the Systems Engineering Division Lead with VisiTech, Ltd. He provides technical expertise to the U.S. Naval Sea Systems Command, SEA61, in support of Navy Open Architecture development and the Joint Single Integrated Air Picture (SIAP) Systems Engineering Office (JSSEO). He is also the system engineer for the Navy P RA Assessment Testbed, which is being used to conduct virtual end-toend testing of U.S. Navy ship combat systems in support of ship class operational evaluation. He is currently the U.S. industry representative to the NATO Sub-Group 61 on Virtual Ships.