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

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

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

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

Рисунок 1. Этапы проектирования

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

Типичные этапы проектирования микропроцессорных систем включают:

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

Человеческий фактор допускает неисправности и принятие неверных проектных решений. Также существуют аппаратурные дефекты в устройствах. Например, возможны следующие источники ошибок на этапах:

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

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

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

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

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

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

Основными методами контроля правильности проектирования являются: верификация, моделирование и тестирование.

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

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

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

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

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

Список литературы:

1. СибГУТИ [Электронный ресурс] / Проектирование микропроцессора на ПЛИС – Режим доступа: http://ict.sibsutis.ru/sites/csc.sibsutis.ru/files/courses/mps/mp.pdf–свободный. – загл. с экрана. – яз. рус. (дата обращения 22.12.2017).
2. Зотов В. Embedded Development Kit - система проектирования встраиваемых микропроцессорных систем на основе ПЛИС серий FPGA фирмы Xilinx. 2004. № 3.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· стремиться использовать уже известные типовые решения при поддержке пакетов САПР, ориентированных на разработку МПС (хотя творчески работающему специалисту хочется создать нечто оригинальное);

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

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

Рис.64

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

Рассмотрим более подробно каждый из этапов.

Формулировка проблемы.

На рис.65 дана последовательность работ, раскрывающая суть этапа "Формулировка проблемы".

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

Рис.65

Основными критериями достижения цели на этом шаге можно считать:

1. Быстроту разработки и организации серийного производства.

2. Эффективность применения (особенно его наглядность).

3. Минимальность затрат (быструю окупаемость). Некоторую по­мощь здесь может оказать табл.1.

Таблица 1

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

Для этого необходимо иметь полную математическую модель ТОУ (процесса) . В АСУ же решение нештатных ситуаций возлагается на человека и имеется возможность вмешательства в процесс. Решение о создании САУ может быть принято и без наличия точной модели ТОУ. Однако разработчик должен сознавать, что в этом случае потребует­ся проведение научных исследований для ее построения на этапе "Разработка модели управления" (см. рис.). Структурная концепция МПС в случае САУ представлена на рис.66.

Рис.66	Рис.67
Рис.68

Если принято решение о создании АСУ, приступают к определению ее макрофункций: сбор данных, советник оператора, непосредственное или супервизорное управление. Целью режима "Сбор данных" (см. рис.67) является накопление информации о состоянии ТОУ при различных условиях для построения модели процесса (когда она неполна или неизвестна) и/или управления им со знанием ситуации. Данный режим всегда присутствует как подзадача в более сложных макрофун­кциях. Его особенность - разомкнутый контур управления, т.е. в качестве решающего устройства используется человек, а МП выполняет функции предпроцессора сбора/предварительной обработки данных и постпроцессора для формирования управляющих воздействий по закону, заданному человеком. В режиме "Советник оператора" помимо сбора данных МПС вычисляет по известной модели (или ее части) управляющие воздействия и предлагает их оператору, который и принимает решение. Число управляемых переменных невелико, чтобы человек был в состоянии удержать их в поле зрения и своевременно реагировать на изменение ситуации.

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

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

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

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

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

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

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

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

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

При разработке архитектуры МПС (системный этап) необходимо решить следующие задачи:

Дать описание концептуальной структуры функционального поведения системы с позиций учета интересов пользователя при ее построении и организации вычислительного процесса в ней;

Определить структуру, номенклатуру и особенности построения программных и микропрограммных средств;

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

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

Основные этапы проектирования МПС приведены на рис. 3.1.

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

На уровне “черного ящика” МПС описывается внешними спецификациями, где перечисляются внешние характеристики.

Рис. 3.1. Этапы проектирования МПС

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

Программный уровень разделяется на два подуровня (команд процессора и языковый) и МПС интерпретируется как последовательность операторов или команд, вызывающих то или иное действие над некоторой структурой данных.

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

Схемный уровень базируется на описании работы элементов дискретных устройств.

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

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

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

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

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

Наблюдаемость – свойство системы, позволяющее проследить за поведением системы, за сменой ее внутренних состояний.

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

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

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

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

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

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

Контрольные вопросы

1. Поясните понятия модульности, магистральности и микропрограммируемости МПС при проектировании.

2. Перечислите задачи, решаемые разработчиками при проектировании МПС.

3. Перечислите основные этапы проектирования МПС.

4. Назовите концептуальные уровни описания МПС при проектировании и разработке.

5. Перечислить основные методы контроля правильности проектирования МПС.

6. Какими свойствами должна обладать проектируемая МПС для выполнения этапа ее отладки?

7. Перечислите виды неисправности при проектировании МПС.

8. Назовите причины физической и субъективной неисправностей МПС.

9. Поясните понятия: диагностика неисправности, отладка.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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