 |
 |
 |
 |
|
 |
 |
SAE J2735-Draft-Rev18 [issued: 06-26-07]
-
27 -
This is an SAE Motor Vehicle Council draft document of the DSRC committee, subject to change.
<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 occur in an interoperable way. When a device receives a request for a data
element it does not understand or support, then that request is simply ignored.
ASN.1 Representation:
CommonSafetyRequest ::= SEQUENCE {
msgID DSRCmsgID, -- App ID value, 1 byte
request2Cnt INTEGER (0..32), -- 1 byte
requests2 SEQUENCE (SIZE(0..32)) OF StdTagList,
-- Part II items
request3Cnt INTEGER (0..32), -- 1 byte
requests3 SEQUENCE (SIZE(0..32)) OF TwoByteTagList,
-- Part III items
... -- # LOCAL_CONTENT
}