Научная электронная библиотека
Монографии, изданные в издательстве Российской Академии Естествознания
Приложение к разделу 6. Унификации интерфейсов и протоколов в АСКУЭ
Гуртовцев А.Л., к.т.н., ведущий научный сотрудник РУП “БелТЭИ”
В АСКУЭ промышленности и быта от разных изготовителей используются, как правило, собственные счетчики, УСПД, протоколы и фирменное программное обеспечение этих изготовителей. В результате количество различных АСКУЭ превышает количество изготовителей и фирм системных интеграторов, которые комбинируют в конкретных АСКУЭ средства учета от разных изготовителей.
Сложившаяся реальность создает для энергоснабжающих организаций проблемы интеграции АСКУЭ отдельных потребителей, выполненных на разнородных средствах, в единую систему учета электроэнергии энергосистемы. Проблема усложняется и тем, что в процессе совершенствования средств учета даже одного и того же изготовителя меняются их характеристики, функции и протоколы, и, как следствие, теряется преемственность и информационная совместимость между различными моделями одного и того же средства учета.
Ниже рассматриваются общие подходы по обеспечению совместимости средств учета от различных изготовителей в рамках единой АСКУЭ энергосистемы. Поскольку АСКУЭ являются разновидностью измерительно-информационных систем, полезно проследить те исторически сложившиеся подходы к обеспечению совместимости разнородных средств, которые имеют место в области вычислительной техники, передачи цифровых данных и промышленной автоматизации (АСУ ТП, или SCADA-системах).
Из истории интерфейсов* и протоколов**
Унификация компонентов, интерфейсов и протоколов вычислительных, измерительных и информационных систем является краеугольным камнем технического прогресса. В доцифровую эру унифицированное взаимодействие компонентов таких систем базировалась на использовании аналоговых сигналов 4-20 мА и нестандартных протоколов передачи данных. До сих пор многие датчики, например, температуры, давления, расхода имеют именно такой выходной сигнал. С созданием в начале 50-х годов первых серийных вычислительных машин и цифровых измерительно-информационных систем возник вопрос по стандартизации передачи цифровых данных как внутри таких систем, так и между ними. В переходной период от аналоговых сигналов к цифровым создавались различные гибридные коммуникационные технологии, представителем которых, в частности, является протокол HART известной американской фирмы Fisher-Rosemount, созданный в середине 80-хх годов (гибридный протокол обмена данными с использованием цифрового сигнала для передачи информации, накладываемого поверх аналогового управляющего сигнала 4-20 мА).
В начале 60-х годов в рамках Международной организации по стандартизации (МОС/ISO), Международного консультативного комитета по телефонии и телеграфии (МККТТ/CCITT), Международной электротехнической комиссии (МЭК/IEC), Ассоциации электронной промышленности США (АЭП/EIА), Института инженеров по электротехнике и радиоэлектронике США (ИИЭР/IEEE), национальных организаций и институтов по стандартизации ANSI (США), DIN (Германия), ANFOR (Франция) и других начались процессы международной стандартизации в области вычислительной техники и передачи цифровых данных. Именно в те годы был создан известный стандарт интерфейса физической последовательной связи между оконечным оборудованием данных и аппаратурой передачи данных EIA RS-232/V.24 (1962г.), усовершенствованный в 1969г. в стандарте EIA RS-232С/V.28. Позднее были разработаны новые стандарты интерфейсов физического уровня RS-423/V.10 и RS-422А/V.11 (1978г.), а также их усовершенствованный, ныне широко применяемый стандарт RS-485А (1983г.).
В 70-е годы МОС продолжила разработку протоколов более высокого, чем физический, канального уровня - бит-ориентированных протоколов управления каналами передачи данных. Эти работы велись в тесном контакте с МККТТ по сетям передачи данных общего пользования. Недостатком всей этой деятельности по разработке протокольных спецификаций, в которой участвовало много организаций из различных стран, было отсутствие единого плана, учитывающего все системные требования, в частности, разнородность и рассредоточенность систем пользователей, содержащих различные конфигурации, структуры и, характеристики технических средств. Как обеспечить взаимодействие столь разнородных систем? Какие стандарты необходимы для создания среды открытых систем»?
Для решения этих вопросов технический комитет ТС97 МОС Системы обработки информации» учредил новый подкомитет CS16 Взаимосвязь открытых систем» (ВОС/OSI – Open Systems Interconnection), в задачу которого входила разработка эталонной модели, архитектуру которой можно было бы взять за основу при создании всех новых международных стандартов для систем распределенной обработки данных. Работы, начавшиеся в подкомитете в 1978г., завершились к 1983г. принятием международного стандарта ISO7498, которым была определена 7-уровневая архитектура ISO/OSI.
Эта модель получила одобрение в меж дународном масштабе и стала основой для разработки дальнейших стандартов в области обработки и передачи цифровых данных. В модели ISO/OSI используется способ разделения сложных задач на ряд более простых подзадач, которые можно решать независимо друг от друга, с распределением их, включая функции передачи данных, между рядом уровней, т.е. производится структурирование модели по уровням. Назначение модели - описание набора уровней и определения функций каждого из них, а цель - разработка протоколов для реализации функций каждого уровня. Архитектура протоколов, созданных на основе модели, состоит соответственно из протоколов нескольких уровней с одним или несколькими протоколами на каждом из них. Причина появления архитектур протоколов - простота разработки и внедрения их программной реализации, при которой функция большого пакета программного обеспечения распределяется по модулям (уровням), каждый из которых проектируется, кодируется и тестируется в отдельности.
В модели ISO/OSI самый нижний, первый, физический уровень (к нему относятся вышеупомянутые стандарты типа EIA RS-232С/V.28 и другие) устанавливает правила прохождения битов от одного устройства к другому, обеспечивает передачу неструктурированного потока битов по физической среде, а также определяет механические, электрические, функциональные и процедурные характеристики доступа к среде. Самый верхний, седьмой, прикладной уровень обеспечивает доступ пользователей к среде ISO/OSI, предоставляя им ресурсы распределенных информационных систем, а также реализует общие механизмы поддержки распределенных приложений. Между этими двумя уровнями находятся промежуточные - канальный, сетевой, транспортный, сеансовый и представительный. Каждый уровень обслуживает вышележащий, пользуясь услугами нижележащего уровня. Модель построена таким образом, что отдельные уровни, если исполняемая ими функция не нужна, могут отсутствовать. Тем самым 7-уровневая модель может быть редуцирована в модель с меньшим количеством уровней.
При разработке модели ее авторы полагали, что ISO/OSI вместе со своими протоколами вытеснит существовавшие прежде фирменные одноуровневые протоколы, но этого не произошло. В рамках модели было разработано множество полезных протоколов, но в целом 7-уровневая модель осталась незавершенной из-за своей сложности, больших затрат времени и накладных расходов на передачу данных между всеми уровнями (в модели ISO/OSI отсутствует непосредственная связь между одноранговыми уровнями). Вместе с тем, упрощенная, как правило, 3-уровневая модель ISO/OSI (физический, канальный и прикладной уровни) стала основой многих фирменных многоуровневых архитектур протоколов. В этих архитектурах второй, канальный уровень обеспечивает установление, сохранение и разрыв соединения, а также надежную передачу информации по физическим каналам, включая отправку блоков (кадров, пакетов, фреймов), их синхронизацию, отслеживание ошибок и управление потоком данных. Редуцированная модель ISO/OSI стала признанной базой в области средств коммуникации промышленного применения, включая телемеханику. В телемеханике отсутствуют многие задачи неиспользуемых уровней, что позволяет при ограниченной скорости передачи данных уменьшить за счет сокращения числа вложенных заголовков длину кадра, исключить потери времени на передачу информационных блоков между уровнями на передающей и приемной стороне системы, обеспечив тем самым повышение ее производительности и уменьшение времени реакции.
Начиная с середины 80-х годов, основные поставщики и пользователи систем промышленной автоматизации разрабатывали стандарты полевой шины Fieldbus - открытого цифрового протокола, который позволил бы работать с полевым оборудованием различных изготовителей (датчиками, исполнительными механизмами, программируемыми контроллерами, промышленными компьютерами). Более 30 лет компании в области промышленной автоматизации создавали собственные "нишевые" полевые шины для связи оборудования контроля и управления производственными процессами. Появилось более полусотни коммуникационных технологий для создания промышленных сетей и полевых шин, основанных на собственных протоколах и аппаратных средствах фирм-производителей, среди которых, в частности, стали широко популярны Bitbus (IEEE 1118), CAN (ISO/DIS 11898), Interbus-S (DIN 9258), Modbus, DeviceNet, LonWorks, P-net и другие. В начале 90-х годов статус национального стандарта в Германии приобрела спецификация Profibus (DIN 19245), а в середине 90-х годов в США завершилась разработка стандарта Foundation Fieldbus (IEC 61158). Эти стандарты стали двумя мировыми лидерами и конкурентами в области промышленной автоматизации.
Выше отмечалось, что для шин промышленного применения не нужны все уровни. Так, например, в стандарте Profibus (спецификации FMS по протоколу высокого уровня, DP по обмену данными между контроллером и устройствами ввода-вывода и PA по обмену данными между системой управления и полевым оборудованием), реализованы те же 3 уровня: физический (базируется на стандарте RS-485, позволяет подключать к шине до 127 устройств), канальный (обеспечивает длину пакета до 255 байт) и прикладной (допускает в исключительных случаях передачу пакетов данных размером в несколько кбайт). Для работоспособности этой модели протоколов некоторые функции из неиспользуемых уровней 3-6 интегрированы в 7-ой уровень. Функции, определяемые на нижних уровнях модели, всегда реализуются на базе аппаратных средств, а средние и верхние уровни - в виде программного обеспечения. Для подключения к шине разнородного оборудования различных изготовителей используется его уникальное описание на стандартизированном языке устройств DDL (Device Description Language), которое служит в дальнейшем для разработки соответствующих программных DDL-драйверов (для некоторых типов распространенных полевых шин они поставляются вместе с оборудованием изготовителя).
Полевая архитектура с полевыми шинами и интеллектуальными полевыми приборами, позволяющая получать, передавать, использовать, распределять информацию и осуществлять управление в каждой точке измерения, основана на открытых международных стандартах связи, которые обеспечивают полную эксплуатационную совместимость оборудования от разных изготовителей. Вместе с тем, отсутствие для множества различных приборов тех или иных изготовителей единого программного интерфейса приводило к необходимости разработки за счет пользователей и посредством фирм системных интеграторов специальных программ: DDE -драйверов (драйверов Dynamic Data Exchange - стандартного динамического обмена данными). Возникла проблема унификации и стандартизации программных интерфейсов: ведь чтобы использовать прибор, необходимо знать его интерфейс, который должен быть опубликован в виде документа или стандарта. В 1994г. под эгидой Microsoft была создана международная организация OPC Foundation с целью разработки и поддержки на базе объектно-ориентированного программирования открытых промышленных стандартов, регламентирующих методы обмена данными в реальном времени.
Взамен DDE-технологии фирмой Microsoft было предложено более эффективное и надежное средство передачи данных между информационными процессами - OLE (Object Linking and Embedding – Связывание и Встраивание Объектов). На базе этого средства был создан стандарт совместимого интерфейса OPC (OLE for Process Control – OLE для Управления Процессами). ОРС - это стандарт на интерфейс обмена данными с оборудованием в интегрированных разнородных системах. Он предоставляет правила для реализации СОМ-объектов (под термином OLE спрятано понятие COM - Component Object Model – Модель Составных Объектов и ее сетевое расширение DCOM - Distributed COM – Распределенная СОМ-технология): использовать СОМ-объекты должны СОМ-клиенты. Комитеты OPC Foundation разрабатывают спецификации СОМ-интерфейсов и СОМ-объектов, оформляют их в виде стандартов и опубликовывают, генерируют или создают вспомогательные файлы для пользовательского интерфейса, библиотеки типов для интерфейса промышленной автоматизации, разрабатывают вспомогательные компоненты. В соответствии с новой технологией изготовители контроллеров и средств промышленной автоматизации должны поставлять со своей продукцией унифицированные программные драйверы, соответствующие спецификациям ОРС, - ОРС-сервера, которые являются источником данных для ОРС-клиентов (других подсистем, например, архивирования данных).
В ОРС-технологии доступ к каждому процессу возможен только через интерфейс, который объединяет группу взаимосвязанных функций объекта. Главная особенность СОМ-интерфейса – его публичность, т.е. после опубликования интерфейса его нельзя изменять, а новая версия интерфейса должна сохранять в себе старую. Этим обеспечивается совместимость при обновлении и модернизации объектов, что является важным шагом интеграции процессов. Передача данных, или вызовы одного процесса другим, организуются с помощью библиотек типа DLL (Dynamic Link Library – Динамически Подсоединяемая Библиотека), которые предоставляют функции для работы с объектами: создание объектов, их упаковка, передача параметров и т.д. Поддерживающие компоненты (заместитель, заглушка, вызов удаленных процедур и другие) делают прозрачной работу с СОМ-объектами для СОМ-клиентов. Реализацию же сетевых решений обеспечивает системный сервис DCOM, делающий СОМ прозрачным в локальных сетях.
ОРС-технология программного объединения разнородного оборудования широко используется в SCADA-системах (Supervisory Control And Dada Asquisition - Супервизорный контроль и Сбор Данных) – прикладном программном обеспечении (ППО) для конечных систем управления. SCADA-системы поддерживают уровень автоматизации, связанный с получением и визуализацией информации от программируемых контроллеров и распределенных систем управления. Основу большинства SCADA-пакетов составляют несколько программных компонентов: базы данных реального времени, ввод-вывод, предыстория (архив), аварийные ситуации и администраторы. Широко распространены SCADA-пакеты FIX (GE Fanuc Automation, ранее Intellution - российский филиал General Electric, США), Genesis32 (Iconics, США, 1986г.), Factory Link (United States Data Co., США), Trace Mode (AdAstra, Москва), Genie (Advantech, США), InTouch (Wonderwar, США), WinCC (Siemens) и другие. Все SCADA-системы используют синтаксис языка ANSI SQL, который не зависит от типа базы данных (БД), что позволяет менять БД без изменения прикладных задач. Для подсоединения драйверов ввода-вывода (системы содержат сотни различных драйверов для подключения разнообразного оборудования от различных изготовителей) используются механизмы стандартного динамического обмена данными, обмена по внутреннему, известному лишь фирме-разработчику протоколу и ОРС-сервера. Все открытые SCADA являются ОРС-клиентами, а некоторые из них и ОРС-серверами.
В последние годы с распространением Internet и Intranet для унификации связи между системами стали использоваться встроенные в них web-серверы. Фирма Schneider Electric еще в 1997г. выпустила первые встроенные web-серверы для серии своих контроллеров. Web-сервер, встроенный в промышленный программируемый контроллер, может обеспечить данными реального времени любого клиента в пределах сети Intranet. В этом случае частично или полностью отпадает необходимость в SCADA-системах и непосредственные данные могут быть получены на различных уровнях АСУ субъекта хозяйствования без дополнительных издержек через тот же браузер. Web-технология предлагает действительную универсальность и прозрачность.
По определению система является открытой, если для нее определены и описаны используемые форматы данных и процедурный интерфейс, что позволяет подключить к ней внешние, независимо разработанные компоненты. Открытость системы для разработчика пакета, разработчика ППО на его основе и конечного пользователя может быть различна. Фактически открытость системы означает доступность спецификаций системных вызовов, реализующих тот или иной системный сервис. Минусы открытых технологий – техническая и программная избыточность, удлинение срока и трудоемкости разработки. Кроме того, любой самый замечательный стандарт означает необходимость строгого его соблюдения, а стандарты стареют. Плюсы – уменьшение затрат пользователей в интеграцию оборудования разных изготовителей, уменьшение затрат на обучение. Крупные фирмы периодически создают свои новые, внутрифирменные стандарты, которые позволяют преодолеть недостатки старых открытых стандартов, а затем решают: объявить о достоинствах своей новой технологии и быть ее единственным обладателем и продавцом или пробить новый внутрифирменный стандарт в международных комитетах в качестве международного стандарта.
Варианты решения проблемы совместимости средств учета в АСКУЭ
Исторически сложилось так, что электронные электросчетчики от разных изготовителей имеют свои собственные цифровые протоколы, по которым они взаимодействуют со своими фирменными УСПД и программным обеспечением (ПО) верхнего уровня АСКУЭ. Совместимость использования в рамках единой системы учета счетчиков от различных изготовителей можно обеспечить двумя путями: 1) унификацией протоколов счетчиков, 2) разработкой под каждый уникальный протокол счетчика конкретного изготовителя своего драйвера, который бы конвертировал бы данные индивидуального протокола в некую единую базу данных, находящуюся в УСПД и/или на компьютере верхнего уровня АСКУЭ.
В рамках СНГ предпринимались попытки по унификации протоколов счетчиков (создавались соответствующие ассоциации изготовителей), но они закончились неудачей. Причина - коммерческие интересы изготовителей и их стремление монополизировать те или иные ниши рынка средств приборного учета электроэнергии. В Европе также первоначально складывалось аналогичное положение, но с созданием в 1998г. стандарта протокола DLMS (Device Language Message Specification) начался процесс унификации протоколов счетчиков отдельных изготовителей на базе этого международного протокола.*** В настоящее время практически все европейские (и не только европейские) изготовители электронных счетчиков (включая литовских), закладывают в свои счетчики этот протокол (как опцию) наряду со своими узко фирменными протоколами. Следует отметить, что еще раньше в счетчики для локального (не дистанционного доступа, о котором идет речь!) доступа к данным (через оптопорт) был встроен международный протокол IEC 1107 (1985г.).
В СНГ пошли по другому пути, т.е., как обычно, своим путем. Для интеграции в рамках единой АСКУЭ счетчиков различных изготовителей фирмы-разработчики стали модернизировать свои фирменные УСПД, ориентированные вначале на один фирменный тип счетчика, под счетчики и других изготовителей. В настоящее время существуют десятки типов УСПД различных изготовителей, которые работают со счетчиками различных изготовителей и по разным протоколам. В частности, среди таких УСПД - белорусский СЭМ-2, владимирский СИКОН, московский RTU-325/327 и другие. Поэтому можно считать, что для стран СНГ и для Беларуси вопрос унификации протоколов счетчиков не стоит. Хотя, если белорусские изготовители планируют в будущем выйти на рынки Европы и других стран со своей продукцией, то им придется закладывать в свои счетчики протоколы, соответствующие если не мировым, то европейским стандартам, в частности, DLMS .
Однако, решение унификации сбора данных на нижнем уровне АСКУЭ посредством универсального по протоколам нижнего уровня УСПД, не решило проблемы для АСКУЭ в целом, поскольку сохранилось разнообразие самих УСПД и ПО верхнего уровня АСКУЭ от различных изготовителей. Для решения задач унификации сбора данных на верхний уровень АСКУЭ можно выбрать по аналогии с решением проблемы унификации для счетчиков те же два пути, о которых говорилось выше.
Первый путь - унификация протокола УСПД верхнего уровня. Второй путь - разработка под каждый УСПД своего драйвера верхнего уровня, который бы встраивался в некую программу-сборщик, работающую на верхнем уровне АСКУЭ со стандартными базами данных, типа, например, Microsoft SQL- сервер или Oracle.
При выборе решения по первому пути можно пойти по двум различным вариантам: А или Б.
Вариант А - это выбор проверенного на практике протокола отдельного изготовителя и придание ему статуса отраслевого стандарта. Плюсы такого подхода - минимальные затраты времени и труда на разработку отраслевого стандарта. Минусы: 1) возможность выбора узкоспециализированного и не перспективного протокола, разработанного фирмой под свои частные программно-аппаратные решения и применения, 2) предоставление преимуществ одному из изготовителей перед всеми другими (фора составляет до 1 года) и нарушение принципа свободной конкуренции, способствующего совершенствованию изделий и снижению цен на них, 3) необходимость внесения больших изменений в свою продукцию другим изготовителям, у которых на рынок Беларуси идет лишь часть (возможно, незначительная) их продукции, 4) закрытие доступа продукции белорусским (и другим) изготовителям, использующих местечковый» протокол, на международные рынки средств приборного учета электроэнергии.
Вариант Б - это выбор в качестве отраслевого протокола международного стандарта, например, DLMS. При этом все минусы предыдущего подхода автоматически превращаются в плюсы, а минусом становятся дополнительные затраты на вхождение в ассоциацию пользователей этого протокола, освоение протокола (с учетом необходимости его перевода на государственный язык Беларуси) и международную сертификацию изготовителями УСПД своей продукции.
Второй путь - разработка драйверов под конкретные УСПД и программу сборщика в стандартную базу данных - является наиболее гибким и универсальным, не отвергающим, в том числе, и решения первого пути. По такому же пути происходит развитие не только АСКУЭ, но и родственных систем - АСУ ТП, или SCADA-систем. В рамках этих систем используются сотни драйверов, ориентированных на применение сотен типов оборудования (датчиков, исполнительных механизмов, контроллеров и компьютеров) от различных изготовителей. Обычно в SCADA-систем эти драйверы входят в виде пакета, набора типовых программ, но в случае отсутствия в таком пакете драйвера какого-либо редкого устройства, он может быть разработан с помощью средств разработки, также входящих в состав SCADA-системы. При этом часто используются, как было показано выше, унифицированные технологии разработки драйверов в виде ОРС-серверов и соответствующих ОРС-клиентов.
Выводы
1. Для унификации решений в АСКУЭ на верхних уровнях сбора данных целесообразно выбрать путь разработки программы-сборщика данных в стандартные базы данных и соответствующих драйверов под конкретные УСПД, использующиеся в АСКУЭ промышленности и быта.
2. Разработка программы-сборщика и драйверов может быть выполнена силами специалистов отрасли (отраслевых институтов, служб АСУ ТП или АСКУЭ энергосистем и их филиалов), если на эти цели будут выделены средства из отраслевого инвестиционного фонда Министерства энергетики Республики Беларусь. Для этих разработок можно также дополнительно привлечь по хозяйственным договорам средства заинтересованных конкретных изготовителей УСПД.
3. Вслед за программой сборщиком следует разработать программу обработки баз данных (отображение, контроль, управление, документирование, связь с потребителями информации). Эта программа может быть индивидуальна для каждой региональной энергосистемы и разработана как специалистами отрасли, так и по их заказу специализированными софтверными компаниями.
4. При выборе унифицированного протокола для связи счетчика или УСПД с верхним уровнем АСКУЭ предпочтение следует отдавать международным стандартам и выполнять разработки своих устройств со встраиванием в них соответствующих протоколов в рамках ассоциаций пользователей этих стандартов.
Примечания.
* Интерфейс – система технических средств и правил для сопряжения и взаимодействия (физического и информационного) компонентов (оборудования и программ) систем. Назначение интерфейса – унификация внутри- и межсистемных связей.
** Протокол – набор правил обмена данными (синтаксис протокола – форматы данных, уровни сигналов и т.п., семантика протокола – управляющая информация, синхронизация). Протоколы служат для связи между процессами различных систем, т.е. определяют что, как и когда передается, и должны соответствовать заключенным публичным соглашениям.
***DLMS - протокол для дистанционного считывания данных приборного учета энергоносителей (электроэнергии, тепловой энергии, воды, газа и т.д.) и коммуникации в двух направлениях для большого числа приборов с коммутацией по различным каналам связи - телефонной сети, мобильной сети сотовой связи, силовой сети, радиосети и т.д.. Международные стандарты МЭК для DLMS: 62056-21 (прямой локальный обмен данными), 62056-42 (физический уровень для соединения и обмена асинхронными данными), 62056-46 (канальный уровень с использованием протокола HDLC), 62056-53, 62056-61, 62056-62 (интерфейс объектов). Организационный ежегодный взнос для вступления в ассоциацию членов DLMS - без права голоса 500 евро, с правом голоса – 1500 евро.
Справка
Статья опубликована в журналах:
Энергетика и ТЭК, №9,2007 (Беларусь)
Промышленные АСУ и контроллеры, №10,2007 (Россия)