Принципы самотестирования

[Dale]

то есть самотестирование аппаратуры мне и нужно, но видимо начать нужно было не c vax, а вообще. хотя тогда я бы Вас не нашел) ну что, создавать?

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

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

Мне кажется правильным такой подход:

1. Оцениваем вероятность каждого дефекта (например, вероятность выгорания выходного буфера я оценил бы гораздо выше вероятности порчи команды вычитания). Не обязательно точным числом, хотя бы грубо вроде "высокая, средняя, низкая".

2. Оцениваем последствия проявления каждого дефекта опять же по шкале "катастрофа, терпимо, мелкая неприятность".

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

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

[levon]

добрый вечер. попробую сейчас переименовать тему. а нельзя ли Вам написать в icq, если не возражаете?

[Dale]

Если вопрос может представлять интерес и для других, тогда лучше здесь. Если нет, тогда в личные сообщения. Я стараюсь не злоупотреблять ICQ на работе.

[levon]

)) понял. тогда наверное лучше здесь. а как переименовать тему? что-то не выходит у меня.

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

в этом я еще больший новичок, однако интересно и наверняка не избито. о чем тут речь?

[Dale]

"Управление рисками" является одной из важнейших дисциплин современной программной инженерии. По таксономии Блума она относится к разделу "Управление разработкой программного обеспечения", подраздел "Планирование программного проекта".

Если совсем коротко, то ее суть состоит в следующем. Проектная группа должна:

• выявить все риски, которым может подвергнуться проект;
• оценить вероятность наступления каждого нежелательного события, а также ущерб в случае, если оно возникнет;
• разработать план действий в случае, если событие все-таки случится.

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

Налицо риск с высокой вероятностью и катастрофическими последствиями для проекта. Руководитель проекта совещается с ведущими специалистами, и они принимают решение:

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

Ну и так по каждому пункту.

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

[Dale]

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

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

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

[levon]

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

[Dale]

Кстати, я упустил из рассмотрения такой аспект тестирования.

Существует две разновидности тестов. Не знаю, как они классифицируются официально, назовем их условно функциональными и диагностическими.

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

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

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

Собственно, я этот разговор затеял вот почему. Ранее справедливо отмечалось, что если устройство будет часто и скрупулезно самотестироваться, то ему будет некогда выполнять полезную работу. А от слабых тестов мало проку. Что толку знать, что сложное устройство не работает, если не знаешь, как его починить? Разделение тестов на категории позволяет разрешить это противоречие. Устройство регулярно производит быстрое самотестирование общей функциональности. Если тестирование дает сбой, устройство демонтируется и переводится в диагностический режим, но уже не на объекте, а на ремонтном стенде.

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

[RXL]

Offtopic:

Название поправил. К сожалению, чтобы поправить названия во всех постах, нужно переместить тему, а это уже модераторские права.

[Dale]

Еще предлагаю рассмотреть такой вариант проверки "на лету".

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

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

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

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

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

Если конкретизируете задачу, попробую посоветовать что-то более предметно.

[levon]

Конкретизирую. Любая система на железной дороге разделяется грубо на 3 уровня: наборный, связующий и исполнительный. Наборный - это когда оператор сидит у себя в будке и нажимает кнопки маршрутов, допустим. Там проверяются всякие условия безопасности и т.д., и выполняют наборную группу уже на контроллерах (дублируют полностью каналы, их выходы на элемент И, соответственно, сигналы полностью совпали - значит, все нормально). Исполнительная группа - это непосредственно перевод стрелок (т.е. включение нужных обмоток электроприводов), включение светофоров и т.д. Строят до сих пор на реле 1-го класса надежности. Между наборной группой и исполнительной ставят устройства сопряжения (связующий уровень), и это все работает. Гальванические развязки между уровнями есть. Каналы верхнего уровня постоянно обмениваются друг с другом информацией. При этом контроллеры собирают через устройства сопряжения информацию о каждом объекте и т.д... Если можно, то могу Вам скинуть на почту небольшую методичку, где разобрана одна современная система, и Вы сразу поймете все, а то тяжело как-то сформулировать.

[Sel]

Offtopic:

levon, пиши предложения с большой буквы! Надоело исправлять! Ничего же не понятно, все сливается!

Поставлю в угол.

[levon]

Хорошо. Обязуюсь)

[Dale]

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

Лучше все-таки попытайтесь сформулировать. Четкая формулировка проблемы - обязательное условие ее понимания. А методичка наверняка содержит уйму несущественных деталей, которые мне по ходу изучения придется отбрасывать.

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

Я как раз в предыдущем посте описал принципы контроля подобных устройств.

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

Какие еще есть варианты исполнительных групп, нуждающихся в контроле?

[levon]

Dale, я пока здесь ничего не пишу, потому что хочу именно конкретизировать все и понять что хочу именно.

[Sla]

levon, диагностика, можно читать как самотестирование - целая наука.
По большому счету не существует каких-то единых правил и подходов к диагностике устройств.
Основной принцип - не навреди. Т.е. тест не должен привести к аварийной ситуации.

Dale, привел, на мой взгляд, практически полный подход к самотестированию.

Порядок прохождения тестов зависит он назначения и функционала контроллера.
В основном, всё нужно рассматривать применимо  к конкретной  системе.

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

Например.

придумали МК и решили-надо их туда поставить. но вот надежность маленькая. и обслуживать сложно, потому что не видно как и что происходит. поэтому строят сейчас все как правило дублированным, с резервами всякими и прочим.

У меня тогда вопрос, а вернее несколько.
Почему сделан вывод о маленькой надежности?
Проводились расчеты?
Выяснялись причины выхода из строя МК?
Какая элементная база использовалась?
Какая категория защищенности приборов?


зы задета болевая точка, как-никак этому отданы 5 лет "научной" работы

 

[Dale]

Dale, я пока здесь ничего не пишу, потому что хочу именно конкретизировать все и понять что хочу именно.

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

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

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

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

Это в общем разные задачи, и решаться они должны также по-разному. Я думаю, целесообразнее их решать в том порядке, в каком я их перечислил, но окончательное решение принимать вам.

[Dale]

И еще вдогонку пара общих мыслей по теме.

1. Стопроцентное тестирование - это идеал, который нам вряд ли удастся достичь на практике. Это вроде как пытаться достичь скорости света - можно лишь приближаться асимптотически, но по мере приближения трудность каждого следующего шага нарастает лавинообразно. Лучше для начала выбрать какой-то приемлемый уровень покрытия тестами, золотую середину, чтобы и на практике было полезно, и стоимость решения не была при этом заоблачной. Если этого окажется недостаточно, тогда повышать покрытие, смирившись с увеличением расходов на разработку тестов и дополнительного диагностического оборудования.

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

[Sla]

Господа! а чего разговор заглох?

[Dale]

Вроде как на общие вопросы были найдены более-менее приемлемые ответы, а более конкретные пока что не поступали. Либо тема потеряла актуальность, либо автор готовит новые вопросы. Ждем-с.

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