Building the ITI: Putting the National Architecture into Action

Prepared for the Federal Highway Administrationby Mitretek Systems

April 1996Washington, DC

Table of Contents

Section Page

1. Introduction - How this Document will Help You 1

2. What is the Intelligent Transportation Infrastructure (ITI)? 5

3. The National ITS Architecture and Why it is Important to You 17

4. How the Architecture Addresses the IT1 23

5. Common Questions Raised by Implementors 39

Appendix: Index into the Architecture Documentation 43

For more information on this and other ITS topics, visit us on the Internet atwww.its.dot.gov.

Purpose of this Handbook

The intended audiences for this handbook are transportation managers, project managers,and their staff. Its purpose is to provide focused information about the National IntelligentTransportation Systems (ITS) Architecture (referred to in this document as the architecture)to those implementing the Intelligent Transportation Infrastructure (ITI) in a metropolitanarea. We provide an introduction to what the architecture says about the ITI, and why aplanner or implementor should be aware of the architecture. In this handbook, we stay at afairly high level within the architecture and discuss major architecture systems andinformation flows...enough to provide a basic understanding of what information thearchitecture provides to implementors. To go further, the reader needs to refer to thearchitecture documentation.

In order to make this a standalone document, we have also included some information onwhat the IT1 components are, what the architecture is, and the benefits of having and usingthe architecture to guide deployment. We have tried to anticipate potential questions youmay have and have included those as questions and answers; these are distributedthroughout the document, but are concentrated in Section 5. We hope that these Qs and Asprovide some insight on key deployment issues.

This is a first generation document that will serve to introduce both public and privatesector transportation managers and implementors to the architecture. More detailedimplementation guidance is currently being prepared. The following diagram is providedto help you identify sections of this document that you may want to focus on, dependingupon your area of interest:

- What is an architecture?

- Why is it important thatI know about it?

- How are architecture andstandards related?

- What does it mean to“conform” to thearchitecture?

- What could happen if Iignore the architecture?

- How does thearchitecture recommendinterconnecting theITI components?

- What architecturesubsystems compriseeach of the ITIcomponents? (verydetailed.)

- What are the integrationeeds of the ITIcomponents?

- We’ve tried to anticipatesome questions you mayhave, such as:

What do I do untilstandards are developed?

What happens to my oldequipment?

Should I let other peopleuse my traffic data?

Should I lease or buycommunication lines?

1. Introduction - How this Document will Help You

If you’re reading this document, you’veprobably seen a significant amount of materialdescribing the IT1 (Intelligent TransportationInfrastructure) and discussing the benefits thatyou can expect from ITI. You’ve also heardthat it’s important that you should Buy Smart.But, before you can Buy Smarter, you haveto understand the requirements. You’ll needtransportation systems that integrate withsystems of other agencies in your jurisdictionand with those of other jurisdictions. And,you’ll need systems that can be readilyupgraded to take advantage of constantlyimproving technologies. At the same time,you have to make the best use of yourexisting transportation investment and insurethat the new systems you add work inharmony with existing equipment.

A significant amount of work has gone intodeveloping the architecture that defines thebasic structure of ITS. The architecture willbe invaluable in helping you specify, design,and deploy ITS. Used effectively, it will helpyou build faster, cheaper, and better. Thearchitecture was developed through the jointefforts of a multi-disciplinary group includingtransportation engineers, planners,communication engineers, and systemsengineers. Additionally, a significant effortwent into various outreach programs so thatthe needs of local transportation officialscould be factored into the architecture. Thearchitecture contains a wealth of informationthat will be invaluable as you begin BuyingSmarter.

However, the architecture is extensive,technically detailed, and covers a broad rangeof topics. The full architecture documentationpackage is approximately 5 100 pages long,covering a number of volumes -- you can’tjust dive in without getting lost; most peopleneed a roadmap to help understand what thearchitecture can do for them and how it relatesto the material they’ve seen regarding the ITI.

The application of current andevolving technology totransportation systems and thecareful integration of systemfunctions to provide more efficientand effective solutions to multimodaltransportation problems. Inparticular, the technologies andoperations needed for atransportation system that willsatisfy the requirements of 29defined user services. Theseservices are listed in Section 3.

Metropolitan ITI:The ITI, formerly referred to as theCore Infrastructure, is the integratedset of nine basic infrastructurecomponents needed to get primarilyurban ITS deployment started. TheIT1 is the key building block toachieving a fully developed ITS.These are the systems we have todeploy first, and that will lay thefoundation for future services. It isenvisioned that IT1 deployment willbe accomplished primarily by thepublic sector with support of theprivate sector. Basically, IT1 is theinfrastructure portion of ITS.

In addition, much of the detail is for systems de

National ITS Architecture:The architecture is the frameworkthat addresses the full set of 29 ITSuser services. The architecturedefines the subsystems and dataflows (i.e., information that must beshared between subsystems)required to make ITS work. Thishandbook briefly summarizes howthe architecture can be verybeneficial in deploying the ITI.gners and implemenrors aevetopmg

detailed component specifications. This handbook provides an overview and roadmap tothe architecture so that you can begin to appreciate how the architecture can help you,without having to examine thousands of pages.

But First, Some Background on How we Got Here...

While research into ITS has been going on for some time, a concentrated Federal programaddressing ITS came about with passage of the Intermodal Surface TransportationEfficiency Act (ISTEA) in December 1991. The ISTEA established the ITS Program andencouraged implementation of “A national system of travel-support technology, smoothlycoordinated among modes and jurisdictions to promote safe, expeditious, and economicalmovement of goods and people”. Attaining a smoothly coordinated system on a nationallevel requires some fairly extensive up-front concept definition and analysis. Ifjurisdictions are to deploy systems in which vehicles and devices smoothly interoperate, aframework must be developed to guide implementors and manufacturers. This need for acommon framework led ITS America to recommend, and the U.S. DOT to initiate, aNational ITS Architecture developmentprogram. The architecture defines thebasic subsystems and interconnectionsbetween subsystems required to implementITS. In addition, it identifies the interfacebetween subsystems for which standardsmust be developed. The process ofdeveloping those standards is underway.By starting with a common framework,the risk of developing systems that areincompatible with one another issignificantly reduced. The architectureprovides a common framework that shouldpromote national compatibility.

It was important that all viewpoints beheard as this basic groundwork was laid

StandardsI

Standards will provide the means by whichcompatibility between systems will beachieved. The U.S. DOT has initiated aneffort to accelerate development ofconsensus-based standards using theinterconnection requirements defined in thrarchitecture. While these standards arebeing developed, you can use these samerequirements to ensure that your equipmentwill be reasonably compatible with futuresystems. You don’t have to wait untilstandards are in place to deploy systemsthat conform to the architecture.

for future ITS deployment. The architecture was developed with the participation of theprivate sector, the public sector, academia, national laboratories, and local implementors.The architecture defines the framework for the complete set of anticipated ITS services andrepresents the collective national view on how ITS should be defined and deployed.

How is ITI Related to ITS?

ITS is the full range of services that can beused to improve the performance of usersof the transportation system. ITS rangesfrom traffic control systems to automatedhighway systems. But you can’t start bytrying to deploy everything at once.You’ve got to start with a core set ofcapabilities and do those right. IT1 is thatcore set of primarily public sectorcapabilities.

ITI is a system, not just ninecomponents

IT1 is an integrated system oftransportation components. Each of thenine IT1 components must work smoothlywith the others. The architecture has goneto great efforts to exploit the synergiesbetween these components, trying toensure maximum capability with minimuminvestment. The initial focus of the IT1 ison urban transportation systems.However, the architecture accommodatesRural and Commercial Vehicle Operations(CVO) systems and details will beforthcoming.

