CERS_NR-KPP_20120105.doc

CERS NR KPP

UNCLASSIFIED

CERS NR KPP

UNCLASSIFIED

Appendix A Net Ready KPP for

Consolidated Emergency Response System Ver 1.1 5 January 2012 Appendix A - Integrated Architecture Products and Net Ready KPP

1. Introduction This Appendix presents the Integrated Architecture Products and the analysis that constitute the Net Ready KPP (NR-KPP) for the Consolidated Emergency Response System (CERS). The NR-KPP will be used to assess information needs, information timeliness, information assurance, and net-ready attributes required for exchange of information and the end-to-end operational effectiveness. The NR-KPP elements include:

· NR-KPP Compliance Statement

· Mandatory Integrated Architecture Products

· Net-Centric Data and Services Strategy

· GIG Technical Guidance (GTG)

· DOD IA and Critical Infrastructure Protection (CIP) Requirements

· DOD Supportability

CERS is a non-tactical system exclusively supporting emergency management command and coordination of First Responders. CERS shall reside on a dedicated purpose-built emergency services Internet Protocol (IP) data network that is physically and logically separated from routine business traffic.

2. Net-Ready KPP Compliance Statement Table 1: Net-Ready KPP Compliance Statement

1) Solution architecture products compliant with DOD Enterprise Architecture based on integrated DODAF content, including specified operationally effective information exchanges

2) Compliant with Net -Centric Data Strategy and Net-Centric Services Strategy, and the principles and rules identified in the DOD Information Enterprise Architecture (DOD IEA)

3) Compliant with GIG Technical Guidance to include IT Standards identified in the StdV-1 and implementation guidance of GIG Enterprise Service Profiles (GESPs) necessary to meet all operational requirements specified in the DOD Enterprise Architecture and solution architecture views

4) Information assurance requirements including availability, integrity, authentication, confidentiality, and non-repudiation, and issuance of an Interim Authorization to Operate (IATO) or Authorization To Operate (ATO) by the Designated Accrediting Authority (DAA), and

5) Supportability requirements to include GPS and Spectrum requirements.

CERS will support execution of all operational activities and information exchanges identified in DOD Enterprise Architecture and solution architectures based on integrated DODAF content, and will satisfy the technical requirements for transition to Net-Centric emergency response operations to include:

1) Solution architecture products compliant with DOD Enterprise Architecture based on integrated DODAF content, including specified operationally effective information exchanges

2) Compliant with Net –Centric Data Strategy and Net-Centric Services Strategy, and the principles and rules identified in the DOD IEA

3) Compliant with GIG Technical Guidance to include IT Standards identified in the StdV-1 and StdV-2, and implementation guidance of GESPs, necessary to meet all operational requirements specified in the DOD Enterprise Architecture and solution architecture views

4) Information assurance requirements including availability, integrity, authentication, confidentiality, and non-repudiation, and issuance of an ATO by the DAA, and

5) Supportability requirements to include GPS and Spectrum requirements.

3. Compliance with Net-Centric Data and Services Strategy CERS complies with the DOD Net-Centric Data Strategy and DOD Net-Centric Services Strategy for net-centric services and data shared within the emergency response and emergency management community.

The architecture products for CERS describe the net-centric activities applicable to the system to establish, use, operate, and manage the system capabilities within the net-centric enterprise information environment to include: the user interfaces, the intelligent-assistant capabilities, the net-centric service capabilities, and the enterprise management components.

CERS complies with the DOD Net-Centric Data Strategy and DODD 8320.2 Data Sharing in a Net-Centric Department of Defense requirements and intent. The data produced and used by CERS will be shared only within the emergency response and emergency management community of interest. CERS has identified the Communities of Interest (COIs) as being pertinent: Installation Emergency Management (IEM).

CERS data and services must be secure. CERS data assets shall have associated security metadata and an authoritative source for the data identified. CERS semantic, structural, and security agreements for service sharing shall be provided through the emergency response and emergency management community.

CERS data and services must be interoperable only within emergency response and emergency management community.

4. Mandatory Integrated Architecture Products The following supporting Integrated Architecture products are presented in accordance with CJCSM 3170.01C and CJCSI 6212.01E. The DOD Architecture Framework Version 2.0 provides the data-centric build sequence and architecture format that has been used to develop the CERS Integrated Architecture.

4.1. CERS All Viewpoints

The All Viewpoints (AV) provides an executive summary, information overviews for all viewpoints, where the architecture fits in relationship to other architectures, and is a central source for definitions used in the integrated architecture.

A. CERS Overview and Summary Information (AV-1)

CERS AV-1:

B. CERS Integrated Dictionary (AV-2)

CERS AV-2:

4.2. CERS Operational Viewpoints

The Operational Viewpoints (OV) are typically focused on human and organizational interactions, and DoDAF-described Models except when human beings are considered an integral part of the system’s operation and functionality (e.g., system operator versus system user).

A. High-Level Operational Concept Graphic (OV-1) The purpose of CERS is to provide an equitable and standardized level of emergency First Responder coordination as is specified for the public safety of civilian populations outside of military installations. CERS supports the dispatcher who receives, processes, and manages emergency calls in a 24/7/365 environment. CERS utilizes a dispatch workstation with specialized technologies for receipt, processing and management of calls for service, achieving and maintaining situational awareness, radio communications and mapping. CERS also interfaces with external systems that relate to emergency response such as Mass Notification, Intrusion Detection Systems (IDS) and Fire Alarms. Voice communications between dispatchers and first responders will be provided by Enterprise Land Mobile Radio (E-LMR).

