Архитектура промышленной сети BitBus

Архитектура промышленной сети BitBus

145

Введение

Любая современная система управления состоит из двух компонентов: компьютера и системы связи. Любой из них может преобладать в зависимости от конкретных функций, но оба существуют в той или иной степени. Существуют системы для зданий, заводов, больниц, железных дорог, кораблей, автодорог, квартир и т.д. По пути следования электроэнергии от электростанции к подстанциям, распределительным трансформаторам, питающим дома и предприятия, существует управляющая система, использующая компьютеры. В больнице за пациентом наблюдают с помощью мониторов, диагностического и лечебного оборудования, подключенного к компьютерной сети. Спутники тоже имеют свою управляющую систему, где компьютеры хранят и обрабатывают информацию. Количество датчиков и электроприводов в управляющих системах обычно составляет от десятков до сотен тысяч единиц. Обычно, каждое управляемое устройство имеет 2-3 порта ввода/вывода. В таких системах количество узлов (датчиков и электроприводов) значительно больше, чем управляющих компьютеров, и все они должны быть обеспечены связью.

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

1. Обзор сетевых технологий контроля

1.1 Определение требований к системам управления

Существуют общие функции систем для работы в любой среде и существуют уникальные, то есть присущие каждому конкретному использованию.

Требования к системе можно разделить на семь направлений:

1. Размер системы и взаимоувязанность составляющих ее частей

2. Надежность системы

3. Гибкость системы

4. Производительность системы

5. Системная интеграция

6. Установка, обслуживание и диагностика

7. Расходы в течение жизненного цикла

Все эти пункты и направления должны определяться в контексте конкретной системы с целью получения правильных результатов.

1.2 Размер системы и взаимоувязанность составляющих ее частей

Размер системы и ее разделение на подсистемы обуславливает адресное пространство, (количество отдельно адресуемых узлов системы) его деление между подсистемами, что сказывается на удобстве использования и производительности системы. Обычно один агрегат или машина содержит 10 - 100 адресуемых элементов. Подсистема может содержать 10 - 32000 узлов и в системе может существовать более 100 подсистем. Можно организовать систему по иерархическому принципу, и обходится на каждом уровне небольшим адресным пространством, но такие системы уже устарели, т.к. одноуровневая архитектура обладает лучшими характеристиками. В случае использования одноуровневой архитектуры сегментация осуществляется логически. С этой целью применяются маршрутизаторы сетевого уровня. Внутри одноуровневой архитектуры гибкая система адресации позволяет использовать короткие адреса в небольших системах и длинные в системах контроля крупных предприятий, офисных зданий и транспортных объединений.

1.3 Надежность системы

Таблица 1.1.

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

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

Аутентификация отправителя сообщений необходима для защиты от несанкционированного доступа. Эта функция существует почти во всех системах управления: от домашней до промышленной.

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

1.4 Гибкость системы

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

Таблица 1.2.

1.5 Производительность системы

Производительность системы в целом зависит от многих факторов. Вот некоторые из них.

- Максимально возможная скорость передачи.

Этот параметр непосредственно влияет на время прохождения пакета в линии. Например, для 100-битного пакета время прохождения составляет 0,1 микросекунды при скорости 1Mbps и 1 миллисекунду при скорости 100Kbps. Очень полезна возможность варьировать скорость передачи в широких пределах, от нескольких килобит в секунду до мегабайта в секунду. Обдуманный выбор скорости передачи - наиболее желательный способ оптимизации соотношения цена/производительность для трансиверов, среды передачи и сетей связи.

- Схема доступа к среде передачи.

Демократический доступ к среде передачи для всех при минимальном количестве узлов идентификации - крайне необходим для предотвращения возникновения патологической ситуации для узлов с низким приоритетом. При недемократической схеме доступа, когда приоритет является единственным критерием доступа к сети, узлы с низким приоритетом могут быть полностью задавлены более разговорчивыми. Это может снизить их производительность до неприемлемого уровня. В мире PLC контроллеров (Programmable Logical Controller), который наиболее “подвинут” в сторону “детерминизма” и где доступ к среде возможен лишь в фиксированные промежутки времени, схема с мультиплексированной шиной управляемой приоритетами наименее приемлема.