What Additiodal Guidance Can I Expect from U.S. DOT?

Over the next several months, U.S. DOT will be preparing guidance documents to help youbetter understand and utilize the architecture and move forward with system design andprocurement actions at regional, state, and local levels. Guidance documents will include:

l Detailed technical guidance on how to deploy IT1 components

l Guidance or functional specifications that will include information needed to ensurefuture compatibility with newer systems, and that can be tailored to your localrequirements

l ITS Planning Documentation (ref. “Interim Handbook on ITS Planning”, JHK andAssociates, available Spring, 1996)

3

2. What is the Intelligent Transportation Infrastructure (ITI)?

This section discusses what the IT1 is and what the IT1 components do. Later in thishandbook, once we understand what the IT1 is, we will get into more specifics as to howthe architecture defines how the individual IT1 components function and addresses theirintegration.

The IT1 is comprised ofcomponents:

ITI is the infrastructure portion of ITSin metropolitan areas. Many of thefunctions needed for ITS are already

- Traffic Signal Controll Freeway Managementl Transit Managementl Incident Managementl Electronic Fare Paymentl Electronic Toll Collectionl Railroad Grade Crossings- Emergency Management Servicesl Regional Multimodal Traveler Information

-being provided or supported by abroad variety of IT1 features, whichcan serve as the building blocks of afull ITS implementation. The IT1refers to those portions of ITS-relatedhardware, software, services, etc. thattoday, and increasingly in the future,will manage and support thetransportation-related activities. Thisis typically happening first in

metropolitan areas but is expanding to include commercial vehicle and rural needs.

Deployment of the ITI components permits efficient operation and management of roadwayand transit resources through the integration and use of currently available technologies,combined with strengthened institutional ties and inter-jurisdictional/interagencycoordination. In the near-term, implementation of the ITI components is expected to be led

by the public sector, andthe development of newand/or enhanced capabilitieswill occur in anevolutionary manner. Thisis especially true in theareas of TravelerInformation, ElectronicFare Payment, andElectronic Toll Collection.However, private sectorparticipation is highlyencouraged, andappropriate partnershipopportunities should beactively sought by State andlocal implementingagencies. Maturation of the

IT1 components in metropolitan areas can be expected to drive private sector developmentof new/advanced products and industries to provide future ITS user services. The ability toupgrade system functions with new system components and technologies in a modularfashion, and the increasing level of integration and coordination of system functions andactivities across jurisdictions, agencies, and the various IT1 components, protectsinvestments while enhancing services.

Finally, it must be emphasized that while significant benefits are derived from the nineindividual components, even greater benefits can be shown when these features areintegrated and operated in a coordinated fashion throughout the metropolitan area or region.

5

While currently not explicitly mentioned aspart of the ITI, Commercial VehicleOperations (CVO) depends greatly on theservices and enhanced performanceprovided by the ITI. Parallel efforts arebeing undertaken to encourageenhancement of CVO specific activitieswhich will eventually be incorporated aspart of the ITI. Additionally, rural aspectsof ITS are also under further developmentfor future inclusion.

The nine IT1 components are described onthe following pages.

Examples of IT1 Benefits:

Freeway Management Systems, withquantified benefit coming mostly fromramp meters, have reduced accidentsby 15% - 62% while handling 8% -22% more traffic at 16% - 62% greaterspeeds compared to pre-existingcongested conditions

Electronic toll collection allows anincrease of 200% - 300% in per lanecapacity compared to attended lanes

Transit management systems haveyielded improvements in on-timeperformance of 12% - 28% whilereducing costs to yield a positive returnon investment in as little as three years

Transit signal priority systems yieldeda 5% - 8% decrease in transit run times

Providing a video feed from the trafficmanagement center to the towingconcession yielded a clearancereduction of 5 - 8 minutes

Ref.:

FHWA-JPO-96-001, Assessment of ITSBenefits: Early Results

FHWA-JPO-96-008, IntelligentTransportation Infrastructure Benefits:Expected and Experienced

6

Traffic Signal Control

q Signaling systems that react tochanging traffic conditions are animportant component in improvingtransportation system efficiency. Tobe effective, advanced signal controlsystems require an accurate current

picture of the traffic flow and status on the roadwaynetwork. This information consists of real-time inputsfrom traffic sensors (inductive loops, video cameras,etc.), status and incident reports from police and cellularcall-ins, etc. Historical demand information, such astime-of-day specific data would, at a minimum, permitthe establishment of separate time-of-day signal controlstrategies. Advanced signal systems automate the useof real-time traffic flow information to change the signal timing to efficiently accommodatetraffic demands on all streets.

Current state-of-the-art traffic signal control systems have the capability to dynamicallymodify signal timings in response to changing traffic demand. They coordinate operationbetween adjacent signals to maximize the roadway (network) throughput. Coordination ofadjacent signals allows the traffic manager to establish timing, in which vehicles can movethrough selected portions of the traffic network with less delay. At a minimum, thesecoordinated signal control systems can provide for the selection of several time-of-day orspecial signal timing patterns that can optimize operations along major arterial routes andover traffic networks. When part of an integrated ITI, traffic signal control can givepriority to transit or emergency vehicles. These “open architecture” hardware/softwaresystems are designed to be upgraded in capability, enabling relatively inexpensiveinstallation of improved products. This open architecture approach also supports thepotential extension and integration of capabilities, such as coordinated operation withadjacent freeway and arterial systems. The National Transportation Communications for

Deployment objectives:

- Deploy signaling systems that reactquickly to changing traffic conditions.

- Collect and process real-time trafficinformation to provide up-to-datestatus of the transportation system

ITS Protocol (NTCIP) is being developedto support interoperability andinterconnectivity of traffic control and ITSdevices and support capabilities such asvariable message sign control, cameracontrol, vehicle classification, and generalpurpose data collection and device control.

l Install automated tools which take alltraffic data into account and provide thetraffic manager with a clearer picture ofthe status of the transportation system

l Deploy modular systems that facilitatefuture upgrades and allow addition ofnew capabilities as they becomeavailable

l Provide flexible signal timing to transitand emergency response vehicles

The various signal systems in a regionshould be capable of electronically sharingtraffic flow information with the signalsystems of adjoining jurisdictions in orderto provide metropolitan-wide signalcoordination. This information sharingsupports coordination of traffic signalsystems along major corridors, and resultsin smooth traffic flows acrossjurisdictional boundaries.

Freeway Management

Real-time informationabout traffic flow androadway conditions is key

Ito managing the roadway

Inetwork in a proactivemanner. Methods for

Imonitoring freewayconditions include

inductive loop detectors, video cameras (withand without signal processing capability), andmicrowave radar and ultrasonic monitors.These sensors provide occupancy, presence, count, and in some cases speed and queuelength data. Other sources of information on the freeway include the traditional inputs frompolice and maintenance personnel as well as increasing numbers of cellular phone reportsfrom drivers. Information collected by the Freeway Management component can also beused by the other IT1 components. Relevant information can be made available to supportincident management and congestion mitigation activities on the freeway and to allowcoordination of these actions with adjacent traffic signal control systems. With videocoverage of incidents on the freeway, the incident management team can determine theseverity and type of incidents that have occurred and can direct the appropriate resources tothe scene. This permits both faster response and better utilization of the incident/emergencyresponse resources, through a tailored response.

Deployment Objectives:

l Provide critical information to travelersthrough infrastructure-baseddissemination methods, such as variablemessage signs and highway advisoryradio

l Monitor traffic and other environmentalconditions on the freeway system

l Identify recurring and non-recurring flowimpediments so that short-term and long-term actions can be taken to alleviatecongestion

l Implement various control andmanagement strategies (such as rampmetering and/or lane control, or trafficdiversion)

l Use probe vehicles as an additionalsensor for collecting real-time trafficinformation

The freeway management system(s)include(s) a Freeway Management Center(or multiple centers when responsibilityfor the freeway system is shared by morethan one jurisdiction) and informationlinks to the Regional Multimodal TravelerInformation Center and othertransportation management and controlsystems in the metropolitan area. Thesecapabilities can provide, or be enhanced toprovide, for the coordination ofemergency response and incidentmanagement, and to support themanagement of special-event situations.Examples of integrated/cooperativemanagement include regular analysis andupdating of control and incident responsestrategies and coordination with otherlocal traffic management systems in thearea for handling special events.

8

Transit Management

On-time performance is acritical factor in thepublic’s decision to chosetransit as a mode of travel.Transit fleet managementinclude hardware/softwarecomponents on buses and

in dispatching centers, radiocommunications systems, and operationsand maintenance facilities and personnel.Depending upon the specific needs of thejurisdiction’s fleet management system,additional capabilities could be consideredsuch as automatic vehicle location, advancedvoice and data communications, automaticpassenger counting, driver information(voice and visual), vehicle diagnostics,geographic information system databases forschedule management and emergencyresponse, as well as computer aideddispatching. These systems reduce cost byimproving efficiency, while also providing better information to travelers.

Advanced fleet management systems which include Automated Vehicle Location systemsprovide reliable bus position information to the dispatcher. The dispatcher with computerassistance can compare the vehicle actual location with schedule information to trackschedule adherence and, when necessary, take corrective actions to either get the vehicleback on schedule or to dispatch additional resources to cover the route. This function couldbe performed manually by the dispatcher or automatically, depending upon the level ofautomation. In addition, any pertinent schedule information would be disseminated innear-real-time to the traveler, either via kiosks or at home or the office. This informationcan be used by travelers in conjunction with information from other sources and allows tripplanning to include mode selection. The systems can be enhanced to provide a disnlav of

Deployment objectives:

Provide real-time, accurate transitinformation to travelers

Monitor the locations of transitequipment so as to provide moretimely information on arrival times

Optimize travel times for transitvehicles

Support flexible routing of transitvehicles

Support automated maintenancemonitoring of transit vehicles

information on routes and schedules fortransit passengers on the vehicle. Otherenhancements include in-vehicle sensors tomonitor information such as passengerloading, fare collection, vehicle diagnostics,etc., to support efficient management of thetransit system. In the event of anemergency, the dispatcher can notify thepolice or other support services of thesituation and direct the respondingauthorities to the exact location of theincident. Information links from transitmanagement to and from freeway andsignal control functions can be valuable, aswhen a transit vehicle may require priorityat signalized intersections to better meetroute schedules.

9

Incident Management

Rapid and effectiveresponse to incidentsis a key factor insaving lives andreducing travel delay.Many metropolitanareas currently have

programs for quickly identifying andresponding to incidents that occur onfreeways and major arterials. Theobjectives are to rapidly respond toincidents with the proper personnel andequipment, to aid crash victims, and to facroad-way. Timely execution of these activities saves lives while minimizing the buildup ofqueues and reducing the delays and frustrations of the traveling public. In this manner theinvolved public agencies and individuals can satisfactorily meet their requirements andresponsibilities. To accomplish incident management, real-time input from the freeway andarterial surveillance systems and the agencies responsible for managing them is critical.

The various jurisdictions and agencies responsible for operations and enforcement in themetropolitan area work together to develop policies and operating agreements that definespecific responsibilities for all aspects of incident management, including detection,verification, response, clearance, scene management, traffic control, and informationdissemination. These multi-jurisdictional operating agreements ensure routine cooperation,coordination and communications among all agencies, including enforcement, fire,ambulance, highway traffic control and maintenance, environmental (as well as HAZMAT

Deployment objectives:

- Coordinate incident managementacross regional boundaries to ensureefficient and sufficient response

- Use traffic management capabilitiesto improve response times

- Use onboard moving map routeguidance equipment to assist incidentresponse vehicles (e.g., ambulancesand tow trucks)

- Reduce traveler delays due toincidents

response teams) and other public agencies aswell as private towing services. Improvedsurveillance, augmented by rapid andaccurate reporting of incidents, allows therapid dispatch of appropriate equipment andpersonnel to the incident scene. Availabilityof accurate and timely incident informationto the traveling public will further helpreduce delays for drivers and transit riders.Use of a common regional digital mapsystem by the various traffic and incidentmanagement organizations will allow theincident management team to better locatethe reported incident, and will facilitate thecoordination among the several agenciesinvolved in the incident response.

10

Electronic Fare

will be in operation

Payment

Electronic fare payment is bothconvenient for the traveler, whono longer has to fumble forexact change, and a costsavings for public agencies asthey reduce manual handlingand processing of money.Electronic fare payment systemsfor collection of transit fares,

parking lot-fees, etc. The systems will include hardware and software for roadside, in-vehicle, and in-station use, and passenger/driver payment cards, which possibly wouldinclude financial and card accounting systems. Electronic fare collection eliminates theneed for travelers to carry exact fare (change) amounts and facilitates the subsequentimplementation of a single fare payment medium for all public transportation services.

These systems can include debit, credit, and/or stored value cards. Manual cash paymentwill continue to be supported. Eventually, travelers will be able to use standard financialinstitution credit cards to pay fares, much as they use a credit card at the gas pump today.

Where appropriate, the system wouldfacilitate private company participation in

l Provide a single medium for paying programs where the employer subsidizestravel-related fares and parking fees employee work-related travel on the transit

system by directly depositing funds inl Reduce the necessity for travelers and employees’ transit accounts .

public agencies to handle money

11

Electronic Toll Collection

reduces delays at tollplazas and operatingcosts of toll agencies.Electronic toll collectionsystems are inoperation within oraround a number of

metropolitan areas (and on segments ofrural interstate systems) for automated tollcollection. The systems include hardware and software for roadside and in-vehicle use,including payment cards or tags, and a communications system between the vehicle and theroadside. Toll payment is processed as the vehicle passes the toll station at a safe speed,thereby decreasing delays and improving system productivity.

The system may include any combination of debit, credit, or stored value toll tag capability.Electronic toll collection systems can be installed in various configurations, includingmainline barrier plazas and systems where tolls are based on entry and exit points. Specific

Deployment objectives:

l Reduce delay at toll collectionplazas

l Reduce costs incurred by tolloperating agency

l Use common toll readers andtags to promote interoperabilityand reduce cost to the travelingpublic

l Reduce handling and processingof money

functional components-of the system will includeautomatic vehicle identification, automaticdetermination of toll amount for differing classesof vehicles, automated enforcement of tollviolations and flexibility in financialarrangements (e.g., prepaid debit tag, paymentcards).

12

Emergency Management Services

Efficient management anduse of emergencyequipment is an importantcontributor to a safetransportation system. Byequipping emergencyresnonse vehicles with

automated vehicle location capabilities, thesevehicles can be more efficiently managed byallowing dispatchers to know the locations ofvarious pieces of equipment. Also, thislocation information can be used to get emergency vehicles to their destinations morequickly. Assignments of response vehicles to cover reported incidents can be based onvehicle location when, for instance, they are not at their station and the routing of thesevehicles to the incident scene can be accomplished more effectively based upon accurateknowledge of current vehicle location and traffic condition. Use of a common regionaldigital map system by emergency services personnel will facilitate the coordination among

the several agencies involvedin the incident response andwill improve the ability torespond to an incident.Emergency managementservices will also supportautomated MAYDAYcapabilities, a concern in ruralareas where accidents may beundiscovered for lengthyperiods of time.

Deployment objectives:

. Use traffic management capabilities to improveresponse times

