МЭК 61850 может получить новый механизм клиент-серверной коммуникации — IEC 61850-8-3. Проект нового стандарта предлагает дополнительный маппинг сервисов МЭК 61850 на Direct Message Specification (DMS) с использованием JSON Encoding Rules и WebSockets.

Важно: речь идёт не об отказе от существующего стандарта МЭК 61850-8-1. Сегодня основной клиент-серверный обмен в МЭК 61850 реализуется через МЭК 61850-8-1, то есть через маппинг сервисов на протокол MMS — Manufacturing Message Specification. Этот механизм применяется с первых лет внедрения МЭК 61850, работает в большом количестве устройств и систем, но при этом остаётся сложным для понимания, реализации, отладки и интеграции с современными IT-технологиями.

Новый стандарт МЭК 61850-8-3 предлагается как дополнительный SCSM — Specific Communication Service Mapping. Его задача — сделать клиент-серверный обмен IEC 61850 более простым, понятным и удобным для разработки.

Архитектура клиент-серверного обмена в МЭК 61850: текущая (8-1) и предлагаемая (8-3)
Рис. 1. Архитектура клиент-серверного обмена в IEC 61850: текущая (8-1 через MMS) и предлагаемая (8-3 через DMS, JSON и WebSockets).

Почему возникла потребность в МЭК 61850-8-3

Проблема не в самой информационной модели МЭК 61850. Модель остаётся сильной стороной стандарта: IED, Logical Device, Logical Node, Data Object, Data Attribute, DataSet, Report Control Block — всё это хорошо описывает структуру цифровых устройств и их данные.

Сложность возникает на уровне маппинга абстрактных сервисов МЭК 61850-7-2 ACSI на протокол MMS. MMS был разработан ещё в 1980-е годы, использует ASN.1 и BER-кодирование, имеет собственную объектную модель и большой набор сервисов. Для IEC 61850 используется только часть возможностей MMS, но сам маппинг получается непрямым и требует множества специальных правил.

Например, логическое устройство МЭК 61850 отображается в MMS как domain object, многие другие объекты — как named variables, а различение логических узлов, данных, атрибутов и управляющих блоков обеспечивается специальными соглашениями об именовании. В результате инженер, который уже понимает модель МЭК 61850, всё равно должен отдельно понимать, как эта модель «упакована» в MMS.

Именно эта сложность часто становится барьером для применения МЭК 61850 за пределами классического домена цифровых подстанций. На фоне более простых для восприятия протоколов, таких как МЭК 60870-5-104 или DNP3, связка МЭК 61850 + MMS может восприниматься как более тяжёлая, дорогая и трудная для внедрения.

Что предлагает DMS

МЭК 61850-8-3 предлагает другой подход: для каждого сервиса ACSI определить соответствующее конкретное сообщение DMS.

То есть вместо сложного отображения МЭК 61850-7-2 на объектную и сервисную модель MMS предлагается прямое соответствие:

ACSI service → DMS service

Например:

GetServerDirectory в ACSI становится GetServerDirectory в DMS. Read остаётся Read. Write остаётся Write.

Идея в том, что инженер изучает один набор моделей и сервисов МЭК 61850, а не две разные системы понятий — ACSI и MMS. В представленной транскрипции подчёркивается, что DMS следует структуре ACSI: те же имена моделей, те же сервисы, те же параметры. Отличие в том, что ACSI остаётся абстрактным интерфейсом, а DMS задаёт конкретную форму сообщений.

flowchart LR
    A["<b>ACSI</b><br/>IEC 61850-7-2<br/>абстрактные сервисы"]

    A --> S1["GetServerDirectory"]
    A --> S2["Read"]
    A --> S3["Write"]
    A --> S4["Report"]
    A --> S5["GetFile"]
    A --> S6["..."]

    S1 --> M1["МЭК 61850-8-1<br/>MMS-объекты, namedVariables,<br/>специальные правила именования<br/>→ ASN.1 BER → TCP"]
    S2 --> M1
    S3 --> M1
    S4 --> M1
    S5 --> M1
    S6 --> M1

    S1 --> D1["<b>МЭК 61850-8-3</b><br/>DMS message GetServerDirectory<br/>→ JSON (JER) или PER → WebSockets"]
    S2 --> D2["<b>МЭК 61850-8-3</b><br/>DMS message Read<br/>→ JSON (JER) или PER → WebSockets"]
    S3 --> D3["<b>МЭК 61850-8-3</b><br/>DMS message Write<br/>→ JSON (JER) или PER → WebSockets"]
    S4 --> D4["<b>МЭК 61850-8-3</b><br/>DMS message Report<br/>→ JSON (JER) или PER → WebSockets"]
    S5 --> D5["<b>МЭК 61850-8-3</b><br/>DMS message GetFile<br/>→ JSON (JER) или PER → WebSockets"]
    S6 --> D6["<b>МЭК 61850-8-3</b><br/>DMS message ...<br/>→ JSON (JER) или PER → WebSockets"]

    style A fill:#E8F4FD,stroke:#4A86D7,color:#0D3F7A
    style S1 fill:#FFF8E1,stroke:#E6A23C,color:#7A5418
    style S2 fill:#FFF8E1,stroke:#E6A23C,color:#7A5418
    style S3 fill:#FFF8E1,stroke:#E6A23C,color:#7A5418
    style S4 fill:#FFF8E1,stroke:#E6A23C,color:#7A5418
    style S5 fill:#FFF8E1,stroke:#E6A23C,color:#7A5418
    style S6 fill:#FFF8E1,stroke:#E6A23C,color:#7A5418
    style M1 fill:#FBE9D6,stroke:#E6A677,color:#7A4118
    style D1 fill:#E8F5E9,stroke:#7EC3A0,color:#1B5E3F
    style D2 fill:#E8F5E9,stroke:#7EC3A0,color:#1B5E3F
    style D3 fill:#E8F5E9,stroke:#7EC3A0,color:#1B5E3F
    style D4 fill:#E8F5E9,stroke:#7EC3A0,color:#1B5E3F
    style D5 fill:#E8F5E9,stroke:#7EC3A0,color:#1B5E3F
    style D6 fill:#E8F5E9,stroke:#7EC3A0,color:#1B5E3F
