 |
 |
 |
 |
|
 |
 |
SAE J2735-Draft-Rev15 [issued: 01-30-07]
-
23 -
This is an SAE Motor Vehicle Council draft document of the DSRC committee, subject to change.
<xs:maxInclusive value="32"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="items2" >
<xs:complexType>
<xs:sequence minOccurs="0" maxOccurs="32">
<xs:element name="items2-item" >
<xs:complexType>
<xs:sequence>
<xs:element name="tag" type="TwoByteTagList" />
<xs:element name="data" >
<xs:complexType>
<xs:choice>
<xs:element name="payload" type="Payload" />
<xs:element name="value" type="ValueList" />
</xs:choice>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="localBasicSafetyMessage" type="local:BasicSafetyMessage"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
Remarks: This message is divided into three primary parts with a slightly different message encoding plan used in
each. It is important to understand this encoding system in order to decode this message. The first part of the
message, Part I, is always sent at all times without exception. Because the data structures are known, this has
no tagging present. Part II of the message consists of predetermined data frames and data elements of known
length which follow in a defined order and may or may not be present in any specific instance of the message.
This can be determined by examining the tag found before each element item in Part II of the message. This
process is repeated until the end of the part II encoded content is reached. Part III allows the creator of the
message to add additional content (both defined in this data dictionary and defined privately outside of the scope of
this standard) as befitting his unique needs by using a simple delimited tag and value system. By this
methodology an effective yet simple message encoding is created which manages the tradeoff between message
decoding complexity and the need to conserve channel bandwidth.
5.3 Message: MSG_CommonSafetyRequest
Use: The Common Safety Request message provides a means by which a vehicle participating in the exchange of
the basic safety message can unicast requests to other vehicles for addition information which it requires for the
safety applications it is actively running. Responding vehicles will add this information to the appropriate place in
the basic safety message when they broadcast it. Additional operational concepts are explained further in other
clauses of this standard.
Addition information (data elements and data frames) can be requested by this message to be placed into either
the Part II or Part III sections of the basic safety message (Part I contains selected information that is always
present in every message without exception). The method of selecting specific elements to be sent follows the
same style of tagging that is used in encoding in Parts II and Part III.
Because the elements which can be selected in Part III are a super set of those defined in Part II, some overlap
can result. It is recommended that elements be sent with Part II style encoding when possible. Observe that the
encoding style in Part III allows for the inclusion of data elements outside the scope of this standard (so called
"private data"). This is provided to allow vendor specific additions to the messages defined in this standard to