Attachment_002_-_TO1_CRS_&Attachment.pdf

WIDEBAND SATELLITE COMMUNICATIONS (SATCOM) TREND ANALYSIS AND

ANOMALY RESOLUTION SUBSYSTEM/WIDEBAND SATCOM OPERATIONS

MANAGEMENT SYSTEM (WSOMS) MEDIATED INTEROPERABILITY

INFRASTRUCTURE (WSTARS/WMII)

TASK ORDER 0001

Customer Requirements Statement (CRS)

1. PURPOSE

The primary purpose of this Task Order (TO) is to complete the Definition and Design of the requisite WSTARS capability to operate as a functional replacement for the existing Defense Satellite Communications System (DSCS) Integrated Management System (DIMS), as well as complete the Definition and Design of the Centralized Wideband Control Database and Common Information Management system.

Moreover, the Definition, Design, Procurement, and Build of the Integration Hardware Environment (IHE) for the full WMII Converged and Composable Infrastructure will be completed during this TO.

Finally, the additional WSTARS functionality that will be implemented across the final four years of the overall indefinite delivery/indefinite quantity (IDIQ) contractual effort, will be investigated and defined during this TO.

2. TYPE OF ORDER

The Government will award a hybrid Task Order for this effort. All CLINs will be Cost Plus Fixed Fee, with the exception of Program Management and Cyber Security which will be Firm Fixed Price, and Travel and Other Direct Costs which will be Cost Reimbursable.

3. PERIOD OF PERFORMANCE (PoP)

The contractor shall complete this TO within 12 months of the contract award, with the exception of Program Management and Cyber Security which have a PoP of 12 months from TO award with four, 12 month option periods.

4. OBJECTIVES

a) Develop and maintain a WSTAR/WMII Product Roadmap (as defined in Section 1.1.a of the WSTARS/WMII base IDIQ CRS.) of iteratively derived functionality across the life of the contract, which includes dependencies on the corresponding evolution of other WSOMS subsystems (as defined in Section 5.1 of the WSTARS/WMII Base Contract CRS).

b) Definition and design of a single centralized database each for Red and Black Equipment Areas for the WSOMS subsystems including, but not limited to CNPS, Attachment 002 - TO1 CRS & Attachment, 13 December 2016

MANAGEMENT SYSTEM (WSOMS) MEDIATED INTEROPERABILITY

INFRASTRUCTURE (WSTARS/WMII)

TASK ORDER 0001

Customer Requirements Statement (CRS)

GSCCE, RSCCE, WRMS, GT3CS, JMOS, RFMOW, RRFIS, and RMCE (as defined in Section 5.1 of the WSTARS/WMII base IDIQ CRS.)).

c) Definition and design of a standardized Information Management system conforming to Service Oriented Architecture (SOA) standards.

d) Design and implementation of a Common Object Request Broker Architecture (CORBA) to SOA Translator, as the interim WSTARS/WMII interface with all applicable WSOMS subsystems.

e) Definition, Design, Procurement, and Build of three (3) identical IHE Converged and Composable Infrastructures that host the CNPS, GSCCE, RSCCE, WRMS, GT3CS, JMOS, RFMOW, RRFIS, and RMCE subsystem applications and associated databases in a Virtual Machine environment.

f) Assist other WSOMS subsystems Integrated Product Teams (IPTs) with conversion to new Database and Information Management designs and interfaces.

g) Identify and Develop Necessary legacy DIMS functionality for WSTARS.

h) Investigate and develop WSTARS design requirements for:

o Resource Allocation and Configuration Tool o Trend Analysis and Anomaly Resolution o Data Collection & Trouble Tickets o Public Key Infrastructure (PKI) / Access Management o Cybersecurity / Information Assurance

5. ASSUMPTIONS

• General Information requirements (as defined in Section 1.2 of the WSTARS/WMII base IDIQ CRS) and deliverables of the WSTARS/WMII Base Contract CRS are applicable, unless noted in this Task Order.

• Mutual cooperation will exist between the WSTARS/WMII contractor and the other WSOMS subsystems IPTs, and all WSOMS subsystem dependencies identified in the aforementioned Product Roadmap will be accomplished within the required timeframe.

