Комментарии 11
А разве в технологических картах реактора не прописаны диапазоны значений? Или сборка данных не подразумевает их чистку на месте сбора?
В ядерной энергетике никогда не работал, но с теми промышленными объектами, на которых работал ситуация следующая. На первом уровне сбора информации данные никогда не подвергаются изменению, показывается все как есть. Уже на следующих уровнях происходит верификация, нормализация, отбрасывание части значений, но при этом "сырец" всегда храниться.
К сожалению, встречал кейсы, когда данные вообще не хранились, либо сохранялись только после каких-то преобразований. По опыту: чем выше уровень автоматизации и цифровизации, тем чаще хранятся сырые данные и вообще стратегия работы с данными становится осмысленнее и лучше с точки зрения машинного обучения и data science.
Речь в статье идет скорее о промышленных производствах и других менее "опасных" и "закрытых" объектах промышленности, а не о реакторах или АЭС в целом.
Не могу ничего, к сожалению, сказать про данные на реакторах)
Я бы еще добавил сюда два довольно типичных дефекта, которые серьезно нарушают однородность сигнала:
1) псевдозапись и
2) изменение масштаба.
Псевдозапись - это когда в измерительной системе что-то "заклинивает" и она начинает писать одинаковые или почти одинаковые значения. По моему опыту, это совершенно типовой брак. Я почти не встречал сколько-нибудь длинных рядов относительно высокочастотного мониторинга (с дискретизацией 1 Гц или выше), где этот дефект отсутствовал бы. Мы для выбраковки таких серий включили в свой пакет специальную функцию, которая чистит временной ряд от этого брака. На вход она берет количество одинаковых значений данных (=минимальную длину бракуемой серии) и критерий "одинаковости" (чтобы функция считала одинаковыми слегка флуктуирующие значения, а не только в точности совпадающие). И еще: когда будете делать свой вариант, не забудьте, что такие повторяющиеся значения могут чередоваться с пропусками данных - брак от этого не перестает быть браком.
Псевдозапись надо обязательно выбраковывать, если при обработке считаются любые фрактальные статистики или оцениваются свойства высокочастотной составляющей. Иначе алгоритм будет безбожно врать, как только в скользящее окно попадет подобный фрагмент.
Второй баг - это скачок коэффициента масштаба. Очень часто при замене датчиков или блоков в системе регистрации новый коэффициент усиления (умножения) не равен старому, хотя теоретически блоки/датчики идентичные. Но по данным разницу видно сразу же, если сигнал достаточно однородный.
Вообще, если в рядах есть сдвиги (скачки) уровня, то с очень большой вероятностью там и с масштабом не все гладко. Поэтому у нас оценка постоянства масштаба входит в базовый алгоритм "дефектоскопии данных". Для проверки наличия такого сдвига можно посчитать дисперсию высокочастотной составляющей ряда в скользящем окне и проверить ее постоянство. Мы для этого сперва жестко убираем из сигнала все, что хоть немного похоже на выброс, потом убираем низкие частоты ядерным сглаживанием, потом считается дисперсия сигнала в скользящем окне, затем полученный ряд скользящей дисперсии сглаживается медианой, и уже этот ряд скользящей медианы тестируется на скачки/сдвиги.
Впрочем, найти скачок масштаба - это только полдела, потом его еще устранить надо, чтобы сделать ряд однородным. И вот тут обычно оказывается, что скачок масштаба сопровождается еще и сдвигом уровня, т.е. нужно делать полноценное линейное преобразование по типу Ax+B с оцениваемыми коэффициентами А и B, а не просто умножить на что-то.
А разве в технологических картах реактора не прописаны диапазоны значений? Или сборка данных не подразумевает их чистку на месте сбора?
Заведомо нереалистичные значения (типа отрицательной амплитуды), конечно, надо отсекать сразу. Но очень часто в данных есть менее очевидный брак, для выявления которого нужно проводить специальный анализ, иногда с участием эксперта. Мы у себя поэтому ведем не одну, а две базы данных: с первичными сигналами и с почищенными.
В первичную базу данных грузятся непосредственно те сигналы, которые
поступили с регистраторов
У нас это ana+anp-файлы, которые записываются где-то на пункте наблюдений, а затем по сети пересылаются в центр обработки с определенной регулярностью. Эти данные грузятся в "черновую" БД и сшиваются в непрерывный ряд в автоматическом режиме, сразу по мере поступления.
Затем полученные данные проходят через процедуру очистки (у нас это называется первичная обработка, и ее обычно контролирует оператор), и только после этого они загружаются в "чистовую" БД, которая используется для анализа наблюдений. При этом первичные (нечищеные) сигналы тоже хранятся, и к ним всегда можно вернуться - например, если захотелось что-то подкрутить в алгоритме первичной обработки.
Такая архитектура системы обусловлена спецификой научного мониторинга, основная цель которого - изучение наблюдаемых процессов, а не управление ими. Фактически у нас нет задач реального времени: анализ ведется преимущественно ретроспективно. В зависимости от вида наблюдений, запаздывание обработки может составлять от суток до месяца, а иногда бывает и больше. А оперативный контроль данных нужен прежде всего для того, чтобы убедиться, что измерительная система работает и с ней все в порядке.
И хотя проблемы качества рядов данных у нас практически те же самые, но отсутствие требования работы в реальном времени сильно расширяет арсенал инструментов, доступных для их решения. Напоследок приведу пару ссылок на публикации, где обсуждаются используемые у нас методы и подходы:
Развитие систем прецизионных наклономерных наблюдений в условиях подземной обсерватории
А полные тексты этих статей выложены вот здесь.
Частично в узкой сфере наблюдения за более-менее стабильным процессом нас на кафедре учили использовать метод главных компонент, который убирает множество недостатков, но это применение в промышленности. Его недостатки достаточно сложный мат. аппарат на матрицах, зато интерпретировать можно хоть нечеткой логикой, хоть экспертными таблицами.
Интересно Ваше мнение, с какими из представленных проблем он борется (или какие недостатки убирает), потому что в первую очередь мне он знаком как метод снижения размерности
Для сложных случаев уже необходимо синтезировать совмещенные системы.
Спасибо за дополнения и ответы на вопросы, а также за полезные материалы!
У меня в основном глючит сеть. Ничего если это - температура с периудом опрса 10сек. Но скорсти и нагрузка приводов - это критично.
Проблемы качества промышленных данных (временных рядов)