Practical_modern_SCADA_protocols_-_dnp3,_60870-5_and_Related_Systems

154

154 Practical Modern SCADA Protocols: DNP3, 60870.5 and Related Systems The device profile document also lists many configuration details including default configurations for confirmations, retries and other details. All of these need to be checked for compatibility with the planned implementation. Confirming interoperability: • Determine DNP3 polling mode to be used • Determine range of slave devices • Assemble device profile documents for range of slave devices • Determine minimum required DNP3 level • Determine functions above this level that will require support • Determine data objects above selected base level that will require support • Examine device profiles for RTUs and establish compatibility with IEDs • Examine device profiles for master station and establish compatibility with RTUs 6.3 Implementation rules and recommendations The following sub-sections summarize rules and recommendations that appear in the subset definition document DNP3 Subset Definitions, Version 2, Nov 1995. These rules and recommendations provide information that extends and clarifies that contained in the Basic Four documents. 6.3.1 Error responses Error responses are defined to cope with side-effects of having levels. These are the possibility that a device of one level will be polled for data objects that it cannot provide. Types: • Request not valid for its level • Request not valid for the particular device These are reported by the internal indications bits 0–2. Event objects are also a special case, because although they are not tied to a physical device and they may not exist at a given time, because there may be no new events to report. In this case the device must provide a null response rather than a ‘requested objects unknown’ response.

6.3.2 Data classes and events Advanced considerations of distributed network protocol 155 The simplest method of referencing data in requests in DNP3 is to call for objects by class. This in fact is a fundamental assumption behind the minimum implementation subsets, which at their lowest level depend on the use of calls by class to obtain many objects. This is provided for by requiring that all devices have their static data objects assigned to class 0, and all event objects assigned to one of the other classes. The sub-set document defines a relationship between event type object variations and class. Event type object variations are required to be assigned by default as class 1, 2 or 3, but not class 0. Class 0 is to be assigned by default to static data points only. Level 3 devices must allow a master to enable or disable event reporting for a point. To enable event reporting the master would assign the point to required data class 1, 2 or 3. To disable event reporting the master would assign the point to class 0. Level 1 or 2 devices do not need to support enabling or disabling of event reporting by the master. For these devices, default assignments are required to be in-built. Rules: 6.3.3 Default variation • All static objects are by definition class 0 • Event objects are by definition in class 1, 2 or 3 (may be configurable) • All event objects must be assigned by default to class 1, 2 or 3 • Level 3 slave devices must allow disabling of event reporting If a master request does not specify a particular variation for a point, then the slave must send the default variation. This may be configurable. This occurs when the master requests by class, or uses object variation zero. 6.3.4 Order of responses A slave must preserve the sequence of event order when responding requests for data by class. In particular, when a read request calls for multiple classes, the event data must not be returned in class groups, but rather in sequence of occurrence. 6.3.5 Actions on slave device startup The following actions must occur on startup of a slave device: • The device restart IIN bit must be set • If configured for unsolicited responses, it must send one on startup • This response must contain either no data, or all static data • This response may also contain unreported event data. If provided, these must be included in the message prior to the static data It is recommended that if a device does not report all of its static data on startup, the master should immediately poll for all static and event data.