К вопросу о странностях и систематическом подходе
Отбросьте всё невозможное, то, что останется, и будет ответом, каким бы невероятным он ни оказался.
Есть на одном зарубежном ресурсе по электронике раздел «Записки Шерлока Омса», где рассматриваются загадочные случаи из инженерной практики (не только по электронной части, но, как правило, по ней). Решил завести нечто подобное, вот очередная история инженерного расследования.
Имеется некое устройство, выдержка из структурной схемы которого приведена на рисунке 1.
Мы видим на нем импульсный преобразователь входного питания в промежуточную шину 12 Вольт, импульсный преобразователь из 12 в 5 Вольт, линейный стабилизатор, формирующий из 5 питание микроконтроллера (МК) 3.3 Вольта, схему сброса МК в виде задержки на интеграторе, собственно МК, который управляет индикатором через шину взаимодействия, включая сигнал сброса, и сам индикатор, через который осуществляется взаимодействие с пользователем. Ничего особенного в данной структуре устройства нет, можно обратить внимание только на то, что все указанные компоненты отечественного производства (далее следует реклама) — фирм Александер Электрик Дон (источники серии МДМ), Миландр (линейный стабилизатор и МК серии 1986), КТЦ-МК (индикатор типа EL240).
Немного о индикаторе, поскольку он является главным героем повествования — мало того, что он отечественный (вышеуказанная фирма их реально собирает, я сам видел, правда, из частично импортных комплектующих), так он еще имеет и честный температурный диапазон от -40 С без всяких подогревов — это электро-люминесцентный («плазменный») индикатор. Но за все в этом мире надо платить — в данном случае мы платим более высоким (по сравнению с индикаторами на других технологиям со сравнимым разрешением) энергопотреблением, массо-габаритными параметрами, размером пикселя, необходимостью двух питаний ну и деньгами, конечно.
Устройства такого типа были спроектированы, изготовлены и успешно выполняли свои задачи в течении длительного времени, пока однажды одно из них не было «случайно подвергнуто механическому воздействию, выходящему за пределы требований по стойкости к ударам в соответствии ТУ на изделие» (ударили о выступ на объекте), что и привело в повреждению экрана. Устройство привезли к нам, экран заменили и собирались уже отдавать его потребителю, но обратили внимание на одно обстоятельство — индикация несколько изменилась.
Дело в том, что после включении устройство входит на некоторое время (5–6 секунд) в сервисный режим, в котором представитель эксплуатанта может удостовериться в соответствии номера версии ПО указанному в паспорте на изделие (поскольку речь идет о потребителе, которому важно иметь отечественные компоненты в изделии — Вы уже поняли, кто это — распространенное требование), а затем переходит в основной режим работы, и на индикатор поступает рабочая информация. Так вот, после ремонта в тестовом режиме на экране присутствовала некая псевдослучайная информация, а затем начиналась нормальная работа. Быстро проведенное исследование показало, что на протяжении тестового режима экран не был должным образом инициализирован (хотя импульс сброса на него МК в начале работы исправно подавал), а после повторной инициализации (перед началом рабочего режима) приходил в норму.
Возникает гипотеза — первый импульс сброса не отрабатывается, поскольку попадает на неустановившееся питание индикатора. Проверить ее очень легко — после включения устройства подаем на вход МК сигнал сброса путем замыкания конденсатора — после снятия закоротки заново отрабатывается процедура старта программы и индикатор верно отражает данные, начиная с тестового режима — гипотеза подтвердилась. На всякий случай проводим дополнительное исследование, более точно проверяющее гипотезу — закорачиваем конденсатор при выключенном питании, потом включаем и через секунду убираем пинцет — дефект отсутствует, индикация в тестовом режиме отрабатывается. Рабочую гипотезу принимаем верной и ищем способы исправления дефекта.
Смотрим осциллографом временную диаграмму сигналов в момент запуска и видим, что после появления стабильного питания +12 (кстати, взлетает оно почти вертикально, источник явно имеет хороший запас по мощности) питание +5 (вместе с питанием +3.3) становится стабильным через 80 мсек (задержка включения второго источника, причем фронт тоже очень хороший, резкий), сигнал сброса МК пропадает еще через 1 мсек, а сигнал сброса на индикатор приходит еще через 100 мсек, как и предусмотрено в программе. Странно как то, вроде бы все нормально и сброс явно попадает на стабильное питание, значит, гипотезу надо менять. Предполагаем, что после подачи одного из питаний на индикатор необходимо выдержать паузу до подачи сигнала сброса и это требование в данный момент не выполняется. Смотрим дата в части последовательности включения индикатора и обнаруживаем, что никаких требований не предъявляется, от слова совсем, есть лишь требование после завершения сброса воздержаться от передачи информации индикатору на 3 мсек, что вполне выполнено. Всплывают какие то смутные (устройство и прошивка к нему разрабатывались 4 года назад, а комментарии в программе, естественно, ну не то чтобы совсем отсутствуют, но близко к этому) воспоминание, что две инициализации — это неспроста и видимо, с первого сброса не всегда запускался индикатор и, значит, действительно необходима задержка, а в новом экземпляре экрана потребовалось ее увеличить (ну так получилось, с параметрами, не указанными в документации, такое бывает). Ну и прикинем, что, поскольку сейчас мы видим величины порядка сотни мсек, то и увеличение должно быть соразмерным, по крайней мере десятки мсек, а лучше сотенку добавить, тем более, что в требования к устройству по времени готовности мы вписываемся с большим запасом.
Для начала определим, где необходима увеличенная задержка — от подачи 12 до сброса экрана или от подачи 5 до него же. Проводим еще один эксперимент — источник +5 имеет вход разрешения работы, поэтому при включенном устройстве закорачиваем вход разрешения на его входной минус (это по дата на источник допустимо и даже рекомендовано) и устройство запускается без дефекта — значит, нужна задержка после поднятия 12 и до запуска 5. Немного непонятно, я бы все таки запитал логическую часть устройства от 5, но, наверное, я не все знаю, пока согласимся.
Конечно, задержку можно поставить и после появления 5 до запуска МК, при этом автоматом добавится задержка от 12 до сброса, но это потребует значительного изменения параметров цепочки (сейчас там постоянная времени 1 мсек) и сделает фронт сильно затянутым, что обычно не приветствуется, или после запуска МК до формирования сброса на индикатор (но это требует изменения программы, что хорошо бы отложить на случай, если не справимся допиливанием железа).
Поэтому ставим схему задержки на RC цепочке на вход включения источника 5 с постоянной времени 100 мсек и… ничего не получилось — дефект при включении сохранился, хотя осциллограмма подтверждает, что задержка стала на 100 мсек больше. Странно как то, либо требуется увеличение задержки еще больше (но и так мы уже сделали почти 300 мсек), либо гипотеза о месте требуемой задержки неверна. Проводим еще один эксперимент — закорачиваем разрешение работы источника 5 на входной минус, включаем устройство и через секунду отпускаем — и видим, что дефект не исчез. Ага, значит задержка нужна все таки между включением 5 и сбросом экрана. Корректируем программу и выясняем, что при задержке в 120 мсек дефект исчезает, поэтому для надежности делаем 200 мсек и вписываем комментарий, почему сделано именно так (вот в таких ситуациях и понимаешь всю необходимость комментирования текста, которая обычно представляется некоей досадной абстракцией).
Задача решена, дефект устранен, но неприятный осадок остался — есть непонятности (лично я очень не люблю, когда чего-то до конца не понимаю, эти непонятки имеют пренеприятное обыкновение потом выскакивать в самый неподходящий момент и больно ударять в спину). В общем подход «но ведь работает же» — это категорически не наш подход, мы должны понимать (ну или думать, что понимаем), почему именно решение работает. «Не так страшно, если Ваша программа не работает и непонятно почему. Самый плохой случай — это когда Ваша программа работает, и непонятно почему».
Первый, не главный, вопрос — что это за задержка, которая не описана в дата. Ну здесь все просто, криворукие разработчики ввели какое-то изменение в схемотехнику, типа временной блокировки, чтобы избежать гонок при включении, а проверить его влияние на поведение устройства не удосужились и в дата не отразили. Такое случается сплошь и рядом, хотя это никак не может служить их (разработчиков) оправданием, так что прошу данный пост рассматривать в том числе и как обращение в техническую поддержку фирмы — производителя индикатора. Есть еще возможность, что это дефект конкретного индикатора и в старые времена я бы так поведение экземпляра в условия отсутствия требований к задержке в ТУ и расценил и составил бы рекламационный акт, но старые времена канули в Лету (не знаю, хорошо это или плохо, но это факт «объективной реальности, данной нам в ощущениях» и размышлениях). Схемы индикатора у меня все равно нет, а и особого желания разбираться в чужой схеме не наблюдается, так что правдоподобное объяснение мы придумали и нас это на данном этапе устраивает.
А вот вторая непонятка куда тревожнее — ведь эксперимент первоначально явно указал на неверную причину дефекта (на самом деле эксперимент ни на что не указывал, кроме факта, ошибочна наша интерпретация его результатов) и с этим надо бы разобраться — это наш косяк в понимании происходящего, что недопустимо в принципе. Еще раз сформулируем противоречие — если мы выключаем источник 5 в момент, когда устройство находится под питанием 12 и функционирует, то включение проходит без дефекта, а вот если мы задерживаем включение источник 5 с самого начала старта подачи питания, то имеется дефект при первом запуске. В полном соответствии с правилами ТРИЗ, грамотно сформулированное противоречие подсказывает механизм его преодоления. Выдвигаем гипотезу, что если индикатор уже правильно функционирует (сброс отработан), то выключение питания 5 не приводит к его возврату в исходное (неопределенное) состояние, то есть 12 его как-то поддерживают. Для проверки данной гипотезы проводим еще один эксперимент — блокируем источник 5, включаем устройство, отпускаем 5 и даем МК поработать, но не доходим до второго сброса, опять блокируем и повторяем процедуру. Видим, что тестовый режим в таком случае (до рабочего режима мы не доходим) всегда имеет дефект. Если же мы позволяем МК дойти до второго сброса и войти в рабочий режим, то все последующие перезапуски источника 5 приводят к правильной последовательности включения. Не очень понятно, зачем так сделано, но вполне реализуемо и мы можем даже нарисовать схему, имеющую подобное поведение.
Теперь, когда нам все стало понятно, фиксируем новую задержку в программе и считаем задачу полностью решеной (до получения новых результатов, которые будут противоречить ранее полученным), до получения экземпляра индикатора, которому и 200 мсек задержки будет недостаточно.
