Квалификационные требования кт-178b

Практикум по разработке программного обеспечения в соответствии с требованиями КТ-178В

Квалификационные требования КТ-178B – российский аналог документа RTCA/DO-178B «Software considerations in airborne systems and equipment certification».

Заключение о соответствии программного обеспечения требованиям КТ-178B является обязательным при сертификации комплектующих изделий авиационного оборудования в Авиационном Регистре МАК.

Сложность документа КТ-178В и отсутствие конкретных практических рекомендаций в совокупности с отсутствием достаточного опыта разработки программного обеспечения по «тяжелым» процессам приводит к тому, что большинство компаний сектора авиационного строительства сталкиваются с проблемой самостоятельного внедрения процессов разработки ПО в соответствии с КТ-178B. Этот процесс сложен, трудоемок, и, как следствие, требует значительных финансовых затрат.

ДС БАРС предлагает компаниям-производителям авиационного оборудования уникальный учебный курс «Практикум по разработке программного обеспечения в соответствии с требованиями КТ-178B», аналогов которому на рынке сейчас нет. Создание этого курса стало возможным, благодаря большому опыту работы наших специалистов в проектах с ведущими западными компаниями по разработке и верификации программного обеспечения в соответствии с требованиями DO-178B.

Участие в практикуме даст специалистам вашей компании возможность:

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

Практикум основан на специализированном тренировочном проекте и включает:

лекционный курс, дающий представление о процессах разработки бортового ПО;
практическое освоение процесса управления конфигурацией ПО;
участие в процессах разработки и верификации требований к ПО;
практическое освоение мероприятий рассмотрения и анализа;
знакомство с процессами разработки описания проекта ПО и исходного кода;
участие в процессе разработки тестов и их выполнение на целевом вычислителе;
знакомство с мероприятием анализа структурного покрытия кода.

Каждый блок практикума будет предваряться лекцией, на которой наши тренеры-консультанты расскажут о роли соответствующего процесса разработки в общем процессе создания ПО.

Курс рассчитан на специалистов российских компаний авиационной отрасли: инженеров-программистов, системных инженеров и участников проектов по сертификации программного обеспечения.

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

На период проведения курса мы предоставляем следующие материалы:

план управления конфигурацией ПО;
план разработки ПО;
план верификации ПО;
стандарт на разработку требований к ПО;
стандарт на проектирование ПО;
стандарт на кодирование ПО;
презентации по процессам КТ-178В, которые включают в себя:
- общую информацию о целях соответствующего процесса разработки;
- oпримеры методов достижения целей, описанных КТ-178В;
- oтипичные ошибки при реализации методов достижения целей КТ-178В;
базовую версию ПО, включающую требования, описание проекта, исходный код, модульные и интеграционные тесты.

Стоимость курса можно уточнить по телефону: +7 (495) 942 6610 или отправив заявку на участие.

Проведение курса возможно как на территории ДС БАРС, так и на базе компании-заказчика.

Бортовое программное обеспечение самолета

Основное назначение нормативных документов и стандартов — изложение инструктивных материалов для использования в процессах создания ПО авиационных бортовых систем, которые должны выполнять надлежащие функции с уровнем доверия к безопасности, удовлетворяющим требованиям к летной годности ВС.

Среди международных нормативных документов, содержащих требования к ПО АТ, важнейшим является документ DO-178, впервые сформулированный в 1978 г. В настоящее время используются его усовершенствованные варианты: DO-I78A, действующий с 1985 г., и DO-I78B, действующий с 1993 г., в котором значительное внимание отводится вопросу квалификации инструментального программного обеспечения.

В Украине и России действуют аналоги этих документов: соответственно КТ-178А с 1998 г. и КТ-178В с 2004 г. Дополнениями к этим квалификационным требованиям служат документы РМ-178А и РМ-178В.

Среди стандартов серии ISO, действующих в Украине и относящихся к ПО, главное место занимают два: ДСТУ ISO 9000-3-98 и ДСТУ 3918-1999 (ISO/IEC 12207:1995). Первый посвящен организации и мероприятиям системы качества применительно к ПО, второй процессам ЖЦ ПО. Требования стандартов ISO связаны непосредственно с процедурами сертификации ВС и его компонентов, включая процедуры сертификации ПО.

Кроме этого, при сертификации предприятий авиационной промышленности, в данном случае производственных процессов создания и применения ПО, используется документ АРМАК «Руководство 21.2С», а именно раздел «Элемент 3. Гарантия качества программного обеспечения», который подразделяется на две части: «Часть А. Бортовое ПО» и «Часть Б. ПО для приемки изделий».

К бортовому ПО относится ПО тех электронных систем ВС, которые входят неотъемлемой частью в сертификационный базис ВС определенного типа и установлены на его борту с целью выполнения необходимых для эксплуатации ВС функций. ПО систем, предназначенных, например, для проведения испытаний ВС, хоть и установлено на борту ВС, не является бортовым, а относится к инструментам процессов создания АТ.

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

Критичность функциональных бортовых систем и уровень программного обеспечения. Главная цель процедур сертификации — это, прежде всего, получение определенных гарантий безопасности: предотвращение смерти, телесных повреждений, ухудшения здоровья людей, потери собственности. Началом работ по сертификации ПО любой сложной технической системы является анализ возможных последствий влияния потери (нарушения) функции системы на безопасность ее работы или использования для человека и собственности. Причем не имеет значения, чем вызвано нарушение функции — ошибкой пользователя, отказом аппаратуры или ошибками проектирования ПО. Важными являются глубина контроля системы, выявление и возможность парирования отказов средствами самой системы или системы более высокого уровня иерархии, необходимость резервирования, реконфигурации. К анализу следствий нарушения функции системы, как правило, приходится возвращаться неоднократно после следующих этапов, так как от правильного определения категории критичности системы зависит жесткость требований к ПО.

Документ КТ-178В определяет пять категорий критичности функциональных систем и соответственно пять уровней ПО. Несмотря на то, что по определению категории критичности системы и уровни ПО жестко связаны, процедура установления уровней допускает отклонения как в одну, так и в другую сторону.

Классификация уровней программного обеспечения по категориям критичности следующая:

ПО уровня А — ПО такой функциональной системы, отказное состояние которой, возникшее из-за ошибки в ПО, может привести к катастрофической ситуации для ВС, когда практически невозможно предотвратить гибель ВС и людей. Вероятность возникновения такой ситуации на один час полета должна быть практически невероятной, т. е. меньше чем 10

ПО уровня В ПО такой функциональной системы, отказное состояние которой, возникшее из- за ошибки в ПО, может привести к аварийной ситуации для ВС. Аварийная ситуация характеризуется значительным ухудшением характеристик ВС или превышением его предельных ограничений, а также таким физическим напряжением летного экипажа, при котором он не может точно и полностью выполнить свои функции. Аварийная ситуация может привести к значительным повреждениям ВС, травмам людей или отдельным жертвам. Вероятность возникновения такой ситуации на один час полета должна быть крайне маловероятной, т. е. быть в диапазоне 10 М0

ПО уровня С — ПО такой функциональной системы, отказное состояние которой, возникшее из- за ошибки в ПО, может привести к сложной ситуации для ВС. Сложная ситуация характеризуется заметным ухудшением характеристик ВС, выходом одного или больше параметров за эксплуатационные ограничения, но без достижения предельных ограничений, а также уменьшением способности экипажа справится с этой ситуацией из-за увеличения рабочей нагрузки и по причине появления неблагоприятных условий, которые снижают эффективность действий экипажа. Сложная ситуация может вызвать дискомфорт пассажиров, включая, возможно, травмы. Вероятность возникновения сложной ситуации на один час полета должна быть маловероятной, т. е. быть в диапазоне 10 5-10-7;

ПО уровня D — ПО такой функциональной системы, отказное состояние которой, возникшее из-за ошибки в ПО, может привести к усложнению условий полета для ВС. Такая ситуация характеризуется незначительным ухудшением характеристик ВС или небольшим увеличением рабочей нагрузки на экипаж. Такую ситуацию можно предотвратить, например, путем изменения плана полета, а для пассажиров она должна приводить не более, чем к некоторым неудобствам;

ПО уровня Е — ПО такой функциональной системы, отказное состояние которой, возникшее из-за ошибки в ПО, не влияет на эксплуатационные возможности ВС и не увеличивает нагрузки на экипаж. Получение от сертификационного органа подтверждения того, что данное ПО принадлежит к уровню Е, означает, что к нему не применяются положения документа КТ-178В.

Документ КТ-178А определяет три категории критичности функций бортовых авиационных систем:

существенную, если особая ситуация, которая может возникнуть при нарушении выполнения хотя бы одной из функций системы ВС, характеризуется как катастрофическая или аварийная;

важную, если особая ситуация, которая может возникнуть при нарушении выполнения хотя бы одной из функций системы ВС, относится к сложной;

несущественная, если особая ситуация, которая может возникнуть при нарушении выполнения хотя бы одной из функций системы ВС, относится к усложнению условий полета или не имеет последствий.

Соответственно существуют три уровня программного обеспечения:

уровень 1 для категории «критическая» с наиболее высокими требованиями к ПО и максимальным объемом работ, выполнение которых необходимо для доказательства соответствия сертификационным требованиям, и максимальным количеством сопроводительной документации;

уровень 2 — для категории «существенная» с более низкими требованиями;

уровень 3 — для категории «несущественная» с минимальными требованиями.

