Unsolicited data

Similar to the Event Type Data described above, unsolicited data also contains three attributes; information to identify the point, a value, and the time the value changed. The unsolicited data belongs to one of three different classes of data; class 1, 2, or 3. Events belonging to class 1 generally have a higher priority than events in class 2, or 3.

If unsolicited data is requested and supported by the RTU, data will be sent to the interface whenever the RTU generates class 1, 2, or 3 events. Configuring the interface to request and receive unsolicited data from an RTU can eliminate the need to poll for events at a regular basis. However, the points for a specific RTU can be configured to receive polled data, unsolicited data, or a combination of both.

The interface can be configured to request and receive unsolicited by modifying the xml configuration file for the interface.

Note: To request and receive unsolicited data from an RTU, the xml configuration file must have the Unsolicited node defined as <Unsolicited>1</Unsolicited> for the RTU.

Consider increasing the ReadTimeout attribute of the Device Configuration (XML) File when the interface is configured to receive unsolicited data. An increased ReadTimeout may be necessary when the RTU sends unsolicited events at a rate which is faster than data that is scanned due to the priority of servicing unsolicited data before solicited data is serviced. Failure to increase the ReadTimeout could result in Data Link or Application Layer retries or the interface or exceeding the ReadTimeout; which would inform the interface to reset the link of the RTU.

The enabling of an RTU to send unsolicited data that is configured to share the same IOGroup as defined in the xml configuration file is not recommended due to possible data collisions.

Take care to ensure "IO Timeout" is not erroneously writing to PI points when the interface is configured to receive only unsolicited data from an RTU. Make sure the /IOTimeout startup command line parameter is set to zero or a value greater than the expected interval between unsolicited data. Failure to do so may result in "IO Timeout" being written to PI points because no unsolicited data has been received from the RTU in the maximum period set by the parameter. If the RTU infrequently sends unsolicited data, then the interface should be configured to request and integrity poll on a regular basis and the /IOTimeout parameter should be set to a value greater than the integrity poll interval to ensure that the interface can detect a communication error if the integrity scan fails to return valid results.