Основным нормативным документом, регламентирующим разработку встроенного программного обеспечения для авиационной техники, является стандарт КТ-178С. Для дорожных транспортных средств аналогичную роль выполняет серия стандартов ГОСТ Р ИСО 26262, в частности часть 6, посвящённая разработке программного обеспечения.
Подходы к разработке программного обеспечения в авиационной и автомобильной промышленности имеют как общие черты, так и существенные различия. Общность проявляется прежде всего в организации процесса разработки: и КТ-178С, и ГОСТ Р ИСО 26262 обязуют применение V-образной модели жизненного цикла, в рамках которой разработка программного обеспечения начинается с разработки требований, далее выполняется проектирование архитектуры и реализация программных компонентов, а на каждом этапе проводятся соответствующие процедуры верификации.
В то же время между этими нормативными подходами существует принципиальное различие, связанное с анализом безопасности программной архитектуры. Авиационные нормативные документы не предусматривают обязательного выполнения анализа безопасности на уровне программного обеспечения, в то время как, стандарт ГОСТ Р ИСО 26262 требует проведения такого анализа как одного из элементов доказательства функциональной безопасности.
Возникает закономерный вопрос: достигается ли достаточный уровень безопасности программного обеспечения в авиационной отрасли при отсутствии обязательного анализа безопасности на уровне программной архитектуры, и, напротив, не является ли проведение такого анализа избыточным в контексте автомобильной промышленности? Данная проблематика представляет значительный интерес и нередко становится предметом профессиональных дискуссий среди специалистов, имеющих опыт работы как с требованиями ГОСТ Р ИСО 26262, так и со стандартом КТ-178С.
Место анализа безопасности в процессе разработки авиационного ПО
Примечательной особенностью стандарта КТ-178С является то, что он напрямую не упоминает и не предписывает проведение анализа безопасности программного обеспечения. Это не является упущением, а отражает четкое разделение ответственности, заложенное в методологии. Само понятие «анализ безопасности ПО» вынесено за рамки КТ-178C и реализуется на предшествующем, системном уровне.
Основой для определения требований к программному обеспечению служат руководства ARP4754A(Б) по разработке воздушных судов и систем, а также ARP4761(A) по методам оценки безопасности систем и бортового оборудования. В ходе работ, выполняемых в соответствии с этими документами, проводятся все классические виды анализа безопасности, включая анализ видов и последствий отказов (FMEA) и анализ дерева неисправностей (FTA), но на уровне системы в целом. ПО на этом этапе рассматривается как неотъемлемая часть архитектуры системы.
Ключевым результатом системного анализа безопасности, который служит входными данными для разработки ПО, является определение Уровней Гарантии Разработки (DAL — Design Assurance Level). ПО классифицируется по уровням от A до E, где A соответствует наивысшей критичности. Именно уровень DAL определяет строгость и набор мероприятий, которые необходимо применить при разработке ПО по КТ-178C . Например, для DAL A демонстрация соответствия исходного кода архитектуре ПО является обязательной и должна проводиться при помощи независимых мероприятий. Для DAL B это требование может быть смягчено, оставляя заявителю определенную свободу в выборе методов подтверждения и её необходимости в целом.
Из этого следует, что в авиационной практике ПО рассматривается преимущественно как задача обеспечения качества проектирования (design assurance), а не как прямой объект классического анализа безопасности. Основное требование КТ-178C к архитектуре ПО заключается в ее четком определении и последующей верификации на соответствие заданным требованиям. Стандарт не требует проведения отдельного программного FMEA или FTA, так как этот анализ уже выполнен на системном уровне.
Таким образом, КТ-178C выполняет функцию стандарта, гарантирующего, что реализация ПО не нарушит допущения по безопасности, установленные на системном уровне.
Следовательно, доверие к безопасности ПО в авиации формируется не путем поиска опасностей внутри самого кода, а посредством доказательства того, что ПО является корректным, детерминированным и строго ограничено предписанными ему требованиями безопасности, источником которых является системный анализ. КТ-178C не «упускает» анализ безопасности ПО — он выстраивает целостный аргумент безопасности, опираясь на распределение требований на системном уровне в сочетании с дисциплинированным проектированием и верификацией ПО.
Место анализа безопасности в процессе разработки автомобильного ПО
По аналогии с подходами в авиации ГОСТ Р ИСО 26262-4 также требует проведение анализа безопасности на уровне системы. Но в отличие от авиационного подхода, стандарт ГОСТ Р ИСО 26262 дополнительно интегрирует анализ безопасности непосредственно в процесс разработки программного обеспечения, а не выносит его исключительно на системный уровень. Это принципиальное различие отражает иную философию построения аргументации безопасности в автомобильной промышленности.
Стандарт ГОСТ Р ИСО 26262 -6, посвящённый разработке ПО, явным образом требует проведения анализа безопасности программной архитектуры . В соответствии с его положениями, реализация требований безопасности ПО зависит от отсутствия влияния или достаточной независимости между программными компонентами. Основная цель проведения анализа заключается в демонстрации отсутствия нарушения требований безопасности.
Такие систематические ошибки ПО зачастую возникают из-за ошибок в разработке ПО, а именно в нарушениях потоков данных или потоков управления между компонентами архитектуры ПО. Анализ безопасности позволяет ввести некоторые меры по недопущению этих нарушений, по их обнаружению или предотвращению их последствий. Основной мерой недопущения систематических нарушений, разумеется, является соблюдение процессов разработки ПО, а для обнаружения нарушений или предотвращения их последствий архитектура ПО дополняется механизмами безопасности.
Из всего этого следует, что в автомобильной практике ПО рассматривается как полноправный и дополнительный объект анализа безопасности наравне с системой и аппаратурой.
Истоки методологических расхождений
Возникает закономерный вопрос: если в автомобильной отрасли анализ безопасности на системном уровне выполняется аналогично авиационным процессам, то почему нельзя ограничиться только им и доказательством безопасности ПО через корректность его разработки, как это делает КТ-178C? Ответ на этот вопрос, безусловно, остаётся за разработчиками стандартов, но мы можем выдвинуть обоснованные гипотезы, объясняющие сложившееся различие.
Ключ к пониманию кроется в более фундаментальных требованиях, предъявляемых к разработке авиационной и автомобильной техники на самом верхнем уровне. Для самолетов транспортной категории нормы летной годности (АП-25, часть 1309) устанавливают жесткий императив: любое катастрофическое отказное состояние не должно являться следствием единичного отказа и должно быть практически невероятным. Это требование фундаментально меняет подход к проектированию. Оно обязывает разработчиков закладывать в архитектуру системы многократное резервирование критически важных компонентов. В такой парадигме последствия отказов, включая отказы программного обеспечения, парируются именно на системном уровне. Сами отказы могут возникать, но архитектура системы гарантирует, что они не приведут к катастрофе благодаря резервированию и функциональному дублированию.
В автомобилестроении ситуация иная. Требования к разработке здесь менее императивны в части архитектурной избыточности. Даже для наивысшего уровня ASIL D не существует обязательного требования резервировать все критические компоненты. Однако это не отменяет необходимости обеспечивать безопасность. В этих условиях роль программного обеспечения становится определяющей - именно на него ложится основная нагрузка по предотвращению или парированию опасных ситуаций, т.е. требования безопасности ПО.
Здесь и вступает в силу анализ безопасности программной архитектуры, направленный на недопущение нарушений требований безопасности ПО из-за систематических ошибок в ПО. Поскольку аппаратное резервирование не является обязательным, инженеры вынуждены компенсировать это введением мер и механизмов безопасности непосредственно в ПО: алгоритмов самодиагностики, контроля целостности данных, защитных отключений и т.д. Но чтобы эти механизмы были эффективны, их необходимо тщательно спроектировать. Именно эту функцию выполняет дополнительный анализ безопасности ПО, требуемый ГОСТ Р ИСО 26262-6.
Таким образом, если в авиации безопасность достигается за счет аппаратной избыточности на системном уровне, а от ПО требуется лишь корректно выполнять заданные функции в рамках этой надежной архитектуры, то в автомобилестроении ПО само становится активным элементом обеспечения безопасности. Проведение анализа его архитектуры позволяет целенаправленно встраивать защитные механизмы и доказывать их достаточность, компенсируя отсутствие жестких требований к аппаратному резервированию. Это и объясняет, почему автомобильный стандарт пошел по пути включения ПО в контур непосредственного анализа безопасности, в то время как авиационный оставил эту функцию исключительно за системным уровнем.
А как вы считаете: достаточен ли авиационный подход, при котором анализ безопасности архитектуры ПО не выполняется только на системном уровне, или же автомобильная практика с обязательным анализом программной архитектуры выглядит более обоснованной? Поделитесь своим мнением.
Еще больше интересных статей вы можете прочитать ниже: