By Ron Kratzke, Principal Systems Engineer
Over the past year there has been an increased interest in performing “Mission Engineering” during initial concept development. This has come about for many reasons, one of which is an effort to ensure that subsequent operational and system architectures – and the systems developed to support them – are aligned with and support the missions for which they were designed in the first place.
So what is a mission? The Merriam-Webster dictionary defines mission as: “4. (a.) a specific task with which a person or group is charged; (b) a definite military, naval, or aerospace task; (c) a pre-established and often self-imposed objective or purpose.” (Retrieved January 8, 2017.)
The Department of Defense defines mission engineering as “the deliberate planning, analyzing, organizing, and integrating of current and emerging operational and system capabilities to achieve desired warfighting mission effects.” Mission engineering (as opposed to mission analysis) examines the design and adaption of systems of systems to meet the mission objectives. This approach leads to the “planning, analyzing, organizing, and integrating” of operational and system capabilities. Therefore, mission engineering includes but goes beyond traditional mission analysis to include an analysis of the operational architecture and the supporting systems architecture (nominally a system of systems architecture).
How, then, do we handle mission engineering in CORE / GENESYS?
The model-based systems engineering (MBSE) approach and schema used in CORE / GENESYS provide for capturing missions in the MISSION class. The features and workflow described in this article provide a structured way to examine mission architectures and make first order decisions regarding the completeness of the architecture and identification of areas for more detailed analysis using specific operational research models and techniques.
In the operational architecture domain of the schema, the following relations are established:
An ARCHITECTURE “achieves” a set of MISSIONs. And, any one MISSION may include a subset of discrete MISSIONs, so we use the “includes” relation to provide for the decomposition of an abstract MISSION into more discretely defined MISSIONs.
A mission may also be related to a set of operational tasks. In some instances, we may actually be starting with a set of operational tasks which were identified by an executive organization for accomplishment. And, we may want to relate these tasks to current missions and goals, or create a set of new missions and goals supporting the operational tasks (which would be the future architecture that we are planning to achieve). To support this need, the operational architecture schema provides the following relations:
Given a mission set, the system architect must derive the operational behavior necessary to accomplish the mission or missions. An operational activity is an action or process needed to fulfill a mission, task, or role in an operational architecture. The system architect must define or derive the operational behavior – represented by these operational activities – to support the mission as shown in the following diagram:
The OPERATIONAL ACTIVITY class is a logical element in the schema and as such, the system architect can construct and visualize this behavior using either the activity diagram or enhanced functional flow block diagram (EFFBD). Operational activity models are directly executable using the simulator feature in CORE or GENESYS, which validates the operational activity dimension of the mission engineering.
To this point we have related a set of desired mission objectives and goals to an operational activity architecture to support these missions. What operational requirements need to be defined to describe and support the operational activities? The operational requirements are captured in the CAPABILITY class in the schema, which is related to MISSIONS and OPERATIONAL ACTIVITIES as shown in the following diagram:
The work flow described here supports the overall concept of mission analysis by providing traceability from a desired architecture to a set of missions and the operational functions (or activities) needed to satisfy the mission.
The user can examine alternative mission architectures constructing two ARCHITECTURE entities. Let’s call them Architecture Version 1 and Architecture Version 2. Each architecture may have a different set of missions, and each mission set may have a unique set of operational activities. Leaf level MISSION entities and/or leaf level OPERATIONAL ACTIVITY entities can be used in different combinations between the two architectures to compare the two alternatives.
Once the analysis team has narrowed their alternatives, additional analysis – conducted by specific analysis techniques and models – can be used to refine the overall architecture.
