4.4.5 Supporting Information
This section contains additional detail on the CSC/PBFI Team software design. It includes supporting information on:
188.8.131.52 Windows NT vs. UNIX
The approach for selecting an operating system for the CHART II system included analysis of requirements and an analysis of operating system characteristics to determine a best fit.
The operating systems characteristics that are of primary concern derive from three uses: desktop workstation, application server, and data server. They also derive from the following classes of requirements:
184.108.40.206.1 Operating System Choices
With current technology, there are 3 mainstream choices for operating systems: Microsoft Windows NT, UNIX or proprietary. Proprietary systems may be ruled out because they are not open and more importantly require a much higher life cycle investment due to specialized training, maintenance and third-party software costs. Also, proprietary systems typically include proprietary hardware, which adds to the cost, and also presents the risk of lack of support as technology and the computer market evolve.
A UNIX variant known as Linux is also available. The basic Linux software has been placed in the public domain and many software developers around the world, including commercial vendors are enhancing it with state-of-the-art functions and features. The primary shortcomings are that Linux is incomplete as compared with other UNIX and the Windows NT operating systems, support for it is limited, and there are few commercial third-party packages that operate on it.
While Microsoft Windows NT is a proprietary operating system, it is an open system with many thousands of software and hardware products available from third party vendors. Most UNIX operating systems while based upon an open system design include many proprietary elements while the promise is to run a UNIX application on any UNIX system, the reality is that most applications require tailoring for each manufacturer’s implementation.
Windows NT has an inherent advantage in operating system security over UNIX. Because it is a newer operating system, security has been designed in as a fundamental system component. Windows NT (server and WS) 3.5 has been evaluated and certified under the National Security Agency’s Trusted Computer System program as compliant with C2 level security capabilities. NT was identified as having components required for B2 (a higher level) security although not fully evaluated and certified. Microsoft participates in the NSA’s Rating Maintenance Phase (RAMP). Microsoft Corporation intends to add different platforms as well as new processors to the evaluated configuration. A network configuration of the Windows NT platform is currently pending evaluation agreement. As with most computer systems, connecting to a network, especially one that permits external access, exposes the system to additional risks.
Of the major UNIX system vendors only HP with HP-UX and IBM with AIX are listed as certified on the NSA’s Trusted Computer Products web site. Certification is for older, special release versions of those operating systems. UNIX is an older operating system and although in some cases this means maturity in system products, for security it means that the system and its security vulnerabilities are well known. Also UNIX was not designed with modern security requirements in mind.
Security for both operating systems can be enhanced with third-party add-on tools. For example, tools are available to monitor communication ports, enhance system logging and monitor resource utilization.
Overall, security risks are more effectively controlled by solid practice than inherent features of the operating systems. Good practices such as having and implementing a security policy including use of passwords and applying security patches and maintenance as available from the vendor are required regardless of operating system.
Historically, UNIX systems have had a significant performance advantage over PC-based operating systems primarily because the hardware was typically mini-computer class. This meant that there was an advantage in the speed and number of processors, speed of the system bus, size, quantity of disk drives and memory expansion capabilities. While this is still true to an extent the gap is narrowing and for CHART II the selection will be a function of performance requirements for data input/output throughput now and into the future. Multi-processing systems having gigabytes of memory, multiple large disk drives and high-speed bus are widely available for operating both the NT and UNIX operating systems. The Enterprise version of Windows NT is available to operate using an 8-processor system and clusters of computers operating together. The clustering capability is currently an early release that provides little more than failover capabilities however full clustering capabilities will become available in the near future. The availability of faster system and input/output bus and processors for UNIX hardware may give a slight edge to UNIX where high input/output throughput (i.e., several MBps) or a high transaction processing rate (~100 tps) may be necessary.
Windows NT Server is the foundation of Windows NT Server Enterprise Edition and is an integrated, comprehensive and easy-to-use server operating system. Windows NT Server provides fast file and print services, robust application support, standards-based communications features, and complete Internet and Intranet functionality, which enhance its ability to expand in terms of both functionality and capacity.
Windows NT systems can currently scale to 4 GB Random Access Memory (RAM) The result is higher performance for applications working with large data sets.
The eight-processor symmetric multiprocessing (SMP) capability of Windows NT allows use of eight-processor SMP servers. Clustering allows several machines to be used together to achieve more scalability.
Some UNIX-based systems can scale to larger multi-processor and cluster configurations but only with a proprietary hardware/software solution. UNIX systems can also expand in model lines to extremely high-end with respect to number of processors, speed of processor and memory/disk capacities. These can reach far beyond what is needed for CHART II in the near future but may be necessary should data archiving, retrieval, and storage requirements accelerate, or if multimedia objects (e.g., video clips) be included as an archive requirement.
For both UNIX and Windows NT there are tools available to enhance system reliability. Microsoft Cluster Server (MSCS), when implemented on a validated cluster configuration, automatically recovers from application or server failures to keep data and applications online. MSCS enables the rearranging of workloads between clusters to balance loads as well as unloads servers for planned maintenance without downtime. Similarly, there are both vendor-specific and third party tools available to support hot standby and other forms of redundant system architecture.
The CSC/PBFI Team has proposed a system monitoring and control process to monitor process functioning and restart processes if they fail. This is a fundamental component of the overall reliability strategy.
Hardware is a major factor in determining reliability capabilities for a system. The CSC/PBFI Team has proposed a hardware configuration that implements many system reliability features such as RAID disk storage, redundant power supplies, redundant processor power modules, built-in system monitoring/management features, etc. This approach is applicable to either operating system.
Another major determinant of system reliability is configuration stability. The settings and configuration for both the operating system and the application software have a significant impact on system reliability. Both UNIX and Windows NT systems are adversely affected by significant changes to the system. Following adequate systems administration policies include logging into and using proper accounting groups to perform maintenance, timely application of updated feature releases, and reading and following vendor release notes. These will mitigate the risks of maintenance to an operating systems in a mission critical system.
Although UNIX-based systems have been in the market longer and therefore account for many mission critical environments, this has not slowed down the acceptance of Windows NT into environments such as manufacturing control, process control, banking and other high-availability applications. In fact, growth in UNIX based server systems has stagnated while growth in Windows NT server implementations continues at a rapid pace according to recent market share reports by third party industry analysts.
The CSC/PBFI Team will not hesitate to recommend a Windows NT as a 24 by 7 operating systems for CHART II.
Windows based graphical user interfaces provide the opportunity for software developers to create easy to use, innovative interfaces that are intuitive and that follow the business workflow of the users. There is a very mature set of tools and system features to support user interface development under Windows NT and is a primary advantage to using them in desktop and application server context.
On the UNIX platform there is a standard for developing windows-like user interfaces, the X-Windows standard. As with many attempts to standardize the UNIX environment the "X" standard did not survive as a generic standard so that there are several vendor-specific implementations including higher-level operating environments that rely on X characteristics. UNIX evolved from a technical (telecommunications) operating system. As such, basic system administration and operation tasks are not especially user friendly or easy to accomplish. The X-Windows add-on improves the situation but does not achieve the same level as Windows NT. Windows NT was designed as a window-based graphical user interface from its inception.
More practically, Windows-based systems including Windows 3.1, 95, 98, and NT are all suitable clients for an NT-based server application requiring no third-party software to login and used. A UNIX-based server application would require third-part application software (although, technically an X server component) to be used in the same way. This fact alone has propelled the rapid rate of acceptance for Windows NT as a server in the enterprise for many types of custom and COTS applications.
220.127.116.11.7 Open System
Both Windows NT and UNIX systems are open environments, from a third-party perspective, in that specifications required to develop software have interfaces that are published and available. However, UNIX-based systems are typically developed for a specific hardware platform whereas Windows NT operates on many vendors’ hardware.
Both operating systems support standard communication protocols and a rich set of application programming interfaces into the system.
Multi-tasking and multi-threading are prerequisite operating system capabilities to manage CHART II’s complexities. Both UNIX and Windows NT allow an application to perform many simultaneous tasks.
The trend in the software industry is away from UNIX towards Windows NT for systems development. Developers and technicians, as well as everyday computer users have followed that trend resulting in a marketplace that consists of more people in general who have Windows NT experience. This will ultimately make it easier to find developers to build and maintain CHART II, and operators with experience using NT based systems.
From a cost perspective, Windows NT is cheaper than UNIX. While the savings on an individual workstation is insignificant, it becomes a factor when multiplied by the large number of workstations in the CHART II system.
Studies within the transportation industry are reporting that a large majority of ATMS clients are asking for Windows NT over UNIX by a factor of 9 to 1. This can be significant in two areas, inter-jurisdictional interface and availability of off the shelf ATMS components. The need for multiple jurisdictions to share data has grown as the sophistication of ATMS installations has increased. When systems that need to communicate are running on the same operating system, the complexity of the communications issues decreases significantly. In addition, if one operating system becomes dominant in a particular industry, it becomes more cost effective for software and hardware vendors to develop products for that industry that work on one platform rather than multiple. This often results in a wide variety of potentially useful products from vendors who are more likely to stay in business and support their products.
Finally, from the application and desktop perspective, NT affords better integration with the Office Automation tools (e.g., GroupWise EMAIL, Word, Excel, PowerPoint, etc.) that CHART II operators, administrators, and managers use now on their desktops.
18.104.22.168 Reusable Code
With the approval of MDSHA, the CSC/PBFI Team will use, modify or enhance code developed for other PBFI systems around the country, where this is feasible and advantageous. Many of the CHART II functional requirements are similar to those contained in systems that PBFI has installed in Connecticut; Orlando, Florida; Seattle, Washington; and other places. These include, for example, surveillance monitoring, CCTV control, and VMS control. The code for these common functions is designed to be reusable, and may meet MDSHA requirements.
PBFI may also have code that communicates with specific devices in their "language" (i.e., their communications protocol). Although the NTCIP will serve to standardize these communications to a degree, individual device drivers will still be required to take full advantage of all of the features of a particular product. Much of the code developed for the graphical user interface prototype will also be reusable.
The concept of reusable code is important because to the extent that it can be taken advantage of, software development costs are reduced, time to implement is shortened, and reliability is increased.
Recognizing that software code we develop for clients can be used in other systems we are chosen to implement around the country, PBFI annually invests internal research and development funds in the improvement of its software products. PBFI has also instituted a program of regular client contacts in part to guide these investment decisions. PBFI will be using its World Wide Web site (pbfi.com) to regularly communicate with its software users, effectively forming a "virtual" users group.
MDSHA will be able to consider adding features suggested or implemented by other users, and take advantage of PBFI’s annual IR&D investments.
22.214.171.124 System Expansion
The CHART II system has been designed to adapt to both a changing environment, and changing system requirements. The first type of change refers to the ability to add like elements to or change the configuration of the system. This includes adding devices that are the same or functionally equivalent to existing system devices, modifying device configurations, or appending new recipients to mailing lists. The second type of change is changing the capabilities of the system, such as adding a new type of device, defining a new incident detection algorithm, or changing the steps of incident management.
One of the objectives of the design is to eliminate the need for an operating system shutdown, or even requiring an operator to exit the system following a change in configuration. Although adding system capabilities will usually require portions of the system to be rebuilt, the modularity of the design aims to reduce the amount of time to perform the build, the required testing time and system configuration changes. Any changes implemented will also be supplied in a backward-compatible fashion. That is, the new components will inter-operate with pre-existing components, and the pre-existing components will operate minus the new features. This approach will permit the system to be updated in a piecewise fashion, eliminating the need to shutdown the entire system for reconfiguration.
The following subsection lists each of the changes that CHART II is designed to accommodate, provides a definition of the change, the method for performing the change, and the impact of the change in terms of operator actions and system availability. It is divided into parts, Expansion of Existing Capabilities, which analyzes how to add objects that are already in the system, and Addition of New Capabilities, which describes the steps to expand the capabilities of the system.
126.96.36.199.1 Expansion of Existing Capabilities
188.8.131.52.1.1 New Devices
Procedure for adding new devices of existing types to the CHART II system.
Install the new device in the field and interconnect it to the appropriate FMS. Right click on the system map of any operator interface at the location where you would like the device to be placed. Select Add New <device type> from the context menu. A property sheet will be displayed for the device you are adding. Fill in the properties. The system will update the database and will inform all other system components that a new device has been added to the system.
Procedure for adding a new client workstation to the CHART II system.
Configure a system with Microsoft Windows NT, run the CHART II GUI software installation procedure, Install any other legacy or third party software necessary. If the client workstation is not already connected to the MDSHA Enterprise LAN, configure the MDSHA Enterprise network to accommodate the newly configured workstation, and connect the workstation to the MDSHA Enterprise network. Double click on the CHART II GUI icon to run the program.
New client workstation only.
184.108.40.206.1.3 Services (paging server, fax, e-mail)
Procedure for adding a new existing service to a CHART II district. The service in this case would be a service type that has already been installed in other districts.
Run the service installation procedure on the NT server machine where the service will run. The installation procedure will inform the transaction server for the district of the availability of the service by updating the system database.
220.127.116.11.1.4 Service Participants
Procedure for adding a new user to a service. An example would be to add a new fax recipient to the system.
Logon at any CHART II workstation as a user with appropriate privileges. Use the dialog boxes provided to add the new user to the service. The software will update the appropriate database tables and will inform the service that a new user has been added.
18.104.22.168.1.5 Users (Operators, Supervisors)
Procedure for adding a new CHART II user to the system
Use the Microsoft Windows NT user manager for domains applet to add a new NT user to the CHART II domain. Add this user to the appropriate user groups to grant him/her the appropriate system privileges. The users may now login to the NT system and use the CHART II software.
Procedure for introducing new groups into the CHART II system.
Use the Microsoft Windows NT user manager for domains applet to add a new NT user group to the CHART II domain. Run a CHART II GUI application and assign the new group to the appropriate system functions and system devices. This GUI will update the system database. You may now use the NT user manager for domains applets to add users to the group as appropriate.
22.214.171.124.1.7 Areas of Responsibility
Procedure for introducing a new area of responsibility into the CHART II system.
Areas of responsibility will be implemented by adding and removing users from groups. Thus adding a new area of responsibility will require adding a new user group, assigning that group rights to the correct system devices, and finally adding the correct users to the groups. These steps will be done via the NT user manager for domains and CHART II user GUI as mentioned above.
126.96.36.199.1.8 Areas of Interest
Procedure for introducing a new area of interest into the CHART II system.
Areas of interest will be implemented by adding and removing users from groups. Thus adding a new area of interest will require adding a new user group, assigning that group the appropriate system rights, and finally adding the correct users to the groups. These steps will be done via the NT user manager for domains and CHART II user GUI as mentioned above.
Procedure for adding a new map to the CHART II system.
The CHART II system will allow the user to open any AutoCAD Version 12 DXF format file as a system map. Each of the devices in the CHART system is aware of its GPS latitude and longitude position. If the map that has been opened contains the latitude and longitude position of the device, it will be automatically plotted in the correct position. If the map does not contain the coordinates of this device, the device will not appear. This procedure will work for all system devices but will not work for system links. System links will be drawn on the map using the CHART II map GUI software. The user will draw the link over an existing roadway graphic. He/she will then be presented with a dialog that will allow him/her to assign the new link graphic to an existing link database record. The updated map file may then be saved to disk and distributed to all CHART II workstations for use.
188.8.131.52.1.10 External System Interface
Procedure for adding a new connection to a known system interface. An example would be to export web data from a district operations center that had not previously exported to the web server.
The user will need to run the installation procedure for the appropriate service on the appropriate server machine in the district. The service will then begin collecting or exporting data and communicating with the transaction server.
184.108.40.206.1.11 Legacy Interfaces
Procedure for adding a new connection to a known legacy interface. An example would be to add a connection to the IEN system to a district that was not previously aware of the IEN interface.
The user will need to run the installation procedure for the appropriate service on the appropriate server machine. The service will then begin importing and exporting data to and from the legacy system.
220.127.116.11.2 Addition of New Capabilities
18.104.22.168.2.1 New Device Type
Procedure for adding a new device type to the CHART II system. A new device type is defined as a device type that does not conform to the protocol of any of the current devices.
The GUI may have to be modified to display the different characteristics of the new device. For example, in the case of a drum sign, the GUI might be updated to display a pick list of available messages. A system service might need to be updated to accommodate a different type of message. In the case of a drum sign, the VMS Server might have to be modified to handle the new message type. In addition, a new driver for the FMS may have to be written. If the new device type supplies additional data of interest to the incident detection subsystem, then that subsystem will have to be enhanced to support the new device data. If the new device type supplies data that needs to be archived, additional components of the archive service will need to be developed. Once the development is completed, the service will need to be reinstalled and the archive database will need to be extended. Note that any software changes can be made in such a way as to support the new device, and be transparent to or ignored by pre-existing system components.
New GUI software would have to be installed at each of the CHART II client workstations. Consequently, the system would be unavailable at that client workstation long enough to perform the install and ensure that the changes were made correctly. Changes to system services and the FMS can be made with minimal user impact. The only impact would be that affected services would be unavailable during the install process. Note that the impacted FMS could be manually placed offline prior to the reconfiguration, and then placed back online via the CHART II GUI.
22.214.171.124.2.2 New Algorithm
Logic that can be inserted into a system service, and replaced with minimal effect on its execution. A new incident detection algorithm is an example.
Deploying a new algorithm involves rebuilding the system service that employs the algorithm. If the changes required new GUI components, the new components would have to be developed. The workstations that need to interface with the new service will need to have the GUI re-installed. Additionally, if the new service contains data that needs to be archived, the archive service will need to be developed and reinstalled. If necessary, the archive database will need to be extended.
Changes to system services can be made with minimal user impact. The only impact would be that the affected service would be unavailable during the install process. If GUI changes are required, the new GUI software would have to be installed at each of the CHART II client workstations. Consequently, the system would be unavailable at that client workstation long enough to perform the install and ensure that the changes were made correctly.
126.96.36.199.2.3 New GUI Features – New Map Feature
A new object type or new feature of an existing object type.
This involves adding the new feature to the GUI, and rebuilding it.
New GUI software would have to be installed at each of the CHART II client workstations. Consequently, the system would be unavailable at that client workstation long enough to perform the install and ensure that the changes were made correctly.
188.8.131.52.2.4 New External System Interface
New data format being imported from an external system, or new data format exported to an external system
This involves writing a new import or export procedure. The existing external import and export system services will not have to be changed, but their driving databases would be modified to handle the data format
No user impact
184.108.40.206.2.5 New Link Definitions
Procedure for changing the existing links on a system map.
System links will be stored on a layer separate from all other map graphics. When the system links need to be modified, this layer may be exported to a DXF format file. This file may then be modified in AutoCAD. When the user has finished drawing the link graphics, the altered DXF link file may be merged back into the system map. The user may then click on each link and enter the necessary information to update the system database to enable the link for system data. All downstream links on the same road will be automatically renumbered to ascertain sequential system link identifiers.
The new map file must be distributed to all CHART II workstations for use.
220.127.116.11 Links and Modeling
The CHART II GUI utilizes links to represent sections of roadways. It is important to be consistent on the definition of links before examining the features of the CHART II GUI. It is also meaningful to consider the suggestions for assigning links and benefits of performing modeling with those links.
18.104.22.168.1 Link Definitions
Links and their representation on the map within the GUI will be configured as follows:
A link is a contiguous section of road in one direction that has uniform traffic characteristics. The status of the link is uniform throughout any one link and may be associated with a specific detector.
This implies that in the ideal general case there is one section of road between a source and a sink that has no changes in the numbers of lanes, and in approximately the mid-point of the link, a detector is constantly reporting the real-time traffic data.
The ideal case needs to be tempered with the reality of the fact that there are liable to be changes of geometry between sources and sinks, there are always more links than there are detection points. Additionally complications include locations where there is more than one data source per uniform stretch of road and in other cases, there are sections of roads where there are links with detection devices on every second or third link. These, less than ideal circumstances, will be discussed individually.
To link data within an architecture requires an open definable process to provide:
We propose to apply the following rules when allocating links.
22.214.171.124.2 Links and CORSIM
FHWA’s CORSIM traffic simulation model provides a wonderful opportunity for MDSHA and the University of Maryland (UM) to be able to use the proposed archived data user service to model the CHART II network to provide operational feedback. Modeling the network may, in the future, enable operational decisions to be made in real-time. For example, a separate application reading the real-time data can be run in parallel with operational decisions to evaluate their consequences.
The major factor affecting this process is that the two networks be compatible. This is a question of geometry and link definitions. The rules for link definitions defined above are based upon the system requirements. CORSIM has its own requirements for both surface street links and freeway links and these are listed below.
126.96.36.199.3 CORSIM Surface Street Links
CORSIM surface street links have the following characteristics:
188.8.131.52.4 CORSIM Freeway LINKS
Freeway links have the following characteristics:
The dynamic and signal control data associated with the links are not of concern to the CHART II link definition process although they are very definitely a requirement for the modeler. It is assumed that since all the operational data such as flows and speeds will be kept in an SQL database, such information will be readily accessible to the UM. Dynamic information such as turning movements and signal timings will need to be collected as an off-line process. For the CHART II operational system to be modeled, the geometric information must be comparable. Therefore, the first set of rules associated with the CHART II link definitions must also incorporate CORSIM geometric requirements considerations. This will result in the following:
It is proposed that the following steps be used to develop the link definitions with CORSIM compatibility.
Step 1. Meetings with MDSHA will define the geometrical aspects of state road network that is to be used in the CHART II operational system
Step 2. Meetings with the UM will agree the rules associated with link definition development.
Step 3. The project team will then apply these rules to the network to develop a link list.
Step 4. UM will then put these link definitions into CORSIM together with arbitrary default dynamic data.
Step 5. UM would then model the network to ensure that correct link definition.
Step 6. Following correction of any errors the link definitions could be loaded into the CHART II system.
Step 7. CHART II operations will begin with a CORSIM compliant network.
Another interesting feature is that the UM could use the map play feature of the proposed CHART II GUI to replay the data sets produced by the modeling. The CORSIM model could be run to provide one-minute data sets of speed on links. These could then be converted to the CHART II SQL data format and run through the map play process. This would allow the output to be visualized from the CHART II GUI.