ВИДЕО ОНЛАЙН
КОНСУЛЬТАЦИИ
Джаз

Статьи и обзоры систем автоматизации и безопасности

ПРЕДЫДУЩАЯ СТАТЬЯПРЕДЫДУЩАЯ СТАТЬЯСЛЕДУЮЩАЯ СТАТЬЯСЛЕДУЮЩАЯ СТАТЬЯ

24 июля 2014

Как обеспечить надежность РЭС

 

Опытный образец отказал в самый неподходящий момент? Ваше устройство не прошло комплексные испытания у заказчика? «Сглючил» мобильный телефон, после переезда сгорел «телек», а в самую жару сломался кондиционер? Эх, не везет! Возможно. Но может быть причина в недостаточно проработанной схеме или конструкции устройства, возможно при разработке упущен какой-то ключевой момент? Если Вы читали предыдущую статью «почему техника ломается», то наверное уже догадываетесь … да, то самое забытое понятие «надежность». Данная статья ни в коей мере не претендует на полноту освещения столь обширной темы, как проектирование радиоэлектронных средств (РЭС), но в ней я постараюсь осветить. Проблемы дизайна типичные ошибки проектирования, приводящие к потенциальному (и в большинстве случаев реальному) снижению надежности разрабатываемой аппаратуры. Накопив некоторый опыт в разработке радиоэлектронных устройств, хочу поделиться им с коллегами-разработчиками. Конечно, видеть «грабли» не значит не наступать на них, тут каждый проходит через свои «шишки», но думаю идеи, изложенные на этих страницах, найдут отклик в умах многих разработчиков. Давайте вместе попробуем разобраться, что же такое «не везет» и как с ним бороться.

Введение

Как известно «везение» — категория не столько «везучих», сколько упорных и трудолюбивых. В данном случае именно так и есть, так как успех разработки всецело зависит от ответственности подхода к проектированию, его комплексности и широты охвата, целеустремленности и квалификации разработчика. Как уже было описано в предыдущей статье «Почему техника ломается, или что такое забытое понятие «надежность», надежность — категория комплексная, хотя и выражается одним, вполне конкретным числовым параметром — вероятностью безотказной работы. Так вот, при проектировании нужно уделять внимание всем аспектам, влияющим на показатели надежности. Рассматриваемые в здесь вопросы перекликаются с перечисленными в предыдущей статье. Будем считать, что читатель уже ознакомился предыдущей публикацией. Итак, начнем. Чтобы не запутаться попытаемся разделить все «пространство проблем» по категориям (в скобках будут указаны связи с проблемами, описанными вы предыдущей статье):

 

1. Организационные аспекты

2. Схемотехнические аспекты

3. Конструкционные аспекты

4. Программные проблемы

5. Проблемы дизайна

6. Задачи тестирования

7. Оформление конструкторской и пользовательской документации

1. Организационные аспекты

Оставим за рамками этой статьи многие организационные проблемы и сконцентрируемся на одной — наиболее важной для разработчика — техническое задание (ТЗ). Это сокращение на кого-то наводит ужас, кто-то в очередной раз, увидя его, отмахивается, как от назойливой мухи, а кто-то воспринимает его со всей ответственностью и «в порядке вещей». Но, как бы то ни было, с ТЗ, в той или иной форме, приходится сталкиваться всем. Полное ТЗ сложный и многостраничный документ, во многом индивидуальный для каждой разработки. Возможно, что вообще универсального ТЗ не бывает, но все же есть базовые пункты, которых стоит придерживаться при его составлении. Известно из опыта, что где-то посередине пути к окончанию работ, начинают рождаться крамольные идеи о том, что вообще нужно было делать все по-другому. Бывает, что ТЗ по ходу работ неоднократно уточняется и согласовывается, и как правило, подтверждается один из «законов Мерфи»: «Только в конце работы мы обычно узнаем, с чего же нужно было начинать». Но, тем не менее, ТЗ позволяет выбрать нужное направление деятельности, определить сроки и «контрольные точки», трезво оценить объем работ и распределить силы. А потому, являясь базовым документом для начала работ ТЗ требует к себе пристального внимания. Необходимо помнить, что ТЗ как документ от заказчика разработчику, так и от разработчика — заказчику. Его составление процесс обоюдный и итерационный. В ходе составления ТЗ необходимо выяснить все спорные моменты, в противном случае согласование этих моментов с заказчиком на этапе окончания работ может легко перейти в правовую плоскость. Отсутствие ТЗ при разработке сродни отсутствию договора в гражданском праве. Составление грамотного ТЗ — целое искусство, но многие пренебрегают даже его облегченной версией, а зря. Чтобы можно было оценить важность данного документа, приведу типичные пункты ТЗ.

 

  • основания для разработки и назначение разработки
  • общее описание изделия
  • требования к изделию:

— Требования к характеристикам

— Требования по надежности

— Условия эксплуатации

— Специальные требования

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

 

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

