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

За основу была взята 32/64-разрядная высокопроизводительная шина PCI, локальный интерфейс подсистемы В/В для надплатных расширений активной материнской платы, ставшая стандартом де- факто для современных ПК. Эта шина имеет массу достоинств: она не зависит от типа микропроцессора, может работать с самыми быст- рыми из них, имеет большую пропускную способность и аппарат ав- токонфигурирования устройств В/В. Сейчас PCI активно применяет- ся в VME-компьютерах для подключения периферии.

После доработки, в 1995 году, был выпущен стандарт CompactPCI, основанный на общепринятой технологии создания надежных промышленных модульных систем – пассивной объединительной ма- гистрали [5]. Большое практическое значение имеет тот факт, что любое ПО, работающее на настольных ПК, может быть без измене- ний перенесено в систему CompactPCI. А программисты, работающие на ПК, но не имеющие дела с аппаратурой, могут быстро скомпоно- вать систему CompactPCI, установить ОС и сконфигурировать систе- му в соответствии с реальными потребностями.

CompactPCI стал достойным конкурентом технологии VME. Од- нако CompactPCI – относительно новый стандарт, и некоторые необ- ходимые функции в нем либо отсутствуют (горячая замена), либо не доведены до кондиций. Кроме того, номенклатура продуктов CompactPCI пока небольшая, особенно в сравнении с рынком VME/ISA- оборудования. Поэтому сейчас следует ориентироваться на связку двух стандартов, используя CompactPCI как недорогую объедини- тельную панель с высокой скоростью передачи данных.

4.5. Мезонинные технологии

Мезонинные технологии применяются достаточно давно: в се- редине 80-х не было способа запаивать на основной плате кристаллы памяти емкостью более 64 Кбайт, и для увеличения ее объема ис- пользовались мезонинные модули. Сейчас, когда степень интеграции микросхем гораздо выше, на одной плате размещается простой ком- пьютер со всеми соответствующими электронными атрибутами, и еще остается место. Мезонинные технологии приобрели новый смысл

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

www.pdffactory.com

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

Таким образом, мезонинные платы представляют еще один, бо- лее низкий по сравнению, например, с модулями VMEbus уровень модульности. Типичный размер мезонинных плат 50×80 мм. Они яв-

ляются функционально законченными изделиями и устанавливаются на плату-носитель (в стандарте VMEbus, ISAbus или каком-либо дру- гом). Стандартные установочные габариты платы при этом не меня- ются – мезонины устанавливаются поверх нее. Носитель может быть пассивным или содержать собственный процессор. Так самый, пожа- луй, популярный в мире одноплатный компьютер/контроллер MVME162 кроме обычных аксессуаров (CPU MC68040, Ethernet, SCSI, DRAM, RTC, 2xRS232, Flash-диск, EPROM, VME64) имеет пор-

ты для установки 4 мезонинных плат. Это позволяет дополнить плату компьютера, например, 192 каналами цифрового ввода/вывода, спец- процессорами TMS32040, графикой, любой сетью.

Существует широкая номенклатура мезонинных плат: многока- нальные ЦАП, АЦП, цифровой ввод/вывод, EEPROM/FLASH, SRAM, графические контроллеры, различные типы сетей, интерфейс PCMCIA и т. д. Хотя до сих пор довольно активно применяются част- ные мезонинные интерфейсы, особенно широко распространено не-

сколько стандартов: PCI Mezzanine Card (PMC), IndustryPack (IP) и ModPack.

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

4.6. Полевые системы

Рассмотренные архитектурные решения относятся к локальному (центральный процессор и локальная шина) и региональному (VMEbus) уровню организации систем промышленной автоматизации. В условиях реального производства необходимо еще наладить взаимо- действие центрального управляющего блока с пространственно рас- пределенным оборудованием системы автоматизации – датчиками, исполнительными механизмами, передаточными устройствами, при- водами и программируемыми контроллерами.

Такую связь можно было бы реализовать, например, с помощью сети Ethernet, но к промышленным сетям предъявляются особые тре-

