 |
 |
 |
 |
|
 |
 |
SAE J2735-Draft-Rev15 [issued: 01-30-07]
-
148 -
This is an SAE Motor Vehicle Council draft document of the DSRC committee, subject to change.
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.
ANNEX A OPERATION WITH THE VEHICLE SAFETY MESSAGE
1.
Application Background
The message sets specified for vehicle safety (ACID 20) in this Recommended Practice were developed based on
analysis of communications requirements for seven high-priority vehicle-to-vehicle application scenarios with
significant anticipated safety benefits. These application scenarios are:
Intersection Collision Warning
Emergency Electronic Brake Lights
Pre-Crash Sensing
Cooperative Forward Collision Warning