SAE J 2369-2000 Standards for ATIS Message Sets Delivered Over Reduced Bandwidth Media《减速宽波介质上ATIS信息组的传送标准》.pdf

上传人:dealItalian200 文档编号:1026894 上传时间:2019-03-21 格式:PDF 页数:235 大小:1.12MB
下载 相关 举报
SAE J 2369-2000 Standards for ATIS Message Sets Delivered Over Reduced Bandwidth Media《减速宽波介质上ATIS信息组的传送标准》.pdf_第1页
第1页 / 共235页
SAE J 2369-2000 Standards for ATIS Message Sets Delivered Over Reduced Bandwidth Media《减速宽波介质上ATIS信息组的传送标准》.pdf_第2页
第2页 / 共235页
SAE J 2369-2000 Standards for ATIS Message Sets Delivered Over Reduced Bandwidth Media《减速宽波介质上ATIS信息组的传送标准》.pdf_第3页
第3页 / 共235页
SAE J 2369-2000 Standards for ATIS Message Sets Delivered Over Reduced Bandwidth Media《减速宽波介质上ATIS信息组的传送标准》.pdf_第4页
第4页 / 共235页
SAE J 2369-2000 Standards for ATIS Message Sets Delivered Over Reduced Bandwidth Media《减速宽波介质上ATIS信息组的传送标准》.pdf_第5页
第5页 / 共235页
点击查看更多>>
资源描述

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 2000 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 StandardJ2369ISSUEDMAR2000Issued 2000-03Standards for ATIS Message Sets Delivered o

4、ver Reduced Bandwidth MediaForewordThis document outlines the US standard for sending Advanced Traveler Information Services (ATIS)messages over reduced bandwidth media data streams. It specifies the “over the air” format and method for suchdata messages at a bit level within the structure of the ho

5、st system. The methodology allows a cooperativesharing of the medias total bandwidth with other non-ATIS data services. It allows for further expansion to otherATIS messages such as transit schedules and weather use. It uses a common directory of messages to divide outthose messages which are the su

6、bject of this specification from others. It can be deployed upon multiple physicalmodulation types, typically wireless in nature.TABLE OF CONTENTS1. Scope . 62. References . 62. Related Documents 63. Definitions. 74. Overview 124.1 Message Types Supported 124.2 The Protocol Stack . 154.3 Physical Mo

7、dulation . 154.4 The Network Layer . 154.5 Data Tokens and Stream . 164.6 The Examples Used in this Document . 175. Background Concepts 175.1 Stream Schemas How the information streams work 175.2 Tokens and Tables The Theory of Data Compression Used 215.3 Tiles and Grids Efficient Representations of

8、 Latitude and Longitude Values 265.4 Traffic Models Shared Models of Link Impedance Modeling. 305.5 Forward Pointers Indirection to Other Data Sources. 365.6 Frame Bit Stuffing Unused “Flea Bits” in the Message Frame 375.7 Frame Headers The Concept of Context. 375.8 Transit Scheduling Unified Concep

9、ts of Multi Modal Scheduling Tables 376. Network/Directory Messages 38SAE J2369 Issued MAR2000-2-6.1 Overview of Structure other media do not. Theoverall success or failure of a given host can be compared to other alternatives by consideration of its MER. 3.30 Message ContextThat portion of the mess

10、age frame (often also called the header) which establishesdefault values for expansion of the frame from which the subsequent data (the message payload) may beparsed.3.31 Message FrameThe envelope of the message, the frame is the outer layer of the message, typically a multi-byte long structure ATIS

11、 message. The actual frame length will vary depending on the host media from as fewas 22 bytes to as much as 512 bytes in length.3.32 MessageIn the most general definition, messages are the groups of coherent thoughts which are packagedtogether in a set of bytes called a frame. This term is applied

12、in two different ways in this document. First, amessage is taken as being the same as the message frame (containing a context and the payload area).Second, the payload of a frame contains one or more messages (each made up of tokens as specified in thecontext).3.33 National TableThe table of string

13、entries (names) used by all receivers to save on transmitted text. Thistable rarely changes and is used (with the other tables, typically the local table) to expand passed strings(street names and free text) back into their original format. It is typically not transmitted over the media as itwould n

