3. Тестовое диагностирование мультирежимных систем

   1. Принципы тестового диагностирования мультирежимных систем

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

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

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

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

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

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