2.5.1. Основные положения метода структурного проектирования

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

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

Применение.  На протяжении всего этого параграфа мы будем иллюстрировать применение выдвинутых концепций на примере разработки системы управления стереоусилителем. Прототип нашего примера контроллер стереоусилителя, был разработан доктором Паррисом Нилом (Parris Neal) из Аэрокосмической Академии в Колорадо. Парис — превосходный инженер, разрабатывает стереоусилители мирового уровня. Любой из его проектов — это произведение искусства. Паррис разработал стереоусилитель, который может принимать звуковые сигналы от шести различных источников. Пользователь должен выбрать сигнал либо с помощью переключателей на передней панели корпуса усилителя (рис. 2.1), либо с дистанционного пульта управления, связанного со стереоусилителем по инфракрасному каналу. Паррис попросил первого автора этой книги разработать микропроцессорный контроллер для этого усилителя, используя 8 разрядный RISC МК компании Atmel. Ему было интересно на практике исследовать возможности МК Atmel в качестве низкостоимостного МК для следующих проектов.

а) Вид спереди

б) Плата с микроконтроллером

в) Вид сзади 

Рис. 2.1. Внешний вид стереоусилителя с дистанционным управлением

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

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

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

• При разработке устройства управления необходимо использовать МК компании Atmel.

После знакомства с этими первыми техническими требованиями был создан список вопросов, который должен был бы помочь разработчику более полно понять все особенности данного проекта:

• Что конкретно должен делать контроллер в ответ на выбор номера канала воспроизведения?

• Кто несет ответственность за интерфейс сопряжения между контроллером и стереоусилителем?

• Каковы электрические характеристики сигналов с передней панели усилителя и с удаленного пульта управления?

• Какие сигналы должен формировать контроллер для управления переключением каналов усилителя?

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

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

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

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

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

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

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

Рис. 2.2. Структура программы управления стереоусилителем

Рис. 2.3. Блок-схема алгоритма управления стереоусилителем

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

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

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

Рис. 2.4. Псевдокод программы управления стереоусилителем

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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