Методы организации программного обеспечения процесса диагностирования

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

- загрузку своего имени и идентификатора из соответствующих атрибутов xml-элемента;

- загрузку параметров;

- загрузку задач;

- предоставление возможности получения значений имени и идентификатора;

- предоставление доступа к параметрам и их значениям по имени;

- предоставление доступа к задачам по их имени или идентификатору;

- реализацию методов установки и предоставления информации о своём состоянии (для объектов контроля и объектов диагностирования);

- реализацию методов установки и предоставления информации о своём диагностическом состоянии (для объектов диагностирования);

- организацию загрузки дочерних объектов, а также предоставление механизма доступа к этим объектам по имени и идентификатору (для группы мониторинга).

Объекты мониторинга объединяются в иерархию специальным менеджером объектов. Для организации диагностирования создается поток обработки данных, который управляет обработкой данных подсистемы ввода и организует работу задач объектов мониторинга.

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

< Object NAME=”1-й” ID=”123” CLASS=”UniObject”>

<! -- Задачи контроля и измерения -->

< ObjData NAME=”SSig” CLASS=”DSig” Ref=”/IOSYS/БА1/МДВ3/XP2-1”/>

< ObjData NAME=”USig” CLASS=”ASig” Ref=”/IOSYS/БА1/МА1/XP2-1”/>

<! -- Задачи диагностирования, связанные с этим объектом -->

< ObjTask NAME=”Diag” CLASS=”SigTask” SigRef=”../SSig”/>

< ObjTask NAME=”Special” CALSS=”SpTask” TimeOut=”100”>

< SSIG REF=”../../2-й/ASig”/>

< USIG REF=”../USig”/>

< /ObjTask>

<! -- Задача формирования состояния: -->

< ObjState NAME=”STATE” CLASS=”SigState” SigRef=”../SSig”/>

< /Object>

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

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

Событием называется изменение состояния некоторой сущности. Например, изменение состояния объекта контроля, изменение диагностического состояния, изменение состояния задачи, изменение сигнала подсистемы ввода, истечение заданного промежутка времени и т.д. Каждое событие может либо зависеть от другого события, либо быть независимым. Простейшими независимыми событиями являются изменения сигналов подсистемы ввода. Зависимые события являются изменениями состояний различных задач. Таким образом, зависимости событий основываются на зависимостях между компонентами объектов мониторинга. Можно говорить, что каждое событие генерируется некоторой задачей, поскольку сигнал подсистемы ввода можно рассматривать как задачу контроля и измерения этого сигнала.

Все события разделены на три нечетких множества: события с малой (S), средней (M) и большой (B) вероятностью появления за малый промежуток времени. К событиям с большой вероятностью появления за малый промежуток времени относятся, например, изменения значения большинства аналоговых сигналов, так как каждое измерение имеет некоторую случайную погрешность. К событиям с малой вероятностью появления за малый промежуток времени относятся, например:

- изменения многих дискретных сигналов (изменение занятости рельсовой цепи, изменение состояния сигнального реле светофора и т.д.);

- изменение состояний большинства объектов мониторинга;

- изменение диагностических состояний;

- изменение состояния задачи контроля аналогового показателя (выход аналогового сигнала за норму, изменение кода кодирования рельсовой цепи, изменение нечеткого высказывания: «значительное увеличение напряжения за короткий промежуток времени» и т.п.).

Необходимо заметить, что события, которые зависят только от событий множества S, сами относятся к множеству S. Кроме того, к множеству S могут относиться события, зависящие от событий множества B. Это позволяет выделить группы задач, которые зависят от событий только из множества S. Именно эти группы задач целесообразно выносить в другие процессы, так как зависимость от событий множества S минимизирует количество передаваемых данных при спорадическом режиме обмена. Формирование множества S и групп задач, которые можно выносить на отдельные процессы, должно производиться на этапе адаптации программного обеспечения системой автоматизации проектирования.

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

Рис. 4.19 Иллюстрация организации обратных связей между событиями

Событийная модель обновления состояния должна строиться преимущественно для зависимостей типа S à S, в редких случаях - для зависимостей типа M à S или M à M и никогда - для зависимостей типа B à B, B à M или B à S.

Для реализации событийной модели состояний в подсистеме предварительной обработки создается поток обработки данных, который для выполнения цикла обработки ожидает получения данных для подсистемы ввода или проявления события истечения заданного промежутка времени для задач. Обработка может привести к проявлению ряда событий, связанных с изменениями сигналов в подсистеме ввода. Появление событий приводит к выполнению обновления задач. На рисунке ниже приведена блок-схема обновления состояния задач на потоке обработки данных:

Рис. 4.20 Блок-схема обновления состояния задач

менеджером объектов мониторинга

Распределение функций диагностирования строится на основе событийной модели обновления состояния.

Рассмотрим пример зависимости компонентов двух объектов мониторинга, взаимодействие между которыми происходит на одном процессе (рис. 4.21).

Предположим, что нужно вынести работу задач объекта диагностирования «В» в отдельный процесс «П2». Для этого в процессе «П2» объявляется зеркальный объект «А’», в котором указываются только те компоненты, которые используются задачами объекта «В». От этих компонент требуется лишь возможность установки их состояния на основе данных, полученных от исходного процесса «П1». Зеркальный объект А’ является составляющей некоторой дополнительной подсистемы ввода процесса «П2».

Рис. 4.21 Зависимости между объектами на одном процессе

В процессе «П1» вводится концентратор, обеспечивающий сбор и передачу в процесс «П2» событий, от которых зависят задачи в процессе «П2». Передача осуществляется в спорадическом режиме, что гарантирует минимальный объем передаваемых данных. На стороне процесса «П2» организуется распределение приходящих событий по объектам и задачам, составляющим дополнительную подсистему ввода процесса «П2», в которой происходит повторная генерация событий для извещения зависимых задач.

Для распределения задач одного и того же объекта мониторинга по разным процессам (рис. 4.22) в процессе «П1» объявляются только те задачи, работу которых необходимо выполнять на процессе «П1», а в процессе «П2» – задачи, состояния которых необходимо выполнять на процессе «П2». При этом задача S объекта B’, в процессе «П2» обеспечивает только возможность установки её состояния на основе полученных от процесса «П1» данных.

Подобное распределение работы задач объектов мониторинга может выполняться и с более глубокой вложенностью (П1à П2à П3 и т.д.). Кроме того, распределенные процессы диагностирования и мониторинга в СТДМ АДК-СЦБ, могут быть организованы на разных платформах, что обеспечивается единым протоколом обмена.

Рис. 4.22 Зависимости между объектами на разных процессах