- Максимальный размер пакета.

Это непосредственно определяет число пакетов и, следовательно, время, требуемое для завершения транзакции. В приведенной ниже таблице представлена информация о длине пакета в различных областях применения.

Таблица 1.3.

Практически все системы, даже такие дорогостоящие как системы освещения или разрозненные производственные системы с большим количеством цифровых датчиков, содержат аналоговые или сложные (analog/complex) датчики и активаторы (приводы). И эти датчики требуют поддержки пакетов размером 4-25 бит для обычных данных и несколько более длинных пакетов для передачи калибровочных данных. Более того, чем устройство интеллектуальней, тем длина пакета больше. Уже на сегодняшний день характерный размер передаваемых данных составляет 30 байт, а в ближайшие несколько лет обещает вырасти до 50 и более байт.

В общем, можно выделить два основных требования:

- как можно больший максимальный размер пакета;

- возможность варьировать длину пакета от нуля до максимального.

На следующих двух рисунках проиллюстрировано отличие между единой сетью, поддерживающей передачу пакетов разной длины (рисунок 1.1.), и объединением нескольких сетей, каждая из которых поддерживает передачу пакетов только фиксированной длины (рисунок 1.2.). Метод передачи больших пакетов путем разбивки в несколько маленьких (фрагментация) лучше использовать как вспомогательный, хотя он позволяет повысить производительность. Совершенно очевидно, что единая сеть, поддерживающая пакеты разной длины без использования фрагментации, наиболее предпочтительна.

Рисунок 1.1. Единая сеть, поддерживающая передачу пакетов разной длины.

Рисунок 1.2. Объединение нескольких сетей, каждая из которых поддерживает передачу пакетов только фиксированной длины.

- По-событийное обновление показаний датчиков.

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

- Одноуровневая архитектура.

Такая архитектура позволяет связываться устройствам прямо через сеть управления. Это делает ненужным центральный контроллер, являющийся узким местом всей системы. Как было замечено ранее, центральный контроллер - просто исторический артефакт тех времен, когда вычислительные мощности были сосредоточены в больших центральных машинах. С приходом недорогих СБИС с достаточными вычислительными ресурсами, такая архитектура стала полностью вымирающей и ненужной. Независимо от демократического одноуровневого доступа к среде передачи и по-событийного обновления показаний датчиков, одноуровневая система также требует достаточной интеллектуальности для датчиков и активаторов (особенно для активаторов) для обеспечения прямого выполнения управляющего алгоритма (и производства необходимых действий) вместо ожидания управляющей команды от центрального котроллера, вырабатываемой на основе обработки данных от датчиков.

- Выделенный прикладной процессор.

Многократно повторяющиеся прерывания прикладного процессора на обработку приходящих пакетов или других коммуникационных задач отрицательно влияют на производительность в обоих случаях. Они также влияют на надежность узла и системы в целом. Пусть занятый канал послал десять пакетов с интервалом 100 микросекунд при размере пакета 100 бит и скорости 1 мегабит в секунду и ждет подтверждения приема каждого пакета. На обработку прерывания, возникающего при приеме пакета, процессор тратит не менее 25 микросекунд и в итоге приложению может не хватить времени на сортировку приходящих пакетов, осуществление процесса ввода/вывода, выполнения локальных вычислений и генерацию пакетов с ответом. Таким образом, на приемном конце пакеты могут быть потеряны. Потерянные пакеты приведут к срыву завершения транзакции и могут вызвать остановку работы сети в целом.

- Задержки при прохождении роутеров (маршрутизаторов) и шлюзов.

Роутеры, соединяющие подсети, должны работать на уровне приложений модели OSI/ISO, если реализация сетевого уровня протокола не предполагает маршрутизации на своем уровне. Для иллюстрации отличия между маршрутизацией прикладного и системного уровня, приведем аналогию с почтовой службой. Письмо. Посылаемое из города А в город Б, может быть отсортировано прямо по адресу города и доставлено (маршрутизация сетевого уровня). Во втором случае, клерк на почте не читает адрес города, а только фамилии адресата и отправителя и должен помнить, что мистер Джонс из города А всегда пишет мистеру Грину в город Б (маршрутизация прикладного уровня). Такая система требует больше ресурсов и работает медленнее. Читатель может сам сделать выводы о производительности, масштабируемости, восстанавливаемости и гибкости на основании приведенного примера.

