G
things I would want in a communications protocol, especially if it were being developed from scratch: 1. support for report-by-exception i want to be able to register interest in a value in a device, and be informed by the device when the value changes. example: i have an application in which i am monitoring generators, UPSs and automatic transfer switches for a facility. each piece of equipment has a controller, and each controller contains (among other things) setpoints, process variables, and alarm condition indicators. my client wants the monitoring system to reflect any change in an alarm condition within 1 second. since the protocol doesn't support report by exception, i have to poll each set of device alarm indicators at least once a second in order to display them within a second of their occurrence. this is an enormous waste of I/O processing and bandwidth, since a given device indicates an alarm indication on the average of once every three days. 2. support for useful data types i want to be able to get floating point values, and timestamps, and data quality flags, from the device in an unambiguous form. example: i talk to a PLC that maintains a circular buffer of 128 fault records. the fault record consists of a fault type, a fault value, and a timestamp. because the PLC protocol doesnt support timestamps, the PLC programmer has to store the timestamp as a set of register values. my application has to read the registers, reassemble a timestamp from them, and treat it as an attribute of the fault type and value. in the same application, i talk to devices that map timestamps in four different formats, so my application has a bunch of custom code to decipher timestamps. using your average scada toolkit, I/O data must get mapped into tags to be accessible to the application, so i have to invoke conversion code on every upate to convert a set of related tag values into another value. or i have to have a custom driver for the "standard" protocol, which driver contains application-specific code to convert timestamps internally. example: i talk to a PLC that acts as a data concentrator for other devices. the PLC knows whether or not it is communicating successfully with those devices, and reflects the status of its communication with each device in a register. i have to poll the device data and the comm status, and map I/O data into the data quality flags defined by the scada software. which means further application-specific customization of a "standard" protocol driver. if the protocol supported native data quality flags (data not available, stale, remote comm failure, etc), then the PLC programmer wouldn't be forced to kludge around the shortcoming, and i wouldn't have to write a bunch of custom code to generate commonly required I/O status infomation. this is certainly not a comprehensive list of the shortcomings i see in protocols from an application development and systems integration standpoint. but it's a start. -- Greg Goodman -- Chiron Consulting -- [email protected] _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