• In addition to the GFI (listed in Section 3.3 of the WSTARS/WMII base IDIQ CRS) that will be supplied upon contract award, Attachment 1: DIMS Synopsis, provides a summary of the pertinent information regarding legacy DIMS requirements, and associated interfaces with other subsystems.

6. SCOPE

The Contractor shall furnish all supplies, equipment, facilities and services required to perform work under this task order that are not listed under Section 3 of the base CRS.

The Contractor shall be responsible for providing cables, connectors, and other ancillary equipment as required to configure the WSTARS/WMII systems to full operational states. All equipment fielded on Department of Defense (DOD) networks are required to be on the DOD Unified Capabilities (UC) Approved Products List (APL).

7. SPECIFIC TASKS

The Contractor shall perform applicable System Engineering tasks in accordance with the referenced WSTARS/WMII base IDIQ CRS Sections and Subsections:

i) CONVERGED AND COMPOSABLE WMII: INFRASTRUCTURE DESIGN

• Contractor shall define and design the Converged and Composable WMII hardware and software infrastructure necessary to provide the requisite Virtual Machine Host for WSTARS, in accordance with Section 5.1.a of the WSTARS/WMII base IDIQ CRS.

• Contractor shall produce a Drawing Tree as defined in Section 5.3.3 of the

• Contractor shall produce a Technical Data Package as defined in Section 5.3.4 of the WSTARS/WMII base IDIQ CRS.

• Contractor shall produce an Interface Control Document as defined in Section

5.3.6 of the WSTARS/WMII base IDIQ CRS.

• Contractor shall perform all necessary Safety tasks as defined in Section 5.7 and

Subsections of the WSTARS/WMII base IDIQ CRS.

• The following CDRLs apply to this task:

CDRL Data Item Description (DID) Description

H006 DI-DRPR-81961 Engineering Drawing Tree https://aplits.disa.mil/apl/

H007 DI-SESS-80776A Technical Data Package C015 DI-SAFT-80102C Safety Assessment Report (SAR) C016 DI-SESS-81248B Interface Control Document (ICD)

ii) CONVERGED AND COMPOSABLE WMII: INFRASTRUCTURE PROTOTYPES

• Contractor shall procure, build, test, install, and verify the WMII Converged and

Composable Infrastructure IHE prototypes (Quantity 3), as defined in Sections 5.1.b and 5.3.1.a of the WSTARS/WMII base IDIQ CRS.

• Contractor shall perform all necessary Test, Evaluation, and Acceptance in accordance with Section 5.3.2 and Subsections of the WSTARS/WMII base IDIQ

CRS.

• Contractor shall produce an As-Built Configuration List in accordance with Section 5.3.5 of the WSTARS/WMII base IDIQ CRS.

• Contractor shall perform all necessary Post Design/Production Software Support tasks in accordance with Section 5.8 and Subsections of the WSTARS/WMII base IDIQ CRS.

F001 DI-IPSC-81488 Source Lines of Code F004 DI-IPSC-81488 Computer Software Product F005 DI-SESS-81646B Configuration Audit Plan F007 DI-CMAN-81516 As-Built Configuration List F008 DI-MISC-80711A Software Build Procedures F009 DI-IPSC-81441A Software Product Specification F010 DI-IPSC-81427A Software Development Plan (SDP) F012 DI-IPSC-81435A Software Design Description F015 DI-IPSC-81442A Software Version Description (SVD) J001 DI-NDTI-80566A Test Plan J002 DI-NDTI-80603A Test Procedures J003 DI-NDTI-80809B Test/Inspection Reports

J008 DI-NDTI-80809B Failure Analysis and Fault Correction Technical Report

iii) CENTRALIZED DATABASE

• Contractor shall ensure the centralized database is instantiated, and accessible to all applicable WSOMS subsystems in accordance with Section 5.1.c of the

• Contractor shall produce a Technical Data Package as defined in Section 5.3.4 of the WSTARS/WMII base IDIQ CRS.

• Contractor shall produce an Interface Control Document as defined in Section

5.3.6 of the WSTARS/WMII base IDIQ CRS.