Уровень ПО зависит не только от категории критичности функции. Немалую роль играют архитектура системы и структура ее программного обеспечения. Например, анализируемая система может иметь резервный аналоговый канал, который целиком дублирует функции цифрового канала. В определенных условиях этого может быть достаточно для снижения уровня ПО. И, наоборот, в случае, когда на одном ВС анализируемая система используется таким образом, что ее отказ отвечает одной категории критичности, а на другом ВС отказ этой же системы приводит к более критическим условиям эксплуатации, разработчик системы может определить более высокий уровень ПО. Важное влияние на определение уровня ПО имеют также методы его проектирования. Напри мер, метод обособления или контроля как метод зашиты от конкретных отказных состояний путем непрерывной проверки правильности выполнения функции, или много-версионный метод, реализация которого предусматривает создание двух или больше компонентов ПО, выполняющих одну функцию разными способами и разным ПО, дает возможность отделить функционально независимые компоненты ПО с целью изоляции отказов.

Упомянутые выше количественные значения вероятности возникновения особых ситуаций не касаются вероятности не выявленных ошибок в ПО. К ПО невозможно применить развитый математический аппарат теории статистики, который лает возможность рассчитывать вероятность событий, так как нет прямой связи между вероятностью возникновения особых ситуаций и вероятностью не выявления ошибок в ПО. Таким образом, уровни ПО или показатели его надежности, основывающиеся на уровнях ПО, не могут быть использованы в процессе оценки безопасности системы, например, так, как используется интенсивность отказов аппаратного обеспечения.

Тем не менее, нормативные документы рекомендуют применять те или другие количественные критерии оценки качества ПО или достижения определенного уровня качества с учетом того факта, что индустрия программных средств накопила большую коллекцию моделей и метрик, которые позволяют оценивать разные характеристики ПО. Больше того, во время разработки и верификации ПО настоятельно рекомендуется вести учет выявленных ошибок и недостатков ПО, а также принятых мер по их устранению.

Процессы разработки, верификации и аттестации программного обеспечения

Главным этапом при создании любого технического продукта является его разработка, включая изготовление опытного образца, его испытания для подтверждения соответствия требованиям и, в конце концов, официальное утверждение его эксплуатационной пригодности. Создание программного продукта полностью соответствует этим процессам.

Приведены процессы создания программного продукта, интересные с точки зрения получения определенных гарантий безопасности. Здесь каждое мероприятие, связанное с разработкой (Р) имеет соответствующее верификационное мероприятие (В). И те, и другие порождают соответствующие документы (Д).

Исходным материалом для инициации процессов создания ПО являются заявленные требования к системе, которые должны быть оформлены в виде соответствующего документа (ДФ ), и которые необходимо преобразовать в требования к ПО (Д1), именно в связи с тем, что реализация функций цифровых электронных систем, как уже отмечалось, осуществляется программными средствами. Процесс разработки требований к ПО (Р1) — это и есть процесс трансформации требований к системе в требования к ПО.

Для облегчения понимания процедуры трансформации, как во время разработки, так и ее верификации, рекомендуется поделить процедуру как минимум на две части: разработку требований высокого уровня и последующую разработку требований низкого уровня.

Требования высокого уровня непосредственно вытекают из анализа требований к системе с учетом особенностей ее построения. При этом необходимо соблюдение следующих условий: каждое требование к системе должно переноситься на одно или более требований к ПО высокого уровня, и наоборот, каждое требование к ПО высокого уровня — на одно или больше требований к системе, за исключением производных требований, которые непосредственно не возникают из требований к системе (например, требование обработки прерываний, зависящей от особенностей выбранного целевого вычислителя). Производные требования высокого уровня должны быть переданы в процесс оценки безопасности системы. К требованиям высокого уровня относятся функциональные и технические требования, требования к взаимодействию и требования к безопасности.

Требования низкого уровня формулируются в терминах инженерии ПО и их получают путем анализа и детализации требований высокого уровня. Требования низкого уровня относятся непосредственно к процедурам кодирования и комплексирования ПО, т. е. это требования к применяемым языкам программирования, компиляторам, к архитектуре и связям ПО, к структуре его компонентов, к классификации программных объектов, к операторному базису, к среде разработки и верификации, а также к стилю программирования.

Сопутствующими документами являются стандарты и другие нормативные документы (Д2) на технические задания, на проектирование, на кодирование, сопровождение. Верификационное мероприятие, завершающее первый этап разработки, — это сопоставление требований к ПО с требованиями к системе с целью проверки совместимости распределения функций между аппаратными и программными средствами и интерфейсами, полноты и адекватности требований к ПО. Рекомендуемая форма документирования — таблица перекрестных ссылок, которая может быть оформлена как отдельный верификационный документ, или быть частью общего документа, описывающего процедуры верификации всех этапов, их результаты, а также возникающие проблемы и меры по их устранению.

Следующие этапы разработки — планирование процессов создания ПО и управления его качеством. Основная цель планирования — определение ресурсов и последовательности действий, обеспечивающих достижение поставленных целей. Тут еще определяется организация (взаимосвязь) процессов. В результате должны быть оформлены пять документов (допускается обоснованное совмещение): план сертификации ПО (ДЗ), план разработки ПО, план верификации, а также планы управления конфигурацией ПО (Д6) и гарантии его качества. Верификационные мероприятия (В2, ВЗ) относятся, в основном, к процедурам согласования планов на этапе утверждения, а также к их коррекции по замечаниям, возникшим на более поздних этапах создания и даже эксплуатации ПО. Содержание документов рассматривается дальше.

Продолжением процесса разработки является процесс проектирования ПО. Здесь требования к ПО высокого уровня уточняются на протяжении нескольких итераций процесса проектирования для формирования архитектуры ПО алгоритмов функционирования, с учетом требований низкого уровня до такой степени, чтобы по ним можно было составить исходный код. Для удовлетворения требований безопасности следует предусмотреть контроль потоков управления и данных, например, предусмотреть сторожевой таймер, проверку на непротиворечивость и перекрестное сравнение потоков, естественно с соответствую щей реакцией на «отказные» состояния. Результаты проектирования фиксируются в документе, описывающем проект ПО.

Верификационное мероприятие В4 — проверка проекта ПО на соответствие требованиям к ПО и стандартам на проектирование, включая проверку алгоритмов функционирования системы. Главной целью верификации проекта является обеспечение его «проверяемости». При этом должны быть учтены, по крайней мере, такие факторы: последовательность выполнения программы, потоки данных и возможное их искажение, потенциальное влияние аппаратных средств на обособление и целостность функций. В верификационном документе Д13 должна быть представлена таблица соответствия проекта ПО требованиям к ПО в виде перекрестного анализа. Отступления от стандартов и требований должны быть отмечены и обоснованы.

Все рассмотренные до сих пор этапы, лаже этап проектирования ПО, можно охарактеризовать как подготовительные. Только в результате процессов программирования (Р5), комплексирования программных компонентов (Р6) и интеграции ПО с аппаратными средствами (Р7) появляется собственно программный продукт в окончательном виде.

Первым результатом процесса, реализующим требования низкого уровня, всегда является исходный код (Д9), который должен трансформироваться в проект ПО. Учет архитектуры ПО в процессе проектирования реализуется в процедурах комплексирования компонентов ПО, а интеграция ПО в целевой вычислитель даст в конце концов, исполняемый объектный код (ДЮ) и соответствующий каталог комплектации ПО (Д11). Неправильные или недостаточные входные данные, выявленные в этих процессах, следует возвратить в предыдущие процессы для внесения исправлений или ясности. Кроме этого, среда создания ПО (она же, чаще всего, и среда его сопровождения) должна быть четко и детально определена и зафиксирована (Д12).

Само собой разумеется, на данном этапе разработки осуществляются наиболее объемные, наиболее сложные по содержанию и наиболее важные верификационные мероприятия (В5, В6, В7) под общим названием — тестирование (испытания) ПО с целью выявления содержащихся в ПО ошибок. Проблема здесь в том, что выявленные ошибки, как правило, устраняются, а не выявленные не могут быть даже спрогнозированы.

Содержание всех трех верификационных мероприятий.

Процесс этот состоит из многих итераций и включает все указанные позиции в каждой итерации и в каждом мероприятии. Результаты процесса фиксируются в документе Д13.

Рассмотрение процессов создания ПО будет неполным, если не упомянуть о планах УКПО и ГКПО. которые должны быть реализованы путем внешних и внутренних аудиторских проверок состояния конфигурации, а также соответствующих организационных и технологических процедур, и отражены в протоколах Д14 и Д15.

Реализация плана сертификации ПО фиксируется документом Д16.

Цикл создания ПО завершается испытаниями подтверждения эксплуатационной пригодности бортовой цифровой функциональной системы (В9). Эти испытания проводятся как часть общего официального удостоверения (аттестации) того, что система на данном ВС в заявленных эксплуатационных условиях функционирует правильно.

Документация для сертификации программного обеспечения. В США с 1987 г. официально существует методика института SEI (Software Engineering Institute), позволяющая определить уровень технологической зрелости предприятий, разрабатывающих ПО и совершенствовать процессы разработки. Первоначально это Capability Maturity

