SWD Software Ltd. - официальный дистрибьютор QNX на территории России и стран бывшего СССР Операционная система реального времени QNX
Инструменты для создания надёжных встраиваемых систем и
интеллектуальных устройств любой сложности
QNX Software Systems - разработчик встраиваемой операционной системы QNX
Информационные брошюры
Статьи и публикации
Обзоры
Операционные системы
Графические интерфейсы
Средства разработки
Прикладные системы на базе ОС QNX
Разное
Конкурсные статьи
Техническая литература
Материалы конференций QNX-Россия
Полезные ссылки
Блог QNX
Главная страница > Материалы > Статьи и публикации > Конкурсные статьи > Применение операционной системы реального времени QNX для автоматизации систем контроля и управления в области научных и прикладных исследований Сделать страницу стартовой Послать ссылку коллеге Версия для печати

Применение операционной системы реального времени QNX для автоматизации систем контроля и управления в области научных и прикладных исследований

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

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

Итак, перейдем к рассмотрению конкретных примеров из физики твердого тела и нейтронной физики. Данные исследования проводятся на пучках нейтронов реактора ВВР-М Петербургского Института Ядерной Физики РАН. ПИЯФ РАН является Государственным Научным Центром России. Он был основан в 1959 как филиал известного Физико-Технического института и действует как самостоятельная организация с 1971 года со своим исследовательским реактором ВВР-М и протонным синхротроном как основными приборами для фундаментальных и прикладных исследований. В настоящее время в Институте более 600 научных сотрудников и 1000 инженеров. Вы можете найти более подробную информацию на нашем Интернет-сервере http://www.pnpi.spb.ru. Вся работа, результаты которой изложены ниже, была сделана одним программистом (И.Д.) в течение 1 года. Он и расскажет о своей работе.

С ОС реального времени QNX я начал работать с 1996 года и за короткий срок удалось разработать и внедрить две системы контроля и управления. Первая система получила название DEUTON и применяется в области ядерной (нейтронной) физики, вторая - REFLECTOMETER используется для исследований в физике твердого тела. В обеих системах есть много общего, так как в обоих случаях речь идет о регистрации и анализе ионозирующих излучений (гамма-квантов и нейтронов), но есть и отличия.

Несколько слов о причинах выбора ОСРВ QNX. Распределенная система DEUTON первоначально была реализована в среде MS DOS. Распределенность означает, что СКУ работает одновременно на нескольких компьютерах, связанных одноранговой локальной сетью. Основным средством разработки был пакет Borland C++ 3.1. Для разработки интерфейса использовались редактор графического интерфейса UIEdit и библиотеки LabWindows фирмы National Instruments. Для обеспечения многозадачности - библиотека ADAinC, которая позволяет применить механизмы задач и обработки исключений, определенные в языке ADA, в программе, написанной на C. Разработка заняла много времени из-за ошибок в библиотеках и компиляторе, плохой совместимости разного программного обеспечения (ПО), используемого в проекте, ограничений по использованию ОЗУ и в результате модифицирование и расширение системы стало невозможным. После этого начался поиск ПО, которое позволило бы избежать этих трудностей. ПО по нашему мнению должно было удовлетворять следующим требованиям:

- работать на PC совместимых компьютерах, основной парк техники в институте составляют именно они;

- способность работать на слабых компьютерах, поскольку часть машин представлена 286 и 386 компьютерами с небольшим объемом ОЗУ (до 4 Mb);

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

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

- быстрой реакцией на внешние события (прерывания), в экспериментах есть характерные времена порядка миллисекунд;

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

- развитым графическими средствами, опять же, дабы избавить программиста от необходимости писать всю графику самому;

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

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

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

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



Рис.1.Главное окно СКУ DEUTON.

Выбор пал на ОСРВ QNX с графическим интерфесом Photon, компилятором WATCOM C и основным средством разработки Application Builder. Все компоненты, кроме компилятора, разработаны фирмой QNX Software Systems, поэтому о совместимости средств разработки и среды исполнения беспокоится нет нужды. Дальнейшая работа с этими продуктами показала правильность выбора.

