3.10 Встраиваемые системы и системы реального времени

Обзор и мотивация

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

Система реального времени это система, где корректность зависит от времени, а не только от выдачи правильного ответа. Контроллер подушки безопасности, вычисливший идеальную команду раскрытия на секунду позже, полностью провалился. Работа в реальном времени добавляет к каждой задаче трудный вопрос: успеет ли она к сроку, каждый раз, в худшем случае? Это иная дисциплина, чем мышление «в первую очередь пропускная способность», обычное для веб- и облачных программ.

Для большой организации это важнее, чем кажется сначала. Корпорации строят подключённые автомобили, медицинские устройства, промышленные контроллеры и миллиарды устройств интернета вещей (IoT). Государства эксплуатируют оборонные платформы, авионику, контроллеры энергосетей и медицинских регуляторов. В этих областях программный дефект может ранить людей, остановить производственную линию или подорвать национальную безопасность. Здесь правила строже, тестирование труднее, а стандарты юридически обязательны. Эта глава помогает строить программы, корректные, своевременные, безопасные и защищённые при реальных ограничениях. Она связана с конструированием программ (глава 2.9), распределёнными системами (глава 3.3), масштабируемостью и производительностью (глава 3.5), безопасностью инфраструктуры и облака (глава 4.3) и сопровождением программ (глава 3.7).

Ключевые принципы

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

Рекомендации

Классифицируйте каждое временное требование как жёсткое, твёрдое или мягкое

Не все сроки равны. Жёсткий срок реального времени нельзя пропускать никогда, потому что пропуск вызывает отказ системы или вред: подумайте об управлении двигателем или рулевых поверхностях. Твёрдый срок допускает редкие пропуски, но запоздалый результат бесполезен и отбрасывается. Мягкий срок реального времени деградирует ценность плавно: видеокадр, пришедший чуть позже, снижает качество, но не вызывает катастрофы. Помечайте каждую чувствительную ко времени задачу её классом, потому что усилия, строгость тестирования и стоимость различаются огромно. Два свойства описывают временное поведение. Задержка (latency) это промежуток между событием и реакцией. Джиттер это изменение этой задержки от одного появления к другому. Системы жёсткого реального времени заботятся об ограничении джиттера так же, как о снижении задержки, потому что предсказуемость позволяет доказать, что срок выполняется всегда.

Выбирайте основу исполнения намеренно: RTOS или голое железо

У вас две основные основы. Прошивка на голом железе работает прямо на оборудовании без операционной системы, используя простой цикл и обработчики прерываний. Это самый малый и самый предсказуемый вариант, подходящий для крошечных устройств с одной ясной задачей. Операционная система реального времени (RTOS) это малая операционная система, планирующая задачи по приоритету и гарантирующая временные границы. Она даёт несколько задач, планировщик и службы вроде таймеров и очередей сообщений, сохраняя предсказуемость времени. Выбирайте RTOS, когда есть несколько одновременных задач с разными сроками. Выбирайте голое железо, когда устройство очень ограничено или время должно быть доказуемо простым. Для работы жёсткого реального времени предпочитайте вытесняющий планировщик на приоритетах и анализируйте его методом вроде монотонного планирования по частоте (rate-monotonic scheduling), назначающего приоритеты по частоте задач и позволяющего доказать планируемость набора задач.

Бюджетируйте память, процессор и энергию как первоклассные ресурсы

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

Обращайтесь с прерываниями и параллелизмом со строгой дисциплиной

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

Пишите драйверы устройств, изолирующие аппаратные детали

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

Принимайте стандарт функциональной безопасности, управляющий вашей областью

Если ваше устройство может навредить людям или имуществу, вероятно, применим стандарт функциональной безопасности, и это часто закон. IEC 61508 общий стандарт безопасности электронных систем и родитель нескольких других. ISO 26262 управляет безопасностью дорожных транспортных средств. DO-178C управляет бортовым программным обеспечением гражданской авиации. IEC 62304 управляет программами медицинских устройств. Для кодирования MISRA C широко используемый набор правил, ограничивающих рискованные возможности языка C, чтобы сделать код безопаснее и более поддающимся анализу. Эти стандарты требуют прослеживаемости от требования к коду и тесту, определённых процессов и свидетельств, которые можно передать аудитору или регулятору. Принимайте нужный рано, потому что дооснащение бумажным следом позже болезненно, а иногда невозможно.

Тестируйте симуляцией и оборудованием в контуре

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

Проектируйте обновления по воздуху и защиту устройств с первого дня

