 |
 |
 |
 |
|
 |
 |
SAE J2735-Draft-Rev15 [issued: 01-30-07]
-
169 -
This is an SAE Motor Vehicle Council draft document of the DSRC committee, subject to change.
ANNEX D USE OF THE MESSAGE DISPATCHER (INFORMATIVE)
Introduction
It is not possible to predict all the data elements that will be required by applications which have yet to be
implemented or even conceived. Subsequently, standardizing a static set of message definitions tends towards
including data elements in case some future application will use them. Data elements not currently used simply
increase the utilization of the communication channel. In addition, some vehicles may not be able to measure all
the elements required by a fixed message structure. The Message Dispatcher (MD) architecture addresses these
issues by enabling the flexibility to reduce, extend and reconfigure message contents.
The Message Dispatcher (MD) enables the separation of applications from communication messaging by
exploiting the flexibility of message set construction described earlier in this document (Clause 4.3 Philosophy of
Message Design). It also enables many simplifications in the scheduling, sending, creating and distribution of
message traffic between different applications found on the vehicle, as well as between vehicles. The concept
behind the MD is to use a flexible and efficient method for communicating the minimal set of required safety
information, thereby minimizing communication overhead and redundancy, while future-proofing the safety
communication paradigm.
This section provides informative guidance regarding a design approach for this element and how the specifications
in this standard can be used to achieve it. An illustrative example is also given.
Overview
The basic idea is illustrated in Figure 1D on the next page. Applications running on a particular node specify what
data elements they require to be sent / received with the MD. The MD then constructs a single message which
combines duplicate information and drops redundant information. The message is constructed using the data
elements, data frames (and unique identifiers) and message types described in this standard. Any receiving MD
will separate and distribute information to any applications which need it, as shown in the lower section of Figure
1D. Each Message Dispatcher can interpret the contents of a message using the Unique Identifiers assigned in
this standard (see the data element StdTagList and its use). The following section will describe how to build and
interpret these messages.
The result is a system that can easily be extended and upgraded as required. In addition, since only the message
passing format is specified, different OEM’s are able to develop their own products and differentiating services to
end users without requiring industry wide adoption.
Message Dispatcher Concept
In the MD architecture each application specifies the set of data elements that it uses (see Figure 1D) and
registers the data elements with the MD. (The allowable data elements are specified in this standard. Data
elements not included in the standard can also be registered with the Message Dispatcher as described later).
Applications may also register data elements later. If an old application is upgraded and no longer uses a specific
data element, the new application does not register the obsolete data element with the MD and the data element
will no longer be part of the message. In brief, under the MD architecture the message content is dynamically
determined by the applications that register the different data elements they need. The structure and the means to
interpret the messages are defined in this standard.
2.1 Message Construction
Once each application has registered its data elements with the MD, the MD is responsible of constructing the
packet. The packet should be constructed so to minimize the utilization of the communication channel. For
instance, if multiple applications register the same data element, possibly with different update frequencies, the
MD should only include the data element in the message once with its maximum update frequency and notify each
application at the update frequency they specified.