Требования к программному обеспечению бортовой аппаратуры и систем КТ-178B, страница 3

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

Отказное состояние и уровень ПОНиже изложен материал относительно классификации отказных состояний, определенияуровней ПО, связи между уровнями программного обеспечения и категориями отказныхсостояний, а также приведены рекомендации по назначению уровней ПО.© НИИАО 2002.Формат А413КТ-178В________________________________________________________________________________Категория отказного состояния системы устанавливается посредством определениятяжести отказных состояний для воздушного судна и находящихся в нём людей.Ошибка ПО может явиться причиной неисправности, способствующей появлениюотказного состояния.Таким образом, уровень ПО в целом, необходимый для безопасности, соотносится сотказными состояниями системы.2.2.1. Классификация отказных состоянийДля получения исчерпывающих сведений о классификации отказных состояний следуетобращаться к Авиационным правилам, части 23, 25, 29, раздел А-0.Приведенный здесь перечень отказных состояний заимствован из указанных документови включен в данный документ для облегчения его использования.Классификация категорий отказных состояний следующая:а.

Катастрофическое - отказное состояние, для которого принимается, что при еговозникновении предотвращение гибели людей оказывается практически невозможным.b. Аварийное - отказное состояние, которое может привести к значительномуухудшению характеристик воздушного судна, и/или физическому утомлению или такой рабочейнагрузке экипажа, что уже нельзя полагаться на то, что он выполнит свои задачи точно иполностью.с.

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

Без последствий - отказное состояние, которое не влияет на характеристикивоздушного судна и не увеличивает рабочую нагрузку на экипаж.2.2.2. Определения уровней ПОУровень ПО основан на вкладе программного обеспечения в возможные отказныесостояния, определяемые в процессе оценки безопасности системы.Уровень ПО предполагает, что объем работ, выполнение которых необходимо длядоказательства соответствия сертификационным требованиям, изменяется в зависимости откатегории отказного состояния.Определения уровней ПО следующие:а. Уровень А: ПО, ненормальная работа которого согласно оценке, полученной впроцессе анализа безопасности системы, может вызвать или способствовать отказу функциисистемы, приводящему к катастрофическим отказным состояниям для воздушного судна.b.

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

Уровень С: ПО, ненормальная работа которого согласно оценке, полученной впроцессе анализа безопасности системы, может вызвать или способствовать отказу функциисистемы, приводящему к сложным отказным состояниям для воздушного судна.d. Уровень D: ПО, ненормальная работа которого согласно оценке, полученной впроцессе анализа безопасности системы, может вызвать или способствовать отказу функциисистемы, приводящему к отказным состояниям типа «усложнение условий полета» воздушногосудна.е. Уровень Е: ПО, ненормальная работа которого согласно оценке, полученной впроцессе анализа безопасности системы, может вызвать или способствовать отказу функциисистемы без влияния на эксплуатационные возможности воздушного судна или загрузку пилота.© НИИАО 2002.Формат А414КТ-178В________________________________________________________________________________Получение от сертифицирующего органа подтверждения, что данное программноеобеспечение относится к Уровню Е, означает, что к нему не применимы изложенные нижеположения данного документа.2.2.3.

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

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

2.3.2 «Многоверсионное разнородное ПО» и п.2.3.3 «Обеспечение безопасности с помощью непрерывного контроля».Последовательной реализацией является такая, при которой для выполнения функциисистемы используется несколько компонент ПО таким образом, что отказное состояние можетвозникнуть при ненормальной работе любой из этих компонент.При такой реализации компоненты ПО будут иметь уровень ПО, соответствующийнаиболее тяжелой категории отказного состояния функции системы.© НИИАО 2002.Формат А415КТ-178В________________________________________________________________________________Разработка ПО, соответствующего некоторому уровню ПО, не подразумевает назначенияинтенсивности его отказов.Таким образом, уровни ПО или показатели его надежности, основанные на уровнях ПО,не могут быть использованы в процессе оценки безопасности системы, как используютсяинтенсивности отказов аппаратного обеспечения.Концепции построения, которые не соответствуют инструктивным материалам данногопараграфа, следует обосновывать в процессе оценки безопасности системы.2.3.

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