SOBRE ACTIVIDADES INDUSTRIALES: Se refiere al impuesto que deben pagar todos los establecimientos

The HP methodology is a graphical method used to identify an AAW system’s functions and its physical partitioning. The HP structure methods separate the AAW system specification into two models: requirements (data model & control model) and architecture. The requirements model describes what the AAW system should do, while the architecture model describes the entities in the AAW system and the allocation of requirements to hardware, software, and people. The HP methodology was chosen for the AAW system architecture due to its strong emphasis on software reuse as well as its bottom-up and top-design approach to system specification. The HP descriptive models (artifacts) can be compared to the DoDAF artifacts as outlined in Appendix K.

A set of Data Flow Diagrams (DFDs), and control and process specifications provide the basis of the AAW system requirement model. The model captures the core requirements of the AAW system, which are technology agnostic (independent of specific technology). The intent is to determine system behavior to arrive at a specification. The enhanced requirements model adds to the core model requirements for input, output, user interface, and maintenance/self test processing.

The architecture model was derived from Navy AAW activities and from basic Detect- Control-Engage functions. From this view and further decomposition, the Architecture Context Diagram (ACD), Architecture Flow Diagram (AFD), and Architecture Interconnection Diagram (AID) were developed. The ACD depicts the physical boundaries of the AAW system. The AFD shows the physical entities, called modules, in the AAW system. The AID illustrates the interconnections of modules in the AAW system.

The HP Model Development Process, depicted in Figure 4-28, consists of the following (Haggerty 2000):

1. Development of system core requirements, including context diagram, DFDs, EDFDs, control specs, and process specs

2. Enhancement of requirements

3. Determination of the architecture modules for the system

4. Allocated processes and control specs from the enhanced requirements to architecture modules using super bubbles

5. Drawing the core requirements for each module in the system

6. Enhancing the module core requirements as necessary for inter-module communication, new user interfaces, and maintenance/self-test

7. Drawing the flows and interconnections on the AFD and AID based on the boundaries of the enhanced module requirements.

The HP structure method separates the AAW system specification into two models: requirements (data model & control model) and architecture. The requirements model describes what the AAW system should do, while the architecture model describes the entities in the AAW system and the allocation of requirements to hardware, software and people.

4.4.3.1 System Requirement Model

The Logical Architecture is illustrated as a single function to show the external inputs and outputs and is represented by the System Context Diagram. The system context diagram, Figure 4-29, was developed using the ConOps document. Once the boundaries were identified, the next step was the decomposition of the AAW system and the creation of the Data Flow Diagram (DFD) to demonstrate that the next level of process bubbles in the system could be developed. These bubbles were then further decomposed into lower levels. At the lowest level of this decomposition are the actual Process Specifications (PSPECs). The Logical Architecture was then mapped to a Physical Architecture that assigns the logical processes to physical subsystems and service packages. This mapping is documented in the Physical Architecture Data Dictionary.

The AAW Data Context Diagram (DCD) illustrates the high-level interactions of AAW as a stand-alone system with the various external and environmental inputs/outputs. The diagram is a derivation of the SysML requirement Context Diagram. The constraints and limitations of the AAW system are outlined in the ConOps document and further refined by the system requirements. The diagram represents all external entities that may interact with the AAW system.

Threats and atmospheric data are captured from the environment and fed to the AAW System. Atmospheric conditions can affect the performance of the AAW system and can be confused with threat data; clutter tracks can mask real tracks. Other assets within the limited area of influence require protection. The AAW system interacts with the operator via display consoles providing assessment and control of area defense.

The Data Flow Diagram Level 0 (DFD0) (Figure 4-30) illustrates the functional architecture of the AAW system and shows the system as processes. The DFD is designed to show how a system is divided into smaller portions and to highlight the flow of data between those parts. This context-level DFD shows more detail of the system

being modeled. It provides a structural visualization of the main functionalities of the AAW system software architecture and how the AAW system is implemented. The diagram shows core process data flows within the functions of AAW, which include search/detect, track, C2, and engage.

Limited Area Context Based

Figure 4-29: AAW Context Diagram

The DFD is designed to show how a system is divided into smaller portions and to highlight the flow of data between those parts; initial data flow diagram.

The Enhanced Data Flow Diagram Level 0 (EDFD0) applies the architecture template to the AAW processing functions. The template adds input/output, human machine interface, and support process activities to the requirement functions presented within the DFD0 diagram for a complete AAW capability. The four enhanced regions of the template contain processes, behaviors, and items for the physical interface with the system environment. (Hatley and Pirbhai 2000) The diagram completes the system’s enhanced requirement model of the HP model development process. The template is broken up into five separate and distinct regions of processing.

