0 Bewertungen0% fanden dieses Dokument nützlich (0 Abstimmungen)
16 Ansichten19 Seiten
DNP V3:00 TRANSPORT FUNCTIONS Network. Information in this manual is subject to change without notice. The information contained in this manual does not represent a commitment on the part of Harris Corporation or the DNP Users Group.
DNP V3:00 TRANSPORT FUNCTIONS Network. Information in this manual is subject to change without notice. The information contained in this manual does not represent a commitment on the part of Harris Corporation or the DNP Users Group.
DNP V3:00 TRANSPORT FUNCTIONS Network. Information in this manual is subject to change without notice. The information contained in this manual does not represent a commitment on the part of Harris Corporation or the DNP Users Group.
Network File Name: P009-0PD.TF Original Author: Malcolm Smith Date and Version of Preliminary Release: November 8, 1992 Version 0.00A Associated Software Release(s): DNP V3.00 Revisions Since Preliminary Release Date Version By Whom Pages Affected Reason for Changes Nov. 08/92 0.00A M. Smith All Created Aug. 20/93 0.01 J. Bhat All Revised after review Sep 01/93 0.01 AV All Corrections as per C. Huene May 30/97 0.01 S. Tessari All Converted to MSWord 6.0 DNP Users Group DNP PRODUCT DOCUMENTATION DNP V3.00 TRANSPORT FUNCTIONS Document Version: 0.01 Internal File: P009-0PD.TF Associated Software Release: DNP V3.00 NOTICE OF RIGHTS - DNP USERS GROUP The contents of this manual are the property of the DNP Users Group. Revisions or additions to the definition and functionality of the Distributed Network Protocol cannot be made without express written agreement from the DNP Users Group or its duly authorized party. In addition, no part of this document may be altered or revised or added to in any form or by any means, except as permitted by written agreement with the DNP Users Group or a Party duly authorized by the DNP Users Group. As a Party, duly authorized by the DNP Users Group, Harris Corporation has made every reasonable attempt to ensure the completeness and accuracy of this document, however, the information contained in this manual is subject to change without notice, and does not represent a commitment on the part of Harris Corporation or the DNP Users Group. An update program for DNP documents is provided upon request by Harris Corporation on behalf of the DNP Users Group. TRADEMARK NOTICES Brand and product names mentioned in this document are trademarks or registered trademarks of their respective companies. DNP V3.00 Transport Functions (Version 0.01) i TABLE OF CONTENTS ABOUT THIS DOCUMENT iii PURPOSE OF THIS SPECIFICATION iii WHO SHOULD USE THIS SPECIFICATION iii HELP AND ADDITIONAL DOCUMENTATION iii HOW THIS SPECIFICATION IS ORGANIZED iv CONVENTIONS USED IN THIS SPECIFICATION iv 1. OVERVIEW 1-1 2. TRANSPORT FUNCTIONS 2-1 2.1 TRANSPORT HEADER 2-1 2.2 TRANSPORT HEADER FIELD DEFINITIONS 2-2 2.3 FRAME ASSEMBLING 2-3 2.4 TRANSMISSION OF MESSAGES 2-4 3. TRANSPORT SERVICES AND RESPONSIBILITIES 3-1 3.1 TRANSPORT FUNCTIONS 3-1 3.2 INTERFACE DESCRIPTION 3-2 LIST OF ABBREVIATIONS AND ACRONYMS DNP Users Group ii TABLE OF FIGURES FIGURE 2-1 TRANSPORT LAYER MESSAGE LAYOUT 2-2 FIGURE 2-2 TH BIT DEFINITIONS 2-2 FIGURE 2-3 ASSEMBLING OF DATA FROM THREE DATA FRAMES 2-3 FIGURE 2-4 TRANSMISSION OF A SINGLE FRAME MESSAGE 2-4 FIGURE 2-5 FRAGMENTING OF A MULTI-FRAME APPLICATION MESSAGE 2-4 DNP V3.00 Transport Functions (Version 0.01) iii ABOUT THIS DOCUMENT PURPOSE OF THIS SPECIFICATION This document specifies the Distributed Network Protocol (DNP) V3.00 Transport Functions, transmission procedures and Transport Protocol Data Unit. WHO SHOULD USE THIS SPECIFICATION This specification is intended for communication engineers and programmers interested in knowing the function and message format of the DNP V3.00 Transport Functions. This includes programmers implementing and designing DNP V3.00 Transport Functions software/hardware and quality assurance personnel testing and verifying implementations of the DNP V3.00 Transport Functions. Application programmers may find this specification useful in determining how to interface with and make use of the DNP V3.00 Transport Functions. Familiarity with the ISO-OSI 7-layer model, IEC 3-layer EPA and IEC TC-57 standards is helpful. HELP AND ADDITIONAL DOCUMENTATION The following documentation may be helpful. IEC 870-5-1 and IEC 870-5-2 standards (or drafts), Technical Committee No. 57 for data transmission in telecontrol systems DNP V3.00 Data Object Library (P009-0BL) DNP V3.00 Application Layer (P009-0PD.APP) DNP V3.00 Data Link Layer (P009-0PD.DL). DNP Users Group iv HOW THIS SPECIFICATION IS ORGANIZED 1. OVERVIEW A general overview of the transport functions. 2. TRANSPORT FUNCTIONS A detailed description of the packet formats and transmission procedures. 3. TRANSPORT SERVICES AND RESPONSIBILITIES Services provided by an interface to the transport functions. LIST OF ABBREVIATIONS AND ACRONYMS CONVENTIONS USED IN THIS SPECIFICATION In this document, the octet is a term used to refer to an eight bit-data object and is synonymous with the term byte. The low order bit of an octet is referred to as bit 0 and the high order bit as bit 7. Irregular capitalization is used in referencing technical terms which have an associated verb or noun. For example, data link indications commonly referred to as IND, can also be described using the word INDication. DNP V3.00 Transport Functions (Version 0.01) 1-1 1. OVERVIEW This document defines the Distributed Network Protocol (DNP) V3.00 Transport Functions, Transport Protocol Data Unit (TPDU), as well as transport services and transmission procedures. Master stations, submaster stations and outstations or intelligent electronic devices (IEDs) can use these transport functions to pass messages between primary (originating) stations and secondary (receiving) stations. In this protocol, master stations, submaster stations and outstations are both originators (primary stations) and receivers (secondary stations). The ISO (International Organization for Standardization) OSI (Open System Interconnection) model supported by this protocol specifies physical, data link and application layers only. This is termed the Enhanced Protocol Architecture (EPA). However, to support advanced RTU functions and messages larger than the maximum frame length as defined by the IEC (International Electrotechnical Committee) document 870-5-1, the DNP V3.00 Data Link is intended to be used with this pseudo-transport layer which implements message assembly and disassembly. This pseudo-transport layer is actually a super-data link transport protocol which is normally found as part of some OSI data links. However, because the IEC data link (DNP V3.00 Data Link Layer) does not support these functions in the data link, it is necessary to move them out of the data link in order to maintain compliance. DNP V3.00 Transport Functions (Version 0.01) 2-1 2. TRANSPORT FUNCTIONS This section describes the Transport layer functions which act as a pseudo-transport layer to the DNP data link layer. The pseudo-transport layer function is specific only for those messages that are larger than one Link Protocol Data Unit (LPDU) between primary and secondary stations. This pseudo-transport layer acts as the DNP data link user in a protocol stack consisting of only the DNP Data Link and DNP Application Layer. This functionality allows the pseudo-transport layer to disassemble one Transport Service Data Unit (TSDU) into multiple (more than one) Transport Protocol Data Units (TPDUs), or frames, and assemble multiple (more than one) TPDUs into one TSDU. This process works as follows: The pseudo-transport layer takes one TSDU (user data) and breaks it into several sequenced TPDUs (each with Transport Protocol Control Information (TPCI)). Each TPDU is sent to the data link layer as Link Service Data Unit (LSDU) for transmission. It also works in the reverse fashion. The pseudo-transport layer receives multiple TPDUs from the data link layer and assembles them into one TSDU. LSDUs are user data fragments which are small enough to fit into the defined FT3 frame format. When a primary station transmits a message to a secondary station, the transport functions break the message into LSDUs. These functions add a Transport layer Header (TH) octet at the beginning of the user data fragments that contain the information for the secondary station to reconstruct the complete message. All pseudo-transport layer messages have a TH. The secondary station checks the TH octet on reception of each LSDU for the correct sequence and builds a TSDU message for higher layers. The TH contains information that can identify the first frame, last frame and give every frame a six-bit sequence number. This information is required to reconstruct a message and also to guard against higher layers from receiving misdirected or incomplete messages. 2.1 TRANSPORT HEADER After the data link receives a complete frame, the data is presented to the transport functions in a format illustrated below. The TH field is stripped out before the frame is combined with other frames belonging to the same message. Figure 2-1 shows the structure of a TPDU. ----------------- | | | DNP Users Group 2-2 | TH | USER DATA | | | | ----------------- Figure 2-1 Transport Layer Message Layout TH Transport control octet. One octet in length. USER DATA 1 to 249 octets in length. When an application requests the transmission of a long message, the message is broken into fragments small enough to fit in a single DNP V3.00 Data Link frame. The maximum size of a fragment is 249 octets of user data. The TH is added to the head of the fragment and the maximum number of octets to be framed becomes 250 octets. Maximum data link data count + 255 octets Data link header data count - 5 octets Transport header - 1 octet Application user data = 249 octets 2.2 TRANSPORT HEADER FIELD DEFINITIONS ----------------------------------------------- | | | | | | | | | | FIN | FIR | | | SEQUENCE | | | | | | | | | | | | ----------------------------------------------- BIT 7 6 5 4 3 2 1 0 Figure 2-2 TH Bit Definitions FIN The final bit indicates that this frame of user data is the last frame of a sequence which compromises a complete user message. FIN = 0 More frames follow. 1 Final frame of a sequence. FIR The first bit indicates that the frame is the first in a sequence of frame(s) which comprise a complete message. When a secondary station receives a frame with the FIR bit set, all previously received unterminated frame sequences are discarded. The first frame of a sequence may have any sequence from 0 to 63. If a frame is received without the FIR bit set and no message sequence is currently in progress, then the frame is ignored. If a complete user message is only one frame in length, both the FIR and FIN bits are set. FIR = 1 First frame of a sequence. 0 Not the first frame of a sequence. DNP V3.00 Transport Functions (Version 0.01) 2-3 SEQUENCE The sequence number of the frame is used to check that each frame is being received in sequence. It guards against missing or duplicated frames. All user messages start off with a sequence specified in the first frame which has the FIR bit set (each message may start with any sequence number between 0 and 63). After sequence number 63 the next sequence number will be 0. The sequence number increments for each frame sent to or received from the same address belonging to the same message and resets at the beginning of a new message. The sequence number does not have to increment across message boundaries, i.e. any sequence number is valid when the FIR bit is set. 2.3 FRAME ASSEMBLING Figure 2-3 illustrates the assembling of a three-frame message. The first frame of the message identified by having the FIR bit set in the TH field. The last frame is identified by having the FIN bit set in the TH field. USER DATA FRAMES TRANSPORT DATA BUFFER
-------------- | SOURCE = n | -------------- -------------- | FIR = 1 | | FIN = 0 | | SEQUENCE = 3| Note sequence starts with the value in the frame that has the FIR bit = 1 | USER DATA 0 | -------------- -----------> ------------- | USER DATA 0 | ------------- -------------- | SOURCE = n | -------------- -------------- | FIR = 0 | | FIN = 0 | | SEQUENCE = 4| | USER DATA 1 | -------------- -----------> ------------- | USER DATA 1 | ------------- | USER DATA 0 | ------------- -------------- | SOURCE = n |-----------------------------------> -------------- SOURCE ADDRESS passed to application -------------- | FIR = 0 | | FIN = 1 | FIN indicates last frame | SEQUENCE = 5| | USER DATA 2 | -------------- -----------> ------------- | USER DATA 2 | FIN indicated this is the last frame of message ------------- | USER DATA 1 | ------------- | USER DATA 0 | complete message passed to application ------------- -----------> Figure 2-3 Assembling of Data From Three Data Frames DNP Users Group 2-4 2.4 TRANSMISSION OF MESSAGES Figure 2-4 illustrates the transmission of a single frame message using the SEND - CONFIRM frame service. Figure 2-5 illustrates the transmission of a multi-frame message using the SEND - CONFIRM frame service. FRAMES SENT FROM DATA LINK COMPLETE MESSAGE FROM APPLICATION CONFIRM FRAMES RECEIVED --------------- | DESTINATION | parameter from application --------------- --------------- | USER DATA | | | | 30 octets | --------------- -------------- | DESTINATION | parameter to data link -------------- -------------- | FIR = 1 | | FIN = 1 | 1 TH octet | SEQUENCE = 1 | | USER DATA 0 | send 30 user octets plus 1 TH = 31 octets SEND <----- -------------- CONFIRM -------> --------------------> SUCCESS to application layer Figure 2-4 Transmission of a Single Frame Message -------------- | DESTINATION | parameter from application -------------- -------------- | USER DATA | | | | 598 octets | -------------- -------------- | DESTINATION | parameter to data link -------------- -------------- | FIR = 1 | | FIN = 0 | 1 TH octet | SEQUENCE = 2 | | USER DATA 0 | send 249 octets (1 to 249 is the valid range for this count) SEND <------- -------------- CONFIRM --------> -------------- | DESTINATION | parameter to data link -------------- -------------- | FIR = 0 | | FIN = 0 | | SEQUENCE = 3 | | USER DATA 1 | send 249 octets SEND <------- -------------- CONFIRM --------> -------------- | DESTINATION | parameter to data link -------------- -------------- | FIR = 0 | | FIN = 1 | | SEQUENCE = 4 | | USER DATA 2 | send last 100 octets (249 + 249 + 100 = 598) SEND <------- -------------- CONFIRM --------> --------------------> SUCCESS to application layer Figure 2-5 Fragmenting of a Multi-Frame Application Message DNP V3.00 Transport Functions (Version 0.01) 3-1 3. TRANSPORT SERVICES AND RESPONSIBILITIES 3.1 TRANSPORT FUNCTIONS This section describes the services offered by the pseudo-transport layer and its function. The communication requirements of the network layer and the application layer are satisfied by the pseudo-transport layer service primitives. The pseudo-transport layer is responsible for performing the following functions: Packing user data into multiple frames (more than one) of the defined DNP V3.00 Data Link frame format and using the services of the DNP V3.00 Data Link for transmitting the data Unpacking multiple frames that are received from the data link into user data Controlling all aspects of the data link excluding data link configuration. The pseudo-transport layer is responsible for providing the following services: Exchange of SDUs between peer DNP V3.00 pseudo-transport layers Error notification to transport user Sequencing of SDUs Prioritized SDU delivery Quality SDU delivery. SDUs will only be exchanged between peer DNP V3.00 pseudo-transport layers. Error notification is given to the transport user when a response to a request has not been received. Priority delivery can be set to EXPEDITED or NORMAL to indicate a high or low priority request. Quality delivery can be set to SEND-NO-REPLY or SEND-CONFIRM to indicate whether or not message acknowledgment is required. DNP Users Group 3-2 3.2 INTERFACE DESCRIPTION The pseudo-transport layer service primitives are illustrated in pseudo code to illustrate the requirements and behavior in a real implementation and are not intended as an exact interface definition. Transport request (REQ) services can be used at any time after the transport functions have been initialized and configured by the system. confirm = request_transport_service( SERVICE, TIME_SERVICE, destination, source, send_data_buffer, send_count, retry_flag, time_of_transmission) Input: SERVICE Service to perform. TIME_SERVICE Guaranteed time service to perform. source Source address to use in sent message. destination Destination address to use in sent message. send_data_buffer Data to send in message. send_count Number of octets in message. retry_flag Instructs data link layer to retry unacknowledged frames or not. time_of_transmission Time that first bit of first octet of message is to be sent. Output: time_of_transmission Time that first bit of first octet of message was sent confirm = 0 Requested service is successful. 1 Requested service has failed. 2 Requested SEND data service is terminated by the current primary station. (reception of a NACK frame from the secondary station). 3 Service code is not implemented. 4 Requested service cannot proceed at this time because the data link is busy either with a previous requested transaction, current unrequested transaction or waiting for physical layer availability. DNP V3.00 Transport Functions (Version 0.01) 3-3 service = 0 Send a message specified in parameters using SEND-CONFIRM frames. Fails if the data link is busy. 1 Send a message specified in parameters using SEND-NO- REPLY frames. Fails if the data link is busy. 2 Expedited send a message specified in parameters using SEND- CONFIRM frames. May necessitate canceling the current secondary transaction if a half-duplex system is used.(i.e. forces the data link to send a NACK frame instead of a CONFIRM frame in the next secondary transaction). This action only takes place if the primary station is using SEND-CONFIRM frames. 3 Expedited send a message specified in parameters using SEND- NO-REPLY expected frames. In a half-duplex system, this may mean canceling the current secondary transaction. (as above). 4 Return link status. Return successful if the data link is not busy. time_service = 0 Send message at time specified in time_of_transmission. This service should have the highest priority. 1 Send message at any time with priority specified. Data link indications (IND) can be requested at any time by the service user but should be checked as often as possible in order to obtain received data. indications = request_data_link_indications( source_address, destination_address, received_data_buffer, received_data_count, time_of_reception) Output: source_address Source address of received message. destination_address Destination address of received address. received_data_buffer Received message. received_data_count Number of octets in message. time_of_reception Time at which first bit of first octet of message was received. DNP Users Group 3-4 Indications = 0 No indications to report. 1 Data link has received a valid message that has been placed in received_data_buffer and the number of octets received has been placed in received_data_count. The source address of the received message has been placed in source_address. If the data link is configured as a master station then the time that the first bit of the first octet of the message was received has been placed in time_of_reception. If the data link is configured as an outstation then the time_of_reception will still be returned but the service user has to be aware of the possibility of inaccurate times received before the outstation has been time-synchronized. 2 Pseudo-transport layer has detected a transaction failure. DNP V3.00 Transport Functions (Version 0.01) 1 LIST OF ABBREVIATIONS AND ACRONYMS CRC cyclic redundancy check DNP Distributed Network Protocol EPA enhanced protocol architecture IEC International Electrotechnical Commission ISO International Organization for Standardization octet 8-bit data object (byte) OSI Open System Interconnection RTU remote terminal unit