Model (СММ), а позднее — Capability Maturity Model Integration (CMMI). В соответствии с моделью высший («оптимизирующий») уровень технологической зрелости — пятый — отвечает целиком автоматизированному процессу производства ПО на базе математической модели с применением методов параметрической и структурной оптимизации, и организация сосредотачивается на совершенствовании процессов. Одним из признаков низшего первого («первоначального») уровня является зависимость организации от отдельных программистов, а одним из условий перехода со второго («повторяемого») уровня на третий («определенный») — документирование процессов под управлением соответствующей службы во главе с ответственным лицом из состава высшего руководства организации.

Все фазы ЖЦ ПО имеют начало и конец Документация же может существовать вечно. Поэтому сформулировать требования к документации — значит сформулировать требования ко всем вышеописанным процессам создания программного обеспечения. Документация и есть тот самый материальный фактор, по которому сертифицируется ПО. Документация также является основным элементом, тщательно анализируемым при расследовании катастроф или предпосылок аварийных ситуаций.

Очень важны форма и содержание документа, включение в него количественных и качественных характеристик изделия, глубины его контроля и анализа, наличие возможности учета и хранения, уровень ответственности лиц, подписывающих документ. Наиболее слабое звено документации — полнота учета заявленных к ней требований.

Конкретный перечень документации, необходимой для сертификации ПО, зависит от уровня ПО (от критичности системы) и определяется в процессе согласования плана сертификации с сертификационным органом. Ниже кратко показана суть и уже упомянутых документов.

Д1 «Требования к ПО» — содержит описание трансформации требований к системе в требования к ПО с выделением требований высокого и низкого уровней и с особым вниманием к вопросам безопасности и возможным отказным состояниям. Должны быть определены критерии выполнения функций и возможные ограничения, например: по памяти, по времени, по частоте, по взаимодействию. Особое внимание отводится обособлению компонентов ПО.

Д2 — «Стандарты создания ПО» — множественный перечень. Как минимум — это перечень официально действующих стандартов разработки требований, проектирования, кодирования, испытаний ПО. Вместе со стандартами — это несколько документов.

Их содержание — методы создания, правила структурирования, ограничения на проект (например, исключение рекурсии, динамических объектов, альтернативных обозначений данных), ограничения по сложности (например, вложенность вызовов, использование переходов), по языку и компиляторам, среде и инструментам.

ДЗ — «План сертификации ПО» подается на утверждение в государственный сертификационный орган, определяет порядок действий, методы доказательства соответствия продукта требованиям к нему, к системе, к ВС и необходимую для этого документацию.

Д4 «План разработки ПО» — определяет ЖЦ создания ПО, взаимодействие исполнителей и среду разработки.

Д5 — «План верификации ПО» — определяет этапы (позиции процесса разработки и критерии перехода к процедурам верификации), методы, процедуры, среду и инструменты верификации, включая инструментальные программные средства, инструкции относительно достижения необходимых показателей качества (безопасности) и указания относительно повторных проверок и испытаний после внесения изменений в ПО, которые гарантируют устранение выявленных ошибок.

Д6 — «План управления конфигурацией ПО» — устанавливает правила идентификации единиц ПО и комплектации, базовые версии и их трассируемость на производные версии, правила управления изменениями, правила порядка и учета состояния конфигурации, архивирования, контроля и зашиты данных, обращения единиц ПО.

Д7 — «План гарантии качества ПО» устанавливает сферу действия, распределение ответственности и полномочий инспекций и аудита, других мероприятий, связанных с процессами получения гарантий, включая сообщения о проблемах, их отслеживание и корректирующие действия.

Д8 — «Описание проекта ПО» — содержит подробное описание того, каким образом ПО удовлетворяет предъявляемым к нему требованиям высокого уровня, включая алгоритмы, структуры данных, и как требования к ПО распределяются по задачам и процессам. Кроме этого, приводится описание архитектуры ПО, библиотек, входов/ выходов, потоков данных и управления, распределения ресурсов и связанных с этим ограничений, процедур диспетчеризации, схем между-процессного и межзадачного обмена, прерывания, компонентов ПО, методов их обособления.

Д9 «Исходный код» — содержит исходный код, инструкции компилятора для генерации объектного кода, данные для редактирования связей и загрузки.

Д10 — «Объектный исполняемый код» — содержит код, пригодный для непосредственного выполнения процессором целевого вычислителя, т. е. такой, который загружается в аппаратуру системы авионики.

Д11 — «Каталог комплектации ПО» — определяет конфигурацию продукта как поставляемой единицы. Он должен идентифицировать программный продукт в целом, каждый компонент, соответствующие документы и их носители.

Д12 — «Каталог среды ПО» — содержит описание среды ЖЦ ПО, начиная с этапа специфицирования требований и заканчивая этапом списания продукта из эксплуатации. В каталоге идентифицируются инструменты разработки, верификации, сопровождения программных средств, приводятся данные относительно квалификации инструментария.

Д13 — «Процедуры и результаты верификации» допускается делить на два-три документа, в которых должны быть описаны процедуры рассмотрения, анализа, испытаний на всех этапах разработки, примененные тестовые примеры и результаты проведенных процедур с идентифицированными компонентами ПО. Все проблемы и выполненные корректирующие действия должны быть подробно описаны.

Д14 — «Протоколы УКПО».

Д15 — «Протоколы ГКПО».

Д16 — «Итоговое заключение о ПО» — это основной документ, фиксирующий выполнение «Плана сертификации ПО» и степень соответствия «Требованиям к ПО». Он должен содержать краткие описания системы и ПО, сертификационные условия (договоренности), характеристики, идентификацию и состояние ПО, перечень документации на ПО и заявление о степени выполнения требований к ПО.

Квалификационные требования кт-178b

Решение S-KT-178B позволяет сократить трудозатраты на поддержание трассировки требований и повысить качество проектных решений, а также сократить ошибки проектирования за счет автоматизации верификации.

Управлять проектом становится намного проще за счет консолидации проектных данных. Сроки исполнения контракта сокращаются за счет поддержки параллельного проектирования.

Удобный настраиваемый интерфейс позволяет эффективно работать в проекте специалистам разных направлений.

Решение SATURS КТ178B предназначено для:

Сокращения трудозатрат на подготовку к сертификации бортового ПО.
Сокращения ошибок проектирования.

Решение полностью соответствует требованиям КТ178B к организации и трассировке проектных данных.

Решение позволяет:

Управлять требованиями всех уровней от требований к системе до требований к ПО низкого уровня.
Разрабатывать модели и проектные решений, моделировать производительность.
Раздельно управлять правами доступа к требованиям каждого типа.
Вести конфигурационное управление проектом (версии, базовые линии, формальное проведение запросов на изменение, история изменений)
Автоматически формировать представления (матриц, таблиц, деревьев) для верификации требований, в том числе, на транзитивных связях и других инструментов.
Генерировать проектную документацию.
Генерировать метрики для оценки состояния проектирования.
Управлять отказными состояниями системы, структурой модулей и функциями системы.
Трассироввать нефункциональные требования к функциям системы и ее модулям.
Управлять процедурами рассмотрения, тестовыми примерами и процедурами испытаний.
Управлять сообщениями о проблемах.
Управлять сертификационными записями — протоколами ГКПО, протоколами рабочих совещаний и протоколами УКПО.
Управлять планом работ проекта и технологией его выполнения.

Решение построено на платформе системной инженерии 3SL Cradle, которая успешно используется в 250+ международных компаниях, таких как: AREVA, KnollsAtomicPowerLaboratory (KAPL), Lesedi Nuclear Services, NASA, SES, HP, Samsung, Siemens, Nokia и т.д. 3SL Cradle использовался более чем в 20 крупных проектах при разработке ПО по DO178B (истребители, подводные лодки и др. проекты) .

Решение включает настроенную панель фаз проекта, на которой систематизированы все цели и задачи сертификации — это гид по процессу и целям сертификации КТ178B, позволяющий оперативно проверять соответствие текущего состояния проекта квалификационным требованиям :

Это решение корпоративного уровня, которое поддерживает:

гибкую настройку прав доступа и уровней секретности;
корпоративную аналитику (KPI, метрики);
высокий уровень безопасности, подтверждённый сертификатом CESG (Communications-Electronics Security Group) IT Health Check.

Решение позволяет публиковать правильно оформленные документы с содержанием, списком таблиц и рисунков, не требующие дополнительной правки. Из проектной базы в документы могут быть выведены требования, проектные решения, модели SysML, UML, eFFBD, DFD, ER, IDEF0 и др, а также автоматически сгенерированные таблицы и матрицы трассировки, иеархические диаграммы:

В проекте по КТ178 можно вести технологию проекта и публиковать готовые технологические регламенты.

Страница не найдена

К сожалению указанная страница не найдена. Вы можете перейти на страницу «Карта сайта» или воспользоваться формой поиска по каталогу:

Все права на материалы, находящиеся на сайте, охраняются в соответствии с законодательством Российской Федерации

Межгосударственный Авиационный Комитет Авиационный Регистр КВАЛИФИКАЦИОННЫЕ ТРЕБОВАНИЯ ЧАСТЬ 178В

1 1 Межгосударственный Авиационный Комитет Авиационный Регистр КВАЛИФИКАЦИОННЫЕ ТРЕБОВАНИЯ ЧАСТЬ 178В ТРЕБОВАНИЯ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ БОРТОВОЙ АППАРАТУРЫ И СИСТЕМ ПРИ СЕРТИФИКАЦИИ АВИАЦИОННОЙ ТЕХНИКИ

