Process Specifications

PSPECs are primitive specifications provided as structured English descriptions that use “shall” statements to describe the way in which they transform input information into desired outputs. PSPECs are functional requirements of the EDFD0. Each process bubble has corresponding PSPECs (Table 4-3). In this architecture development model, the PSPEC’s input and output data flows represent all those to/from that process. It is essential to the goal of an open architecture that modules designed and produced by different manufacturers will interoperate and interface seamlessly. The PSPEC encapsulates each process’s internal operational behavior and exposes only the external interfaces.

Table 4-3: PSPECs

2.1 Process Search/Detect Input Flow(s):

Detect Criteria

Engage Target Data Request

Output Flow(s): Raw Data Status Description:

This process shall be responsible for interface with shipboard sensors. It shall provide raw data report to the track process as requested via a detect criteria set forth by the command and control process. Engagement data shall also provide to the kill assessment process. Search and Detect status shall be provides to the manage process.

Functional Requirement(s): a) Sensing b) Cueing c) Correlation d) Classification 2.2 Process Operator Input Flow(s): Status Output Flow(s): System Interface

Description:

This process shall be human and machine interface. It shall be the avenue of interaction of ship force with the AAW system via combat display consoles.

Functional Requirements: a) Display b) Decision Authority 2.3 Process Track Input Flows: Raw Data Criteria for ID Output Flows: Track Criteria

Rank Threat Summary List Tracks

Status Description:

This process shall be responsible for creation of track database compiled from the raw data provided by the search/detect process. It shall provide a ranked threat summary list set forth by the criteria for ID from the command and control process. The process shall also provides status to the manage resources process.

Functional Requirements: a) Establish Track

b) Firm Track c) Correlation/ID

2.4 Process Command and Control Input Flows:

Track Criteria

Rank Threat Summary List Illumination Request Output Flows: Criteria for ID Detect Criteria TEWA Kill Status Description:

This process shall be the set detection criteria for the search/detect process. It shall perform the TEWA functions and provide kill status to the kill assessment process. It shall plan and direct track database with criteria for ID and detection criteria to the search/detect process and the track process. It shall provide illumination function to the engage process.

Functional Requirements: a) Thread Evaluation b) Weapons Assignment c) Establish Firing Doctrine d) Select Director

e) Final Engage Ability f) Fire Control Solution g) Final ID Confirm h) Final Launch Oder i) Check-Hold Fire/BRK j) System Health Manager 2.5 Process Kill Assessment Input Flows:

Kill Status Resource Status

Output Flows:

Kill Evaluation Results

Engage Target Track Data Request Status

Description:

This process shall perform kill assessment function from engagement track data provided by the search/detect process. It shall update the command and control process with a kill status report. System status shall be monitored via the resource management process.

Functional Requirements: a) Kill Assessment

2.6 Process Manage Weapons Resources Input Flows: TEWA Output Flows: Engagement Order Status Description:

This process shall manage onboard missile assets. It shall determine the proper missile and cell selection for engagement process. System status shall be monitored via the resource

management process. Functional Requirements: a) Missile Selection b) Cell Selection

c) Determine Engage Solution d) Engage

2.7 Process Manage Resources Input Flows:

Status

Output Flows: Resource Status Description:

This process shall provide shipboard interfaces and provide status the sensor/detect process, track process, command and control process, kill assessment process, and the engage process. It shall monitor the health of shipboard resources such as power, water, gyro, and NAV.

Functional Requirements: a) Diagnostics b) Ship Interfaces b) Power/Water/Gyro/NAV 2.8 Process Engage Input Flows: Engagement Order Tracks Output Flows: Illumination Request Status Description:

This process shall be responsible for routing the engagement order from Command and Control to the missile launching platform. It shall track and update missile status during the initial stage, homing stage, and the terminal stage. It shall upload illumination of threat to the missile. System status shall be monitored via the resource management process.

