Промышленное производство
Промышленный Интернет вещей | Промышленные материалы | Техническое обслуживание и ремонт оборудования | Промышленное программирование |
home  MfgRobots >> Промышленное производство >  >> Industrial Internet of Things >> Встроенный

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

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

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

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

Решение загадки многоядерного анализа времени (MTA)

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

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

Эксперты из Барселонского суперкомпьютерного центра (BSC), Rapita Systems Ltd (RPT), Raytheon Technologies (RTRC) и Marelli Europe (MAR) уже много лет ищут ответы на эти вопросы. BSC и Rapita разрабатывают решение, которое вскоре будет внедрено в аэрокосмической и автомобильной промышленности. Специализированные инструменты и автоматизация в сочетании с методологией, основанной на требованиях и ориентированной на безопасность, стали ключом к решению головоломки.

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

Современные инструменты

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

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

Анализ и контроль помех в действии

Ключом к пониманию помех является методология структурированного тестирования с привлечением экспертов по аппаратному и программному обеспечению для получения свидетельств о поведении многоядерной синхронизации. Специализированная технология от BSC (известная как технология многоядерных микротестов или MμBT, коммерциализированная Rapita как RapiDaemons) позволяет разработчикам системы анализировать и количественно оценивать влияние помех в многоядерном приложении, создавая дополнительные сценарии помех для стресс-тестирования различных частей системы. многоядерный процессор.

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

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

щелкните, чтобы увеличить изображение

Рис. 1. Использование микротестов при анализе помех. (Источник:авторы)

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

При анализе эффектов помех использование MμBT поддерживается моделью конкуренции задач (TCM), которая обеспечивает ранние оценки возможных проблем с задержкой конкуренции. Инструменты автоматизации и тестирования программного обеспечения RapiTest и RapiTime, разработанные Rapita, используются для написания тестов и их выполнения на встроенной мишени.

Методология проектирования

Следуя семиэтапному процессу разработки тестов в рамках стандартного процесса разработки программного обеспечения «V» (рис. 2), инженеры могут более полно понять влияние помех.

  1. Настройка критической конфигурации многоядерного процессора, анализ канала помех и анализ событий . Эксперты по аппаратному обеспечению помогают определить важные параметры конфигурации, чтобы установить структуру, в которой также определяются каналы помех, а также меры по их снижению. Идентификация аппаратных мониторов событий также играет важную роль в обеспечении средств проверки для всех следующих шагов.
  2. Определите временные требования. Помогите конечному пользователю определить его конкретные потребности, требования к срокам, риски и проблемы безопасности для системы. Например, проверьте производительность любого подхода к аппаратной изоляции, чтобы минимизировать помехи.
  3. Дизайн тестового набора . Разработайте конкретные тестовые примеры (описание теста) для проверки набора гипотез, поддерживающих требования пользователя, включая определение элементов MμBT, которые потребуются для предоставления свидетельств при анализе канала помех. Это включает изолированное выполнение (без вмешательства), выполнение с использованием микротестов для оценки времени выполнения приложения и чувствительности оборудования к помехам в различных поддающихся количественной оценке сценариях стресса.
  4. Выполнение тестовых процедур . В настоящее время это ручной процесс, который должен быть автоматизирован в MASTECS. На этом этапе создаются процедуры тестирования, состоящие из тестовой среды, микротестов и измерительных зондов для записи / отслеживания результатов.
  5. Сбор доказательств (тестирование). Процедуры тестирования выполняются на платформе для сбора доказательств тестирования. В настоящее время это связано с некоторой ручной работой, и это будет автоматизировано в MASTECS с использованием инфраструктуры автоматизации RapiTest для выполнения этих тестов и их обратной связи с требованиями проверки.
  6. Анализ результатов . Обзор результатов тестирования техническими экспертами, чтобы проверить, как результаты теста подтверждают (или иным образом) требования проверки. Например, на рисунке 3 показан снимок экрана RapiTime с указанием времени выполнения, указанного для различных функций программы.
  7. Подтвердите результаты и создайте документацию. Окончательный анализ требований, создание документации и результатов аттестации в поддержку аргументов безопасности системы. Заказчик может использовать полный набор отчетов и артефактов анализа непосредственно для сертификации программного обеспечения, работающего на многоядерных системах.

щелкните, чтобы увеличить изображение

Рис. 2. Шаги MTA в процессе разработки программного обеспечения V-модели. (Источник:авторы)

