Автор: Сюй Илунфэй, группа системного моделирования, Шанхайский научно-исследовательский институт инноваций в области доверенного программного обеспечения Конган
Раздел| Форум Цзяньюань · Посмотреть модель
Сообщество | Добавьте идентификатор WeChat « TICPShanghai » и присоединитесь к «Сообществу безопасности Shanghai Kongan 51fusa»
01
краткое содержание
В данной статье в основном обсуждается промышленное применение формальных методов в области аэронавтики. Авиационная отрасль является сферой, где безопасность критически важна, и при разработке программного обеспечения бортовых систем применяются очень сложные и строгие стандарты безопасности, обеспечивающие ее безопасность и надежность. Однако из-за увеличения программных функций бортового комплекса масштаб программного комплекса увеличился, а вся система стала более сложной, что затрудняет соответствие традиционному методу требованиям проверки системы управления полетом. . Для решения болевых точек в авиационной сфере эффективным решением становятся формальные методы. Формальные методы — это инженерные методы, основанные на математике и формальной логике, которые можно использовать для проектирования, проверки и анализа систем. Применение формальных методов помогает обеспечить безопасность полетов, улучшить летно-технические характеристики самолетов и оптимизировать системы управления полетом.
02
Опыт применения в области авиации
В области авиации программное обеспечение системы управления полетом является основным компонентом и играет решающую роль во всем самолете. Его безопасность и надежность играют жизненно важную роль в нормальной эксплуатации самолета. В случае сбоя программного обеспечения причиненный ущерб будет быть огромным. Однако из-за сложности современного программного обеспечения систем управления полетом, которое предполагает совместное взаимодействие программного и аппаратного обеспечения, традиционные методы тестирования не только требуют много человеческих ресурсов и временных затрат, но также трудно охватить все возможные ситуации. чтобы полностью избежать потенциальных угроз безопасности. Это создает риск возникновения проблем с требованиями или проектированием системы в процессе разработки системного программного обеспечения. Исторически сложилось так, что катастрофические аварии, которые привели к тяжелым потерям из-за таких проблем, шокируют. В 2007 году программное обеспечение управления полетом истребителя F-22 ВВС США не учитывало разницу во времени: при изменении пилотом системного времени при пересечении международной линии времени система управления полетом блокировалась, в 2018 и 2019 годах программное обеспечение управления полетом двух самолетов. Дефект в центральной противостопорной системе (MCAS) стал причиной крушения и гибели в общей сложности более 300 человек.
Рисунок 1 Типичные программные аварии: инциденты с F-22 и Boeing 737-MAX (фотографии из новостей)
Уроки крови и слез в истории человеческой авиации способствовали постоянному совершенствованию стандартов сертификации летной годности. Чтобы лучше обеспечить безопасность и корректность бортового программного обеспечения, авиационная отрасль предложила стандарт DO-333. Стандарт DO-333 был написан Специальным комитетом RTCA (Авиационный радиотехнический комитет) и Рабочей группой EUROCAE (Европейская организация по оборудованию гражданской авиации) и одобрен Комитетом по управлению программой RTCA (PMC) 13 декабря 2011 г. под названием «Дополнение к формальным методам к DO-178C и DO-278A». Среди них DO-178C — стандарт разработки программного обеспечения для самолетов в авиационной области, а DO-278A — стандарт разработки соответствующего программного обеспечения наземных систем. И DO-333 является дополнением к ним и призван помочь командам разработчиков авиационного программного обеспечения применять формальные методы в жизненном цикле разработки программного обеспечения. В DO-333 внесены некоторые изменения и дополнения в цели, действия, пояснительный текст и данные о процессах жизненного цикла программного обеспечения, приведенные в исходном DO-178C. Эти изменения и дополнения включают несколько документов, описанных формальным языком, а также материалы, подтверждающие формальную проверку, основанные на этих официальных документах. С этой целью в ДО-333 специально внесены целевые дополнения и корректировки. Стандарт летной годности DO-333 определяет процесс разработки программного обеспечения как четыре звена, а именно: процесс разработки требований к программному обеспечению, процесс проектирования программного обеспечения, процесс кодирования программного обеспечения и процесс наследования программного обеспечения. В нем также выдвигаются цели проверки для каждого процесса разработки программного обеспечения, объясняется, как применять формальные методы в четырех звеньях разработки программного обеспечения, а также излагаются его преимущества и недостатки. Предложение этого стандарта показывает, что в области авиации, критически важной для безопасности, способность формальных методов повышать безопасность и надежность бортового программного обеспечения в технике была в определенной степени признана, что также привело к тому, как лучше применить его к бортовое программное обеспечение.Обсуждения в процессе разработки и сертификации.
03
Формальные методы решения
Формальные методы — это методы написания спецификаций, разработки и проверки программного обеспечения для цифровых систем, основанные на строгой математике. Формальная математическая основа в основном включает формальную логику, дискретную математику и машинно-распознаваемый язык. Основная идея исследования формальных методов заключается в том, что инженеры надеются строго проанализировать надежность и правильность проектирования программного обеспечения с помощью разумных теоретических и инженерных методов, особенно методов математического анализа, чтобы обнаружить дефекты программного обеспечения, которые трудно обнаружить при проверке человеком, и для удовлетворения высоких требований людей.Доверенные ожидания в отношении качественного программного обеспечения. Основная особенность формального метода — четко и без двусмысленности описать требования к программной системе и обеспечить строгую проверку непротиворечивости и точности программного обеспечения посредством формального выражения программного обеспечения.
Формальные методы обычно включают два типа ключевых технологий, а именно формальное моделирование и формальный анализ. Два из них имеют несколько типов методов реализации. При формальном моделировании формальная модель, определяемая однозначным математическим синтаксисом и семантикой, может быть создана различными методами, например, формальная графическая модель, где компоненты графа и связи между ними имеют строгий математически определенный синтаксис и семантику, например состояние машины в инструментах SCADE являются типичными случаями формализованного графического моделирования. Существуют также модели, описываемые с использованием формальных языков моделирования, таких как язык Z, метод B, BIP. Формальные методы анализа можно сгруппировать в 3 категории: 1) дедуктивные методы, такие как доказательство теорем, 2) проверка модели и 3) абстрактная интерпретация.
1) Дедуктивный метод: предполагает математические рассуждения, то есть доказательство свойств формальных моделей математическими методами. Математическое доказательство свойств предоставляет строгие доказательства правильности свойств программного обеспечения. Математическим доказательствам обычно помогают автоматизированные или интерактивные системы доказательства теорем. В некоторых случаях построение математических доказательств может быть трудным или даже невозможным даже при использовании систем доказательства теорем. Однако как только доказательство может быть построено, становится легко автоматически проверить правильность доказательства.
2) Проверка модели: исследуйте все возможные варианты поведения формальной модели, чтобы определить, сохраняются ли указанные свойства. Если свойство не выполняется, алгоритм проверки модели автоматически генерирует контрпример, чтобы определить, где и почему свойство не выполняется. В некоторых случаях инструменты проверки модели могут быть не в состоянии определить, сохраняется ли данное свойство.
3) Абстрактная интерпретация: это теория построения консервативного представления (консервативного) семантики языка программирования (консервативного представления для обеспечения надежности). На практике эта технология разрабатывает алгоритм анализа, основанный на семантике программы для систем с бесконечным состоянием, который может статически, автоматически и надежно анализировать динамические свойства системы. Абстрактные интерпретации с помощью соответствующих инструментов создают формальные модели конкретных свойств. Этот метод можно рассматривать как частичное выполнение компьютерной программы без фактического выполнения всех вычислительных задач при определении важных влияющих отношений между программами (таких как структура потока управления, поток информации, размер стека, количество тактовых циклов и т. д.).
04
Приложения
Этот пример применения взят из «Примеры использования формальных методов для DO-333.», в котором представлены примеры применения формальных методов в области аэрокосмической промышленности. Чтобы проверить, удовлетворяет ли спецификация системы конкретным свойствам и требованиям, применяется проверка модели для проверки правильности односторонней логики модели системы наведения полета (FGS). Логика режима является ключевым компонентом системы управления полетом, который определяет навигацию и поведение автопилота самолета, а ее правильность имеет решающее значение для обеспечения безопасности полета. В FGS логика схемы относительно сложна, но входные и выходные данные состоят только из логических значений, что делает ее подходящей для формальной проверки с использованием проверки модели.
4.1 Обзор логики схемы
Режим относится к взаимоисключающему набору поведений системы. Для системы FGS режим соответствует конфигурации системы одного (или группы) поведений FGS. Точнее, режим FGS представляет собой абстракцию законов управления полетом, и его режим «Логика» в основном состоит из трех разных типов шаблонов.
1. Режим без постановки на охрану (режим без постановки на охрану): этот режим имеет только два фактических состояния: ОЧИСТЕН и ВЫБРАН. Режим считается состоянием «Выбрано», если он запрошен вручную летным экипажем или автоматически подсистемой, такой как FMS, в противном случае он считается состоянием «Разрешено».
Рисунок 2. Режим без постановки на охрану
2. Режим постановки на охрану: этот режим имеет три состояния: ОХРАНА, АКТИВНОСТЬ и ВЫБРАН. ОХРАНА и АКТИВ являются подсостояниями состояния ВЫБРАН, то есть, когда режим находится в состоянии ОХРАНА или АКТИВ, он также находится в состоянии ВЫБРАН.
Рисунок 3. Режим охраны
3. Режим захвата/отслеживания: по сравнению с предыдущим режимом, в этом режиме различаются состояния захвата и отслеживания в АКТИВНОМ режиме. Оба состояния CAPTURE и TRACK являются подсостояниями состояния ACTIVE, а законы управления полетом этого режима являются АКТИВНЫМИ в обоих состояниях, т.е. генерируют инструкции для систем наведения полета и автопилота.
图4 Режим съемки/слежения
4.2 Цели случая проверки модели
Целью этого случая является формальная проверка логики модели на одной стороне FGS, чтобы гарантировать, что она удовлетворяет требованиям спецификации и законов управления полетом. Используйте проверку модели для выполнения действий по проверке, связанных с результатами процесса проектирования программного обеспечения, уделяя особое внимание целям таблицы A-4 в DO-178C и таблицы FM.A-4 в DO-333. Целью этих действий по проверке является обнаружение любых ошибок, которые могут быть допущены в процессе разработки программного обеспечения (DO-178C, раздел 5.2). В частности, в этом случае будут проверены требования к программному обеспечению низкого уровня логики шаблона на стороне FGS и показано, что архитектура программного обеспечения и требования к программному обеспечению низкого уровня соответствуют требованиям к программному обеспечению высокого уровня. Подробные цели проверки показаны в Таблице 1.
Таблица 1. Цели проверки программного обеспечения
4.3 Инструменты и методы проверки модели
В этом случае используются два основных типа средств проверки моделей: средства проверки модели BDD с неявным состоянием (например, NuSMV) и средства проверки модели SMT (например, Kind). Эти две модели проверочных устройств подходят для различных типов спецификаций и задач проверки.
Процесс проверки :
1. Сначала преобразуем логическое описание схемы FGS в форму, приемлемую для средства проверки модели, например язык спецификации в форме Lustre.
2. Идентифицировать и указать различные состояния и переходы между состояниями логики шаблона.
3. Напишите протокол и спецификацию свойств, охватывающую все требования целевой проверки.
4. Проверьте спецификацию и свойства с помощью средства проверки модели, чтобы найти возможные ошибки и контрпримеры.
Результаты проверки:
Путем проверки средства проверки модели получается результат того, удовлетворяет ли логика модели спецификации и закону управления полетом. Если средство проверки модели обнаруживает ошибки или контрпримеры, команда разработчиков может вносить исправления и проводить повторную проверку до тех пор, пока все цели не будут достигнуты. Когда модальная логика модели FGS была окончательно проверена с помощью средства проверки модели Kind, всего было обнаружено шестнадцать ошибок.
Пример ошибок, обнаруженных при проверке модели:
Ниже мы подробно расскажем, как использовать инструмент проверки модели для поиска ошибок.На рисунке 5 показана очень простая, но распространенная ошибка именования.При выходе из режима ACTIVE выходной переменной LGA_Active (правильный регистр должен быть VGA_Active) присваивается значение false. Эту ошибку обнаружила программа проверки модели Kind. Обратный пример, созданный средством проверки модели Kind, показан на рисунке 6.
Рисунок 5. Пример ошибок, полученных при проверке модели
Рисунок 6. Контрпримеры, полученные при проверке модели
Этот контрпример состоит всего из 3 шагов и показывает значения соответствующих входных и выходных данных для каждого шага. Значения, которые не изменились, показаны серым текстом. Серым фоном отмечены наиболее важные значения, которые помогут читателю понять противоположный пример. На начальных этапах режим ROLL_Active активен, как и ожидалось. На втором этапе режим LGA активируется нажатием переключателя GA. Это также активирует режим VGA. На третьем шаге активируется VS_Pitch_Wheel_Rotated, очищает режим VGA, то есть переходит из состояния ACTIVE в состояние CLEARED, однако на самом деле на третьем шаге режим LGA не очищается, а из-за ошибки в именовании выходная переменная LGA_Active неверно установлено значение false.
Таким образом, формальные методы начали получать все больше и больше внимания в авиационной сфере и постепенно вошли в соответствующий процесс проверки. Благодаря практическому применению в промышленности формальный метод продемонстрировал свою ценность в повышении безопасности и надежности бортовых программных систем. С помощью формальных методов мы можем точно определить спецификации и свойства системы и автоматически проверить правильность системы на разных этапах жизненного цикла разработки программного обеспечения. Развитие формальных методов будет и дальше способствовать инновациям и прогрессу разработки программного обеспечения в авиационной сфере, а также обеспечит более надежную гарантию безопасности полетов. Благодаря постоянным углубленным исследованиям и практике формальные методы будут продолжать играть важную роль в авиационной сфере, обеспечивая постоянную поддержку безопасности и надежности систем управления полетом. В будущем мы продолжим вводить больше технических деталей и больше случаев применения формальных методов.
основная ссылка:
1. RTCA DO-333, Дополнение формальных методов к DO-178C и DO-278A (декабрь 2011 г.)
2. Кофер Д., Миллер С. П. Примеры формальных методов для DO-333[R]. 2014.
3. Платцер А., Кезель Дж. Д. Европейская система управления поездами: пример формальной проверки [C] // Международная конференция по формальным инженерным методам. Берлин, Гейдельберг: Springer Berlin Heidelberg, 2009: 246–265.
4. Кларк Э. М. Проверка моделей [C] // Основы программных технологий и теоретической информатики: 17-я конференция Харагпур, Индия, 18–20 декабря 1997 г. Материалы 17. Springer Berlin Heidelberg, 1997: 54–56.
5. Кузо П., Кузо Р. Абстрактная интерпретация: единая решетчатая модель для статического анализа программ путем построения или аппроксимации фиксированных точек[C] //Материалы 4-го симпозиума ACM SIGACT-SIGPLAN по принципам языков программирования. 1977: 238–252.