💻 Safeware: ТОП-5 главных рисков ПО Программисты на месте? Пристегнитесь, мы взлетаем! Наверняка, каждому представителю технической специальности доводилось хотя бы раз в жизни писать код: при выполнении лабораторных и курсовых работ в вузе, на стажировке или реальном проекте. Менеджеры и управленцы, не пропускайте этот пост, наверняка у вас тоже бывали ошибки, о которых пойдет речь. Как часто при написании программ вы прописываете проверочные условия, которые обеспечивают безопасную и корректную работу программы? Многие думают: «Да что может пойти не так? Я же лично входные данные задаю». Но что делать если что-то произойдет с бортовым ПО прямо во время полета? Задумывались ли Вы, почему нельзя писать ПО для авиационных систем так же, как мобильного приложения? Давайте рассмотрим топ-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 — покрытие требований высокого и низкого уровней, структуры и проведение дополнительной верификации кода (для ПО уровня гарантии разработки А) обязательны. Вместо итога Разработка авиационного ПО — это не просто написание кода, а целое искусство, доказывающее безопасность полета. Каждая строчка проходит через многоуровневую верификацию, чтобы гарантировать, что даже в экстремальных условиях самолет останется под контролем. 😃 [FTS] Экварта | Лицом к безопасности