The Advanced Regional Traffic Interactive Management Information System (ARTIMIS) is currently under development in the Cincinnati metropolitan area. The system will cover the bi-state area which includes Cincinnati, Ohio, Covington, Kentucky, and surrounding suburbs.

ARTIMIS represents the coordinated efforts of the Kentucky Transportation Council, the Ohio Department of Transportation, the FHWA, OKI--which is the MPO for the area--and the City of Cincinnati. TRW is the major contractor for the system, which is currently in development, with full deployment scheduled for October 1996.

As Raj mentioned, one of the challenges of this project has been the involvement of multiple jurisdictions and two states. Ohio is a home rule state, which means that the cities have total control over the roadways in their jurisdictions, including the Interstate system. The municipalities provide all police, fire, and EMS services on these facilities. There are some 20 jurisdictions and 80 agencies in the area covered by ARTIMIS.

The goals of ARTIMIS are to improve air quality levels, enhance overall safety, and decrease travel times. To do this the system will ultimately provide pre-trip travel information, in-vehicle navigation capabilities, in-route guidance, traffic and congestion management, and other services.

I-75 and I-71 form the main north-south freeways in the area. ARTIMIS will encompass 88 miles of the freeway system. Approximately 75 percent of the project is in Ohio and 25 percent is in Kentucky. The system involves 825 loop detectors, 60 wide beam radar units, 26 video detectors, 50 closed circuit television cameras, 43 changeable message signs, five highway service patrols, HAR, and telephones for traffic information queries. Communication will be by fiber optic cable and the control center will be located in downtown Cincinnati.

The development of the system was initiated by OKI, partly in response to the designation of the metropolitan area as an air-quality non-attainment area. A committee was formed by the two states to develop a plan for the system. The result of this effort was the OKI ARTIMIS Implementation Prospectus published in 1993.

A Policy Committee, comprised of representatives from the two state departments of transportation and OKI, was established to oversee the development of a request for proposal (RFP) for consultant services, the selection of a consultant team, and the deployment of the system. A Technical Committee was also formed. This committee includes members from both states, OKI, the City of Cincinnati, and the FHWA. There are also four subcommittees, including one on software which I head. Kentucky assumed the lead on the project, in part because of more flexible procedures in the consultant selection process.

The development of the RFP was a major challenge. I was concerned about the lack of detail concerning the system software. There was only one sentence in the initial RFP concerning software. After discussions with many people and extensive reading, we were able to expand the software specifications significantly. This was especially important since a lump sum contract was going to be awarded to the selected consultant. I think it is very important to ensure that the software specifications are clearly spelled out, since the software is the core of the system.

Based on our experience, I would also stress the critical need to communicate and coordinate with local jurisdictions and agencies. Bringing them into the process early is important. This should include listening to their needs and problems and showing them how ITMS will help them do their job better.

I hope to be able to report more on the status of ARTIMIS at the next Symposium. Further, we would welcome the opportunity to host a future ITMS Symposium in Cincinnati.

Legal and Procurement
Cindy Elliot, ITS Joint Program Office, U.S. Department of Transportation

It is a pleasure to have the opportunity to talk with you today. Others have mentioned the importance of the early invovlement of all groups in the ITMS planning process. I would strongly encourage that attorneys be part of this group. Attorneys can help with issues that may cause problems later in the development process. Identifying and addressing potential issues early can help reduce unanticipated delays in the implementation of ITMS.

The U.S. Department of Transportation's ITS institutional issues program is focusing on more than just legal issues. Environmental and social issues, mainstreaming ITS and the planning process, inter-jurisdictional concerns, privacy issues, and liability issues represent just some of the other areas being examined. An initial scoping of the major issues in all these areas has been completed, and we are now focusing on practical applications that will assist in the deployment of ITS. This effort is not focusing on a "one size fits all approach." Rather, we are looking at the experiences from projects around the country, including those highlighted at this Symposium, and identifying approaches which appear to work.

Two projects underway are focused on this kind of experience sharing. They also involve a legal research component. One of the projects is examining shared resource ITS activities. The other effort is examining innovative contracting procedures.

One of the issues being examined is the effectiveness of different contract instruments for various ITMS deployments. Most people are familiar with fixed-price and cost reimbursement contracts, as these approaches are commonly used with all types of projects. More innovative contracting mechanisms include design/build, build-transfer-operate, build-operate-transfer, and cooperative agreements. These approaches may provide greater value to agencies on some types of ITS projects.

Some agencies have experience with design/build approaches, while others are considering it. Build-transfer-operate is commonly referred to as a turnkey approach, while build-operate-transfer is known as the privatization approach. Cooperative agreements have been used with some of the ITS Operational Tests. Concerns have been raised by the private sector on whether this approach is competitive enough for deployment, however.

We are also examining the effectiveness of contract award methods for different ITMS procurements. You are all well aware of the problems with low-bid procedures for the procurement of high technology systems and projects. These problems have sometimes resulted in the separation of the design and the construction phases of a project. Better value may be obtained from the contractor, however, if these two phases can be combined.

There appears to be a good deal of interest on the part of public agencies in considering performance criteria in procurements. Although public agencies have a good understanding of the goals and functional requirements of a system, they may need assistance in developing the technical specifications. The private sector may be looked at for this expertise. There is concern among private firms with this approach, however, which has resulted in a good deal of litigation. Functional and performance requirements are not easy to develop and the private sector often complains that public agencies do not do a good job of outlining what they want.

A number of private companies have identified numerous ideas for partnerships with public agencies. This approach, known as private initiatives or sole source awards, has not been used widely, however. States vary in their ability to use sole source contracts. Staged procurement is another approach being considered in some areas. One concern among the private sector with this approach is that it lacks predictability. There is no guarantee with this approach that a company making significant investments in the development of a proposal and the early phases of a project, will be awarded later phases of the contract.

One real challenge in developing public/private partnerships is determining the value of the different elements. These might include the value of the public investment in the cost sharing elements such as goods and services, the value of the risk being assumed by the public sector, and the research and development costs assumed by the private sector. There is also a good deal of controversy over the treatment of intangible assets and how system integration is paid for.

A number of benefits may be realized through combined or coordinated procurements. Many of these are well known. The ability to increase the purchasing and negotiating leverage with vendors may be one of the more important of these benefits.

Other speakers have touched on some of the administrative difficulties of different contracting approaches. Many of the more innovative approaches are subject to political and administrative changes. New approvals may be needed with new elected officials or administrative personnel. Further, joint efforts may be very time consuming. Private sector groups have expressed concerns with the time it takes to address the requirements of numerous public agencies. There is also an ongoing need to ensure the compatibility of the technology being used by the different agencies.

As I noted, a major part of the institutional program in this area is identifying good experiences and case studies. We are also developing training material that can be used by a wide range of groups. Some of the initial training efforts are focusing on the use of flexible procurement regulations and the development of technical specifications. I would welcome any ideas you might have on training needs and training approaches in this area.

There has been a good deal of interest in shared resource projects by state departments of transportation. There are a number of legal and political issues associated with shared resource projects, however. In addition, telecommunication agencies are very concerned about groups that create their own systems rather than taking advantage of capacity in existing telecommunication systems. This issue has created a good deal of political interest and Congress is considering possible legislation in this area.

Another shared resource issue relates to if a utility accommodation policy provides the authority to use public right-of-way for telecommunications. Some areas have found many telecommunication companies already have established access and do not have any interest in the public sector projects.

One of the most important issues with shared resources is the lack of public sector authority to receive or earmark compensation from public/private projects. Many states are simply not interested in such arrangements. This issue has wider ramifications for public/private partnerships in many areas.

There are a number of financial issues that also need to be addressed. One of the more important of these concerns relates to how public resources are valued. A variety of techniques have been used to assess the value of public resources on projects, but no one best approach has emerged. Some examples of methods used to date include competitive auction, cost of the next best alternative, and needs-based compensation.

Project structure issues may also need to be examined. The type of consideration is one of these issues. When valuing any public resource, it is important to consider not only current needs, but also future needs. For example, there have been cases where the full long-term value of a right-of-way was not adequately consider in the valuation process.

There are a number of other issues that should be examined to ensure that the best agreement is realized for all groups. These include concerns related to relocation, system modification, geographic and social equity, liability, intellectual property rights, and the potential for one community or area to be favored.

Finally, privacy is a major concern with ITS among many groups, especially the public. We need to do a better job of explaining ITS and the benefits of ITS projects to the public. One lawyer has said that "ITS is infested with nearly impenetrable and constantly changing acronyms, not to mention obscure technical language which is frequently understandable only to the most intrepid technofile."

On the other hand, the public seems to have grasped the privacy issues associated with ITS. Even the New York Times has questioned the privacy implications of ITS. This is an area we need to be extremely sensitive toward. We have sponsored a number of studies on the privacy issue, and there are some excellent reports available on how to ensure privacy safeguards. There are three major ways to address the privacy issue. These include technical strategies, the development and use of industry fair information principles, and federal or state statutes. All three approaches will need to be used to ensure privacy safeguards with ITS.

Thank you for your kind attention. There are a number of other issues I could discuss, but I will hold those for the workshop sessions.

System Integration Issues
Philip Tarnoff, Faradyne Systems, Inc.

My presentation, which will focus on system integration issues, is intended to help set the stage for more detailed discussions in the workshop sessions. Since I will be addressing problems associated with system integration, many of my comments will be negative.

It is important to remember, however, that there have been a number of significant successes with system integration in traffic management. Addressing issues such as schedule overruns, cost overruns, technical difficulties, and other concerns will be important for the future deployment of ITMS and ITS.

Many of the problems with system integration are not new. In fact, this presentation probably could have been given 25 years ago. Little progress has been made in addressing some of these problems over the years. One of the reasons for this lack of progress is that ITS is an outgrowth of the highway system. As a result, we are suffering from many of the safeguards and constraints that have been placed on highway construction over the years. The process used for building concrete freeways is not the same process that is needed to design and develop complex electronic, computer-based, and communications-based systems. More focus is needed on examining legal and policy issues associated with contracting and system design, development, and operation.

System integration is the process of combining software elements, hardware elements, or both into an overall system. As such, system integration activities must be part of the ITMS development process from the very beginning. Early involvement in the planning process, which should continue through design and implementation, will help address many potential problems with system integration.

System integration is not an easy process. Although it is easy to draw two boxes on a piece of paper and connect them with a line labeled RS232, it takes a long period of time to actually accomplish the link between the two.

System integration is extremely important given the complex systems that are being developed in ITS. Since ITMS involves public safety, the reliability of the systems is critical. It is also important to remember that all groups--from both the public and the private sectors--share the responsibility to develop reliable systems on schedule and within budget.

There are a number of reasons why issues still arise in system integration, even when all parties are committed to the process. First, ITMS are complex, encompassing hardware and software with both wide area networks (WAN) and local area networks (LAN), multiprocessor environments, large geographic coverage, unpredictable environments, and unpredictable functional and geographic expansion.

A number of issues often cause problems during system integration. First, public agencies may not be aware of either the elements or the conditions of the existing infrastructure. This includes the elements they are directly responsible for, as well as the infrastructure of other groups. This can result in numerous surprises when a system is being implemented.

Second, agencies may require specific software designs or equipment. Custom designs, which are very expensive and frequently not needed, may be requested. At one time, we thought it might be possible to develop standardized software. Even though the MIST system mentioned this morning allows for this, none of the approximately 30 installations of MIST have been the same due to special requirements, unique reporting features, and other local desires. These special requirements can significantly increase the cost of a software system.

Third, the distribution of responsibilities can often cause problems in the design and development of a system. The responsibility for the success of a system usually does not rest with just one agency. Rather, success is often shared between the public sector agencies and the private sector groups involved in the system design and development. In addition, coordination must occur not only among these groups, but also among the numerous departments within each of these groups.

Current attempts to solve system integration issues often involve increasing funding levels. New ways are needed to address and resolve these concerns. Identifying new techniques and approaches would be a good topic for consideration in the workshop sessions.

No discussion of system integration issues would be complete without a discussion of the two commonly used contracting approaches--systems manager and the consultant/contractor. In the systems manager process, a single company is responsible for the software design and development, and system integration. The public agency then procures the hardware, software, and construction services using a low bid procurement process. The consultant/contractor method has traditionally been used to design and build highway projects. Under this approach, a consultant designs the system and then the agency procures a turnkey installation using this design.

Neither approach is perfect, and there are potential problems associated with each. Possible issues with the systems manager method include no single point of responsibility, lack of control over system interfaces, no guarantee of mature technology, and no guarantee of prior experience. This technique may also force custom tailoring of software and provides little control over schedules and inspection. The consultant/contractor approach may discourage adequate budgets and schedules for system integration. Other problems with this approach include the fact that the contractor has to implement the design produced by another consultant, the lead contractor--which is usually an electrical firm--rarely considers system integration issues, and the system integrator may have little control over schedules and review cycles.

In conclusion, I would like to identify a few elements for successful system integration. First, a single point of responsibility is critical. Second, it is important to provide well defined system interfaces. Third, I would strongly recommend system testing at every step. Although this will increase costs, the end results will be better and it may save money in the long run by avoiding more expensive problems. Finally, I would suggest maximizing the use of mature technologies, rather than requiring special interest components.