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

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

Рисунок 6.1 - Основные этапы разработки контроллера

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

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

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

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

При этом необходимо исходить из того, что максимальное использование аппаратных средств упрощает разработку и обеспечивает высокое быстродействие контроллера в целом, но сопровождается, как правило, увеличением стоимости и потребляемой мощности. Связано это с тем, что увеличение доли аппаратных средств достигается либо путем выбора более сложного МК, либо путем использования специализированных интерфейсных схем. И то, и другое приводит к росту стоимости и энергопотребления. Увеличение удельного веса программного обеспечения позволяет сократить число элементов контроллера и стоимость аппаратных средств , но это приводит к снижению быстродействия, увеличению необходимого объема внутренней памяти МК, увеличению сроков разработки и отладки программного обеспечения. Критерием выбора здесь и далее является возможность максимальной реализации заданных функций программными средствами при минимальных аппаратных затратах и при условии обеспечения заданных показателей быстродействия и надежности в полном диапазоне условий эксплуатации. Часто определяющими требованиями являются возможность защиты информации (программного кода) контроллера, необходимость обеспечения максимальной продолжительности работы в автономном режиме и другие. В результате выполнения этого этапа окончательно формулируются требования к параметрам используемого МК.

При выборе типа МК учитываются следующие основные характеристики:

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

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

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

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

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

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

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

Нельзя не упомянуть здесь о новой идеологии разработки устройств на базе МК, предложенной фирмой «Scenix». Она основана на использовании высокоскоростных RISC-микроконтроллеров серии SX с тактовой частотой до 100 МГц. Эти МК имеют минимальный набор встроенной периферии, а все более сложные периферийные модули эмулируются программными средствами . Такие модули программного обеспечения называются «виртуальными периферийными устройствами», они обеспечивают уменьшение числа элементов контроллера, времени разработки , увеличивают гибкость исполнения. К настоящему времени разработаны целые библиотеки виртуальных устройств, содержащие отлаженные программные модули таких устройств как модули ШИМ и ФАПЧ, последовательные интерфейсы, генераторы и измерители частоты, контроллеры прерываний и многие другие.

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

Структура

Структурная схема системы представлена на рисунке 3.2.

Рисунок 3.2 - Структурная схема МПС

МП является центральным блоком МПС. Он управляет всеми микросхемами и производит обработку данных.

МП формирует адрес на США и осуществляет обмен с СШД.

ОЗУ предназначено для хранения промежуточных данных.

ПЗУ предназначена для хранения кода программы и различных констант.

ППИ предназначен для подключения внешних устройств. К ППИ подключены АЦП, дискретные сигналы и ПП.

АЦП предназначен для преобразования аналогового сигнала с датчиков в цифровой код.

ПП предназначен для организации обмена по последовательному каналу между диспетчерским пунктом и МП.

Проектирование принципиальной схемы

К МПС должна обеспечивать:

• - опрос 7 аналоговых датчиков;
• - сбор 8 дискретных сигналов;
• - формирование 4 дискретных управляющих воздействий.

Расчет необходимого объема памяти данных производится по формуле

где и - количество аналоговых и дискретных входных сигналов соответственно; и - разрядность аналогового и дискретного сигналов.

В нашем случае и.

В итоге для хранения данных опроса датчиков необходимо

В качестве центрального блока системы выбран микроконтроллер КМ1816ВЕ51. Его основными преимуществами являются:

• - наличие резидентной памяти программ и данных;
• - наличие встроенного ПП;
• - 4 порта;
• - низкое энергопотребление;
• - встроенные таймеры-счетчики.

Для хранения данных используется встроенные 128 байт памяти программ МК. Программа будет храниться в резидентной памяти программ.

Для опроса аналоговых датчиков используется микросхема К572ПВ4. К преимуществам микросхемы относятся:

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

Так как у МК нет выходов генератора, для формирования тактового сигнала используется микросхема генератора К531ГГ1.

Для организации обмена информации с диспетчерским пунктом используется встроенный в МК приемопередатчик. Однако ПП КМ1816ВЕ51 передает данные с помощью пятивольтовых логических сигналов: единица представляется уровнем напряжения от 2,4 В до 5 В, а нуль - от 0 до 0, 8 В. При передаче по каналу RS-232 нуль и единица кодируются одинаковыми по величине (от 5 до 12 В), но разными по знаку сигналами.

Поскольку для передачи по RS-232 пятивольтовые логические сигналы должны быть преобразованы в сигналы другого уровня, в МПС используется микросхема MAX202E от Maxim. Она содержат преобразователь напряжения из +5 В в ±10 В и каскады, осуществляющие преобразование логических сигналов стандартного пятивольтного уровня по стандарту RS-232. Она содержит преобразователи логического уровня для двух приемников и двух передатчиков, из которых используется только один приемопередающий канал.

