PROFIBUS ( PROcess FIeld BUS) – это классическая сеть с передачей маркера. Стандарт (DIN-19245) содержит 3 различных протокола: PROFIBUS-FMS, PROFIBUS-DP, PROFIBUS-PA.

PROFIBUS-FMS появился первым (1990 г.) и был рассчитан на цеховый уровень. Скорость обмена данными – до 1,5 Мбит/с.

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

- мастер класса 2 (может выполнять функции конфигурирования и диагностики устройств сети);

- мастер класса 1 (ПЛК с функциями ведущего узла);

- ведомые устройства (DP-Slave).

Скорость обмена – до 12 Мбит/с.

Протокол PROFIBUS-PA (1997 г.) является расширением PROFIBUS-DP для взрывоопасных сред. Скорость обмена – 31,25 кбит/с.

В Европе PROFIBUS покрывает ~ 40% рынка пром. сетей. Физическая среда – витая пара или оптоволоконный кабель. Количество узлов в сети – до 126. Топология – шина, звезда, кольцо.

Скажем несколько подробнее об PROFIBUS-DP.

Рис. 1

Логически потоки данных в такой сети делятся на три основных цикла.

1. Цикл ввода-вывода выполняется под управлением контроллера ведомого уз­ла. В этом цикле происходит автомати­ческий опрос модулей ввода, установ­ленных в УСО, и строится таблица последних значений, готовых к передаче в сеть. Одновременно с этим происхо­дит передача выходным модулям УСО новых значений, полученных из сети. Длительность этого цикла зависит от количества установленных модулей и, как правило, измеряется единицами миллисекунд.

2. Цикл сетевого обмена реализуется по инициативе ведущего узла, в дан­ном случае по маркеру мастер-карты рабочей станции. В этом цикле веду­щий формирует пакеты, содержащие данные для модулей вывода каждого из абонентов, и принимает от них пакеты, в которых передается информация от входных модулей. Пакеты оптимизи­рованы настолько, что на передачу данных отводится ровно столько места, сколько эти данные занимают. Напри­мер, передача аналогового сигнала за­нимает в сетевом пакете два байта, а передача дискретного — один бит. Служебная информация в пакетах пре­дельно мала, поэтому теоретическая пропускная способность сети умень­шается в основном только в связи с из­держками на передачу и обработку маркера, а также из-за того, что пара­метры передаются по сети независимо от того, изменилось их значение со времени предыдущего циклаопроса или нет. Цикл сетевого обмена осуще­ствляется без участия центрального процессора рабочей станции и начина­ется сразу после подачи напряжения питания на сетевую карту и сетевые УСО. Данные, которые передаются ве­домым абонентам, ведущий постоянно берет из определенного поля адресов специальной двухпортовой памяти. В эту же память после каждого цикла об­мена по сети помещаются новые зна­чения, полученные от каналов ввода. Для ускорения сетевого обмена данные в пакетах передаются подряд, без ука­зания их источника или, наоборот, ад­ресата. Для того чтобы ведущий «знал», какие из участков своей двухпортовой памяти пе­редать каждому из абонен­тов и, соответственно, ка­кую длину пакета ожидать в ответ и что это будет обо­значать, такая сеть изна­чально должна быть одно­кратно сконфигурирована с помощью специальной программы. В результате работы программа-конфи­гуратор настраивает веду­щего и ведомых участни­ков друг на друга и сохраняет информацию о параметрах сети в энергонезависимой памяти всех узлов. Такая дисциплина работы PROFIBUS-DP, конечно, не допускает «горячего» (на ходу) изменения числа участников сети и даже состава их модулей ввода-вывода, но зато обеспечивает высокую скорость обмена. Так, например, цикл обмена по сети, которая обслуживает 5000 дискретных сигналов и 1000 ана­логовых, может составлять менее 2 миллисекунд!

3. Цикл управления внутри рабочей станции. Эта работа возлагается на центральный процессор. Он работает с так называемым образом процес­са, который находится в двух­портовой памяти сетевой карты. Процессору требуется считать из памяти информа­цию о входных каналах, осу­ществить над ней необходи­мые преобразования и вы­дать управляющие воздейст­вия, занеся в определенные ячейки памяти новые дан­ные.

