 |
 |
 |
 |
|
 |
 |
SAE J2735-Draft-Rev26 [issued: 09-18-08]
-
29 -
This is an SAE Motor Vehicle Council draft document of the DSRC committee, subject to change.
<xs:element name="msgCnt" type="MsgCount" />
<!-- 1 byte -->
<xs:element name="secMark" type="DSecond" />
<!-- 2 bytes -->
<xs:element name="id" type="TemporaryID" />
<!-- 4 bytes
Part I, sent as a single octet blob -->
<xs:element name="blob1" type="BSMblob" />
<!-- The blob consists of the following packed bytes:
pos PositionLocal3D,
lat Latitude, -x- 4 bytes
long Longitude, -x- 4 bytes
motion Motion,
speed Speed, -x- 2 bytes
heading Heading, -x- 2 byte
accelSet AccelerationSet4Way, -x- accel set
-x- (four way) 7 bytes
control Control,
brakes BrakeSystemStatus, -x- 1 byte
basic VehicleBasic,
size VehicleSize, -x- 3 bytes
Part II, sent as required -->
<xs:element name="events" type="EventFlags" minOccurs="0"/>
<!-- 2 bytes -->
<xs:element name="partTwo" type="PartTwoContent" minOccurs="0"/>
<xs:element name="localBasicSafetyMessage" type="local:BasicSafetyMessage"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
In addition, this item may be used by data structures in other ITS standards.
Remarks: This message is divided into three primary parts and uses the same BER-DER encoding system
in each. In the first part (those data elements which are always sent at all time) some data element have
been encoded as well defined octet blobs to enable concise encoding and conserve channel bandwidth. In
the second part, DER tags and lengths precede each possible defined element in the normal way. In the last,
or 3rd part, user defined data elements (elements not defined in the standard) may be sent along with
predefined content, also using DER tags. Developers of such local content should take steps to avoid
creating content with tags which could conflict with future revisions of the standard.
5.4 Message: MSG_CommonSafetyRequest (Remove now?)
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 {
 |