Freeway Management and Operations Handbook

Chapter 16 – Regional Integration
Page 2 of 2

16.3 Implementation and Operational Considerations

Technical integration is only a tool for enhancing regional, multi-agency coordination. Operational integration can still be achieved, often resulting in significant user benefits, through "low-tech" means such as regular meetings, phone calls, faxes, etc. between stakeholders. In fact, the automated exchange of information between ITS-based systems should be viewed as supplementing, not replacing, such "manually-intensive" activities.

The Federal Register in which FHWA Rule 940 is published (Reference 2), includes a background section stating: "Successful ITS integration and interoperability require addressing two different and yet fundamental issues; that of technical and institutional integration. Technical integration of electronic systems is a complex issue that requires considerable up-front planning and meticulous execution for electronic information to be stored and accessed by various parts of a system. Institutional integration involves coordination between various agencies and jurisdictions to achieve seamless operations and/or interoperability. In order to achieve effective institutional integration of systems, agencies and jurisdictions must agree on the value of being part of an integrated system. They must agree on roles, responsibilities, and shared operational strategies. Finally, they must agree on standards and, in some cases, technologies and operating procedures to ensure interoperability. This coordination effort is a considerable task that will happen over time, not all at once. Transportation organizations, such as transit properties, State and local transportation agencies, and metropolitan planning organizations must be fully committed to achieving institutional integration in order for integration to be successful. The transportation agencies must also coordinate with agencies for which transportation is a key, but not a primary part of their business, such as, emergency management and law enforcement agencies."

As difficult as the technical issues may be to resolve, successful regional integration is primarily dependent on resolving the institutional issues. During the aforementioned ITMS Conference (Reference 11), separate breakout groups addressed technical and institutional integration. They all reached the same basic conclusions. The groups focusing on institutional integration agreed "that the institutional issues associated with ITMS are frequently more difficult to address than the technical issues"; while the groups focusing on technical integration "identified the link between institutional and technical issues, noting that institutional concerns frequently influence the technical elements of a project." In fact, most of the common themes that emerged from the ITMS conference (as documented in the Proceedings – Reference 11), focused on institutional issues, including:

• "The need for transportation agencies to focus on operations as a core mission was identified as a key element. Changing the mindset of these agencies from construction to operations is not an easy process, but is critical to the success of ITMS.
• Institutional issues are frequently more of a stumbling block than technical issues. Interagency coordination and cooperation is key to ITMS. Developing multi-agency partnerships, bridging institutional gaps, and establishing new institutional arrangements are all needed to maximize ITMS.
• Stakeholder Involvement. Develop and distribute information and briefing materials on ITMS for use by transportation professionals in presentations to the public and to elected officials.
• Training, education, and staffing needs are critical to ITMS. Emphasis should be placed on recruiting, retaining, training, retraining, and cross-training personnel at all levels. Educational materials are needed for undergraduate and graduate courses, as well as on-the-job training."

As noted in the ITMS Conference White Paper on Institutional Barriers (Reference 12), "it is natural for individual transportation entities to be motivated first by their own operational concerns and needs. It is not uncommon for state and local governments to have a rather contentious relationship, be it about funding levels, their respective responsibilities and levels of authority, schools, transportation, etc. ITMS typically requires that "new" players (e.g., enforcement agencies, emergency service providers, private information service providers) be brought into the institutional mix, and there may be a certain amount of cautionary discretion at first, and possibly misunderstandings. Legal considerations and constraints can play a significant role, particularly if some form of "joint" control of ITS devices or combined staffing of an operations center is being considered for the ITMS."

Institutional barriers can also exist within an individual agency. Different departments within the same agency (e.g., operations, construction, financial) will likely have roles to play within an ITMS; but they may also have overlapping responsibilities, a lack of understanding of the other departments' missions, and conflicting priorities and policies. An agency may oversee multiple, geographically separated transportation facilities within the same region (e.g., tunnels and bridges), where the day-to-day management and operations of these individual facilities has historically been relatively independent from one another. These intra-agency barriers can prove a greater hindrance to an ITMS than the inter-agency challenges, particularly if senior management within the agency do not understand (or accept) the importance of and the need for ITS and integration (12).

What impetus is there for getting all the affected agencies and entities together to discuss coordinated operations and regional integration in the first place? Perhaps foremost is the need to overcome a sort of "institutional inertia" – to change the mindset within transportation agencies such that their core mission includes operations. It is also possible that FHWA Rule 940 – tying Federal funding for ITS projects to the establishment of a Regional ITS Architecture, and conformity of these projects with that architecture – may also be helpful in promoting regional integration. Regardless, as noted in References 1, 3, 11, and 12, "champions" are essential to take the lead in this endeavor, to arrange and organize inter-agency meetings, and continuously promote the need and benefits of regional integration. The champions must also have the authority, ability, and credibility to influence decisions within all agencies and groups. Outreach to policy makers is a key part of building support and champions at the political level. In addition to individuals, a lead agency is also often helpful. It may be the MPO, a "regional" transportation agency, or a State DOT. Obviously, the ITMS champion must function as an advocate. At the same time, however, any lead agency must be careful that it is not viewed by the other entities as using the ITMS concept as a means to expand its own influence and control.

Other considerations when dealing with institutional issues include the following:

• Stakeholder Involvement – The need for all affected entities to participate in the planning and development of a Regional Architecture and ITMS (as well as a freeway management and operations program) is discussed in Section 16.2, and emphasized throughout this Handbook and in numerous references. A case study on the development of the Regional ITS Architecture / Regional ITS Integration for the NY-NJ-CT region (Reference 13) emphasizes the need to involve as many organizations as possible in the process; that early establishment of interagency communications and relationships is the key to success in the regional ITS architecture development process. In essence, bringing together all the stakeholders can serve to cultivate an interest in coordinated operations and regional solutions, increasing the agencies' understanding of the importance and need for ITMS. The various participants can identify and focus on common goals, leading to the development of a regional concept that will satisfy these goals. Moreover, it allows each entity to understand the specific functions and perspectives of their partner agencies, as well as their respective institutional constraints and barriers, thereby making the collaborations more productive.
• Organizational Structures and Processes – Determining the most appropriate organizational structure for regional integration and coordinated operations depends on the needs of the region, existing institutional relationships and processes, and the visions of the transportation operating agencies and service providers within the region. The organizational structure will vary, but may begin as an ad hoc arrangement among a few people or organizations and evolve to more formal arrangements. Figure 16-1 illustrates this range of organizational approaches. The process of regional coordination and integration will often move along a spectrum from little to no information sharing and collaboration, to ad hoc relationships built around specific issues or special events, to more formal collaborative relationships with mutually agreed-upon objectives and strategies, and finally, in some instances, to joint ownership and control of transportation facilities and services. This spectrum, illustrated in Figure 16-2, shows some of the ways that a region's public and private sector entities may interact.

Figure 16-1: Organizational Approaches for Regional Integration (Reference 1) D

Figure 16-2: Spectrum of Regional Integration Processes (Reference 1) D

• Inter-Agency Agreements – Agreements among the different stakeholder agencies and organizations are required to realize the coordination, cooperation, and integration associated with the regional ITS architecture. The "Regional ITS Architecture Guidance Document" (Reference 3) includes inter-agency agreements as an individual procedural step, in which "a list of the required agreements is compiled and new agreements that must be created are identified, augmenting agreements that are already in place. Each connection between systems in the regional ITS architecture represents cooperation between stakeholders and a potential requirement for an agreement, recognizing that one agreement may accomplish what is necessary to support many (or possibly even all) of the interfaces identified in the architecture. The number of agreements and the level of formality and structure of each agreement will be determined by the agencies and organizations involved." The ITMS Conference White Paper on Maintenance and Operations (Reference 14) states: "the development of agreements should be started well in advance of when the agreements are needed. An important strategy used for meetings where agreements are discussed is to consider all agencies to be equal and not have one of them be in charge of the meeting (i.e., meetings are arranged, facilitated and documented by non-agency resources.) This strategy reduced the risk of any agency forcing their agenda on the other agencies just because that agency was responsible for the meeting." Some common types of agreements are listed in Table 16-4. A major impediment can be getting each agency to approve an agreement. One approach is to keep the agreement at the lowest possible hierarchical level and to keep it informal. Another approach is to have the agreements signed at the highest levels. There are advantages and disadvantages to each approach. With the first approach, high-level support may be denied when it is needed. With the second approach, the legal reviews may take a considerable amount of time and may never be concluded.