Принципиальная схема МПС приведена в приложении В.

К выводам XTAL1 и XTAL2 микроконтроллера DD1 подключается кварцевый резонатор ZQ1 на 12 МГц. Для более стабильного запуска выводы кварцевого резонатора соединены с общим проводом через конденсаторы С1 и С2 емкостью 21 пФ.

При подаче напряжения питания на микроконтроллер обязателен сброс микроконтроллера. С этой целью вход RST соединен с шиной питания через конденсатор С3 емкостью 6 мкФ и с общим проводом - через резистор R1 сопротивлением 100 кОм. В момент включения питания конденсатор разряжен, и вход сброса оказывается под потенциалом, близким к напряжению питания. Несмотря на снижение этого потенциала вследствие заряда С3, в течение десятка миллисекунд уровень сигнала на входе сброса остается единичным, и осуществляется корректный запуск микроконтроллера.

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

К линиям порта P0 МК DD1 подключены дискретные входные сигналы DDAT1-DDAT8. К линиям порта P1 подключена АЦС DA1. На линиях P1.0-P1.3 формируются дискретные управляющие воздействия DOUT1-DOUT4.

Так как аналоговые датчики, подключаемые к АЦС DA1 должны иметь выходным параметром напряжение, находящееся в диапазоне от 0В до 2,5В. Для преобразования токовых сигналов датчиков в сигнал напряжения используются резисторы R2-R13 .

Спецификация элементов представлена в приложении Г.

Разработка алгоритма работы МПС

МПС работает в следующей последовательности:

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

Блок-схемы алгоритмов программы работы МПС представлены в приложении Д, фрагмент кода программы - в приложении Е.

Расчет потребляемой мощности

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

Расчет мощности сведен в таблицу 3.4.

Таблица 3.1 - Расчет потребляемой мощности

Система потребляет мощность.

Устройство передачи данных

Для обеспечения обмена с диспетчерским пунктом используется преобразователь интерфейса MI 486. Он позволяет осуществлять прием/передачу данных через сеть Ethernet с компьютера со скоростью до 112 кбод.

Преобразователь интерфейса показан на рисунке 3.3.

Рисунок 3.3 - Преобразователь интерфейса MI 486

Технические характеристики:

• - выходной интерфейс: RS-232;
• - макс. скорость - до 112 кбод;
• - входной интерфейс Ethernet 10BaseT/100BaseT;
• - разъем RJ45.

Структурная схема устройства представлена в приложении А.

Данная микропроцессорная система состоит из следующих блоков: микропроцессор, ОЗУ, ПЗУ, программируемый параллельный интерфейс, аналого-цифровой преобразователь, таймер, дисплей.

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

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

Микропроцессор обращается к АЦП через программируемый параллельный интерфейс. Считывает информацию с выходов АЦП, заносит ее в ячейку памяти ОЗУ. Кроме того, МП на основе информации, полученной от датчика давления нефти на выходе станции, вычисляет регулирующее воздействие. Эта величина в виде цифрового кода передается исполнительный механизм.

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

Программное обеспечение системы хранится в ПЗУ (постоянном запоминающем устройстве). Операцией чтения управляет микропроцессор.

Программа, которая хранится в ПЗУ, предусматривает следующие операции системы:

Последовательный опрос датчиков;

Управление аналогово-цифровым преобразованием аналогового сигнала;

Регулирование давления нефти;

Индикация и сигнализация;

Реакция на потерю питания.

Разработка алгоритма системы

Структурная блок-схема алгоритма представлена в приложении Б.

Инициализация

На данном этапе происходит запись управляющих слов в РУС программируемого параллельного интерфейса. ППИ DD10 работает в нулевом режиме. Порты работают следующим образом: порт А - ввод, порт В - вывод, порт С - вывод. ППИ DD1 работает в нулевом режиме. Порты работают следующим образом: порт А - вывод, порт В - вывод, порт С - вывод.

Опрос датчиков

Опрос аналоговых датчиков производит АЦП. Дискретные датчики через порт А ППИ 1 опрашиваются микропроцессором.

Сохранение в ОЗУ

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

Управляющее воздействие

Микропроцессорная система анализирует поступившие данные и вырабатывает цифровое управляющее воздействие.

Разработка принципиальной схемы

Принципиальная схема устройства представлена в приложении Д.

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

Шина данных формируется с помощью шинного формирователя, выбор которого происходит подачей сигналов DT/R и OE.

Формирование системной шины происходит через дешифратор DD10 подачей сочетания сигналов M/IO, WR, RD.

Таблица 1 - Управляющие сигналы

