Type: Mobility
Groups:- Public Safety
Advanced Automatic Crash Notification Relay
The Advanced Automatic Crash Notification Relay application (which was previously called Mayday Request) provides the capability for a vehicle to automatically transmit an emergency message when the vehicle has been involved in a crash or other distress situation. An automatic crash notification feature transmits key data on the crash recorded by sensors mounted in the vehicle (e.g. deployment of airbags) without the need for involvement of the driver. The emergency message is broadcast to passing connected vehicles, who can relay the message to other connected vehicles as well as roadside "hotspots." Once received by emergency response services (either through emergency vehicles or through the roadside equipment), the appropriate response to the vehicle situation can be carried out by emergency response services. This application allows a vehicle to forward mayday requests even in areas where no V2I infrastructure exists.
Enterprise
This is one way this application may be realized, but not the only way. There are other ways to build a given application and accomplish a stated objective.
The enterprise diagram can be viewed in SVG or PNG format and the current format is SVG. SVG Diagrams: Installation Operations Maintenance Certification
PNG Diagrams: Installation Operations Maintenance Certification
Business Interaction Matrix:
| Advanced Automatic Crash Notification Relay Operations Stage | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Vehicle Owner | Driver | Vehicle OBE Owner | Roadway Owner | RSE Owner | RSE Operator | Emergency Fleet Manager | Remote Vehicle OBE Owner | Emergency Manager | RSE Emergency Notification Support Provider | Other Emergency Manager | Emergency System Operator | Emergency Response Personnel | EV On-Board En Route Support Provider | Vehicle Emergency Notification I/F Provider | |
| Vehicle Owner | Vehicle Usage Agreement | Vehicle OBE Usage Agreement | Application Usage Agreement | ||||||||||||
| Driver | Vehicle Usage Agreement | Expectation of Information Provision | Presumption of Correct Operation | Expectation of Action | |||||||||||
| Vehicle OBE Owner | Vehicle OBE Usage Agreement | Expectation of Information Provision | Expectation of Data Provision | Information Exchange Agreement | |||||||||||
| Roadway Owner | Service Delivery Agreement | ||||||||||||||
| RSE Owner | Service Delivery Agreement | Operations Agreement | Information Exchange Agreement | Application Usage Agreement | |||||||||||
| RSE Operator | Operations Agreement | ||||||||||||||
| Emergency Fleet Manager | Vehicle Usage Agreement | Application Usage Agreement | |||||||||||||
| Remote Vehicle OBE Owner | Presumption of Correct Operation | Expectation of Data Provision | |||||||||||||
| Emergency Manager | Information Exchange Agreement | Information Exchange Agreement | Information Exchange Agreement | Employment Agreement | |||||||||||
| RSE Emergency Notification Support Provider | Application Usage Agreement | ||||||||||||||
| Other Emergency Manager | Information Exchange Agreement | ||||||||||||||
| Emergency System Operator | Employment Agreement | ||||||||||||||
| Emergency Response Personnel | Expectation of Action | Vehicle Usage Agreement | |||||||||||||
| EV On-Board En Route Support Provider | Application Usage Agreement | ||||||||||||||
| Vehicle Emergency Notification I/F Provider | Application Usage Agreement | ||||||||||||||
Includes Enterprise Objects:
| Enterprise Object | Description |
|---|---|
| Application Certification Entity | The body that determines whether an application may be deployed and operated in the Connected Vehicle Environment. This entity's composition, the requirements it applies and the procedures it uses to verify those requirements may vary with application type. For example, applications with human safety component (crash avoidance, movement assistance etc.) may have stringent requirements and extensive testing in a variety of conditions, while applications that provide strictly mobility functionality may have far less testing requirements; possibly as little as just making sure the application doesn't interfere with any other applications. |
| Commercial Vehicle Administrator | The organization responsible for the administration functions performed by the Commercial Vehicle Administration Center. |
| Commercial Vehicle Manufacturer | The entity which builds commercial vehicles, including long haul trucks and local pick up and delivery vehicles. This entity is complementary to the Vehicle Manufacturer entity in that it represents those aspects of vehicle manufacture which are unique to commercial vehicles. |
| Commercial Vehicle OBE Manufacturer | The Commercial Vehicle OBE Manufacturer is the provider of the commercial vehicle on-board equipment. This entity may design and build the OBE, or may integrate other components to form the OBE, or may use some combination of approaches to provide the on-board equipment. Since the OBE could be aftermarket, retrofit, built-in or nomadic, this entity is the one that builds whatever that-is. In some cases it may be a smart phone manufacturer, or in others a top tier parts supplier, or any other entity in the production chain, depending on the device and commercial vehicle in question. |
| Commercial Vehicle Owner | The entity that owns the commercial vehicle. This entity is complementary to the Vehicle Owner in that it represents those aspects of ownership which are unique to commercial vehicles. |
| CV On-Board Cargo Monitoring Installer | Application Component Installers are specified more by role than by function. Installers are responsible for the installation of the application component, which may require a support system, and may entail agreements and relationships between end users and application providers. |
| CV On-Board Cargo Monitoring Maintainer | Application Component Maintainers are specified more by role than by function. Maintainers are responsible for the maintenance (configuration changes, patches and updates, hardware repairs) of the application component, which may require a support system, and may entail agreements and relationships between end users and application providers. |
| CV On-Board Cargo Monitoring Provider | Application Component Providers are specified more by role than by function. Providers are responsible for the development of the application component, including initial creation, enhancement and bug fixes. Delivery of the application to the end user may require relationships with other entities (installers, maintainers) if the provider chooses not to fulfill those roles. |
| Device Certification Entity | The body that determines whether a device may be deployed and operated in the Connected Vehicle Environment. This entity's composition, the requirements it applies and the procedures it uses to verify those requirements may vary with device type. |
| Driver | 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. |
| Emergency Call-Taking Installer | Application Component Installers are specified more by role than by function. Installers are responsible for the installation of the application component, which may require a support system, and may entail agreements and relationships between end users and application providers. |
| Emergency Call-Taking Maintainer | Application Component Maintainers are specified more by role than by function. Maintainers are responsible for the maintenance (configuration changes, patches and updates, hardware repairs) of the application component, which may require a support system, and may entail agreements and relationships between end users and application providers. |
| Emergency Call-Taking Provider | Application Component Providers are specified more by role than by function. Providers are responsible for the development of the application component, including initial creation, enhancement and bug fixes. Delivery of the application to the end user may require relationships with other entities (installers, maintainers) if the provider chooses not to fulfill those roles. |
| Emergency Fleet Manager | The entity that controls emergency vehicles and provides them for use in incident response. |
| Emergency Manager | The "Emergency Manager" represents agencies charged with incident management, disaster response, and transportation environment security. |
| Emergency Notification Support Installer | Application Component Installers are specified more by role than by function. Installers are responsible for the installation of the application component, which may require a support system, and may entail agreements and relationships between end users and application providers. |
| Emergency Notification Support Maintainer | Application Component Maintainers are specified more by role than by function. Maintainers are responsible for the maintenance (configuration changes, patches and updates, hardware repairs) of the application component, which may require a support system, and may entail agreements and relationships between end users and application providers. |
| Emergency Notification Support Provider | Application Component Providers are specified more by role than by function. Providers are responsible for the development of the application component, including initial creation, enhancement and bug fixes. Delivery of the application to the end user may require relationships with other entities (installers, maintainers) if the provider chooses not to fulfill those roles. |
| Emergency Response Personnel | "Emergency Personnel" represents personnel that are responsible for police, fire, emergency medical services, towing, service patrols, and other special response team (e.g., hazardous material clean-up) activities at an incident site. These personnel are associated with the Emergency Vehicle during dispatch to the incident site, but often work independently of the Emergency Vehicle while providing their incident response services. Emergency personnel may include an Officer in Charge (OIC) and a crew. When managing an incident following standard Incident Command System practices, the on-site emergency personnel form an organizational structure under the auspices of an Incident Commander. |
| Emergency System Operator | 'Emergency System Operator' represents the human entity that monitors all ITS emergency requests, (including those from the E911 Operator) and sets up pre-defined responses to be executed by an emergency management system. The operator may also override predefined responses where it is observed that they are not achieving the desired result. This also includes dispatchers who manage an emergency fleet (police, fire, ambulance, HAZMAT, etc.) or higher order emergency managers who provide response coordination during emergencies. |
| Emergency Vehicle Manufacturer | The entity that builds, assembles, verifies and validates the Emergency Vehicle in which the Emergency Vehicle OBE will eventually operate. |
| Emergency Vehicle OBE Manufacturer | The entity that builds, assembles, verifies and validates the Emergency Vehicle OBE. This can be an OEM-equipped OBE, retrofit or aftermarket equipment. |
| EV On-Board En Route Support Installer | Application Component Installers are specified more by role than by function. Installers are responsible for the installation of the application component, which may require a support system, and may entail agreements and relationships between end users and application providers. |
| EV On-Board En Route Support Maintainer | Application Component Maintainers are specified more by role than by function. Maintainers are responsible for the maintenance (configuration changes, patches and updates, hardware repairs) of the application component, which may require a support system, and may entail agreements and relationships between end users and application providers. |
| EV On-Board En Route Support Provider | Application Component Providers are specified more by role than by function. Providers are responsible for the development of the application component, including initial creation, enhancement and bug fixes. Delivery of the application to the end user may require relationships with other entities (installers, maintainers) if the provider chooses not to fulfill those roles. |
| Federal Regulatory | Federal regulatory bodies that have legal authority to control and/or provide input to policies regulating transportation infrastructure and operations. This includes entities such as the Federal Communications Commission and US Department of Transportation. |
| Other Emergency Manager | Representing another Emergency Manager, "Other Emergency Manager" provides the source and destination for agreements and expectations between Emergency Managers, enabling emergency management activities to be coordinated across jurisdictional boundaries. |
| Remote Vehicle OBE Owner | The owner of the Remote Vehicle OBE |
| Roadway Owner | The owner of the roadway proximate to which roadside equipment will be/is installed. |
| RSE Deployer | The entity responsible for the deployment, operations and maintenance of roadside equipment. |
| RSE Emergency Notification Support Installer | Application Component Installers are specified more by role than by function. Installers are responsible for the installation of the application component, which may require a support system, and may entail agreements and relationships between end users and application providers. |
| RSE Emergency Notification Support Maintainer | Application Component Maintainers are specified more by role than by function. Maintainers are responsible for the maintenance (configuration changes, patches and updates, hardware repairs) of the application component, which may require a support system, and may entail agreements and relationships between end users and application providers. |
| RSE Emergency Notification Support Provider | Application Component Providers are specified more by role than by function. Providers are responsible for the development of the application component, including initial creation, enhancement and bug fixes. Delivery of the application to the end user may require relationships with other entities (installers, maintainers) if the provider chooses not to fulfill those roles. |
| RSE Operator | The entity that operates roadside equipment in the transportation environment. |
| RSE Owner | The owner of roadside equipment. |
| RSE Provider | The "RSE Provider" is the entity that develops and (presumably) sells roadside equipment to other entities for deployment and research. |
| State Regulatory | State regulatory bodies that have legal authority to control and/or provide input to policies regulating vehicles, transportation infrastructure and operations. This includes entities like Departments of Motor Vehicles, property tax authorities and tolling agencies. |
| Transit Fleet Manager | The agency or organization that operates transit vehicles. This includes administration, routing, driver instruction, maintenance and any other responsibilities associated with the operations and maintenance of a transit system. |
| Transit Vehicle Manufacturer | The entity which builds transit vehicles. This entity is complementary to the Vehicle Manufacturer entity in that it represents those aspects of vehicle manufacture which are unique to transit vehicles. |
| Transit Vehicle OBE Manufacturer | The Transit Vehicle OBE Manufacturer is the provider of the transit vehicle on-board equipment. This entity may design and build the OBE, or may integrate other components to form the OBE, or may use some combination of approaches to provide the on-board equipment. Since the OBE could be aftermarket, retrofit, built-in or nomadic, this entity is the one that builds whatever that-is. In some cases it may be a smart phone manufacturer, or in others a top tier parts supplier, or any other entity in the production chain, depending on the device and commercial vehicle in question. |
| Transit Vehicle Passenger Counting Installer | Application Component Installers are specified more by role than by function. Installers are responsible for the installation of the application component, which may require a support system, and may entail agreements and relationships between end users and application providers. |
| Transit Vehicle Passenger Counting Maintainer | Application Component Maintainers are specified more by role than by function. Maintainers are responsible for the maintenance (configuration changes, patches and updates, hardware repairs) of the application component, which may require a support system, and may entail agreements and relationships between end users and application providers. |
| Transit Vehicle Passenger Counting Provider | Application Component Providers are specified more by role than by function. Providers are responsible for the development of the application component, including initial creation, enhancement and bug fixes. Delivery of the application to the end user may require relationships with other entities (installers, maintainers) if the provider chooses not to fulfill those roles. |
| Vehicle Emergency Notification I/F Installer | Application Component Installers are specified more by role than by function. Installers are responsible for the installation of the application component, which may require a support system, and may entail agreements and relationships between end users and application providers. |
| Vehicle Emergency Notification I/F Maintainer | Application Component Maintainers are specified more by role than by function. Maintainers are responsible for the maintenance (configuration changes, patches and updates, hardware repairs) of the application component, which may require a support system, and may entail agreements and relationships between end users and application providers. |
| Vehicle Emergency Notification I/F Provider | Application Component Providers are specified more by role than by function. Providers are responsible for the development of the application component, including initial creation, enhancement and bug fixes. Delivery of the application to the end user may require relationships with other entities (installers, maintainers) if the provider chooses not to fulfill those roles. |
| Vehicle Manufacturer | The entity that builds, assembles, verifies and validates the Vehicle in which the Vehicle OBE will eventually operate. |
| Vehicle OBE Manufacturer | The entity that builds, assembles, verifies and validates the Vehicle OBE. This can be an OEM-equipped OBE, retrofit or aftermarket equipment. |
| Vehicle OBE Owner | The entity, individual, group or corporation that owns the Vehicle On-Board equipment. This could be the same as the Vehicle Owner, but it could be a third part that licenses the use of the OBE to the Owner. |
| Vehicle Owner | The individual, group of individuals or corporate entity that is identified as the registered owner of the Vehicle under state law. |
Includes Resources:
| Resource | Description |
|---|---|
| Application Component Certification Requirements | The requirements that define the functionality, performance and operational environment of an application component. Certification Requirements must be met in order for an application to be installed in the CVE. |
| Backoffice Service Development System | The systems used to develop backoffice (center) hardware and software components of applications. |
| Backoffice Service Installation System | The systems used to install and configure backoffice (center) hardware and software components. |
| Backoffice Service Maintenance System | The systems used to maintain and upgrade backoffice (center) hardware and software components. |
| Commercial Vehicle | The commercial vehicle includes the sensory, processing, storage, and communications functions necessary to support safe and efficient commercial vehicle operations. It includes two-way communications between the commercial vehicle drivers, their fleet managers, attached freight equipment, and roadside officials, and provides HAZMAT response teams with timely and accurate cargo contents information after a vehicle incident. It can collect and process vehicle, cargo information from the attached freight equipment, and driver safety data and status and alert the driver whenever there is a potential safety or security problem. Basic identification, security and safety status data are supplied to inspection facilities at mainline speeds. In addition, it can automatically collect and record mileage, fuel usage, and border crossings. |
| Commercial Vehicle OBE | The Commercial Vehicle On-Board Equipment (OBE) resides in a commercial vehicle and provides the sensory, processing, storage, and communications functions necessary to support safe and efficient commercial vehicle operations. It provides two-way communications between the commercial vehicle drivers, their fleet managers, attached freight equipment, and roadside officials. In CVRIA, a separate 'Vehicle OBE' physical object supports the general V2V and V2I safety applications and other applications that apply to all vehicles, including commercial vehicles. The Commercial Vehicle OBE supplements these general capabilities with capabilities that are specific to commercial vehicles. |
| CV On-Board Cargo Monitoring | "CV On-Board Cargo Monitoring" monitors the location and status of the commercial vehicle and its cargo. It sends the collected data to appropriate centers and roadside facilities, including emergency management in the case of HAZMAT incidents. Depending on the nature of the cargo, it may include sensors that measure temperature, pressure, load leveling, acceleration, and other attributes of the cargo. |
| Device Certification Requirements | The requirements that define the functionality, performance and operational environment of a connected vehicle device. Certification Requirements must be met in order for the device to be granted the credentials necessary to operate in the Connected Vehicle Environment. |
| Emergency Call-Taking | "Emergency Call-Taking" supports the emergency call-taker, collecting available information about the caller and the reported emergency, and forwarding this information to other objects that formulate and manage the emergency response. It receives 9-1-1, 7-digit local access, and motorist call-box calls and interfaces to other agencies to assist in the verification and assessment of the emergency and to forward the emergency information to the appropriate response agency. |
| Emergency Management Center | The 'Emergency Management Center' represents systems that support incident management, disaster response and evacuation, security monitoring, and other security and public safety-oriented ITS applications. It includes the functions associated with fixed and mobile public safety communications centers including public safety call taker and dispatch centers operated by police (including transit police), fire, and emergency medical services. It includes the functions associated with Emergency Operations Centers that are activated at local, regional, state, and federal levels for emergencies and the portable and transportable systems that support Incident Command System operations at an incident. This Center also represents systems associated with towing and recovery, freeway service patrols, HAZMAT response teams, and mayday service providers. It manages sensor and surveillance equipment used to enhance transportation security of the roadway infrastructure (including bridges, tunnels, interchanges, and other key roadway segments) and the public transportation system (including transit vehicles, public areas such as transit stops and stations, facilities such as transit yards, and transit infrastructure such as rail, bridges, tunnels, or bus guideways). It provides security/surveillance services to improve traveler security in public areas not a part of the public transportation system. It monitors alerts, advisories, and other threat information and prepares for and responds to identified emergencies. It coordinates emergency response involving multiple agencies with peer centers. It stores, coordinates, and utilizes emergency response and evacuation plans to facilitate this coordinated response. Emergency situation information including damage assessments, response status, evacuation information, and resource information are shared The Emergency Management Center also provides a focal point for coordination of the emergency and evacuation information that is provided to the traveling public, including wide-area alerts when immediate public notification is warranted. It tracks and manages emergency vehicle fleets using real-time road network status and routing information from the other centers to aid in selecting the emergency vehicle(s) and routes, and works with other relevant centers to tailor traffic control to support emergency vehicle ingress and egress, implementation of special traffic restrictions and closures, evacuation traffic control plans, and other special strategies that adapt the transportation system to better meet the unique demands of an emergency. |
| Emergency Notification Support | "Emergency Notification Support" receives emergency notification messages from vehicles or personal handheld devices, determines an appropriate response, and either uses internal resources or contacts a local agency to provide that response. The nature of the emergency is determined based on the information in the received message as well as other inputs. This object effectively serves as an interface between automated collision notification systems and the local public safety answering point for messages that require a public safety response. This capability depends on an up-to-date registry of public safety answering points/response agencies by coverage area, the type of emergency, and hours of service. |
| Emergency Vehicle | The "Emergency Vehicle" represents a range of vehicles including those operated by police, fire, and emergency medical services, as well as incident response vehicles including towing and recovery vehicles and freeway service patrols. |
| Emergency Vehicle OBE | The Emergency Vehicle On-Board Equipment (OBE) resides in an emergency vehicle and provides the processing, storage, and communications functions that support public safety-related connected vehicle applications. It represents a range of vehicles including those operated by police, fire, and emergency medical services. In addition, it represents other incident response vehicles including towing and recovery vehicles and freeway service patrols. It includes two-way communications to support coordinated response to emergencies. In CVRIA, a separate 'Vehicle OBE' physical object supports the general V2V and V2I safety applications and other applications that apply to all vehicles, including emergency vehicles. The Emergency Vehicle OBE supplements these general capabilities with capabilities that are specific to emergency vehicles. |
| EV On-Board En Route Support | "EV On-board En Route Support" provides communications functions to responding emergency vehicles that reduce response times and improve safety of responding public safety personnel and the general public. It supports traffic signal preemption via short range communication directly with signal control equipment and sends alert messages to surrounding vehicles. |
| Field Component Development System | The system used in a backoffice environment to develop and test the field component of the application. |
| Field Component Installation System | The system used to install a field component of a connected vehicle application. |
| Field Component Maintenance System | The system used to install and configure changes and updates to the field component of the application. This system is capable of acquiring and reporting diagnostic information about the application's configuration and performance. |
| Mobile Component Development System | The system used in a backoffice environment to develop and test the mobile component of the application. |
| Mobile Component Installation System | The system that interacts with the Vehicle OBE other mobile device and installs the mobile component of the application. |
| Mobile Component Maintenance System | The system used to configure changes and updates to the mobile component of the application. This system is capable of acquiring and reporting diagnostic information about the application's configuration and performance. |
| Other Emergency Management Centers | 'Other Emergency Management Centers' provides a source and destination for information flows between various communications centers operated by public safety agencies, emergency management agencies, other allied agencies, and private companies that participate in coordinated management of transportation-related incidents, including disasters. The interface represented by this object enables emergency management activities to be coordinated across jurisdictional boundaries and between functional areas, supporting requirements for general networks connecting many allied agencies. It also supports interface to other allied agencies like utility companies that also participate in the coordinated response to selected highway-related incidents. |
| Remote Vehicle OBEs | 'Remote Vehicle OBEs' represents other connected vehicles that are communicating with the host vehicle. This includes all connected motorized vehicles including passenger cars, trucks, and motorcycles and specialty vehicles (e.g., maintenance vehicles, transit vehicles) that also include the basic 'Vehicle OBE' functionality that supports V2V communications. In CVRIA, this object provides a source and destination for information transfers between connected vehicles. The host vehicle on-board equipment, represented by the Vehicle OBE physical object, sends information to, and receives information from the Remote Vehicle OBEs to model all connected vehicle V2V communications in CVRIA. |
| Roadside Equipment | 'Roadside Equipment' (RSE) represents the Connected Vehicle roadside devices that are used to send messages to, and receive messages from, nearby vehicles using Dedicated Short Range Communications (DSRC) or other alternative wireless communications technologies. Communications with adjacent field equipment and back office centers that monitor and control the RSE are also supported. This device operates from a fixed position and may be permanently deployed or a portable device that is located temporarily in the vicinity of a traffic incident, road construction, or a special event. It includes a processor, data storage, and communications capabilities that support secure communications with passing vehicles, other field equipment, and centers. |
| RSE Development System | The system used in a backoffice environment to develop and test the roadside equipment. |
| RSE Emergency Notification Support | "RSE Emergency Notification Support" receives emergency notification messages, determines if the message has been previously received, and forwards unique messages to the back office center of the designated responding agency. |
| RSE Installation System | The system used to install and configure the roadside equipment. |
| RSE Maintenance System | The system used to configure changes and updates to the roadside equipment. This system is capable of acquiring and reporting diagnostic information about the RSE's configuration and performance. |
| Transit Vehicle | The vehicle that provides the sensory, processing, storage, and communications functions necessary to support safe and efficient movement of passengers. This includes buses, paratransit vehicles, light rail vehicles, other vehicles designed to carry passengers, and supervisory vehicles. |
| Transit Vehicle OBE | 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. In CVRIA, a separate 'Vehicle OBE' physical object supports the general V2V and V2I safety applications and other applications 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 Passenger Counting | "Transit Vehicle Passenger Counting" collects transit vehicle loading data and makes it available to the center. |
| Vehicle | The conveyance that provides the sensory, processing, storage, and communications functions necessary to support efficient, safe, and convenient travel. These functions reside in general vehicles including personal automobiles, commercial vehicles, emergency vehicles, transit vehicles, or other vehicle types. |
| Vehicle Databus | The 'Vehicle Databus' represents the interface to the vehicle databus (e.g., CAN, LIN, Ethernet/IP, FlexRay, and MOST) that may enable communication between the Vehicle OBE and other vehicle systems to support connected vehicle applications. The vehicle system statuses and/or sensor outputs available on the databus will vary based on the equipment installed on the vehicle and availability on databus. System statuses and sensor outputs may include select vehicle systems and sensors such as accelerometers, yaw rate sensors, and GPS derived location and timing information. In CVRIA, this physical object is used to represent the onboard interactions between the Vehicle OBE and the other systems included in a host vehicle. Note that the vehicle databus interface is not standardized across all vehicle classes. Also, some Vehicle OBE implementations will not have access to the vehicle databus. See 'Vehicle OBE' for more information. |
| Vehicle Emergency Notification I/F | "Vehicle Emergency Notification I/F" provides the capability for drivers or collision detection sensors to report an emergency and summon assistance. It includes the on-board collision detection sensors, a mechanism for the driver to summon assistance, and two-way communications. |
| Vehicle OBE | The Vehicle On-Board Equipment (OBE) provides the vehicle-based processing, storage, and communications functions necessary to support connected vehicle operations. The radio(s) supporting V2V and V2I communications are a key component of the Vehicle OBE. This communication platform is augmented with processing and data storage capability that supports the connected vehicle applications. In CVRIA, the Vehicle OBE includes the functions and interfaces that support connected vehicle applications for passenger cars, trucks, and motorcycles. Many of these applications (e.g., V2V Safety applications) apply to all vehicle types including personal vehicles, commercial vehicles, emergency vehicles, transit vehicles, and maintenance vehicles. From this perspective, the Vehicle OBE includes the common interfaces and functions that apply to all motorized vehicles. |
Includes Roles:
| Role | Description |
|---|---|
| Certifies | An Enterprise verifies that a target Resource meets relevant performance, functional, environmental and quality requirements. |
| Constrains | A Resource or Enterprise applies requirements, constraints and associated tests to another Resource. |
| Installs | An Enterprise performs the initial delivery, integration and configuration of the target Resource. |
| Maintains | An Enterprise administers the hardware and software that comprise the target Resource. |
| Member | An Enterprise is part of another larger, target Enterprise. |
| Operates | An Enterprise controls the functionality and state of the target Resource. An Enterprise that Operates a resource is considered Responsible. |
| Owns | An Enterprise has financial ownership and control over the Resource. An Enterprise that Owns a resource is considered Accountable. |
Includes Coordination:
| Coordination | Type | Description |
|---|---|---|
| Application Installation Data | Information Sharing | Data needed to install the application, including the application executable code and any configuration data. Unidirectional flow. |
| Application Interface Specification | Agreement | The definition of an interface between two application components that operate on two distinct pieces of hardware. The Application Interface Specification is specific to the application in question. |
| Application Maintenance Data | Information Sharing | Data used to facilitate the upgrade, patching and general health maintenance of an application component. |
| Application Performance Data | Information Sharing | Data used to characterize application performance, including such measures as availability, known errors and known uses. |
| Application Procurement Agreement | Agreement | An agreement whereupon one entity provides a copy of an application component to another entity. This component is capable of being installed and functioning, according to its requirements that passed through the application's certification process. |
| Application Usage Agreement | Agreement | An agreement in which one entity that controls an application component's use gives the other entity the necessary tools and permission to operate that application or application component. |
| Backoffice Component Installation Agreement | Agreement | An agreement that grants one party permission to install a backoffice application component on a center-based device controlled by the other party. |
| Backoffice Component Maintenance Agreement | Agreement | An agreement in which one entity maintains the operational status of the backoffice component of an application under the control of another entity. This maintenance may include routine and as-needed maintenance, such as software update and configuration, hardware replacement and related system administration activities. |
| Device Placement and Operations Agreement | Agreement | An agreement that enables the controller of a physical device to install it (so as to make it operational) at a fixed location controlled by another entity. |
| Employment Agreement | Agreement | An agreement between an individual and a corporation or government entity, whereupon the individual agrees to provide labor to the corporation/agency, which in turn compensates the employee. Stipulates level of compensation, working conditions, necessary equipment and training and expectations of employee performance. |
| Expectation of Action | Expectation | An expectation where one party expects another party to take a specific action, typically in response to data or information provided by the first party, but without any formal agreement. |
| Expectation of Data Provision | Expectation | An expectation where one party believes another party will provide data on a regular and recurring basis, and that that data will be useful to the receiver in the context of the receiver's application. This thus includes some expectation of data fields, timeliness, quality, precision and similar qualities of data. |
| Expectation of Information Provision | Expectation | An expectation where one party believes another party will provide it information whenever such information is likely relevant to the recipient. |
| Extends | Includes | Indicates that one component includes all of the functionality of another component, and in provides additional functionality beyond that other component's. |
| Field Component Installation Agreement | Agreement | An agreement that grants one party permission to install a field application component on a roadside device controlled by the other party. |
| Field Component Maintenance Agreement | Agreement | An agreement in which one entity maintains the operational status of the field component of an application under the control of another entity. This maintenance may include routine and as-needed maintenance, such as software update and configuration, hardware replacement and related system administration activities. |
| Includes | Includes | Indicates that one component is entirely contained within another component. |
| Information Exchange Agreement | Agreement | An agreement to exchange information, which may include data or control information; the exact information to be exchanged may vary from agreement to agreement. |
| Interface Description | Agreement | Documentation of the interface between two systems, where one system does not have an application component that is part of the application, but does provide and/or receive data and/or information that is used by or sourced from the application. In many cases this is an existing interface used by the application, so the description of the interface already exists and is imposed by the terminator. |
| Maintenance Data Exchange Agreement | Agreement | An agreement that states one entity will provide data related to maintenance of an application component to the other entity. |
| Mobile Component Installation Agreement | Agreement | An agreement whereupon the controller of OBE gives another party permission to install, configure and make operational a component that enables the mobile portion of an application. |
| Mobile Component License Agreement | Agreement | An end-user license agreement allowing the operator of the mobile device to use the mobile application component that is part of the application in question. |
| Mobile Component Maintenance Agreement | Agreement | An agreement in which one entity maintains the operational status of the mobile component of an application under the control of another entity. This maintenance may include routine and as-needed maintenance, such as software update and configuration, hardware replacement and related system administration activities. |
| Operations Agreement | Agreement | An agreement where one entity agrees to operate a device or application on behalf of another, device/application controlling entity. |
| Presumption of Correct Operation | Expectation | The assumption made by one party that another party operates their device in a similar and correct fashion. Specific to devices in the transportation environment, this assumption is relevant when devices interact, where one party's device receives information from another's. The operator of the device implicitly trusts that the other device is operating according to a similar set of governing rules as its device. |
| RSE Deployment Agreement | Agreement | Agreement to install, configure and make operational roadside equipment, between the provider of that equipment and the entity that controls access to the roadside. May define locations, expectation of power provision, backhaul responsibility and installation restrictions. |
| RSE Installation Data | Information Sharing | Data necessary to configure and make RSE operational. Uni-directional. |
| RSE Maintenance Data | Information Sharing | Data necessary to modify the operational configuration of RSE; assumes RSE is already configured. Uni-directional. |
| RSE Performance Data | Information Sharing | Data that includes metrics of RSE performance. Could include fields such as uptime, packets received/transmitted, distance vector from which packets received, as well as application-specific performance measures. |
| RSE Procurement Agreement | Agreement | An agreement whereupon one entity provides roadside equipment to another entity. The RSE is capable of being installed and functioning, according to its requirements that passed through the device's certification process. |
| Service Delivery Agreement | Agreement | A relationship where one party agrees to provide a service to the other party. This agreement may specify the expected performance of this service in terms of availability and/or actions/time-type performance specifications. |
| Vehicle Data Access Agreement | Agreement | An agreement whereby the party that controls access to on-board vehicle data grants another party the right and ability to access that data. Includes the conditions under which data may be accessed, and specifies the mechanisms, including physical and functional access methods, data formats and any other considerations necessary for the accessing party to acquire data. May also include caveats regarding responsibility for data quality and responsibility for use of the data. |
| Vehicle OBE Usage Agreement | Agreement | An agreement that grants one entity permission to use a Vehicle OBE that the other party controls. |
| Vehicle Procurement Agreement | Agreement | The exchange of a vehicle for compensation. One entity purchases the vehicle from the other. |
| Vehicle Usage Agreement | Agreement | An agreement between the owner of a vehicle and a prospective operator, whereupon the owner allows the operator to use the vehicle. |
| Warranty | Agreement | A guarantee or promise made by one entity to another, that provides assurance of the functionality and performance over time of an application component. |
Functional
Includes Processes:
Includes Data Flows:
Physical
This is one way this application may be realized, but not the only way. There are other ways to build a given application and accomplish a stated objective.
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 |
|---|---|---|
| Commercial Vehicle OBE | Vehicle | The Commercial Vehicle On-Board Equipment (OBE) resides in a commercial vehicle and provides the sensory, processing, storage, and communications functions necessary to support safe and efficient commercial vehicle operations. It provides two-way communications between the commercial vehicle drivers, their fleet managers, attached freight equipment, and roadside officials. In CVRIA, a separate 'Vehicle OBE' physical object supports the general V2V and V2I safety applications and other applications that apply to all vehicles, including commercial vehicles. The Commercial Vehicle OBE supplements these general capabilities with capabilities that are specific to commercial 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. |
| Emergency Management Center | Center | The 'Emergency Management Center' represents systems that support incident management, disaster response and evacuation, security monitoring, and other security and public safety-oriented ITS applications. It includes the functions associated with fixed and mobile public safety communications centers including public safety call taker and dispatch centers operated by police (including transit police), fire, and emergency medical services. It includes the functions associated with Emergency Operations Centers that are activated at local, regional, state, and federal levels for emergencies and the portable and transportable systems that support Incident Command System operations at an incident. This Center also represents systems associated with towing and recovery, freeway service patrols, HAZMAT response teams, and mayday service providers. It manages sensor and surveillance equipment used to enhance transportation security of the roadway infrastructure (including bridges, tunnels, interchanges, and other key roadway segments) and the public transportation system (including transit vehicles, public areas such as transit stops and stations, facilities such as transit yards, and transit infrastructure such as rail, bridges, tunnels, or bus guideways). It provides security/surveillance services to improve traveler security in public areas not a part of the public transportation system. It monitors alerts, advisories, and other threat information and prepares for and responds to identified emergencies. It coordinates emergency response involving multiple agencies with peer centers. It stores, coordinates, and utilizes emergency response and evacuation plans to facilitate this coordinated response. Emergency situation information including damage assessments, response status, evacuation information, and resource information are shared The Emergency Management Center also provides a focal point for coordination of the emergency and evacuation information that is provided to the traveling public, including wide-area alerts when immediate public notification is warranted. It tracks and manages emergency vehicle fleets using real-time road network status and routing information from the other centers to aid in selecting the emergency vehicle(s) and routes, and works with other relevant centers to tailor traffic control to support emergency vehicle ingress and egress, implementation of special traffic restrictions and closures, evacuation traffic control plans, and other special strategies that adapt the transportation system to better meet the unique demands of an emergency. |
| Emergency System Operator | Center | 'Emergency System Operator' represents the human entity that monitors all ITS emergency requests, (including those from the E911 Operator) and sets up pre-defined responses to be executed by an emergency management system. The operator may also override predefined responses where it is observed that they are not achieving the desired result. This also includes dispatchers who manage an emergency fleet (police, fire, ambulance, HAZMAT, etc.) or higher order emergency managers who provide response coordination during emergencies. |
| Emergency Vehicle OBE | Vehicle | The Emergency Vehicle On-Board Equipment (OBE) resides in an emergency vehicle and provides the processing, storage, and communications functions that support public safety-related connected vehicle applications. It represents a range of vehicles including those operated by police, fire, and emergency medical services. In addition, it represents other incident response vehicles including towing and recovery vehicles and freeway service patrols. It includes two-way communications to support coordinated response to emergencies. In CVRIA, a separate 'Vehicle OBE' physical object supports the general V2V and V2I safety applications and other applications that apply to all vehicles, including emergency vehicles. The Emergency Vehicle OBE supplements these general capabilities with capabilities that are specific to emergency vehicles. |
| Other Emergency Management Centers | Center | 'Other Emergency Management Centers' provides a source and destination for information flows between various communications centers operated by public safety agencies, emergency management agencies, other allied agencies, and private companies that participate in coordinated management of transportation-related incidents, including disasters. The interface represented by this object enables emergency management activities to be coordinated across jurisdictional boundaries and between functional areas, supporting requirements for general networks connecting many allied agencies. It also supports interface to other allied agencies like utility companies that also participate in the coordinated response to selected highway-related incidents. |
| Remote Vehicle OBEs | Vehicle | 'Remote Vehicle OBEs' represents other connected vehicles that are communicating with the host vehicle. This includes all connected motorized vehicles including passenger cars, trucks, and motorcycles and specialty vehicles (e.g., maintenance vehicles, transit vehicles) that also include the basic 'Vehicle OBE' functionality that supports V2V communications. In CVRIA, this object provides a source and destination for information transfers between connected vehicles. The host vehicle on-board equipment, represented by the Vehicle OBE physical object, sends information to, and receives information from the Remote Vehicle OBEs to model all connected vehicle V2V communications in CVRIA. |
| Roadside Equipment | Field | 'Roadside Equipment' (RSE) represents the Connected Vehicle roadside devices that are used to send messages to, and receive messages from, nearby vehicles using Dedicated Short Range Communications (DSRC) or other alternative wireless communications technologies. Communications with adjacent field equipment and back office centers that monitor and control the RSE are also supported. This device operates from a fixed position and may be permanently deployed or a portable device that is located temporarily in the vicinity of a traffic incident, road construction, or a special event. It includes a processor, data storage, and communications capabilities that support secure communications with passing vehicles, other field equipment, and centers. |
| 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. In CVRIA, a separate 'Vehicle OBE' physical object supports the general V2V and V2I safety applications and other applications that apply to all vehicles, including transit vehicles. The Transit Vehicle OBE supplements these general capabilities with capabilities that are specific to transit vehicles. |
| Vehicle Databus | Vehicle | The 'Vehicle Databus' represents the interface to the vehicle databus (e.g., CAN, LIN, Ethernet/IP, FlexRay, and MOST) that may enable communication between the Vehicle OBE and other vehicle systems to support connected vehicle applications. The vehicle system statuses and/or sensor outputs available on the databus will vary based on the equipment installed on the vehicle and availability on databus. System statuses and sensor outputs may include select vehicle systems and sensors such as accelerometers, yaw rate sensors, and GPS derived location and timing information. In CVRIA, this physical object is used to represent the onboard interactions between the Vehicle OBE and the other systems included in a host vehicle. Note that the vehicle databus interface is not standardized across all vehicle classes. Also, some Vehicle OBE implementations will not have access to the vehicle databus. See 'Vehicle OBE' for more information. |
| Vehicle OBE | Vehicle | The Vehicle On-Board Equipment (OBE) provides the vehicle-based processing, storage, and communications functions necessary to support connected vehicle operations. The radio(s) supporting V2V and V2I communications are a key component of the Vehicle OBE. This communication platform is augmented with processing and data storage capability that supports the connected vehicle applications. In CVRIA, the Vehicle OBE includes the functions and interfaces that support connected vehicle applications for passenger cars, trucks, and motorcycles. Many of these applications (e.g., V2V Safety applications) apply to all vehicle types including personal vehicles, commercial vehicles, emergency vehicles, transit vehicles, and maintenance vehicles. From this perspective, the Vehicle OBE includes the common interfaces and functions that apply to all motorized vehicles. |
Includes Application Objects:
| Application Object | Description | Physical Object |
|---|---|---|
| CV On-Board Cargo Monitoring | "CV On-Board Cargo Monitoring" monitors the location and status of the commercial vehicle and its cargo. It sends the collected data to appropriate centers and roadside facilities, including emergency management in the case of HAZMAT incidents. Depending on the nature of the cargo, it may include sensors that measure temperature, pressure, load leveling, acceleration, and other attributes of the cargo. | Commercial Vehicle OBE |
| Emergency Call-Taking | "Emergency Call-Taking" supports the emergency call-taker, collecting available information about the caller and the reported emergency, and forwarding this information to other objects that formulate and manage the emergency response. It receives 9-1-1, 7-digit local access, and motorist call-box calls and interfaces to other agencies to assist in the verification and assessment of the emergency and to forward the emergency information to the appropriate response agency. | Emergency Management Center |
| Emergency Notification Support | "Emergency Notification Support" receives emergency notification messages from vehicles or personal handheld devices, determines an appropriate response, and either uses internal resources or contacts a local agency to provide that response. The nature of the emergency is determined based on the information in the received message as well as other inputs. This object effectively serves as an interface between automated collision notification systems and the local public safety answering point for messages that require a public safety response. This capability depends on an up-to-date registry of public safety answering points/response agencies by coverage area, the type of emergency, and hours of service. | Emergency Management Center |
| EV On-Board En Route Support | "EV On-Board En Route Support" provides communications functions to responding emergency vehicles that reduce response times and improve safety of responding public safety personnel and the general public. It supports traffic signal preemption via short range communication directly with signal control equipment and sends alert messages to surrounding vehicles. | Emergency Vehicle OBE |
| RSE Emergency Notification Support | "RSE Emergency Notification Support" receives emergency notification messages, determines if the message has been previously received, and forwards unique messages to the back office center of the designated responding agency. | Roadside Equipment |
| Transit Vehicle Passenger Counting | "Transit Vehicle Passenger Counting" collects transit vehicle loading data and makes it available to the center. | Transit Vehicle OBE |
| Vehicle Emergency Notification I/F | "Vehicle Emergency Notification I/F" provides the capability for drivers or collision detection sensors to report an emergency and summon assistance. It includes the on-board collision detection sensors, a mechanism for the driver to summon assistance, and two-way communications. | Vehicle OBE |
Includes Information Flows:
| Information Flow | Description |
|---|---|
| commercial vehicle data | Information about the commercial vehicles cargo, credentials, and payments that is shared between on board equipment over an in-vehicle bus. This includes freight equipment type (box, flatbed, trailer, container, etc.), type of cargo (refrigerated, non-perishable, liquid, etc.), hazardous material data, quantity of cargo, and cargo permits as applicable (hazmat, special routing permissions). |
| driver input | Driver input to the vehicle on-board equipment including configuration data, settings and preferences, interactive requests, and control commands. |
| driver input information | Driver input received from the driver-vehicle interface equipment via the vehicle bus. It includes configuration data, settings and preferences, interactive requests, and control commands for the connected vehicle on-board equipment. |
| 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. |
| emergency acknowledge | Acknowledge request for emergency assistance and provide additional details regarding actions and verification requirements. |
| emergency notification | An emergency request for assistance that is automatically initiated by a vehicle or manually initiated by a vehicle occupant. The request includes call-back number, date, time, location, pre-event vehicle heading, vehicle make, model, model year, and fuel type, and crash severity indicators. Crash severity indicators include: airbags deployed, number of impacts, crash delta velocity, principle direction of force, and rollover indication. In addition, seatbelt restraint use, number of occupants, occupant location, and intrusion may be included. For commercial vehicles, this flow may also include freight equipment type (box, flatbed, trailer, container, etc.), type of cargo (refrigerated, non-perishable, liquid, etc.), hazardous material data, quantity of cargo, and cargo permits as applicable (hazmat, special routing permissions). |
| emergency notification relay | The relay of a previously received emergency notification. This relay enables a connected vehicle that is passing within radio range of a vehicle in need of assistance to store the notification and then forward it to a public safety agency when communications is available. Multiple relays may be necessary in remote areas with infrequent traffic and spotty communications coverage. The relay includes all of the information included in the original emergency notification (see 'emergency notification') and relay-specific data that can be used to manage the relay. Relay-specific data may include the date and time of original emergency notification receipt and the number of times the message has been relayed. |
| emergency operations input | Emergency operator input supporting call taking, dispatch, emergency operations, security monitoring, and other operations and communications center operator functions. |
| emergency operations status | Presentation of information to the operator including emergency operations data, supporting a range of emergency operating positions including call taker, dispatch, emergency operations, security monitoring, and various other operations and communications center operator positions. |
| host vehicle status | Information provided to the connected vehicle on-board equipment from other systems on the vehicle platform. This includes data from on-board sensors, the current status of the powertrain, steering, and braking systems, and status of 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 Connected Vehicle environment. |
| incident report | Report of an identified incident including incident location, type, severity and other information necessary to initiate an appropriate incident response. |
| request for service | Driver inputs that summon an emergency response, request a financial transaction, or initiate other services. |
| transit vehicle data | Information about the transit vehicle that is shared between on board equipment over an in-vehicle bus. This includes passenger count data and current on board equipment status. |
Application Interconnect Diagram
This is one way this application may be realized, but not the only way. There are other ways to build a given application and accomplish a stated objective.
The application interconnect diagram can be viewed in SVG or PNG format and the current format is SVG. SVG Diagram
PNG Diagram
Application Triples
Requirements
| Need | Requirement | ||
|---|---|---|---|
| N2.002 | Advanced Automatic Crash Notification Relay (AACN-Relay) needs to determine that a crash or emergency situation has taken place, based on on-board sensor data that detect changes in velocity, vehicle orientation, and airbag status. | 2.002 | AACN-Relay shall monitor vehicle characteristics, e.g., velocity, orientation, and air bag status for indications of a collision. |
| 2.003 | AACN-Relay shall determine that a collision has occurred based on changes in vehicle sensor data. | ||
| N2.003 | AACN-Relay needs to determine that a crash or emergency situation has taken place, based on on-board sensor data that detect changes in velocity, vehicle orientation, and airbag status. | 2.001 | The Advanced Automatic Crash Notification Relay (AACN-Relay) system shall provide the capability to broadcast collision notifications or distress calls from vehicles. |
| N2.004 | AACN-Relay needs to provide data about the crash and the vehicle's occupants in order to facilitate the quickest and most appropriate response. | 2.004 | AACN-Relay shall broadcast notification about the occurrence of a collision. |
| 2.005 | AACN-Relay shall broadcast information about the vehicle when a collision occurs, including: position, change in velocity, vehicle orientation, airbag status, call-back number, video, and multiple impact indicators. | ||
| 2.006 | AACN-Relay shall broadcast information about the vehicle's occupants when a collision occurs, including: number of occupants, seat belt use, and passenger special medical needs. | ||
| 2.007 | AACN-Relay shall broadcast information about the vehicle's contents when a collision occurs, including: freight equipment type (box, flatbed, trailer, container, etc.), type of cargo (refrigerated, non-perishable, liquid, etc.), hazardous material data, quantity of cargo, and cargo permits as applicable (hazmat, special routing permissions). | ||
| N2.005 | AACN-Relay needs to securely send notification about a crash without requiring involvement of the driver or occupant. | 2.008 | AACN-Relay shall broadcast collision notifications without requiring involvement of the driver. |
| 2.009 | AACN-Relay shall support the ability of a driver/occupant to initiate a collision notification message, i.e. distress call. | ||
| N2.007 | AACN-Relay needs to receive broadcast AACN alerts in order to determine the location and nature of the emergency. | 2.010 | AACN-Relay shall provide the capability to receive collision notifications from vehicles. |
| 2.011 | AACN-Relay shall determine the location of the sender when it receives a collision notification broadcast. | ||
| 2.012 | AACN-Relay shall determine the nature of the emergency from the contents of the received collision notification message. | ||
| N2.008 | AACN-Relay needs to rebroadcast AACN alerts when received from a connected vehicle in order to get the message to the appropriate call center quickly. | 2.013 | AACN-Relay shall provide the capability for vehicles to retransmit a collision notification message. |
| 2.014 | AACN-Relay shall determine if a received collision notification message should be retransmitted based on criteria such as the distance from position of message origin or the number of retransmissions already made. | ||
| 2.015 | AACN-Relay shall increment the number of retransmissions of a collision notification as part of the retransmitted message. | ||
| N2.009 | AACN-Relay needs to route AACN alerts to the appropriate emergency communications center (ECC) for action. | 2.016 | AACN-Relay shall route collision notification messages to the appropriate emergency communications center (ECC) for action. |
| 2.017 | AACN-Relay shall maintain a registry of ECCs based on factors such as coverage area (county, state, continent), types of emergencies serviced (e.g. all, hazmat, rail crossing, Brand X autos), and hours of service (days, 24 hr, etc.). | ||
| 2.018 | AACN-Relay shall provide the capability for equipped devices to forward collision notifications to the appropriate ECC. | ||
| N2.010 | AACN-Relay needs to inform the operator when it receives an AACN alert message to allow the operator to verify the message and/or provide additional notification to the authorities. | 2.019 | AACN-Relay shall inform the emergency system operator or passing vehicle operator when a collision notification message has been received. |
| N2.011 | AACN-Relay needs to provide a receipt message back to the originating AACN broadcaster that it has received their distress call. | 2.020 | AACN-Relay shall send a message back to the originator of the collision notification message that its message has been received, including: time message received, type of entity receiving the call (other Vehicle, the ECC), and whether the message will be retransmitted. |
| N2.102 | AACN-Relay needs to send an alert (mayday request) to public safety agencies when a vehicle is involved in an accident. | 2.222 | AACN-Relay shall be able to receive input from vehicle systems that indicate vehicle status. |
| 2.223 | AACN-Relay shall analyze vehicle system outputs to determine when the vehicle has been involved in an accident. | ||
| 2.224 | AACN-Relay shall contact emergency management agencies with the vehicle's position and accident status. | ||
Related Sources
- R.E.S.C.U.M.E. (Response, Emergency Staging and Communications, Uniform Management, and Evacuation) ConOps, Final, 11/19/2012
- R.E.S.C.U.M.E. Report on Functional and Performance Requirements, and High-Level Data and Communication Needs, Final, 2/7/2013
- SAE J3067- Candidate Improvements to Dedicated Short Range Communications (DSRC) Message Set Dictionary (SAE J2735)Using Systems Engineering Methods, 8/15/2014
Security
In order to participate in this application, each physical object should meet or exceed the following security levels.
| Physical Object Security | ||||
|---|---|---|---|---|
| Physical Object | Confidentiality | Integrity | Availability | Security Class |
| Security levels have not been defined yet. | ||||
In order to participate in this application, 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 | |||
| Security levels have not been defined yet. | |||||