C016 DI-SESS-81248B Interface Control Document (ICD) H007 DI-SESS-80776A Technical Data Package F001 DI-IPSC-81488 Source Lines of Code F004 DI-IPSC-81488 Computer Software Product F005 DI-SESS-81646B Configuration Audit Plan F007 DI-CMAN-81516 As-Built Configuration List F008 DI-MISC-80711A Software Build Procedures F009 DI-IPSC-81441A Software Product Specification F010 DI-IPSC-81427A Software Development Plan F012 DI-IPSC-81435A Software Design Description F015 DI-IPSC-81442A Software Version Description (SVD) J001 DI-NDTI-80566A Test Plan

J003 DI-NDTI-80809B Test/Inspection Reports

iv) COMMON INFORMATION MANAGEMENT SYSTEM

• Contractor shall ensure that the Common Information Management system is instantiated and usable by all applicable WSOMS subsystems through the CORBA to SOA Translator, in accordance with Section 5.1.d of the

• Contractor shall produce a Technical Data Package as defined in Section 5.3.4 of the WSTARS/WMII base IDIQ CRS.

• Contractor shall produce an Interface Control Document as defined in Section

5.3.6 of the WSTARS/WMII base IDIQ CRS.

C016 DI-SESS-81248B Interface Control Document (ICD) H007 DI-SESS-80776A Technical Data Package F001 DI-IPSC-81488 Source Lines of Code F004 DI-IPSC-81488 Computer Software Product F005 DI-SESS-81646B Configuration Audit Plan F007 DI-CMAN-81516 As-Built Configuration List F008 DI-MISC-80711A Software Build Procedures F009 DI-IPSC-81441A Software Product Specification F010 DI-IPSC-81427A Software Development Plan F012 DI-IPSC-81435A Software Design Description F015 DI-IPSC-81442A Software Version Description (SVD)

J001 DI-NDTI-80566A Test Plan

J003 DI-NDTI-80809B Test/Inspection Reports

v) DIMS FUNCTIONALITY

• All necessary legacy DIMS functionality to be incorporated into WSTARS/WMII shall be identified and documented by the Contractor as defined in Section 5.1.j of the WSTARS/WMII base IDIQ CRS, and in accordance with CDRL F014: DI- IPSC-81433: Software Requirements Specification.

vi) WSTARS/WMII FUNCTIONALITY AND REQUIREMENTS WHITE PAPERS

• Contractor shall investigate and define appropriate WSTARS/WMII functionality and requirements in accordance with CDRL B0001: DI-MISC-80508B: White Paper, to implement a Resource Allocation and Configuration Tool defined in Sections 5.1.k.1 and 5.1.i.1 of the WSTARS/WMII base IDIQ CRS.

Paper, to implement Trend Analysis and Anomaly Resolution (e.g. Rain Fade) defined in Sections 5.1.k.1 and 5.1.i.2 of the WSTARS/WMII base IDIQ CRS.

Paper, to implement Status Reporting & Trouble Tickets defined in Sections 5.1.k.2 and 5.1.i.3 of the WSTARS/WMII base IDIQ CRS.

Paper, to implement PKI / Access Management defined in Sections 5.1.k.3 and 5.1.g of the WSTARS/WMII base IDIQ CRS.

Paper, to implement Cybersecurity and Information Assurance Requirements defined in Sections 5.1.k.4 and 5.4 of the WSTARS/WMII base IDIQ CRS.

vii) PROGRAM MANAGEMENT

• Contractor shall perform all applicable Program Management and Security tasks in accordance with the WSTARS/WMII base IDIQ CRS Sections 2 and 5.2 and Subsections.

• The following CDRLs are applicable to this task:

A002 DI-MGMT-81861A Integrated Master Schedule A003 DI-QCIC-81722 Quality Program Plan A004 DI-MGMT-81605 Briefing Materials A005 DI-MGMT-80227 Meeting Minutes A006 DI-MGMT-80227 Progress, Status, and Management Reporting A007 DI-MGMT-81466A Contractor Manpower Reporting A008 DI-MGMT-81809 Risk Management Status Report A009 DI-MGMT-80934C Operations Security Plan C004 DI-MISC-80711A Configuration Control Document H001 DI-SESS-81875 Configuration Management Plan H003 DI-SESS-80639D Engineering Change Proposal H004 DI-SESS-80643D Specification Change Notice H005 DI-SESS-80640D Request For Variance

viii) Cyber Security

Contractor shall perform all necessary Cyber Security tasks in accordance with the WSTARS/WMII base IDIQ CRS Section 5.4 and Subsections.

The following CDRL is applicable to this task:

I002 DI-MGMT-82001 DOD Risk Management Framework (RMF) Package Deliverables

ix) OTHER TASKS AND APPLICABLE CDRLs TO THIS TASK ORDER:

The Contractor shall perform other applicable tasks in accordance with the referenced WSTARS/WMII base IDIQ CRS Sections and Subsections:

i) Product Roadmap as defined in Section 1.1.a of the WSTARS/WMII base IDIQ CRS.

CDRL

Data Item

Description

(DID)

Description

F002 DI-MISC-80711A Product Roadmap

ii) WSOMS Coordination as defined in Section 1.1.b of the WSTARS/WMII base IDIQ

A004 DI-MGMT-81605 Briefing Materials A005 DI-MGMT-80227 Meeting Minutes

iii) Post Award Conference as defined in Section 1.2.5 of the WSTARS/WMII base IDIQ

A004 DI-MGMT-81605 Briefing Materials A005 DI-MGMT-80227 Meeting Minutes

iv) Technical Execution Plan as defined in Section 1.2.6 of the WSTARS/WMII base IDIQ

A001 DI-MGMT-80004A Task Execution Plan

v) Key Personnel as defined in Section 1.2.8 of the WSTARS/WMII base IDIQ CRS, in

Contractor format at the time of the Post Award Conference

vi) Contractor Manpower Reporting as defined in Section 1.2.9 of the WSTARS/WMII

A007 DI-MGMT-81466A Contractor Manpower Reporting

vii) Data Rights as defined in Section 1.2.13 of the WSTARS/WMII base IDIQ CRS.

B003 DI-MISC-80711A Government Data Rights

viii) International Traffic in Arms Regulations as defined in Section 1.2.14 of the

WSTARS/WMII base IDIQ CRS. The Contractor shall submit a copy of the Technical Assistance Agreement to the Government Contracting Officer prior to the export of applicable data, software, or material.

8. TRAVEL REQUIRED

Under this TO, the contractor will be required to travel to the Joint Satellite Engineering Center (JSEC)- Control Systems Laboratory in Aberdeen, MD, and the National Capital Region, to conduct any necessary investigations or technical coordination. All travel will be on a cost reimbursable basses. The Contractor is authorized travel expenses consistent with the provisions of the Joint Travel Regulation. All travel requires Government approval/authorization and notification to the Contracting Officer Representative.

The following CDRL is applicable to all travel under this TO:

A006 DI-MGMT-80227 Progress, Status, and Management Reporting

9. OTHER DIRECT COSTS (ODC)

ODCs, when approved by the Government and incurred by the Contractor in performance of tasks will be reimbursed by the Government. The Contractor shall obtain prior approval from the COR for micro purchases (< $3K) and the Contracting Officer approval for all purchases over the micro purchase level. Only actual costs for ODCs that are supported with detail sufficient for the Government to verify that costs are reasonable and in performance of tasks will be reimbursed.

10. COMPLETION/ACCEPTANCE CRITERIA

All deliverable data items under this task are subject to review and acceptance by the Government. Acceptance criteria will vary by product delivered and requirements specified in each individual CDRL.

Attachment 1: DIMS Synopsis

************************** NOT PROVIDED WITH THIS DRAFT TO 1 CRS***************************

TASK ORDER 0001 – Customer Requirements Summary

1. Introduction:

As noted in Section 1 of the base IDIQ CRS, the end-state of WSTARS/WMII is a subsystem that both replaces DIMS, and expands upon its functionality. While Section 5.1 of the base IDIQ CRS provides significant detail on those required performance enhancements that shall result from WSTARS/WMII, Section 5.1.j and this Task Order specifically require the Contractor to identify and document all necessary legacy DIMS functionality to be incorporated into WSTARS/WMII in the form of a Software Requirements Specification. In the interim, this document represents a summary of existing DIMS functionality, and its associated interfaces with other subsystems. This description is applicable to DIMS Version 7.1.

