Лекция
Привет, Вы узнаете о том , что такое КАК ОБЕСПЕЧИТЬ НАДЕЖНОСТЬ РЭС, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое КАК ОБЕСПЕЧИТЬ НАДЕЖНОСТЬ РЭС , настоятельно рекомендую прочитать все из категории Надежность радиоэлектронных устройств.
Опытный образец отказал в самый неподходящий момент? Ваше устройство не прошло комплексные испытания у заказчика? «Сглючил» мобильный телефон, после переезда сгорел «телек», а в самую жару сломался кондиционер? Эх, не везет! Возможно. Но может быть причина в недостаточно проработанной схеме или конструкции устройства, возможно при разработке упущен какой-то ключевой момент? Если Вы читали предыдущую статью «почему техника ломается», то наверное уже догадываетесь … да, то самое забытое понятие «надежность». Данная статья ни в коей мере не претендует на полноту освещения столь обширной темы, как проектирование радиоэлектронных средств (РЭС), но в ней я постараюсь осветить. Проблемы дизайна типичные ошибки проектирования, приводящие к потенциальному (и в большинстве случаев реальному) снижению надежности разрабатываемой аппаратуры. Накопив некоторый опыт в разработке радиоэлектронных устройств, хочу поделиться им с коллегами-разработчиками. Конечно, видеть «грабли» не значит не наступать на них, тут каждый проходит через свои «шишки», но думаю идеи, изложенные на этих страницах, найдут отклик в умах многих разработчиков. Давайте вместе попробуем разобраться, что же такое «не везет» и как с ним бороться.
Как известно «везение» — категория не столько «везучих», сколько упорных и трудолюбивых. В данном случае именно так и есть, так как успех разработки всецело зависит от ответственности подхода к проектированию, его комплексности и широты охвата, целеустремленности и квалификации разработчика. Как уже было описано в предыдущей статье «Почему техника ломается, или что такое забытое понятие «надежность», надежность — категория комплексная, хотя и выражается одним, вполне конкретным числовым параметром — вероятностью безотказной работы. Так вот, при проектировании нужно уделять внимание всем аспектам, влияющим на показатели надежности. Рассматриваемые в здесь вопросы перекликаются с перечисленными в предыдущей статье. Будем считать, что читатель уже ознакомился предыдущей публикацией. Итак, начнем. Чтобы не запутаться попытаемся разделить все «пространство проблем» по категориям (в скобках будут указаны связи с проблемами, описанными вы предыдущей статье):
1. Организационные аспекты
2. Схемотехнические аспекты
3. Конструкционные аспекты
4. Программные проблемы
5. Проблемы дизайна
6. Задачи тестирования
7. Оформление конструкторской и пользовательской документации
Оставим за рамками этой статьи многие организационные проблемы и сконцентрируемся на одной — наиболее важной для разработчика — техническое задание (ТЗ). Это сокращение на кого-то наводит ужас, кто-то в очередной раз, увидя его, отмахивается, как от назойливой мухи, а кто-то воспринимает его со всей ответственностью и «в порядке вещей». Но, как бы то ни было, с ТЗ, в той или иной форме, приходится сталкиваться всем. Полное ТЗ сложный и многостраничный документ, во многом индивидуальный для каждой разработки. Возможно, что вообще универсального ТЗ не бывает, но все же есть базовые пункты, которых стоит придерживаться при его составлении. Известно из опыта, что где-то посередине пути к окончанию работ, начинают рождаться крамольные идеи о том, что вообще нужно было делать все по-другому. Бывает, что ТЗ по ходу работ неоднократно уточняется и согласовывается, и как правило, подтверждается один из «законов Мерфи»: «Только в конце работы мы обычно узнаем, с чего же нужно было начинать». Но, тем не менее, ТЗ позволяет выбрать нужное направление деятельности, определить сроки и «контрольные точки», трезво оценить объем работ и распределить силы. А потому, являясь базовым документом для начала работ ТЗ требует к себе пристального внимания. Необходимо помнить, что ТЗ как документ от заказчика разработчику, так и от разработчика — заказчику. Его составление процесс обоюдный и итерационный. В ходе составления ТЗ необходимо выяснить все спорные моменты, в противном случае согласование этих моментов с заказчиком на этапе окончания работ может легко перейти в правовую плоскость. Отсутствие ТЗ при разработке сродни отсутствию договора в гражданском праве. Составление грамотного ТЗ — целое искусство, но многие пренебрегают даже его облегченной версией, а зря. Чтобы можно было оценить важность данного документа, приведу типичные пункты ТЗ.
— Требования к характеристикам
— Требования по надежности
— Условия эксплуатации
— Специальные требования
Составление ТЗ, как я уже говорил, выходит за рамки данной статьи. Интересующимся можно посоветовать изучить соответствующие нормативные документы, а также посетить тематические сайты, посвященные разработке конструкторской документации.
Итак: ТЗ есть, что дальше? Теперь на основании этого ТЗ разработчик должен составить для себя (и для заказчика тоже) «план работ». План должен содержать примерные сроки выполнения ключевых этапов работ, сроки представления промежуточных контрольных результатов, и конечно срок окончания работ. В интервале от начала работ до сдачи результата разработчик волен варьировать сроки промежуточных этапов, однако, большое отклонение от назначенных сроков в контрольных точках — тревожный сигнал. На практике, конечно, редко удается выдержать в точности указанные сроки, но, по крайней мере, нужно стремиться попасть в отведенные временные рамки. Так что тут без плана никак, иначе разработка рискует затянуться на неопределенное время. Указанные выше проблемы обычно отсутствуют во «взрослых КБ» (но где они сейчас?) и, как правило, проявляются в небольших коллективах, в частных предприятиях, коих теперь большинство. Но даже при наличии ТЗ и плана работ — наиболее типичная и опасная ошибка — занижение сроков разработки. Причины, по которым это происходит - совершенно различны, от простой недооценки трудностей, до желания предложить заказчику более выгодные условия сотрудничества. Результат один — работа в цейтноте и в конечном счете - срыв сроков и ухудшение качества работ. Если у разработчика за плечами нет хотя бы нескольких крупных проектов (на которые затрачено по полгода работы), то можно смело умножать кажущиеся разумными сроки разработки на 1,5 или даже 2. «Ну это уж слишком!» - думаете? Проанализируйте все «узкие» и «скользкие» места в ТЗ и Вы почти наверняка согласитесь. Не спешите - лучше лишний день подумайте. Более опытные разработчики ошибаются с оценкой сроков значительно реже. Ну вот: ТЗ и план работ есть теперь можно приступать к самому интересному.
С чего начинается строительство здания? Правильно с фундамента. Так вот для принципиальной схемы, фундамент — схема структурная и функциональная. Если большинство специалистов действительно обладают достаточной квалификацией, чтобы не делать ошибок в отдельных узлах и каскадах принципиальной схемы, то в общем и целом, при отсутствии структурной схемы, разработчик часто двигается не в оптимальном направлении. Наличие структурной схемы позволяет начать проектирование устройства на «верхнем уровне иерархии», видеть его принципиальные недостатки и достоинства. В то время, как ее отсутствие, часто «зацикливает» разработчика на «частностях», препятствуя созданию оптимальной структуры устройства. А в дальнейшем, отсутствие структурной схемы значительно может осложнить модификацию разработки, анализ отказов и ремонт. Попробуйте, например, описать работу сложной технической системы (допустим ПК) без деления ее на функциональные блоки. Вряд ли получится, а если и получится, то все равно волей-неволей оперируем макропонятиями: «чипсет», «процессор», «шина» и т.п. То есть, структурируем сложную систему. Это вполне естественно. Но почему-то при разработке часто полностью игнорируется структурное представление разрабатываемого устройства. «Валить все в одну кучу» еще возможно при ведении проекта (хотя наверняка будут ошибки из-за отсутствия видения в целом), а уж по прошествии времени, разобраться в такой «каше» без детального описания и структурной схемы бывает очень тяжело. Да и анализ таких схем крайне и крайне затруднителен (особенно если он проводится не автором данной разработки, да и еще и при отсутствии пояснительной записки). Единственным оправданием отсутствия структурной схемы может быть, на мой взгляд, только простота проекта (глупо было бы рисовать структурную схему, например для несложного источника питания).
Не менее важна и схема функциональная. Давайте внесем ясность в понятия функциональной и структурной схем, так как многие не видят между ними разницы. Структурная схема должна отображать устройство в виде законченных функциональных блоков, показывать взаимосвязь между ними и отображать общий принцип работы всего устройства. Глядя на структурную схему, даже начинающий специалист, знакомый с азами предмета, должен понять как «это» работает. Если такого понимания нет, то можно сказать, что такая структурная схема никуда не годится. Функциональная схема — более подробная схема функциональных узлов (возможно даже с элементами принципиальной схемы). Функциональная схема раскрывает принцип действия функционального блока или узла. Она, так сказать, более низкий уровень иерархии, чем схема структурная, но еще не является принципиальной схемой.
Точные структурные и функциональные схемы, как и точное ТЗ, как правило, могут «родиться» только после окончания разработки, но это не мешает создать их в «первом приближении» в самом начале работ. Эти схемы будет сопровождать Вас на протяжении всего времени работы над проектом (и даже после, при поиске ошибок и анализе отказов). Так что рекомендую отнестись к этому очень и очень серьезно.
Чтобы дать читателю возможность умственно поразмяться и убедиться в этом, рассмотрим какой-нибудь нетривиальный сложный проект, например робота (рис.1).
Рис.1. Пример структурной схемы сложной технической системы (робота)
Анализируя данную структурную схему, без особого труда можно увидеть узкие и ненадежные места, а так же понять потенциальные возможности системы, оценить трудоемкость проектирования каждого функционального узла и т.п.
Структурная схема позволяет четко видеть взаимосвязь всех структурных звеньев проектируемого технического объекта. Всегда позволяет оценить их взаимовлияние и важность, особенно это ценно при структурном анализе надежности системы, т.к. во- первых: позволяет увидеть «узкие места», присутствие и влияние дестабилизирующих факторов, а во-вторых: адекватно внести коррективы в структуру системы. То же относится и к схемам функциональным, но на более детальном уровне. Структурная схема зачастую позволяет разделить проект на «обособленные» участки, поручить работу над ними разным инженерам или группам. К тому же, структурная схема позволяет не запутаться в сложном проекте и не попасть цейтнот, грамотно распределив силы и время. Каждый разработчик проходил в своей жизни ситуации работы в условиях дефицита времени, когда силы были брошены «не туда», а теперь приходится, когда сроки поджимают «гнать» работу, делая попутно массу ошибок. Как правило, ничем, кроме потери нервов, здоровья и доверия заказчика это не заканчивается. Но будем считать, что с созданием структуры проектируемой системы и с функциональными схемами мы справились, теперь требуется «набить» этот скелет «мясом».
Принципиальные схемы можно рассматривать как наиболее низкий уровень иерархии схем любых видов (в том числе структурных и функциональных). Общая принципиальная схема естественным образом представляет собой совокупность принципиальных схем функциональных узлов и блоков. О классических ошибках схемотехники не говорим, подразумеваем, что разработчик достаточно квалифицирован, чтобы их не допускать. Кстати, всегда следует помнить один из «законов Мерфи», который гласит: «квалифицированный специалист удачно избегает мелких ошибок, неуклонно двигаясь к какому-нибудь глобальному заблуждению». Это к разговору о структурной схеме. Знание основ схемотехники отнюдь не обеспечивает оптимального построения структуру системы в целом. Недаром есть две специальности со схожими названиями «схемотехник» и «системотехник». В современных условиях эти две специальности часто совмещаются одним специалистом, который не уделяет должного внимания системотехнике. Помните: если у вас возникли какие-либо непреодолимые технические трудности, то возможно стоит пересмотреть структурную схему. Всегда подтверждается мудрость: «если что-то не получается, значит Вы делаете не то или не тем способом».
Начинаем «ваять» принципиальную схему. Итак: разработчик обладает актуальной информацией о современной элементной базе и технологиях, перед ним структурная схема, квалификация достаточна для того, чтобы воплотить все это «в железе». Но и здесь его поджидает «чертик» толкающий «под руку». Вот типичные упущения на этом этапе разработки, как правило, ведущие к снижению надежности.
Неправильная интерпретация параметров РЭ из справочных данных
Многие производители РЭ, в рекламных целях приводят на заглавных листах техдокументации на РЭ максимально достижимые, лучшие параметры. И многие разработчики используют именно эти параметры, забывая посмотреть, при каких условиях они достижимы. А кроме наилучших есть еще и наихудшие. Кто сказал что Вам попался элемент с лучшими характеристиками? Хорошее правило — всегда исходить из наихудших параметров РЭ. Бывает, что разработчик вообще игнорирует такие неявные параметры как допустимая мощность рассеяния корпуса РЭ, допустимое напряжение для резисторов или допустимый ток для конденсаторов. Для некоторых откровением является и то, что кроме средней мощности есть еще и пиковая, которая так же регламентируется. Некоторые производители выдумывают свои названия характеристик, что тогда делать? Совет один — внимательно читать документацию, вдумываться в физический смысл параметров, руководствоваться здравым смыслом.
Игнорирование показателей надежности и «насилование» РЭ в предельных режимах
Зачастую расчет надежности изделия не делается вовсе, но это не самое страшное, т.к. при соблюдении несложных правил, в большинстве случаев показатели надежности всего изделия будут вполне удовлетворительными (исходя из показателей надежности РЭ). Ведь РЭ проектируются для работы «нормальных» условиях и имеют при этом весьма неплохие показатели надежности. Задача — не выходить за границы «нормальных» условий эксплуатации РЭ, и тогда все будет хорошо. Речь конечно не идет об ответственных разработках, где отказы могут повлечь катастрофические последствия и полный расчет надежности обязателен. Кстати, бывает что данные, необходимые для полного расчета надежности, найти весьма проблематично, т.к. редко какой производитель публикует эти параметры в стандартных «даташитах». В этом случае, также, соблюдение ряда несложных правил позволяет быть достаточно уверенным в надежной работе проектируемого узла. С моей точки зрения правила эти звучат так:
Некоторые могут возразить, что все это «анахронизм», что так поступали во времена Советского Союза, а сейчас РЭ прекрасно работают и при 100-150 °С. Ага, и «…число «π» в военное время может достигать значения 4», только вот законы физики об этом не знают. И формулы для расчета «λ» какими были 20 лет назад, такими и остались. Так что я бы рекомендовал все же придерживаться вышеприведенных простых правил.
Например, для полупроводниковых приборов интенсивность отказов, как функция температуры, приложенного напряжения и тока, приблизительно выражается формулой:
λ(Tп, U, I) = λ(Tпmax, Umax, Imax) х (U / Umax)2 х (I / Imax)2 х exp[–B х (1 / Tп–1 / Tпmax)]
Нетрудно заметить что интенсивность отказов «λ» растет в 2 раза на каждые 20 °С и имеет квадратичную зависимость от U, I. То есть при снижении приложенного напряжения (U) или протекающего тока (I) в 2 раза, «λ» падает в 4 раза. Соблюдение правила нагружать РЭ не более 75% обеспечивает уменьшение интенсивности отказов более чем в 3 раза! Снижение температуры уменьшает вероятности отказов всех видов, а также уменьшает деградацию параметров РЭ во времени. Снижение рабочего напряжения особенно актуально для высоковольтных приборов, т.к. значительно уменьшает вероятность электрического пробоя, а снижение токов — для сильноточных, т.к. препятствует процессу деградации металлизаций и контактных соединений. Конечно, это не догма и есть исключительные случаи, где такие правила невыполнимы, но тенденции ясны.
Ошибки моделирования схем в системах типа «PSpice», отягощенные недостаточными инженерными расчетами
Среди коллег попадаются три вида инженеров. Первые наивно полагают что системы схемотехнического моделирования могут все. Вторые — наоборот, не верят им вообще, и третьи — разумно используют такие системы, взяв на вооружение здравый смысл, теорию и известную долю скепсиса. Конечно системы схемотехнического моделирования типа «PSpice» не панацея, но очень мощный инструмент в умелых руках. И тут необходимо понимать, что есть ряд условий, которые необходимо помнить и соблюдать.
Во-первых: существует конечная точность машинных вычислений, и точность алгоритмов численной математики, особенно это сказывается при анализе переходных процессов. «Накрутив не знаючи» параметры моделирования можно получить абсолютно несуразные результаты, повторюсь, особенно на переходных процессах.
Во-вторых: правильность расчета определяется еще и корректностью предоставленных исходных данных. Это относится как к принципиальной схеме для моделирования, так и к математическим моделям РЭ, и здесь, к сожалению, далеко не всегда достижима желаемая полнота и достоверность исходных данных. Схема для моделирования может отличаться от реальной схемы, например, введением фиктивных сопротивлений, пренебрежимо малых, включенных последовательно с РЭ или пренебрежимо больших, включенных параллельно некоторым узлам схемы. Математические модели РЭ могут учитывать далеко не все их параметры. Наиболее правильный путь — использовать математические модели, предоставляемые производителями РЭ, но даже и в этом случае нельзя гарантировать полную достоверность моделирования.
Системы схемотехнического моделирования — сложные программы и ими нужно уметь пользоваться. Даже квалифицированному специалисту далеко не всегда под силу смоделировать некоторые схемы правильно. В таких случаях я всегда вспоминаю крылатую фразу «не знать — не стыдно, стыдно не учиться». Сегодня есть масса литературы по теории и практике моделирования в системах с расчетным ядром «Spice», но, тем не менее, не всегда возможно достоверно рассчитать поведение схемы.
Резюмируя, скажу, что системы моделирования мощный инструмент в руках схемотехника, но требуют аккуратного обращения, грамотной подготовки исходных данных и интерпретации результатов. Желательно сделать прикидочный анализ «вручную» чтобы обезопасить себя от явных промахов. Об этом говорит сайт https://intellect.icu . Всегда не мешает понимать, что же мы пытаемся смоделировать, и каков ожидаемый результат. И здесь «авось» тоже не проходит, иначе инженерный анализ превращается в профанацию. В принципе, любая САПР требует к себе внимательного отношения. Многие САПР (включая и среды программирования) имеют как потрясающие возможности разработки, так и потрясающие возможности допускать крайне коварные ошибки (ввиду своей сложности). Если уж действительно пользоваться инструментом, то необходимо подойти к его изучению как можно тщательнее.
Недооценка ЭМС узлов и агрегатов устройства и вообще влияния помех и дестабилизирующих факторов
Зачем фильтрующие емкости, ограничительные цепи, стабилизация «рабочих точек» и т.п ? И так все будет работать… Конечно будет — но только в «тепличных» условиях. Даже небольшие внешние воздействия в большинстве случаев способны нарушить нормальную работу таких узлов, не говоря уже об интенсивных помехах, температурных стрессах, и просто воздействии времени. Вопросы ЭМС и влияния дестабилизирующих факторов, естественным образом отпадают у разработчиков прецизионной аналоговой и силовой электроники, так как без учета этого, большая часть схем будет просто неработоспособной. Сегодня очень большое число инженеров имеют дело с цифровой техникой, где данные вопросы не столь актуальны, да к тому же обилие аналоговых (в том числе и прецизионных) микросхем высокой степени интеграции позволяет разрабатывать многие схемотехнические узлы просто пользуясь стандартными схемами из «даташитов». К сожалению, многие инженеры отказываются видеть дальше «даташитов» и забывают основы основ аналоговой схемотехники. Конечно удобно строить схему «из кубиков», но даже самые современные микросхемы требуют хоть какой-то обвязки, и в ряде случаев дополнительно к стандартной (например ограничительные цепи по входам и выходам, фильтры питания, буферные каскады). Тут-то инженер, плавающий в вопросах аналоговой схемотехники и ЭМС, и допускает ошибки. Опасность их заключается в том, что они редко себя проявляют, а потому трудно устранимы, да еще часто и недостаточная квалификация разработчика позволяет им «укорениться» в изделии если не навсегда, то надолго.
Что касается дестабилизирующих факторов, то всегда необходимо помнить, что такие вещи как изменение условий эксплуатации в рамках ТЗ (колебания температуры, влажности, давления, механические нагрузки и т.п.), не должны приводить к отказам системы или ухудшения ее характеристик до недопустимых значений. Температурные и временный дрейфы параметров РЭ, деградация характеристик и т.п., также не должны остаться без внимания. Следует проанализировать возможные воздействия электромагнитных и электростатических полей, наведенных и кондуктивных помех, механических нагрузок. Эти воздействия могут быть, как сгенерированы самой системой, так и действовать извне. В любом случае, дестабилизирующие факторы не должны нарушать нормального функционирования изделия.
Пренебрежение физическими явлениями в РЭ и системе в целом
Продолжая затронутую в предыдущем абзаце тему, скажу, что пренебрежение физическими явлениями в РЭ и схеме в целом, равно, как и незнание их влияния, преподносит разработчику множество сюрпризов. Для того, чтобы вопрос не казался простым, просто перечислю некоторые из них:
Эффекты в полупроводниках (Миллера, Эрли, критические скорости нарастания напряжений и токов и т.п.), емкость и индуктивность монтажа (и печатного в т.ч), емкости, индуктивности выводов и другие паразитные параметры РЭ, градиент температур на печатной плате (особенно важно для прецизионных схем), температурные коэффициенты параметров РЭ, волновые эффекты в области ВЧ/СВЧ, а так же проблемы электромагнитной совместимости (ЭМС), допустимые плотности токов для проводников и дорожек печатных плат, падение напряжения на проводниках (у меди тоже есть сопротивление), термо-ЭДС спаев, старение материалов и РЭ, деградация их характеристик (особенно в условиях высоких температур), временные и температурные дрейфы параметров ОУ, влияние влажности, запыленности и температуры в силовых и высоковольтных схемах, поверхностный пробой, ионизация воздуха и поляризация диэлектриков и т.п. Также нелишним будет помнить про физические свойства материалов: теплопроводность, теплоемкость, гигроскопичность, прочностные характеристики, механические напряжения в РЭ и конструкциях во всем диапазоне температур эксплуатации.
И этот список еще не полон. Как же быть? Ну, во-первых, в какой-то конкретной схеме, встречаются далеко не все из них. А во-вторых, необходимо выявить в схеме наиболее ответственные узлы (например: прецизионные, силовые, высоковольтные и т.п.) и уже для них рассмотреть возможные физические явления. Решение данных проблем легче дается разработчику с опытом и широким кругозором, но, опыт, к сожалению, накапливается очень медленно.
Отсутствие анализа типа «а что если …»
Интригующее начало, не правда ли? Да, это не анализ типа «Монте-Карло» или другой «классический», это так сказать, анализ на «невероятные» ситуации. Но настолько ли уж невероятные? Приведу примеры: Посмотрите на фрагмент схемы изображенной на рис.2. А теперь представьте, что микроконтроллер (МК) завис, и его выводы находятся в «Z» состоянии или перепрограммированы на ввод. Что при этом будет с транзистором? А вот если бы узел был чуть-чуть изменен, как на рис.3, то ничего бы не произошло.
Рис. 2. Опасная схема подключения транзистора к МК (потенциальная "висящая база")
Рис. 3. Безопасная схема подключения транзистора к МК
Вот еще пример. Взгляните на схему сетевого ИП с гасящим конденсатором на рис.4, а теперь представьте, что будет с элементами если форма напряжения питания отличается от синусоидальной, например виду выбросов в сети или «дребезга» в подсоединительной колодке или в паре вилка-розетка?
Рис. 4. Пример схемы, не учитывающей вероятные коммутационные перегрузки и выбросы в питающей сети
Согласитесь — не такие уж «невероятные» ситуации. Конечно, схема «обрастает» элементами защит от перенапряжений и становится весьма дорогой в реализации, но гораздо правильнее делать «так как нужно». Таких примеров можно привести множество. Причем сюда же следует включать и анализ «невероятных» действий пользователя, например: нажатие всех кнопок управления одновременно, неадекватные ситуации действия, принудительное отключение питания и т.п. Зачем? Ну вот захотелось пользователю это сделать, физически это ведь возможно. В схемотехнике тоже нужна защита от «изобретательного» или неквалифицированного пользователя. Сформулирую некоторые виды анализов проводимых для «невероятных» ситуаций:
1) Анализ работы схемы при изъятии из нее программируемых или программно-конфигурируемых элементов. При этом все оставшиеся РЭ схемы должны работать в штатных режимах, не должно быть «висящих» баз и затворов, недопустимых выбросов напряжений и т.п.
2) Анализ работы схемы при изменении функций двунаправленных программируемых выводов (например, портов микроконтроллера (МК)). Взгляните на фрагмент схемы на рис. 5 и 6 и представьте, что входы МК перепрограммировались на работу в режиме «выходов».
Рис. 5. Схема, ведущая к перегрузке порта МК при программном сбое
Рис. 6. Использование защитного резистора по входу МК (защита от перегрузки входа МК при программном сбое)
Что с ними станет? А включить дополнительный резистор практически ничего не стоит. Вообще любые двунаправленные порты следует рассматривать как порты вывода (т.е. переключение этих портов в режим вывода с произвольным установлением на них как лог.«0», так и лог.«1» не должно приводить к перегрузкам элементов схемы). Если Вы уделяете особое внимание надежности устройства, то стоит провести такой анализ, ведь надежность МК или другого процессора тесно связана с его ПО, которое зачастую не блещет стабильностью работы. По тем же причинам схема, изображенная на рис.8, более предпочтительна, чем показанная на рис.7.
Рис. 7. Пример нежелательного параллельного соединения выходных портов МК (возможны перегрузки при программном сбое)
Рис. 8. Безопасная схема "запараллеливания" выходных портов МК
3) Анализ переходных процессов при ступенчатом изменении входных сигналов (в т.ч. и питающих напряжений) и нагрузок (в т.ч. обрывы и К.З.). Наиболее простой и наглядный способ — замена всех емкостей перемычками (или источниками напряжения с ЭДС «до переходного процесса»), а всех индуктивностей — обрывами (или источниками тока с токами «до переходного процесса»). Следует помнить, что при переходном процессе через емкость протекают «броски тока» и сама емкость рассматривается как К.З. (вспомните свойства источника напряжения), а на индуктивности появляются «броски напряжения» и сама индуктивность рассматривается как Х.Х., т.е. обрыв (вспомните свойства источника тока). Проведя такую замену, Вы легко увидите элементы, подверженные перегрузкам.
4) Анализ работы схемы и ПО при нештатных ситуациях. Например: обеспечение целостности данных при внезапном пропадании питания и акивном обмене с энегонезависимой памятью, адекватность реакции системы на неправильные действия пользователя и т.п. Согласен, что всего предусмотреть невозможно, тут, как говорится, придется крепко «поморщить репу».
5) Анализ работы схемы в наихудших условиях эксплуатации, предусмотренными ТЗ, причем, когда все условия наихудшие одновременно.
6) Всегда полезно провести «статический» анализ живучести, «воздействуя» на входы а иногда и выходы схемы киловольтными импульсами, например от эквивалента человеческого тела (последовательно соединенные RC 1.5 кОм/100 пФ ±10 кВ). При этом часто становятся видны слабые места,
продолжение следует...
Часть 1 КАК ОБЕСПЕЧИТЬ НАДЕЖНОСТЬ РЭС
Часть 2 3. КОНСТРУКЦИОННЫЕ АСПЕКТЫ - КАК ОБЕСПЕЧИТЬ НАДЕЖНОСТЬ РЭС
Часть 3 7. ОФОРМЛЕНИЕ КД И ПД - КАК ОБЕСПЕЧИТЬ НАДЕЖНОСТЬ РЭС
Ответы на вопросы для самопроверки пишите в комментариях, мы проверим, или же задавайте свой вопрос по данной теме.
Комментарии
Оставить комментарий
Надежность радиоэлектронных устройств
Термины: Надежность радиоэлектронных устройств