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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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