Figure 1: CERS High-Level Operational Concept (OV-1)

B. Operational Resource Flow Description (OV-2) The OV-2 DoDAF-described Model applies the context of the operational capability to a community of anticipated users. The primary purpose of the OV-2 is to define capability requirements within an operational context. The OV-2 expresses a capability boundary and describes a logical pattern of resource (information and personnel) flows.

CERS OV-2:

C. Operational Resource Flow Matrix (OV-3)

The CERS OV-3 details information exchanges and identifies “who exchanges what information, with whom, why the information is necessary, and how the information exchange must occur.” There is not a one-to-one mapping of OV-3 information exchanges to OV-2 needlines; rather, many individual information exchanges may be associated with one needline. The CERS OV-3 identifies information elements and relevant attributes of the information exchange and associates the exchange to the producing and consuming operational nodes and activities and to the needline that the exchange satisfies.

CERS uses E-LMR and other wired and wireless infrastructure to transport voice and data between the dispatch center and First Responders.

CERS OV-3:

D. Organizational Relationships Chart (OV-4) The OV-4 illustrates the command structure or relationships among operational roles or organizations in the CERS integrated architecture. Interactions illustrate the fundamental roles and management responsibilities, such as supervisory reporting, command, coordination, collaboration that pertain to the scope of the architecture.

CERS OV-4:

E. Operational Activity Decomposition Tree (OV-5a) and Activity Model (OV-5b) The OV-5a describes the capabilities and operational activities organized in a hierarchal structure.

The OV-5b describes the context of capabilities and operational activities and their relationships among activities, inputs, and outputs.

CERS OV-5a:

The Context diagram establishes the scope of the CERS architecture and identifies the relationship between the internal activities and those external activities that provide input to or receive output from CERS internal activities. It is based on the Mission Assurance Operational Activity Model and includes those operational activities to provide context and consistent numbering convention for CERS.

Gray rectangles represent external activities with provide input/receive output from CERS internal activities, but are outside the scope of this architecture. These activities are performed by external Operational Nodes as depicted in the OV-2. Information exchanges that are generated by external activities contain the _Ext_ prefix.

The yellow rectangle represents operational activities preformed within the CERS framework and is decomposed into a series of more detailed OV-5 diagrams.

E.1 OV-5 Conduct Mission Assurance The OV-5 Conduct Mission Assurance describes the operations that are normally conducted in the course of achieving a mission or a business capability. It describes capabilities, operational activities (or tasks), input and output (I/O) flows between activities, and I/O flows to/from activities that are outside the scope of the architecture. Mission Assurance (Green Rectangles) activities are depicted for context and to retain a consistent numbering scheme. Diagrams only depict those information exchanges that are relevant to CERS. The Mission Assurance Architecture provides details missing in these diagrams.

Conduct MA Preparation--"Actions taken to manage and coordinate mission assurance program elements. (OAG Oct 09) Respond to Crisis--Taking measures to identify, acquire, and plan the use of resources needed to resolve a threat or an act of terrorism or natural disaster.

E.2 OV-5 Conduct Mission Assurance Preparation

The OV-5 Conduct Mission Assurance Preparation diagram provides an operational activity view of the Mission Assurance Preparation Process. It describes capabilities, operational activities (or tasks), input and output (I/O) flows between the elements of the Preparation Process, and I/O flows to/from activities that are both internal and outside the scope of the architecture. The yellow rectangles depict the single element of the Mission Assurance Preparation Process that supports CERS: Provide Communications.

Provide communications includes providing, maintaining and distributing data and information by any means.

E.3 OV-5 Respond to Crisis

The OV-5 Respond to Crisis provides an operational activity view of the essential crisis response activities. It describes capabilities, operational activities (or tasks), input and output (I/O) flows between the crisis response activities, and I/O flows to/from activities that are both internal and outside the scope of the architecture.

Respond--Conduct efforts to minimize the short-term direct effects of an incident threatening life, property, environment, or critical systems.

E.4 OV-5 Respond

The OV-5 Respond depicts efforts to minimize the short-term direct effects of an incident threatening life, property, environment, or critical systems

Manage Emergency Response--The process required to dispatch, monitor, and track the day-to-day movement of emergency services personnel and equipment to all types of emergency and non-emergency incidents.

E.5 OV-5 Manage Emergency Response The OV-5 Manage Emergency Response depicts the process required to dispatch, monitor, and track the day-to-day movement of emergency services personnel and equipment to all types of emergency and non-emergency incidents.

Maintain Situational Awareness--The action taken by the commander to remain knowledgeable on the status of his own force, that of the enemy commander's force and the nature of the area of operation. Maintaining situational awareness involves monitoring, or the continuous observation of the current situation to identify opportunities for the force, threats to the force, gaps information, and progress according to the plan or order. For example, by locating and gaining contact with the enemy, the commander collects information about the enemy's location, disposition, and movement to gain an advantage and be less vulnerable to surprise.

Evaluate Threat--To evaluate emergency response requirements.

Dispatch Emergency Services Resources--Direct the appropriate emergency services resources (fire, police, EMT) to designated location in response to alarm or emergency call.

Maintain Records--Manage records of all emergency calls and dispatches.

Conduct Translation--Provides immediate high-quality, effective interpretation and translation of all major languages. Thus, the dispatcher with the assistance of the foreign language service representative will be able to render emergency response services to any non-English speaking caller.

