• содействие заказчику (потребителю) в компетентном выборе предприятий для размещения заказа на продукцию для государственных нужд и государственного оборонного заказа.
Эти цели достигаются:
• установлением статуса сертификата как государственного гаранта надежности продукции (в том числе поставляемой из стран ближнего и дальнего зарубежья);
• соответствием норм, правил и процедур сертификации международным требованиям;
• государственной поддержкой в обеспечении международного признания сертификата, в том числе на основе двусторонних и многосторонних межправительственных соглашений;
• ориентацией на максимальное использование имеющегося научно-технического и интеллектуального потенциала предприятий оборонного комплекса, что обеспечивает оптимизацию затрат на сертификацию;
• предоставлением органам государственного управления и заинтересованным организациям, предприятиям и частным лицам объективной информации о надежности продукции, стабильности и возможностях производства, необходимой для принятия решений о размещении государственных заказов, кредитования развития приоритетных направлений оборонного комплекса, инвестиционной поддержки конкурентоспособных предприятий и др.
Основу организационной структуры подсистемы надежности может составлять действующая организационная структура системы «Оборонсертифика» (см. п. 4.4).
6.5. Сертификация программно-математического обеспечения
6.5.1. Зарубежный опыт сертификации программно-математического обеспечения
В авиационной промышленности накоплен многолетний опыт конструирования, производства, монтажа и применения аналогового оборудования и систем, в том числе выполняющих в полете критические функции. Разработаны и успешно применяются методы и процедуры, позволяющие демонстрировать соответствие требованиям, предъявляемым полномочными государственными органами, регулирующими деятельность в области авиации. Согласно этим требованиям отказы в оборудовании и системах, выполняющих критические функции, не должны оказывать влияния на безопасность летательного аппарата.
В перспективе все большую долю будут составлять оборудование и системы, использующие цифровые вычислители. При этом качество программно-математического обеспечения (ПМО) будет непосредственно влиять на безопасность полетов. Таким образом, необходима разработка руководств по сертификации программно-математического обеспечения. За рубежом, и в первую очередь в США, накоплен значительный опыт сертификации цифрового бортового оборудования самолетов, представляющий значительный интерес для отечественных специалистов. Наиболее полно принципы сертификации авиационного бортового оборудования изложены в документах Радиотехнической комиссии США по аэронавтике (РТКА). Временный специализированный комитет, учрежденный исполкомом РТКА, пришел к заключению, что хотя стандарты РТКА и стандартизированные технические требования федерального авиационного управления (FAA) и охватывают в достаточной степени сертификационные требования и характеристики выполняемых функций, однако необходимо дополнительное руководство относительно требований к программно-математическому обеспечению. Временный специализированный комитет рекомендовал исполкому РТКА образовать специальный комитет, целью которого явилась бы разработка и оформление в виде документа практических методов, помогающих сертифицировать оборудование и системы, основанные на использовании программно-математического обеспечения. В 1980 г. был учрежден Специальный комитет «Математическое обеспечение цифрового радиоэлектронного авиационного оборудования».
Круг полномочий комитета включал в себя следующие вопросы:
• разработку плана проверки и демонстрации качества программно-математического обеспечения;
• разработку классификации требований при демонстрации качества программно-математического обеспечения по категориям, определяемым критичностью систем при выполнении полета;
• разработку информационного и конструктивного материала по программно-математическому обеспечению авиационного оборудования;
• выдачу рекомендаций относительно изменений существующих стандартов, необходимых для учета особенности применения цифровой техники;
• координацию деятельности с другими организациями.
6.5.2. План сертификации
Предполагается, что любая программа сертификации цифрового бортового оборудования или системы будет выполняться в соответствии с планом, подготовленным соискателем свидетельства о летной годности летательного аппарата и утвержденным полномочным государственным органом, регулирующим авиационную деятельность.
План должен охватывать:
• категорию критичности, применительно к которой должны быть сертифицированы оборудование или система;
• существо сертификации (сертификация типа, соответствие стандартизированным техническим требованиям и пр.);
• программы разработки, испытаний, сопровождения и гарантии качества программно-математического обеспечения;
• разделы нормативных документов, на соответствие которым будет проводиться сертификация;
• специальные условия;
• документацию, необходимую для сертификации.
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
совместимости метода разделения и средств организации совместной работы отдельных блоков.
Для проверки полноты и качества проекта выполняется анализ его соответствия требованиям. Целью этой проверки является установление правильности воплощения в проектной документации требований к программно-математическому обеспечению, соблюдение стандартов на проектирование, гарантии того, что алгоритмы правильно представляют техническую идею, являются точными и устойчивыми.
Технология реализации проекта должна гарантировать, что полученные с ее помощью программы понятны, прослеживаемы до уровня проектной документации и поддаются проверке. Все ошибки должны быть зарегистрированы.
При реализации проекта ПМО большие преимущества сулят использование языков высокого уровня соответствующих компиляторов (трансляторов) и обеспечивающих программных средств. К числу этих преимуществ относятся облегчение понимания результатов реализации и потенциальная возможность снижения количества ошибок, допускаемых на ранних этапах разработки.
При изменениях обеспечивающих программных средств необходимы процедуры, позволяющие идентифицировать текущее состояние этих средств и проверить влияние любых изменений на конечную программу. В том случае, когда обеспечивающие программные средства разработаны не изготовителем оборудования, а другим предприятием, могут потребоваться консультации с государственным органом относительно методов установления доверия к этим средствам.
Для проверки результатов программирования получают листинг исходной программы. Проверка осуществляется либо вручную путем сквозного разбора программы с помощью таблицы контрольных проверок ошибок отдельных видов, либо с помощью таблиц истинности, либо автоматически с помощью анализаторов программ. Далее выполняется проверка блоков программы с целью показать, что блоки выполняют заданные функции и не выполняют не заданные операции. Результаты этой проверки сводятся в «План испытаний программно-математического обеспечения». Проверка блоков проводится в двух направлениях: проверка логики и проверка вычислений.
Целью проверки логической части программы является обнаружение и устранение ошибок программирования, связанных с возможностью ненормального хода программы, а именно:
• остановом или зацикливанием;
• принятием неправильных логических решений;
• отсутствием логических операций с определенными комбинациями входных данных;
• отсутствием логических операций с пропуском входных данных.
Целью проверки вычислительной части программы является обнаружение и устранение ошибок в последовательности вычислений, их выполнении, точности, синхронизации; в правильности установки числовых алгоритмов в исходное положение для данных, находящихся в пределах технических условий, выходящих за эти пределы, граничных, особых; для масштабирования при вычислениях с фиксированной запятой и для используемых единиц измерения физических величин, а также в случае нежелательных режимов работы контуров с обратными связями.
После проверки блоков программы выполняется проверка правильности объединения блоков программы с целью показа правильности взаимодействия при выполнении заданных функций функционально связанных блоков программы. Эта проверка вовлекает дополнительные аппаратурные ресурсы, способствующие объединению модулей (периферийные устройства и память).
В ходе испытаний проверяются:
• связи между блоками (связь между блоками данных и управляющей логикой программы; порядок, вид и количество аргументов при обращениях к подпрограммам; отсутствие ложных выходов или нежелательных изменений в базе данных общего пользования);
• временная диаграмма;
• заданная последовательность событий (выставка и повторная выставка общих управляющих флажков; выставка переменных в исходное положение);
• возобновление вычислений при прерываниях;
• возможность нежелательных режимов работы контуров с обратными связями;
• разделение функций, имеющих различные категории критичности.
Для полной проверки в реальном масштабе времени соответствующее программное обеспечение вводится в смежный с аппаратурой или ее макетным образцом и другими внешними устройствами блок. К числу ошибок, выявляемых на стадии проверки совместного функционирования программного и аппаратурного обеспечения, относятся:
• неправильный уровень обработки прерываний;
• неспособность программного модуля удовлетворить требования к времени выполнения вычислений;
• неправильная работа программ, осуществляющих переключение аппаратуры или ее реконфигурацию в случае отказов;
• конфликтные ситуации в каналах передачи данных или при распределении ресурсов;
• отказ встроенного тест-контроля;
• неспособность программного обеспечения справиться с запуском, изменением входных нагрузок, переходными процессами в цепях питания;
• отказ выполнить проверку в контрольной точке;
• ошибки в организации взаимодействия аппаратуры и программно-математического обеспечения;
• ошибки в технических требованиях к такому взаимодействию.
Для проведения проверки совместной работы аппаратуры и программно-математического обеспечения используются:
• моделирование в реальном масштабе времени;
• контроль степени использования центрального процессора;
• анализ отказных режимов работы (сбои, переходные процессы и отказы в аппаратуре);
• введение в аппаратуру отказов;
• введение максимальных расчетных ограничений. Проверка совместного функционирования программного и
аппаратурного обеспечения состоит из:
• проверки в реальном масштабе времени функционирования общей программы, реализованной в реальном вычислителе или с использованием реальных устройств сопряжения;
• демонстрации того, что данная комбинация аппаратуры и программного обеспечения в условиях эксплуатации отвечает требованиям к программно-математическому обеспечению.
Испытания на воздействие окружающей среды являются необходимой частью сертификации любого оборудования и выполняются с целью демонстрации того, что аппаратура правильно функционирует в заданном диапазоне условий окружающей среды. Программное обеспечение, используемое при этих испытаниях, может быть как рабочим, так и специальным испытательным.
Испытания для санкционирования эксплуатационной пригодности системы выполняются после завершения всех проверок на соответствие предъявляемым требованиям и охватывают:
• демонстрацию соответствия системы требованиям в эксплуатационных условиях и при имитации изменения характеристик летательного аппарата в допускаемых пределах;
• демонстрацию соответствия системы предъявляемым требованиям в специфических условиях окружающей среды (например при электромагнитных помехах, переходных процессах и перерывах в электропитании и т. д.);
• летные испытания.
В испытаниях с целью проверки совместной работы, проводимых как часть испытаний для санкционирования эксплуатационной пригодности, должны быть выявлены ошибки в программно-математическом обеспечении следующих видов:
• неправильная реализация протоколов связей между элементами системы;
• непредвиденная неустойчивость контуров, замыкаемых между элементами системы;
• неспособность программно-математического обеспечения одного из элементов системы правильно функционировать при отказе другого элемента.
Требования пользователя изменить функциональные возможности системы и обнаруженные в процессе эксплуатации ошибки проектирования приводят к необходимости послесертифика-ционных изменений программно-математического обеспечения.
Изменения, внесенные в программно-математическое обеспечение критических и важных функций, требуют повторных проверок: программных блоков; их взаимодействия; взаимодействия аппаратуры и программного обеспечения; частей системы, затронутых внешними изменениями.
Изменения программно-математического обеспечения не важных функций могут быть внесены на основе анализа или повторных испытаний.
6.5.5. Сопровождение программно-математического обеспечения и вопросы гарантии качества
Сопровождение программно-математического обеспечения представляет собой специальную техническую дисциплину, связанную с идентификацией и контролем изменений и регистрацией текущего состояния программно-математического обеспечения в течение всего срока службы.
Сопровождением охватывается рабочее программное обеспечение, обеспечивающие программные средства, математическое обеспечение для испытаний и проектирования, а также аппара-тура, необходимая для внесения изменений в рабочее программ-ное обеспечение для его испытаний и воспроизведения.
Сопровождение включает также контроль документов, в ко-торых регламентируются требования к взаимодействию с про-граммами табличных данных и автоматического тест-контроля, выбираемыми пользователем, но сами эти программы под конт-роль данного сопровождения не подпадают, имея свое собствен-ное сопровождение.
Рассмотрение вопросов, связанных с сопровождением про-граммно-математического обеспечения, является частью каждо-го из этапов жизненного цикла изделия (табл. 6.2). Планы сопро-вождения программно-математического обеспечения (СПМО) и гарантии качества математического обеспечения (ГКПМО) мо-гут быть как раздельными, так и объединенными в единый доку-мент. План СПМО устанавливает содержание сопровождения (до-кументацию, ее контроль, контроль изменений уровня решений о внесении изменений) и порядок, которого изготовитель дол-жен придерживаться до сертификации головной партии серий-ных изделий или до их поставки предприятию-заказчику.
План ГКПМО описывает роль гарантии качества программ-но-математического обеспечения при выполнении требований и стандартов на его разработку, при выполнении плана ПМО и плана испытаний, а также в обеспечении соответствия матема-тического обеспечения документации на него.
В плане СПМО рассматриваются вопросы идентификации, контроля и учета текущего состояния, а также вопросы, связан-ные с ревизиями и проверками состава и общего построения про-граммных и аппаратурных средств.
В плане СПМО должны быть определены минимальные тре-бования к сопровождению для каждого применения оборудова-ния. На основании этого плана изготовитель должен разработать соответствующую документацию и хранить ее в течение всего жиз-ненного цикла оборудования.
План ГПМО определяет технические средства, приемы и ме-тоды, которых необходимо придерживаться при производстве ре-визий и проверок качества, а также при выполнении других фун-кций, гарантирующих целостность изделия и соответствующей документации на него, а также непрерывность процесса сопро-вождения.
СПМО на этапе сертификации и в течение всего периода эк-сплуатации изделия должно предусматривать наличную докумен-
тацию; соглашение относительно маркировки изделия, контроля изменений, учета текущего состояния.
На внешней стороне каждого сменного блока должна быть нанесена маркировка в виде блочного номера. В системе нумерации должны быть воплощены следующие принципы:
• сменные блоки с одинаковой маркировкой должны быть взаимозаменяемыми по габаритам, посадочным размерам и выполняемым функциям;
• если в конструкцию блока или в его программно-математическое обеспечение внесено изменение, блочные номера таких блоков и блочные номера блоков более высоких уровней должны быть изменены вплоть до уровня, на котором восстанавливается взаимозаменяемость. Контроль действительного текущего состояния, осуществляемый пользователем, не обязательно должен быть основан на системе нумерации блоков, принятой у изготовителя.
Если используется маркировка статуса состояния блока, то в каталогах комплектации блоков и систем могут даваться ссылки без указания статуса модификации, однако в этих каталогах должна быть ссылка на журнал регистрации статуса модификации.
На каждое устройство заранее программируемой памяти, входящее в состав блока, должна быть нанесена маркировка, позволяющая установить состояние его аппаратурного и программного обеспечения. Если память сменного блока загружается на месте, то идентификатор состояния может быть вызван из самой памяти и проидентифицирован.
В устройства заранее программируемой памяти должны быть введены идентификаторы программно-математического обеспечения, доступные для других частей системы, для аппаратуры автоматического тест-контроля и для другой поверочной аппаратуры, необходимые при выполнении экипажем эксплуатационных процедур. В одном и том же блоке могут быть предусмотрены вариации программных функций.
Изменения в программно-математическом обеспечении могут считаться незначительными при условии, что они не затрагивают основу первоначальной сертификации критических функций или любые аспекты, связанные с выполнением обязательных функциональных требований.
Изменение программно-математического обеспечения, не затрагивающее функциональную взаимозаменяемость, требует:
• изменения маркировки статуса программно-математического обеспечения;
• введения в блочный номер соответствующего подномера;
• изменения идентификатора программно-математического обеспечения, вводимого в память модифицированного запоминающего устройства;
• внесения изменений в журнал регистрации состояния блока.
Изменение программно-математического обеспечения, приводящее к нарушению функциональной взаимозаменяемости, требует введения нового опознавательного номера программно-математического обеспечения блока или нового идентификатора в память модифицированного запоминающего устройства. Изменение в документации на программно-математическое обеспечение блока отражается в конечной части номера соответствующей документации, отделенной от головной части номера с помощью тире. Изменение в программно-математическом обеспечении вспомогательного оборудования требует только изменения документации.
С помощью приведенных ниже примеров показываются некоторые способы, позволяющие вставить обозначение варианта программного обеспечения в блочный номер.
Таблица 6.3 иллюстрирует требования к изменению маркировки аппаратурного/программного обеспечения после выполнения их доработок.
В данном примере требования к маркировке конкретного блока удовлетворяются с помощью комбинации блочного номера, обозначающего основной вариант конструктивного выполнения блока и номера варианта рабочего программного обеспечения блока. Любые доработки, не затрагивающие взаимозаменяемость, обозначаются с помощью двух указателей вариантов модификаций – одного для аппаратуры и одного для программного обеспечения.
Проведем расшифровку значения блочного номера, показанного в табл. 6.3. Номер блока, указанный на его внешней поверхности:
Вариант модификации, указанный на внешней поверхности блока и в журнале регистрации состояния блока: аппаратуры – 03; программного обеспечения – 06.
Опознавательный номер комплекта документации, указываемый только в каталоге комплектации: 503.
Блочный номер, указанный в каталоге комплектации:
СПМО действует в течение всего периода существования оборудования или системы, но ответственность за его выполнение может передаваться.
Производитель оборудования отвечает за СПМО до поставки изделия пользователю, он же продолжает сопровождение в течение всего срока существования оборудования.
Пользователь может взять на себя сопровождение своего оборудования. Одним из наиболее важных средств, позволяющих создать качественное и надежное программно-математическое обеспечение, является проверка его соответствия требованиям на ранних этапах разработки изделия путем выполнения серии
Таблица 6.3
проверок и ревизий в ключевых точках процесса разработки изделия и внесения в него изменений.
Такое определение указанных проверок и ревизий, их график и последовательность проведения приводятся в плане гарантии качества программно-математического обеспечения (ГКПМО).
Для критических функций устанавливается система официальных сообщений о недостатках, обнаруженных в математическом обеспечении и мерах по их устранению. Такая же система желательна и для функций других категорий. Указанная система должна гарантировать ответные действия на все документально зафиксированные недостатки.
В план СПМО и гарантии его качества должны быть включены положения о контроле носителей программно-математического обеспечения. Со всех оригиналов, действующих документов, записей исходных и объектных программ, программ для проведения проверок и испытаний, программ вспомогательных систем должны быть сняты копии, хранящиеся в отдельных архивах с соблюдением мер предосторожности.
Для гарантии целостности хранимых данных устанавливается порядок апробации всех лент, дисков и т. п. с периодичностью, совместимой с гарантийным сроком хранения данного носителя. При создании оригиналов и архивных документов следует предусмотреть меры предосторожности, гарантирующие только считывание хранимой информации. Каждый процесс снятия копии должен проверяться с помощью побитового сравнения. На каждом носителе следует записать алгоритмы, предназначенные для проверки правильности компиляции, копирования или загрузки.
6.5.6. Документация на аппаратное/программное обеспечение
Для первоначальной сертификации оборудования или системы, а также для их повторной сертификации после модернизаций, необходима достаточная, точная и отражающая текущее состояние дел документация двух видов (табл. 6.4 и 6.5).
В табл. 6.4 (с разбивкой по категориям критичности: НВ – не важная, К – критическая) указана документация, которую изготовитель должен подготовить для первоначальной сертификации типа, дополнительной сертификации типа или для утверждения оборудования (например утверждения соответствия стандартизованным техническим требованиям FАА). В этой таблице знаком «Д» отмечены документы, которые соискатель удосто
Таблица 6.4
верения летной годности может направить органу, регулирующему деятельность в области авиации в качестве официально зарегистрированных материалов, обосновывающих заявку. Знак «А» обозначает дополнительную документацию, которая может быть сочтена в плане сертификации необходимой для какого-либо конкретного случая.
Каталог комплектации (документ № 1) является основным контрольным документом для каждой самостоятельной версии программно-математического обеспечения. В нем (в хронологическом порядке) даются ссылки на все документы, находящиеся под контролем, осуществляемым в рамках сопровождения, и указывается статус каждого из них на данный момент времени.
Для цифровых систем каталог комплектации системы является регистрационным документом высшего уровня. В нем содержатся наименования блоков аппаратуры, номера всех сменных блоков, входящих в состав системы, и номера программно-математического обеспечения всех сменных блоков, имеющих таковое. В нем также дан перечень каталогов комплектации всех сменных блоков системы.
Каталог комплектации системы может разрабатываться изготовителем оборудования или предприятием, осуществляющим его установку.
Каталог комплектации сменного блока описывает его аппаратуру и его программно-математическое обеспечение. Он подготавливается разработчиком оборудования для каждого сменного блока, имеющего программно-математическое обеспечение. В его содержании указывается:
а) точный состав и построение объединенного пакета программно-математического обеспечения, поставляемого вместе с блоком;
б) перечень действующей документации на данный сменный блок.
В требованиях к программно-математическому обеспечению (документ № 2), разрабатываемому предприятием, осуществляющим установку оборудования, или предприятием-разработчиком, должна содержаться (но не обязательно ограничиваться приведенным перечнем) следующая информация:
а) функциональные и эксплуатационные требования к программно-математическому обеспечению, сформулированные в количественной форме и там, где это применимо, с указанием допусков; общий и описательный материал, включающий функциональную блочную схему или эквивалентное предоставление каждой машинной программы; графическое изображение процесса выполнения функции и связей между функциями;
б) требования к каждой рабочей функции или режиму работы плюс требования к таким специальным функциям, как упорядочение, выявление и устранение ошибок, контроль входной и выходной информации, диагностика в реальном масштабе времени и т. д.;
в) требования к характеристикам, проверке, проектированию и критичности каждой функции;
г) требования к ресурсам памяти и временным ресурсам;
д) описание взаимодействия аппаратуры и программного обеспечения;
е) требования к встроенному тест-контролю или непрерывному контролю;
ж) характеристики при отказах (ухудшение характеристик и качество функционирования).
Описание построения программно-математического обеспечения (документ № 3), разрабатываемого изготовителем оборудования, содержит:
а) описание структуры построения программы (древовидную схему) и членение программы на самостоятельные части;
б) описание или схему потока данных;
в) описание или блок-схему программы;
г) описание информационного и управляющего взаимодействия между отдельными частями программы и между программным и аппаратурным обеспечением (описание отдельных трактов «вход-выход»);
д) описание алгоритмов;
е) технические условия на временные ресурсы;
ж) информацию об организации и ресурсах памяти. Назначением руководства для программистов (документ № 4) является изложение информации, достаточной для понимания принципов работы и для программирования вычислителя, используемого в бортовом оборудовании. Эта информация должна включать полное описание архитектуры (работу системы команд), а также описание и руководство по применению языка программирования. Допускается, что для выполнения программирования вычислителя может оказаться необходимой информация о структуре программы и взаимодействии ее частей, содержащаяся в документе № 3 и других документах.
Для гарантии функционирования изделия в соответствии с техническими условиями в плане сопровождения ПМО и гарантии его качества (документ № 5) дается описание:
а) процедур сопровождения;
б) обозначений вариантов построения программно-математического обеспечения;
в) порядка учета текущего состояния вариантов построения программно-математического обеспечения;
г) процедур контроля изменений в программном обеспечении;
д) процедур контроля носителей программ;
е) средств и методов, используемых при разработке программно-математического обеспечения;
ж) стандартов, установившейся практики и соглашений, используемых при разработке программно-математического обеспечения;
з) документации, необходимой для разработки программно-математического обеспечения;
и) процедур выполнения проверок и ревизий;
к) процедур составления и прохождения донесений о выявленных недостатках и процедур устранения недостатков;
л) процедур контроля, осуществляемого поставщиком изделия.
Листинг исходной программы (документ № 6) содержит исходные операторы, по которым составляется машинная программа с комментариями для описания модулей, функций и управляющей логики программы. Листинг должен содержать блочный номер программы, ее наименование и дату выпуска. В комплектацию данного документа должен быть включен листинг редактора связей распределителя памяти, дающий схему загрузочного модуля.
Для исходной программы (документ № 7) следует использовать согласованный носитель – бумагу, магнитные диски, ленты и т. п.
Для выходной (объектной) программы (документ № 8) следует использовать согласованный носитель-ленту, магнитные диски, программируемое постоянное запоминающее устройство (ППЗУ), перфокарты и т. д.
Состав и построение системы вспомогательных средств и средств для разработки программно-математического обеспечения (документ № 9) описывают аппаратуру, программное обеспечение и процессы, используемые для разработки, хранения и воспроизведения исходных и объектных программ.
Краткий обзор выполненных работ (документ № 10, на контроль не передается) представляет краткое описание задач, решенных в процессе разработки программно-математического обеспечения и плана его сопровождения. К числу вопросов, рассматриваемых в обзоре, относятся описание системы, порядок проектирования, испытания и контроль.
План, методики и результаты испытаний (документ № 11) могут быть составлены применительно к разным этапам испытаний и описывать испытания, которые должны быть выполнены; цель каждого из них; функции, которые должны быть проверены; последовательность и методы испытаний. Эти документы также охватывают средства проверки на соответствие требованиям и средства, используемые при санкционировании эксплуатационной пригодности; требования к поверочному оборудованию; требования к испытаниям программно-математического обеспечения и результаты испытаний.
Стандарты на проектирование программно-математического обеспечения (документ № 12), разрабатываемые изготовителем оборудования или предприятием, осуществляющим его установку, определяют требования на проектирование программно-математического обеспечения и его реализацию, действующие соответственно на этапах разработки и испытаний. В нем также описываются запрещенные способы реализации программно-математического обеспечения, применение которых могло бы повредить выполнению функций, предписанных системе.
В требованиях к системе (документ № 13) дается общее описание сертифицируемой системы. Документ может исходить или от предприятия, осуществляющего установку оборудования, или от предприятия-изготовителя. Он должен содержать:
а) описание системы и ее функциональную блок-схему, разбиение системы на сменные блоки, описание сертифицируемых функций;
б) сертификационные требования, включая все применимые положения Федеральных авиационных правил (FAR), консультативных циркуляров FАА, требования Британского управления гражданской авиации и требования других нормативных документов. Дополнительно (если система, выполняющая сертифицируемую функцию, является элементом системы более высокого уровня) необходимо дать ссылку на требования к этой последней или их краткое изложение;
в) методы и средства проверки соответствия, позволяющие:
• завершить программу разработки, выполняемую поставщиком изделия;
• завершить программу проверки соответствия требованиям, проводимую предприятием, устанавливающим оборудование;
• обнаружить и устранить ошибки программирования;
• разработать документацию.
В табл. 6.5 приведена документация, которую изготовитель должен (в соответствии с соглашением, достигнутым в результате переговоров) представить пользователю, желающему взять на себя ответственность за совершенствование и доработку оборудования или систем.
Здесь установлены три категории пользователей.
Категория «X». Пользователи этой категории только эксплуатируют оборудование и не имеют возможности ремонтировать его. Ремонт и (или) доработка выполняются ремонтной базой или изготовителем.
Категория «Y». Пользователи этой категории могут эксплуатировать оборудование, а также выполнять его установку и/или ремонт. Это типично для авиатранспортных компаний, ремонтирующих свое собственное оборудование, или для ремонтных баз, имеющих официальное разрешение и продающих свои услуги пользователям категории «X». Пользователи категории «Y» могут
Таблица 6.5
выполнять доработки по документации изготовителя аппаратуры, одобренные государственным органом, регулирующим авиационную деятельность.
Категория «Z». Пользователи этой категории эксплуатируют, устанавливают и ремонтируют оборудование, а также имеют возможность модифицировать его. Это типично для крупных авиатранспортных компаний, имеющих достаточно квалифицированный инженерный персонал и материальную базу для разработки модификаций, получения их утверждения со стороны полномочного государственного органа, а также для выполнения ремонта и доработок по документации изготовителя оборудования.
Изготовитель должен определить, для пользователя какой категории создается изделие и степень критичности его применения. Затем он должен определить объем работ по созданию документации. Аналогично предприятие, осуществляющее установку оборудования, определяет требования к документации на основании конечного применения изделия и степени критичности этого применения. Затем инструктивный материал данного документа служит основой для ведения переговоров относительно окончательных требований к документации.