Итак: ТЗ есть, что дальше? Теперь на основании этого ТЗ разработчик должен составить для себя (и для заказчика тоже) «план работ». План должен содержать примерные сроки выполнения ключевых этапов работ, сроки представления промежуточных контрольных результатов, и конечно срок окончания работ. В интервале от начала работ до сдачи результата разработчик волен варьировать сроки промежуточных этапов, однако, большое отклонение от назначенных сроков в контрольных точках — тревожный сигнал. На практике, конечно, редко удается выдержать в точности указанные сроки, но, по крайней мере, нужно стремиться попасть в отведенные временные рамки. Так что тут без плана никак, иначе разработка рискует затянуться на неопределенное время. Указанные выше проблемы обычно отсутствуют во «взрослых КБ» (но где они сейчас?) и, как правило, проявляются в небольших коллективах, в частных предприятиях, коих теперь большинство. Но даже при наличии ТЗ и плана работ — наиболее типичная и опасная ошибка — занижение сроков разработки. Причины, по которым это происходит - совершенно различны, от простой недооценки трудностей, до желания предложить заказчику более выгодные условия сотрудничества. Результат один — работа в цейтноте и в конечном счете - срыв сроков и ухудшение качества работ. Если у разработчика за плечами нет хотя бы нескольких крупных проектов (на которые затрачено по полгода работы), то можно смело умножать кажущиеся разумными сроки разработки на 1,5 или даже 2. «Ну это уж слишком!» - думаете? Проанализируйте все «узкие» и «скользкие» места в ТЗ и Вы почти наверняка согласитесь. Не спешите - лучше лишний день подумайте. Более опытные разработчики ошибаются с оценкой сроков значительно реже. Ну вот: ТЗ и план работ есть теперь можно приступать к самому интересному.

2. Схемотехнические аспекты

С чего начинается строительство здания? Правильно с фундамента. Так вот для принципиальной схемы, фундамент — схема структурная и функциональная. Если большинство специалистов действительно обладают достаточной квалификацией, чтобы не делать ошибок в отдельных узлах и каскадах принципиальной схемы, то в общем и целом, при отсутствии структурной схемы, разработчик часто двигается не в оптимальном направлении. Наличие структурной схемы позволяет начать проектирование устройства на «верхнем уровне иерархии», видеть его принципиальные недостатки и достоинства. В то время, как ее отсутствие, часто «зацикливает» разработчика на «частностях», препятствуя созданию оптимальной структуры устройства. А в дальнейшем, отсутствие структурной схемы значительно может осложнить модификацию разработки, анализ отказов и ремонт. Попробуйте, например, описать работу сложной технической системы (допустим ПК) без деления ее на функциональные блоки. Вряд ли получится, а если и получится, то все равно волей-неволей оперируем макропонятиями: «чипсет», «процессор», «шина» и т.п. То есть, структурируем сложную систему. Это вполне естественно. Но почему-то при разработке часто полностью игнорируется структурное представление разрабатываемого устройства. «Валить все в одну кучу» еще возможно при ведении проекта (хотя наверняка будут ошибки из-за отсутствия видения в целом), а уж по прошествии времени, разобраться в такой «каше» без детального описания и структурной схемы бывает очень тяжело. Да и анализ таких схем крайне и крайне затруднителен (особенно если он проводится не автором данной разработки, да и еще и при отсутствии пояснительной записки). Единственным оправданием отсутствия структурной схемы может быть, на мой взгляд, только простота проекта (глупо было бы рисовать структурную схему, например для несложного источника питания).

Не менее важна и схема функциональная. Давайте внесем ясность в понятия функциональной и структурной схем, так как многие не видят между ними разницы. Структурная схема должна отображать устройство в виде законченных функциональных блоков, показывать взаимосвязь между ними и отображать общий принцип работы всего устройства. Глядя на структурную схему, даже начинающий специалист, знакомый с азами предмета, должен понять как «это» работает. Если такого понимания нет, то можно сказать, что такая структурная схема никуда не годится. Функциональная схема — более подробная схема функциональных узлов (возможно даже с элементами принципиальной схемы). Функциональная схема раскрывает принцип действия функционального блока или узла. Она, так сказать, более низкий уровень иерархии, чем схема структурная, но еще не является принципиальной схемой.

Точные структурные и функциональные схемы, как и точное ТЗ, как правило, могут «родиться» только после окончания разработки, но это не мешает создать их в «первом приближении» в самом начале работ. Эти схемы будет сопровождать Вас на протяжении всего времени работы над проектом (и даже после, при поиске ошибок и анализе отказов). Так что рекомендую отнестись к этому очень и очень серьезно.

Чтобы дать читателю возможность умственно поразмяться и убедиться в этом, рассмотрим какой-нибудь нетривиальный сложный проект, например робота (рис.1).

 


 

Рис.1. Пример структурной схемы сложной технической системы (робота)

 

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

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

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

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

 

  • Неправильная интерпретация параметров радиоэлементов (РЭ) из справочных данных.
  • Игнорирование показателей надежности и «насилование» РЭ в предельных режимах.
  • Ошибки моделирования схем в системах типа «PSpice», отягощенные недостаточными инженерными расчетами.
  • Недооценка ЭМС узлов и агрегатов устройства и вообще влияния помех и дестабилизирующих факторов.
  • Пренебрежение физическими явлениями в РЭ и системе в целом.
  • Отсутствие анализа типа «а что если …»

 

Неправильная интерпретация параметров РЭ из справочных данных

Многие производители РЭ, в рекламных целях приводят на заглавных листах техдокументации на РЭ максимально достижимые, лучшие параметры. И многие разработчики используют именно эти параметры, забывая посмотреть, при каких условиях они достижимы. А кроме наилучших есть еще и наихудшие. Кто сказал что Вам попался элемент с лучшими характеристиками? Хорошее правило — всегда исходить из наихудших параметров РЭ. Бывает, что разработчик вообще игнорирует такие неявные параметры как допустимая мощность рассеяния корпуса РЭ, допустимое напряжение для резисторов или допустимый ток для конденсаторов. Для некоторых откровением является и то, что кроме средней мощности есть еще и пиковая, которая так же регламентируется. Некоторые производители выдумывают свои названия характеристик, что тогда делать? Совет один — внимательно читать документацию, вдумываться в физический смысл параметров, руководствоваться здравым смыслом.

 

