1. 1 Standards Migration and Integration William L. Skillas, P.E. Larry D. Henson, P.E. TransCore’s Standards Migration/Integration Efforts/Projects

2. 2 Outline TransCore’s perspective Current Standards - Systems Perspective Projects Our NTCIP Experience (Phoenix and Lakewood)

3. 3 TransCore ITS/ATMS is our business –TransCore and its predecessors have been in ITS for 50 years –Specialize in Electronic Toll and ATMS applications Full service engineering consulting firm –Feasibility and design –Implementation and operations –evaluation TransCore has 700 employees in 48 U.S. cities and Australia

4. 4 TransCore’s - Perspective System Designer/Integrator/Operator (Freeway, Traffic, CCTV, etc.) Core Systems Products –Traffic Control (Series 2000, SCATS) –Traveler Information System (VMS/HAR) –CCTV management system (VCS) –Incident Tracking and Management (MICE/CATS) –Malfunction management –WWW applications Use Off-The-Shelf ‘Open Systems’ Hardware/Software –PC/NT/ODBC/CORBA/ORACLE/SYBASE/UNIX/COM-DCOM/... Middle-ware/Enabling products –Data transport –ATMS MAP –ATMS Explorer

5. 5 A Systems View of the Standards Program TMC TMDD ATIS Road-Side Devices NTCIP Class B IEEE P1512 MS/ETMC 2 DSRC SAE - J2353, J2354 EMC TMC ISP Foundation P1488 - MST P1489 - DDF LRMS- J2374 1 Links 2 Incidents 3 Traffic Devices 4 Freeway Devices 5 Other In-Vehicle C2C - NTCIP NTCIP Transit METS MS/ETMC 2 SAE

6. 6 Typical ATMS Architecture TCSFTMSATIS Export Import Traffic Controller Ramp Controllers Detector Count Station Changeable Message Sign Hwy Advisory Radio NTCIP Class B (Serial) NTCIP Class E or TCP/IP (Ethernet) NTCIP Class E / C2C / PE1512 Workstation ESSCCTV

7. 7 TransCore’s Migration Projects Milwaukee, WI –TMDD –P1512 Monroe County, NY –NTCIP for Controllers –C2C using DATEX ASN Phoenix/Lakewood –NTCIP for Controllers San Gabriel Valley, CA –C2C using CORBA NYS- Region 11 –C2C (TBD) –TMDD Cross Bronx Expressway –DMS –C2C using DATEX ASN Atlanta, GA –C2C using CORBA –TMDD

8. 8 Traffic Control System Architecture Core Traffic System Communications Server Controllers Serial Communications (Leased Lines, Fiber, Spread- Spectrum, etc) NTCIP Class B Workstations Central Database LAN / WAN Workstations

9. 9 Traffic Controller NTCIP Comm Logic/OpsDatabase Local Comm OutputsInputs Laptop

10. 10 Requirements for an NTCIP Controller? Interchangeability ? – At what level - all features or a subset ? A minimum operational feature set ? The ability to monitor and control the intersection from Central ? Support of additional (vendor-specific) features E.g. Econolite dual vehicle permissive periods PEEK - adaptive split control

11. 11 Approaches Least Common Denominator –Specify a set of objects to which all vendors must comply. –Each vendor may expand that set with proprietary objects. Minimum base-line functionality - customized only as vendor’s require. Universal Data Set –Specify an all-encompassing object set, and each vendor must choose objects from that set. - $$$ System must support all features and functions, even though not all vendors will provide them.

12. 12 Two Case Studies City of Phoenix - Least Common Denominator, no NTCIP specifics. City of Lakewood - Universal Data Set, specified each required and desired object.

13. 13 Case Study: Phoenix, AZ Generic Requirements in RFP (for the controllers): “ Controller units shall be capable of an operational communications protocol allowing full communications to the City’s new traffic signal system. Protocol is based on the latest version of the NTCIP protocol. If NTCIP is updated/revised in the future, the City will desire such upgrades to be implemented in controllers. Proposer shall provide... all upgrades and updates at no additional cost for a period of 24 months from the date of delivery of units to the City Traffic Signal Shop... … Proposers shall provide the City with all information identifying manufacturer-specific features and functions contained within the proposed NTCIP protocol beyond those specified and required by the NTCIP definition.”

