2.1 Модель вычислений

При создании прикладного ПО встроенных систем используется метод, основанный на модели (model-based design [2]). Метод состоит из двух этапов. На первом этапе создается модель вычислений (MoC – Model of Computation) системы, а на втором – разрабатывается ее программная реализация.

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

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

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

Связи между компонентами могут быть зафиксированы в виде графа, вершины которого и представляют компоненты. В таких графах к вычислениям относят процессы или задачи и соответственно называют графами задач или сетями процессов. Ребра графа представляют отношения между компонентами. Наиболее очевидным отношением между компонентами является причинная зависимость (вычисления могут быть выполнены только после завершения выполнения других вычислений). Она фиксируется графом зависимости. На рис. 64 приведен примерграф задач, где Т1, Т2, Т3, Т4, Т5 – задачи (Т1, Т2, Т3 являются независимыми). (1,8], например, обозначает, что 8 (время исполнения), а специально помеченные узлы обозначают доступ к ресурсам (ввод/вывод).

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

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

Рис. 64. Пример графа зависимости (граф задач)

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

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

Синхронная передача сообщений (или взаимодействие с блокировкой).

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

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

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

Модель фон Неймана. Эта модель основана на последовательном выполнении цепочек примитивных вычислений.

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

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

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

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

Комбинированные модели. Реальные языки программирования обычно объединяют определенные модели взаимодействия с организацией вычислений в компонентах. Например, SDL объединяет машины с конечным числом состояний с асинхронной передачей сообщений. Языки ADA и CSP объединяют модель фон Неймана с синхронной передачей сообщений.

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

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

Примеры использования (use cases). Для многих приложений целесообразно представлять потенциальные применения проектируемой системы. Такие применения фиксируются как use cases. Use cases описывают возможные применения системы и могут использовать разные способы обозначения. Для поддержки ранних стадий проектирования был разработан стандарт UML (Unified Modeling Language), содержащий стандартизованную форму для use cases [23]. На рис. 65 приведен пример нескольких use cases для устройства Автоответчик.

Рис. 65. Пример use cases

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

Диаграмма взаимодействия (MSC – Message Sequence Charts). Это чуть более детальный уровень представления, позволяющий подробно задавать последовательность сообщений между компонентами для реализации некоторого применения проектируемой системы. В MSC одно измерение (вертикальное) используется для представления последовательностей, а другое (горизонтальное) отражает взаимодействие компонент. MSC описывает частичный порядок между передачами сообщений и показывает возможное поведение проектируемой системы. MSC стандартизовано в UML. На рис. 66 показана MSC одного из use cases Автоответчика.