 |
 |
 |
 |
|
 |
 |
SAE J2735-Draft-Rev18 [issued: 06-26-07]
-
203 -
This is an SAE Motor Vehicle Council draft document of the DSRC committee, subject to change.
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.
Common data elements are identified by a single byte unique identifier listed in the data dictionary in
Section (using the data element StdTagList). Using the unique identifier of each data element, any sequence
or combination of data elements can be inserted into Part II of any of the messages described in Section 4.3.
The MD should attempt to group together data elements requested by the different applications in
accordance with the data elements and data frames defined by this Standard (refer to clauses 6, 7, and 8 for
these definitions). Since data elements appear in the data frame in a predefined order, they are not prefixed
by their unique identifier within the data frame and only the data frame unique identifier is required. Thus a
single unique identifier is assigned to each data frame. Hence, MD should use data frames, when
appropriate, in the construction of the message to reduce the message size. However, if not all elements of a
data frame are in use, the MD may include these data elements individually in the message instead of the
data frame in Part I of the message.. The data frames can then be included in Part II of the messages using
their unique ID. Special data elements that are not listed in the data dictionary (and would be defined by the
application users outside of this standard) can also be added to the message using Part III by using the two
byte tagging scheme detailed in Section 4.3. In the case where an entire message is needed to be unique the
ala carte message can be used.
Once the required data elements and frames are assembled into a message, any receiving MD will share the
common data dictionary and know how to interpret and use the received message by determining the
message type using the DSRC Message Id (see the data element concept DE_DSRC MessageID ).
The exact MD implementation will be OEM specific. However, the format of the message generated by the
MD is standardized. This allows the MD implemented by a specific OEM to exchange messages with MD
implemented by a different OEM. Since only the communication interface is specified between units,
OEMs are able to create unique applications that do not depend on other vehicles adopting their standard or
running their application. This design architecture is somewhat similar to the IP architecture in which two
internet based companies can provide different services, but both over the same communication channel.