14. 14 Case Study: Phoenix, AZ Cont. Problems: –Manufacturers only agreed to support the Mandatory Objects. –All other objects to be proprietary. (NDA for MIBS) –Each manufacturer has a unique set of proprietary objects that could not be cross-mapped. Solutions: –Mandated support of small subset of optional standard TS3.5 objects. –Manufacturer-specific implementation at TCS for monitoring of devices. (Transition for Series 2000) –Manufacturer-specific database and user interface configurations. NOTE: vendors had separate supply contract to the city Phoenix went for a full city wide deployment First Vendor - Econolite, Second was PEEK - Both Low Bid

15. 15 Project was characterized by –Stop work –Change-orders –Re - negotiations –Delayed Installation –Interim Implementation of AB3418 But it was new technology....... –The RFP was prior to the publication of the NEMA documents! Phoenix is to be commended in leading the way and proofing the technology and developing the applications for NTCIP. –At the time of the Bid, NONE of the vendors had NTCIP compliant controllers! Case Study: Phoenix, AZ Cont.

16. 16 Case Study: Lakewood, CO Very Specific NTCIP Requirements: “The traffic signal controller shall implement all mandatory Conformance Groups as defined in NEMA Standards Publication TS 3.4 … and TS 3.5” “The traffic signal controller shall also implement all mandatory Objects of the following optional Conformance Groups as defined in NEMA Standards Publication TS 3.4 … and TS 3.5...” “The traffic signal controller shall also implement the following optional objects as defined in NEMA Standards Publication TS 3.5...”

17. 17 Case Study: Lakewood, CO - Cont. Additional Specific Requirements: “It is the City's desire that the controller software also implement the following optional objects as defined in NEMA Standards Publication TS 3.5...” Note: RFP further specified ranges (Clarifying the NEMA Spec.) “All objects required by these specifications shall support all values within its standardized range, unless otherwise approved by the City of Lakewood...” Several tables of object ranges followed

18. 18 Case Study: Lakewood, CO - Cont. Approach –System Integrator is responsible for purchasing and establishing a test bed. (9 Intersections) –There will be an evaluation of the test bed controllers. –System Integrator required each vendor to submit a proposal based on the RFP. –The proposal was to include a conformance statement, reasons for non-conformance, and alternative solutions. After evaluation –City will select vendors for full scale deployment - Low Bid

19. 19 Case Study: Lakewood, CO - Cont. Problems Encountered –Manufacturers could not support the required object set within the specified time frame –No compliant controllers available! –Vendor’s were reluctant to commit to building a solution for a small quantity without guarantee of large delivery. Solution –System Integrator sent a list of questions and minimum set of objects to vendors for review and discussion –The System Integrator set up teleconferences with each Vendor. –The City, the Vendor, and the System Integrator discussed alternative solutions and proposals with each Vendor.

20. 20 Case Study: Lakewood, CO - Cont. Result : –Integrator-mandated support of small subset of optional standard TS3.5 objects. –Manufacturer-specific implementation at TCS for monitoring of devices. –Manufacturer-specific database and user interface configurations. NOTE : The Solution is Identical to Phoenix - but issues are being resolved prior to procurement. The concept of a test-bed minimizes the risks to the City, the System Integrator, and the Vendor.

21. 21 Similarities in the Solutions Both Cities ended up with identical solutions: Mandatory Objects Small set of Optional Objects Database access via Proprietary Objects

22. 22 Conclusions Standardization of Objects nullifies proprietary features and functionality. –It is impossible for a standard object set to fully address each manufacturer’s operation. –It is difficult (if not impossible) to design a TCS that uses each manufacturer’s proprietary objects in a generic fashion. Each agency must evaluate tradeoff between standard operation and controller features. –Do the standard objects provide the desired functionality? –Can the controller features be mapped into the standard object set?

23. 23 Observations Manufacturers are working toward controller versions that support the standard (TS 3.5) object set. –Must modify underlying functionality to match data set. –Finite resources for implementing NTCIP. –Proprietary objects higher priority than standard. The newest TS-2 specifications address the issue of the required object set. –Subset of the optional TS 3.5 objects are required for TS-2 Level 2 Conformance. –Many manufacturers are focusing on these objects prior to the remaining optional objects.

24. 24 Recommendations Certification process for controllers - for all conformance groups FHWA/DOT sponsored development of software exerciser(s) which can be used by controller manufacturers and system developers to validate elements of the system. The early version has problems, and without this type of funding, everyone pays to iron out the ambiguities. The existing exerciser has been very valuable, as far as it goes. Comprehensive implementation guide to clarify the NTCIP deployment issues (This is in process).

25. 25 Applicability to Other Standards Implementation of P1512 and NTCIP C2C protocols rely on standardized message sets Message sets must be well defined and finalized in order to ensure a successful implementation Incomplete standard opens door for interpretation and “custom” implementations This leads to “scope creep”, increased cost and delays