|
UniSet 2.32.1
|
Класс SharedMemory расширяет набор задач класса IONotifyController. Для ознакомления с базовыми функциями см. page_IONotifyController
Задачи решаемые SM:
SM позволяет определять список датчиков, которые он будет предоставлять для работы другим объектам. Помимо этого можно задавать фильтрующие поля для списка "заказчиков"(consumer) по каждому датчику, а также поля для фильтрования списка зависимостей(depends) по датчикам. Все эти параметры задаются в командной строке
В SM реализован механизм позволяющий задавать список объектов, которым присылается уведомление о старте/рестарте SM. Параметр определяющий фильтр, по которому формируется список объектов задаётся из командной строки --e-filter. Параметр --e-startup-pause msec - задаёт паузу после старта SM, после которой заданным объектам посылается уведомление. Чтобы указать объект которому необходимо присылать уведомление, необходимо для него в конфигурационном файле указать поле evnt_xxx="1", где xxx - имя заданное в качестве параметра --e-filter. Пример:
При этом в параметрах старта SM должно быть указано --e-filter myfilter. Тогда при своём старте SM пришлёт объекту с идентификатором 2342 уведомление.
В качестве уведомления объектам рассылается сообщение SystemMessage::WatchDog.
В SM реализован механизм позволяющий задавать зависимости между датчиками. Т.е. датчик будет равен "0" пока разрешающий датчик не будет равно "1". Ниже показан пример конфигурирования зависимости.
В данном примере Sensor1 зависит от значения датчика Node_Not_Respond_FS. При этом значение блокировки инвертировано (block_invert=1). Т.е. если Node_Not_Respond=0, то Sensor1 - будет равен своему реальному значению. Как только Node_Not_Respond_FS станет равен 1, зависящий от него датчик Sensor1 сбросится в "0". Описание зависимости производится в секции <depends>. Возможные поля:
На данный момент зависимость можно устанавливать только на дискретные датчики.
Слежение за специальными датчиками (инкремент специальных датчиков), а также выставление дискретных датчиков "живости" процессов.
Данный механизм построен на следующей логике:
При этом, имеется возможность для некоторых процессов (обычно для особо важных, без которых работа невозможна) указать, время ожидания "перезапуска процесса"(heartbeat_reboot_msec) и в случае если для SM настроена работа с WDT-таймером и за заданное время процесс не перезапустился (не обновил свой счётчик), происходит перезагрузка контроллера (SM перестаёт сбрасывать WDT-таймер).
У аналоговых датчиков "сердцебиения" в конфигурационном файле необходимо указывать heartbeat="1". А также поля:
Пример задания датчиков "сердцебиения":
"Аварийный дамп" представляет из себя набор циклических буферов (размер в количестве точек хранения задаётся через конф. файл), в которых сохраняется история изменения заданного набора датчиков. В качестве "детонатора" задаётся идентификатор датчика (если это аналоговый датчик, то задаётся значение) при котором накопленный аварийный дамп должен "сбрасываться". За сохранение накопленного дампа (при "сбросе") отвечает разработчик, который может обрабатывать это событие подключившись к сигналу SharedMemory::signal_history(). Количество циклических буферов не ограничено, размер, а также список датчиков по которым ведётся "история" также не ограничены. Настройка параметров дампа осуществляется через конф. файл. Для этого у настроечной секции объекта SharedMemory должна быть создана подсекция "<History>". Пример: В данном примере задаётся две "истории".
где:
Каждый датчик может входить в любое количество групп (историй).
Механизм функционирует по следующей логике:
При запуске происходит считывание параметров секции <History> и заполнение соответствующих структур хранения. При этом происходит проход по секции <sensors> и если встречается "не пустое" поле заданное в качестве фильтра (filter), датчик включается в соответствующую историю.
Далее каждые savetime мсек происходит запись очередной точки истории. При этом в конец буфера добавляется новое (текущее) значение датчика, а одно устаревшее удаляется, тем самым всегда поддерживается буфер не более size точек.
Помимо этого в функциях изменения датчиков (семейство setValue) отслеживается изменение состояния "детонаторов". Если срабатывает заданное условие для "сброса" дампа, инициируется сигнал, в который передаётся идентификатор истории и текущая накопленная история.
В SM реализован механизм позволяющий задать специальный дискретный датчик ("пульсар"), который будет с заданным периодом менять своё состояние. Идентификатор датчика задаётся в настроечной секции параметром pulsar_id или из командной строки, параметром --pulsar-id. Период мигания задаётся параметром pulsar_msec или в командной строке --pulsar-msec. В качестве дискретного датчика можно задать любой датчик типа DO или DI. Параметр определяющий тип заданного датчика pulsar_iotype или в командной строке --pulsar-iotype.
Для оптимизации, по умолчанию в SM отключено сохранение каждого изменения датчиков в БД (реализованное в базовом классе IONotifyController). Параметр командной строки --db-logging 1 позволяет включить этот механизм (в свою очередь работа с БД требует отдельной настройки).
Для повышения надёжности работы в SharedMemory предусмотрен механизм восстановления текущего состояния (датчиков) из списка резервных SM. После того, как SM запускается и активизируется, но до того, как она выдаст exist()=true и с ней можно будет работать, происходит попытка получить значения всех датчиков от резервных SM. Список резервных SM задаётся в секции <ReservList>...</ReservList>. При этом попытки получить значения идёт в порядке указанном в списке и прекращаются, при первом успешном доступе.
1.10.0