IFSF Comms over LonWorks translate(翻译).doc

INTERNATIONAL FORECOURT STANDARD FORUMSTANDARD FORECOURT PROTOCOLPART II.1COMMUNICATION SPECIFICATIONOver LonWorksVersion 1.91 March 2006Page: 67This document was written by the IFSF - Working Group:NameCompanyTelephoneDieter ClabenScheidt & Bachmann GmbH, Breite Strasse 132, 41238 Mnchengladbach, Germany+49/2166/266363Arnaud de FerrySchlumberger TechnologiesPeter MaeersBP Oil Europe, Gloucester House, Langley Quay, Waterside Drive, Langley, Slough , Berkshire SL3 6EY, United Kingdom+44/1753/549420John CarrierShell Europe Oil Products, York Road, London, SE1 7NA,United KNick BradshawIFSF Project ManagerNEduardo RezendeShellJrgen WedemannDeutsche Shell AG, VTP/4, berseering 35, 22297 Hamburg, Germany+49/40/63246445David BlythCalon Associates, Runcorn, United KJiri KrivanekBeta Control Limited, Cerneho 58/60, Bystrc, CZ-635, Brno, Czech RepublicJkrivanekbetacontrol.czFor further copies and amendments to this document please contact:IFSF Technical Services. E-mail: Their contact details and the latest revision of this document can be found on the Internet at the following address: Internet address: .FP2_1.91IFSF STANDARD FORECOURT PROTOCOLCOMMUNICATION SPECIFICATIONMarch 2006Document Contents文献内容0RECORD OF CHANGES54变更纪录1SYSTEM ARCHITECTURE86系统构架2COMMUNICATION PRINCIPLES97通讯原理2COMMUNICATION PRINCIPLES108通讯原理2.1LON Features108LON的特征2.2Application Communication Basics129应用通讯基础3APPLICATION MESSAGE FORMAT1712应用报文格式3.1Generic Message Frame1712一般报文框架3.2Application Message Fields1913应用报文域3.2.1Message Status M_St1913报文身份M_St3.2.2Message Length M_Lg2014报文长度M_Lg3.2.3Database Address DB_Ad and Length DB_Ad_Lg2014数据库地址DB_Ad和长度DB_Ad_Lg3.2.4Application Data Data2115应用数据Data3.3Application Message Type2115应用报文类型3.3.1Read - Message2115Read报文3.3.2Answer - Message2316Answer报文3.3.3Write - Message2518Write报文3.3.4Acknowledge - Message2719Acknowledge报文3.3.5Unsolicited Data - Message3022Unsolicited Data报文3.4Concurrent Message Handling322425并发的报文处理3.4.1Ambiguity of Block Cut Messages33253.4.2Ambiguity of Response Messages3325应答报文的不明确3.4.3NACK Reads3325NACK读取4IFSF COMMUNICATION SERVICES3426IFSF通讯服务4.1Addressing3426寻址4.2Application Protocol Parameters3426应用协议参数4.3Messages Code IFSF_MC3527报文编码IFSF_MC4.4Block Cutting BL35274.5Communication Service Database3628通讯服务数据库4.5.1Initial Node Installation3729初始节点安装4.5.2Recipient Address Table3729接受地址表4.5.3Heartbeat4335心跳4.6Data Encryption4436数据编密码4.6.1COPT Data Encryption4436COPT数据编密码4.7Unlocking4840解锁5IMPLEMENTATION GUIDELINES & RECOMMENDATIONS4941执行指导以及建议5.1Actions when a Device Recognises that a SC is Off-Line4941当设备识别到一个SC出于离线时的动作5.2IFSF Message Examples4941IFSF报文举例5.2.1Read and Answer Messages4941读取和应答报文5.2.2Write and Acknowledge Messages4941写和承认报文5.3Read and Write Data Error Handling5042读取与写数据错误的处理5.3.1Communication Layer Errors5042通讯层错误5.3.2Application Data Layer Errors5143应用数据层错误5.4Data_Ack Error Handling5244DATA_ACK错误的处理5.4.1Checking Order5345检查命令0Record of ChangesOnly changes effected in Versions1.83, 1.84 and 1.85 are listed. Previous changes can be viewed in previous versions available in the Library, Standards Archive Section.这里只列出了在1.83、1.84和1.85版本基础上的改变，其余的可以参见以前版本的库和标准档案文件部分。DateVersionModificationOctober 20021.83Various formatting modification throughout the document文献中所有的格式修改Reduced Record of Changes section.减少的更改记录的部分Section 4.1 Subnet Addressing Table removed. Cross referenced to Engineering Bulletin No. 8.删除了4.1部分的子网寻址表。February 20031.84Removed contact details for IFSF Technical Support and made reference to the IFSF web site instead.删除了与IFSF技术支持的联系资料和Chapter 3第3章Section 3.1 M_St included in “Message on the Network” Matrix.3.1部分M_St包含在“网络中的报文”的矩阵里Section 3.3.4 Value field of MS_ACK corrected.3.3.4部分中MS_ACK的Value域被更正Section 3.3.5 Example Database corrected.3.3.5部分中Example Database被更正Chapter 4第4章Section 4.3 Minor spelling corrections.4.3部分中次要的拼写被更正April 20031.85Various grammar and format corrections, including reducing white space from document.不同的文法与格式的更正，Chapter 1 System architecture modified to emphasize the decentralised solution (picture page 6 corrected).第1章系统结构上的修改是强调了分散的解决方案（第6页的图片被更正）Chapter 2.2. Table on page 10 corrected to be consistent with text on page 9. Footnote added to clarify the use of Acknowledge Message after a Read Message.2.2章第10页的表格修改为与第9页的文字一致。在读取报文之后，为了清楚说明确认报文的使用，增加了脚注Chapter 4.5.2. The writing of recipient address table is removed and detailed examples provided for reading, adding and removing addresses from the recipient address table.4.5.2章删除了接收地址表的写操作，详细说明了提供的从接收地址表中读取、增加、移除地址的例子。Chapter 5.2 Worked examples are included for each type of message.5.2章的实际例子被包含在每种类型的报文里Chapter 5.3. Error Handling added to clarify the priority of error messages.5.3章为了说明清楚错误报文的优先权，加入了错误的处理October 20031.86Chapter 5.3 amended5.3章被修改- Clarification of processing of an unexpected message, e.g. answer or acknowledge message from controller device意外的报文的处理的说明，例如，从控制设备发出的应答和确认报文- Clarification of processing of a read or write to a DataID which cannot be read or written.给一个不能够读或者写的DataID的读或写操作的处理说明October 20041.87Chapter 章Additional information added to allow both implementations of “Read Recipient Address Table”.为了允许两个“读取接收地址表”的执行。增加了附加信息。December 20041.88Chapter .3章Additional information added to on Controller Device Heartbeat Interval.在控制设备心跳报文的时间间隔上增加了附加信息Chapter 4.7 补充了4.7章Added.June20051.89“Checking Order” added to Data_Ack matrix, section 3.3.4增加给Data_Ack矩阵一个“检查命令”，3.3.4部分Section 5.4 added. Clarification of Data_Ack.增加了5.4部分，Data_Ack的详细说明February20061.90Section 4.2 note on optional Block Length range of 32 to 64 added. 4.2部分指出可选择的块长度在32到64之间March20061.91Section 3.3.5 note added on when to send an unsolicited message without acknowledge.3.3.5部分指出增加了当发送一个未被恳求的未确认报文。1System Architecture系统结构The protocol is defined to be able to support different configurations:协议能够支持不同的配置Decentralised system in which the multiple POSs are directly connected to the bus, the dispenser and other controller devices themselves providing the management of their information (lock/unlock transactions,.). This allows for interoperability between different controller devices and increased resilience.在多个POS机直接连接在总线上的分散式系统中，加油机与其它控制设备自己能够提供信息（锁定与解锁交易）的管理。由此，实现了控制设备的互操作性，同时提高了系统的灵活性。System using a single forecourt controller which manages the different communications with the forecourt equipment (dispensers, outdoor payment terminals, price sign displays,.); this forecourt controller is able to store the dispenser transactions; if multiple Points of Sale (POS) are used, it is responsible for dispatching data between them;使用单一的前庭控制器的系统，这个前庭控制器管理不同的前庭设备（包括加油机、室外结算终端、价格显示器等）间的通讯。前庭控制器能储存加油机的交易信息。如果多个POS都被使用，他还负责在它们之间分派数据。The choice between these 2 solutions depends on:两种解决方案的选择依赖于：- W&M rules (ability to buffer or not in the dispenser or in the forecourt controller.);W&M标准（在加油机或在前庭控制器中是否有存储缓冲器功能）- - migrations (most existing systems use the second architecture so they can easily implement it).- 移植能力（大多数已存在的系统使用的都是第二种结构，所以很容易实现）Architecture 1:Dispenser 1Dispenser nOPTMonolith / Pole Sign LON BUSPOS1POS2POS3POS4Forecourt ControllerPOS1POS2POS3POS4Dispenser 1Dispenser nOPTMonolith / Pole SignLON BUSArchitecture 2:Different points can be considered in the document to describe the exchanged messages:在文献中，通过描述不同点间的数据交换来说明报文的传递。- messages between the Originator Application and the Originator Communication layers,报文在发送端应用层和发送端通讯层间的传递。- messages on the network,报文在网络上的传输。- messages between the Recipient Communication layers and the Recipient Application.报文在接收端通讯层与接收端应用层间的传递。For interoperability reasons only the message on the network have to be considered, but for explanations it is sometime useful to also consider the interface between the Application (layer 7) and the Communication (layers 1 to 6).为了实现互操作性，只需考虑在网络上传输的报文的形式。但是有时为了表述清楚，也要考虑到应用层（第7层）与通讯层（第1到6层）间的接口Originator Application layer 7Originator Communication layers (1-6)Recipient Application layer 7Recipient Communication layers (1-6)Network2Communication Principles通讯原理The transport layer for an IFSF network may be either a Lonworks based network architecture or a system based on TCP/IP. The TCP/IP specification is given in Part 2.II. This document describes the implementation over LonWorks. The application layer defined by the IFSF is independent of the transport layer used.IFSF网络的传输层要么是基于Lonworks的网络结构，要么是基于TCP/IP的系统。TCP/IP的详细说明在Part 2.II中给出。本文主要描述的是在LonWorks上的实现。IFSF定义的应用层是与传输层独立的。2.1LON FeaturesLON的特点The LON component selected to provide the ISO communications layers 1 to 6 is already used in the building wiring/services business. The very large usage of this component offers a powerful solution at an acceptable cost.所选的LON组件提供了ISO通讯层的第1层到第6层的实现，已经使用在“建筑配线与服务”中。这个组件的广泛应用，为在可接受的造价上提供了强有力的解决方案。The LON is able to use different physical layers (layer 1):LON能使用不同的物理层（第1层）-RS485 (max speed: 39 kbit/s)RS485总线（最大传输速率：39k/s）-Transformers (78 kbit/s or 1.25 Mbit/s)-Power Lines (PLT-20, Cenelec C-Band)电力线-Optical Fibres光纤-Short Range Radio短距离广播-Infrared Light红外-Intrinsically Safe-Free Form Topology (FTT-10A 78 kbits/s)自由拓扑LonWorks Specific Network ParametersLonWorks特有的网络参数Addressing:寻址：- the top level of the addressing hierarchy of a LonWorks network is a domain. If different applications are to share a communication network, they may be separated into different domains.All forecourt devices are installed in domain 1.LonWorks网络寻址的最高层是域。如果不同的应用共用一个通讯网络，它们可能会被配置成不同的域。所有前庭设备都配置为在第1域中。- the second level of addressing is the subnet. A subnet is a logical grouping of nodes from one or more channels. There may be up to 255 subnets per domain.寻址的第2级是子网。一个子网包含了一个或多个信道上的节点的逻辑组。每个域可以有255个子网。- the third level of addressing is the node. There may be up to 127 nodes per subnet.寻址的第3级是节点。每个子网最多可能有127个节点。- group addressing facilities are not used.没有使用组寻址工具The Lontalk protocol offers four basic message services these being:-Lontalk协议提供4个基本的报文服务机制：ACKD, REQUEST/RESPONSE, UNACKD_RPT, UNACKDThe service implemented on the IFSF network is ACKD. The ACKD service is were a message is sent to a node and individual acknowledgements are expected back from each recipient node. If the acknowledgements are not all received, the sender times out and retries the transaction. The number of retries and the time-out value are variable and are set along with the network parameters by application level code (layer 7 OSI model) see below for parameter description and the values set in the IFSF network implementation:-在IFSF网络上实现的是ACKD机制。ACKD服务机制是：一个报文发送给一个节点并且期望从接收到报文的节点处返回一个确认的信息。如果没有收到所有的确认，则发送端超时并且再次尝试发送该报文。重发次数和超时时间值是可变的，通过应用层设置网络参数时设置。下文是对参数的描述及在IFSF网络中实现时设定的值：Priority Slot:1Determines if message has priority over other messages, improves response time of critical messages (set to 1 to allow for the creation of emergency messages). 优先权1：决定报文是否有高于其他报文的优先级，用来提高要求严苛的报文的应答时间（ 紧急情况报文通过将其设置为1来创建。）Retry = 3Specifies the number of times a node will repeat sending A message if it doesnt receive an acknowledgement.如果没有收到确认信息，确定一个节点该报文重发的次数RPT_Timer : Not usedSpecifies how frequently the message is repeated when using unacknowledged/repeated service.未使用；表示当使用非确认/应答服务时，确定报文的发送频率RCV_Timer:Not usedStarted when a node receives a message.未使用，表示当节点接收到报文时，启动记时。TX_Timer = 96msDetermines how long a node waits for an acknowledgement before retrying. (LonTalk TX_TIMER Value 5).决定在再次重试前节点等待确认信息的时间Non_Group_Timer = 768 ms Started when a node receives a message providing it can allocate a receive transaction record.当节点接收到一个能分派接受交易记录的报文时，启动The chosen standard for layer 1 is the Free Form Topology FTT-10 at 78 kbits/s. This high speed will offer a very good response time even in the worst conditions and allows the bus topology to be any combination of a star, loop or bus. 第1层选择自由拓扑78k/s的FTT-10。高的速率可以在最坏的环境下仍然有非常好的响应，并且允许总线拓扑结构变成“星形”、“环形”或者“总线型”。请注意，The LON uses a P-Persistence CSMA protocol (similar to Ethernet) and so no master is required on the bus.LON使用的是P-Persistence CSMA协议（类似于Ethernet），因此总线上不需要masterThe LON chip uses 3 processors and so the communications on the bus (managed by 2 of them) never interferes with the transfer of messages with the application (managed by the third). The forecourt communication expects to use a LON component for layer 1 to 6, using Explicit Messages.LON芯片使用3个处理器，因此在总线上的通讯（由其中两个管理）不会干扰应用层的报文传输（由第三个处理器管理）。前庭通讯使用LON的组件的第1到6层，同时使用显式报文。The length of such messages is set by the Max_Block_Length communication data element (see chapter 4.5 Communication Service Database). The range for the block length is 32 to 228. To allow messages longer than this value, a Block number BL is included in the message (for details see chapter 4.4 Block Cutting).报文的长度是由Max_Block_Length通讯数据项设定的（见4.5章“通讯服务数据库”）。块长度的范围从32到228。为了允许报文比这个值长，在报文中使用BL项来记数块的序号（详细见章节4。4中的块的分割）2.2Application Communication Basics应用通讯要素To avoid specifying message contents where application dependent, the choice was to use a read/write mechanism.为了区分应用层报文的内容，选择使用读/写机制Six basic messages are used to access any data in the system:系统中使用了6个基本报文，用于操作系统中的数据- Read Messages - Answer Messages- Write Message- Unsolicited Data Message with Acknowledge- Unsolicited Data Message without Acknowledge - Acknowledge Message 读报文回答报文写报文自发需应答报文自发无需应答报文应答报文A Read Message allows an originator device to read the value(s) of any system data element from a recipient device within a specified database. It is possible to read multiple data elements in one command. This is achieved by requesting a list of data elements. So only the accessible data elements must be requested and the messages are application dependent. The recipient must respond to the Read Message with an Answer Message within the time-out period of 8 seconds. However, if a recipient node is unable to respond it must reply with an ACK. If for instance the device was busy it replies with a MSG_ACK of NAK7 or if the “Read Message” contains an invalid database address the device replies with a MSG_ACK of NAK6.Read Message允许一个originator始发设备从接收设备的数据库中读取已定义的系统数据项。可能在一个命令中读取多个数据元素。这是通过请求一串数据元素完成的。所以，只有可读取的数据元素才可被请求，并且报文是由应用程序决定的。接收端必须在8秒的超时范围内应答给Read Message一个Answer Message。但是，如果接收节点不能满足要求，它必须返回一个ACK。例如，如果设备正在忙，它返回MSG_ACK的值是NAK7的或者如果“Read Message”包括一个无效的数据库地址，这个设备返回MSG_ACK一个NAK6的值。An Answer Message is a message which provides to the originator of a Read Message all the requested data elements.Answer Message是提供给所有请求数据元素的Read Message的originator的报文A Write Message is used to send data from an originator to a recipient device. The identifier of the data element is defined in the recipient device. It is possible to write a multiple data elements in the one command. This is achieved by issuing a message including a list of data elements and their values.Write Message用于从起始设备发送数据到接收设备。报文中的数据项的标识符已经在接收设备中定义过。一个命令可能写多个数据元素。这是由发布一个包含数据元素和它们的值的列表的报文来完成的。Sending a Command is considered as writing a data element with no value. The same message is able to send commands and data elements used as parameters.发送一个Command命令可以认为是一个数据元素值为空值的写报文。相同的报文可能同时发送命令和作为参数的数据元素。The recipient must respond to the Write Message with an Acknowledge Message within the time-out period of 8 seconds.接收端必须在超时的8秒范围内应答给Write报文一个an Acknowledge的应答报文。An Unsolicited Data Message with Acknowledge is used for sending data elements. The recipient must respond to this message with an Acknowledge Message within the defined time-out of 8 seconds.Unsolicited确认报文用于发送数据元素。接收端必须在超时的8秒内应答，回应这个报文一个确认报文。The only difference from a Write Message is that the data elements (database address, data identifier, data element contents) are defined in the originator device.与Write Message的唯一不同是数据元素（数据库地址、数据标识符、数据元素内容）定义在始发设备中。An Unsolicited Data Message without Acknowledge is used for sending data elements (e.g. status change, error) where the recipient must not respond to the message.Unsolicited 非确认报文用于发送数据元素（例如：状态变更、错误），同时接收到报文的设备不必回复一个确认 报文。The Acknowledge Message is used by the recipient of a message (write, unsolicited with acknowledge) to respond. Acknowledge 报文是报文接收方在接收到报文后（写报文, unsolicited确认报文）作应答用的。Table 1. Message Sequences Overview表1，报文序列总览MESSAGES SEQUENCES报文序列Originato发送端rRecipient接收端Requesting data elements from a single database in a device在一个设备中从单一数据库请求数据元素Read Message读报文-Answer Message应答报文-Answer Message应答报文 -Answer Message应答报文-Acknowledge Message