Modbus point not observing "Discard extreme values" during point write

[Pedro]

I recently created a new Modbus Holding Register "Settable" point under core 2.7.12 build 481. Discard extreme values is set, and both Discard low limit and Discard high limit are set to three-digit positive integers. The Logging properties Logging type is set to "When point value changes."

When I set a new point value via data_point_details.shtm that is above or below the Discard limit values, the point value is immediately written to the Modbus register, according to both tcpdump and to the reaction of the Modbus device. Even though the invalid value is written to the Modbus device, the invalid point value is not displayed on the point, neither on data_point_details.shtm nor on the graphical view, nor is it displayed in the point History. Shortly before and after the time of the point entry, no unusual entries were observed in ma.log.

[phildunlap]

Hi Pedro,

That's an interesting observation! I am curious, what do you think the desired behavior should be? Do you think it is better to tell the user they are wrong in setting such a value or to have the data source send and record the extreme value?

I don't believe discard extreme values was ever intended to handle outbound traffic, which may make either of these situations require core changes. I would wonder from a systems design perspective if this situation doesn't speak to a potential to improve the responsibilities of the devices. Namely, if there is a value that is too extreme for Mango to consider it valid, why isn't that value too extreme for the PLC to consider it valid and refuse the set? I would think that solving this problem by preventing Mango from sending out the value would still enable a nefarious or untrained actor to set the value and have it avoid detection by someone only using Mango (I imagine it would trigger a no update detector, though), as would solving the problem by recording the extreme value when set from the user.

[Pedro]

Hi Phil,

Honestly I was surprised to find that Mango does not check for extreme outgoing values. It is seriously problematic on multiple levels, and I feel strongly that discarding extreme values must occur by default when setting a point value, even if that is done only on the back end, with no front end interface changes. When I first posted this, I thought it was a bug.

We must not assume that just because certain equipment supports a particular value setting, the process or application that it controls should accept the value without causing harm. We must also not assume that all PLCs in different devices at a site are available for customization by their end users, nor that the Modbus device is a PLC at all.

Picture a scenario where you have an oven that can be commanded to heat anywhere from 25 to 200 Celsius. The oven is an off-the-shelf device whose firmware is not customized by the end user: it just does what is commanded.

In your process, you do not want to heat the contents above 75 Celsius because it will damage the batch. The operator usually enters a number between 25 and 75 Celsius, but one day he enters 96 instead of 69 Celsius, which destroys the batch. Moreover, if the admin had configured "Discard extreme values" to 75 Celsius, the typo would neither be caught nor logged by Mango, and the user would not be alerted. I think this is dangerous.

This is made more dangerous by the fact that when extreme values are set:

• the extreme values are rejected by meta data points but not by Modbus points.
• the extreme values are not displayed in any of the Modbus point views
• the user is not alerted about the entry error

The Meta data point extreme value behavior seems to be what users would expect, but the combination of "proper" metadata extreme value behavior and extreme value hiding by Modbus points leads admins into thinking that extreme Modbus values are rejected. I would not have discovered that they are not, were it not for tcpdump and a Modbus device that contains a derived value at another register address.

I could cite more examples using liquid levels, voltages, currents, etc, where the equipment manufacturer allows a wider range of values than what would be desired for the particular application. It is impractical and often infeasible for each manufacturer to customize their equipment to each application; that can be done by customized end-user software at each installation site. Even if the PLCs are configured for a certain value range, Mango must allow that value to be further constrained by the point configuration.

The obvious short term solution to prevent this dangerous behavior is to apply the extreme value range when the point value is set. I truly believe that is the configuration most users would want, and may in fact think they have. I think this should be a priority.

Do you think it is better to tell the user they are wrong in setting such a value or to have the data source send and record the extreme value?

I think it is safest to reject the value rather than setting the limit value on the Modbus device: when there is an error, it is best to assume it is a typo rather than a deliberate error. The user has the opportunity to manually enter the limit value after reading the alert. The alert should include the value limits, the entered value, and the point name.

Longer term solutions could be applied, but I don't consider them a priority compared to limiting the set value on the back end, with no front end changes. For instance:

• Immediately alert the user when discarding an extreme value that was set.
• Display the extreme value range next to the point value data entry field
• Allow separate extreme value settings for data entry vs. logging. I cannot think of a use case for this, even though it is the current behavior, in that the current range allowed is different: it is the entire floating point value range.

If any changes are made to the extreme value point logging code, rather than the above listed options, I think it makes more sense to allow the user to choose an event level to generate when extreme values are discarded. However, implementing the ability to limit entered point values for Modbus points rather than just Metadata points should be a high priority. I consider it a bug fix, because I cannot think of a reasonable scenario where a user would want to reject read and logged extreme values but not reject set extreme values.

[phildunlap]

I understand and agree that the behavior of setting the value and not reading it back is the least ideal situation, compared to not setting the value and saving the extreme set value. Technically 'discard extreme values' is a logging property, so it may not be the safest assumption it handles more than logging. That said, I completely see the merit in your argument.

I agree that we cannot assume everything is a PLC with that degree of customization, but my point was along the lines of: if your system relies on these components not getting these factory permissible values, then someone can attack the system by sending these messages over the network by some means other than Mango. Nothing Mango can do will plug that hole. I do agree Mango should enforce this restriction, but it cannot be the only responsible party for the values in those devices. If it is, it would be more prudent to alert at values over the threshhold you have supplied, rather than discard them. But, that would remove coding in the restriction on the set, since you would be handling this situation with event detectors.

The meta point and the modbus point have the same handling, it's the data sources that behave differently.

It is certain we will resolve this issue, but fully resolving this for all modules will be in the core or individually in every module.

[Pedro]

Your point is well taken regarding attacks. Our network is firewalled and segmented to limit network access to equipment. Additionally, on critical equipment we have hardware lockouts that reject Modbus write commands. Some equipment may be momentarily switched to accept write commands for maintenance, but that requires physical access to the hardware. I have also added voltage supervisor relays to disable equipment if it goes outside preset voltage limits that can only be set by hand. Nonetheless, we like to use Mango to further narrow the value ranges, so we still need protection from an operator inadvertently entering an incorrect value when in maintenance mode.

After the discarding of extreme Modbus set values is implemented, if it is not quickly followed by a new core release, can you please send me a patch? Thanks. Meanwhile, I will watch for a github issue on this matter.

[phildunlap]

I have created a github issue: https://github.com/infiniteautomation/ma-core-public/issues/851

I have also emailed you a modbus module that will reject extreme sets, but I am not going to release this as I suspect we'll fix the extreme values issue in the core.

[Pedro]

I installed your modbus module, and it seems to be working as expected. Thank you very much for addressing this so quickly. I really hope that the next release discards extreme values when setting points.