• Document Success Stories – These need not be traditional benefit/cost studies. It is more important to document real examples of how the quality of transportation operations has been improved with regional integration and ITMS implementations. Without a significant constituency for operations, it will continue to receive limited funding and support. More success stories would be helpful. These success stories should involve innovative applications that cross traditional institutional structures and can be understood for their intrinsic value. Improving the response time of an ambulance through improved integrated operations is a benefit that does not require a benefit/cost ratio to be understood.

16.4 Examples

16.4.1 Transcom Regional Architecture

The New York-New Jersey-Connecticut Region is the most highly populated and one of the most highly congested areas in the country. The region's geography (e.g., numerous river crossings), a significant use of transit, and its complex jurisdictional structure (i.e. numerous agencies responsible for operating the network, often in an overlapping fashion) makes interagency coordination and information sharing essential. The various transportation agencies within the region have long recognized this need. In 1986, 14 agencies formed TRANSCOM (Transportation Operations Coordinating Committee), which now is comprised of the 18 transportation and public safety agencies listed in Table 16-5.

A "regional architecture" for information sharing and interagency coordination – albeit a "low tech", manually intensive one – was in place from the very beginning. The various agencies and Transportation Management Centers within the metropolitan region would contact the TRANSCOM Operations Information Center (OIC) – primarily by phone – to report major roadway and transit incidents on their respective facilities. These calls were logged, and the OIC operator entered the information into the TRANSCOM system, which in turn disseminated the information throughout the region via a pager network. Other information linkages of this "manual" architecture included faxes (e.g., weekly and quarterly construction activities), two-way radio, and telephone circuits for displaying slow-scan and digitized video from a few closed-circuit television cameras. TRANSCOM staff utilized these data, plus information on agency-specific ITS components, to provide several regional functions:

• Disseminating information on incidents, construction, and other unusual events to affected agencies and other interested parties, including private entities.
• Serving as an interface to the media and private traffic reporting entities regarding incidents and other events that impact the regional transportation network.
• Analyzing the real-time incident information, determining the nature and extent of any regional impacts, developing response scenarios for mitigating these projected problems (e.g., CMS messages), and helping to marshal regional resources for response (e.g., contacting those agencies with operations and control responsibilities to discuss and request implementation of these regional plans.)
• Developing and disseminating a weekly regional summary of the member agencies' major road/track closings and planned construction activities, and maintains a long-term database of projected construction projects. This regional construction coordination program helps member agencies to avoid unknowingly restricting capacity on adjacent facilities or routes.

These "manual" information linkages proved to be very effective; and are still an integral part of TRANSCOM's operations. Nevertheless, the environment in which the regional coordination and the associated information linkages operate has been changing for some years. All of the member agencies have been enhancing the management and operation of their respective facilities through the implementation of ITS technologies and strategies. As these systems have come on-line, the quantity and quality of information available to the operating agencies, and to the region as a whole, has increased; as have the opportunities for automating the information linkages between the TMCs.

TRANSCOM and its member agencies recognized the importance of automating center-to-center linkages in the early 1990's. In fact, it was identified as "an absolute necessity for properly managing the increased information with minimal impacts on the staffing requirements at the agency TMCs, while continuing to provide timely response to transportation problems and credible information to the traveling public" (Note: Transcom Regional Architecture; Final Report; 1995). In 1995, the TRANSCOM member agencies developed a region-wide ITS implementation strategy. This project defined a concept for a regional ITS architecture for TRANSCOM and the member agencies such that the regional transportation network – consisting of expressways, surface streets, and transit routes, and all passing through multiple jurisdictions – is treated as a single "seamless" entity. During the project, discussions with representatives from the various transportation entities within the region revealed a strong consensus as to the specific functions to be incorporated into the regional ITS architecture—specifically, the same functions already being provided: TRANSCOM:

• Clearinghouse of real-time information covering all critical routes and modes. This database integrates available information from agency-specific systems and TMCs to provide a composite picture of the real-time status of the surface transportation network. This information is made available to all member agencies, TMCs, other operating entities, and private traffic reporting entities.
• Regional coordination support between TMCs, transportation agencies, and public safety agencies during "major" incidents and events (i.e., those in which the impacts cross jurisdiction boundaries).

It is noted that the TRANSCOM Regional ITS Architecture does not include operations or control of system components. Such functions are the responsibility of the individual transportation agencies; although the architecture can handle exceptions to this rule whenever the affected agencies agree.