www.pdffactory.com

бования по надежности и помехоустойчивости. Для связи с удален-

ными цифровыми устройствами промышленного назначения принято использовать бит-последовательные промышленные или полевые шины (bit serial Fieldbus). К этой группе относятся несколько евро-

пейских (PROFIBUS (DIN 19245), FIP (UTE-C46-6xx), Bitbus (IEEE

1118), CAN (ISO/DIS 11898), Interbus-S (DIN 9258)) и американских

(Foundation, HART) конкурирующих стандартов. Ведется разработка общеевропейского стандарта EN 50170, объединяющего PROFIBUS и FIP.

Каковы основные возможности лидера – PROFIBUS? Это от- крытый стандарт, определяющий обмен информацией с компонента- ми автоматизации любых разновидностей – ПЛК, ПК, панелями опе- ратора, датчиками и силовыми приводами. Существует три основных варианта PROFIBUS: FMS, DP и ISP.

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

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

альное устройство обеспечивается в коммуникационной модели PROFIBUS интерфейсом прикладного уровня. Для этого объекты коммуникации PROFIBUS-станции вводятся в ее локальный словарь объектов – OD. Конфигурация OD может определяться и загружаться в устройство либо его производителем, либо разработчиком или мо- жет формироваться динамически. OD содержит структуру и типы всех объектов, а также их внутренние адреса в устройстве и пред- ставление на шине (индекс/имя). Доступ к объектам при функциони- ровании происходит через сервисные функции протокола PROFIBUS-

www.pdffactory.com

FMS, которые позволяют, например, опросить/установить значения переменных и массивов, запустить/остановить программу.

Что касается двух других вариантов стандарта, то PROFIBUS- DP – это оптимизированная по производительности версия PROFIBUS, предназначенная специально для взаимодействий, кри- тичных по времени. PROFIBUS-ISP – проект взаимодействующих частей, базируется на технологии PROFIBUS и дополняет ее возмож- ностями управления процессами, включая внутреннюю защиту.

4.7. Программное обеспечение промышленных систем

Как показала практика, стоимость создания систем промышлен-

ной автоматизации определяется в основном затратами на разработку ПО, доля которого может доходить до 60%.

Чем располагает разработчик промышленной системы? В пер- вую очередь это операционные системы, поддерживающие функцио- нирование разрабатываемого приложения. В сфере промышленной автоматизации свой мир операционных систем – ОС реального вре- мени (ОС РВ). Для VME-процессоров, например, существует 17 ОС

(OS-9/OS-9000, VRTX/Spectra, VxWorks, PDOS, pSOS+, LynxOS, VMEexec, iRMX, C-Exec, QNX и т. д.). Поскольку крупные компании-

производители обеспечивают для своих процессоров и устройств ввода/вывода полную поддержку сразу нескольких ОС РВ, можно найти версии систем из приведенного списка для многих платформ: 68000, PowerPC, ix86, Pentium.

ОС РВ характеризуется прежде всего малым временем реакции на внешние события. Так, гарантированное время реакции системы на процессоре MC68040/25 МГц под управлением операционной сис- темы OS-9 v3.0/Atomic составляет 3 мкс. Как правило, это многополь- зовательские многозадачные ОС, выполненные по технологии микро- ядра. Последние версии ОС имеют прерываемое микроядро, что га- рантирует быструю реакцию на внешнее событие при любом состоя- нии системы. Особенность большинства ОС – возможность стопро- центного размещения в памяти ядра, сетевого и графического обес- печения, драйверов и прикладных программ. Для встроенных бездис- ковых систем это чрезвычайно важно.

Традиционно ОС РВ делятся на "жесткие" и "мягкие". Система "жесткого" РВ должна без сбоев отвечать на внешние события в рам- ках заранее определенного интервала времени. Время ответа должно

www.pdffactory.com

быть предсказуемым и не зависеть от текущего состояния системы. "Мягкая" ОС РВ тоже должна отвечать очень быстро, но гарантиро- ванное время ответа в ней не обеспечивается. Здесь нужно отметить,

