Валидация данных в системе яЭнергетик – это многоуровневый процесс, который охватывает все этапы работы с информацией. В рамках серии из трёх статей мы последовательно разберём каждый уровень защиты.

Первый и самый важный этап защиты от некачественных данных – это этап их непосредственного сбора с приборов учета. Данные поступают по различным каналам связи: GSM, GPRS, Ethernet, радиоканалы. Каждый из этих каналов подвержен помехам, обрывам и искажениям. Задача системы на уровне сбора – отсеять «мусор» еще до того, как он попадет в базу данных для дальнейших расчетов.

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

Рассмотрим ключевые механизмы валидации, работающие на этом этапе.

1. Проверка размера пакета

Каждый протокол обмена с прибором учета имеет строго определенную структуру. Система заранее знает ожидаемый размер или допустимый диапазон размеров ответа на каждый конкретный запрос.

• Как это работает: сервер сбора отправляет запрос к прибору и ожидает ответ определенной длины. Если приходит пакет, размер которого не соответствует ожидаемому, система немедленно фиксирует это.
• Что происходит при ошибке: пакет считается битым и отбрасывается. В журнал событий записывается ошибка с указанием ожидаемого и фактического размера.

Рисунок 1 – Схема проверки размерности

Примечание: Мы не всегда знаем точный размер ответа. Но для ряда протоколов мы знаем диапазон допустимых размеров (т.е. минимальную и максимальную допустимую длину для корректного пакета).

2. Проверка терминаторы (маркеров начала и конца пакета)

В большинстве протоколов связи каждый пакет имеет четкие маркеры, обозначающие его начало и конец. Это могут быть специальные байты-заголовки (например, флаг 0x7E в HDLC-кадрировании, используемом в протоколе DLMS, который лежит в основе СПОДЭС) или стартовые/завершающие символы в текстовых протоколах.

·         Как это работает: сервер сбора сканирует входящий поток байтов в поисках маркера начала пакета. Обнаружив его, система начинает сбор данных до тех пор, пока не встретит маркер конца пакета.

·         Что происходит при ошибке: если маркер начала или конца отсутствует, система понимает, что пакет битый. Такой пакет не обрабатывается.

3. Проверка контрольной суммы (CRC)

Это классический и один из самых надежных способов проверки целостности данных. Контрольная сумма – это число, вычисляемое по специальному алгоритму (CRC-16, CRC-32 и т.д.) на основе всех байтов пакета. Прибор учета вычисляет CRC и добавляет его в отведенное для него поле пакета перед отправкой.

• Как это работает: сервер сбора, получив пакет, вычисляет контрольную сумму по тому же алгоритму и сравнивает ее со значением, присланным прибором.
• Что происходит при ошибке: если суммы не совпадают, это однозначно указывает на искажение данных в процессе передачи (помехи, плохой сигнал, сбой оборудования). Пакет отбраковывается.

4. Проверка константных значений в пакете

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

• Как это работает: сервер сбора знает, какой адрес закреплен за каждым прибором в системе. При получении пакета система извлекает адрес отправителя и сверяет его с эталонным значением.
• Что происходит при ошибке: если адрес в пакете не соответствует ожидаемому, данные не принимаются. Это защищает от ситуации, когда показания одного счетчика по ошибке записываются в базу другого.

5. Проверка размерности конкретных полей в пакете

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

• Как это работает: сервер сбора знает, сколько байт должно занимать каждое поле (показания, время, статусные флаги) и проверяет это соответствие.
• Что происходит при ошибке: если поле имеет неверную длину или значение выходит за допустимые пределы (например, отрицательное показание), пакет считается некорректным и отбрасывается.

6. Логирование всех поступающих данных

Все, что приходит на сервер, сохраняется в «сыром» виде в специальном лог-файле. Это означает, что система хранит полный архив всех принятых пакетов.

• Как это работает: Каждый байт, поступивший от прибора учета, записывается на диск в неизменном виде.
• Зачем это нужно:
• Расследование инцидентов: если возникла спорная ситуация, инженер всегда может открыть лог и посмотреть, что именно пришло от прибора в тот или иной момент.
• Отладка: при настройке новых типов приборов или протоколов логи помогают разработчикам и инженерам видеть, что реально приходит «на проводе».
• Аудит: это обеспечивает полную прозрачность и возможность проверить работу системы задним числом.

7. Мониторинг инфраструктуры через Zabbix

Валидация данных – это не только проверка самих пакетов, но и контроль состояния всей инфраструктуры сбора.

• Как это работает: система мониторинга Zabbix отслеживает:
• Трафик на каналах связи (объем переданных/принятых данных).
• Состояние оборудования (модемы, УСПД, серверы сбора) – онлайн/офлайн.
• Загрузку процессора и память на серверах сервер сбора.
• Количество ошибок опроса в единицу времени.
• Зачем это нужно: проблемы с качеством данных часто связаны не с самими приборами, а с состоянием инфраструктуры. Zabbix позволяет оперативно обнаружить, что, например, упал канал связи или «завис» модем, и принять меры до того, как это приведет к массовым потерям данных.

В следующих частях: валидация на уровне бэкенд, алгоритмы восстановления пропусков, контроль аномалий и итоговая сверка.