книги / Диагностические модели и методы повышения контролепригодности элементов и устройств распределенных информационно-управляющих систем на основе комбинирования логик

цедур поиска нЭФ с требуемой глубиной локализации. Это объясняется тем, что, как было изложено выше, большая часть элементарных проверок привязана к видам обеспечения (или средствам измерения) и является фиксированной. Количество элементарных функций (структура диагностической модели) при этом определяется и регламентируется принятыми требованиями и ограничениями. Тогда необходимо применить указанные при анализе вариантов 2 и 3 способы декомпозиции элементарных функций или тестов с учетом введенных ограничений и допущений. При этом важно выбрать объект декомпозиции: элементарные функции или тесты с учетом имеющихся ограничений и с анализом последствий возможных изменений.

Применение разных форматов таблиц диагностирования, преобразование форматов в сочетании с условными или безусловными алгоритмами поиска обусловлено принятыми рекомендациями и ограничениями на структуру ДМ, заданными средствами контроля, а также планируемыми для реализации методами диагностирования степени выполнения ЭФ и в конечном итоге определяется при формировании контролепригодной структуры ДМ. Задание структуры таблиц диагностирования осуществляется в рамках разработанной методики контролепригодного проектирования.

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

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

–общее описание каждого вида обеспечения и его подсистем;

–количество и формулировки названий и функциональности подсистем каждого вида обеспечения;

–количество и формулировки элементарных функций, сгруппированных по установленным в рамках предложенной диагностической модели признакам;

–требования к средствам контроля (тестам);

–график и формы проведения процедур контроля;

–рекомендации (ограничения) по количеству и соотношению компонентов каждого уровня структуры диагностической модели;

–требования по выбору методов диагностирования, включая формат таблицы диагностирования, ограничения по глубине локализации ЭФ с недостаточным уровнем освоения (нЭФ), ресурсные ограничения по реализации алгоритмов поиска, свойства шкалы оценивания и т.п.

Проектирование контролепригодной структуры диагностической модели является слабоформализуемой итеративной задачей, поэтому не имеет единственно-

81

го тривиального решения. На качество решения влияют имеющиеся ограничения и рекомендации, наличие научно-методических публикаций по данной проблематике, квалификация специалиста-диагноста, опыт в разработке и внедрении систем управления и т.д. Задача разработки контролепригодной структуры диагностической модели – определить необходимое количество и формулировки ЭФ, увязанные с построением тестов и выбранными методами диагностирования степени выполнения ЭФ. При этом предлагается придерживаться следующих этапов общего итеративного подхода.

1.Проанализировать назначение, структуру, принципы построения, протоколы и т.п. для выбранной системы управления.

2.Составить укрупненную структуру диагностической модели (виды обеспечения, их подсистемы, группы функций, элементарные функции).

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

4.Выбрать метод (методы) диагностирования (алгоритмы безусловного и/или условного поиска ЭФ с недостаточной степенью выполнения – нЭФ) и с их учетом сформировать требования к структуре ДМ (варианту формата таблицы диагностирования для каждого вида обеспечения).

5.Определить количество и формулировки ЭФ для каждой подсистемы. При выборе количественных показателей разных групп функций (интерфейсных – ГИФ, обрабатывающих – ГИФ, трансформирующих – ГТФ) рекомендуется при-

держиваться соотношения: NГИФ > NГОФ > NГТФ. Данная процедура имеет итеративный характер, и ее результаты могут быть скорректированы в процессе разработки требуемых средств контроля и выбора методов диагностирования.

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

7.Разработать процедуру условного и/или безусловного поиска нЭФ с заданной глубиной локализации, т.е. мощностью конечного множества подозреваемых нЭФ.

8.Выбрать вариант покрытия и построить таблицу диагностирования.

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

10.Проверить количественные показатели структуры ДМ для каждой подсистемы, характеризующие избыточность, отсутствие дублирования, полное по-

82

крытие, равнозначность формулировок ЭФ и т.д., при необходимости ввести коррекцию в количество и формулировки ЭФ.

11. При изменении исходных данных пересмотреть структуру ДМ (изменение количества и формулировок ЭФ, а также тестов, отвечающих за контроль степени выполнения ЭФ, и т.п.).

Рассмотрим детализированную пошаговую реализацию этапов предложен-

