SysML Products Generation and Analysis

As described in section 3.1.5, SysML was used to create artifacts documenting system requirements and design features. Although several SysML automation tools are used in industry, none were available for this project due to funding constraints. Instead, a SysML 1.0 template for Microsoft Visio was used to represent system design concepts in the modeling language. A summary of each diagram developed in the requirements process is given below.

4.2.3.1 Context Diagram

The context diagram was developed to define system boundaries and identify the actors and external systems that interact with the system. Figure 4-3 depicts a context diagram for the AAW system. External systems include personnel, communications, logistics, command activities, and engagement factors. The context diagram depicts the system and identifies interfaces that must be developed for successful interoperability. This diagram was developed in accordance with the scenarios in the AAW ConOps.

bdd AAW Context Diagram (with packages)

Command Activity

Threat

Other External Facilities

Training System Chain of Command Maintainers Operators Auxiliary Systems Environment AAW Combat System Off-Board Sensors Links External COMMS Navigation Intelligence pkg COMMS pkg Personnel pkg Engagement Factors pkg Command Activities pkg Logistics Supportablity Domain

Depicts the AAW system and the following external influences to the system: personnel, communications, logistics, command activities, and engagement factors.

4.2.3.2 Use Case Diagrams

The Unified Modeling Language (UML) use case diagram describes the major tasks the system must accomplish to achieve its overall goal. Figures 4-4 through 4-7 are the use case diagrams developed for the AAW system. The illustrations provide a portion of what would be provided to develop a complete use case. The use case descriptions provided in the following paragraphs would be included in a fully dressed use case. The use case diagram identifies the actors that use the system and captures the system behavior by showing internal functionalities, capabilities and dependencies. Use cases are goal-oriented and describe the workflow of a process instead of interactions among system components. The use case diagrams help system analysts understand the underlying problems to be solved and the objectives to be accomplished by the perceived systems.

For the combat system, use cases were used to form mission threads. Figure 4-4 is a multi-mission use case diagram that represents the many functions a warship command activity may engage in, such as AAW, Surface Warfare (SUW), Strike Warfare and Anti- Submarine Warfare (ASW). The diagram depicts a system with four possible mission capabilities: Engage in AAW, Engage in SUW, Engage in Strike Warfare, and Engage in ASW. The actors in these mission threads are identified as the Command Activity or the Environment/Threat. Each oval in Figure 4-4 describes a scenario depicting the interactions between the actors and the overall mission. The AAW mission threads (Surveillance, Self Defense and Limited Area Defense) are depicted in the AAW Mission Use Case diagram (Figure 4-5).

Depicts the possible mission roles in the form of a use case diagram.

Figure 4-4: Multi-Mission Use Case Diagram

Depicts the decomposition of the AAW mission in the form of a use case diagram.

Figure 4-6 is the Surveillance use case diagram and depicts the high-level search, detect and track functions required to perform the surveillance mission. The surveillance system could be a multi-function phased-array radar capable of search, automatic detection, transition to track, tracking of air and surface targets, and missile engagement support.

Figure 4-7 is the Self Defense and Limited Area Defense use case diagram. The high- level functions are Track, Command and Control (C2), and Engage functions. The functions can be performed by a combination of personnel, equipment, communications and facilities based on the level of automation required. The tracking function continuously determines and updates the location (bearing, range and elevation) and direction of a target which is then fed to C2. The C2 functions consist of planning, coordinating, directing, and controlling forces and operations to accomplish the mission. C2 additionally provides the human interface for control of system operation. C2 provides engagement orders and data for directing engagement. The output of the tracking system can be sent to a fire control system, which stores the information and derives the target's motion and its future position. The engage function provides the capability for decisions to be made by automatically based on doctrine. The actors in these mission threads are identified as the Operator and Air Track.

Depicts the decomposition of the surveillance mission in the form of a use case diagram.

Figure 4-6: Surveillance Use Case Diagram

Depicts the decomposition of the self defense/limited area defense mission in the form of a use case diagram.

4.2.3.3 Requirements Diagrams

The requirements process involves the elicitation, specification, prioritization and management of requirements. Traditionally, these requirements have been captured in natural language, which can be ambiguous and open to interpretation. SysML provides a method for representing functional and non-functional requirements, and their relationships with one another, in a hierarchical graphical form to reduce or eliminate ambiguity. SysML provides a bridge between natural language-based requirements and methods of functional allocation, such as activity and sequence diagrams. SysML requirements diagrams also support traceability of requirements during system modeling and specification. “Requirements traceability helps in identifying the sources, destinations, and links between requirements and models created during system development.” (Soares and Vrancken 2007) The requirements diagram is the first model in which effectiveness measures are identified and assigned values that allow designers to bound the solution space, evaluate the alternatives and discriminate the solution from competitor solutions (Friedenthal 2008).

Figure 4-8 is the AAW Requirements Diagram. In this diagram, the AAW mission is decomposed to display a parent-child relationship between AAW and its three functional areas: Surveillance, SD and LAD. Furthermore, the entire AAW mission is refined and supported by non-functional Supportability Performance Range Thresholds and Objectives. These mission areas and supportability concepts were packaged for further decomposition in follow-on diagrams.

