ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ВСТРОЕННЫХ СИСТЕМ

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

Драйверы устройств это библиотеки программ для инициализации аппаратных средств, управления доступа к ним элементами вышестоящего уровня.

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

Встроенные системы часто напрямую не взаимодействуют с человеком как персональные компьютеры. Как следствие совокупность необходимых сервисов ОС, в которых они нуждаются, может быть очень разным. Microsoft Windows, MacOS X и Linux сегодня являются доминирующими ОС для персональных компьютеров общего назначения. Они обеспечивают сервисы, которые для встроенных MPS могут потребоваться, а могут и нет. Например, многие встроенные приложения не требуют графического интерфейса пользователя (GUI), файловой системы, управления фонтами и даже сетевого стека.  

Несколько ОС были спроектированы специально для встроенных приложений: Windows CE (WinCE) от Microsoft, VxWorks от WindRiver Systems (приобретена  Intel в 2009), QNX от QNX Software Systems (приобретена в 2010 Research in Motion (RIM)), Embedded Linux (поддерживает открытое сообщество) и FreeRTOS (поддерживает другое открытое сообщество). Эти ОС разделяют много особенностей с ОС общего назначения, но обычно имеют специализированное ядро операционных систем реального времени (RTOS). RTOS обеспечивает ограниченную задержку при выполнении подпрограмм обработки прерываний и программы планировщика для процессов с ограничениями реального времени.  

Мобильные операционные системы являются третьим классом ОС, спроектированных для управления такими устройствами как мобильные телефоны и карманные компьютеры. Примерами являются Symbian OS (открытая с поддержкой Symbian Foundation), Android от Google, BlackBerry OS от  RIM, iPhone OS от Apple, Palm OS от Palm, Inc.( приобретена Hewlett Packard и 2010) и Windows Mobile, Windows Phone  от Microsoft. Эти ОС имеют специальную поддержку для беспроводного взаимодействия и мультимедиа-форматов.

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

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

Промежуточное ПО обычно является посредником между приложением и ядром ОС или драйверами устройств.

 Основная цель компонент BSP это обеспечить уровень абстракции между ОС и драйверами устройств.

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

Рис. 63. Варианты уровневых моделей встроенных систем

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.

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