Система DEUTON предназначена для получения спектральных характеристик гамма-излучения, возникающего при взаимодействии пучка нейтронов с водородной мишенью. Гамма-излучение регистрируется двумя комплектами детекторов по восемь детекторов в каждом. Сигналы от каждого детектора обрабатываются собственным спектрометрическим прибором, который состоит из аналогового усилителя и АЦП, результат сохраняется в памяти. Каждый спектрометр выполнен в виде VXI модуля. Спектрометры собраны в двух конструктивах (крейтах) VXI по восемь в каждом. Приборы в крейтах управляются встроенными контроллерами фирмы Radisys Co. (Epc-7 и Epc-2), которые представляют из себя PC-совместимые компьютеры специального исполнения, имеющие доступ к шине VXI. В остальном это компьютер с набором обычных компонент - 486/ 20 MHz/ 8Mb RAM/100 Mb HD/Floppy 1.44, VGA/ COM1/ LPT1/ Ethernet NE2000.

Для работы каждого детектора необходимо высокое напряжение (1-2кВ), которое вырабатывается программно-управляемыми источниками, выполненными в стандарте CAMAC. Сигналы с детекторов, помимо спектрометров подаются также на счетчики собранные в модулях CAMAC. В системе еще есть неуправляемые модули VXI и CAMAC, служащие для общей синхронизации и развязки различных сигналов. Модули в стандарте CAMAC собраны в трех крейтах, которые управляются 286 компьютером через адаптер ISA-CAMAC. Адаптер произведен в ПИЯФ и позволяет управлять с одного слота ISA четырьмя крейтами CAMAC.

Таким образом, система включает в себя 4 компьютера объединенные сетью Ethernet: 2 VXI контроллера , 286 компьютер с адаптером ISA-CAMAC и консоль, с которой осуществляется общее управление системой. Все модули VXI и большая часть модулей CAMAC разработаны и изготовлены в ПИЯФ.



Рис.2. Окно настройки спектрометрического канала СКУ DEUTON.

Методика эксперимента заключается в том, что с помощью магнитного поля изменяются условия взаимодействия нейтронов с водородом. Ожидается, что спектры гамма-квантов, полученные в разных условиях, будут различны. Эта разница и представляет интерес. Чтобы получить эти спектры, память в каждом спектрометре разбита на 2 банка. Магнитное поле имеет два состояния и изменяется раз в 1 секунду, при этом спектры, соответствующие разным секундам, сохраняются в разных банках. Банки памяти переключаются аппаратно с помощью сигнала, отражающего состояние магнитного поля. Этот же сигнал используется для общей синхронизации системы. На время переходных процессов, после изменения магнитного поля, импульсом длительностью 80 ms аппаратно запрещается работа всех АЦП. Измерения проводятся сериями, серия состоит из четного количества секунд и начинается всегда с положительной секунды. Длительность серии зависит от стабильности усилителей и составляет около 20 секунд.

Каждый спектрометрический канал имеет память (VXI shared memory) 8192 24-х разрядных слова и 14 управляемых параметров. Это усиления, пороги, управление работой АЦП, высокое напряжение и тому подобное, так что общее количество параметров больше двухсот. Shared memory термин VME, означает что память доступна из модуля и с шины VME или VXI. Параметры можно поделить на статические, которые изменяются оператором, и динамические - изменяются программой при автономной работе.



Рис. 3. Блок-схема программного обеспечения СКУ DEUTON.

В задачу программной части системы входит обеспечение настройки спектрометрических каналов и автоматическая работа в режиме сбора данных с визуализацией процесса набора. Интерфейс программы выполнен в виде двух главных окон, первое отображает всю систему в целом, второе - отдельный спектрометрический канал (рисунки 1 и 2 соответственно). Окно канала открывается при нажатии кнопки Module # в главном окне. Настройка канала связана с длительной операцией - набором спектра, поэтому обеспечена возможность настраивать все каналы одновременно, для чего можно открыть все окна каналов и работать со всеми каналами параллельно. Параметры настройки доступны при нажатии соответствующих кнопок через дополнительные окна. Режим измерений включается кнопкой AllADCs в главном окне. В этом режиме программно запрещается изменение параметров настройки и через окна каналов можно только наблюдать процесс набора данных, что можно делать во всех каналах одновременно. Программа состоит из нескольких процессов (программных модулей):

- Interface - процесс реализует общее отображение и управление системой;

- Main - управляет измерениями, то есть накоплением и сохранением данных (основная задача системы). После запуска, в случае сбоя в системе, может работать автономно;