Inputs prefaced with _C_ indicate controls which express conditions required to produce correct output.

Inputs prefaced with _M_ indicate Mechanisms which depict means used to perform a function. Mechanisms in this model are mapped to OV-2 Nodes and are detailed in the OV-3.

See the AV-2 for detailed descriptions of the inputs.

F. Event-Trace Description (OV-6c) OV-6c describes Operational Activity or business process responses to sequences of events. Events may also be referred to as inputs, transactions, or triggers; and can be internally or externally generated and can include such things as the receipt of a message, a timer going off, or conditional tests being satisfied.

The OV-6c uses Business Process Modeling Notation (BPMN) to depict sequence flows between Operational Nodes conducting processes. Each Swimlane is mapped to an Operational node and each process is mapped to operational activities. Sequence and Message flows are traceable to OV-5 ICOMs. The OV-6c reads from left to right and depicts time sequence in relative terms. Sequence flows (blue lines) depict the relative sequence of information exchanges between processes that are performed in each swim lane. Message flows (black dashed lines) depict flow of messages between two separate Process Participants. An Event is represented by a blue circle and is something that “happens” during the course of a business process. These Events affect the flow of the process and usually have a cause (trigger) or an impact (result).

In this scenario, an explosion occurs within a populated area. Base residents report the incident by calling 911. The Dispatcher receives the call and evaluates the scenario. Based upon his situational awareness he dispatches the appropriate fire, police and emergency medical personnel to the scene. The Dispatcher also informs the caller that emergency responders are enroute and provides Emergency Medical Dispatch which instructs the caller on actions to take before the responders arrive.

As responders arrive, they assess the situation and request assistance from the Watch Commander. The Incident Commander establishes the Incident Command System to coordinate all responding units. This coordination may also include civilian Law Enforcement, fire and emergency medical assets from the local communities if required. Law Enforcement secures the location and establishes a crime scene to facilitate investigation of the incident.

The Installation staff establishes the Emergency Operations Center in accordance with the SOPs, and begins crisis action planning. The EOC conducts coordination with civilian Law Enforcement, Fire and Emergency Services as required.

CERS OV-6c:

4.3. CERS System Viewpoints

The System Viewpoints (SV) are DoDAF-described Models that describe the design for system-based solutions to support or enable requirements created by the operational development processes (JCIDS) and Defense Acquisition System.

A. Systems Interface Description (SV-1) The SV-1 depicts systems nodes and the systems resident at these nodes to support organizations/human roles represented by operational nodes of the OV-2. The SV-1 also identifies the interfaces between systems and systems nodes. SV-1 links together the OV and SV by depicting the assignments of systems and systems nodes (and their associated interfaces) to the operational nodes (and their associated needlines) described in OV-2. OV-2 depicts the operational nodes representing organizations, organization types, and/or human roles, while SV-1 depicts the systems nodes that house operational nodes (e.g., platforms, units, facilities, and locations) and the corresponding systems resident at these systems nodes that support the operational nodes. The SV-1 has been divided into two separate diagrams to improve resolution.

CERS SV-1:

B. Systems Resource Flow Description (SV-2) The SV-2 depicts pertinent information about communications systems, communications links, and communications networks. SV-2 documents the kinds of communications media that support the systems and implements their interfaces as described in SV-1. Thus, SV-2 shows the communications details of SV-1 interfaces that automate aspects of the needlines represented in OV-2. While SV-1 depicts interfaces between systems or systems nodes, SV-2 contains a detailed description of how each SV-1 interface is implemented (e.g., composing parts of the implemented interface including communications systems, multiple communications links, communications networks, routers, and gateways). Communications systems (e.g., switches, routers, and communications satellites) are systems whose primary function is to control the transfer and movement of system data as opposed to performing mission application processing. The SV-2 has been divided into two separate diagrams to improve resolution.

CERS SV-2:

C. Systems-Systems Matrix (SV-3) The SV-3 provides a tabular summary of the system interactions specified in the SV-1 Systems Interface Description model.

CERS SV-3:

D. Systems Functionality Description: Taxonomic Functional Hierarchy (SV-4a) The SV-4 addresses human and system functionality. This diagram depicts the CERS system function hierarchy. All systems functions except Receive Call and Manage Law Enforcement, Fire and Emergency Response Records originate from the Joint Common System Function List. Those two systems functions are unique to CERS.

CERS SV-4a:

E. Systems Functionality Description: Data Flow Diagram (SV-4b) The SV-4 addresses human and system functionality. Within an Architectural Description, the SV-4 documents system functions, the Resource Flows between those functions, the internal system data repositories or system data stores, and the external producers and consumers for the system data flows, but not those external to the Architectural Description scope. This diagram depicts the System Context Data Flow Diagram. The context diagram depicts the top level of the functional decomposition diagram and includes all sub functions. All relevant functions are included in the decomposition of the CERS Context diagram. The notation depicting three dots at the top of a system function indicates that there is a child diagram underneath containing additional detail.

The yellow rectangle represents the top level of CERS system functions. Gray rectangles depict external functions that performed by external system nodes. Arrows depict resource flows and are traceable to the SV-6.

E.1 SV-4 Manage Emergency Response The SV-4 is used to specify the functionality of resources in the architecture (in this case, functional resources, systems, performer and capabilities). The SV-4 is the behavioral counterpart to the SV-1 Systems Interface Description (in the same way that OV-5b Operational Activity Model is the behavioral counterpart to OV-2 Operational Resource Flow Matrix).