ного общего итеративного подхода к разработке контролепригодной структуры диагностической модели. При этом раскроем некоторые ограничения, выполнение которых проверяется на определенных шагах процедуры проектирования.

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

Шаг № 2 – выбираются методы диагностирования (безусловные и/или условные процедуры поиска ЭФ с недостаточной степенью выполнения), что может потребовать пересмотра структуры ДМ и таблиц диагностирования (разработка методов и условий их применения – отдельное направление исследования); применяется инструментарий моделирования для проверки полноты покрытия и глубины локализации нЭФ (аналог рассматриваемой в технической диагностике «обратной задачи», которая заключается в синтезе теста, обнаруживающего заданную неисправность объекта контроля) – этап 7.

Шаг № 3 – трансформируются таблицы диагностирования: консолидируются (объединяются) схожие по формулировкам ЭФ либо, наоборот, декомпозируются (дробятся) ЭФ для перераспределения средств контроля; из простых тестов строятся составные и сложные тесты, что требует переформатирования структуры; вводятся новые ЭФ и/или тесты по выбранным методам диагностирования и т.д. – этапы 8-9.

Шаг 4 – проверяется выполнение требований и ограничений, накладываемых нормативно-методической документацией, – этап 10.

При изменении исходных данных (в зависимости от характера изменений) проводится возврат на соответствующий шаг – этап 11.

Предлагаемый подход к проектированию контролепригодной структуры диагностической модели элемента системы управления позволит взаимоувязать свойства объекта контроля и методы диагностирования и оценивания. Это, с одной стороны, даст возможность учета характеристик тестов для обеспечения наиболее полного и точного диагностирования ЭФ, а с другой – возможность подбора «удобной» структуры диагностической модели под имеющиеся средства диаг-

83

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

3.3. Повышение контролепригодности элементов РИУС на этапах разработки, производства и эксплуатации

Контроль технического состояния функциональных узлов и связей между ними является одним из составляющих технологического процесса производства и наладки современной аппаратуры РИУС. Указанные функции выполняют ав-

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

системой управления и мониторинга (СУМ). Такая система наряду с функцио-

нальным контролем рабочих характеристик и параметров позволяет производить тестовое диагностирование выбранных устройств [65].

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

АВТОМАТИЗИРОВАННАЯ СИСТЕМА ТЕСТОВОГО ДИАГНОСТИРОВАНИЯ

Рис. 3.1. Структура автоматизированной системы технического диагностирования

84

Для повышения полноты и адекватности представления информации о техническом состоянии предлагается следующая иерархия объектов контроля [132]:

1.Модуль (физический (процессор, память, порт и т.п.) или виртуальный (канал, стык, поток и т.п.) объект управления и контроля).

2.Плата (функциональный элемент, типовой элемент замены на эксплуатации).

3.Блок (единица оборудования, обладает заданной функциональностью).

4.Узел (объединяет несколько блоков в локальную сеть управления и мониторинга).

5.Сеть (объединяет узлы в транспортную сеть управления и мониторинга). Отметим, что рекомендациями ITU-T (в частности, серии G) описываются

сообщения о неисправностях (как правило, только для формируемых информационных потоков), поэтому предложенная детализация позволяет сформировать более адекватное представление о контролируемых элементах РИУС.

Эффективность реализации предложенных рекомендаций по повышению контролепригодности можно оценить при выполнении процедур диагностирования элементов и устройств РИУС на разных этапах жизненного цикла. Рассмотрим реализацию процедур диагностирования и оценку показателей контролепригодности на примере коммуникационного оборудования производства ПАО «Морион» и ОАО «Такт» (г. Пермь) [93]. АСТД интегрирована в информационное и программное обеспечение менеджера сетевых элементов (КПО-31) и менеджера сети управления (КПО-01). Применение разработанного инструментария диагностирования при разработке, производстве и эксплуатации аппаратуры РИУС показано далее (см. приложение Б).

3.3.1. Реализация рекомендаций по повышению контролепригодности элементов и устройств РИУС на этапе разработки и производства

Для обеспечения контролепригодности элементов физической архитектуры системы управления (плат или блоков) часто применяются достаточно простые технические решения:

–доступ к контрольным точкам (измерение частоты, скорости, параметров сигнала и т.п.);

