ArchiSense. Интеллектуальные системы мониторинга зданий и сооружений. Теория, методы практика

Рисунок 7. Рабочий стол системы ArchiSense

Узлы сбора данных и edge-контроллеры

ArchiSense – это условное название интегрированной платформы мониторинга здания, включающей аппаратные и программные компоненты. Архитектура обычно многоуровневая. Нижний уровень сами сенсоры и первичные преобразователи, распределенные по объекту. Они могут подключаться к локальным узлам сбора данных (ДСУ – датчики, сбор, управление). Эти узлы представляют собой небольшие контроллеры на краю (edge), размещенные, например, по техническим этажам или зонам объекта. Каждый такой контроллер собирает данные с группы датчиков поблизости (по проводной связи или беспроводной) и выполняет предварительную обработку: оцифровку, фильтрацию, агрегирование. Кроме того, на контроллеры возложены функции локальных триггеров событий, они могут анализировать поступающие значения и при наступлении заданных условий (превышение порога, появление резкого всплеска, пропадание сигнала) немедленно реагировать, сохранить фрагмент с высокой частотой, отправить тревожное сообщение на верхний уровень. Это позволяет разгрузить сеть и центральный сервер, не передавать гигантские потоки постоянно, а только полезную информацию. Локальные вычисления близки к концепции фог- и edge-computing, когда часть интеллектуальной обработки выдвигается ближе к сенсорам. Как отмечено в исследованиях по безопасности, edge-контроллерный слой собирает данные с датчиков, выполняет первичную фильтрацию и пороговый анализ, а также при необходимости передает управляющие команды обратно на сенсоры (например, изменить частоту сбора). В связке с ними может работать контроллер управления – это устройство, получающее команды от центральной системы и способное замыкать локальные исполнительные механизмы (включить сигнализацию, перекрыть клапан и т.д.).

Средний уровень – это шлюзы связи и сервер сбора данных. Edge-узлы соединяются с верхним уровнем по различным каналам, зачастую через шлюз это устройство, конвертирующее протоколы. Например, беспроводные датчики связываются с ближайшим шлюзом, который уже через Ethernet или сотовую сеть подключен к центральному серверу. Центральный сервер (или кластер) выполняет роль хранилища и процессора данных. В ArchiSense центральный компонент – это программное обеспечение, реализующее сбор временных рядов, хранение, обработку, визуализацию и обмен с внешними системами. Сервер может быть физически расположен на объекте (например, промышленный компьютер в диспетчерской) или в дата-центре (облачное решение).

Для повышения надежности архитектура ArchiSense предусматривает резервирование, а именно ключевые узлы дублированы, а связь построена с автономными сценариями. Мы считаем, что данный вариант является максимально безопасным и надежным. Например, если центральный сервер потеряет связь с некоторыми контроллерами, они могут автономно работать и записывать данные локально (на SD-карту) в течение некоторого времени, а затем переслать по восстановлении связи. Если отказывает отдельный сенсор, система отмечает канал как неисправный, но на основе соседних датчиков и моделей может иногда экстраполировать данные, пока ведутся ремонтные работы.

Беспроводная и проводная связь

Передача данных от сотен сенсоров непростая задача, особенно если требуется реальное время. ArchiSense может использовать комбинацию протоколов. Для локальных сетей датчиков часто применяются легковесные IoT-протоколы: MQTT (publish/subscribe модель над TCP/IP), CoAP (Constrained Application Protocol, аналог HTTP over UDP для упрощенных узлов), или AMQP (Advanced Message Queuing Protocol) для гарантированной доставки в более требовательных сценариях. Например, edge-контроллер может выступать MQTT-клиентом, публикующим топики с данными сенсоров (например building1 / floor2 / strain / beam12 = 150 µ) на MQTT-брокер на сервере. MQTT хорош своей малой нагрузкой и возможностью работать при нестабильной связи, контроллер буферизует сообщения и отсылает при подключении. CoAP может использоваться, когда нужно прямое обращение «запрос-ответ» к датчику (например, запросить разово его состояние), он эффективен по UDP и подходит для сетей с минимальными ресурсами. AMQP более тяжеловесен, но обеспечивает очереди, транзакционность его могут использовать подсистемы ArchiSense для интеграции с корпоративными шинами данных, где нужна надежность доставки.

Хранилище временных рядов и каталог данных

