libuniset2 — библиотека для создания АСУ. Лучше один раз увидеть…Часть 2 (Запуск имитатора)

В предыдущей статье я закончил на создании и конфигурировании имитатора… Продолжим…

Запуск имитатора

С запуском с одной стороны всё просто, а с другой стороны есть некоторая магия. Она вполне объяснима, если «много знать» :)
Но поскольку целью статей и примеров является показать простоту создания и функционирования систем с использованием libuniset2, то я не буду вдаваться очень глубоко в детали. Но общий принцип всё-таки придётся описать (хотя частично он был изложен ещё в той первой статье).
Чтобы процессы (uniset-объекты) могли взаимодействовать между собой, они обладают уникальным (в рамках проекта) идентификатором, но этого мало :) Чтобы они могли получать от SharedMemory уведомления, чтобы можно было работать отладочным утилитам с этими объектами и т.п., им необходимо как-то о себе заявить. Для этого служит репозиторий. Вообще это всё уходит «корнями» в технологию CORBA. В данном случае в libuniset2 для этого используется реализация репозитория (службы имён) omniNames, входящая в libomniORB (реализацию CORBA от AT&T).
И ещё одна особенность локальной наладки, о которой следует упомянуть. Т.к. над одним проектом (на одном сервере) может трудиться много разработчиков, и каждый хочет запускать свой экземпляр SharedMemory, процессов, необходимо как-то разделять их всех между собой. Для этого все экземпляры процессов запускаются на разных портах. А как гарантировать уникальность порта для каждого user-а? В libuniset мы пошли следующим путём: запускаем процессы на порту равном USERID+50000, чтобы сдвинуть всё это в область «относительно надёжно» не пересекающуюся ни с кем. И всё это актуально только при локальной наладке. Т.к. в реальной системе (на контроллере) процессы уже будут запущены в единственном экземпляре.
Вся эта отладочная обвязка скрыта в нескольких поставляемых с пакетом libuniset2-utils утилитах uniset2-start.sh и uniset2-stop.sh. Поэтому для того, чтобы запустить имитатор (и никому не мешать) надо запускать его с использованием uniset2-start.sh. А чтобы каждый раз не писать строку с ключами, в каталоге Imitator создан файлик start_fg.sh вот с таким содержимым:

	#!/bin/sh
	uniset2-start.sh -f ./imitator

Параметр -f — означает запустить программу в foreground.
Утилита uniset2-start.sh при запуске как раз подставляет необходимые параметры (--uniset-port xxx) для сдвига порта.
Помимо этого она стартует службу имён (репозиторий) если он ещё не запущен. Во время работы (отладки) достаточно запустить службу имён (omniNames) один раз. Хотя видимо стоит немного надо об этом рассказать..

Репозиторий

Репозиторий это «программа», выполняющая функции аналогичные DNS-серверу. Вообще это служба имён для объектов CORBA. Если по-простому, то каждый объект регистрируется в репозитории, публикует под своим (уникальным) именем CORBA-ссылку на себя. После этого все, кому необходимо обратиться к этому объекту, запрашивают у репозитория ссылку по имени и дальше уже работают с этой ссылкой. В целом служба имён в CORBA это более сложная тема (из них как и из DNS можно строить иерархии и конгломераты) и т. п. В нашем применении всё проще. Запускается omniNames (это собственно и есть программа репозиторий). Запускается она на определённом порту. Репозиторий запускается один на все текущие uniset-проекты, и они друг другу не мешают, т.к. каждый проект создаёт в нём свою иерархию объектов, начиная с корня, который называется как проект, а точнее задаётся в configure.xml параметром RootSection="..". В реальном проекте можно обойтись и без репозитория, но удалённое обращение к объекту будет недоступно.