что временные характеристики последних версий промышленных ОС практически стерли ранее существовавшую грань между двумя этими разновидностями. Сейчас OS-9, ранее считавшаяся "мягкой" ОС, практически не уступает классическим "жестким" ОС - pSOS+ и

VxWorks.

Все большее распространение в сфере промышленной автомати- зации получают ОС общего назначения: Unix в разных реализациях, NT, OS/2, VMS. Для этого есть несколько причин. В различные реали- зации Unix стали включаться ядра реального времени, и это движение поддержано открытыми стандартами. В POSIX стандартизованы, на- пример, диспетчеризация и синхронизация процессов, нити, тайм- ауты, управление прерываниями. Во-вторых, трудно устоять перед мощной экспансией ПК, особенно после выхода Windows NT [13], и рабочих станций. Третья причина состоит в наличии на платформах

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

Действительно, кроме базовой поддержки, предоставляемой ОС РВ, для создания приложений разработчику требуется развитый ин- струментарий, которого, конечно, больше в общецелевых системах. Нельзя сказать, что ОС РВ в этом отношении бедны – в них обычно поддерживаются сетевые протоколы, X Window, Motif, но конкуриро- вать на равных им все же тяжело, особенно с новейшими инструмен- тальными технологиями. С другой стороны, все ОС РВ имеют собст-

венные среды разработки (FasTrack, Microtec, MasterWorks), чьи воз-

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

Конечно, можно создать ПО системы автоматизации, опираясь только на общецелевые средства, однако цена такой разработки будет

www.pdffactory.com

очень высока. Системы автоматизации – это такая же прикладная об- ласть, как, например, графика или САПР, и кроме универсального здесь нужен специализированный инструментарий.

Специализированные средства разработки. Реакцией на небла-

гополучное состояние дел в этой сфере явилось то, что в мае 1995 го- да VITA инициировала проектирование стандарта на унифицирован- ную программную среду встраиваемых систем (ESSE). Необходи- мость в таком стандарте назрела давно, поскольку его отсутствие привело к кризису в разработке встраиваемых систем: и пользователи и производители много времени тратят на инсталляцию драйверов, переписывание программ и разработку новых инструментальных ин- терфейсов для каждой встраиваемой системы. Первоначально иссле- дования намечались по трем направлениям: инструментальные сред- ства, прикладные пользовательские интерфейсы ОС (OSAPI) и драй- веры В/В. В апреле 1996 года была образована еще и новая группа по двоичному интерфейсу встраиваемых приложений (EABI). Что же имеется на сегодняшний день кроме проектов?

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

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

томатизации для этого традиционно применяются более простые и дешевые устройства – программируемые логические контроллеры. В первом поколении ПЛК представляли собой релейные схемы, выра- батывающие сигналы для оборудования по правилам булевой логики. Сегодня они стали более интеллектуальными: например, устройства типа Smart I/O имеют конфигурацию, в которой центральный процес- сор на базе дешевого микропроцессора MC68302, последовательные порты и DC/DC-преобразователь собраны в одном компактном про- мышленном кожухе. Модульная структура Smart I/O позволяет гибко изменять конфигурацию, сокращать и наращивать число каналов вво- да/вывода за счет широкой номенклатуры производимых модулей.

Программирование ПЛК может осуществляться двумя способа- ми. В качестве инструментальной системы можно использовать мощ- ные системы разработки типа Dev Pak для OS-9 или кросс-системы,

имеющиеся практически на любых современных компьютерных платформах: Unibridge (Unix), PCbridge (PC), FasTrack (Unix, DOS,

www.pdffactory.com

Windows). В составе этих систем поставляется большое количество драйверов ввода/вывода, и прикладное ПО для ПЛК становится мо- бильным. Все вроде бы хорошо, однако, во-первых, мобильность ог- раничена рамками одной инструментальной системы, и, во-вторых,

программирование ПЛК таким способом нетрадиционно и в общем неадекватно: требуется знание ОС и языков программирования.

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

