Разработка ПО в соответствии с КТ-178/DO-178

Вячеслав, расскажите пожалуйста, какой опыт есть в компании по разработке в соответствии со стандартом КТ-178.

Давайте я сначала расскажу о стандарте КТ-178, точнее о его последней редакции, документе КТ-178C или его зарубежной основе — документе DO-178C. Этот документ посвящен функциональной безопасности (functional safety) программного обеспечения в таком критически важном применении как ПО для летательных аппаратов. В нем описываются цели для всего жизненного цикла ПО: от стадии планирования до сертификации, мероприятия и практики, рекомендуемые для достижения указанных целей, а также способы проверки того, что цели разработки надёжного с точки зрения безопасности ПО достигнуты.

Я правильно понимаю, что запросы на разработку в соответствие с этим стандартом поступают от клиентов, преимущественно работающих в аэрокосмической области?

И да, и нет. Основной наш заказчик на разработку по DO-178, с которым мы уже сотрудничаем более 25 лет, — это компания-разработчик Операционной Системы Реального Времени (ОСРВ). А уже эта ОСРВ используется конечными заказчиками – компаниями, создающими летательные и космические аппараты. Хотя эта же ОСРВ может использоваться в других областях, например, для автоматизации производства.

А применяется ли стандарт КТ-178С для разработки безопасного ПО в других областях?

Хотя, в подходах к разработке безопасного ПО много общего, исторически в разных областях промышленности образовались свои рабочие группы по безопасности ПО, были созданы свои регулирующие документы, и, конечно свои сертифицирующие органы. Более того, целевой рынок, то есть страны использования устройства и ПО влияют не только на то, какой орган будет его сертифицировать, но и какие стандарты functional safety будут использованы. Так, например, при разработке ПО медицинского устройства для рынка стран ЕС разработчикам надо следовать IEC 62304, а при разработке ПО для электронных блоков, устанавливаемых в серийно производимых автомобили, необходимо соответствовать стандарту functional safety ISO 26262.

Получается, что для разработки безопасного ПО для применения в ответственных областях, компаниям нужно иметь опыт разработки в каждой области?

Если отвечать кратко и формально, то да. И здесь я хочу также отметить богатый опыт компании Аурига в разработке ПО для медицинских устройств. Если же посмотреть на этот вопрос шире, то, как говорил я ранее, стандарты functional safety имеют между собой много общего, особенно, когда дело касается работы с требованиями, кодирования и подходов к верификации кода, а это ведь наиболее трудозатратная часть разработки ПО и которая чаще всего отдается сервисным компаниям, — таким, как Аурига. Более того, уже заметны усилия рабочих групп, направленные на гармонизацию стандартов. Так, например, стандарт на разработку ПО для медицинских устройств IEC 62304, как и стандарт на разработку ПО для электронных блоков автомобиля ISO 26262, опирается на стандарт IEC 61508, который разрабатывался в качестве основы для индустрия-специфичных стандартов functional safety. То есть, если отвечать более широко, имеющийся опыт компании Аурига в разработке ПО для ответственных применений, существующая в компании система качества, культура менеджмента и инжиниринга, позволяет нам быстро адаптироваться под специфичные для других областей особенности.

Вячеслав, ты упомянул, что КТ-178С описывает разные стадии и процессы по разработке ПО, все ли их охватывает компания Аурига?

Действительно, цели КТ-178С/DO-178C охватывают все процессы разработки ПО начиная с процессов планирования и разработки требований до взаимодействия с сертифицирующими органами. Более того, стандарт определяет каким образом разработка ПО и разработка системы целиком, включая аппаратную часть, должны быть связаны друг с другом. Поэтому компания, которая хочет передать разработку такого ПО на заказ, также должна привести свои процессы в соответствии с требованиями КТ-178С. В этом могут помочь специализированные консалтинговые фирмы, они же могут помочь и с подготовкой к подаче в сертификационные органы. Сервис, предоставляемый компанией Аурига, заключается в другом, в самой трудоёмкой части: в формулировании и документировании требований высокого уровня, разработке архитектуры и требований низкого уровня, собственно, в разработке кода программ и их верификации, или упрощая тестировании.

Но ведь кодирование и тестирование – это неотъемлемая часть разработки ПО не только для областей ответственного применения. В чём отличие?

Как элементы best practices, часть мероприятий, используемых в разработке ПО согласно стандарту DO-178C, могут присутствовать и в разработке обычного ПО. Например, требование DO-178C согласно которому исходный код должен соответствовать стандартам на кодирование (выбираются стандарты кодирования, нацеленные на безопасность, MISRA C и тп), в настоящее время стало часто использующейся практикой Coding Style и в разработке обычного ПО. Можно сказать, что КТ-178С/DO-178C задаёт всесторонний подход и высокий уровень разработки качественного ПО. Это, в частности, выражается в цели двунаправленной прослеживаемости требований к системе в исходном коде и процедурах верификации, что требует особого порядка документирования кода и встречается редко в обычном ПО.

А можете рассказать про тестирование в соответствии с КТ-178С?

Да, конечно. Во-первых, как я уже говорил, мы знаем какое требование верифицирует каждый тест и наоборот. Причём покрытие должно быть полным, что даёт нам доказательство, что требования реализованы программой. Также после проведения испытаний (тестирования) мы получаем структурное покрытие, то есть метрику покрытия тестами кода. И структурное покрытие тоже должно быть полным. То есть следуем принципу «есть что должно быть и нет того, чего быть не должно». Причем анализируется покрытие как операторов кода, так и точек ветвления в коде. А для уровня безопасности ПО А (DO-178C DAL A) структурное покрытие оценивается по объектному коду, т. е. проверка идёт на уровне Ассемблера. Для этого специалисты QA используют специализированные инструменты. Для удобства и быстрой сертификации мы используем имеющейся на рынке готовые и уже квалифицированные для этой цели инструменты.

При разработке обычного ПО после тестирования у разработчиков появляются новые задачи по багфиксу. Какие дополнительные задачи возникают после тестирования при разработке по КТ-178С?

Да, испытания могут выявить ещё и недостатки структурного покрытия. И у этого могут быть разные причины. Во-первых, конечно, причиной может быть неполнота покрытия тестами требований или недостаточностью самих требований. Также не 100% структурное покрытие может быть следствием наличия «мертвого кода».

Мертвого кода? Звучит страшно)

Мертвый код – это код, который не был выполнен при полной проверке функциональности системы. Если этот код не был деактивирован специально или не несёт защитной функции, то значит он появился неумышленно и надо его устранить, чтобы он не привносил ненужной сложности в программу, а также не нёс потенциальной угрозы.

Похоронить, чтобы не ожил)

Да) Ещё одной причиной неполного структурного покрытия объектного кода, полученного в ходе тестирования с использованием специальных инструментов, могут быть особенности трансляции исходного кода на языке высокого уровня, в нашем случае языка C, в объектный код компилятором. Компилятор при трансляции использует паттерны, но при этом учитываемая глубина потока выполнения не охватывает всю функцию. Более того, компилятор может не знать подробности контракта на функцию, если система типов недостаточна для его определения. Это, вместе с применяемыми компилятором оптимизациями, приводит к наличию в объектном коде участков, которые в реальной системе никогда не будут выполнены.

И что же с этим делать?

В этом случае инженеры исследуют эти дыры в покрытии, анализируя соответствующий ассемблерный код. При этом они проверяют является ли данный недостаток покрытия результатом особенности трансляции программы в объектный код и не несёт ли он рисков для безопасности.

Звучит очень трудоёмко…

Да, это действительно так. Но этот труд нужен для того, чтобы не случилось катастрофы. Ведь уровень DAL A – это высший уровень безопасности при разработке ПО по КТ-178С/ DO-178C и используется там, где цена ошибки – жизни людей.

Да, это очень важно. Чтобы вы рекомендовали компаниям, разрабатывающим или планирующим создавать продукты, требующие сертификации по КТ-178С/DO-178C?

Как руководитель проектов хочу выделить важность процессов. Прежде всего в организации должна быть зрелая система менеджмента качества. Она является фундаментом для того, чтобы процессы разработки, указанные в стандарте КТ-178С/DO-178C, могли быть внедрены. Так же важна производственная культура, а если точнее её носители, сотрудники компании, должны понимать важность и целесообразность процессов, обладали личной ответственностью и строго следовали правилам разработки. Чаще всего компании, создающие продукты, требующие сертификации по КТ-178С/DO-178C, уже имеют этот набор качеств, но перед ними может быть проблема выбора соответствующего технологического партнера.

И таким технологическим партнером может стать компания Аурига?

Совершенно верно.

Хочется пожелать вашей команде успехов в работе. И спасибо Вам за интересный разговор.

Спасибо Вам за интересные вопросы. И желаю всем читателям безопасных полётов.