The regional architecture concept was unanimously approved by all TRANSCOM member agencies. Deployment and expansion has been an on-going process. The configuration of the TRANSCOM Architecture, as of the time of writing this Handbook, is shown in Figure 16-3. The model is relatively heterogeneous; allowing the agency's ITS systems to be as different as necessary to support their local missions. It also allows the integration of existing systems and their databases.

Figure 16-3: TRANSCOM Regional Architecture Network D

Specific attributes and elements of this information sharing architecture are summarized below:

• Regional Workstations – All user access to the regional network is through workstations. Information is presented to the operators in an integrated fashion, combining graphical, text, and video formats. Graphical displays represent the primary mechanism for interfacing with and navigating through the regional database. The regional transportation network is displayed in a graphical map-based format providing a common, areawide reference for network conditions, the location of incidents, and the position of ITS devices. Examples of the user interface are shown in Figures 16-4 and 16-5.

Figure 16-4: TRANSCOM Regional Architecture Event Tracking Interface D

Figure 16-5: TRANSCOM Regional Architecture Map Viewer Interface D

• Data Interface – A data interface (DI) is integrated with the central hardware platform at various TMCs. As the name implies, this process – either resident on a separate server, or integrated into the native system – interfaces and communicates with the agency's ITS system, extracts various data elements from this native system, processes the information as required, converts the data to the TMDD format used within the regional network, and transmits the information to the regional server, using C2C protocol, for subsequent aggregation and distribution to workstations throughout the region.
• Regional Architecture Database (RAD) – TRANSCOM receives information from the workstations and DIs, combines and integrates the data with information from other systems into a composite and consistent representation of the region, and distributes the information to workstations throughout the region. The RAD also serves as the primary information source for the TRIPS 1-2-3 traveler information system, including providing the information to the public (free of charge) via a web page and telephone, and a fee-based personalized traveler service.
• Use of National Standards – The regional architecture uses national standards to communicate within its expansive network of servers and workstations and subsequently promotes future interoperability with systems that are external to the region, as external systems adopt national standards. The national standards include the use of the NTCIP DATEX center-to-center (C2C) protocol for encoded packet based communications between centers or TMCs as well as the MS/ETMCC Traffic Management Data Dictionary (TMDD). These standards promote an efficient approach to sharing traffic information between internal and external TMCs.

Overlaying the data architecture is the Interagency Remote Video Network (IRVN), permitting "full motion" video sharing between agencies. The IRVN system allows a TMC operator to interface with the video network and choose the cameras (up to three at any one time) he/she wishes to view. The video encoders convert the NTSC video from the selected cameras (routed through the video switch) to IP real-time streaming video. At the receiving TMC, video decoders convert the streaming video signal for display using a video capture card. Attributes of the IRVN system and user interface include:

• Lists of the TMC locations connected to the network, the cameras available from each TMC, and those cameras (up to three from each TMC at any one time) currently transmitting video over the network.
• If an operator wishes to view a camera already on the network, he/she uses a mouse to click on that camera, and the picture from that camera will then appear on a television monitor. An alphanumeric description will accompany the picture. If the camera is not on the network, IRVN will communicate with the video switch at the TMC where the desired camera is located, resulting in the video from that camera being transmitted over the network.
• A problem will arise if four or more different cameras are selected from the same TMC, because each location can only put three video signals on the network at one time. If this circumstance occurs, the current three video signals will remain on the network, and a message will be displayed to call TRANSCOM for coordination. TRANSCOM will then work with the appropriate agencies to determine which three video signals should be placed on the network.
• Each agency may block any of its video feeds from being placed on IRVN.

A case study developed for FHWA (Reference 14) identified the following major lessons learned from the TRANSCOM regional ITS architecture:

• Early establishment of interagency relationships is important
• Education about ITS and regional ITS architecture is needed within agencies to garner critical senior management involvement and support for ITS and regional efforts
• Federal support, including education and the establishment of standards, has been and continues to be important
• Institutional issues must be considered and respected
• ITS has created a new regionally focused paradigm for transportation planning and operations

16.4.2 Spokane Regional Transportation Management System

In July of 2000, the Spokane Regional Transportation Council documented the ITS National Architecture standards and Implementation Plan for the greater Spokane region, identifying the basic functionality of how data would be collected, used, and shared within the region; and how the region would manage transportation information. The high priority projects identified in the Region's Implementation Plan are identifies in Table 16-6.

