There are also concerns about data rebroadcast latency, which will be dependent on both how the central control system communicates with the signals and how the installed rebroadcast hardware works. This approach potentially avoids the need to install intersection level equipment but is only viable if an agency has a centrally controlled and/or monitored signal system. The company would also typically need to know intersection layouts and phase diagrams. And they typically offer some agency control over who the data is then redistributed to. Some of these companies offer installation at no cost to the agency but requiring that the central signal control system uses NTCIP compliant communications protocols and requiring a SPaT data stream via Ethernet from the central signal control computer. One port plugs into the hardware that draws the SPaT data from your central signal control computer a second port then provides for the distribution of the data to others. The connection to the central signal control computer is typically done through Ethernet ports. Typically this is done using a small device that interfaces with the central signal control computer which can redistribute real-time traffic signal data to selected third parties. Several startup companies are beginning to offer a hardware solution to agencies wishing to provide a central signal control system option for SPaT broadcast. This also enables individual intersections operating adaptive control to communicate their real-time status to the central controller. This enables operators to select to change the current signal timing plans in operation at the intersections without traveling to the intersections. In areas where traffic signal controllers are connected to central signal control systems, a central system communicates regularly with some or all of the traffic signal controllers (TSCs) at the intersections. The intent of this subsection is to recognize this alternate approach, and to clarify some functions of the DSRC approach. There is currently an approach towards disseminating traffic signal timing status to travelers that does not use DSRC broadcasts. Section 5: Performance Requirements for SPaT, MAP, and RTCM – This section provides performance requirements for SPaT broadcasts based on integration with the Red Light Violation Warning Application.This section also provides information to help you determine the additional hardware/software needed to be implemented to support the SPaT broadcast, and finally describes the V2I Hub as a resource available to all agencies. Section 4: Installing New Hardware/Software to Support SPaT – This section presents minimum existing infrastructure needs to support SPaT to help you determine if your existing signal control software is compatible with the SPaT broadcast.Section 3: Overall SPaT Implementation Guidance – This section presents a high-level summary of three resources that describe a checklist of activities, specifications for SPaT hardware, and lessons learned from SPaT deployments, together with hyperlinks to the source documents.Section 2: Physical Architecture Drawing and Summary of Needed Functions and Data Exchanges – This section presents an overall diagram of the primary components of a SPaT deployment, together with a summary of the functions required. The intent of this document is to support agencies that have decided to deploy SPaT broadcasts by providing an overall summary of the implementation process. The goal of the SPaT Challenge is to encourage state or local agencies throughout the United States to deploy Dedicated Short Range Communications (DSRC) broadcasts of Signal Phase and Timing (SPaT) at approximately 20 intersection locations, typically in a corridor or network setting.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |