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

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

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

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

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

Любое современное встроенное устройство состоит из аппаратной платформы и программного обеспечения:

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

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

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

3. Разработчики встраиваемых систем – это инженеры-схемотехники и инженеры-программисты, отвечающие за непосредственное проектирование печатных плат и написание программного кода.

4. QA-специалисты отвечают за тестирование разрабатываемых решений.

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

Поскольку КЕДР Solutions специализируется на контрактной разработке встраиваемой электроники, идеи новых продуктов обычно принадлежат нашим заказчикам. Когда команда присоединяется к проекту, наша первая задача – собрать требования к будущему устройству:

• Функциональные требования (что должна делать система);
  
  
• Нефункциональные требования: производительность, масштабируемость, безопасность, размер, вес, ограничения законодательства и другие важные характеристики.
  
  

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

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

На основе этой информации команда КЕДР Solutions формирует техническое задание на разработку проекта – документ, описывающий назначение, функции, поведение и другие требования к будущему устройству и обсуждает его с заказчиком.

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

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

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

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

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

• Работая с каким-либо компонентом впервые, сперва мы его тестируем, чтобы убедиться, что тот работает так, как указано в спецификациях.
• Если к проекту предъявляются соответствующие требования, печатные платы должны быть защищены от электростатических разрядов, электромагнитных помех, неблагоприятных условий окружающей среды и других факторов.
• Если заказчик планирует выпускать продукт серийно, разработка должна вестись с учетом требований производства (по принципам DFM).
• Плата должна быть спроектирована с учетом требований сертификации (если клиент планирует сертифицировать продукт).
• Работа должна вестись в полном соответствии с правилами проектирования печатных плат, чтобы устройство прослужило как можно дольше и без проблем.
• Должное внимание необходимо уделять тепловому режиму платы – особенно при проектировании мощного устройства. Достаточного отведения тепла можно добиться за счет правильного размещения компонентов, увеличения площади меди, добавления переходных отверстий, использования радиаторов и других способов.

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

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

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

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

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

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

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

В зависимости от типа устройства его прошивка может содержать ПО разного уровня:

Приложение

Этот тип ПО содержит алгоритм работы встроенного устройства. В нем реализованы его бизнес-функции. Приложения могут быть написаны на языках высокого уровня, таких как C++, Python и Java.

Встроенная операционная система

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

Среда выполнения

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

Такой подход широко применяется при разработке программируемых логических контроллеров для промышленной автоматики. На плате запускается ОС, сверху устанавливается CODESYS (среда выполнения), в которой, в свою очередь, выполняются пользовательские приложения.

Интерфейсы и драйверы

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

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

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

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

• IDE (интегрированные среды разработки) – это наборы инструментов, которые содержат различные средства программирования: редакторы, компиляторы, отладчики и т.д.
  
• Компиляторы и кросс-компиляторы переводят код, написанный на языке высокого уровня, в машинный код.
  
• Отладчики помогают разработчикам находить и устранять баги.
  
• Линкеры, или компоновщики, могут объединять различные фрагменты кода и модули в одну исполняемую программу. Современные компиляторы имеют встроенные линкеры.
  
• Симуляторы и эмуляторы позволяют создавать виртуальные среды, приближенные к реальным условиям, для тестирования программ.
  
• Средства конфигурации системы и генерации кода автоматически генерируют код для настройки аппаратных компонентов устройства. Они сводят к минимуму рутинную работу и, как следствие, сокращают вероятность ошибок.
  
• Средства автозаполнения кода – это инструменты на основе искусственного интеллекта, которые анализируют написанный программистом код и автоматически дополняют его контекстуально релевантными фрагментами. Эти инструменты значительно ускоряют разработку программного обеспечения для встраиваемых систем.
• Дизассемблеры позволяют конвертировать исполняемый файл в текстовое представление на уровне ассемблерных инструкций. Это используются для выявления ошибок, допущенных компиляторами. Иногда проще устранить ошибки на уровне ассемблера, чем в высокоуровневом коде. Да, иногда бывает и такое, а ждать, когда появятся исправления в компиляторе, можно очень долго.

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

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

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

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

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

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

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

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

Иногда мы создаем mock-сервис, который эмулирует работу встроенной программы и генерирует синтетические данные для разрабатываемого программного обеспечения прикладного уровня.

Выбор языка программирования определяется тем, какое аппаратное обеспечение мы собираемся использовать и какой тип ПО мы хотим создать. Например, программы для устройств на базе Android создаются на Java, а программное обеспечение для одноплатных компьютеров – на C или C++. Язык C подходит для низкоуровневого программирования, т.е. для программ, которые напрямую взаимодействуют с железом. C++, Python, Java, Rust и другие языки подходят для высокоуровневого программирования.

Специализация КЕДР Solutions – разработка на C/C++. Программист с опытом работы на C++ может с помощью фреймворка Qt создавать как встраиваемое программное обеспечение, так и прикладное десктопное ПО. Хотя существуют более безопасные альтернативы C/C++ (например, язык Rust), наша команда обладает достаточной квалификацией, чтобы не допускать ошибок при работе на C/C++. Это позволяет нам унифицировать процесс разработки, что сокращает стоимость вашего проекта.

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

Разработчикам доступны разные встроенные ОС: Embedded Linux, Android, Windows IoT, RTOS, RTEMS и др. Выбор определяется несколькими факторами:

• Целью проекта;
  
• Доступными аппаратными ресурсами;
  
• Стоимостью разработки.
  
  

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

Часто чем больше аппаратных ресурсов доступно разработчику, тем дешевле сама разработка, и наоборот.

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

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

К числу наиболее частых сложностей, с которыми сталкивается команда, можно отнести следующие.

• Недостаток информации
  
  

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

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

• Безопасность данных
  
  

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

• Ограниченность памяти и производительности
  
  

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

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

• Стабильность
  
  

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

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

При написании кода разработчики должны предусмотреть такие ситуации и дать процессам соответствующие инструкции – например, поручить Процессу 2 сперва опрашивать Процесс 1 и забирать значение, только если оно рассчитано.

• Новые требования
  
  

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

• Оптимизация
  
  

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

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

Например, при работе над системой безопасной буксировки самолетов команде нужно было как-то испытать устройство с модулем, измеряющим дистанцию до препятствий. Наш тестировщик спроектировал и изготовил на 3D-принтере специальный стенд. Устройство крепилось к стойке, а сама стойка с помощью магнита крепилась к капоту автомобиля.

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

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

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

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

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

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