4.4.1 Overview

This section describes the software that comprises the CHART II system. The software solution proposed for CHART II is comprised of three types of applications:

Graphical user interfaces (GUI) are applications that operators run to perform their primary duties. For CHART II, the GUI is the main program that initiates other applications such as the incident handler and reporting subsystems.

A system service is defined as a process that runs without operator intervention. They typically react to specific events and/or manage scheduled requests. A system service performs predefined tasks when requested by an on-line process or another system service, or has been scheduled to execute at a predetermined time, over a defined interval, or continually. For example, the System Controller is a system service that will continually check for failed processes.

Utility programs are secondary programs that operators or system administrators use to accomplish support functions, usually table maintenance. For example, the operator maintenance is a utility program used to set operator privileges and responsibilities.

As previously mentioned, the CSC/PBFI Team is using an Object Oriented Design (OOD) approach in the development of CHART II. Appendix B contains a series of use case and sequence diagrams that represent our initial step into the OOD process. The information presented in Appendix B encapsulates the ideas and processes described in the GUI and system services sections that follow.

All software that the CSC/PBFI Team provides or develops will be Y2K compliant.

4.4.1.1 Windows NT and UNIX

The CSC/PBFI Team has selected a combination of Windows NT and UNIX for CHART II as explained below.

Desktop workstation – There is a clear usability advantage in favor of a Windows-style operating environment for CHART II operators and other users of a CHART II workstation. Windows NT Workstation 4.X is recommended for this reason.

Application Server – Windows NT server is the platform of choice for a number of reasons. These include greater availability of software development tools, a strong and growing market acceptance (both ATMS markets and general), and more plentiful skills availability. These also include a slight edge in how security has been engineered into the operating system, more favorable functionality, and ease of administration.

Data Server – UNIX ((in this case Sun Microsystems) is the platform of choice because it is tuned for data input/output and performance scalability. This is needed due to the extent to which final CHART II performance requirements may scale in terms of data storage and archiving (and the fact that these may grow to unanticipated levels). It is also needed due to the system design’s reliance on a replicated database to which application servers make queries.

Section 4.4.5 contains supporting information regarding why the choice was made for each major system component.

4.4.1.2 Relationship Between Software and Hardware

Table 4-3 shows a preliminary allocation of software functions and hardware components. However, the software solutions we will describe below have not been designed to run in a predefined location or set of locations. This provides substantial flexibility for system configuration. Otherwise, each time a decision is made to add or move a location of a service, other affected services would have to be modified to accommodate the change.

 

 

 

 

 

Table 4-3. Preliminary Allocation of Software Functions and Hardware Components

CSC/PBFI Advantage: Our solution provides flexibility in terms of where software functions can be located.

 

Functions

 

System

GUI

Reporting

Field Device

Controller

Transaction (ORB)

Incident Detection

Data Replication

Legacy Import

External Systems Import

External Systems Export

Archive

Utilities

Map

Navigator

Field Device Control

Alarm Ticker

Operator Assignment/Security

Web Feed

AVL

Page/Fax

Detector/ATR

VMS

TAR

RWIS

AVCM

Hardware Component

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

CHART II Workstation

•

•

•

 

•

•

•

•

•

•

•

•

•

•

•

•

•

 

•

•

•

•

MSP Workstation

•

•

 

 

 

•

•

 

•

•

•

 

 

 

 

 

 

 

 

 

 

•

External Systems

 

 

 

 

 

•

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

AVCM/FMS Server

•

•

•

•

 

 

 

 

•

•

•

•

•

•

•

 

•

•

•

•

•

•

SOC Database Server

•

•

•

•

 

 

 

•

•

•

•

•

•

•

•

 

 

•

•

•

•

•

SOC Application Server

•

•

•

 

•

•

•

•

•

•

 

 

 

•

 

•

•

 

 

 

 

 

SOC Video Server

•

•

 

 

 

 

 

 

•

•

 

 

 

 

 

 

 

 

 

 

 

 

AOC Database Server

•

•

•

•

 

 

 

•

•

•

•

•

•

•

 

 

 

•

•

•

•

•

AOC Application Server

•

•

•

 

•

•

•

•

•

•

 

 

 

•

 

•

•

 

 

 

 

 

 

Our design will work whether a particular service is only running in one location or all locations. System architecture factors will determine where particular services are located, weighing between data replication costs when a service is in many locations against transport costs for handling data requests when a service is in fewer locations. With this flexible methodology, the services described are not subject to constant redesign whenever architectural design decisions require service availability to change.

The only exception is the Transaction Server, which is responsible for routing service requests between centers and thus must be running in all districts and operation centers at all times.