Устройствам в поле понадобятся исправления, поэтому планируйте обновления по воздуху (OTA): способ безопасно доставлять новую прошивку по сети. Безопасный проект OTA криптографически подписывает каждое обновление, проверяет подпись перед установкой, обновляет атомарно и может откатиться к заведомо рабочему образу, если новый не загрузился. Сочетайте это с принципами безопасности главы 4.3, адаптированными для ограниченного оборудования. Используйте аппаратный корень доверия и безопасную загрузку, чтобы работала только подписанная прошивка. Шифруйте данные при передаче и хранении. Меняйте учётные данные по умолчанию и отключайте неиспользуемые интерфейсы. Парк IoT это распределённая система с огромной поверхностью атаки, и один слабый пароль по умолчанию может скомпрометировать миллионы устройств сразу.

Компромиссы: плюсы и минусы

Выбор	Плюсы	Минусы / цена
RTOS	Многозадачность, приоритетное планирование, службы времени	Накладные расходы, больший объём, кривая обучения
Голое железо	Наименьшее, самое предсказуемое, полный контроль	Трудно масштабировать на многие задачи, больше ручной работы
Статическое выделение	Предсказуемо, нет фрагментации, дружественно безопасности	Менее гибко, всё нужно размерять заранее
Формальная сертификация безопасности	Юридический доступ к рынку, строгие свидетельства, больше доверия	Большие затраты времени и денег, медленнее итерации
Обновления OTA	Исправление и улучшение устройств в поле, продление жизни	Инфраструктура обновлений, бремя безопасности, риск отката

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

Вопросы для обсуждения с командой

