Некорректные значения переменных в базе данных

[botanic]

Здравствуйте. Во время работы, сервер MYSQL периодически записывает себе в базу данных очень маленькие значения переменных. Всегда с разных переменных. Самой SCADA это не мешает. Но сильно мешает системе построения отчетов. Отчеты не формируются, если в заданный период попали такие значения. Приходится удалять их вручную. Как такие значения были записаны в базу данных, хотя в реальности их не было? Что можно сделать, что бы они не было? Возможно такие значения появляются, когда происходят незапланированные отключения электроэнергии, но это не точно.

[pan2000]

   Здравствуйте.

Для начала нужно убедиться, что от ОРС-сервера не поступают ошибочные данные. Индикация наличия ошибочных - скрипт "Изменились переменные":

Код: (delphi)

// ОТЛОВ МИНИМАЛЬНЫХ ЗНАЧЕНИЙ
begin
  with Variable do
// выбор минимального порога
//    if (Value <= LowAlarm) and (not IsFirstChange) then  // индивидуальный
    if (Value <= 5) and (not IsFirstChange) then       // общий

      AddMessage(Now, mkAlarm, Name + '=' + AsStr, True, True);
end.

При наличии ошибок желательно их ликвидировать как явление.
И как последнее средство - введение фильтра минимальных значений перед архивированием. Т.е. переменная разделяется на входную (не архивируемую), по изменению которой происходит контроль величины и выходную (архивируемую), перезаписываемую из входной при прохождении контроля.
При условии, что имена входной и выходной переменной отличаются только суффиксом у выходной переменной - скрипт по событию "Изменились переменные":

Код: (delphi)

// ФИЛЬТР МИНИМАЛЬНЫХ ЗНАЧЕНИЙ
begin
  with Variable do
// выбор минимального порога
//    if (Value > LowAlarm) and (not IsFirstChange) then
    if (Value > 5) and (not IsFirstChange) then

      GetVariableByName(Name + '_out').Value := Value;
end.

См. пример.

[Simple_Scada]

Здравствуйте.

Во время работы, сервер MYSQL периодически записывает себе в базу данных очень маленькие значения переменных. Всегда с разных переменных.

Значения внешних тегов поступают в скада-систему от OPC-сервера, после чего архивируются в БД. Ни скада-система, ни СУБД не влияют на значения переменных. Какое значение было получено от OPC-сервера (с учетом настройки параметра переменной "Преобразование значения"), то и попадет в БД.

Возможные причины и рекомендации:
1. На сервере Simple-Scada запущены несколько проектов, которые используют одну и ту же БД, из-за чего проекты будут портить архивные данные друг друга. Для каждого проекта должна использоваться своя БД.
2. Проблемные переменные перезаписываются на ПЛК, либо из скриптов скада-системы.
3. Возможно в проекте имеются скрипты с SQL-запросами, которые записывают данные в стандартную таблицу "trends", что недопустимо.
4. Проверьте журнал сервера Simple-Scada, возможно в нем имеются какие-либо ошибки или сообщения о проблемах в работе OPC-сервера.
5. Проверьте логи OPC-сервера и убедитесь, что они не содержат сообщений о проблемах в качестве связи, работе OPC-сервера или других ошибках.
6. Если найти причину образования некорректных данных поступающих в скада-систему не получится, то можно попробовать отфильтровать некорректные значения переменной, чтобы они не попадали в БД/тренды. Для этого, можно в настройках переменной включить "Фильтр мин. макс" и указать в качестве минимума 0, а в качестве максимума указать максимальное значение, которое может принимать данная переменная. Учтите, что данные, которые не входят в указанный диапазон, будут отфильтровываться, и Вы их не увидите.

[pan2000]

   Здравствуйте.

...записывает себе в базу данных очень маленькие значения переменных. ... Приходится удалять их вручную...

Т.е. речь идет от отбрасывании заведомо недопустимых значений.

Если найти причину образования некорректных данных поступающих в скада-систему не получится, то можно попробовать отфильтровать некорректные значения переменной... в настройках переменной включить Фильтр мин. макс.

Судя по описанию и интерактивной картинке фильтра в редакторе, "Фильтр мин. макс" не отбрасывает недопустимое значение, а конвертирует его в минимум/максимум.
На картинке зеленым цветом показано поведение переменной при условии игнорирования недопустимых значений. Хорошо видно, что площадь под кривой заметно различается для фильтра и при отбрасывании значения.
В этом случае отчет-то может и будет строится, а вот его корректность ещё придется доказать (понятно, что недопустимые значения весьма редкие, и отчет скорее всего не пострадает, но "не аккуратненько").

[ZWolol]

Я сталкивался с подобной проблемой когда значения формата double обрезалось до float путем отбоса лишних байт.
Иногда получалось, что в результате отброса действующее значение становилось равным нулю.
А для дробных чисел ноль в степени не допустим и может привести к ошибке.
У меня даже запись в базу такого значения вызывало потом ошибку при select.

[botanic]

Коллеги. Некорректные значения переменных, которые записываются в базу данных, находятся примерно в диапазоне от -1.0Е20 до 0. Корректные значения переменных могут быть как положительные, так и отрицательные. Поэтому предлагаемый метод фильтрации по минимуму и максимуму не сработает. Проверять и отфильтровывать каждую переменную при помощи отдельного скрипта, при условии, что переменных в проекте около 3000, так себе идея. Хотелось бы понять природу появления таких некорректных значений. Скриптов с SQL-запросами, которые записывают данные в стандартную таблицу "trends" нет. Ошибок от ОРС сервера нет. Все переменные берутся от ОРС сервера без перезаписывания и корректировки в скриптах.

[Simple-Scada]

Возможные причины перечислены в нашем сообщении выше. Нужно выявить откуда в скаду приходят некорректные значения и устранить причину. Сама скада, как и СУБД, такие значения никогда не создаёт. Если у Вас не получается самостоятельно выявить откуда приходят эти значения, то со стороны скады Вы можете только попытаться отфильтровать их, как описано выше.

[ZWolol]

Как вариант можно поставить второй другой OPC и писать данные еще и с него.
Будут ли там такие же значения...
Возможно вы читаете параметры обычного модбас, но по сети.