For example, search/detect is a logical input to Track processing and is found in the input processing section of the template. The intent is not to arrive at specific hardware at this level of decomposition, but rather to show that Search and Detect are main functions. From the name of the process, there is no way to understand how the AAW system will handle all the detections and how they will be distributed throughout the system. Search/Detect is comprised of many sub–functions (Figure 4-31). What, how, and when must be answered, and to meet the requirements described in the ConOps, the system must be able to distinguish if and when it detects a target and if it can be distinguished from other objects.

It is via this process that sub-functions are discovered; specifically, sensing, correlation, and classification are required before determining a valid detection has been made. An object could be anything in space that provides energy back to the system. The energy has to be correlated to other energy (contacts) and further classified to avoid confusion with other contacts. The same process of discovery would be used to explore all the functions in Figure 4-30. The inputs/outputs/control/data flows must be evaluated to describe performance and control. The descriptions can then be used to build the Search and Detect specification. The functions and behaviors of search and Detect require further breakdown and extensive study to allocate to a correct sensor for this function.

Process applied to HP template

4.4.3.2 Control Specifications

The completion of the AAW System Requirement Model entails the development of the AAW System Control Model. The Control Model captures the major operating modes of the AAW System. The behavioral aspects of the AAW System are captured in the Finite State Machine (FSM). It interacts with the Data Model through control flows and by enabling/disabling processes from the DFD of the Data Model.

The Control Specifications (CSPECs) are used to indicate how the software behaves when an event or control signal is activated and which corresponding processes of the Data Model are invoked. It represents the behavior of the AAW System in two ways. The CSPECs contains a state transition table that is a sequential specification of AAW system behavior. It also contains a process activation table mapping the Data Model processes to the AAW System FSM control state.

Figure 4-33 provides a control view of the Enhanced Data Flow Diagram Level 0 and is a CSPECs artifact. It highlights the behaviors of the EDFD0, providing better fidelity of AAW architecture behavioral functionalities. The AAW System FSM consists of two modes: normal and diagnostic. In normal mode, there are three states: continuous, idle, and active. The event trigger causes the AAW system to transition from state to state. For example, in the normally idle state, an engagement request from command and control triggers the FSM to transition to an active state. In this state, AAW deploys a weapon, then transitions back to idle upon a trigger event of perform kill assessment. It transitions back to active only if kill assessment determines the need for a new engagement action. In the continuous state, in addition to search and detect, tracking functions are also performed with criteria set by command and control in a continuous manner. The trigger event to the idle state is an engagement order from command and control. The diagnostic mode is a subset FSM of the AAW system. It consists of test engage order and test deployed weapon. The diagnostic mode is a function of the shipboard training and system health assessment.

Continuous

Idle Active

H

Engage Order / Fire Weapon

Deployed Weapon / Perform Kill Assessment Destroyed Target Engage Order /

Perform TEWA

Leaked Target / Receive Energy Search and Detect

in Progress

Track in Progress Lay up

AAW Finite State Machine

Test Engage Order Test Deployed Weapon

Engage Order / Update Display

Deployed Weapon / Update Display

Return / Restore System States Diagnosis / Save System States

Test Search and Detect in Progress / Search and Detect

Test Track in Progress / Track Test Termination Normal Mode Diagnostic Mode Track Test Track in Progress Diagnostic

Diagnostic

Search and Detect Test Search and Detect in Progress Diagnostic

Diagnostic

Update Display Deployed Weapon

Test Engage Order Test Deployed Weapon

Update Display Engae Order

Test Deployed Weapon Test Engage Order

Resotre System States Return

Idle Test Engage Order

Save System States Diagnosis

Test Engage Order Idle

Perform Kill Assessment Deployed Weapon Idle Active Fire Weapon Engage Order Active Idle Receive Energy Leaked Target Continous Idle Perform TEWA Engage Order Idle Continous Track Track in Progress Continuous Continuous

Search and Detect Search and Detect in Progress Continuous Continuous ACTION EVENT TO STATE FROM STATE

AAW State Transition Table 6: EDFD0, AAW Capability

2 Search/ Detect 9-19 C^2 9 Manage Weapon Resources 5-8 Track Raw Data Display 22-28 Engage System Mode 21 Kill Assessment 29 Sys. Health Management TEWA Status Status Track Criteria Criteria for ID Status Ranked Threat Summary List Detect Criteria Status Tracks Kill Status Kill Eval Results

Engage Target Track Date Request Illumination Request System Mode Status Engagement Order Select Weapon Deploy Weapon Status

Data and Control Model Relationship

Continuous

Idle

Active

H

Engage Order / Fire Weapon

Deployed Weapon / Perform Kill Assessment

Destroyed Target Engage Order /

Perform TEWA

Leaked Target / Receive Energy Search and Detect

in Progress

Track in Progress Lay up

Test Engage Order

Test Deployed Weapon