Серверная часть ArchiSense отвечает за приём и долговременное хранение данных. Поскольку данных много, и они имеют временную природу, используют специализированные СУБД временных рядов (Time Series Database), например, InfluxDB, TimescaleDB, либо распределённые хранилища (Apache Kafka + Hadoop и пр.). В них данные хранятся как точки во времени: метка + значения + теги (идентификаторы датчика, объекта). Такой подход оптимизирован по скорости записи и агрегирования по времени. Для каждого канала (датчика) создается временной ряд, многие СУБД позволяют автоматически вычислять агрегаты (например, среднее за час) и хранить их для ускорения аналитики. Кроме сырых данных, база содержит события (events), пометки о наступлении какого-то факта (сработал порог, произведена калибровка, датчик вышел из строя). Важным компонентом является каталог сенсоров – это метаданные обо всех датчиках и каналах системы. Каждый датчик описывается: тип, модель, серийный номер, расположение (привязка к элементу конструкции или координатам), единицы измерения, диапазон, дата последней калибровки, статус (в строю или отключён). Это можно рассматривать как базу данных устройств (CMDB), связанная с BIM-моделью. Система ArchiSense предоставляет интерфейс для доступа к этим данным: так, аналитический модуль может запросить список всех температурных датчиков на 5 этаже или все датчики типа «тензодатчик» с шагом измерения 1 минута, и затем получить по ним данные.

Отдельно продумывается схема версионирования и аудита данных. Поскольку данные мониторинга могут использоваться в официальных отчётах и даже суде, важно хранить исходные неизменённые данные (raw) и все произведённые над ними преобразования. Если производится корректировка, то исходные значения не удаляются, а создаётся новая версия, а старая помечается как не использовать. В современных СУБД реализуют концепцию версионированных таблиц, позволяющих запросить данные на любую дату прошлого с учётом того, что было тогда известно. Это важно для трассируемости изменений, можно показать, что неугодные данные не потеряли, а учли с объяснением причины. Аудит подразумевает ведение журнала всех действий пользователей, кто и когда изменил настройки датчика, откорректировал данные или подтверждал тревогу. ArchiSense, как платформа, регистрирует эти события. Журнал и версии помогают соблюсти требования стандартов.

В системе также реализуется резервное копирование: периодически вся база (или её критические части) копируются на резервный сервер. При отключении основного, резервный может принимать данные (возможно, с некоторой деградацией функций реального времени). Реализация хранением и доступом сильно зависит от масштаба системы: у небольшого здания – это может быть просто SQLite база на одном ПК, у моста – это распределённое облачное хранилище с веб-интерфейсом. Однако принципы единны, оптимизация под временные ряды, хранение отношений «датчик-элемент конструкции», версии и аудит.

Контроль качества данных

Перед использованием собранных данных их необходимо подвергнуть контролю качества. Во-первых, выявляются пропуски данных (missing data) это периоды, когда от датчика не было показаний. Причины от сбоя связи до отказа сенсора. ArchiSense автоматически маркирует такие интервалы, и, если это критичный канал, может выдавать оповещение при пропуске больше заданного интервала. Пример: наклономер должен давать данные раз в минуту, если нет данных 10 минут это сигнал тревоги о возможной неисправности. Во-вторых, отслеживаются выбросы (outliers) это разовые невероятные скачки измерений, обычно из-за помех или ошибок. Например, если тензодатчик обычно показывал ~100 με, а в одном отсчете дал 5000 με и вернулся назад – скорее всего, это выброс. Используют несколько подходов: простые пороговые (отсекание значений вне физических границ), статистические, например, по методу межквартильного размаха или по 3σ отклонению от скользящего среднего. Также применяют правило монотонности: некоторые данные не могут резко меняться (осадка фундамента не может прыгнуть вверх, только плавно вниз). Обнаруженные выбросы помечаются флагом, исключаются из аналитических расчетов и могут замещаться оценками, например, линейной интерполяцией соседних корректных точек. Далее, контролируется дрейф нуля и чувствительности (bias, drift). Для этого иногда в систему включают «нулевые каналы» – это датчики, которые не должны испытывать воздействий. Если они начинают показывать не ноль, значит, сдвинулась нулевая линия. По ним и по статистике остальных можно судить о необходимости ретрокалибровки. Например, если все термометры вдруг показывают +3° C, а должно быть ~0° C (снег, мороз), вероятен систематический дрейф, поправка. Однако чаще дрейф учитывают при плановом обслуживании. Синхронизация каналов: ArchiSense следит, чтобы данные, помеченные одним моментом времени, действительно относятся к одному физическому времени. При объединении разнородных источников (геодезия, датчики, метеоданные) могут быть рассогласования часов. Платформа либо приводит все к единому временному стандарту (UTC с поправкой часового пояса), либо к меткам от главного сервера. Если замечено постоянное рассогласование (например, один сенсор всегда на 2 секунды позже), вносятся поправки автоматически при записи. Наконец, фильтрация шума: для некоторых каналов сырой сигнал очень шумный, и хранят или анализируют сглаженный. Используются цифровые фильтры – это скользящее среднее, медианный фильтр (для выбросов), более сложные калмановские фильтры. При этом оригинал все равно сохраняется, чтобы не потерять информацию. В рамках DQA система формирует отчеты о качестве, процент пропусков, число выбросов за сутки, текущий дрейф. Если показатели выходят за нормы (например, больше 5% выбросов) выдается предупреждение операторам, поскольку это может говорить о начале отказа датчика или о внешнем воздействии, например, заливание водой вызывает шум. Таким образом, прежде чем данные пойдут в глубокий анализ, они очищены и приведены к сопоставимому виду, что предотвращает ложные выводы. Согласно опыту, до 5—10% сырого объема данных SHM могут быть помечены как некорректные и требуют внимания или коррекции.

