Введение
Стандарт RTCA для критически важного программного обеспечения
DO 178B, «Рассмотрение вопросов программного обеспечения в бортовых системах и оборудовании при сертификации», является руководством, касающимся безопасности критически важного программного обеспечения, используемого в определенных бортовых системах. Он был разработан совместно рабочей группой RTCA SC 167 по критически важным системам радиотехнической комиссии по аэронавтике (RTCA) и рабочей группой 12 Европейской организации по оборудованию гражданской авиации (EUROCAE). RTCA опубликовала документ как RTCA/DO 178B, а EUROCAE – как ED 12B. Хотя формально это руководство, оно фактически являлось стандартом для разработки программных систем авионики до его замены в 2012 году на DO 178C. Федеральное управление гражданской авиации (FAA) использует DO 178B в качестве руководства для определения надежности работы программного обеспечения в бортовой среде, если это предусмотрено техническим стандартным приказом (TSO), для которого требуется сертификация. В Соединенных Штатах внедрение TSO в процесс сертификации летной годности, а следовательно, и DO 178B, прямо установлено в разделе 14 «Аэронавтика и космос» Кодекса федеральных правил (CFR), также известного как Федеральные авиационные правила, часть 21, подраздел O.
Процессы и документы
Процессы предназначены для поддержки целей в соответствии с уровнем программного обеспечения (A–D; уровень E не входил в область применения DO 178B). В DO 178B процессы описываются как абстрактные области работы, и планировщики реального проекта должны определять и документировать конкретные способы реализации процесса. В рамках реального проекта необходимо продемонстрировать, что фактические действия, выполняемые в контексте процесса, поддерживают поставленные цели. Эти действия определяются планировщиками проекта в процессе планирования. Ориентация DO 178B на достижение целей обеспечивает значительную гибкость в отношении различных моделей жизненного цикла программного обеспечения. После определения действия в рамках процесса, как правило, ожидается, что проект будет придерживаться этого задокументированного действия в рамках данного процесса. Более того, процессы (и их конкретные действия) должны иметь чётко определённые критерии входа и выхода, согласно DO 178B, и проект должен демонстрировать соблюдение этих критериев при выполнении действий в процессе. Гибкость процессов и критериев входа/выхода DO 178B затрудняет их внедрение при первом применении, поскольку эти аспекты являются абстрактными и отсутствует "базовый набор" действий, от которого можно отталкиваться. DO 178B не был разработан как предписывающий стандарт. Существует множество допустимых способов определения этих аспектов для реального проекта. Это может быть сложно для компании, впервые разрабатывающей систему гражданской авионики в соответствии с этим стандартом, что создало нишу для обучения и консалтинга по DO 178B. Для типового процесса, основанного на DO 178B, приводится визуальное резюме, включающее этапы вовлечения (SOI), определённые FAA в документе "Руководство и вспомогательные материалы по программному обеспечению и сложному электронному оборудованию".
Планирование
Системные требования обычно задаются для всего проекта. Последние 3 документа (стандарта) не требуются для программного обеспечения уровня D.
Связь по сертификации
Обычно уполномоченный инженер-представитель (ДЭР) рассматривает технические данные при подаче заявки в FAA для получения одобрения.
Инструменты
Программное обеспечение может автоматизировать, оказывать помощь или иным образом выполнять или способствовать процессам, предусмотренным DO 178B. Все инструменты, используемые при разработке в соответствии с DO 178B, должны быть включены в процесс сертификации. Инструменты, генерирующие встроенный код, квалифицируются как инструменты разработки и подлежат тем же ограничениям, что и сам встроенный код. Инструменты, используемые для верификации кода (симуляторы, средства выполнения тестов, инструменты измерения покрытия кода, инструменты формирования отчетов и т.п.), должны быть квалифицированы как инструменты верификации, что представляет собой менее сложный процесс, заключающийся в комплексном тестировании инструмента методом "черного ящика". Инструмент стороннего разработчика может быть квалифицирован как инструмент верификации, однако инструменты разработки должны быть разработаны в соответствии с процессом DO 178. Компании, предоставляющие такие инструменты как готовые решения (COTS), подлежат аудитам со стороны органов по сертификации, которым они предоставляют полный доступ к исходному коду, спецификациям и всем материалам, связанным с сертификацией. За пределами этого, результаты работы любого используемого инструмента должны быть проверены вручную. Система управления проблемами может обеспечивать отслеживаемость изменений. SCI и SECI могут быть сформированы на основе журналов в системе контроля версий.
Управление требованиями
Прослеживаемость требований подразумевает документирование жизненного цикла требования. Должна быть возможность отследить происхождение каждого требования, а каждое изменение, внесенное в требование, должно быть задокументировано для обеспечения прослеживаемости. Даже использование требования после развертывания и применения реализованных функций должно быть прослеживаемым.
Критика
VDC Research отмечает, что DO 178B становится "несколько устаревшим", поскольку он недостаточно хорошо отвечает потребностям и предпочтениям современных инженеров. В том же отчете также отмечается, что DO 178C, по всей видимости, способен решить эту проблему.