2. Functional Description:

a. General:

i. Physical Definition – The Defense Satellite Communications System (DSCS) Integrated Management System (DIMS) is a mature hardware, and COTS and mission specific developed software, based subsystem. It utilizes multiple concurrently operating, and application specific Commercial Off-The-Shelf (COTS) servers, a Redundant Array of Independent Disks (RAID) storage, as well as a minimum of one WSOMS Workstation and one Printer to accomplish its functional mission. DIMS employs a modified version of the traditional two-tier client/server software architecture, in which a database server stores all data while multiple clients read and update the data in the server using a Human Computer Interface (HCI). DIMS also adds a background process to this architecture, called a Subsystem Traffic Manager, to implement a two-way interface (disseminating network configuration data, and collecting network performance data) to the Replacement Satellite Configuration Control Element (RSCCE) subsystem. Finally, DIMS provides a Gateway Service to export data to remote management sites.

ii. Operating Environment - DIMS is a central subsystem within the Wideband

Satellite Communications (SATCOM) Operational Management System (WSOMS). DIMS is physically located within each of the five Wideband Satellite Operation Centers (WSOC) identified in Table 1-1 of the WSTARS/WMII base IDIQ Customer Requirements Summary, and is connected to the associated Ethernet (100 Mbps) local area WSOMS Network (WSOMSNet). DIMS occupies a contiguous 4U slot within the WSOC Node 19” rack, as well as an additional six (6) square-feet of floor space within a climate controlled facility. Portions of the DIMS subsystem software suite are also deployed as required in other Wideband Management sites, remote to the WSOCs.

b. Purpose - The primary objective of DIMS is to simplify network management tasks by providing an integrated area-level management system that enables database distribution across WSOMS subsystems, and summarizes monitoring information from those WSOMS subsystems. DIMS is also capable of various levels of data correlation that provide WSOMS network controllers and managers with information views not available on any other one subsystem.

DIMS provides:

i. A hosting platform for the requisite software services (see Section 3.c) to perform the aforementioned integrated area-level management;

ii. Satellite operating scenario extraction (retrieval) from the Common Network

Planning Software (CNPS) subsystem;

iii. Database distribution (dissemination) to the RSCCE, the Global SATCOM

Configuration Control Element (GSCCE) and the Wideband Remote Monitoring Sensor (WRMS) subsystems;

iv. Data Collection from the RSCCE, GSCCE, and WRMS subsystems; and

v. Exporting Data from the WSOMS local area network (LAN).

DIMS is used by two primary types of users – satellite network controllers (SNCs) and satellite network managers (SNMs). SNCs operate DIMS from WSOC sites and SNMs operate DIMS from Wideband Management sites, as identified in Table 1-1 in the WSTARS/WMII base IDIQ CRS. Operations Analysts (OAs) also utilize DIMS to supervise the other control positions within the WSOC. DIMS enables all of these users to perform limited troubleshooting and trend analysis. DIMS also accommodates multiple, concurrent users to view, disseminate data, and print reports.

3. High-Level Architecture & Design:

a. WSOMS Enterprise Architecture – The high-level WSOMS Architecture instantiated (with respect to DIMS, GSCCE, and WRMS) to accomplish the aforementioned DIMS objectives, is depicted in Figure 3-1: Notional WSOMS Architecture. As shown in the figure, each of these subsystems is connected to the other in a System-of-Systems, Full-Mesh configuration. Moreover, these subsystems share a common event-driven communications standard between the applications, as well as a common and highly-tailored data sharing protocol. As the DIMS - RSCCE functional interaction is managed independently, it is described separately in Section 3.d.

Figure 3-1: High-Level WSOMS Architecture

b. DIMS Logical Architecture – To maximize the interoperability with associated WSOMS subsystems, DIMS is compliant with the enterprise standard Objective DSCS Operations Control System (ODOCS) architecture. The ODOCS architecture is composed of three logical tiers (as depicted in Figure 3-2):