2 2 ЛИСТ УЧЕТА ИЗМЕНЕИЙ к Квалификационным требованиям «Требования к программному обеспечению бортовой аппаратуры и систем при сертификации авиационной техники» КТ-178B п/п Обозначение изменения 1 «1И1 8.2» Дата вступления в силу п/п Обозначение изменения Дата вступления в силу Примечание: номер изменения состоит из цифр, указывающих: — общий порядковый изменения, — буквы «И», — цифр, указывающих порядковый изменения к данному пункту и — пункта, в который вносится изменение. Например: «3И2 5.2» — это 3-е изменение к КТ-178В, являющееся вторым к пункту 5.2.

3 3 Предисловие Основой настоящих Квалификационных требований КТ-178В «Требования к программному обеспечению бортовой аппаратуры и систем при сертификации авиационной техники» является документ RTCA/DO-178B «Software considerations in airborne systems and equipment certification» [1] с учетом его корректировок и изменений, приведенных в документе «First annual report for clarification of ED-12B» [2]. Документ КТ-178В развивает требования и методические подходы, приведенные в ранее выпущенном документе КТ-178А [3]. Термины и определения, использованные в КТ-178А, по возможности, сохранены. Отказные состояния определены в соответствии с разделом А-0 Авиационных правил (части 23, 25 и 29) [4-6]. Заключение о соответствии ПО требованиям КТ-178В является обязательным при квалификации комплектующих изделий [7].

4 4 ОГЛАВЛЕНИЕ п/п Наименование раздела Стр. 1. ВВЕДЕНИЕ Назначение документа Область применения документа Связь с другими документами Рекомендации относительно работы с документом Структура документа Отличия данного документа от DO-178B СИСТЕМНЫЕ АСПЕКТЫ, ОТНОСЯЩИЕСЯ К РАЗРАБОТКЕ ПО Информационные потоки между процессами жизненных циклов системы и программного обеспечения Информационный поток из процессов системы в процессы ПО Информационный поток из процессов ПО в процессы системы Отказное состояние и уровень ПО Классификация отказных состояний Определения уровней ПО Установление уровня ПО Учет особенностей архитектуры системы Обособление Многоверсионное разнородное ПО Обеспечение безопасности с помощью непрерывного контроля Учет влияния системных аспектов на ПО, модифицируемое пользователем, опционное ПО и готовое коммерческое ПО Учет влияния схемы построения системы на ПО, загружаемое на месте эксплуатации Учет требований к системе при верификации ПО Учет ПО при верификации системы ЖИЗНЕННЫЙ ЦИКЛ ПО Процессы жизненного цикла ПО Определение жизненного цикла ПО Критерии перехода между процессами ПРОЦЕСС ПЛАНИРОВАНИЯ СОЗДАНИЯ ПО Цели процесса планирования Мероприятия процесса планировании создания ПО Планы создания ПО Планирование среды жизненного цикла ПО Среда разработки ПО Языки программирования и компиляторы Среда испытаний ПО Стандарты на разработку ПО Рассмотрение и гарантия процесса планирования создания ПО ПРОЦЕССЫ РАЗРАБОТКИ ПО Процесс разработки требований к ПО Цели процесса разработки требований к ПО Мероприятия процесса разработки требований к ПО Процесс проектирования ПО Цели процесса проектирования ПО Мероприятия проектирования ПО Проектирование ПО, модифицируемого пользователем Процесс кодирования Цель процесса кодирования Мероприятия процесса кодирования Процесс интеграции Цель процесса интеграции 32

5 5 п/п Наименование раздела Стр Мероприятия процесса интеграции Обстоятельства, которые следует учитывать в процессе интеграции Трассируемость ПРОЦЕСС ВЕРИФИКАЦИИ ПО Цели процесса верификации ПО Мероприятия процесса верификации ПО Рассмотрения и анализы ПО Рассмотрения и анализы требований высокого уровня Рассмотрения и анализы требований низкого уровня Рассмотрения и анализы архитектуры ПО Рассмотрения и анализы «Исходного кода» Рассмотрения и анализы результатов процесса интеграции Рассмотрения и анализы тестовых примеров, процедур и результатов испытаний Испытания ПО Среда испытаний Выбор тестовых примеров на основе требований Тестовые примеры в допустимом диапазоне Робастные тестовые примеры Методы испытаний на основе требований Анализ полноты испытаний Анализ тестовых покрытий на основе требований Анализ структурного покрытия Устранение недостатков по результатам анализа структурного покрытия ПРОЦЕСС УПРАВЛЕНИЯ КОНФИГУРАЦИЕЙ ПО Цели процесса управления конфигурацией ПО Мероприятия процесса управления конфигурацией ПО Идентификация конфигурации Базовые версии и трассируемость Сообщения о проблемах, отслеживание и корректирующие действия Управление изменениями Рассмотрение изменений Учет состояния конфигурации Архивирование, воспроизведение и выпуск Контроль загрузки ПО Контроль за состоянием среды жизненного цикла ПО Категории контроля данных ПРОЦЕСС ГАРАНТИИ КАЧЕСТВА ПО Цели процесса гарантии качества ПО Мероприятия процесса гарантии качества ПО Рассмотрение соответствия ПО требованиям ПРОЦЕСС ВЗАИМОДЕЙСТВИЯ ЗАЯВИТЕЛЯ И СЕРТИФИЦИРУЮЩЕГО ОРГАНА Методы определения соответствия и планирование Обоснование соответствия Минимальный состав документов жизненного цикла ПО, представляемых сертифицирующему органу Документы жизненного цикла ПО, относящиеся к типовой конструкции ОБЗОРНОЕ ОПИСАНИЕ ПРОЦЕССА СЕРТИФИКАЦИИ ВОЗДУШНОГО СУДНА И ДВИГАТЕЛЯ Сертификационный базис Учет ПО при сертификации воздушного судна и двигателя Определение соответствия ДОКУМЕНТЫ ЖИЗНЕННОГО ЦИКЛА ПО План сертификации ПО 57

6 6 п/п Наименование раздела Стр План разработки ПО План верификации ПО План управления конфигурацией ПО План гарантии качества ПО Стандарты на разработку требований ПО Стандарты на проектирование ПО Стандарты на кодирование Требования к ПО Описание проекта ПО Исходный код Исполняемый объектный код Примеры и процедуры верификации ПО Результаты верификации ПО Каталог среды жизненного цикла ПО Каталог комплектации ПО Сообщения о проблемах Протоколы УКПО Протоколы ГКПО Итоговое заключение о ПО ДОПОЛНИТЕЛЬНЫЕ УКАЗАНИЯ Использование ранее разработанного ПО Модификация ранее разработанного ПО Установка на другое воздушное судно Изменение условий применения или среды разработки Доработка базовой версии Указания по вопросам управления конфигурацией ПО Указания по вопросам гарантии качества ПО Квалификация инструмента Критерии квалификации инструментов для разработки ПО Критерии квалификации инструментов для верификации ПО Документы квалификации инструмента План квалификации инструмента Эксплуатационные требования к инструменту Одобрение квалификации инструмента Альтернативные методы Формальные методы Испытания по методу полного перебора Указания по верификации многоверсионного разнородного ПО Независимость многоверсионного разнородного ПО Верификация ПО, реализуемого на нескольких процессорах Верификация многоверсионного «Исходного кода» Квалификация инструмента для многоверсионного разнородного ПО Применение нескольких имитаторов при верификации Модели надёжности ПО Заархивированный период эксплуатации 77 ПРИЛОЖЕНИЕ А 79 ПРИЛОЖЕНИЕ В. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ 90 ПЕРЕЧЕНЬ ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ 98 БЛАНК ДЛЯ ИЗЛОЖЕНИЯ ПРЕДЛОЖЕНИЙ ПО СОВЕРШЕНСТВОВАНИЮ 99

7 7 1. ВВЕДЕНИЕ 1.1. Назначение документа Назначением данного документа является изложение инструктивных материалов относительно создания программного обеспечения (ПО) бортовых систем и оборудования, которые выполняют предписанные им функции с уровнем доверия к безопасности, удовлетворяющим требованиям к летной годности. Эти инструктивные материалы имеют форму: Целей процессов жизненного цикла ПО. Описания мероприятий и конструктивных соображений для достижения этих целей. Описания доказательных материалов, подтверждающих, что цели достигнуты Область применения документа В документе рассматриваются те аспекты сертификации, которые относятся к созданию ПО для бортовых систем и оборудования, используемых на воздушных судах или двигателях. Чтобы облегчить понимание процесса сертификации, при обсуждении этих вопросов описывается жизненный цикл системы и его связь с жизненным циклом ПО. Полное описание жизненного цикла ПО, включая процесс оценки безопасности системы и процесс удостоверения пригодности или процесса сертификации самолета и двигателя, не является назначением данного документа Связь с другими документами Дополнительно к требованиям летной годности существуют национальные и международные стандарты на ПО. В некоторых сообществах может потребоваться их выполнение. Однако обращение к таким стандартам или предложение методов применения этих стандартов как альтернативы или дополнения к данному документу выходит за его рамки. Везде, где в документе используется термин «стандарты», его следует понимать как стандарты, принимаемые разработчиком бортовой системы, бортового оборудования, двигателя или воздушного судна в конкретном проекте. Такие стандарты могут быть разработаны на основании общих стандартов, созданных или приспособленных изготовителем для своих мероприятий Рекомендации относительно работы с документом При использовании документа следует иметь в виду: Чтобы облегчить читателю понимание обсуждаемого вопроса, в текст документа включены пояснительные материалы. Например, в разделе 2 дается информация, необходимая для понимания взаимосвязи между жизненными циклами системы и ПО. Раздел 3 представляет собой описание жизненного цикла ПО, а раздел 10 — обзорное описание процесса сертификации воздушного судна или двигателя. Документ предназначен для использования и на уровне международного авиационного сообщества. Чтобы способствовать этому, ссылки на конкретные национальные нормы и правила сведены к минимуму. Применяются общеупотребляемые термины. Например, используется термин «Сертифицирующий орган», который означает организацию или лицо, дающее удостоверение летной годности от имени страны, ответственной за сертификацию воздушного судна или двигателя. Если другая страна или группа стран санкционирует такую сертификацию или участвует в ней, данный документ может быть использован при должном признании двусторонних соглашений или меморандумов о взаимопонимании между странами. В документе признается, что изложенные в нем инструктивные материалы не имеют обязательной юридической силы, но представляют единодушное мнение авиационного сообщества. Кроме того, признается, что Заявитель может использовать методы, отличающиеся от приведенных в настоящем документе.