Такая конфигурация уп­равляющей системы по принципу работы и програм­мирования почти ничем не отличается от «вырожден­ной» централизованной сис­темы. Один и тот же процес­сор здесь отвечает и за управ­ление, и за интерфейс с опе­ратором. Преимущества, ко­торые мы смогли получить на данном этапе, — это осво­бождение процессора от за­дач ввода-вывода (обслужи­вание прерываний от АЦП, поддержка каналов DMA, не­обходимость работы с рези­дентными драйверами уст­ройств и т.п.), а также возможность максимально приблизить УСО к объекту контроля.

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

В этом случае (рис. 2) в сети при­сутствуют три типа устройств: один-единственный ведущий контроллер, одна или более рабочих стан­ций верх-

Рис. 2. Система с выделенным управляющим контроллером

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

Контроллер «видит» че­рез окно двухпортовой па­мяти мастер-карты каналы ввода-вывода удаленных УСО и область памяти slave-карты рабочей стан­ции. Программа, выполня­ющаяся в контроллере, пи­шется на любом процедур­ном языке программирова­ния общего назначения или на одном из языков стандарта IЕС 61131. С по­мощью специальных инст­рументальных средств (например, Ultralogik) она работает в режи­ме реального времени и осуществляет основной цикл управления.

Передавать в SCADA-систему желательно не все, а только то, что непосредственно должно быть вид­но оператору и сохраняться в архивах. Кроме SCADA-пакета, на рабочей станции должен быть установлен не­кий драйвер сети PROFIBUS-DP. Для современных пакетов могут использоваться соответствующие ОРС-серверы, поставляемые, например, фирмой Hilscher.

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

Рис. 3. Распределенное управление, локальные УСО

2. Распределенное управление

В этой модели (рис. 3) рабочая станция является ведущей в сети, а контроллеры — ведомыми. В качестве контроллеров могут выступать, напри­мер, процессорные платы MicroPC с сетевыми адаптерами Hilscher. Все уст­ройства ввода-вывода в данном случае являются локальными. Контроллеры, с одной стороны, выполняют ввод-вы­вод из локальных устройств, произво­дят необходимые расчеты, осуществля­ют управление исполнительными уст­ройствами, а с другой — публикуют все необходимые данные в сетевой плате PROFIBUS-DP (Slave). Ведущему (ра­бочей станции) остается собрать дан­ные с контроллеров, передать им необ­ходимые управляющие воздействия и организовать взаимодействие с опера­тором и архивом. Данная архитектура также является полностью детерминированной и под­держивающей «распределенный ин­теллект», но в силу ограничения прото­кола PROFIBUS-DP не позволяет ис­пользовать в циклах управления уда­ленные переменные от других кон­троллеров без участия SCADA-систе­мы. Это связано с тем, что в сети PROFIBUS-DP может быть только один ведущий.

Большой выбор аппаратных средств, оконечных устройств и программного обеспечения делает решения на базе PROFIBUS на сегодня одними из са­мых распространенных.

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

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

● Режим «Клиент - сервер». Данный режим имеет много общего с предыдущим и используется в системах с гибким распределением функций. Узел клиент запрашивает данные, а узел сервер их предоставляет. При этом клиент может запрашивать несколько узлов, а сервер – иметь несколько клиентов. Также функции клиента и сервера могут совмещаться на одном узле. Примером может послужить ЦПС Foundation Fieldbus.

● Режим «Подписка». В этом режиме узел, нуждающийся в регулярном поступлении какой - либо информации, подписывается на её получение от другого узла, после чего получает регулярные рассылки данных без дополнительных запросов. Режим имеет два варианта: в первом случае данные передаются циклически с определенным интервалом вне зависимости от динамики информации; во втором случае данные передаются только в случае их изменения. Данный режим также используется в сетях Foundation Fieldbus.

Практика применения ЦПС (цифровых пром. сетей) на производстве неизбежно приводит к тому, что на разных участках предприятия функционируют сети разных стандартов, использующих неодинаковые среды передачи данных и протоколы. Что делать в такой ситуации, какими средствами объединить эти суверенные острова в единую мощную информационную систему? Одним из возможных вариантов является применение конверторов протоколов PKV фирмы Hilscher.

Одним из наиболее интересных устройств данного типа являются конверторы протоколов ЦПС в среду Ethernet серии PKV 40.

