![]() ![]() ![]() ![]() SAE J2735-Draft-Rev15 [issued: 01-30-07]
-
170 -
This is an SAE Motor Vehicle Council draft document of the DSRC committee, subject to change.
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.
|