Измеряете ли вы джиттер или только среднюю задержку на ваших критичных по времени путях? Корректность жёсткого реального времени опирается на ограничение изменчивости времени отклика (джиттера), а не только снижение типичной задержки, потому что предсказуемость позволяет доказать, что срок выполняется всегда. Контур управления с низким средним, но случайными большими всплесками, всё же может пропустить срок и причинить вред, а среднее это скроет. Принесите измерения разброса, включая худший случай, для каждой критичной по времени задачи и пометьте каждую как жёсткую, твёрдую или мягкую, чтобы строгость тестирования соответствовала последствию пропуска. Всё удобное в системах общего назначения (динамическая память, сборка мусора, планирование по наилучшим усилиям) нападает на предсказуемость, поэтому оно остаётся вне жёсткого пути. Если вы сообщаете только средние, вы не можете честно утверждать, что жёсткий срок выполняется.
Всё ли ещё верен ваш выбор RTOS или голого железа и можете ли вы доказать планируемость набора задач? Основа исполнения это решение, которое нужно пересматривать по мере роста устройства: голое железо наименьшее и самое предсказуемое для одной ясной задачи, тогда как RTOS отрабатывает накладные расходы, когда есть несколько одновременных задач с разными сроками. Для работы жёсткого реального времени глава указывает на вытесняющий планировщик на приоритетах, анализируемый методом вроде монотонного планирования по частоте, позволяющего доказать, что задачи помещаются, а не надеяться на это. Принесите текущий набор задач, их частоты и их время выполнения в худшем случае и проверьте, действительно ли планируемость выполняется или задачи тихо накопились сверх того, что основа может гарантировать. Остерегайтесь инверсии приоритетов, когда низкоприоритетная задача, держащая блокировку, задерживает высокоприоритетную. Выбор основы по привычке, а не по набору задач, то, как гарантии времени молча размываются.
Где именно проходит граница между детерминированным устройством и гибким облачным бэкендом и достаточно ли она чиста, чтобы быстро двигаться по одну сторону, не подвергая опасности другую? Главный компромисс главы отказывается от гибкости ради детерминизма и безопасности, а умение в том, чтобы тратить этот размен только там, где срок или риск действительно этого требуют. Чистая граница позволяет критичной для безопасности прошивке оставаться консервативной и сертифицированной, пока облачный бэкенд быстро итерируется, так что обе эволюционируют своим безопасным темпом. Принесите вашу архитектуру и найдите этот шов: что должно быть доказано детерминированным и обновляться по подписанному проверяемому пути против того, что может меняться еженедельно на сервере. Размывание линии тянет облачные привычки (динамическое выделение, время по наилучшим усилиям) в путь управления или без нужды замедляет бэкенд до ритма прошивки. Правильная граница сохраняет и свидетельства безопасности, и скорость поставки.
Какой стандарт функциональной безопасности управляет каждым продуктом и насколько текущие свидетельства далеки от того, что принял бы аудитор? Стандарт (IEC 61508, ISO 26262 для дорожных транспортных средств, DO-178C для бортового ПО, IEC 62304 для медицинских устройств) часто закон и требует прослеживаемости от требования к коду и тесту, которую нельзя подделать в конце. Для большой команды риск в том, что группы принимают бумажный след неравномерно, так что одна линия продуктов готова к аудиту, а другая обнаруживает посреди сертификации, что её требования никогда не прослеживались. Противоположное тяготение скорость: полная прослеживаемость и соблюдение MISRA C замедляют ежедневные итерации, и команда под давлением срока искушена отложить свидетельства «на потом». Принесите текущую матрицу прослеживаемости, ещё открытые находки статического анализа и честный анализ разрывов относительно целевого уровня гарантии. В корпоративной и государственной среде добавьте срок сертификации и ожидания аудитора, потому что дооснащение свидетельствами после проектирования медленно, дорого, а иногда невозможно, и сорванная сертификация может полностью заблокировать доступ к рынку.
Если завтра в устройстве в поле найдут серьёзный дефект, как быстро вы смогли бы безопасно исправить его по всему парку и репетировали ли вы откат? Устройство, которое нельзя пропатчить, становится постоянным обязательством по безопасности и защищённости, а физический отзыв стоит на порядки дороже подписанного обновления по воздуху. Напряжение в том, что небрежный механизм обновления сам поверхность атаки и риск «окирпичивания»: путь OTA, устанавливающий неподписанные образы или не умеющий откатить неудачную загрузку, может превратить один плохой выпуск в миллионы мёртвых устройств. Принесите ваш проект обновления (криптографическая подпись, проверка подписи перед установкой, атомарная установка, автоматический откат к заведомо рабочему образу), состояние безопасной загрузки и аппаратного корня доверия и когда в последний раз кто-либо действительно выполнял откат на реальном оборудовании. Для корпоративного или общественного парка добавьте, кто отвечает за ключи подписи и как вы отозвали бы скомпрометированный, потому что утёкший ключ или общий пароль по умолчанию могут скомпрометировать весь парк сразу.
Записаны ли ваши бюджеты памяти, процессора и энергии с жёсткими потолками и упражняет ли ваша стратегия тестирования и симуляцию, и реальное оборудование? Гарантии реального времени опираются на время выполнения в худшем случае и фиксированный ресурсный след, а не среднее поведение, поэтому небюджетированное выделение в куче или непротестированная нагрузка худшего случая то место, где детерминизм тихо размывается. Для большой команды опасность в дрейфе: задачи накапливаются, память ползёт вверх, и никто не владеет бюджетом, пока устройство не откажет в поле после недель работы. Компромисс это покрытие против стоимости, потому что стенд hardware-in-the-loop, вносящий неисправности вроде застрявшего датчика, дорог в построении, тогда как чистая симуляция скрывает ошибки времени, проявляющиеся только на настоящем чипе. Принесите документированные бюджеты, измеренное время выполнения в худшем случае относительно них и свидетельства того, что ваш конвейер запускает модульные тесты на слое абстракции, симуляцию и hardware-in-the-loop до выпуска. В регулируемой и государственной среде свяжите это со структурным покрытием тестами, требуемым стандартом, поскольку аудитор захочет доказательство, что неисправные условия были проверены, а не уверение, что средний случай выглядел хорошо.

Взгляд по секторам

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

Малый бизнес. Без встраиваемого специалиста в штате опирайтесь на проверенные модули, референсные проекты и дистрибутивы RTOS от поставщиков, а не пишите собственный планировщик или загрузчик. Формулируйте выбор «строить или покупать» вокруг того, кто будет патчить устройство следующее десятилетие: купленный стек безопасности и обновления, на который можно положиться, лучше самодельного, который некому сопровождать. Воспринимайте пароли по умолчанию, открытые отладочные интерфейсы и неподписанные обновления как отказы, наиболее вероятно способные вам навредить, потому что их дёшево предотвратить и губительно обнаружить в поле.

Крупная организация. Проблема в согласованности по многим линиям продуктов и командам: общая политика основы исполнения, общие шаблоны бюджетов ресурсов, принудительные MISRA C и статический анализ и одна сертифицированная платформа обновлений по воздуху и безопасной загрузки, чтобы каждая группа не изобретала её заново. Бюджетируйте бремя функциональной безопасности и hardware-in-the-loop явно, стандартизируйте интерфейс абстракции оборудования, чтобы исчезновение чипа со склада не оставило продукт без опоры, и управляйте свидетельствами времени парка, артефактами безопасности и положением защищённости как управляемыми активами, а не фольклором отдельных команд. Один слабый пароль по умолчанию по всему парку это обязательство корпоративного масштаба, поэтому централизуйте управление учётными данными и ключами.

