 |
 |
 |
 |
|
 |
 |
SAE J2735-Draft-Rev29 [issued: 12-11-08]
-
229 -
This is an SAE Motor Vehicle Council draft document of the DSRC committee, subject to change.
to transit event, if that is the active event -->
</xs:sequence>
</xs:complexType>
10. Conformance
Since this SAE Standard specifies standard message sets, data frames and data elements for use by
applications intended to utilize the DSRC communications systems, an application will be judged to be in
conformance with this Standard by demonstrating functional interoperability with other conformant
applications. The level of interoperability possible will initially be limited to applications that can
effectively use the initial representative message sets, data frames and data elements specified in this
Standard.
11.
Other Application Notes (Informative)
11.1
On the use of TIME
The representation of time in the DSRC standard follows the methodology defined in the ISO 8601
standards for representing time. Unless specifically indicated in the definition of a data element, data
frame, or message, the time reference shall be Coordinated Universal Time (UTC) with the time zone of
Greenwich Mean Time (GMT). In this regard it follows the conventions of other ITS standards, however
there are some minor unique points that should be pointed out. First, the resolution of time in DSRC is
universally kept and expressed with a precision of one millisecond. This value (and its modulo derivatives)
is commonly used in many DSRC applications and forms the basis of many “short” forms of time. Time
within the current UTC minute is therefore expressed in a 2 bytes value (range 0 to 60,000 milliseconds) in
many messages. The rest of the elements of time (minutes, hours, days, month years etc..) are expressed in
the normative definition provided by ISO 8601 including a local time zone, although the time zones is not
used in most DSRC messages. Leap-seconds and other periodic approbations are handled in the normal
ISO 8601 way. In many DSRC messages there is only a need to send relative time (such as the current
minute or second) and the full (absolute) moment of time is only sent once or periodically when actually
needed. It should also be pointed out that component elements of the time in DSRC are sent as integer
values (i.e. Jan is sent as Hex 0x01) and not as ASCII strings as is found in some representations (for
example, ISO 8601 expressed as XML where Jan is represented as the ASCII pattern for “01” or Hex
0x3031). In addition, some unknown values have been mapped to the last value in the range. This is at
odds with some other standards that use zero for both a legal value of time and as an unknown value.
11.2
Persistence of the temporary MAC ID field
The MAC address used by OBUs is randomly generated at various times according to a timer, or vehicle
start-up, or possibly other events. This random MAC address is called the Temporary ID in DSRC
messages. The reason for having a non-permanent MAC address, and avoiding any other long-term
identification that is publicly available, is to preserve privacy through anonymity. The MAC value for a
mobile OBU device (unlike a typical wireless or wired 802 device) will therefore periodically change to a
new random value to ensure the overall anonymity of the vehicle. Because this value is used as a means to
identify the local vehicles that are interacting during an encounter, it is used in the message set.