Устройства PKV 40, с одной стороны, поддерживают такие основные протоколы ЦПС, как CANopen, DeviceNet, PROFIBUS-DP, ModBus-Plus, AS-интерфейс, а также стандартные последовательные шины RS_232/422/485. С другой стороны, доступ к данным осуществляется по протоколу TCP/IP, обеспечивая прозрачную интеграцию в любую систему верхнего уровня автоматизации. Кроме доступа посредством TCP/IP, PKV 40 обеспечивает пользователя целым рядом «продвинутых» функций. Приверженцы Интернет-технологий в автоматизации могут воспользоваться встроенным Web-сервером. Создание страниц в стандартном формате html осуществляется любым редактором, после чего они передаются по сети в память устройства. Дальнейший просмотр накопленных устройством PKV 40 данных осуществляется обычным Интернет-браузером, то есть практически с любого компьютера из любой точки земного шара. Поддержка языка Java позволяет реализовать произвольную предварительную обработку данных, а также требуемый для технологов и специалистов интерфейс.

Кроме того, PKV 40 может использоваться как самостоятельный ПЛК благодаря наличию процессора и предустановленной операционной системы ОС Windows CE. Большинство разработчиков уже в той или иной степени знакомы с этой ОС, которая за последние годы стала одним из стандартов дефакто в области встраиваемых систем.

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

Для конфигурирования PKV 40 необходимо только стандартное для изделий Hilscher программное обеспечение SyCon, что облегчает инженерам АСУ ТП ввод оборудования в эксплуатацию. Настройка, в том числе загрузка пользовательских программ, может осуществляться как удаленно через TCP/IP, так и на месте установки оборудования через последовательный интерфейс, которым снабжен каждый PKV 40.

9. Программное обеспечение АПК

9.1. Системное программное обеспечение

9.1.1 ПО управляющих вычислительных комплексов

Основные особенности операционных систем реального времени

Операционные системы общего назначения не предназначе­ны для решения задач реального времени. Они ориентированы в основном на рациональное распределение ресурсов ЭВМ между пользователями, а также между выполняемыми задачами.

В УВК используются специализированные операционные системы — операционные системы реального времени (ОС РВ). Они управляют событиями и распределяют ресурсы УВК. Прин­ципиальным требованием к ОС РВ является гарантированное время реакции на внешние события, происходящие на управляе­мом объекте. Время реакции не должно превышать критического (deadline) времени для этого события. Критическое время обслу­живания события зависит от специфики управляемого объекта и должно быть известно при создании системы управления.

Различают операционные системы жесткого (или детерми­нированного) и мягкого реального времени. Системы жесткого реального времени применяют для построения УВК, в которых задержка реакции недопустима, поскольку ведет к отказу систе­мы и может повлечь за собой катастрофические последствия. ОС мягкого реального времени используют при построении УВК, в которых задержка реакции не является отказом, однако может привести к потере качества, например к снижению производительности системы. В АСУТП используют, как правило, ОС же­сткого реального времени.

Рассмотрим основные особенности ОС РВ, отличающие их от ОС общего назначения.

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

Наиболее важными параметрами, характеризующими реак­тивность ОС, являются время задержки прерывания (interrupt latency) и время переключения контекста (context switching).

Время задержки прерывания t_ЗП— это интервал времени от момента посылки запроса на прерывание до выполнения первой команды программы обработки прерывания. Обычно это время оценивается для худшего случая (при наличии других прерыва­ний, занятости процессора и т.д.) и зависит от эффективности операционной системы и архитектуры процессора, связанной с обработкой прерываний.

Время переключения контекста t_ПК - это среднее время, которое система затрачивает на переключение между независимы­ми задачами:

где t_i, — время переключения i-й задачи;

n — число одновременно выполняемых задач.

Время t_ПК зависит от эффективности структуры данных уп­равления задачей, архитектуры процессора и набора инструкций.

Время t_ЗП и t_ПК составляет от единиц до десятков микросекунд.

Для оценки производительности ОС РВ разработаны различ­ные наборы тестов. Среди них — тесты BNCH для оценки произ­водительности отдельных компонентов и комплексные тесты, разработанные компанией AIM, для интегральных оценок.

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

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

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

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

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