Выбор ПЗУ, ОЗУ и других устройств происходит с помощью линий А13-А15 шины адреса через дешифратор. Ячейки ПЗУ располагаются с адреса 0000h.

Таблица 2 - Выбор устройств

Выбор порта или регистра управляющего слова ППИ осуществляется через линии A0, A1 шины адреса. На входы порта А PA0-PA7 ППИ DD12 подаются дискретные датчики; на входы порта В - с АЦП; на входы порта С подключены светодиоды.

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

Резисторы R2-R4 служат для преобразования унифицированного токового сигнала 4…20 мА в напряжение 1…5В.

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

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

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

С точки зрения контроля и диагностики МПС данный этап имеет следующие особенности:

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

Все эти причины делают задачи контроля и диагностики на этапе разработки МПС наиболее сложными, а требования к квалификации персонала весьма высокими.

Инструментальные средства контроля и диагностики на этом этапе должны отвечать следующим требованиям:

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

• возможность работы как с аппаратурой, так и с программным обеспечением.

  На этапе производства микропроцессорной системы на первый план выдвигаются требования:

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

  Контроль на этом этапе проводится с использованием отработанных тестовых программ . Тестирование проводится на специально разработанных контрольных стендах (в случае достаточно большого объема производства), предназначенных для выдачи тестовых воздействий и автоматического анализа реакций на них. Как правило, на этом этапе проводится только контроль работоспособности системы по принципу "годен - не годен". Определение места и характера неисправности проводится более высококвалифицированным персоналом в ходе отдельного процесса.

  Контроль в процессе эксплуатации , как правило, проще, чем на предыдущих этапах, по следующим причинам:

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

Однако требования к инструментальным средствам, предназначенным для эксплуатационного обслуживания МПС, весьма противоречивы.

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

Рассмотрим теперь собственно инструментальные средства контроля и отладки микропроцессорных систем.

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

Средства контроля и отладки должны:

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

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

Как показывает опыт разработки, производства и эксплуатации МПС, окончательный контроль работоспособности должен производиться на реальной аппаратуре и на рабочих тактовых частотах . Поэтому инструментальные средства должны обеспечивать решение задач генерации входных воздействий и регистрации выходных реакций в реальном времени. Наличие в МПС двунаправленных шин требует обеспечения возможности переключения контрольного оборудования с передачи на прием в течение одного периода тактовой частоты . Для контроля временных характеристик требуются весьма быстродействующие инструментальные средства. Кроме того, значительная длина тестовых программ вызывает потребность в использовании ОЗУ , контроллеров внешних устройств, блока питания, генератора тактовых импульсов и т. д.

При автономной отладке аппаратуры могут потребоваться приборы, умеющие:

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

Для автономной отладки аппаратуры на схемном уровне широко используются осциллографы, вольтметры, амперметры, частотомеры, генераторы импульсов , сигнатурные анализаторы. На более высоком уровне применяют внутрисхемные эмуляторы, эмуляторы ПЗУ , логические анализаторы , платы развития, а также специальные отладочные средства, которые встраиваются в БИС на этапе их разработки.

Этапы проектирования микропроцессорных систем

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

При проектировании многопроцессорных микропроцессорных систем, содержащих несколько типов микропроцессорных наборов, необходимо решать вопросы организации памяти, взаимодействия с процессорами, организации обмена между устройствами системы и внешней средой, согласования функционирования устройств, имеющих различную скорость работы, и т. д. Ниже приведена примерная последовательность этапов, типичных для создания микропроцессорной системы:
1. Формализация требований к системе.
2. Разработка структуры и архитектуры системы.
3. Разработка и изготовление аппаратных средств и программного обеспечения системы.
4. Комплексная отладка и приемосдаточные испытания.

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

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

Этап 3. После определения функций, реализуемых аппаратурой, и функций, реализуемых программами, схемотехники и программисты одновременно приступают к разработке и изготовлению соответственно опытного образца и программных средств. Разработка и изготовление аппаратуры состоят из разработки структурных и принципиальных схем, изготовления прототипа, автономной отладки.
Разработка программ состоит из разработки алгоритмов; написания текста исходных программ; трансляции исходных программ в объектные программы; автономной отладки.

Этап 4. см. Комплексная отладка.

На каждом этапе проектирования МПС людьми могут быть внесены неисправности и приняты неверные проектные решения. Кроме того, в аппаратуре могут возникнуть дефекты.

Источники ошибок

Рассмотрим источники ошибок на первых трех этапах проектирования.

Этап 1. На этом этапе источниками ошибок могут быть: логическая несогласованность требований, упущения, неточности алгоритма.

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

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

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

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

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

Проверка правильности проекта

Основные методы контроля правильности проектирования следующие: верификация - формальные методы доказательства корректности проекта; моделирование; тестирование.

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

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

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

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