6.5.3. Классификация функций по категориям критичности
Критерии, используемые при сертификации цифрового оборудования и систем, основаны на значимости функций, выполняемых этим оборудованием или системами для безопасности полета. Ключевое значение при этом имеет влияние, оказываемое неисправностью или утратой функции, на безопасность. Описанные ниже категории критичности приняты авиационными специалистами и полномочными государственными органами, регулирующими авиационную деятельность. Существуют следующие категории критичности функций:
? критическая – к ней относятся функции, для которых возникновение любой опасной ситуации или проявление ошибки исключает безопасное продолжение полета и выполнение посадки;
• важная – к ней относятся функции, для которых возникновение любой отказной ситуации или ошибки снижает возможности летательного аппарата и уменьшает способность экипажа справиться с неблагоприятными условиями полета;
• не важная – к ней относятся функции, для которых отказы или ошибки не приводят к значительному ухудшению возможностей летательного аппарата или экипажа.
Классификация каждой функции осуществляется с использованием описания проекта, анализа, моделирования, метода аналогий, наземных и летных испытаний и пр.
Правильность выбора категории критичности подтверждается полномочным органом при разработке плана сертификации.
6.5.4. Требования и процедуры разработки программно-математического обеспечения
Общий подход учитывает три разновидности сертификации: сертификация типа, дополнительная сертификация типа, сертификация на соответствие стандартизированным требованиям FАА (рис. 6.7).
Процесс сертификации начинается с документа «Требования к системе». Затем разработчик определяет перечень работ, необходимых для проверки соответствия программно-математического обеспечения предъявляемым требованиям и для санкционирования его эксплуатационной пригодности (табл. 6.1). Рисунок 6.8 показывает, что разработка является итерационным процессом. Рисунок 6.9 иллюстрирует процесс разработки программно-математического обеспечения. На каждой стадии
разработки (для гарантии качества программно-математического обеспечения) выполняются проверки.
Таблица 6.1
Примечание:
(1) Слово «Требуется» означает необходимость представления доказательств выполнения данного вида работы.
(2) В таких случаях объем работ, связанных с проверкой соответствия предъявляемым требованиям и санкционированием эксплуатационной пригодности, зависит от тяжести последствий ошибки проектирования. Оценки тяжести последствий, данные разными полномочными государственными органами, могут отличаться одна от другой.
(3) Слово «Рекомендуется» означает, что, хотя представление доказательств выполнения данного вида работы не является обязательным, в соответствии с оправдавшей себя практикой это следует делать в установленном документами порядке.
(4) В ходе утверждения соответствия стандартизированным техническим требованиям FАА может оказаться необязательным проведение отдельных испытаний для санкционирования эксплуатационной пригодности системы.
Первым шагом в цикле разработки программно-математического обеспечения является формулирование требований к нему, которые определяют функции, реализуемые системой. Они могут касаться:
• функций, выполняемых программно-математическим обеспечением;
• степени критичности функций;
• взаимодействия аппаратуры и программно-математического обеспечения;
• характеристики используемого процессора;
• требований к временным характеристикам;
• требований к встроенному тест-контролю и непрерывному контролю;
• ухудшения характеристики и/или утраты функций в ситуациях отказа;
• требований к проверке.
Для гарантии полного учета и понимания требований к системе необходимо проведение соответствующего этапа поверочных работ, в процессе которого сопоставляются требования к программно-математическому обеспечению и требования к системе. Целью данной поверочной операции является:
• проверка совместимости разделения аппаратуры и программно-математического обеспечения на независимые части с методами и средствами организации взаимодействия этих частей;
• проверка совместимости требований к системе с требованиями к программно-математическому обеспечению;
• проверка того, что требования к системе, трансформированные в требования к реализации программно-математического обеспечения, исчерпывающим образом сформированы в основной документации на программно-математическое обеспечение.
При наличии полных требований к программно-математическому обеспечению с использованием соответствующих руководств, разрабатывается подробная проектная документация на программно- математическое обеспечение, в том числе план испытаний.
В правильно составленной программе разработки ПМО важное значение имеет установление такого порядка проектирования, который позволяет получить программно-математическое обеспечение, поддающееся проверке и понятное не только его создателям. Этот порядок должен быть документально оформлен. Одним из возможных методов проектирования является ограничение функций, реализуемых с помощью разделения в пределах отдельных блоков программы (принцип разделения программно- математического обеспечения). Особое внимание следует уделять
Рис. 6.8
Рис. 6.9
совместимости метода разделения и средств организации совместной работы отдельных блоков.
Для проверки полноты и качества проекта выполняется анализ его соответствия требованиям. Целью этой проверки является установление правильности воплощения в проектной документации требований к программно-математическому обеспечению, соблюдение стандартов на проектирование, гарантии того, что алгоритмы правильно представляют техническую идею, являются точными и устойчивыми.
Технология реализации проекта должна гарантировать, что полученные с ее помощью программы понятны, прослеживаемы до уровня проектной документации и поддаются проверке. Все ошибки должны быть зарегистрированы.
При реализации проекта ПМО большие преимущества сулят использование языков высокого уровня соответствующих компиляторов (трансляторов) и обеспечивающих программных средств. К числу этих преимуществ относятся облегчение понимания результатов реализации и потенциальная возможность снижения количества ошибок, допускаемых на ранних этапах разработки.
При изменениях обеспечивающих программных средств необходимы процедуры, позволяющие идентифицировать текущее состояние этих средств и проверить влияние любых изменений на конечную программу. В том случае, когда обеспечивающие программные средства разработаны не изготовителем оборудования, а другим предприятием, могут потребоваться консультации с государственным органом относительно методов установления доверия к этим средствам.
Для проверки результатов программирования получают листинг исходной программы. Проверка осуществляется либо вручную путем сквозного разбора программы с помощью таблицы контрольных проверок ошибок отдельных видов, либо с помощью таблиц истинности, либо автоматически с помощью анализаторов программ. Далее выполняется проверка блоков программы с целью показать, что блоки