8 8 В документе устанавливаются цели для уровней ПО, определения которых даны в п В Приложении А раскрывается содержание этих целей в зависимости от уровня ПО. Если Заявитель выбирает данный документ для решения вопросов сертификации, его можно применять как сборник инструктивных материалов относительно удовлетворения этих целей. В разделе 11 содержится перечень материалов, которые обычно составляются для того, чтобы помочь сертификации ПО. В тексте документа наименования таких документов выделяются с помощью кавычек, например, «Исходный код». В разделе 12 обсуждаются дополнительные указания, касающиеся использования ранее разработанного ПО, квалификации инструмента и применения методов, альтернативных описанным в разделах Указания раздела 12 могут применяться не во всяком сертификационном процессе. Таблицы целей и выходных документов процессов в зависимости от уровня ПО и толковый словарь терминов содержатся в Приложениях, являющихся нормативными частями данного документа. В тех случаях, когда для иллюстрации возможного применения инструктивных материалов используются примеры в графической или повествовательной форме, их не следует рассматривать в качестве предпочтительных методов. Перечень рассмотренных вопросов не следует считать исчерпывающим. В данном документе примечания используются для изложения пояснительных материалов, придания особого значения некоторому вопросу или для привлечения внимания к смежным вопросам, выходящим за рамки контекста. Примечания не содержат инструктивных материалов.

9 Структура документа Структура данного документа в виде перечня разделов и их взаимосвязи приведена на Рис Рис Структура документа КТ-178В.

10 Отличия данного документа от DO-178B В настоящем документе сохранены все разделы и подразделы документа DO-178B «Software Considerations in Airborne Systems and Equipment Certification» кроме Дополнений. Раздел 1 дополнен настоящим подразделом. [8]. В Приложении В приведен ряд терминов и определений, установленных в ГОСТ

11 11 2. СИСТЕМНЫЕ АСПЕКТЫ, ОТНОСЯЩИЕСЯ К РАЗРАБОТКЕ ПО В данном разделе рассматриваются аспекты процессов жизненного цикла системы, которые необходимы для понимания процессов жизненного цикла ПО. К таким аспектам относятся: Обмен данными между процессами жизненного цикла системы и программного обеспечения (п. 2.1). Установление категории критичности, определение уровней ПО и назначение уровня ПО (п. 2.2). Учет особенностей архитектуры системы (п. 2.3). Учет влияния системных аспектов на ПО, модифицируемое пользователем, опционное ПО и готовое коммерческое ПО (п. 2.4). Учет влияния схемы построения системы на ПО, загружаемое на месте эксплуатации (п. 2.5). Учет требований к системе при верификации ПО (п. 2.6). Учет ПО при верификации системы (п. 2.7) Информационные потоки между процессами жизненных циклов системы и программного обеспечения На Рис. 2-1 представлены потоки информации, связанные с обеспечением безопасности, между процессами жизненного цикла системы и процессами жизненного цикла ПО. Ввиду взаимосвязи процесса оценки безопасности системы и процесса разработки системы, рассматриваемые информационные потоки имеют итерационный характер. Рис Потоки информации, связанные с безопасностью, между процессами жизненных циклов системы и ПО

12 Информационный поток из процессов системы в процессы ПО Процесс оценки безопасности системы устанавливает отказные состояния системы и определяет их категории. В ходе этого процесса в результате анализа проекта системы устанавливаются требования, связанные с безопасностью её применения, которые определяют желаемую степень устойчивости и реакцию системы в отказных состояниях. Такие требования устанавливаются для аппаратуры и ПО с целью исключения или ограничения влияния неисправностей и могут обеспечивать обнаружение неисправностей и устойчивость к последним. В связи с тем, что решения принимаются в процессе проектирования аппаратуры и в процессах разработки ПО, то в процессе оценки безопасности системы проводится анализ результирующего проекта системы с целью подтверждения того, что этот проект удовлетворяет требованиям к безопасности. Требования, связанные с обеспечением безопасности, являются частью требований к системе, причем последние являются исходными данными для процессов жизненного цикла ПО. Чтобы гарантировать надлежащий учет требований к безопасности в течение этого цикла, в требованиях к системе обычно даётся следующая информация или ссылки на документы, в которых она содержится: Описание системы и характеристика аппаратного обеспечения. Сертификационные требования, включающие Квалификационные требования и другие нормативные документы. Требования к системе, относящиеся к требованиям к ПО, в том числе: — функциональные требования, — эксплуатационные требования, — требования к безопасности. Уровень(и) ПО и данные по их обоснованию, отказные состояния, их категории, а также соответствующие функции, относящиеся к ПО. Концепции обеспечения безопасности и проектные ограничения, включая методы проектирования, такие, как обособление, разнородность, резервирование и контроль. Если система является составной частью другой системы, указываются требования к безопасности системы более высокого уровня. Для поддержки мероприятий верификации системы процессы жизненного цикла системы могут формулировать требования к процессам жизненного цикла ПО Информационный поток из процессов ПО в процессы системы Процесс оценки безопасности системы учитывает влияние проекта и реализации ПО на безопасность системы на основе информации, получаемой из процессов жизненного цикла ПО. Эта информация включает границы, распространения неисправностей, требования к ПО, описание архитектуры ПО, источники ошибок, которые могут быть обнаружены или устранены за счет выбора архитектуры ПО, посредством использования инструментов или с помощью других методов, применяемых при проектировании программного обеспечения. Трассируемость связей между требованиями к системе и проектом ПО важна для процесса оценки безопасности системы. Изменения, вносимые в ПО, могут повлиять на безопасность системы, и поэтому они должны быть определены для их оценки в процессе оценки безопасности системы Отказное состояние и уровень ПО Ниже изложен материал относительно классификации отказных состояний, определения уровней ПО, связи между уровнями программного обеспечения и категориями отказных состояний, а также приведены рекомендации по назначению уровней ПО.

13 13 Категория отказного состояния системы устанавливается посредством определения тяжести отказных состояний для воздушного судна и находящихся в нём людей. Ошибка ПО может явиться причиной неисправности, способствующей появлению отказного состояния. Таким образом, уровень ПО в целом, необходимый для безопасности, соотносится с отказными состояниями системы Классификация отказных состояний Для получения исчерпывающих сведений о классификации отказных состояний следует обращаться к Авиационным правилам, части 23, 25, 29, раздел А-0. Приведенный здесь перечень отказных состояний заимствован из указанных документов и включен в данный документ для облегчения его использования. Классификация категорий отказных состояний следующая: а. Катастрофическое — отказное состояние, для которого принимается, что при его возникновении предотвращение гибели людей оказывается практически невозможным. b. Аварийное — отказное состояние, которое может привести к значительному ухудшению характеристик воздушного судна, и/или физическому утомлению или такой рабочей нагрузке экипажа, что уже нельзя полагаться на то, что он выполнит свои задачи точно и полностью. с. Сложное — отказное состояние, которое может привести к заметному ухудшению характеристик воздушного судна, и/или выходу одного или нескольких параметров за эксплуатационные ограничения, но без достижения предельных ограничений, и/или уменьшению способности экипажа справиться с неблагоприятными условиями, как из-за увеличения рабочей нагрузки, так и из-за условий, понижающих эффективность действий экипажа. d. Усложнение условий полёта — отказное состояние, которое может привести к незначительному ухудшению характеристик воздушного судна, и/или незначительному увеличению рабочей нагрузки на экипаж. е. Без последствий — отказное состояние, которое не влияет на характеристики воздушного судна и не увеличивает рабочую нагрузку на экипаж Определения уровней ПО Уровень ПО основан на вкладе программного обеспечения в возможные отказные состояния, определяемые в процессе оценки безопасности системы. Уровень ПО предполагает, что объем работ, выполнение которых необходимо для доказательства соответствия сертификационным требованиям, изменяется в зависимости от категории отказного состояния. Определения уровней ПО следующие: а. Уровень А: ПО, ненормальная работа которого согласно оценке, полученной в процессе анализа безопасности системы, может вызвать или способствовать отказу функции системы, приводящему к катастрофическим отказным состояниям для воздушного судна. b. Уровень В: ПО, ненормальная работа которого согласно оценке, полученной в процессе анализа безопасности системы, может вызвать или способствовать отказу функции системы, приводящему к аварийным отказным состояниям для воздушного судна. с. Уровень С: ПО, ненормальная работа которого согласно оценке, полученной в процессе анализа безопасности системы, может вызвать или способствовать отказу функции системы, приводящему к сложным отказным состояниям для воздушного судна. d. Уровень D: ПО, ненормальная работа которого согласно оценке, полученной в процессе анализа безопасности системы, может вызвать или способствовать отказу функции системы, приводящему к отказным состояниям типа «усложнение условий полета» воздушного судна. е. Уровень Е: ПО, ненормальная работа которого согласно оценке, полученной в процессе анализа безопасности системы, может вызвать или способствовать отказу функции системы без влияния на эксплуатационные возможности воздушного судна или загрузку пилота.

