< < PT12.2 : PT12.3 : PT13.1 > >
PT12.3: MEC Implementation
Multi-Access Edge Computing (MEC) devices in the vicinity of the station/stop are used to communicate transit vehicle presence and intention to pull into or out of a station/stop to vehicles in range and activate dynamic message signs to notify drivers of unequipped vehicles.
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 |
|---|---|---|
| Basic Transit Vehicle | Vehicle | The 'Basic Transit Vehicle' represents the transit vehicle that hosts the on-board equipment that provides ITS functions. It includes a specialized and extended databus that is subject to different vehicle databus standards and hosts a broad range of components that are unique to a transit vehicle including the farebox and associated electronics, passenger counters, and transit security systems. The Transit Vehicle may represent a bus, paratransit vehicle, light rail vehicle, or other vehicle designed to carry passengers. |
| Basic Vehicle | Vehicle | 'Basic Vehicle' represents a complete operating vehicle. It includes the vehicle platform that interfaces with and hosts ITS electronics and all of the driver convenience and entertainment systems, and other non-ITS electronics on-board the vehicle. Interfaces represent both internal on-board interfaces between ITS equipment and other vehicle systems and other passive and active external interfaces or views of the vehicle that support vehicle/traffic monitoring and management. External interfaces may also represent equipment that is carried into the vehicle (e.g., a smartphone that is brought into the vehicle). Internal interfaces are often implemented through a vehicle databus, which is also included in this object. Note that 'Vehicle' represents the general functions and interfaces that are associated with personal automobiles as well as commercial vehicles, emergency vehicles, transit vehicles, and other specialized vehicles. |
| Driver | Vehicle | The 'Driver' represents the person that operates a vehicle on the roadway. Included are operators of private, transit, commercial, and emergency vehicles where the interactions are not particular to the type of vehicle (e.g., interactions supporting vehicle safety applications). The Driver originates driver requests and receives driver information that reflects the interactions which might be useful to all drivers, regardless of vehicle classification. Information and interactions which are unique to drivers of a specific vehicle type (e.g., fleet interactions with transit, commercial, or emergency vehicle drivers) are covered by separate objects. |
| 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 |
| Personal Information Device | Personal | The 'Personal Information Device' provides the capability for travelers to receive formatted traveler information wherever they are. Capabilities include traveler information, trip planning, and route guidance. Frequently a smart phone, the Personal Information Device provides travelers with the capability to receive route planning and other personally focused transportation services from the infrastructure in the field, at home, at work, or while en-route. Personal Information Devices may operate independently or may be linked with vehicle on-board equipment. This subsystem also supports safety related services with the capability to broadcast safety messages and initiate a distress signal or request for help. |
| 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 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. |
| Transportation Information Center | Center | The 'Transportation Information Center' collects, processes, stores, and disseminates transportation information to system operators and the traveling public. The physical object can play several different roles in an integrated ITS. In one role, the TIC provides a data collection, fusing, and repackaging function, collecting information from transportation system operators and redistributing this information to other system operators in the region and other TICs. In this information redistribution role, the TIC provides a bridge between the various transportation systems that produce the information and the other TICs and their subscribers that use the information. The second role of a TIC is focused on delivery of traveler information to subscribers and the public at large. Information provided includes basic advisories, traffic and road conditions, transit schedule information, yellow pages information, ride matching information, and parking information. The TIC is commonly implemented as a website or a web-based application service, but it represents any traveler information distribution service. |
| Traveler | Personal | The 'Traveler' represents any individual who uses transportation services. The interfaces to the traveler provide general pre-trip and en-route information supporting trip planning, personal guidance, and requests for assistance in an emergency that are relevant to all transportation system users. It also represents users of a public transportation system and addresses interfaces these users have within a transit vehicle or at transit facilities such as roadside stops and transit centers. |
| Vehicle | Vehicle | This 'Vehicle' physical object is used to model core capabilities that are common to more than one type of Vehicle. It provides the vehicle-based general sensory, processing, storage, and communications functions that support efficient, safe, and convenient travel. Many of these capabilities (e.g., see the Vehicle Safety service packages) apply to all vehicle types including personal vehicles (including motorcycles), commercial vehicles, emergency vehicles, transit vehicles, and maintenance vehicles. From this perspective, the Vehicle includes the common interfaces and functions that apply to all motorized vehicles. The radio(s) supporting V2V and V2I communications are a key component of the Vehicle. Both one-way and two-way communications options support a spectrum of information services from basic broadcast to advanced personalized information services. Advanced sensors, processors, enhanced driver interfaces, and actuators complement the driver information services so that, in addition to making informed mode and route selections, the driver travels these routes in a safer and more consistent manner. This physical object supports all six levels of driving automation as defined in SAE J3016. Initial collision avoidance functions provide 'vigilant co-pilot' driver warning capabilities. More advanced functions assume limited control of the vehicle to maintain lane position and safe headways. In the most advanced implementations, this Physical Object supports full automation of all aspects of the driving task, aided by communications with other vehicles in the vicinity and in coordination with supporting infrastructure subsystems. |
Includes Functional Objects:
| Functional Object | Description | Physical Object |
|---|---|---|
| MEC Traveler Information Communications | 'MEC Traveler Information Communications' distributes information to vehicles for in-vehicle display. The information may be provided by a center (e.g., variable information on traffic and road conditions in the vicinity of the field equipment) or it may be determined and output locally (e.g., static sign information and signal phase and timing information). This includes the interface to the center or field equipment that controls the information distribution and the wireless communications equipment that provides information to vehicles. | Multi-Access Edge Computing |
| Personal Pedestrian Safety | 'Personal Pedestrian Safety' improves pedestrian, cyclist, and other vulnerable road user safety by providing personal location information to the infrastructure that can be used to avoid collisions involving vulnerable road users. It may also alert the vulnerable road user of unsafe conditions, augmenting or extending information provided by signals and signs. The information provided and the user interface delivery mechanism (visual, audible, or haptic) can also be tailored to the needs of the user that is carrying or wearing the device that hosts the application. | Personal Information Device |
| Roadway Traffic Information Dissemination | 'Roadway Traffic Information Dissemination' includes field elements that provide information to drivers, including dynamic message signs and highway advisory radios. | ITS Roadway Equipment |
| TIC Traffic Control Dissemination | 'TIC Traffic Control Dissemination' serves as intermediary between transportation operations centers (e.g., TMC, Transit MC) and transportation users (e.g., vehicles, personal devices). It collects and disseminates intersection status, lane control information, special vehicle alerts, and other traffic control related information that is real-time or near real-time in nature and relevant to vehicles in a relatively local area on the road network. It collects traffic control information from Traffic Management and other Center(s) and disseminates the relevant information to vehicles and other mobile devices. | Transportation Information Center |
| Transit Center Fixed-Route Operations | 'Transit Center Fixed-Route Operations' manages fixed route transit operations. It supports creation of schedules, blocks and runs for fixed and flexible route transit services. It allows fixed-route and flexible-route transit services to disseminate schedules and automatically updates customer service operator systems with the most current schedule information. It also supports automated dispatch of transit vehicles. Current vehicle schedule adherence and optimum scenarios for schedule adjustment are also provided. It also receives and processes transit vehicle loading data. | Transit Management Center |
| Transit Vehicle Pedestrian Safety | 'Transit Vehicle Pedestrian Safety' exchanges current location and motion information with pedestrian-carried devices in the vicinity and uses that information to warn the driver of pedestrians in the vehicle's path. Information from on-board sensors (e.g., radars and image processing) are used to augment the short range communications, if available. In addition to notifying the driver, control information can also be provided to support automated control functions that can avoid the collision. | Transit Vehicle OBE |
| Transit Vehicle V2V Safety | 'Transit Vehicle V2V Safety' exchanges current vehicle location and motion information with other vehicles in the vicinity, uses that information to predict vehicle paths, and notifies the driver when the potential for an impending collision is detected. Information from on-board sensors (e.g., radars and image processing) are used to augment the V2V communications, if available. In addition to notifying the driver, control information can also be provided to support automated control functions that can avoid the collision. This object is similar to the 'Vehicle Basic V2V Safety', but it accounts for crash scenarios that are unique to transit vehicles (e.g., Vehicle Turning Right in Front of Bus). It is also stop-aware since stop locations pose specific crash threats for transit vehicles. Finally, the detection and control algorithms, filters, and timing account for bus performance and risk profiles associated with remote vehicles that are unique to transit. | 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 Traveler Information Reception | 'Vehicle Traveler Information Reception' receives advisories, vehicle signage data, and other driver information of use to all types of vehicles and drivers and presents this information to the driver using in-vehicle equipment. Information presented may include fixed sign information, traffic control device status (e.g., signal phase and timing data), advisory and detour information, warnings of adverse road and weather conditions, travel times, and other driver information. | Vehicle |
Includes Information Flows:
| Information Flow | Description |
|---|---|
| driver input | Driver input to the vehicle on-board equipment including configuration data, settings and preferences, interactive requests, and control commands. |
| driver update information | Information provided to the driver-vehicle interface to inform the driver about current conditions, potential hazards, and the current status of vehicle on-board equipment. The flow includes the information to be presented to the driver and associated metadata that supports processing, prioritization, and presentation by the DVI as visual displays, audible information and warnings, and/or haptic feedback. |
| driver updates | Information provided to the driver including visual displays, audible information and warnings, and haptic feedback. The updates inform the driver about current conditions, potential hazards, and the current status of vehicle on-board equipment. |
| host transit vehicle status | Information provided to the ITS on-board equipment from other systems on the Transit Vehicle Platform. |
| host vehicle status | Information provided to the ITS on-board equipment from other systems on the vehicle platform. This includes the current status of the powertrain, steering, and braking systems, and status of other safety and convenience systems. In implementations where GPS is not integrated into the Vehicle On-Board Equipment, the host vehicle is also the source for data describing the vehicle's location in three dimensions (latitude, longitude, elevation) and accurate time that can be used for time synchronization across the ITS environment. |
| personal location | The current location (latitude, longitude, and elevation) reported by the personal information or safety device |
| roadway dynamic signage data | Information used to initialize, configure, and control dynamic message signs. This flow can provide message content and delivery attributes, local message store maintenance requests, control mode commands, status queries, and all other commands and associated parameters that support remote management of these devices. |
| roadway dynamic signage status | Current operating status of dynamic message signs. |
| transit stop locations | The current geographic location and dimensions of transit stops. This flow may also include the road geometry in the vicinity of the stops as needed to support transit vehicle safety applications when arriving at or departing from stops. |
| transit vehicle operator display | Visual, audible, and tactile outputs to the transit vehicle operator including vehicle surveillance information, alarm information, vehicle system status, information from the operations center, and information indicating the status of all other on-board ITS services. |
| transit vehicle operator input | Transit vehicle operator inputs to on-board ITS equipment, including tactile and verbal inputs. Includes authentication information, on-board system control, emergency requests, and fare transaction data. |
| traveler input | User input from a traveler to summon assistance, request travel information, make a reservation, or request any other traveler service. |
| traveler interface updates | Visual or audio information (e.g., routes, messages, guidance, emergency information) that is provided to the traveler. |
| vehicle location and motion | Data describing the vehicle's location in three dimensions, heading, speed, acceleration, braking status, and size. |
| vehicle path prediction | The predicted future vehicle path of travel. This flow includes an indication of the future positions of the transmitting vehicle that can be used by receiving vehicles to support coordinated driving maneuvers and enhance in-lane and out-of-lane threat classification. |
| vehicle signage data | In-vehicle signing data that augments regulatory, warning, and informational road signs and signals. The information provided would include static sign information (e.g., stop, curve warning, guide signs, service signs, and directional signs) and dynamic information (e.g., local traffic and road conditions, restrictions, vehicle requirements, work zones, detours, closures, advisories, and warnings). |
Goals and Objectives
Associated Planning Factors and Goals
| Planning Factor | Goal |
|---|
Associated Objective Categories 
| Objective Category |
|---|
Associated Objectives and Performance Measures 
| Objective | Performance Measure |
|---|
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 |
| Basic Transit Vehicle | ||||
| Basic Vehicle | ||||
| ITS Roadway Equipment | ||||
| Multi-Access Edge Computing | ||||
| Personal Information Device | ||||
| Transit Management Center | ||||
| Transit Vehicle OBE | ||||
| Transportation Information Center | ||||
| Vehicle | ||||
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 | |||
| Basic Transit Vehicle | Transit Vehicle OBE | host transit vehicle status | Moderate | Moderate | Moderate |
| This can include some sensitive data. However, other data, such as vehicle location and motion will then be broadcast. There also may be proprietary information included in this. DISC THEA believes this to be LOW: "sensor data is not confidential; harm should not come from seeing status." | This is used later on to determine whether a vehicle should request priority at an intersection. If this information is incorrect the vehicle may make false requests. All other flows that use the data from this flow have a MODERATE integrity requirement, therefore, this must also have a MODERATE integrity requirement. DISC: THEA believes this should be HIGH: "sensor data needs to be accurate and should not be tampered with." | This information would need to be available immediately for the application to work.DISC: THEA believes this should be HIGH: "sensor data must be consistently available to feed BSMs broadcast at 10Hz, notifications, etc.." | |||
| Basic Vehicle | Vehicle | host vehicle status | Low | Moderate | High |
| Unlikely that this includes any information that could be used against the originator. | This can be MODERATE or HIGH, depending on the application: This is used later on to determine whether a vehicle is likely going to violate a red light or infringe a work zone. This needs to be correct in order for the application to work correctly. | Since this monitors the health and safety of the vehicle and that information is eventually reported to the driver, it should be available at all times as it directly affects vehicle and operator safety. | |||
| Driver | Vehicle | driver input | Moderate | High | High |
| Data included in this flow may include origin and destination information, which should be protected from other's viewing as it may compromise the driver's privacy. | Commands from from the driver to the vehicle must be correct or the vehicle may behave in an unpredictable and possibly unsafe manner | Commands must always be able to be given or the driver has no control. | |||
| ITS Roadway Equipment | Multi-Access Edge Computing | roadway dynamic signage status | Moderate | Moderate | Moderate |
| Device status information should not be available, as those with criminal intent may use this information toward their own ends. | Data is intended to feed dissemination channels, either C-ITS messages or DMS or other channels, so it should generally be correct as it is distributed widely and any forgery or corrupted data will have widespread impact. | Occasional outages of this flow will delay dissemination of the data to travelers (the eventual end user) which could have significant impacts on travel, both safety and mobility impacts. | |||
| Multi-Access Edge Computing | ITS Roadway Equipment | roadway dynamic signage data | Moderate | Moderate | Moderate |
| Device control information should not be available, as those with criminal intent may use this information toward their own ends. | Data is intended to feed dissemination channels, either C-ITS messages or DMS or other channels, so it should generally be correct as it is distributed widely and any forgery or corrupted data will have widespread impact. | Occasional outages of this flow will delay dissemination of the data to travelers (the eventual end user) which could have significant impacts on travel, both safety and mobility impacts. | |||
| Multi-Access Edge Computing | Vehicle | vehicle signage data | Low | Moderate | Moderate |
| This data is intentionally transmitted to everyone via a broadcast. It is meant to augment other signage data, and by definition is meant to be shared with everyone. | These signs are meant to augment other visual cues to the driver. They should be accurate, but any inaccuracies should be corrected for by other means. | These notifications are helpful to a driver, but if the driver does not receive this notification immediately, there should still be other visual cues. | |||
| Personal Information Device | Transit Vehicle OBE | personal location | Not Applicable | High | Moderate |
| This data is intentionally transmitted to everyone via a broadcast. It can also be determined via other visual indicators. | An incorrect location message could lead to a false warning or lack of warning. A lack of warning can have obvious catastrophic consequences, while a false warning could lead to users ignoring warnings due to perceived inaccuracy. Given that this triple may apply to highly dynamic environments (such as work zones), its accuracy is paramount, and thus if sent, must have HIGH integrity. | There are other visual indicators about the geofenced areas. PID users in dynamic environments (incident and work zones) should know when they are leaving a geofenced area. As long as they remain in the geofenced area, this information is not as necessary. Not all pedestrians will carry a personal information device, and the system should be able to operate without this information. | |||
| Personal Information Device | Traveler | traveler interface updates | Not Applicable | Moderate | Moderate |
| Personalized data that includes directions and guidance for an individual, but eventually evident anyway. | Should be accurate as the Traveler will be relying on this information for routing and related choices. Lack of accuracy will result in lack of confidence from the traveler as well as an unsatisfactory trip, leading to a negative feedback spiral. | Users expect their devices to work. If information is not presented to the operator, the relevant applications simply won't be used. | |||
| Transit Management Center | Transit Vehicle OBE | transit stop locations | Low | Moderate | Moderate |
| This information is not sensitive. It is generally made public, to support transit system functionality. | This information is most necessary to support safety use cases surrounding stop locations. If this information is inaccurate or unavailable, those use cases may not function correctly, decreasing safety. | This information is most necessary to support safety use cases surrounding stop locations. If this information is inaccurate or unavailable, those use cases may not function correctly, decreasing safety. | |||
| Transit Management Center | Transportation Information Center | transit stop locations | Not Applicable | Moderate | Moderate |
| This data is broadcast and intended for general consumption. | False information here could play havoc with an individual's schedule and cause inconvenience to users of transit services that received incorrect information. | This data should be available through other means, but it will be more convenient if available. Depending on the implementation and other dissemination methods, this may be LOW. | |||
| Transit Vehicle OBE | Personal Information Device | vehicle path prediction | Not Applicable | High | Moderate |
| This is intended for broadcast. | Path prediction is intended for collision avoidance applications, which have high integrity requirements to avoid potentially catastrophic consequences. | Path prediction is intended for collision avoidance applications, which ideally would have HIGH availability requirements, but given the constraints of the wireless medium are reduced to MODERATE. | |||
| Transit Vehicle OBE | Transit Management Center | vehicle location and motion | Not Applicable | High | Moderate |
| This data is intentionally transmitted to everyone via a broadcast. Much of its information content can also be determined via other visual indicators | Incorrect information could lead to the system not operating properly. If the system does not properly know where the vehicle is, it cannot make an accurate decision about whether there is going to be a pedestrian in the crosswalk that the vehicle is approaching. This can have a safety impact. | This data is required for the system to operate properly. If this data is not available, the system cannot give accurate warning information. | |||
| Transit Vehicle OBE | Transit Management Center | vehicle path prediction | Not Applicable | High | Moderate |
| This data is intentionally transmitted to other vehicles operating in a cluster. | Path prediction is intended for collision avoidance applications, which have high integrity requirements to avoid potentially catastrophic consequences. | Path prediction is intended for collision avoidance applications, which ideally would have HIGH availability requirements, but given the constraints of the wireless medium are reduced to MODERATE. | |||
| Transit Vehicle OBE | Transit Vehicle Operator | transit vehicle operator display | Low | Moderate | Low |
| This should not include any sensitive information. It would be possible for a person standing behind the driver to observe the information transmitted. | Some minimal guarantee of data integrity is necessary for all C-ITS flows. This entire application should not directly affect the drivers driving habits. The operator should still be slowing and stopping at yellow or red lights, along with observing all other driving regulations. DISC: Original V2I analysis classified this as LOW. | Even if the operator is not made aware of the signal preemption, the system should still operate correctly. The operator should be using the traffic lights to influence their decision about whether or not to stop, not the display. | |||
| Transit Vehicle OBE | Transportation Information Center | vehicle path prediction | Not Applicable | High | Moderate |
| This data is intentionally transmitted to other vehicles operating in a cluster. | Path prediction is intended for collision avoidance applications, which have high integrity requirements to avoid potentially catastrophic consequences. | Path prediction is intended for collision avoidance applications, which ideally would have HIGH availability requirements, but given the constraints of the wireless medium are reduced to MODERATE. | |||
| Transit Vehicle Operator | Transit Vehicle OBE | transit vehicle operator input | Low | Moderate | Low |
| This information is transmitted through systems on board the Transit Vehicle. Even if the vehicle were compromised and these communications monitored, most of this information is directly observable. | Some minimal guarantee of data integrity is necessary for all C-ITS flows. If this is compromised, it could result in an incorrect signal priority request, which has minimal impact. DISC: Original V2I analysis classified this as LOW. | A delay in reporting this may result in a signal priority request not going through, which has minimal impact. | |||
| Transportation Information Center | Vehicle | vehicle signage data | Low | Moderate | Moderate |
| This data is intentionally transmitted to everyone via a broadcast. It is meant to augment other signage data, and by definition is meant to be shared with everyone. | These signs are meant to augment other visual cues to the driver. They should be accurate, but any inaccuracies should be corrected for by other means. | These notifications are helpful to a driver, but if the driver does not receive this notification immediately, there should still be other visual cues. | |||
| Traveler | Personal Information Device | traveler input | Not Applicable | Moderate | Low |
| This data is informing the vehicle of operational information that is relevant to the operation of the vehicle. It should not contain anything sensitive, and does not matter if another person can observe it. | While public, information must be correct or travelers may make incorrect decisions with regard to their travel plans. | Information is available through other means, though depending on the location this might not always be the case, in which case this would be MODERATE. | |||
| Vehicle | Basic Vehicle | driver update information | Low | Moderate | Moderate |
| This information is all presented to the vehicle operator. Encrypting this information may make it harder to reverse engineer vehicle systems, and may defeat criminal tracking tools when the vehicle has already been compromised. Unless those scenarios are of concern to the operator or manufacturer, this can safely be set LOW. | Any information presented to the operator of a vehicle should be both accurate and timely. By definition this includes safety information, but given that the driver has other means of learning about most threats, it seems difficult to justify HIGH. If HIGH is warranted, it should apply to both availability and integrity. | Any information presented to the operator of a vehicle should be both accurate and timely. By definition this includes safety information, but given that the driver has other means of learning about most threats, it seems difficult to justify HIGH. If HIGH is warranted, it should apply to both availability and integrity. | |||
| Vehicle | Driver | driver updates | Not Applicable | Moderate | Moderate |
| This data is informing the driver about the safety of a nearby area. It should not contain anything sensitive, and does not matter if another person can observe it. | This is the information that is presented to the driver. If they receive incorrect information, they may act in an unsafe manner. However, there are other indicators that would alert them to any hazards, such as an oncoming vehicle or crossing safety lights. | If this information is not made available to the driver, then the system has not operated correctly. | |||
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 |
| NEMA TS2 Traffic Controller Assemblies | Traffic Controller Assemblies with NTCIP Requirements | ITS Roadway Equipment |
| NEMA TS4 Hardware Standards for DMS | Hardware Standards for Dynamic Message Signs (DMS) With NTCIP Requirements | ITS Roadway Equipment |
System Requirements
| No System Requirements |