Standards Migration and Integration

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

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

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

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

7. 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 TransCore’s Migration Projects

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

9. Traffic Controller Laptop Local Comm NTCIP Comm Logic/Ops Database Outputs Inputs

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. Econolitedual vehicle permissiveperiods PEEK - adaptive split control

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. 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. 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. 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. Case Study: Phoenix, AZ Cont. • 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!

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. 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. 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. 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. 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. Similarities in the Solutions • Both Cities ended up with identical solutions: • Mandatory Objects • Small set of Optional Objects • Database access via Proprietary Objects

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. 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. 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 implementationguide to clarify the NTCIP deployment issues (This is in process).

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