Государственный сектор. Правила закупок, прозрачность и публичная подотчётность определяют каждый выбор. Требуйте, чтобы поставщики разрабатывали бортовое, медицинское или оборонное ПО по управляющему стандарту (DO-178C, IEC 62304, IEC 61508) на уровне гарантии, соответствующем опасности, и передавали свидетельства прослеживаемости и структурного покрытия, которые рассмотрят аудиторы. Требуйте безопасной загрузки, аппаратного корня доверия и контролируемого подписанного процесса обновления в поле, потому что непроверенное обновление системы полёта или энергосети неприемлемо. Отдавайте предпочтение контрактам, дающим права на исходный код, артефакты безопасности и возможность повторной сертификации со вторым поставщиком, чтобы уход поставщика из бизнеса не оставил без опоры систему, от которой общество зависит десятилетиями.

Примеры

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

Крупная организация. Производитель подключённых автомобилей строит электронный контроллер торможения. Жёсткий контур управления реального времени работает на RTOS с монотонным планированием по частоте и статической памятью, а каждая задача несёт измеренное время выполнения в худшем случае. Команда разрабатывает по ISO 26262 с полной прослеживаемостью от требования к коду и тесту и принудительно применяет MISRA C статическим анализом при каждом коммите. Стенд hardware-in-the-loop воспроизводит тысячи дорожных сценариев, включая внесённые неисправности датчиков, до выпуска любой прошивки. Подписанные обновления OTA позволяют компании исправить дефект по всему парку без дорогого отзыва, с автоматическим откатом, если автомобиль не загрузил новый образ.

Государственный сектор. Национальный авиационный орган сертифицирует новый бортовой компьютер управления полётом. Поставщик разрабатывает бортовое ПО по DO-178C на уровне гарантии, соответствующем опасности, создавая свидетельства покрытия требований и структурного покрытия тестами, которые рассматривают аудиторы. Время доказано детерминированным при нагрузке худшего случая, с ограниченной задержкой прерываний и без динамического выделения после запуска. Безопасная загрузка и аппаратный корень доверия гарантируют, что работает только подписанная сертифицированная прошивка. Обновления в поле следуют контролируемому подписанному процессу, потому что непроверенное обновление системы полёта неприемлемо.

Бизнес-обоснование: мотивы, ROI и TCO

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

Формулируйте возврат инвестиций вокруг избежания отзывов, более быстрой сертификации и более долгой жизни устройств. Надёжная возможность OTA превращает многие потенциальные отзывы в недорогие удалённые исправления, а каждый избежанный отзыв может окупить всю программу обновлений. Строгий анализ WCET и бюджетирование ресурсов позволяют уверенно поставлять на более дешёвом оборудовании, снижая стоимость единицы по большому парку. Для совокупной стоимости владения помните, что эти устройства живут годами или десятилетиями: бремя сопровождения, патчинга безопасности и поддержки (глава 3.7) затмевает первоначальное построение. Проектирование под обновляемость, чистую абстракцию оборудования и документированные бюджеты то, что держит этот длинный хвост доступным.

Антипаттерны и ловушки

Оптимизация для среднего случая. Выполнение срока «обычно» это провал жёсткого требования реального времени.
Динамическое выделение в пути управления. Фрагментация кучи вызывает отказ, проявляющийся только после недель работы.
Толстые обработчики прерываний. Тяжёлая обработка внутри прерывания взрывает ваш бюджет времени и создаёт гонки.
Игнорирование стандарта до аудита. Дооснащение прослеживаемостью и свидетельствами поздно медленно, дорого, а иногда невозможно.
Поставка без пути обновления. Устройство, которое нельзя пропатчить, становится постоянным обязательством по защищённости и безопасности.
Пароли по умолчанию и открытые интерфейсы. Один слабый пароль превращает парк IoT в ботнет.
Тестирование только на симуляторе или только на оборудовании. Каждое скрывает ошибки, которые поймало бы другое; нужны оба.
Воспринимание оборудования как чужой проблемы. Время, порядок байтов и причуды датчиков здесь заботы программы.

Модель зрелости

