Раздел 2. интегририованные системы проектирования
И УПРАВЛЕНИЯ. ОСНОВНЫЕ ПОЛОЖЕНИЯ,
SCADA-ТЕХНОЛОГИИ
Основы построения сетей
2.1.1. АСУ ТП и диспетчерское управление
Непрерывную во времени картину развития АСУТП можно разделить на три этапа, обусловленные появлением качественно новых научных идей и технических средств. В ходе истории меняется характер объектов и методов управления, средств автоматизации и других компонентов, составляющих содержание современной системы управления.
- Первый этап отражает внедрение систем автоматического регулирования (САР). Объектами управления на этом этапе являются отдельные параметры, установки, агрегаты; решение задач стабилизации, программного управления, слежения переходит от человека к САР. У человека появляются функции расчета задания и параметры настройки регуляторов.
- Второй этап - автоматизация технологических процессов. Объектом управления становится рассредоточенная в пространстве система; с помощью систем автоматического управления (САУ) реализуются все более сложные законы управления, решаются задачи оптимального и адаптивного управления, проводится идентификация объекта и состояний системы. Характерной особенностью этого этапа является внедрение систем телемеханики в управление технологическими процессами. Человек все больше отдаляется от объекта управления, между объектом и диспетчером выстраивается целый ряд измерительных систем, исполнительных механизмов, средств телемеханики, мнемосхем и других средств отображения информации (СОИ).
- Третий этап - автоматизированные системы управления технологическими процессами - характеризуется внедрением в управление технологическими процессами вычислительной техники. Вначале - применение микропроцессоров, использование на отдельных фазах управления вычислительных систем; затем активное развитие человеко-машинных систем управления, инженерной психологии, методов и моделей исследования операций и, наконец, диспетчерское управление на основе использования автоматических информационных систем сбора данных и современных вычислительных комплексов.
От этапа к этапу менялись и функции человека (оператора/диспетчера), призванного обеспечить регламентное функционирование технологического процесса. Расширяется круг задач, решаемых на уровне управления; ограниченный прямой необходимостью управления технологическим процессом набор задач пополняется качественно новыми задачами, ранее имеющими вспомогательный характер или относящиеся к другому уровню управления.
Диспетчер в многоуровневой автоматизированной системе управления технологическими процессами получает информацию с монитора ЭВМ или с электронной системы отображения информации и воздействует на объекты, находящиеся от него на значительном расстоянии с помощью телекоммуникационных систем, контроллеров, интеллектуальных исполнительных механизмов.
Основой, необходимым условием эффективной реализации диспетчерского управления, имеющего ярко выраженный динамический характер, становится работа с информацией, т. е. процессы сбора, передачи, обработки, отображения, представления информации. От диспетчера уже требуется не только профессиональное знание технологического процесса, основ управления им, но и опыт работы в информационных системах, умение принимать решение (в диалоге с ЭВМ) в нештатных и аварийных ситуациях и многое другое. Диспетчер становится главным действующим лицом в управлении технологическим процессом.
Говоря о диспетчерском управлении, нельзя не затронуть проблему технологического риска. Технологические процессы в энергетике, нефтегазовой и ряде других отраслей промышленности являются потенциально опасными и при возникновении аварий приводят к человеческим жертвам, а также к значительному материальному и экологическому ущербу. Статистика говорит, что за тридцать лет число учтенных аварий удваивается примерно каждые десять лет. В основе любой аварии за исключением стихийных бедствий лежит ошибка человека.
В результате анализа большинства аварий и происшествий на всех видах транспорта, в промышленности и энергетике были получены интересные данные. В 60 - х годах ошибка человека была первоначальной причиной аварий лишь в 20% случаев, тогда как к концу 80-х доля "человеческого фактора" стала приближаться к 80 %.
Одна из причин этой тенденции - старый традиционный подход к построению сложных систем управления, т. е. ориентация на применение новейших технических и технологических достижений и недооценка необходимости построения эффективного человеко - машинного интерфейса, ориентированного на человека (диспетчера).
Таким образом, требование повышения надежности систем диспетчерского управления является одной из предпосылок появления нового подхода при разработке таких систем: ориентация на оператора/диспетчера и его задачи.
Концепция SCАDA (Supervisory Control And Data Acquisition - диспетчерское управление и сбор данных) предопределена всем ходом развития систем управления и результатами научно-технического прогресса. Применение SCADA-технологий позволяет достичь высокого уровня автоматизации в решении задач разработки систем управления, сбора, обработки, передачи, хранения и отображения информации.
Дружественность человеко-машинного интерфейса (HMI/MMI), предоставляемого SCADA - системами, полнота и наглядность представляемой на экране информации, доступность "рычагов" управления, удобство пользования подсказками и справочной системой и т. д. - повышает эффективность взаимодействия диспетчера с системой и сводит к нулю его критические ошибки при управлении.
Следует отметить, что концепция SCADA, основу которой составляет автоматизированная разработка систем управления, позволяет решить еще ряд задач, долгое время считавшихся неразрешимыми: сократить сроки разработки проектов по автоматизации и прямые финансовые затраты на их разработку.
В настоящее время SCADA является основным и наиболее перспективным методом автоматизированного управления сложными динамическими системами (процессами).
Управление технологическими процессами на основе систем SCADA стало осуществляться в передовых западных странах в 80-е годы. Область применения охватывает сложные объекты электро- и водоснабжения, химические, нефтехимические и нефтеперерабатывающие производства, железнодорожный транспорт, транспорт нефти и газа и др.
В России диспетчерское управление технологическими процессами опиралось, главным образом, на опыт оперативно-диспетчерского персонала. Поэтому переход к управлению на основе SCADA-систем стал осуществляться несколько позднее. К трудностям освоения в России новой информационной технологии, какой являются SCADA-системы, относится как отсутствие эксплуатационного опыта, так и недостаток информации о различных SCADA-системах. В мире насчитывается не один десяток компаний, активно занимающихся разработкой и внедрением SCADA-систем. Каждая SCADA-система - это "know-how" компании и поэтому данные о той или иной системе не столь обширны.
Большое значение при внедрении современных систем диспетчерского управления имеет решение следующих задач:
- выбора SCADA-системы (исходя из требований и особенностей технологического процесса);
- кадрового сопровождения.
Выбор SCADA-системы представляет собой достаточно трудную задачу, аналогичную принятию решений в условиях многокритериальности, усложненную невозможностью количественной оценки ряда критериев из-за недостатка информации.
Подготовка специалистов по разработке и эксплуатации систем управления на базе программного обеспечения SCADA осуществляется на специализированных курсах различных фирм, курсах повышения квалификации. В настоящее время в учебные планы ряда технических университетов начали вводиться дисциплины, связанные с изучением SCADA-систем. Однако специальная литература по SCADA-системам отсутствует; имеются лишь отдельные статьи и рекламные проспекты.
Компоненты систем контроля и управления и их назначение
Многие проекты автоматизированных систем контроля и управления (СКУ) для большого спектра областей применения позволяют выделить обобщенную схему их реализации, представленную на рис.2.1.
Рис. 2.1. Обобщенная схема реализации автоматизированных систем контроля
и управления (СКУ)
Как правило, это двухуровневые системы, так как именно на этих уровнях реализуется непосредственное управление технологическими процессами. Специфика каждой конкретной системы управления определяется используемой на каждом уровне программно - аппаратной платформой.
- Нижний уровень - уровень объекта (контроллерный) - включает различные датчики для сбора информации о ходе технологического процесса, электроприводы и исполнительные механизмы для реализации регулирующих и управляющих воздействий. Датчики поставляют информацию локальным программируемым логическим контроллерам (PLC - Programming Logical Controoller), которые могут выполнять следующие функции:
- сбор и обработка информации о параметрах технологического процесса;
o управление электроприводами и другими исполнительными механизмами;
- решение задач автоматического логического управления и др.
Так как информация в контроллерах предварительно обрабатывается и частично используется на месте, существенно снижаются требования к пропускной способности каналов связи.
В качестве локальных PLC в системах контроля и управления различными технологическими процессами в настоящее время применяются контроллеры как отечественных производителей, так и зарубежных. На рынке представлены многие десятки и даже сотни типов контроллеров, способных обрабатывать от нескольких переменных до нескольких сот переменных.
К аппаратно-программным средствам контроллерного уровня управления предъявляются жесткие требования по надежности, времени реакции на исполнительные устройства, датчики и т.д. Программируемые логические контроллеры должны гарантированно откликаться на внешние события, поступающие от объекта, за время, определенное для каждого события.
Для критичных с этой точки зрения объектов рекомендуется использовать контроллеры с операционными системами реального времени (ОСРВ). Контроллеры под управлением ОСРВ функционируют в режиме жесткого реального времени.
Разработка, отладка и исполнение программ управления локальными контроллерами осуществляется с помощью специализированного программного обеспечения, широко представленного на рынке. К этому классу инструментального ПО относятся пакеты типа ISaGRAF (CJ International France), InConrol (Wonderware, USA), Paradym 31 (Intellution, USA), имеющие открытую архитектуру.
- Информация с локальных контроллеров может направляться в сеть диспетчерского пункта непосредственно, а также через контроллеры верхнего уровня (см. рис.). В зависимости от поставленной задачи контроллеры верхнего уровня (концентраторы, интеллектуальные или коммуникационные контроллеры) реализуют различные функции. Некоторые из них перечислены ниже:
- сбор данных с локальных контроллеров;
- обработка данных, включая масштабирование;
- поддержание единого времени в системе;
- синхронизация работы подсистем;
- организация архивов по выбранным параметрам;
- обмен информацией между локальными контроллерами и верхним уровнем;
- работа в автономном режиме при нарушениях связи с верхним уровнем;
- резервирование каналов передачи данных и др.
- Верхний уровень - диспетчерский пункт (ДП) - включает, прежде всего, одну или несколько станций управления, представляющих собой автоматизированное рабочее место (АРМ) диспетчера/оператора. Здесь же может быть размещен сервер базы данных, рабочие места (компьютеры) для специалистов и т. д. Часто в качестве рабочих станций используются ПЭВМ типа IBM PC различных конфигураций. Станции управления предназначены для отображения хода технологического процесса и оперативного управления. Эти задачи и призваны решать SCADA - системы. SCADА - это специализированное программное обеспечение, ориентированное на обеспечение интерфейса между диспетчером и системой управления, а также коммуникацию с внешним миром.
Спектр функциональных возможностей определен самой ролью SCADA в системах управления и реализован практически во всех пакетах:
- автоматизированная разработка, дающая возможность создания ПО системы автоматизации без реального программирования;
- средства исполнения прикладных программ;
- сбор первичной информации от устройств нижнего уровня;
- обработка первичной информации;
- регистрация алармов и исторических данных;
- хранение информации с возможностью ее пост-обработки (как правило, реализуется через интерфейсы к наиболее популярным базам данных);
- визуализация информации в виде мнемосхем, графиков и т.п.;
- возможность работы прикладной системы с наборами параметров, рассматриваемых как "единое целое" ("recipe" или "установки").
Рассматривая обобщенную структуру систем управления, следует ввести и еще одно понятие - Micro-SCADA. Micro-SCADA - это системы, реализующие стандартные (базовые) функции, присущие SCADA - системам верхнего уровня, но ориентированные на решение задач автоматизации в определенной отрасли (узкоспециализированные). В противоположность им SCADA - системы верхнего уровня являются универсальными.
Разработка прикладного программного обеспечения СКУ: выбор пути и инструментария
Приступая к разработке специализированного прикладного программного обеспечения (ППО) для создания системы контроля и управления, системный интегратор или конечный пользователь обычно выбирает один из следующих путей:
- Программирование с использованием "традиционных" средств (традиционные языки программирования, стандартные средства отладки и пр.)
- Использование существующих, готовых - COTS (Commercial Of The Shelf) - инструментальных проблемно-ориентированных средств.
Для большинства выбор уже очевиден. Процесс разработки ППО важно упростить, сократить временные и прямые финансовые затраты на разработку ППО, минимизировать затраты труда высококлассных программистов, по возможности привлекая к разработке специалистов-технологов в области автоматизируемых процессов. При такой постановке задачи второй путь может оказаться более предпочтительным.
Для сложных распределенных систем процесс разработки собственного ППО с использованием "традиционных" средств может стать недопустимо длительным, а затраты на его разработку неоправданно высокими. Вариант с непосредственным программированием относительно привлекателен лишь для простых систем или небольших фрагментов большой системы, для которых нет стандартных решений (не написан, например, подходящий драйвер) или они не устраивают по тем или иным причинам в принципе.
Итак, выбор пути сделан! Это очень важно, но тогда следует сделать и второй шаг - "определиться" с инструментальными средствами разработки ППО. Программные продукты класса SCADA широко представлены на мировом рынке. Это несколько десятков SCADA - систем, многие из которых нашли свое применение и в России. Наиболее популярные из них приведены в табл. 2.1.
Таблица 2.1
|
При таком многообразии SCADA - продуктов на российском рынке естественно возникает вопрос о выборе. Выбор SCADA-системы представляет собой достаточно трудную задачу, аналогичную поиску оптимального решения в условиях многокритериальности. Ниже приводится примерный перечень критериев оценки SCADA - систем, которые в первую очередь должны интересовать пользователя. Этот перечень не является авторским и давно уже обсуждается в специальной периодической прессе. В нем можно выделить три большие группы показателей:
- технические характеристики;
- стоимостные характеристики;
- эксплуатационные характеристики.
Технические характеристики
Программно-аппаратные платформы для SCADA-систем. Анализ перечня таких платформ необходим, поскольку от него зависит ответ на вопрос, возможна ли реализация той или иной SCADA-системы на имеющихся вычислительных средствах, а также оценка стоимости эксплуатации системы (будучи разработанной в одной операционной среде, прикладная программа может быть выполнена в любой другой, которую поддерживает выбранный SCADA-пакет). В различных SCADA-системах этот вопрос решен по разному. Так, FactoryLink имеет весьма широкий список поддерживаемых программно-аппаратных платформ:
| Операционная система | Компьютерная платформа |
| DOS/MS Windows | IBM PC |
| OS/2 | IBM PC |
| SCO UNIX | IBM PC |
| VMS | VAX |
| AIX | RS6000 |
| HP-UX | HP 9000 |
| MS Windows/NT | Системы с реализованным Windows/NT, в основном на РС-платформе. |
В то же время в таких SCADA-системах, как RealFlex и Sitex основу программной платформы принципиально составляет единственная операционная система реального времени QNX. Подавляющее большинство SCADA-систем реализовано на MS Windows платформах. Именно такие системы предлагают наиболее полные и легко наращиваемые MMI - средства. Учитывая позиции Microsoft на рынке операционных систем (ОС), следует отметить, что даже разработчики многоплатформных SCADA-систем, такие как United States DATA Co (разработчик FactoryLink), приоритетным считают дальнейшее развитие своих SCADA-систем на платформе Windows NT. Некоторые фирмы, до сих пор поддерживавшие SCADA-системы на базе операционных систем реального времени (ОСРВ), начали менять ориентацию, выбирая системы на платформе Windows NT. Все более очевидным становится применение ОСРВ, в основном, во встраиваемых системах, где они действительно хороши. Таким образом, основным полем, где сегодня разворачиваются главные события глобального рынка SCADA--систем, стала MS Windows NT/2000 на фоне всё ускоряющегося сворачивания активности в области MS DOS, MS Windows 3.xx/95.
Имеющиеся средства сетевой поддержки. Одной из основных черт современного мира систем автоматизации является их высокая степень интеграции. В любой из них могут быть задействованы объекты управления, исполнительные механизмы, аппаратура, регистрирующая и обрабатывающая информацию, рабочие места операторов, серверы баз данных и т.д. Очевидно, что для эффективного функционирования в этой разнородной среде SCADA-система должна обеспечивать высокий уровень сетевого сервиса. Желательно, чтобы она поддерживала работу в стандартных сетевых средах (ARCNET, ETHERNET и т.д.) с использованием стандартных протоколов (NETBIOS, TCP/IP и др.), а также обеспечивала поддержку наиболее популярных сетевых стандартов из класса промышленных интерфейсов (PROFIBUS, CANBUS, LON, MODBUS и т.д.) Этим требованиям в той или иной степени удовлетворяют практически все рассматриваемые SCADA-системы, с тем только различием, что набор поддерживаемых сетевых интерфейсов, конечно же, разный.
Встроенные командные языки. Большинство SCADA-систем имеют встроенные языки высокого уровня, VBasic-подобные языки, позволяющие генерировать адекватную реакцию на события, связанные с изменением значения переменной, с выполнением некоторого логического условия, с нажатием комбинации клавиш, а также с выполнением некоторого фрагмента с заданной частотой относительно всего приложения или отдельного окна.
Поддерживаемые базы данных. Одной из основных задач систем диспетчерского контроля и управления является обработка информации: сбор, оперативный анализ, хранение, сжатие, пересылка и т. д. Таким образом, в рамках создаваемой системы должна функционировать база данных. Практически все SCADA-системы, в частности, Genesis, InTouch, Citect, используют ANSI SQL синтаксис, который является независимым от типа базы данных. Таким образом, приложения виртуально изолированы, что позволяет менять базу данных без серьезного изменения самой прикладной задачи, создавать независимые программы для анализа информации, использовать уже наработанное программное обеспечение, ориентированное на обработку данных.
Графические возможности. Для специалиста-разработчика системы автоматизации, также как и для специалиста - "технолога", чье рабочее место создается, очень важен графический пользовательский интерфейс. Функционально графические интерфейсы SCADA-систем весьма похожи. В каждой из них существует графический объектно-ориентированный редактор с определенным набором анимационных функций. Используемая векторная графика дает возможность осуществлять широкий набор операций над выбранным объектом, а также быстро обновлять изображение на экране, используя средства анимации. Крайне важен также вопрос о поддержке в рассматриваемых системах стандартных функций GUI (Graphic Users Interface). Поскольку большинство рассматриваемых SCADA-систем работают под управлением Windows, это и определяет тип используемого GUI.
Открытость систем
Система является открытой, если для нее определены и описаны используемые форматы данных и процедурный интерфейс, что позволяет подключить к ней "внешние", независимо разработанные компоненты.
Разработка собственных программных модулей. Перед фирмами-разработчиками систем автоматизации часто встает вопрос о создании собственных (не предусмотренных в рамках систем SCADA) программных модулей и включение их в создаваемую систему автоматизации. Поэтому вопрос об открытости системы является важной характеристикой SCADA-систем. Фактически открытость системы означает доступность спецификаций системных (в смысле SCADA) вызовов, реализующих тот или иной системный сервис. Это может быть и доступ к графическим функциям, функциям работы с базами данных и т.д.
Драйверы ввода-вывода.Современные SCADA-системы не ограничивают выбора аппаратуры нижнего уровня, так как предоставляют большой набор драйверов или серверов ввода-вывода и имеют хорошо развитые средства создания собственных программных модулей или драйверов новых устройств нижнего уровня. Сами драйверы разрабатываются с использованием стандартных языков программирования. Вопрос, однако, в том, достаточно ли только спецификаций доступа к ядру системы, поставляемых фирмой-разработчиком в штатном комплекте (система Trace Mode), или для создания драйверов необходимы специальные пакеты (системы FactoryLink, InTouch), или же, вообще, разработку драйвера нужно заказывать у фирмы-разработчика.
Разработки третьих фирм. Многие компании занимаются разработкой драйверов, ActiveX-объектов и другого программного обеспечения для SCADA-систем. Этот факт очень важно оценивать при выборе SCADA-пакета, поскольку это расширяет область применения системы непрофессиональными программистами (нет необходимости разрабатывать программы с использованием языков С или Basic).
Стоимостные характеристики
При оценке стоимости SCADA-систем нужно учитывать следующие факторы:
- стоимость программно-аппаратной платформы;
- стоимость системы;
- стоимость освоения системы;
- стоимость сопровождения.
Эксплуатационные характеристики
Показатели этой группы критериев наиболее субъективны. Это тот самый случай, когда лучше один раз увидеть, чем семь раз услышать. К этой группе можно отнести:
- удобство интерфейса среды разработки - "Windows - подобный интерфейс", полнота инструментария и функций системы;
- качество документации - ее полнота, уровень русификации;
- поддержка со стороны создателей - количество инсталляций, дилерская сеть, обучение, условия обновления версий и т. д.
Если предположить, что пользователь справился и с этой задачей - остановил свой выбор на конкретной SCADA - системе, то далее начинается разработка системы контроля и управления, которая включает следующие этапы:
- Разработка архитектуры системы автоматизации в целом. На этом этапе определяется функциональное назначение каждого узла системы автоматизации.
- Решение вопросов, связанных с возможной поддержкой распределенной архитектуры, необходимостью введения узлов с "горячим резервированием" и т.п.
- Создание прикладной системы управления для каждого узла. На этом этапе специалист в области автоматизируемых процессов наполняет узлы архитектуры алгоритмами, совокупность которых позволяет решать задачи автоматизации.
- Приведение в соответствие параметров прикладной системы с информацией, которой обмениваются устройства нижнего уровня (например, программируемые логические контроллеры - ПЛК) с внешним миром (датчики технологических параметров, исполнительные устройства и др.)
- Отладка созданной прикладной программы в режиме эмуляции.
В последующих главах на примере двух известных и хорошо зарекомендовавших себя SCADA-систем (InTouch и Citect) рассмотрены основные компоненты, функции и возможности систем диспетчерского управления и сбора данных.
2.1.2. Основные сетевые топологии
Сетевая топология описывает способ (тип) сетевого объединения различных устройств. Существует несколько видов топологий, отличающихся друг от друга по трем основным критериям:
- режим доступа к сети;
- средства контроля передачи и восстановления данных;
- возможность изменения числа узлов сети.
Основные топологии - это звезда, кольцо и шина. Сравнение этих топологий представлено в табл. 2.2.
Таблица 2.2
Сравнительные характеристики основных топологий
| Сравнительные характе- ристики | Звезда | Кольцо | Шина |
| 1. Режим доступа | Доступ и управление через центральный узел | Децентрализованное управление. Доступ от узла к узлу | Возможен централизованный и децентрализованный доступ |
| 2. Надежность | Сбой центрального узла - сбой всей системы | Разрыв линии связи приводит к сбою всей сети | Ошибка одного узла не приводит к сбою всей сети |
| 3. Расширяемость | Ограничено числом физических портов на центральном узле | Возможно расширение числа узлов, но время ответа снижается | Возможно расширение числа узлов, но время ответа снижается |
Структура "звезда"
В данной топологии вся информация передается через некоторый центральный узел, так называемый обрабатывающий компьютер.
Каждое устройство имеет свою собственную среду соединения. Все периферийные станции могут обмениваться друг с другом только через центральный узел. Преимущество этой структуры в том, что никто другой не может влиять на среду передачи. Один собственник управляет и владеет ею.
С другой стороны, центральный узел должен быть исключительно надежным устройством как в смысле логического построения сети (отслеживание конфликтных ситуаций и сбоев), так и физического, поскольку каждое периферийное устройство имеет свой физический канал связи и, следовательно, все они должны обеспечивать одинаковые возможности доступа. Дополнительное устройство может быть включено в сеть только в том случае, если организован порт для его подсоединения к центральному узлу.
Структура "кольцо"
В кольцевой структуре информация передается от узла к узлу по физическому кольцу. Приемник копирует данные, регенерирует их вместе со своей квитанцией подтверждения следующему устройству в сети. Когда начальный передатчик получает свою собственную квитанцию, это означает, что его информация была корректно получена адресатом. В кольце не существует определенного централизованного контроля. Каждое устройство получает функции управляющего контроллера на строго определенный промежуток времени. Отказ в работе хотя бы одного узла приводит к нарушению работы кольца, а, следовательно, и к остановке всех передач. Чтобы этого избежать, необходимо включать в сеть автоматические переключатели, которые берут на себя инициативу, если данное устройство вышло из режима нормальной работы. То есть, они позволяют включать/выключать отдельные узлы без прерывания нормальной работы.
Структура "шина"
В любой шинной структуре все устройства подсоединены к общей среде передачи данных, или шине. В отличие от "кольца" адресат получает свой информационный пакет без посредников.
Процесс подключения дополнительных узлов к шине не требует аппаратных доработок со стороны уже работающих узлов сети, как это имеет место в случае топологии "звезда".
Однако шинная топология требует жесткой регламентации доступа к среде передачи. Существует два метода регулирования такого доступа, известного еще под термином "шинный арбитраж»;
- "фиксированный мастер" (централизованный контроль шины) - доступ к шине контролируется центральным мастер-узлом;
- "плавающий мастер" (децентрализованный контроль шины) - благодаря собственному интеллекту каждое устройство само определяет регламент доступа к шине.
Передача данных
Основными достоинствами промышленных сетей являются недорогие линии и надежность передачи данных. Данные передаются последовательно бит за битом, как правило, по одному физическому каналу (одному проводнику). Такой режим передачи не только экономит кабельное оборудование, но и позволяет решать задачи по надежной передаче данных на большие расстояния. Время передачи, однако, увеличивается пропорционально длине битовой строки.
Методы доступа к шине
Если несколько устройств коммутируются между собой через общую линию связи (шину), то должен быть определен ясный и понятный протокол доступа к ней.
Существуют два метода упорядоченного доступа: централизованный и децентрализованный.
В случае централизованного контроля за доступом к шине выделяется узел с правами Мастера. Он назначает и отслеживает порядок и время доступа к шине для всех других участников. Если вдруг Мастер "сломался", то и циклы обмена по шине останавливаются.
Именно по этой причине децентрализованный контроль с переходящими функциями мастера от одного участника (узла сети) к другому получил наибольшее внимание и развитие. Здесь права мастера назначаются группе устройств сети. Во всем мире широко приняты и используются две модели децентрализованного доступа:
- модель CSMA/CD (например, Ethernet) как стандарт IEEE 802-3;
- модель с передачей маркера как стандарт IEEE 802.4 (Token Passing Model).
Для совместной работы сетей типа CSMA/CD и Token Model необходим так называемый межсетевой шлюз.
Случайный метод доступа к шине (CSMA/CD)
Наиболее известным механизмом управления локальной сетью шинной конфигурации является метод множественного доступа с контролем несущей и обнаружением конфликтов (Carrier Sense Multiple Access with Collision Detection, CSMA/CD). Наиболее широко известная реализация этого метода - спецификация Ethernet.
Все станции на шине имеют право передавать данные. Каждая из них постоянно прослушивает шину. Если шина свободна, любой из участников сети может занять шину под свой цикл передач. В том случае, когда несколько станций претендуют на шину одновременно, это приводит к так называемому конфликту (коллизии), и тогда все "претенденты снимают свою заявку».
Затем каждый из участников включает некий случайный генератор, который задает случайный интервал ожидания до следующего момента запроса шины.
Метод CSMA/CD получил широкое распространение в офисных системах и наиболее эффективен в условиях относительно низкой общей загрузки канала (менее 30%). В условиях большей загрузки канала выгоднее использовать сети, реализующие модель с передачей маркера. Сравнительные характеристики различных сред передачи данных приведены в табл. 2.3.
Таблица 2.3
Сравнительные характеристики различных сред передачи данных
| Характеристики | Витая пара | Радиоканал | Коаксиальный кабель | Оптоволокно |
| Типовой диапазон | 1 - 1000 | 50 - 10000 | 10 - 10000 | 10-10000 |
| Типовая скорость передачи | 0,3 - 2000 | 1,2-9.6 | 300 - 10000 | 1 - 100000 |
| Относительная цена узла | $10-$30 | $50-$100 | $30 - $50 | $75 - $200 |
| Затраты на установку | Низкие | - | Средние | Средние- высокие |
Метод передачи маркера (The Token Passing Method)
В этом методе маркер, то есть право на доступ к шине, передается в цикле от устройства к устройству. Порядок передачи зависит от прикладной задачи и определяется на стадии планирования системы.
Этот метод предлагает каждому участнику сети "справедливое" разделение шинных ресурсов в соответствии с их запросами. Принцип передачи маркера используется в системах, где реакция на события, возникающие в распределенной системе, должна проявляться за определенное время.
Метод MASTER-SLA VE
Это решение находит свое применение как на контроллерном уровне (field level), так и на уровне датчиков и исполнительных механизмов (sensor/аctuator level). Право инициировать циклы чтения/записи на шине имеет только MASTER-узел. Он адресует каждого пассивного участника (SLAVE node), обеспечивает их данными и запрашивает у них данные. С тем чтобы увеличить пропускную способность шины, команды протокола должны быть как можно проще. В рамках протокола решаются такие задачи, как защита данных, обнаружение ошибок при передаче, восстановление данных. На скорость и объем передаваемой информации естественным образом влияет среда передачи.
Основные критерии выбора
Предпочтительность того или иного сетевого решения как средства транспортировки данных можно оценить по следующей группе критериев:
- объем передаваемых полезных данных;
- время передачи фиксированного объема данных;
- удовлетворение требованиям задач реального времени;
- максимальная длина шины;
- допустимое число узлов на шине;
- помехозащищенность;
- денежные затраты в расчете на узел.
Часто улучшение по одному параметру может привести к снижению качества по другому, то есть при выборе того или иного протокольного решения необходимо следовать принципу разумной достаточности. В зависимости от области применения весь спектр промышленных сетей можно разделить на два уровня:
- Field level (промышленные сети этого уровня решают задачи по управлению процессом производства, сбором и обработкой данных на уровне промышленных контроллеров);
- Sensor/actuator level (задачи сетей этого уровня сводятся к опросу датчиков и управлению работой разнообразных исполнительных механизмов).
Другими словами, необходимо различать промышленные сети для системного уровня (field busses) и датчикового уровня (sensor/actuator busses). Сравнение этих двух классов в самом общем виде можно получить по критериям из табл. 2.4.
Таблица 2.4
Сравнительные критерии промышленных сетей типов Fieldbus и Sensorbus
| Основные критерии | Fiеldbus | Sensorbus |
| 1. Расширение сети | от 100 м до 1 км | до 100 м |
| 2. Время цикла | от 10 мс до 10с | от 1 мс до 1 с |
| 3. Объем передаваемых данных за цикл | от 8 байт до нескольких сотен байт | от 1 до 8 байт |
| 4. Доступ к шине | фиксированный/свободный | свободный |
| 5. Цена среды передали | низкая | очень низкая |
Наши рекомендации |