CC BY
45Владимир КОВАЛЕВ
Введение
Как известно, «везение» — категория не столько «везучих», сколько упорных и трудолюбивых. В данном случае именно так и есть, так как успех разработки всецело зависит от ответственности подхода к проектированию, его комплексности и широты охвата, целеустремленности и квалификации разработчика. Как уже было описано в предыдущей статье «Почему техника ломается, или Что такое забытое понятие «надежность», надежность — категория комплексная, хотя и выражается одним, вполне конкретным числовым параметром — вероятностью безотказной работы. Так вот, при проектировании нужно уделять внимание всем аспектам, влияющим на показатели надежности. Рассматриваемые здесь вопросы перекликаются с перечисленными в предыдущей статье. Будем считать, что читатель уже ознакомился предыдущей публикацией. Итак, начнем. Чтобы не запутаться, попытаемся разделить все «пространство проблем» по категориям (в скобках будут указаны связи с проблемами, описанными в предыдущей статье).
• Организационные аспекты.
• Схемотехнические аспекты.
(Надежность схемотехнических решений.
Надежность элементной базы.)
Что такое «не везет» и как с ним бороться,
или Как обеспечить надежность РЭС при разработке
Опытный образец отказал в самый неподходящий момент? Ваше устройство не прошло комплексные испытания у заказчика? «Сглючил» мобильный телефон, после переезда сгорел «телек», а в самую жару сломался кондиционер? Эх, не везет! Возможно. Но, может быть, причина в недостаточно проработанной схеме или конструкции устройства, возможно, при разработке упущен какой-то ключевой момент? Если вы читали предыдущую статью «Почему техника ломается», то, наверное, уже догадываетесь... Да, то самое забытое понятие «надежность». Данная статья ни в коей мере не претендует на полноту освещения столь обширной темы, как проектирование радиоэлектронных средств (РЭС), но в ней автор, на основе личного опыта в разработке радиоэлектронных устройств, постарается осветить типичные ошибки проектирования, приводящие к потенциальному (и в большинстве случаев реальному) снижению надежности проектируемой аппаратуры. Конечно, видеть «грабли» — не значит не наступать на них, тут каждый получает свои «шишки». Но, думаем, изложенные идеи найдут отклик у многих разработчиков. Давайте вместе попробуем разобраться, что же такое «не везет» и как с ним бороться.
• Конструкционные аспекты.
(Надежность конструкционных решений. Надежность элементной базы.)
• Программные проблемы.
(Надежность программного обеспечения.)
• Проблемы дизайна.
(Надежность пользователя.)
• Задачи тестирования.
(Надежность технологических процессов сборки. Надежность пользователя.)
• Оформление конструкторской и пользовательской документации.
(Надежность пользователя.)
Организационные аспекты
Оставим за рамками этой статьи многие организационные проблемы и сконцентрируемся на одной — наиболее важной для разработчика — техническом задании (ТЗ). Это сокращение на кого-то наводит ужас, кто-то в очередной раз, увидев его, отмахивается, как от назойливой мухи, а кто-то воспринимает его со всей ответственностью и «в порядке вещей». Но как бы то ни было, с ТЗ, в той или иной форме, приходится сталкиваться всем. Полное ТЗ — сложный и многостраничный документ, во многом индивидуальный для каждой разработки. Возможно, что вообще
универсального ТЗ не бывает, но все же есть базовые пункты, которых стоит придерживаться при его составлении. Известно из опыта, что где-то посередине пути к окончанию работ начинают рождаться крамольные идеи о том, что вообще нужно было делать все по-другому. Бывает, что ТЗ по ходу работ неоднократно уточняется и согласовывается, и, как правило, подтверждается один из «законов Мерфи»: «Только в конце работы мы обычно узнаем, с чего же нужно было начинать». Но, тем не менее, ТЗ позволяет выбрать нужное направление деятельности, определить сроки и «контрольные точки», трезво оценить объем работ и распределить силы. А потому, являясь базовым документом для начала работ, ТЗ требует к себе пристального внимания. Необходимо помнить, что ТЗ представляет собой документ, направленный как от заказчика разработчику, так и от разработчика — заказчику. Его составление — процесс обоюдный и итерационный. В ходе составления ТЗ необходимо выяснить все спорные моменты, в противном случае согласование этих моментов с заказчиком на этапе окончания работ может легко перейти в правовую плоскость. Отсутствие ТЗ при разработке сродни отсутствию договора в гражданском праве. Составление грамотного ТЗ — целое искус-
ство, но многие пренебрегают даже его облегченной версией, а зря. Чтобы можно было оценить важность данного документа, приведу типичные пункты ТЗ:
• основания для разработки и назначение разработки;
• общее описание изделия;
• требования к изделию:
- требования к характеристикам;
- требования по надежности;
- условия эксплуатации;
- специальные требования;
• технико-экономические показатели (в том числе и предполагаемые затраты на ТО);
• порядок контроля и приемки;
• приложения (описания, предварительные расчеты, схемы и т. п., которые могут быть использованы при разработке). Составление ТЗ выходит за рамки данной
статьи. Интересующимся можно посоветовать изучить соответствующие нормативные документы, а также посетить тематические сайты, посвященные разработке конструкторской документации.
Итак, ТЗ есть. Что дальше? Теперь на основании этого ТЗ разработчик должен составить для себя (и для заказчика тоже) «план работ», который должен содержать примерные сроки выполнения ключевых этапов, даты представления промежуточных контрольных результатов и, конечно, дату окончания работ. В интервале от начала работ до сдачи результата разработчик волен варьировать сроки промежуточных этапов, однако большое отклонение от принятого плана в контрольных точках — тревожный сигнал. На практике, безусловно, редко удается выдержать в точности указанные сроки, но, по крайней мере, нужно стремиться попасть в отведенные временные рамки. Так что тут без плана никак, иначе процесс разработки рискует затянуться на неопределенное время. Указанные выше проблемы обычно отсутствуют во «взрослых КБ» (но где они сейчас?) и, как правило, проявляются в небольших коллективах, в частных предприятиях, коих теперь большинство. Но даже при наличии ТЗ и плана работ наиболее типичная и опасная ошибка — занижение сроков разработки. Причины, по которым это происходит, — совершенно различны, от простой недооценки трудностей до желания предложить заказчику более выгодные условия сотрудничества. Результат один — работа в цейтноте и, в конечном счете, — срыв сроков и ухудшение качества работ. Если у разработчика за плечами нет хотя бы нескольких крупных проектов (на которые затрачено по полгода работы), то можно смело умножать кажущиеся разумными сроки разработки на 1,5 или даже 2. «Ну, это уж слишком!» — скажете вы. Думаете? Проанализируйте все «узкие» и «скользкие» места в ТЗ и вы почти наверняка согласитесь со мной. Не спешите, лучше лишний день подумайте. Более опытные разработчики ошибаются
с оценкой сроков значительно реже. Ну вот: ТЗ и план работ есть. Теперь можно приступать к самому интересному.
Схемотехнические аспекты
С чего начинается строительство здания? Правильно, с фундамента. Для принципиальной схемы фундамент — схема структурная и функциональная. Если большинство специалистов действительно обладают достаточной квалификацией, чтобы не делать ошибок в отдельных узлах и каскадах принципиальной схемы, то, в общем и целом, при отсутствии структурной схемы разработчик часто двигается не в оптимальном направлении. Наличие структурной схемы позволяет начать проектирование устройства на «верхнем уровне иерархии», видеть его принципиальные недостатки и достоинства. В то время как ее отсутствие часто «зацикливает» разработчика на «частностях», препятствуя созданию оптимальной структуры устройства. А в дальнейшем отсутствие структурной схемы может значительно осложнить модификацию разработки, анализ отказов и ремонт. Попробуйте, например, описать работу сложной технической системы (допустим ПК) без деления ее на функциональные блоки. Вряд ли получится, а если и получится, то все равно волей-неволей вы будете оперировать макропонятиями: «чипсет»,
«процессор», «шина» и т. п. То есть структурируете сложную систему. Это вполне естественно. Но почему-то при разработке часто полностью игнорируется структурное представление разрабатываемого устройства. «Валить все в одну кучу» еще возможно при ведении проекта (хотя наверняка будут ошибки из-за отсутствия видения в целом), а уж по прошествии времени разобраться в такой «каше» без детального описания и структурной схемы бывает очень тяжело. Да и анализ таких схем крайне затруднителен (особенно если он проводится не автором данной разработки, да еще и при отсутствии пояснительной записки). Единственным оправданием отсутствия структурной схемы может быть, на взгляд автора, только простота проекта (глупо было бы рисовать структурную схему, например, для несложного источника питания).
Не менее важна и схема функциональная. Давайте внесем ясность в понятия функциональной и структурной схем, так как многие не видят между ними разницы. Структурная схема должна отображать устройство в виде законченных функциональных блоков, показывать взаимосвязь между ними и отображать общий принцип работы всего устройства. Глядя на структурную схему, даже начинающий специалист, знакомый с азами предмета, должен понять, как «это» работает. Если такого понимания нет, то можно сказать, что такая структурная схема никуда не годится.
Функциональная схема — более подробная схема функциональных узлов (возможно, даже с элементами принципиальной схемы). Функциональная схема раскрывает принцип действия функционального блока или узла. Она, так сказать, более низкий уровень иерархии, чем схема структурная, но еще не является принципиальной схемой.
Точные структурные и функциональные схемы, как и точное ТЗ, как правило, могут «родиться» только после окончания разработки, но это не мешает создать их в «первом приближении» в самом начале работ. Эти схемы будут сопровождать вас на протяжении всего времени работы над проектом (и даже после, при поиске ошибок и анализе отказов). Так что рекомендуем отнестись к этому очень серьезно.
Чтобы дать читателю возможность умственно поразмяться и убедиться в этом, рассмотрим какой-нибудь нетривиальный сложный проект, например, робота (рис. 1).
Анализируя данную структурную схему, без особого труда можно увидеть узкие и ненадежные места, а также понять потенциальные возможности системы, оценить трудоемкость проектирования каждого функционального узла и т. п.
Структурная схема позволяет четко видеть взаимосвязь всех структурных звеньев проектируемого технического объекта. Всегда дает возможность оценить их взаимовлияние и важность. Особенно это ценно при структурном анализе надежности системы, так как, во-первых, позволяет увидеть «узкие места», присутствие и влияние дестабилизирующих факторов, а во-вторых, адекватно внести коррективы в структуру системы. То же относится и к схемам функциональным, но на более детальном уровне. Структурная схема зачастую помогает разделить проект на обособленные участки, поручить работу над ними разным инженерам или группам. К тому же, структурная схема позволяет не запутаться в сложном проекте и не попасть в цейтнот, грамотно распределив силы и время. Каждый разработчик проходил в своей жизни ситуации работы в условиях дефицита времени, когда силы были брошены «не туда», а теперь приходится, когда сроки поджимают, «гнать» работу, делая попутно массу ошибок. Как правило, ничем, кроме потери нервов, здоровья и доверия заказчика, это не заканчивается. Но будем считать, что с созданием структуры проектируемой системы и с функциональными схемами мы справились, теперь перейдем к следующему этапу.
Принципиальные схемы можно рассматривать как наиболее низкий уровень иерархии схем любых видов (в том числе структурных и функциональных). Общая принципиальная схема естественным образом представляет собой совокупность принципиальных схем функциональных узлов и блоков. О классических ошибках схемотехники не говорим, подразумеваем, что разработчик
достаточно квалифицирован, чтобы их не допускать. Кстати, всегда следует помнить один из «законов Мерфи», который гласит: «Квалифицированный специалист удачно избегает мелких ошибок, неуклонно двигаясь к какому-нибудь глобальному заблуждению». Это к разговору о структурной схеме. Знание основ схемотехники отнюдь не обеспечивает оптимального построения структуры системы в целом. Недаром есть две специальности со схожими названиями «схемотехник» и «системотехник». В современных условиях эти две специальности часто совмещаются одним специалистом, который не уделяет должного внимания системотехнике. Помните: если у вас возникли какие-либо непреодолимые технические трудности, то, возможно, стоит пересмотреть структурную схему. Всегда подтверждается мудрость: «Если что-то не получается, значит вы делаете не то или не тем способом».
Начинаем «ваять» принципиальную схему. Итак: разработчик обладает актуальной информацией о современной элементной базе и технологиях, перед ним структурная схема, квалификация достаточна для того, чтобы воплотить все это «в железе». Но и здесь его поджидает «чертик», толкающий «под руку».
Вот типичные упущения на этом этапе разработки, как правило, ведущие к снижению надежности.
• Неправильная интерпретация параметров радиоэлементов (РЭ) из справочных данных.
• Игнорирование показателей надежности и «насилование» РЭ в предельных режимах.
• Ошибки моделирования схем в системах типа Р8рке, отягощенные недостаточными инженерными расчетами.
• Недооценка ЭМС узлов и агрегатов устройства и вообще влияния помех и дестабилизирующих факторов.
• Пренебрежение физическими явлениями в РЭ и системе в целом.
• Отсутствие анализа типа «а что если...».
Неправильная интерпретация параметров РЭ из справочных данных Многие производители РЭ в рекламных целях приводят на заглавных листах техдокументации на РЭ максимально достижимые, лучшие параметры. И многие разработчики используют именно эти параметры, забывая посмотреть, при каких условиях они достижимы. А кроме наилучших есть еще и наихудшие. Кто сказал, что вам попался элемент с лучшими характеристиками? Хорошее правило — всегда исходить из наихудших параметров РЭ. Бывает, что разработчик вообще игнорирует такие неявные параметры, как допустимая мощность рассеяния корпуса РЭ, допустимое напряжение для резисторов или допустимый ток для конденсаторов. Для некоторых откровением является и то, что кроме средней мощности есть еще и пиковая,
которая также регламентируется. Некоторые производители выдумывают свои названия характеристик, что тогда делать? Совет один — внимательно читать документацию, вдумываться в физический смысл параметров, руководствоваться здравым смыслом.
Игнорирование показателей надежности и «насилование» РЭ в предельных режимах
Зачастую расчет надежности изделия не делается вовсе, но это не самое страшное, так как, при соблюдении несложных правил, в большинстве случаев показатели надежности всего изделия будут вполне удовлетворительными (исходя из показателей надежности РЭ). Ведь РЭ проектируются для работы в «нормальных» условиях и имеют при этом весьма неплохие показатели надежности. Задача — не выходить за границы «нормальных» условий эксплуатации РЭ, и тогда все будет хорошо. Речь, конечно, не идет об ответственных разработках, где отказы могут повлечь катастрофические последствия, и поэтому полный расчет надежности обязателен. Кстати, бывает, что данные, необходимые для полного расчета надежности, найти весьма проблематично, так как редко какой производитель публикует эти параметры в стандартных «даташитах». В этом случае соблюдение ряда несложных правил позволяет быть достаточно уверенным в надежной работе проектируемого узла. С точки зрения автора правила эти звучат так:
1) Коэффициент нагрузки элемента по и, I, Р (как по среднему, так и по импульсному значению) не должен превышать 0,75 от заявленного.
2) Нагрев корпуса РЭ также не должен превышать 0,75 от максимально допустимого (следует вообще избегать нагрева РЭ выше 70 °С).
3) Соотношение времени работы РЭ при среднем допустимом и пиковом значении параметров не должно быть более 10:1 (в случае, если такое соотношение не оговаривается в техдокументации на РЭ).
4) Допустим одновременно только один пиковый параметр (например, И или I, но не И и I одновременно).
5) Нагрев на каждые 20 °С в два раза увеличивает интенсивность отказов X.
6) Зависимость X от приложенного напряжения или протекающего тока — квадратичная.
7) Не ставить в схему «абы что» (с неизвестными параметрами).
8) Не полагаться на «авось» (только честный инженерный, хотя бы прикидочный, расчет). Некоторые могут возразить, что все это
«анахронизм», что так поступали во времена Советского Союза, а сейчас РЭ прекрасно работают и при 100-150 °С. Ага, и «.число п в военное время может достигать значения 4», только вот законы физики об этом не знают. И формулы для расчета X какими были 20 лет
назад, такими и остались. Так что автор рекомендовал бы все же придерживаться приведенных простых правил.
Например, для полупроводниковых приборов интенсивность отказов, как функция температуры, приложенного напряжения и тока, приблизительно выражается формулой:
Х(Тп, и, I) =
= Х(Тпшах, итах, 1шах)х(и/ишах)2х х(Шшах)2хехр[-Вх(1/Тп-1/Тпшах)],
где В = 6000 К; Тп и Тпшах в К (действительная и максимально допустимая температура перехода); и, итах, V (действительное и максимально допустимое напряжение на переходе); I, ішах, А (действительный и максимально допустимый ток через переход); Х(Тпшах, ишах, ішах) — интенсивность отказов при максимальных нагрузках и температуре.
Нетрудно заметить что интенсивность отказов X растет в 2 раза на каждые 20 °С и имеет квадратичную зависимость от и, I. То есть при снижении приложенного напряжения (и) или протекающего тока (I) в 2 раза, X падает в 4 раза. Соблюдение правила нагружать РЭ не более 75% обеспечивает уменьшение интенсивности отказов более чем в 3 раза! Снижение температуры снижает вероятность отказов всех видов, а также уменьшает деградацию параметров РЭ во времени. Снижение рабочего напряжения особенно актуально для высоковольтных приборов, так как значительно уменьшает вероятность электрического пробоя, а снижение токов — для сильноточных, так как препятствует процессу деградации металлизаций и контактных соединений. Конечно, это не догма и есть исключительные случаи, где такие правила невыполнимы, но тенденции ясны.
Ошибки моделирования схем в системах типа PSpice, отягощенные недостаточными инженерными расчетами
Среди коллег попадаются три вида инженеров. Первые наивно полагают, что системы схемотехнического моделирования могут все. Вторые — наоборот, не верят им вообще, и третьи — те, кто разумно использует такие системы, взяв на вооружение здравый смысл, теорию и известную долю скепсиса. Конечно, системы схемотехнического моделирования типа Рврісе не панацея, но очень мощный инструмент в умелых руках. И тут необходимо понимать, что есть ряд условий, которые необходимо помнить и соблюдать.
Во-первых: существует конечная точность машинных вычислений и точность алгоритмов численной математики, особенно это сказывается при анализе переходных процессов. «Накрутив не знаючи» параметры моделирования, можно получить абсолютно несуразные результаты, особенно на переходных процессах.
Во-вторых: правильность расчета определяется еще и корректностью предоставленных исходных данных. Это относится как к принципиальной схеме для моделирования, так и к математическим моделям РЭ, и здесь, к сожалению, далеко не всегда достижима желаемая полнота и достоверность исходных данных. Схема для моделирования может отличаться от реальной схемы, например, введением фиктивных сопротивлений, пренебрежимо малых, включенных последовательно с РЭ, или пренебрежимо больших, включенных параллельно некоторым узлам схемы. Математические модели РЭ могут учитывать далеко не все их параметры. Наиболее правильный путь — использовать математические модели, предоставляемые производителями РЭ, но даже и в этом случае нельзя гарантировать полную достоверность моделирования.
Системы схемотехнического моделирования — сложные программы, и ими нужно уметь пользоваться. Даже квалифицированному специалисту далеко не всегда под силу смоделировать некоторые схемы правильно. В таких случаях автор всегда вспоминает крылатую фразу «не знать — не стыдно, стыдно не учиться». Сегодня есть масса литературы по теории и практике моделирования в системах с расчетным ядром Р8рке, но, тем не менее, не всегда возможно достоверно рассчитать поведение схемы.
Резюме: системы моделирования — мощный инструмент в руках схемотехника, но требуют аккуратного обращения, грамотной подготовки исходных данных и интерпретации результатов. Желательно сделать прикидочный анализ «вручную» чтобы обезопасить себя от явных промахов. Всегда не мешает понимать, что же мы пытаемся смоделировать, и каков ожидаемый результат. И здесь «авось» тоже не проходит, иначе инженерный анализ превращается в профанацию. В принципе, любая САПР требует к себе внимательного отношения. Многие САПР (включая и среды программирования) имеют как потрясающие возможности разработки, так и потрясающие возможности допускать крайне коварные ошибки (ввиду своей сложности). Если уж действительно пользоваться инструментом, то необходимо подойти к его изучению как можно тщательнее.
Недооценка ЭМС узлов и агрегатов устройства и вообще влияния помех и дестабилизирующих факторов
Зачем нужны фильтрующие емкости, ограничительные цепи, стабилизация «рабочих точек» и т. п ? И так все будет работать. Конечно, будет — но только в «тепличных» условиях. Даже небольшие внешние воздействия в большинстве случаев способны нарушить нормальную работу таких узлов, не говоря уже об интенсивных помехах, температурных стрессах и просто воздействии времени. Вопросы ЭМС и влияния дестаби-
002
1ч РЕЭЕТ иСи +УСС
ХТА1_1
4_ ХТАІ.2
12_ РВО/АШ РОО/1«ГО
13_ РВІ/АІМ РйІ/ТХР
14_ РВ2 РР2/1М0
1Ь_ РВЗ/ОС1 РОЗ/ШИ
1Ь_ РВ4 РРЗ/Т0
1_/_ РВ5/МОБІ Р05/Т1
1«_ РВ5/МІБО Р05/ІСР
1«_ РВ5/БСК
20
10
+5 В
1*3 1К
ХР1
1 І-СР ВаскИдЫ+ (1 А)
— 2 1_С0 ВаскЫдМ— (1 А)
3,4 2РМ
АТ9082313 вОІС
\ЛТ1
ВСР54 БОТ-223
Рис. 2. Опасная схема подключения транзистора к МК (потенциальная «висящая база»)
002
1 1*Е8ЕТ иСи +УСС
5_ ХТАИ С№
4_ хтдьг
12_ РВО/АІІМ РЭ0/1*ХР
13_ РВ1/А1Ы1 Р01/ТХР
14_ РВ2 РР2/1М0
1Ь_ РВЗ/ОС1 РОЗ/1М1
16_ РВ4 РРЗ/ТО
11_ РВ5/М08І РР5/Т1
18_ РВ5/МІ80 РР5/ІСР
19_ РВБ/ЭСК
20
10
— 1*31К
АТ90Б2313 БОІС
1*2
1К
ХР1
+5 В
1 І-Сй ВаскІ-ід№+ (1 А)
2 1_Сй ВаскЬ|дЫ- (1 А)
2РШ
3,4
УТ1
ВСР54 эот-ггз
Рис. 3. Безопасная схема подключения транзистора к МК
лизирующих факторов естественным образом отпадают у разработчиков прецизионной аналоговой и силовой электроники, так как без учета этого большая часть схем будет просто неработоспособной. Сегодня очень большое число инженеров имеют дело с цифровой техникой, где данные вопросы не столь актуальны, да к тому же обилие анало-
говых (в том числе и прецизионных) микросхем высокой степени интеграции позволяет разрабатывать многие схемотехнические узлы просто пользуясь стандартными схемами из «даташитов». К сожалению, многие инженеры отказываются видеть дальше «дата-шитов» и забывают основы основ аналоговой схемотехники. Конечно, удобно строить
схему «из кубиков», но даже самые современные микросхемы требуют хоть какой-то обвязки, и в ряде случаев дополнительно к стандартной (например, ограничительные цепи по входам и выходам, фильтры питания, буферные каскады). Тут-то инженер, «плавающий» в вопросах аналоговой схемотехники и ЭМС, и допускает ошибки. Опасность их заключается в том, что они редко себя проявляют, а потому трудно устранимы, да еще часто и недостаточная квалификация разработчика позволяет им «укорениться» в изделии, если не навсегда, то надолго.
Что касается дестабилизирующих факторов, то всегда необходимо помнить, что такие вещи, как изменение условий эксплуатации в рамках ТЗ (колебания температуры, влажности, давления, механические нагрузки и т. п.), не должны приводить к отказам системы или ухудшению ее характеристик до недопустимых значений. Температурный и временной дрейфы параметров РЭ, деградация характеристик и т. п. также не должны остаться без внимания. Следует проанализировать возможные воздействия электромагнитных и электростатических полей, наведенных и кондуктивных помех, механических нагрузок. Эти воздействия могут быть как сгенерированы самой системой, так и действовать извне. В любом случае дестабилизирующие факторы не должны нарушать нормального функционирования изделия.
Пренебрежение физическими явлениями в РЭ и системе в целом
Пренебрежение физическими явлениями в РЭ и схеме в целом, равно, как и незнание их влияния, преподносит разработчику множество сюрпризов. Для того чтобы вопрос не казался простым, просто перечислю некоторые из них.
Эффекты в полупроводниках (Миллера, Эрли, критические скорости нарастания напряжений и токов и т. п.), емкость и индуктивность монтажа (и печатного в том числе), емкости, индуктивности выводов и другие паразитные параметры РЭ, градиент температур на печатной плате (особенно важно для прецизионных схем), температурные коэффициенты параметров РЭ, волновые эффекты в области ВЧ/СВЧ, а также проблемы электромагнитной совместимости (ЭМС), допустимые плотности токов для проводников и дорожек печатных плат, падение напряжения на проводниках (у меди тоже есть сопротивление), термо-ЭДС спаев, старение материалов и РЭ, деградация их характеристик (особенно в условиях высоких температур), временные и температурные дрейфы параметров ОУ, влияние влажности, запыленности и температуры в силовых и высоковольтных схемах, поверхностный пробой, ионизация воздуха и поляризация диэлектриков и т. п. Также нелишним будет помнить про физические свойства материалов: теплопроводность, теплоемкость, гигроскопичность,
РА1
1 ІП эти Оігі 3
С1 С2
0,1 мкФ —2 Г“ 0,1 мкФ
Рйі
РВ5/АОСО/^Ё8ЁТ РВ4/АОСЗ РВЗ/АОС2
РВ2/АОС1 /ТО/І ІЧТО/в^ І РВІ/АІМІ/ОСР/МІБО РВО/АІІМО/АРЕР/МОвІ
иСІІ
;к
АТТІЦІ5 БОІС
Усс
7805
Рис. 5. Схема, ведущая к перегрузке порта МК при программном сбое
с1
0,1 мкФ “^
т
ОА1
ІП эти Оігі
00*1
РВБ/АОСО/РЁвЁТ РВ4/АОСЗ РВЗ/АЭС2
РВ2/АЭС 1 /Т0/І МТО/Бр РВ1 /А1М1/ОСР/М1вО РВО/АІМО/АРЕР/МОвІ
иСи
К
Усс
7805
т
С2
0,1 мкФ
Рис. 6. Использование защитного резистора по входу МК (защита от перегрузки входа МК при программном сбое)
Рй1
_1 2 3
----- \\HL1 щ 47 +5В
1----------и---------------о—-
6___ОІІТВОАРО_І_ЕО
5
АТТ1МУ15_801С
Рис. 7. Пример нежелательного параллельного соединения выходных портов МК
(возможны перегрузки при программных сбоях)
Усс иСи РВ5/АОСО/РЕБЕТ
РВ4/АОСЗ
РВЗ/АОС2
1 В2/АОС1/ТО/1МТО/8СК
РВ1 /А1Ы1 /ОСР/МЮО
РВО/АІЧО^ЕР/МОБІ
прочностные характеристики, механические напряжения в РЭ и конструкциях во всем диапазоне температур эксплуатации.
И этот список еще не полон. Как же быть? Ну, во-первых, в какой-то конкретной схеме встречаются далеко не все из них. А во-вторых, необходимо выявить в схеме наиболее
ответственные узлы (например, прецизионные, силовые, высоковольтные и т. п.) и уже для них рассмотреть возможные физические явления. Решение данных проблем легче дается разработчику с опытом и широким кругозором, но, опыт, к сожалению, накапливается очень медленно.
DD1
Vcc
6ND
uCU
PB5/ADC0/RESET PB4/ADC3 PB3/ADC2 F)B2/ADC1 /TO/INTO/SCK PB1/AIN1/OCP/MISO PBO/AINO/AREF/MOSI
_1
2
з R1,
ATTINY15 SOIC
R2 r
R3 .
120 \\HL1+5b И к
120
120 ІЧІ OUTBOARD LED
Рис. В. Безопасная схема «запараллеливания» выходных портов МК
Отсутствие анализа типа «а что если...»
Интригующее начало, не правда ли? Да, это не анализ типа «Монте-Карло» или другой «классический», это, так сказать, анализ «невероятных» ситуаций. Но настолько ли уж невероятные? Приведем примеры. Посмотрите на фрагмент схемы, изображенной на рис. 2. А теперь представьте, что микроконтроллер (МК) «завис», и его выводы находятся в 2-состоянии или перепрограммированы на ввод. Что при этом будет с транзистором? А вот если бы узел был чуть-чуть изменен, как на рис. 3, то ничего бы не произошло.
Вот еще пример. Взгляните на схему сетевого ИП с гасящим конденсатором на рис. 4, а теперь представьте, что будет с элементами, если форма напряжения питания отличается от синусоидальной, например ввиду выбросов в сети или «дребезга» в подсоединитель-ной колодке или в паре «вилка-розетка»?
Согласитесь — не такие уж «невероятные» ситуации. Конечно, схема «обрастает» элементами защит от перенапряжений и становится весьма дорогой в реализации, но гораздо правильнее делать «так, как нужно». Таких примеров можно привести множество. Причем сюда же следует включать и анализ «невероятных» действий пользователя, например: нажатие всех кнопок управления одновременно, неадекватные ситуации действия, принудительное отключение питания и т. п. Зачем? Ну вот захотелось пользователю это сделать, физически это ведь возможно. В схемотехнике тоже нужна защита от «изобретательного» или неквалифицированного пользователя.
Сформулируем некоторые виды анализа, которые проводятся при «невероятных» ситуациях:
1) Анализ работы схемы при изъятии из нее программируемых или программно-конфи-гурируемых элементов. При этом все оставшиеся РЭ схемы должны работать в штатных режимах, не должно быть «висящих» баз и затворов, недопустимых выбросов напряжений и т. п.
2) Анализ работы схемы при изменении функций двунаправленных программируемых выводов (например, портов микроконтроллера (МК)). Взгляните на фрагмент схемы на рис. 5, 6 и представьте, что входы МК перепрограммировались на работу в режиме «выходов». Что с ними станет?
А включить дополнительный резистор практически ничего не стоит. Вообще любые двунаправленные порты следует рассматривать как порты вывода (то есть переключение этих портов в режим вывода с произвольным установлением на них как логического «0», так и логической «1» не должно приводить к перегрузкам элементов схемы и самих портов). Если вы уделяете особое внимание надежности устройства, то стоит провести такой анализ, ведь надежность МК или другого процессора тесно связана с его ПО, которое зачастую не блещет стабильностью работы. По тем же причинам схема, изображенная на рис. 8, более предпочтительна, чем показанная на рис. 7.
3) Анализ переходных процессов при ступенчатом изменении входных сигналов (в том числе и питающих напряжений) и нагрузок (в том числе обрывы и К. З.). Наиболее простой и наглядный способ — замена всех емкостей перемычками (или источниками напряжения с ЭДС «до переходного процесса»), а всех индуктивностей — обрывами (или источниками тока с токами «до переходного процесса»). Следует помнить, что при переходном процессе через емкость протекают «броски тока» и сама емкость рассматривается как К. З. (вспомните свойства источника напряжения), а на индуктивности появляются «броски напряжения» и сама индуктивность рассматривается как Х. Х., то есть обрыв (вспомните свойства источника тока). Проведя такую замену, вы легко увидите элементы, подверженные перегрузкам.
4) Анализ работы схемы и ПО при нештатных ситуациях. Например: обеспечение целостности данных при внезапном пропадании питания и активном обмене с энергонезависимой памятью, адекватность реакции системы на неправильные действия пользователя и т. п. Согласны, что всего предусмотреть невозможно, тут придется подумать как следует.
5) Анализ работы схемы в наихудших условиях эксплуатации, предусмотренных ТЗ, причем, когда все условия наихудшие одновременно.
6) Всегда полезно провести «статический» анализ живучести, «воздействуя» на входы, а иногда и выходы схемы киловольт-ными импульсами, например от эквива-
лента человеческого тела (последовательно соединенные RC 1,5 кОм/100 пФ ±10 кВ). При этом часто становятся видны «слабые места», схемотехнику которых, возможно, стоит пересмотреть. Как известно, воздействие «статики» — одна из наиболее частых причин выхода аппаратуры из строя, особенно это актуально для устройств, предназначенных для работы с оператором-че-ловеком, а также работающих в промышленных условиях, где возможно накопление зарядов статического электричества.
В заключение дополним этот раздел рядом
несложных правил, которые позволяют значительно повысить надежность работы схем
и облегчают их понимание.
1)Никогда не выводить небуферизирован-ные входы и выходы за пределы платы (исключение составляют компактные многоплатные конструкции).
2) Лучшее средство от помех по входам — опторазвязки.
3) Низкий импеданс входных цепей — неплохое средство против наведенных помех.
4) Длинные внешние соединения всегда должны быть гальванически развязаны.
5) Помеха по «земле» и питанию проникает в устройство ничуть не хуже, чем по сигнальному проводу (стараться не выводить линии питания далеко за пределы платы, а если это необходимо, то ставить в цепи питания фильтры).
6) Резисторы З0—100 Ом на входах МК (чем ближе к МК — тем лучше) значительно повышают помехоустойчивость.
7) В микропроцессорной системе обязателен супервизор питания, а также крайне желателен Watch Dog таймер (внутренние или внешние).
8) Каждому МК — свой блокировочный конденсатор! (И не забывать про другие цифровые микросхемы — 1 конденсатор на 2-З корпуса, а счетчикам, триггерам и регистрам — индивидуальные).
9) На ВЧ и «импульсах», проводах, дорожках печатной платы и выводах РЭ — индуктивности (примерно 1 нГн/мм).
10) Избегать совмещения в одном разъеме высоковольтных и сигнальных цепей, и если уж так произошло, то изолировать высоковольтные цепи «холостыми» штырями разъема.
11) Подстроечные элементы — злейший враг надежности и технологичности. Необходимо избегать их использования, лучше поставить дополнительную микросхему или модифицировать встроенное ПО. Лучшая схема та, которая не требует настройки («Система, требующая настройки и регулировки, обычно не поддается ни тому, ни другому («законы Мерфи»)).
12) Чем меньше номенклатурный ряд компонентов — тем лучше.
13) Прецизионные элементы действительно необходимы только в исключительных случаях.
14) Механические коммутаторы, как правило, необходимы также в исключительных случаях.
15) Силовые контакты механических коммутаторов необходимо снабжать искрогасящими цепями.
16) Начертание схемы должно быть близко к ГОСТ (все ж в России живем, да и требования там очень даже разумные, например, относительно минимального количества изгибов и пересечений, нумерации элементов сверху-вниз/слево-направо, группировки и т. п.).
17) Номиналы пассивных компонентов всегда указывать на схеме (зачастую единственный документ, доступный «сейчас», когда нужно срочно разобраться, — принципиальная схема).
18) Убедиться, что используемые в схеме компоненты еще «живы» (некоторые производители импортных компонентов снимают их с производства уже по прошествии 3-5 лет с начала выпуска).
19) Лучше не генерировать помехи, чем с ними бороться. (Вопрос больше к конструктивному исполнению устройства, но и схемотехники тоже касается. Из нескольких вариантов исполнения узла — потенциального источника помех — при прочих равных условиях лучше выбирать наименее «шумный».)
Рассмотрев схемотехнические аспекты,
завершим пока нашу беседу. В следующей
части статьи будут затронуты оставшиеся
вопросы: конструктивные, программные
проблемы, вопросы дизайна, тестирования
и документирования разработки. ■
Окончание следует Литература
1. Уразаев В. Г. Влагозащита печатных узлов. М.: Техносфера, 2006.
2. Усатенко С. Т., Каченюк Т. К., Терехова М. В. Выполнение электрических схем по ЕСКД. Справочник. М.: Издательство стандартов, 1989.
3. Хоровиц П., Хилл У. Искусство схемотехники. Том 1-3 / Перевод с англ. М.: Мир, 1993.
4. Воробьев Е. Как читать DATA SHEET на микросхемы // Электронные компоненты. 2008. № 3.
5. Маквецов Е. Н., Тартаковский А. М. Механические воздействия и защита радиоэлектронной аппаратуры. Учебник для вузов. М.: Радио и связь, 1993.
6. Тугов Н. М., Глебов Б. А., Чарыков Н. А. Полупроводниковые приборы. Учебное пособие для вузов. М.: Энергоатомиздат, 1990.
7. Воронин П. А. Силовые полупроводниковые ключи. M.: Издательский дом «Додэка-XXI», 2001.
8. Справочник конструктора РЭА: общие принципы конструирования / Под ред. Р. Г. Варламова. М.: Советское радио, 1980.
9. Павлов В. Н., Ногин В. Н. Схемотехника аналоговых электронных устройств. Учебное пособие для вузов. М.: Радио и связь, 1997.
10. Левин Б. Р. Теория надежности радиотехнических систем. М.: Советское радио, 1978.