14、ot change as the user moved from one local operational area to another.3.34 Off-hoursNon-peak hours of operation for the host are typically late at night. These hours are often used tosend support files and longer messages which conflict with bandwidth needs during daily operations. This mayprove a

15、way to distribute small maps for self contained users. On some hosts, this may also be a time slotwhen higher speed modulation can be employed based on the pre-established stationary nature of the receiverduring this time period. SAE J2369 Issued MAR2000-10-3.35 Ordinal Post NameThat part of the nam

16、e appended to the “number” field of a numerical street designation,the “rd” in 3rdstreet or the “th” in 123th street.3.36 Payload, of a frameThe portion of a frame which contains the actual data and is used in conjunction withthe context and tables to expand into a more complex message for use by th

17、e receiving device. 3.37 Post-NameThe portion of the name field at the end of the primary name, such as Street in “North MainStreet.”3.38 Pre-NameThe portion of the name field at the beginning before the primary name, such as North in “NorthMain Street.”3.39 Primary NameThe portion of the name field

18、 containing the primary name, such as Main in “North MainStreet.”3.40 Primary TableA table which is used as the “first entry” for table look-ups. Such tables are typically nationalor local in scope and do not change very often. They can be used in conjunction with secondary tables toprovide a “one o

19、f many” look up function, however, the primary table entry is taken as the preferred value. Forexample, the primary tables might contain “Main Street” as an entry while the secondary tables provide a valuesuch as “Hwy 39” and thus provide a local alias.3.41 Raw SymbolsThe smallest data element found

20、 in the payload of the message frame. They can vary inlength from one to many bits and have no octet alignment properties. Symbols are parsed (using the contextand tables) to create values which fit into byte aligned memory attributes in receiving devices.3.42 RDS-TMCRadio Data SystemTraffic Message

21、 Channel, the proper term for the delivery of incident textmessages over the RDS-RBDS modulation format. This format has been deployed in various ways over thelow speed subcarrier in the EC and to a small degree in the US (RDS an 1187-bit/s raw data rate stream with200 useable bits per second). The

22、message format used consists of hard coded locations (by index valueand therefore requiring a common agreed upon map) combined with textual messages (which can beexpanded into the local language of choice). There are no link impedance concepts in the RDS messages,only short textual descriptions. The

23、 text look up tables are not that different from the method used here,however, they are never transmitted over the media and do not change or evolve once issued.3.43 Retransmission TimeThe stream of data found in some broadcast (oneway) hosts containing messageswhich are repeated frequently. This is

24、 referred to as the retransmission time and can vary due to severalconsiderations including policy decisions, other needs for bandwidth and how often the data itself changes.Messages are also retransmitted to ensure that a user who may have missed a prior message can successfullydecode it when repea

25、ted this type of time diversity improves the system robustness. Users are also enteringand leaving the systems (turning their receivers on and off) at all times so considerations must be given to thepopulation of “new” users who may not yet be tracking current data transmitted in prior messages. Two

26、-waymedia will typically transmit on demand in a point to point fashion. 3.44 Route ImpedanceAn electrical engineering construct commonly used to model the traffic flow rates. A highimpedance implies a “slow” link. This term and route travel time are often used interchangeably. At a grosslevel, rate

27、 of travel multiplied by length of segment can be considered the same as the segment travel time.3.45 SegmentA portion of roadway network between two end nodes. Typically, one cannot “leave” the segmentand enter another segment except at a joining node. See SAE J2374 for a more complete taxonomy ofn

28、etwork description terms. 3.46 Services DirectoryA stream of information informing the user as to what information is available in the hostdata stream.SAE J2369 Issued MAR2000-11-3.47 Sizing DataInformation about a stream of data, typically a table being sent, regarding its ultimate size intransmitt

29、ed bits and (in some message) in expanded bytes. This information is provided so that the receivercan determine if it has the capacity to recover the entire message. This may require the receiver to purge otherinformation in its memory, the process of which is beyond the scope of this document.3.48

