Р4754: Руководство по сертификации сложных бортовых систем ВС

МЕЖГОСУДАРСТВЕННЫЙ АВИАЦИОННЫЙ КОМИТЕТ
РУКОВОДСТВО
по процессам сертификации
высокоинтегрированных сложных бортовых
систем воздушных судов гражданской авиации
Р4754
(на базе документов SAE/ARP4754 и EUROCAE/ED-79)
2007
Авиарегистр МАК
Р4754
ПРЕДИСЛОВИЕ К РУССКОМУ ИЗДАНИЮ
В последние годы в США и Европе идёт активная работа по
совершенствованию политики и практики проектирования и сертификации
воздушных судов (ВС) гражданской авиации. Это вызвано тем, что современные
и перспективные авиационные системы становятся все более сложными, а
традиционные методы их сертификации не устраивают ни авиационные, ни
сертификационные власти. Отсутствие русскоязычных регламентаций по
проектированию и сертификации бортовых систем, гармонизированных с
западными, затрудняет сертификацию отечественной авиационной техники, а
также взаимопонимание её разработчиков с западными сертификационными
властями при продвижении своей продукции на мировой рынок.
Данное руководство совместно с руководством Р4761 (русскоязычная
версия ARP4761 по методам оценки безопасности), с документами КТ-178В
(действующая русскоязычная версия документа DO-178B/ED-12B) и КТ-254
(русскоязычная версия документа DO-254/ED-80) направлено на преодоление
упомянутых трудностей. Документы Р4754, Р4761 и КТ-254 подготовлены в
рамках созданной Авиационным регистром МАК рабочей группы с
привлечением специалистов ведущих предприятий и организаций отечественной
авиационной отрасли.
Настоящее руководство можно считать «пилотным» вариантом в интересах
большего внедрения системного подхода при создании перспективных образцов
отечественной авиационной техники использующих высокоинтегрированные
сложные системы для реализации заданных функций. Известно, что
англоязычные версии упомянутых документов в настоящее время
совершенствуются в интересах большего учёта «человеческого фактора»,
углубления методологии назначения «уровней гарантии проектирования», учёта
широкого использования при проектировании автоматизированных средств
моделирования и необходимости их квалификации/аттестации, а также в других
направлениях. Поэтому можно засчитывать, что после опубликования
настоящего варианта руководства Р4754 и связанных с ним документов Р4761 и
КТ-254 начнётся работа по их дальнейшему совершенствованию в интересах
обеспечения отечественных разработчиков передовыми методами и подходами к
проектированию и сертификации авиационной техники.
Текст документа близок к оригиналу, иногда даже в ущерб принятой в
отечественной авиационной отрасли стилистики. При необходимости трактовки
используемой в руководстве терминологии, следует обращаться к оригинальным
текстам SAE/ARP4754 и EUROCAE/ED-79 и/или к сертификационным властям, а
также к специалистам, участвующим в подготовке данного документа.
Сделанные редактором вставки по тексту выделены шрифтом италик.
2
Авиарегистр МАК
Р4754
ВВЕДЕНИЕ
На протяжении многих лет накоплен практический опыт работы
промышленности и разработаны нормативные требования, гарантирующие
обеспечение стандартов безопасности в гражданской авиации. Повышающаяся
степень интеграции и сложность электронных систем воздушных судов
обусловили необходимость пересмотра существующих процедур и разработки
руководящих
материалов,
позволяющих
обеспечить
правильное
функционирование и безопасность будущих систем, а также проведение их
доработок.
3
Авиарегистр МАК
Р4754
СОДЕРЖАНИЕ
1. ОБЛАСТЬ ПРИМЕНЕНИЯ.................................................................................. 8
1.1. Назначение документа.................................................................................... 9
1.2. Организация документа................................................................................ 10
1.3. Терминология, принятая в документе......................................................... 12
1.4. Обоснование разработки оригинального документа................................. 13
2. ССЫЛКИ.............................................................................................................. 14
2.1. Использованные документы ........................................................................ 14
2.2. Определения .................................................................................................. 15
2.3. Сокращения и акронимы .............................................................................. 15
3. СИСТЕМНОЕ ПРОЕКТИРОВАНИЕ ............................................................... 15
3.1. Процесс концептуального проектирования системы ................................ 15
3.2. Гарантия проектирования............................................................................. 18
3.2.1
Мероприятия по обеспечению гарантии проектирования........................ 18
3.2.2
Доказательства гарантии проектирования ................................................. 19
3.3. Концепция проектирования, обеспечивающего заданную безопасность19
4. ПРОЦЕСС СЕРТИФИКАЦИИ И КООРДИНАЦИИ ...................................... 19
4.1. Планирование процесса сертификации ...................................................... 20
4.2. Согласование предлагаемых методов оценки соответствия .................... 20
4.3. Доказательство соответствия....................................................................... 21
4.4. Сертификационные данные ......................................................................... 21
4.4.1
План сертификации....................................................................................... 22
4.4.2
Указатель конфигурации.............................................................................. 23
4.4.3
План проектирования.................................................................................... 24
4.4.4
Архитектура и конструкция ......................................................................... 24
5. ФОРМИРОВАНИЕ ТРЕБОВАНИЙ И НАЗНАЧЕНИЕ УРОВНЯ
ГАРАНТИИ КАЧЕСТВА ПРОЕКТИРОВАНИЯ..................................................... 24
5.1. Формирование требований........................................................................... 25
5.2. Виды требований........................................................................................... 25
5.2.1
Требования безопасности............................................................................. 26
5.2.2
Функциональные требования....................................................................... 26
5.2.3
Дополнительные сертификационные требования ..................................... 27
5.3. Производные требования ............................................................................. 28
5.4. Назначение уровней проектирования ......................................................... 29
5.4.1
Рассмотрение архитектуры системы........................................................... 30
5.4.2
Контроль ошибок реализации...................................................................... 36
5.4.3
Назначение уровней программного обеспечения...................................... 36
5.4.4
Назначение уровней аппаратной части....................................................... 36
4
Авиарегистр МАК
Р4754
5.5. Назначение риска отказного состояния ...................................................... 37
6. ПРОЦЕСС ОЦЕНКИ БЕЗОПАСНОСТИ ......................................................... 38
6.1. Оценка функциональных опасностей ......................................................... 41
6.2. Предварительная оценка безопасности системы....................................... 42
6.3. Оценка безопасности системы..................................................................... 43
6.4. Анализ общих причин отказов .................................................................... 44
6.5. Задачи летного или наземного экипажей влияющие на безопасность.... 45
7. ВАЛИДАЦИЯ ТРЕБОВАНИЙ.......................................................................... 46
7.1. Задачи процесса валидации.......................................................................... 47
7.2. Модель процесса валидации ........................................................................ 47
7.3. Проверка полноты требований .................................................................... 49
7.4. Проверки правильности/корректности ....................................................... 50
7.5. Валидация допущений.................................................................................. 51
7.5.1 Допущения по окружающим условиям и эксплуатации........................... 52
7.5.2 Допущения, относящиеся к проектированию ............................................ 52
7.5.3 Допущения, относящиеся к производству.................................................. 53
7.5.4 Допущения, относящиеся к эксплуатационной технологичности........... 54
7.5.5 Допущения, относящиеся к установке оборудования............................... 54
7.6. Жёсткость валидации.................................................................................... 55
7.6.1
Методы валидации ........................................................................................ 55
7.6.2
Рекомендуемые методы................................................................................ 56
7.7. Валидационные данные................................................................................ 57
7.7.1
План валидации ............................................................................................. 57
7.7.2
Выходные данные и записи.......................................................................... 58
7.7.3
Прослеживание валидации........................................................................... 58
7.7.4
Сводный отчет по валидации....................................................................... 58
8. ВЕРИФИКАЦИЯ РЕАЛИЗАЦИИ .................................................................... 59
8.1. Задачи процесса верификации ..................................................................... 59
8.2. Модель процесса верификации ................................................................... 59
8.3. Планирование верификации ........................................................................ 60
8.4. Методы верификации ................................................................................... 61
8.4.1
Осмотр и экспертная оценка ........................................................................ 61
8.4.2
Анализ ............................................................................................................ 61
8.4.2.1 Моделирование.............................................................................................. 62
8.4.2.2 Анализ охвата требованиями ....................................................................... 62
8.4.3
Испытания...................................................................................................... 62
8.4.4
Сходство/ опыт эксплуатации...................................................................... 63
8.4.5
Рекомендуемые верификационные мероприятия...................................... 63
8.5. Верификационные данные ........................................................................... 64
5
Авиарегистр МАК
Р4754
8.5.1
План верификации ........................................................................................ 65
8.5.2
Процедуры и результаты верификации ...................................................... 65
8.5.3
Матрица верификации .................................................................................. 65
8.5.4
Верификационное заключение .................................................................... 66
9. УПРАВЛЕНИЕ КОНФИГУРАЦИЕЙ............................................................... 66
9.1. Задачи процесса управления конфигурацией ............................................ 66
9.2. Мероприятия процесса управления конфигурацией................................. 67
9.2.1
Идентификация конфигурации.................................................................... 67
9.2.2
Отчеты о проблемах и контроль изменений .............................................. 67
9.2.3
Архивация и извлечение данных................................................................. 68
10. ГАРАНТИЯ ПРОЦЕССОВ ................................................................................ 68
10.1. Цели гарантии выполнения процессов ....................................................... 69
10.2. План гарантии процессов ............................................................................. 69
10.3. Экспертизы/рассмотрения плана проекта .................................................. 69
10.4. Очевидность гарантии выполнения процессов.......................................... 70
11. МОДИФИКАЦИЯ ВОЗДУШНОГО СУДНА .................................................. 70
11.1. Сертификационный базис ............................................................................ 70
11.2. Методы соответствия.................................................................................... 70
11.3. Рассмотрение модификаций......................................................................... 71
11.3.1 Ввод новой самолётной функции ................................................................ 71
11.3.2 Замена одной системы другой на существующем ВС .............................. 71
11.3.3 Адаптация существующей системы к другому типу ВС .......................... 72
11.3.4 Переделка системы на существующем ВС................................................. 74
11.4. Дополнительные рассмотрения ................................................................... 75
11.4.1 Дополнение имеющихся сертификационных данных............................... 75
11.4.2 Использование данных по эксплуатации.................................................... 75
ПРИЛОЖЕНИЕ A. РАССМОТРЕНИЕ ТИПОВОГО ПОДХОДА К
ПРОЕКТИРОВАНИЮ ФУНКЦИОНАЛЬНЫХ СИСТЕМ ВС............................... 77
A.1. Типовые процессы системного проектирования........................................... 78
A.1.1 Идентификация самолётных функций, функциональных требований к
функциям и интерфейсов............................................................................................ 78
A.1.2 Определение последствий отказов функций и вызываемых ситуаций ....... 78
A.1.3 Распределение функций между системами и экипажем ............................... 79
A.1.4 Проектирование архитектуры системы и назначение требований к
изделиям 80
A.1.5 Назначение требований к аппаратной части и программному обеспечению
изделий 80
A.1.6 Разработка/создание аппаратной части и программного обеспечения........ 81
A.1.7 Интеграция аппаратной части и программного обеспечения....................... 81
A.1.8 Интеграция системы.......................................................................................... 82
6
Авиарегистр МАК
Р4754
A.2. Обмен информацией между процессами жизненных циклов системы и
аппаратной части, а также программного обеспечения ....................................... 82
A.2.1 Информационный поток от системных процессов к процессам разработки
аппаратуры и программного обеспечения ................................................................ 82
A.2.2 Информационный поток из процессов разработки аппаратной
части/программного обеспечения к системным процессам ................................... 83
ПРИЛОЖЕНИЕ B. ОПРЕДЕЛЕНИЯ, СОКРАЩЕНИЯ И АКРОНИМЫ ............. 85
B.1. Определения ...................................................................................................... 85
B.2. Сокращения и акронимы.................................................................................. 94
ПРИЛОЖЕНИЕ C. ПЕРЕЧЕНЬ КОНЦЕПЦИЙ, ЗАДАЧ И ФУНКЦИЙ .............. 97
ПРИЛОЖЕНИЕ D. РАСПРЕДЕЛЕНИЕ РИСКА ПРИ ПРОЕКТИРОВАНИИ
СИСТЕМ ВОЗДУШНЫХ СУДОВ .......................................................................... 100
D.1. Использование ресурсов ................................................................................ 100
D.2. Архитектурная изолированность и независимость..................................... 101
D.3. Опыт эксплуатации......................................................................................... 102
D.4. Интерпретация системных указаний DO-178B ........................................... 102
D.5. Заключение ...................................................................................................... 103
7
Авиарегистр МАК
1.
Р4754
ОБЛАСТЬ ПРИМЕНЕНИЯ
В данном документе рассматриваются аспекты сертификации
высокоинтегрированных сложных систем, устанавливаемых на воздушных судах
(ВС), с учетом условий их эксплуатации и выполняемых функций. Термин
"высокоинтегрированная" относится к системам, которые на уровне ВС
выполняют или участвуют в выполнении значительного числа функций. Термин
"сложная" относится к системам, безопасность работы которых не может быть
доказана только путем испытаний и логику работы которых трудно понять без
привлечения аналитического инструментария.
Руководящие материалы, изложенные в данном документе, разработаны в
контексте FAR/JAR/CS/АП-25. Данное руководство применимо и к другим частям
норм, таким, как части 23,27,29 и 33. Общие положения руководства могут быть
также распространены на системы двигателя и относящееся к ним оборудование.
Предполагается, что окончательное одобрение всех систем сертифицирующим
органом завершается совместно с сертификацией ВС.
Документ разработан, в первую очередь, для электронных систем, которые
по своей природе могут быть сложными, и допускают высокую степень
интеграции. Однако рекомендации, изложенные в данном документе, могут
распространяться и на другие системы ВС.
В данном документе рассматривается полный жизненный цикл систем,
которые обеспечивают реализацию функций на уровне ВС. В нем детально не
рассматриваются специфические вопросы процесса разработки систем, их
аппаратной части и программного обеспечения, за исключением тех вопросов,
которые существенно влияют на обеспечение безопасности реализуемых систем.
Более детальное рассмотрение вопросов разработки программного обеспечения
проведено в документе RTCA DO-178B (отечественные требования КТ-178В) и
в аналогичном документе EUROCAE ED-12B. Вопросы проектирования сложной
аппаратуры рассматриваются в документе RTCA DO-254 и в аналогичном
документе EUROCAE ED-80. Методология процесса оценки безопасности
изложена в документе ARP4761 (отечественное руководство Р4761). На Рис.1
показана взаимосвязь между различными документами, содержащими
руководящие материалы по разработке систем, оценке безопасности и
жизненному циклу аппаратной части и программного обеспечения.
Предполагается, что данный документ будет служить руководством, как
для сертифицирующих органов, так и для заявителей высокоинтегрированные
или сложные системы, в частности тех из них, которые имеют значительный
объем программного обеспечения. В целом документ направлен на достижение
8
Авиарегистр МАК
Р4754
безопасности путем гарантии качества процесса проектирования и доказательства
безопасности реализованной системы. Конкретные указания по доказательствам
безопасности, остаются за рамками данного документа, в некоторых местах
которого делаются необходимые ссылки. Материал, изложенный в данном
документе, соответствует современному уровню техники и, насколько возможно,
отвечает требованиям перспективных технологий. Однако предполагается, что
данный документ будет периодически пересматриваться с целью учета будущих
достижений техники и совершенствования процесса разработки систем.
П роцесс оценки безопасности
Руководство и методы
(AR P 4761/ Р4761 )
Сам олётны е
ф ун кци и
Ф ункция, отказ и
инф орм ация по
безопасности
Системная
документация
П роцессы проектирования
систем ы
Ф ун кциональн ая
систем а
(A R P 4754/ Р4754 )
Сист емное
проект ирование
Ж изненный
цикл
аппарат уры
Ж изненный
цикл П О
Ф ункции и требования
Реализация
Ж изненны й цикл
разработки аппаратуры
(D O-254 / КТ-254 )
Ж изненны й цикл
разработки П О
(D O-178 B/ КТ-178 В )
Рисунок 1. Руководства по сертификации в части процессов проектирования
систем, аппаратуры, программного обеспечения (ПО) и оценки безопасности
1.1.
Назначение документа
Данное руководство предназначено для того, чтобы предоставить
разработчикам и изготовителям систем, предприятиям, устанавливающим
системы на ВС, и сертифицирующим органам общую международную базу для
демонстрации соответствия требованиям летной годности, относящимся к
высокоинтегрированным или сложным системам. Руководящие материалы, в
9
Авиарегистр МАК
Р4754
первую очередь, относятся к системам, интегрирующим многочисленные
функции, выполняемые на уровне ВС, и имеющим виды отказов, которые в
потенциале могут создавать небезопасные условия летной эксплуатации. Обычно
эти системы имеют программное обеспечение и существенно взаимодействуют с
другими системами в широко интегрированной среде. Часто важные элементы
этих систем разрабатываются различными фирмами, промышленными группами
или организациями. Высокоинтегрированные и сложные системы требуют
дополнительного порядка проектирования и определённой структуры в интересах
полной реализации и подтверждения эксплуатационных требований, а также
требований безопасности. Когда данное руководство используется при
разработке простых систем, формальные положения, относящиеся к структуре,
процессам проектирования и к проектной документации могут быть в
значительной мере смягчены.
Поскольку назначение данного документа состояло в том, чтобы создать
единую основу для сертификации, то руководство направлено, в основном, на
обеспечение требований к безопасности, связанных с параграфом 25.1309
JAR/FAR/CS/АП. Оценка соответствия другим требованиям, определяющим
удовлетворительное функционирование системы и содержащимся, например, в
параграфе JAR/FAR/CS/АП 25.1301, может также производиться с помощью
данного документа или его упрощенном толковании.
Значительная часть материала, содержащегося в данном документе, не
является новой, поэтому там, где возможно, сделаны ссылки на соответствующие
документы. Многие из процессов, рассмотренных в данном документе, находятся
на стадии быстрого эволюционного развития. Более того, границы
классификации различных систем в качестве высокоинтегрированных или
сложных могут меняться в широких пределах. Можно считать, что создание
единого документа, рассматривающего типичные высокоуровневые аспекты
сертификации высокоинтегрированных или сложных систем, расширит
понимание основных принципов проектирования. А это, в свою очередь, должно
помочь заявителю и сертифицирующему органу достигнуть соглашения о
деталях процесса сертификации системы на конкретной модели ВС.
Данный документ не содержит руководящих материалов, относящихся к
организационной структуре -заявителя и распределению ответственности за
отдельные этапы процесса сертификации. Материалы документа не следует
использовать для руководства по этим вопросам.
1.2.
Организация документа
В Таблице 1 показано структура документа, и цели каждого раздела.
10
Авиарегистр МАК
Р4754
Таблица 1. Содержание и назначение разделов документа
Раздел
Содержание и цель
2
3
Список литературы.
Описание характерных особенностей
высокоинтегрированных и сложных систем и предложение
по использованию понятия гарантии проектирования как
метода сертификации.
Описание общих руководящих указаний по выбору
сертификационных данных, планированию и координации
программы сертификации.
Описание методов, используемых для определения и
распределения требований к системе, включая требования,
вытекающие из архитектуры системы, применяемых, в
частности, для установления уровней гарантии
проектирования.
Описание мероприятий по оценке безопасности, которые
сопровождают процесс разработки и обеспечивают
подготовку рекомендуемой доказательной информации для
сертификации.
Описание мероприятий валидации, которые подтверждают
достаточность и полноту требований.
Описание мероприятий по верификации результатов
проектирования, т.е. подтверждению корректности
реализации разработки.
Описание элементов управления конфигурацией, которое
поддерживает подтверждение требований гарантии
проектирования.
Описание элементов гарантии выполнения процессов,
которая поддерживает подтверждение гарантии уровня
проектирования.
Пояснения по применению данного руководства при
модификации самолёта или функциональных систем.
Описание общего подхода к системному проектированию в
интересах лучшего понимания внедряемой концепции и
терминологии.
Перечень определений, сокращений и используемых
акронимов.
Перечень описаний и примеров применения понятий, задач,
4
5
6
7
8
9
10
11
Приложение
А
Приложение
В
Приложение
11
Авиарегистр МАК
С
Приложение
D
1.3.
Р4754
функций, являющихся особенно важными в данном
документе.
Пояснение значения архитектуры системы для управления
рисками в высокоинтегрированных или сложных системах.
Терминология, принятая в документе
Данный документ содержит положения и руководящие указания,
предложенные специалистами в области проектирования воздушных судов,
двигателей и электронного оборудования (авионики) гражданской авиации, а
также представителями сертифицирующих органов. Содержанием документа
являются рекомендации, выполнение которых не является обязательным по
закону. Поэтому авторы избегали применения таких слов, как "должен" и
"обязан". Признается, что организации, предъявляющей для сертификации
высокоинтегрированную или сложную бортовую систему, могут использовать
альтернативные методы по отношению к методам, которые описаны или на
которые сделаны ссылки в данном документе.
Термины функция (function) и система (system) могут использоваться на
самых различных уровнях. Поскольку термины система и функция используются
на всех уровнях процесса проектирования, создается возможность их
неправильного толкования. В каждой программе проектирования при
использовании этих терминов должна указываться область их применения.
Термин изделие (item) в данном документе применяется для описания
любого образца оборудования, сменного блока или сменного модуля. Каждое
изделие характеризуется содержащейся аппаратной частью и, там, где это имеет
место, программным обеспечением. Компоненты и программы, из состава
оборудования, сменных блоков или модулей и которые не имеют обозначения
(номера чертежа) для контроля на уровне ВС, не рассматриваются в данном
документе в качестве изделий.
В данном документе, в общем случае, под системой понимается
комбинация связанных между собой изделий, предназначенных для реализации
одной или нескольких функции верхнего уровня. Типичная система включает в
себя такие изделия, как источники питания, датчики, органы управления,
средства обработки информации, индикаторы и функциональные выходные
устройства. Это более широкое понятие, чем типовое определение системы по
АТА 1ОО (и в более поздней версии).
Термин обособление (partition) в данном документе означает механизм,
используемый для разделения системы или изделия на отдельные составные
12
Авиарегистр МАК
Р4754
части, обладающие такой независимостью, что для каждой из этих частей может
быть установлен и подтвержден свой уровень гарантии проектирования.
1.4.
Обоснование разработки оригинального документа
Во время разработки редакции В документа RTCA DO-178 (отечественный
аналог – КТ-178В) стало очевидно, что информация на уровне системы является
необходимой в качестве исходной для процесса разработки программного
обеспечения. Поскольку многие решения, принятые на уровне системы, являются
основополагающими для безопасности и выполнения функций бортовых систем,
то участие сертифицирующего органа в процессах обоснования и оценки
результатов этих решений считается необходимым и оправданным.
Данный документ был разработан по запросу FAA к SAE. FAA просила
SAE определить вид и объем информации на уровне систем для демонстрации
соответствия нормам высокоинтегрированных и сложных систем авионики.
Специальная группа по разработке требований к интеграции систем (SIRT) была
организована для подготовки рекомендательного руководства (ARP),
рассматривающего данный вопрос.
Начинавшие работу члены группы SIRT пришли к выводу, что крайне
желательным было бы согласование требований разрабатываемого документа на
международном уровне, поэтому для участия в группе приглашались, помимо
представителей FAA и представители JAA. Для координации предложений со
стороны европейских стран в группу SIRT в EUROCAE была создана
аналогичная рабочая группа WG-42. В специальную группу SIRT входят
специалисты, имеющие большой опыт проектирования и поддержки
эксплуатации магистральных гражданских самолетов, самолетов местных
воздушных линий, самолетов авиации общего назначения, бортового
электронного оборудования, двигателей и их систем управления. В работе
группы принимали участие представители сертифицирующих органов разных
специальностей и с разным опытом работы. Были установлены и
поддерживаются формальные и неформальные связи со специальными
комитетами RTCA (SC-167 и SC-180) и комитетом SAE (S-18). Во время
разработки данного документа поддерживалась связь с рабочей группой, которая
занимается сближением требований параграфов 25.1309 норм FAR и JAR.
Во время разработки данного документа неоднократно возникала дискуссия
по поводу степени его детализации. Приводились серьезные аргументы в пользу
включения в документ четко определенного перечня шагов, выполняемых при
сертификации – перечня проверок (checklist). Одновременно высказывалась не
менее серьезно аргументированная точка зрения о том, что в руководящем
материале должно быть сконцентрировано внимание на фундаментальных
13
Авиарегистр МАК
Р4754
вопросах, а детали, касающиеся конкретных систем, должны определяться между
заявителями и сертифицирующим органом. Было признано, что в любом случае
при сертификации всех систем, за исключением самых идеализированных,
требуется здравая инженерная оценка обоими сторонами. Качество этих оценок
будет наилучшим, если обе стороны признают или принимают во внимание
фундаментальные принципы сертификации. Решение принять при разработке
документа этот подход диктовалось и рядом других факторов, наиболее вескими
из которых были разнообразие применения перспективных систем, быстрое
развитие системотехники и опыт использования в промышленности руководящих
материалов, содержащихся в DO-178, DO-178A и DO-178B (отечественные
аналоги – КТ-178, КТ-178В) .
Типовая последовательность этапов разработки систем, показанная в
Приложении A, и терминология, приведенная в Приложении B.1, дают
дополнительное представление о процессе создания систем, которое может
оказаться полезным для лиц, которые непосредственно не сталкивались с этой
работой. Перечень понятий, задач и функций, приведенный в Приложении C,
предназначен для помощи пользователям документа в быстром поиске требуемой
информации. Методика назначения рисков, рассмотренная в Приложении D,
разъясняет связь между данным документом и DO-178B (отечественный аналог
– КТ-178).
2.
ССЫЛКИ
2.1.
Использованные документы
Указанные ниже издания являются частью данного руководства в тех
пределах, которые указаны в документе. При использовании публикаций SAE
делаются ссылки на их последние издания. Другие публикации должны быть
действующими в момент их заказа. В случае противоречия между текстами
данного документа и документа, на который делается ссылка, предпочтение
отдается данному документу. Однако ни одно из положений данного документа
не заменяет тексты соответствующих законов и правил, если на это не получено
специального разрешения.
2.1.1 Публикации SAE. Заказ в SAE по адресу: 400 Commonwealth Drive,
Warrendale, PA 15O96-OOO1.
ARP4761 Руководящие указания и методы проведения оценки безопасности
бортовых систем гражданской авиации (отечественный аналог – Р4761).
2.1.2 Публикации FAA. Заказ в Федеральной Авиационной Администрации
по адресу: 8OO Independence Avenue, SW, Washingtone, DC 2O591
AC 25.13O9-1A Проектирование систем и анализ, Рекомендательный
14
Авиарегистр МАК
Р4754
циркуляр.
2.1.3 Публикации JAA. Заказ в Центральном Офисе JAA по адресу:
Saturnusstraat 1O, P.O. Box 3OOO, 213O KA Hoofddorp, Netherlands.
AMJ 25.13O9 Проектирование систем и анализ, Рекомендательный
материал к объединенным нормам (в настоящее время действует
соответствующий циркуляр EASA к CS 25.1309 и планируется подготовить
отечественный аналог).
2.1.4 Публикации ATA. Заказ в Американской Транспортной Ассоциации
Авиакомпаний по адресу: 17O9 New York Avenue,NW, Washingtone, DC 2OO6.
ATA-1OO "Требования ATA к технической документации изготовителя"
Rev. 3O, Oct. 31, 1991 (в настоящее время действует соответствующая
редакция этого документа АТА).
2.1.5 Публикации RTCA. Заказ в RTCA Inc. по адресу: 114O Connecticut
Avenue, NW, Suite 1O2O, Washingtone, DC 2OO36.
DO-178B Рассмотрение программного обеспечения при сертификации
авиационных бортовых систем и оборудования (отечественный аналог – КТ178В).
DO-254 Руководство по гарантии разработки бортовой электронной
аппаратуры (отечественный аналог – КТ-254).
2.2.
Определения
См. Приложение B.1.
2.3.
Сокращения и акронимы
См. Приложение B.2
3.
СИСТЕМНОЕ ПРОЕКТИРОВАНИЕ
В данном разделе изложена общая модель процесса проектирования
системы, которая определяют структуру следующих разделов документа. Здесь
же вводится понятие "гарантии проектирования".
3.1.
Процесс концептуального проектирования системы
На Рисунке 2 представлена модель процесса реализации функций ВС.
Модель охватывает многочисленные процессы системного проектирования.
Процесс проектирования каждой системы может включать ряд процессов
15
Авиарегистр МАК
Р4754
разработки составляющих её изделий. Процесс разработки каждого изделия
может содержать ряд жизненных циклов разработки, как аппаратных частей, так
и программного обеспечения. На каждом этапе проектирования выполняются
определённые повторяющиеся поддерживающие процессы. На Рис. 3 показан
типовой процесс проектирования системы, отражающий содержание данного
документа. Описание основ этого процесса приведено в Приложении А.1. Это
описание дается для упрощения понимания, а не в качестве изложения
предпочтительного метода или основания для создания некоей организационной
структуры. Взаимодействие между процессом разработки системы и жизненными
циклами аппаратной части и программного обеспечения рассмотрено в
Приложении А.2.
П роц ессы
п одд ерж ки
Коо рд ин а ция
сертиф ика ции
Функция В С x
Функция В С 2
Функция В С 1
О цен ка
безоп асн ости
В алидац ия
Система j
Система2
Система1
требован и й
Вериф ика ция
реализации
КИ n
КИ 2
КИ 1
У правл ен и е
конф и гура цие й
П р оц есс
гаран тии
ЖЦ
ЖЦ
АЧ
ПО
Разработка КИ
П роектирование системы
Ф ункция ВС
Рисунок 2. Процесс реализации функций воздушного судна (ВС)
16
Авиарегистр МАК
Р4754
Ф ункции
О тка зн ы е со сто ян и я ,
п оследстви я, класси ф и кац и я,
х ар ак тер и сти ки б езо п асн о сти
сам олета
Ф ун к ц и и
О тка зн ы е со сто ян и я ,
п ослед ств и я, клас си ф и ка ц и я,
х ар ак тер и сти к и б езо п асн о сти
О бесп еч ен ие
безо п а сн о ст и
с и стем ы
Т р еб ов ан и я к
а рхи тек тур е
А р х -р а
Ф ункциональны е
тр ебов ан и я
сам ол ета
Р аспределение
функций по
си стем ам
П р оек ти рован и е
архитектуры
систем ы
с и стем ы
Р азр аботк а Т З н а
и зд ел и я , н а
аппаратны е и
програм м ны е части
Т Т н а и зд ел и е
Р е а л и з. с и с т е м а
И зготов л ен и е
и зд ел и й , в ход я щ и х в
си стем у
Р еальн а я
си стем а
Р езуль таты
С ертиф икация
П р оц есс о ц енки безоп а сно ст и
П роцесс проект ирования сист ем ы
Рисунок 3. Модель процесса разработки системы
Процесс проектирования большинства современных систем включает в
себя множество итеративных циклов, и опыт показывает, что этот процесс
является скорее циклическим, чем последовательным. Начальной точкой
реализации функции ВС может быть любая точка цикла. Для новой функции,
выполняемой на верхнем уровне ВС, процесс начинается с определения
требований высшего уровня. При расширении выполняемых функций, начальная
точка может быть связана с изменением конкретного образца оборудования.
Однако, независимо от расположения начальной точки, необходимо производить
оценку влияния новой или измененной функции на другие функции,
выполняемые на верхнем уровне, и на поддерживающие их требования. На
практике многие из этапов разработки, показанных на Рис.3, являются
17
Авиарегистр МАК
Р4754
совпадающими по времени, они могут взаимодействовать между собой, что
приводит к изменению первоначально заданных требований.
При создании высокоинтегрированных и сложных систем появляется
больше возможностей возникновения ошибок проектирования (ошибок в
требованиях и ошибок разработки) и возникновения ненамеренных
нежелательных эффектов. В то же время в большинстве случаев оказывается
нецелесообразным (а иногда и просто невозможным) разработать конкретную
последовательность испытаний высокоинтегрированной или сложной системы,
которая убедительно продемонстрировала бы отсутствие не выявленных ошибок
проектирования. Поскольку эти ошибки, в общем случае, не являются
детерминированными, и приемлемые числовые методы для их оценки
отсутствуют, должны использоваться другие качественные методы демонстрации
удовлетворения системы требованиям безопасности. Гарантия проектирования
(Development assurance - см. определение, данное ниже и в Приложении А.1)
обеспечивает уверенность, что проектирование системы проводилось способом,
ограничивающим вероятность появления ошибок, влияющих на безопасность ВС.
3.2.
Гарантия проектирования
Гарантия проектирования представляет собой процесс, состоящий из
специальных запланированных систематических мероприятий, которые в
совокупности обеспечивают уверенность, что ошибки или упущения в
требованиях или проекте выявлены и устранены таким образом, что
реализованная система удовлетворяет относящимся к ней сертификационным
требованиям.
3.2.1
Мероприятия по обеспечению гарантии проектирования
Гарантия проектирования поддерживаются процессами, показанными на
Рис.2. В разделе 5 данного документа рассматривается методика установления
для систем и изделий «уровней гарантии проектирования» в зависимости от
классификации отказных состояний функций ВС, реализованных в системах и
изделиях. Строгость и дисциплина выполнения поддерживающих процессов
может меняться в зависимости от уровня гарантии проектирования/проекта (в
дальнейшем тексте для краткости используется термин «уровень проекта»).
В разделах с 4-го по 10-ый устанавливается связь уровня проекта с
рекомендуемыми мероприятиями, предусматриваемыми процессами поддержки.
Уровень проекта определяет необходимые уровни разработки программного
обеспечения и аппаратной части в соответствии с DO-178B и DO-254(КТ-178В и
КТ-254).
18
Авиарегистр МАК
3.2.2
Р4754
Доказательства гарантии проектирования
В процессе доказательства гарантии проектирования имеются два
ключевых элемента. Один из них предусматривает своевременное отслеживание
выполнения поддерживающих процессов до получения соответствующих
результатов. Второй высвечивает, каким образом процесс оценки безопасности
взаимодействует с другими процессами поддержки в ключевых точках
программы проектирования. Для большинства высокоинтегрированных или
сложных систем доказательство обеспечения гарантии проекта осуществляется в
течение большей части периода проектирования. С этой точки зрения удобно
рассматривать
сертификационный
процесс
как
процесс
поддержки
проектирования.
3.3.
Концепция проектирования, обеспечивающего заданную
безопасность
Концепция проектирования, обеспечивающего заданную безопасность,
которая является альтернативной по отношению к методам обеспечения качества
проектирования систем, изложенным в данном документе, может обеспечить
альтернативные методы доказательства соответствия требованиям параграфа
25.13О9 FAR/JAR/CS/АП. Данная концепция переносит акцент с общих
мероприятий по исключению ошибок (из которых только часть связана с
безопасностью) на анализ ошибок, потенциально влияющих на безопасность. При
этом используются специальные методы разработки, позволяющие исключить
или ограничить влияние этих ошибок на безопасность. Концепция
проектирования обеспечивающего заданную безопасность предусматривает
применение процессов оценки безопасности, подтверждения достаточности и
полноты требований (валидации) и проверки результатов (верификации), которые
во многих отношениях сходны с методами, изложенными в данном документе.
4.
ПРОЦЕСС СЕРТИФИКАЦИИ И КООРДИНАЦИИ
Целью процесса сертификации является доказательство соответствия ВС и
его систем относящимся к ним требованиям норм летной годности. В
большинстве случаев сертификация ВС осуществляется выполнением
совокупности планов сертификации систем. Планирование и координация очень
важны для установления взаимодействия между заявителем и сертифицирующим
органом и для достижения соглашения о методах доказательства соответствия ВС
и его систем требованиям летной годности.
Одной из особенностей высокоинтегрированных и сложных систем
является необходимость использования методов гарантии проектирования как
одного из средств обеспечения очевидности сертификации систем.
19
Авиарегистр МАК
Р4754
Внимательное отношение к архитектурам систем и их изделий, выбору
компонентов могут упростить методы гарантии проектирования и ограничить
перечень систем и изделий, к которым применяется эта сертификационная
стратегия.
4.1.
Планирование процесса сертификации
На современных ВС устанавливаются системы, отличающиеся друг от
друга сложностью и степенью интеграции. Поэтому процесс сертификации
должен быть гибким. Планирование процесса сертификации обеспечивает эту
гибкость для заявителя, обеспечивая, в то же время, заявителю и
сертифицирующему органу высокую степень доверия к правильности
используемого подхода к сертификации.
При планировании сертификации аспекты общего проектирования,
связанные с реализацией требований норм, представляются в виде отдельных
задач, выполняемых в логичной последовательности. В плане высшего уровня
приводится сертификационный базис (применяемые требования и специальные
технические условия) и указываются методы, с помощью которых заявитель
предполагает демонстрировать соответствие нормам. Своевременная подготовка
плана сертификации может минимизировать эффект от неправильного
толкования норм и рекомендательных материалов.
План сертификации сложной или высокоинтегрированной системы
определяет облик и установку сертифицируемого объекта, дает описание
процессов обеспечивающих гарантию проектирования и включает в себя
предлагаемые методы оценки соответствия нормам. Поскольку многие
мероприятия обеспечения гарантию проектирования желательно выполнить до
реализации проекта, рекомендуется, как можно раньше обеспечить координацию
действий с сертифицирующим органом. В заранее подготовленном плане
сертификации могут отсутствовать существенные детали, и поэтому возможна
последующая его корректировка. Но даже с учетом этого настоятельно
рекомендуется проводить координацию планов как можно раньше.
4.2.
Согласование предлагаемых методов оценки соответствия
Заявитель предлагает методы оценки соответствия определяющие, каким
образом проектирование системы или оборудование будут соответствовать
действующему сертификационному базису. Заявитель должен:
a. направить планы на рассмотрение сертифицирующему органу до начала
проектирования. Если запрашиваются дополнительные доказательные
материалы, касающиеся планов или методов оценки соответствия, они
20
Авиарегистр МАК
b.
c.
Р4754
должны быть представлены вовремя для обеспечения детального изучения;
ответить на вопросы сертифицирующего органа, относящиеся к методам
оценки соответствия системы требованиям летной годности;
согласовать планы с сертифицирующим органом.
4.3.
Доказательство соответствия
Сертификационные данные являются доказательством того, что система
удовлетворяет требованиям норм летной годности. Это относится, как к данным,
предъявляемым сертифицирующему органу, так и к данным, которые требуется
сохранять у заявителя. Сертифицирующий орган определяет достаточность
данных для доказательства соответствия нормам. Заявитель должен подготовить
сертификационное заключение (сводку, резюме), в котором должно быть указано,
каким образом было определено, что установленная на ВС система,
соответствует согласованному плану сертификации.
В сертификационном заключении должны быть изложены результаты
выполнения этапов плана сертификации. В заключении должны быть указаны все
отклонения от согласованного плана с обоснованием причин. Помимо
материалов, относящихся к каждому пункту плана сертификации, заключение
должно также содержать:
a. выводы о соответствии требованиям норм летной годности;
b. краткое описание незакрытых проблем («отчётов о проблемах»), влияющих
на функционирование или безопасность.
4.4.
Сертификационные данные
В перечне ряда возможных сертификационных данных, приведенном в
Таблице 2, сделаны ссылки на разделы данного документа, в которых можно
найти соответствующую информацию, включая информацию об уровнях
гарантии проектирования.
Нет необходимости представлять сертификационные данные, выходящие за
пределы оговоренного с сертифицирующим органом объема. Минимальный
объем сертификационных данных, который должен быть представлен
сертифицирующему органу, включает в себя план сертификации,
сертификационное заключение и указатель конфигурации.
Специальные требования к оформлению, группировке и формату
сертификационных данных (бумажная копия, электронный файл или
представление на терминале) не предъявляются. При любой выбранной
заявителем форме представления, сертификационным властям должна быть
предоставлена возможность доступа и просмотра данных в соответствии с
21
Авиарегистр МАК
Р4754
действующими нормами и законами, относящимися к эксплуатирующимся ВС.
Таблица 2. Перечень сертификационных данных
Сертификационные данные системы
План сертификации
План проектирования
Архитектура и конструкция
Требования
План валидации
План верификации
План управления конфигурацией
План гарантии выполнения процессов
Указатель конфигурации
Оценка функциональных рисков
Предварительная оценка безопасности системы
Оценка безопасности системы
Анализ общих причин отказов
Данные валидации
Данные верификации
Данные, подтверждающие наличие управления
конфигурацией
Данные, подтверждающие гарантию выполнения
процессов
Сертификационное заключение
Описание
4.4.1
4.4.3
4.4.4
5.2 и 5.3
7.7.1
8.5.1
9.0
10.2
4.4.2
6.1
6.2
6.3
6.4
7.7
8.5
9.2
10.4
4.3
Примечание: Выделенные позиции составляют минимальный объем
сертификационных данных.
4.4.1
План сертификации
План сертификации высокоинтегрированной или сложной системы должен
учитывать, как системные, так и самолётные окружающие условия, в которых
система будет использоваться. Степень детализации плана должна зависеть от
классификации риска(ов) на верхнем уровне. Каждый план должен включать:
22
Авиарегистр МАК
a.
b.
c.
d.
e.
f.
g.
h.
i.
j.
k.
Р4754
Описание функций и условий эксплуатации системы и ВС, на котором она
будет установлена. Описание элементов системы, включая аппаратную часть
и программное обеспечение. Это описание должно включать
функциональное, физическое и информационное взаимодействие системы с
другими системами и функциями ВС.
Описание взаимосвязи данного плана сертификации с планами
сертификации других систем.
Заключение об оценке функциональных рисков (риски самолёта, отказные
состояния и их классификация).
Заключение о предварительной оценке безопасности системы (требуемые
показатели безопасности системы и предварительные уровни гарантии
проектирования системы).
Описание нововведений или специфических особенностей конструкции,
которые планируется применить для обеспечения соответствия показателям
безопасности.
Описание новых применяемых технологий.
Сертификационный базис системы, включая специальные технические
условия.
Предлагаемые методы оценки соответствия сертификационному базису,
включая краткое описание предполагаемых процессов гарантии
проектирования (оценки безопасности, валидации, верификации, управления
конфигурацией и гарантии выполнения процессов).
Перечни представляемых данных и данных, подлежащих контролю
управления конфигурацией, с описанием или примером формата данных.
Приблизительная последовательность график сертификационных этапов.
Список лиц или организаций, ответственных за координацию процесса
сертификации.
4.4.2
Указатель конфигурации
В указателе конфигурации системы идентифицируются все физические
элементы, которые, в целом, составляют систему. Кроме того, в указателе
конфигурации приводятся процедуры и ограничения, которые неотделимы при
обеспечении безопасности системы. Должны быть отражены все особенности
конструкции и характеристик, выходящие за рамки требований, обеспечивающих
безопасность системы в соответствии с действующими нормами.
Типичный указатель конфигурации системы содержит
информацию:
a. Идентификацию конфигурации каждого изделия системы.
b. Входящее в состав изделий программное обеспечение.
c. Взаимодействие изделий.
d. Необходимый интерфейс с другими системами.
следующую
23
Авиарегистр МАК
e.
Р4754
Влияющие на безопасность эксплуатационные процедуры, процедуры
технического обслуживания и ограничения.
В случае необходимости включается информация о взаимозаменяемости
изделий внутри системы.
4.4.3
План проектирования
Поскольку специальные рекомендации по процессу системного
проектирования отсутствуют, в Приложении А приведена типовая модель
проектирования в интересах общего понимания как самого процесса, так и
используемой терминологии. Конкретный процесс проектирования изложен
достаточно детально, чтобы можно было четко представлять его ключевые
элементы и их взаимодействие.
В плане проектирования указываются предполагаемые для использования
процессы верхнего уровня, основные этапы проектирования, организационная
структура и основные ответственные лица по проектированию. Описание
процессов и этапов проектирования должно быть достаточно детальным, чтобы
установить их значимость, сроки выполнения и взаимосвязь между собой, а
также представить ожидаемые промежуточные и окончательные результаты.
4.4.4
Архитектура и конструкция
Описание архитектуры и конструкции должна основываться на общем
понимании: заданных функций ВС, выполняемых или поддерживаемых
системой, ожидаемых условий эксплуатации системы, а так же конкретных
характеристик системы после установки на ВС. Описание архитектуры и
конструкции должно быть достаточно детальными в той степени, чтобы можно
было установить, как система выполняет заданные функции. В описании также
должны быть указаны методы ограничения последствий основных отказов или
неисправностей. Должны быть указаны нововведения и новые элементы
конструкции наряду с особенностями архитектуры и конструктивными
элементами, выполняющими особую роль в обеспечении и сохранении
безопасности системы.
5. ФОРМИРОВАНИЕ ТРЕБОВАНИЙ И НАЗНАЧЕНИЕ УРОВНЯ
ГАРАНТИИ КАЧЕСТВА ПРОЕКТИРОВАНИЯ
В данном разделе рассматривается формирование требований, начиная с
идентификации функций ВС до производных требований, возникающих при
разработке аппаратной части и программного обеспечения. Показана связь между
24
Авиарегистр МАК
Р4754
функциями, классификацией их отказных состояний, требованиями к системам и
изделиям и соответствующими уровнями гарантии проектирования. Рассмотрены
альтернативные архитектуры систем и приведены примеры, показывающие
влияние выбора архитектуры на назначение уровня гарантии проектирования
изделий.
В разделе изложены вопросы назначения численных показателей рисков
при реализации детерминистской аппаратной части и показаны возможности
смягчения некоторых отказных ситуаций с помощью вмешательства экипажа.
5.1.
Формирование требований
Требования совместно с соответствующими рисками опасных ситуаций
формируют общую базу для процессов поддержки проектирования. Так как
риски могут иметь различные уровни важности, распределение требований по
архитектуре системы, существенно влияет на простоту представления
доказательств, при сертификации системы.
Процессом высшего уровня в цикле проектирования ВС является
идентификация его функций и формулирование требований, связанных с этими
функциями. Функции ВС, их интерфейс (взаимосвязь) и соответствующие
требования к безопасности формируют основу для определения архитектуры
системы. Выбор архитектуры вызывает появление дополнительных требований,
необходимых для реализации этой архитектуры. На каждом этапе
формулирования и распределения требований (т.е., системы, изделия, аппаратура
и программное обеспечение) появляются дополнения к существующим
требованиям и возникают новые производные требования. Принятые решения и
встретившиеся трудности при реализации являются основным источником
производных требований и могут вызывать новые требования к безопасности
системы.
5.2.
Виды требований
Требования, связанные с данной функцией, определяют способ, которым
эта функция реализуется в окружающей среде, и включают в себя определение
интерфейса "пользователь/машина". Виды требований, которые более подробно
изложены ниже, необходимо рассматривать на различных уровнях
проектирования (т.е. функция, система, изделие и аппаратура/программное
обеспечение). Среди них, возможно, есть требования, которые относятся только к
деловым или экономическим аспектам и не касаются безопасности или
сертификационных требований.
25
Авиарегистр МАК
5.2.1
Р4754
Требования безопасности
Требования безопасности выполнения функций на уровне Вс и системы
включают минимально допустимые показатели как по готовности (availability –
непрерывность функции), так и целостности (integrity – корректность поведения)
функции. Эти требования безопасности должны быть определены посредством
оценки функциональных рисков в соответствии с разделом 6.1.
Требования безопасности для функций систем и ВС определяются путем
выявления и классификации соответствующих отказных состояний функции. Для
всех функций определяются виды отказов и возникающие при этом эффекты
состояния ВС даже в случаях их классификации как "Не влияющие на
безопасность". Функциональные отказы может влиять на безопасность ВС либо
напрямую, либо косвенно.
Должна быть предусмотрена трассировка требований, направленных на
исключение отказных состояний или на выполнение функций, связанных с
безопасностью, на всех уровнях проектирования, по крайней мере, до аппаратной
части и программного обеспечения. Это гарантирует очевидность требований
безопасности на уровне разработки программного обеспечения и аппаратной
части.
5.2.2
Функциональные требования
Функциональными являются требования, которым должна соответствовать
система в интересах обеспечения определённых свойств в заданных условиях
работы.
Они
включают
в
себя
пожелания/требования
заказчика,
эксплуатационные ограничения, ограничения, содержащиеся в нормах и
правилах, и возможности реализации. Эти требования отражают все
существенные особенности рассматриваемой системы. При этом не зависимо от
источника требований, все функции должны рассматриваться с точки зрения
влияния на характеристики безопасности.
5.2.2.1 Требования заказчика
Требования заказчика зависят от типа ВС, выполняемых функций или от
типа рассматриваемой системы. Требования могут быть связаны с желаемой
полезной нагрузкой, воздушными трассами, эксплуатационной практикой,
концепцией технического обслуживания и желаемыми свойствами.
5.2.2.2 Эксплуатационные требования
Эксплуатационные требования определяют интерфейс между летным
26
Авиарегистр МАК
Р4754
экипажем и функциональными системами, между наземным экипажем и
бортовыми системами, между другим обслуживающим персоналом и
относящимися к его компетенции функциями или оборудованием. Основную
часть эксплуатационных требований составляют требования к действиям
экипажа, принятию решений и срокам. При формировании эксплуатационных
требований необходимо учитывать, как нормальные, так и ненормальные
условия.
5.2.2.3 Требования к характеристикам
Требования к характеристикам определяют те свойства функции или
системы, которые делают ее нужной для ВС или заказчика. Наряду с указанием
типа ожидаемой характеристики определяются такие её показатели как точность,
достоверность, диапазон, разрешающая способность, скорость и время отклика.
5.2.2.4 Требования к физическим характеристикам и установке
Требования к физическим характеристикам и установке определяют
физические свойства системы в окружающей среде ВС. Они могут включать
требования к размерам, методам монтажа, потребляемой мощности, охлаждению,
параметрам окружающей среды, видимости, доступности, регулировке,
обращению и хранению. При формировании этих требований могут также играть
роль и производственные ограничения.
5.2.2.5 Требования к техническому обслуживанию
Эти требования включают требования к техническому обслуживанию,
предусмотренному регламентом и по состоянию, а также связи с функциями
обеспечения безопасности полета. Такие показатели, как процент обнаружения
отказов и процент изоляции неисправностей также могут быть важны. Сюда же
относятся требования к сигналам и разъемам для внешних средств контроля.
5.2.2.6 Требования к интерфейсам
Они включают в себя требования к физическим связям между системами и
изделиями, а также к характеристикам передаваемой информации. При
определении интерфейсов должны быть указаны источники входной информации
и приемные устройства поступающей выходной информации.
5.2.3
Дополнительные сертификационные требования
Дополнительные функции,
потребоваться для обеспечения
их свойства или реализации могут
соответствия нормам летной годности.
27
Авиарегистр МАК
Р4754
Требования данного вида должны быть согласованы с соответствующими
сертификационными органами.
5.3.
Производные требования
На каждом этапе проектирования принимаются решения по обеспечению
соответствия определенному требованию или группе требований. Вследствие
таких технических решений возникают новые требования для следующего этапа
проектирования. Поскольку эти требования возникают в самом процессе
разработки, их нельзя однозначно соотнести к требованиям верхнего уровня, и
они определяются как производные требования.
Производные требования должны быть проанализированы с целью
определения их привязки к той функции (или функциям) ВС которые они
поддерживают, так, чтобы была возможность классифицировать отказные
состояния и произвести оценку полноты и корректности самих требований (т.е.,
валидацию). Не смотря на то, что большинство таких требований не влияют на
требования более высокого уровня, некоторые из них могут быть связанными с
верхним уровнем. Производные требования должны оцениваться с точки зрения
влияния на требования всё более высокого уровня до тех пор, пока не будет
установлено, что такое влияние отсутствует.
Например, производные требования могут вытекать из решения выбрать
отдельный источник питания для изделия, выполняющего определенную
функцию. Требования к такому источнику питания, включая требования по
безопасности, являются производными требованиями. Риск, возникающий при
неисправности или отказе функции, выполнение которой обеспечивается
источником питания, определяет необходимый уровень проектирования.
Производные требования могут также возникать при выборе архитектуры.
Например, выбор трехканальной архитектуры для повышения функциональной
целостности (integrity) будет иметь другие последствия и другие производные
требования, по сравнению с двухканальной архитектурой с контролем, для
достижения тех же характеристик.
Производные требования могут также вытекать из решения изолировать
реализацию функции с более серьёзной классификацией отказного состояния, от
влияния неисправностей или отказов систем, имеющих менее серьёзную
классификацию отказных состояний.
Производные требования также включают требования, определяющие
интерфейс между аппаратной частью и программным обеспечением. Некоторые
из них могут иметь существенное влияние на системном уровне. Другие,
28
Авиарегистр МАК
Р4754
касающиеся более детальных аспектов интерфейса между аппаратной частью и
программным обеспечением, могут учитываться в соответствии с документами
DO-178B и DO-254 (КТ-178В и КТ-254).
Производные требования должны формироваться и реализовываться на
равных с другими требованиями, относящимися к данному этапу
проектирования.
5.4.
Назначение уровней проектирования
Уровень проектирования системы назначается, исходя из наиболее
серьёзной
классификации
отказного
состояния
соответствующей(их)
функции(ий) на уровне ВС (см. Таблицу 3). Небольшим отличием этой таблицы
от требований параграфов AC25.13О9-1A и AMJ25.13O9 является наличие
уровня Е - "отсутствие влияния на безопасность".
Таблица 3. Назначение уровней гарантии проектирования системы
Классификация отказного
состояния
Катастрофическое
(Catastrophic)
Аварийное
(Hazardous/Severe Major)
Сложное
(Major)
Усложнение условий полета
(Minor)
Отсутствие влияния на безопасность
(No safety effect)
Уровень гарантии проектирования
системы
A
B
C
D
E
Если предварительная оценка безопасности системы (PSSA - см. раздел 6.2)
показывает, что архитектура системы ограничивает влияние ошибок разработки
так, что на уровне ВС влияние этих ошибок значительно смягчается, то для
изделий внутри системы, процессы гарантии проектирования могут
осуществляться на более низком уровне жесткости.
Если система имеет несколько категорий отказных ситуаций для различных
выполняемых ею функций, то для ограничения взаимного влияния изделий
системы могут применяться различные архитектурные методы. Это позволяет
разрабатывать отдельные изделия на различных уровнях проектирования.
29
Авиарегистр МАК
Р4754
Уровень гарантии проектирования изделия опирается на общую
архитектуру системы посредством распределения рисков выявленных в процессе
предварительной оценке безопасности системы (PSSA). Для изделий,
обеспечивающих реализацию нескольких функций ВС, требования безопасности
должны базироваться на самом опасном по последствиям отказе или
неисправности любой из функций или их комбинации при обеспечении
самолётных функций.
5.4.1
Рассмотрение архитектуры системы
Архитектурные свойства системы, такие как резервирование, непрерывный
контроля, обособление могут использоваться для того, чтобы исключить или
ограничить влияние отказа изделия на возникновение определенной отказной
ситуации. Соответствующим выбором архитектуры системы можно уменьшить
сложность и интерфейс отдельных её изделий, что позволит упростить или
снизить объем работ по обеспечению необходимой гарантии проектирования.
Если архитектурные средства позволяют снизить уровня гарантии
проектирования изделия в составе системы, то должно быть доказано
достаточность этого при соответствующем риске на верхнем уровне. Это не
мешает назначению уровней изделий, более низких, чем уровень,
соответствующий риску на верхнем уровне; однако приемлемость назначенных
уровней изделий и их независимость должны быть проверены (validated) на более
высоком уровне и подтверждены при оценке безопасности системы (процесс SSA
– см. раздел 6.3).
Резервирование является
методом, обеспечивающим многократную
реализацию функции либо установкой нескольких изделий, либо применением
нескольких каналов внутри изделия. Этот метод базируется на предположении,
что отказы, оказывающие одинаковое влияние на систему, не будут проявляться
одновременно в двух и более независимых элементах. Резервирование требуется
при создании отказоустойчивой конструкции предупреждающей возникновение
катастрофической ситуации, и оно может оказаться необходимым для
обеспечения соответствия требованиям по более серьёзным отказным
состояниям. Резервирующие элементы могут работать в параллель или
находиться в резервном режиме, а их конструкция может быть подобной или нет.
Для всех систем, за исключением простейших, практически невозможно
гарантировать правильность и полноту требований, а также правильность всех
необходимых допущений. Архитектурная стратегия с использованием
неподобных конструкций может служить мощным средством уменьшения
опасных последствий ошибочных требований или ошибок реализации проекта.
Характер и вероятность возникновения таких ошибок, в общем случае, нельзя
точно и надежно предсказать. Поэтому эффективность применения конкретных
30
Авиарегистр МАК
Р4754
особенностей архитектуры для снижения выбранного уровня риска изделия, в
общем случае, нельзя выразить в количественном виде. Следовательно, для
подтверждения правильности этого выбора заявитель и сертифицирующий орган
вынуждены, в значительной степени, прибегать к инженерным оценкам.
Своевременные
обсуждения,
адекватно
документированные,
снижают
вероятность последующих изменений конструкции, вызванных неразрешенными
разногласиями в этих оценках.
Если для сдерживания ошибок разработки используется метод несходства
(dissimilarity) конструкции, то степень доверия должна быть соотнесена с типом и
содержанием ошибок разработки, которые парируются данным методом.
Например, несходные конструкции, реализующие одинаковую функцию.
сдерживают определённые ошибки реализации, но не ошибки функциональных
требований. Если может быть показана достаточная независимость, несхожая
конструкция, реализующая неодинаковые функции может обеспечить
сдерживание ошибок, как реализации, так и требований. Следует отметить, что
архитектурная несхожесть влияет как на целостность (integrity), так и на
готовность (availability). Поскольку повышение целостности может быть связано
со снижением готовности и наоборот, то необходимо проведение специального
анализа с целью определения допустимости подобных действий.
Основные принципы обеспечения гарантии проектирования систем, в
определённой мере, подобны принципам гарантии программного обеспечения.
Однако между гарантией программного обеспечения и обеспечением качества
проектирования систем имеются и существенные различия1*.
В Таблице 4 и разделах с 5.4.1.1 по 5.4.1.5 представлены примеры
различных системных архитектур и показано влияние архитектуры на уровни
гарантии разработки изделий. Реальные системы ВС могут иметь комбинацию
этих архитектур или альтернативные архитектуры, не совпадающие ни с одним
из приведенных примеров. Если выбор архитектуры используется в качестве
средства борьбы с типовыми ошибками разработки, то необходимо дополнить
количественные оценки архитектуры качественными оценками. Влияние
совокупностей исходной информации для разработки, методологий разработки,
технологической проработки и понимания применения, наряду с другими
факторами, часто учитывается качественно. Примеры, приведенные в Таблице 4,
совместно с позитивным опытом эксплуатации систем могут способствовать
переходу от архитектуры конкретной системы к требованиям на уровни гарантии
1
Руководящие материалы по распределению риска, содержащиеся в ARP4754/Р4754, являются более
детальными и определенными, чем в обобщенном материале, представленном в DO-178B/КТ-178В. В обоих
документах подчеркивается необходимость использования процесса оценки безопасности систем, как средства
выбора и подтверждения уровней проектирования. В Приложении D содержатся дополнительные материалы по
рассмотрению вопроса назначения риска при проектировании функциональных систем ВС.
31
Авиарегистр МАК
Р4754
проектирования каждого изделия системы.
5.4.1.1 Обособление при разработке
Обособление (partitioning) представляет собой метод разработки для
обеспечения изоляции и/или сдерживания отказов и их потенциальных
последствий в интересах процессов верификации системы. Если изделие
участвует в выполнении нескольких функций ВС, имеющих различные
критичности, то метод обособления может использоваться для ограничения
перекрестного функционального влияния ошибок разработки в отдельных частях
изделия.
Конструкция, обеспечивающая обособление должна разрабатываться на
уровне гарантии, который соответствует наивысшей классификации отказного
состояния реализуемой функции.
Обособленная конструктивная часть может разрабатываться на уровне
гарантии, соответствующем наиболее жесткой классификации отказного
состояния данной части (см. Таблица 4, архитектура 1).
Таблица 4. Примеры назначения уровней проектирования и ограничений,
обусловленных архитектурой.
Классификация отказного
Классификация отказного
состояния состояния Архитектура
(см. прим.5)
Катастрофическое
Аварийное
1) Обособление
(многочисленные
категории отказов)
Уровень А для системы, включая
обособленные элементы
Уровень В для системы, включая
обособленные элементы
Внутри каждой
обособленной
части
Уровень, соответствующий
наиболее жесткому классу
отказного состояния
обособленной части
Уровень, соответствующий
наиболее жесткому классу
отказного состояния
обособленной части
2) Несходные,
независимые
тракты/элементы
реализующие
функцию ВС
(см. прим.2 и 3)
Уровень А для системы, включая
неодинаковые и независимые
элементы
Уровень В для системы, включая
неодинаковые и независимые
элементы
Тракты/элементы Уровень В (см. прим.5 и раздел
Уровень С (см. прим.5 и раздел
32
Авиарегистр МАК
Р4754
(см. прим.4)
5.4.1.2)
5.4.1.2)
3) Несходные
тракты/элементы,
реализующие
самолётную
функцию (см.
прим. 2)
Уровень А для системы, включая
элементы, обеспечивающие
обособление между частями
Уровень В для системы, включая
элементы, обеспечивающие
обособление между частями
Основной тракт
Второй тракт
Уровень А
Уровень В (см. прим.5 и раздел
5.4.1.3)
Уровень В
Уровень С (см. прим.5 и раздел
5.4.1.3)
4) Параллельные
тракты активный/
контролирующий
(см. прим.2)
Уровень А для системы
Уровень В для системы
Активный и
контролирующий
тракты
Уровень А для, по крайней мере,
одного тракта;
Для другого тракта по крайней
мере уровень С
(см. прим. 5 и 6)
Уровень В для, по крайней мере,
одного тракта;
Для другого тракта по крайней
мере уровень С
(см. прим. 5 и 6)
5) Параллельная
архитектура с
резервированием
(см. прим.2)
Основной тракт
Резервный тракт
Уровень А для системы
Уровень В для системы
Уровень А
Уровень С (см. прим. 4)
Уровень В
Уровень С (см. прим. 4)
Не заштрихованные позиции относятся к системе в целом.
Затенённые позиции относятся к составным частям системы, если это
допускается архитектурой.
Примечание 1:
Примечание 2:
Примечание 3:
Примечание 4:
Примечание 5:
Данные архитектуры иллюстрируют конкретные ситуации при назначении
уровня гарантии проектирования/разработки; в реальных системах может
применяться широкий спектр и других архитектур.
Логические устройства для переключения /голосования/обнаружения
отказов должны иметь наивысший уровень гарантии разработки.
До применения данного метода очень важно получить согласие
сертифицирующего органа, как это указано в разделе 4.1.
В этом случае обособление распространяется на изделие, группу изделий
или подсистему.
Должны удовлетворяться требования готовности и ограничения,
изложенные в соответствующем нижеизложенном параграфе.
33
Авиарегистр МАК
Примечание 6:
Р4754
Уровень гарантии проектирования зависит от классификации любого
отказного состояния без исключения контролирующей части.
5.4.1.2 Архитектура с несходными и независимыми трактами,
реализующая функцию ВС
Архитектура с несколькими параллельными несходными трактами может
обеспечить защиту, как от случайных отказов аппаратной части, так и от
аномалий, вызванных ошибками в разработке2.
В этом случае уровни гарантии проектирования отдельных трактов можно
выбирать ниже, чем уровень, задаваемый для верхнего уровня на основе
классификации его отказного состояния (см. Табл. 4, архитектура 2). Анализ
должен подтвердить несходство и независимость реализации, требований,
алгоритмов, данных, окружающих условий и других потенциальных источников
ошибок проектирования.
Для принадлежности к этой категории должны быть доказаны различия
конструкций по способам предотвращения отказных состояний на верхнем
уровне, методологиям и технологиям их создания, а также по использованию
функции. Валидация предположения о независимости трактов особенно важна
при демонстрации правомочности применения данной стратегии разработки.
Принятие сертифицирующим органом архитектуры, описанной в данном
параграфе, упрощается в случае заблаговременных и многократных обсуждений,
проводимых параллельно с проектированием системы.
2
В документе DO-178B рекомендуется, чтобы в системах с параллельной архитектурой, по крайней мере, один
компонент программного обеспечения имел уровень, соответствующий наиболее жесткому классу функционального отказного
состояния системы. Такая архитектура соответствует категории, которая будет рассмотрена в 5.4.1.3. В ARP4754 параллельные
архитектуры подразделяются еще дальше, причем указывается, что в некоторых системах несхожесть и независимость
подсистем выражена настолько четко, что позволяет снизить уровень каждой подсистемы.
В качестве примера можно привести функцию торможения самолета на земле. На большинстве современных
гражданских самолетов эта функция реализуется либо с помощью тормозов колес либо реверсированием тяги двигателей.
Аналогичным образом, наведение самолета с помощью радиолокатора службой УВД, использующей связные радиостанции,
представляет собой безопасное и надежное средство навигации, которое является независимым и несхожим по отношению к
системе навигации на базе VOR/DME. При правильном исполнении такие комбинации могут удовлетворять требованию
целостности самолетной функции с один на уровень выше, чем показатели целостности каждого из трактов, реализующих
функцию. Для обеспечения доверия к таким комбинациям нужно показать несхожесть и независимость таких трактов на
уровне гарантии проектирования, соответствующем самолетной функции (в нашем случае торможение самолета и навигация).
На более детализированном примере автопилота можно показать, каким образом данный подход используется на
внутрисистемном уровне. Предположим, что в конструкции автопилота требуется устройство непрерывного контроля,
обладающее высокой целостностью и готовностью. Для реализации этого требования можно выбрать два несхожих
независимых метода: движение управляющих поверхностей и движения самого самолета. В данном примере требования к
этим двум устройствам контроля будут несхожими и независимыми, хотя при определении соответствующих порогов
срабатывания могут использоваться одни и те же допущения и общие модели. Необходимо, чтобы любое допущение можно
было просто подвергнуть валидации, а также, чтобы валидация проводилась на уровне гарантии проектирования,
соответствующем наиболее жесткой классификации отказного состояния. Если проверка дает положительные результаты, то
процесс гарантии безопасности системы будет поддерживать уровень гарантии проектирования обоих каналов контроля, более
низком на один уровень, чем требуемый верхний уровень контроля в целом.
34
Авиарегистр МАК
Р4754
5.4.1.3 Архитектура с несхожими трактами, реализующая функцию ВС
Если нельзя показать, что отдельные тракты системы являются несхожими
в соответствии с параграфом 5.4.1.2, то основной тракт должен иметь уровень
проектирования, соответствующий самой жесткой классификации отказного
состояния функции. В этом случае резервный(е) тракт(ы) системы обеспечивают
выполнение функции после случайного аппаратного отказа основного тракта.
Основной и резервный тракты могут работать одновременно или резервный тракт
могут находиться в «горячем резерве» и переходить в рабочий режим после
отказа основного тракта.
Уровень разработки резервного(ых) тракта(тов) устанавливается ниже по
сравнению с основным трактом, однако он должен быть не ниже уровня С, если:
a. Вероятность катастрофической ситуации, вызванной случайным отказом
аппаратуры основного тракта системы меньше, чем 1.0х10-5, а вероятность
аварийной ситуации меньше 1.0х10-4, и
b. Основной тракт системы всегда находится в режиме работы за исключением
случаев его отказа; а
c. Резервный тракт системы не участвует в обнаружении отказов и не вызывает
отказов основного тракта.
5.4.1.4 Параллельная архитектура с действующей и контролирующей
трактами
При данной архитектуре наличие действующей и контролирующей частей
необходимо для того, чтобы система удовлетворяла требованию целостности
(integrity). При данной архитектуре обнаруживаются случайные отказы
аппаратной части и при достаточной степени независимости могут выявляться
аномалии,
вызванные
ошибками
разработки.
Наиболее
тяжёлое
классифицируемое отказное состояние определяет уровни гарантии
проектирования, по крайней мере, одного канала и средств, обеспечивающих
независимость каналов. Другой канал может иметь более низкий уровень
гарантии проектирования, в виду необходимости соответствия требованиям
готовности (availability).
5.4.1.5 Параллельная архитектура с резервированием
В системе могут быть изделия, которые являются резервными по
отношению к остальным. То есть они должны работать только после того, как
откажут другие изделия системы. Если основной тракт удовлетворяет
требованиям целостности без резервирования, а вероятность случайного отказа
35
Авиарегистр МАК
Р4754
для потери функции основного тракта очень мала (1.0х1О-7 для
катастрофического ситуации, или 1.0х1О-5 для аварийной отказного состояния),
то уровень резервного тракта может быть на две ступени ниже верхнего уровня
риска, но не ниже уровня D. Назначение этих уровней должно быть согласовано с
сертифицирующим органом. Гарантия проектирования архитектуры системы,
связанная с требованием готовности резервного тракта, должна быть на уровне,
соответствующем наиболее критическому отказному состоянию системы.
5.4.2
Контроль ошибок реализации
Методы, изложенные в 5.4.1, относятся как к функциональным
требованиям верхнего уровня, так и к требованиям, возникающим при
реализации системы. Выбранные архитектура и технология реализации могут
играть существенную роль при определении влияния на систему отказов и
ошибок разработки. Выбор соответствующей архитектуры или технологии
реализации, которые учитываются при предварительном анализе безопасности
системы, могут смягчить или устранить последствия некоторых типов отказов и
ошибок разработки. Эти и другие методы проектирования могут полностью или
частично исключить необходимость соответствия некоторым показателям
безопасности, подтверждение которых в других случаях необходимо для
заданного уровня гарантии проектирования. Любое снижение или исключение
показателей гарантии проектирования, должно быть обосновано анализом,
включая предварительный анализ безопасности системы.
5.4.3
Назначение уровней программного обеспечения
Уровни программного обеспечения и соответствующие процессы,
регламентированные документом RTCA/DO-178B (КТ-178В), связаны с
классификацией отказных ситуаций и могут устанавливаться с учётом уровней
проектирования изделий, представленных в разделе 5.4 и таблицах 3 и 4.
5.4.4
Назначение уровней аппаратной части
Подтверждение разработки аппаратной части изделия может быть
выполнено путем всесторонних испытаний и/или анализа за исключением
случаев, когда отдельный(ые) элемент(ы) является(ются) слишком сложным(и)
для того, чтобы его(их) можно было анализировать детерминистскими методами.
Необходимая степень жесткости испытаний или анализа зависит от
классификации отказного состояния.
36
Авиарегистр МАК
Р4754
Когда детерминистские методы подтверждения не применяются или оказываются
недостаточными, можно использовать методы назначения уровней разработки,
указанные в данном разделе. Пять уровней гарантии качества проектирования
системы, приведенные в таблице 3, соответствуют пяти уровням аппаратной
части. (Методы подтверждения гарантии разработки для каждого уровня
аппаратной части разработаны Специальным Комитетом RTCA SC-18О и
изложены в документе DO-254/КТ-254). Процессы валидации требований и
верификации результатов разработки на уровнях системы и изделий должны
гарантировать, что соответствующие требования к разработке аппаратной части и
ожидаемая гарантия качества проектирования обеспечиваются аппаратной
частью.
5.5.
Назначение риска отказного состояния
Риски отказных состояний, могут назначаться изделиям на базе
предварительного анализа безопасности системы (PSSA). Назначенное числовое
значение риска входят в состав требований к аппаратной части изделия или могут
дальше распределяться в качестве требований к составным частям его
архитектуры. К аппаратной части изделия должны предъявляться и качественные
требования, например, требование отсутствия единичного отказа.
Последствия некоторых отказных ситуаций могут быть смягчены
вмешательством экипажа. Признавая, что неправильное вмешательство экипажа
может усугубить, а не исправить ситуацию, важно учесть характер и
независимость помощи, оказываемой экипажу для обеспечения правильности его
действий. Поддержка должна оказываться для распознавания как отказного
состояния системы или изделия, так и для выполнения действий по устранению
последствий отказа. В случае, когда такая помощь обеспечивает возможность
выполнения экипажем необходимых действий, системе или изделию может быть
установлен пониженный риск. Для подтверждения этого необходимо, как
минимум, учесть:
a. Обеспечение распознаваемости отказа,
b. Характер требуемой реакции на возникновение отказа и ее своевременность,
c. Приоритет данной реакции по отношению к другим задачам экипажа,
d. Общую загрузку экипажа,
e. Вероятность появления отказа,
f. Независимость подсказок экипажу по распознаванию отказа и по
корректирующим действиям.
Назначение риска для изделий в процессе проектирования должно быть
осуществлено таким образом, чтобы уровни гарантии проектирования и уровни
надежности были совместимыми.
37
Авиарегистр МАК
6.
Р4754
ПРОЦЕСС ОЦЕНКИ БЕЗОПАСНОСТИ
Процесс оценки безопасности обеспечивает аналитическую очевидность
соответствия требованиям летной годности. Он включает конкретные оценки,
корректируемые в процессе проектирования системы и увязанные с другими
процессами поддержки её проектирования. Ниже перечислены основные
процессы оценки безопасности.
a. Оценка функциональных опасностей (Functional Hazard Assessment - FHA), в
ходе которой рассматриваются функции ВС и его систем с целью
определения их возможных отказов, а также проводится классификация
опасностей связанных с ними отказных состояний. Оценка опасности
функциональных отказов производится на ранней стадии проектирования и
пересматривается по мере появления новых функций или отказных
состояний.
b. Предварительная оценка безопасности системы (Preliminary System Safety
Assessment - PSSA), в результате которой устанавливаются конкретные
требования к безопасности системы и составляющих её изделий и дается
первоначальное подтверждение того, что предполагаемая архитектура
системы сможет удовлетворить эти требования. Предварительная оценка
безопасности уточняется в процессе проектирования системы.
c. Оценка безопасности системы (System Safety Assessment - SSA), в ходе
которой собираются, анализируются и документируются доказательства
того, что реализованная система удовлетворяет требованиям безопасности,
установленным в процессах оценки функциональных опасностей и
предварительной оценки безопасности.
d. Анализ общих причин отказов ( Common Cause Analysis - CCA), в ходе
которого устанавливаются и оцениваются требования по физическому и
функциональному разделению и изоляции систем, а также проверяется как
эти требования выполняются.
В данном разделе дано описание указанных выше четырех основных
процессов оценки безопасности. Также разъясняется поддерживающий их
процесс определения задач и интервалов технического обслуживания.
На Рисунке 4 показаны основные связи между этими четырьмя процессами
оценки безопасности и процессами проектирования системы. В действительности
существует значительно большее количество взаимосвязей, как между
процессами, так и внутри их, но они опущены в интересах ясности рисунка.
38
Авиарегистр МАК
Р4754
Анализ
6.1
функциональных
опасностей (FHA) ВС
Функциональное
взаимодействие
Фукции
ВС
Отказные состояния, их последствия и
классификация, требования к безопасности
Анализ общих причин отказов
CCAs
Анализ функциональных
опасностей (FHA)
системы
Функциональ
ные отказы и
последствия
Функции
систем
Архитектурные
требования
Проектирование
архитектуры
системы
Архитектура
систем
к разделению
Разделение &
верификация
Распределение
функций ВС по
системам
Отказные состояния, их последствия и
классификация, требования к безопасности
Предварительный
анализ
6.2
Требования безопасности (PSSAs)
6.4
Требования к
ВС
Требования к КИ
Требования к КИ, общ.
задачи безопасности,
требования к анализу
Анализ
безопасности
системы (SSAs) 6.3
Распределение
требований к КИ
на ПО и
аппаратуру (АЧ)
Реализация
системы
Реализация
См. Рис. 3
Физическая
система
Результаты
Сертификация
Процесс оценки безопасности
Процесс проектирования системы
Рисунок 4. Модель процесса оценки безопасности
Раздел содержит следующие указания и рекомендации по следующим
вопросам:
a. Какой анализ безопасности является предпочтительным для каждого
классифицированного отказного состояния,
b. Как использовать результаты различных оценок безопасности на каждом
этапе проектирования. При этом определяются как требования к
безопасности выполнения функций, так и производные требования
безопасности.
39
Авиарегистр МАК
Р4754
Степень детализации различных оценок безопасности зависит от
классификации отказного состояния функции(ий) ВС, степени интеграции и
сложности реализации системы. В частности, в процессе оценки безопасности
следует принимать во внимание все взаимозависимости выбранной архитектуры
или применение общих сложных компонент при межсистемной или
внутрисистемной интеграции. Процесс оценки безопасности должен
планироваться и управляться таким образом, чтобы обеспечить необходимые
гарантии выявления всех отказных состояний и рассмотрения все существенных
комбинаций отказов, вызывающих эти отказные состояния. Процесс оценки
безопасности имеет первостепенную важность в установлении соответствующих
показателей безопасности системы и определении соответствия реализованной
системы этим требованиям.
Мероприятия по оценке безопасности и требуемые показатели
безопасности для каждого класса отказных состояний изложены в последующих
разделах этого документа и указаны в таблице 5. (Примечание: Требования к
безопасности изделия формулируются при предварительной оценки безопасности
системы - PSSA). Детальные указания и методы выполнения различных оценок
приведены в ARP 4761 (Р4761).
Таблица 5. Классификация отказов и влияние их на безопасность
Результаты
FHA (см. 6.1)
Результаты
FHA (см. 6.1)
Показатели
безопасности
Показатели
безопасности
Классифика
ция отказного
состояния
Уровень
гарантии
качества
проектировани
я
Отказо
безопасность
(Fail Safe)
Катастрофи
ческое
Аварийное
A
Сложное
C
Требуется
(5.4)
Может быть
необходим
(5.4)
Может быть
необходим
(5.4)
Усложнение
условий
полета
Безопасное
D
E
B
Предваритель
ный анализ
безопасности
Анализ
безопасности
Анализ
общих
причин
Количествен
ные требования
(Примечание 1)
PSSA
SSA
CCA
Р < 10-09
(6.2, 6.5)
(6.3, 6.5)
(6.4)
Р < 10-07
(6.2, 6.5)
(6.3, 6.5)
(6.4)
Р < 10-05
(6.2)
(6.3)
нет
нет
Примечание 2
Примечание
2
Может
быть
необходим
(6.4)
нет
нет
нет
Примечание 3
нет
нет
В таблице указаны номера соответствующих разделов данного документа.
Примечание 1:
Примечание 2:
В соответствии с Рекомендательным циркуляром AC/AMJ
13О9; величины вероятностей относятся к одному часу полета.
В соответствии с параграфом 8.2 Рекомендательного циркуляра
40
Авиарегистр МАК
Примечание 3:
6.1.
Р4754
AC/AMJ 25.13O9 может потребоваться анализ конструктивного
и функционального разделения от других функций и систем.
Требуется в объеме, необходимом для подтверждения
отсутствия влияния на безопасность.
Оценка функциональных опасностей
Результатом оценки функциональных опасностей (FHA) каждой функции
ВС, а также их и комбинации является:
a. Идентификация соответствующих отказных состояний,
b. Идентификация последствий отказных состояний,
c. Классификация каждого отказного состояния в зависимости от последствий
(катастрофическое, аварийное, сложное, усложнение условий полета,
безопасное) и назначение требуемых показателей безопасности, указанных в
Рекомендательных циркулярах AC 25.13O9-1А и AMJ 25.13O9,
расширенных путем включения в них "безопасного состояния" (No Safety
Effect),
d. Идентификация требуемых уровней гарантии проектирования,
e. Составление итогового заключения, в котором указываются рассмотренные
случаи и допущения при оценке каждого отказного состояния (в том числе
неблагоприятные эксплуатационные или окружающие условия и фазы
полета).
Целью данной оценки является достижение ясного понимания
обстоятельств возникновения и степени опасности последствий каждого
отказного состояния с обоснованием классификации.
Так как использование общих архитектур или сложных компонентов в
раздельных системах может вызвать появление дополнительных отказных
состояний с вовлечением нескольких самолётных функций, то при оценке
функциональных опасностей (FHA) эти новые отказные состояния должны быть
определены и классифицированы. Если несколько функций ВС интегрированы в
рамках одной системы или их комбинации, оценка функциональных опасностей
должна быть выполнена повторно для того, чтобы определить и
классифицировать отказные состояния этой совокупности функций. Если оценка
FHA структурирована по системам, то необходимо предусмотреть трассировку
опасностей и отказных состояний между уровнями ВС и систем.
Варианты реализации, принятые при проектировании, могут создавать
общие причины как множества отказных состояний на самолётном уровне, так и
взаимовлияния
систем,
приводящие
к
нарушению
нормального
функционирования. Эти общие причины могут преодолевать границы систем или
функций. Поэтому необходимо рассмотрение реализации систем в интересах
определения таких отказных состояний и их учёта в оценке функциональных
41
Авиарегистр МАК
Р4754
опасностей (FHA) на самолётном уровне (см. раздел 6.4).
6.2.
Предварительная оценка безопасности системы
Предварительная оценка безопасности системы (PSSA) проводится для
того, чтобы убедиться в полноте перечня отказных состояний, полученного при
оценке функциональных опасностей (FHA) и для дополнения требований к
безопасности. Кроме того, эта оценка используется для демонстрации
соответствия системы количественным и качественным требованиям для
идентифицированных опасностей. В процессе предварительной оценки
безопасности PSSA идентифицируются производные требования к безопасности
системы, и может выявиться необходимость в применении альтернативных
защитных стратегий (таких, как обособление, встроенный контроль, несходство,
текущий контроль, выбор интервалов технического обслуживания и т.д.).
Результаты предварительной оценки безопасности PSSA должны использоваться
в качестве исходных данных при оценке безопасности системы (SSA), а также в
других документах, включая (но, не ограничиваясь) системных требованиях,
требованиях к программному обеспечению и требованиях к аппаратной части.
Предварительная оценка безопасности системы (PSSA) является
итеративным процессом анализа, входящим, как составная часть, в общий
процесс проектирования. Этот непрерывный процесс, начинается на ранних
этапах проектирования с распределения функций ВС и требований между
системами. Затем системные требования распределяются между составляющими
их изделиями и, наконец, требования к изделию разделяются на требования к
аппаратной части и к программному обеспечению (см. Приложение А). При
анализе общих причин отказов (ССА) определяются требования к изоляции и
разделению, которые должны быть включены в предварительную оценку
безопасности систем.
При предварительной оценке безопасности системы должны быть
определены отказы и их комбинации, вызывающие отказные состояния,
рассмотренные при оценке функциональных рисков (FHA). Возможные факторы,
вызывающие возникновение отказных состояний, могут быть установлены путем
применения «дерева отказов» (FТA), диаграмм зависимостей, цепей Маркова или
других методов анализа. Отказы аппаратуры, возможные ошибки при разработке
программного обеспечения/аппаратной части и отказы, вызванные общими
причинами, должны включаться в анализ для того, чтобы оценить их влияние и
установить, какие дополнительные требования безопасности должны
предъявляться к системе, ее изделиям, к их аппаратной части и программному
обеспечению. Этот процесс является основой для назначения численных
показателей риска случайных отказов аппаратной части изделий (см. раздел 5.5).
42
Авиарегистр МАК
Р4754
При расчете вероятности события, связанного с отказным состоянием,
должно учитываться время, в течение которого может сохраняться скрытый
отказ. Так, должен приниматься во внимание интервал появления и/или
сохранения отказа резервного канала и/или устройства защиты до
ремонта/восстановления. Во многих случаях отказы обнаруживаются летным
экипажем при обычных осмотрах, периодических включениях питания или
самоконтроле. В некоторых случаях обнаружение скрытых отказов связано с
интервалом проверки оборудования в лаборатории или специальными
проверками при техническом обслуживании ВС. Эти задачи и интервалы
определяются при предварительной оценке безопасности (PSSA) и проверяются
при оценке безопасности SSA путем исследования дерева отказов (FTA),
диаграмм зависимостей, Марковских цепей или другими подобными методами.
Включение в данный анализ в качественном виде ошибок аппаратуры,
программного обеспечения и эксплуатационных ошибок показывает, какое
влияние они оказывают на безопасность, и дает ценную информацию для
определения уровней гарантии проектирования (см. раздел 5.4). Предварительная
оценка безопасности может также использоваться для установления специальных
требований к аппаратной части и программному обеспечению, связанных с
безопасностью, таких как определение границ сдерживания последствий отказов,
стратегии обособления и специальных стратегий верификации. Эти требования
должны входить в состав требований к системе.
Должна предусматриваться трассировка требований к безопасности от
предварительной оценки безопасности системы (PSSA) до требований к системе.
6.3.
Оценка безопасности системы
Оценка безопасности системы (SSA) представляет собой систематическое
всестороннее рассмотрение реализованных функций системы, показывающее
соответствие относящихся к ней требований безопасности. Процесс анализа
сходен с предварительной оценкой безопасности (PSSA), однако их цели
различны. Предварительная оценка безопасности (PSSA) служит для того, чтобы
сформировать требования безопасности к системе и ее составляющим изделиям,
в то время как целью оценки безопасности (SSA) является проверка соответствия
реализованной системы этим требованиям.
Оценка безопасности системы (SSA) объединяет
результаты
многочисленных анализов для того, чтобы подтвердить безопасность системы в
целом и «закрыть» все специальные вопросы безопасности, идентифицированные
в предварительной оценке (PSSA). Данные процесса SSA включают в себя
результаты этих анализов и доказательств. Типовая оценка безопасности системы
может включать:
a. Согласованный перечень вероятностей внешних событий,
43
Авиарегистр МАК
b.
c.
d.
e.
f.
g.
h.
i.
Р4754
Описание системы, включающее выполняемые функции и интерфейсы,
Перечень отказных состояний (FHA, PSSA),
Классификация каждого отказного состояния (FHA, PSSA),
Результаты качественного анализа отказных состояний (анализ дерева
отказов - FTA, сводки по видам и последствиям отказов - FMES, анализ
Марковских цепей, диаграмм зависимостей и т.д.),
Подтверждение того, что были рассмотрены все опасности реализации
данной системы с учетом реализации других систем,
Результаты количественного анализа отказных состояний (анализ дерева
отказов - FTA, сводки по видам и последствиям отказов - FMES, анализ
Марковских цепей, диаграмм зависимостей и т. Д.),
Результаты анализа общих причин отказов (ССА),
Перечень задач и интервалов технического обслуживания (анализ дерева
отказов - FTA, сводки по видам и последствиям отказов - FMES, анализ
Марковских цепей, диаграмм зависимостей и т.д.).
6.4.
Анализ общих причин отказов
Рекомендательные материалы, относящиеся к системам, диктуют
необходимость рассмотрения отказов, вызванных общими причинами (AC/AMJ
25.13О9). Возможность возникновения подобных отказов возникает при любой
архитектуре системы, которая имеет резервирование или в которой некоторые
компоненты или программное обеспечение используются и другими системами.
Для создания отказобезопасной конструкции тракт, выполняющий основную
функцию, должен быть отделен от резервных каналов и/или устройств защиты и
резервные каналы и/или устройства защиты могут быть разделены друг от друга.
Если предъявлены требования разделения и изолирования, то должен быть
выполнен анализ общих причин отказов вдоль границы и определёна стратегия
ограничения последствий неисправностей с обоснованием, подтверждающим
полноту покрытия отказов.
Данный тип неисправности может также быть вызван общими ошибками
проектирования.
Общие причины неисправностей могут быть отнесены к одной из
следующих категорий:
a. Ошибка разработки программного обеспечения,
b. Ошибка при кодировании программ,
c. Ошибка в требованиях,
d. Ошибка в процессе восстановления/ремонта,
e. Факторы окружающей среды,
f. Отказ аппаратной части,
g. Ошибка разработки аппаратной части,
44
Авиарегистр МАК
Р4754
h.
i.
j.
k.
l.
Ошибка компилятора,
Ошибка в процессе производства,
Ошибка при установке,
Ошибка в эксплуатации,
Каскадные отказы.
a.
b.
c.
Для облегчения работы анализ общих причин отказов делится на три части:
Анализ зональной безопасности,
Оценка особых/специфических рисков,
Анализ общих режимов.
Эти анализы могут выполняться на любой стадии разработки. Очевидно,
что наиболее эффективен по стоимости анализ, проводимый на ранней стадии
разработки, так как по его результатам можно скорректировать архитектуру
системы. Однако пока система не реализована, подтверждение правильности
принятых решений получить можно не всегда.
При анализе зональной безопасности, рассматриваются все физические
зоны ВС, чтобы показать, что размещение оборудования и возможное
взаимодействие с соседними системами не нарушает требования независимости
систем.
При оценке особых/специфических рисков должны рассматриваться те
общие события или влияющие факторы, которые являются внешними по
отношению к рассматриваемой(мым) системе(мам), но которые могут нарушать
требование независимости. Эти особые риски могут одновременно влиять на
несколько зон ВС, в то время как зональный анализ проводится отдельно для
каждой конкретной зоны. Некоторые из этих рисков могут учитываться
конкретными требованиями летной годности.
При анализе общих режимов показывается очевидность того, что отказы,
которые считаются независимыми, действительно являются независимыми. При
анализе учитывается также влияние ошибок разработки, изготовления,
технического обслуживания и влияние отказов общих компонентов.
6.5.
Задачи летного или наземного экипажей влияющие на
безопасность
Функции, выполняемые летным и наземным персоналом, представляются в
задачах и процедурах, с которыми могут быть увязаны требования безопасности.
Влияние идентифицированных отказных состояний на безопасность может быть
парировано постановкой летному экипажу и обслуживающему персоналу
специальных задач и ограничений. Когда эти задачи и ограничения используются
45
Авиарегистр МАК
Р4754
в
качестве
сертификационных
доказательств,
они
должны
быть
идентифицированы и включены в сертификационные данные (см. 4.1.2).
Сертификационные требования к техническому обслуживанию изложены в АС
25.19.
7.
ВАЛИДАЦИЯ ТРЕБОВАНИЙ
Валидация требований и принятых допущений представляет собой процесс
гарантирующий, что они являются достаточно корректными и полными,
обеспечивая соответствие требованиям летной годности. Валидация включает в
себя объективные и субъективные процессы.
При доказательстве соответствия JAR/FAR 25.13О1 и JAR/FAR 25.13О9,
процесс валидации поддерживает разработку требований, вытекающих из
необходимости выполнения функциональных задач и соображений безопасности.
В процессе такого проектирования должен быть сформирован полный набор
требований. Процесс валидации рассматривает каждое из этих требований. Хотя
формат требований определяется разработчиком, однако структура процесса
должна быть изложена в плане валидации (см. 7.7.1).
Идеальным с точки зрения плавности процесса проектирования было бы
проводить валидацию до начала реализации проекта. Однако на практике, в
особенности для сложных и интегрированных систем, требуемую ясность в
понимании всех вытекающих последствий принятия требований, можно
получить лишь после того, как система реализована и может быть испытана с
учетом особенностей эксплуатации. Вследствие этого валидация обычно
представляет собой многоступенчатый процесс, выполняемый по всему циклу
проектирования. На каждом этапе мероприятия по валидации обеспечивают
нарастающую уверенность в правильности и полноте требований.
Процесс валидации на каждом уровне иерархии требований должен
включать все соответствующие технические методы, в том числе и оценку
безопасности системы. Опыт показывает, что внимательный подход к
формированию и валидации требований позволяет идентифицировать самые
неуловимые ошибки и упущения на ранних этапах проектирования и сокращать
время последующей доработки или корректировки характеристик системы.
Отдельные испытания могут служить одновременно как в интересах
валидации, так и верификации, в то время как реализация системы может
использоваться лишь при валидации требований. Целью этих мероприятий
является проверка с одной стороны соответствия требований и реализованной
системы, с другой стороны – соответствие требований условиям эксплуатации.
Подобная двойственная цель должна быть обеспечена координацией планов
46
Авиарегистр МАК
Р4754
валидации и верификации.
7.1.
Задачи процесса валидации
Целями процесса валидации являются проверка правильности и полноты
требований. Ошибки при формулировке требований к системе вызываются тремя
основными причинами: (1) неоднозначностью, (2) неверным изложением или (3)
неполнотой (пропуск) требований. Необходимо, чтобы все эти потенциальные
недостатки были перекрыты в процессе валидации. Ключевым аспектом оценки
является проверка необходимости и существенности требований. Следующей
задачей
валидации
является
ограничение
потенциала
появления
непреднамеренных
функций
как
в
разрабатываемой,
так
и
во
взаимодействующих системах.
В данном документе термины "правильность/корректность" (correctness) и
"полнота" (completeness) понимаются следующим образом:
a. Правильность/корректность требования означает отсутствие
неоднозначности или ошибок в его формулировке,
b. Полнота требования означает, что ни один из его признаков не упущен и что
все сформулированные признаки являются существенными.
7.2.
Модель процесса валидации
Требования и допущения должны оцениваться на каждом иерархическом
уровне их формирования. Этот процесс включает валидацию требований к
функциям ВС, его системам и изделиям, а также валидацию оценки
функциональных опасностей (FHA). В общем случае валидация требований и
допущений на верхних уровнях служит основой их валидация на более низких
уровнях.
Взаимосвязь валидации и процесса проектирования системы показана на
Рисунке 2. Более подробная модель процесса приведена на Рисунке 5. Входная
информация процесса валидация может включать в себя описание системы
(включая ожидаемые условия эксплуатации), требования к системе, описание
архитектуры системы и уровень гарантии проектирования.
Ниже рассмотрен процесс валидации требований и допущений. Этот
процесс может использоваться для валидации на различных иерархических
уровнях. Он, а также приемлемые альтернативные процессы, могут применяться
для поддержки процесса сертификации.
47
Авиарегистр МАК
Р4754
Требования
Процесс
разработки
Уровень гарантийности
проектирования,
Планы проектирования,
Требования и описания
План
валидации
7.7
Требования к
разработке
Матрица
(начальная)
Допущения
7.7
Опыт
проектирования/
разработки
Проверка
полноты и
корректности
7.3, 7.4
Матрица
(конечная)
7.7
Итоговый
отчёт по
валидации
7.7
Определение
уровня
валидации
7.6
Требования заказчика,
сертификационные
требования и промышленные
стандарты
Валидация
допущений
7.5
Данные процесса проектирования
Процесс валидации
Рисунок 5. Модель процесса валидации.
a.
b.
c.
d.
План валидации.
В плане должны быть указаны методы, применяемые при валидации
требований к системе и допущений. (Дополнительная информация,
относящаяся к планированию валидации, изложена в разделе 7.7.1).
Определение уровня валидации.
Необходимый уровень валидации определяется уровнем гарантии
проектирования функции, к которой относится требование (см. раздел 7.6).
Проверки полноты и корректности.
Проверки полноты и корректности требований могут потребовать
инженерной оценки, проведения анализа или испытания. Справедливость
таких оценок и содержащейся в них аргументации подтверждается легче,
если они проводятся в момент формирования соответствующего требования.
(Дополнительная информация о данных проверках изложена в разделах 7.3 и
7.4).
Валидация допущений.
В процессе валидации принятых допущений доказывается, что допущения
точно изложены, соответствующим образом распределены и оценены с
48
Авиарегистр МАК
e.
f.
Р4754
использованием представленных данными (см. раздел 7.5).
Валидационная матрица.
При подготовке матрицы валидации (см. 7.7.3) используются требования и
результаты валидации, в том числе характеристики аппаратной части,
программного обеспечения, производные требования, рассмотрения
окружающих и эксплуатационных условий, а также допущения и
подтверждающие данные. Должен быть указан источник каждого
требования. В процессе разработки матрица должна регулярно обновляться
и в окончательном виде включаться в сводный отчет по валидации.
Сводные отчеты по валидации.
Данные, описывающие процесс валидации и его результаты, могут быть
эффективным средством, доказывающим, что полученная информация
базируется на последовательном и сбалансированном понимании вопросов,
существенных для проектирования системы (см. раздел 7.7.4).
7.3.
Проверка полноты требований
Ниже приведен примерный перечень вопросов, которые ставятся для
оценки полноты требований на каждом иерархическом уровне. В каждом
отдельном случае этот перечень может корректироваться.
a.
b.
c.
Все ли требования вытекают из установленных источников?
1)
Требования к функциям заданы на уровне ВС или системы,
2)
Все функций, опасности и отказные состояния установлены при
проведении оценки функциональных опасностей (FHA),
3)
Все отказные состояния включены в предварительную оценку
безопасности системы (PSSA),
4)
Производные требования вытекают из решений или допущений,
принятых при разработке,
5)
Учтены применяемые официальные стандарты и руководящие
указания,
6)
Учтены ожидаемые условия эксплуатации,
7)
Установлены процедуры выполнения полетов и технического
обслуживания.
Должным ли образом определены, обоснованы и адресованы все
ограничения и допущения?
1)
Оценки рынка,
2)
Оценки безопасности (например, оценка функциональных опасностей
FHA, анализы видов отказов и их последствий FMEA, предварительные
оценки безопасности систем PSSA),
3)
Ограничения, связанные с окружающими условиями,
4)
Промышленные стандарты и стандарты предприятия.
Правильно ли задана реализация системы?
49
Авиарегистр МАК
d.
Р4754
1)
Все самолётные и системные функции полностью размещены,
2)
Определены все интерфейсы - внутренние, внешние, физические,
функциональные и интерфейс с экипажем,
3)
Определена архитектура системы и сформулированы требования к
аппаратной части и программному обеспечению.
Точно ли определены характеристики запрещенного поведения системы?
7.4.
Проверки правильности/корректности
В процессе валидации должна быть рассмотрена и подтверждена
корректность, как классификации отказных состояний, так и содержания
сформулированных требований. Проверки корректности должны выполняться на
каждом иерархическом уровне требований. Ниже приводятся вопросы, которые
могут помочь при оценке корректности требований. В конкретных случаях этот
перечень должен корректироваться и дополняться.
a.
b.
c.
Корректно ли сформулированы все требования?
1)
Что требуется (в противоположность тому, как это достигается)?
2)
Отсутствует ли неоднозначность?
3)
Обеспечивают ли формулировки требований соответствующую
конструкцию?
4)
Возможно ли реализовать и проверить требования со степенью
жесткости, соответствующей уровню гарантии проектирования системы?
5)
Учтены ли в требованиях все ожидаемые окружающие условия
работы?
6)
Учтены ли нормальный режим работы и режим с ухудшенными
характеристиками?
7)
Корректны ли производные требования и подтверждены ли
анализом?
8)
Указан(ы) ли источник(и) каждого из требований?
Корректны ли все допущения?
1)
Являются ли допущения существенными и неотъемлемыми для
формулировки требований?
2)
Документированы ли допущения?
3)
Трассированы ли допущения?
4)
Подтверждается ли классификация отказных состояний допущений
при оценке функциональных опасностей (FHA)?
Корректно ли отражены в требованиях результаты анализа безопасности?
1)
Корректно ли выполнены соответствующие анализы безопасности?
2)
Корректно ли определены и классифицированы все системные
опасности?
3)
Рассмотрено ли влияние небезопасной элементов конструкции или
ошибок разработок?
50
Авиарегистр МАК
Р4754
4)
Имеются ли требования к надежности, готовности и устойчивости к
отказам?
7.5.
Валидация допущений
В большинство программ проектирования имеются допущения (или
рассуждения), правильность которых нельзя напрямую доказать в момент их
использования. Это, в частности, относится к первоначальной версии оценки
функциональных опасностей (FHA). Наличие таких допущений, само по себе, не
влияет на сертификацию и безопасность. Однако когда недопонимание сути
допущений и области их распространения становятся частыми, соответствующие
последствия могут помешать реализации требований безопасности. Таким
образом, допущения (прямые или подразумевающиеся) должны быть
идентифицированы, а их обоснованность должна быть показана применительно к
конкретной системе и ее уровню гарантии проектирования.
Допущения могут использоваться на ранних этапах процесса
проектирования в отсутствии более точной информации, которая будет получена
позднее. В этом случае валидация заключается в иллюстрации того, что более
точные знания или приемлемые обоснования действительно получены и что все
противоречия между точной информацией и принятыми допущениями
разрешены.
Процесс валидации допущений фокусируется на том, что допущения:
a. Точно изложены,
b. Соответствующим образом распределены,
c. Обоснованы представленными данными.
Для валидации допущений применяются экспертиза, анализы и испытания.
Там, где последствия принятого ошибочно допущения могут создать
предпосылки для снижения безопасности, единственно возможной стратегией
валидации является демонстрация того, что конструкция системы ограничивает
последствия ошибочно принятого допущения.
В оставшейся части данного раздела изложены руководящие материалы по
определению и оценке обоснованности допущений. Для облегчения этой задачи
допущения распределяются по категориям:
a. Эксплуатации/ окружающим условиям,
b. Разработке/проектированию,
c. Производству,
d. Способности к обслуживанию и ремонту,
e. Установке на борту.
Ниже приводятся примеры конкретных допущений, относящихся к каждой
51
Авиарегистр МАК
Р4754
из этих категорий.
7.5.1
a.
b.
c.
d.
e.
f.
g.
h.
i.
j.
Допущения по окружающим условиям и эксплуатации
Допущения по летной эксплуатации относятся к:
Воздушным трассам,
Техническому обслуживанию,
Перевозимым грузам,
Персоналу,
Динамике полета,
Системам управления воздушным движением,
Характеристикам ВС или двигателя,
Процедурам лётной эксплуатации,
Пассажирам,
Политике и целям эксплуатанта и соответствующих правительственных
организаций.
Допущения, относящиеся к окружающим условиям в которых будет
эксплуатироватьсяВС, включают в себя условия среды как внутри, так и вне
самолёта. Как минимум, они включают атмосферные условия, электромагнитные
поля и воздействия ударов молний; опасные объекты и материалы.
Примерами допущений, относящихся к летной эксплуатации, являются:
a.
b.
c.
d.
Время нахождения ВС на земле,
Плотность воздушного движения,
Интервалы технического обслуживания,
Ограничения летно-технических характеристик.
Обоснование этой категории допущений может быть осуществлено
экспертизой соответствующих инженерных данных и опыта эксплуатирующих
авиакомпаний либо путем сопоставления с другими точно известными условиями
и обстоятельствами.
7.5.2
Допущения, относящиеся к проектированию
Допущения, относящиеся к проектированию, распространяются на
интерфейс экипажа, межсистемный интерфейс и надежность. Обоснование этой
категории допущений достигается сравнительными экспертными оценками с
имеющимся в промышленности опытом и принятой практикой.
52
Авиарегистр МАК
a.
b.
c.
Р4754
Допущения, касающиеся интерфейса экипажа.
Данные допущения могут включать в себя взаимодействие экипажа с
оборудованием и рабочей средой в нормальных и аварийных условиях,
характеристики членов экипажа (например, время реакции, восприятие
отображаемой на индикаторах информации, физические ограничения), а
также взаимодействие членов экипажа между собой. Примерами таких
допущений могут быть: время реакции экипажа на различного вида
сообщения, время распознавания событий (например, распознавание
забросов рулей), стратегия принятия решений, частота ошибок восприятия,
точность различения сигналов в зависимости от их физических размеров, а
также формы, цвета и динамических характеристик.
Допущения, касающиеся системного интерфейса.
Данные допущения делаются при рассмотрении вопросов, связанных со
смысловой или логической интерпретацией данных обмена (например,
формат, целостность данных, скрытности, разрешения) или с физическими
характеристиками сигналов (например, уровни напряжения, импеданс,
отношение сигнал/шум).
Примерами допущений по системному интерфейсу могут быть вероятность
ошибок считывания информации шины данных, правильность обработки
ошибочных данных всеми взаимодействующими системами, ограничение
последствий отказа и невосприимчивость к внешним отказам.
Допущения, касающиеся надежности.
Вопросы надежности, по которым часто принимаются допущения, могут
включать:
1)
Адекватность интенсивности отказов моделируемой по всему
жизненному циклу,
2)
Вылет с отказавшим оборудованием,
3)
Адекватность плановых задач технического обслуживания и их
частота,
4)
Адекватность замены изделий,
5)
Рассмотрение потенциально скрытых отказов и периодов их
обнаружения,
6)
Полнота анализа отказных режимов,
7)
Адекватность результатов испытаний для установления или
подтверждения предполагаемых величин средней наработки на отказ,
8)
Применимость изделий, проверенных в эксплуатации.
7.5.3
Допущения, относящиеся к производству
Данные допущения касаются эффективности контроля/инспекций и
производственных испытаний. Обоснованность этих допущений подтверждается
экспертизой соответствия стандартам предприятия и существующей практикой.
53
Авиарегистр МАК
a.
b.
Р4754
Допущения, касающиеся контроля/инспекций.
При инженерном анализе обычно предполагается, что система
контроля/инспекций соответствует внутренним стандартам фирмы и
соответствующим национальным или международным стандартам
(например, FAA/JAA/EASA).
Допущения, касающиеся производственных испытаний.
Предполагается, что производственные испытания подтверждают, что
технологический процесс изготовления оборудования обеспечивает
соответствие оборудования техническим условиям (по эксплуатационным
характеристикам, стойкости к окружающим условиям и безопасности) в
течение всего производственного цикла. Производственные испытания
должны также выявить дефекты характеристик, которые не могут быть легко
обнаружены при нормальных проверках функционирования (например,
работоспособность устройств защиты).
Обычно принимаются допущения о том, что:
1)
Производственные испытания гарантируют эксплуатационную
технологичность,
2)
Производственные испытания не ухудшают безопасность,
3)
Предусмотрены специальные производственные испытания для
выявления ошибок, которые в отсутствии этих испытаний остались бы
незамеченными.
7.5.4
Допущения, относящиеся к эксплуатационной технологичности
Обычно предполагается, что мероприятия по обслуживанию и ремонту не
снижают безопасность. Валидация этого допущения осуществляется экспертизой
процедур технического обслуживания и применяемого при этом оборудования.
7.5.5
Допущения, относящиеся к установке оборудования
Типичные допущения по установке оборудования касаются раздельного
размещения и изоляции, кабельных жгутов, сечений проводов, окружающих
условий, резервирования электропитания, выбора автоматов защиты, вентиляции,
дренажа, защиты от загрязнений, прочности монтажных деталей, заземления и
экранирования. Валидация этих допущений производится экспертизой
соответствия промышленным стандартам и установившейся практике,
выборочными испытаниями и/или осмотром макета ВС, опытного образца или
анализом производственных чертежей аппаратуры.
54
Авиарегистр МАК
7.6.
Р4754
Жёсткость валидации
Уровень жёсткости валидации определяется уровнем(-нями) гарантии
проектирования системы, изделия или компонента, к которым относятся
требования (см. раздел 5.4). Валидации подвергается каждый уровень гарантии
проектирования и обоснования для его выбора. Методы валидации представлены
в разделе 7.6.1, а их применение - в разделе 7.6.2.
7.6.1
Методы валидации
Для поддержки процесса валидации используются несколько методов. К ним
относятся: трассировка требований, анализ, моделирование, испытания, анализ
сходства и инженерные оценки. При валидации должны рассматриваться как
предусмотренные, так и непредусмотренные функции. При валидации
требований к предусмотренным функциям используется объективный критерий
"удовлетворяет/не удовлетворяет". В процессе анализа и испытаний необходимо
внимательно
идентифицировать
непредусмотренное
функционирование
системы/изделий или возникновение побочных эффектов. Если отсутствие
непредусмотренных функций установить непосредственно не представляется
возможным, то для снижения вероятности их появления могут проводиться
специальные анализы и испытания.
a.
b.
c.
d.
Трассировка.
Трассировка является основным элементом валидации. Каждое требование
должно быть или «прослежено» (трассировано) до «родительского»
требования или должно быть показаны конкретные проектные решения или
данные, на основе которых это производное требование было
сформулировано. Допущение должно быть трассировано к стандарту,
принятой практике, анализу или испытаниям.
Анализ.
Для установления приемлемости требований может использоваться большое
количество методов и приемов анализа. Некоторые специальные методы
анализа, связанные с безопасностью, описаны в ARP4761 (Р4761).
Обсуждение результатов оценки функциональных опасностей (FHA) и
предварительной оценки безопасности системы (PSSA) с сертифицирующим
органом на ранней стадии проектирования способствует проведению
успешной валидации требований по безопасности.
Моделирование.
Метод моделирования может использоваться при валидации сложных
систем.
Испытания.
Для валидации требований могут применяться специальные испытания,
имитация или демонстрация характеристик. Эти методы могут применяться
55
Авиарегистр МАК
Р4754
на любом этапе проектирования в зависимости от наличия макетов, опытных
образцов, имитаторов или конкретного оборудования. Особое внимание
должно быть уделено сходству имитаторов с действительной системой, ее
интерфейсами и окружающими условиями работы.
e.
f.
Сходство (По опыту эксплуатации).
При данном методе валидация проводится сравнением с требованиями к
аналогичным сертифицированным эксплуатирующимся системам. Ценность
данного метода возрастает по мере роста периода эксплуатации аналогичной
системы. Метод сходства нельзя применять до тех пор, пока не будет
доказано что время эксплуатации аналогичной системы достаточен и что все
связанные с безопасностью проблемы были выявлены и решены. Различают
две разновидности сходства по опыту эксплуатации:
1)
Прямо применяемое сходство – может использоваться, если две
системы/изделия выполняют одни и те же функции, имеют одинаковую
классификацию отказных состояний и одинаково используются в
одинаковых окружающих условиях.
2)
Применяемое сходство - может использоваться, если две
системы/изделия выполняют одни и те же функции в эквивалентных
окружающих условиях.
Инженерное заключение.
Использование личного опыта путем проведения экспертизы, осмотров и
демонстраций может способствовать доказательству полноты и
корректности требований. В обоснованном инженерном заключении (т.е.
логично-обоснованном) требования должны быть трассированы.
7.6.2
Рекомендуемые методы
В Таблице 6 указаны методы валидации и данные в зависимости от
установленного уровня гарантии проектирования A-E. Например, для уровней A
и B при валидации могут использоваться анализы, испытания предназначенных
функций, и прямо применяемое сходство может использоваться при оценке
корректности и полноты требований. При валидации некоторых требований для
проверки правильности могут использоваться одни методы, а для проверки
полноты - другие.
Для каждого требования должна быть выбрана и применена комбинация
рекомендуемых и допустимых методов, необходимых для обеспечения
требуемого доверия к валидации.
Таблица 6. Валидационные методы и данные
Методы и
Уровень гарантии проектирования
56
Авиарегистр МАК
Р4754
данные (см.
7.6.1.a-f и 7.7)
AиB
C
D
E
Предварительный
анализ
безопасности
системы 6.2
План валидации
Матрица
валидации
Сводный отчет
по валидации
Трассировка
требований
Анализ,
моделирование
или испытания
Сходство (Опыт
эксплуатации)
Инженерное
заключение
Влияние на
реализацию
системы
R
R
A
A
R
R
R
R
A
A
N
N
R
R
A
N
R
A
A
N
A
N
A
N
A
N
A
N
R
A
Один из
рекомен
дованных
методов
A
R
A
R - Рекомендуемый для сертификации
A - По согласованию с сертифицирующим органом
N - Не требуется для сертификации
7.7.
Валидационные данные
7.7.1
План валидации
План проведения валидации требований должен иметь место на протяжении
всего процесса проектирования. В этом плане должно быть указано, каким
образом будет доказываться полнота и корректность требований и допущений.
План должен включать описание:
a. Применяемых методов,
b. Данных, которые должны быть собраны или подготовлены,
c. Характера подготавливаемых документов (заключения, экспертиза,
исследования),
d. Средства своевременного доступа к информации по валидации требований,
57
Авиарегистр МАК
e.
f.
g.
Р4754
Сведений о том, как будет поддерживаться или управляться процесс
валидации при изменении требований,
Роли и ответственности при выполнении валидации,
План-график основных мероприятий валидации.
Аспекты процесса валидации, которые могут служить также частью
процесса верификации, должны быть скоординированы с планом верификации.
7.7.2
Выходные данные и записи
Для того чтобы полученные данные и письменные материалы можно было
использовать при сертификации, они должны удовлетворять следующим
критериям:
a. Должна быть обеспечена возможность обращения к ним в будущем,
b. Источники полученных данных, такие как анализ или испытания, и
примененные методы должны быть в достаточной степени
контролируемыми чтобы, в случае необходимости, полученные данные
можно было воспроизвести.
Это способствует достижению очевидности доказательств при будущих
усовершенствованиях, разрешения возникающих проблем и экспертизе
сертификационными властями.
7.7.3
Прослеживание валидации
Для контроля хода процесса валидации желательно использовать матрицу
валидации или другой аналогичный подход. Степень детализации должна
зависеть от уровня гарантии реализации функции по данным требованиям и
описывается в плане валидации. Рекомендуется, чтобы первоначальный процесс
отслеживания описывался в плане сертификации и в случае необходимости,
производилась его корректировка. Окончательные данные должны включаться в
сводный отчет по валидации. Форма матрицы может выбираться заявителем, но
она должна, как минимум, содержать:
a. Требование или допущение,
b. Источник требований или основание для принятия допущения,
c. Функция(и), связанная(ые) с требованием,
d. Уровень гарантии проектирования,
e. Используемый(ые) метод(ы) валидации,
f. Результат валидации («обоснованное»/«необоснованное» требование).
7.7.4
Сводный отчет по валидации
Сводный отчет (заключение) по валидации должен гарантировать, что
58
Авиарегистр МАК
Р4754
валидация была проведена надлежащим образом. Отчет должен включать:
a. Ссылку на план валидации и описание всех существенных отклонениях от
этого плана,
b. Матрицу валидации, указанную в разделе 7.7.3,
c. Идентификацию полученных данных или источника этих данных (см. раздел
7.7.2.).
8.
ВЕРИФИКАЦИЯ РЕАЛИЗАЦИИ
Целью верификации является выяснение соответствия каждого уровня
реализации относящимся к нему требованиям.
Процесс верификации гарантирует, что реализованная система
удовлетворяет предъявляемым к ней прошедшим валидацию требованиям.
Верификация производится методами осмотра, экспертной оценки, анализа,
испытаний, учета опыта эксплуатации в соответствии с планом верификации.
Мероприятия, выполняемые при верификации, описаны ниже.
8.1.
a.
b.
c.
Задачи процесса верификации
В процесс верификации:
Подтверждается, что предусмотренные функции правильно реализованы,
Требования были удовлетворены,
Гарантируется, что анализ безопасности остается в силе для реализованной
системы.
8.2.
Модель процесса верификации
На Рисунке 6 показан общий вид модели верификации на различных
уровнях реализации системы.
a.
b.
с.
Процесс верификации состоит из трех описанных ниже составляющих:
Планирование.
Оно включает в себя планирование требуемых ресурсов, последовательности
проводимых мероприятий, формируемые выходные данные, сравнения
требуемой информации, выбора конкретных мероприятий и критериев
оценки, а также подготовки специальной аппаратуры или программного
обеспечения верификации (см. раздел 8.3.).
Проведение мероприятий.
Включает мероприятия с использованием соответствующих методов
верификации (см. раздел 8.4).
Выходные данные.
Они обеспечивают очевидность результатов проверки (см. раздел 8.5).
59
Авиарегистр МАК
Р4754
Уровень верификации определяется уровнем гарантии проектирования
системы или изделия (см. 8.4.5).
Исходными материалами для верификации является совокупность
документированных требований к реализуемой системе или изделию и полное их
описание.
Процесс
разработки
План
верификации
8.5.1
Реализация
Матрица
(Начальная)
8.5.3
Требования к
разработке и
Уровень гарантии
проектирования
Проверки,
экспертиза,
анализы,
испытания и
опыт
эксплуатации
8.4
Матрица
(Конечная)
8.5.3
Итоговый
отчёт по
верификации
8.5.4
Данные
Процесс проектирования
Процесс верификации
Рисунок 6. Модель процесса верификации.
Для верификации может использоваться нескольких методов проверки.
Например, при проверке наиболее тяжелых случаев наряду с анализом может
потребоваться и проведение натурных испытаний.
В процессе верификации все выявленные аномалии предусмотренных
функций (такие, как непредусмотренные функции или отклонения
характеристик) должны фиксироваться для последующей экспертизы.
8.3.
Планирование верификации
Целью этого этапа является определение процессов и критериев по каждому
требованию в обеспечение выполнения задач верификации. На этапе
планирования должны быть выполнены следующие мероприятия:
a. Идентификация конфигурации системы или изделия, включая любое
специальное испытательное оборудование, установки, а также любые
аппаратные или программные свойства/характеристики, которые должны
60
Авиарегистр МАК
b.
c.
d.
e.
Р4754
проверяться.
Сопоставление всех требований, которые относятся к рассматриваемому
уровню, включая производные требования и их трассировку.
Определение конкретных методов верификации, которые должны
применяться для доказательства соответствия каждому требованию с учетом
уровня гарантии проектирования.
Определение критерия, который должен использоваться для оценки
очевидности результатов полученных при использовании каждого из
методов верификации.
Идентификация достоверности верификации системы с учётом мероприятий
по верификации аппаратуры и программного обеспечения.
8.4.
Методы верификации
Целью мероприятий по выбору методов верификации является обеспечение
проверки
соответствия
реализованной
системы
функциональным
и
конструктивным требованиям, включая заданные окружающие условия
эксплуатации. Для верификации любой системы или изделия могут
использоваться четыре основных метода:
a. Осмотр и экспертная оценка,
b. Анализ,
c. Испытания,
d. Опыт эксплуатации.
Каждый из этих методов будет рассмотрен в последующих разделах.
8.4.1
Осмотр и экспертная оценка
Осмотр и экспертная оценка производятся для формирования
согласованного мнения о соответствии продукта предъявляемым требованиям.
Обычно при этом используется контрольный перечень проверок (checklist) или
аналогичный документ. Типичными операциями при экспертной оценке
являются:
a. Осмотр, свидетельствующий о том, что система или изделие соответствуют
необходимой физической реализации и требуемому качеству исполнения,
b. Экспертиза проекта, показывающая, каким образом система или изделие
будут функционировать в нормальных и ненормальных условиях,
c. Экспертиза испытаний, устанавливающая их приемлемость для проверки
соответствия требованиям системы или изделия.
8.4.2
Анализ
Анализ обеспечивает очевидность соответствия системы или изделия
требованиям путем детального рассмотрения (например, их функциональных
61
Авиарегистр МАК
Р4754
возможностей и характеристик). Методы анализа описываются в следующих
разделах, однако допускается применение и других методов.
8.4.2.1 Моделирование
Моделирование сложных детерминированных систем может быть
полностью
математическим
или
комбинированным
(математическое
моделирование и испытания). Моделирование применяется для оценки
параметров системы и получения информации о поведении системы на ранних
этапах проектирования или для других целей.
8.4.2.2 Анализ охвата требованиями
Данный анализ выполняется, чтобы определить степень охваченности
требований в процессе проектирования и верификации. Обычно при этом
используется одна из форм трассировки требований.
8.4.3
Испытания
Испытания обеспечивают воспроизводимую очевидность корректности
проверяемых систем или изделий путем проверки соответствия требованиям.
Испытания выполняют две задачи:
a. Продемонстрировать, что реализованная система или изделие выполняют
предусмотренные функции. Проверка выполнения предусмотренных
функций включает оценку по критерию "Удовлетворяет/Не удовлетворяет",
вытекающему из требований безопасности,
b. Обеспечить уверенность, что реализованная система не выполняет
непредусмотренных функций (т.е. тех функций, которые не были заложены
при разработке), влияющих на безопасность. Для обнаружения
предусмотренных функций системы (изделия) или побочных эффектов
могут потребоваться специальные испытания или ужесточенный контроль в
ходе обычных испытаний. Следует отметить, что путем испытаний
невозможно установить полное отсутствие непредусмотренных функций.
Испытания производятся на полном комплекте системы (изделия), либо на
ее части, либо на утвержденной модели с использованием процедур,
документированных достаточно детально для того, чтобы можно было
воспроизвести результаты испытаний. Проблемы/недостатки, обнаруженные во
время испытаний должны быть описаны, должны быть выполнены мероприятия
по их устранению, а доработанное изделие должно быть повторно испытано.
a.
Для каждого испытания должны быть определены:
Требуемые входы, при этом при установлении критериев испытаний должны
62
Авиарегистр МАК
b.
c.
a.
b.
c.
d.
e.
f.
Р4754
быть рассмотрены различные их вариации,
Выполняемые действия,
Ожидаемые результаты и допуски на них.
Данные по результатам испытаний должны, как минимум, содержать:
Версию используемой спецификации (перечня требований) испытаний,
Версию испытуемого образца системы или изделия,
Версию или ссылку на стандарт используемого испытательного
оборудования/средства и приспособления с их калибровочными данными,
Результаты каждого испытания с констатацией соответствия критерию
"Удовлетворяет/Не удовлетворяет",
Расхождения между ожидаемыми и действительными результатами,
Заключение об успешном или неудачном завершении процесса испытаний,
содержащее увязку с программой верификации.
8.4.4
Сходство/ опыт эксплуатации
Верификационный «кредит доверия» может быть получен оценкой
конструкции, включая установку на ВС, и сведениями об удовлетворительной
эксплуатации другого гражданского ВС, на котором установлена та же самая или
сходная
система.
При
данном
методе
должны
использоваться
документированный опыт эксплуатации совместно с инженерными и
эксплуатационными оценками, демонстрирующими, что ни один значительный
отказ не остался не устранённым при данной установке на борту. Более детально
данный вопрос рассмотрен в разделе 11.4.2.
8.4.5
Рекомендуемые верификационные мероприятия
В Таблице 7 представлен перечень рекомендуемых и допустимых методов
верификации и получаемых при этом данных, которые выбираются в
зависимости от требуемого уровня гарантии проектирования. Необходимое
применение и распространение этих методов и данных зависят не только от
уровня проектирования, но и находятся под влиянием соответствующих отказных
состояний.
Например, верификация проведённая по уровню А или В, может включать
в себя осмотр или экспертную оценку и анализ а также должна включать
проведение некоторых испытаний. Степень применения каждого метода и объем
получаемых данных устанавливаются по соглашению с сертифицирующим
органом в зависимости от особенностей сертифицируемой системы.
63
Авиарегистр МАК
Р4754
Таблица 7. Верификационные методы и данные
Уровень гарантии проектирования
Методы и данные (см.
AиB
8.4 и 8.5)
Матрица верификации
R
План верификации
R
R
Процедуры верификации
R
Заключение по
результатам верификации
R
Оценка безопасности
системы (SSA, см. 6.3)
Испытания
Осмотр, экспертная
и один или
оценка, анализ или
более из
испытания (Прим. 1)
остальных
методов
R
Испытания на
непредусмотренные
функции
A
Опыт эксплуатации
C
D
E
R
R
A
R
A
A
A
A
N
N
N
N
R
N
N
Один или
более
A
N
(Прим. 2)
A
A
N
A
A
A
R – рекомендуется.
A - по согласованию.
N - не требуется для сертификации.
Примечание 1:
Примечание 2:
8.5.
Эти методы обеспечивают сходные степень проверки. Выбор
наиболее приемлемого метода зависит от архитектуры
конкретной системы и типа реализованной функции.
Должна быть показана совместимость с условиями установки и
окружающей средой.
Верификационные данные
Верификационные данные должны подтвердить очевидность проведения
верификации в соответствии с планом. Эти данные могут потребоваться для
доказательства соответствия и подтверждения требований к сертификационным
данным, описанным в разделах 4.3 и 4.4. Поэтому в процессе проектирования
рекомендуется оформлять и поддерживать верификационную матрицу, а также
оформлять итоговый отчет с результатами верификации.
64
Авиарегистр МАК
Р4754
Требования к верификации программного обеспечения и аппаратной части
указаны в документах DO-178B и DO-254, соответственно. Итоговые отчёты по
результатам верификации программного обеспечения и аппаратной части
должны включаться в верификационные данные соответствующей системы.
8.5.1
План верификации
План верификации устанавливает стратегию демонстрации соответствия
реализации установленным для нее требованиям. Типичный план верификации
может включать:
a. Распределение ролей и ответственности по выполнению мероприятий
верификации,
b. Описание степени независимости разработки и мероприятий верификации,
c. Применение метода(ов) верификации,
d. Данные, которые должны быть получены,
e. Последовательность выполнения связанных мероприятий,
f. График выполнения основных мероприятий верификации.
Некоторые аспекты процесса верификации могут также поддерживать
валидацию отдельных требований и должны быть скоординированы с планом
валидации.
8.5.2
Процедуры и результаты верификации
Описание процедур верификации совместно с полученными результатами
обеспечивают очевидность, необходимую для подтверждения правильности
проведённой верификации.
8.5.3
Матрица верификации
Матрица верификации или эквивалентный трассировочный документ
должен быть подготовлен для отслеживания состояния процесса верификации.
Степень детализации этой матрицы зависит от уровня гарантии проектирования
верифицируемых систем или изделий. Форма матрицы определяется заявителем,
но она должна, как минимум, включать в себя:
a. Требования,
b. Соответствующую функцию,
c. Уровень гарантии проектирования,
d. Применяемый (ые) метод(ы) верификации,
e. Результат верификации («Удовлетворяет» или «Не удовлетворяет»),
f. Сводное заключение по верификации (с «привязкой» процедур и результатов
проверок к требованиям на системы или изделия).
65
Авиарегистр МАК
8.5.4
Р4754
Верификационное заключение
Заключение (резюме, сводка) по результатам верификации обеспечивает
наглядность доказательств соответствия реализованной системы или изделия
установленным требованиям. Оно должно содержать:
a. Ссылки на план верификации и описание всех существенных отклонений от
него,
b. Матрицу верификации, упомянутую в разделе 8.5.3,
c. Ссылку на систему разрешения проблем (соответствующая уровню гарантии
проектирования),
d. Описание «открытых» отчётов о проблемах и оценку их влияния на
безопасность (в соответствии с уровнем гарантии проектирования),
e. Идентификация выходных данных и их источников (в соответствии с
уровнем качества проектирования), см. раздел 7.7.2 в части критериев к
данным.
9.
УПРАВЛЕНИЕ КОНФИГУРАЦИЕЙ
В данном разделе рассматриваются цели и мероприятия процесса
управления конфигурацией системы. Данный процесс распространяется на
систему, входящие в неё изделия, используемый инструментарий и требуемые
сертификационные данные. План управления конфигурацией включает методы,
используемые при иллюстрации достижения целей процесса управления
конфигурацией.
Наименование или содержание данного раздела не подразумевает
существование независимого подразделения или организации выполняющих
функции управления конфигурацией.
9.1.
a.
b.
Задачи процесса управления конфигурацией
Задачами процесса управления конфигурацией являются:
Технический и административный контроль конфигурации:
1)
Системных требований,
2)
Изделий, реализующих систему,
3)
Соответствующих сертификационных данных (см. таблицу 2),
4)
Инструментария и средств, конфигурация которых является
существенной для подтверждения гарантии проектирования при
сертификации.
Контроль изменений конфигурации системы или сертификационных данных
путем:
1)
Установления определенной точки пересмотра, идентифицирующей
состояние модификаций и контроля изменений системной конфигурации по
66
Авиарегистр МАК
Р4754
отношению к установленной базовой конфигурации (baseline),
2)
Обеспечение контроля, гарантирующего, что идентифицированные
проблемы и мероприятия по их устранению зафиксированы, одобрены и
реализованы.
c. Гарантия обеспечения архивации, пользования и контроля соответствующих
системных данных.
d. Трассировка соответствия системы требованиям к ней.
Управление конфигурацией включает мероприятия, относящиеся как к
проектированию системы, так и ее сертификации. С позиций графика
сертификации базовая конфигурация и соответствующие процедуры контроля
изменений должны быть установлены уже на том этапе проектирования, когда
необходимо
представлять
первые
сертификационные
доказательства.
Трассировка между заключительной предлагаемой конфигурацией и базовой
конфигурацией является необходимым элементом демонстрации гарантии
проектирования.
9.2.
Мероприятия процесса управления конфигурацией
Процесс управления конфигурацией включает в себя идентификацию
конфигурации,
контроль
изменений/решение
проблем,
а
также
архивацию/восстановление документации. Неразрывность выполнения этих
мероприятий значительно повышает их эффективность и доверие ко всему
процессу управления конфигурацией. В интересах сертификации очевидность
непрерывности процесса управления конфигурацией может подтверждаться, не
ограничиваться только этим, ведением записей или отчетов, в которых
описываются проведенные мероприятия.
9.2.1
Идентификация конфигурации
Целью идентификации конфигурации является однозначное обозначение
изделий и сертификационных данных системы (а также их последующих
вариантов/версий) для установления базиса, в интересах последующих ссылок и
контроля изменений. В случае необходимости каждый отдельно контролируемый
компонент или версия программного обеспечения должны маркироваться
(например, этикеткой или «шильдиком»). Формат маркировки определяется
заявителем.
9.2.2
Отчеты о проблемах и контроль изменений
Целью подготовки отчетов о проблемах, связанных с сертификацией,
является документирование возникающих проблем и их разрешения. Контроль
изменений обеспечивает оценку и одобрение изменений, влияющих на
67
Авиарегистр МАК
Р4754
сертификацию. Ниже приводятся руководящие указания, относящиеся к тем
аспектам контроля изменений и формирования отчетов о проблемах, которые
являются важными для демонстрации гарантии проектирования:
a. Должны быть предусмотрены способы документирования характера
возникших проблем, путей их решения, а также и изменений изделия, его
технических или сертификационных данных. В данные должны включаться
все изменения, связанные с производными требованиями,
b. Контроль изменений должен обеспечивать сохранение целостности изделий
и сертификационных данных, обеспечивая защиту от несанкционированных
изменений,
c. Контроль изменений должен гарантировать, что любое изменение изделия
или сертификационных данных идентифицировалось путём
соответствующего изменения конфигурационной идентификации,
d. Контроль изменений должен гарантировать, что изменение изделия влечёт за
собой изменение данных, относящихся к данному изделию.
9.2.3
Архивация и извлечение данных
Система архивации и извлечения данных должна гарантировать
восстановление сертификационных данных на систему и входящие в нее изделия.
Процедуры сохранения данных должны удовлетворять требованиям летной
годности. При этом необходимо руководствоваться следующим:
a. Данные, относящиеся к системе или входящим в нее изделиям, должны
извлекаться/получаться из контролируемого источника (например, из
организации или фирмы, являющейся разработчиком системы),
b. Должны быть установлены процедуры, обеспечивающие целостность
сохраняемых данных в течение времени, требуемого сертифицирующим
органом. Эти процедуры должны предусматривать:
1)
Исключение несанкционированных изменений,
2)
Выбор носителя информации, обеспечивающего минимальные
искажения или ошибки при регенерации информации;
3)
Проверку и/или восстановление архивных данных с частотой,
определяемой характеристиками носителя информации;
4)
Хранение дублирующих копий в физически разнесённых хранилищах
для того, чтобы минимизировать риск их потери в случаях бедствия.
10.
ГАРАНТИЯ ПРОЦЕССОВ
В данном разделе описываются мероприятия, которые гарантируют, что
проектирование системы и поддерживающие процессы ведутся в соответствии с
установленным порядком, который поддерживается и соблюдается во время
проектирования. Описанные ниже действия по гарантии выполнения процессов
не предполагают наличия каких-либо специальных организационных структур
68
Авиарегистр МАК
Р4754
или ответственных.
10.1.
Цели гарантии выполнения процессов
Мероприятия по обеспечению гарантии выполнения процессов проводятся
для того, чтобы:
a. Гарантировать наличие необходимых планов, которые поддерживаются по
всем аспектам системного проектирования,
b. Гарантировать выполнение этапов и процессов проектирования в
соответствии с этими планами,
c. Гарантировать возможность очевидной демонстрации реализации этих
планов.
10.2.
План гарантии процессов
План гарантии выполнения процессов описывает средства, которые
гарантируют, что в процессе проектирования системы установленные процедуры
и практические указания выполняются. Особое внимание должно уделяться
мероприятиям, связанным с сертификацией. При подготовке плана гарантии
процессов должно учитываться следующее:
a. Область распространения и содержание других планов проекта (планы
проектирования/разработки, сертификации, валидации, верификации и
управления конфигурацией) должны соответствовать уровню
проектирования/разработки системы или изделия,
b. Взаимосвязи, координация, последовательность выполнения и механизм
контроля хода выполнения проекта должны быть определены,
c. Процедуры контроля изменений, технического обслуживания и
эксплуатации должны быть определены,
d. В интересах своевременного обнаружения ошибок проектирования должна
быть обеспечена возможность экспертных оценок/рассмотрений проекта,
e. Должна быть запланирована тесная координация с сертифицирующими
органами.
10.3.
a.
b.
c.
d.
Экспертизы/рассмотрения плана проекта
При оценке проектных планов, должно быть рассмотрено в какой степени:
Применяемые процедуры и практические указания документированы,
Применённая практика связи гарантирует своевременный обмен
информацией между задействованными процессами и персоналом,
Определены процедуры корректировок планов, вызванных изменениями
процесса, графика работ или техническими причинами,
Изменения планов соответствующим образом отслеживаются и
контролируются.
69
Авиарегистр МАК
10.4.
a.
b.
c.
d.
11.
Р4754
Очевидность гарантии выполнения процессов
Очевидность соответствия проектным планам может обеспечиваться:
Одобренными и датированными проектными планами,
Отчетами и заключениями по экспертным оценкам, предусмотренными в
планах.
Фактическими данными, полученные в процессе разработки, верификации,
валидации, управления конфигурацией и сертификации,
Подтверждением (например, оформленными протоколами проверок,
обсуждений) своевременно проведенных экспертиз/рассмотрений гарантии
выполнения процессов.
МОДИФИКАЦИЯ ВОЗДУШНОГО СУДНА
Многие из процессов, описываемых в данном документе, относятся к
проектированию ВС и его систем. Их не всегда можно распространить на
эксплуатирующийся ВС. В этих случаях могут потребоваться альтернативные
методы для доказательства соответствия сертификационным требованиям. В
данном разделе рассматривается, каким образом материалы настоящего
документа могут использоваться при модификации ВС или системы, которые
разрабатывались без учета рекомендаций данного документа.
11.1.
Сертификационный базис
Сертификационный базис определяет распространяющиеся на разработку
нормы, соответствие которым должен обеспечить заявитель, и включает, кроме
того, ряд специальных требований, дополняющих действующие нормы. При
модификации системы или ВС сертифицирующий орган рассматривает влияние
проводимой модификация на результаты проведенной сертификации. В
некоторых случаях модификация требует дополнения к существующему
сертификационному базису (например, в случае применения совершенно новой
технологии).
11.2.
Методы соответствия
Заявитель предлагает методы оценки соответствия, которые позволяют
продемонстрировать соответствие системы сертификационному базису. Вне
зависимости от того, изменялся или нет сертификационный базис, необходимо
оценить предлагаемые методы соответствия, чтобы убедиться в их
совместимости с согласованным сертификационным базисом.
70
Авиарегистр МАК
11.3.
Р4754
Рассмотрение модификаций
Модификации существующего ВС могут производиться в различных
формах, включая:
a. Ввод новой функции ВС,
b. Замену на существующем ВС одной системы на другую,
c. Адаптацию существующей системы к другому типу ВС,
d. Изменение существующей системы на существующем ВС.
Поскольку большинство высокоинтегрированных или сложных систем
реализует несколько функций, весьма вероятно, что конкретная модификация
такой системы будет включать в себя несколько указанных выше форм.
11.3.1 Ввод новой самолётной функции
Новая самолётная функция может быть введена модификацией
существующей системы, ранее установленной на ВС или установкой новой
системы. Для ввода новой функции на уровне ВС:
a. Заявитель должен проектировать новую функцию ВС в соответствии с
разделами 3-10 данного документа. Особое внимание должно быть обращено
на следующие моменты:
1)
Оценка функциональных опасностей должна показать отказные
состояния и соответствующие опасности для новых функций, а также
идентифицировать требования к безопасности модифицированной системы,
2)
Оценка функциональных опасностей должна также
идентифицировать и показать, каким образом другие функции и системы
реагируют на ввод новой функции ВС. Для этого можно произвести анализ
взаимодействия и взаимозависимости функций и определить, в какой
степени каждая функция интегрирована с другими функциями ВС,
b. Если соответствие доказывается на основе ранее сертифицированных
«базовых» ВС или системы, то предлагаемая система или изделие должны
быть трассированы с этой базовой типовой конструкцией,
c. Если сертификационные данные для неизменяемых систем ВС не
существуют или не доступны для заявителя, то он должен указать и
обосновать допущения для неизмененных систем, чтобы подтвердить
результаты процесса оценки безопасности.
11.3.2 Замена одной системы другой на существующем ВС
Установка сменной системы на ранее сертифицированном типе ВС может
изменить реализацию функции или функций без добавления новой функции на
уровне ВС. Если же новая функция на уровне ВС добавляется, то необходимо
руководствоваться разделом 11.3.1. Установка новой системы взамен
существующей может производиться по ряду причин, к которым относятся:
71
Авиарегистр МАК
Р4754
замена устаревшего оборудования, повышение надежности или целостности, а
также приведение в соответствие с изменившимися нормами. При замене
системы на ранее сертифицированном типе ВС:
a. Заявитель должен провести экспертизу имеющихся результатов ранее
проведенной оценки безопасности (если она отсутствует, см.
предшествующий подраздел «с.»), учитывая:
1)
Установку сменной системы,
2)
Область, в которой используется новая система,
3)
Наличие сертификационных данных по заменяемой системе,
4)
Сертификационный базис ВС.
Может потребоваться подготовка дополнительных данных по оценке
безопасности для подтверждения корректности и полноты показателей
безопасности заменяемой системы и для гарантии того, что показатели
безопасности на уровне ВС в целом удовлетворяются.
b. Если соответствие доказывается на основе ранее сертифицированных
«базовых» ВС или системы, то предлагаемая система или изделие должны
быть трассированы с этой базовой типовой конструкцией,
c. Если сертификационные данные для неизменяемых систем ВС не доступны
для заявителя, то он должен указать и обосновать допущения для
неизмененных систем, чтобы подтвердить результаты процесса оценки
безопасности,
d. Заявитель должен проектировать новую устанавливаемую взамен систему в
соответствии с разделами 3-10 данного документа. Особое внимание должно
быть обращено на следующие моменты:
1)
Оценка функциональных опасностей должна быть направлена на
отказные состояния заменяющей системы и на идентификацию показателей
безопасности модифицируемых систем,
2)
Оценка функциональных опасностей должна также
идентифицировать и показать, каким образом другие функции и системы
реагируют на ввод заменяющей системы. Для этого можно произвести
анализ взаимодействия и взаимозависимости функций и определить, в какой
степени функция(и) ВС осуществляемые заменяющей системой
интегрируются с другими функциями ВС.
11.3.3 Адаптация существующей системы к другому типу ВС
Системы, предварительно одобренные для использования на одном типе
ВС, должны быть повторно проверены в интересах установки на другой тип ВС.
Для
зачёта
заявителю
результатов
предыдущей
сертификации,
сертифицирующий орган потребует доказательств подобия конструкции,
установки и применения. При отсутствии таких доказательств, для демонстрации
соответствия устанавливаемой системы показателям безопасности можно
использовать соответствующие части разделов 3 - 10 данного документа. При
72
Авиарегистр МАК
Р4754
установке существующей системы на другом ВС:
a. Заявитель должен провести экспертизу результатов проведенной оценки
безопасности, учитывая:
1)
Подобие/сходство установки и эксплуатации системы на
существующем и новом ВС,
2)
Сходство функций в обоих случаях использования системы,
3)
Воздействие устанавливаемой системы на другие системы ВС, к
которому производится адаптация,
4)
Сертификационный базис,
5)
Адекватность сертификационных данных, относящихся к
предыдущей установке системы.
b. Если показатели безопасности устанавливаемой системы на новом типе ВС
являются такими же, как на предыдущем типе и доказан необходимый
уровень сходства ВС, то выполнения каких-либо дополнительных действий
не требуется.
В противном случае процесс оценки безопасности должен идентифицировать и
обосновать работоспособность старых функций при новой установке. Оценка
должна быть направлена на неизменность функционирования при новой
установке. Это может быть осуществлено с помощью анализа взаимодействия и
взаимозависимости новой системы и других систем ВС.
c. Если соответствие доказывается с использованием мероприятий по гарантии
проектирования ранее сертифицированных «базовых» самолёта или
системы, то сертификационные данные предлагаемой системы или изделия
должны быть трассированы с базовыми сертификационными данными.
d. Если сертификационные данные оставшихся без изменения функций ВС, с
которыми связана новая система, недоступны заявителю, то для
подтверждения результатов оценки безопасности он должен
идентифицировать и обосновать допущения, относящиеся к этим
неизмененным функциям.
e. Заявитель должен дополнить имеющиеся сертификационные данные в
соответствии с руководящими указаниями раздела 11.4.1 в
нижеприведённых случаях:
1)
Когда недоступны сертификационные данные предыдущей установки
системы, которые могли бы подтвердить, что новая установка удовлетворяет
требуемым для нее показателям безопасности,
2)
Когда сертификационные данные предыдущей установки
недостаточны для того, чтобы установить и обосновать область действия
системы.
f. Должна быть произведена валидация требований и верификация новой
установки в соответствии с разделами 7 и 8.
73
Авиарегистр МАК
Р4754
11.3.4 Переделка системы на существующем ВС
Переделка ранее одобренной системы может изменить реализацию
функции ВС без добавления новой функции на уровне самолёта. Если же новая
функция на уровне ВС добавляется, то необходимо руководствоваться разделом
11.3.1. Переделка может быть вызвана изменением требований или желаемых
характеристик, исправлением ошибок реализации или повышением надежности
оборудования. При переделке системы на ранее сертифицированном самолёте:
a. Заявитель должен провести экспертизу результатов процесса оценки
безопасности, учитывая влияние переделки на:
1)
Область, в которой используется новая система,
2)
Доступность сертификационных данных,
3)
Сертификационный базис ВС,
4)
Существующие требования (включая влияние на оставшиеся
неизмененными требования),
5)
Архитектуру системы.
В процессе оценки безопасности должны быть идентифицирована и
подтверждена область влияния переделки. Для этого, в соответствии с
соответствующими частями раздела 5, можно провести анализ взаимодействия
переделываемой системы с другими системами ВС.
b. Если соответствие доказывается с использованием мероприятий по гарантии
проектирования ранее сертифицированных «базовых» самолёта или
системы, то предлагаемая переделка системы или изделия, а также их
сертификационные данные должны быть трассированы с базовыми
сертификационными данными.
c. Если сертификационные данные оставшихся без изменения областей ВС, в
которых действует новая система, недоступны заявителю, то для
подтверждения результатов оценки безопасности он должен
идентифицировать и обосновать допущения, относящиеся к этим областям.
d. Заявитель должен дополнить имеющиеся сертификационные данные в
соответствии с указаниями раздела 11.4.1 при следующих условиях:
1)
Отсутствуют (или недоступны) сертификационные данные
предыдущей установки системы, которые могли бы подтвердить, что новая
установка удовлетворяет требуемым показателям безопасности,
2)
Когда сертификационные данные предыдущего проектирования
недостаточны для того, чтобы определить и обосновать область, на которую
будет влиять переделка системы.
e. Должна быть произведена валидация требований, на которые повлияла
переделка системы, а также верификация реализации переделки в
соответствии с разделами 7 и 8.
74
Авиарегистр МАК
11.4.
Р4754
Дополнительные рассмотрения
При составлении руководящих указаний, содержащихся в данном
документе, предполагалось, что для доказательства соответствия определённым
требованиям гарантии проектирования используются надлежащим образом
структурированное процессы проектирования и оценки безопасности. Если
соответствие пытаются доказать, используя мероприятия по обеспечению
гарантии проектирования, выполненные на сертифицированном ранее «базовых»
ВС или системе, то предлагаемая система или изделие и их сертификационные
данные должны быть трассированы с этой базой. В некоторых случаях такие
доказательства могут оказаться недостаточными. В ниже приведённых разделах
изложены руководящие указания по:
a. Дополнению имеющихся сертификационных данных для обеспечения
сертификации модификации существующих систем или новых установок
ранее сертифицированных систем.
b. Использованию данных эксплуатации системы на одном типе ВС для
поддержки сертификации этой системы на другом типе ВС или подобной
системы на этом же типе ВС.
11.4.1 Дополнение имеющихся сертификационных данных
a.
b.
c.
d.
Для дополнения имеющихся сертификационных данных заявитель может:
Оценить применимость данных предыдущей сертификации, чтобы
определить, какие требования настоящего документа удовлетворяются для
новой заявки, а какие нуждаются в дополнительном рассмотрении.
Использовать метод обратной разработки (reverse engineering) для получения
сертификационных данных, подтверждающих соответствие настоящему
документу.
Использовать сведения по эксплуатации в соответствии с разделом 11.4.2
для подтверждения соответствия настоящему документу.
Указать стратегию доказательства соответствия настоящему документу в
Плане сертификации.
11.4.2 Использование данных по эксплуатации
Материалы по эксплуатации могут использоваться для поддержки
сертификации новых или модифицированных систем, если анализ показал
применимость этих данных, притом, что изменения конфигурации системы
контролировались и документировались надлежащим образом. Данный метод
допускает валидацию требований путем сравнения с требованиями к сходной
сертифицированной системе, находящейся в эксплуатации. Аргумент сходства
становится все более убедительным по мере роста продолжительности
эксплуатации системы. Аргументы сходства не должны использоваться до тех
75
Авиарегистр МАК
Р4754
пор, пока не будет подтверждено, что все встретившиеся в эксплуатации
проблемы изучены и разрешены.
При использовании материалов эксплуатации:
a. Заявитель должен указать в Плане сертификации, каким образом будут
использоваться эти данные, (в частности, доступный объем
эксплуатационных данных и описание метода их анализа).
b. Заявитель должен выполнить анализ, позволяющий установить, в какой
степени могут быть использованы материалы эксплуатации. Этот анализ
должен показать, что:
1)
Процедуры по отчётам о проблемах за время рассматриваемого
периода эксплуатации обеспечивают представление достаточной
информации о возникавших проблемах,
2)
Изменения системы во время рассматриваемого периода
эксплуатации не повлияли существенно на характеристики системы и ее
безопасность,
3)
Фактическое использование базовой системы в рассматриваемый
период эксплуатации совпадает с намерениями по использованию новой или
модифицированной систем. Если условия эксплуатации существующей и
предлагаемой систем отличаются, то дополнительные мероприятия по
валидации и верификации этих отличий должны быть проведены в
соответствии с разделами 7 и 8.
c. Заявитель должен проанализировать все проблемы безопасности и
подготовить отчёт по их причинам, корректирующим действиям и
установить, относятся ли они к предлагаемой системе, модификации
системы или к применению системы на ВС.
76
Авиарегистр МАК
Р4754
ПРИЛОЖЕНИЕ A. РАССМОТРЕНИЕ ТИПОВОГО ПОДХОДА К
ПРОЕКТИРОВАНИЮ ФУНКЦИОНАЛЬНЫХ СИСТЕМ ВС
В данном разделе рассмотрен типовой подход к проектированию систем
ВС, начиная с концептуального определения выполняемых функций и заканчивая
сертификацией. Задачей данного приложения является установление общей
терминологии по общим процессам, определение их взаимосвязи в интересах
понимания предназначения и применимости доказательных материалов. Типовой
процесс, изложенный в данном разделе служить средством достижения этого
понимания. Этот раздел не предлагает предпочтительный метод или процесс и не
подразумевает конкретную организационную структуру.
Обычной концептуальной моделью процесса проектирования системы
является последовательность выполняемых «сверху-вниз» действий, начиная от
определения требуемых функций на уровне ВС. Типовое проектирование
системы идет путем итераций и параллельных операций с использованием
стратегий как «сверху-вниз», так и «снизу-вверх». В данном документе основное
внимание уделено аспектам проектирования, связанным со стратегией «сверхувниз», поскольку при этом обеспечивается необходимая связь между
проектированием системы и безопасностью ВС в интересах доказательства
соответствия системы требованиям летной годности.
Ниже приводится перечень этапов типового процесса проектирования
систем:
a. Идентификация самолётных функций, функциональных требований и
интерфейсов,
b. Определение последствий отказов функций и вызываемых ситуаций,
c. Распределение функций между системами и экипажем,
d. Проектирование архитектуры системы и назначение требований к изделиям,
e. Назначение требований к аппаратной части и программному обеспечению
изделий,
f. Разработка/создание аппаратной части и программного обеспечения изделия,
g. Интеграция аппаратной части и программного обеспечения,
h. Интеграция системы.
В связи с итеративной природой всех программ системного
проектирования, за исключением самых простых, этот процесс следует считать
скорее циклическим, чем последовательным. Более того, точкой ввода любой
заданной функции может быть любая точка цикла. Для новой самолётной
функции, процесс начинается с определения требований высшего уровня. При
расширении самолётной функций, входной точкой может считаться изменение
77
Авиарегистр МАК
Р4754
некоторого изделия. Однако, в любом случае, необходимо производить оценку
влияния новой или измененной функции на другие функции, выполняемые на
уровне ВС, и на предъявляемые к ним требования.
На практике многие из этапов разработки совпадают, и могут
взаимодействовать между собой, что ведет к изменению первоначально
установленных требований. Производные требования, возникающие на любом
уровне, могут изменить или ограничить решения, связанные с требованиями
верхнего уровня (см. 5.3).
A.1. Типовые процессы системного проектирования
A.1.1 Идентификация самолётных функций, функциональных требований
к функциям и интерфейсов
Этот процесс начинается с установления основных летно-технических
характеристик ВС и эксплуатационных требований. Исходя из этих основных
требований, могут быть установлены функциональные требования и
идентифицированы их функциональные интерфейсы с физической средой, а
также средой, в которой будет эксплуатироваться ВС.
Каждая из самолётных функций, выполняемых на верхнем уровне, не
обязательно связана с единственной физически реализованной системой.
Типичными функциями, выполняемыми на уровне ВС, являются:
a. Управление полётом,
b. Управление ВС («рулёжка») на земле,
c. «Бортовая часть» управления воздушным движением,
d. Автоматическое управление полётом ВС,
e. Погрузочно-разгрузочные операции,
f. Управление двигателем,
g. Предупреждение столкновений в воздухе,
h. Торможение на земле,
i. Контроль окружающих среды,
j. Комфорт пассажиров,
k. Связь,
l. Наведение,
m. Навигация,
n. Безопасность пассажиров.
Результатом этого этапа является перечень функций, выполняемых на уровне ВС,
требований к этим функциям и их интерфейсы.
A.1.2 Определение последствий отказов функций и вызываемых ситуаций
Для того чтобы установить классификацию отказных состояний каждой из
78
Авиарегистр МАК
Р4754
функций, на уровне ВС производится оценка функциональных опасностей.
Руководящие указания по классификации отказных состояний приводятся в
разделе 6.1. Результатом этого является установление связи каждой функции ВС
(см. А.1.1.) с относящейся к ней классификацией отказного состояния в
зависимости от создаваемой опасности.
A.1.3 Распределение функций между системами и экипажем
Следующим этапом является разбиение функций ВС на группы и
распределение относящихся к ним требований между системами и экипажем.
Выбор предпочтительных групп функций из возможных комбинаций часто
является сложным и противоречивым процессом. В данном руководстве не
содержится специальных рекомендаций по группировке функций. Однако для
успешного выполнения последующих этапов чрезвычайно важным является
тщательный выбор основы, для принятия решений включая касающихся этого
этапа допущений. Группировка функций связана с архитектурой ВС и являются
основой для проектирования архитектуры систем. В то время как необязательно
знать в деталях, как будет реализована в системе требуемая группа функций, то
ограничения на реализацию, влияние отказов и поддержка жизненного цикла
могут играть существенную роль при группировке функций. Допущения,
которые сделаны на данном этапе, становятся существенной частью комплекса
общих требований к системе и они являются объектом валидации наравне с
другими требованиями.
Специфика каждой группы функций играет существенную роль в
распределении их между человеком и машиной. В любом случае должны быть
указаны входы, выполняемые процессы и выходы. Необходимо рассмотреть
аспекты, связанные как с эксплуатацией, так и поддержкой.
Исходя из распределения функций и связанных с ними последствий
отказов, определяются дальнейшие конкретные требования к системам,
обеспечивающие соответствие показателям безопасности. На этом этапе могут
появляться производные требования и дополнительные допущения, как следствие
рассмотрения различных комбинаций функций и распределения их между
системами и экипажем. Это, в свою очередь, может привести к изменению
требований к функциям, выполняемым на уровне ВС.
Результатом данного этапа работ является совокупность требований ко
всем действиям экипажа, к каждой системе ВС и к интерфейсам между ними.
При определении интерфейсов для каждого входа указывается источник, а для
каждого выхода – потребитель(и), и это есть или член экипажа или какая либо
система.
79
Авиарегистр МАК
Р4754
A.1.4 Проектирование архитектуры системы и назначение требований к
изделиям
Архитектура системы устанавливает структуру и границы, в пределах
которых разрабатывается каждое изделие системы с учетом всех заданных
функциональных требований и требований безопасности. Для реализации могут
рассматриваться несколько возможных вариантов архитектуры системы. Анализ
общих причин отказов (Common Cause Analysis - CAA) поддерживает выбор
архитектуры системы, подтверждая требуемую независимость трактов.
Практические соображения, касающиеся применяемых технологий, сроков
реализации, годности для производства, себестоимости, готовности
промышленности, являются дополнительными ограничениями при выборе
архитектуры системы. Руководящие указания по выполнению анализа общих
причин отказов (ССА) кратко изложены в разделе 6.4 и подробно рассмотрены в
ARP4761/Р4761.
Предварительная оценка безопасности системы (PSSA) проводится с целью
сравнения вариантов архитектур системы, определения численных значений
требуемых показателей безопасности изделий системы, установления уровней
гарантии проектирования системы и входящих в нее изделий и для
подтверждения приемлемости показателей безопасности на уровне изделий
системы. Эта оценка обеспечивает уверенность в достижении системой
показателей безопасности верхнего уровня. Руководящие указания по
выполнению оценки PSSA кратко изложены в разделе 6.2 и подробно
рассмотрены в ARP4761/Р4761..
По мере выполнения данного этапа работы становятся более ясными
производные требования, вытекающие из технологии, архитектуры, интерфейсов
систем и изделий или способа реализации. Эти производные требования могут
налагать существенные ограничения или приводить к изменениям требований
верхнего уровня.
Результатом данного этапа является архитектура системы на уровне
входящих изделий, а также распределение по изделиям функциональных
требований и требований безопасности. В результаты должны включаться
требования к интеграции и интерфейсы изделий.
A.1.5 Назначение требований к аппаратной части и программному
обеспечению изделий
На практике проектирование архитектуры системы и распределение
требований к изделию между его аппаратной частью и программным
обеспечением являются тесно связанными итеративными процессами. С каждым
циклом итерации растёт понимание производных требований, а распределение
системных требований между аппаратной частью и программным обеспечением
изделий становится все более обоснованным. Процесс завершается, когда все
требования распределены в рамках выбранной архитектуры.
80
Авиарегистр МАК
Р4754
В процессе распределения функциональных требований должна быть точно
установлена классификация отказных состояний для того, чтобы их трассировкой
подтвердить обоснованность дальнейшего разбиения архитектуры. При
невозможности трассировки в целях определения требований безопасности при
всех возможных отказах изделия, должно использоваться наихудшее отказное
состояние. На этом этапе распределения требований могут снова появиться
производные требования, которые должны подвергнуться валидации и оценке
влияния на безопасность.
Производные требования, возникающие при распределении требований,
могут относиться как к системе, так и к аппаратуре и/или программному
обеспечению. В соответствии с этим, верификация реализации может
проводиться на уровне системы и/или на уровне аппаратной части и
программного обеспечения.
Результатом работ по распределению требований являются требования к
аппаратной части с соответствующими показателями надежности и уровнями
гарантии разработки, а также требования к программному обеспечению, включая
уровни гарантии программного обеспечения для каждого изделия. Там, где это
необходимо, должны включаться требования, определяющие интеграцию
аппаратной части и программного обеспечения. Результаты этого этапа
используются также для корректировки предварительной оценки безопасности
системы.
A.1.6 Разработка/создание аппаратной части и программного обеспечения
Процессы разработки аппаратуры и программ должны предусматривать
трассировку по отношению к требованиям, относящимся к аппаратной части и
программному обеспечению каждого изделия. Если разработка аппаратуры и
программ ведется в параллель с распределением требований и определением
архитектуры, то необходимо строго соблюдать дисциплину разработки,
гарантирующую, что все производные требования выявлены, а все
функциональные требования реализованы.
Результатами данного этапа являются процедуры интеграции аппаратной
части и программного обеспечения, выпущенные чертежи аппаратуры, исходные
коды программ с соответствующей документацией, данные по гарантии уровня
разработки, макетные или опытные образцы аппаратуры и изделия для
лабораторных/летных испытаний. Документы RTCA, указанные в разделе 2.1.5,
содержат дополнительную информацию по мероприятиям обеспечения гарантии
уровней аппаратной части и программного обеспечения.
A.1.7 Интеграция аппаратной части и программного обеспечения
В зависимости от вида системы и принятого процесса разработки
первоначальная интеграция аппаратной части и программного обеспечения
может производиться на макетах, опытных образцах, компьютерных эмуляторах
или на изделиях, предназначенных для лабораторных или летных испытаний.
81
Авиарегистр МАК
Р4754
Результатом является физическое изделие с контролируемой конфигурацией с
данными по гарантии уровня разработки. Для проверки соответствия всем
требованиям интеграции аппаратной части и программного обеспечения должны
использоваться детальные процедуры, созданные на этапе разработки изделия.
A.1.8 Интеграция системы
Обычно процесс начинается с последовательной интеграции одного
изделия с другим и завершается полной интеграцией системы. Трудности точного
прогнозирования или моделирования среды, в которой система будет
функционировать на ВС, ведет к тому, что некоторые работы по интеграции
выполняются непосредственно на ВС. Хотя считается, что достоверность
результатов интеграции, проведенной на ВС, высока, впечатляющие или
экономически эффективные результаты можно достигнуть в условиях
лаборатории или моделирующего стенда. Процедуры системной интеграции
очень разнообразны в масштабах промышленности.
Для устранения недостатков, обнаруженных при интеграции системы,
приходится возвращаться назад, к соответствующим этапам проектирования или
поддержки (установление требований, их распределение и валидация,
реализация, верификация и т.д.). По завершению всех итераций появляется
проверенная интегрированная система с данными, демонстрирующими
соответствие системы всем функциональным требованиям и требованиям
безопасности.
Задачей интеграции систем является гарантия того, что раздельное и
совместное функционирование систем аналогично установке их на ВС. Поэтому
интеграция является средством доказательства соответствия межсистемным
требованиям, относящимся к группе систем. Кроме того, интеграция дает
возможность обнаружить и исключить функции, непредусмотренные для систем.
A.2. Обмен информацией между процессами жизненных циклов системы и
аппаратной части, а также программного обеспечения
A.2.1 Информационный поток от системных процессов к процессам
разработки аппаратуры и программного обеспечения
Этап, на котором требования распределяются между аппаратной частью и
программным обеспечением, является также переходом от рекомендаций
настоящего документа к рекомендациям документов DO-178B/КТ-178В (для
программного обеспечения), DO-254/КТ-254 (для сложной аппаратной части), а
также к другим действующим в промышленности руководствам. Приведённые
ниже данные должны использоваться в процессах разработки программного
обеспечения и аппаратной части при формировании требований:
a. Требования к аппаратной части,
b. Требования обеспечению,
c. Уровни гарантии проектирования, относящиеся к каждому требованию, и, в
82
Авиарегистр МАК
d.
e.
f.
g.
h.
Р4754
случае необходимости, описание связанных с ними отказных состояний,
Заданные величины интенсивности отказов и интервала(ов) сохранения
наиболее существенных скрытых отказов аппаратуры,
Описание интерфейса между аппаратной частью и программным
обеспечением (проект системы),
Ограничения при разработке, включая требования к разделению функций,
разнесению и обособлению,
Мероприятия по валидации системы, которые, в случае необходимости,
должны выполняться на уровне программного обеспечения или аппаратной
части,
Мероприятия по верификации системы, которые должны проводиться на
уровне программного обеспечения или аппаратной части.
A.2.2 Информационный поток из процессов разработки аппаратной
части/программного обеспечения к системным процессам
Информация, приведённая ниже, должна содержаться в данных,
используемых в мероприятиях поддержки проектирования системы на
соответствующем уровне:
a. Описание реализации назначенных и производных требований,
b. Требования к программному обеспечению, включая производные
требования (относящиеся как к системе, так и к программному
обеспечению), которые необходимо оценить применительно к системным
требованиям и к требованиям на изделия, а также и к результатам
предварительной оценки безопасности системы (PSSA),
c. Требования к аппаратной части, включая производные требования, которые
необходимо оценить применительно к системным требованиям и к
требованиям на изделия, а также и к результатам предварительной оценки
безопасности системы (PSSA),
d. Описание реализованной архитектуры с указанием достигнутой
независимости и возможности сдерживания последствий неисправностей,
e. Подтверждение очевидности соответствующего уровня(ней) гарантии
проектирования. включая те, которые получены с помощью
инструментальных средств,
f. Подтверждение очевидности мероприятий по валидации системы (при
необходимости), проводимых на уровне программного обеспечения или
аппаратной части,
g. Подтверждение очевидности мероприятий по верификации
системы/изделия, проводимых на уровне программного обеспечения или
аппаратной части,
h. Сводные заключения по видам отказов аппаратной части и их последствий
(FMES), анализы видов отказов и их последствий (FMEA), величины
интенсивностей отказов, глубина контроля неисправностей и интервалы
сохранения скрытых неисправностей для включения их в оценку
83
Авиарегистр МАК
i.
Р4754
безопасности системы (SSA),
Отчёты по проблемам и изменениям, влияющим на требования к системе
или ее изделиям применительно к системным требованиям и к требованиям
на изделия, а также и к результатам предварительной оценки безопасности
системы (PSSA).
84
Авиарегистр МАК
Р4754
ПРИЛОЖЕНИЕ B. ОПРЕДЕЛЕНИЯ, СОКРАЩЕНИЯ И АКРОНИМЫ
B.1. Определения
Анализ
Analysis
Анализ общих причин
отказов
Common Cause Analysis
Аппаратура, аппаратная
часть
Hardware
Базовая конфигурация
Configuration Baseline
Безопасность
Safety
Безопасность зон
(зонная/зональная
безопасность)
Zonal Safety
Валидация
Validation
Верификация
Verification
Взаимозаменяемость
Interchangeability
Оценка, базирующаяся на разложении на
простые элементы.
Установившийся термин, включающий в себя
анализ зон, анализ отдельных факторов риска и
анализ отказов, вызванных общими режимами.
Изделие, являющееся физическим объектом.
Термин, в основном, относится к сменным
блокам или модулям, печатным платам и блокам
питания.
Конфигурация, впервые установленная не
позднее этапа проектирования, при котором
впервые требуется наличие кредита/доверия для
проведения мероприятий по обеспечению
требуемого уровня проектирования. После
установления базовой конфигурации, должны
быть внедрены документированные процессы
контроля изменений.
Состояние, в котором величина риска ниже его
граничного значения. Граничное значение риска
является верхним пределом приемлемого риска.
Оно характеризует технический процесс или
состояние.
Безопасности, относящиеся к установке,
взаимному влиянию систем и возможным
ошибкам при техническом обслуживании.
Определение того, что требования к продукту
являются достаточно правильными и
корректными.
Оценка реализации требований с целью
доказательства того, что эти требования
удовлетворены.
Способность заменить одно изделие системы на
другое при сохранении соответствия
характеристик системы техническим
требованиям.
85
Авиарегистр МАК
Вид отказа
Failure Mode
Вылет с ограничениями
Time Limited Dispatch
Гарантия (обеспечение
гарантии)
Assurance
Гарантия проектирования
Development Assurance
Готовность
Availability
Демонстрация
Demonstration
Допущения
Assumtions
Единица/элемент
конфигурации
Configuration Item
Инспекция
Inspection
Интеграция,
комплексирование
Integration
Интенсивность отказов
Failure rate
Испытание, проверка, тест
Test
Р4754
Характер проявления отказа.
Методы, позволяющие вылет ВС при наличии
некоторых отказов, но с ограничением по
времени.
Запланированные и систематические
действия/мероприятия, для получения
достаточных доказательств того, что продукт
или процесс удовлетворяют заданным
требованиям (DO-178B).
Все запланированные и систематические
действия/мероприятия, подтверждающие с
приемлемым уровнем доверия, что ошибки
проектирования выявлены и устранены, так что
система удовлетворяет применяемому
сертификационному базису.
Вероятность того, что изделие находится в
работоспособном состоянии в заданный момент
времени.
Метод подтверждения характеристик путем
наблюдения функционирования (т.е. при
испытаниях или эксплуатации).
Формулировки, принципы и/или предположения,
используемые без доказательств.
Один или более элементов аппаратуры или
программного обеспечения, рассматриваемых
как единое целое (измененная формулировка
IEEE, SC-167, WG-5).
Проверка изделия на соответствие
определенному стандарту.
1. Действия, обеспечивающие совместное
функционирование элементов изделия.
2. Действия по объединению определённого
числа раздельных функций в единую
реализацию.
Характеристика, относящаяся к общему числу
эксплуатирующихся изделий и рассчитываемая
делением числа отказов на общую наработку.
Процедура количественной оценки
характеристик с использованием объективных
критериев в интересах получения результата:
86
Авиарегистр МАК
"Каскадный" отказ
Cascading Failure
Контроль изменений/
Контроль конфигурации
Change Control/
Configuration Control
Компонент
Component
Критичность
Criticality
Летная годность
Airworthiness
Надежность
Reliability
Независимость
Independence
Неправильное
Р4754
«прошел» - «не прошел».
Отказ, вероятность появления которого
значительно возрастает при наличии
предыдущего отказа.
1. Процессы документирования, оценки,
утверждения или отклонения и координации
изменений конфигурации изделия после её
формальной идентификации или те же процессы
по отношению к базовой конфигурации после их
установления.
2. Систематическая оценка, координация,
утверждение или отклонение, а также внедрение
одобренных изменений конфигурации изделия
после ее формального установления или те же
процессы по отношению к базовой
конфигурации после их установления (DO178B).
Любая автономная часть, совокупность частей,
сборка или блок, которая выполняет
определенную функцию, необходимую для
работы системы.
Показатель уровня опасности, относящийся к
функции, аппаратной части, программному
обеспечению и т.д., при рассмотрении их
ненормального поведения в отдельности или в
комбинации с внешними событиями.
Состояние авиационного изделия (ВС, системы
или их компонента), при котором это изделие
обеспечивает выполнение возложенных функции
безопасным образом.
Вероятность того, что изделие будет безотказно
выполнять требуемые функции в установленных
условиях в течение установленного периода
времени.
1. Концепция проектирования, при которой отказ
одной составляющей части не вызывает отказа
других составляющих частей (заимствовано из
JAR AMJ 25.1309).
2. Разделение ответственности, которое
обеспечивает выполнение объективной оценки.
Появление условий функционирования за
87
Авиарегистр МАК
функционирование
Malfunction
Непредусмотренная
функция
Unintended Function
Одобрение (утверждение)
Approval
Одобренный
Approved
Опасность
Hazard
Особый/специфический
риск
Particular Risk
Отказ
Failure
Отказ общего режима
Common Mode Failure
Отказное состояние
Failure Condition
Оценка
Assessment
Оценка безопасности
Р4754
установленными ограничениями/пределами.
Функция на уровне ВС, которая не
предусматривалась и не предполагалась при
предварительной оценке безопасности системы
(PSSA). Когда такая функция создает опасность
на уровне ВС или приводит к деградации
заданных функций, она считается существенной
при сертификации.
Акт формального одобрения сертифицирующим
органом.
Признанный сертифицирующим органом годным
для определенной цели (ИКАО).
Потенциально небезопасное состояние,
вызванное отказами, неправильным
функционированием, внешними ф или их
комбинацией.
Риск, связанный с такими событиями или
воздействиями, которые являются внешними по
отношению к рассматриваемой системе(ам) и
изделию(ям), но которые могут нарушать
требования независимости отказов.
Неспособность изделия выполнять возложенные
на него функции.
Событие, которое оказывает влияние
одновременно на ряд элементов, которые в
других случаях считаются независимыми.
Состояние, оказывающее непосредственное или
косвенное влияние на ВС и находящихся на
борту лиц, которое вызвано или усугублено
одним или несколькими отказами,
рассматриваемое с учетом неблагоприятных
эксплуатационных или окружающих условий.
С позиций летной годности гражданских ВС
отказные ситуации классифицированы по
степени серьезности их последствий в
параграфах FAA AC 25.1309-1A или JAR AMJ
25.1309.
Рассмотрение, базирующееся на экспертном
мнении инженеров
Систематическая и всесторонняя оценка
88
Авиарегистр МАК
системы
System Safety Assessment
Оценка функциональной
опасности
Functional Hazard
Assessment
Ошибка, погрешность
Error
Ошибка разработки
Design Error
Ошибка проектирования
Development Error
Поломка
Defect
Полномочный орган
(власть)
Authority
Применимые требования
Applicable Requirements
Принятие
Acceptance
Р4754
реализованной системы с целью доказательства
соответствия установленным требованиям
безопасности.
Систематическое и всестороннее исследование
функций ВС с целью выявления и
классификации их отказных состояний в
соответствии с их тяжестью.
1. Событие, происшедшее в результате
неправильного действия или решения, принятого
персоналом, эксплуатирующим или
обслуживающим систему (JAR AMJ 25.1309).
2. Ошибка в требованиях, при проектировании
или в реализации.
Ошибка в процессе разработки, вызванная либо
неправильным выбором методов, либо
неправильным применением методов или
информации.
Заблуждение в установлении требований или
разработке.
Состояние изделия, характеризующееся
невыполнением заданных требований к его
характеристикам. Поломка может, но не
обязательно, приводить к отказу.
Организация или лицо, ответственное в
государстве (стране) за сертификацию
соответствия применимым требованиям.
Примечание: Сертификация типа ВС, двигателя
или воздушного винта или одобрение
оборудования обычно выполняется
сертифицирующим органом (властью); вопросы,
касающиеся поддержания летной годности в
процессе эксплуатации, рассматриваются
службой летной годности (JAR 1).
Всесторонние и подробные требования ИКАО
для рассматриваемого класса ВС (См.
Приложение 8 к Конвенции ИКАО, Часть II, 2.2)
(Заимствовано из документов ИКАО).
Признание сертифицирующим органом того, что
представленные данные, доказательства
соответствия или эквивалентного соответствия
удовлетворяют применимым требованиям (По
89
Авиарегистр МАК
Р4754
материалам дискуссии в группе CAST).
Последствия отказа
Описание функционирования в результате
отказа.
Failure Effect
Предварительная оценка
Систематическая оценка предлагаемой
архитектуры системы и ее реализации,
безопасности системы
базирующаяся на оценке функциональных
Preliminary System Safety
опасностей и классификации отказных
Assessment
состояний, в интересах определения требований
безопасности для всех составляющих частей
архитектуры.
Программное обеспечение
Компьютерные программы, процедуры, правила
(ПО)
и любая связанная с ними документация,
относящаяся к работе компьютерной системы
Software
(по материалам SC-167,WG-4 и ISO 2382/1).
Продукт
Аппаратура, программы, изделие или система,
разработанные в соответствии с определенным
Product
набором требований.
Производные требования
Дополнительные требования, возникающие в
процессе проектирования на этапах разработки и
Derived Requirements
реализации. Производные требования не могут
быть напрямую трассированы к требованиям
верхнего уровня, но могут оказывать на них
влияние.
Процесс разработки
Процесс создания системы или изделия на
основе ряда предъявляемых требований.
Design Process
Реализация
Создание физического объекта по техническим
требованиям.
Implementation
Резервный, резервирующий, Многократные независимые объединенные
избыточный (в смысле
средства для выполнения заданной функции.
надежности)
Примечания:
Redundant
1. Различаются следующие принципы
построения резервированных архитектур:
• Сходное/однородное резервирование
(многократные средства одинаковы);
• Несходное/асимметричное резервирование
(применяются неодинаковые многократные
средства);
• Резервирование повторением (избыточность
обеспечивается повторением цикла работы).
2. По функционированию резервированные
архитектуры классифицируются:
90
Авиарегистр МАК
Руководящие указания
Guidelines
Сборка
Assembly
Сертификация
Certification
Р4754
• активный резерв (множество средств
используются постоянно и участвуют в
решении задачи);
• пассивный резерв (дополнительные средства
участвуют в решении задачи только в случаях
неправильного функционирования или
отказа);
• "горячий" пассивный резерв (дополнительные
средства всегда включены);
• "холодный" пассивный резерв
(дополнительные средства включаются только
в случае неправильного функционирования
или отказа).
Рекомендуемые процедуры обеспечения
соответствия регламентациям.
Несколько частей, узлов или комбинация их,
которые соединены вместе для выполнения
определенной функции и могут быть разобраны
без повреждения для дальнейшего
использования.
"Сертификация" означает юридическое
признание того, что продукт, служба,
организация или лицо соответствуют
распространяющимся на них требованиям.
Данная сертификация включает в себя действия
по технической проверке продукта, службы,
организации или лица и формальное признание
соответствия применимым требованиям путем
выдачи сертификата, лицензии, одобрения или
другого документа, предусмотренного
национальными законами и процедурами.
В частности, сертификация продукта включает:
a. Процесс оценки конструкции продукта, чтобы
гарантирующий его соответствие комплексу
стандартов, относящихся к данному типу
продукта, демонстрируя тем самым
приемлемый уровень безопасности.
b. Процесс оценки отдельных продуктов, чтобы
убедиться в том, что они соответствуют
сертифицированной типовой конструкции.
c. Выдачу сертификата, требуемого
национальными законами, чтобы подтвердить,
91
Авиарегистр МАК
Сертифицирующий орган
(сертификационная власть)
Certification Authority
Система
System
Сложность
Complexity
Совпадение
Conformance
Соглашение
Agreement
Соответствие
Compliance
Средняя наработка на отказ
Mean Time Between Failures
(MTBF)
Сходство (как
сертификационная
Р4754
что было выявлено соответствие с
применимыми стандартами согласно
приведенным выше пунктам (а) или (b).
(Директива Е.С., измененная группой CAST).
Организация или лицо, ответственные за выдачу
утверждающего документа по поручению
страны-изготовителя.
Комбинация взаимосвязанных изделий,
предназначенная для выполнения определенной
функции (WATOG).
Сложность является свойством систем или
изделий, которая затрудняет понимание их
функционирования. Повышенная сложность
систем часто вызвана применением сложных
компонентов или многочисленными связями в
системе.
Установление корректности с точки зрения
стандартов, спецификаций (технических
требований) или чертежей (По материалам
дискуссии в группе CAST).
Признание сертифицирующим органом, что план
или предложение, относящееся или
поддерживающее заявку на получение
одобрения на систему или образец
оборудования, является приемлемым заявлением
о намерениях с учетом применимых требований
(По материалам дискуссии в группе CAST).
Успешное выполнение всех обязательных
действий; соответствие ожидаемых или
заданных результатов с реальными
результатами.
Математическое ожидание промежутка времени
между двумя последовательными отказами
аппаратной части изделия.
Примечание: Данное статистическое
определение имеет смысл только для
ремонтируемых изделий. Для неремонтируемых
изделий используется термин "средний срок
службы".
Относится к системам, которые по своим
характеристикам и использованию подобны
системам, используемым на ранее
92
Авиарегистр МАК
стратегия)
Similarity (as a certification
strategy)
Технические требования
Specification
Трассируемость
(прослеживаемость)
Traceability
Требование
Requirement
Управление конфигурацией
Configuration Management
Р4754
сертифицированных ВС. В принципе
предполагается, что ни одна из частей
рассматриваемой системы не находится в
условиях более высокого риска (в связи с
окружающими условиями или установкой) и что
эксплуатационные нагрузки не являются более
тяжелыми, чем нагрузки на аналогичную ранее
сертифицированную систему.
Если ни одно из идентифицированных отказных
состояний рассматриваемой системы не
оказывает более серьезного влияния на
рассматриваемое ВС, чем те же отказные
состояния подобной системы на подобный ВС,
то утвержденный отчет о надежности подобной
системы может использоваться в качестве
доказательства соответствия с JAR
25.13О9(b)/FAR 25.13О9.
Совокупность требований, которые, в целом,
являются критерием, определяющим функции и
свойства системы или изделия.
Свойство, позволяющее связать требования
одного уровня проектирования с требованиями
другого уровня.
Идентифицированный элемент технического
задания, корректность и полнота которого может
быть подтверждена и, по отношению к которому
может быть проведена верификация реализации.
1. Процесс идентификации и определения
составляющих
элементов
конфигурации
системы, контроля выпуска документации и
внесения изменений в нее на протяжении
проектирования системы, документирования и
извещения о состоянии конфигурационных
единиц/элементов и требований по их
изменению, проверки полноты и корректности
элементов конфигурации.
2. Порядок на основе технических и
административных мероприятий управления и
надзора за:
a. Идентификацией и документированием
функциональных и физических характеристик
конфигурационных элементов,
93
Авиарегистр МАК
Целостность
Integrity
Р4754
b. Контролем изменения этих характеристик,
с. Обработкой записей и извещений об
изменениях, а также состоянием их выполнения
IEEE, SC-167 WG-5.
Свойство системы или изделия быть в состоянии
точно выполнять свои функции по требованию.
B.2. Сокращения и акронимы
Advisory Circular
(FAA)
Automatic Direction
ADF
Finding
Advisory Material Joint
AMJ
(JAA)
Airline TransportaATA
tion Assosiation
Air Traffic Control
ATC
Aviation Rulemaking
ARAC
Advisory Committee
(FAA)
Aerospace Recommended
ARP
Practice (SAE)
Avionic Systems Division
ASD
(SAE)
Certification Authority
CAST
Software Team (FAAJAA)
Common Cause Analysis
CCA
Dependence Diagram
DD
Distance Measurement
DME
Equipment
EUROCAE European Organization for
Civil Aviation Equipment
Federal Aviation
FAA
Administration
Federal Aviation
FAR
Regulations
AC
Рекомендательный циркуляр (ФАА)
Автоматический радиокомпас
Рекомендательный материал Норм
летной годности западной Европы
Ассоциация воздушного транспорта
Управление воздушным движением
Авиационный консультативный
комитет по разработке норм (ФАА)
Аэрокосмическая рекомендательная
практика
Отделение систем радиоэлектронного
оборудования (авионики)
Группа представителей
сертифицирующих органов по
программному обеспечению
Анализ общих причин отказов
Диаграмма зависимостей
Дальномерное оборудование
Европейская Организация по
оборудованию гражданской авиации
Федеральная Авиационная
Администрация
Федеральные Авиационные Правила
94
Авиарегистр МАК
FHA
FMEA
FMES
FTA
GPS
HW, H/W
ICAO
IEEE
ILS
JAA
JAR
MLS
MRB
MTBF
PSSA
RTCA
SAE
SC-167
SC-18O
Functional Hazard
Assessment
Failure Mode and Effect
Analysis
Failure Mode and Effect
Summary
Fault Tree Analysis
Global Positioning System
Hardware
International Civil
Aviation Organization
The Institute of Electrical
and Electronic Engineers,
Inc
Instrument Landing
System
Joint Aviation Authority
Joint Airworthiness
Requirements
Microwave Landing
System
Maintenance Review
Board
Mean time between
failures
Preliminary System Safety
Assessment
RTCA, Inc
Society of Automotive
Engineers, Inc
RTCA special committee
responsible for DO-178
RTCA special committee
responsible for preparing a
document (DO-254)
covering complex
hardware
Р4754
Оценка функциональных опасностей
Анализ видов и последствий отказов
Сводка видов и последствий отказов
Анализ дерева отказов
Глобальная навигационная система
Аппаратура, аппаратная часть системы,
изделия
Международная организация
гражданской авиации
Институт инженеров по электротехнике
и электроннике
Инструментальная система посадки
Объединенная авиационная власть
стран Западной Европы
Объединенные нормы летной годности
стран Западной Европы
Микроволновая система посадки
Бюро технического обслуживания
Средняя наработка на отказ
Предварительная оценка безопасности
системы
Радиотехническая комиссия по
аэронавтике
Общество инженеров транспорта
Специальный комитет RTCA по DO-178
Специальный комитет RTCA,
ответственный за подготовку документа
(DO-254), относящегося к сложной
аппаратуре
95
Авиарегистр МАК
SIRT
SSA
SW, S/W
TC
VOR
WG-#
WATOG
Systems Integration
Requirements Task Group
System Safety Assessment
Software
Transport Canada
Very high frequency
Omnidirectional Range
A numbered working
group (EUROCAE)
World Airlines Technical
Operation Glossary
Р4754
Специальная группа по разработке
требований к интеграции систем
Оценка безопасности системы
Программное обеспечение
Авиационный регистр Канады
Всенаправленный УКВ-радиомаяк, ВОР
Рабочая группа EUROCAE
Словарь терминов по технической
эксплуатации мировых авиакомпаний
96
Авиарегистр МАК
Р4754
ПРИЛОЖЕНИЕ C. ПЕРЕЧЕНЬ КОНЦЕПЦИЙ, ЗАДАЧ И ФУНКЦИЙ
х
х
х
х
х
х
х
Производство
Конструкция
х
Верификация
х
х
х
Реализация
Анализ
Архитектура
рассмотрение
выбор
Архивация и извлечение
Допущения/предположения
разработка
исходные
изготовление
серийное производство
условия эксплуатации
техническое обслуживание и ремонт
валидация.
Сертификация
координация
данные
план
планирование
процесс.
Контроль изменений
Проверки
полноты
правильности/корректности.
Анализ общих причин отказов
Соответствие,
согласование методов соответствия,
доказательство соответствия
Управление конфигурацией
идентификация
мероприятия процесса
цели процесса
Обеспечение гарантии проектирования
Система
Концепции,
задачи,
функции
Концепция
Этап разработки
х
х
8.4.2
х
5.4.1
5.1
9.2.3
х
х
х
Ссылка
на раздел
7.5.2
7.5.5
7.5.3
7.5.3
7.5.1
7.5.4
7.5
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
4.
4.4
4.4.1
4.1
4.
9.2.2
х
7.3
7.4
6.4
х
х
4.2
4.3
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
9.2.1
9.2
9.1
97
Авиарегистр МАК
Р4754
Реализация
Верификация
Производство
х
х
х
х
х
Конструкция
мероприятия
назначение уровней
значение
подтверждение
Назначение показателей риска опасных
состояний
Безопасность лётной эксплуатации
Назначение уровней аппаратной части
Осмотр и экспертная оценка
Безопасность технического обслуживания
Эксплуатационные ограничения
Предварительная оценка безопасности
системы
Извещения о проблемах
Гарантия процессов
очевидность
цели
план
Экспертные оценки плана проекта
Требования
дополнительные сертификационные
заданные
производные
функциональные
требования безопасности
типы
валидация
Процесс оценки безопасности
общая
системы
Опыт эксплуатации
Сходство
Назначение уровней ПО
Процесс проектирования системы
Испытания
Валидация
Система
Концепции,
задачи,
функции
Концепция
Этап разработки
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
3.2.1
5.4
3.2
3.2.2
5.5
6.5
5.4.3
8.4.1
6.5
4.1.2
6.2
х
х
Ссылка
на раздел
х
х
х
9.2.2
10.4
10.1
10.2
10.3
5.2.3
5.1
5.3
5.2.2
5.2.1
5.2
7
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
х
6
6.3
8.4.4
8.4.4
5.4.2
3.1
8.4.3
98
Авиарегистр МАК
Р4754
х
Производство
х
х
х
Верификация
Реализация
х
х
х
х
Конструкция
методы
модель процесса
цели процесса
рекомендуемые мероприятия
строгость оценки
Верификация
методы
планирование
модель процесса
цели процесса
рекомендуемые мероприятия
Система
Концепции,
задачи,
функции
Концепция
Этап разработки
Ссылка
на раздел
7.6.1, 7.6.2
7.2
7.1
7.6.2
7.6
х
х
х
х
х
х
х
х
х
8.4
8.3
8.2
8.1
8.4.5
99
Авиарегистр МАК
Р4754
ПРИЛОЖЕНИЕ D. РАСПРЕДЕЛЕНИЕ РИСКА ПРИ ПРОЕКТИРОВАНИИ
СИСТЕМ ВОЗДУШНЫХ СУДОВ
В данном приложении содержится дополнительная информация,
относящаяся к основным принципам распределения риска, принятым в
ARP4574/Р4754. Понимание этих принципов может облегчить их использование
в реальных условиях. Материал, представленный в приложении, получен при
подготовке данного документа и в процессе контактов с другими рабочими
группами и органами, занимающимися разработкой регламентирующих
документов, которые сталкиваются с аналогичными или сходными проблемами.
В настоящем документе признается, что распределение задач между
человеком и машиной, выбор архитектуры систем и распределение риска на
уровне ВС являются фундаментальными задачами для формирования системных
требований. Поскольку эти решения часто в значительной мере носят
субъективный характер, для выявления и подтверждения требований, к каждому
конкретному изделию и выдвигаемых этим изделием к системе, используется
процесс оценки безопасности системы. При таком подходе опыт эксплуатации
систем с различной архитектурой может использоваться для обоснования уровня
гарантии проектирования новой системы. В свою очередь, назначенный уровень
гарантии проектирования системы влияет на требования к уровням разработки
программного обеспечения и аппаратной части.
Первоначально на выбор подхода к распределению риска в
высокоинтегрированных и сложных системах повлияли работы, выполненные
специалистами по программному обеспечению при подготовке документа DO178B/КТ-178В. Хотя между разработкой программного обеспечения и
проектированием систем имеется много параллелей, существует и ряд
значительных различий. Области, в которых отмечаются эти различия,
рассмотрены в данном приложении.
D.1. Использование ресурсов
Проектирование высокоинтегрированной или сложной системы требует
значительных ресурсов, как со стороны разработчика, так и со стороны
сертифицирующего органа. Ресурсы, требуемые для достижения высокого уровня
жёсткости процессов проектирования, резко возрастают по мере увеличения
сложности системы или степени ее интеграции. В этих условиях решение о
реализации отдельного процесс проектирования уменьшает ресурсы, которые
могли бы использоваться для выполнения других процессов.
Решение о выборе наиболее приемлемого процесса проектирования
является, само по себе, сложным и для его принятия требуется взаимопонимание
и единая точка зрения разработчика и сертифицирующего органа. Опыт
показывает, что выбор наиболее приемлемого процесса меняется в широких
пределах для различных систем и для различных применений этих систем. Из
100
Авиарегистр МАК
Р4754
этого следует, что разнообразие процессов проектирования и методов
подтверждения соответствия является необходимым и обоснованным.
Действительно, без этого разнообразия не могут успешно и безопасно
развиваться ни методы, ни системы.
D.2. Архитектурная изолированность и независимость
Любая попытка достаточно убедительно показать только методом
испытаний, что в сложной или высокоинтегрированной системе отсутствуют
погрешности, быстро терпит неудачу с ростом сложности системы. В этих
случаях структурированные процессы, включая формальный контроль
системного проектирования, могут использоваться в качестве дополнительного
доказательства для поддержки осуществимого уровня испытаний. Основным
аспектом любого структурированного процесса проектирования является
формирование и валидация требований. Некоторые требования очень трудны для
валидации до реализации, когда всю систему можно будет испытать в реальных
эксплуатационных условиях. Исследования процессов разработки программного
обеспечения показали, что более половины программных ошибок вызваны
неправильной формулировкой или отсутствием требований, а также
неправильной их интерпретацией. Этот источник потенциальных ошибок следует
учитывать при поиске возможных альтернативных средств устранения таких
ошибок. На практике число известных альтернативных стратегий контроля
требований невелико. Эти стратегии, доказавшие свою эффективность, можно
отнести к одной или нескольким из следующих категорий:
a. Минимизация области влияния требований к отдельной системе (например,
параллельные системы, реализующие несходные функции),
b. Неукоснительное следование формальным методам валидации требований,
c. Обеспечение непрерывного контроля выхода системы с возможностью
«пересиливания» при условии, что работа устройства непрерывного
контроля не зависит от нормального функционирования системы ( например,
пересиливание системы пилотом или применение ограничителей сигналов
управления),
d. Максимизация числа требований высшего уровня, которые получены из
успешно эксплуатирующихся систем (например, эволюционный процесс
проектирования систем).
Эффективность
ограничения
влияния
ошибочных
требований,
обеспечиваемая различными системными архитектурами, является важным
фактором при выборе архитектуры сложных или высокоинтегрированных
систем.
В документе ARP4754/Р4754 указывается, что если выбранная архитектура
обеспечивает надлежащую изолированность одна часть системы от другой, а
функции, выполняемые этими частями, существенно независимы, то уровень
гарантии проектирования каждой части в границах архитектуры, определяется
101
Авиарегистр МАК
Р4754
последствиями отказов данной части системы. Ключом к успешному выбору
архитектуры для этой цели является определение адекватности и
существенности. Объективные и количественные методы определения этих
свойств отсутствуют, за исключением случаев простых систем. Поэтому
специалисты,
занимающиеся
проектированием
и
сертификацией
высокоинтегрированных и сложных систем, должны полагаться на инженерные
оценки при определении «надлежащего изолирования и существенной
независимости» в каждой системе.
D.3. Опыт эксплуатации
С начала 1980-х годов, когда в эксплуатацию были введены самолеты
Боинг 757, 767 и Эрбас А-310, промышленность накопила большой опыт
использования сложных бортовых систем, содержащих значительный объем
программ. Большая часть программного обеспечения разрабатывалась в
соответствии с требованиями уровня 2 (RTCA/DO-178A) и менее жесткими
требованиями. В то время как отдельные функции отказывали или выполнялись с
отклонениями вследствие ошибок в требованиях, практически не было ошибок к
отдельных требований, которые почти одновременно влияли на совокупность
несхожих функций. Например, информация, полученная от радионавигационных
или радиосвязных источников, может использоваться для обеспечения навигации
во многих районах земного шара. Полная потеря этой информации вызвал бы
отказное состояние, классифицируемое как сложное. На самолете, где основной
является радионавигация, потеря обоих типов радиостанций вызывал бы
аварийную ситуацию. Даже когда эти радиостанции работают в сходных
режимах, используют сходные компоненты и настроены на смежные диапазоны
частот, существует небольшая или практически не очевидная общая ошибка в
требованиях, влияющая одновременно на оба класса радиотехнических систем.
Возникновение одновременных отказов в ряде сменных блоков, имеющих
различную конструкцию, вызывалось общей физической причиной, такой как
отказ электропитания или системы охлаждения. Во многих ситуациях риск и
воздействие физических отказов, которые могли бы быть оценены
непосредственно анализом конструкции оборудования с привлечением
дополнительных затрат на управление высоко структурированным процессом
проектирования являются недопустимыми.
D.4. Интерпретация системных указаний DO-178B
В руководящих указаниях по разработке, содержащихся в DO-178B,
признается, что некоторые формы процесса системного проектирования будут
использоваться для выявления опасностей на самолётном уровне, вызванных
отказами функций, реализованных с помощью программного обеспечения. DO178B/КТ-178В разрабатывался ранее, чем APR4754/Р4754, поэтому, по
необходимости, он содержал в сжатой форме указания по разработке систем.
Например, в разделе 2.2.2 «Определение уровней программного обеспечения»
102
Авиарегистр МАК
Р4754
констатируется: «Выбор уровня программного обеспечения базируется на том
влиянии, которое оно оказывает на возникновение опасных состояний,
выявленных в процессе оценки безопасности системы». В разделе 2.3 DO178B/КТ-178В «Рассмотрение архитектур системы» отмечается, что если
«…архитектура системы препятствует возникновению наиболее серьезного
отказного состояния системы вследствие аномалий программного обеспечения,
то уровень программного обеспечения определяется наиболее жесткой
категорией остальных отказных состояний, вызванных аномальным поведением
программного обеспечения».
APR4754/Р4754 строится на этих концепциях и дает определённые
руководства по использованию архитектурных способов, таких как несходство,
для защиты от некоторых аномалий поведения программного обеспечения. В
обоих документах процесс оценки безопасности системы является средством
назначения уровня, который используется в процессе разработки программного
обеспечения.
В качестве другого примера рассмотрим формулировку DO-178B/КТ-178В:
«При параллельной реализации (функции), по крайней мере, один компонент
программного обеспечения должен иметь уровень, соответствующий наиболее
жесткой категории отказного состояния функции системы». APR4754/Р4754
уточняет указания для параллельной архитектуры, разъясняя, что в случае
раздельных каналов, использующихся для обеспечения избыточности при
реализации функции самолетного уровня, у которых подтверждены
независимость и несхожесть конструкции, применяемых технологий и
реализации, допустимо назначение этим каналам более низких уровней гарантии
проектирования по сравнению с уровнями идентичных каналов, реализующих ту
же самую функцию. Скрытое противоречие между этими двумя формулировками
разрешается последним предложением 2.2.3 DO-178B/КТ-178В, в котором
констатируется, что стратегии, которые отступают от указаний DO-178B/КТ178В, относящихся к системам, должны быть подтверждены в процессе оценки
безопасности системы. Указания ARP4754/Р4754 согласуются с этим
положением.
D.5. Заключение
Выбор архитектуры системы оказывает большое влияние на характер и
объем работ, необходимых для подтверждения соответствия сложных и
высокоинтегрированных систем требованиям норм. Опыт эксплуатации
предыдущих систем является жизненно необходимым для определения
приемлемости конкретной архитектуры для новой системы. Процесс оценки
безопасности системы представляет собой средство объединения объективных и
субъективных оценок, данных эксплуатации и результатов испытаний для того,
чтобы установить и обосновать соответствующий уровень гарантии
проектирования.
103