- Прогнозируемость.

Прогнозируемость (Determinism) иногда упоминается как фактор, влияющий на производительность без уточнения почему. Однако тот детерминизм, который упоминается везде и всюду, есть прогнозируемость системного уровня и означает, что цикл измерения завершится в течении строго определенного временного интервала, начиная с возникновения события или условия, заставившего датчик сработать. Такая прогнозируемость невозможна в реальном мире за исключением традиционных однопоточных систем полностью контролируемых центральным устройством, подобным PLC (Programmable Logical Controller), выполняющим постоянное сканирование в строго определенные моменты времени, использующим централизованно управляемую шину типа точка-точка или шину с множественным доступом и временным разделением. Схема с прослушиванием несущей и контролем коллизий не гарантирует прогнозируемости уровня соединений (link level determinism). Такие технологии как предупреждение коллизий, разрешение коллизий, определение коллизий, система приоритетов и их комбинации, будучи применяемы в рамках CSMA схемы доступа (carrier-sense multiple access), могут увеличить прогнозируемость системы. Должна существовать возможность включать и выключать эти дополнительные подпротоколы избирательно для канала, узла или параметров узла без остановки всей системы.

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

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

Однако, прогнозируемость, как объективная реальность, более похожа на требования к “реально быстрым” системам, нежели на требования к системам “реального времени”. Цель первых иллюзорна и препятствует выработке любого реального решения. Второе требует системного подхода и предполагает оптимизационные решения для системных требований реального времени.

- Системная интеграция.

Системная интеграция - это ключевая область, в которой требуется глубокое понимание реализации системной архитектуры, сервисных протоколов, средств разработки и инструментария. Легкость системной интеграции имеет прямое влияние на стоимость установки и текущей эксплуатации. В бытовых условиях это означает, что даже десятилетние дети и пожилые родители могут изменять конфигурацию системы безопасности без вызова специалиста. В случае офисного здания разница стоимости установки системы может достигать 20%, что может составлять от сотен тысяч до нескольких миллионов долларов и достаточна, чтобы возбудить дискуссию с покупателем. На производственном предприятии экономия может составлять до 40%.

Наиболее важным из вышеперечисленных факторов является качество реализации стека протоколов передачи данных. Обзор наиболее качественных решений выделяет различия в целесообразности их применимости. Компьютерный мир предоставляет нам очень поучительный урок. Мир ОС UNIX, содержащий максимально совместимые решения, вынужден сейчас развиваться в сторону DOS, несмотря на неоспоримое техническое превосходство. Даже во время второго раунда, когда UNIX все еще мог предложить большие возможности, нежели Windows NT, последний был более популярен. Мир PC страдает от многочисленных ошибок несовместимости, добиваясь жизнеспособности. 98% компаний, ориентированных на PC выходят из бизнеса, поскольку их продукты вызывают слишком много побочных эффектов для других приложений.

Пользователи, купившие свои PC, мучаются каждый день от необъяснимых аномалий операционной системы. Разработчики программного и аппаратного обеспечения PC хорошо помнят кошмары тестирования системного уровня своего продукта на совместимость с огромным числом других программ. В мире множественных реализаций любого сложного стандарта (операционная система, сетевой протокол) немного решений проходят проверку временем с точки зрения Plug&Play совместимости. Понятие правильной реализации теста обречено быть ограниченным в своей практической годности, поскольку реальные тесты всегда не полны, и не дают полной верификации. Более того, все реализации, точные или нет, являются предметом для личных интерпретаций.

Таблица 1.4.

- Установка системы, эксплуатация и диагностика.

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

Таблица 1.5.

Таблица 1.6.

- Стоимость эксплуатации и окупаемость.

В среднем по промышленным предприятиям необходимый срок окупаемости нового оборудования снижается. Период переоснастки производственных линий фабрик снизился с 6-10 лет до 3-4 лет. В полупроводниковом производстве линии обновляются каждые 2-3 года. Ресурс вагонеток составляет 5-10 лет. Системы автоматизации зданий могут служить больше, но нуждаются в периодических доработках и модификациях.