i. Presentation Tier - Hosted on one (or more) ODOCS HCI Workstations.

ii. Application Tier - Hosted on one (or more) Mission Area Application (MAA) Servers.

iii. Data Tier - Hosted on one (or more) Database Servers.

Figure 3-2: ODOCS Logical Tiers

c. Software Services – The ODOCS architecture also specifies application integration services for each of the three logical tiers. Collectively, these application integration services are known as the ODOCS Software Services (OSS).

i. Presentation Tier – the ODOCS HCI Navigation Service (OHNS) provides navigation from one application’s HCI to another application’s HCI, both within and across WSOMS ODOCS-compliant subsystems.

ii. Application Tier – the ODOCS System Control Service (OSCS) provides a mechanism for applications running on MAA Servers across associated WSOMS subsystems, to inform one another of the approximate 30 interdependent events. OSCS is compliant with Object Management GroupTM1 (OMG) notification service standards, and employs OMG’s Common Object Request Broker Architecture (CORBATM2) as the distribution standard for this loosely coupled and asynchronous exchange of event messages. This publish/subscribe model decouples the applications, and permits one (or multiple) application(s) to send an event message without any knowledge about the application(s) that will receive the message. Two COTS

1Object Management GroupTM is a registered trademark of Object Management Group, Inc.

2CORBA is a registered trademark of Object Management Group, Inc.

software products are employed in support of OSCS. Specifically, OpenFusion CORBA ServicesTM3, from Micro Focus International, is utilized to support the OMG Naming Service, Notification Service, and Log Service.

OrbixTM4, from IONA Technologies, incorporates the requisite runtime CORBA instance, and Locator / Activation Daemons. Three custom built software components provide the OSCS Setup Wizard, the Access Control Interceptor for OSCS Event Channel integrity, and the OSCS Traffic Log.

Finally, the ODOCS Common Naming Service (OCNS) provides directory services for the storage and retrieval of references to the other services and application-specific resources. Figure 3-3 provides a notional component diagram of OSCS.

Figure 3-3: Notional Component Diagram for OSCS

3OpenFusion CORBA ServicesTM is a Registered Trademark of Micro Focus International, plc.

4OrbixTM is a Registered Trademark of IONA Technologies, Inc.

iii. Data Tier – the ODOCS Data Management Service (ODMS) utilized in DIMS, provides approximately 200 integrated views of all ODOCS data assets, and enables data exchange between the subsystems within a local WSOC domain. ODMS is responsible for creating a virtual ODOCS database composed of distributed relational databases residing in each subsystem.

This is accomplished by using database views, Structured Query Language (SQL), and Call-Level Interface (CLI) calls.

ODMS provides a hub-centric configuration where all ODOCS-compliant software applications may request and retrieve data needed for mission activities. ODOCS subsystems connect to the ODMS user account on the ODMS-hosting platform, which is set up and password protected separately from the local subsystem account. ODMS views then use database links to gain access to the individual subsystem databases. Accessibility to the ODOCS subsystem databases is limited to read-only access. The option to use ODMS to write to a subsystem’s database is not provided within the scope of ODMS. ODMS does not affect any replication scheme used within a subsystem’s implementation. A subsystem may replicate its database between instances at one or multiple sites independent of ODMS.

Figure 3-4 illustrates the logical ODMS architecture. Data is accessed using ODMS (consumer) views that are stored within the ODMS-hosting platform.

Effectively a view is a derived table that contains no rows itself, but exists as a virtual table that combines data from base tables or other views. A view may also be a pointer to another view. Views can reside in any database;

however, the preference is to have the view reside in the same database as the source table. For the purpose of maintainability and consistency, all ODMS views are stored and maintained within the ODMS-hosting platform.

Producer views, which are accessed by the consumer views to gain access to the data, are stored and maintained in the individual subsystems. Producer views are provided for the purpose of establishing streamlined accessibility to the data for efficiency and security purposes.

To access the data, the consumer issues an automated or manual SQL/CLI query to retrieve the desired data by accessing one of the consumer views stored within the ODMS-hosting platform. ODMS transparently handles the data retrieval process for the consumer, and ODMS returns the data to the requesting ODOCS subsystem.

