В этой главе...
Созданная в RTWin СКУ построена по модульному принципу. Это позволяет разместить ее модули на разных узлах QNX сети для организации распределенной обработки данных. Все файлы, связанные с конфигурацией запуска проекта, расположены в директории
[путь_к_проекту]/[имя_проекта]/cfg.
Старт проекта осуществляется утилитой rtstart , которая находит список модулей для запуска в файле rtstart.cfg .
В случае распределенного проекта для каждого узла сети необходим файл с именем rtstart.cfg.[номер_узла], который определяет набор запускаемых на узле модулей проекта. В этом случае порядок запуска на узлах QNX сети описывается в файле nodes.start. Этот файл содержит список узлов, на которых надо запускать проект , в последовательности запуска. Список начинается с ключевого слова WORKNODES . Номера узлов разделены пробелами или запятыми.
Для организации межмодульных связей используется главный администратор passadm . Этот администратор необходим один на проект. При старте проекта passadm должен быть запущен первым. Если модули проекта будут располагаться на нескольких узлах сети, то первым должен загрузиться узел на котором будет находиться passadm .
Для реализации функций панелей управления используется администратор панелей управления cprun . Необходимо, чтобы на узле, где будет работать cprun перед стартом проекта был запущен Photon. Администратор панелей управления должен быть запущен на каждом узле сети, где будут размещаться панели управления и/или окно тревог.
Панели управления также могут быть размещены на различных узлах сети. Для каждого узла сети необходим файл с именем cpanel.cfg.[номер_узла] , который определяет набор используемых на узле панелей управления. Если такого файла нет и на данном узле предусмотрен запуск администратора панелей управления, то на данном узле доступны все панели управления проекта
RTWin позволяет размещать на различных узлах QNX сети как объекты и панели управления, так и системные администраторы. Как уже отмечалось выше, распределение модулей проекта по узлам сети задается с помощью файлов конфигурации с именами rtstart.cfg.[номер_узла] , расположенных в директории ./cfg проекта.
Каждый такой файл содержит список запускаемых на конкретном узле сети модулей в порядке их запуска. Кроме этого, файл конфигурации может содержать ссылку на директорию, в которой находятся утилиты и системные администраторы RTWin (ключевое слово BIN_PATH ).
Например, на 12-ом узле находится проект с именем Project. При запуске этого проекта необходимо разместить модули на 3-ем и 1-ом узлах сети. Для этого в директории ./cfg проекта необходимо наличие следующих файлов:
rtstart.cfg.3 |
rtstart.cfg.1 |
nodes.start |
Пример написания файла конфигурации запуска проекта для 3-го узла сети rtstart.cfg.3 :
BIN_PATH = //12/usr/rtw/bin
passadm ##главный администратор проекта
cprun ##администратор панелей управления
alrman ##администратор тревог
dbman ##администратор баз данных
Module1 ##объект1
Module2 ##объект2
Пример написания файла конфигурации запуска проекта для 1-го узла сети rtstart.cfg.1 :
BIN_PATH = //12/usr/rtw/bin
cprun ##администратор панелей управления
forman ##администратор форм
Module3 ##объект3
Module4 ##объект4
Пример написания файла nodes.start :
WORKNODES 3 1
Для старта проекта Project с любого узла сети необходимо выполнить команду :
rtstart -p Project -d //12/usr/rtw/apps
Как уже отмечалось выше, распределение панелей управления по узлам сети задается с помощью файлов конфигурации с именами cpanel.cfg.[номер_узла] , расположенных в директории ./cfg проекта.
Каждый такой файл содержит список доступных на конкретном узле сети панелей управления и флаги, соответствующие их начальному состоянию. Возможны 2 варианта начального состояния панелей управления :
1 - открыта при старте проекта
0 - закрыта при старте проекта.
Например, допустим, что в упомянутом выше проекте Project имеется описание трех панелей управления. Одна из них должна быть расположена на 3-ем узле, а остальные две - на 1-ом. Причем, в момент старта проекта панели управления на 1-ом узле должны быть закрыты.
Тогда, файл конфигурации панелей управления для 3-го узла сети cpanel.cfg.3 будет иметь вид :
Cpanel1 1
А файл cpanel.cfg.1 - вид :
Cpanel2 0
Cpanel3 0
Если удалить файл cpanel.cfg.1 , то при старте проекта Project на 1-ом узле будут открыты сразу все три панели управления одновременно. Тогда панель управления Cpanel1 будет одновременно отображаться на двух узлах сети. Это иллюстрирует еще одну возможность RTWin - дублирование панелей управления.
| На каждом узле , где необходимо отображение панелей управления , должен быть запущен администратор панелей управления cprun. |
RTWin позволяет отображать одновременно несколько панелей управления с одинаковыми именами . При этом все данные, передаваемые по каналам в панель управления, будут дублироваться на всех одноименных панелях управления . Действия, производимые операторами, будут поступать со всех одноименных панелей управления.
Для того чтобы продублировать панель управления на различных узлах сети, необходимо в файл конфигурации панелей управления для соответствующего узла cpanel.cfg.[номер_узла] включить имя нужной панели управления.
RTWin предоставляет возможность обмена данными между одновременно работающими различными проектами. Для описания совместной работы проектов вводится понятие метапроекта.
Метапроект позволяет объединить несколько проектов и описать связь между ними. Директорий метапроекта имеет ту же структуру, что и обычный проект.
Связь между проектами в составе одного метапроекта организована посредством модулей специального типа - шлюзов (см. пункт Шлюз главы Концепция RTWin книги rtstart , при этом файл rtstart.cfg должен содержать команды запуска всех проектов , входящих в метапроект , и администраторов связи rtgate .
Например, файл rtstart.cfg метапроекта Meta, включающего в себя два проекта Prj1 и Prj2, будет иметь следующий вид :
rtstart -p Prj1
rtstart -p Prj2
rtgate -m Meta -f relations
В этом примере relations - имя файла описания связей между проектами Prj1 и Prj2.
Один файл описывает связь только между 2-мя проектами. На текущий момент нет никакого интерактивного инструмента для создания файла описания связей .
Ниже приведен пример структуры файла описания связей :
PROJECT_1 prj1_name
INSTANCE_NAME_1 prj1_inst_name
PROJECT_2 prj2_name
INSTANCE_NAME_2 prj2_inst_name
LINKS
type prj1_point_name1 prj2_point_name1
. . .
type prj1_point_nameN prj2_point_nameN
END_LINKS
Здесь PROJECT_1 и PROJECT_2 ключевые слова, указывающие на следующие за ними имена связанных проектов, INSTANCE_NAME_1 и INSTANCE_NAME_2 ключевые слова, указывающие на уникальные имена копии проекта , LINKS и END_LINKS ключевые слова, ограничивающие блок описания связей.
Слово type может иметь два значения: INPUT и OUTPUT, - и указывает на тип шлюза (вход или выход) 1-го проекта , что определяет тип связи :
Слова prj1_name и prj2_name являются именами проектов, prj1_inst_name и prj2_inst_name уникальными именами копии проекта , prj1_point_name1 и prj1_point_nameN имена шлюзов 1-го проекта , prj2_point_name1 и prj2_point_nameN имена шлюзов 2-го проекта .
Пример написания файла:
PROJECT_1 Prj1 |Имя 1-го проекта
INSTANCE_NAME_1 i1 |Уникальное имя 1-го проекта
PROJECT_2 Prj2 |Имя 2-го проекта
INSTANCE_NAME_2 i2 |Уникальное имя 2-го проекта
LINKS |Блок описания связей
##Тип модуля связи |Имя модуля связи |Имя модуля связи
##1-го проекта |1-го проекта |2-го проекта
OUTPUT out_gate1 In_gate1
OUTPUT str_gate_out in_type_5
INPUT In_gate1 out_gate1
INPUT str_gate out_type_5
INPUT time time
END_LINKS |Конец блока описания связей