Проблемы проектирования встроенных систем

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

1 Встроенные системы должны быть реально надежными. Уровень надежности выходит далеко за рамки традиционного уровня, достигнутого для систем, подобных ПК. Примеры серьезных случаев ненадежности включают в себя следующее:

В одном случае, система голосового управления в аэропорту Лос-Анджелеса была потеряна более чем на 3 часа [Broesma, 2004].

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

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

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

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

4 Ссылка на физику имеет дополнительные последствия. Например, мы должны проверить, действительно ли мы укладываемся в ограничения по времени. Управление временем является одной из самых больших проблем [Ли, 2006].

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

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

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

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

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

Учет ограничений в режиме реального времени очень важен для кибер-физических систем, но вряд ли – для систем, подобных ПК. Соответствие временным ограничений может быть верифицировано только во время разработки, если все приложения известны во время разработки.

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

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

Проект, разрабатываемый с нуля

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

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

Информация хранится в проектном хранилище.

Хранилище позволяет отслеживать разработку моделей. В большинстве случаев, хранилище должно обеспечить управление версиями или «контроль версий», как CVS [Седерквист, 2006] или SVN [Коллинс-Сассмен и др., 2008]. Хорошее проектное хранилище должно также сопровождаться интерфейсом управление проектированием, которое будет также отслеживать применимость инструментов проектирования и последовательности, все это должно быть интегрировано в удобный графический пользовательский интерфейс (ГПИ).

Проектное хранилище и графический интерфейс пользователя может быть расширено в интегрированную среду разработки (ИСР), которая также называется проектной разработкой (см, например, [Liebisch and Jain, 1992])

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

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

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

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

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

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

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

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