Информационная модель прибора учёта в СПОДЭС
Клиент не «читает регистры по адресам», как в Modbus. Он работает с объектной моделью: прибор описывает сам себя, а программа опрашивает объекты этой модели. Понимание модели — самая большая часть работы при интеграции.
Объект, класс, атрибут, метод
Каждый объект в приборе — экземпляр интерфейсного класса. Класс задаёт, какие атрибуты и методы у объекта есть. Атрибут 1 у любого объекта — его логическое имя, тот самый OBIS-код, по которому объект и адресуется. Остальные атрибуты хранят данные: значение, единицы и масштаб, состав записи, время и так далее. Методы выполняют действия — сброс, активацию расписания, отключение нагрузки.
Отсюда следует важное для разработчика: чтобы прочитать величину, нужно знать три вещи — интерфейсный класс, логическое имя объекта и номер атрибута. Все три перечислены в требованиях к модели (ГОСТ Р 58940-2020, раздел 7).
Логическое устройство и логическое имя
Внутри прибора данные сгруппированы в логические устройства. Устройство управления есть всегда и служит точкой входа: через него доступен список объектов и сведения о самом приборе. Логическое имя устройства и правила адресации объектов COSEM описаны в разделе 6 ГОСТ.
Модель читается один раз
Особенность СПОДЭС — трёхстадийный обмен, первая стадия которого посвящена именно модели: она считывается с прибора данного типа и затем используется для всех однотипных приборов. Смысл в экономии: зная модель, клиент не пересылает описания форматов при каждом опросе.
Практический вывод: в клиентском ПО стоит хранить кэш моделей по типу прибора и обновлять его, когда меняется прошивка. Наш Конфигуратор СПОДЭС показывает полную модель прибора деревом — это удобный способ увидеть, что в приборе есть на самом деле, а не по документации.
Категории приборов учёта
Требования к составу параметров зависят от того, где прибор применяется. СТО делит приборы на четыре категории (приложение А):
| Категория | Где применяется | Особенности учёта |
|---|---|---|
| A | Электростанции и распределительные трансформаторные центры; объекты свыше 670 кВт и напряжением выше 1 кВ | Энергетический учёт и аудит, экспорт и импорт энергии; включение через трансформаторы напряжения и тока |
| B | Отходящие фидеры 0,4 кВ и вводные устройства мощных потребителей; присоединённая мощность 150–670 кВт | Активная, реактивная и полная энергия в одном направлении, многотарифный учёт, технические потери, фиксация максимальной мощности; включение через трансформаторы тока |
| C | Трёхфазные приборы прямого включения, абонентский расчётный учёт; мощность до 150 кВт | Многотарифный учёт активной энергии, контроль максимальной мощности, реактивная энергия |
| D | Однофазные многотарифные абонентские приборы | То же, что категория C, но для одной фазы, с учётом в прямом и обратном направлении |
Списки параметров для категорий приведены в приложениях СТО отдельно для A, B, C и отдельно для D, плюс общие параметры для всех категорий. Именно эти приложения отвечают на вопрос «что прибор обязан уметь отдавать».
Как классифицируются данные
Стандарт делит передаваемые данные на группы, и это удобная рамка для проектирования клиента:
- мгновенные (текущие) параметры — напряжения, токи, мощности;
- профили нагрузки — срезы с заданным периодом;
- суточные профили;
- ежемесячные профили для коммерческого учёта и балансов;
- абстрактные параметры, не связанные с энергией: паспортные данные, настраиваемые параметры и функции;
- журналы событий;
- счётчики внешних воздействий.
Опрос почти всегда строится по этим группам: паспорт и часы — редко, мгновенные значения — по запросу, профили и журналы — с догрузкой по времени последней записи.
Обязательный минимум объектов
В четвёртой версии стандарта появилось отдельное приложение с перечнем обязательных объектов COSEM-модели прибора. Для разработчика это опорная точка: если объект есть в этом перечне, его можно ожидать в любом сертифицированном по версии 4 приборе; всё остальное проверяется по факту — чтением модели.
