Буквально сегодня сформулировали кредо по разработке Yocto BSP для промышленных контроллеров (ПР, ПЛК, ...) — это "создание детерминированной, сертифицируемой и долгосрочно поддерживаемой платформы".
Сейчас распишем основные шаги
1. Создание BSP-слоя: структура
meta-<plc>/conf/machine/, conf/layer.conf, описание SoC, памяти, интерфейсов и загрузчика.2. Настройка ядра точно вне этого небольшого поста, для железа с архитектурой ARM и RISC-V все гораздо сложнее, чем выбор штатного
linux-yocto или кастомного upstream, тут искусство кернальщика, и поговорим об этом позже. Отметим только применение PREEMPT_RT, отключение неиспользуемых драйверов, в первую очередь графики и т.п..3. Bootloader и secure chain: U-Boot с поддержкой verified boot, FIT-образов. Опять же вне этого сообщения оставим вопросы аппаратного корня доверия и восстановления при сбоях питания и критических ошибках прошивок.
4. Валидация:
bitbake core-image-minimal → кастомный образ → запуск на реальном железе или QEMU, проверка загрузки, сети, RTC, storage.Набор пакетов
Для ПЛК применяется принцип «минимальный детерминированный базис + промышленный стек», хотя строго говоря промышленного стека не существует пока, есть carrier grade, но это телеком больше.
• Базовые:
systemd (или busybox/sysvinit для legacy), dropbear/openssh с hardened-конфигом, chrony, logrotate, iproute2, util-linux. Добавим к этому еще syslog-ng, наверное, как минимум для интеграции с SIEM• Промышленные:
mosquitto, open62541 (OPC UA), libmodbus, socat, net-snmp, rt-tests, python3 + runtime-библиотеки (если используется скриптовая логика).• Аппаратные/безопасность:
tpm2-tools, cryptsetup, watchdog, irqbalance (отключается для RT), procps.Все пакеты жёстко фиксируются в
IMAGE_INSTALL и PACKAGECONFIG. Лишнее отсекается через DISTRO_FEATURES, IMAGE_FEATURES += "read-only-rootfs", EXTRA_IMAGE_FEATURES не включаются без необходимости. Версии зависимостей привязываются к слою, репозитории кэшируются для воспроизводимости.Автоматическая сборка
Промышленный BSP живёт в CI/CD. Стандартный стек:
kas или crops для изоляции Docker-среды, GitLab CI / Jenkins для оркестрации. Пайплайн включает:•
bitbake -k с параллельной сборкой нескольких машин/профилей.•
oe-selftest и ptest для проверки рецептов.• Генерацию артефактов (u-boot, kernel, rootfs, sdcard/wic) с хешированием.
• HIL-тесты через LAVA/Robot Framework: прошивка, проверка загрузки, пинг, опрос GPIO/Fieldbus, стресс-тест watchdog.
Каждый коммит фиксируется в реестре, образы подписываются, метаданные версионируются. Откат к предыдущему билду занимает минуты.
Проверка на уязвимости
Безопасность в Yocto встроена, но требует явной активации:
•
INHERIT += "cve-check" сканирует рецепты на этапе парсинга и сборки, генерируя отчёт cve.log.•
BB_SIGNATURE_HANDLER = "OEBasicHash" гарантирует, что изменение версии или патча пересоберёт пакет и сбросит хеш.• Пост-билд анализ:
syft/grype или scancode-toolkit поверх готового rootfs, генерация SBOM (SPDX/CycloneDX) для аудита и соответствия IEC 62443.•
CVE_CHECK_WHITELIST используется только для ложных срабатываний; критические/высокие CVE блокируют пайплайн (FAIL_ON_CVE = "1").• Дополнительно:
INHERIT += "sign-package", IMAGE_CLASSES += "image-buildinfo", строгий контроль лицензий (INHERIT += "license"), автоматическое обновление баз CVE в ночном режиме.Итог
Успешный Yocto BSP для промышленного ПЛК строится на трёх китах: фиксированный минимальный набор пакетов, полностью автоматизированный воспроизводимый пайплайн и непрерывный контроль уязвимостей с генерацией SBOM. Это даёт базу для долгосрочной поддержки, прохождения аудитов и сертификации без ручного вмешательства.
Что скажете, согласны с нашей парадигмой?