Готовые программные решения для встраиваемых систем: как оценить и выбрать подходящее
Готовые программные решения для встраиваемых систем: техническое руководство для инженеров и лиц, принимающих решения
У вас есть целевое аппаратное обеспечение. У вас есть срок поставки. Теперь кто-то в комнате спрашивает, стоит ли команде покупать готовое программное решение для встраиваемых систем или разрабатывать стек прошивки с нуля. Этот вопрос звучит просто. На практике он затрагивает затраты на лицензирование, обязательства по сертификации, окна долгосрочной поддержки и вопрос о том, кому принадлежат права на интеллектуальную собственность через пять лет. Это руководство последовательно рассматривает каждый из этих факторов, чтобы вы могли получить обоснованный ответ до обзора архитектуры.
Полное руководство по покупке: Оценка и выбор готового программного решения для встраиваемых систем
Что отличает «решение» от пользовательской прошивки
Готовое программное решение для встраиваемых систем объединяет предварительно интегрированные компоненты. Представьте себе ядро RTOS, уровень аппаратных абстракций, промежуточное ПО для подключения или файловых систем, а иногда и пакет поддержки платы — все это протестировано вместе и поставляется как единое целое. Пользовательская прошивка начинается с отдельных компонентов, которые инженер встраиваемого программного обеспечения интегрирует, настраивает и валидирует специально для вашего оборудования.
Основной компромисс — это время выхода на рынок против долгосрочной гибкости. Готовое решение может ускорить начальную разработку на недели или месяцы. Вы пропускаете интеграционную работу, которую уже выполнил поставщик. Цена заключается в том, что архитектура решения формирует вашу. Если ваш продукт развивается в направлении, для которого решение не было разработано, вы в конечном итоге упретесь в потолок.
Правильный выбор обычно сводится к трем вопросам. Существует ли уже решение, которое достаточно близко соответствует вашей процессорной архитектуре и набору периферийных устройств? Обладает ли ваша команда достаточной инженерной глубиной для поддержки пользовательской сборки на протяжении всего жизненного цикла продукта? И требует ли ваша дорожная карта владения интеллектуальной собственностью — например, если вы планируете сублицензировать саму прошивку?
| Фактор | Готовое решение | Пользовательская сборка прошивки |
|---|---|---|
| Время первоначальной разработки | Короче — интеграция уже выполнена | Дольше — интеграция — ваша работа |
| Долгосрочная гибкость | Ограничена архитектурой поставщика | Полный контроль над решениями стека |
| Владение интеллектуальной собственностью | Зависит от условий лицензирования | Полностью ваша |
| Путь сертификации | Может включать предварительно сертифицированные компоненты | Вы отвечаете за полный цикл сертификации |
| Текущее обслуживание | Зависит от поставщика | Ответственность внутренней команды |
Как оценить решение для встраиваемого ПО для вашей аппаратной платформы
Начните с совместимости. Решение должно поддерживать архитектуру вашего процессора — ARM Cortex-M, RISC-V или любую другую, на которую ориентировалась ваша команда разработчиков аппаратного обеспечения. Помимо ядра, тщательно проверьте поддержку периферии. Решение, которое работает с вашими UART и SPI, но не имеет протестированного драйвера для вашего конкретного Ethernet MAC, приведет к дополнительным работам по интеграции, что сведет на нет преимущество в скорости вывода на рынок, которое вы пытались получить.
Потребление памяти имеет большее значение, чем часто признают поставщики в своих основных спецификациях. Проверяйте минимальные требования к ОЗУ и флэш-памяти при реалистичной нагрузке, а не только в конфигурации демонстрационной версии. Решение, которое легко помещается на устройстве с 512 КБ флэш-памяти в своей сборке по умолчанию, может превысить ваш бюджет после включения функций, которые действительно нужны вашему продукту.
Модели лицензирования заслуживают пристального внимания на протяжении всего жизненного цикла продукта. Лицензии на открытое ПО — MIT, Apache 2.0, BSD — обычно разрешают коммерческое использование без роялти за единицу продукции, но каждая имеет разные обязательства в отношении указания авторства и производных работ. Коммерческие лицензии часто включают SLA поддержки и сертификационные артефакты, но они вводят структуры затрат за единицу продукции или за рабочее место, которые накапливаются по мере роста объемов вашего производства. Модели, основанные на роялти, могут выглядеть доступными на этапе прототипа, а затем стать значительной статьей расходов в больших масштабах. Подсчитайте затраты при прогнозируемых объемах на три и пять лет, прежде чем принимать решение.
Обязательства по поддержке и обслуживанию легко упустить из виду при оценке. Спросите поставщика напрямую: каков гарантированный период поддержки для этой версии? Как доставляются исправления безопасности? Существует ли путь миграции при выходе следующей основной версии? Решение, которое хорошо поддерживается сегодня, но будет заброшено через три года, создает нагрузку на обслуживание, которая ляжет на вашу инженерную команду в самый неподходящий момент.
Такая ясность относительно долгосрочных обязательств имеет наибольшее значение при принятии решения, которое определит ваш продукт на годы вперед. kilngold поставляет материалы с четкими, проверяемыми стандартами качества. Тот же принцип применим и здесь: поставщик, который может предоставить вам задокументированные сроки поддержки и историю исправлений, дает вам нечто конкретное для оценки, а не просто обещание от отдела продаж.
Тревожные сигналы и критерии для шорт-листа при сравнении поставщиков или платформ
Качество документации является одним из самых надежных показателей зрелости решения. Хорошо поддерживаемое решение имеет полную справочную документацию по API, руководство по началу работы, которое действительно работает, и журнал изменений, отражающий реальную активность разработки. Скудная или устаревшая документация обычно означает, что решение не было широко протестировано за пределами собственного оборудования поставщика. Это риск, который вы возьмете на себя.
Размер сообщества особенно важен для решений с открытым исходным кодом. Большое, активное сообщество означает, что ошибки обнаруживаются быстрее, существуют обходные пути до появления официальных исправлений, и вы можете найти инженеров, которые уже знают платформу. Проверьте трекер проблем: как быстро подтверждаются критические ошибки? Сколько проблем остаются открытыми более года без решения?
Для приложений, критически важных с точки зрения безопасности, готовность к сертификации не подлежит обсуждению. IEC 61508 охватывает функциональную безопасность в промышленных системах. ISO 26262 применяется к автомобильной промышленности. DO-178C регулирует бортовое программное обеспечение. Если вашему продукту требуется одно из этих требований, запросите у поставщиков артефакты сертификации заранее — проектную документацию, отчеты о покрытии тестами, записи о квалификации инструментов. Решение, которое заявляет о готовности к сертификации, но не может предоставить эти документы, на самом деле не готово к сертификации. Проверьте это до фиксации архитектуры.
Технологический стек внутри решения для встраиваемого программного обеспечения
Технологический стек внутри типичного решения для встраиваемого программного обеспечения
Встроенное программное решение — это не единое целое. Это набор уровней, и выбор, сделанный на каждом уровне, имеет последствия, которые распространяются вверх по стеку. Понимание этих уровней помогает задавать более точные вопросы при оценке.
Слой аппаратных абстракций (HAL) находится ближе всего к кремнию. Он преобразует специфические для оборудования регистровые операции в согласованный API, который могут вызывать вышележащие уровни, не зная деталей нижележащего чипа. Хорошо спроектированный HAL делает ваш код приложения переносимым между поколениями оборудования. Плохо спроектированный HAL привязывает вас к SDK конкретного поставщика микросхем и делает миграцию дорогостоящей.
Ядро RTOS находится над HAL. Оно управляет планированием задач, выделением памяти и межзадачным взаимодействием. Выбор ядра — FreeRTOS, Zephyr, ThreadX и других — влияет на характеристики производительности в реальном времени, на накладные расходы по памяти и на варианты сертификации. Некоторые ядра имеют готовые артефакты сертификации безопасности; другие — нет.
Слои промежуточного программного обеспечения находятся над ядром. Здесь располагаются стеки подключения, файловые системы, стеки USB-устройств и криптографические библиотеки. Промежуточное программное обеспечение часто является местом скрытой реальной сложности интеграции. Решение, которое включает в себя хорошо протестированное промежуточное ПО, экономит значительное время инженеров. Решение, которое оставляет выбор промежуточного ПО вам, ближе к библиотеке компонентов, чем к полному решению.
Каркас приложения, если он включен в решение, обеспечивает структуру для вашего собственного кода — шаблоны управления устройствами, обработку событий, управление конфигурацией. Не все решения включают этот уровень. Для команд с глубокими знаниями в области разработки встраиваемого ПО это нормально. Для команд, которые хотят двигаться быстрее, зрелый каркас приложения уменьшает количество архитектурных решений, которые вашей команде придется принимать с нуля. Для более глубокого изучения того, как эти уровни взаимодействуют во время разработки, см. раздел стек разработки встраиваемого программного обеспечения на родительской странице.
Открытый исходный код против проприетарного ядра: компромиссы, которые переживут первоначальную сборку
Решение «открытое ПО против проприетарного» — это не только вопрос первоначальной стоимости. Оно определяет вашу модель поддержки, график выпуска обновлений безопасности и степень зависимости от поставщика на протяжении всего жизненного цикла продукта.
| Атрибут | Ядро с открытым исходным кодом | Проприетарное ядро |
|---|---|---|
| Первоначальная стоимость | Низкая или нулевая | Лицензионный сбор или роялти за единицу продукции |
| Долгосрочная поддержка | Развивается сообществом; переменчиво | SLA, гарантированное поставщиком |
| Обновления безопасности | Скорость сообщества; вы применяете обновления | Выпускаются поставщиком; могут отставать от обнаружения сообществом |
| Риск привязки к поставщику | Низкий — исходный код доступен | Высокий, если поставщик прекращает поддержку или меняет условия |
| Артефакты сертификации | Редко; вы генерируете свои собственные | Часто включается на более высоких уровнях |
Ядра с открытым исходным кодом предоставляют вам доступ к исходному коду, что означает, что вы можете вносить исправления, проводить аудит и форкать при необходимости. Риск заключается в том, что поддержка сообщества не гарантируется. Широко используемый проект, такой как FreeRTOS или Zephyr, имеет достаточный импульс, чтобы поддержка вряд ли исчезнет. Небольшой проект с горсткой сопровождающих несет реальный риск преемственности на протяжении десятилетнего жизненного цикла продукта.
Проприетарные ядра оправдывают свою стоимость в определенных ситуациях. Если ваш продукт требует сертификации безопасности, а поставщик предоставляет квалифицированные инструменты и документацию, вы получаете значительное сокращение ваших собственных усилий по сертификации. Если вашей команде не хватает глубины для управления пользовательским процессом поддержки, коммерческое соглашение об уровне обслуживания (SLA) предоставляет вам предсказуемый путь эскалации. Эти преимущества реальны — но они сопряжены с зависимостью от поставщика. Если поставщик прекращает выпуск продукта, изменяет условия лицензирования или повышает цены, ваши возможности ограничены.
Практическое правило: если ваш продукт выпускается большими тиражами, работает более пяти лет и не требует сертификации безопасности, ядро с открытым исходным кодом обычно обеспечивает лучшую совокупную стоимость владения. Если требуется сертификация или если ваша команда мала и нуждается в надежной поддержке, проприетарное ядро часто окупает свою цену.
Текущие тенденции, формирующие спецификацию встраиваемых программных решений
Ожидания в отношении подключения и обновлений OTA теперь являются базовыми требованиями
Пять лет назад беспроводная связь была особенностью некоторых встраиваемых продуктов. Сегодня это базовое требование для большинства категорий продуктов — промышленных датчиков, потребительских устройств, медицинских мониторов и инфраструктурного оборудования. Этот сдвиг меняет то, что вы должны требовать от решения для встраиваемого программного обеспечения, прежде чем включать его в краткий список.
Распространение Интернета вещей (IoT) сделало интеграцию беспроводного стека и возможность обновления по воздуху (OTA) стандартным пунктом спецификации, а не дополнительной опцией. Если вы оцениваете решение, которое рассматривает OTA как надстройку или полностью перекладывает его на ваш прикладной уровень, считайте это пробелом, а не незначительным упущением. Возможность обновления OTA — это инфраструктура безопасности. Устройство, которое не может получать обновления прошивки в полевых условиях, — это устройство, которое не может быть исправлено при обнаружении уязвимости. Для читателей, которым нужен основополагающий контекст перед изучением требований к подключению, что такое встраиваемое программное обеспечение четко охватывает основы.
При рассмотрении заявлений о возможностях подключения решения задайте конкретные вопросы: включает ли решение готовый к производству фреймворк OTA или предоставляет ли оно точки интеграции для создания собственного? Криптографически ли аутентифицирован процесс OTA? Можно ли откатить обновления, если новый образ не прошел проверку? Это не продвинутые требования. Это минимум для подключенного продукта, который будет обслуживаться в полевых условиях.
Также проверьте, какие беспроводные стеки включены и как они поддерживаются. Wi-Fi, Bluetooth LE, Thread и сотовая связь имеют свои собственные требования к сертификации и поддержке. Решение, которое включает беспроводной стек, но не поддерживает его через обновления версий протокола, быстрее, чем вы ожидаете, создаст технический долг.
Дизайн с учетом безопасности как не подлежащий обсуждению уровень спецификаций
Безопасность во встраиваемых системах раньше рассматривалась как слой, который добавлялся после установки основной архитектуры. Такой подход больше не работает — ни технически, ни с точки зрения регулирования. Закон ЕС о киберстойкости (Cyber Resilience Act), руководящие принципы NIST по безопасности IoT и аналогичные рамки в других странах делают документацию по безопасности требованием при закупках, а не просто передовой практикой.
При оценке встраиваемого программного решения проверьте наличие трех возможностей безопасности на уровне решения. Безопасная загрузка гарантирует, что на устройстве может работать только аутентифицированная прошивка. Шифрованное хранилище защищает конфиденциальные данные в состоянии покоя — учетные данные, конфигурацию, пользовательские данные. Аппаратный корень доверия означает, что якорная точка безопасности находится в кремнии, а не в программном обеспечении, что значительно затрудняет ее обход.
Эти функции должны присутствовать в самом решении, а не быть добавлены на уровне приложения. Решение, которое полностью перекладывает реализацию безопасной загрузки на вашу команду, возвращает вам значительную нагрузку по разработке и проверке. Решение, которое включает интеграцию аппаратного корня доверия, но только для безопасного элемента одного поставщика кремния, может не соответствовать вашему аппаратному целевому объекту. Проверяйте совместимость на уровне компонентов, а не только список функций.
Регуляторное давление также меняет требования к документации, которую вам необходимо предоставить. Закон ЕС о киберустойчивости, после полного вступления в силу, потребует от производителей продемонстрировать, что безопасность была рассмотрена систематически, а не только то, что продукт имеет пароль. Это означает, что ваше встраиваемое программное решение должно поддерживать ведение журналов безопасности, процессы раскрытия уязвимостей и механизмы обновления, которые могут быть задокументированы и проверены. Если ваш поставщик решения не может предоставить документацию по безопасности, соответствующую этим требованиям, это пробел, который вам придется заполнить внутри компании. Для команд, взвешивающих, может ли внутренний потенциал устранить эти пробелы, обзор набора навыков инженера встраиваемых систем дает ясное представление о том, что на самом деле включает в себя эта работа.
Практическое следствие: безопасность по замыслу — это не уровень функций. Это базовая спецификация. Если решение не включает безопасную загрузку, шифрованное хранилище и документированный механизм обновления, исключите его из своего краткого списка — независимо от того, насколько хорошо оно соответствует другим критериям.
Сведение воедино: четкий путь от требований к решению
Вопрос в начале этого руководства — готовое решение или собственная разработка — обычно решается сам собой после того, как вы проработаете приведенные выше факторы. Если ваш аппаратный целевой объект хорошо поддерживается, у вас сжатые сроки, и вашей команде не нужно владеть каждым уровнем стека, пакетное встраиваемое программное решение почти всегда является более быстрым путем. Если ваш продукт имеет необычные аппаратные требования, длительный жизненный цикл с высокой стоимостью интеллектуальной собственности или путь сертификации, который ни одно существующее решение не покрывает чисто, собственная разработка дает вам необходимый контроль.
Для команд, выбирающих готовое решение, процесс отбора не менее важен, чем окончательный выбор. Проверяйте качество документации до проведения первого же теста. Проверяйте возможности OTA и безопасности на уровне функций, а не маркетинговых заявлений. Рассчитайте модель лицензионных затрат на пять лет. И запрашивайте у поставщика сертификационные артефакты до рассмотрения архитектуры, а не после.
Команды, принимающие это решение правильно, подходят к нему как к процессу закупки с техническими критериями, а не как к чисто техническому решению, принятому без учета затрат и жизненного цикла. Начните с документа требований, сопоставьте каждое требование с критерием оценки решения и используйте критерии отбора из этого руководства для фильтрации перед тем, как инвестировать время инженеров в доказательство концепции.
