PICON/RTIME SENSOR DISCRIPTION SENSOR.103 Sensor.103 is a continuation of sesnor.101 and sensor.102. It addresses the problems of "focus from RTIME", "RTIME formula generation", "errors in blind sensors", "unsolicited responses", and "string variables". FOCUS FROM RTIME ------------------------------------------------ One of the more powerful tools avaliable to the knowledge engineer is the ability of RTIME to cause PICON to preform a focus on a unit or category, just as he can focus or activate in PICON. This functionallity has been inplemented in an ad hoc way in both Exxon and Oak Ridge. The functionallity needs to become a generally available feature. What PICON expects is a string input on ttyl4 in the form: (this format is from memory, but very close if not correct) byte SOH Start of header byte binary total lenght this message byte binary length unit name bytes ASCII unit name byte binary length category name bytes ASCII category name Either unit name or category may be omitted by setting their length to 0. Currently there are "custom hacks" in RTIME to generate the above strings. What we need is a standard way to do the focus as well as the custom hacks for special applications. The standard way requires four(4) action items: 1) Insure the PICON focus mechanisum still check ttyl4 for a possible focus. 2) Install the RTIME formula in a sensor frame. 3) Change the RTIME "if" routine to reconigize the verbs focus and activate and send the approprate messages. 4) Define what PICON should do if the category or unit name from a focus is not defined. Note: What does PICON do if a activate or focus name is not defined, my PICON ignores the error!!!! RTIME FORMULA GENERATION ------------------------------------------ RTIME has the ability to run formulas on data. Curently the only place this is used is in the seconds and minutes nodes which is used only as a confidence level that RTIME is running. There are two widlely used needs for using the formulas in RTIME: 1) Preprocessing variables from the distributed system. An example of this is when the supplier does not provide engineering units as values, but rather, supplies raw binary numbers that need conversion to engineering units. The Honeywell TDC200 is this type of system. A typical conversion might be: Engineering units = (raw reading * magic number) + offset 2) Using RTIME to focus on or activate PICON rules. This is a feature we advertise but have never implemented. I had thought that it was never implemented because it caused the "rule tree" printing to be incomplete. However, on testing the current "rule tree" printing on a activated rule I find it does not referance the activating rule, so that can't be the reason. The action items to acomplish this formula generation to RTIME are: 1) Decide if PICON is going to try to parse the rule to see if it is correct. If we decide to parse the rule we can also add pop-up menus like PICON rules to queue the next verb, noun, etc. 2) If we do not parse the RTIME rule, we need to define an error routine so RTIME can notify the knowledege engineer of his error via PICON. 3) Requardless of how we decide the parsing issue, PICON does need to do some "subsitution". RTIME sees sensors as nodes or array indexes in the shared array. Therefore, PICON has to subsitute tag names for node numbers (array indexes). For example: (t101 = PV * 101.1 + 20),(if t101 > 300 focus too-hot) would be entered by knowledge engineer. (N40 = PV * 101.1 +20), (if N40 >300 focus too-hot) would be the form seen by RTIME. NOTE: PV is the process value from sensor and is a reserved word. Since PICON assign the node index at run time that is the time it should do the subsitution. We could even make the knowledge engineer mark the sensors such as: (~t101 = PV * 101.1 + 20),.... ERRORS ON BLIND SENSORS -------------------------------------------- In sensors.102 sets of sensors were discussed. In the case of sets "blind sensors" (sensors that do not appear on the schematic) were generated automatically. There are two additional points requarding blind sensors. 1) Instantiation of the root sensor (process value sensor) does not automatically instantiate all of the blind sensors but only makes them available to be generated if they are used in the knowledge base (a rule). 2) Since blind sensors do not appear on the schematic, some way of dealing with thier errors must be implemented. One way of handleing the errors is to "pipe" the error to the root sensor. If piping is done an ID of the actual sensor must be supplied also. UNSOLICITED RESPONCES --------------------------------------------- By defination PICON is a demand system (i.e. It requests the data it requires.). There are cases where some or all of PICON needs to be data driven. By convention we have called the input of non-requested data unsolicited responces. Again, it is Exxon and Oak Ridge that have forced us to handle this form of data in a ad hoc way. Other users (any financial application for one class) can use this feature. There are three general types of unsolicited responses: 1) Value input associated with tag name. 2) General numeric input, such as, an error number on no specific device, or an operator inputs a number to request some action. 3) String input. Since PICON was designed as a value (numeric) system, the string input will be handled as a seperate subject in the next section. Value input associated with a tag name (or route code) ------- This type of input can be handled nicely if we implement RTIME FORMULA's. The formula can have a focus associated with it and all the right things will happen. PICON will now accept updates from RTIME that it has not requested and put them in its data base (if the node has been defined). General numeric input ---------------------------------------- This type of input falls into two categories: associated and non-assiciated. The associated input would be from something like an operator console with a prompt list of valid responses/request. In this case, RTIME needs to be provided an associated list of "number, focus names" at run time. This list should come from an initial-rule that has a special send verb, so that, RTIME knows to store the list as a look-up table. Then when the unsolicited response is recieved a focus can be generated in PICON. By making the list an initial-rule, the list is dynamic and setable by the knowledge engineer. The non-associated input would be a combination of the tag name input and the associated input. A dummy sensor would be created by the knowledge engineer thur which the value of the input would be passsed and a focus to some point in the "associated list" (probably the first entry in the list) would be done. When RTIME is customized it can make several combinations of the actions happen depending on the user application. The RTIME interfacing guide needs to have a section added to handle these options. The way to send RTIME the "associated list" is to use the process message scheme. A special system ID should be assigned that designates the "associated list". For example: PM:S?:"0,TROUBLE;1,HELP-MESSAGE;..." would indicate: PM: process message string (current defination) S?: system for associated list (? denotes this) 0,trouble focus on trouble routine (default) 1,help focus on help routine (maybe, send prompts) STRING VARIABLES ------------------------------------------------ String variables is something the PICON/RTIME interface has never been defined to handle. This is a weakness that needs to be corrected. When we move to the "AT" as the front end processor and all data is seriallized will be the proper place to address this issue. In the meantime, if we become "hard pressed " by some customer it could be handled thru a ttyl3 stream. But, let's try to avoid getting in the string interface box.