Игнорирование показателей надежности и «насилование» РЭ в предельных режимах

Зачастую расчет надежности изделия не делается вовсе, но это не самое страшное, т.к. при соблюдении несложных правил, в большинстве случаев показатели надежности всего изделия будут вполне удовлетворительными (исходя из показателей надежности РЭ). Ведь РЭ проектируются для работы «нормальных» условиях и имеют при этом весьма неплохие показатели надежности. Задача — не выходить за границы «нормальных» условий эксплуатации РЭ, и тогда все будет хорошо. Речь конечно не идет об ответственных разработках, где отказы могут повлечь катастрофические последствия и полный расчет надежности обязателен. Кстати, бывает что данные, необходимые для полного расчета надежности, найти весьма проблематично, т.к. редко какой производитель публикует эти параметры в стандартных «даташитах». В этом случае, также, соблюдение ряда несложных правил позволяет быть достаточно уверенным в надежной работе проектируемого узла. С моей точки зрения правила эти звучат так:

 

  1. Коэффициент нагрузки элемента по U,I,P (как по среднему, так и по импульсному значению) не должен превышать 0.75 от заявленного.
  2. Нагрев корпуса РЭ также не должен превышать 0.75 от максимально допустимого (следует вообще избегать нагрева РЭ выше 70oС).
  3. Соотношение времени работы РЭ при среднем допустимом и пиковом значении параметров не должно быть более 10:1 (в случае если такое соотношение не оговаривается в техдокументации на РЭ).
  4. Допустим одновременно только один пиковый параметр (например U или I, но не U и I одновременно).
  5. Нагрев на каждые 20 °С в два раза увеличивает интенсивность отказов «λ»
  6. Зависимость «λ» от приложенного напряжения или протекающего тока — квадратичная.
  7. Не ставить в схему «абы что» (с неизвестными параметрами).
  8. Не полагаться на «авось» (только честный инженерный, хотя бы прикидочный, расчет).

 

Некоторые могут возразить, что все это «анахронизм», что так поступали во времена Советского Союза, а сейчас РЭ прекрасно работают и при 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», но, тем не менее, не всегда возможно достоверно рассчитать поведение схемы.

Резюмируя, скажу, что системы моделирования мощный инструмент в руках схемотехника, но требуют аккуратного обращения, грамотной подготовки исходных данных и интерпретации результатов. Желательно сделать прикидочный анализ «вручную» чтобы обезопасить себя от явных промахов. Всегда не мешает понимать, что же мы пытаемся смоделировать, и каков ожидаемый результат. И здесь «авось» тоже не проходит, иначе инженерный анализ превращается в профанацию. В принципе, любая САПР требует к себе внимательного отношения. Многие САПР (включая и среды программирования) имеют как потрясающие возможности разработки, так и потрясающие возможности допускать крайне коварные ошибки (ввиду своей сложности). Если уж действительно пользоваться инструментом, то необходимо подойти к его изучению как можно тщательнее.

 

Недооценка ЭМС узлов и агрегатов устройства и вообще влияния помех и дестабилизирующих факторов

Зачем фильтрующие емкости, ограничительные цепи, стабилизация «рабочих точек» и т.п ? И так все будет работать… Конечно будет — но только в «тепличных» условиях. Даже небольшие внешние воздействия в большинстве случаев способны нарушить нормальную работу таких узлов, не говоря уже об интенсивных помехах, температурных стрессах, и просто воздействии времени. Вопросы ЭМС и влияния дестабилизирующих факторов, естественным образом отпадают у разработчиков прецизионной аналоговой и силовой электроники, так как без учета этого, большая часть схем будет просто неработоспособной. Сегодня очень большое число инженеров имеют дело с цифровой техникой, где данные вопросы не столь актуальны, да к тому же обилие аналоговых (в том числе и прецизионных) микросхем высокой степени интеграции позволяет разрабатывать многие схемотехнические узлы просто пользуясь стандартными схемами из «даташитов». К сожалению, многие инженеры отказываются видеть дальше «даташитов» и забывают основы основ аналоговой схемотехники. Конечно удобно строить схему «из кубиков», но даже самые современные микросхемы требуют хоть какой-то обвязки, и в ряде случаев дополнительно к стандартной (например ограничительные цепи по входам и выходам, фильтры питания, буферные каскады). Тут-то инженер, плавающий в вопросах аналоговой схемотехники и ЭМС, и допускает ошибки. Опасность их заключается в том, что они редко себя проявляют, а потому трудно устранимы, да еще часто и недостаточная квалификация разработчика позволяет им «укорениться» в изделии если не навсегда, то надолго.

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

 

Пренебрежение физическими явлениями в РЭ и системе в целом

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

Эффекты в полупроводниках (Миллера, Эрли, критические скорости нарастания напряжений и токов и т.п.), емкость и индуктивность монтажа (и печатного в т.ч), емкости, индуктивности выводов и другие паразитные параметры РЭ, градиент температур на печатной плате (особенно важно для прецизионных схем), температурные коэффициенты параметров РЭ, волновые эффекты в области ВЧ/СВЧ, а так же проблемы электромагнитной совместимости (ЭМС), допустимые плотности токов для проводников и дорожек печатных плат, падение напряжения на проводниках (у меди тоже есть сопротивление), термо-ЭДС спаев, старение материалов и РЭ, деградация их характеристик (особенно в условиях высоких температур), временные и температурные дрейфы параметров ОУ, влияние влажности, запыленности и температуры в силовых и высоковольтных схемах, поверхностный пробой, ионизация воздуха и поляризация диэлектриков и т.п. Также нелишним будет помнить про физические свойства материалов: теплопроводность, теплоемкость, гигроскопичность, прочностные характеристики, механические напряжения в РЭ и конструкциях во всем диапазоне температур эксплуатации.

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

 