. Use onboard moving map route guidanceequipment to assist emergency vehicle operators

. Improve response to HAZMAT incidents byproviding emergency personnel with timely,accurate information

14

Regional Multimodal Traveler Information

Providing timely travelinformation will enablethe public to makeinformed transportationchoices. Metropolitanareas generally consist ofmultiple local jurisdictionsand state level

organizations, each responsible for providingsome level of traffic surveillance, management,and control within their own jurisdictions.There is a need for an integrated source ofroadway and transit information to provide acomprehensive and integrated view of theroadway and transit conditions throughout themetropolitan area or region. Some users suchas travelers, traffic managers and transitoperators, and private sector transportation-intensive businesses may use this informationdirectly. Additionally, the private sector mayelect to re-package this data and provide it aspart of a marketable value-added service.

The information repositories may be either centralized (i.e., housed and managed in onefacility) or distributed (i.e., housed and managed in separate facilities) systems that directlyreceive roadway and transit information from the various roadway surveillance systems andother information sources, either public or private. The IT1 will have the capability tocombine the data from the various sources; which allows packaging of the data in a varietyof formats and providing the information to the users through different distributionchannels, such as telephone voice and data services, radio and TV broadcasts, kiosks,

computer-based (e.g., Internet) services,Deployment objectives: etc. Various options exist for either

public or private sector distribution oftransportation information.- Promote regional coordination in

collecting, processing, and presentingtraveler information

- Collect and maintain comprehensivetransportation data to all potential users ona timely basis

- Format/package this data such that it willbe meaningful to the traveler

- Provide travel information to the publicvia a range of communication devices(broadcast radio, cellular telephone, theInternet, cable TV) for presentation on arange of devices (home/office computers,television, kiosks, radio)

Traveler information may be providedboth directly to the public and to public orprivate sector Information ServiceProviders (ISPs) that will supplement itwith additional information, features, andservices, and market the enhanced serviceproducts. Traveler information will bepulled from the various IT1 componentsinto a comprehensive regional informationsystem, thereby facilitating the timelydistribution of critical travel-relatedinformation to the traveler andtransportation-related commercial users.

15

3. The National ITS Architecture and Why it is Important to You

System architecture is a conceptthat evolved over many years ofdeveloping and supportingcomplex electronic systems. Anarchitecture provides theframework, based on userrequirements, for a systemdesign. The architectureidentifies basic subsystems,defines the functions performedby each subsystem, andidentifies the data that must betransferred between them. Itpurposely does not provide theactual design, however, or tellyou what to buy since that is alocal choice.

The 29 User Services Supported by theArchitecture

Why have an architecture?

The architecture gives everyonea common starting point and acommon language. Everysystem initially has anarchitecture. You may not havecalled it that in the past, butbefore you did your detaileddesign, you sat down anddecided what the system woulddo, what its functionalcomponents would be, and howthese components would beinterconnected. That’s anarchitecture.

Transportation systemdevelopers in the past did thesame thing. Since there waslittle coordination, everyone’sarchitecture was slightlydifferent, preventinginteroperable andinterchangeable systems. Now,rather than thousands of

Travel and Transportation ManagementEn route Driver InformationRoute GuidanceTravel Services InformationTraffic ControlIncident ManagementEmissions Testing and Mitigation

Travel Demand ManagementDemand Management and OperationsPre-trip Travel InformationRide Matching and Reservation

Public Transportation OperationsPublic Transportation ManagementEn route Transit InformationPersonalized Public TransitPublic Travel Security

Electronic PaymentElectronic Payment Services

Commercial Vehicle OperationsCommercial Vehicle Electronic ClearanceAutomated Roadside Safety InspectionsOn-board Safety MonitoringCommercial Vehicle Administrative ProcessesHazardous Material Incident ResponseFreight Mobility

Emergency ManagementEmergency Notification and Personal SecurityEmergency Vehicle Management

Advanced Vehicle Control and SafetySystems

Longitudinal Collision AvoidanceLateral Collision AvoidanceIntersection Collision AvoidanceVision Enhancement for Crash AvoidanceSafety ReadinessPre-crash Restraint DeploymentAutomated Highway Systems

Note: Italicized services comprise the basic capabilitiesof the ITT. Other services build upon them. HighwayRail Intersection is a newlv added user service which

localities across the countrystarting from scratch and

will be incorporated into the architecture.

developing their own architectures to implement ITS, the architecture gives you a starting..I . point and has gone through much of the up-front analysis for you. You still nave to designat the local level, but the architecture moves you ahead several steps in the process and

17

gives you a common framework for discussions with manufacturers and otherimplementors. The framework is also the foundation for standards development.

How is the Architecture Structured?

If you plan to look at the detailed architecture documentation, then you need to be aware ofthe terminology used and the basic structure of the architecture. At the most fundamentallevel, the architecture defines a series of functions . These are the various activities that anITS system would carry out. Examples of functions would be traffic surveillance oroperating transit vehicles. Clearly such high-level functions are broad in scope, so theyare broken down into more and more detail, yielding sub-functions, sub-sub-functions,etc. Monitor HOV Lane Use or Provide Transit Vehicle Driver Interface are examples oflower level functions defined in the architecture. In the architecture documentation, higherlevel functions are depicted graphically as Data Flow Diagrams or DFDs. Each of thelowest level functions is given a precise definition, known as a Process Specification or P-spec for short.

One of the primary roles of the architecture is to assign functions to various components --or subsystems -- of the overall ITS system. Information Service Providers, TrafficManagement, and Transit Management are example subsystems. However, the varioussubsystems cannot act independently of one another. Information about the trafficsituation, incidents, etc. must be exchanged between these subsystems if the overall ITSsystem is to act in a coordinated, integrated fashion. Therefore, the architecture alsodefines the connections or interfaces between these subsystems. This is done in terms ofdataflows. Probe Data and Transit Fare Information are example data flows.

Logical Architecture -What has to be done(functions)

Dataflows

Physical Architecture -How it should be done

Interface

(group functionsSubsystem A Subsystem B

together)

The Logical Architecture documentation defines the DFDs and P-specs. The PhysicalArchitecture Documentation defines the subsystems, assigns P-spec functions to them, anddocuments the dataflow interfaces between the subsystems. In this document, thearchitecture subsystems and dataflows needed to implement IT1 are found in Chapter 4.

18

Benefits of Using the Architecture to Guide Deployment:

l National Compatibility: as travelers and commercial vehicles move within the UnitedStates, the equipment on their vehicles continues to support them at all locations

l Multiple suppliers: more vendors will be supplying compatible equipment, leading tocompetition and less expensive equipment

l Future Growth: By following an “open systems” approach, the architecture allowsmigration paths for future system growth and expansion (i.e., you upgradesubsystems, you don’t start from scratch.)

l Support for ranges of functionality: the architecture supports high-end and low-end features. Basic services can be provided free, while value-added services can beprovided on a fee basis.

l Synergy: the architecture considers the requirements for multiple functions andallocates systems to optimally support those functions

l Risk reduction: the architecture’s common framework reduces risk for implementors,manufacturers, and consumers alike.

But my local requirements aren’t the same as someone else's...

The architecture is flexible and doesn’t lock you into rigid deployment options. Rather, itaddresses all of the subsystems and interfaces that may be required by any IT1 deployment.It is unlikely that any one region would deploy everything. If you don’t need a particularsubsystem now, you don’t have to install it. But, thanks to the architecture, if you laterdecide that you do have a requirement for that subsystem, you can install it without havingto replace all of your other equipment provided the equipment procured under your initialdesign conforms to the architecture. That’s what we mean by buying smarter . . . you canupgrade or replace parts of your system without having to start from scratch provided youhave taken care to buy equipment which conforms to the architecture.

