System Definition

The system defined in this report is an AAW system used to illustrate that MBSE can support an approach to meet the required Anti-Ship Cruise Missile PRA. The ConOps

(Appendix G) breaks the AAW problem into scenarios from which requirements have been captured in SysML artifacts. The program management plan raises questions about implementation of the systems engineering process for SPL development and the challenges it poses for the Navy. SPL designs are flexible, extensible, and feasible. The success of future software design relies on the ability of the software system to support reuse of source code. Oliver provides a collection of processes and information models. One of the approaches calls for views used to understand information for defining behaviors, functions, and data flow. These views are represented as both requirements and architecture. (Oliver et al. 1997) The Hatley-Pirbhai (HP) approach was chosen for the software architecture specification necessary to support the AAW architecture. Figure 4-25 represents the decomposition of the system specification; the HP method provides a process to determine relationships between requirements and architecture. (Hatley et al. 2000)

Decomposition of the system specification into software and hardware.

Figure 4-25: Software and Hardware System Specification Structure

The HP method was developed specifically for design, development, and decomposition of multi-disciplinary systems. The model allows for representations of physical interconnections, information, material, and energy movement between systems/components. Systems must operate in and interact with the real world, and they do so through different types of technology – electrical, mechanical, hydraulic, pneumatic, optical, radio, and many others. Moreover, these technologies interact with each other independently of software, in both intended and unintended ways. (Dorset House 2008)

The HP method is an extension of structured methods which include architecture models, information (data) models, and control flow models, and supports bottom-up as well as top-down design. A valid comparison for the HP method is a set of architectural prints for a house that includes and ties in all the appropriate views from which tradesman and craftsman could build. All models are tied together via a data dictionary. The models can be thought of as a tool kit to help designers understand a complex system so it can be designed and built. The models can also be used as a communications tool to help explain the system to others, including the customer and users. (Rickman 2000)

The Navy’s traditional AAW architecture employs a Detect to Engage (DTE) approach for the control of sensors and the release of weapons. This functional formulation was used in the development of the Aegis and SSDS combat systems. The systems architecture was based on a shared memory concept. The limitations of this approach included dependency on legacy programming language (Aegis used CMS2 language – not many colleges teach this), limited scalability and extensibility (hardware choices were specific and unique) and high cost to modify (software and software retesting were projected to break the bank). The transformation to OA creates a foundation for future war fighting capabilities. Additionally, the open computing environment allows for modern programming languages (C++, JAVA etc), modular functional allocation, and libraries of common services (defined components).

Both Aegis and SSDS have been re-architected to allow for the use of COTS products and the use of a layered communication approach. To minimize the cost of updating systems, a layered architecture is an appropriate choice. Layered architecture provides for modularized layers, which are relatively easy to update and are cheaper to adapt new technologies. An Analysis of Alternatives (AoA) (Appendix I) and a Software Integrated Product Team (IPT) Report (Appendix J) support a layered architecture approach for combat systems.

Layered software architecture is a prevalent approach used by client-server and web- based systems. It helps to structure applications that can be decomposed into n groups of subtasks in which each group is at a particular level of abstraction with well-defined interfaces. The ith layer could communicate with only the (i-1)th and the (i+1)th layer. Layered architecture is widely used in most web-based systems where performance is a critical factor. (Sharmal et al. 2005)

Rather than focus on point-to-point functional and physical interfaces, the layered architecture concept recognizes the need for continuous and concurrent combat system

data processing. What are important are the information being produced and the responsibility for its creation and dissemination. For example, the core layer consists of several components for the system’s functions (Figure 4-26). The AAW core layer includes sensor management services, track management services, weapons management services, and TEWA services. Functions are assigned unique responsibilities; Sensor Management produces unique sensor system information and broadcasts this information as messages throughout the system. Each function has access to its appropriate layer from which to perform its responsibility.

In the AAW domain, information is generated upon change from a development view; the functional independence provided by a layered architecture removes the complications of sequential function coordination and communication. The communication hierarchy is developed from a commercial standard from which information can be shared. From this form of functional independence, it is easy to develop physical independence in the form of distributed processor architectures. A review of legacy systems, such as Aegis and SSDS, indicates that this approach allows for massive amounts of computing power to be focused where and when it is required. As systems grow, the addition of new system functions can be integrated into the system information (new processors that follow proper protocols can be added to the system to add capability). (Johns Hopkins APL 2001)

The layered architecture concept recognizes the need for continuous and concurrent nature of combat system data processing.

