DOCUMENT REVISION HISTORY
Name of Document: DNP V3.00 Application Layer Protocol Description
Network File Name: P009-0PD.APP
Original Author: Malcolm Smith/Jim McFadyen
Date and Version of Preliminary Release: August 7, 1991 Version 0.00
Associated Software Release(s): DNP V3.00
Revisions Since Preliminary Release
Date Version By Whom: Pages Affected:
Reason for Changes:
Sept. 30/91 0.00A NFM All Document renamed and relocated from
O:\Document\Other\DOC0362.wp to
P009-0FS.APP Reformatted to WI
standards
Nov. 11/91 0.00B J. McFadyen Corrections
Nov. 18/91 0.00C J. McFadyen Minor corrections
Jan. 13/92 0.01A J. McFadyen Section 3 Addition of Application Control fields
Apr. 30/92 0.01B NFM All Minor fixes per J. McFadyen.
Jul. 24/92 0.01C MCH 3-11 Reversed MSB and LSB in Figure 3-7
as per J. McFadyen.
Sep. 8/92 0.02A M. Smith ALL Re-design of qualifier, clarification of
function code usage, added support of
multi-fragment objects, changed
terminology to match IEC definitions.
Oct. 22/92 0.02B M.Smith Time-sync Removed all references to TIME-
SYNCHRONIZATION in the Application
Layer as this is a Data Link function.
Oct. 27/92 0.02C M.Smith Section 3 Re-defined Application Control (AC)
octet to handle sequencing of fragments
and added diagrams to illustrate this.
Changed name of document.
Nov.8/92 0.02D MS Sections 3, 4 Re-added TIME-SYNC and made some
technical corrections.
Nov.25/92 0.03 LA All Reformatted to WI standards.
July 7/93 0.03 P. Morton All Reformatted, added chapters.
Jul.21/93 0.03 J. Bhat All Removed Section 9, Reformatted.
Aug.20/93 0.03 J. Bhat All Re-edited and reformatted.
Aug.30/93 0.03 J. Bhat All Re-edited and reformatted.
Sept.01/93 0.03 AV All Format check, glossary, footers.
May 28/97 0.03 S. Tessari All Converted to MS Word 6.0
DNP Users Group
DNP PRODUCT DOCUMENTATION
DNP V3.00 APPLICATION LAYER
Document Version: 0.03
Internal File: P009-0PD.APP
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.
TABLE OF CONTENTS
ABOUT THIS DOCUMENT ix PURPOSE OF THIS SPECIFICATION ix WHO SHOULD USE THIS SPECIFICATION ix HELP AND ADDITIONAL DOCUMENTATION ix HOW THIS SPECIFICATION IS ORGANIZED x CONVENTIONS USED IN THIS SPECIFICATION x
1. OVERVIEW 1-1 1.1 DESCRIPTION AND IEC RELATIONSHIP 1-2
2. MESSAGE FORMATS 2-1 2.1 APPLICATION REQUEST FORMAT 2-2
2.2 APPLICATION RESPONSE FORMAT 2-2
3. DEFINITION OF DNP MESSAGE FIELDS 3-1 3.1 APPLICATION HEADERS 3-1 3.2 COMMUNICATION FLOW CONTROL 3-2 3.3 MASTER REQUEST & UNSOLICITED RESPONSE COLLISIONS 3-8 3.4 ERROR RECOVERY 3-11 3.5 FUNCTION CODES 3-12 3.6 INTERNAL INDICATIONS 3-14
3.7 OBJECT HEADER 3-16
4. DETAILED FUNCTION CODE DESCRIPTIONS 4-1 4.1 CONFIRM (FUNCTION CODE 0) 4-1 4.2 READ (FUNCTION CODE 1) 4-2 4.3 WRITE (FUNCTION CODE 2) 4-14 4.4 SELECT (FUNCTION CODE 3) 4-16 4.5 OPERATE (FUNCTION CODE 4) 4-18 4.6 DIRECT OPERATE (FUNCTION CODE 5) 4-19 4.7 DIRECT OPERATE - NO ACKNOWLEDGEMENT (FUNCTION CODE 6) 4-19 4.8 IMMEDIATE FREEZE (FUNCTION CODE 7) 4-20 4.9 IMMEDIATE FREEZE - NO ACKNOWLEDGEMENT (FUNCTION CODE 8)4-20 4.10 FREEZE AND CLEAR (FUNCTION CODE 9) 4-20 4.11 FREEZE AND CLEAR - NO ACKNOWLEDGEMENT (FUNCTION CODE 10)4-21 DNP V3.00 Application Layer (Version 0.03)v
4.12 FREEZE WITH TIME (FUNCTION CODE 11) 4-21 4.13 FREEZE WITH TIME - NO ACKNOWLEDGEMENT (FUNCTION CODE 12)4-22 4.14 COLD RESTART (FUNCTION CODE 13) 4-22 4.15 WARM RESTART (FUNCTION CODE 14) 4-23 4.16 INITIALIZE DATA (FUNCTION CODE 15) 4-23 4.17 INITIALIZE APPLICATION (FUNCTION CODE 16) 4-24 4.18 START APPLICATION (FUNCTION CODE 17) 4-25 4.19 STOP APPLICATION (FUNCTION CODE 18) 4-25 4.20 SAVE CONFIGURATION (FUNCTION CODE 19) 4-26 4.21 ENABLE SPONTANEOUS MESSAGES (FUNCTION CODE 20) 4-26 4.22 DISABLE SPONTANEOUS MESSAGES (FUNCTION CODE 21) 4-27 4.23 ASSIGN CLASSES (FUNCTION CODE 22) 4-27
4.24 DELAY MEASUREMENT (FUNCTION CODE 23) 4-28
5. CLASSES 5-1
6. TIME SYNCHRONIZATION 6-1
7. BINARY INPUT WITH TIME EVENTS 7-1
8. FILE TRANSFER 8-1 8.1 FILE IDENTIFIER OBJECTS PERFORMING WRITE FUNCTIONS 8-1 8.2 FILE IDENTIFIER OBJECT PERFORMING READ FUNCTIONS 8-5 LIST OF ABBREVIATIONS AND ACRONYMS
vi
DNP Users Group
TABLE OF FIGURES
FIGURE 1-1 CONTEXT OF EPA 1-2 FIGURE 2-1 MESSAGE SEQUENCE 2-1 FIGURE 2-2 APPLICATION REQUEST FORMAT 2-2 FIGURE 2-3 APPLICATION RESPONSE FORMAT 2-3 FIGURE 3-1 REQUEST HEADER 3-1 FIGURE 3-2 RESPONSE HEADER 3-1 FIGURE 3-3 APPLICATION CONTROL FIELD 3-2 FIGURE 3-4 TYPICAL MESSAGE TRANSACTION FLOW 3-4 FIGURE 3-5 MULTI-FRAGMENT RESPONSE & RTU CONFIRMATION TIMEOUT 3-5 FIGURE 3-6 MESSAGE TRANSACTIONS WITH RESPONSE TIMEOUTS 3-6 FIGURE 3-7 MESSAGE FLOW WHEN RESPONSE DELAYED ON A
NETWORK 3-7 FIGURE 3-8 RESENDING UNSOLICITED RESPONSES DUE TO NETWORK DELAYS 3-7 FIGURE 3-9 SIMULTANEOUS TRANSMISSIONS, IMMEDIATE_PROCESS MODE 3-9 FIGURE 3-10 SIMULTANEOUS TRANSMISSIONS, IMMEDIATE_PROCESS MODE 3-10 FIGURE 3-11 SIMULTANEOUS TRANSMISSIONS, PROCESS_AFTER_CONFIRM MODE 3-11 FIGURE 3-12 OBJECT HEADER 3-16 FIGURE 3-13 OBJECT FIELD 3-17 FIGURE 3-14 QUALIFIER FIELD 3-18 FIGURE 3-15 MESSAGES WITHOUT DATA OBJECTS 3-23 FIGURE 3-16 MESSAGES WITH DATA OBJECTS 3-26 FIGURE 4-1 CONFIRMATION MESSAGE 4-1 FIGURE 4-2 SINGLE OBJECT REQUEST 4-3 FIGURE 4-3 MULTIPLE OBJECTS OR RANGES 4-3 FIGURE 4-4 SINGLE OBJECT RANGE WRITE 4-15 FIGURE 4-5 MULTIPLE OBJECT OR MULTIPLE RANGES 4-15 FIGURE 4-6 MASTER SELECTION OF TWO CONTROL OR ANALOG OUTPUTS 4-17 FIGURE 4-7 OUTSTATION RESPONSE 4-17 FIGURE 4-8 MASTER SELECTION OF A PATTERN OUTPUT 4-17 FIGURE 4-9 OUTSTATION RESPONSE TO THE PATTERN SELECT
MESSAGE 4-18 FIGURE 4-10 MASTER SELECTION OF TWO OUTPUTS OR SETPOINTS 4-18 DNP V3.00 Application Layer (Version 0.03)vii
FIGURE 4-11 OUTSTATION RESPONSE 4-18
FIGURE 4-12 MASTER SELECTION OF TWO OUTPUTS OR SETPOINTS 4-19
FIGURE 4-13 OUTSTATION RESPONSE 4-19
FIGURE 4-14 MASTER SELECTION OF TWO OUTPUTS OR SETPOINTS 4-19
FIGURE 4-15 MASTER IMMEDIATE FREEZE CONTROL MESSAGE 4-20
FIGURE 4-16 OUTSTATION RESPONSE TO IMMEDIATE FREEZE 4-20
FIGURE 4-17 MASTER IMMEDIATE FREEZE NO-ACK CONTROL MESSAGE 4-20
FIGURE 4-18 MASTER FREEZE AND CLEAR CONTROL MESSAGE 4-21
FIGURE 4-19 OUTSTATION RESPONSE TO FREEZE AND CLEAR REQUEST 4-21
FIGURE 4-20 MASTER FREEZE AND CLEAR NO-ACK CONTROL MESSAGE 4-21
FIGURE 4-21 MASTER FREEZE WITH TIME MESSAGE 4-22
FIGURE 4-22 OUTSTATION RESPONSE TO FREEZE WITH TIME 4-22
FIGURE 4-23 MASTER FREEZE WITH TIME NO-ACK MESSAGE 4-22
FIGURE 4-24 MASTER COLD RESTART CONTROL MESSAGE 4-23
FIGURE 4-25 OUTSTATION RESPONSE TO COLD RESTART REQUEST 4-23
FIGURE 4-26 MASTER WARM RESTART CONTROL MESSAGE 4-23
FIGURE 4-27 OUTSTATION RESPONSE TO WARM RESTART REQUEST 4-23
FIGURE 4-28 MASTER INITIALIZE DATA CONTROL MESSAGE 4-24
FIGURE 4-29 OUTSTATION RESPONSE TO INITIALIZE DATA REQUEST 4-24
FIGURE 4-30 MASTER INITIALIZE APPLICATION CONTROL MESSAGE 4-24
FIGURE 4-31 OUTSTATION RESPONSE AFTER INITIALIZING
APPLICATION(S) 4-24 FIGURE 4-32 MASTER START APPLICATION CONTROL MESSAGE 4-25
FIGURE 4-33 OUTSTATION RESPONSE AFTER STARTING
APPLICATION(S) 4-25 FIGURE 4-34 MASTER STOP APPLICATION CONTROL MESSAGE 4-25
FIGURE 4-35 OUTSTATION RESPONSE AFTER STOPPING
APPLICATION(S) 4-26 FIGURE 4-36 MASTER SAVE CONFIGURATION CONTROL MESSAGE 4-26
FIGURE 4-37 OUTSTATION RESPONSE AFTER SAVING
CONFIGURATION(S) 4-26 FIGURE 4-38 MASTER REQUEST TO ENABLE SPONTANEOUS MESSAGES 4-27
FIGURE 4-39 OUTSTATION RESPONSE 4-27
FIGURE 4-40 MASTER REQUEST TO DISABLE SPONTANEOUS MESSAGES 4-27
FIGURE 4-41 OUTSTATION RESPONSE TO DISABLE SPONTANEOUS
MESSAGE 4-27
FIGURE 4-42 MASTER REQUEST TO ASSIGN CLASSES TO DATA 4-28
FIGURE 4-43 OUTSTATION RESPONSE TO ASSIGN CLASSES 4-28
FIGURE 4-44 MASTER REQUEST TO INITIATE DELAY MEASUREMENT 4-28
FIGURE 4-45 OUTSTATION REPONSE TO DELAY MEASUREMENT
REQUEST 4-29
FIGURE 8-1 PASSING A FILE IDENTIFIER OBJECT VIA DATA
CONCENTRATORS 8-4
viii
DNP Users Group
ABOUT THIS DOCUMENT
PURPOSE OF THIS SPECIFICATION
This document specifies the Distributed Network Protocol (DNP) application layer services and message format. This document specifies the Application Protocol Data Unit (APDU), application data flow control and any specific information pertaining to DNP application layer services.
WHO SHOULD USE THIS SPECIFICATION
This specification is for people who need to know the structure and meaning of the fields that make up the application layer message.
This includes programmers implementing and designing an application and Quality Assurance personnel testing and verifying implementations of the application layer. HELP AND ADDITIONAL DOCUMENTATION
The following documentation may be helpful.
? DNP V3.00 Data Object Library (P009-0BL).
DNP V3.00 Application Layer (Version 0.03)ix
HOW THIS SPECIFICATION IS ORGANIZED
1. OVERVIEW
A general overview of the application layer.
2. MESSAGE FORMATS
A definition of the request and response formats.
3. DEFINITION OF THE DNP MESSAGE FIELDS
A detailed explanation of the message field.
4. DETAILED FUNCTION CODE DESCRIPTION
A description of the function codes.
5. CLASSES
A description of the classes.
6. TIME SYNCHRONIZATION
A description of time synchronizing.
7. BINARY INPUT WITH TIME EVENTS
A description of binary input with time events.
8. FILE TRANSFER
A description of file transfer.
LIST OF ABBREVIATIONS AND ACRONYMS
CONVENTIONS USED IN THIS SPECIFICATION
The term octet used in this document refers to an eight-bit data object and is synonymous with the term byte. The low order bit of an octet is numbered as bit zero (0) and the high order is bit seven (7). Data octets illustrated in this document are received and transmitted from left to right.
x
DNP Users Group
1. OVERVIEW
This document defines the Harris Distributed Network Protocol (DNP) application layer APDU format and services.
The ISO OSI (International Standards Organization Open System Interconnection) model specifies seven layers. The International Electrotechnical Commission (IEC) specifies a simplified model consisting of the physical, data link and application layers only. This is termed the Enhanced Performance Architecture (EPA). This document defines the third layer of this EPA or the Application Layer. The data link layer is defined in:
Distributed Network Protocol Version 3.00:Data Link Layer (P009-0PD.DL).
Harris Canada Inc. has developed the DNP for application in both SCADA and distributed automation (DA) systems. Primary focus has been on the current and future needs of these areas. The DNP is suitable for use in highly secure, moderate speed and moderate throughput applications. The protocol is highly flexible and open-ended without any target hardware specific constructs.
Figure 1-1 on the following page shows the EPA structure and how it fits into the entire communication system. As shown, the User Layer interfaces to the Application Layer in one place only implying that the user has no need to know of the other elements of the communication system except the Application Layer interface. The User Layer makes use of the Application Layer to send/receive complete SCADA/DA messages to/from a master station or outstation.
DNP V3.00 Application Layer (Version 0.03)1-1
Figure 1-1 Context of EPA
1.1 DESCRIPTION AND IEC RELATIONSHIP
The DNP Application Layer APDU is based in principle on the IEC 870-5-3 and 870-5-4 draft documents as prepared by TC-57 WG 03. Structurally, the Application Layer PDU (Protocol data Unit) fits the IEC description of an APDU. The user sends Application User Data to the Application Layer where it is converted to ASDU (Application Service Data Unit). In DNP, the Application User Data is converted into multiple ASDUs. Each ASDU is then prefixed by APCI (Application Protocol Control Information) which is then packaged as an APDU. In DNP, each APDU that is part of the larger multi-APDU is referred to as a fragment and there is a restriction that each fragment contains complete data objects only and that the function code portion of the APCI (Application Protocol Control Information) is identical in each fragment of the same message or multi-APDU. That is, there will be no fragmentation of information objects between APDUs and the same operation must be requested of each object in the message. This is to ensure that each fragment on its own can be processed and also implies that each ASDU contains only complete data objects. In reverse, the Application Layer receives multiple APDU (one at a time) where it removes the APCI to obtain the ASDU and assembles the ASDUs into Application User Data.
1-2
DNP Users Group
2. MESSAGE FORMATS
This section defines the formats of the application layer messages (APDU). The terms APDU and fragment are interchangeable. In this specification the master station is defined as the station sending a request message and the Outstation is the slave device, Remote Terminal Unit (RTU) or Intelligent End Device (IED) to which the requested messages is destined. In DNP, only designated master stations can send Application Layer request messages and only Outstations can send Application Layer Response messages.
Figure 2-1 below shows the sequence of Application Layer messages between one master and one Outstation.
Master
Outstation
Send Request --------------------> Accept request and process
confirmation
Optional
<--------------------
Accept response <----------------- Send Response
Optional confirmation --------------------------------->
detected
change
Important
Accept response <----------------- Send Unsolicited Response
Optional confirmation --------------------------------->
Figure 2-1 Message Sequence
As shown above, the master station sends an Application Layer Request to the outstation which returns an Application Layer Response. The outstation can decide to spontaneously transmit data using an Application Layer Unsolicited Response message. For a master, a request/response transaction with a particular outstation must be completed before another requests can be sent to that outstation. A master station may accept unsolicited responses while the request transaction is in progress. For an outstation, a request/response transaction must be completed before any other requests are accepted or unsolicited responses are sent. Unsolicited responses can be sent before or after the request/response transaction but not during. If an outstation is presently in the middle of an unsolicited transaction (i.e. waiting for a confirmation), it may conditionally accept one request command from the master. (For detailed information, see Section 3.3 - Master Request and Unsolicited Response Collisions).
In addition, each response or request can consist of 1 or more individual fragments. Each fragment however should be digestible (parsable) and therefore executable (because
DNP V3.00 Application Layer (Version 0.03)2-1
the function code is part of every fragment). It is advised that devices with limited message storage capabilities should only be sent single fragment message requests when the expected response (from all fragments sent) is larger than one fragment. This is to ensure that devices can process a request and build and more importantly send a response before the next request is received. Otherwise, multi-fragment messages may require multi-fragment responses which may require more message storage than the device has available.
2.1 APPLICATION REQUEST FORMAT
The application request message format (APDU) is illustrated in Figure 2-2. The APDU is made up of an APCI block which contains message control information and an ASDU which contains information to be processed by the receiving station. The APCI is often called a request header in an application request message. In DNP, the ASDU is optional and is used when the message meaning is not conveyed completely in the request header. The request header contains information on how to assemble a multi-fragment message and on the purpose of the message. The request header is present in all application layer request APDUs. If the request header implies all the needed information required to carry out the request, the ASDU is not present.
Each ASDU consists of one or more Data Unit Identifiers (DUI) or object headers and optional associated Information Objects (IO) or data fields. The object header can specify 0 or more en that returned by the receiving station or that follow the header in the message.
│ DUI │ IO .. IO │ DUI │ IO │
┌────────────────┼────────────────┼──────┐ ....├───────────────┼──────┤
│ Request Header │ Object Header │ data ││ Object Header │ data │
│││││││
├────────────────┼────────────────┴──────┘.....└───────────────┴──────┤
│ APCI │ ASDU │
Figure 2-2 Application Request Format
Request Header The request header identifies the purpose of the message and
consists of APCI (Application Protocol Control Information). Object Header This header identifies the data objects that follow.
Data Data object(s) of the type specified in the object header.
2.2 APPLICATION RESPONSE FORMAT
The response from an Outstation to an application layer request APDU or the unsolicited response from an outstation have the format illustrated in Figure 2-3. The format is identical in form to the request. The APCI is often called a response header in an application response message. The response header contains the same information as the request header plus an additional field containing internal indications of the outstation. The response header is always part of the application response. The response ASDU has
2-2
DNP Users Group
the same format of the request message with one notable exception (explained in Section 3).
│ DUI │ IO .. IO │ DUI │ IO │
┌────────────────┼────────────────┼──────┐ ....├───────────────┼──────┤
│ Response Header│ Object Header │ data ││ Object Header │ data │
│││││││
├────────────────┼────────────────┴──────┘.... └───────────────┴──────┤
│ APCI │ ASDU │
Figure 2-3 Application Response Format
Response Header The response header identifies the purpose of the message and
consists of APCI (Application Protocol Control Information). Object Header This header identifies the data objects that follow.
Data Data object(s) of the type specified in the object header.
DNP V3.00 Application Layer (Version 0.03)2-3
2-4
DNP Users Group
3. DEFINITION OF DNP MESSAGE FIELDS
This section describes the request and response headers (APCIs) which control the sequence and flow of application messages between a master station and an Outstation, and the ASDU which include DUI or data object headers. The headers are used to assemble multi-fragment (multi-APDU) messages into Application User Data. The object headers are used to identify uniquely the information object(s) that optionally follow the header.
3.1 APPLICATION HEADERS
3.1.1 Request Header
The request header or APCI has two fields. Each field is one octet in length and is illustrated below.
┌─────────────────────┬───────────────┐
│ Application Control │ Function Code │
│ AC │ FC │
└─────────────────────┴───────────────┘
Figure 3-1 Request Header
3.1.2 Response Header
The response header has three fields as illustrated below.
┌─────────────────────┬───────────────┬──────────────────────┐
│ Application Control │ Function Code │ Internal Indications │
│ AC │ FC │ IIN │
││││
└─────────────────────┴───────────────┴──────────────────────┘
Figure 3-2 Response Header
3.1.3 Application Control
The application control field has a size of one octet. It provides information needed to construct multi-fragment application messages.
DNP V3.00 Application Layer (Version 0.03)3-1
Application messages may be packaged into fragments, with each fragment small enough to fit into the application's message buffer. The recommended size of the fragment buffer is 2048 bytes in order to maintain compatibility with current DNP devices. Each fragment has an application header and appropriate object headers so that each fragment can be processed as individual messages which can then be discarded making room for the next fragment.
7 6 5 4 3 2 1 0 bit
┌───────┬───────┬────────┬───────────────────────┐
│ FIR │ FIN │ CON │ SEQUENCE │
│││││
└───────┴───────┴────────┴───────────────────────┘
Figure 3-3 Application Control Field
FIR If set to one (1), this bit indicates the message fragment is the first fragment of a complete application message.
FIN If set to one (1), this bit indicates the message fragment is the final fragment of a complete application message.
CON If set to one (1) in a received message, indicates the sending application is expecting a confirmation from the receiving application of the reception of the
fragment. An application function code zero (0) is used in the confirmation
message.
SEQUENCE Indicates the fragment number. Fragment numbers 0 to 15 are reserved for master station requests and all Outstation responses (NOT Unsolicited
Responses). Fragment numbers 16 to 31 are reserved for unsolicited
responses from Outstations. For unsolicited responses, each consecutive
fragment from an Outstation must have an increasing sequence number
(the number overflows from 31 to 16). For requests to an Outstation and
the Outstation responses (not unsolicited responses), each consecutive
fragment received from or transmitted to the same Outstation must have
an increasing sequence number (the number overflows from 15 to 0).
Unsolicited Response is a message generated by an Outstation, NOTE: An
usually containing event data, which is sent automatically to the master.
The master does not need to poll the Outstation for this data.
NOTE:It is recommended that any changed data that is reported from an
Outstation be sent with a confirmation requested in the response.
3.2 COMMUNICATION FLOW CONTROL
The flow of requests and responses between the master and the Outstation is controlled by fields in the response and request headers as well as application timers and parameters. The fields, timers and parameters controlling message flow are:
3-2
DNP Users Group
1) CON bit field. Setting/clearing this bit enables/disables message CONFIRMation
responses. A CONFIRMation response is an application acknowledgments of the previous request or response message.
2) FIR and FIN bit fields.
3) Sequence Number field. This number is used to assemble multi-fragment
messages and identify which responses match particular requests.
4) Master station and Outstation application response time-outs. These specify how
long an application must wait for a response or CONFIRMation response before
re-transmitting or aborting the transaction. The application may or may not
support re-transmission of transactions at the application layer.
5) Master station and Outstation application retry count. Applications may or may
not support application level retries. Retry counters specify how many times a
request is repeated if a response fails, or how often responses are re-transmitted if
a CONFIRMation response is not received.
An Outstation must completely process a request and respond to it before beginning to process a second request. It cannot simultaneously process multiple requests.
The Sequence Number for all requests from the master station to the Outstation is in the range 0 to 15 inclusive. The sequence number for all Unsolicited Responses from the Outstation is in the range 16 to 31 inclusive.
The following rules dictate how sequence numbers work:
? The sequence number rolls over from 15 to 0 or from 31 to 16. Each successive request fragment from the DNP master station has an incremented sequence number.
The exception is for retries on requests. For single fragment request retries, the
sequence number is NOT incremented. For multi fragment request retries, the
sequence number of the first fragment of the request retry equals the sequence number of the last fragment of the request which has just failed.
? A single fragment response to a single fragment request has the same sequence number as the request.
? The CONFIRMation response to a request or response has the same sequence number as the request or response.
? The first fragment of a multi-fragment response to a single fragment request has the same sequence number as the request. For successive fragment of the multi-fragment response, the sequence number is incremented.
? The first fragment of a multi-fragment response to a multi-fragment request has the same sequence number as the last fragment of the multi-fragment request.
The use of this sequence number scheme ensures the Outstation and master station can cope with all occurrences of messages being lost or delayed on a communication network. The following rules are obeyed by both the Outstation and master station: ? If the system uses application level retries, when a response is not received before time-out, the request will be re-transmitted with the same sequence number.
DNP V3.00 Application Layer (Version 0.03)3-3
? If two messages are received with the same sequence number, it usually means that the response to the message was not received by the other station. In this case, retransmit the response (re-processing the message is unnecessary).
? If two CONFIRMation responses are received with the same sequence number, ignore the second response.
The following figures illustrate some cases of message transactions and how the Sequence Numbers prevent problems. In the examples, SEQ is the Sequence Number and CON is the Confirmation Requested bit in the message. Time progresses from left to right in the diagrams. The vertical arrows represent the flow of messages between the Outstation and the master station.
Case One illustrates typical message transactions. The master sends a request, the Outstation responds and the master CONFIRMs the response. Later on, the Outstation sends an Unsolicited Response to the master station. When the Outstation transmits the response, it starts a CONFIRMation response timer. If this timer had expired before the CONFIRMation was received, the Outstation would have re-transmitted the response. Case Two shows a similar situation to Case One except the master request requires a CONFIRMation response as well as a normal response.
CASE 1
Time
────────────────────────────────────────────────────────────→
Master │ Request. ││
│ Response │ CONFIRM │ CONFIRM
│ expected. │ (SEQ=7) │ (SEQ=24)
│ (CON=0) ││
│ (SEQ=7) ││
--------------------------------------------------------------------
Outstation
│ Response │ Unsol.
│ to master │ Response
│ (CON=1) │ (CON=1)
│ (SEQ=7) │ (SEQ=24)
││
CASE 2
Time
────────────────────────────────────────────────────────────→
Master │ Request. │
│ Response │ CONFIRM
│ expected. │ (SEQ=2)
│ (CON=0) │
│ (SEQ=2) │
--------------------------------------------------------------------
Outstation
│ CONFIRM │ Response
│ (SEQ=2) │ to master
││ request
││ (CON=1)
││ (SEQ=2)
Figure 3-4 Typical Message Transaction Flow
NOTE:In Figure 3-4 and some of the following figures, the CON bit is set in the Outstation responses. The CON bit may be clear in some transaction (e.g.
3-4
DNP Users Group
一.设计 1.详细设计: 2个字节的起始字头，1个字节的命令字，1个字节的数据包编号，4个字节的报文总大小, 4个字节的传输数据总大小, 2个字节的文件名大小, 1个字节的保留（备用）字，若干字节的数据块. 2.详细内容 (1)报头的内容: 1.标志位, 2.命令字, 3.数据包的编号, 4.该报文的总大小, 5.该段传输 数据的大小, 6.文件名的大小, 1)命令字: 1.普通图片, 2.普通文档, 3.普通消息, 4.加密图片, 5.加密文档, 6.加密消息. 2)数据包编号: 1.对大文件或长消息体, 以一定的大小进行分割. 一次编号. 3)文件名大小: 1.数据包的数据块中, 刚开头的部位, 进行写文件名, 用来保证每段新数据写入对应的文件. 4)标志位: 1.消息体中需要对与报头,校验字相同的内容进行转义. (2)消息体: 1.文件名或消息名; 2.文件或消息的具体内容. 定义一个规则，发送的时候按照规则封装，接收的时候再按照这个规则解封装(TLV)。 二.TCP报文分段传输的依据: (1)MTU（最大传输单元） 是链路层中的网络对数据帧的一个限制，以以太网为例，MTU为1500个字节。 一个IP数据报在以太网中传输，如果它的长度大于该MTU值，就要进行分片传输，使得每片数据报的长度小于MTU。分片传输的IP数据报不一定按序到达，但IP首部中的信息能让这些数据报片按序组装。IP数据报的分片与重组是在网络层进完成的。
(2)MSS（最大分段大小） MSS是TCP里的一个概念（首部的选项字段中）。MSS是TCP数据包每次能够传输的最大数据分段，TCP报文段的长度大于MSS时，要进行分段传输。 TCP协议在建立连接的时候通常要协商双方的MSS值，每一方都有用于通告它期望接收的MSS选项（MSS选项只出现在SYN报文段中，即TCP三次握手的前两次）。 MSS的值一般为MTU值减去两个首部大小（需要减去IP数据包包头的大小20Bytes和TCP数据段的包头20Bytes）所以如果用链路层以太网，MSS的值往往为1460。而Internet 上标准的MTU（最小的MTU，链路层网络为x2.5时）为576; 如果不设置，则MSS的默认值就为536个字节。很多时候，MSS的值最好取512的倍数。TCP报文段的分段与重组是在运输层完成的。 TCP分段的原因是MSS，IP分片的原因是MTU，由于一直有MSS<=MTU，很明显，分段后的每一段TCP报文段再加上IP首部后的长度不可能超过MTU，因此也就不需要在网络层进行IP分片了。因此TCP报文段很少会发生IP分片的情况。 对于TCP协议来说，整个包的最大长度是由最大传输大小（MSS）决定，MSS就是TCP 数据包每次能够传输的最大数据分段。 为了达到最佳的传输效能TCP协议在建立连接的时候通常要协商双方的MSS值.这个值TCP协议在实现的时候往往用MTU值代替（需要减去IP数据包包头的大小20Bytes和TCP 数据段的包头20Bytes）所以往往MSS为1460。通讯双方会根据双方提供的MSS值得最小值, 确定为这次连接的最大MSS值。
通讯协议及编程 通讯协议分为协议和协议，我公司的多种仪表都采用通讯协议，如：2000智能电力监测仪、巡检表、数显表、光柱数显表等。下面就协议简要介绍如下： 一、通讯协议 （一）、通讯传送方式： 通讯传送分为独立的信息头，和发送的编码数据。以下的通讯传送方式定义也与通讯规约相兼容： 初始结构= ≥4字节的时间 地址码 = 1 字节 功能码 = 1 字节 数据区 = N 字节 错误校检 = 16位码 结束结构= ≥4字节的时间 地址码：地址码为通讯传送的第一个字节。这个字节表明由用户设定地址码的从机将接收由主机发送来的信息。并且每个从机都有具有唯一的地址码，并且响应回送均以各自的地址码开始。主机发送的地址码表明将发送到的从机地址，而从机发送的地址码表明回送的从机地址。 功能码：通讯传送的第二个字节。通讯规约定义功能号为1到127。本仪表只利用其中的一部分功能码。作为主机请求发送，通过功能码告诉从机执行什么动作。作为从机响应，从机发送的功能码与从主机发送来的功能码一样，并表明从机已响应主机进行操作。如果从机发送的功能码的最高位为１(比如功能码大与此同时127)，则表明从机没有响应操作或发送出错。 数据区：数据区是根据不同的功能码而不同。数据区可以是实际数值、设置点、主机发送给从机或从机发送给主机的地址。 码：二字节的错误检测码。 （二）、通讯规约： 当通讯命令发送至仪器时，符合相应地址码的设备接通讯命令，并除去地址码，读取信息，如果没有出错，则执行相应的任务；然后把执行结果返送给发送者。返送的信息
中包括地址码、执行动作的功能码、执行动作后结果的数据以及错误校验码。如果出错就不发送任何信息。 1．信息帧结构 地址码：地址码是信息帧的第一字节(8位)，从0到255。这个字节表明由用户设置地址的从机将接收由主机发送来的信息。每个从机都必须有唯一的地址码，并且只有符合地址码的从机才能响应回送。当从机回送信息时，相当的地址码表明该信息来自于何处。 功能码：主机发送的功能码告诉从机执行什么任务。表1-1列出的功能码都有具体的含义及操作。 数据区：数据区包含需要从机执行什么动作或由从机采集的返送信息。这些信息可以是数值、参考地址等等。例如，功能码告诉从机读取寄存器的值，则数据区必需包含要读取寄存器的起始地址及读取长度。对于不同的从机，地址和数据信息都不相同。 错误校验码：主机或从机可用校验码进行判别接收信息是否出错。有时，由于电子噪声或其它一些干扰，信息在传输过程中会发生细微的变化，错误校验码保证了主机或从机对在传送过程中出错的信息不起作用。这样增加了系统的安全和效率。错误校验采用16校验方法。 注：信息帧的格式都基本相同：地址码、功能码、数据区和错误校验码。 2．错误校验 冗余循环码（）包含2个字节，即16位二进制。码由发送设备计算，放置于发送信息的尾部。接收信息的设备再重新计算接收到信息的码，比较计算得到的码是否与接收到的相符，如果两者不相符，则表明出错。 码的计算方法是，先预置16位寄存器全为1。再逐步把每8位数据信息进行处理。在进行码计算时只用8位数据位，起始位及停止位，如有奇偶校验位的话也包括奇偶校验位，都不参与码计算。 在计算码时，8位数据与寄存器的数据相异或，得到的结果向低位移一字节，用0 填补最高位。再检查最低位，如果最低位为1，把寄存器的内容与预置数相异或，如果最低位为0，不进行异或运算。 这个过程一直重复8次。第8次移位后，下一个8位再与现在寄存器的内容相相异或，这个过程与以上一样重复8次。当所有的数据信息处理完后，最后寄存器的内容即为码值。码中的数据发送、接收时低字节在前。 计算码的步骤为：
湖南省山洪灾害监测预警系统水文通信协议规范
目录 1 总则 (1) 2 术语、符号和代号 (3) 3 数据报文传输规约 (5) 3.1帧结构 (5) 3.1.1本标准采用异步式传输帧格式。 (5) 3.1.2传输规则应按以下规定执行 (5) 3.1.3链路层应符合以下规定： (6) 3.1.4报文传输 (7) 3.2链路传输 (8) 3.3物理层规约 (9) 4 数据传输报文及数据结构 (10) 4.1应用层数据编码规定 (10) 4.1.1链路用户数据编码格式 (10) 4.1.2站点水情信息编报 (11) 4.1.3水情信息编码分类码 (11) 4.1.4水情站码 (12) 4.1.5测报时间码 (12) 4.1.6要素标识符 (13) 4.1.7数据编码 (14) 4.2水文信息编码 (14) 4.2.1降雨量编码 (14) 4.2.2蒸发量编码 (16) 4.2.3河道水情编码 (17) 4.2.4水库（湖泊）水情编码 (19) 4.2.5闸坝水情编码 (20) 4.2.6泵站水情编码 (22) 4.2.7潮汐水情编码 (23) 4.2.8土壤墒情编码 (25) 4.3数据传输报文结构 (27) 4.3.1 链路测试(AFN=02H) (27) 4.3.2 参数设置（AFN=04H） (28) 4.3.3 参数查询（AFN=0AH） (31) 4.3.4 控制命令（AFN=0CH） (32) 5 通信方式和误码率 (34) 5.1通信方式 (34) 5.2误码率 (36) 6 仪表设备数据传输规约 (37) 6.1仪表数据通信规约 (37)
7 数据传输的考核 (38) 7.1考核内容和指标 (38) 7.2考核方法 (38) 附录A 事件记录表 (39) 附录B 编码要素及标识符汇总表 (40) 附录C本标准用词说明 (47)
1．通信协议的概念及其要素 在OSI开放互联参考模型中，对等实体之间数据单元在发送方逐层封装，在接收方的逐层解析。发送方N层实体从N+1层实体得到的数据包称为服务数据单元（Service Data Unit，SDU）。N层实体只将其视为需要本实体提供服务的数据，将服务数据单元进行封装，使其成为一个对方能够理解的数据单元（Protocol Data Unit，PDU），封装过程实际上是为SDU增加对等实体间约定的控制信息（Protocol Control Information，PCI）的过程。为了保证网络的各个功能的相对独立性，以及便于实现和维护，通常将协议划分为多个子协议，并且让这些协议保持一种层次结构，子协议的集合通常称为协议簇。 网络协议的分层有利于将复杂的问题分解成多个简单的问题，从而分而治之。各层的协议由各层的实体实现，通信双方对等层中完成相同协议功能的实体称为对等实体。对等实体按协议进行通信，所以协议反映的是对等层的对等实体之间的一种横向关系，严格地说，协议是对等实体共同遵守的规则和约定的集合。 通信协议精确地定义了双方通信控制信息和解释信息：发送方能将特定信息（文本、图片、音频、视频）按协议封装成指定格式的数据包，最终以串行化比特流在网络上传输；接收方接收到数据包后，根据协议将比特流解析为本地化数据，从而获取对方发送过来的原始信息。通信协议包括三个要素： （1）语法：规定了信息的结构和格式； （2）语义：表明信息要表达的内容； （3）同步：规则涉及双方的交互关系和事件顺序。 整个计算机网络的实现体现为协议的实现，TCP/IP协议是Internet互联网的核心协议。2．通信协议开发步骤 （1）协议的开发主要包括协议设计、协议形式描述、协议实现和协议一致性测试。协议的开发过程与步骤如图1所示。 图1 协议开发过程与步骤 （2）协议设计过程中的分组发送接收模型如图2所示。
STM32串口通信协议简单教程 一、修改串口UART1IT工程模版 用Keil MDK打开短学期资料中的工程示例→串口→UART1IT示例，查看main.c代码如图1所示： 图1 UART1IT串口示例代码 打开文件列表中的stm32f10x_it.c文件，找到UART1中断函数如图2所示代码： 图2 UART1串口中断函数
为方便起见，将整个USART1_IRQHandler函数剪切到main.c文件末尾如图3所示。并删除stm32f10x_it.c文件中的sp变量定义，如图4所示。 图3 移动串口中断函数 图4 去除stm32f10x_it.c中的sp变量声明 重新编译一次工程，看看修改是否出现错误，编译失败出现错误则需仔细检查刚才的修改是否正确。编译成功，下载工程到实验板，关闭下载程序。将实验板BOOT跳线至正常运行模式并重新上电。打开串口调试助手，选择实验板USB虚拟串口并打开，如图5所示。可以看到图中窗口不停的接收到“Hello world！”这样的字符串数据。在发送区域输入字符1，点击发送按钮，可以观察到实验板的流水灯速度变快了很多。
在main函数之前，添加按键扫描代码如图6所示，然后在main函数中，添加sendstr 数组，key和oldkey两个整数变量，如图7所示。
图6 添加按键扫描函数 图7 添加相关变量 接下来，在main函数的while主循环中，添加发送按键状态代码如图8所示。同时，将main函数中的Hello world字符串发送行注释掉，如图9所示。为使按键响应灵敏，可以将main.c文件开头的sp变量初始值由100改为10。 注意，资料包里面的串口调试助手UartAssit软件容易造成虚拟串口占用，甚至使系统崩溃。考虑到使用方便，推荐使用sscom42软件。这里给大家一个下载地址http://biz.doczj.com/doc/c42864295.html,/soft/53912.html
通信协议 来自中国工控网 所谓通信协议是指通信双方的一种约定。约定包括对数据格式、同步方式、传送速度、传送步骤、 检纠错方式以及控制字符定义等问题做出统一规定，通信双方必须共同遵守。因此，也叫做通信控制规程，或称传输控制规程，它属于ISO'S OSI七层参考模型中的数据链路层。 目前，采用的通信协议有两类：异步协议和同步协议。同步协议又有面向字符和面向比特以及面向 字节计数三种。其中，面向字节计数的同步协议主要用于DEC公司的网络体系结构中。 串行通讯简单认识 串行通讯的基本概念：与外界的信息交换称为通讯。基本的通讯方式有并行通讯和串行通讯两种。 一条信息的各位数据被同时传送的通讯方式称为并行通讯。并行通讯的特点是：各数据位同时传送，传送速度快、效率高，但有多少数据位就需多少根数据线，因此传送成本高，且只适用于近距离（相距 数米）的通讯。 一条信息的各位数据被逐位按顺序传送的通讯方式称为串行通讯。串行通讯的特点是：数据位传送，传按位顺序进行，最少只需一根传输线即可完成，成本低但送速度慢。串行通讯的距离可以从几米到几 千米。 根据信息的传送方向，串行通讯可以进一步分为单工、半双工和全双工三种。信息只能单向传送为 单工；信息能双向传送但不能同时双向传送称为半双工；信息能够同时双向传送则称为全双工。 串行通讯又分为异步通讯和同步通讯两种方式。在单片机中，主要使用异步通讯方式。 MCS_51单片机有一个全双工串行口。全双工的串行通讯只需要一根输出线和一根输入线。数据的输 出又称发送数据（TXD），数据的输入又称接收数据（RXD）。串行通讯中主要有两个技术问题，一个是数 据传送、另一个是数据转换。数据传送主要解决传送中的标准、格式及工作方式等问题。数据转换是指 数据的串并行转换。具体说，在发送端，要把并行数据转换为串行数据；而在接收端，却要把接收到的 串行数据转换为并行数据。 单工、半双工和全双工的定义 如果在通信过程的任意时刻，信息只能由一方A传到另一方B，则称为单工。 如果在任意时刻，信息既可由A传到B，又能由B传A，但只能由一个方向上的传输存在，称为半双工传输如果在任意时刻，线路上存在A到B和B到A的双向信号传输，则称为全双工。 电话线就是二线全双工信道。由于采用了回波抵消技术，双向的传输信号不致混淆不清。双工信道有时也发信道分开，采用分离的线路或频带传输相反方向的信号，如回线传输。 --------> <--------> --------> A---------B A----------B A---------B <-------- 单工半双工全双工
CSU03B通信协议更改记录 2006-06-13：V1.0；其中历史告警记录有重大调整，其他与CSU03A兼容。
CSU03B通信协议 本协议以电信总局《通信局（站）电源、空调及环境集中监控管理系统前端智能设备通信协议》（一九九九年三月）为基础制定；与CSU03A通信协议兼容（历史数据和历史告警除外）。 一．物理接口 1．串行通信口采用RS232/RS485，数据传输速率2400bps； 2．信息传输方式为异步方式，起始位1位，数据位8位，停止位1位，无校验。 3．局站监控系统（SU）与设备监控单元（SM）的通信为主从方式。SU呼叫SM并下发命令，SM收到命令后返回响应信息。SU500ms内收不到SM响应或接收响应信息错误，则认为本次通信过程失败。 二．信息类型及协议的基本格式 1．信息分两种类型： (1) 由SU发出到SM的命令信息（简称命令信息）； (2) 由SM返回到SU的响应信息（简称响应信息）。 基本格式的注解见表2.2、表2.3。 表2.2 协议的基本格式 说明： COMMAND INFO由以下控制命令码（其中一部分）组成： COMMAND GROUP（1字节）：表示同一类型设备的不同组号； COMMAND ID（1字节）：表示同一类型设备相同组内的不同监控点； COMMAND TYPE（1字节）：表示不同的遥控命令或历史数据传输中的不同控制命令； COMMAND TIME（1字节）：表示时间字段。 DA TA INFO由以下应答码（其中一部分）组成： DATAI：含有整型数的应答信息；
RUNSTATE：设备的运行状态； WARNSTA TE：设备的告警状态； DATAFLAG：标示字节；本协议中该字节无效，固定为00H； DATATIME：时间字段。 表2.3返回码RTN 3．数据格式 3．1 基本数据格式 在表2.1基本格式中各项除SOI和EOI是以十六进制解释（SOI=7EH，EOI=0DH），十六进制传输外，其它各项都是十六进制解释，十六进制—ASCII码的方式传输，每个字节用两个ASCII码表示，即高四位一个ASCII码表示，低四位用一个ASCII码表示。 例：CID2＝4BH，传送时顺序发送34H和42H两个字节。 3．2 LENGTH数据格式 LENGTH共两个字节，由LENID和LCHKSUM组成，LENID表示INFO项的ASCII 码字节数，当LENID=0时，INFO为空，即无该项。LENGTH传输中先传高字节，再传低字节，分四个ASCII码传送。 校检码的计算：D11D10D9D8+D7DD6D5D4+D3D2D1D0，求和后模16余数取反加1。例：I NFO项的ASCII码字节数为18，即LENID=0000 0001 0010B。 D11D10D9D8＋D7D6D5D4＋D3D2D1D0=0000B+0001B+0010B=0011B，模16余数为0011B，0011B取反加1就是1101B，即LCHKSUM为1101B。 可得： LENGTH为1101 0000 0001 0010B，即D012H。 3．3 CHKSUM数据格式 CHKSUM的计算是除SOI、EOI和CHKSUM外，其他字符按ASCII码值累加求和，所得结果模65536余数取反加1。 例：收到或发送的字符序列是：“~1203400456ABCDFEFC72C C R R”（“~”为SOI,“C C R R”为EOI），则最后五个字符“FC72C C R R”中的FC72是CHKSUM，计算方法是： ‘1’＋‘2’＋‘0’＋…＋‘A’＋‘B’＋…＋‘F’＋‘E’ = 31H + 32H + 30H + …+ 41H + 42H + …+ 46H + 45H = 038EH 其中‘1’表示1的ASCII码值，‘E’表示E的ASCII码值。038EH模65536余数是
MODBUS_RTU通讯规约（本协议采用主从问答方式） PDM系列仪表/变送器： PDM系列仪表/变送器采用全新的设计，革命性地改变了传统电表的概念；具有多功能、高精度、数字式、可编程、结构紧凑、多画面显示的特点，它可以满足电力工业未来对电表的需求。 MODBUS通讯协议： ModBus通讯规约允许PDM系列仪表/变送器与施耐德、西门子、AB、GE等多个国际著名品牌的可编程顺序控制器（PLC）、RTU、SCADA系统、DCS或与第三方具有ModBus 兼容的监控系统之间进行信息交换和数据传送。 PDM系列仪表/变送器只要简单地增加一套基于计算机（或工控机）的监控软件（如：组态王、Intouch、FIX、synall等）就可以构成一套电力监控系统。 广泛的系统集成： PDM系列仪表/变送器提供了标准的RS-485/422通讯接口及ModBus通讯协议，这个通讯协议已广泛被国内外电力行业及工控行业作为系统集成的标准。 通讯数据的类型及格式： 信息传输为异步方式，并以字节为单位。在主站和从站之间传递的通讯信息是11位的字格式： 字格式（串行数据） 11位二进制 起始位1位 数据位8位 奇偶校验位1位:有奇偶校验位/无：无奇偶校验位 停止位1位:有奇偶校验位/2位：无奇偶校验位 ●通讯数据（信息帧）格式 数据格式：地址码功能码数据区错误校检 数据长度：1字节1字节N字节 16位CRC码（冗余循环码） ★ 注：1、1个字节由8位二进制数组成（既8 bit）。 2、ModBus是Modicon公司的注册商标。
一、通讯信息传输过程： 当通讯命令由发送设备（主机）发送至接收设备（从机）时，符合相应地址码的从机接收通讯命令，并根据功能码及相关要求读取信息，如果CRC校验无误，则执行相应的任务，然后把执行结果（数据）返送给主机。返回的信息中包括地址码、功能码、执行后的数据以及CRC校验码。如果CRC校验出错就不返回任何信息。 1.1 地址码： 地址码是每次通讯信息帧的第一字节（8位），从0到255。这个字节表明由用户设置地址的从机将接收由主机发送来的信息。每个从机都必须有唯一的地址码，并且只有符合地址码的从机才能响应回送信息。当从机回送信息时，回送数据均以各自的地址码开始。主机发送的地址码表明将发送到的从机地址，而从机返回的地址码表明回送的从机地址。相应的地址码表明该信息来自于何处。 1.2 功能码： 是每次通讯信息帧传送的第二个字节。ModBus通讯规约可定义的功能码为1到127。PDM系列仪表/变送器仅用到其中的一部分功能码。作为主机请求发送，通过功能码告诉从机应执行什么动作。作为从机响应，从机返回的功能码与从主机发送来的功能码一样，并表明从机已响应主机并且已进行相关的操作。 表8.1 MODBUS部分功能码 功能码定义操作（二进制） 02 读开关量输入读取一路或多路开关量状态输入数据 01 读开关量输出读取一路或多路开关量输出状态数据 03 读寄存器数据读取一个或多个寄存器的数据 05 写开关量输出控制一路继电器“合/分”输出 06 写单路寄存器把一组二进制数据写入单个寄存器 10 写多路寄存器把多组二进制数据写入多个寄存器 1.3 数据区： 数据区包括需要由从机返送何种信息或执行什么动作。这些信息可以是数据（如：开关量输入/输出、模拟量输入/输出、寄存器等等）、参考地址等。例如，主机通过功能码03告诉从机返回寄存器的值（包含要读取寄存器的起始地址及读取寄存器的长度），则返回的数据包括寄存器的数据长度及数据内容。对于不同的从机，地址和数据信息都不相同（应给出通讯信息表）。 PDM系列仪表/变送器采用Modbus通讯规约，主机（PLC、RTU、PC机、DCS等）利用通讯命令（功能码03），可以任意读取其数据寄存器（其数据信息表详见附录）。PDM 系列仪表/变送器的数据寄存器存储的电量多达几百个（如：电流、电压、功率、0~31次谐波分量等），并且都是16位（2字节）的二进制数据，并且高位在前；一次最多可读取寄存器数（既各种电量的数量）是50个。 PDM响应的命令格式是从机地址、功能码、数据区及CRC码。数据区的数据都是两个字节，并且高位在前（电能量除外）。 注：1、PDM-820AC/ACM/ACR、PDM-800AC/ACM具有“03”、“06”、“10”功能码； 2、如果PDM采用MODBUS ASCII通讯协议，其通讯数据格式为；7个数据位，1个 停止位，偶校验。
编号： 密级：内部 页数：__________基于RS485接口的DGL通信协议（修改） 编写：____________________ 校对：____________________ 审核：____________________ 批准：____________________ 北京华美特科贸有限公司 二○○二年十二月六日
1.前言 在常见的数字式磁致伸缩液位计中，多采用RS485通信方式。但RS485标准仅对物理层接口进行了明确定义，并没有制定通信协议标准。因此，在RS485的基础上，派生出很多不同的协议，不同公司均可根据自身需要设计符合实际情况的通信协议。并且，RS485允许单总线多机通信，如果通信协议设计不好，就会造成相互干扰和总线闭锁等现象。如果在一条总线上挂接不同类型的产品，由于协议不一样，很容易造成误触发，造成总线阻塞，使得不同产品对总线的兼容性很差。 随着RS485的发展，Modicon公司提出的MODBUS协议逐步得到广泛认可，已在工业领域得到广泛应用。而MODBUS的协议规范比较烦琐，并且每字节数据仅用低4位（范围：0~15），在信息量相同时，对总线占用时间较长。 DGL协议是根据以上问题提出的一种通信协议。在制定该协议时已充分考虑以下几点要求： a.兼容于MODBUS 。也就是说，符合该协议的从机均可挂接到同一总线上。 b.要适应大数据量的通信。如：满足产品在线程序更新的需要(未来功能)。 c.数据传输需稳定可靠。对不确定因素应加入必要的冗错措施。 d.降低总线的占用率，保证数据传输的通畅。 2.协议描述 为了兼容其它协议，现做以下定义： 通信数据均用1字节的16进制数表示。从机的地址范围为：0x80～0xFD，即：MSB=1； 命令和数据的数值范围均应控制在0~0x7F之间。即：MSB=0，以区别地址和其它数据。 液位计的编码地址为：0x82~0x9F。其初始地址(出厂默认值)为：0x81。 罐旁表的编织地址为：0xA2~0xBF。其初始地址(出厂默认值)为：0xA1。 其它地址用于连接其它类型的设备，也可用于液位计、罐区表地址不够时的扩充。 液位计的命令范围为：0x01~0x2F，共47条，将分别用于参数设定、实时测量、诊断测试、在线编程等。 通信的基本参数为：4800波特率，1个起始位，1个结束位。字节校验为奇校验。 本协议的数据包是参照MODBUS RTU 通信格式编写，并对其进行了部分修改，以提高数据传输的速度。另外，还部分参照了HART协议。其具体格式如下： 表中，数据的最大字节数为16个。也就是说，整个数据包最长为20个字节。 “校验和”是其前面所有数据异或得到的数值，然后将该数值MSB位清零，使其满足0~7F 的要求。在验证接收数据包的“校验和”是否正确时，可将所有接收数据(包括“校验和”)进行异或操作，得到的数据应＝0x80。这是因为，只有“地址”的MSB=1，所以异或结果的MSB也必然等于1。 本协议不支持MODBUS中所规定的广播模式。 3.时序安排 在上电后，液位计将先延迟10秒，等待电源稳定。然后，用5秒的时间进行自检和测试数据。
分层及通信协议 协议软件是计算机通信网中各部分之间所必须遵守的规则的集合，它定义了通信各部分交换信息时的顺序、格式和词汇。协议软件是计算机通信网软件中最重要的部分。网络的体系结构往往都是和协议对应的，而且，网络管理软件、交换与路由软件以及应用软件等都要通过协议软件才能发生作用。 一、通信协议 1、什么是通信协议 通信协议(简称协议Protoco l)，是指相互通信的双方(或多方)对如何进行信息交换所一致同意的一整套规则。一个网络有一系列的协议，每一个协议都规定了一个特定任务的完成。协议的作用是完成计算机之间有序的信息交换。 通信网络是由处在不同位置上的各节点用通信链路连接而组成的一个群体。通信网必须在节点之间以及不同节点上的用户之间提供有效的通信，即提供有效的接入通路。在计算机通信网中，将这种接入通路称为连接(connection)。建立一次连接必需要遵守的一些规则，这些规则也就是通信网设计时所要考虑的主要问题。 (l)为了能在两个硬件设备之间建立起连接，应保证在源、宿点之间存在物理的传输媒介，在该通路的各条链路上要执行某种协议。 如果传输线路使用电话线，则要通过调制解调器将信号从数字转换成模拟的，并在接收端进行反变换。 如果用的是数字传输线路，则在数据处理设备和通信设备之间，必须有一个数字适配器，以便将数字信号的格式转换成两种设备各自所期望的形式。 为了在两个端设备之间互换数据，需要协调和同步，调制解调器和数字适配器必须执行它们自己的协议。 无论是模拟的还是数字的通信设备，调制解调器和数字适配器的状态必须由接到节点上的设备来控制，这里必定有一个物理的或电气的接口来执行这种功能，执行某种适当的协议来达到这一控制目的。 (2)在计算机通信网中，许多信息源都是突发性的(bursty)，问题是要利用信息的这种突发性质来降低消耗在线路上的费用，由此开发了许多共享通信资源的技术。所谓共享，是指允许多个用户使用同一通信资源，这就产生了多用户的接入问题。多路接入
串口通讯—通信协议 所谓通信协议是指通信双方的一种约定。约定包括对数据格式、同步方式、传送速度、传送步骤、检纠错方式以及控制字符定义等问题做出统一规定，通信双方必须共同遵守。因此，也叫做通信控制规程，或称传输控制规程，它属于ISO'S OSI七层参考模型中的数据链路层。 目前，采用的通信协议有两类：异步协议和同步协议。同步协议又有面向字符和面向比特以及面向字节计数三种。其中，面向字节计数的同步协议主要用于DEC公司的网络体系结构中。 一、物理接口标准 1.串行通信接口的基本任务 （1）实现数据格式化：因为来自CPU的是普通的并行数据，所以，接口电路应具有实现不同串行通信方式下的数据格式化的任务。在异步通信方式下，接口自动生成起止式的帧数据格式。在面向字符的同步方式下，接口要在待传送的数据块前加上同步字符。 （2）进行串－并转换：串行传送，数据是一位一位串行传送的，而计算机处理数据是并行数据。所以当数据由计算机送至数据发送器时，首先把串行数据转换为并行数才能送入计算机处理。因此串并转换是串行接口电路的重要任务。 （3）控制数据传输速率：串行通信接口电路应具有对数据传输速率——波特率进行选择和控制的能力。 （4）进行错误检测：在发送时接口电路对传送的字符数据自动生成奇偶校验位或其他校验码。在接收时，接口电路检查字符的奇偶校验或其他校验码，确定是否发生传送错误。 （5）进行TTL与EIA电平转换：CPU和终端均采用TTL电平及正逻辑，它们与EIA采用的电平及负逻辑不兼容，需在接口电路中进行转换。 （6）提供EIA-RS-232C接口标准所要求的信号线：远距离通信采用MODEM时，需要9根信号线；近距离零MODEM方式，只需要3根信号线。这些信号线由接口电路提供，以便与MODEM或终端进行联络与控制。 2、串行通信接口电路的组成
Modbus通讯协议学习 了解了它，会使你对串口通信有一个清晰的认识！通用消息帧ASCII消息帧(在消息中的每个8Bit 字节都作为两个ASCII字符发送) 十六进制，ASCII字符0...9，A...F 消息中的每个ASCII字符都是一个十六进制字符组成每个字节的位1个起始位n个数据位，最小的有效位先发送1个奇偶校验位，无校验则无1个停止位（有校验时），2个Bit（无校验时）错误检测域LRC(纵向冗长检测) RTU 消息帧8位二进制，十六进制数0...9，A...F 消息中的每个8位域都是一个两个十六进制字符组成每个字节的位1个起始位8个数据位，最小的有效位先发送1个奇偶校验位，无校验则无1个停止位（有校验时），2个Bit（无校验时）错误检测域CRC(循环冗长检测) CRC校验 (http://biz.doczj.com/doc/c42864295.html,/view/1664507.htm) public static string CRCCheck(string val) { val = val.TrimEnd(' '); string[] spva = val.Split(' '); byte[] bufData = new byte[spva.Length + 2]; bufData = ToBytesCRC(val); ushort CRC = 0xffff;
ushort POLYNOMIAL = 0xa001; for (int i = 0; i < bufData.Length - 2; i++) { CRC ^= bufData[i]; for (int j = 0; j < 8; j++) { if ((CRC & 0x0001) != 0) { CRC >>= 1; CRC ^= POLYNOMIAL; } else { CRC >>= 1; } } } return Maticsoft.DBUtility.HLConvert.ToHex(System.BitConverter .GetBytes(CRC)); } /// <summary>
Modbus通讯协议 Modbus协议 Modbus协议最初由Modicon公司开发出来，在1979年末该公司成为施耐德自动化(Schneider Automation)部门的一部分，现在Modbus已经是工业领域全球最流行的协议。此协议支持传统的RS-232、RS-422、RS-485和以太网设备。许多工业设备，包括PLC，DCS，智能仪表等都在使用Modbus协议作为他们之间的通讯标准。有了它，不同厂商生产的控制设备可以连成工业网络，进行集中监控。 当在网络上通信时，Modbus协议决定了每个控制器须要知道它们的设备地址，识别按地址发来的消息，决定要产生何种行动。如果需要回应，控制器将生成应答并使用Modbus 协议发送给询问方。 Modbus协议包括ASCII、RTU、TCP等，并没有规定物理层。此协议定义了控制器能够认识和使用的消息结构，而不管它们是经过何种网络进行通信的。标准的Modicon控制器使用RS232C实现串行的Modbus。Modbus的ASCII、RTU协议规定了消息、数据的结构、命令和就答的方式，数据通讯采用Maser/Slave方式，Master端发出数据请求消息，Slave 端接收到正确消息后就可以发送数据到Master端以响应请求；Master端也可以直接发消息修改Slave端的数据，实现双向读写。 Modbus协议需要对数据进行校验，串行协议中除有奇偶校验外，ASCII模式采用LRC校验，RTU模式采用16位CRC校验，但TCP模式没有额外规定校验，因为TCP协议是一个面向连接的可靠协议。另外，Modbus采用主从方式定时收发数据，在实际使用中如果某Slave站点断开后（如故障或关机），Master端可以诊断出来，而当故障修复后，网络又可自动接通。因此，Modbus协议的可靠性较好。 下面我来简单的给大家介绍一下，对于Modbus的ASCII、RTU和TCP协议来说，其中TCP和RTU协议非常类似，我们只要把RTU协议的两个字节的校验码去掉，然后在RTU协议的开始加上5个0和一个6并通过TCP/IP网络协议发送出去即可。所以在这里我仅介绍一下
常用几种通讯协议 Modbus Modbus技术已成为一种工业标准。它是由Modicon公司制定并开发的。其通讯主要采用RS232，RS485等其他通讯媒介。它为用户提供了一种开放、灵活和标准的通讯技术，降低了开发和维护成本。 Modbus通讯协议由主设备先建立消息格式，格式包括设备地址、功能代码、数据地址和出错校验。从设备必需用Modbus协议建立答复消息，其格式包含确认的功能代码，返回数据和出错校验。如果接收到的数据出错，或者从设备不能执行所要求的命令，从设备将返回出错信息。 Modbus通讯协议拥有自己的消息结构。不管采用何种网络进行通讯，该消息结构均可以被系统采用和识别。利用此通信协议，既可以询问网络上的其他设备，也能答复其他设备的询问，又可以检测并报告出错信息。 在Modbus网络上通讯期间，通讯协议能识别出设备地址，消息，命令，以及包含在消息中的数据和其他信息，如果协议要求从设备予以答复，那么从设备将组建一个消息，并利用Modbus发送出去。 BACnet BACnet是楼宇自动控制系统的数据通讯协议,它由一系列与软件及硬件相关的通讯协议组成,规定了计算机控制器之间所有对话方式。协议包括:(1)所选通讯介质使用的电子信号特性,如何识别计算机网址,判断计算机何时使用网络及如何使用。(2)误码检验,数据压缩和编码以及各计算机专门的信息格式。显然,由于有多种方法可以解决上述问题,但两种不同的通讯模式选择同一种协议的可能性极少,因此,就需要一种标准。即由ISO(国际标准化协会〉于80年代着手解决,制定了《开放式系统互联(OSI〉基本参考模式(Open System Interconnection/Basic Reference Model简称OSI/RM)IS0- 7498》。 OSI/RM是ISO/OSI标准中最重要的一个,它为其它0SI标准的相容性提供了共同的参考,为研究、设计、实现和改造信息处理系统提供了功能上和概念上的框架。它是一个具有总体性的指导性标准,也是理解其它0SI标准的基础和前提。 0SI/RM按分层原则分为七层,即物理层、数据链路层、网络层、运输层、会话层、表示层、应用层。 BACnet既然是一种开放性的计算机网络,就必须参考OSIAM。但BACnet没有从网络的最低层重新定义自己的层次,而是选用已成熟的局域网技术,简化0SI/RM,形成包容许多局 域网的简单而实用的四级体系结构。 四级结构包括物理层、数据链路层、网络层和应用层。
串口通信协议 串口通信的概念非常简单，串口按位（bit）发送和接收字节。尽管比按字节（byte）的并行通信慢，但是串口可以在使用一根线发送数据的同时用另一根线接收数据。
的检查数据，简单置位逻辑高或者逻辑低校验。这样使得接收设备能够知道一个位的状态，有机会判断是否有噪声干扰了通信或者是否传输和接收数据是否不同步。 什么是RS-232 RS-232（ANSI/EIA-232标准）是IBM-PC及其兼容机上的串行连接标准。可用于许多用途，比如连接鼠标、打印机或者Modem，同时也可以接工业仪器仪表。用于驱动和连线的改进，实际应用中RS-232的传输长度或者速度常常超过标准的值。RS-232只限于PC串口和设备间点对点的通信。RS-232串口通信最远距离是50英尺。 DB-9针连接头 9针串口连接口顺序图 从计算机连出的线的截面。 RS-232针脚的功能： 数据： TXD（pin 3）：串口数据输出(Transmit Data) RXD（pin 2）：串口数据输入(Receive Data) 握手： RTS（pin 7）：发送数据请求(Request to Send) CTS（pin 8）：清除发送(Clear to Send) DSR（pin 6）：数据发送就绪(Data Send Ready) DCD（pin 1）：数据载波检测(Data Carrier Detect) DTR（pin 4）：数据终端就绪(Data Terminal Ready) 地线： GND（pin 5）：地线 其他 RI（pin 9）：铃声指示 什么是RS-422 RS-422（EIA RS-422-AStandard）是Apple的Macintosh计算机的串口连接标准。RS-422使用差分信号，RS-232使用非平衡参考地的信号。差分传输使用两根线
1应用范围 本规范规定了电能表进行点对点的或一终端对多台电能表进行一主多从的本地通讯接口进行数据交换的技术要求，规定了本地系统硬件和协议规范。规定了物理连接、通讯链路及应用技术规范（数据的基本格式、校验方式、编码传输规则等）。 本规范主要参考了部颁DL/T 645-1997多功能电能表通信规约，根据我公司的DSSD331-3、DTSD341-3电能表的特色做了相应的扩展。本规范中未给出的一些例子和示意图请参见部颁规约。 2引用标准 下列标准所包含的条文，通过在本标准中的引用而构成为本标准的条文。本标准出版时，所示版本均为有效，所有标准都会被修订，使用本标准的各方应探讨使用下列标准最新版本的可能性。 DL/T 645-1997 多功能电能表通信规约 DL/T 614-1997 多功能电能表 3术语 3.1费率装置tariff device 固定的数据采集与处理单元，通常与电能表连接或与电能表组装在一起。 3.2手持单元（HHU）hand-heldunit 能与费率装置或电能表进行数据交换的便携式设备。 3.3数据终端设备data terminal equipment 由数据源、数据宿或两者组成的设备。
3.4直接本地数据交换direct local data exchange 一组费率装置与数据终端设备通过总线连接进行数据交换。 3.5本地总线数据交换local bus data exchange 一组费率装置与数据终端设备通过总线连接进行数据交换。 3.6远程数据交换remote data exchange 通过数据网络，数据采集中心与一台或一组费率装置之间的数据交换。 3.7主站master station 具有选择从站并与从站进行信息交换功能的设备。本标准中指手持单元或其它数据终端设备。 3.8从站slave station 预期从主站接收信息并与主站进行信息交换的设备。本标准中指费率装置。 3.9总线bus 连接主站与多个从站并允许主站每次只与一个从站通信的系统连接方式（广播命令除外）。 3.10半双工half-duplex 在双向通道中，双向交替进行、一次只在一个方向（而不是同时在两个方向）传输信息的一种通信方式。 3.11物理层physical layer 规定了数据终端设备或手持单元与费率装置之间的物理接口、接口的物理和电气特性，负责物理媒体上信息的接收和发送。 3.12数据链链路层data-link layer 负责数据终端设备与费率装置之间通信链路的建立并以帧为单位舆信息，保证信息的顺序传送，具有传输差错检测功能。 3.13应用层application layer
HTTP网页访问的协议分析 在协议模型中，应用层是用户与计算机进行实际通信的地方，只有当马上就要访问网络时，才会实际上用到这一层。例如，我们可以从系统中卸载掉任何联网组件，如TCP/IP、网卡（NIC）等，仍可以使用IE来浏览本地的HTML文档。可如果我们试图浏览必须使用HTTP 的文档，或者用FTP下载一个文件，事情就没那么容易了。此时，IE将尝试访问应用层来响应这一类请求。因此，应用层也可被看作是实际应用程序和下一层（OSI模型中为表示层，TCP/IP模型中为传输层）之间的接口，它通过某种方式把应用程序的有关信息送到协议栈的下面各层。 应用层协议则是实现用户和系统之间接口的工具，用户可通过这些协议方便地访问网络资源，实现信息共享，HTTP则是其中一种。 HTTP（超文本传输协议）是客户端浏览器或其他程序与Web服务器之间的应用层通信协议。在Internet上的Web服务器上存放的都是超文本信息，客户机需要通过HTTP协议传输所要访问的超文本信息。HTTP包含命令和传输信息，不仅可用于Web访问，也可以用于其他因特网/内联网应用系统之间的通信，从而实现各类应用资源超媒体访问的集成。 HTTP是基于请求/响应方式的。它的运作方式很简单：一个客户机与服务器建立连接后，发送一个请求给服务器，服务器接到请求后，给予相应的响应报文。其中，“客户”与“服务器”是一个相对的概念，只存在于一个特定的连接期间，即在某个连接中的客户在另一个连接中可能作为服务器。因此，当网络中的任一台拥有可被访问的页面的计算机被其它计算机访问时，它便是服务器，而当它访问其它浏览非本地的HTTP文档时，它便是客户端。因此，我们可以在局域网中搭建简单的环境来观察分析访问HTTP的工作流程。 最简单的情况可能是在用户和服务器之间通过一个单独的连接来完成，如图1-1： 图1-1 根据图连接好以及配好相应IP后，测试网络互通。而后，在server上建立HTTP服务器。首先在控制面板\添加删除程序\添加删除Windows组件中查看Internet信息服务（IIS）是否装上，若没有则安装，若安装好，则可以进入管理工具\Internet服务管理器，在默认WEB站点下建立自己的站点及目录。而后，在client浏览器地址栏中键入http：//31.0.0.1便可浏览位于server端默认站点目录下网页。 在此过程中，我们通过Ethereal所抓的数据包如下： 1、数据链路层：