Рис. 2. Сопоставление сервисов ACSI и сообщений DMS: одному сервису ACSI соответствует одно сообщение DMS, тогда как в IEC 61850-8-1 каждый сервис «перекладывается» на объектную модель MMS.

JSON для разработки, бинарное кодирование для промышленного применения

Важная особенность предлагаемого подхода — использование ASN.1 JER, то есть JSON Encoding Rules.

Это позволяет описывать сообщения строго, через ASN.1-схему, но при этом получать человекочитаемое JSON-представление для разработки, тестирования, отладки и анализа.

Практическая идея выглядит так:

  • на этапе разработки и испытаний можно использовать JSON-представление, которое легко читать, логировать и анализировать стандартными инструментами;
  • после проверки реализации можно применять компактное бинарное кодирование при сохранении той же схемы сообщений.

Оба варианта кодирования могут использовать одну и ту же ASN.1-схему, а выбор кодирования может согласовываться при установлении WebSocket-соединения.

Почему это важно для диагностики и испытаний

Для специалистов по цифровым подстанциям особенно интересен аспект диагностики.

Сегодня Wireshark хорошо показывает MMS-сообщения, но для полного понимания смысла обмена по МЭК 61850 инженеру всё равно нужно восстановить соответствие между MMS-структурой и объектами МЭК 61850. При DMS сообщение должно быть ближе к исходной семантике МЭК 61850: если вызывается сервис ACSI, то и в сообщении виден именно этот сервис.

Это может упростить:

  • разработку клиентских и серверных стеков МЭК 61850;
  • создание API для прикладного ПО;
  • интеграцию МЭК 61850 с web-технологиями;
  • отладку обмена между клиентами и серверами;
  • обучение инженеров;
  • тестирование совместимости;
  • анализ сообщений стандартными инструментами;
  • применение МЭК 61850 вне подстанционного домена.

При этом GOOSE и Sampled Values остаются отдельными механизмами передачи данных. IEC 61850-8-3 касается именно клиент-серверного обмена, который сегодня в большинстве реализаций выполняется через MMS.

Что означает текущий статус проекта

У проекта IEC 61850-8-3 указан статус 20.99 WD approved for registration as CD.

Кратко это означает, что документ прошёл стадию Working Draft (WD) и одобрен для регистрации как Committee Draft (CD).

То есть это ещё не опубликованный стандарт, а рабочий проект, который признан достаточно зрелым для перехода к следующему этапу обсуждения в техническом комитете IEC. На стадии CD национальные комитеты и эксперты рассматривают текст более формально, направляют замечания и голосуют по дальнейшему продвижению документа.

flowchart LR
    NP["<b>NP</b><br/>New Work Item<br/>Proposal"]
    WD["<b>WD</b><br/>Working Draft"]
    CD["<b>CD</b><br/>Committee Draft<br/>национальные комитеты"]
    CDV["<b>CDV</b><br/>Committee Draft<br/>for Vote"]
    FDIS["<b>FDIS</b><br/>Final Draft<br/>International Standard"]
    IS["<b>IS</b><br/>International<br/>Standard"]

    NP --> WD --> CD --> CDV --> FDIS --> IS

    CURRENT["📍 IEC 61850-8-3<br/>20.99 WD approved for<br/>registration as CD"]
    CURRENT -.-> CD

    style NP fill:#F4F6FB,stroke:#9aa6c8,color:#5a6584
    style WD fill:#F4F6FB,stroke:#9aa6c8,color:#5a6584
    style CD fill:#FBE9D6,stroke:#E6A677,color:#7A4118
    style CDV fill:#F4F6FB,stroke:#9aa6c8,color:#5a6584
    style FDIS fill:#F4F6FB,stroke:#9aa6c8,color:#5a6584
    style IS fill:#E8F5E9,stroke:#7EC3A0,color:#1B5E3F
    style CURRENT fill:#FFF8E1,stroke:#E6A23C,color:#7A5418
Рис. 3. Этапы созревания документа в МЭК: на сегодня МЭК 61850-8-3 имеет статус «WD одобрен для регистрации как CD», то есть переходит к стадии обсуждения национальными комитетами.

Возможный сдвиг в развитии МЭК 61850

Если работа над МЭК 61850-8-3 будет успешно продолжена, этот документ может стать одним из наиболее заметных изменений в практическом применении МЭК 61850 за последние годы.

Сама информационная модель МЭК 61850 при этом не меняется. Меняется способ передачи клиент-серверных сообщений: вместо сложного маппинга ACSI на MMS появляется прямой маппинг ACSI на DMS.

Для цифровых подстанций это не означает немедленную замену МЭК 61850-8-1. Скорее, речь идёт о появлении дополнительного варианта коммуникации, который может быть особенно полезен для новых классов приложений: web-интерфейсов, цифровых двойников, учебных стендов, испытательных платформ, аналитических систем и инструментов разработки.

Именно поэтому МЭК 61850-8-3 стоит рассматривать не как «ещё один протокол», а как попытку сделать клиент-серверную часть МЭК 61850 ближе к современной инженерной и программной практике.