Архитектура микроядра.Современные ОС РВ (QNX, OS-9, VxWorks, Lynx OS и др.) имеют микроядерную архитектуру. В ми­кроядро системы включаются только самые необходимые функ­ции, связанные с управлением памятью и процессами, обработ­кой прерываний и обработкой системных вызовов, сообщений, а драйверы, файловая система и другие функции вынесены из яд­ра. Размер микроядра современных ОС РВ составляет около 20 Кбайт. Операционные системы реального времени с микроядер­ной архитектурой обладают меньшим временем реакции на со­бытия. Время задержки прерывания в таких системах составляет порядка 10 мкс.

Модульный принцип. Масштабируемость.Операционные сис­темы реального времени строятся по модульному принципу. Функциональные компоненты ОС - ядро, система управления файлами, система ввода-вывода и др. - реализованы в виде неза­висимых модулей. Такие операционные системы являются мас­штабируемыми и расширяемыми системами. Исходя из требова­ний применения, можно создавать как миниатюрные встроен­ные системы, размещаемые в ПЗУ, так и крупномасштабные се­тевые многопользовательские системы. ОС РВ поддерживают развитые средства разработки и включения в систему дополни­тельных драйверов для нестандартных устройств ввода-вывода.

Аппаратная поддержка.ОС РВ работают на различных аппа­ратных платформах: Intel 386/486/Pentium, Motorola 680x0, Power PC, Siemens C16X и др., на которых строятся системы реального времени. ОС РВ с аппаратной платформой, на которой она ис­полняется, иногда называется целевой (target) системой. Потреб­ность в памяти для размещения ОС РВ (ядро, системные модули, драйверы и т.д.) составляет обычно около 20 Мбайт. Разработчи­ки ОС РВ стараются уменьшить размер системы. Важным свой­ством является возможность размещения ОС РВ и приложений в ПЗУ, что позволяет создавать компактные (в том числе встроен­ные в технологическое оборудование) системы без внешних на­копителей.

Работа в вычислительных сетях.Операционные системы ре­ального времени поддерживают работу во всех основных типах локальных сетей (Ethernet, Profibus, CAN, Token Ring и др.), кото­рые являются средствами взаимодействия УВК и промышленных контроллеров; имеют прозрачный (transparent) доступ к ресурсам любого узла сети; отвечают требованиям надежности и отказоус­тойчивости (fault-tolerance), в частности предоставляют пользо­вателю сетевую избыточность и возможность гибкой переконфи­гурации системы; содержат программные средства защиты ин­формации от несанкционированного доступа.

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

• удовлетворяют общепринятым международным стандартам и
соглашениям (прежде всего IEEE POSIX —Portable Operating System Interface for Computing Environments), что обеспечивает мобильность приложений;

• поддерживают стандартные протоколы, например TCP/IP, для создания сетевых конфигураций;

• имеют дружественный пользователю интерфейс общения (подобный пользовательскому интерфейсу для ОС общего назна­чения), основанный на стандартах X Windows, Motif и др.;

• осуществляют поддержку стандартных систем управления база­ми данных.

Средства разработки.Приложения реального времени — поль­зовательские программы, исполняемые в среде ОС РВ, — разра­батываются на инструментальном компьютере. Разработка и от­ладка приложений для ОС РВ осуществляется, как правило, в среде распространенных ОС общего назначения, например UNIX и MS Windows. Некоторые ОС РВ имеют «резидентные» средства разработки, исполняемые в среде самой ОС РВ.

Ниже рассмотрены операционные системы реального време­ни, которые наиболее широко используются в УВК СМ1820М.

Операционная система QNX.