As part of the data retrieval process, ODMS activates the database link to the remote database and queries the database via the producer view in the designated subsystem. This is performed according to the contents of the SQL statement that defines the consumer view. The producer view provides access to the data using locally stored views or via direct access to any of the approximate 400 tables in the database.

In Figure 3-4, three possible types of ODMS views are shown. In case Q1, CNPS issues an SQL call to an ODMS view, which provides direct access to a table within DIMS. In this case no producer view is used. In case Q2, DIMS issues an SQL call to an ODMS view, which acts as a pointer to a view within GSCCE. In case Q3, GSCCE issues an SQL call to an ODMS view, which accesses views from three independent sources, the WRMS table, a DIMS view and a CNPS view. A fourth query is shown to indicate that WRMS can query ODMS views as well. Any combination of views and/or tables can be used to fill a data request.

Figure 3-4: ODMS Logical View

Figure 3-5: DIMS Component Diagram

d. Subsystem Traffic Manager – As illustrated in Figure 3-5: DIMS Component

Diagram, the distribution of configuration and monitoring data between the RSCCE and DIMS is managed by the Subsystem Traffic Manager (STM). The STM process is bidirectional and event driven, responding to Oracle Alerts from DIMS and Status Messages from RSCCE. STM performs the following functions:

DIMS Database Server

Wideband SATCOM Server

DECnet

ATM

One-way

Fibers

Subsystem Traffic Manager

RSCCE

Subsystem

CNPS

Subsystem

WRMS

Subsystem OSS Server

Integrated Network Management System

DIMS Gateway Server

GSCCE

Subsystem

DIMS DB ODMS DB

DIMS HCI

Default Protocol: TCP/IP

: DIMS Component

: DIMS Server

: DIMS Service

i. Receive Level Monitor (RLM) Measurements – The STM collects RLM measurements from RSCCE and inserts them into the appropriate data tables residing in DIMS.

ii. Transmit Level Sensor (TLS) Measurements – The STM collects TLS measurements from RSCCE and inserts them into the appropriate data tables residing in DIMS.

iii. Database Transfers – The STM receives and sends full or partial Database Transfers between DIMS and RSCCE.

iv. Operational Database Dissemination – The STM facilitates the Dissemination of the Operational Database (identified in Section 3.f.ii) from DIMS to RSCCE.

v. Status & Alarm – The STM receives Status and Alarm information from RSCCE and relays it appropriately to DIMS.

e. DIMS Gateway – The DIMS Gateway connects DIMS to the WSOMSNet through a dedicated, one-way, secure communication channel to the Wideband SATCOM Server (at a remote WSOMS management site), and the Integrated Network Management System (for consumers outside of the WSOMSNet). This communication is facilitated by a custom, application specific software - DIMS Gateway Manager (DGM). DGM performs user-defined queries on any connected DIMS database, and formats the resulting data into an XML file for transfer to one or both of the two potential receivers.

f. Host Hardware/Software Environment – As depicted in Figure 3-5: DIMS

Component Diagram, DIMS is comprised of four (4) application specific servers, and a Client HCI software application on a user-defined number of additional workstations.

i. OSS Server – A common server (Dell PowerEdge R730-210-ACXU-

6X500GB) is used as the host for the OSCS, ODMS, and OHNS software applications to enable the ODOCS compliant functionality of the applicable WSOMS subsystems. Installed software includes:

• MicrosoftTM5 WindowsTM6 Server 2012R2

• JavaTM7 1.7 Build 80 (64-bit)

• Java SE Development Kit 7 (64-bit)

• Microsoft Visual CTM8++ 2013 x64 Minimum & Additional Runtime

• McAfee VirusScan Enterprise

5 MicrosoftTM is a Registered Trademark of Microsoft Corporation 6 WindowsTM is a Registered Trademark of Microsoft Corporation.

7 JAVATM is a Registered Trademark of Oracle Corporation.

8 Visual CTM is a Registered Trademark of Microsoft Corporation.

• InstallRoot

• Microsoft SilverlightTM9

• McAfee Agent