Специфика запуска uniset-проекта в том, что «один раз» структуру репозитория для проекта… нужно создать. А для этого служит ещё одна специальная (многофункциональная) утилита — uniset2-admin
Мы ещё будем пользоваться этой утилитой и для других целей, но сейчас нам надо создать репозиторий.
Полная команда для этого выглядит так:

uniset2-start.sh uniset2-admin --confile configure.xml --create

Но для облегчения этого процесса, в исходниках есть каталог src/Services/Administator и там сделаны «ссылки-команды» для быстрого запуска. Там есть и команда «create». Запустим её и если всё хорошо, то мы не увидим никаких ошибок

	[pv@pvbook Administrator]$ ./create
	[pv@pvbook Administrator]$ 

Есть одна деталь, скрипты рассчитаны на то, что вы войдёте в каталог src/Services/Administator и там запустите create(просто в них файл configure.xml ищется в текущем каталоге).
Для проверки что репозиторий создан, можно (нужно) запустить там же команду «./exist» и увидеть следующее

[pv@pvbook Administrator]$ ./exist 

||=======********  UNISET-EXAMPLE/Services  ********=========||

пусто!!!!!!

||=======********  UNISET-EXAMPLE/Controllers  ********=========||

пусто!!!!!!

||=======********  UNISET-EXAMPLE/Objects  ********=========||

пусто!!!!!!
[pv@pvbook Administrator]$ 

Как видно из вывода, uniset создаёт в репозитории три секции Services, Controllers, Objects. На самом деле четыре, четвёртая это sensors, но её здесь не видно, с ней мы поработаем позже :)

Запуск SharedMemory

Прежде чем мы запустим имитатор, надо запустить «хранилище» — SharedMemory. Репозиторий мы уже создали, так что просто переходим в каталог src/SharedMemory/ и запускаем там start_fg.sh после чего должны увидеть на экране

	[pv@pvbook SharedMemory]$ ./start_fg.sh
SharedMemory1(sysCommand): wait activate...
************************** activate: 1 msec

Чтобы убедиться что SM доступна для работы, перейдём (в другой консоли) в каталог src/Services/Administrator и запустим ./exist. Мы должны увидеть:

[pv@pvbook Administrator]$ ./exist

||=======********  UNISET-EXAMPLE/Services  ********=========||

пусто!!!!!!

||=======********  UNISET-EXAMPLE/Controllers  ********=========||

(22000 )SharedMemory1                                             <--- exist ok

||=======********  UNISET-EXAMPLE/Objects  ********=========||

пусто!!!!!!

[pv@pvbook Administrator]$

Значит всё ok.

Запуск имитатора

Наконец-то запускаем имитатор. Как можно уже догадаться, переходим в каталог src/Algorithms/Imitator и запускаем ./start_fg.sh

  [pv@pvbook Imitator]$ ./start_fg.sh
04/03/2016 01:24:32(  info):  Imitator1(waitSM): waiting SM ready 60000 msec testID=101
04/03/2016 01:24:33(level8):  Imitator1(resetMsg): reset messages..

Чтобы убедиться что имитатор уже работает… перейдём (в другой консоли) в каталог src/Services/Administrator и запустим ./exist

[pv@pvbook Administrator]$ ./exist

||=======********  UNISET-EXAMPLE/Services  ********=========||

пусто!!!!!!

||=======********  UNISET-EXAMPLE/Controllers  ********=========||

(22000 )SharedMemory1                                             <--- exist ok

||=======********  UNISET-EXAMPLE/Objects  ********=========||

(20001 )Imitator1                                                 <--- exist ok
[pv@pvbook Administrator]$ 

Итак у нас уже запущено SM и Imitator. Этого достаточно чтобы начать отладку работы имитатора и на этом примере посмотреть какие инструменты для этого есть. Но всё-таки, прежде чем я опишу наладку, мы создадим наш главный процесс управления...в следующей части...

Для тех кого заинтересовало:

• Проект libuniset2 на github
• Исходники примера
• Багзилла проекта

Автор: PavelVainerman

Источник