Отсутствие анализа типа «а что если …»

Интригующее начало, не правда ли? Да, это не анализ типа «Монте-Карло» или другой «классический», это так сказать, анализ на «невероятные» ситуации. Но настолько ли уж невероятные? Приведу примеры: Посмотрите на фрагмент схемы изображенной на рис.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. Низкий импеданс входных цепей - неплохое средство против наведенных помех.
  4. Длинные внешние связи всегда должны быть гальванически развязаны.
  5. Помеха по «земле» и питанию проникает в устройство ничуть не хуже, чем по сигнальному проводу (стараться не выводить линии питания далеко за пределы платы, а если это необходимо, то ставить в цепи питания фильтры).
  6. Резисторы 30-100 Ом на входах МК (чем ближе к МК — тем лучше) значительно повышают помехоустойчивость.
  7. В микропроцессорной системе обязателен супервизор питания, а также крайне желателен «Watch Dog»-таймер (внутренние или внешние). 
  8. Каждому МК — свой блокировочный конденсатор! (и не забывать про другие цифровые м/сх — 1 конденсатор на 2-3 корпуса, а счетчикам триггерам и регистрам — индивидуальные).
  9. На ВЧ и «импульсах», провода, дорожки печатной платы и выводы РЭ — индуктивности (примерно 1 нГн/мм).
  10. Избегать совмещения в одном разъеме высоковольтных и сигнальных цепей и если уж так произошло, то изолировать высоковольтные цепи «холостыми» штырями разъема.
  11. Подстроечные элементы — злейший враг надежности и технологичности Необходимо избегать их использования, лучше поставить дополнительную микросхему, или модифицировать встроенное ПО. Лучшая схема та, которая не требует настройки (“Система, требующая настройки и регулировки обычно не поддается ни тому, ни другому /«законы Мерфи»/).
  12. Чем меньше номенклатурный ряд компонентов — тем лучше.
  13. Прецизионные элементы действительно необходимы только в исключительных случаях.
  14. Механические коммутаторы, как правило, необходимы также в исключительных случаях.
  15. Силовые контакты механических коммутаторов необходимо снабжать искрогасящими цепями.
  16. Начертание схемы должно быть близко к ГОСТ (все ж в России живем, да и требования там очень даже разумные, например касательно минимального количества изгибов и пересечений, нумерации элементов сверху-вниз/слево-направо, группировке и т.п).
  17. Номиналы пассивных компонентов всегда указывать на схеме (зачастую единственный документ доступный «сейчас», когда нужно срочно разобраться — принципиальная схема).
  18. Убедиться, что используемые в схеме компоненты еще «живы» (некоторые производители импортных компонентов снимают их с производства уже по прошествии 3-5 лет с начала выпуска).
  19. Лучше не генерировать помехи, чем с ними бороться (вопрос больше к конструктивному исполнению устройства, но и схемотехники тоже касается. Из нескольких вариантов исполнения узла — потенциального источника помех, при прочих равных условиях, лучше выбирать наименее «шумный»).

3. Конструкционные аспекты

Спектр конструкционных вопросов очень широк. Полностью ответить на них в рамках журнальной статьи практически невозможно. Затрону лишь наиболее «популярные».

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