Алгоритмы обнаружения аномалий

Главная задача мониторинга – это обнаружение аномальных ситуаций (повреждение, перегрузка) на основе сенсорных данных. Для этого в ArchiSense реализован многоуровневый подход к поиску аномалий. Простейший уровень, пороговые правила: для каждого датчика или индикатора заданы безопасные пределы. Например, прогиб балки не должен превышать l/250, или виброскорость 5 мм/с по ГОСТ. Если значение переходит порог, фиксируется событие. Преимущество – это простота и ясность (меньше ложных срабатываний при правильно выбранных порогах). Недостаток – это не ловит постепенные деградации, если они остаются ниже порога, и не учитывает корреляции между параметрами. Поэтому вводят более умные статистические методы. Один из них модели временных рядов (ARIMA, ETS) для прогноза поведения и сравнения с фактом. Например, ARIMA-модель обучается на прошлых данных температуры и деформации и прогнозирует, какой должна быть деформация сейчас. Если фактическая намного отличается от предсказанной – это аномалия. Такие методы хорошо работают для стационарных или сезонных процессов (температура, осадка с годовым циклом), по ним строят прогноз с доверительным интервалом, и если реальный тренд выходит за доверительный интервал – сигнал. Применение сезонно-трендовых декомпозиций (например, STL) позволяет отделить долговременный тренд и выявить аномальный скачок поверх тренда. Также, ARIMA с внешними регрессорами (ARIMAX) используется для детектирования аномалий через анализ остатков, так, в работах показано, что ARIMAX-модель, учитывающая сезонные факторы, может эффективно распознавать аномальные отклонения по статистическим тестам на остатки. Следующий уровень, машинное обучение для outlier detection. ArchiSense может применять обучение без учителя на исторических «нормальных» данных: методы Local Outlier Factor (LOF), Isolation Forest и их аналоги. LOF оценивает локальную плотность данных вокруг точки и сравнивает с плотностью соседей: если точка сильно разреженно расположена – это выброс. Isolation Forest строит случайные решающие деревья, пытаясь отделить точки; точки, которые изолируются за мало шагов (легко изолируемые) – считаются аномалиями. Эти методы способны обнаруживать сложные взаимосвязанные аномалии, например, невзаимосвязанный с температурой рост деформации: когда обычно деформация ростом 1 мм соответствует +10° C, а тут 3 мм при том же изменении температуры – алгоритм ловит как аномальный мульти-вариативный вектор. Преимущество – это не нужно задавать конкретный порог, система сама «понимает» норму по данным. Недостаток – это возможны ложные срабатывания при смене режима работы здания (например, включили новое оборудование, изменился характер вибраций, для алгоритма это может выглядеть как аномалия, хотя всё нормально). Поэтому по возможности модели периодически переобучают, либо используют адаптивные пороги. Еще более продвинутый уровень, глубинные нейросети, обученные выделять особенности (feature extraction) и распознавать паттерны. Популярны автоэнкодеры – это нейросеть, сжимающая входной многомерный сигнал в латентное пространство и потом восстанавливающая. Если подать на обученный автоэнкодер нормальный сигнал, он восстановит хорошо, а аномальный плохо (большая ошибка). Это служит признаком аномалии. Также применяются LSTM сети для временных рядов, которые прямо прогнозируют следующий шаг и сигнализируют о всплеске ошибки предсказания (как вариант – LSTM-автоэнкодер, объединяющий оба подхода). Например, LSTM, обученная на нормальных вибросигналах моста под обычным трафиком, заметит резкий выброс в момент аварии (пролом настила), потому что это событие никогда не видели раньше, и модель выдаст большую ошибку. Глубокие модели могут улавливать сложные взаимосвязи и нелинейности, однако их внедрение требует больших объемов обучающих данных и осторожности с интерпретацией (так называемый «black box»). В практике SHM часто комбинируются подходы: сначала простые пороги (для явно аварийных ситуаций), затем статистика (для трендов), и параллельно ML, дающие ранние предупреждения. Например, ArchiSense может выдавать предупреждения уровней: информационное (сработал ML-алгоритм, нужна проверка инженером), предупреждение (превышен статистический прогноз, высокая вероятность проблемы) и авария (достигнут явный порог, необходимо немедленное действие). Такой многоступенчатый подход снижает риск пропустить проблему и уменьшает число ложных тревог, что важно для доверия к системе пользователями.