This diagram depicts the four major groups of CERS system functions. Each function has its JCSFL designation where appropriate. Each function on this diagram is further decomposed into a child diagram. System functions include:

· Maintain Shared Situational Awareness. This function is used to update and maintain common situational awareness utilizing shared information provided by the Global Information Grid (GIG). (JCSFL 3.4.5)

· Control Communications. This function provides optimum operation of communications equipment/systems and controls the use of communication protocols that interface user services with physical communication systems. (JCSFL 7.1.39)

· Control Mission. This function generates the controls and inputs necessary to control the employment of the force weapons, sensors, and platforms. (JCSFL 6.1.9)

· Manage Data – Group. This group contains all functions related to data management including actions taken with data, actions performed on data, storage and manipulation of data, and employing guidelines with data. (JCSFL 8.7)

E.2 SV-4 Maintain Situational Awareness

This function is used to update and maintain common situational awareness utilizing shared information provided by the Global Information Grid (GIG). System functions include:

· Receive, Store and Maintain Geospatial Product Information. This function receives, stores, and maintains National Geospatial-Information Agency (NGA) geodesy information such as Digital Nautical Charts (DNC), Digital Terrain Elevations Data (DTED), and Digital Aeronautical Flight Information File (DAFIF) data. (JCSFL 3.4.3)

· Maintain and Display Unit and Platform Status Information. This function maintains and displays status information on units and platforms specified. (JCSFL 3.2.14)

· Query Data. This function locates information in response to a query request and supports the subsequent data retrieval for the requestor. (JCSFL 8.7.8)

· Perform Collaboration. This function allows users to collaborate in the form of white boarding, instant messaging, video or other forms of visual and audio communication. (JCSFL 8.12.3)

E.3 SV-4 Control Communications

This function provides optimum operation of communications equipment/systems and controls the use of communication protocols that interface user services with physical communication systems. Major functions include:

· Disseminate Time Data. This function disseminates time data. (JCSFL 8.7.23)

· Monitor and Report Communication Networks Status. This function monitors communications network status (on, off, degraded) of a given communications network, and reports the status based on user provided parameters. (JCSFL 7.3.22)

E.4 SV-4 Control Mission

This function generates the controls and inputs necessary to control the employment of the force weapons, sensors, and platforms. System Functions include:

· Receive Call. Receive and process incoming call for service via voice or data.

· Allocate Platform to Mission. This function allocates platforms to specific missions based on platform capabilities, mission requirements, and resource limitations. (JCSFL 5.4.6)

· Generate Reports. This function executes a script to automatically create and edit reports based on factors such as specified information, frequency of report, information change, and type of report. (JCSFL 8.4.40)

· Translate Foreign Languages. This function provides Machine Foreign Language Translation techniques to translate text, speech, system Human Machine Interface (HMI) controls, and system produced products from one language to another. This includes the translation of messages, forms, documents, keyboard character sets, text to speech, and speech to text. (JCSFL 7.1.50)

E.5 SV-4 Manage Data

This group contains all functions related to data management including actions taken with data, actions performed on data, storage and manipulation of data, and employing guidelines with data. Key functions include:

· Maintain Law Enforcement, Fire and Emergency Response Records. This function provides the ability to update and store data that result from those fire and emergency services activities.

· Record Data. This function records data, system events, or data exchanged on selected system interfaces based on user provided collection parameters. Actual data to be recorded shall be defined by factors such as default settings, categories, and event break points. This function can be used for data reduction and subsequently used for event reconstruction, post mission analysis, and system troubleshooting. Also known as Data Extraction. (JCSFL 8.7.108)

F. Operational Activity to Systems Function Traceability Matrix (SV-5a) The SV-5a addresses the linkage between System Functions described in SV-4 Systems Functionality Description and Operational Activities specified in OV-5a Operational Activity Decomposition Tree.

CERS SV-5a:

G. System Resource Flow Matrix (SV-6) The SV-6 provides details of system resource flow elements being exchanged between systems and the attributes of that exchange.

CERS SV-6:

4.4. Data and Information Veiwpoint (DIV)

The Data and Information Viewpoint articulates the data relationships and alignment structures in the architecture content for the capability and operational requirements, system engineering processes, and systems and services. The CERS DIV-2 diagrams are provided as notional models; as COTS, CERS will utilize existing data models.

A. Logical Data Model (DIV-2) The DIV-2 allows analysis of architecture’s data definition aspect, without consideration of implementation specific or product specific issues. Another purpose is to provide a common dictionary of data definitions for models, wherever logical-level data elements are included in the descriptions. The DIV-2 describes the structure of an architecture domain’s system data types and the structural business process rules (defined in the architecture’s OV) that govern the system data. It provides a definition of architecture domain data types, their attributes or characteristics, and their interrelationships. Each data entity is mapped to an OV-5 ICOM.

In an identifying relation the existence of the child entity is completely dependent on the existence of its parent entity. The primary key of the parent entity is part of the primary key of the child entity. The identifying relation is, by definition, mandatory, and the parent cannot be specified as optional.

In a non-identifying relation the child entity does not rely on the parent entity for its identification. The parent entity can be specified as mandatory or optional. The foreign keys propagated through a non-identifying relation line are not primary key attributes in the child entity

A non-specific relation can indicate a many-to-many relation or an unknown relation. Foreign keys are not propagated through a non-specific relation. During the early stages of modeling a system, one may want to use non-specific relations in order to avoid getting locked into definitions.

CERS DIV-2:

4.5. Standards Viewpoints

The Standards Viewpoints (StdV) articulate the applicable operational, doctrinal, business, technical, and industry policies, standards, guidance, constraints, and forecasts that apply to capability and operational requirements, system engineering processes, and systems and services.

CERS StdV-1 and StdV-2:

5. GIG Technical Standards / Interfaces Declaration

GIG Technical Guidance (GTG) content will be evolutionary in nature and, as is currently being developed and validated. Therefore, per CJCSI 6212.01E guidance this NR-KPP will provide a combination of GIG Technical Profiles (GTP) data, as shown in Table 2: GIG Technical Standards/Interfaces Declaration. The GTG Technical Standards/Interfaces Declaration table was developed from GTP found at <https://www.intelink.gov/wiki/Portal:GIG_Technical_Guidance/GTG_GTPs/GTP_Development_List>.

Table 2: GIG Technical Standards/Interfaces Declaration The Technical standards/Interfaces Declaration Table was developed IAW guidance contained in the following:

· CJCSI 6212.01E, 15 December 2008

· DISR Baseline and technical standards/interfaces information on DISRonline

· IPv6 Test Methodology

· IP Test Methodology

6. DoD Information Assurance (IA) and Critical Infrastructure Protection (CIP) Requirements

The CERS program or system will comply with the IA requirements in DOD 8500 series and CJCS 6510 series directives, instructions and manuals. CERS is designated Mission Assurance Category (MAC) III in accordance with DODI 8500.2. IA capability will be monitored, reported and evaluated as a distinct element of mission readiness throughout the CERS system development. The CERS REF Text2 \* MERGEFORMAT PM will ensure that IA is fully integrated into all phases of the CERS acquisition and/or upgrade, including initial design, development, testing, fielding, and operation as stated in DODI 8580.1 and outlined in the “Defense Acquisition Guidebook.” The point of contact for this program’s IA documentation is the PM ERS IA Manager.

CERS will comply with DOD Certification and Accreditation (C&A) Process Guidance and the DOD Information Assurance Certification and Accreditation Process (DIACAP). IA is an integral part of net readiness and will be incorporated in all Emergency Management Command and Coordination (EMC2) systems to ensure appropriate security measures are in place to protect system data and resources from all known threats. The system shall incorporate defensive IA capabilities that protect the availability, integrity, authenticity, confidentiality, and non-repudiation of the information exchanged and used. The Designated Approving Authority (DAA) for CERS is HQMC C4IA.

7. Supportability Requirements A. Electromagnetic Environmental Effects (E3) control and Spectrum Supportability Policy.

E3, Spectrum Supportability, and Host Nation Approval concerns do not apply. CERS does not contain any radios; however, CERS will utilize E-LMR radio assets under the E-LMR (Slice) POR.

B. Global Positioning System (GPS). CERS will comply with CJCSI 6130.01D, which directs planning, use and management of GPS as required. CERS will utilize commercial vendor standard positioning system (SPS) GPS for vehicle and personnel location (AVL/PLI).

C. JTRS ORD Compliance Statement. CERS does not contain any tactical radios. The JTRS ORD does not apply.

UNCLASSIFIED

UNCLASSIFIED

_1428155395.pdf

CERS SV-3

S 01 E 911 S 02 CAD System S 03 MDC S 04 Fire Station Paging S 05 EOC System S 06 Notification System S 07 Building Fire Alarm S 12 Electronic Mapping System S 13 Building Fire Alarm Monitor and Control S 14 Time System S 15 External E 911 System S 16 PSTN S 17 Geospatial Data Source S 18 Fire Station Alerting

S 01 E 911 X X X X X X X X

S 02 CAD System X X X X X X X X

S 03 MDC X X X

S 04 Fire Station Paging X

S 05 EOC System X X

S 06 Notification System X X

S 07 Building Fire Alarm X

S 12 Electronic Mapping System X X

S 13 Building Fire Alarm Monitor and Control X X

S 14 Time System X X X X X X

S 15 External E 911 System X X

S 16 PSTN X

S 17 Geospatial Data Source X

S 18 Fire Station Alerting X

Consolidated Emergency Management System (CERS)

SV-3 System to System Interface

Responsible Organization: PG 10 Emergency Response Systems (PMM-105)

SV Developer: WBB Consulting Ver 1.0 1November 2011

Reviewer: Date: 28 December 2011

Approver: Cntrl#: N/A image1.png

_1428155407.pdf

_1428155409.pdf

Description

The SV-5a provides the mappings of system functions from the SV-4 to the operational activities from the CERS OV-5.

CERS SV-5

NOTE:

** Any data displayed in this template is for reference use only. All existing data will be deleted prior to using the template in support of any architecture development effort.**

(1) System Functions are required (CJCSI 6212.01E) to come from the current Joint Common System Function List (JCSFL). If unique system functions are required after exhausting the JCSFL, submit all requests for new system functions to SIAT via the SIAT Architecture Support Team (QNA).

(2) Only leaf level system functions are to be mapped to operational activities, all other (upper level) system functions are to be omitted from this matrix.

(3) Only leaf level operational activities are to be mapped to system functions/service, all other (upper level) operational activities are to be omitted from this matrix.

Architecture Project Name: Consolidated Emergency Response System (CERS) Architecture Ver 1.0 Date: 20111021 SV-5a Operational Activity to Systems Function / Service Traceability Matrix USMC SV-5a/b Template Version 1.0 dtd 22 March 2011

System Functions (1) (2) Operational Activities (3) walter.kulakowski: Operational Activities:

The operational activities used on the Operational Viewpoints (OV-3/5a/5b/6c).

JCSFL ID Number walter.kulakowski: JCSFL ID Number:

The uniqe identification number assigned to a system function as listed in the current Joint Common System Function List (JCSFL).

JOINT COMMON SYSTEM FUNCTION

walter.kulakowski: Joint Common System Function:

The system function name as listed in the Joint Common System Function List.

Architecture Specific Hierarchy Number walter.kulakowski: Architecture Specific Hierarchy Number:

The architecture specific hierarchy number as listed in the SV-4 hierarchy diagram.

SYSTEM FUNCTION DESCRIPTION

walter.kulakowski: SYSTEM FUNCTION DESCRIPTION The item description as defined in the Joint Common System Function List.

walter.kulakowski: Operational Activities:

The operational activities used on the Operational Viewpoints (OV-3/5a/5b/6c).

A0 A1 A1.1 A1.6 A3.3.1.1 A3.3.1.2 A3.3.1.3 A3.3.1.4 A3.3.1.5

A0 Perform Total Force Structure Process A1 Support Force Structure Analysis A1.1 Model Changes to Force Structure A1.6 Provide Communications A3.3.1.1 Maintain Situational Awareness A3.3.1.2 Evaluate Threat A3.3.1.3 Dispatch Emergency Services Resources A3.3.1.4 Maintain Records A3.3.1.5 Conduct Translation

5.4.6 Allocate Platform to Mission 1.3.4 This function allocates platforms to specific missions based on platform capabilities, mission requirements, and resource limitations. X X

8.7.23 Disseminate Time Data 1.2.2 This function disseminates time data. X

8.4.40 Generate Reports 1.3.3 This function executes a script to automatically create and edit reports based on factors such as specified information, frequency of report, information change, and type of report. X

3.2.14 Maintain and Display Unit and Platform Status Information 1.1.1 This function maintains and displays status information on units and platforms specified. X X

New Maintain Law Enforcement, Fire and Emergency Response Records 1.4.2 This function provides the ability to update and store data that result from those law enforcement activities. X X

7.3.22 Monitor and Report Communication Networks Status 1.2.1 This function maintains the status of circuits, communication paths, communication plans, and networks to determine equipment performance. X

8.12.3 Perform Collaboration 1.1.4 This function allows users to collaborate in the form of white boarding, instant messaging, video or other forms of visual and audio communication.

8.7.8 Query Data 1.1.3 This function locates information in response to a query request and supports the subsequent data retrieval for the requestor. X

Receive Call 1.3.1 Recieve and process incoming phone call or alert message. X

3.4.3 Receive, Store and Maintain Geospatial Product Information 1.1.2 This function receives, stores, and maintains National Geospatial-Information Agency (NGA) geodesy information such as Digital Nautical Charts (DNC), Digital Terrain Elevations Data (DTED), and Digital Aeronautical Flight Information File (DAFIF) data. X

8.7.108 Record Data 1.4.1 This function records data, system events, or data exchanged on selected system interfaces based on user provided collection parameters. Actual data to be recorded shall be defined by factors such as default settings, categories, and event break points. This function can be used for data reduction and subsequently used for event reconstruction, post mission analysis, and system troubleshooting. Also known as Data Extraction. X

7.1.50 Translate Foreign Languages 1.3.2 This function provides Machine Foreign Language Translation techniques to translate text, speech, system Human Machine Interface (HMI) controls, and system produced products from one language to another. This includes the translation of messages, forms, documents, keyboard character sets, text to speech, and speech to text. X

Feb 23, 2011 &P image1.png

_1428155413.pdf

_1428155414.pdf

UNCLASSIFIED

Technical View (TV)

Printed by DISRonline on 2011-10-12

System Profile Consolidated Emergency Response System (CERS)

System Description

CERS is a secure (sensitive but unclassified) system composed of hardware and software components that facilitate expedient emergency response. The main elements of CERS include but are not limited to:

Computer Aided Dispatch (CAD), interface to wireless communications systems, Enhanced 911 (E911) systems, Fire Station Alerting (FSA), Mobile Data Computers (MDC), and interfaces to other systems.

Created by eric.ho0

Last Updated 2011-10-12

CDD or ISP Stage 1? yes

TV-1 IT Profiles

IT Profile Country Codes

IT Description

Country codes are required in e-mail addresses and e-mail display names in Active Directory attributes for all contractors and foreign nationals. This profile describes two Country Codes standards that can be used in this case.

Service Area Standard ID & Title of Standard Current Status

Sun set

Application-specific Data Interchange

ISO 3166-1:2006 - Codes for the representation of names of countries and their subdivisions, Part 1: Country codes, 20 November 2006

Mandated

IT Profile Cryptography

Cryptography is the practice and study of hiding information. Cryptography is used to protect electronic information. The two main areas of cryptography are symmetric-key and asymmetric-key.

Access Control ANSI/INCITS 359-2004 - Information technology - Role Based Access Control (RBAC)

Access Control FIPS Pub 140-2 - Security Requirements for Cryptographic Modules, 25 May 2001

Access Control FIPS Pub 186-3 - Digital Signature Standard (DSS), June

Access Control FIPS Pub 197 - Advance Encryption Standard (AES), 26 November 2001

Authentication FIPS Pub 198-1 - Federal Information Processing Standard Publication 198-1, The Keyed-Hash Message

Page 1 of 26Printer Friendly Page

10/12/2011https://disronline.csd.disa.mil/a/DISR/cr_printerfriendly.jsp?content=/DISR/content/techn...

Authentication Code (HMAC), June 2007 Information System Security Management

HAIPE IS v3.0.2 - High Assurance Internet Protocol Encryptor (HAIPE) Interoperabiltiy Specification, Version 3.0.2, December 2006

Authentication IETF RFC 2560 - IETF Public Key Infrastructure X.509 (PKIX) Online Certificate Status Protocol (OCSP), RFC 2560, June 1999

Authentication IETF RFC 3161 - Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)

Cryptographic Key Management

IETF RFC 4754 - IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA), January 2007

Architectures and Applications

IETF RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, May 2008

Devices (Smart Cards) ISO/IEC 7816-15:2004/Cor. 1:2004 - ISO/IEC 7816- 15:2004/Cor. 1:2004

Access Control ITU-T X.509:2005 - Information Technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks, August 2005

Access Control NIST FIPS Pub 180-3 - Secure Hash Standard (SHS), October 2008

Security Protocols PKIKMITKNPP - Public Key Infrastructure and Key Management Infrastructure Token (Medium Robustness)

PP

Authentication RSA Labs PKCS #12 v1.0:1999 with Corrigendum - PKCS #12: Personal Information Exchange Syntax Standard, version 1.0, and PKCS #12 v1.0 Technical Corrigendum

RSA PKCS #11 v2.20 - RSA PKCS #11 v2.20:

Cryptographic Token Interface Standard

IT Profile Domain Name System

IT Description DNS is a distributed hierarchical naming system for computers, services, or any resource connected to the Internet or a private network.

Network Technologies IETF RFC 2136 - Dynamic Updates in the Domain Name System, April 1997

Network Technologies IETF Standard 13/RFC 1034/RFC 1035 - Domain Name System, November 1987

IT Profile Dynamic Host Configuration Protocol (DHCP)

IT Description DHCP is an autoconfiguration protocol used on IP networks.

Network Technologies IETF RFC 2131 - Dynamic Host Configuration Protocol, March 1997

Network Technologies IETF RFC 2132 - DHCP Options and BOOTP Vendor Extensions, March 1997

Page 2 of 26Printer Friendly Page

10/12/2011https://disronline.csd.disa.mil/a/DISR/cr_printerfriendly.jsp?content=/DISR/content/techn...

Network Technologies IETF RFC 3011 - The IPv4 Subnet Selection Option for DHCP, November 2000

Network Technologies IETF RFC 3396 - Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4), November 2002

IT Profile Electronic Mail (Email)

Email is a method of exchanging digital messages. It was originally designed for text-only messages. Email has been extended to carry multimedia content attachments, which is called Multipurpose Internet Mail Extensions (MIME).

Electronic Mail IETF RFC 2231 - MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations, November 1997

Access Control IETF RFC 2634 - Enhanced Security Services for S/MIME, June 1999

Electronic Mail IETF RFC 2821 - Simple Mail Transport Protocol, April

Electronic Mail IETF RFC 2822 - Internet Message Format, April 2001 Mandated Electronic Mail IETF RFC 3030 - SMTP Service Extensions for

Transmission of Large and Binary MIME Messages, December 2000

Electronic Mail IETF RFC 3462 - The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages, January 2003

Electronic Mail IETF RFC 3501 - Internet Message Access Protocol, Version 4rev1, March 2003

Security Protocols IETF RFC 3850 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling, July

Electronic Mail IETF RFC 3851 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification, July 2004

Electronic Mail IETF RFC 4262 - X.509 Certificate Extension for Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities, December 2005

IETF RFC 5008 - Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME), September 2007

Electronic Mail IETF RFCs 2045-2049 - Multipurpose Internet Mail Extensions (MIME) Parts 1-5, November 1996

IT Profile Fibre Channel (FC)

Fibre Channel (FC) is a gigabit-speed network technology primarily used for storage networking. FC signaling can run on both twisted pair copper wire and fiber-optic cables. Its topologies comprise of point-to-point, shared loop, and switched. The most common protocol the FC associates with is FCP, which is a transport protocol that is similar to TCP used in IP networks.

Current Sun

Page 3 of 26Printer Friendly Page

10/12/2011https://disronline.csd.disa.mil/a/DISR/cr_printerfriendly.jsp?content=/DISR/content/techn...

Service Area Standard ID & Title of Standard Status set Backplanes and Busses ANSI INCITS 289-1996 (R2001) - Information Technology -

Fibre Channel - Fabric Generic Requirements (FC-FG), December 1996

Backplanes and Busses ANSI INCITS 373-2003 - Information Technology - Fibre Channel, Framing and Signaling Interface (FC-FS), October 2003

Backplanes and Busses ANSI INCITS 387-2004 - Information technology - Fibre channel Generic Services - 4 (FC-GS-4), August 2004

C4ISR: Payload Platform

ANSI X3.230:1999 - Fibre Channel - Physical and Signaling Interface (FC-PH), with amendments, 24 May

Backplanes and Busses ANSI/INCITS 297:1997 (R 2002). - Information Technology

- Fibre Channel Physical and Signaling Interface-2 (FC-PH- 2), 1997

Backplanes and Busses ANSI/INCITS 303-1998 (R 2003). - Fibre Channel Physical and Signaling Interface - 3 (FC-PH-3)

