U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590

Skip to content
Facebook iconYouTube iconTwitter iconFlickr iconLinkedInInstagram

California Division

Home / About / Field Offices / California Division / Systems Engineering Guidebook for ITS

Home What's New Systems Engineering Guidebook Views Search Glossary Resources Feedback Site Map

8.5.3 Maryland Chart Project

System Description

CHART (Coordinated Highways Action Response Team) is primarily an incident management system for roadways in Maryland.

CHART is a joint effort of the Maryland Department of Transportation, Maryland Transportation Authority (toll authority) and the Maryland State Police, in cooperation with other federal, state and local agencies. CHART's mission is to improve "real-time" operations of Maryland's highway system through teamwork and technology. The CHART program relies on communication, coordination, and cooperation among agencies and disciplines, both within Maryland and with neighboring jurisdictions, to foster the teamwork necessary to achieve this goal.

The CHART vision is comprised of four major categories of business objectives:

1. CHART is intended to be a statewide traffic management system, not limited to one or two specific corridors of high traffic volumes, but expandable to cover the entire state as funds, resources, and roadside equipment become available to support traffic management.

2. CHART is intended to be a coordination focal point, able to identify incidents, congestion, construction, road closures and other emergency conditions; and then able to direct the resources from various agencies, as necessary, to respond to recurring and nonrecurring congestion and emergencies. It should also manage traffic flow with traveler advisories and signal controls, and coordinate or aid in the cleanup and clearance of obstructions.

3. CHART is intended to be an information provider, providing real-time traffic flow and road condition information to travelers and the media broadcasters, as well as providing real-time and archived data to other state agencies and local, regional, inter-state, and private sector partners.

4. CHART is intended to be a 7 day per week, 24 hours per day operation with the system performing internal processing and status checks to detect failed system components and resetting or reconfiguring itself where appropriate, or notifying operators and/or maintenance staff where necessary for service.

The system being described here is actually the second version of the original CHART system, and is technically called CHART II. The first CHART system was the first major ITS project undertaken by the stakeholders, and that experience helped greatly when it came to the system replacement project. In particular, it clearly identified the need for more careful planning and sound systems engineering in developing large traffic management systems.

Unless stated otherwise, all further references to CHART here are referring to CHART II, for which a system integrator was selected in 1998. The new system became operational in 2001.

Physical components of the CHART system include the statewide operations center, multiple multi-agency traffic operations centers, multiple emergency response centers, private sector travel information centers, computers, information displays, vehicle detectors on roadways, weather sensors, closed circuit television cameras, dynamic message signs, traveler advisory radio transmitters, and motorist service patrol vehicles.

CHART software uses primarily Windows, Java, CORBA, and Oracle.

CHART Agencies and Their Roles

The program is directed by the CHART Board, consisting of senior technical and operational personnel from The Maryland State Highway Administration, Maryland Transportation Authority (operator of tolled bridges and tunnels), Maryland State Police, Federal Highway Administration, University of Maryland Center For Advanced Transportation Technology, and various local county and city governments in Maryland. The board is chaired by the Chief Engineer of the State Highway Administration. The Director of CHART and ITS Development, and the CHART System Administrator, are employees of the Maryland State Highway Administration, the lead agency. These are the primary agencies involved in developing the system.

These and many other organizations are involved in the use of CHART. These include: Maryland Aviation Administration (Baltimore-Washington International airport), Maryland Emergency Management Agency, Maryland Institute for Emergency Medical Services Systems, Virginia Department of Transportation, Washington DC Department of Transportation, Ravens and Redskins football stadiums, and US Park Police. CHART has recently replaced application software-based workstations with a web-based user interface to increase usability for operators as well as to simplify remote access.

The University of Maryland Center for Advanced Transportation Technology serves as a data clearinghouse for CHART. It makes both real-time and archived data available to interested parties. The university performs periodic performance reviews of CHART. These reviews have been conducted annually in the past but are now conducted quarterly. The University also uses CHART data in research activities.

CHART Contractors and Their Roles and How Selected

The CHART agencies contracted with Computer Sciences Corporation (CSC) to develop the new system. CSC has assisted in all facets of the project, including refinement of the project objectives and requirements, system design, development, validation, deployment, and on-going maintenance.

The software contractor was selected via a design competition. The CHART agencies developed a solicitation document that described objectives, a concept of operations, and functional requirements. Three systems development firms with existing multiple-award contracts were identified as suitable candidates for building the new system. Each was funded to develop and document a proposed approach, and to build and demonstrate prototype software that illustrated that approach. Two firms responded, and one was selected.

An attractive feature of the selected contractor was their emphasis on a rigorous systems engineering process, based on their routine internal systems development procedures. Their internal procedures and tools were used openly with CHART stakeholders, and included techniques for refining objectives and requirements. For testing purposes, the contractor maintains a replica of the system and its operational environment, at its facilities.

Separately, two other firms were hired to provide independent oversight of the software contractor. One firm performed software code reviews to ensure the software was sound. The other monitored the contractor’s system development procedures to ensure they were being appropriately used.

The value of the rigorous software standards and documentation was realized when two subsequent software enhancement projects were awarded to still other firms who were able to successfully integrate new modules with the base software.

Agencies' Previous Systems Engineering Experience and Capabilities

The CHART agencies and involved personnel had very limited experience with the formal systems engineering process prior to this project. Recognizing this shortage of experience and knowledge, they made it a priority to select a contractor that would be able to bring systems engineering experience, tools, and procedures to the project.

Systems Engineering Management Planning

The systems engineering process to be used, who is responsible for what, and the resources needed, were documented in the Project Management Plan and Contract Management Plan. These documents were updated for each stage of software development. Separately maintained was a High-Level Five-Year Development Schedule.

At the time of this project, the CHART agencies had no formal procedures or requirements for systems engineering. In 2002, the Maryland Department of Budget and Management published systems engineering templates under the title of Systems Development Life Cycle, and these procedures are being used in on-going CHART maintenance and development activities.

Comments on the Overall Experience

The CHART system was successfully deployed and has achieved its goals. Annual evaluations performed by the University of Maryland have documented the considerable benefits of CHART, which far exceed its cost.

The systems engineering procedures used were extremely helpful, during system development and especially for on-going system operation and maintenance. The considerable time spent interviewing stakeholders and CHART operators was important in refining the system requirements and building the right system.

The original plan to provide a complete system that met all requirements in version 1, was found to be impractical. Some items turned out to be too difficult to build completely or debug completely within the time and budget available. A pragmatic approach was adopted whereby the say 80% of functionality that could be readily provided was released and put into service quickly, with documented workarounds for missing features and bugs. The missing features and bug fixes were re-scheduled into later versions, along with other enhancements found necessary based on initial operating experience. A flexible time-and-materials contract and close working relationship with the software developer, were key to enabling this change in approach.

The size, complexity, and number of users of the system are making it increasingly difficult to quickly make system changes and enhancements. Complete regression testing following every change is becoming impractical. Interruption to system use during upgrades is an issue.

System development never ends, and there is an on-going need for funding of this activity. A three tiered software maintenance approach has been adopted – routine maintenance (e.g., upgrade operating system as existing one becomes obsolete), bug fixes and minor functional enhancements (new builds), and major functional enhancements (new releases). It is sometimes desirable to employ different software teams with different specialties for different tasks. Coordination of different overlapping efforts by different developers is a challenge going forward.

CHART management personnel see a need to become more adept at estimating the cost of planned major software enhancements, and are undergoing project management training accordingly. This will help in budgeting specific funds for such projects in future years, over and above a base-level of on-going routine maintenance funding.

Innovative approaches have been used successfully in the past, and will likely be used again. It has been a big help having a CHART Board of Directors, composed of senior transportation managers that are very supportive of the program, appreciative of the challenges it faces, and of trying different approaches. They saw the value of spending more in the short term on rigorous systems engineering for long term gain.

The Key Lessons Learned in the Application of Systems Engineering to CHART

The rigorous systems engineering process took time and money, but paid off in the successful operation of the system and the ability to maintain and enhance it.

High Agency involvement in the definition of the system was important to the system development.

Well documented software allowed other system integrators to upgrade the system.

A time-and-materials, task-order agreement with the primary contractor allowed the system to evolve over multiple incremental versions rather than a single deliverable as originally envisioned. This allowed more rapid implementation of the base system, and subsequent feedback from users lead to a better final product.

Despite the thorough software documentation, on-going software maintenance and enhancement upgrades have been found to be very time consuming. Software maintenance activities have therefore been divided into three categories – routine maintenance (e.g., upgrade operating system), minor functional changes and fixes, and major functional enhancements.

Better software cost estimation skills by the agency are desired and the agency is pursuing Project Management Institute (PMI) certification for all major IT project managers.

Using a qualified independent verification consultant was a contractual requirement of the agency and is felt to have been critical to the success CHART has achieved to date.

The contract required that the software contractor have a solid history of using systems engineering and required the winning contractor to bring its documented internal systems engineering processes to the project and train the agency in its use. The State now has a published Software Development Life Cycle that it uses for all major IT projects in identifying the concept of operations, needs, and requirements, as well as actual software development.


Richard Dye, CHART Systems Administrator, generously contributed his time for interviews, and contributed much of the information collected for this case study. Rick was also instrumental in having all significant documentation associated with the system posted in the CHART website’s Reading Room. The website has been an invaluable resource for this study, and is recommended to the reader interested in obtaining additional information about CHART. http://www.chart.state.md.us/

Table 8‑3 Summary – CHART Systems Engineering Activities by project phase

Process Task

Process Used

Documents Produced

Agency Effort


Explanation, Issues, Problems, Lessons Learned


Nothing formal under CHART II effort, because were operating a system

No formal documents under CHART II.

Various meeting minutes, etc.


Building CHART II was a replacement and enhancement of the original CHART system.


Two stages - CHART personnel determined what was needed prior to design competition, then much more planning conducted jointly with the contractor.

Business Area Architecture.


Contractor helped the agency with system planning. Time and materials contract with task orders was critical to allowing contractor work to vary as needs were identified.

Concept of Operations

Partially done in preparation for design competition. Enhanced as part of business area architecture once integrator on board.

Software Functional Requirements Document.

Business Area Architecture.


Agency used the contractor’s systems engineering procedures to document the existing system operation, and to identify further needs, and requirements.

Validation Plan

Nothing formal.



Evaluating the finished system was always planned in peoples’ minds, but not formally documented.

System Requirements

Functional requirements developed for design competition. Refined in consultation with contractor.

Software Functional Requirements Document.

Business Area Architecture.

CHART II System Requirements.


Business Area Architecture process worked very well to identify needs and requirements. BAA didn’t get continually updated. Will do this next time.

System Verification Plan

Done by contractor during software development. Approved by agency.

Integration Test Plan.

Test Procedures.

Test Plan.


Worked well. An avenue for use of disadvantaged small businesses on the contractor team. Complete regression testing now becoming impractical. Need to determine how to choose what regression testing to do under what circumstances.

High Level Design
Sub-system Requirements and Verification Plans

Several technology studies done of specific issues, such as which standards to use. Contractor did test plans for internal testing of sub-systems.

High Level Design (for whole system and for various sub-systems and components).

Unit Testing Plan.


Extensive effort and agency involvement in this was worthwhile and process worked well. The contractor had extensive procedures and documentation for internal testing at each level.

Component Level Design

Graphical user interface and other distinct elements were described, and prototyped where appropriate.

Graphical User Interface Detailed Design.

Database Design.

Server Design.


Agency involvement in reviewing prototypes and interim progress was very worthwhile.

Hardware and Software Development

Followed contractor’s internal procedures. Independent contractors monitored software code and processes.

Documented Source Code.

Acceptance Document.

Regular reports from independent verification contractors.


Independent verification contractors used to monitor software code quality and integrator’s software development procedures.

Unit Verification

Agency reviewed prototypes where applicable. Contractor performed further internal testing.

Contractor reports.



Unit Integration

Not treated separately as such.

Contractor reports.



Sub-system Verification

Used test environment in contractor’s facilities. Contractor demonstrated user interface and other key items as soon as available.

Contractor reports.


The test environment set up in the contractor’s facilities was valuable in conducting realistic component and sub-system testing. Independent verification contractor monitored this and other contractor internal processes.

Sub-system Integration

Contractor performed integration.

Contractor reports.



System Verification

Formal acceptance tests of the installed system were witnessed and approved by CHART personnel.

System Test Report.



Worked well. Found impractical to fix all problems. Write a problem report, evaluate cost of fixing it versus cost of operating with a workaround. Often best to leave it and pick it up in next build rather than delay deployment of the system.


Contractor took lead in deployment planning, for each build.

Transition Plan.

Operational Readiness Review.




Informal feedback from the users.

University of Maryland does periodic evaluation.

CHART Evaluation Reports.

E-mails from operators.


Evaluation by University of Maryland has confirmed that the system works as planned and delivers value for the investment. Informal operator feedback turned into requirements for future builds.

Operations and Maintenance

Contractor prepared operation (user), administration, and maintenance documentation for each build.

Operations and Maintenance Guide.

Users Guide.

Software Development Guide.


The Software Development Guide provides the information a third party developer would need to modify or interface with the existing CHART software. This is key to providing flexibility in choice of contractors for future work. Two separate contractors have already made system enhancements.

Changes and Upgrades

Change control board. Configuration of hardware and software are tracked via three levels – requirements maintained in DOORS, problem reports in ClearQuest, and source code in ClearCase. Hardware configuration documented in mainframe financial reporting system.

Reports generated from online tools as needed.



Software configuration is managed very thoroughly. Hardware and network configuration are not so well managed, and an effort is underway to correct this.


Previous Document section | Next Document section
Return to top
Page last modified on January 31, 2017
Federal Highway Administration | 1200 New Jersey Avenue, SE | Washington, DC 20590 | 202-366-4000