19

What does “architecture conformance” mean and why is it important?

By conforming to the architecture, we arenot talking about a strict, literal, word-by-word adoption of every word and conceptdocumented in the architecture. Rather,we mean you should use the architectureframework to guide you as you design anddeploy your systems. In general, byconforming to the architecture, we meanthat a subsystem or device:

. Supports the functions defined forthat subsystem in the architecture

. Supports the data flows defined forthat subsystem in the architecture

. Uses open system interfacestandards (i.e., uses commoncommunication interfaces supportedby industry) wherever they exist, butnot to the exclusion of proprietaryinterfaces or communicationprotocols with other subsystemswhen appropriate

So, is the architecture complete, oris there more work to be done?

At this point in time, the architecture iscomplete for the list of 29 user services.The architects have taken a first step intrying to map new technologies and newways of thinking to an old problem.Obviously, changes will have to be madeas implementors begin to deploy to thearchitecture and identify newrequirements. For this reason, the U.S.DOT has initiated efforts to ensure that the

Why is conformance with thearchitecture important?

Following the architecture providesyou with an evolutionary path. Youwon’t be stuck with obsolete systemsthat can’t be upgraded.

The architecture provides a commonlanguage for deployment. You want tobe in step with current and evolvingpractices.

Standards Development Organizationsare using requirements from thearchitecture to develop ITS and IT1standards.

Equipment builders are also relying onthe architecture’s requirements and thestandards that are being developed.

The architecture has already done a lotof work for you in defining data flowsand potential system configuration.Take advantage of it!

Consequences of not conforming tothe architecture

l Future system upgrades (new featuresor replacements) may be difficult, if notimpossible

l You may be locked into one supplierdue to proprietary interfaces

architecture will be maintained, updated, and distributed as necessary. The specifics of thisactivity are just now being defined, but we see this as an important activity and we will beseeking input from implementors as part of this process. For example, the HighwayRailroad Crossing or Highway-Rail Intersection was not one of the initial userrequirements. However, the requirement now exists and plans are being made to add it tothe architecture.

20

A major output from the architecture Priority Standards Areas:development process is requirementsfor developing standards. Some l Information broadcast (e.g., FMITI/ITS standards development subcarrier)activities are already underway, l Travel Information Messagessome are just now in the early . Traffic Management (e.g., NTCIP)development stages. The l Mayday Messagesarchitecture has identified which - Incident Messagesinterfaces require standardization and l Dedicated Short Range Communicationshas developed initial requirements l Commercial Vehicle Operationsfor those standards. In the interim, l Border crossingsbetween completion of the l Map databasesarchitecture and development ofstandards, much of this standards *Note: Priority standards include some thatrequirements information can be apply to the more general set of ITSused in designing systems...it’s the User Services , not just strictly to thesame information the Standards ITI.Development Organizations will be

Standards

using to guide their standards setting efforts. Your system might not be 100% compatiblewith the eventual standard, but it will be much easier to make modifications to move intocompliance than if you had pursued a totally independent design path. U.S. DOT hasalready initiated an ITS Standards Development Program which will begin using standardsrequirements identified in the architecture to develop standards in priority areas. StandardsDevelopment Organizations (SDOs) are now on-board and beginning the process ofprioritizing and initiating development of these standards. However, standardsdevelopment is a long process. During this period, U.S. DOT will support an outreachprogram to keep implementors informed as to what standards are being developed (i.e.,news you can use as you design systems) and status as to when key standards will becompleted.

Architecture Synergies

One of the benefits of the architecture is that it promotes the integration of user services anduse of common system components for multiple purposes (e.g., each of thecommunications channels provides data for multiple user services). As pointed outthroughout this handbook, there is significant benefit to having individual subsystemsshare information with other subsystems. A system designed this way is more efficientand reduces overall cost. Areas where synergy can be found in the architecture include:

1. Network surveillance. The information provided from network surveillanceequipment (e.g., traffic counts and speeds) can be used for many purposes, includingcontrol and management of the traffic signals, incident management, demandmanagement, emissions management, and traveler information (including routeguidance). The surveillance information can also be saved as historical data forplanning purposes or for evaluating the effectiveness of previous systemenhancements. Probe surveillance information can be used for many of the samepurposes.

21

2. Toll tags. Vehicles equipped with toll tags can also serve as traffic probes (for flowmonitoring). Toll tags could also be used for demand management strategies such ascongestion pricing.

3. Communication channels. Each of the communication interconnect channels ofthe architecture is structured to support data messages pertaining to multiple userservices. For example, the two-way wide-area cell-based communication systemsupports messages relating to traveler information, route guidance, emergencynotification (Mayday), probe surveillance, yellow pages, etc.

4. Traffic management subsystem (TMS). The traffic management subsystem(TMS) allows for many functions to be performed at a single location, enabling thebeneficial sharing of equipment, facilities, and information across multiple userservices, including traffic control, incident management, travel demand management,and en-route driver information.

5. Vehicle location determination. Vehicle location equipment (e.g., a GPSreceiver) has many uses within the architecture: vehicle tracking for navigation/routeguidance, probe data collection, emergency notification, and personal security.

6. Map databases. Map databases in a particular subsystem should be capable ofsupporting multiple user services. For example, a single map database in a personalvehicle subsystem supports route guidance, en-route driver information, and pre-triptravel information. More importantly for ITI, map databases are an important part ofemergency and transit management.

7. Transit vehicle tracking. Transit vehicle tracking provides several usefulfunctions: it facilitates more efficient public transportation management (includingdynamic route modification and personalized public transit), can provide data usefulfor travel information purposes (schedule adherence data), and also enhances publictravel security (location information can be provided to the police in an emergency orincident).

8. Electronic fare payment. A single electronic fare payment media can be used toprovide financial transactions for several surface transportation modes (tolls, transitfares, parking charges) as well as non-transportation purposes.

9. CVO tag/DSRC. A tag and Dedicated Short Range Communication (DSRC)system on board commercial vehicles can support multiple services, such aselectronic clearance, international border clearance, and safety monitoring.

22

4. How the Architecture Addresses the ITI

Up to this point, we have defined the IT1 components, discussed what the architecture is,and discussed why it is important that the architecture be utilized in deployment. In thissection, we pull just enough information from the architecture definition to show you whatthe architecture says about how the IT1 works.

The architecturedocumentation is a highlydetailed set of technicaldocuments. The definitionportion of the architecture waswritten by engineers forengineers. This illustrativediagram shows how just oneof the simple objects in ourhandbook can be blown upinto extensive detail in thearchitecture definition.

What we have done in thisdocument is gone throughthe architecture definition andpulled out the basicsubsystems and data flowsthat are needed to implementthe ITI. In some cases, wehave taken liberties incombining numerous dataflows into single, genericdata flows. This is enoughto get you started as youbegin to understand how touse the architecture.

This type of picture in this hand book

Traffic Signal Control and H ighway Rail

Regional Multi-modal Traveler

C mssin g Traffic Data and lnfonationPredicted Incidents

Translat es in to the fo llow ing in the a chitecture

23

require essentially the same types of interfaces to the other IT1 components; this isemphasized by having the arrows go to the outer box. They also share data with eachother, as shown by the Coordination Data arrow between them. Second, the architectureprovides the flexibility to implement these two components separately or to combine theminto a single facility. As we move further through Section 4, we will define each of the IT1components individually. For each component, a diagram will depict the architecturesubsystems that make up that component and will show the data flows defined in thearchitecture required to interconnect those subsystems. The definitions for the subsystemsand some discussion of the data flows will be provided. To obtain more data on thosesubsystems or components, it will be necessary to dig into the architecture.

The Integrated IT1

