The team of Computer Sciences Corporation and PB Farradyne Inc. (CSC/PBFI) is pleased to respond to the Maryland State Highway Administration’s (MDSHA) request for design documentation for the replacement of the Maryland CHART Advanced Traffic Management System. This replacement system is referred to throughout this document as CHART II.
Our response demonstrates that:
We look forward to working in partnership with MDSHA in the development and implementation of software designed to meet CHART II needs well into the next century.
OUR VISION AND STRATEGY
A successful CHART II system must help manage Maryland’s diverse traffic management challenges and overcome the shortcomings of the existing system. CSC and PBFI believe that success is predicated on constantly working to understand MDSHA’s needs and providing innovative solutions. We have developed a vision for CHART II that has its foundation in the mission statement contained in the CHART Business Plan—"…to improve efficiency and safety on Maryland’s major highways through the application of ITS technology and interagency teamwork…"
Our vision is to develop, in partnership with MDSHA, a CHART II system that:
Our strategy for achieving these results is based on:
The Application of the Proven, State-of-the-Art ITS Technology—We will work closely with end-users, MDSHA project managers and technical staff, and equipment vendors to ensure that only state-of-the-art ITS software applications and equipment are selected to support CHART II (Section 4). We will provide total life cycle support (Section 5).
Teambuilding and Open Communications—Our project management style involves MDSHA staff and CSC/PBFI Team members actively working together towards common goals and objectives. The CSC/PBFI Team will frequently and openly communicate with MDSHA and its clients. This will start with negotiations and continue through software development, deployment, and operations and maintenance (Sections 6.4 and 6.5).
The Assignment of Our Best Managers and Technical Staff to this Task—Only our most experienced software managers and developers, and system engineers will be assigned to CHART II (Section 6.5.8).
This is the way in which both firms interact with customers and achieve results. It is inherent in the way we do business.
Our ability to implement this strategy is further enhanced by the fact that we are local firms, readily accessible to MDSHA personnel and its clients. We are here not just during system implementation—we are here and immediately available during the entire life cycle of the system. More to the point, we are customers of the system because we live and work in the State of Maryland. We are never more than a few minutes away.
OUR DESIGN CONCEPTS
Before describing our design solution, there are certain design concepts that are uniquely responsive to MDSHA needs. These concepts include the following:
Iterative Requirements Identification, Analysis, and Management. Allowing for the identification of new requirements throughout the development process ensures that CHART II will be fully responsive to MDSHA requirements on the day that it is delivered. It ensures that "lessons learned" during one-on-one discussions with MDSHA personnel and from system prototyping are included in the final solution. It ensures that both MDSHA and CSC/PBFI personnel are fully involved in all key decisions (Section 3.3.1).
An Open Systems Approach. By employing only open systems, we ensure consistency with the National ITS Architecture and emerging national ITS standards. Open systems ease the incorporation of legacy systems and communications with external systems, permit interchangeability of system components, and facilitate system growth (Section 3.3.2).
Object Oriented Analysis, Design, and Implementation (OOAD&I). This approach to software design allows system design information to be related in terms of ITS components instead of abstract computer science terms throughout the life cycle of the software. Enabling better communications between client and developer ensures more successful systems. It is particularly appropriate for complex systems integrating text, graphics, pictures, sound, and video, i.e., CHART II. OOAD&I allows complex objects to be manipulated in an intuitive and organized manner and allows the building of new objects by combining properties of previously existing objects. Applications are easier to maintain and enhance than with other design approaches. New applications can also be built on existing applications without the need for restructuring the underlying data, thereby reducing development time and easing maintenance (Section 3.3.3).
System Prototyping. Prototyping the system, as it is developed, identifies problems early in the development process. In effect, it permits MDSHA to "fly before buy" thereby ensuring the delivery of a system responsive to MDSHA needs (Section 3.3.4).
Incremental Deployment. Deploying systems in a multiple, frequent release strategy provides an earlier operating capability, incorporates user operating experience into later deliveries, and promotes high morale through a series of successes instead of a big bang approach (Section 3.3.5).
These concepts are incorporated in every aspect of the design solution that follows.
KEY FEATURES OF OUR DESIGN
Our CHART II technical solution has been designed from the perspective of the user—the system operator. The features and benefits of our engineering approach and our design concepts are summarized in table 1-1.
Table 1-1. Our Engineering Approach and Design Concepts
CSC/PBFI Advantage: Our engineering approach and design concepts support a solution fully responsive to MDSHA needs.
Benefits to CHART II
Our Engineering Approach
Iterative Requirements Identification
Our Design Concepts
Built on Planned Telecommunica-tions Infrastructure
Innovative, Repeatable Software
CHART Operator Interface
We provide operators with the tools to collect, process, and analyze traffic information from throughout the state and use that information to make real-time traffic management decisions and initiate corrective actions. Operators may work at workstations that consist of two monitors—the result of which effectively doubles the screen space available for work. Under this configuration, one monitor can display traffic conditions throughout the state and the other can be used for running related software applications. See Section 4.3.3 for further details.
The details of our proposed CHART II user interface have been demonstrated in a series of prototyping sessions held with CHART stakeholders and we will continue to learn your needs and communicate our resulting design in this way. We will remain open to new ideas, and incorporate input provided by our colleagues at the University of Maryland Human Computer Interaction laboratory as they may be provided.
The CSC/PBFI Team offers a distributed approach providing compelling advantages for information distribution and communication efficiency, and offers superior availability for CHART computer and data assets relative to a centralized approach (see Section 4.3.1).
A geographically distributed architecture based on the Statewide Operation Center and each regional Traffic Operation Center offers some distinct advantages. One of the most compelling is survivability. Each distributed processing site is a logical microcosm of the total system. Failure of a single site does not result in extended failure of the system while field devices are re-terminated onto the alternate data center and consumers are not totally blinded. Further, any processing site can assume responsibilities of a central traffic management center (TMC) disaster recovery site. A geographically distributed architecture also lends itself to efficiencies of parallel operation and communications.
The CSC/PBFI Team will ensure CHART II is an open system, meaning that the operating system complies with the IEEE Portable Operating System Interface (Posix) suite of standards and the system uses generally accepted International standard communications protocols. That is, although CHART II will execute on Microsoft Windows-compatible client desktop computers, Microsoft Windows NT application servers, and Sun UNIX database servers, software developed for specific traffic devices will be portable and platform independent. CHART II will by definition be able to run across heterogeneous networks made up of all platforms (Section 4.3.2).
There are nine functional areas in the CHART II applications (see Section 4.3.4) accessed via the operator interface:
The system software architecture that will support these functional applications is shown by figure 1-1. External and legacy systems that need to communicate with CHART II will do so via a database that has implemented the National Architecture for ITS Traffic Management Data Dictionary (TMDD) schema.
The CHART II database will be implemented using a distributed model. There are two main reasons for this. First, information is located closest to where it will normally be used. Second, a distributed database enhances system survivability. The Oracle commercial DBMS engine will automatically retrieve requested information from where ever it is stored in the distributed system.
Figure 1-1. CHART II System Software Architecture
Our open software architecture is device and platform independent.
FMS/AVCM Subsystem Software Architecture
The CHART ATM Video Control Manager (AVCM)/Field Management Station (FMS) subsystem (see Section 4.3.5) provides three major architectural elements:
These capabilities ensure that MDSHA’s investment in the ongoing CHART Network Implementation is preserved.
Several legacy ITS applications will be integrated with CHART II: SCAN, EORS, Econolite Aries signal control system, and WSI Weather for Windows via their database. The mechanics of information transfer between the legacy application and the CHART II consumer will be performed using the accepted industry practice of wrapping legacy data with a so-called "object-wrapper", via an applications programming interface designed specifically for this purpose (Section 4.3.6).
Since it will be designed as an open system, CHART II will have interfaces to several external transportation systems for information interchange, specifically with the Virginia Department of Transportation (VDOT) signal control system in Northern Virginia, the Montgomery County system, the Partners in Motion system, the VDOT Freeway Management System in Northern Virginia, and with the I-95 Corridor Coalition’s Information Exchange Network. The kind of resource access required by each of the external systems is for various queries against the CHART II Database. Because these external systems each "speaks" in a different legacy format, there will be a protocol translator (PT) interface to each (Section 4.3.2).
CHART II communications will be based on work in progress to implement the CHART Backbone Network, CHART AVCM, and CHART FMS—although the CHART II FMS will have far more functionality than its predecessor. The core of the network will be formed by ATM switching nodes currently being installed in the SOC, District 3 and District 4. This is consistent with the CHART Business Plan and telecommunications implementation that this team is performing on-schedule and within budget (Section 4.3.7).
The CSC/PBFI Team has allocated enforcement of the CHART II security policy—security and protection of CHART II data and computing systems—to the operating system and CHART II database management system.
The first level of defense will be enforcement of a personal security profile for each individual authorized to log onto a CHART workstation, server, or other intelligent device. Each individual will be assigned one or more roles that include certain system authorizations.
The second level of defense is the capability of our selected RDBMS, Oracle, to enforce a security policy by use of an access control list (ACL). An Oracle ACL can contain individuals and groups and enforce row (record) as well as table (database) granularity. It can even be used to exclude access to a member of a group normally allowed to access a row or table. For example, a person can be assigned to a group called HR. The group HR can access all records of a personnel database. However, this person can be prevented from seeing personnel information about themselves, their supervisors, and others by including the person’s user ID on the group member exclusion list for those specific records.
The CHART II security requirements, vulnerabilities, threats, and design countermeasure recommendations draw strongly on CSC’s prior studies for the U.S. Department of Transportation, John A. Volpe National Transportation Systems Center: State of Maryland Intelligent Transportation Systems Security Requirements Recommendations, November 1, 1997; and State of Maryland Intelligent Transportation Systems Security Implementation Recommendations, November 1, 1997. Security issues are discussed in greater detail in Section 4.3.8.
Two key features of our software design are our innovative use of graphical user interfaces (GUI) and our selection of operating platforms for the system components based on their ability to do the job.
A Superior GUI
The GUI for the CHART II system as shown in the prototypes delivered with this document is entirely new (see Section 4.4.2 for more details). It has been developed specifically to respond to the requirements contained in the RFP as well as the comments expressed by MDSHA staff during the development of this design. In addition the design of this GUI has been significantly influenced by feedback that the project team has obtained from a variety of users of other GUI’s that are currently operational in traffic control systems. This feedback from other users was in response to systems that had conventional pull down menus as the basis for the interface. The most common complaint was that there were too many clicks, too many windows, and inadequate alerting mechanisms. In contrast, our approach is that:
This approach will provide far superior performance of our system.
The Right Platform For The Job
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—and from the following classes of requirements: security, performance, scalability, stability, usability, open system, and multi-tasking/multi-threading (Section 4.4.3).
The CSC/PBFI Team recommends the following choice of platforms for the CHART II system:
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 workstation. Windows NT Workstation 4.X is recommended for this reason.
Application Server. Greater availability of software development tools, a strong and growing market acceptance (both ATMS markets and general), a more plentiful skills availability, a slight edge in how security has been engineered into the operating system, more favorable functionality, and ease of administration all favor the selection of Windows NT Server as the platform of choice.
Data Server. 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 levels unanticipated now), and the system design’s reliance on a replicated data base to which application servers make query transactions, favor the selection of a platform that is tuned for data input/output, and performance scaleability. UNIX (in this case Sun Microsystems) is the platform of choice.
ARCHIVED DATA USER SERVICE
Recently, the use of ITS-derived data as a resource for planning activities reached a milestone with the establishment of an Archived Data User Service (ADUS) as a new ITS user service. We propose that in order to have an effective outreach to stakeholder groups who would be interested in an ADUS and which are primarily not traffic operations oriented, a process be set up during the implementation of CHART II to create an Archived Data Work Group (ADWG) that would parallel the established CHART Working Group (CWG). We are prepared to take the lead in assisting the MDSHA to establish such a group.
We anticipate four levels of access to ADUS:
We propose a number of special transportation planning and engineering analysis tools and concepts that would support ADUS activities and these are described in our design. See Section 4.5 for additional details.
Consistent with our proven systems development methodology, test plans will be developed for testing the various system components and the overall CHART II system. Testing and system deployment will take place in an iterative fashion, permitting "lessons learned" from earlier testing and deployment to be applied to later iterations.
Training will be provided to CHART engineers, operators, and technicians in the operations and maintenance of the new CHART II system. Training methods and materials will be developed in conjunction with CHART personnel to develop methods and materials suitable for the target audience. Three types of training courses will be presented:
A variety of training techniques (instructors, CBT, etc.) will be employed and emphasis will be placed on "hands on" training (Section 4.6).
LIFE CYCLE OPERATIONS AND MAINTENANCE (O&M)
While the importance of life cycle O&M cannot be over emphasized, we believe it is premature to select a particular approach for providing that O&M support. However, there are three basic approaches that appear appropriate:
In-house Support. While this traditional approach provides the MDSHA with total control over their operations and the opportunity for sharing personnel across similar operations within the State, it also burdens the MDSHA staff positions and overhead structure necessary to support these activities at a time when most State governments are trying to reduce staffing and overhead costs.
Privatization. This approach too is traditionally used and places the burden of performing certain very specific tasks on a commercial contractor while retaining portions of the work for in-house performance. However, under this approach a very rigid scope of work is normally established and adding unanticipated tasks to often difficult and expensive.
Facilities Management. A final approach is to employ a broad facilities management or "outsourcing" arrangement that provides more flexibility and incentives for both parties than that normally provided by a privatization contract. Under such an contract, service level agreements are established that specify the level of performance desired and often establish incentives for exceeding that performance. Because it is paid for mission fulfillment, the contractor has the incentive to seek efficiencies and cost-effective techniques for achieving the contract objectives.
During the development of the system, we will perform a cost/benefit analysis of these three options and make specific recommendations to the MDSHA (Section 5.3.2).
MANAGING THE PROGRAM
Process, organization, personnel, and experience all contribute to the success of a program—an innovative technical solution alone cannot ensure success. For that reason, we include here an overview of the most important features of our management approach.
The CatalystSM Methodology
CatalystSM is the structured methodology we employ to implement our technical and management approach. A total methodology for business change and for complex system development, Catalyst facilitates and guides application system development, integration, deployment, and operational services. It provides the formal structure within which we work.
CSC has used Catalyst for over 19 years to support a wide range of commercial and Government customers. Catalyst is thoroughly documented in 16 volumes and is available to all CSC/PBFI Team employees. In fact, it guides the work that CSC and PBFI are now doing for the CHART Network and our two companies are currently pursuing other ITS projects using this methodology because it right for our team, our clients, and for the ITS industry.
Catalyst supports the criteria of Carnegie Mellon University’s Software Engineering Institute (SEI) Capability Maturity Model (CMM) for Software Development. CSC, an SEI fellow, has recently achieved Level 4 of the CMM, one of only 9 companies in the world to do so.
The use of Catalyst ensures that:
The Catalyst methodology is unique to the CSC/PBFI Team. We have each made an investment in using it, and believe that the goal of achieving success in a timely and cost-effective ATMS implementation depends on it (Section 6.2).
Organizing for Success
We assume that CHART II be implemented within the framework of the MD NMS contract. Performing this task under the MD NMS contract ensures that quality assurance (QA), configuration management (CM), and other staff support available under that contract is available to support this task as well. Further, by having the Task Manager report directly to the CSC, MD NMS Program Manager, the CHART II task is assured the immediate attention and support by not only that program manager but also the CSC Vice President for Information Operations. These individuals will be available at all times to MDSHA managers (Section 6.5).
The CSC/PBFI Team is proposing Mr. David Snyder as both the CHART II Task Manager and the Senior Manager for Development Coordination (System Engineering). Similarly, Mr. John Schumitz is being proposed as the Task Manager for Software Architecture/Development. Mr. Schumitz will be supported by the Mr. Scott Melby, Deputy Task Manager. We have also chosen to identify our Task Manager for Deployment, Mr. Mark Thompson. Mr. Snyder is a CSC employee currently supporting the CHART II AVCM effort. Mr. Schumitz and Mr. Melby are PBFI employees currently supporting the CHART subtask under the MD NMS contract. Mr. Thompson heads the PBFI Systems Engineering Department. See Section 6.5.8 for additional information. Detailed resumes for each are contained in Appendix F of this document.
Resource Sharing—One Approach to Reducing CHART Costs
While every effort has been made to minimize projected CHART II costs through the use reusable code, COTS packages, and rapid prototyping design/development methodologies; there are yet other creative approaches that MDSHA might wish to consider to achieve even greater savings. "Resource sharing" is just one such example.
We have identified two resource sharing partners that are interested in a cost sharing arrangement with CHART stakeholders in return for access to both longitudinal Right of Way as well as prospective wireless tower sites. Each of these offer the potential for cost mitigation to the CHART II systems integration effort and together are estimated to lower the net MDSHA cost for CHART II by as much as 50% of the budgeted cost.
Should the CSC/PBFI Team be selected and awarded the CHART II project, we are fully prepared to discuss these options and their incorporation into our proposal (Section 7.3).
OUR COMMITMENT TO THE MDSHA
We are committed to working in partnership with MDSHA and delivering a CHART II software system fully responsive to MDSHA needs. We will make available to MDSHA our best software managers and developers, and system integrators. We will meet with MDSHA as needed to ensure a full and open dialog on all matters related to this project. We will provide whatever reporting is necessary to give MDSHA full visibility into our progress. We will be constantly vigilant to identify areas to improve system performance or reduce system costs. In short, we will do everything necessary to ensure the success of CHART II for all concerned.