Functional Requirements: a)Energize Missile

b) Ignite Propulsion c) Missile Fly Out d) Missile Comms

e) Engagement Scheduling f) Illuminator Scheduling g) Terminal homing

The Process Control Table (Table 4-4) maps the output action of the AAW system FSM to corresponding PSPECs. The control signal activates and deactivates all the matching processes of the PSPECs. For example, the control action receiver energy activates PSPECs 2.1 and 2.3. The process/control mapping binds the static data model to the behaviors of the control model. This methodology completes the system requirement model of the HP structure analysis.

Table 4-4: Process Control Table

Mapping Control Action to Data Process

Process Control Search/Detect 2.1 Operator 2.2 Track 2.3 Command and Control 2.4 Kill Assessment 2.5 Manage Weapon Resources 2.6 Manage Resources 2.7 Engage 2.8 Search and Detect 1 0 1 1 0 0 0 0 Track 0 0 1 1 0 0 0 0 Perform TEWA 0 0 0 1 1 0 0 0 Receive Energy 1 0 1 0 0 0 0 0 Fire Weapon 0 0 0 1 0 1 0 1 Perform Kill Assessment 0 0 0 1 1 0 0 0 Save System States 0 0 0 0 0 0 1 0 Restore System States 0 0 0 0 0 0 1 0 Update Display 0 1 0 1 0 0 0 0

In a simple system, an architecture module might not need further breakdown because the process that is allocated to the architecture module might be enough to generate the desired outputs. However, a complex system like AAW cannot be described with one level of a process in the architecture module. Another example of how the HP process can help is provided in an example, illustrated in Figure 4-37. The sensor process is named Search & Detect. When a process message request from Cueing tells Sensing to sense for objects, the module needs to correlate and classify the sensed object data to prepare a detection report. There are four necessary processes to generate the output of the sensor module. DFD2 (Figure 4-37) shows the four sub-level processes and data flow.

EDFD2 (Figure 4-38) shows external entities of the sensor module such as operator process and C2 process. These external entities give commands to sub-level processes of the sensor module. The operator process sends a system mode signal to turn on or off the sensor. The C2 process starts the cueing process by sending a request. An EDFD of the architecture module presents a complete picture of how data flows in the system. The views enhance the reader’s understanding of control and data flow, conveying required information of system architecture.

The Architecture Flow Diagram (AFD) shows data and control flows among architecture modules defined in Figure 4-39. All flows have already been defined in EDFD (Figure 4- 38). In Figure 4-39, all processes in EDFD were allocated to architecture modules, which were represented as super bubbles. All data and control flow lines shown in Figure 4-38 are lines that connected super bubbles in Figure 4-39.

First level of decomposition

Figure 4-37: Search and Detect DFD2

Second Level of decomposition

Architecture Module Data Flow

Figure 4-39: AAW AFD0

The Architecture Interconnect Diagram (AID) (Figure 4-40) illustrates the physical channels for exchanging information such as data and control. It depicts the allocation of data and control flows to channels. The proposed AAW system in this study was designed to use Transmission Control Protocol/Internet Protocol (TCP/IP), requiring the system to be smart enough to send information to where it is needed. This approach offers the advantage of reducing the amount of cable installations needed. AID shows one common bus that is connected to all architecture modules. To remove any ambiguity, all flow-to-channel allocations are recorded in the architecture dictionary (Table 4-5).

Operator

Manage Resource

7.2: AID0, AAW System

Sensor Weapon Weapon Management Processing Track Processing C2 Central Processing Data Bus Data Bus Data Bus Data Bus Data Bus Data Bus

Architecture Module Data Bus Interconnection

Figure 4-40: AAW AID

Table 4-5: Architecture Dictionary

Name Definition/Physical Description

Type Source Destination Channel

Detect Report

Current location and speed of

detected objects Data Sensor

Track Processing Common Bus Track Report

Calculated estimated heading and speed + current course + past course