The following paragraphs step you through the boxes and arrows shown in the IT1 systemdiagram on the previous page. Starting at the left side of the diagram are two tightlycoupled components: Incident Management and Emergency Management. IncidentManagement also has interfaces with the Regional Multimodal Traveler Information andTraffic Signal Control/Freeway Management components. Incident Management receivestraffic data from the Traffic Signal Control/Freeway Management components wheneverthere is an indication of the possible presence of congestion. These data include suchinformation as vehicle counts, queue lengths, and speeds. Incident Management analyzesthese data for incidents. If the system detects an incident, the appropriate IncidentManagement functions are carried out. This includes passing the location of the incident onto the Emergency Management component, if appropriate. Emergency Management willdispatch the appropriate vehicles to the scene. Details on the incident and the responsestatus are passed back in the reverse direction from Emergency Management to IncidentManagement. In addition, details on the location, time, type, and severity of the incidentare passed to Regional Multimodal Traveler Information and Traffic SignalControl/Freeway Management. Information on predicted incidents, such as planned laneclosures, is also passed. For Regional Multimodal Traveler Information, incident data aresupplemented with information on the impact on traffic. Incident data passed back toTraffic Signal Control/Freeway Management enable signal timings to be adjusted to allowgreen waves for emergency vehicles responding to the incident. Incident data also serve asthe basis for generating messages displayed on Variable Message Signs (VMS).

Transit data are transferred directly by the Transit Management component (shown on theright side of the diagram) for use by Regional Multimodal Traveler Information. There aretwo basic types of Transit Data. The first type is relatively static (i.e., does not changerapidly over time.) It includes information on transit routes, schedules, and services.Clearly, such information does not have to be exchanged on a minute-by-minute basis.The second type of Transit Data is quite dynamic and includes estimated arrival times attransit stops and destinations, and deviations from published schedules and routes.

Transit Management generates data for its own operation and makes it available to theRegional Multimodal Traveler Information component for dissemination to the travelingpublic. It is responsible for packaging the data and disseminating it to the public in avariety of formats. For example, the route number of an approaching transit vehicle can bedisplayed on electronic signs at roadside transit stops. Interactive kiosks and personalhand-held devices can receive the data for use in trip planning, or the information can bebroadcast over a wide area by an Independent Service Provider. This division ofresponsibility between Transit Management and Regional Multimodal Traveler Informationis illustrative of how the architecture assigns functional responsibility and why the various

25

IT1 components must be integrated to provide maximum benefit. It also illustrates theregional variations allowed while still conforming to the architecture.

Traffic Signal Control/Freeway Management, shown at the center of the figure, are the hubof the ITI. Both of these components are responsible for the surveillance, monitoring,device control, and management of the road network. Each passes traffic data to theIncident Management and Transit Management Components. These data include link traveltimes, traffic volumes, and speeds currently flowing on the road and highway network.Model predictions for these quantities may also be included. The traffic data are also outputto Regional Multimodal Traveler Information. There they are disseminated to the public fortrip planning and other purposes.

The Traffic Signal Control/Freeway Management components monitor the current trafficsituation through surveillance equipment and through receipt of incident data. A portion ofthis information is passed on to Transit Management in the form of predicted delays alongvarious portions of the road network. Transit Management needs these data to managetransit vehicle schedule deviations and generate the necessary corrective actions such as theintroduction of extra vehicles or the premature termination of some services. It would beinefficient for Transit Management to duplicate the collection of raw traffic data andgenerate the delay information. Again, by integrating IT1 components, the architectureenables Transit Management to take advantage of the available information in anothercomponent.

Information also flows in the reverse direction -- from Transit Management to the TrafficSignal Control/Freeway Management components. This takes the form of TransitPriorities. Static priority data is passed from Transit Management to Traffic SignalControl. This establishes the overall transit priority on the roadway. Real-time prioritydata is also passed. Originating within transit vehicles, these data allow Traffic SignalControl to adjust traffic signals. Priority or even signal preemption is given to transitvehicles in accordance with the overall management philosophy.

Similar static and dynamic priority data are also passed from Transit Management toFreeway Management. This allows ramp control signals to be adjusted in accordance withan overall transit ramp management philosophy.

The Traffic Signal Control/Freeway Management components also exchange CoordinationData with each other as shown inside the larger box. The Coordination Data flow allowsthe traffic management strategies on the freeways, the freeway entrance ramps, and thesurface street network to act as an integrated system. These data define the actions to betaken by the system when a particular signal timing plan is in effect on the road network,and when a particular sign plan is in effect on the highways. For example, ramp metertimings and traffic signal controls can be coordinated to ensure that queues do not back upinto intersections. Or consider a scenario in which traffic is being diverted off of a freewayto bypass an incident. Traffic signal timings can be adjusted to handle the increased flowon the arterials. At the same time, variable message signs can be updated along the arterialsto give directions on how to return to the freeway beyond the incident location.

Electronic Toll Collection is responsible for automatic collection of tolls so that motoristsdo not have to stop to pay them. Although this offers significant benefits as an isolatedsystem, there is further synergism obtained by integrating Electronic Toll Collection withother IT1 components. In particular, the Electronic Toll Collection roadside and vehicleelectronics can be used as a source of traffic probe data for Traffic Signal Control/Freewaymanagement components.

26

l Wireline communications - this is something like plugging your computer modeminto your telephone outlet and connecting to an on-line service. There are ranges ofcapacity for wireline communication, they may be dedicated or dial-up, and theymay be provided by either the public or private sector. In some cases, it mayactually use wireless links (e.g., microwave), but the two ends are always fixed.

- Dedicated Short Range Communications (DSRC) - This channel would bededicated for short range (up to about 200 feet) communication between vehiclesand the immediate infrastructure. It would support functions such as toll collection,transit vehicle management, or automated commercial vehicle operations.

Each of the nine ITI components is associated with one or more of the 19 architecturesubsystems. The following table illustrates this affiliation between the IT1 and thearchitecture. The question mark under Railroad Grade Crossings indicates that thisinterface has not yet been defined.

Architecture

Roadway Subsystem (RS)Remote Traveler Support (RTS)Toll Administration (TAS)

Architecture Deployment Strategy

The logical and physical architectures that have been discussed above are provided todescribe how transportation functions and data flows are tied together. They do not provideany guidance as to which organizations should provide the functionality. If oneorganization carries out multiple functions and operates multiple sub-systems, this is all tothe good, because that organization can more likely ensure that data flows are compatible.

28

However, one of the benefits of the ITS architecture is that it identifies what data flowsmight exist between different organizations, such as transit management and trafficmanagement organizations. The architecture indicates the requirements for eachorganization’s functions to be able to be coordinated or integrated with those of anotherentity. For example, traffic surveillance could be carried out by a private sector entity aswell as by the more traditional public agencies because the architecture defines the linksneeded to cross both jurisdictional and organizational boundaries.

The ITS architecture identifies portions of the physical architecture as one or moreInformation Service Providers, or ISPs. The ISPs provide transportation information totravelers and other interested users. The important point of the architecture is that an ISPcan be either a public or private organization. For example, a State or municipal trafficagency could collect, process and disseminate traffic information; or, the traffic agencycould collect and process the data, and then provide (perhaps even sell) it to a private ISPthat would do more sophisticated processing, and then sell it to consumers. Othervariations can exist, where a commercial ISP would obtain raw data directly from localtraffic sensor/processor systems.

The architecture has a structure that allows for any and all of the possible ISParrangements. The data flows have been identified in such a way that the organizationsinvolved in a particular deployment approach can find the appropriate assistance in thearchitecture documents.

What the following paragraphs provide

