 |
 |
 |
 |
|
 |
 |
SAE J2735-Draft-Rev29 [issued: 12-11-08]
-
236 -
This is an SAE Motor Vehicle Council draft document of the DSRC committee, subject to change.
Annex B The Safety Message Handler (Informative)
Annex C describes examples of vehicle safety applications aimed at preventing collisions. The Safety
Message Handler is focused on that same type of safety application, though it can also be applied more
broadly. These safety applications generally [RS2]compare the state of a host vehicle with the states of
remote vehicles, and take some action, e.g. driver warning, when a threat of collision is detected. Each
application tracks a set of state variables, many of which are of common concern to other applications, and
some of which are application-specific. As the name implies, the Basic Safety Message (BSM) [5.x] is
designed to support the collective communication needs of a set of safety applications. Rather than
transmit a series of single-application messages, a vehicle sends one BSM whose contents convey all
aspects of the vehicle’s current state that are relevant to at least one application. This feature of the
communication architecture saves bandwidth resources by suppressing redundant information and avoiding
extra per-packet protocol overhead. It also saves processing resources in the sender and especially in the
receiver. Finally, it simplifies application designs by separating them from details of the communication
system like message structure and data element format.
This separation of the applications from the communication system implies an intermediate function. The
purpose of this annex is to describe at a high level how that function, which is called here a Safety Message
Handler (MH), could be designed to send and receive messages in support of safety applications.
A given vehicle both transmits its state and receives state updates from other vehicles. As noted in Annex
C, the state information from each vehicle might be updated via periodic broadcasts of the BSM. The
message period could be modified in response to network conditions or changing application requirements.
The periodic messages could also be supplemented by an occasional message upon the occurrence of a
specific event (e.g. hard-brake event).
Each application running on a vehicle has requirements for the state information that it needs to
communicate to other vehicles. For each state element, the application also has a requirement for the
broadcast update frequency. The job of the MH on the sender side is to compose and dispatch messages
with contents and at intervals that satisfy the collective needs of the applications. This process is illustrated
in Figure 1
5
. Three applications are shown on the left of the figure. For each, a set of data elements is
listed; these represent the state information that each application requires to be broadcast. The MH
composes messages whose content represents the union of the required elements. Note that an element like
Position that is required by multiple applications is sent only once in each message.
The MH might use a BSM to send the required information. In that case, any required element that is
included in Part I of the BSM is automatically sent. Any required element that is not included in Part I of
the BSM is explicitly included in Part II. Alternatively, a MH might use an A La Carte (ALC) message to
send the required information. The ALC has all of the flexibility of the BSM, but with no mandatory part;
Part I of the ALC message is similar to Part II of the BSM. If the MH chose to send an ALC message,
every required element is explicitly included. The choice of whether to use a BSM or an ALC may depend
on how much of the BSM Part I information is in the set of required information. Part I of the BSM is
specifically designed to include the information most likely to be useful for safety applications, so one can
expect the BSM to be a good message choice for a MH most of the time.
The transmit and receive parts of each application running on a vehicle have a dual structure. Just as the
transmit part has requirements for information to be sent, the receive part has a set of elements that it
desires to receive. The receive side of the MH shown in Figure 1 performs an inverse operation of the
send side. Upon receipt of a safety message, the MH parses the message to extract the component
elements. Every received element is provided to each application that desires to receive it. Received
elements that no application needs are ignored.
5
In this annex, all references to specific applications, data elements, and message rates are purely
illustrative.