- Read_memory - процесс буфер, получает от процесса Sync информацию о наличии прерывания и передает ее процессу Interface;

- Sync - процесс владелец прерывания, после прерывания передает информацию о нем процессам Main и Read_memory;

- Voltage - управляет источниками высокого напряжения;

- VXI.driver - реализует доступ к шине VXI;

- CAMAC.driver - реализует доступ к шине CAMAC;

Распределение процессов по компьютерам (узлам в терминологии QNX) и их взаимодействие показано на блок-схеме рис.3. Стрелками отмечены направления вызовов. Процессы на Epc-7 и Epc-2 одинаковы.

Для разработки СКУ использовались разнообразные возможности организации исполнения многопроцессных или многозадачных приложений ОС реального времени QNX. Процессы в ОСРВ QNX - это программные модули, которые исполняются параллельно. ОС QNX предлагает широкий набор средств для обмена информацией между процессами. Это механизм синхронизованного обмена с помощью функций Send, Receive, Reply и их различных модификаций. Обмен синхронизован, так как процесс выполняющий одну из этих функций, блокируется до тех пор, пока процесс-оппонент не будет готов ответить. Процессы разблокируются после выполнения всех связанных с обменом процедур. При этом способе обмена возможна передача сообщений как в прямом, так и обратном направлении. Объем сообщений не ограничен. В системе DEUTON есть сообщения объемом 32 kb. Mеханизм proxy используется, когда процесс-источник не ждет подтверждения от процесса-приемника. Кроме этого, есть механизм передачи сигналов, стандартный для всех UNIX систем. Общее всех этих механизмов заключается в том, что для их использования процесс-источник должен знать ProcessID, это номер, под которым процесс-приемник зарегистрирован в системе. Один из способов его получения будет описан ниже. Главное состоит в том, что процесс-источник и процесс-приемник могут находится на разных узлах, связанных сетью любой архитектуры (Ethernet, Arcnet и т.д.), тем не менее ОС обеспечит передачу сообщения также, как если бы они находились на одном узле. Далее это будет проиллюстрировано.

Из блок-схемы видно, что с шинами могут работать несколько процессов. Может произойти вытеснение процесса, работающего с шиной, другим процессом, также требующим работы с шиной. В результате будут установлены неверные параметры или получены неверные данные. Чтобы избежать этого, используется процесс-владелец (драйвер) шины (разделяемого ресурса). Работа с ресурсом выполняется только через драйвер. Он имеет самый высокий приоритет и всегда готов обслужить другие процессы. Пока драйвер обслуживает какой-либо процесс, остальные ждут своей очереди . Таким образом исключаются ошибки использования разделяемого ресурса. Вторая задача драйвера заключается в следующем. Никакой процесс не может обратится к "железу", находящемуся на другом узле, напрямую. Процесс-драйвер этого "железа" доступен любому процессу с любого узла. Таким образом, любой ресурс имеющий драйвер, становится общим для системы.

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

WORD data[8192];

struct

{

WORD Call;

LWORD Address;

WORD Size;

WORD Value;

} msg_receive;

void main(void)

{

pid_t pid;

qnx_name_attach(0,"VXI/driver");

for(;;)

{

pid=Receive(0,&msg_receive,sizeof(msg_receive));

.............................................

.............................................

Reply(pid,data,sizeof(data));

}

}

Процесс, требующий доступа к ресурсу, получает ProcessID, используя системную функцию qnx_name_locate:

pid_t pid_VXI_driver;

WORD data[8192];

struct

{

WORD Call;

LWORD Address;

WORD Size;

WORD Value;

} msg_send;

void main(void)

{

pid_VXI_driver=qnx_name_locate(0,"VXI/driver",0,NULL);

..........................................................

..........................................................

А затем при необходимости посылает сообщение драйверу в заранее оговоренной

форме:

msg_send.Call=2; // Read module memory

msg_send.Address=0x12<<16;

msg_send.Size=8192;

msg_send.Value=0;

Send(pid_VXI_driver,&msg_send,data,sizeof(msg_send),sizeof(data));

..................................................................

..................................................................

}

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

Вернемся к блок-схеме. Синхроимпульс, связанный с состоянием магнитного поля, заведен на RS232 контроллеров VXI на линию RI. Изменение состояния этой линии вызывает прерывание, которое получает процесс Sync. Далее с помощью функции Creceive процесс Sync освобождает процессы Main и Read_memory, если они ожидают от него ответа. Если ожидающих процессов нет, информация о прерывании сбрасывается (функция Creceive не блокирует процесс Sync), так как изменение параметров в режиме измерений можно выполнить только в течение мертвого времени (80 ms). Под мертвым здесь подразумевается время на которое аппаратно запрещается работа АЦП для исключения влияния на измерения переходных процессов. Использовать для синхронизации механизм proxy нельзя, потому что в этом случае прерывания будут накапливаться и процессы будут получать устаревшую информацию о состоянии системы. Код процесса Sync приведен ниже:

pid_t proxy;

//The hardware interrupt handler COM1

#pragma off(check_stack);

pid_t far int_handler(void)

{

inp(0x3fe);

return (proxy);

}

#pragma on(check_stack);

void main(int argc,char *argv[])

{

pid_t pid_Main;

pid_t pid_Read_memory;

qnx_name_attach(0,"DEUTON/Sync");

.....................................................................................................

.....................................................................................................

//Устанавливает обработчик прерывания

proxy=qnx_proxy_attach(0,0,0,-1);

qnx_hint_attach(4,&int_handler,FP_SEG(&proxy));

qnx_hint_mask(4,1);

while(1)

{

//Ждет прерывания

Receive(proxy,0,0);

//Первым обслуживается процесс выполняющий измерения

if(Creceive(pid_Main,NULL,0)!=-1)

Reply(pid_Main,NULL,0);

if(Creceive(pid_Read_memory,NULL,0)!=-1)

Reply(pid_Read_memory,NULL,0);

}

}

Процесс Read_memory служит только для визуализации. Чтобы визуализация происходила не в произвольный момент времени, а была синхронизована с состоянием системы, процесс Read_memory получает информацию о прерывании от процесса Sync и передает ее процессу Interface, который сам через драйвер VXI считывает память спектрометров и отображает спектры в открытых окнах каналов. Если окна закрыты, ничего считываться и отображаться не будет.

Главную задачу - управление накоплением и сохранение полученных данных выполняют процессы Main. Один из них ведущий, другой ведомый. После нажатия кнопки AllADCs в главном окне, оба процесса устанавливают необходимые параметры в спектрометрах и очищают их память. Затем ведущий посылает ведомому сообщение о готовности, после чего с приходом синхроимпульса они оба включают все АЦП. По следующим синхроимпульсам отсчитывается заданный временной интервал, по окончании которого АЦП выключаются, данные считываются и сохраняются в одном файле. Файл может быть создан на любом накопителе в сети. Если кнопка AllADCs не была отжата, все повторяется. Очень важно, чтобы включение или выключение АЦП происходило только в течение 80 ms после прихода синхроимпульса (мертвое время), в противном случае данные будут искажены и их придется выбросить. С учетом большой стоимости работ на нейтронном канале финансовые потери будут очень велики. Объем сырых данных, полученных за одну серию, составляет 512 kb. При сохранении данные сжимаются (не архивируются!) в 4 раза без потери содержательной информации. При серии 20 секунд общий объем информации за час работы превышает 20Mb. Система же должна работать непрерывно сутками.

СКУ REFLECTOMETER предназначена для структурных исследований материалов. Пучок нейтронов под малым углом падает на поверхность исследуемого материала, отражается и попадает на 20-ти канальный детектор нейтронов. Детектор с усилителем, пороговым устройством и счетчиком образуют счетный канал. В отличии от системы DEUTON, где важны спектральные характеристики излучения, здесь нас интересуют интегральные данные - количество попавших на детектор частиц. Распределение счетов по каналам позволяет судить о структуре вещества.

Рис.4. Главное окно СКУ REFLECTOMETER.

В системе можно выделить две подсистемы. Первая - подсистема движения, служит для позиционирования пучка нейтронов на поверхности образца и перемещения детекторов. Она имеет 8 осей перемещения. Схематическое изображение механической части отображено в главном окне программы рис. 4. Перемещения по осям выполняются с помощью шаговых двигателей. Контролируется движение позиционно-чувствительными датчиками с высокой точностью. Модули управления шаговыми двигателями и обработки данных от датчиков перемещений выполнены в стандарте CAMAC и помещаются в одном крейте.

Вторая подсистема - 20-ти канальный позиционно-чувствительный детектор, выполнена в стандарте VME. Счетчики собраны по 4 в модуле. Для настройки счетных каналов в каждом модуле есть один АЦП и память объемом 4096 16-разрядных слов (8kb) . Так как АЦП один на каждые четыре канала, каналы в одном модуле можно настраивать только последовательно, а не одновременно как в системе DEUTON. Все модули VME собраны в одном крейте. Окно программы, позволяющее производить настройку каналов приведено на рис. 5. Все модули и адаптеры системы разработаны и изготовлены в ПИЯФ.

С точки зрения вычислительных средств СКУ состоит из двух компьютеров. Один управляет работой крейтов через адаптеры ISA-CAMAC и ISA-VME, возможно использование 286 компьютера. Второй служит в качестве консоли, выполняет отображение и управление системой.

Программа, управляющая работой системы, проще чем в СКУ DEUTON. При ее разработке использовались те же подходы, что и в предыдущем примере. В частности, в СКУ REFLECTOMETER, используется без изменений драйвер CAMAC, разработанный для СКУ DEUTON. Блок-схема программного обеспечения системы REFLECTOMETER приведена на рис. 6. Процессы входящие в эту программу имеют следующее назначение:

- Interface, служит для отображения и общего управления системой;

- Motion, считывает информацию с модулей датчиков перемещений и передает ее процессу Interface;

- Counters, управляет работой счетных каналов;

- драйверы VME и CAMAC обеспечивают доступ к инструментальным шинам.



Рис.5. Окно настройки порога счетного канала СКУ REFLECTOMETER.

Отличия СКУ REFLECTOMETER от ранее описанной состоят в том, что в этой системе нет сигнала общей синхронизации, что осложняет планирование работы процессов. Кроме того, модули обработки данных от датчиков перемещения не позволяют работать с использованием прерываний. Для отслеживания перемещений процесс Motion, вынужден заниматься последовательным опросом модулей постоянно, так как перемещения могут быть не только управляемые СКУ, но и от внешнего по отношению к ней воздействия. Это существенно загружает ОС и процессор на котором этот процесс работает, чего при использовании прерываний удалось бы избежать. Чтобы облегчить процесс Motion, управление шаговыми двигателями выполнено в процессе Interface.

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

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



Рис. 6. Блок-схема программного обеспечения СКУ REFLECTOMETER.

Опыт проделанной работы показывает, что набор базовых средств операционной системы реального времени QNX, Photon, Watcom C и Application Builder позволяет достаточно быстро и эффективно решать задачи, связанные с автоматизацией. Еще раз подчеркну очень важное достоинство перечисленных средств - это интегрированные средства. При их использовании не возникает проблем совместимости между ними. Нет необходимости "бороться" с ОС или средствами разработки. Под этим подразумевается ситуация, когда правильно написанная с точки зрения норм языка и использования системных вызовов программа работает неправильно или плохо. Для решения этих проблем приходится "искривлять" или "гнуть" программный код так, чтобы обойти это место. При разработке СКУ DEUTON под MS DOS, "борьба" заняла половину времени разработки. С увеличением объема написанного кода сопротивление возрастало, так что под конец стало ясно, что дальше будет только "борьба" без продуктивной работы. Особенно неприятно, что это становится понятно только под конец, когда уже затрачено много сил и средств на разработку.

Работа в ОС QNX позволила обойтись без этих проблем. Программное обеспечение обеих СКУ было написано одним программистом в течение года, с учетом времени потребовавшегося на постановку задач и при этом не видно ограничений для дальнейшего развития этих систем. В качестве примеров такого развития можно привести два предложения. Первое - добавить в СКУ DEUTON динамическое управление усилением спектрометрических каналов для стабилизации. Сложность здесь заключается в том, что о коэффициенте усиления можно судить только по форме спектра. Для этого программа должна считывать все спектры раз в 2 секунды, рассчитывать по ним усиление каналов и изменять параметры усилителей в мертвое время (время переходных процессов 80 ms), чтобы скомпенсировать дрейф. Делать это нужно не потому, что усилители плохие, а потому что измерения выполняются с очень большой точностью. Второе - осуществление видеоконтроля в обеих СКУ, что является по нашему мнению необходимым компонентом во многих системах автоматизации . Это возможно потребует привлечения дополнительных вычислительных мощностей в связи с большим объемом вычислений при обработке видеоинформации, но в ОС QNX это не представляет проблемы.

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

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

О производительности или эффективности ОС говорит размер системного кода. Фирма Microsoft при написании ОС вероятно исходит из предположения о бесконечности ресурсов. Но если теоретически можно предположить существование бесконечного по объему ОЗУ, способного вместить бесконечный код Microsoft, то бесконечный по производительности процессор не может приснится даже во сне. Так что бесконечный код будет исполнятся бесконечно. А если говорить серьезно, то объем ОС QNX со всеми средствами разработки и визуализации всего 33 Mb. После Windows это может показаться фантастикой, но это так.

Сильный аргумент в пользу QNX - это возможность работать в условиях ограниченных ресурсов. Так, в системе DEUTON используется 286 компьютер с ОЗУ 1 Mb для управления тремя крейтами CAMAC. Это возможно благодаря модульности и масштабируемости ОС. Эти термины означают следующее. ОС QNX состоит из процессов (программных модулей). Каждый из процессов реализует тот или иной системный сервис. Это может быть поддержка файловой системы, поддержка работы терминала, драйверы различных накопителей, драйверы сети, драйверы портов ввода вывода и так далее. Причем дробление системных функций довольно сильное. Например, поддержка жесткого диска и дисководов выполняется разными процессами. Обязательными процессами для ОС являются только ядро системы и процесс менеджер с системной библиотекой. Их общий объем не превышает 300 kb. Все остальные процессы могут запускаться или удалятся во время работы ОС. Это напоминает игру в детский конструктор. Нужно работать с дисководом - добавим соответствующий драйвер, нужна мышь - добавим драйвер последовательного порта, не хватает памяти -удалим какой нибудь ненужный в данный момент процесс.

Используя модульность и масштабируемость, можно набрать только те детали конструктора, которые необходимы нам в данном конкретном случае. В системе DEUTON 286 компьютер используется по существу как голый процессор, необходимо только иметь к нему доступ через сеть. Поэтому на нем запускаются только обязательные процессы для ОС, о которых говорилось выше, и процессы, поддерживающие работу сети. После этого еще остается более 500 kb ОЗУ. Для ОС QNX это совсем не мало. Для сравнения, в системе REFLECTOMETER объем драйвера CAMAC всего 7 kb, драйвер VME 18 kb. Сказанное выше не стоит воспринимать как признание в крайней нищете. На самом деле речь идет о применении ОС QNX во встроенных системах. Это могут быть контроллеры MicroPC или PC104, находящие широкое применение в промышленности и на транспорте. Как правило, такие контроллеры имеют процессор 386EX с портами ввода-вывода и ОЗУ до 1 Mb. Наличие последовательного порта делает возможным объединение этих устройств в распределенную систему на базе ОС QNX со всеми описанными выше удобствами.

Немаловажным вопросом является отладка. Не все ОС реального времени располагают полноценными средствами отладки или эти средства очень дороги. Например, FasTrak для OS 9 или OS 9000 стоит несколько тысяч долларов. Отладка же распределенных систем может доставить сильную головную боль. В среде QNX есть полноценный, многооконный отладчик Wvideo фирмы Watcom, который поставляется вместе с Watcom C. Отдельных денег платить не надо. У него правда, есть недостаток - основным средством общения с ним является командная строка, но это всего лишь небольшое неудобство. Возможности же его в сочетании с возможностями ОС при отладке распределенных систем трудно переоценить. Уже говорилось, что ОС QNX это распределенная ОС. Это позволяет с одного рабочего места запустить несколько сессий отладки и отлаживать удаленные процессы так же как и локальные. При этом процессы могут взаимодействовать друг с другом. Но это еще не все. Распределенность и многозадачность ОС позволяют все процессы программы запустить на одном компьютере, несмотря на то, что в жизни они должны работать на разных. Программа будет работать точно также, ничего менять в ней не нужно. Просто при ее разработке нужно такую возможность учесть. К примеру, программное обеспечение системы DEUTON с помощью ключей командной строки можно запустить как в локальном варианте, так и в распределенном. Отсюда вывод: распределенную систему можно разрабатывать и отлаживать на одном компьютере. Так и делалось при разработке описанных в статье систем.