The following paragraphs provide more architecture information on the individual IT1components. Architecture subsystems that make up the IT1 components are shown. Dataflows between these subsystems are also shown. Note, however, that these flows areinternal to and reside within the IT1 component. The external flows to other componentswere discussed in the preceding section. They are indicated here as external to the outerdotted line boxes surrounding the subsystems.

29

Regional Multimodal Traveler Information

Three architecture subsystems are used to provide Regional Multimodal TravelerInformation. Incident, traffic, and transit data from the other IT1 components are input,processed, and stored by the Information Service Provider (ISP). The other twosubsystems, Remote Traveler Support (RTS) and the Personal Information AccessSubsystem (PIAS), essentially duplicate each other’s functionality. They requestinformation from the ISP and provide it to the traveler. However, the electronic mediaused for dissemination of the information differs between them. RTS disseminates theinformation at fixed sites, such as at signs at transit stops. RTS also provides kiosks atshopping malls and other public locations. The PIAS, on the other hand, disseminatestraveler information in the home or place of business using personal portable devices andother electronic media.

Traveler Trip lnformatlon

Transit VehicleSchedule Deviations

Information Service Traveler Trip Informatlon

Provider (ISP) Transit VehicleSchedule Deviations

Collects, processes, stores, and disseminatestraveler information to subscribers and to

Traffic Data for Kiosksthe public at large

Inputs data From other ITI elements

Provides traffic and incident data For themedia

Multi-modal trip planning

Remote TravelerSupport (RTS)

Provides traveler information attrans,t stops and other Fixed sntes

Get traveler requests

Inform traveler

Provides traveler Information athomes, business. and wa personalportable devices

I Get traveler requests

Inform traveler

Incident Data Traffic Data Transit Data

Regional Multimodal Traveler Information Data Flows

Traveler Trip Information: includes information on traffic conditions, transitroutes, and schedules

Transit Vehicle Schedule Deviations: deviations from published routes andschedules

Traffic Data for Kiosks: current and predicted traffic conditions on the roadnetwork

Traveler Requests: traveler trip requests that include traveler identification,origin/destination, and time of trip; requests for current information on trafficconditions and incidents

38

5. Common Questions Raised by Implementors

Now that you’ve read all of this, you probably have questions. In developing thearchitecture and in preparing this handbook, we spent a great deal of time talking toimplementors. From these interactions, we’ve identified a list of “frequently askedquestions” and have prepared answers for them.

Q: The architecture doesn’t specify standards to be used in deploying theIT1 but indicates that they should be used once developed. What do I do toensure that my current investments are not negated by future technologydevelopments ? What do I do while I’m waiting for these standards to bedeveloped?

A: The architecture addresses the systems that make up IT1 and discusses data that must beshared between systems. It also identifies some ongoing standards activities that maysupport deployment based on the architecture. The architecture should be used indesigning a system or evaluating a potential deployment to make sure that all capabilitiesand dataflows defined by the architecture for that subsystem are supported and that keyinterfaces are developed. By doing this, you can realize immediate ITS benefits, whilemaximizing your ability to adopt future standards when performing upgrades.

Q: I am building a Traffic Management Center now and have plans tocollect surveillance data. Someday, I may want to be able to distribute thisinformation to the public (e.g., link travel times) via and ISP. What can Ido now so that I don’t preclude that option in the future?

A: The architecture addresses the issue of providing this type of data to ISPs. Review thearchitecture regarding the contents of messages that will be needed to support this function.In designing your system, make sure that you have collected, or at least considered, all ofthe data which the architecture considers necessary for this interface. When you developyour custom interface between your TMC and the ISP , isolate it from the rest of yoursystem so that, once a standard has been developed, you can quickly redesign that interfacewithout having to change the rest of your system. This is an excellent approach to “buyingsmart” and is expected to have significant economic benefits in the future.

Q: I’m sold on the concept of the ITI, but can I afford it?

The components of the IT1 are not new budget items to State and local jurisdictions. MostState and many metropolitan areas are already using Federal-aid funds to purchase orupgrade IT1 systems, including traffic signals, freeway management, transit management,incident management, electronic fare payment and toll collection, traveler informationcenters, railway-highway grade crossings, and emergency management. Many of thesesystems are already in place and were purchased with Federal-aid funds.

As you upgrade, repair, or replace these existing systems, you need to plan ahead forsystem integration, and “buy smart.” In the future, State and local jurisdictions need topurchase component systems that are able to share data with other transportation systemsand with neighboring jurisdictions, so that the public can experience the benefits ofintegrated metropolitan transportation management.

Our emphasis on “buying smart” is directed at encouraging implementors to be aware ofwhat the future requirements may be, and to know what “sister agencies” in the same andsurrounding jurisdictions are planning. In this manner, for example, agencies which need

39

to communicate with one another during a traffic incident (as with freeway managementand emergency response entities) would get together to establish common functionalrequirements and specifications for radio and data links so that “real-time” coordination cantake place. Financially, it may be feasible to combine purchase needs into a single, largerprocurement which would benefit all participating agencies due to economies of scale. Inaddition to these types of financial benefits, we also are working to encourage agencies tocontinue efforts to partner with private sector firms, especially in the area of travelerinformation dissemination. Most aspects of this type of integration and innovativefinancing are eligible under current Federal-aid funding categories, and we encourageStates and other entities to work with appropriate U.S. DOT offices regarding theseopportunities.

Q: How should my future designs include both existing equipment andconform to the architecture? What should I do to ensure that futureupgrades of my equipment conform to the architecture?

A: As you plan new features and upgrades to your systems and subsystems, you shouldreview the design of these new features to make sure the interfaces utilize the architectureor, eventually, the standards recommended by the architecture. Over time, proprietaryinterfaces will phase out if no one is buying them and will be replaced with open interfacesthat can readily be interfaced to other subsystems. This will not all happen overnight. Insome cases, protocol converters may be needed to interface existing equipment to newerequipment until such time as the existing equipment needs to be replaced. At that time, itshould be replaced by a system supporting open interfaces. Standards can provide amessaging format to minimize interface cost and complexity.

Q: I live in a rural area of the country. However, this handbook seems tofocus primarily on urban transportation systems. What should I be doing?

A: The IT1 includes support for rural implementations and the architecture addresses ruralservices. This handbook has been limited in scope to focus on urban applications. Futureguidance will be provided that helps implementors interpret the architecture from a ruralperspective.

Q: Where does the architecture allocate “intelligence” in the system? Is itcentralized or distributed?

A: The architecture is flexible enough to support both distributed intelligence andcentralized systems. For route guidance applications, it is assumed that more systemintelligence will reside within the vehicle in the near-term and that, over time, morecentralized systems may evolve. For traffic management, the architecture supports bothtypes of systems, although coordination functions are generally centralized in nature.

Q: I am concerned that by providing data to private sector InformationService Providers (ISP) and letting them package and disseminate it totravelers, I may lose control over my transportation system. What can I doto prevent that? (e.g., suppose an ISP routes all of my freeway trafficthrough local streets to avoid a backup?)

A: The architecture specifies the types of data that should be shared between subsystems.Restrictions as to how that data is used will have to be determined on a regional basis. If alocal DOT wants to place limitations on where vehicles are routed during a backup, thatDOT will have to reach an agreement with the ISP receiving the data as to how it can beused and will need to determine an approach for enforcing the agreement.

40

Q: Who will own and operate ITS/ITI?

A: Various deployment options are possible with the ITI/ITS. The public sector willundoubtedly retain ownership of some portions, some portions may be provided by theprivate sector, and some may entail public/private partnerships. Public/private partnershipscan take many forms, including contracting out of maintenance and/or operations,privatizing services, franchising, or consortia. The architecture itself is independent ofthese various options and any combination of the three may be possible. And, there isexpected to be some regional variation in how deployment occurs. The architecture onlydefines the subsystems and dataflows between subsystems and does not specify who ownsor operates the various components. Ownership of the different components andresponsibility for operation will be determined on a regional basis.