Это одна из наиболее широко распространенных операционных систем реального времени (http://www.sdw.ru/qnx). Она насчитывает более полумиллиона применений, преимущественно в системах управления и сбора данных, работающих в реальном времени. На систему QNX ори­ентировано более 100 компаний, выпускающих аппаратные и программные средства для УВК. В отечественной промышленно­сти QNX используется чаще других ОС РВ. Благодаря архитектур­ным особенностям ОС QNX может применяться в составе как ав­тономных интеллектуальных промышленных контроллеров, так и мощных многопроцессорных (SMP - Symmetric Multiprocessor) вычислительных систем. Таким образом, обеспечивается возмож­ность построения распределенных иерархических систем управ­ления на единой программной платформе. Система QNX служит базовой программной средой для УВК CM 1820M.

Основными свойствами QNX являются:

• гарантированное время реакции системы, что отвечает требованиям применения в системах жесткого реального времени;

• работа в 32-разрядном режиме;

• архитектура микроядра;

• модульный принцип построения, что обеспечивает оптималь­ное использование реально необходимых ресурсов;

• поддержка процессоров ix86, PowerPC, MIPS;

• компактность, возможность размещения системы в ПЗУ (Flash,
ROM) для встраиваемых (embedded) применений;

• расширяемость (extensibility), достигаемая без снижения надеж­ности системы, поскольку включение новых модулей (драйве­ров и менеджеров ресурсов) не требует перестроения ядра;

• масштабируемость (scalability) под различные технические тре­бования — от встроенных до многопроцессорных систем;

• большое количество графических подсистем: графические при­ ложения можно создавать с помощью библиотечных функций, поставляемых с компилятором Watcom С;

• поддержка ряда систем управления базами данных (Watcom
SQL, dbVista, Faircom C-free и др.);

• соответствие файловой системы требованиям стандарта POSIX;

• поддержка сетевого протокола TCP/IP;

• уникальная сетевая технология FLEET [Fault-tolerance (отказоустойчивая). Load-balancing (регулирующая нагрузку), Efficient (эффективная), Extensible (расширяемая), Transparent (прозрач­ная)].

Операционная система QNX построена на основе принципа микроядра. Микроядро QNX очень компактно. В него включены только базовые функции операционной системы:

• управление планированием (диспетчеризацией) и взаимодейст­вием процессов;

• управление передачей сообщений между процессами.

Система в целом построена в виде совокупности независи­мых взаимодействующих компонентов. Микроядро дополняется менеджером процессов (Ргос), который создает процессы и уп­равляет процессами и памятью процессов, файловой системой (Fsys), менеджером устройств (Dev) и менеджером сети (Net). Эти системные компоненты размещаются вне пространства ядра.

Операционная система QNX реализует простой и эффектив­ный механизм межзадачного обмена информацией между одновре­менно работающими процессами. Основной принцип коммуни­каций в ОС QNX — обмен сообщениями. Его использование обеспечивает эффективную совместную работу процессов в сис­теме.

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

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

Операционная система QNX построена по сетевой техноло­гии FLEET. Рассмотрим особенности этой технологии.

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

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

Любой узел может выполнять роль моста между двумя раз­личными локальными сетями, соответствующими стандарту IEEE 802. Таким образом, пользователь может работать одновре­менно в нескольких сетях: Ethernet, Token Ring и FDDI. В случае если какая-либо из них будет перегружена или выйдет из строя, ОС QNX способна автоматически перенаправить информацию через другую доступную сеть, что обеспечивает отказоустойчи­вость сети в целом. Менеджер сети выбирает путь для передачи информации к удаленному узлу, если он не единственный.

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

Рассмотрим инструментальные средства разработки прило­жений. ОС QNX, которые, как отмечалось, широко используется для встраиваемых систем. Пакет Embedded Kit позволяет разместить ОС QNX и приложения пользователя в ПЗУ (Flash или ROM) раз­рабатываемого промышленного контроллера. Пакет поддержи­вает различные аппаратные платформы (Intel, Octagon, Ziatech и др.), архивацию данных или файлов в памяти, а также встраивае­мые файловые системы, которые обслуживают вызовы ввода-вы­вода стандарта POSIX.

Многие приложения используют для отображения контроли­руемого технологического процесса в реальном времени графи­ческий интерфейс. Средством разработки графического интер­фейса для ОС QNX является, например, пакет Photon Developers Toolkit. Пакет представляет собой встраиваемую графическую оболочку с поддержкой 2D- и 3D-графики, а также с возможнос­тью запуска графических приложений, написанных для X Window System. Пакет создает компактный код для встраиваемых прило­жений реального времени.

Пакет Photon Developers Toolkit содержит:

• библиотеку графических примитивов;

• набор графических стандартных компонентов;

• средства интерактивного проектирования графических прило­жений PhAB (Photon Application Builder), обеспечивающие со­здание и редактирование сложных графических объектов из на­бора стандартных, а также вновь созданных компонентов.

Для создания Интернет-приложений в среде ОС QNX имеет­ся пакет Voyager SDK (Software Development Kit), который содер­жит все инструменты, необходимые для разработки специализи­рованного Web-браузера. Браузер Voyager обеспечивает пользова­телю удаленный доступ к промышленному контроллеру.

Операционная система Linux.

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

Linux является 32-разрядной многозадачной и многопользо­вательской UNIX-подобной операционной системой, имеющей следующие основные свойства:

• соответствие стандарту POSIX, что позволяет переносить разра­ботанное для классических UNIX-систем программное обеспечение на Linux-системы;

• модульный принцип организации, что является безусловным
преимуществом перед так называемыми «монопольными» (pro­prietary) UNIX-системами;

• расширяемость и масштабируемость системы, что делает ее пригодной для использования как в простых промышленных контроллерах на базе 4386ЕХ-микропроцессора, так и в много­процессорных системах;

• предоставление всех возможностей, доступных через вычисли­тельную сеть, поскольку Linux поддерживает работу с локаль­ными промышленными сетями (например, Ethernet и Profibus) и обеспечивает доступ к удаленным УВК через сеть Интернет; сетевые технологии в Linux соответствуют концепции «клиент-сервер», реализуемой на основе протоколов TCP/IP;

• возможность работы на большинстве известных 32-разрядных процессорных платформ: Intel, IBM, Motorola и др. Перенос си­стемы на другую платформу требует адаптации небольшой аппаратно-зависимой части исходного кода ядра (это в основном драйверы устройств и загрузчики ядра). Доступность исходного кода операционной системы дает возможность ее оптимальной
настройки в конкретных случаях.

Усеченный вариант Linux занимает 2 Мбайта на жестком дис­ке и хорошо подходит для компактных встроенных приложений (обычно потребность таких приложений в ресурсах оперативной памяти — от 2 до 8 Мбайт).

Для поддержки режима реального времени в среде Linux раз­работаны специальные расширения KURT и UTIME, а также RTLinux.

Программный пакет KURT является системой «мягкого» ре­ального времени, имеет два режима работы - нормальный и ре­ального времени, оформлен в виде системного модуля Linux RTMod, который является планировщиком реального времени. Планирование процессов реального времени может осуществ­ляться по событиям или по таймеру.

При переключении в режим реального времени все обычные процессы в системе приостанавливаются до завершения процес­са реального времени. Планировщик RTMod выделяет каждому процессу реального времени интервал (квант) времени, равный 10 мс.

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

Расширение RTLinux реализовано в виде небольшого ядра, поддерживающего режим «жесткого» реального времени, под уп­равлением которого работает Linux [33]. Фактически ядро Linux становится ожидающей задачей в системе реального времени, которая выполняется только тогда, когда в очереди нет задач ре­ального времени. Процессы, выполняемые в среде Linux, не мо­гут при этом блокировать аппаратные прерывания и запрещать свою выгрузку из памяти.

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

Ядро реального времени в Linux является непрерываемым, но поскольку его программы очень малы, нет причин для больших задержек в обслуживании. Тестирование ядра на аппаратной платформе Pentium 120 показало, что интервал задержки плани­рования задач не превышает 20 мкс.

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

Продвижением Linux в промышленные системы управления заняты более 100 компаний. Расширение RTLinux применимо для многих задач реального времени; ОС Linux может быть ис­пользована в качестве программной платформы для УВК СМ1820М.

9.1.2. ОС Windows

Завершая разговор об операционных системах, нельзя не сказать об ОС Windows. В руководстве по эксплуатации АПК указывается вид ОС, под управлением которой он функционирует. Многие АПК работают под Windows. Эта ОС позволяет решать задачи ”мягкого” реального времени. Будучи системой общего назначения, Windows стоит гораздо дешевле ОС РВ. С ней связано множество информационных технологий компании Microsoft, реализованных в приложениях Windows. Есть примеры удачной адаптации Windows к задачам РВ. Так решения специалистов фирмы Venturcom стали фактическим стандартом для создания ответственных приложений жесткого реального времени на платформе Windows NT. Они пошли по пути модификации модуля Windows – слоя аппаратных абстракций HAL – Hardware Abstraction Layer. Этот модуль отвечает за выработку высокоприоритетных системных прерываний, мешающих задаче осуществлять управление в жестком РВ. Фирма поставляет программный продукт – Component Integrator – в качестве средства ускоренной разработки и внедрения приложений РВ под Windows. Пакет содержит инструментальные средства – ECK (Embedded Component Kit) и расширения РВ – RTX соответствующей версии.

Другой подход применила компания RadiSys. Windows загружается как низкоприоритетная задача под ОС РВ iRMX. Все функции обработки и управления РВ выполняются каквысокоприоритетные задачи под управлением iRMX. Они изолированы в памяти ПК от приложений и драйверов Windows механизмом защиты процессора. Задача РВ становится независимой от работы Windows.

9.2. Прикладное ПО

На рынке АПК существует большое количество программных продуктов класса SCADA/HMI. Они призваны автоматизировать процесс разработки приложений для отраслей промышленности. Нами уже был рассмотрен представитель класса – Advantech Studio. Назовем еще некоторые пакеты:

Genesis32 компании Iconics (США) – универсальный пакет для ИСУ любой сложности;

InTouch - Wonderware;

FIX – Intellution;

Trace Mode – AdAstra; Master SCADA - inSAT (Россия); и др.

Технология OPC-сервер

Технология связывания и внедрения объектов для систем промышленной автоматизации OPC (OLE for Process Control) предназначена для обеспечения универсального механизма обмена данными между датчиками, исполнительными механизмами, контроллерами, устройствами связи с объектом и системами представления технологической информации, оперативного диспетчерского управления, а также системами управления базами данных. Производители аппаратных средств, пользуясь спецификацией OPC, имеют возможность разрабатывать единственный сервер OPC для обеспечения единственного и наиболее общего способа организации доступа к данным и передачи в адрес приложений-клиентов различных производителей программного обеспечения для промышленной автоматизации.

OPC основана на модели распределенных компонентных объектов Microsoft DCOM и устанавливает требования к классам объектов доступа к данным и их специализированным (custom) интерфейсам для использования разработчиками клиентских и серверных приложений. Опираясь на объектную технологию COM/DCOM, стандарт OPC фиксирует определенную модель взаимодействия между клиентом и сервером.

Базовым понятием этой модели является элемент данных (Item). Каждый элемент данных имеет значение, время последнего обновления (time stamp) и признак качества, определяющий степень достоверности значения. Значение может быть практически любого скалярного типа – булево, целое, с плавающей точкой и т.п. – или строкой (так называемый OLE VARIANT). Время представляется с 100 наносекундной точностью (FILETIME Win32 API). Реальная точность измерения времени обычно бывает хуже и, в общем случая, зависит от реализации сервера и аппаратуры. Качество – это код, содержащий в себе грубую оценку – UNCERTAIN, GOOD и BAD (не определено, хорошее и плохое), а на случай плохой – еще и расшифровку, например QUAL_SENSOR_FAILURE – ошибка датчика.

Следующим вверх по иерархии является понятие группы элементов (OPC Group). Группа создается OPC сервером по требованию клиента, который затем может добавлять в группу элементы (Items). Для группы клиентом задается частота обновления данных, и все данные в группе сервер старается обновлять и передавать клиенту с заданной частотой. Отдельно стоящих вне группы элементов быть не может. Клиент может создать для себя на сервере несколько групп, различающихся требуемой частотой обновления. Для каждого клиента всегда создается своя группа (кроме так называемых публичных групп), даже если состав элементов и частоты обновления совпадают. Отсоединение клиента приводит к уничтожению группы.

Элементы в группе, таким образом, – это своего рода клиентские ссылки на некие реальные переменные (теги), находящиеся на сервере или в физическом устройстве. Понятие тега спецификацией OPC не определяется, но подразумевается неявно. Элементы в группу клиент добавляет по имени, и эти имена являются именами соответствующих тегов. Клиент может либо знать нужные имена заранее, либо запросить список имен тегов у сервера. Для запроса имен тегов служит интерфейс IOPC Browse Server Address Space, с помощью которого сервер описывает клиенту свое “пространство имен”, организованное в общем случае иерархически. Пример полного имени тега: Устройство1. Модуль5. АналоговыйВход3. При добавлении элемента в группу клиент всегда указывает это полное имя. Заметим, что группы, создаваемые клиентом, не обязаны совпадать (и, как правило, не совпадают) с подразделами пространства имен сервера, элементы в группу добавляются “в разнобой”. Единственное, что их объединяет – это общая частота обновления и синхронность отправки клиенту.

Наконец, на верхней ступеньке иерархии понятий находится сам OPC-сервер. Из всех перечисленных (OPC группа, OPC элемент) он единственный является COM-объектом, все остальные объекты доступны через его интерфейсы, которые он предоставляет клиенту. Взаимосвязь групп и элементов OPC

Рис. 2. Взаимосвязь групп и элементов OPC