Показать преимущества данной ОС и средств разработки без сравнения со аналогичными средствами на других программных платформах невозможно. Операционных систем реального времени довольно много, перечисление только одних названий этих ОС займет много места. Стоимость таких ОС, как правило, высока, и мы, естественно, не могли познакомится со многими из них. Возможно, VxWorks хорошая система, но мы не можем ее использовать, так как ее стоимость - 30000$ превышает наши финансовые возможности. Это тоже аргумент при выборе программной платформы. Другая крайность - использование "бесплатных" или "дешевых" продуктов фирмы Microsoft. Это MS DOS, Windows 95, Windows NT с набором средств той же Microsoft - Visual C++, SDK, DDK, MFC и так далее.

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

Существуют средства, предназначенные для автоматизации с использованием ОС Windows 95 или NT от других производителей, например National Instruments или Wonderware. Но эти средства дешевыми не назовешь. Полный комплект разработки от Wonderware стоит десятки тысяч долларов США. Продукты National Instruments ненамного дешевле. И при этом остаются все те же проблемы с ОС от Microsoft. Средство разработки CVI/LabWindows фирмы National Instruments инструмент того же типа, что и Application Builder фирмы QSSL. В CVI/LabWindows используется та же методология построения приложений, но несмотря на казалось бы большее количество "заготовок" (кнопки, ручки и так далее), в итоге инструментарий CVI беднее, потому что возможности модифицировать "заготовки" намного меньше, чем в Application Builder. Кроме того, Application Builder позволяет разрабатывать собственные "заготовки". Надо сказать, что и код National Instruments не оптимален. К примеру, для вывода графиков на экран с использованием Graph Controls все выводимые данные приводятся к одному типу - с плавающей точкой двойной точности. Конечно, этот подход будет работать всегда, но эффективность такого подхода вызывает сомнения. При выводе ста точек это незаметно, а вывод десяти тысяч может надолго озадачить даже Pentium.

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

При выборе программной платформы, надо также учитывать наличие региональной поддержки дистрибьютора. Если книжки "Как писать под Microsoft" пишут все кому не лень, то найти литературу о работе в профессиональной среде разработки тяжело. Я лично не встречал. В этих условиях отсутствие региональной поддержки может стать серьезной помехой в работе. При выборе QNX мы учитывали, что есть региональный представитель - фирма SWD и неоднократно прибегали к помощи специалистов этой фирмы, что позволяло оперативно решать возникавшие проблемы.

Все вышесказанное об ОС QNX смахивает на большую бочку меда. Естественно, в эту бочку надо положить хоть маленькую ложку дегтя. Перейдем к недостаткам. На мой взгляд, к ним можно отнести несколько аспектов. Первый - отсутствие в ОС поддержки потоков, что не позволяет использовать многозадачность внутри процессов. Это лишает возможности параллельно работающим задачам использовать общие переменные в рамках одного процесса. Второй - нет механизма обмена содержательными сообщениями без подтверждения, то есть процесс-источник, пославший сообщение, не должен был бы блокироваться. Это позволило бы проще проектировать системы, отдельные части которых могли бы продолжать работать самостоятельно при нарушении работы общей системы. Механизм proxy для этого не годится, так как при срабатывании proxy никакой содержательной информации, кроме самого факта срабатывания, не передается. Третий аспект - вызовы одним процессом другого безымянны. То есть, адресуется вызов к процессу, а не к конкретному месту в нем. Не хватает механизма поименованных вызовов, характерного для механизма задач языка ADA. И последний, наверное, самый важный, аспект - отсутствие поддержки процессоров других типов. В частности, хотелось бы иметь ОС QNX на процессорах Motorola, наиболее естественных в архитектуре VME, ставшей стандартом de facto в промышленности. К счастью, эти недостатки лишь несколько затрудняют работу, но не делают ее бессмысленой.

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

А. Баженов, И. Дьяков
Петербургский Институт Ядерной Физики РАН
Отдел Автоматизации экспериментов на реакторах
тел (812) 294-9149
E-mail: bazhenov@pnpi.spb.su

Рассказать друзьям:

Rambler's Top100           Рейтинг@Mail.ru