< < PT09.6 : PT09.7 : PT09.8 > >
PT09.7: MEC Supported Implementation
Multi-Access Edge Computing (MEC) at the local Wide-Area Wireless node receives the signal priority request and processes it at the edge of the WAW network, coordinating with the signal controller to grant priority access to the transit vehicle, reducing latency and communications network traffic.
Relevant Regions:
- Enterprise
- Functional
- Physical
- Goals and Objectives
- Needs and Requirements
- Sources
- Security
- Standards
- System Requirements
Enterprise
Development Stage Roles and Relationships
Installation Stage Roles and Relationships
Operations and Maintenance Stage Roles and Relationships
(hide)
| Source | Destination | Role/Relationship |
|---|
Functional
This service package includes the following Functional View PSpecs:
Physical
The physical diagram can be viewed in SVG or PNG format and the current format is SVG.SVG Diagram
PNG Diagram
Includes Physical Objects:
| Physical Object | Class | Description |
|---|---|---|
| ITS Roadway Equipment | Field | 'ITS Roadway Equipment' represents the ITS equipment that is distributed on and along the roadway that monitors and controls traffic and monitors and manages the roadway. This physical object includes traffic detectors, environmental sensors, traffic signals, highway advisory radios, dynamic message signs, CCTV cameras and video image processing systems, grade crossing warning systems, and ramp metering systems. Lane management systems and barrier systems that control access to transportation infrastructure such as roadways, bridges and tunnels are also included. This object also provides environmental monitoring including sensors that measure road conditions, surface weather, and vehicle emissions. Work zone systems including work zone surveillance, traffic control, driver warning, and work crew safety systems are also included. |
| Multi-Access Edge Computing | Field | 'Multi-Access Edge Computing' ((MEC) previously known as mobile edge computing) represents computing devices that operate and are managed like a cloud server, but are deployed at the edge of a network (typically a cellular network, but it could be any network). While not in strict proximity to the transportation network, these systems do benefit from vastly decreased distances to the roadway compared to central systems, and so can provide lower latency than strictly backoffice systems |
| Traffic Management Center | Center | The 'Traffic Management Center' monitors and controls traffic and the road network. It represents centers that manage a broad range of transportation facilities including freeway systems, rural and suburban highway systems, and urban and suburban traffic control systems. It communicates with ITS Roadway Equipment and Connected Vehicle Roadside Equipment (RSE) to monitor and manage traffic flow and monitor the condition of the roadway, surrounding environmental conditions, and field equipment status. It manages traffic and transportation resources to support allied agencies in responding to, and recovering from, incidents ranging from minor traffic incidents through major disasters. |
| Transit Management Center | Center | The 'Transit Management Center' manages transit vehicle fleets and coordinates with other modes and transportation services. It provides operations, maintenance, customer information, planning and management functions for the transit property. It spans distinct central dispatch and garage management systems and supports the spectrum of fixed route, flexible route, paratransit services, transit rail, and bus rapid transit (BRT) service. The physical object's interfaces support communication between transit departments and with other operating entities such as emergency response services and traffic management systems. |
| Transit Operations Personnel | Center | 'Transit Operations Personnel' represents the people that are responsible for fleet management, maintenance operations, and scheduling activities of the transit system. These different roles represent a variety of individuals in the transit industry. Within the transit industry the person responsible for fleet management is known by many names: Street Supervisor, Starter, Dispatcher, Supervisor, Traffic Controller, Transportation Coordinator. This person actively monitors, controls, and modifies the transit fleet routes and schedules on a day to day basis (dynamic scheduling). The modifications will take account of abnormal situations such as vehicle breakdown, vehicle delay, detours around work zones or incidents (detour management, connection protection, and service restoration), and other causes of route or schedule deviations. Transit operations personnel are also responsible for demand responsive transit operation and for managing emergency situations within the transit network such as silent alarms on board transit vehicles, or the remote disabling of the vehicle. In addition the Transit Operations Personnel may be responsible for assigning vehicle operators to routes, checking vehicle operators in and out, and managing transit stop issues. This object also represents the personnel in the transit garage that are responsible for maintenance of the transit fleets, including monitoring vehicle status, matching vehicles with operators, and maintenance checking of transit vehicles. Finally, it represents the people responsible for planning, development, and management of transit routes and schedules. |
| Transit Vehicle OBE | Vehicle | The 'Transit Vehicle On-Board Equipment' (OBE) resides in a transit vehicle and provides the sensory, processing, storage, and communications functions necessary to support safe and efficient movement of passengers. The types of transit vehicles containing this physical object include buses, paratransit vehicles, light rail vehicles, other vehicles designed to carry passengers, and supervisory vehicles. It collects ridership levels and supports electronic fare collection. It supports a traffic signal prioritization function that communicates with the roadside physical object to improve on-schedule performance. Automated vehicle location enhances the information available to the transit operator enabling more efficient operations. On-board sensors support transit vehicle maintenance. The physical object supports on-board security and safety monitoring. This monitoring includes transit user or vehicle operator activated alarms (silent or audible), as well as surveillance and sensor equipment. The surveillance equipment includes video (e.g. CCTV cameras), audio systems and/or event recorder systems. It also furnishes travelers with real-time travel information, continuously updated schedules, transfer options, routes, and fares. A separate 'Vehicle OBE' physical object supports the general vehicle safety and driver information capabilities that apply to all vehicles, including transit vehicles. The Transit Vehicle OBE supplements these general capabilities with capabilities that are specific to transit vehicles. |
| Transit Vehicle Operator | Vehicle | The 'Transit Vehicle Operator' represents the person that receives and provides additional information that is specific to operating the ITS functions in all types of transit vehicles. The information received by the operator would include status of on-board systems. Additional information received depends upon the type of transit vehicle. In the case of fixed route transit vehicles, the Transit Vehicle Operator would receive operator instructions that might include actions to take to correct schedule deviations. In the case of flexible fixed routes and demand response routes the information would also include dynamic routing or passenger pickup information. |
Includes Functional Objects:
| Functional Object | Description | Physical Object |
|---|---|---|
| MEC Intersection Management | 'MEC Intersection Management' uses cellular communications to support connected vehicle applications that manage signalized intersections. It communicates with nearby vehicles and ITS infrastructure (e.g., the traffic signal controller) to enhance traffic signal operations. There may be constraints related to performance related to communications with participants using network operators foreign to the MEC. | Multi-Access Edge Computing |
| Roadway Signal Control | 'Roadway Signal Control' includes the field elements that monitor and control signalized intersections. It includes the traffic signal controllers, detectors, conflict monitors, signal heads, and other ancillary equipment that supports traffic signal control. It also includes field masters, and equipment that supports communications with a central monitoring and/or control system, as applicable. The communications link supports upload and download of signal timings and other parameters and reporting of current intersection status. It represents the field equipment used in all levels of traffic signal control from basic actuated systems that operate on fixed timing plans through adaptive systems. It also supports all signalized intersection configurations, including those that accommodate pedestrians. In advanced, future implementations, environmental data may be monitored and used to support dilemma zone processing and other aspects of signal control that are sensitive to local environmental conditions. | ITS Roadway Equipment |
| TMC Multi-Modal Coordination | 'TMC Multi-Modal Coordination' supports center-to-center coordination between the Traffic Management and Transit Management Centers. It monitors transit operations and provides traffic signal priority for transit vehicles on request from the Transit Management Center. | Traffic Management Center |
| TMC Signal Control | 'TMC Signal Control' provides the capability for traffic managers to monitor and manage the traffic flow at signalized intersections. This capability includes analyzing and reducing the collected data from traffic surveillance equipment and developing and implementing control plans for signalized intersections. Control plans may be developed and implemented that coordinate signals at many intersections under the domain of a single Traffic Management Center and are responsive to traffic conditions and adapt to support incidents, preemption and priority requests, pedestrian crossing calls, etc. This may include adaptive traffic control systems (ATCS) that adjust signal timings based on traffic conditions, demand, and system capacity. It also supports all signalized intersection configurations, including those that accommodate pedestrians. | Traffic Management Center |
| Transit Center Priority Management | 'Transit Center Priority Management' monitors transit schedule performance and generates requests for transit priority on routes and at certain intersections. It may coordinate with the Traffic Management Center to provide transit priority along the selected route, including allocation of dynamic lanes and granting signal priority. It also coordinates with the Transit Vehicle OBE to monitor and manage local transit signal priority requests at individual intersections. | Transit Management Center |
| Transit Vehicle Signal Priority | 'Transit Vehicle Signal Priority' provides the capability for transit vehicles to determine eligibility for priority and request signal priority at signalized intersections, ramps, and interchanges through short range communication with traffic control equipment at the roadside. | Transit Vehicle OBE |
| Vehicle Basic Safety Communication | 'Vehicle Basic Safety Communication' exchanges current vehicle characteristics, location, and motion (including past and intended maneuver) information with other vehicles in the vicinity and the infrastructure, uses that information to calculate vehicle paths, and warns the driver when the potential for an impending collision is detected. If available, map data is used to filter and interpret the relative location and motion of vehicles in the vicinity. Information from on-board sensors (e.g., radars and image processing) are also used, if available, in combination with the V2V communications to detect non-equipped vehicles and corroborate connected vehicle data. This object represents a broad range of implementations ranging from basic Vehicle Awareness Devices that only broadcast vehicle location and motion and provide no driver warnings to advanced integrated safety systems that coordinate maneuvers and may, in addition to warning the driver, provide collision warning information to support automated control functions that can support control intervention. This object can also support broadcasting other vehicle information required for passing through a specific roadway segment such as variables that describe vehicle's characteristics and parameters, driver's preferences in terms of vehicle motion and behavior, etc. | Vehicle |
| Vehicle Intersection Movement | 'Vehicle Intersection Movement' uses short-range wireless communications to monitor other connected vehicles at intersections and support the safe movement of the vehicle through the intersection by receiving and processing signal phase and timing messages from the intersection. Driver warnings are provided and the application may also optionally take control of the vehicle to avoid collisions, in coordination with Vehicle Control Automation. The application will also notify the infrastructure and other vehicles if it detects an unsafe infringement on the intersection. | Vehicle |
Includes Information Flows:
| Information Flow | Description |
|---|---|
| driver information | Regulatory, warning, guidance, and other information provided to the driver to support safe and efficient vehicle operation. |
| intersection control status | Status data provided by the traffic signal controller including phase information, alarm status, and priority/preempt status. |
| intersection geometry | The physical geometry of an intersection covering the location and width of each approaching lane, egress lane, and valid paths between approaches and egresses. This flow also defines the location of stop lines, cross walks, specific traffic law restrictions for the intersection (e.g., turning movement restrictions), and other elements that support calculation of a safe and legal vehicle path through the intersection. |
| intersection management application info | Intersection and device configuration data, including intersection geometry, and warning parameters and thresholds. This flow also supports remote control of the application so the application can be taken offline, reset, or restarted. |
| intersection management application status | Infrastructure application status including current operational state and status of the field device and a log of operations. |
| intersection status | Current signal phase and timing information for all lanes at a signalized intersection. This flow identifies active lanes and lanes that are being stopped and specifies the length of time that the current state will persist for each lane. It also identifies signal priority and preemption status and pedestrian crossing status information where applicable. It may also include future signal phase and timing information. |
| right-of-way request notification | Notice that a request has occurred for signal prioritization, signal preemption, pedestrian call, multi-modal crossing activation, or other source for right-of-way. |
| signal control commands | Control of traffic signal controllers or field masters including clock synchronization. |
| signal control status | Operational and status data of traffic signal control equipment including operating condition and current indications. |
| signal priority request | Request from a vehicle for priority at an intersection. The request may include the priority level, the desired time and duration of service, and the intended travel path through the intersection. This flow may also allow the originator to cancel a previously issued request for priority. |
| signal priority service request | A service request for vehicle priority issued to a traffic signal controller. The request includes the priority level, and may include other parameters such as the desired time and duration of service, and the intended travel path through the intersection. This flow also allows the originator to cancel a previously issued request for priority. |
| signal priority status | In response to a request for signal priority, this flow indicates the status of the priority or preemption request. |
| traffic control priority request | Request for signal priority at one or more intersections along a particular route. |
| traffic control priority status | Status of signal priority request functions at the roadside (e.g., enabled or disabled). |
| transit operations personnel input | User input from transit operations personnel including instructions governing service availability, schedules, emergency response plans, transit personnel assignments, transit maintenance requirements, and other inputs that establish general system operating requirements and procedures. |
| transit operations status | Presentation of information to transit operations personnel including accumulated schedule and fare information, ridership and on-time performance information, emergency response plans, transit personnel information, maintenance records, and other information intended to support overall planning and management of a transit property. |
| vehicle location and motion | Data describing the vehicle's location in three dimensions, heading, speed, acceleration, braking status, and size. |
Goals and Objectives
Associated Planning Factors and Goals
| Planning Factor | Goal |
|---|
Associated Objective Categories 
| Objective Category |
|---|
Associated Objectives and Performance Measures
| Objective | Performance Measure |
|---|
Since the mapping between objectives and service packages is not always straight-forward and often situation-dependent, these mappings should only be used as a starting point. Users should do their own analysis to identify the best service packages for their region.
Needs and Requirements
| Need | Functional Object | Requirement | ||
|---|---|---|---|---|
Related Sources
| Document Name | Version | Publication Date |
|---|---|---|
| None |
Security
In order to participate in this service package, each physical object should meet or exceed the following security levels.
| Physical Object Security | ||||
|---|---|---|---|---|
| Physical Object | Confidentiality | Integrity | Availability | Security Class |
| ITS Roadway Equipment | ||||
| Multi-Access Edge Computing | ||||
| Traffic Management Center | ||||
| Transit Management Center | ||||
| Transit Vehicle OBE | ||||
In order to participate in this service package, each information flow triple should meet or exceed the following security levels.
| Information Flow Security | |||||
|---|---|---|---|---|---|
| Source | Destination | Information Flow | Confidentiality | Integrity | Availability |
| Basis | Basis | Basis | |||
| ITS Roadway Equipment | Multi-Access Edge Computing | intersection control status | Moderate | High | Moderate |
| This data is intentionally transmitted to everyone via a While this information is broadcast and can also be determined via other visual indicators, all communications between field infrastructure should be protected from viewing to prevent attackers from analyzing traffic and developing attack methods. | If this is compromised, the Roadway Equipment and Roadside Equipment will be sending messages that are inconsistent with each other, leading to confusion and possible accidents. | If this is down, the RSE doesn’t get the information it needs to stay in synch with the actual signal state, reducing or eliminating the value add from having this application. The RSE must detect a lack of availability and choose not to send out-of-date information, so a failure of availability could be interpreted as having the same value as Integrity. However, this data is semi-predictable and there are other indicators (such as the lights themselves) of the intersection status. From NYC, who believe this should be HIGH for some applications: If this is down, the RSE doesn’t get the information it needs to stay in synch with the actual signal state, reducing or eliminating the value add from having this application. The RSE must detect a lack of availability and choose not to send out-of-date information, so a failure of availability cannot have worse consequences than a failure of integrity which we have previously assessed at HIGH. | |||
| ITS Roadway Equipment | Traffic Management Center | right-of-way request notification | Low | Moderate | Moderate |
| This can be reasonably guessed based on observing the ITS RE’s environment. It is obvious when a bus approaches an intersection. | Invalid messages could lead to an unauthorized user gaining signal priority at an intersection. This could also be used to delay traffic, which could lead to a financial impact on the community. However, the traffic signal will have controls in place to ensure that it does not display an illegal configuration (such as green in every direction). | Even if all of the Right-of-way Requests are not passed along from an ITS RE, the intersection will still operate as normal. There are other existing methods to assist a right-of-way requesting vehicle safely traveling through an intersection, such as lights and sirens, which prevent this from being a HIGH. DISC: THEA and NYC believe this to be LOW: "not necessary for the app to work; can cope with not having immediately available data" | |||
| ITS Roadway Equipment | Traffic Management Center | signal control status | Low | High | Moderate |
| The current conditions of an ITS RE are completely observable, by design. | This influences the TMC response to a right-of-way request. It should be as accurate as the right-of-way request themselves. For some applications (ISIG) this need only be moderate. Per THEA: info needs to be accurate and should not be tampered to enable effective monitoring and control by the TMC. DISC: THEA believes this to be MODERATE: "info needs to be accurate and should not be tampered to enable effective monitoring and control by the TMC; should be as accurate as the right of way request". NYC:TMC doesn’t play an active role in this application, i.e. even if the information contained in this flow were incorrect, it is unlikely to affect the outcome of this application one way or the other. On some applications NYC has this MODERATE though. RES: This value can obviously change a lot depending on the application context. | The TMC will need the current status of the ITS RE in order to make an educated decision. If it is unavailable, the system is unable to operate. However, a few missed messages will not have a catastrophic impact. From NYC: TMC doesn’t play an active role in this application, i.e. even if it is unavailable, it is unlikely to affect the outcome of this application one way or the other. RES: This value can change a lot depending on the application context. | |||
| ITS Roadway Equipment | Transit Vehicle Operator | driver information | Not Applicable | High | Moderate |
| This data is sent to all drivers and is also directly observable, by design. | This is the primary signal trusted by the driver to decide whether to go through the intersection and what speed to go through the intersection at; if it’s wrong, accidents will happen. | If the lights are out you have to get a policeman to direct traffic – expensive and inefficient and may cause a knock-on effect due to lack of coordination with other intersections. | |||
| Multi-Access Edge Computing | ITS Roadway Equipment | signal priority service request | Moderate | Moderate | Low |
| There is no sensitive or confidential information within this messages. Additionally, it could be inferred by observing either the presence of a priority-requesting vehicle near an intersection, or the effect on the timing of the intersection. This is also transmitted as a result of broadcast data; however, all communications between field infrastructure should be protected from viewing to prevent attackers from analyzing traffic and developing attack methods. | The MEC is transmitting a request to the ITS RE on behalf of a priority-requesting vehicle. It should only be making requests on behalf of an approved vehicle. A corrupted request may lead to a vehicle not receiving a green light after requesting it. In this case, this may lead to traffic delays. If an unapproved vehicle is able to forge these requests, they may cause larger scale traffic delays. | If the ITS RE does not receive any requests, the vehicle may not receive the priority it requested. In the worst case scenario the vehicle would be forced to wait at some lights until they turned green. It would be more useful for a device to support this application, and only have some messages received, than to not support this application at all. | |||
| Multi-Access Edge Computing | Traffic Management Center | intersection management application status | Moderate | Moderate | Low |
| This information could be of interest to a malicious individual who is attempting to determine the best way to accomplish a crime. As such it would be best to not make it easily accessible. May be LOW in some cases. | If this is compromised, it could send unnecessary maintenance workers, or worse report plausible data that is erroneous. From THEA: should be able to cope with some bad information on the status and record of alerts/warnings; aggregate info; however could cause appearance of excessive traffic violations or unnecessary maintenance caused if data is compromised (operational state, status, log); should not affect the application functionality | Incident status information should be presented in timely fashion as large scale mobility and safety issues are related. There are other mechanisms for reporting this information however, thus MODERATE. From THEA: Only limited adverse effect of info is not timely/readily available | |||
| Multi-Access Edge Computing | Transit Vehicle OBE | signal priority status | Low | Moderate | Low |
| Not much could be learned by observing this flow, just the state of the priority request and the identity of the requester. Both of those are information that can be gleaned by physical observation, and give little advantage to an observer. | Signal priority status information enables the receiving vehicle to proceed with more surety toward's its next stop; while there are obvious redundancies, a degree of confidence in the state of the message is required for user acceptance if nothing else. | The most important aspect of this flow is the initiating request and hopefull success of that priority message; if that succeeds then the signal will turn in the vehicle's favor, making this flow a 'nice-to-have' that should be correct if it arrives, but is not necessary for the priority application to function. | |||
| Traffic Management Center | ITS Roadway Equipment | signal control commands | Moderate | High | Moderate |
| Control flows, even for seemingly innocent devices, should be kept confidential to minimize attack vectors. While an individual installation may not be particularly impacted by a cyberattack of its sensor network, another installation might be severely impacted, and different installations are likely to use similar methods, so compromising one leads to compromising all. DISC: NYC believes this to be LOW: "The result of this will be directly observable." | Invalid messages could lead to an unauthorized user gaining control of an intersection. This could also be used to bring traffic to a standstill, which could lead to a large financial impact on the community. DISC: NYC believes this to be MODERATE: The signal timing is critical to the intersection operation; incorrect signal timing can lead to significant congestion and unreliable operation; while unsafe operation is controlled by the cabinet monitoring system, attackers could “freeze” the signal or call a preemption. RES: This will vary depending on the application and implementation. | These messages are important to help with preemption and signal priority applications. Without them, these applications mayl not work. However, if these signals are not received, the ITS RE will continue to function using its default configuration. The TMC should have an acknowledgement of the receipt of a message. DISC: NYC blieves this to be LOW: TMC doesn’t play an active role in this application, i.e. even if it is unavailable, it is unlikely to affect the outcome of this application one way or the other. RES: This will vary depending on the application and implementation. | |||
| Traffic Management Center | ITS Roadway Equipment | signal priority service request | Not Applicable | Moderate | Low |
| There is no sensitive or confidential information within this messages. Additionally, it could be inferred by observing either the presence of a priority-requesting vehicle near an intersection, or the effect on the timing of the intersection. This is also transmitted as a result of broadcast data. | The TMC is transmitting a request to the ITS RE on behalf of a priority-requesting vehicle. It should only be making requests on behalf of an approved vehicle. A corrupted request may lead to a vehicle not receiving a green light after requesting it. In this case, this may lead to traffic delays. If an unapproved vehicle is able to forge these requests, they may cause larger scale traffic delays. | If the ITS RE does not receive any requests, the vehicle may not receive the priority it requested. In the worst case scenario the vehicle would be forced to wait at some lights until they turned green. It would be more useful for a device to support this application, and only have some messages received, than to not support this application at all. | |||
| Traffic Management Center | Multi-Access Edge Computing | intersection management application info | Moderate | High | Low |
| Proprietary configuration data with warning parameters and thresholds. | should be accurate and not be tampered with; could enable outside control of application | This message is an indication of a potential hazard. If it isn’t received it increases the risk to other road users. If a vehicle is infringing on an intersection, it must report this. | |||
| Traffic Management Center | Transit Management Center | traffic control priority status | Not Applicable | Moderate | Moderate |
| This information is not sensitive. There are other indicators when an intersection supports transit signal priority. | This information is important for the system to function correctly. If it is incorrect, it could lead to the transit system designing routes that do not take advantage of the optimizations. | This information is necessary for the system to operate properly. There should be an acknowledgement of the message being received. | |||
| Transit Management Center | Traffic Management Center | traffic control priority request | Not Applicable | Moderate | Moderate |
| The result of this will be directly observable. | Invalid messages could lead to an unauthorized user gaining transit signal priority at an intersection. This could also be used to delay traffic, which could lead to a financial impact on the community. However, the traffic signal will have controls in place to ensure that it does not display an illegal configuration (such as green in every direction). | These messages are important to help with the transit signal priority application. Without them, it will not work. However, if these signals are not received, the ITS RE will continue to function using its default configuration. The Transit Management Center should have an acknowledgement of the receipt of a message. | |||
| Transit Management Center | Transit Operations Personnel | transit operations status | Moderate | High | High |
| Backoffice operations flows should have minimal protection from casual viewing, as otherwise imposters could gain illicit control or information that should not be generally available. | Backoffice operations flows should generally be correct and available as these are the primary interface between operators and system. | Backoffice operations flows should generally be correct and available as these are the primary interface between operators and system. | |||
| Transit Operations Personnel | Transit Management Center | transit operations personnel input | Moderate | High | High |
| Backoffice operations flows should have minimal protection from casual viewing, as otherwise imposters could gain illicit control or information that should not be generally available. | Backoffice operations flows should generally be correct and available as these are the primary interface between operators and system. | Backoffice operations flows should generally be correct and available as these are the primary interface between operators and system. | |||
| Transit Vehicle OBE | Multi-Access Edge Computing | signal priority request | Not Applicable | Moderate | Low |
| There is no sensitive or confidential information within this messages. Additionally, it could be inferred by observing either the presence of a priority-requesting vehicle near an intersection, or the effect on the timing of the intersection. This is also transmitted as a result of broadcast data. | Only specific vehicles that have been granted authorization to receive priority/preemption should be able to send this request. Allowing other vehicles to send it could negatively impact the performance of the traffic signal network, so authentication and integrity mechanisms must ensure the message cannot be forged or altered. | If the CVRSE does not receive any requests, the vehicle may not receive the priority it requested. In the worst case scenario the vehicle would be forced to wait at some lights until they turned green. It would be more useful for a device to support this application, and only have some messages received, than to not support this application at all. | |||
Standards
The following table lists the standards associated with physical objects in this service package. For standards related to interfaces, see the specific information flow triple pages. These pages can be accessed directly from the SVG diagram(s) located on the Physical tab, by clicking on each information flow line on the diagram.
| Name | Title | Physical Object |
|---|---|---|
| ITE 5201 ATC | Advanced Transportation Controller | ITS Roadway Equipment |
| ITE 5202 ATC Model 2070 | Model 2070 Controller Standard | ITS Roadway Equipment |
| ITE 5301 ATC ITS Cabinet | Intelligent Transportation System Standard Specification for Roadside Cabinets | ITS Roadway Equipment |
| ITE 5401 ATC API | Application Programming Interface Standard for the Advanced Transportation Controller | ITS Roadway Equipment |
| NEMA TS 8 Cyber and Physical Security | Cyber and Physical Security for Intelligent Transportation Systems | ITS Roadway Equipment |
| Traffic Management Center | ||
| NEMA TS2 Traffic Controller Assemblies | Traffic Controller Assemblies with NTCIP Requirements | ITS Roadway Equipment |
System Requirements
| No System Requirements |