• IONA ORBIX 6.3.7

• OpenFusion CORBA Services 3.0.4

• OracleTM10 12.1.0

ii. DIMS Database Server – The DIMS databases are hosted on a common server (Dell PowerEdge R730-210-ACXU-8X1TB).Installed software includes:

• Microsoft Windows Server 2012R2

• Microsoft Visual C++ 2010 x64

• McAfee VirusScan Enterprise

• psqlODBC_x64

• InstallRoot

• Microsoft Silverlight

• McAfee Agent

• Oracle 12.1.0

In addition to the ODMS database (described in Section 3.C.iii), the DIMS Database Server also hosts the DIMS database. This database is used to store the data that is critical to the core operation of the WSOC and the satellites in view. The DIMS database is logically (not physically) divided into four partitions:

• Site Configuration Database

• Subsystem Performance Database

• Operational Database

• Online Data Dictionary

iii. Subsystem Traffic Manager Server – The STM Server is a Compaq Alpha 1200 server with a 533 MHz processor, 1.5 GB of memory, two (2) Fast Ethernet ports, two (2) 9.1 GB Raid 1 disks, and a Digital Equipment Corporation (DEC)NetTM11 interface card. Installed software includes:

• Hewlett-Packard OpenVMSTM12 v8.3

• Oracle Client 7.3, or later

• Oracle BEAMessageQTM13 5.0

9 SilverlightTM is a Registered Trademark of Microsoft Corporation 10OracleTM is a Registered Trademark of Oracle Corporation.

11DECNetTM is a Registered Trademark of Compaq Corporation.

12OpenVMSTM is a Registered Trademark of Hewlett-Packard Corporation.

13BEAMessageQTM is a Registered Trademark of Oracle Corporation.

• DEC PathworksTM14

• Custom STM Executables and Command Files

iv. DIMS Gateway Server – The DIMS Gateway Server is a DELL PowerEdge

R2850 with both Fast Ethernet and two (2) Owl DualDiodeTM15 Communications Cards. Installed software includes:

• Windows Server 2008

• Owl Technologies Directory File Transfer System

• Custom DIMS Gateway Manager Executables and Command Files

v. WSOMS Workstation – A Fast Ethernet and pointing device enabled Windows 7 Workstation, and the application specific DIMS Client software, is required to perform the necessary DIMS HCI functions. The DIMS HCI can function concurrently on multiple Workstations on the same WSMOS LAN.

g. Interconnection Standards – Referring to Figure 3.5: DIMS Component Diagram, the following are the Interconnection Standards employed between DIMS and other subsystems within and outside the WSOMSNet LAN, as well as the Interconnection Standards employed between DIMS Components:

i. DIMS Database Server <> WSOMSNet LAN:

• Transport Layer – TCP/IP

• Data Layer – Fast Ethernet

ii. DIMS OSS Server <> WSOMSNet LAN:

iii. DIMS Database Server <> WRMS:

iv. DIMS OSS Server <> WRMS:

v. DIMS Database Server <> GSCCE:

14PathworksTM is a Registered Trademark of Compaq Corporation 15DualDiodeTM is a Registered Trademark of Owl Computing Technologies, Inc.

vi. DIMS OSS Server <> GSCCE:

vii. DIMS Database Server <> CNPS:

viii. DIMS OSS Server <> CNPS:

ix. DIMS Database Server <> DIMS OSS Server:

x. DIMS OSS Server <> WSOMS Workstation:

xi. DIMS Database Server <> Subsystem Traffic Manager:

xii. Subsystem Traffic Manager <> RSCCE:

• Data Layer – DECNet (BEAMessageQ)

xiii. DIMS Database Server <> DIMS Gateway Server:

xiv. DIMS Gateway Server > Integrated Network Management System:

• Transport Layer – Owl DualDiode Fiber Asynchronous Transfer Mode

(ATM)

• Data Layer – Owl Directory File Transfer System (XML)

xv. DIMS Gateway Server > Wideband SATCOM Server:

• Transport Layer – Owl DualDiode Fiber Asynchronous Transfer Mode

(ATM)

• Data Layer – Owl Directory File Transfer System (XML)