1、SAE Technical Standards Board Rules provide that: “This report is published by SAE to advance the state of technical and engineering sciences. The use of this report is entirelyvoluntary, and its applicability and suitability for any particular use, including any patent infringement arising therefro
2、m, is the sole responsibility of the user.”SAE reviews each technical report at least every five years at which time it may be reaffirmed, revised, or cancelled. SAE invites your written comments and suggestions.TO PLACE A DOCUMENT ORDER: (724) 776-4970 FAX: (724) 776-0790SAE WEB ADDRESS http:/www.s
3、ae.orgCopyright 1999 Society of Automotive Engineers, Inc.All rights reserved. Printed in U.S.A.SURFACEVEHICLE400 Commonwealth Drive, Warrendale, PA 15096-0001STANDARDSubmitted for recognition as an American National StandardJ2313ISSUEDSEP1999Issued 1999-09On-Board Land Vehicle Mayday Reporting Inte
4、rfaceForewordThis SAE Standard describes the interface between an on-board automatic Mayday detection andreporting system (or systems) and the response center (or centers) which handles the receipt of such calls. Thisdocument covers the physical and application layers of the interface, emphasizing t
5、he required data (“messageset”) to be exchanged between the vehicle and the service provider. This document defines minimum messagecontent, message formats, and interaction protocols which any ITS mayday system should contain and adhere toin order to insure inter-operability with State, Federal, and
6、 Private service providers. The purpose of thisdocument is to facilitate the deployment of such vehicle devices and define a common messaging methodology ofhow they will interface to both private service providers and government agencies such as the National 911network over a variety of telecommunic
7、ations links extending from the vehicle. See Figure 1.FIGURE 1OVERALL OPERATIONAL CONCEPTSAE J2313 Issued SEP1999-2-TABLE OF CONTENTS1. Scope42. References .52.1 Applicable Documents 52.1.1 SAE Publications 52.1.2 ISO Publications .52.2 Related Publications .52.2.1 Other Publications 53. Definitions
8、 .54. Overview of Message Set Standard .94.1 System Architecture104.2 Message Information Flow124.3 Relationships with National Architecture Flows 124.4 Additional Requirements Imposed by Commercial, Hazmat, and Medical Needs144.5 Use of Location Referencing Methods of ITS .144.6 Structure of the Do
9、cument145. The Message Protocol155.1 Message Protocol Flow 175.2 State Time-Out and Transition Requirements 195.3 Third Party message Protocol Flow Considerations.196. The Message Frames.206.1 General Message Frame Elements 216.2 The Data_Msg Frame Elements.226.3 The Init_Msg Frame Elements236.4 The
10、 Req_Msg Frame Elements246.5 The Ack_Msg Frame Elements 247. The Message Types .247.1 Collections of Data Elements into Related Message Types .257.2 Message Type Definitions 267.3 Message Type: Current_Position .277.4 Message Type: Prior_Position277.5 Message Type: Start_Position287.6 Message Type:
11、Position_History 297.7 Message Type: Position_Text 297.8 Message Type: Last_DRSC .297.9 Message Type: Vehicle_Info 307.10 Message Type: Vehicle_Details .307.11 Message Type: Vehicle_Sensor_Info .317.12 Message Type: Vehicle_SRS .317.13 Message Type: Vehicle_Security .327.14 Message Type: Cargo_Info
12、327.15 Message Type: Occupant_Info.337.16 Message Type: Occupant_SRS .337.17 Message Type: Text_Info .347.18 Message Type: Proprietary_Info.347.19 Message Type: Message Sets .347.20 Message Type: Request Data 35SAE J2313 Issued SEP1999-3-7.21 Message Type: Acknowledge Data 357.22 Message Type: Posit
13、ion_LRMS .358. The Data Elements .368.1 Data Element: Message Frame Header .368.2 Data Element: Sequence Number 368.3 Data Element: Frame Word Count .368.4 Data Element: Sender Flags.378.5 Data Element: Sender Status .388.6 Data Element: Message Type 398.7 Data Element: Message Word Count .398.8 Dat
14、a Element: Location-Long .408.9 Data Element: Location-Lat 408.10 Data Element: Location-Alt .418.11 Data Element: Velocity .418.12 Data Element: Heading.418.13 Data Element: Time-Minutes 418.14 Data Element: Beacon-ID .428.15 Data Element: Location-Tech .428.16 Data Element: Identity-Name428.17 Dat
15、a Element: Identity-Number 438.18 Data Element: Identity-ESN438.19 Data Element: Identity-DL-Number.438.20 Data Element: Identity-VIN .448.21 Data Element: Identity-Plate .448.22 Data Element: Identity-Carrier-ID .448.23 Data Element: Vehicle-Sensor-Identifier.448.24 Data Element: Data-Sensor458.25
16、Data Element: Data-Cargo .458.26 Data Element: Data-Proprietary458.27 Data Element: Data-Door-Status 468.28 Data Element: Occupant-Sensor-Identifier .468.29 Data Element: Sensor-Status .478.30 Data Element: Message-Bit-Fields .478.31 Data Element: Ack 488.32 Data Element: Data Text 498.33 Data Eleme
17、nt: Identity-Plate-Origin 498.34 Data Element: Identity-Plate-Type498.35 Data Element: Location-Quality 498.36 Data Element: CRC 509. Implementation of a Rudimentary MAYDAY System over the IDB.519.1 Overview of the IDB519.2 An Illustrative MAYDAY System Using the IDB529.3 IDB MAYDAY Components on th
18、e Bus 529.3.1 Cellular Phone 529.3.2 GPS Set539.3.3 Display Console with Buttons .539.3.4 Central Processor Resource.539.3.5 Gateway into the Vehicle Electronics .53SAE J2313 Issued SEP1999-4-10. Physical Layer Interface Issues 5410.1 Requirements for MAYDAY System over AMPS Celllular Networks5410.2
19、 Physical Layer Specifications for MAYDAY Systems .5410.3 Discussion of Other Communication Technologies 5510.3.1 CDPD Technologies .5510.3.2 Two-Way Paging Technologies 5510.3.3 TDMA Technologies .5510.3.4 CDMA Technologies.5510.3.5 Satellite Communications Technologies.5510.3.6 SMR Technologies .5
20、511. MAYDAY Message Set Testing55Figure 1 Overall Operational Concept 1Figure 2 Generic MAYDAY System Diagram Model.11Figure 3 MAYDAY Functional Flows from the National Architecture 13Figure 4 Detailed MAYDAY Message Flows 13Figure 5 Typical Protocol Exchange .15Figure 6 Typical Three Frame Protocol
21、 Exchange .15Figure 7 Example of Extended Protocol Exchange 16Figure 8 Exchange Initiated by Status Change.17Figure 9 Example of Data from the Dispatch Center 17Figure 10 General Sending Message State Flow .18Figure 11 General Waiting for it is resent with each message. An example of this would be a
22、 system, whichmay be failing during the transmission. A precise definition of the sender flags can be found in the DE section.This data element can be viewed as a list of supported features or messages from the device.Adjacent to this element is the Sender_Status, a two-octet field which is used to
23、transmit with each messagethe current status of the situation. This data can also change during the transaction. For example, a roadsideassistance call can become an accident or car jacking. This data is different from the Sender_Flags in that anychange to it results in the generation of a new messa
24、ge being sent. The flags, which indicate that thismessage is coming from a relay agent (another PSAP or a private central station), are also here. A precisedefinition of the sender status can be found in the DE section. This element can be viewed as a situationstatus word.Within each message frame t
25、here may be a variable number of message types. All message types follow asimple three-part pattern. A definition of each message frame is described next.The CRC is calculated from the first bit of the header element to the last bit of the last octet of the lastmessage. In the case of an AMPS phone
26、communications media, an octet by octet parity is also employed(odd parity) but is not part of the CRC calculation. Precise calculation rules for the CRC are found in the DEsection.6.2 The Data_Msg Frame ElementsThe Data_Msg frame does not have a required content or order ofmessage types. It can use
27、 any message type defined in this document (including those marked proprietary) inany order that it wishes. However, the following message types, which are intended to be used in the Req_Msg and Ack_Msg frame,shall not result in a Data_Msg response message frame being generated. If a response is des
28、ired, the propermessage frame (Req_msg or Ack_Msg) must be used.SAE J2313 Issued SEP1999-23-Data-msg : = SEQUENCE OF SEQUENCEtheMsg CHOICE - in a normal message any set of the below- in any order, may be presenta Current-Position,b Prior-Position, c Start-Position,d Position-History,e Position-Text,
29、f Last-DSRC,g Vehicle-Info,h Vehicle-Details,i Vehicle-Sensors,j Vehicle-SRS,k Vehicle-Security, l Cargo-Info,m Occupant-Info,n Occupant-SRS,o Text-Info,p Proprietary-Info, q Position-LRMS,.- these three messages are special case and may - not be sent in this way- Msg: Message-Set-List- Msg: Request
30、-Data- Msg: Acknowledge-DataIn any media where voice communications are interrupted by the transmission of data, it shall be arequirement, that all transmissions be less than 15 s in length. The total length of the resulting message frameshall be less than 1800 octets inclusive of the framing overhe
31、ad to avoid excessive use of the media bandwidthwhen the transmission media is AMPS at a rate of 1200 baud. In the reverse link connection, at 75 bits persecond, no more than 112 octets shall be sent in one transmission. In high-speed connections, proportionallymore data may be sent as long as the t
32、ransmission duration fits the previous requirements. 6.3 The Init_Msg Frame ElementsThe following message types in the following order are defined for thisframe:Init-Msg : = SEQUENCEa Current-Position,b Prior-Position,c Start-Position,d Vehicle-Info,e Message-Set-List SAE J2313 Issued SEP1999-24-6.4
33、 The Req_Msg Frame ElementsThe following message types in the following order are defined for thisframe: Req-Msg : = SEQUENCE a Request-Data 6.5 The Ack_Msg Frame ElementsThe following message types in the following order are defined for thisframe: Ack-Msg : = SEQUENCE a Acknowledge-Data7. The Messa
34、ge TypesNORMATIVEThis section defines the message types used in the document.Message types are encapsulated within message frames which provide an envelope as well as error detection,see Section 6 for details. Each message type is made up of one or more Data Elements. Data Elements aredefined to the
35、 atomic level (bit level) in Section 8. This section defines all message types.All message types follow a common format of three components as follows: A number of messages for Message_Type are defined and their proper use is provided in this document.Each message type contains data which is made up
36、 of one or more Data Elements (DEs). DEs are atomic innature and are defined to the bit level in this document. All Message types are at least 3 octets long.A number of values for Message_Type are defined and proper use of the corresponding messages is specifiedin this Recommendation.The Wd_Count is
37、 a single octet field that represents a positive integer from 0x00 to 0xFF. This integer value isthe number of octets in the message. The values 0x00 and 0xFF are reserved. The value 0x00 is reserved forfuture messages that contain no data but whose message type alone conveys useful information. The
38、re areno such messages currently implemented in this document. As a rule, all message data should be muchshorter than this to conserve bandwidth. All data elements within a message are of a known length, except forvariable-length text strings. Variable-length textual data elements are handled in one
39、 of two ways. Either theyare in their own message type (in which case the word count provides the string length) or they are the lastelement in a message type (in which case word count provides the summary of the prior elements (all of fixedlength) and the length of the string. Note that this last c
40、ase limits the combined length of all elements and thestring to 255 octets.Examples of messages include various position data, VIN, cargo data, etc as well as SRS sensors which areconsidered a class of messages (SRS_Data). Each message has a defined format. There are both fixed andvariable length me
41、ssages. The data content of the message is not explicitly defined in this section but is madeup of (reusable) DEs. Consult the DE section for the normative definition.Various SRS sensors are combined into messages of the Vehicle_SRS type. For example, the state of anairbag is handled within this mes
42、sage.Further definitions of Message_type and various atomic elements are described in the detailed sections tofollow.SAE J2313 Issued SEP1999-25-A number of other messages containing other objects are purposefully not defined to allow proprietary dataelements to co-exist with other elements. These c
43、an vary from manufacturer and hence, one must be familiarwith the manufacturer in order to fully decode them.Several messages for general variable field length text objects are defined for general display of messages.This can be used to provide map matched address location to the center from suitabl
44、y equipped vehicles or todisplay center messages to the vehicle driver.If a receiving device does not understand or use a specific message object, it can simply skip over the next Xoctets as specified by Wd_Count and then resume message parsing. This feature is to insure messagerobustness, it is not
45、 intended to encourage sending useless information to a center. When not communicating to centers that meet SAE J2313 standards, the message set used is undefined, as isthe message frame. Centers can implement both SAE J2313 and proprietary messages at once as needed. Itis expected that PSAPs will o
46、nly implement SAE J2313 and that all communication be within the messageframe structure and protocol of this document.It is not expected that all PSAPs will be able to interpret all possible messages, however, they will be able tointerpret the minimum messages set. The use of the word count in the s
47、econd octet of the message allows thereceiving party to skip over a message, which it does not understand without garbling the remainder of themessages in the frame.7.1 Collections of Data Elements into Related Message TypesFor logical grouping as well as bandwidthconsiderations, various data elemen
48、ts are grouped into message types with related functions. It is incorrect toview this grouping as implying any class tree or data object model. Messages have been grouped into thefollowing general subject areas. In general, the “basic” messages are required of all devices, whileimplementing the “add
49、itional” messages is optional. basic location position data (Lat-Long) basic occupant private data (primary Lic#, medical)basic vehicle data (VIN, ESN, etc.) basic vehicle SRS data (basic sensors data)additional location data (prior positions) occupant SRS data (seat by seat deployment data)additional vehicle data (color, features) door and security data (lock positions, alarms)cargo data (contents and Hazmat)Minor data elements have been grouped in this message packaging (bit level sensors for example) while otherdata elements are grouped due to their