Таблица 1.7.

1.6 Системная архитектура

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

Модели многих компьютерных систем прошлого были иерархическими и состояли из нескольких уровней. IBM-овский SNA и DEC-овский DNA, во времена их расцвета, показали здоровый спектр мэйнфреймов а также больших и малых миниЭВМ, использующих многоуровневую архитектуру с большим количеством вспомогательных персональных компьютеров на низших уровнях. Конечно, разница между таким взглядом и сегодняшней реальностью достаточно очевидна. Современные системы состоят из сети распределенных систем клиент\сервер, связанных посредством маршрутизаторов, мостов и шлюзов. Многие клиентские компьютеры и сервера обладают одинаковой производительностью, лишь небольшое количество их более мощные нежели остальные, включая многочисленные рабочие станции, редкие миниЭВМ и почти вымершие мэйнфреймы.

Устаревшая архитектурная модель состоит из пяти уровней (рис 6). Не смотря на то, что мир контрольных сетей не является настолько продвинутым, как компьютерный, его развитие в этом направлении неизбежно, благодаря преимуществам этой технологии для конечных пользователей. Децентрализация компьютерных систем приносит колоссальные вычислительные мощности туда, где при централизованной системе это было просто невозможно. Распределенное управление, аналогично, позволяет расширить круг управления. Распределенные системы контроля одноуровневой архитектуры установлены в офисных зданиях, жилых домах, гостиницах, на транспорте и др. Индустриальные системы контроля, загроможденные своим установленным оборудованием, задержались на старте, но теперь набирают скорость и развиваются в том же направлении. Системы управления одноуровневой архитектуры работают в газовых хранилищах, очистных сооружениях, заводах, металлургических комбинатах, автоматических производственных линиях, нефтепроводах и др. Микро PLC (Programmable Logical Controller) и сетевые микро PLC наиболее перспективное направление на рынке дискретного управления.

Рисунки 1.3., 1.4. и 1.5. показывают возможные стадии развития системной архитектуры от иерархической к одноуровневой.

Система, показанная на рисунке 1.3. похожа на большинство промышленных систем. На заводе каждая ячейка может состоять из множества подсистем, выполняющих управление различными функциями передвижения, монтажа, штамповки и другими действиями. Продукт передвигается от ячейки к ячейке по конвейерной линии в течение монтажного процесса. Каждая ячейка может быть оснащена PLC, встроенным PC, индустриальными компьютерами и т.д., управляющими неинтеллектуальными сенсорами и вводом/выводом. Традиционные системы автоматизации зданий и других систем могут быть сегментированы подобным образом.

Рисунок 1.4. показывает систему промежуточной архитектуры, состоящую из нескольких неинтеллектуальных сенсоров (S) и приводов (A), управляемых центральным контроллером, связанным с распределенными подсистемами, использующими интеллектуальные сенсоры (IS) и приводы (IA). Эти интеллектуальные сенсоры передают контрольные сигналы через одноуровневые соединения.

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

Такая распределенная система работает корректно при условии:

- достаточного адресного пространства;

- наличия логической сегментации системы, реализуемой посредством адресации и фильтрации трафика;

- производительность компьютеров, скорость обмена данными и размер пакета масштабируемы для каждого узла в зависимости от решаемой задачи управления.

Рисунок 1.3. Традиционная иерархическая система.

Рисунок 1.4. Переходная система с иерархическими и равноправными элементами.

Рисунок 1.5. Распределенная система одноуровневой архитектуры.

Таблица 1.8.

1.7 Обзор протоколов передачи

Таблица 1.8. содержит информацию о важных сервисных протоколах для шины сенсоров/приводов, полученных в ходе дискуссии на тему системных требований. Для классификации используется семиуровневая модель OSI/ISO.

Семиуровневая модель OSI./ISO

1. Физический уровень - фактическая передача битов по передающей среде, связан с аппаратурой - разъемами, сетевыми платами.

2. Уровень линии передачи данных - обеспечивает связь с фактическим потоком битов на физическом уровне, осуществляет сборку и разборку потока битов на кадры.