14 14 Получение от сертифицирующего органа подтверждения, что данное программное обеспечение относится к Уровню Е, означает, что к нему не применимы изложенные ниже положения данного документа Установление уровня ПО Вначале по результатам мероприятий, выполняемых в процессе оценки безопасности системы, назначается уровень(ни) ПО, соответствующий(ие) компонентам программного обеспечения конкретной системы без учета особенностей её построения. При этом учитывается воздействие отказа, проявляющееся как в невозможности выполнения функции, так и в нарушении её выполнения. Примечание: (1) Заявитель может пожелать рассмотреть запланированные функции, которые будут введены в дальнейшем, а также возможные изменения в требованиях к системе, относящиеся к ПО. Это может привести к отказным состояниям более опасной категории и более высокому уровню ПО. Поэтому может оказаться желательным разработать ПО более высокого уровня, чем тот, который был определён в процессе оценки безопасности системы для её первоначального применения, так как последующая разработка документов, устанавливающих применение с более высоким уровнем ПО, может оказаться затруднительной. Уровень ПО бортовых систем и оборудования, которые не влияют на лётную годность воздушного судна, но установка которых на борту является обязательной согласно эксплуатационным правилам (примером является аварийный самописец полётных данных), должен быть соразмерен выполняемой ими функции. В некоторых случаях уровень ПО может быть установлен в стандартах, определяющих минимальные требования к характеристикам оборудования. Если ненормальная работа некоторой компоненты ПО способствует возникновению более чем одного отказного состояния, то уровень этой компоненты определяется ее наиболее опасным отказным состоянием. Существуют различные концепции архитектурного построения программного обеспечения (например, описанные в п. 2.3), которые могут привести к пересмотру уровня(ей) ПО в ходе эволюционного совершенствования проекта системы. Для выполнения некоторой функции системы может быть выделена одна или более обособленных компонент ПО. Параллельной реализацией является такая, при которой функция системы выполняется несколькими компонентами ПО таким образом, что отказное состояние возникает в случае ненормальной работы более чем одной компоненты. При параллельной реализации по крайней мере одна из компонент ПО должна иметь уровень ПО, соответствующий наиболее тяжелой категории отказного состояния для функции системы. Уровни ПО других компонент определяются категорией отказного состояния, соответствующего потере этой функции. Примеры такой реализации описаны в п «Многоверсионное разнородное ПО» и п «Обеспечение безопасности с помощью непрерывного контроля». Последовательной реализацией является такая, при которой для выполнения функции системы используется несколько компонент ПО таким образом, что отказное состояние может возникнуть при ненормальной работе любой из этих компонент. При такой реализации компоненты ПО будут иметь уровень ПО, соответствующий наиболее тяжелой категории отказного состояния функции системы.

15 15 Разработка ПО, соответствующего некоторому уровню ПО, не подразумевает назначения интенсивности его отказов. Таким образом, уровни ПО или показатели его надежности, основанные на уровнях ПО, не могут быть использованы в процессе оценки безопасности системы, как используются интенсивности отказов аппаратного обеспечения. Концепции построения, которые не соответствуют инструктивным материалам данного параграфа, следует обосновывать в процессе оценки безопасности системы Учет особенностей архитектуры системы Если в процессе оценки безопасности системы установлено, что благодаря её архитектуре предотвращается возникновение наиболее опасного отказного состояния из числа возникающих по вине ненормальной работы ПО, то его уровень определяется категорией наиболее опасного из остальных отказных состояний, возникновению которых может способствовать ненормальная работа ПО. В процессе оценки безопасности системы рассматриваются архитектурные решения для определения, влияют ли они на уровень ПО и функционирование ПО. Ниже приведен инструктивный материал относительно нескольких концепций архитектурного построения систем, использование которых может ограничить влияние ошибок или позволяет обнаружить ошибки и обеспечить приемлемую реакцию системы на них. Эти методы архитектурного построения не следует рассматривать в качестве предпочитаемых или обязательных Обособление Обособление — это метод, позволяющий отделить функционально независимые компоненты ПО с целью сдерживания и/или изоляции отказов и потенциального снижения объёма работ, связанных с верификацией ПО. Если предусматривается защита с использованием метода обособления, то уровень ПО каждой обособленной компоненты определяется наиболее опасной категорией отказного состояния, связанного с данной компонентой. При использовании метода обособления следует придерживаться следующих инструктивных указаний: а. При проектировании защиты по методу обособления для оценки потенциальной возможности нарушения обособления следует учесть следующие характеристики системы: (1) ресурсы аппаратного обеспечения: процессоры, память, устройства ввода/вывода, прерывания и таймеры, связь по управлению: уязвимость к доступу извне, (3) связь по данным: общие или перекрывающиеся данные, включая стеки и регистры процессора, (4) отказные режимы работы аппаратного обеспечения, связанные с действием механизмов защиты. b. Процессы жизненного цикла ПО должны учитывать проектные решения, связанные с применением метода обособления, включая степень и область взаимодействия, которые разрешены для обособленных компонент, а также способ реализации такой защиты: с помощью аппаратных средств или с помощью сочетания аппаратных и программных средств. с. Если защита по методу обособления связана с использованием ПО, то такому программному обеспечению следует назначать уровень ПО, соответствующий наивысшему из уровней обособленных компонент ПО.

16 Многоверсионное разнородное ПО Многоверсионное разнородное ПО — это метод проектирования системы, связанный с созданием двух или более его компонент, обеспечивающих выполнение одной и той же функции таким образом, чтобы избежать источников общих ошибок для компонент. Этот метод называют также многоверсионным программным обеспечением, разнородным программным обеспечением, N-версионным кодированием или вариантным программным обеспечением. Процессы жизненного цикла ПО, выполненные или начатые до применения метода разнородности, остаются потенциальными источниками ошибок. В требованиях к системе может оговариваться конфигурация аппаратных средств, обеспечивающая реализацию многоверсионного разнородного ПО. Степень разнородности и, следовательно, степень защиты, обычно не поддается измерению. Вероятность потери функции системы возрастает до величины, которая зависит от вероятности обнаружения с помощью непрерывного контроля разнородных версий ПО действительных ошибок или переходных процессов, выходящих за пороги срабатывания устройств сравнения. Поэтому разнородные версии ПО обычно используются в качестве средства дополнительной защиты, применяемой после того, как цели процесса верификации для рассматриваемого уровня ПО, описанные в разделе 6, удовлетворены. Если в процессе оценки безопасности системы можно в итоге показать приемлемость потенциальной утраты функции системы, то методы верификации многоверсионного разнородного ПО могут быть сведены к методам верификации одноверсионного ПО. Верификация многоверсионного разнородного ПО рассмотрена в п Обеспечение безопасности с помощью непрерывного контроля Непрерывный контроль для обеспечения безопасности — это метод защиты от конкретных отказных состояний с помощью непосредственного непрерывного контроля правильности выполнения функции для отказов, которые могут способствовать возникновению отказного состояния. Функции контроля могут быть реализованы с использованием аппаратных средств или сочетания аппаратных и программных средств. С помощью применения методов непрерывного контроля, уровень ПО контролируемой функции может быть понижен до уровня, соответствующего утрате данной функции системы. Чтобы такое понижение стало допустимым, следует установить, что средство контроля обладает следующими тремя отличительными особенностями: а. Уровень ПО. Программному обеспечению, осуществляющему контроль, назначен уровень ПО, соответствующий наиболее опасной категории отказного состояния из числа тех, которые связаны с выполнением контролируемой функции. b. Полнота контроля неисправностей системы. Оценка полноты контроля неисправностей системы контролирующим устройством гарантирует, что схема этого устройства и её реализация таковы, что неисправности, подлежащие обнаружению, будут обнаружены при всех необходимых условиях. с. Независимость средств контроля и средств, обеспечивающих выполнение функции. Устройство контроля и защищаемая схема не теряют работоспособность в результате возникновения одного и того же отказа, который вызывает опасную ситуацию.