Идентификация мод по сети датчиков

ArchiSense может отслеживать изменение модальных характеристик во времени автоматически. Имея сеть датчиков (например, 12 акселерометров по этажам здания), система периодически (раз в сутки или непрерывно в скользящем окне) выполняет операционную модальную идентификацию (OMA) и извлекает основные собственные частоты и формы. Затем эти моды сопоставляются (tracked) с базовыми через критерий MAC. Например, изначально у здания первая частота 0.5 Гц, вторая 1.2 Гц. Спустя год OMA показывает пики на 0.48 и 1.17 Гц с немного другим демпфированием. Система через максимальный MAC определяет, что это те же моды, и строит тренд: частота №1 снизилась на 4%, частота №2 на 2.5%, демпфирование №1 выросло с 2% до 3%. Сдвиг частот часто указывает на размягчение конструкции, либо появление трещин, либо снижение жесткости грунта основания, либо добавление массы (например, надстройка оборудования). Рост демпфирования может свидетельствовать о зарождении микроповреждений (они рассеивают энергию) или об изменении контактных условий узлов. В ArchiSense реализованы алгоритмы кластеризации мод по времени (методы модального трекинга), например, каждый новый набор мод сравнивается с несколькими предыдущими, чтобы отстроиться от ложных мод (спуриев) и стабилизировать результаты. В итоге получается временной ряд модальных параметров. Его уже можно анализировать на предмет тенденций (трендов) и аномалий. Например, если частота начала систематически снижаться быстрее, чем можно объяснить сезонным эффектом (частоты часто слегка падают зимой, когда материал охлаждается, и поднимаются летом, но это периодично), система выдаст предупреждение. Данная функциональность, одно из проявлений создания «цифрового двойника» динамики конструкции, который обновляется по данным. Реализовать её достаточно сложно, но существующие пакеты (например, ArTeMIS или собственные модули на Python) могут быть интегрированы. Так, измеренные сигналы акселерометров экспортируются в модуль OMA, который возвращает набор частот, форм (вектор из значений по датчикам) и демпфирований. Далее скрипт ArchiSense сравнивает формы через MAC и относительные изменения частот. Если MAC <0.8 с предыдущими – возможно, появилась новая мода или данные слишком зашумлены. Тогда сигнализируется неопределенность. Если MAC высок, и частота изменилась более чем на допустимы Δf, фиксируется Modal Anomaly Event. Преимущество метода мод чувствительность к распределенным изменениям: даже если ни один датчик по отдельности не показал яркой аномалии, все вместе, влияя на моды, могут выявить проблему. Например, равномерное снижение жесткости нескольких колонн на 5% трудно заметить по локальным датчикам, а первая форма прогиба уже просядет заметно. В литературе показано, что отслеживание модальных частот – мощный индикатор повреждений, но также зависит от окружающих условий (влажности, температуры). Поэтому ArchiSense дополнительно делает корреляционный анализ с факторами окружающей среды: т.е. пытается учесть, что, скажем, при +30° C бетон менее жесткий, и частота падает сама собой. Такие зависимости можно либо вычесть (модель регрессии), либо по крайней мере отделять как сезонные колебания. При построении тревожных критериев используют нормированные показатели: например, модальный коэффициент повреждения