3. Сетевой уровень - определяет фактический путь данных между узлами сети, обеспечивает адресацию и маршрутизацию пакетов.

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

5. Сеансовый уровень-управление сеансом главного компьютера.

6. Уровень представления данных - кодировка и декодировка фактических данных.

7. Прикладной уровень-организация взаимодействия с пользователем.

1.8 Обзор возможных решений

Соглашение о терминологии. Один из факторов, скрывающих тот факт, что обычные платформы могут работать в различных областях производства является вавилонской башней имен этих сетей. Термины “fieldbus”, сеть сенсоров/приводов, сенсорная сеть, управляющая сеть, существовали и раньше, а термин “приборная сеть” появился недавно.

В чем отличие “fieldbus” от управляющей сети (control network)? “Field” инструментарий является более совершенным средством, чем аналоговые сенсоры или составные сенсоры, так же как рабочие станции более совершенны, чем персональные компьютеры. Следует заметить, что на каждый “field instrument” (полевой инструмент) приходится порядка 10 датчиков. Таким образом, для подключения этих устройств к общей сети в стиле “control network”, необходимо использовать “fieldbus”. Если мы используем разнородные устройства, то необходимо использовать разнородные способы подключения. Общая шина, обеспечивающая потребности “field instruments” (полевых инструментов) в вычислительных ресурсах и данных, а также потребности недорогих датчиков, решает обе проблемы.

Приборная сеть определяется как сеть, которая в первую очередь включает в себя дискретные сенсоры. Таким образом, промышленные клиенты сталкиваются с тремя названиями: “fieldbus”, управляющая сеть и приборная сеть.

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

Подобная независимая инициатива была проявлена в Интеллектуальных Авто Дорожных Системах (IVHS) для автоматизации сбора оплаты, создания интеллектуальных перекрестков и других, более футуристических интеллектуальных систем управления движением, таких как караваны машин с автоматическим управлением. Все эти проекты связаны с одними конечными устройствами - сенсорами и приводами. С точки зрения связи приложений, конфигурирования и диагностики, существует несколько сходных и различных требований. Уникальные требования могут быть удовлетворены различными дополнениями к основной технологии.

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

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

Некоторые варианты. Вопрос о необходимости определения единого протокола для управляющих сетей “Один Мир - Один Протокол” остается без ответа до настоящего времени. Основными доступными сейчас и в будущем вариантами являются:

- Решения, основанные на CAN, такие как CAN автоматизация, DeviceNet, J1850 и SDS;

- Шины простых сенсоров Seriplex и Bitbus;

- Технология LonWorks;

- CEBus;

- BACnet;

- Инструментальные шины IEEE488;

- Производственные решения MAP и ARCnet;

- Решения для производственных процессов Profi-Bus и Fieldbus Foundation;

- Другие промышленные шины Opto-22, Interbus-S и др.

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

1.9 Стандартизация контрольных сетей

Взгляд вперед. Важно определить направление развития контрольных сетей, т.е. какими должны стать сенсоры, инструменты для установки, диагностики и ремонта. Существует несколько подходов:

- Общая контрольная сеть с общими объектными моделями.

- Различные контрольные сети с общими объектными моделями.

- Общие контрольные сети с различными объектными моделями.

- Различные контрольные сети с различными объектными моделями.

Необходимо выработать единый протокол передачи (Один мир - один протокол). Общая контрольная сеть обеспечивает совместимость на уровне сети. Общие объектные модели определяют поведение на уровне приложений и совместимость. Такой подход будет выгоден производителям, т.к. можно будет писать программы и строить оборудование, соотносясь только с одной моделью.

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

Таким образом, наилучшим вариантом будет получение общих определений объектов для работы с разными платформами.

- Каждый сенсор, разработанный для выполнения определенных функций, должен будет их выполнять вне зависимости от сетевой платформы, под которой он работает, и типа связи. Аналогично одинаковой работе Word и Excel под Windows или Macintosh System 7, вне зависимости от типа передачи данных через Ethernet/TP, Ethernet/Coax, NetWare, TCP/IP или при использовании другой схемы.

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

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

Страницы: 1, 2, 3, 4, 5, 6