Control systems are generally based on 'pure' numerical values from various sensors and applying those to threshold settings
e.g. if setting = 10, then if measured value >10 the alarm is triggered and certain actions follow.
However sensors have certain accuracy range eg +/- 0.5
Therefore if the sensor is measuring <9.5 it is certain that the real value is less than 10.
However if the sensor is reporting a value of 9.7, the real value could be as low as 9.2 with +0.5 accuracy, or it could be as high as 10.2 with accuracy -0.5.
Similarly if the sensor is giving a value of 10.3, the real value could be as low as 9.8 or as high as 10.8
This is very different to a deadband
This "maybe" state is being referred to as "Three-valued logic"
http://en.wikipedia.org/wiki/Three-valued_logic
Therefore a sensor reporting simply a single value is arguably misleading.
The application is described in this article to some degree:
and by Brian Graham in a series of posts on Linked in SCADA Professionals group:
http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&discussionID=110736462&gid=1887938&commentID=98323340&trk=view_disc&ut=2LYJTR1Suzpls1
Proposal
A simple solution to the dilemma of controlling the process to be certain the real level never exceeds 10 is to set the threshold at 10 minus the sensor accuracy, i.e. 9.5. This implies the accuracy is known at the time of setting the threshold. This suggests the sensor should provide its value with an an additional accuracy range attribute. The IED receiving the sensor value could then provide all information to the operator or do a background 'adjustment' from the operators setting to a value below that by the amount of the accuracy
However this means that the level is not optimised for true maximum capacity and confusion regarding what is the real setting and real level that caused the threshold alarm ot activate.
The alternative proposed is a new "3-level logic" CDC which allows the sensor to issue a range value instead of a single value.
eg for a real value of 9.7 and accuracy +/-0.5 it would report two numbers as the upper and lower linmits of what the real value could be :
{9.2; 10.2]
then the logic is
[9.2; 10,2] > 9.0 ... This is TRUE.
[9.2;10.2] >11.0 ... This is FALSE.
[9.2; 10.2] > 10.0 ... This is MAYBE. It's possible the actual value is greater or less than what it's being compared to.
The control action for the maybe state is to perhaps slow down the pump filling the tank so there is less turbulence on the sensor
Discussion
Created
Status
If the issue is to allow a client evaluation based on the known accuracy of the sensor, then we have two choices: 1. leave it to the client - it has somehow to 'know' the sensor accuracy. Normally the sensor accuracy is chosen so that the application works without having to know it.
2). add some (e.g. minDev, maxDev)optional attributes to the AnalogValue structure,which state the sensor (analog value)accuracy - thus allowing to easily coordinate several clients needing this information.
03 Jan 13
Future Improvement
@ Christoph the LN is basically any T group function which is sending a SV of an analog measurement.
@ Henry The concept is that the sensor itself which is publishing the T SV "knows" its accuracy as defined by the sensor manufacturer. So instead of it publishing an absolute "9.7" value it should really publish the possibility that it is actually somewhere in between 9.2 and 10.2 Hence it is a CDC issue of the format of the number it is publishing
@ Wolfgang the FALSE/MAYBE/TRUE is an issue for the subscribing supervision device which is determined based on the accuracy range reported by the T LN - i.e if the S LN is set to "9.5" it would alarm as MAYBE. If it is set to "9.1" it is clear this is TRUE and if it is set to "10.3" it is clear this is FALSE
21 Dec 12
Future Improvement
I propose to defer that TISSUE for discussion for future Editions of the standard. It is not a topic needing important resolution through the TISSUE process.
Note: The proposed TISSUE status "on hold" shall be changed in the future to "yellow - deferred"
05 Dec 12
Future Improvement
This is not really a TISSUE for 7-3 because 7-3 has to introduce CDCs that are required by data objects. So first we need to define a logical node that would require such a data object.
23 Oct 12
Discussion (red)
I support Wolfgang's opinion. Therefore an addition of a CDC is not necessary.
More, in my understanding the data model should not mix application/function isssues (on LN level) and data format issues (on CDC level). A sophisticated logic with three states may be needed for complex algorithms. But than it should be hidden in a specific LN class. May be you could provide an example for such an algorithm.
22 Oct 12
Discussion (red)
Observe that measurements allow already a limit supervision with a normal (FALSE), warning (MAYBE) and alarm(TRUE) state. This can be used for the above described logic with known sensor accuracy. If we want to generally go into the fuzzy logic calculation, we would probably need some F LN classes for this purpose.