17 Учет влияния системных аспектов на ПО, модифицируемое пользователем, опционное ПО и готовое коммерческое ПО Влияние модификаций, вносимых пользователями, устанавливается в процессе оценки безопасности системы и используется для разработки требований к ПО, а затем и при разработке мероприятий процесса верификации. Проектирование ПО, модифицируемого пользователем, рассматривается далее в п Изменение, которое влияет на не модифицируемое программное обеспечение, его защиту или на границы модифицируемого программного обеспечения, является модификацией ПО и рассматривается в п В данном документе модифицируемой компонентой считается такая часть ПО, для которой предусмотрена возможность изменения пользователем, а не модифицируемой — компонента, для которой такая возможность не предусмотрена. Некоторые бортовые системы могут выполнять опционные функции, выбор которых осуществляется не с помощью программирующих контактов на штепсельных разъёмах аппаратуры, а с помощью специального ПО. Для выбора конкретной конфигурации ПО в целевом вычислителе используются специальные функции программного обеспечения. Инструктивный материал по вопросу отключенного кода изложен в п Ниже приведены инструкции, относящиеся к ПО, модифицируемому пользователем, опционному ПО, и к готовому коммерческому ПО. а. ПО, модифицируемое пользователем. Если в требованиях к системе предусмотрена возможность модификации ПО пользователем, то он может в пределах установленных ограничений вносить изменения в программы без их повторного рассмотрения сертифицирующим органом. b. В требованиях к системе следует четко оговорить меры, предотвращающие возможность влияния внесенных пользователем изменений на безопасность, вне зависимости от того, правильно или нет реализуются такие изменения. Программам, которые обеспечивают защиту от ошибок при внесении изменений пользователем, следует назначать тот же уровень ПО, что и программам в модифицируемой компоненте, которые они защищают. с. Если в требованиях к системе не предусмотрена её модификация пользователем, то он не должен вносить изменения в ПО без демонстрации их соответствия данному документу. d. На период времени, в течение которого пользователь вносит изменения, ему следует взять на себя ответственность за всё, что связано с модифицируемым ПО, например, ответственность за верификацию, управление конфигурацией и гарантию качества программного обеспечения. е. Опционное ПО. В тех случаях, когда в состав ПО включены дополнительные функции, выбираемые программным способом, следует предусмотреть меры предосторожности, гарантирующие невозможность случайного выбора конфигурации ПО, не утверждённой для данного целевого вычислителя и данных условий его установки. f. Готовое коммерческое ПО. Если такое программное обеспечение используется в бортовых системах, то оно должно удовлетворять требованиям данного документа. g. Если документов, составленных в течение жизненного цикла готового коммерческого ПО, недостаточно, то их состав должен быть дополнен таким образом, чтобы удовлетворялись требования к безопасности, изложенные в данном документе. В подобных случаях могут быть полезны указания, изложенные в п Доработка базовой версии и в п Заархивированный период эксплуатации.

18 Учет влияния схемы построения системы на ПО, загружаемое на месте эксплуатации К программному обеспечению, загружаемому на месте эксплуатации, относятся такие программы или таблицы данных, которые могут быть загружены без демонтажа системы или оборудования с места установки. Требования, связанные с обеспечением безопасности при загрузке такого ПО, являются частью требований к системе. Если случайное включение загрузки данных, относящихся к такому ПО, может привести к возникновению в системе отказного состояния, то требования к безопасности загрузки оговариваются в требованиях к системе. При использовании ПО, загружаемого на месте эксплуатации, следует учитывать следующие факторы, связанные с безопасностью применения системы: наличие средств обнаружения неправильной или неполной загрузки, наличие средств обнаружения последствий загрузки несанкционированного ПО, аппаратно-программная совместимость, программно-программная совместимость, совместимость ПО с воздушным судном, возможность непреднамеренного включения загрузки на месте эксплуатации, возможность потери или неправильной индикации идентификатора конфигурации ПО. Ниже приведены инструкции, относящиеся к ПО, загружаемому на месте эксплуатации: а. Если в ходе работ, выполняемых для оценки безопасности системы, не обоснована возможность отступления от изложенного ниже правила, то программу, обнаруживающую неполную или неправильную загрузку ПО, следует относить к источникам отказных состояний наиболее опасной категории или назначать ей наиболее высокий уровень ПО из тех, которые связаны с функцией, для выполнения которой загружается данное программное обеспечение. b. Если в системе предусмотрен режим загрузки несанкционированных программ или данных «по умолчанию», то для каждой обособленной компоненты системы следует сформулировать требования к безопасности использования этого режима, учитывающие возможное отказное состояние. с. При реализации функции загрузки следует предусмотреть меры, обеспечивающие обнаружение неправильных комбинаций «программное обеспечение/аппаратное обеспечение/воздушное судно» и защиту, соответствующую отказному состоянию этой функции. При этом следует учитывать системы и процедуры, используемые для поддержки загрузки. d. Если ПО является частью бортового средства отображения, гарантирующего что воздушное судно соответствует сертифицированному типу, тогда либо данное ПО должно быть разработано по уровню ПО, соответствующему самому высокому уровню загружаемого ПО, либо в процессе оценки безопасности системы должна быть подтверждена целостность проверки идентификатора конфигурации программного обеспечения Учет требований к системе при верификации ПО Требования к системе разрабатываются на основе соответствующих эксплуатационных требований и требований, связанных с безопасностью. Последние являются результатом процесса оценки безопасности системы. При этом учитывается следующее: а. В требованиях к системе указываются две обязательные характеристики ПО: (1) ПО должно выполнять предписанные ему функции так, как это указано в требованиях к системе. ПО не должно приводить к ненормальной работе, определенной в процессе оценки безопасности системы.

19 19 Для исключения ненормальной работы формулируются дополнительные требования к системе. b. Эти требования к системе затем трансформируются в требования к ПО высокого уровня, которые проверяются при выполнении мероприятий процесса верификации ПО Учет ПО при верификации системы Инструктивный материал по верификации (проверкам и испытаниям) системы выходит за рамки данного документа. Однако, процессы жизненного цикла ПО поддерживают процесс верификации системы и взаимодействуют с ним. Для поддержки верификации системы необходимы сведения о построении ПО, связанные с функционированием системы. Верификация системы может обеспечивать значительное покрытие структуры кода. Анализ покрытия испытаний при верификации системы может быть использован и для достижения целей покрытия различных видов испытаний, рассматриваемых при верификации ПО.

20 20 3. ЖИЗНЕННЫЙ ЦИКЛ ПО В данном разделе рассматриваются процессы, образующие жизненный цикл ПО, даётся определение этого понятия, описываются критерии перехода от одного процесса к другому. Инструктивный материал, изложенный в данном документе, не предписывает предпочтительный цикл, а описывает отдельные процессы, которые входят в большинство циклов и взаимосвязи между ними. Разделение процессов не означает, что оно отражает структуру организации(ий), выполняющей эти работы. Для каждого программного продукта планируется его жизненный цикл(ы), состоящий из описанных ниже процессов Процессы жизненного цикла ПО Процессами жизненного цикла ПО являются: Процесс планирования создания ПО, который определяет и координирует мероприятия процессов разработки программного обеспечения и интегральных процессов в рамках проекта. Процесс планирования описывается в разделе 4. Процессы разработки ПО, в результате выполнения которых получается программный продукт. Эти процессы включают: — процесс разработки требований к ПО, — процесс проектирования ПО, — процесс кодирования ПО, — процесс интеграции. Эти процессы описаны в разделе 5. Интегральные процессы, которые гарантируют корректность, управляемость и доверие к процессам жизненного цикла ПО и их результатам. Интегральные процессы включают: процесс верификации ПО, процесс управления конфигурацией ПО, процесс гарантии качества ПО, процесс взаимодействия с сертифицирующим органом.. Важно понимать, что интегральные процессы выполняются одновременно с процессом разработки ПО в течение всего жизненного цикла ПО. Описание интегральных процессов даётся в разделах Определение жизненного цикла ПО Проект, как правило, определяет один или более жизненных циклов ПО посредством выбора мероприятий для каждого из процессов, установления их последовательности и назначения ответственных за эти мероприятия. В конкретном проекте последовательность этих процессов определяется его характерными особенностями: составом выполняемых функций и сложностью системы, объёмом и сложностью ПО, стабильностью требований, использованием результатов предыдущих разработок, концепциями, положенными в основу разработки, наличием аппаратного обеспечения. Обычная последовательность процессов в цикле следующая: требования, проект, кодирование и интеграция.

21 21 Рис. 3-1 иллюстрирует последовательность процессов при разработке нескольких компонент одного программного продукта, имеющих различные жизненные циклы. Рис Пример проекта ПО, в котором используются четыре различные последовательности разработки. Компонента «W» реализует набор требований к системе посредством разработки требования к ПО. На основе этих требований составляется проект ПО, который далее воплощается в Исходный код и интегрируется с аппаратурой. Компонента «X» иллюстрирует применение ранее разработанного ПО, используемого на сертифицированном воздушном судне или двигателе. Компонента «Y» иллюстрирует применение ПО простой обособленной функции, для которой Исходный код можно написать прямо на основании требований к программному обеспечению. Компонента «Z» иллюстрирует метод разработки, основанный на построении прототипа. Обычно, прототип создается для лучшего понимания требований к ПО и для уменьшения объёма доводочных работ и технического риска. Исходные требования используются как базис прототипа. Его работа оценивается в ожидаемых условиях эксплуатации разрабатываемой системы. Результаты оценки используются для уточнения требований. Процессы жизненного цикла ПО могут иметь итерационный характер, то есть, могут повторяться. Время выполнения и степень уточнения при совершении итерационных шагов изменяются в зависимости от степени наращивания функций в процессе разработки, сложности, степени уточнения требований, наличия аппаратуры, наличия обратной связи в предшествующие процессы и от других особенностей проекта. Различные этапы жизненного цикла ПО, выбранного для реализации, связаны между собой последовательным процессом интеграции и мероприятиями процесса верификации.

