Об интерфейсах объектов системы управления в Uni Set

Далее изложение предполагает наличие у читателя представления о том, как была организована работа с сообщениями, датчиками и выходными сигналами в последней версии Uni Set (применённой в Имитаторе), где был опробован отказ от вкомпилированных числовых идентификаторов.
Просьба сторонним читателям не особо беспокоиться по поводу данного текста.

Основные положения

Объекты и интерфейсы

Объект регистрируется в репозитории с уникальным именем и только после этого может взаимодействовать с другими объектами.
Активный объект представлен классом (в С++) и имеет свойства, которые хранятся в конф. файле проекта и определяют тип интерфейса объекта.
Существует ряд базовых типов интерфейса:(Uni Set Object?, Objects Manager?, IONotifyController, для каждого из которых определён набор допустимых над ним операций.

• Uni Set Object? позволяет ему посылать сообщения
• Objects Manager? свойства Uni Set Object? + позволяет через него посылать сообщения подчинённым ему объектам, гарантируя доставку
• IONotifyController позволяет узнавать значения входов и управлять выходами

Названия типов, хранящиеся в конф. файле, соответствуют названию классов в С++.
Для каждого активного объекта на основе конф. файла генерируется базовый класс, который наследован от одного из базовых классов, в зависимости от типа его интерфейса. Класс записывается в отдельный файл и содержит в секции protected переменные состояния датчиков и идентификаторы датчиков. Для этого класса формируется функция, отвечающая за обновление переменных с состояниями датчиков. Также указывается название объекта (уникальное для данного узла). В конструкторе класса происходит получение необходимых идентификаторов.

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

Текстовое название объекта

На перспективу:
Полный путь объекта имеет вид
\\узел\Корень\Вид объекта\Устройство\Название объекта на устройстве
(допустимы любые символы в названии, кроме \0, \\ и '.'
Этот путь является полностью уникальных в пределах системы.
Локальный путь к объекту имеет вид
\Корень\Вид объекта\Название объекта
Для разных узлов сети адрес может повторяться.
Название объекта может повторяться для различных видов объектов.

Требует обсуждения, нужно ли что-то кодировать в названии объекта

Числовой код объекта

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

В использовании констант, обозначающих код объекта, необходимости не найдено.

Способы обмена информацией между объектами

• Получение сообщения о состоянии (датчика)
• Передача извещения (сообщения с командой)
• Установка выходного значения

Надо дополнить

Основные предлагаемые изменения

Далее будут приведено подробное обоснование предлагаемых изменений, сделанное на основании обсуждений ситуации 13.07.2005 и 14.07.2005.
Изменения ставят целью создание простого, завершённого интерфейса для написания алгоритмов управления, а также графических интерфейсов и процессов ввода-вывода.
Все допустимые взаимодействия между объектами должно быть жёстко указано, не должно быть возможно несанкционированное вмешательство в объект из кода, к нему не относящегося. Это относится к удалённому вызову функций, удалённому изменению состояния датчиков.
При написании/проектировании интерфейсов следует предусматривать разделение на уровни – интерфейс, предоставляемый пользователю и интерфейс, нужный самой системе.

Отмена функций askState/askValue

Поскольку информация о заказываемых датчиков для надёжности перенесена в конф. файл, необходимости заказывать датчики напрямую в приложении нет. Чтобы сделать API стройным, функция заказа датчиков упраздняется.
2pv: Чтобы собрать сведения, что заказывает объект, нужно просмотреть весь конф. файл?

Функции saveState/Value

Это способ управления состоянием фиктивных входных датчиков? Такой способ применяться не должен.
saveState НЕ должен быть доступен снаружи объекта.
Функция сохранения состояния не должна быть использована вне процесса, владеющего объектом, для которого меняется состояние. Поэтому из Universal Interface? она должна быть вынесена. ?

Упразднение разделения датчиков на виды

Исторически сложилось, что введены понятия аналоговых (принимающих значение в определённом диапазоне) и дискретных (имеющих два состояния – 1 и 0) датчиков. Для каждого вида датчиков реализован свой набор функций.

• Предлагается упразднить разделение аналоговых и цифровых датчиков/выходов при обращении с ним. Для двоичных по природе датчиков состояние 0 будет кодироваться значением 0, состояние 1 – ненулевым значением.
• В сообщениях поле state будет упразднено (при желании можно сделать совмещение полей state и value)
• Предлагется ввести код состояния датчика (или кодировать его состояние в value). Это позволит узнавать об обрыве/замыкании датчика.

Соответственно функции семейства *State упраздняются.

Отмена функций getState/Value

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

Поэтому предлагается функцию для прямого получения состояния (значения) отменить. Информация об изменении значений будет доставляться заказанными извещениями о изменении состояния датчиков. Для хранения информации о состоянии в класс вводятся локальные переменные, значение которых заполняется специальной функцией, действующей перед обычным вызовом processingMessage, таким образом, что в любой момент при обращении к этим переменным их значения будут максимально актуальны.

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

Тип сообщения

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

Конфигурационный файл

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

Получение идентификатора объекта

Применённое в Имитаторе получение ID выглядит ужасно:
conf->oind->getIdByName(conf->getObjectsSection() + «/GUI»);
Предлагается ввести функцию
Uni Set Types?::getObjectID("/Sensors / Send Server?")
Функции

упразднить или обосновать их существование

Предопределённые каталоги

Должны формироватся configure пути к используемым каталогам, и получаться стандартными средствами, как это делается в других программах.
Функции

по возможности упразднить.