Progress on all of the goals listed in Table 16-5 is on-going – for example, the region has designed and constructed the Spokane Regional Transportation Management Center (SRTMC), while WSDOT is in contract development to construct the I-90 surveillance and driver information system consisting of CCTV cameras, dynamic message signs (DMS), and several miles of fiber optic communication cable. Accordingly, the regional integration and software activities associated with this project focus on the following regional goals:

• Develop a regional traveler information website
• Develop a coordinated incident response application
• Design and deploy and regional data warehouse
• Provide traffic control system integration

16.4.2.1 Concept of Operations

The Spokane Regional Traffic Management Center (SRTMC) is operated 24/7. The TMC operation is governed by the Operating Board, which is made up of WSDOT, city, county, transit, and the regional planning agency (SRTC). The transportation agencies in the Spokane Region have identified the common goal of implementing a regional architecture that will enable limited view and control of the ATMS systems currently in use in the region. Neither ATMS application, on its own, provides a complete picture of traffic conditions throughout the Spokane Region. Through a common graphical user interface, an operator in the TMC (or from anywhere on the Internet) would have the ability to view data from both control systems in real-time and respond to significant events or incidents on a regional, rather than just a local, basis. The following examples illustrate the type of functions capable through a common, regional-level interface:

• A manager-level user at the SRTMC monitors traffic conditions in the metro area (city, county, state), and identifies an incident on the highway. The user monitors the incident via CCTV and implements a message on a DMS. A diversion route is necessary off of the freeway (which is operated by the State) and onto the local arterial (operated by the City). The TMC operator opens a real-time display of the signal timings of an intersection upstream of the incident location, and determines that the signal timing plan in operation will not be acceptable for the significant increase in traffic volume due to the diversion from the highway. The TMC operator implements from a PC in the TMC a new timing plan that has been previously agreed upon for such a scenario through the regional application. Additionally, the manager places an incident icon on the regional interface, which is automatically updated on the regional traveler information website, and sends an email alert to public subscribers that have signed up for incident alerts.
• A junior-level user is currently monitoring traffic conditions in the SRTMC. An incident occurs on the freeway, but since the junior-level user does not have permissions to assign messages to DMS signs or to modify traffic signal timings on the City streets, the operator notifies the TMC Manager. The manager-level operator, who is not currently on-site at the TMC, launches a web browser with a connection to the Internet, and logs into the regional software application. Through the regional application running in the manager's browser, the manager brings up a CCTV control panel and zooms the camera's image in on the incident site to verify the information from the junior-level staff in the TMC. Upon verifying the incident, the manager assigns the appropriate message to the DMS by estimating the incident delay by viewing the real-time links status. Then the manager selects the appropriate timing plan (pre-configured) through the regional application. At the same time, the junior-level user in the TMC places an incident icon on the regional interface, which appears automatically on the regional traveler information website.
• A planner in the Spokane region is preparing a performance assessment report for the region's transportation network. After logging into the regional software using any web browser with a connection to the Internet, the planner retrieves archived freeway traffic data from the previous six months from the on-line archive. The planner produces several performance charts and plots using tools built-in to the archiving software component and embeds the graphics into the summary report.

The regional goals and concept of operations described above may be translated into the following set of functional requirements for the proposed regional integration and associated software:

• Real-time data from signals connected to different signal systems shall be viewable on the same interface (regional display).
• The location and status of ITS devices in the Spokane region consisting of controllers, CCTV, DMS, and freeway link detectors shall be viewable on the same display.
• The TMC operator shall have the capability to implement changes to signal timing plans on different systems through a common application interface.
• PTZ of CCTV cameras and command of DMS shall be available to privileged users outside of the TMC.
• Data from freeway link detectors shall be archived and available on-line for analysis.
• A traveler information website shall be provided to display current ITS device status and transportation conditions data, including incident and event locations, streaming CCTV video, and an email alerts feature.
• Incident and event data from CARS (Note: The WSDOT CARS application provides incident reporting and management, and can be used to provide an interface to WSDOT's 511 system) shall be integrated into the regional application interface.

16.4.2.2 Architecture

The SRTMS high-level architecture is shown in Figure 16-6. Both ATMS retain their communications connections to field devices. Web Services are used for the majority of the C2C functionality using XML (extensible Markup Language) over SOAP (Simple Object Access Protocol) and CORBA for the Center-to-Center (C2C) link to carry data objects requiring the Near Real Time Data Service (NRTDS). The XML and SOAP interface provides the data and control interface from each system to the regional application. From the regional application, City and County users can "log in" to the system for secure view and control of all ITS devices. Public users and other partner agencies can be provided "view only" access to the same data by inserting a firewall between the SRTMS and the Internet. From outside the City/County WAN, public and partner agency users access the view-only portion of the SRTMS by browsing to a URL through any basic web browser and privileged users can access the restricted features of the software by logging in via a web browser. This is a significant advantage of using web-services technology for providing the regional center-to-center features.

Figure 16-6: SRTMS Architecture D

The implementation of the regional management concept is via a component-based software design centered around a commercially available product. The components of SRTMS are shown in Figure 16-7. The regional map interface is the main framework for the application components and the means by which users log in and are validated to view information (maps, tables, etc.) and access controls, and administrators manage users and access. Other component modules within this framework include:

• Streaming CCTV video, including PTZ and archiving
• PeMS (Data archiving and analysis)
• Response Plan / Strategy Implementation
• DMS control
• Status Viewer
• Event Tracker (interface to CARS)
• Users & Security

Figure 16-7: SRTMS Components D

The components shown in Figure 16-7 are built in a Web-services framework. Each web service (e.g. DMS data/controls, link data, etc.) is implemented as an application servlet with an interface to the user's browser using a Java Server Page (JSP). Persistent data (e.g. device locations, street names, ID numbers, etc.) are stored in a standard COTS database and a facade to the data is provided using "session" and "entity" JavaBeans in an applications server. This provides independence of the interface layer (the Java Server Pages and servlets) from the database schema design. In practical terms, these technology selections allow for highly maintainable (bug fixes do not require modifications to many modules), flexible (adding new features is straightforward by re-using existing patterns with new business logic), and scalable (adding new device or device types is managed in a pattern-based way) code.

The main SRTMS interface provides a regional integrated view of transportation operations using web-services. In addition to viewing the status of field devices on a GIS-based map, the interface includes map navigation, layer toggles, access to command and control web pages, and user management and security features to allow various levels of view and control based on user privileges. Any web browser can be used to access the features of the interface through the Internet, given the appropriate privileges.

16.5 References

1. "Regional Transportation Operations Collaboration and Coordination, a Primer for Working Together To Improve Transportation Safety, Reliability, and Security", FHWA, Publication FHWA-OP-03-008, 2002

2. FHWA Rule 940, National Register, January 8, 2001

3. Regional ITS Architecture Guidance Document; "Developing, Using, and Maintaining an ITS Architecture for your Region; draft prepared by National ITS Architecture Team; October, 2001

4. Federal Highway Administration; "Self Assessment Process for Roadway Operations and System Management", Version 1.0; May 2001

5. The ITS National Architecture, Documentation – Version 4.0, April 2002

6. NTCIP Guide – Updated Version 3 (NTCIP 9001 – A Recommended Information Report of the Joint Committee on the NTCIP); AASHTO, ITE, NEMA; October, 2002

7. ITS Standards News, June 2002

8. "TMDD & MS/ETMCC Guide (An Information Report by the TMDD Steering Committee of ITE and AASHTO)"; Institute of Transportation Engineers (ITE) & American Association of State Highway and Transportation Officials (AASHTO); Washington, D.C.; October 30, 2000

9. "Standards for Traffic Management Center to Center Communications, Volume II – Message Sets (Draft)"; Institute of Transportation Engineers (ITE) & American Association of State Highway and Transportation Officials (AASHTO); Washington, D.C.; July 8, 2003

10. Keever, D. et al; "Data Fusion for Delivering Advanced Traveler Information System (ATIS) Services"; Working Draft; SAIC; November 2002.

11. Conference Proceedings; 4TH Integrated Transportation Management Systems (ITMS) Conference; "ITMS: A Key Strategy to Optimize Surface Transportation System Performance; Newark, New Jersey; July 15–18, 2001

12. Neudorff, Louis; "Institutional Challenges, Barriers & Opportunities: Institutional Integration"; White Paper for 4TH ITMS Conference (July, 2001)

13. "Regional ITS Architecture Development: A Case Study, New York-New Jersey-Connecticut Region: Building a Framework for Regional ITS Integration"; FHWA: September 1999

14. Kraft, Walter; "Managing and Operating Integrated Transportation Management Systems: Policies, Procedures, Funding and Staffing Issues; White Paper for 4TH ITMS Conference (July, 2001); Walter Kraft