IEC 60870-6

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

Ранее обмен данными между системами осуществлялся по индивидуальным или фирменным связям и протоколам. Разработка ICCP была начата как попытка создать международный стандарт оперативного обмена данными в электроэнергетике. В 1991 году рабочая группа взялась за разработку протокола, создание прототипа для проверки спецификаций, направление спецификации на утверждение МЭК и проведение тестов совместимости между решениями разных производителей. Вначале стимулом послужили требования Европейского общего рынка 1992 года. Первая версия протокола получила обозначение TASE.1 (англ. Telecontrol Application Service Element-1)^[4]. Вторая версия, TASE.2, использующая спецификацию производственных сообщений (англ. Manufacturing Message Specification, MMS), стала наиболее распространённой^[5].

В США сети ICCP широко используются для объединения групп энергокомпаний, обычно регионального системного оператора с электросетями передачи, распределения и генераторами. Региональные операторы также могут быть связаны между собой для координации экспорта и импорта электроэнергии между регионами по крупным межсистемным линиям.

Базовые возможности ICCP определяются как «блоки соответствия» (Conformance Blocks), перечисленные ниже. Объекты, используемые для передачи данных, определены в различных частях IEC 60870-6.

Описание блоков и примеры данных:

1. Периодические системные данные: состояния, аналоговые значения, флаги качества, метки времени, счётчики изменений, сигналы защиты. Ассоциированные объекты для управления ICCP-сессиями.
2. Мониторинг расширенных наборов данных: отчёт по исключениям для типов данных, поддерживаемых блоком 1.
3. Передача блочных данных: пересылка данных из блоков 1 и 2 блочно, а не по точкам, что позволяет в некоторых случаях снизить нагрузку на канал связи.
4. Информационные сообщения: простые текстовые и двоичные файлы.
5. Управление устройствами: управляющие команды (включение/отключение, пуск/стоп, повышение/понижение и др.), цифровые уставки. Включает механизмы блокировок и операции по принципу выбора-перед-исполнением.
6. Управление программами: дистанционное управление программами, выполняющимися на ICCP-сервере.
7. Информирование о событиях: расширенная передача клиенту сведений об ошибках и изменениях состояний устройств на сервере.
8. Дополнительные пользовательские объекты: информация о планировании, учёте, отключениях и ремонтах оборудования.
9. Массивы временных рядов: запрос клиентом серверу отчёта с историческими данными за указанный период.

ICCP реализован по принципу клиент/сервер. Пересылка данных осуществляется по запросу центра управления (клиента) к другому центру (серверу). Центры управления могут одновременно выступать и как клиенты, и как серверы. Протокол функционирует на прикладном уровне модели OSI. Возможны любые физические, транспортные и сетевые интерфейсы, удовлетворяющие этой модели. Наиболее распространено применение TCP/IP по Ethernet (802.3). ICCP может работать как по точке-точке между двумя центрами, так и в более общей конфигурации с многими центрами и маршрутизируемой глобальной сетью. Логические соединения («ассоциации») между центрами могут формироваться в любом количестве: клиент способен устанавливать связи с несколькими серверами или несколько ассоциаций с одним сервером (например, для передачи данных разного приоритета и качества обслуживания).

ICCP не реализует механизмов аутентификации и шифрования — эти функции обычно обеспечивает нижележащий протокол. Для разграничения доступа используется механизм «Двустронних таблиц» (англ. Bilateral Tables), где фиксируется соглашение между двумя центрами о составе доступных данных и правах на них. Для успешного взаимодействия должны быть согласованы содержимые двусторонних таблиц на обеих сторонах.

Широкое распространение ICCP привело к появлению на рынке нескольких решений от различных поставщиков. Хотя риск несовместимости невелик, стандарт допускает реализацию только необходимого набора блоков соответствия: для минимального исполнения требуется лишь блок 1. В каждом блоке не обязательно выражена поддержка всех объектов. Тестирование совместимости между ведущими продуктами было неотъемлемой частью развития протокола. Также доступно множество независимых и фирменных тестов. Покупатель ICCP должен чётко определить требуемую функциональность по блокам и объектам; профили прикладного взаимодействия клиента и сервера должны совпадать для успешного обмена.

ICCP — протокол для передачи, мониторинга и управления оперативными данными в реальном времени. Для полноценного функционирования необходимы средства администрирования, настройки и контроля производительности канала. Стандарт ICCP не регламентирует реализацию этих функций, а также схем резервирования и реакции SCADA на ICCP-запросы; такие «локальные вопросы реализации» отданы на усмотрение разработчиков. Это позволяет вендорам выделяться дополнительными возможностями. Удобство средств диагностики и эксплуатации часто окупается за счёт уменьшения затрат на обслуживание при масштабировании и развитии системы с ICCP-каналом.

Поставляемые ICCP-продукты, как правило, реализованы в одном из следующих вариантов:

1. Как встроенный протокол внутри SCADA-хоста.
2. В виде сетевого сервера.
3. В качестве шлюзового процессора.

Встроенное решение ICCP полностью интегрировано в программное обеспечение SCADA, обеспечивая максимальную производительность благодаря прямому доступу к базе данных без промежуточных слоёв. Однако добавить такой протокол к устаревшей системе может быть невозможно; в таком варианте ICCP ограничен исключительно средой SCADA, куда он встроен.

Сетевой сервер ICCP посредством стандартных коммуникаций связывается с SCADA-хостом и по быстродействию может приближаться к встроенной реализации, но открыт и к другим подсистемам (например, архивным данным или иным базам). Такое решение проще защитить — ICCP-сервер выделяется отдельно от оперативной среды реального времени. Шлюзовый процессор похож на сетевой сервер, но предназначен для устаревших систем со слабыми возможностями коммуникаций, обеспечивает самую низкую производительность; минимально возможно даже подключение через последовательный порт к RTU SCADA.