Event detectors - Add the option of a limit defined by another datapoint

[fabiodurao]

As per the illustrative image below, it would be very productive to have the option of creating event detectors with the 'upper limit' option, for example, where instead of the user defining a fixed limit, he can place a limit defined by a datapoint intended to be a process setpoint for example.

Imagine the situation in which a process may have a limit that is adjusted for each recipe or that the operator makes manual adjustment in certain situations, there could be a text field in the graphical representation (created with a script for the server, already possible with current resources) where the operator can set this upper limit whenever necessary. If the event detector uses this datapoint as a reference, it will be much faster to define thresholds and events. This could apply to limits of the type: High limit, Low Limit, Positive CUSUM, Negative CUSUM. The names of the fields in the drawing below can be changed, I just copied what already exists in the "setpoint type event handler".

The alternative to doing the same thing today would be to create a meta datapoint that receives in context the datapoint with the setpoint function and the datapoint that is being compared and create logic that when the real datapoint is greater than the setpoint datapoint returns TRUE or FALSE , thus creating an event detector so that when the state is TRUE, it generates the datapoint. In addition to being more time-consuming and laborious, additional datapoints are created to confuse a list of variables, which could be resolved in a much simpler way.

[Limraj]

@fabiodurao, according to our architecture, actions are implemented by Event Handlers, not detectors, these are only used to detect some state. We have a Set Point Handler that performs this task. We can connect many such Event Handlers to each detector, so this proposed setting is unclear what it would mean and would cause confusion.

Regards, Kamil Jarmusik

[fabiodurao]

@Limraj I believe you didn't understand what was proposed. We are not talking about taking actions, but rather triggers for taking actions. The current limitation is that it is only possible to have static thresholds for event detectors, this would allow to have a "dynamic" threshold. In fact, the intention is not for the limit to fluctuate, it could be a virtual datapoint - numeric - without updating - linked as a limit, but for the operator to be able to define this in the graphical representation.

This is based on the premise that I and many other users do not like to let the supervisory operator enter the settings screens and change anything there and we do not want to give permission to do so. We generally block the operator's navigation in the fullscreen graphical representation, we even add the logout button to the graphical representation with an HTML component so that he does not need to use the standard menu or to log out.

Adding the value of a datapoint as a threshold reference would be extremely useful.

Regards

[Limraj]

Okay, I understand the idea of ​​a dynamic limit (from a point), and I understand that it can be useful. However, it seems to me that in your justification you are looking for a solution in the wrong place. Only the administrator can change the configuration. User non-admin with permission to data point (min read), he can only access the point properties using the loupe button, but he cannot change anything there. In Scada-LTS we have settings that limit the main menu and force e.g. fullscreen for the graphical view, and hide info shortcut fullscreen, this can be combined with setting the graphical view as the home page, then the user after logging in is immediately transferred to the fullscreen graphical view screen. If you do not logout, the session lasts 30 minutes.

[fabiodurao]

Ok, this time it was me who hadn't understood you, but now I understand. The limitation you mentioned makes sense, but see, I don't intend for it to be available for the common user to set which datapoint will be used as a limit, this must be done by the admin user himself. However, as we can limit access to a datapoint in the user profile, if the admin releases access to the datapoint created specifically for this purpose and which was linked as a limit, I don't see a problem with this common user just changing the value of this datapoint and the same change the event limit.

I imagine that if this is implemented it would work as follows with 2 datapoints, dapoint_real and datapoint_limit as upper limit for example:

1st user sets the datapoint_limit = 40 when datapoint_real > 40 then triggers an event

2nd If the datapoint_real <=40 or if the user sets the datapoint_limit to a value higher than the datapoint_real at that moment, then the event returns to normal.

[Limraj]

@fabiodurao That is, you are right that another user with set permissions on the limit point could change the value, and only read could be shared with other users. Although, in my opinion, the main benefit of this solution would be the ability to control this limit by an external PLC, which allows you to configure the detector closer to the changing actual values ​​of a given parameter, if the calculation of these limits would be a very complex and demanding operation (e.g. a neural network is used), or we would like to keep it secret how we do it on the plc side.

What you are writing about could probably be achieved through a virtual/modbus data point that would define the limit and a meta data point that would return some state, depending on the dynamic limit(modbus plc) or limit set by the user(virtual), on which you can set a detector that detects a given state and handlers that take action...

[fabiodurao]

I didn't understand the idea of the value received from a PLC and a neural network.

What I suggested can already be done with a meta datapoint and another logic, and another true or false value detector returning the metadatapoint, but it is much more work, it would speed up several projects, where the client has someone internal with an administrative and who wants a screen to configure limit parameters.

Does this make sense to implement or does the fact that there is already a path, however long it may be, make implementation unfeasible?