–визуальная (световая) индикация на лицевой панели элемента;

–взаимодействие с внешним устройством сигнализации (транспарантом);

–поддержка физических интерфейсов с элементами системы управления бо-

лее высокого уровня (RS-232, USB, RS-485, Ethernet, Bluetooth, Wi-Fi) и т.д.

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

всоставе плат, плат в составе блоков, блоков в составе узлов и т.д.) в контроле-

85

пригодную структуру. Она позволяет реализовать дистанционную загрузку и выгрузку тестов, а также проведение функционального диагностирования с использованием ресурсов, имеющихся в поддерживаемых протоколах управления и мониторинга. Для этого еще одним направлением для повышения контролепригодности является реализация стандартизированного представления объектов (MIB)

истандартных протоколов управления, что будет описано далее.

Всоответствии с рекомендацией о контролепригодном проектировании сетевых элементов (параграф 3.1, п. 1) реализована структура внутреннего представления атомарного объекта контроля, включающая переменные или более сложные структуры (таблицы, списки, объекты), описанные на стандартизированных языках (ASN.1, XML). Поддерживается стандартизованный алгоритм взаимодействия (параграф 3.1, п. 2 рекомендации). Для этого в протоколе передачи информации о техническом состоянии формируются данные по одному блоку (функциональному элементу РИУС). Они содержат детализированную информацию о статусе плат (список типов и кодов сообщений об их неисправностях, а также при наличии сведения о статусе модулей, стыков, портов, потоков и т.п.). Это позволяет менеджеру системы управления, сформировав соответствующий запрос и интерпретировав ответ, определить техническое состояние каждого уровня физической (модуль, плата, блок) и логической (узел, подсеть, сеть) архитектуры РИУС. Для взаимодействия с управляющим элементами активно используются стандартизированные транспортные протоколы (параграф 3.1, п. 3 рекомендации) [132].

Для проверки коммуникационного оборудования на базе КПО-31 был спроектирован и реализован отладочный комплекс проверки элементов аппаратуры РИУС (специализированных модулей в составе плат, плат в составе блока, блоков в составе узла). Для этого применяется функциональное диагностирование (проверка правильности формирования сообщений о неисправностях, предусмотренных реализуемой коммуникационной технологией). Для проверки правильности функционирования блоков в составе сетевой структуры используется менеджер (СУМ и АСТД) КПО-01.

Технологический тестер представляет собой аппаратно-программный комплекс, выполняющий следующие функции формирования проверяющих тестов {T}; выдачу управляющей информации {У} и загрузку проверяющих тестов через адаптер; съем реакций {Р} на тест, хранение и обработку данных. Свойство контролепригодности у проверяемых объектов (модулей на плате) формируется за счет поддержки принципа сканируемого пути и поддержки интерфейса JTAG (параграф 3.1, п. 4 рекомендации) [145] (рис. 3.2).

Для диагностирования сложных структурных элементов коммуникационной

аппаратуры использованы способы построения контролепригодных структур (рис. 3.3). Интерфейс диагностирования реализуется в виде внутриблочной шины или внутристоечной магистрали (локальная сеть управления и мониторинга) (параграф 3.1, п. 4 рекомендации).

86

87

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

Для того чтобы дать количественную оценку эффективности от реализованных способов обеспечения контролепригодности, предлагается подход, увязанный требованиями ГОСТ 26656-85 [35]. Проиллюстрируем его на примере диагностики элементов РИУС на уровне плат блока. Для этого выразим общее количество параметров элементов N в виде совокупности следующих составляющих:

где Nпл. – общие параметры платы (версия АО и ПО, идентификатор (номер), статус аварий и т.д.); Nф.м. – количество физических модулей (процессор, контроллер, порт и т.д.); Niф.м. – количество параметров в i-м физическом модуле; Nв.м. – количество виртуальных модулей (поток, канал, стык и т.д.); Njв.м. – количество параметров в j-м виртуальном модуле.

В процессе сборки и наладки на этапе производства контролируется часть параметров Nк., которые являются наиболее значимыми и могут быть проверены имитацией (моделированием). Предложенные способы контролепригодного проектирования (реализация стандартных MIB и протоколов управления) позволяют улучшить показатели диагностирования (уменьшить среднюю оперативную трудоемкость Sд.) и контролепригодности (коэффициент безразборного диагностирования Kб.д.) [35]:

Для рассматриваемого примера внедрения Kб.д. улучшен в среднем до 0,87 для блока аппаратуры, что составляет увеличение на 42 %, а Sд уменьшено примерно в 1,5 раза относительно величин до внедрения разработанной системы. Это стало возможно за счет повышения степени автоматизации процедур с использованием разработанных аппаратно-программных средств диагностирования, формирования приспособленных к диагностированию структур представления объектов контроля (с использованием выбранных алгоритмов взаимодействия и магистралей передачи диагностической информации), а также перехода от системы измерений к функциональному диагностированию.

3.3.2. Реализация рекомендаций по повышению контролепригодности элементов и устройств РИУС на этапе эксплуатации

Рассмотрим пример реализации предложенной выше рекомендации по повышению контролепригодности на этапе эксплуатации. На рис. 3.4, а приведена обобщенная функциональная схема СУМ коммуникационного оборудования под-

88

системы СПРИ РИУС. За состоянием объектов контроля следят специальные ап- паратно-программные средства – агенты (А), реализованные в устройствах контроля и сигнализации (КС), с которыми взаимодействуют менеджеры (М). Построенные в соответствии с указанной схемой системы позволяют реализовать иерархическую сеть управления и мониторинга, обеспечивая при этом эффектив-

ную сетевую диагностику.

Проиллюстрируем реализацию предложенной в предыдущем параграфе рекомендации по повышению контролепригодности на примере менеджера системы управления и мониторинга аппаратуры оперативно-технологической связи (ОТС), реализованной на коммуникационном оборудовании ПАО «Морион» на Октябрьской железной дороге ОАО «РЖД» (рис. 3.4, б).

б

Рис. 3.4. Система управления и мониторинга элементов РИУС: а – обобщенная функциональная схема; б – TMN-платформа управления и мониторинга

Системы управления и мониторинга ОТС построены по принципам, реализующим концепцию TMN (ITU-T M. 3010). Это означает, что они поддерживают стандартизованные протоколы управления (параграф 3.1, п. 3 рекомендации),

89

предусмотренные архитектурой TMN. В системах реализована поддержка стандартизированных интерфейсов TMN F, Q2 (локальная сеть) и Q3 (транспортная сеть), что позволяет обеспечить доступность и полноту управляющей и диагностической информации по всем элементам РИУС.

В программном обеспечении менеджера (пульт оператора) КПО-01 реализуются следующие дополнительные возможности по повышению контролепригодности контролируемых элементов: ведение карты сети; поддержка базы данных оборудования; описание MIB всей номенклатуры устройств; ведение отчета тревог по всем аварийным ситуациям и т.п.

Выполнение п. 1 и 2 рекомендации (параграф 3.1) далее будет рассмотрено на примере построения двухуровневой СУМ с распределением функций управления и взаимодействием разных уровней через сервер БД. Отметим, что для повышения качества управления, доступности и полноты представления информации современные системы управления и мониторинга должны реализовать не только

уровень управления сетевыми элементами, но и уровень управления сетью, а так-

же вышележащие уровни пирамиды TMN [199]. При этом необходимо построить многоуровневую СУМ так, чтобы предоставить нужную информацию с заданными показателями быстродействия, не создавая при этом дополнительный трафик для контролируемого оборудования (что является особенно критичным при реализации встроенных каналов управления). В рекомендациях ITU-T для этого предлагается использование стандартных протоколов управления, что не позволяет эффективно решить задачу в указанной постановке. Поэтому для решения поставленной задачи в работе предложена методика контролепригодного реконфигурирования системы управления, которая заключается в рекомендациях по вве-

дению в структуру СУМ дополнительных элементов адаптации между уровнями

(например, сервер базы данных СУБД с соответствующей СУ; внешнее приложе- ние-шлюз или дополнительные модули для преобразования протоколов и т.д.).

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

1. Анализ и формирование внутренних структур данных (например, представление объектов контроля, карты сети, базы данных оборудования и т.п.) с учетом требований тех систем, с которыми предстоит организовать межпрограммный интерфейс.

2. Разработка протокола и алгоритма межпрограммного взаимодействия (за- прос-ответ, с прерыванием, по событию и т.п.).

90