Опыт работы с оборудованием и процесс временного анализа

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

  1. Эксперты по аппаратному обеспечению определяют многоядерные конфигурации (критические параметры конфигурации на жаргоне авионики), поскольку они играют ключевую роль в определении функционального и временного поведения программного обеспечения и в значительной степени влияют на количество конкурирующих задач, генерируемых друг другом. В качестве наглядного примера, современные процессоры реализуют механизмы изоляции и разделения, которые при правильном развертывании могут значительно снизить конкуренцию.
  2. Эксперты по многоядерным процессорам играют ключевую роль в определении тех ресурсов, в которых может возникнуть конфликт задач (в авионике они называются каналами помех). Способность экспертов по аппаратному обеспечению ориентироваться в технических справочных руководствах по процессорам объемом в несколько тысяч страниц и формулировать соответствующие вопросы о возможной недостающей информации в руководствах для поставщиков микросхем имеет фундаментальное значение для управления соответствующим процессом MTA.
  3. После определения каналов помех специалисты по аппаратному обеспечению определяют те мониторы событий, которые можно использовать для отслеживания активности, которую задачи генерируют на этих каналах помех, в качестве прокси-метрики, чтобы ограничить конкуренцию, которая может возникнуть у задач. Также необходимо проверить правильность этих мониторов событий [2], для чего был разработан специальный набор микротестов.
  4. Наконец, специалисты по аппаратному обеспечению работают рука об руку со специалистами по временному анализу, чтобы вывести из требований пользователя высокоуровневые и низкоуровневые требования и специальные тесты для проверки гипотез, поддерживающих требования пользователей. Каждый тест реализует одну или несколько программ микротеста, разработанных экспертами по аппаратному обеспечению, чтобы обеспечить желаемый уровень нагрузки на целевой (набор) канал (ы) помех.

На поздних стадиях проектирования:

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

щелкните, чтобы увеличить изображение

Рисунок 3:Анализ результатов (RapiTime). (Источник:авторы)

Более широкая картина

Семиступенчатый процесс разработки тестов - лишь одна часть более широкой методологии многоядерной проверки, показанной ранее на рисунке 2. Эта методология, которая будет развиваться и дальше в рамках проекта MASTECS, предназначена для достижения полной прослеживаемости на основе исчерпывающих свидетельств и возвращает результаты к соответствующим требованиям и проектам. Методология разработана для достижения целей, определенных в CAST-32A, ключевом руководящем документе, выпущенном органами аэрокосмической сертификации. Он также специально согласован с ISO 26262, стандартом безопасности для автомобильного сектора, который защищает свободу от вмешательства.

CAST-32A был опубликован группой Certification Authorities Software Team (CAST) в 2016 году и определяет факторы, которые влияют на безопасность, производительность и целостность бортовых программных систем, выполняемых на многоядерных процессорах. Если вы хотите использовать многоядерное оборудование в системе авионики, этот документ вам подойдет. Он предоставляет цели, предназначенные для руководства производством безопасных многоядерных систем авионики, включая цели, связанные с выявлением и ограничением воздействия каналов помех. Ознакомьтесь с позиционным документом CAST-32A здесь. EASA и FAA работают над адаптацией многоядерного универсального CRI в общий материал AMC / AC (AMC 20-193). Ожидается, что он будет опубликован «позже в этом году» [3].

Экспертиза не может быть автоматизирована

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

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

Ссылки

[1] Райнхард Вильгельм. Смешанные чувства по поводу смешанной критичности. Семинар по анализу времени исполнения наихудшего случая, 2018 г.

[2] Энрико Меццетти, Леонидас Космидис, Жауме Абелла, Франсиско Х. Касорла. Высоконадежные блоки мониторинга производительности в автомобильных микросхемах для надежного отсчета времени. V&V. IEEE Micro 38 (1):56-65 (2018).

[3] https://www.aviationtoday.com/2020/02/28/easa-and-faa-to-issue-f Further-guidance-on-multicore-certification-this-year/


Встроенный

  1. Что такое отладка:типы и методы во встроенных системах
  2. Роль встроенных систем в автомобилях
  3. Являются ли текстовые строки уязвимостью во встроенном ПО?
  4. Архитектура SOAFEE для встроенной периферии позволяет программно определяемым автомобилям
  5. TRS-STAR:надежные и безвентиляторные встраиваемые системы от avalue
  6. Axiomtek:3,5-дюймовый встроенный SBC для критически важных и суровых условий
  7. Уязвимости программного обеспечения IIoT снова подпитывают критические атаки на инфраструктуру
  8. Искусственный интеллект предсказывает поведение квантовых систем
  9. Встроенные системы и системная интеграция
  10. Использование DevOps для решения проблем встроенного программного обеспечения