Depicts the packages that support the AAW requirements in the form of a requirements diagram.

Figure 4-8: AAW Requirements Diagram

Figure 4-9, the Surveillance Requirements Diagram, illustrates the surveillance mission: to search for and detect air contacts to be further investigated by other functions in the system. The surveillance system performs a horizon or volume search and detects air contacts in a marine environment. Additional requirements were derived from these higher-level requirements, shown by the SysML “derive” relationship.

Depicts the requirements traceability for the surveillance package.

The SD and LAD mission areas are similar in functionality. The differences lie in the ability of the AAW system to perform point defense (defend against threats coming at ownship) and area defense (defend or cover another ship (a high value unit) operating in the vicinity of ownship). Both mission areas use surveillance air contact detections to track, command, control and engage targets determined to match threat profiles. First order analysis determined what geometries could be covered with the weapons and reaction times limitations identified in the ConOps. (Wagner et al. 1999) The following parameters were identified: detection ranges, reaction time of the system (including the speed of the weapons chosen), and potentially reduced PK of weapons based on aspect

angles of the threat.

Figures 4-10 and 4-11 decompose the LAD and SD mission areas, respectively. Functionally in a LAD role, the system shall defend HVUs from aerial threats with a specified PRA. Similarly, the system shall defend ownship from aerial threats in the SD

role.

Figures 4-12 and 4-13 define the threats and environments, respectively, in which the system will operate. To limit the scope of the mission, a single type of threat in a single type of environment was chosen. Because some lower-level requirements may be shared among many different threat types, the “copy” relationship is used in Figure 4-12. Both diagrams provide placeholders for additional types of threats and environments.

Text = “System shall defend HVU from aerial threats”

Id = “A.1”

«requirement»

Limited Area Defense

Text = “MOE: System shall defend HVU with Probability of Raid Annihilation = 0.99 against 6 evenly-spaced threats within 32 seconds” Id = “A.1.1”

«requirement»

LAD Pra

Text= “System shall create track based on valid detect” Id= “A.1.1.1”

«requirement»

LAD Track

Text= “System shall command and control tracks”

Id= “A.1.1.2” «requirement»

LAD Command and Control

Text= “System shall engage tracks” Id= “A.1.1.3”

«requirement»

LAD Engage

«trace»

Text= “Manage tracks within the system” Id= “A.1.1.2.1”

«requirement»

LAD Manage Tracks

Text= “Assign unique track ID” Id= “A.1.1.2.1.1” «requirement»

LAD Track ID

Text= “Monitor air tracks” Id= “A.1.1.2.1.3”

«requirement»

LAD Monitor Track

Text= “Select the best weapon against the given threats” Id= “A.1.1.3.1”

«requirement»

LAD Select Weapon

Text= “Ensure the weapon is fully supported” Id= “A.1.1.3.2”

«requirement»

LAD Manage Weapon

«refine» Text= “Interrogate track to identify if friend or foe” Id= “A.1.1.2.1.2” «requirement» LAD IFF Threat Environment «refine» «derive» «derive» «derive»

req Limited Area Defense

Master

Anti-Air Warfare

Surveillance

«trace»

Depicts the requirements traceability for the limited area defense package.

Depicts the requirements traceability for the self defense package.

Depicts the requirements traceability for the threat package.

Figure 4-12: Threat Package Requirements Diagram

Depicts the requirements traceability for the environment package.

Figure 4-14 defines the Supportability requirements, which are refined from the high- level Supportability Range and Performance Objectives and Thresholds in Figure 4-8. Supportability requirements are Key Performance Parameters (KPPs) in our methodology. Supportability provides system and personnel readiness. Readiness was further refined to the ILS elements, which would be modeled to support the required AO

(system operational availability to meet mission requirements). As the requirements diagram for Supportability is decomposed, factors such as testability, standardization, Human Factors (anthropometrics, training, etc.), redundancy, reliability, test equipment, technical documentation, supply support (Failure Modes and Effects Analysis (FMEA), Level of Repair Analysis (LORA)), sustainability, maintainability and upgradeability need to be addressed by the systems architect and design engineers.

Decomposition of requirements was shown throughout the SysML requirements diagrams developed for the AAW mission. Stakeholder needs were expressed in mission requirements for Limited Area Defense, Self Defense and Surveillance. Mission requirements were met through system requirements (i.e., PRA against specified threats)

and accomplished through component requirements (i.e., search and detect, track, C2 and engage).

4.2.3.4 Model Validation

Validation analysis was conducted for each developed artifact to ensure the integrity and feasibility of AAW system requirements. Validation efforts consisted of maintaining requirements traceability throughout the systems engineering process. CORE and SysML models were used as primary tools for requirements validation. Both models established parent-child relationships for verifying requirements flow down and were utilized to validate requirements allocation to functions for hardware, mission and software. Validation analysis generated feedback which was used to update the model artifacts. The validation process continued as data from each artifact was input into the automated CORE tool (described in section 4.6). CORE products were used to ensure

that all follow-on models were developed using the same terminology and to guarantee model traceability back to the originating requirements.

Depicts the requirements traceability for the supportability, performance range, thresholds and objectives packages.