Backplanes and Busses ANSI/INCITS 332-1999 - Information Technology - Fibre Channel - Arbitrated Loop (FC-AL-2), 1999

Backplanes and Busses ANSI/INCITS 352-2002 - Information Technology - Fibre Channel - Physical Interfaces (FC-PI), 2002

Backplanes and Busses ANSI/INCITS 355-2001 - Information Technology - Fibre Channel Switch Fabric - 2 (FC-SW-2)

Backplanes and Busses ANSI/INCITS 357-2002 - Information Technology - Fibre Channel - Virtual Interface Architecture Mapping Protocol

(FC-VI)

IT Profile Geospatial Information System (GIS)

IT Description A GIS is a software system which combines a geographic display (a map) with a database which allows queries based on the geography.

GEOINT: Geospatial CAT 2.0.2 - OpenGIS Catalogue Service (CAT) Implementation Specification (2.0.2), 23 February 2007

GEOINT: Geospatial GML 3.1.1 - OpenGIS Geography Markup Language Encoding Specification, 7 February 2004

Mandated X

GEOINT: Geospatial ISO 19111:2007 - Geographic information -- Spatial referencing by coordinates, 26 June 2007

GEOINT: Geospatial MIL-STD-2401 - DoD World Geodetic System 84 (WGS84), 11 January 1994

GEOINT: Geospatial OGC KML 2.2.0 - OGC KML, Version 2.2.0, 14 April 2008 Mandated GEOINT: Geospatial OpenGIS Filter 1.1 - OpenGIS Filter Encoding

Implementation Specification, Version 1.1.0, 3 May 2005

GEOINT: Geospatial OpenGIS GeoXACML 1.0 - OpenGIS Geospatial eXtensible Access Control Markup Language (GeoXACML), Version 1.0, February 2008

Emerging

GEOINT: Geospatial SE 1.1.0 - OpenGIS Symbology Encoding Implementation Specification, Version: 1.1.0, July 21, 2006

GEOINT: Geospatial WFS 1.1 - OpenGIS Web Feature Service (WFS) Implementation Specification

GEOINT: Geospatial WMC 1.1 - OpenGIS Web Map Context (WMC) Mandated

Page 4 of 26Printer Friendly Page

10/12/2011https://disronline.csd.disa.mil/a/DISR/cr_printerfriendly.jsp?content=/DISR/content/techn...

Documents Implementation Specification, Version 1.1.0, 19 January 2005

GEOINT: Geospatial WMS 1.3 - OpenGIS Web Map Service (WMS) Implementation Specification, Version 1.3, 15 March 2006

GEOINT: Geospatial WMTS v1.0.0 - OpenGIS Web Map Tile Service Implementation Standard, v1.0.0, 2010-04-06

GEOINT: Geospatial WPS 1.0 - OpenGIS Web Processing Service, 2007-06-08 Mandated

IT Profile Hypertext Transfer Protocol (HTTP)

HTTP is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic stateless protocol that can be used for many tasks through extension of its request methods, error codes, and headers.

Network Technologies IETF RFC 2616 - Hypertext Transfer Protocol - HTTP 1.1, June 1999

Web Services IETF RFC 2965 - HTTP State Management Mechanism, October 2000

IT Profile Integrated Services Digital Network (ISDN)

ISDN is a set of communications standards for simultaneous digital transmission of voice, video, data, and other network services over the traditional circuits of the public switched telephone network.

Audio Data Interchange IETF RFC 3398 - Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping, December 2002.

IT Profile Internet Protocol Security (IPsec)

IPsec is a security scheme operating at the Network Layer of the OSI Model. Like other Internet security protocols, such as Secure Sockets Layer (SSL), Transport Layer Security (TLS), and Secure Shell (SSH), IPsec can be used for protecting application traffic across the Internet.

Security Protocols IETF RFC 2403 - The Use of HMAC-MD5-96 within ESP and AH, November 1998

IETF RFC 2407 - The Internet IP Security Domain of Interpretation for ISAKMP, November 1998

IETF RFC 2408 - Internet Security Association and Key Management Protocol (ISAKMP), November 1998

IETF RFC 2409 - The Internet Key Exchange (IKE), November 1998

IETF RFC 3526 - More Modular Exponential (MODP) Diffie-Hellman Groups for Internet Key Exchange (IKE), April 2002

Page 5 of 26Printer Friendly Page

10/12/2011https://disronline.csd.disa.mil/a/DISR/cr_printerfriendly.jsp?content=/DISR/content/techn...

IETF RFC 3566 - The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec, Sept 2003

IETF RFC 3602 - The AES-CBC Cipher Algorithm and Its Use with IPsec, Sept 2003

IETF RFC 3664 - The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE), Jan 2004

IETF RFC 3686 - Using Advanced Encryption Standard (AES) Counter Mode with IPsec Encapsulation Security Payload (ESP)

Security Protocols IETF RFC 4106 - The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP), June 2005

Network Technologies IETF RFC 4109 - Algorithms for Internet Key Exchange version 1 (IKEv1), May 2005

IPv6 Capable Product Class Profiles

IETF RFC 4307 - Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2), December 2005

IETF RFC 5903 - Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2, June 2010

IT Profile Internet Protocol version 4 (IPv4)

IPv4 is version 4 of the IP and it is the first version of the IP to be widely deployed. This profile identifies all IPv4-related technical standards that are currently mandated in DISRonline.

System Management Services

IETF RFC 3376 - Internet Group Management Protocol, Version 3, Oct 2002

IETF RFC 5790 - Lightweight Internet…