Одним из определяющих элементов надежности смонтированной печатной платы служат посадочные места РЭ. Правильно разработанное (с учетом технологии пайки и монтажа, разброса размеров РЭ) посадочное место обеспечит минимум брака при сборке изделия. В своей практике, при проектировании посадочных мест, я предпочитаю руководствоваться стандартом IPC-7351. Неплохим подспорьем в этом является «freeware» программа «PCB Matrix LP Viewer» (http://www.pcblibraries.com). В любом случае, этот вопрос желательно согласовывать с конструкторами и технологами сборочного производства, которые дадут необходимые рекомендации по допускам и зазорам (например, для операции автоматического монтажа). Не следует упускать из вида и вопрос грамотной маркировки посадочного места. Необходимая информация в слое маркировки, значительно упростит процесс монтажа, ремонта и обслуживания. Например: информация о контуре РЭ, цоколевка (маркировка ключевых выводов), позиционное обозначение, поясняющие надписи у разъемов, контрольных точек и подстроечных элементов.

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

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

Особое внимание следует уделить вопросам обеспечения нормальных терморежимов РЭ в смонтированном устройстве. Оптимальное размещение элементов на печатной плате позволяет избежать многих неприятных эффектов, например градиента температур (особенно важно для прецизионных узлов). В приведенном на рис.9 примере показано как градиент температур, вызванный неудачной компоновкой может привести к ухудшения характеристик схемы. Разница между элементами R3 и R4 достигает 20 °С, что для резисторов общего назначения значит уход сопротивлений от номинала на единицы процентов.


 

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

 

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


 

Рис. 10 Пример компоновки, приводящей к локальному перегреву печатной платы и компонентов, и пример компоновки для обеспечения более лёгкого теплового режима.

 

Показанный на рис.11 «тепличный» эффект гарантирует перегрев зоны «внутри» радиатора за счет поглощения теплового излучения, расположенными там РЭ, да еще и за счет изоляции конвекционных потоков.

 


 

 

Рис. 11 Пример неудачной с точки зрения отвода тепла компоновки

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

Не менее важным, чем обеспечение терморежимов, является и вопрос электромагнитной совместимости (ЭМС). Здесь как нельзя лучше подходит выражение что «профилактика лучше лечения». Лучше не бороться с помехами, а не создавать благоприятных условий для их возникновения. Наилучшим способом борьбы с импульсными и ВЧ помехами, является локализация цепей, генерирующих помеху, как правило это цепи, где протекают импульсные и ВЧ токи значительной величины («значительной» - понятие сугубо субъективное и индивидуальное для каждой конкретной разработки). Хорошим методом является минимизация трасс на печатной плате и соединительных проводов, для цепей с протекающими импульсными и ВЧ токами, а так же шунтирование емкостями по питанию тех узлов схемы, которые потребляют большие импульсные мощности. Если же источник помех локализовать не удалось, то нужно защищать подверженные помехам цепи и узлы схемы. Касательно слаботочных и прецизионных цепей есть ряд методов, описанных в литературе. Еще одним действенным методом защиты от помех является экранирование. Экранировать можно как источник помех, так и подверженные влиянию помех чувствительные узлы схемы. Экранирование может осуществляться как экранами (электромагнитными и электростатическими), так и элементами конструкции, а также полигонами и специальными слоями на печатной плате.

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

Для обеспечения разводки цепей «земли» и «питания» необходимо выделить функциональные блоки схемы, потребляющие большие токи, а также блоки, чувствительные к помехам по питанию. Выделив такие участки схемы, необходимо развести питающие и «земляные» цепи таким образом, чтобы получились независимые контуры протекания питающих токов для каждого блока. При этом «земли» всех блоков, а также общего источника питания, должны быть эквипотенциальны, причем как для постоянного тока, так и для ВЧ (для импульсных схем можно ориентироваться на частоту 3-й, а лучше 5-й гармоники самого короткого импульсного сигнала). Конструктивно, эквипотенциальность обычно достигается за счет разводки «земли» трассами наименьшей длины и наибольшего возможного сечения. Для примера рассмотрим топологию, показанную на рис.12.
 

 

Рис. 12 Теретически правильная схема разделения контуров питающих токов

 

Рис. 13 Схема разделения контуров питающих токов с учётом реального ненулевого импеданса "земляной" шины

 

Если «земли» всех блоков «А1»…«А4» и источника питания «U», с пренебрежимо малым внутренним сопротивлением, эквипотенциальны, то токи «I1»..«I4»в контурах питания, никоим образом не будут влиять друг на друга. На практике реализация данной топологии может быть затруднительна, в частности, проблематично обеспечить эквипотенциальность «земель» всех блоков. Как правило, реальная схема выглядит примерно так, как показано на рис.14, т.е. присутствует некая «земляная шина» с ненулевым (возможно даже довольно большим) импедансом. Задача разработчика — свести ее импеданс к минимуму.

Кроме снижения индуктивности и омического сопротивления проводников и печатных трасс, посредством вариации их «геометрии», довольно эффективным известным средством снижения импеданса по ВЧ является применение шунтирующих конденсаторов по питанию, которые позволяют нивелировать эти паразитные параметры. Исключив протекание импульсных токов по трассам питания и «земли», мы тем самым не допустим работы этих проводников в качестве «антенн», передающих помехи. Достигается это, как я сказал выше, с помощью грамотной топологии и применения шунтирующих (в данном случае можно сказать «накопительных») емкостей по цепям питания. Термин «накопительный» уместнее применять для емкостей, стоящих в непосредственной близости от узлов, потребляющих большие импульсные токи, при этом питание узла происходит именно за счет энергии накопленной в конденсаторе, исключая, таким образом, протекание импульсных токов по длинным подводящим трассам питания и «земли».

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

Если блоки независимы, или зависимы некоторые из них, то задача значительно упрощается. В этом случае можно, как показано на рис.15, сделать эквипотенциальными только «земли» связанных (зависимых) блоков «А2» и «А3», либо разделить контуры питания, снабдив каждый блок шунтирующей (накопительной) емкостью, а зависимые блоки соединить гальванически развязанным каналом, как например показано на рис.16.


 

Рис. 14 Пример комбинированной топологии разводки "земли" (эквипотенциальные и "независимые" "земляные" узлы)


 

Рис. 15 Пример топологии разводки с "независимыми" "землями" и гальваноразвязанным каналом взаимосвязи блоков

 

Другой путь решения проблемы развязки по питанию - применение ФНЧ, как показано на рис.17, более сложен в реализации, но иногда и более эффективен, позволяя в некоторых случаях упростить разводку питания (чаще применяется в ВЧ схемах), правда в этом случае также встает проблема обеспечения эквипотенциальности «земель». На практике часто приходится применять оба метода (истина, как обычно лежит где-то посередине).

 


 
Рис. 16 Пример топологии разводки цепей питания с фильтрами
 Вообще говоря, практически все меры по улучшению ЭМС направлены на минимизацию длин трасс протекания импульсных и ВЧ токов. Можно также сказать, что оптимальным решением будет локализация этих токов в контурах минимальных размеров, образованными компонентами блока и элементами монтажа.

Резюмируя вышесказанное, можно посоветовать делать хотя бы приблизительные инженерные расчеты. Посчитайте максимальные возможные перегрузки элементов, проанализируйте компоновку печатной платы с точки зрения ЭМС и обеспечения терморежимов силовых РЭ и прецизионных узлов. Проверьте разводку «земли», силовых, прецизионных и высокоимпедансных цепей. Необходимо оценить подверженность прецизионных и высокоимпедансных цепей наведенной помехе. Прецизионными считаем цепи величина напряжений или токов в которых, на шесть и более порядков меньше их абсолютных величин в данной схеме. Высокоимпедансными считаем цепи с модулем полного сопротивления десятки килоом и выше (как правило, это входы аналоговых каскадов, ОУ, АЦП и т.п.). Нужно проанализировать схему на стойкость к кондуктивным помехам по входам/выходам и другим цепям внешних связей. Также нелишним будет проверить стойкость изделия к ударам и вибрациям, в случае сомнений, провести хотя бы прикидочный статический и модальный анализ, естественно, если есть соответствующие требования ТЗ. Не стоит так же упускать из вида вопросы, связанные с монтажом (верификация посадочных мест, маркировка печатной платы, закрепление массивных РЭ), а так же вопросы связывающие компоновку изделия и дизайн.

4. Программные проблемы

Ввиду того, что программируемых компонентов превеликое множество, невозможно дать универсальные рекомендации, подходящие во всех случаях и ко всем программируемым компонентам, зато можно организовать свою работу таким образом, чтобы максимально упростить отладку, поиск ошибок и модификацию программ в будущем. Лично я не помню ни одного случая, чтобы написанная однажды программа никогда бы не улучшалась и не модифицировалась, ведь как известно (из тех же незабвенных «законов Мерфи») «любая полезная программа содержит ошибки».

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

В программировании существует такое мнение — «лучший комментарий к программе на малоизвестном языке — программа на известном языке». Так вот — язык, которым в совершенстве владеет каждый из нас — это естественный язык человеческого общения. Поэтому первое и наиглавнейшее правило при программировании — всегда не лениться комментировать исходные тексты. Причем никогда не откладывать это «на потом», ибо многие идеи воплощенные в коде, как идеи, очень быстро забываются, остается голый код, и понять потом суть программы, бывает очень непросто. Таким образом, комментарий должен быть неотъемлемой частью программы и писаться должен одновременно с ней. Чтобы написание комментария не воспринималось как ненужная рутина, выскажу пару мыслей по поводу того, как я это обычно делаю.

 

1) Всегда необходимо в заголовке программы (процедуры или функции) поставить блочный комментарий и детально описать суть ее работы, синтаксис (входные/выходные параметры), правила применения. Словесно описать общий алгоритм работы, именно общий, не вдаваясь в подробности, разве что указав некоторые ключевые моменты. А также всегда указывать версию и дату последней модификации.

