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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Функции saveState/Value

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

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

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

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

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

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

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

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

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

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

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

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

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