Уровень 1: Начальный. Время ожидается, а не анализируется. Память выделяется динамически по желанию. Никакой стандарт функциональной безопасности не соблюдается. Тестирование ручное и только на устройстве. Устройства нельзя обновить после поставки, так что дефект в поле означает отзыв или постоянное обязательство.
Уровень 2: Развитие. У некоторых задач измерено время и есть базовая RTOS или структурированный цикл, но практика различается по командам. Руководства по кодированию существуют, но не применяются принудительно. Тестирование включает некоторую симуляцию. Ручной рискованный путь обновления существует на некоторых продуктах и отсутствует на других. Хорошие привычки есть, но непоследовательны, и ничто не гарантирует, что следующая линия продуктов их унаследует.
Уровень 3: Стандартизация. Временные требования классифицированы как жёсткие, твёрдые или мягкие и анализируются по времени выполнения в худшем случае и методом планируемости, документированы и соблюдаются по организации. Бюджеты ресурсов памяти, процессора и энергии записаны с жёсткими потолками. Управляющий стандарт функциональной безопасности соблюдается с прослеживаемостью от требования к коду и тесту, а MISRA C или эквивалент принудительно применяется статическим анализом при каждом коммите. Тестирование hardware-in-the-loop работает в конвейере. Подписанные атомарные обновления по воздуху с откатом и безопасная загрузка обязательная база везде.
Уровень 4: Управление. Организация измеряет и контролирует своё встраиваемое хозяйство относительно базовых значений. Она отслеживает запасы времени выполнения в худшем случае, распределения джиттера, доли пропущенных сроков, запас памяти и энергии, ещё открытые находки статического анализа, покрытие свидетельствами сертификации и доли успеха обновлений по воздуху и откатов и сравнивает их с согласованными целями. Дрейф относительно бюджета ресурса или времени запускает действие до отказа устройства в поле, а решения «пускать или нет» опираются на эти данные, а не суждение в моменте. Руководители видят, какие линии продуктов готовы к аудиту, а какие движутся к пропущенному сроку или превышенному бюджету.
Уровень 5: Оркестрация. Детерминизм, свидетельства безопасности и защищённость непрерывно верифицируются и автоматизированы. Внесение неисправностей и hardware-in-the-loop работают на каждое изменение, а артефакты сертификации порождаются как побочный продукт процесса. Парк отслеживается, патчится и безопасно обновляется в масштабе на протяжении долгого срока службы. Организация адаптирует основы исполнения, бюджеты ресурсов и принятие стандартов по мере исчезновения чипов со склада, эволюции угроз и изменения норм, перебалансируя весь портфель устройств по свидетельствам, а не реагируя на каждый кризис в одиночку.

Идеи для обсуждения

Какие задачи вашего устройства по-настоящему жёсткого реального времени и можете ли вы доказать, что каждая всегда укладывается в срок?
Знаете ли вы время выполнения в худшем случае вашего критичного контура управления или только его среднее?
Какой стандарт функциональной безопасности управляет вашим продуктом и насколько ваши текущие свидетельства далеки от того, чего он требует?
Если завтра в устройстве в поле найдут серьёзный дефект, как бы вы его исправили и как быстро?
Где в вашем пути управления ещё существует динамическое выделение памяти и что случится, если оно откажет на тысячном часу?
Как ваш парк IoT выдержал бы атакующего, нашедшего один общий пароль по умолчанию?

Главные выводы

Встраиваемые программы работают на ограниченном оборудовании, а корректность реального времени зависит от времени, а не только от правильного ответа.
Классифицируйте каждый срок как жёсткий, твёрдый или мягкий и проектируйте для времени худшего случая, ограниченного джиттера и детерминизма, а не сырой скорости.
Выбирайте RTOS или голое железо намеренно и бюджетируйте память, процессор и энергию как фиксированные первоклассные ресурсы.
Держите обработчики прерываний крошечными, защищайте общие данные и изолируйте оборудование за чистыми тестируемыми интерфейсами драйверов.
Принимайте рано стандарт функциональной безопасности, требуемый вашей областью (IEC 61508, ISO 26262, DO-178C, IEC 62304, MISRA C), с полной прослеживаемостью.
Тестируйте симуляцией и оборудованием в контуре и стройте безопасные подписанные обновления OTA с возможностью отката и защиту устройств с первого дня.

Источники и дополнительное чтение

IEC 61508, Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems
ISO 26262, Road Vehicles: Functional Safety
RTCA DO-178C, Software Considerations in Airborne Systems and Equipment Certification
IEC 62304, Medical Device Software: Software Life Cycle Processes
MISRA, MISRA C: Guidelines for the Use of the C Language in Critical Systems
Michael Barr and Anthony Massa, Programming Embedded Systems
Elecia White, Making Embedded Systems
Jane W. S. Liu, Real-Time Systems
Giorgio Buttazzo, Hard Real-Time Computing Systems: Predictable Scheduling Algorithms and Applications
Colin Walls, Embedded Software: The Works
Philip Koopman, Better Embedded System Software
OWASP Internet of Things (IoT) security guidance