 |
 |
 |
 |
|
 |
 |
SAE J2735-Draft-Rev18 [issued: 06-26-07]
-
202 -
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.