30、StreamThe concept of an independent flow of information multiplexed (in time) with other streams in the hostdata flow to effectively divide the bandwidth of the system into useful subset parts. Each stream tends to be aself-contained set of information. Some streams, which are supportive in nature,

31、need only be downloadedonce and then this information is used with other streams to decode the information. The transmissionprovider can decide what mix of streams best meet his customer needs in a manner similar to the way abroadcaster determines how often to broadcast the updating of voice traffic

32、 news.3.49 S-T-T-SThe four level schema used in the division of data into related streams. STTS refers to Sizing,Tokens, Tables, and Static stream information and it often denotes the process steps followed to receive astream of data (of which ATIS is but one possible collection of data present on a

33、ny given host). The processgrossly is as follows. The sizing data in the directory must be examined to confirm that the device can handlethe tables it will need. The tokens can then be extracted from messages to monitor the stream and get thesubject data - this step is repeated as long as the data i

34、s desired. In use, the receiving device is must have (orget if it does not have it) the table data which is also periodically transmitted. And finally, if there are statictables which may not be transmitted, such as a National Table, it must have those as well - typically these areobtained from what

35、ever source provided the decoding software in the first place.3.50 Sub-StringA term for the occurrence of one string inside another, and specifically the optimal matching oftable entries to utilize this effect. For example “Road Construction Work” might be a locally used string. In thisstring are ot

36、her National Table strings such as “road” which should be used to represent it. This is encouragedto save space. The governing rule is that a table can not expand within itself. A consideration for encodermakers is to determine algorithms, which will pick the most efficient (typically longest) table

37、 entries rather thanseveral shorter ones.3.51 Table ExtensionThe process of adding additional entries onto a previously issued table. This allows userswith older tables (as determined by the revision number) to continue to use their current tables while obtaininga new one (with the new entries on th

38、e end). Encoders in general extend tables rather than renumber them(which must still be periodically done). The process of renumbering implies that the table has been resorted. 3.52 “Throw an exception”Programming jargon for placing into the stream of parsed token objects, a symbolwhich indicates so

39、me exception process must be made in the line of code to handle it. A typical examplewould be a stream of ASCII characters representing some text when the next character in order was a non-valid printing character such as 0x80. Detecting this character “throws the exception” and indicates that thene

40、xt two characters will be taken together to form an index value into a table which will provide a text string tobe expanded in line and replace the exception character.3.53 TokenThe next object to be processed in a serial stream of data being parsed for expansion. It may be fromone to N bits in leng

41、th. The specific size can be determined by the message specification and the context flagsset.3.54 Topographicalreferring to the height of the subject geographic object.3.55 TopologicalReferring to the connectivity of the subject geographic object.3.56 “Toss Back Token”Programming jargon for an exce

42、ption token appearing in an unusual place where it istypically (from statistical point of view) not found. Its presence is used to indicate that the expected exceptionWILL NOT OCCUR and that the normal flow of symbols will follow. In many instances, it is not required to firstplace an exception toke

43、n in the stream if the message format can be used to establish that a specific token willbe the index value. For example, one of the ways to set the context flags in some messages uses the nameSAE J2369 Issued MAR2000-12-field of the segment as an index value (rather than a stream of ASCII which cou

44、ld contain such a valuepreceded by an exception). If the subsequent name entry was NOT an index value, the presence of the tossback token indicates that a stream of ASCII will follow instead. The use of this construct is almost always theresult of a compression selection which failed in the specific

45、 case and resulted in more tokens being sent - thisis acceptable as long as in the sum of all messages the compression choice was the correct one.3.57 Transmission EpochA period of time (TBD) where the information of the various streams is repeated. Alsosee epoch. This occurs typically in one-way br

46、oadcast transmission of data. 3.58 Variant FlagThe lower two bits of a table index used to control how strings from that table are expanded. 3.59 Yellow Pages This term is no longer used in this document. Originally, it was defined as a portion of theServices Directory.3.60 Zoom ScaleThe scaling fac

47、tor used in the description of the Grid tile entries. A zoom scale can be used tofocus the tile on a much larger or much smaller area of interest. The intended use of the zoom scale isthreefold. To reflect weather and other events on a national scale where final precision needs not be verygreat, and

