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

Авторы: Иво Медейрос, Марко Антонио Альваренга, Паула Борхес Оливио и Педро Энрике М Орта.

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

Цифровая трансформация, возможность собирать и обрабатывать огромные объемы данных и шумиха в отношении искусственного интеллекта (AI) и его подполя машинного обучения (ML) - вот движущие силы будущего. Технологии AI и ML также могут быть частью огромного комплекса систем, таких как AV. «Новая технология» позволяет разрабатывать эффективные решения технических проблем, которые невозможно решить с помощью традиционного подхода. Тем не менее, когда дело доходит до применений в критически важных для безопасности бортовых системах, необходимо проявлять особую осторожность, прежде чем рассматривать их как коммерчески жизнеспособные.

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

Начиная с начальной фазы разработки критически важной для безопасности системы, заявитель, т. Е. Компания, которая намеревается утвердить эту систему центрами сертификации, должна следовать строгим процессам обеспечения разработки, включая оценку безопасности системы, управление требованиями, оценку архитектуры, широкий охват. анализов и, в конечном итоге, исчерпывающая тестовая кампания на соответствие процессу и всем требованиям. Это огромный процесс, который включает в себя большой объем работы и несколько различных инженерных дисциплин; и потребует подробного описания множества страниц. Подробнее об этом подробно говорится в SAE ARP-4754A.

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

Сертификация «обычных» бортовых систем

Три столпа программной инженерии - это требования, реализация и тестирование. Как упоминалось ранее, наиболее распространенный процесс разработки бортовых систем описан в SAE ARP-4754A. ARP обращается к циклу разработки всего самолета, который разделен на три уровня абстракции: самолет, системы и элементы. Процесс ARP состоит из систематического подхода к развертыванию, проверке и проверке требований на каждом из этих уровней абстракции. В этом смысле цель процесса состоит в том, чтобы гарантировать, что требования к самолету зафиксированы и могут быть прослежены до каждого элемента системы. Системный элемент может быть программным или аппаратным. Конечно, в контексте данной статьи мы имеем дело с программным элементом любой критически важной для безопасности системы. См. Ниже упрощенную схему процесса ARP-4754A.

Проще говоря, следуя ARP, мы должны были получить полный набор системных требований для разработки нашего программного продукта. Этот набор системных требований должен быть преобразован в требования к программному обеспечению высокого и низкого уровня и только затем кодифицирован. Процесс разработки программного обеспечения должен следовать другому хорошо известному руководству в авиационной отрасли, RTCA DO-178C - Рекомендации по программному обеспечению при сертификации бортовых систем и оборудования (DO).

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

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

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

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

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

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

Здесь можно спросить, следует ли рассматривать модель как системный элемент в соответствии с ARP 4754. Ответ - нет, модель не является частью системы. Модель находится посередине между системой и ее программным элементом, и она будет переведена в программное обеспечение посредством требований.

Модели уже давно поддерживают разработку программного обеспечения в авиационной отрасли. Дифференциальные уравнения, пространство состояний и логические уравнения регулярно используются в процессе проектирования критически важных для безопасности систем и их программных элементов. RTCA DO-331 - Дополнение для разработки и проверки на основе моделей к DO-178C и DO-278A, дополнение к DO-178C, представляет собой руководство для разработчика программного обеспечения, которое использует преимущества моделей в своей конструкции. Интересно отметить, что DO-331 не о процессе создания модели, а о том, как адаптировать цели DO-178C, чтобы гарантировать, что элементы модели правильно реализованы в программном обеспечении.

Таким образом, несмотря на растущую актуальность моделей при разработке новых продуктов, систем и их программного обеспечения, текущие процессы сертификации систем игнорируют проектирование моделей. Однако времена, кажется, меняются, центры сертификации по всему миру обсуждают проблемы обеспечения безопасности при встраивании функций на основе машинного обучения в бортовую систему; и дизайн модели кажется следующим этапом процесса сертификации новых UAM (городской воздушной мобильности), таких как БПЛА и eVTOL. А руководство и стандарты по аспектам сертификации для искусственного интеллекта, и в данном случае решений на основе машинного обучения, являются предметом различных комитетов, например Искусственный интеллект SAE G-34 для авиации.

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

Вот несколько сложных аспектов, которые необходимо преодолеть с помощью этого нового подхода:

Обеспечение разработки: традиционная структура (DO-178C и DO-278) должна быть адаптирована для работы с этим новым набором систем и возможностей, допускаемых моделями на основе машинного обучения;

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

Наблюдаемость и интерпретируемость. Возьмем для примера классическую нейронную сеть. Отследить, какие нейроны были активированы, непросто; например, после генерации вывода или для объяснения на естественном языке, почему нейронная сеть решила выдать такой результат. Это создает проблемы для отслеживания, проверки и валидации.

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

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

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

использованная литература

G-34 Искусственный интеллект для авиации
AS6983 - Технологический стандарт для разработки и сертификации / утверждения продуктов, связанных с авиационной безопасностью, реализующих ИИ
WIP (рабочий в процессе): https://www.sae.org/works/committeeHome.do?comtID=TEAG34

ARP 4754
WIP: https://www.sae.org/standards/content/arp4754b/
(новый выпуск 2020 г., ARP 4754b с 2012 г.)

DO-178
https://my.rtca.org/NC__Product?id=a1B36000001IcmwEAC

DO-331
https://my.rtca.org/ NC__Product? Id = a1B36000001IcfiEAC

DO-333
https://my.rtca.org/NC__Product?id=a1B36000001IcfeEAC

Https://www.easa.europa.eu/sites/default/files/dfu/EASA-AI-Roadmap-v1.0.pdf

Https://www.easa.europa.eu/sites/default/files/dfu/EASA-DDLN-Concepts-of-Design-Assurance-for-Neural-Networks-CoDANN.pdf



Машинное обучение - AVSI
Исследование, проведенное в рамках AFE 87 -« Машинное обучение
, рассматривало влияние внедрения машинного обучения… avsi.aero»