А есть ли гарантии?
Дмитрий К.Попытки отдельных «философов» разработать методику по расчёту надёжности программного обеспечения до сих пор не увенчались успехом. В авиационном сообществе пришли ко мнению, что если при разработке аппаратных средств и программного обеспечения помимо традиционных методов доказательств безопасности системы будет применяться набор требований к процессам, соблюдение которых приведёт к минимизации ошибок, то можно достичь уровня, при котором будут обеспечены приемлемые уровни рисков. А чтобы стоимость разработки воздушных судов не стала чрезмерно высокой, были определены пять уровней в соответствии с критичностью выполняемых системой функций, и для каждого уровня определён свой набор требований.
Руководство 4754А по разработке воздушных судов гражданской авиации и систем определяет требования по назначению уровней гарантии разработки (Development Assurance Level) на самый верхний уровень – функции воздушного судна и самолётных систем. В документе определены следующие уровни, которые соответствуют степеням особых ситуаций, установленных в действующих авиационных правилах: DAL A – катастрофическая ситуация, DAL B – аварийная ситуация, DAL C – сложная ситуация, DAL D – усложнение условий полёта, DAL E – без ситуации. В рамках данной статьи углубляться в определение этих ситуаций мы не будем, в целом, они понятны инженеру, стоит только заметить, что аналогичная градация есть и в ГОСТ Р ИСО 26262 – уровень полноты безопасности автомобиля (Automotive Safety Integrity Level), за исключением того, что строгость уровня идёт в обратном порядке.
Как говорилось ранее, Руководство 4754А определяет требования на уровень воздушного судна и самолётных систем к таким процессам как:
- планирование;
- разработка;
- оценка безопасности;
- валидация требований;
- верификация;
- управление конфигурацией;
- гарантия процессов;
- взаимодействие с сертифицирующими и регулирующими органами.
Из вышеперечисленного видно, что для обеспечения безопасности полётов на необходимом уровне недостаточно выполнять только оценку безопасности самолёта, необходимо организовать процессы, которые позволят минимизировать количество ошибок. Но мы пока рассмотрели верхний уровень требований, а что насчёт программного обеспечения?
Полученные требования верхнего уровня трассируются (и это тоже требование к процессу) на нижний уровень для разработки аппаратных средств и программного обеспечения. На этом уровне есть свои нормативные документы, такие как квалификационные требования КТ-254 «Руководство по гарантии конструирования бортовой электронной аппаратуры», КТ-178С «Требования к программному обеспечению бортовой аппаратуры и систем при сертификации авиационной техники», которые в свою очередь устанавливают требования к процессам в соответствии с уровнем гарантии разработки, спущенного с верхнего уровня (уровня системы).
На примере КТ-178С мы видим аналогичные требования к процессам:
- планирование ПО;
- разработка ПО;
- верификация выходных данных процесса разработки требований к ПО;
- верификация выходных данных процесса проектирования ПО;
- верификация выходных данных процессов кодирования и интеграции ПО;
- верификация выходных данных процесса интеграции (тестирование);
- верификация выходных данных процесса верификации ПО;
- управление конфигурацией;
- гарантия качества ПО;
- взаимодействие с сертифицирующими органом.
И в каждом процессе определены свои цели, которые должны быть достигнуты для соответствующего уровня гарантии разработки. Пример распределения целей для процесса верификация выходных данных процессов кодирования и интеграции ПО приведён ниже:
Даже при таком поверхностном рассмотрении нормативной документации видно, что цели безопасности систем достигается при строгом соблюдении процессов разработки этих систем. Можно пытаться разрабатывать методики по подсчёту ошибок, допущенных при написании кода, но что даст этот подход? Только статистику для определённого языка программирования на определённый период нашей эпохи? Сейчас, когда мы находимся в эпоху развития ИИ, когда совершенствуются инструменты для разработки, сбор статистики с целью анализа надёжности ПО выглядит, как аварийно-опасный участок дороги, на котором мы ведём учёт аварий, но не предпринимаем никаких мероприятий по снижению аварийности. Это тупиковое развитие. Гораздо важнее сосредоточиться на системном подходе разработки, совершенствовать и дополнять цели и применяемые методы, это позволит гарантировать достижение требуемого уровня безопасности.