1、 SURFACE J2540-2 VEHICLE STANDARD 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 entirely voluntary, and its applicability and suitability for any particular use, including any p
2、atent infringement arising therefrom, 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. Copyright 2009 SAE International All rights reserve
3、d. No part of this publication may be reproduced, stored in a retrieval system or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of SAE. TO PLACE A DOCUMENT ORDER: Tel: 877-606-7323 (inside USA and Canada)
4、 Tel: 724-776-4970 (outside USA) Fax: 724-776-0790 Email: CustomerServicesae.org SAE WEB ADDRESS: http:/www.sae.org Issued 2002-02Revised 2009-11 Superseding J2540-2 NOV2006 ITIS Phrase Lists (International Traveler Information Systems) Rationale This 4th edition of the standard provides additional
5、phrases and categories developed beyond those defined in the prior editions and incorporating continuing feedback from early deployment experience. Major additions in this release include phrase elements needed to support MUTCD sign descriptions. Foreword Prepared for use by the ATIS committee of th
6、e SAE by SubCarrier Systems Corp (SCSC). Create_time: 02:30:27 PM Thursday, April 30, 2009 Extracted from: ITIS_Rev04_00_02.ITS Mod: 4/30/2009 2:22:26 PM Build: First_Word, Ver: 0.8.277 On node C:136-5448-3969 Table of Contents 1. Scope 4 2. References .5 2.1 Applicable Documents . 5 3. Definitions
7、.5 4. Overview 5 5. Operating Concepts .6 5.1 Use in General ITS messages 6 5.2 Use in RDS systems 7 5.3 Use in the TMDD ERM Message 8 5.4 Use in the IEEE Incident Management Message Set 9 5.5 Use in the DSRC Message Set . 10 5.6 Use in Operator Consoles 11 5.7 Formats of tables 12 5.8 Supported voc
8、abularies and alphabets 13 5.9Registering a table within ITS 13SAE J2540-2 Revised NOV2009 - 2 - 6. Data Element Definitions 136.1 Data Element: DE_Accidents and Incidents 136.2 Data Element: DE_Alternate Route 166.3 Data Element: DE_Asset Status 186.4 Data Element: DE_Closures (Road and Lane) 196.5
9、 Data Element: DE_Delays, Status, And Cancellations 206.6 Data Element: DE_Device And Equipment Status 226.7 Data Element: DE_Disasters 246.8 Data Element: DE_Disturbances . 266.9 Data Element: DE_Generic Locations 286.10 Data Element: DE_Incident Response Equipment 316.11 Data Element: DE_Incident
10、Response Status 346.12 Data Element: DE_Information System . 356.13 Data Element: DE_Instructions (Mandatory) 366.14 Data Element: DE_Instructions (Recommendations) . 386.15 Data Element: DE_ITIS_Text . 406.16 Data Element: DE_ITISgroups . 406.17 Data Element: DE_ITIS . 436.18 Data Element: DE_Lane
11、/ Roadway Descriptions . 1216.19 Data Element: DE_Large Numbers 1236.20 Data Element: DE_Mobile Situation . 1266.21 Data Element: DE_MUTCD Locations 1286.22 Data Element: DE_Named Objects . 1316.23 Data Element: DE_Objects 1326.24 Data Element: DE_Obstructions . 1346.25 Data Element: DE_Parking Info
12、rmation 1366.26 Data Element: DE_Pavement Conditions . 1386.27 Data Element: DE_Precipitation . 1416.28 Data Element: DE_Qualifiers 1426.29 Data Element: DE_Recreational Objects And Activities 1456.30 Data Element: DE_Regulatory And Warning Signs . 1486.31 Data Element: DE_Regulatory Signs 1506.32 D
13、ata Element: DE_Responder Group Affected . 1516.33 Data Element: DE_Restrictions . 1526.34 Data Element: DE_Roadside Assets 1546.35 Data Element: DE_Roadwork . 1576.36 Data Element: DE_Small Numbers . 1596.37 Data Element: DE_Special Events 1676.38 Data Element: DE_Sporting Events 1686.39 Data Eleme
14、nt: DE_States And Territories .1706.40 Data Element: DE_Street Suffixes 1726.41 Data Element: DE_Structures . 1776.42 Data Element: DE_Suggestion Advice 1786.43 Data Element: DE_Temperature. 1796.44 Data Element: DE_Traffic Conditions 1816.45 Data Element: DE_Transit Mode 1826.46 Data Element: DE_Tr
15、ansit Operations 1836.47 Data Element: DE_Traveler Group Affected . 1866.48 Data Element: DE_Unit Values . 1876.49 Data Element: DE_Unusual Driving . 1906.50 Data Element: DE_Valid Maneuvers 191SAE J2540-2 Revised NOV2009 - 3 - 6.51 Data Element: DE_Vehicle Groups Affected . 1956.52 Data Element: DE
16、_Visibility as a result syntactically valid messages which produce poorly constructed human language can result. Some standards users address this in varying degrees of detail, but in general it is a function of the message creation system and not covered by the various message sets. Regardless of w
17、hich format of string content ordering is used, implementers SHALL follow the rules and process of SAE J2540 to insure that successful encoding and decoding of the data shall occur by any party using this standard. SAE J2540-2 Revised NOV2009 - 7 - In anticipation of making SAE ATIS messages more li
18、ke those found in the rest of ITS (notably TMDD in this case), it is recommended that implementers group message content into three distinct areas of “description of the event,“ “cause of the event“ and “advice regarding what to do” and append all three areas into a single textual stream when the be
19、arer message does not provide separate areas for each of these. Further, between the first and second items the phrase “Due to: “ should be inserted and between the last two, the phrase “Advice: “ should be inserted. It is anticipated that future revisions of the ATIS standard will provide three dis
20、tinct places to insert SAE strings to be labeled description, cause and advice and that the last two will be optional in nature. When mapping message content from another ITS message which supports this three-part construction to one which does not, the above recommendation SHOULD be followed. 5.2 U
21、se in RDS systems In general, the ITIS phrases cannot be used in the existing RDS media; however the vast majority of so-called RDS systems are not in fact using a SubCarrier transmission media (the point of actual restriction) but are in fact using the RDS phrases as a convenient interim standard f
22、rom which to construct textual descriptions. It is recommended that these users SHOULD revise their systems to use the ITIS phrases (as well as other ITS message set standards) as conditions allow. This requires some degree of mapping to take place and ultimately must be decided by the implementers
23、as best fits local needs. In mapping from the use of RDS phrases to that of ITIS phrases, two general cases occur. In the first case, a single RDS message can be mapped to one or more ITIS messages. At times this mapping is subjective, but as ITIS offers a wider set of expressions this is not overly
24、 problematical. An example would be RDS phrase #324 which is rendered as “Disabled vehicle, Right lane blocked “. An equivalent message made up of three ITIS components would be 0534,8196,0775 which is rendered as “disabled vehicle right lane blocked “. Observe that capitalization and punctuation ma
25、rks can vary slightly in this. The second case involves the limited use of numerical values in messages. Historically RDS allowed only a few “common“ numbers to occur in the messages.1In ITIS phrases, as a function of the methods of SAE J2540, numerical values can be inserted in between phrases as n
26、eeded to express values.2An example would be RDS message #421 which is rendered as “Closed ahead, Stop and go traffic for 5 miles“. An equivalent message made up of ITIS components would be 0771,0258,7721,0005,8712 which is rendered as “Closed ahead Stop and Go traffic for 5 miles “. Depending upon
27、the way in which the numeric value is encoded, ordinal post fix characters can also be automatically added at expansion. In addition, a list of common unit values (seconds, minutes, dollars, mph, miles, etc) is also present in the ITIS list. A number of the “message canceled“ type of phrases have be
28、en preserved in ITIS list for backward compatibility. As an operational concept the use of the these phrases is not encouraged. Specific messages of this type which may be removed or replaced in the future are denoted with the comment “Not Recommended“ in the tables. In addition it should be pointed
29、 out that the data contents found in the ATIS messages (and the rest of ITS) contain a broad spectrum of other elements which are intended to hold concepts like the time period over which a message is valid. These data elements SHOULD be used as intended and the phrase sections of the message SHOULD
30、 NOT be used to circumvent them. 1The latter “multi-block“ RDS messages of Alert+ does allow a value to be delimited in an element of the message which is then inserted into the phrases based on a predetermined use and location. This was considered and rejected in favor of having a more generalized
31、approach in J2540. 2Not all uses of ITS can support this; for example ERM (a message which is part of the TMDD standards) prohibits numeric and free text insertions. In the ERM case, other elements in the message can contains such values. SAE J2540-2 Revised NOV2009 - 8 - 5.3 Use in the TMDD ERM Mes
32、sage When used in constructing an Event Reporting Messages (ERM) message from the TMDD MS/ETMC2 message set some additional considerations and restrictions apply in order to maintain a dual perspective on the encodings found in the ERM message. This allows an “ERM-centric“ practitioner to exchange d
33、ata with an “ATIS centric“ one without involving translations which would detract from interoperability. The key to this dual view is to appreciate that: ATIS tends to view a collection of phrases as representing one atomic element which can be uniformly handled upon receipt, the ERM perspective des
34、cribes an event element as the structured combination of phrases, causes, advice, quantifiers and free text each in its own ASN1 element. Both perspectives are valid. ERM receiving implementations can use this to good effect in various sorting and automatic classification functions (which the SAE pe
35、rspective also supports). The following is an excerpt from the key portion of the ERM message. Event-description := CHOICE event-phrase 1 SEQUENCE OF Event-type, event-cause 2 SEQUENCE OF Event-type, event-advice 3 SEQUENCE OF Event-advice, event-quantities 4 SEQUENCE OF Event-quantities, event-addi
36、tional-text 5 SEQUENCE OF Event-additional-text The heart of the dual view is that first three elements above fragment of code is considered the same as the one below, expressed in a more “ATIS centric“ way. . Event-description := CHOICE event-phrase 1 TheString, event-cause 2 TheString, event-advic
37、e 3 TheString In both cases, a common code list is used. The ERM elements of EventType and EventAdvice map directly to the 16-bit values used in ITIS. From an ERM perspective the first octet represents which data element (i.e. EventTypeXXX) is used, while the second octet represents the specific phr
38、ase code of the phrase within the data element. Implementers are urged to review both the ERM message specification in the TMDD standard and the SAE J2540 standard to fully understand the low level ASN1 tagging issues involved. Harmonization of these lists will be maintained by the ITE and SAE as a
39、part of the data registry process. Observe that the ASN1 terms provided in TMDD are in fact the ASN1 value enumerations for each code. The recommended text for the code is defined by this document. In most cases, it is readily derived from the ASN1 definition used in ITE.3There are several additiona
40、l restrictions in using the ITIS list in ERM in addition to adherence to the requirements of SAE J2540 as follows. Precedence: The ERM ASN1 found in the adopted ITE TMDD standard is the definitive authority for ERM message. 3Again, local variants in such definitions can be readily established when n
41、eeded as per J2540 rules. SAE J2540-2 Revised NOV2009 - 9 - Quantities: The ERM requires that quantities used in situation descriptions adopt the standard (usually metric) quantity definitions and units specified by TMDD, NTCIP, SAE and other ITS standards bodies. These values can be converted to ot
42、her units such as miles, pounds, etc., in the end-user application, if desired. SAE J2540 allows users to send an undefined numerical value followed by a unit phrase, such as “1000“ “pounds“. This practice is not recommended when a data element (such as the quantities category) exists in the message
43、 set. Specifically, implementers SHALL NOT use this ability to add values and units in strings to circumvent the quantities found in a message set.Sub Set: The ERM message definition provides most, but not all of the phrases found in ITIS. Typically these are data elements which in ERM can be expres
44、sed somewhere else in the message itself. The TMDD data element Event-indicators (TMDD #xxx) is an example of this. Such phrases are a part of ITIS in order to allow the subject concept to be expressed in those messages which do not have an allocated place for it. The use of ITIS phrases in such an
45、ITE message SHALL be restricted to those elements which the defining ITE standard allows. Textual Use: The ERM message definition allows free text to be used at any point in the description, along with standards-defined phrases, causes, advice and quantities. However, this text is placed in the data
46、 element assigned to hold it and not inserted into other locations. Language: The language of free text occurring in the ERM message is typically defined in an Interchange Agreement - a working agreement drawn up between message exchange partners. Partners can agree to use English, French, Spanish,
47、or any other language of their choice for routine exchanges. If desired, the language of the free text can also be indicated for a specific message exchange using optional TMDD Data Element #3816 within ERM. Typically, this is used if the normally agreed upon language must be changed in a specific m
48、essage. Text occurring in the rest of the ERM message is presumed to be of table type #0. This is a reserved type which implies that the text will be formatted in Latin_1 characters and employ no indexing (e.g. simple free text). Table Types: The ERM message definition presumes that the table entrie
49、s are static in nature and that entries are never reused. This is reflected in the table header values outlined further in this document. Local Use: ERM allows the standard ITIS phrases to be varied or translated for local applications, e.g. “traffic stopped“ can be expressed as “stationary traffic“ or “bouchon“ if desired in Nova Scotia or Quebec. Like all users of these phrases, makers of ERM message receiving equipment are free to express these tables in whatever rendering, language, or media formats suit
