Fundamentals of distributed network protocol 117 Response function codes Response Functions Code Function Action Response 0 Confirm Message fragment confirmation. No further response required. Used by both requests and responses. 129 Response Respond to request. Master station will respond with confirm if CON bit set. 130 Unsolicited Message Unsolicited message from outstation. Master station will respond with confirm if CON bit set. The response function codes apply for all messages from outstations, ie stations that are not designated as master stations. The only response these messages require (of the master station) is an optional confirmation on receipt by the master station. 5.7.3 Internal indications Local Figure 5.26 Internal indications The internal indications (IIN) field is a two-byte field that follows the function code in all responses. It is by using the internal indications that the outstation status is reported to the master following a request. Each bit in the field has a specific meaning, in accordance with the table. An outstation would have defined flags within its dynamic memory to correspond to the IIN field bits. These flags would then be copied in each response message.
118 Practical Modern SCADA Protocols: DNP3, 60870.5 andRelatedSystems Descriptions of the detailed meaning of each bit are included in the following table. Second Byte Bit Meaning When Set Notes 0 Function code not implemented This function code is not available at this outstation. 1 Requested objects unknown There are no objects as specified or in the specified class. 2 Parameters invalid Parameters in the qualifier, range, or data fields are not valid or are out of range. 3 Buffer overflow Event or other application buffers have overflowed. 4 Operation already in progress This operation is already executing. 5 Corrupt configuration This is a specific problem indication showing that the master will have to download a new configuration. 6 Reserved ( 0 ) Always to return 0. 7 Reserved ( 0 ) Always to return 0. 5.7.4 The object header In DNP3 the data is always comprised of two parts, object headers, and data objects. The object headers identify the data object types, and specific instances of those data that are being referenced by the message. These data may not necessarily be contained in the message, for example a read request carries only the references identifying which data is required. The response to the read request will contain both the data identification and the data itself. The position of the object headers and data objects within the application protocol data unit, or message frame, is shown in the following drawing.