Q: As technologies and applications evolve, it is certain that changes willbe required to the architecture. Are there plans to maintain and evolve thearchitecture? As an implementor, how will I be made aware of thesechanges?

A: Plans are underway for maintaining the architecture into the future once the initialarchitecture development is complete. Items that may cause the architecture to changewould be new user services, modifications to existing user services, or corrections requiredas more implementors begin using the architecture. A process has yet to be determined fordistributing future changes but it is our intention to make such information widelyavailable.

Q: As I deploy the IT1 components, should I install my owncommunication systems or should I lease commercially availablecommunication links?

A: This decision will vary on a regional basis and even within a region and will dependupon a number of factors including:

l Requirements analysis - What functions will be supported? How much capacity doyou need? What coordination is appropriate with adjoining jurisdictions?

l Technical design tradeoffs - are commercial links available to support aninstallation? Do they offer sufficient capacity? Are they accessible where you needthem?

l Cost tradeoffs - can commercial communications links provide the same services atlower cost? Should you consider a public-private partnership? You should be sureto include total life-cycle costs and benefits in the analysis

l State/local regulatory environment - What effect may State/local requirements haveon communications procurement? You should closely examine potentialopportunities in your area which may provide access to communicationsinfrastructure.

l Existing equipment - what infrastructure have you already installed? How can youbest augment your current capabilities?

Q: Does the architecture depend solely upon cellular telephone technologyand Cellular Digital Packet Data (CDPD) for ITS data transmission?

A: No. The architecture is an open architecture and can support a wide range ofdeployment options. Since part of the National ITS Architecture Development Programincluded the requirement to evaluate the architecture, it was necessary to develop a design

41

based on the architecture (you can’t evaluate an architecture.) For this evaluation, CDPDwas chosen as the two-way wide area wireless communication technology. Other mediamay be used for both two-way communication and one-way broadcast of information.

Q: Is it true that the architecture excludes beacons for communicationbetween the roadside and the vehicle?

A: No. The architecture makes use of beacons where they are appropriate such as for tollcollection and commercial vehicle operations. The architecture also supports the optionaluse of beacons for some other applications, such as vehicle probe reports, as is being donein Houston. However, a general purpose beacon infrastructure to support other ITSapplications such as route guidance and navigation is not cost-effective and is neitherrecommended nor supported by the architecture.

Q: The architecture seems to be fairly general and covers everything.What would constitute non-conformance with the architecture? Whatshould I do to begin to utilize the architecture?

A: The architecture doesn’t make technology decisions for you. It’s not supposed to. Thearchitecture provides a framework for thinking about the problem. It looks at the problemon a functional basis and tries to optimize the aggregation of functions. The key is toensure that the various systems and components can exchange the information specified inthe architecture. The architecture identifies ways to take advantage of synergies (see Section3). As you get into regional deployment, you will need to worry about regional concerns(How can I best interface with the jurisdiction next door?) and design tradeoffs (What’s thebest, most affordable way to implement this capability?) Your regional architecture willaddress how you will integrate your systems. If you haven’t gone through the thoughtprocess shown in the architecture documents, your system may be more of anunmanageable kludge than an upgradeable, maintainable system. (Much like an old coalfurnace...it interfaces to your heating ducts and warms the house, but there are much moreefficient ways to do the job.) Given enough money and enough custom interfaces, any onesystem can be made to communicate with another system.

Utilizing the architecture helps you minimize the time and costs to upgrade, integrate, andevolve. Plus, architecture is an evolving process. As standards are developed, they will betailored to the subsystems and interfaces defined in the architecture. Utilization of adoptedstandards will be the ultimate measure of the success of the architecture. If you follow thearchitecture today, then several years from now when there are clear standards andguidelines, you will likely be close to being able to take advantage of the benefits ofarchitecturally compatible equipment in future procurements. If you didn’t consider thearchitecture in your design and didn’t follow its evolution, then your system could be aone-of-a-kind, standalone system, which can be quite difficult and expensive to upgrade orexpand.

The architecture provides a framework that both implementors and vendors can follow as aguide for designing and deploying systems. Following the architecture ensures that youwill have a competitive migration path as you upgrade your systems and add morefunctionality. By not following the architecture, you risk locking yourself into a singlevendor system with the inherent costs, limitations of future growth, and risk of no futuresupport.

42

Q: I thought that CVO is a major part of ITS. Why is there limiteddiscussion of CVO requirements in this handbook?

A: The IT1 includes support for CVO applications and the architecture addresses CVO indetail. This handbook has been limited in scope to focus on urban applications. Futureguidance will be provided that helps implementors interpret the architecture from a CVOperspective.

43

Appendix: How to Find Information in the Architecture Documentation

The architecture is documented in a number of volumes totaling approximately 3600 pages.The primary breakdown of this documentation set is:

Architecture definition: This includes all of thetechnical detail on functions and subsystems, what theyare, and what information is exchanged. These are theblueprints.

Deployment Options: These documents discussvarious options that the designers of the architectureenvisioned for deploying ITS and ITI. These documentsbegin to discuss design issues but don’t tell you exactlywhat to buy.

Architecture Evaluation: This set of documentssummarize the analysis conducted by the architecturedesigners to show that the architecture would actuallywork. Remember, you can’t evaluate anarchitecture...you have to evaluate an implementation ofthe architecture. These documents discuss how various“evaluatory designs” were evaluated. While none ofthese sample analyses will exactly match yourdeployment requirements, they can be used to help youstructure your own analysis and provide you with achecklist so you don’t miss anything.

-Mission Definition-Vision-Theory of Operations-Logical Architecture-Physical Architecture-Traceability Matrix-Communications Document

-Implementation Strategy-Standards Requirements-Standards Development Plan

-Performance and BenefitsStudy

-Cost Analysis-Risk Analysis-Evaluation Summary-Evaluatory Design

45

A brief synopsis of the content of each document follows:

Mission Definition - ties the architecture to the national program plan and addressesgoals, objectives, user service requirements, and expected benefits.

Vision - magazine style view of what ITS will look like in the future.

Theory of Operations - a technical narrative and walk-through of how the architecturesupports ITS in operation.

Logical Architecture - a functional view of what is needed to implement ITS. This is alarge document and defines all of the processes and data flows between processes. Youwould probably reference this only to look at specific functions. This document addresses“what” functions need to be done.

Physical Architecture - collects related functions into subsystems and defines theinterfaces between subsystems. This document addresses “how” subsystems should beconnected to make ITS work.

Traceability Matrix - Provides a detailed mapping between the logical and physicalarchitecture. Used only by those doing detailed analysis.

Communications Document - a thorough analysis of the communication requirementsof the architecture and ITS including discussion of options for implementation of thevarious communications links.

Implementation Strategy - discusses examples of how the architecture can bedeployed.

Standards Requirements - detailed information regarding standards packages that needto be developed to implement the architecture.

Standards Development Plan - discusses the steps necessary to produce interfacestandards. The audience for this document is primarily the Standards DevelopmentOrganizations and system designers.

Performance and Benefits Study - discusses the benefits of having and deploying toan architecture.

Cost Analysis - provides unit and system costs for deploying ITS based upon thearchitecture.

Risk Analysis - assesses risks threatening architecture deployment and presentsmitigation strategies for those risks.

Evaluation Summary - a summary of the various evaluations conducted duringdevelopment of the architecture.

Evaluatory Design - provides a unifying set of assumptions as a basis for theevaluations.

46

Publication No. FHWA-JPO-96-011HVH-l/4-96(10M)QE