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

Естественно с ростом компаний и предлагаемых устройств росло и количество интерфейсов, что привело к появлению проблемы интеграции устройств, различных производителей в одну систему. Поэтому кроме надежности функционирования все более важными требованиями в системах АСУ ТП становятся функциональные возможности, простота инсталляции и обслуживания, приспособленность к специфическим условиям, соответствие общепринятым стандартам. На сегодняшний день существующие протоколы можно разделить на три группы:

  • индивидуальные;
  • частные «закрытые» сети;
  • сети с открытой архитектурой;

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

Частные сети, представляют собой интерфейсы, использующиеся компаниями для выпуска каких-то серий продуктов, без предоставления разработчику системы управления протоколов обмена. Необходимо сразу отметить, что использование «закрытых» сетей значительно снижает «гибкость» системы за счёт использования стандартной аппаратуры без возможности её доработки и замены на модули собственной разработки. Как правило, такие системы получаются очень громоздкими.

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

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

На сегодняшний день существуют сотни различных интерфейсов и сотни тысяч устройств, использующих эти протоколы. Возникает вопрос, каким образом разработчику АСУ разобраться какой протокол применять.

Решение этого вопроса упрощается, если система «однотипная», т.е. предназначенная для решения узкого круга задач, не имеет большого разнообразия датчиков и исполнительных механизмов. В этом случае можно подобрать крупного производителя, например Siemens, Schneider-electric, выпускающего весь спектр оборудования для построения простой системы.

Если же система большая и невозможно найти производителя, способного обеспечить всей необходимой номенклатуры устройств, тогда сразу возникает проблема связи устройств различных производителей. В настоящий момент на рынке множество устройств, так называемых «мостов» для связи различных сетей. Использование этих устройств частично решает проблему, но за счёт увеличения стоимости и делая систему более громоздкой и как следствие менее надёжной.

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

На мой взгляд, есть решение проблемы, позволяющее сделать систему более гибкой за счёт использования устройств более приспособленных для решения конкретной задачи, но имеющих различный интерфейсы. Для этого необходимо проанализировать существующие интерфейсы (самые распространенные) и понять, что же общего у этих интерфейсов и как их можно унифицировать. Для этого необходимо уложить все интерфейсы в какие-нибудь общепринятые рамки и выявить сходные и различные области. Оптимальным вариантом является попробовать представить все интерфейсы в рамках общепринятой модели OSI/ISO. Это не так-то просто сделать, т.к., как уже говорилось, большинство интерфейсов разрабатывалось под конкретные нужды и не всегда опираясь на существующие, на тот момент, стандарты. Часть интерфейсов, вообще закрыты и существуют сложности с получением более или менее достаточной информации для возможности классификации такого протокола.

Модель OSI/ISO описывает семь уровней:

  • 7  Application         Прикладной уровень
  • 6  Presentation         Уровень представления
  • 5  Session       Уровень сессий
  • 4  Transport   Транспортный уровень
  • 3  Network     Сетевой уровень
  • 2  Data Link   Канальный уровень
  • 1  Physical      Физический уровень

На физическом уровне определяются физические характеристики канала связи и параметры сигналов.

Канальный уровень формирует основную единицу передаваемых данных - пакет и отвечает за дисциплину доступа устройства к каналу связи (Medium Access Control) и установление связи.

Сетевой уровень отвечает за адресацию и доставку пакета по оптимальному маршруту.

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

Уровень сессий оперирует сообщениями и координирует взаимодействие между участниками сети.

Уровень представления занимается преобразованием форматов данных, если это необходимо.

Прикладной уровень — это набор интерфейсов, доступных программе пользователя.

На практике большинство промышленных сетей ограничивается только тремя из них, а именно физическим, канальным и прикладным. Наиболее «продвинутые» сети решают основную часть задач аппаратно, оставляя программную прослойку только на седьмом уровне. Дешевые сети (например ModBus) зачастую используют на физическом уровне RS-232 или RS-485, а все остальные задачи, начиная с канального уровня, решают программным путем. Значит для построения той или иной сети достаточно иметь устройство имеющее приёмо-передатчик обеспечивающий физический уровень и канальный (если это необходимо). Для того чтобы понять в каких случаях желательно чтобы приёмопередатчик обеспечивал канальный уровень, а в каких нет, надо разобраться чем это определяется. Канальный уровень описывает, такую важную характеристику сети, как тип доступа к среде. На самом деле, по большому счету, существует два типа доступа: с коллизиями и без. Доступ к каналу с коллизиями используют Ethernet, CAN и LON. Такой тип доступа позволяет эффективно использовать пропускную способность канала и предоставлять доступ в сеть нескольким активным узлам. Например, в сетях Ethernet применяется технология CSMA/CD (Carrier Sense Multiple Access with Collision Detection), CAN протокол относится к классу CSMA/CR (Carrier Sense Multiple Access with Collision Resolution). Очевидно, что при коллизионном доступе к среде существуют сложности реализации этой функции на программном уровне, в случае маркерного доступа или доступа по типу один ведущий, несколько ведомых и т.д. никаких сложностей, программно реализовать канальный уровень – нет.

Ещё одним аргументом в пользу разработки устройств обеспечивающих только физический и канальный уровень, является то, что в большинстве случаев прикладной уровень является избыточным для работы конкретного устройства (датчика температуры, углового положения, веса и т.п.). Это связано с тем, что производители при разработке протокола пытаются сделать его универсальным, чтобы обеспечить работу всей номенклатуры устройств. Значит, для того чтобы обеспечить работу с конкретным датчиком, не обязательно описывать прикладной уровень полностью на 100 процентов, а достаточно всего лишь описать только ту часть, которая необходима. Например, имеется датчик углового положения, работающий по CANOpen, для того чтобы прочитать с него данные, не обязательно реализовывать полностью прикладной уровень, с описание объектов для модулей дискретного ввода/вывода, датчиков веса и т.д.

Таким образом, систему управления можно сделать гибкой, если использовать модули, поддерживающие только физические уровни наиболее распространённых интерфейсов, таких как RS-485, CAN и Ethernet, а для обеспечения необходимого прикладного уровня (ModBus, ProfiBus, CanOpen, DeviceNet и т.д.) предоставить разработчику соответствующие инструменты. Вместо того чтобы «плодить» интерфейсы при появлении новых датчиков гораздо целесообразней сосредоточится на разработке инструментов, позволяющих просто реализовывать прикладной уровень любого интерфейса. Этот способ позволит строить гибкие системы управления без ограничений на используемые интерфейсы, и к тому же позволит модернизировать такие системы при появлении современных датчиков и т.п. без изменения аппаратной части.

Полное наименование статьи - "Проблемы интеграции оборудования с различными интерфейсами связи для построения АСУТП и способы их решения"

Перчиц А.Н.