Engage Order / Update Display

Deployed Weapon / Update Display

Return / Restore System States Diagnosis / Save System States

Test Search and Detect in Progress / Search and Detect

Test Track in Progress / Track Test Termination Normal Mode Diagnostic Mode

AAW Behavior Model

The State Transition Table (STT) (Table 4-2) depicts all the AAW system FSM changes of state. The change of state is triggered by an event derived from control flow. The control flow can originate from internal or external sources. It can be triggered by time, such as a periodic scan for threat in a defined perimeter. It can also initiate from internal processes such as command and control requesting an engagement order. The action column is the result of the trigger event causing the state machine to create a control signal to activate a process within the EDFD. The process activator enables the corresponding processes to execute the required functions.

Table 4-2: AAW State Transition Table

FSM state transition events and action (control)

Track Test Track in Progress

Diagnostic Diagnostic

Search and Detect Test Search and Detect in Progress

Diagnostic Diagnostic

Update Display Deployed Weapon

Test Engage Order Test Deployed Weapon

Update Display Engae Order

Test Deployed Weapon Test Engage Order

Resotre System States Return

Idle Test Engage Order

Save System States Diagnosis

Test Engage Order Idle

Perform Kill Assessment Deployed Weapon Idle Active Fire Weapon Engage Order Active Idle Receive Energy Leaked Target Continous Idle Perform TEWA Engage Order Idle Continous Track Track in Progress Continuous Continuous

Search and Detect Search and Detect in Progress

Continuous Continuous ACTION EVENT TO STATE FROM STATE

AAW State Transition Table

The Architecture Flow Context Diagram (AFCD) (Figure 4-34) shows the high-level flows and interconnects linking the various external and environmental inputs/outputs to the AAW system. The AFCD repackages the context diagram and keeps the input and output relationships. The diagram illustrates the data flow among the entities of the input processing (threat, atmospheric conditions), user interface (operator), output processing (weapon), and AAW system.

AAW High Level Architecture Context Diagram

Figure 4-34: AAW AFCD

The Architecture Flow (without data flows) Diagram Level 0 (AFD0) in Figure 4-35 establishes the derived software architecture modules from the system-enhanced requirements spec of the EDFD. This diagram focuses on core processing. In the context of the study problem track, C2 and weapons management require complex processing to maintain a tactical picture in the timelines specified given that the system will operate in

a marine environment. This results in a plethora of combinations of environmental conditions including friendly and enemy ships and aircraft and land masses. Given the magnitude of the problem, a separate study could be undertaken to determine if it makes sense to combine these processes. For this project, however, the intent was to maintain a relationship with the detect-control-engage paradigm.

Software functions are grouped into modules illustrated in the diagram and allocated to their respective processors. At this stage, hardware choices are not required because a deeper understanding of the behaviors is still being uncovered to meet requirements. This initiates the next step of the development model to showcase SPL templates based on the modulation of the AAW system architecture.

The EDFD in Figure 4-36 illustrates the allocation of processes to super bubbles or to seven architecture modules. Super bubbles in the EDFD represent architecture modules that are created based on the potential for a shared resource. The super bubble (Module 1) groups both the C2 and Kill Assessment (KA) processes, and contains all individual processes included in C2 and KA.

AAW Module Grouping

The seven architecture modules are:

ƒ Module 1 (C2 Central Processing Module & KA): This module contains all functions of C2 and KA. C2 resides in module 1. The KA process was also included in Module 1 because of the processing required to ascertain if the target that C2 engaged has been destroyed. The C2 and KA processing should have low coupling and high cohesion. With low coupling, a change in one module will not require a change in the implementation of another module. Low coupling is often a sign of a well-structured computer system, and when combined with high cohesion, supports the general goals of high readability and maintainability. The KA function is only required to be invoked when a target is engaged and a weapon is fired; the track is maintained by C2 and, at the appropriate time, KA reviews and analyzes it for relevant dynamic behavior. KA provides a confidence that the track is no longer viable or killed. If so, C2 does other work; if not, C2 must re-engage to attempt to kill the target again. C2 and KA processes must have a continuously stable interface to ensure requirements can be met.

ƒ Module 2 (Sensors Module): Includes functions of sensors. Search and detect process is allocated.

ƒ Module 3 (Weapon Management Module): Includes functions of weapon assignment and missile selection. Manage weapon resources process is allocated. ƒ Module 4 (Weapons Module): Includes functions of missile communication and

energizing missiles. Engage process is allocated.

ƒ Module 5 (Operator Procedures Module): Includes functions of command inputs and display. Operator process is allocated.

ƒ Module 6 (Manage Resource Module): Includes functions of monitoring computers in the system. Manage resources process is allocated.

ƒ Module 7 (Track Module): Includes functions of tracking. Track process is allocated.