Data entities and attributes are assigned to particular and unique functions within the layered architecture. This allows for clear separation of the contributions from each function. System information has a distinct source, directly related to a specific portion of software and traceable to specific message output to the data distribution architecture. (Johns Hopkins APL 2001) Benefits of using layered architecture with combat systems include low-latency, high-throughput, high-scalability, deterministic responses, and minimal consumption of network, processor, and memory resources.

Predictable distribution of data with minimal overhead is of primary concern to real-time applications (AAW and the requirements for ship self-defense apply). Since resources are finite, it is important to be able to determine available resources and implement policies that allow middleware to apply the resources to the most critical requirements. There are new standards on the market that address middleware and time data distribution requirements. (OMG 2008) To maintain accuracy in data calculations, data must be time stamped when it is either measured or created. This can be used to indicate valid or accurate time which can be used in later processing. Latency can be thought of as the delay from data measurement to the subsequent processing of the data. The ability to detect and form a track in rapid succession is where latency really becomes a concern. The AAW system described herein has about six seconds from which to gain firm track and engage with weapons. The AoA details quality attributes and uses measures and weights to evaluate architecture requirements.

A layered architecture supports an OA environment that takes advantage of COTS protocols and time-to-market of new products. Developing software for every change can be expensive and time-consuming – a faster and cheaper software development approach is necessary. SPL refers to a software engineering method and techniques for creating a portfolio of similar software systems from a shared set of software assets using a common means of production. (Krueger 2008) When developing software for complex systems, identifying and/or creating commonality can be difficult. Layered architecture facilitates commonality with its well-defined interface requirements that make modularity

possible. Layered architecture places software applications in layers by their sub-level functions such as data handling. For software applications in a layer to communicate with others in different layers, all software applications in the layer need to meet the same interface requirement. That is, the same lines of code that satisfy interface requirements exist in each software application to communicate with other layers. For example, sensor management service and track management service in the core layer must have the same lines of code to communicate with the middleware layer and the user interface layer. The approach of assigning the role of meeting the interface requirements to the common lines of code is the key to designing the AAW software system for a SPL.

4.4.1.1 AAW Architecture Discussion

The Context Diagram in Figure 4-3 illustrates a shipboard AAW system. There are many relationships with other systems required in order to meet Navy AAW requirements. To constrain these relationships, the AAW system is viewed as a black box with a limited view of inputs/outputs and interfaces.

Figure 4-27 identifies AAW functions using the HP architecture template. For study purposes, the context of this system has been reduced and the AAW system can be viewed as stand-alone, i.e. no outside interface is required to reach a solution for PRA.

The boundaries and limitations illustrated in the ConOps are meant to limit the answer of the question of PRA (and supportability requirements). The intent is not to decompose the

problem down to specific hardware and software components (lines of code). The AAW problem is viewed as an operational challenge, and the solution will be an academic view of the logic required. Where appropriate, HW/SW/PW will be used to illustrate what could be accomplished if further decomposition was accomplished.

1.Sensing 2.Cueing 3.Correlation 4.Classification 22.Energize Missile 23.Ignite Propulsion 24.Missile Fly Out 25.Missile Comms 26.Engagement Scheduling 27.Illuminator Scheduling 28.Terminal Homing 5.Establish Track 6.Firm Track 7.Correlation/ID 8.Threat Evaluation 9.Weapon Assignment 10.Establish Firing Doctrine 11.Select Director

12.Final Engage ability 13.Fire Control Solution 14.Missile Selection 15.Cell Selection 16.Determine Engage Solution

17.Final ID confirm 18Final Launcher Order 19.Check-Hold Fire/BRK 20.Engage

21.Kill Assessment 29.System Health Manager Display/Decision Authority Diagnostics Ship Interfaces Power/Water/Gyro/NAV Environment Target Missile Missile Comms Core Processing Input Processing Output Processing User Interface System Interfaces Search & Detect Track C2 Engage

The context of this system has been reduced and the AAW system can be viewed as a stand alone, i.e., no outside

interface is required to reach a solution for the probability of raid annihilation (PRA).

Figure 4-27: AAW Architecture Model (Hatley-Pirbhai 2008)

A thorough understanding of AAW behaviors is required to support DTE, and the Navy has amassed a large body of research to determine activities/behaviors required for AAW systems. The Navy Tactical Data List (3.0) was developed to understand what behaviors are required for various mission requirements. A review of this document and an academic review of Detect-Control-Engage functions allowed for the development of the AAW HP Architectural Model Template. The functions are derived from the SE3123 Time Range Information. (Green 2008b)