Программисты на месте? Пристегнитесь, мы взлетаем!
Наверняка, каждому представителю технической специальности доводилось хотя бы раз в жизни писать код: при выполнении лабораторных и курсовых работ в вузе, на стажировке или реальном проекте. Менеджеры и управленцы, не пропускайте этот пост, наверняка у вас тоже бывали ошибки, о которых пойдет речь.
Как часто при написании программ вы прописываете проверочные условия, которые обеспечивают безопасную и корректную работу программы? Многие думают: «Да что может пойти не так? Я же лично входные данные задаю». Но что делать если что-то произойдет с бортовым ПО прямо во время полета? Задумывались ли Вы, почему нельзя писать ПО для авиационных систем так же, как мобильного приложения? Давайте рассмотрим топ-5 проблем бортового ПО, а в помощь нам КТ-178С
и Misra C.
1.Неопределенное поведение
В C/C++ есть конструкции, поведение которых не определено стандартом. Например, переполнение знакового целого.
Компилятор может:
- проигнорировать ситуацию,
- применить правила «дополнительного кода»
- инвертировать значение
Как регулируется:
→ MISRA C, Rule 1.3, 17.3 — запрет неопределенного и критического незаданного поведения, функции не должны задаваться неявно.
→ КТ-178С, п. 6.1 — процесс верификации направлен на выявление ошибок, внесенных на этапах разработки.
→ Обязательное тестирование граничных и «выходящих за рамки» значений.
2. Бесконтрольная рекурсия
Рекурсия (понимаем вызов функции саму себя) без ограничения глубины вызовов может переполнить стек и вызвать отказ системы управления в полете.
Пример: Ваш ребенок хочет пойти погулять, отпрашивается у мамы, но происходит следующая картина.
Мама: «спроси у папы»
Папа: «спроси у мамы»
Мама: «спроси у папы»
Как регулируется:
→ MISRA C, Rule 17.2 — функции не должны вызывать сами себя, прямо или косвенно.
→ КТ-178С, п. 11.7.e — должны быть учтены ограничения на проект, например, исключение рекурсии, динамических объектов, альтернативных имен данных и компактных выражений.
3. «Мертвый» и посторонний код
Такой код не покрывается тестами, усложняет верификацию и может содержать скрытые уязвимости.
Пример: вы подготовили универсальное резюме, чтобы отправлять его в разные компании, но забыли его проверить перед отправкой и теперь вы 18-летний Senior-разработчик с 30-летним опытом работы в IT.
Как регулируется:
→ КТ-178С, п. 5.2.4, 6.4.4.3.c и 6.4.4.3.d — мертвый и посторонний код должен быть строго обоснован или удален.
→ MISRA C, Rule 2.1-2.7 — динамическое выделение памяти запрещено, чтобы избежать «непредсказуемого» поведения.
4. Недостаточная изоляция компонентов
В авионике сбой в одном модуле не должен влиять на другие — например, отказ навигации не должен вывести из строя управление шасси.
Как регулируется:
→ КТ-178С, п. 2.4.1 — поддержка обособления (partitioning) через выделенные ресурсы процессора и памяти.
→ MISRA C, Rule 8.1-8.12 — явное указание внешних ссылок и запрет глобальных переменных без контроля.
5. Неполное покрытие тестами
Каждое условие в логическом выражении должно быть протестировано независимо. Для авиационного ПО уровня A (самый критичный) необходимо проводить дополнительную верификацию, чтобы установить корректность сгенерированных последовательностей кода.
Как регулируется:
→ КТ-178С, пп. 6.4.4 — покрытие требований высокого и низкого уровней, структуры и проведение дополнительной верификации кода (для ПО уровня гарантии разработки А) обязательны.
Вместо итога
Разработка авиационного ПО — это не просто написание кода, а целое искусство, доказывающее безопасность полета. Каждая строчка проходит через многоуровневую верификацию, чтобы гарантировать, что даже в экстремальных условиях самолет останется под контролем.