22 Критерии перехода между процессами Эти критерии используются для определения, можно ли начинать или повторно начинать некоторый процесс. Каждый процесс жизненного цикла ПО определяет мероприятия, связанные с обработкой входных данных для получения выходных данных. Процесс может порождать обратные связи в другие процессы, а также использовать обратные связи из других процессов. Формирование обратной связи включает решение вопросов, каким образом информация распознается, контролируется и используется для принятия решения принимающим процессом. Примером обратной связи являются сообщения о проблемах. Критерии перехода зависят от запланированной последовательности процессов разработки ПО и интегральных процессов, на них также может влиять уровень ПО. Примерами критериев перехода могут быть следующие: — рассмотрения процесса верификации завершены, — входным объектом является идентифицированная единица конфигурации, — анализ трассируемости для входного объекта завершен. Если удовлетворены критерии перехода для данного вида процесса, то нет необходимости в том, чтобы к моменту его начала были получены все входные данные. Инструкции следующие: а. Если для некоторого процесса входные данные поступают по частям, то при поступлении каждого очередного их набора следует проверить, остались ли в силе предыдущие выходные данные процессов разработки и верификации.

23 23 4. ПРОЦЕСС ПЛАНИРОВАНИЯ СОЗДАНИЯ ПО В данном разделе описываются цели и мероприятия процесса планирования создания ПО. Результатом процесса планирования являются планы и стандарты, которые непосредственно определяют процессы разработки ПО и интегральные процессы. Таблица А-1 Приложения А представляет собой сводку целей и результатов процесса планирования для разных уровней ПО Цели процесса планирования Назначением процесса планирования является определение методов и средств, используемых для создания ПО, удовлетворяющего требованиям к системе, а также позволяющих получить уровень доверия к программному обеспечению, удовлетворяющий требованиям лётной годности. Цели процесса планирования следующие: а. С учетом требований к системе и уровня(ей) ПО следует определить мероприятия процессов разработки и интегральных процессов жизненного цикла программного обеспечения (п. 4.2). b. Следует определить жизненный(ые) цикл(ы) ПО с указанием взаимосвязей между процессами, последовательности их выполнения, схемы обратных связей и критериев перехода (Раздел 3). с. Следует выбрать среду жизненного цикла ПО, включая методы и инструменты, которые будут использованы в мероприятиях каждого процесса жизненного цикла (п. 4.4). d. При необходимости следует учесть дополнительные инструктивные материалы, подобные приведенным в Разделе 12. е. Следует установить стандарты на разработку ПО, согласованные с требованиями к безопасности системы (п. 4.5). f. Планы создания ПО должны соответствовать требованиям, изложенным в п. 4.3 и Разделе 11. g. Следует обеспечить координацию разработки и пересмотра планов ПО (п. 4.3) Мероприятия процесса планировании создания ПО Для создания ПО, соответствующего требованиям данного документа, определяющим фактором является эффективное планирование. Рекомендации по процессу планирования следующие: а. Планы ПО следует разрабатывать так, чтобы обеспечить своевременное руководство для персонала, участвующего в процессе разработки и интегральных процессах. Инструктивный материал приведен в п b. Следует сформулировать или выбрать стандарты разработки ПО для использования в рассматриваемом проекте. с. Следует выбрать методы и инструменты, обеспечивающие предотвращение ошибок в процессе разработки ПО. d. Процесс планирования должен обеспечить координацию процессов разработки и интегральных процессов таким образом, чтобы обеспечить последовательность стратегий, изложенных в планах. е. При планировании следует предусмотреть процедуру пересмотра планов по мере осуществления проекта. f. Если в системе используется многоверсионное разнородное ПО, то в процессе планирования следует выбрать такие методы и инструменты предотвращения или обнаружения ошибок, которые необходимы для удовлетворения требований к безопасности системы. g. Для завершения процесса планирования планы и стандарты на разработку ПО должны находиться под управлением изменениями, а их рассмотрения должны быть завершены (п. 4.6).

24 24 h. Если предусматривается наличие отключенного кода (п. 2.4), то процесс планирования должен описывать, как отключенный код (выбираемые опции, лётные испытания) будет определяться, верифицироваться и как с ним нужно обращаться для того, чтобы удовлетворять требованиям к безопасности системы. i. Если предусматривается код, модифицируемый пользователем, то в планах и в стандартах следует указать процесс, инструменты, среду и данные, доказывающие выполнение указаний п Некоторые процессы жизненного цикла ПО могут начинаться до завершения процесса планирования, если планы и процедуры для конкретного мероприятия процесса уже имеются Планы создания ПО Назначением этих планов является определение средств, обеспечивающих достижение целей данного документа. Планы определяют также организации (группы исполнителей), которые будут выполнять указанные в планах мероприятия. Ниже приведен перечень планов: «План сертификации ПО» (п. 11.1) является основным документом, в котором предлагаемые методы разработки программного обеспечения представляются сертифицирующему органу на утверждение, и документом, в котором указываются методы определения соответствия требованиям данного документа. «План разработки ПО» (п. 11.2) определяет жизненный цикл(ы) и среду разработки ПО. «План верификации ПО» (п. 11.3) определяет средства, с помощью которых будут достигаться цели процесса верификации. «План управления конфигурацией ПО» (п. 11.4) определяет средства, с помощью которых будут достигаться цели процесса управления конфигурацией программного обеспечения. «План гарантии качества ПО» (п. 11.5) определяет средства, с помощью которых будут достигаться цели процесса гарантии качества программного обеспечения. Инструкции, касающиеся планов создания ПО, следующие: а. Планы следует составлять в соответствии с данным документом. b. В планах следует определить критерии перехода между процессами цикла создания ПО, указав при этом: (1) Входные данные процесса, включая обратные связи от других процессов. Мероприятия интегральных процессов, которые могут потребоваться для реакции на эти входные данные. (3) Доступность инструментов, методов, планов и процедур. с. В планах создания ПО следует установить процедуры внесения изменений в программное обеспечение до его применения на сертифицированном воздушном судне или двигателе. Такие изменения могут быть результатами обратных связей от других процессов и они могут приводить к необходимости внесения изменений в планы создания ПО Планирование среды жизненного цикла ПО Целью планирования среды жизненного цикла ПО является определение методов, инструментов, процедур, языков программирования и аппаратных средств, используемых для разработки, контроля, выпуска документации жизненного цикла ПО (Раздел 11) и программного продукта. Примером положительного влияния среды на бортовое ПО является введение стандартов, средств обнаружения ошибок, а также методов предотвращения ошибок и обеспечение отказобезопасности. Среда, в которой осуществляется жизненный цикл ПО, является потенциальным источником ошибок, которые могут привести к отказным состояниям.

25 25 На состав средств, образующих среду, могут оказывать влияние требования к безопасности, установленные в результате оценки безопасности системы, например, требование применения разнородных резервированных компонент. Целью методов предотвращения ошибок является исключение в процессах разработки ПО тех из них, которые могут способствовать возникновению отказных состояний. Основным принципом при этом является выбор методов разработки требований и методов проектирования, инструментов и языков программирования, ограничивающих возможность внесения ошибок, а также выбор методов верификации, гарантирующих обнаружение внесенных ошибок. Целью методов обеспечения устойчивости к неисправностям является внесение в проект ПО и в Исходный код таких особенностей обеспечения безопасности, которые гарантируют, что программное обеспечение будет правильно реагировать на ошибки входных данных и не допустит ошибок на выходе и в управлении. Необходимость применения методов предотвращения ошибок или методов обеспечения работоспособности при возникновении неисправностей устанавливается требованиями к системе и процессом анализа её безопасности. Изложенные выше соображения могут оказать влияние на: Методы и систему обозначений, используемые в процессе разработки требований к ПО и в процессе проектирования программного обеспечения. Используемые языки и методы в процессе кодирования. Инструменты среды разработки ПО. Инструменты, используемые при верификации и управлении конфигурацией. Необходимость квалификации инструментов (п. 12.3) Среда разработки ПО Среда, в которой осуществляется разработка ПО, является важным фактором производства ПО высокого качества. Среда же различными путями может оказать и неблагоприятное влияние на бортовое ПО. Например, компилятор может внести ошибки, исказив откомпилированную программу, или редактор связей может не обнаружить ошибку, допущенную при распределении памяти. Инструкции относительно выбора методов и инструментов, используемых для разработки ПО, следующие: а. В процессе планирования следует выбрать среду, минимизирующую риск её неблагоприятного влияния на готовое бортовое ПО. b. Выбор квалифицированных инструментов или комбинации инструментов и элементов среды следует осуществлять таким образом, чтобы достигался необходимый уровень уверенности, что ошибка, внесенная в одном элементе среды, будет обнаружена в другом элементе. Приемлемая среда формируется тогда, когда оба элемента используются согласованно. с. Чтобы свести к минимуму ошибки, вносимые средой, следует предусмотреть мероприятия процесса верификации ПО или стандарты на разработку программного обеспечения, учитывающие уровень программного обеспечения. d. Если Заявитель планирует использовать комбинации инструментов, то в соответствующем плане следует оговорить последовательность их работы. е. Если в проекте предусматривается использование опционных особенностей инструментов разработки ПО, то влияние этих опций должно быть проверено и отражено в соответствующем плане. Примечание: Это особенно важно в тех случаях, когда инструменты непосредственно генерируют часть программного продукта. В этом отношении компиляторы, по видимому, являются наиболее важными из инструментов, подлежащих рассмотрению.