2) Снабжать исходный текст строчными и блочными комментариями. Причем комментарий не должен повторять исходный текст - он должен пояснять его. Рассмотрим примитивный пример:


;

mov A,B ;    копируем регистр B в A

rol A ;           сдвигаем A влево на 1 разряд

add A,B ;     складываем A и B

 

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


; --                 Увеличим время работы XXX втрое.

mov A,B ;    В регистре «B» исходное время

rol A ;

add B,A ;     Теперь в регистре «B» утроенное время.

;-----------------


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

Очень хороший способ проверить правильно ли все прокомментировано — это попробовать «ухватить» суть программы только по одним комментариям.

Следующий «кит» на которого опирается «искусство программирования» это несомненно блок-схема. Можно долго спорить: нужна ли она или нет. Мое твердое убеждение: блок схема абсолютно необходима. Бытует мнение, что блок-схемы, называемые также структурными и функциональными (см. аналогию в разделе «Схемотехнические аспекты»), бесполезны для современных систем и кросс-средств разработки, где используются объектно-ориентированные языки программирования, всевозможные шаблоны и «визарды». Сами же встроенные системы имеют многозадачные операционные среды «на борту», самые модные «фишки», вплоть до «Java»-машин, TCP/IP и прочих «причиндалов «больших братьев» (ПК). И что-де блок-схема — жуткий атавизм времен Фортрана-IV.

Я не согласен с таким мнением. С помощью блок-схемы возможно описание практически любой программы, в том числе и многопоточных программ и программ для систем с прерываниями. Да — алгоритмические описания стали более сложными (даже визуально они все больше отходят от классических алгоритмов), сложнее стало и взаимодействие с операционной средой, и это тем более веский довод в их пользу. К тому же работа на уровне алгоритма — ключ к созданию эффективного и надежного ПО. До сих пор не угасают споры (уже не один десяток лет!) о преимуществах и недостатках разных языков и методов программирования, но все равно неизменной остается одна истина: лучшая оптимизация — алгоритмическая. Т.е. косвенно подтверждается почти забытый факт, что любая программа, на любом языке, начинается не с объявления переменных, функций и определений, а именно с алгоритма. По моему глубокому убеждению, настоящий программист (не путать с «кодером») реализуя свои идеи, оперирует именно алгоритмами, и среда в которой он сегодня работает — это всего лишь инструмент (именно на сегодня). Если разработчик серьезно собирается заниматься «soft-поддержкой» своего изделия, то наличие блок-схемы значительно упростит процесс модификации ПО, не говоря уже про поиск и исправление ошибок. К тому же вопрос трансляции встроенного ПО на другие платформы не такой простой как может показаться. Большинство встроенных систем по-своему уникальны и зачастую их ПО жестко привязано к аппаратным ресурсам. Действительно сложную программу просто перенести на другую платформу только если она функционирует под управлением какой-нибудь известной стандартной ОС. А если это «вещь в себе», то неизбежно возникают проблемы переносимости, какими бы высокоуровневыми языками не пользовался программист. Наличие в этом случае грамотной блок-схемы значительно упрощает ситуацию.