48、 to establish smaller regions of interest as might be found in an amusement park, or a hotel kioskwhere the host media would be used for transmission of local data regarding these environments. A final useof the zoom scale is to create “vanity maps” over portions of the metro area which cover inform

49、ation in a non-geographically correct way to the benefit of the end user. An example of such a map is the local subway ortransit system where a long established local graphic might be used in place of a geographically correct basemap for reasons of clarity and tradition (the Washington, D.C. Metro system is an example).4. OverviewThis document defines the message set for the transmission of ATIS messages over bandwidthreduced media (BRM). This chapter of the document provides an overview of the type of messagessupported. This is

展开阅读全文
相关资源
猜你喜欢
  • EN 419211-6-2014 en Protection profiles for secure signature creation device - Part 6 Extension for device with key import and trusted channel to signature creation application《安全签.pdf EN 419211-6-2014 en Protection profiles for secure signature creation device - Part 6 Extension for device with key import and trusted channel to signature creation application《安全签.pdf
  • EN 419212-1-2014 en Application Interface for smart cards used as Secure Signature Creation Devices - Part 1 Basic services (Remains Current)《安全签名生成设备智能卡的应用接口 第1部分 基本服务》.pdf EN 419212-1-2014 en Application Interface for smart cards used as Secure Signature Creation Devices - Part 1 Basic services (Remains Current)《安全签名生成设备智能卡的应用接口 第1部分 基本服务》.pdf
  • EN 419212-1-2017 en Application Interface for Secure Elements for Electronic Identification Authentication and Trusted Services - Part 1 Introduction and common definitions.pdf EN 419212-1-2017 en Application Interface for Secure Elements for Electronic Identification Authentication and Trusted Services - Part 1 Introduction and common definitions.pdf
  • EN 419212-2-2014 en Application Interface for smart cards used as Secure Signature Creation Devices - Part 2 Additional services (Remains Current)《安全签名生成设备智能卡的应用接口 第2部分 附加服务》.pdf EN 419212-2-2014 en Application Interface for smart cards used as Secure Signature Creation Devices - Part 2 Additional services (Remains Current)《安全签名生成设备智能卡的应用接口 第2部分 附加服务》.pdf
  • EN 419212-2-2017 en Application Interface for Secure Elements for Electronic Identification Authentication and Trusted Services - Part 2 Signature and Seal Services.pdf EN 419212-2-2017 en Application Interface for Secure Elements for Electronic Identification Authentication and Trusted Services - Part 2 Signature and Seal Services.pdf
  • EN 419221-5-2018 en Protection Profiles for TSP Cryptographic Modules - Part 5 Cryptographic Module for Trust Services.pdf EN 419221-5-2018 en Protection Profiles for TSP Cryptographic Modules - Part 5 Cryptographic Module for Trust Services.pdf
  • EN 419251-1-2013 en Security requirements for device for authentication - Part 1 Protection profile for core functionality《身份验证用装置的安全要求 第1部分 核心功能性的防护性配置文件》.pdf EN 419251-1-2013 en Security requirements for device for authentication - Part 1 Protection profile for core functionality《身份验证用装置的安全要求 第1部分 核心功能性的防护性配置文件》.pdf
  • EN 419251-2-2013 en Security requirements for device for authentication - Part 2 Protection profile for extension for trusted channel to certificate generation application《身份验证用装置的.pdf EN 419251-2-2013 en Security requirements for device for authentication - Part 2 Protection profile for extension for trusted channel to certificate generation application《身份验证用装置的.pdf
  • EN 419251-3-2013 en Security requirements for device for authentication - Part 3 Additional functionality for security targets《身份验证用装置的安全要求 第3部分 安全目标的附加功能》.pdf EN 419251-3-2013 en Security requirements for device for authentication - Part 3 Additional functionality for security targets《身份验证用装置的安全要求 第3部分 安全目标的附加功能》.pdf
  • 相关搜索

    当前位置:首页 > 标准规范 > 国际标准 > 其他

    copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
    备案/许可证编号:苏ICP备17064731号-1