Стандарт IEC 1131-3 [10] описывает два графических языка, "Диаграмма цепей" (LD) и "Диаграмма функциональных блоков" (FBD). В этих языках стандартные символы обеспечивают прямое со-

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

–это программные объекты, реализующие функции управления.

Вдополнение к графическим языкам LD и FBD стандарт IEC 1131-3 определяет язык "Схем последовательных функций" (SFC). Этот язык уже ближе к традиционному программированию и предна- значен для записи алгоритмов последовательного управления. Эле- менты этого языка – шаги, переходы и блоки – используются для оп- ределения порядка операций, написанных на любом языке стандарта.

ВIEC 1131-3 определяются также два текстовых языка: "Список команд" (IL) и "Структурированный текст" (ST). IL – это язык низкого

www.pdffactory.com

уровня, в то время как ST поддерживает структурное программирова- ние.

В стандарте специфицированы механизмы, посредством кото-

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

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

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

Все языки, включенные в стандарт IEC 1131-3, можно комбини- ровать, а также включать в программу фрагменты на традиционных языках. Полная реализация IEC 1131-3 доступна как коммерческий продукт: например, это ISaGRAF для Windows производства фирмы CJ International. При использовании в сочетании с OS-9 ядро ISaGRAF выполняется как пользовательская задача и принимает управ- ление загруженным в ПЛК приложением. Высокую оценку специали- стов по прмышленной автоматизации получил, также пакет IOWorks

(VMIC).

Будущее стандарта IEC 1131-3 связывается со стандартизацией форматов программных файлов, что обеспечит возможность обмена

пакетами функциональных блоков между различными платформами и позволит реально перейти к модульному программированию – соз- данию больших систем из готовых пакетов. Второе направление раз- вития – использование в распределенных управляющих системах функциональных блоков за пределами программируемых контролле- ров. С этой целью был создан стандарт IEC TC65/WG6, в котором концепции IEC 1131-3 применены к стандарту Fieldbus и который оп- ределяет, каким образом средства связи могут объединяться с при- кладным ПО.

Инструментарий ПО для мониторинга и управления. На уровне ПО мониторинга и управления (SCADA) существенное место занима- ет интерфейс человек-компьютер (MMI). Процесс разработки прило- жений SCADA обычно делится на две части. Первая включает проек- тирование и реализацию аппаратуры и ее логики, обычно генерируе-

www.pdffactory.com

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

Между тем абстракции управления, которые вводит стандарт IEC 1131, позволяют скомбинировать обе части в единый процесс, если переменные из программ логического управления сделать дос- тупными из ПО SCADA и наоборот. Примерами интеграции редакто- ров программ ПЛК в стандарте IEC 1131 с ПО разработки интерфейса пользователя могут служить система WizPLC (PC Soft Int. + Smart Software Solutions) и надстройка компании Ci Technologies над паке-

том логического программирования IEC 1131-3 ISaGRAF. Рассмотрим более подробно пакет InTouch (Wonderware, США)

[2], который был признан лучшим инструментальным средством для разработки SCADA-систем на выставке-ярмарке в Ганновере. InTouch реализован для среды Windows NT: управление окнами, работа со шрифтами, механизм межзадачного интерфейса (DDE) – все это ба- зируется на штатных средствах API Windows, что создает привычную для пользователей ПК обстановку.

Основная задача, которую решает InTouch, – разработка графи- ческого интерфейса к переменным (текстовым, дискретным, действи- тельным и целым). Переменные определяет разработчик, и они могут быть двух категорий: DDE (для связи с внешними объектами) либо Memory (внутренние). Кроме значения, переменная имеет набор ат- рибутов: наличие предупредительного сообщения, вызванного выхо- дом значения за границы установок, признак квитированности этого сообщения, групповая принадлежность переменной, комментарий и т. д. Переменную типа DDE можно связать с данными, поступающи- ми от внешних устройств, либо с объектами других пакетов, напри- мер ячейкой Excel.

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

этом плане графический образ соответствует диалоговым панелям Windows. Между переменной и графическим образом устанавливают-

www.pdffactory.com