Очередным непростым этапом разработки надежного встроенного программного обеспечения, является тестирование. Это очень ответственный и зачастую долгий процесс. И тут как нельзя кстати будет наличие под рукой блок-схемы. По своему опыту могу сказать, что подавляющее большинство ошибок находится именно при анализе алгоритма, т.е. блок-схемы. Методики тестирования ПО у каждого программиста свои. Кому-то нравится многократно прогонять программу в симуляторе, кто-то пользуется аппаратными интерфейсами отладки, кто-то вооружившись приборами отлаживает программу в реальном времени. Все эти методы по своему хороши и обладают каждый своими плюсами и минусами, но главное, чтобы этому процессу было уделено самое пристальное внимание. Лучше всего начинать тестирование в процессе написания программы, что при применении подхода «структурного программирования» не составляет большого труда, так как любой пограммный «кирпичик», будь то функция, подпрограмма или даже целая ветвь алгоритма, может быть автономно проверен и «вылизан до блеска».

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

Итак: культура программирования. Принципов здесь не так много и важнейшие из них следующие:

 

  1. При проектировании ПО, с успехом можно применять подход к проектированию сложных систем, когда на уровне более общей структурной схемы определяются принципиальные моменты взаимодействия программных и аппаратных ресурсов.
  2. Необходимо стремиться, по возможности, к структурному программированию (если нет крайне жестких ограничений по аппаратно-программным ресурсам). Каждая подпрограмма и функция в идеале должна быть автономной законченной и отлаженной единицей, этаким «черным ящиком», дали задание — получили результат.
  3. Из п.2 вытекает естественное желание разделения функциональности по специализированным программным и аппаратным модулям. Как правило, опытный программист встроенных систем эффективно распределяет аппаратные ресурсы программируемого компонента в соответствии с общим алгоритмом работы всего устройства (опять блок схема).
  4. Из п.3 вытекает естественная потребность оформления исходных текстов в виде относительно небольших и относительно самостоятельных программ, подпрограмм и процедур, хранящихся в отдельных файлах. Написание всей программы в виде одной большой «простыни» - признак «плохого тона». К тому же с такой программой, как правило, крайне неудобно работать.
  5. Комментарии!!! Как общие алгоритмические, так и применительно к входным/выходным параметрам подпрограмм и функций (см. выше).
  6. Все глобальные константы и переменные, необходимые для работы программы должны быть описаны в одном месте (файле). Как правило, большинство систем программирования поддерживают многофайловые проекты (когда исходный тест программы — совокупность файлов — программных модулей и процедур). Так вот именно в одном файле должны быть декларированы и подробно описаны глобальные константы и переменные и соответственно изменяться они должны только в этом одном файле.
  7. Никогда не использовать в исходных текстах числовые константы. Все числовые константы должны быть именованы и описаны в соответствии с п.6.
  8. Использовать только подходящие по смыслу имена подпрограмм, переменных и адресные метки. «Абракадабра» в метках и именах, или безликие идентификаторы (типа «label1», «label2», «file1» и т.п.) крайне затрудняют понимание исходного текста программы.
  9. Головная программа проекта, или файл описания переменных должны содержать краткое функциональное описание всех подпрограмм, процедур и функций.
  10. Снабдить головную программу или файл описания пояснениями принципиальных особенностей проекта (например: какие должны быть ключи компиляции и наименование среды разработки, какова должна быть конфигурация программируемого компонента, если она задается дополнительными средствами, и т.п.). А также описать в общих словах суть и алгоритм работы всей программы.
  11. Визуально структурировать исходный текст, пользуясь отступами, выравниванием и т.п. Искусно форматированный исходный текст естественным образом позволяет «читать» программу функциональными блоками.
  12. Всегда делать внятные и в меру подробные описания блок-схем, переменных и констант, программных текстов и т.п. Желательно исходить из того, что «исходник» должен понять (конечно, приложив немного умственных усилий), абсолютно сторонний программист. Такой подход позволит в дальнейшем, даже по прошествии некоторого времени, легко вспомнить суть программы и подправить ее в случае необходимости. А уж о корпоративной работе (когда проект может «кочевать» от разработчика к разработчику) я вообще молчу, здесь это условие просто обязательно.
  13. Имена переменных, констант, подпрограмм и меток в блок-схеме и исходном программном тексте должны совпадать.
  14. Блок-схема должна быть всегда актуальной, т.е. всегда должно быть соответствие между блок-схемой и программным текстом. Сначала необходимо вносить изменения в блок-схему, и только потом в программный текст. Если действовать наоборот, то есть большой риск внести в программу ошибки (получится как в расхожей хохме: «в новой версии программы исправлены старые ошибки и добавлены новые» :).

5. Проблемы дизайна

Вопрос настолько широк, что обсуждать его в рамках данной статьи не представляется возможным. Позволю себе лишь самые общие высказывания касательно данной области. Одной из основных точек соприкосновения проблем дизайна и обеспечения надежности является эргономика. Помимо внешнего вида изделия, как воплощения полета мысли дизайнера, существует еще и эргономика, как направление создания удобных для человека вещей. Частенько именно эргономика страдает. За множеством модных интерфейсов и «лампочек» часто не найти нужных органов управления, которые, казалось бы должны быть на первом месте. Излишне броская или не в меру яркая индикация (как впрочем и излишне блеклая и незаметная) часто мешает восприятию необходимых данных. Как первейший элемент ответственный за эффективность взаимодействия человека с техникой, именно эргономика самым важным образом влияет на надежность этого взаимодействия. Не нужно забывать, что в соответствии с теми же «законами Мерфи»: «любая система, зависящая от человеческой надежности — ненадежна», и задача разработчика свести влияние «человеческого фактора» к минимуму. На втором месте стоит сопряжение дизайнерских решений с конструкционными и технологическими решениями проектируемого изделия. Такие вещи как материаловедение, результаты конструкционных расчетов (тепловых, прочностных, ЭМС и т.п.), технологии производства и сборки должны учитываться при создании дизайн-концепции изделия. 

