PICON/RTIME SENSOR DISCRIPTION SENSOR.102 Sensor.102 is a continuation of sensor.101. Two issues are addressed in this document: expanded sensor definitions, and more on currency interval whys and procedures. EXPANDED SENSOR DEFINITIONS ---------------------------------------------------- MULTIPLE VARIABLE SENSORS: (NOT array sensors) In classical process control systems sensors are really sets of values, such as: Process Value -- Value read from a sensor in a control loop. Set Point -- The value the control loop is trying to contol the Process Value to be. Output -- The value of the output of the control loop. This is normally expressed in percent. 100% means the item controlled is full open. High limit -- If the Process Value becomes this high an alarm is activated. Low Limit -- If the Process Value goes this low an alarm is activated. etc. -- such as: High alert, Low alert, Loop gain, ... In non-classic applications, such as, finance they might be: Bid -- Price bid for a stock. Ask -- Price ask for a stock. Last -- Price ask for a stock. There are two approches to this set of values problem. One is to use a descrete sensor and icon for each of the values. The second approach is to treat the Process Value sensor as a possible set of sensors. The advantage to the descrete approach is that PICON has to have no know- ledge about the process system. The disadvantage is that the number of icons on the schematic becomes excessive (100 sensors on the system could cause the user to install 500 icons). Further the schmatic has little resemblance to the process. Also rules become less readable, for example: if T101 output is > 80 then ... is clear in meaning if T101-1 is > 80 then ... requires memorizing that -1 is the output of T101 The problem with sets (which is the current implementation after a fashion) is that the values for other than the Process Value are not displayed on the schematic. (The automatic sensors are blind to the user i.e. not displayed in any way.) The current implementation of these sets is very poor. The way it works now is when a sensor is used in a rule the Process Value is assumed but a menu of output, setpoint, high limit, low limit options comes up with the rest of the menu options. The menu option is fine but the list of options is hard coded. Note: this can be seen by creating the if then rule if t100 ... and looking at the menu options A much better way to create the option list would have been to make the options a customer setable list in a table that is editable from retrieve parameters. The parameter could be sensor table and be something like: Sensor Table Extenshion Send to RTIME Process Value(default) (none) Output 1 Set Point SP High Limit 0a Low Limit % (null) In the example a mixture of the types of information to be appended to the tag name is shown. In the current implementation 1 thru 4 is appended to the tag name for the automatic sensors so that the tag name for t101 output becomes t101-1. In Honeywell's TDC2000 there are about 64 different items that can be had from any loop. Of the 64 about 10 may be of intrest to a PICON user. ARRAY SENSORS: Array sensors are different from sensor sets for several reasons: 1) Sets are individual points on the network and each point must be addressed separately whereas arrays have one address and return multiple values. 2) All items within a set are not required by most rules and are thus not read unless needed whereas in arrays most rules require most of the data in the array. 3) Sets create blind sensors whereas arrays create space in the shared memory table. 4) Sets are common for a network whereas a network may have arrays of different sizes. While we have ad hoc arrays at Exxon and Oak Ridge, Picon has never addressed the array problem. A new sensor class needs to be added to handle these arrays. This issue should be discussed with Greg Fossheim at lenght as he has some definate feelings about the proper implementation. It should be noted that RTIME already has the fascilities to handle the arrays, but PICON never implemented its portion in any general release. CURRENCY INTERVAL -------------------------------------------------------------- The consept of currency interval has three points as its basis: 1) Mininize the load on RTIMES network and the distibuted network. 2) Minimize the load on the control loop processor. 3) Insure PICON is using valid (up to date) data. In general any reading from a sensor can be assumed valid for some period of time. The period of time for which a reading is valid is based on the type of sensor and where it is located in the system. For example, two level sensors are in the system: one on a 60 foot diameter tank and one on a 6 foot diameter tank. If the flows in/out of the two tanks are about the same, the smaller tank would have to be read 100 times more often than the larger tank for the same confidance level that the reading was still reason- ably correct. Process engineers as they build a knowlwdge base know how long they can assume the reading valid in a high level supervisory system. These times range from seconds to hours. Don't be confused by the difference in times the supervisory system uses and control system uses. Control systems check and adjust based on times ranging from milliseconds to seconds. The supervisory system is used to adjust the control system and has a different time referance. PICON will never be a control system and was never intended to be a control system. PICON sets at the human operator level and is intended to better human response. The implications of network load on the distibuted system need to be understood. Requests for data have two effects on the distributed system, first it can block vital control loop to control loop communications, and second it takes time away from the control loop computer. If either the distributed network is overloaded or the control loop is overloaded, control is lost and we cause more harm than good. Of course, this only applies to control systems and not financial systems that stream data. Some of the more recient control systems have attempted to over come this problem by broadcasting data to a host which in turn makes it available to a super- visory system. But, these systems are not in wide use. Westinghouse uses the broadcast method. Both PICON and RTIME have mechanisms to minimize the data request load where needed. These mechanisms fall into four classes: 1) Currency interval on a sensor. 2) Accessing only the data of intrest at the current time. 3) Two modes of reading a sensor: continous and demand. 4) Network throttleing in RTIME. Currency interval: The time a reading can be assumed good. While this time period lightens the network load it increases the load on PICON. First, all sensor data must be time stamped as the values are moved into PICON's data base. Second all referances to the data within PICON must check to see if the data is still valid. Lastly, if one of several data points in a rule causes PICON to wait for an update, the other data must be rechecked to see if it is still valid. To help alleviate some of the problem, when PICON autoprgrams RTIME it gives RTIME a slightly shorter currency interval (one base time - base time discussed later) than PICON has. Thus, if there is a time "jitter" on the network, PICON does not see it. Accessing only data of intrest: While, at run time, PICON auto programs all of the known nodes (sensors), it only activates the nodes from which it needs data. In release 1.2 and before there was a problem with this algorithum (more about the algorithum is in the section on two modes of reading). The problem is some sensors need to be read on a continous basis weather or not they are being accessed at the currrent time or not. Examples include rate of change and historical values (as of 5 minutes ago). This problem was addressed in 2.0 by adding a field to the sensor frame that could specify read continously or requardless of currency always get a new reading. This should be implemented in the next release. Two modes of reading: RTIME has two modes of activation for a node, continous and demand or activate and single read (TA AND TS). With the execption of setting a setpoint nodes, PICON assumes when a node is first accessed that the data will be needed in continous mode and RTIME is sent a TA command. If PICON then recieves four (4) sequential updates from RTIME that are not used the node is deactivated (TD). Further values from RTIME for that node are in single reading mode (TS) untill two readings in suscession are needed within two currency intervals and then the node is returned to active (TA) mode. [ At least that is the way it was spec'ed] Network throttleing in RTIME: The RTIME parameter file contains an entry for each network for the minimum time between network accesses. This throttleing can affect PICON in that data supplier problems can start occuring (RTIME not suppling data in time). On the list of things to do an entry needs to be made to address the problem of how RTIME notifies PICON of a throttle problem and the proper procedure for PICON to follow in this case. Basetime: The time RTIME's scheduler advances on. Normally 500 milliseconds set from PICON. Originally, when only one distributed system was invisioned on the system, it was planned that PICON could do a gracefull degeration when throttleing occured and derate the base time to a higher value thus slowing down the system with one command. With multiple networks this is no longer a good ploy. Base time still has a value however, if RTIME itself becomes overloaded a larger base time would effectly reduce the load.