6. Задачи тестирования

На самом деле тестирование технических решений идет всегда параллельно разработке (аналогично рекомендации начинать тестирование ПО уже в процессе его написания). В принципе, разработка устройства, в некотором роде и есть мысленное тестирование на возможность работы в разных условиях. Помимо традиционного макетирования и программного моделирования всегда полезно проверять работу узлов схемы в условиях, приближенным к рабочим. Гораздо меньше сюрпризов преподносит система, построенная из отлаженных и испытанных ранее узлов. Это конечно не отменяет финальных испытаний устройства на соответствие требуемых в ТЗ характеристик. Для облегчения процесса тестирования, как в последующем и процесса обслуживания или ремонта, необходимо предусмотреть на схемах и печатных платах необходимый набор контрольных точек, диагностических разъемов и т.п. При массовом производстве устройства, конечно необходимо обеспечить процедуру выходного контроля изделий по ряду важнейших параметров, и естественно разработать грамотную методику тестирования. В некоторых случаях бывает нелишне подумать и о входном контроле качества компонентов. Качественная проверка, как и разработка вообще, немыслима без парка хороших измерительных приборов, которые далеко не всегда есть в наличии. Видимо ввиду их дороговизны разработчики часто пользуются весьма ограниченным набором приборов. По правде сказать, многие задачи действительно решаются методами косвенных измерений. Тут главное грамотно представлять: что хотим измерить, с какой точностью, и какими способами этого можно достичь. Контролировать приборами результат разработки необходимо всегда, не надеясь на характеристики комплектующих (так как кроме характеристик есть еще схемотехника, физика, банальный брак РЭ и многое другое). Ну и напоследок выскажу мысль, что изготовленный удачно один образец еще ничего не значит. Статистика и еще раз статистика. Чтобы дать заключение о работоспособности изделия (а в особо ответственных случаях даже отдельного узла) требуются испытания ряда аналогичных изделий. Часто, к сожалению, таким испытанием служит выход устройства «в серию». Чтобы избежать проблем с «серийным» изделием процесс тестирования необходимо проводить тщательно и ответственно. 

7. Оформление КД и ПД

Тут особо распространяться не буду. Скажу лишь, что созданием качественной конструкторской и пользовательской документации сегодня пренебрегает подавляющее большинство разработчиков. А ведь хорошая конструкторская документация это и дальнейшая техподдержка изделия и его модификация и анализ отказов, и многое, многое другое. Создание грамотной конструкторской документации сопряжено с трудностями использования САПР и библиотеками УГО в отечественных стандартах, но эти трудности преодолимы (есть и коммерческие библиотеки, да и самому можно «нарисовать» необходимый минимум в соответствии с ГОСТ). Игнорирование ГОСТ при создании конечной КД, на мой взгляд, крайне нежелательно, так как во-первых: вносит путаницу (и ошибки) в документацию, а во-вторых: значительно затрудняет техническое сопровождение изделия (особенно разными специалистами).

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

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

Заключение

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

 

Рис. 17 Ключевые этапы обеспечения надёжности РЭС при разработке

 

Статья конечно не охватывает всех проблем, возникающих при разработке РЭС и влияющих на ее надежность. Не были, например, затронуты специальные конструкционные и схемотехнические методы обеспечения надежности, такие как различные способы резервирования, проектирование по результатам анализа критичности отказов, разработка устойчивых к сбоям программных решений и т.д. «За кадром» (или затронутыми вскользь) остались также многие конструкционные методы повышения надежности, такие как компоновка изделия, вопросы защиты от ударов и вибраций, экранирование, проектирование печатных плат, пыле и влагозащита и много чего еще. Это специальные вопросы, о которых при проектировании РЭС не стоит забывать, и ответы на которые заинтересованный читатель может найти в специальной литературе. Но, тем не менее, наиболее «популярные» общие проблемы обеспечения надежности РЭС при разработке я постарался осветить. В некоторых случаях даны конкретные рекомендации, в иных, просто указано на проблему, и тут уже задача разработчика не упустить ее из виду и проработать методы ее решения. В любом случае это не набор инструкций «как нужно делать», а скажем некий «сборник рецептов». Воспринимать их или нет — личное дело каждого. Скажу лишь, что эти рекомендации родились не за один день, а являются результатом работы над многими проектами. Их соблюдение не раз облегчало мне мою инженерную деятельность. Предвижу возражения: «Но ведь разработка будет длиться долго, и постоянно будет «спотыкаться» об эти правила!» Да, не всегда все просто, но когда соблюдение подобных правил войдет в систему, Вы сами уже не сможете работать по-другому, потому что вознаграждением будет — безотказная работа спроектированной аппаратуры и минимум проблем с заказчиком, ведь как известно лучше «медленно запрягать, но быстро ехать». К тому же такой подход обеспечивает регламент ведения работ и четкое понимание того что, когда, зачем и как нужно делать. Ведь согласитесь, никому не захотелось бы покупать автомобиль, изготовленный на заводе, где правит принцип «сделаем как-нибудь». Так почему же при проектировании РЭС мы, разработчики, такое себе частенько позволяем?

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


Ковалев Владимир Викторович

директор ООО "Новус-Лаб" /"Novus-Lab" Ltd./

 

ЗАКАЗ ЗВОНКА