Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология
Образование Политология Производство Психология Стандартизация Технологии


Отказные ситуации и уровни ПО



К атегорию отказной ситуации системы устанавливают, определяя серьезность проявления отказной

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

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

исходя из отказных ситуаций системы.

5.2.1 Классификация отказных ситуаций

К атегория А - катастрофическая: отказная ситуация, которая препятствует безопасному функционированию

объекта управления.

К атегория В - опасная/критическая: отказная ситуация, которая приводит к уменьшению

возможностей объекта управления или способности персонала справиться с неблагоприятными

эксплуатационными режимами, при которых возникают:

- большое снижение гарантийных резервов или функциональных возможностей;

- крайне тяжелое положение или перегрузки, которые могут вызвать неточное или неполное выполнение

задачи;

- неблагоприятные или потенциально фатальные воздействия для окружающей среды.

К атегория С - существенная: отказная ситуация, которая приводит к снижению возможностей объекта

управления или способности персонала справиться с неблагоприятными эксплуатационными режимами,

при продолжении которых могут возникать, например, большое снижение гарантийных резервов

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

персонала.

К атегория D - несущественная: отказная ситуация, незначительно уменьшающая безопасность объекта

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

Несущественная отказная ситуация может включать в себя, например, незначительное уменьшение

гарантийных резервов или функциональных возможностей, незначительное увеличение рабочей нагрузки

персонала или некоторое неудобство для персонала.

К атегория Е - невлияющая: отказная ситуация, которая не воздействует на эксплуатационные возможности

объекта управления или не увеличивает рабочую нагрузку персонала.

5.2.2 Определения уровня ПО

У ровень ПО определяется возможностью возникновения потенциальных отказных ситуаций, выявленных

процессом оценки безопасности системы, в результате сбоев в ПО. Уровень ПО означает, что

трудозатраты, необходимые для доказательства согласованности с требованиями сертификации, меняются

в зависимости от категории отказной ситуации.

У ровень А: ПО, аномальное поведение которого, как показано процессом оценки безопасности системы,

вызвало бы (или способствовало бы) возникновению отказа функционирования системы, приводящее к

катастрофической отказной ситуации для объекта управления.

У ровень В: ПО, аномальное поведение которого, как показано процессом оценки безопасности системы,

вызвало бы (или способствовало бы) возникновение(ю) отказа функционирования системы, приводящее к

опасной/критической отказной ситуации для объекта управления.

 

У ровень С: ПО, аномальное поведение которого, как показано процессом оценки безопасности системы,

вызвало бы (или способствовало бы) возникновение(ю) отказа функционирования системы, приводящее

к существенной отказной ситуации для объекта управления.

У ровень D: ПО, аномальное поведение которого, как показано процессом оценки безопасности системы,

вызвало бы (или способствовало бы) возникновение(ю) отказа функционирования системы, приводящее к

несущественной отказной ситуации для объекта управления.

У ровень Е: ПО, аномальное поведение которого, как показано процессом оценки безопасности системы,

вызвало бы (или способствовало бы) возникновение(ю) отказа функционирования системы, не влияющее

на эксплуатационные возможности объекта и работоспособность персонала. Если для ПО был установлен

сертифицирующей организацией уровень Е, то в дальнейшем для сертификации такого ПО никакие

требования данного документа не являются обязательными.

5.2.3 Назначение уровня ПО

П ервоначально процесс оценки безопасности системы присваивает уровни ПО, соответствующие

компонентам ПО конкретной системы. При проведении данного назначения учитывают воздействие

отказов как потери функции или неправильного функционирования.

П римечание - Если систему или ЭКПО разрабатывают для нескольких построений, то компоненту ПО данного построения

может быть назначен более высокий уровень, чем требуется процессом оценки безопасности системы, если использование

этого компонента в других построениях требует такого уровня.

Е сли аномальное поведение компонента ПО вызвано более чем одной отказной ситуацией, уровень ПО

для данного компонента ПО определяет наиболее серьезная категория отказной ситуации. Существуют

архитектурные стратегии (см. 5.5 ), использование которых в процессе проектирования системы может

привести к изменению назначенного уровня ПО.

С истемная функция может быть реализована одним или несколькими компонентами ПО. Параллельная

реализация - это такая реализация, когда функция системы реализуется несколькими компонентами ПО.

Тогда для возникновения отказной ситуации требуется аномальное поведение более чем одного

компонента.

При параллельной реализации по крайней мере один компонент ПО будет иметь уровень ПО, связанный

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

компонентов определяют, используя категорию отказной ситуации, связанную с потерей этой функции.

Примеры таких реализаций описаны в 5.5.2 и 5.5.3.

П оследовательная реализация - это такая реализация, когда несколько компонентов ПО используются для

реализации функции системы так, что аномальное поведение любого из компонентов может привести к

отказной ситуации. При такой реализации все компоненты ПО будут иметь уровень ПО, связанный с

наиболее серьезной категорией отказной ситуации этой функции системы.

Р азработка ПО с заданным уровнем не подразумевает оценку интенсивности отказов для этого ПО.

Таким образом, уровни ПО или оценки надежности ПО, основанные на уровнях ПО, не могут

использоваться процессом оценки безопасности системы в отличие от использования интенсивности

отказов аппаратуры.

5.3 Анализ системных требований

Р азработчик должен принимать участие в анализе требований к системе. Если систему разрабатывают для

нескольких различных построений, ее требования не могут быть полностью определены до завершения

конечного построения.

В этом случае разработчик должен идентифицировать подмножество требований

системы, которые будут определены в каждом построении, и подмножество, которое будет реализовано

в каждом из построений. Анализ требований к системе для данного построения следует интерпретировать

так, чтобы определять требования к системе, идентифицированные для данного построения.

5.3.1 Анализ информации о потребностях пользователя

Р азработчик должен принимать участие в анализе обеспечиваемой заказчиком информации, необходимой

для достижения понимания потребностей пользователя. Эта информация может быть представлена в форме

предложений, обзоров, сообщений о дефектах/изменениях, обратной связи к прототипам, интервью о

потребностях пользователя или любой другой форме.

5.3.2 Эксплуатационная концепция

Р азработчик должен принимать участие в определении и документировании эксплуатационной концепции

для системы. Результат данной работы должен быть представлен в качестве документа «Описание

эксплуатационной концепции» ( 12.32 ).

5.3.3 Требования к системе

Р азработчик должен принимать участие в определении и документировании требований, которым должна

удовлетворять система, и методов, которые необходимо использовать в целях гарантирования выполнения

каждого требования. Результат данной работы должен быть представлен в качестве документа

«Спецификация системы/подсистемы» ( 12.12 ). В зависимости от условий контракта требования

Относительно интерфейсов системы могут быть включены в Спецификацию системы/подсистемы или в

Спецификацию требований к интерфейсу ( 12.14 ).

Е сли система состоит из подсистем, то предполагают, что работы, указанные в 5.3.3, будут

выполнены итеративно с работами, указанными в 5.4 (проектирование системы) для определения

требований к системе, проектирования системы и идентификации ее подсистем, определения требований к

этим подсистемам, проектировании подсистем, идентификации их компонентов и т.д.

5.3.4 Модифицируемое пользователем ПО. ПО с возможностью выбора вариантов. Коммерчески доступное ПО.

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

пользователем, то пользователи могут изменять ПО в заданном диапазоне без рассмотрения,

осуществляемого сертифицирующей организацией. В этом случае системные требования должны

определить механизмы, которые устраняют влияние на безопасность системы осуществляемой

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

должно иметь уровень, такой как у функции, которую оно защищает от ошибок в

модифицируемом компоненте. При проведении модификации пользователем последний должен

нести ответственность за все аспекты модифицируемого им ПО, например управление конфигурацией,

обеспечение качества и верификацию.

С истемные требования к ПО с возможностью выбора вариантов должны определить средства для гарантии

того, что не может быть сделан несанкционированный выбор.

К оммерчески доступное ПО, включаемое в состав системы, должно удовлетворять требованиям данного

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

ПО, то информация, представленная в них, должна быть расширена, чтобы удовлетворить требования

данного документа.

5.3.5 Системные требования для ПО, загружаемого в полевых условиях

З агружаемое в полевых условиях прикладное ПО - программный продукт или таблицы данных, которые

могут быть загружены без демонтажа системы или оборудования. Требования, определяемые

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

Если нечеткое представление функции загрузки данных ПО может вызвать отказную ситуацию в системе,

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

определены в системных требованиях. Требования обеспечения безопасности системы для ПО,

загружаемого в полевых условиях, следующие:

- обнаружение разрушенного или частично загруженного ПО;

- обнаружение загрузки несоответствующей конфигурации ПО;

- совместимость аппаратных и программных средств;

- совместимость компонентов ПО;

- совместимость типа объекта и ПО;

- отображение потери или искажения идентификации конфигурации ПО.

Требования к ПО, загружаемому в полевых условиях:

 

 

- если процессом оценки безопасности системы не определено специально, то механизму обнаружения

разрушенного или частично загруженного ПО должна быть установлена такая же категория отказной

ситуации или уровень ПО, как наиболее серьезной отказной ситуации или наиболее высокому уровню ПО,

связанному с функцией, которая использует загрузку ПО;

- если для системы определен режим, заданный по умолчанию, в случае, когда загружено

несоответствующее ПО или данные, то для каждого выделенного компонента системы должны быть

указаны требования по обеспечению безопасности, определяющие действия в этом режиме;

- механизм загрузки ПО должен включать в себя программные и/или аппаратные средства для обнаружения

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

- если ПО представляет собой часть встроенного бортового механизма отображения, являющегося

средством гарантии того, что объект соответствует сертифицированной конфигурации, то такое ПО

должно быть либо разработано как ПО с самым высоким уровнем из того, которое должно быть загружено,

либо процесс оценки обеспечения безопасности системы должен подтверждать целостность конфигурации

ПО.

5.3.6 Анализ системных требований при верификации ПО

С истемные требования разрабатывают на основе эксплуатационных требований к системе и требований,

связанных с обеспечением безопасности, которые являются выходным результатом процесса оценки

безопасности системы.

В системных требованиях для прикладного ПО устанавливают следующие характеристики ПО:

- ПО должно выполнять специфицированные функции, как определено системными требованиями;

- ПО не должно проявлять аномального поведения, не определяемого процессом оценки безопасности

системы. Должны быть сформулированы дополнительные системные требования для обработки

возможного аномального поведения.

С истемные требования должны быть переработаны затем в требования верхнего уровня к ПО, которые

проверяются работами процесса верификации ПО.

5.3.7 Анализ ПО при верификации системы

Т ребования по выполнению верификации системы выходят за область применения настоящего стандарта.

Однако процессы жизненного цикла ПО поддерживают процесс верификации системы и взаимодействуют

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

быть доступными при выполнении верификации системы. Верификация системы может обеспечивать

значительное покрытие структуры кода. Для достижения критериев тестового покрытия, описанных в

Плане верификации ПО, может быть использован анализ покрытия ПО тестами верификации системы.

Проектирование системы

Р азработчик должен принимать участие в проектировании системы. Если систему разрабатывают для

нескольких различных построений, то ее проект не может быть полностью определен до завершения всех

построений. Разработчик должен идентифицировать части проекта системы, которые будут определены в

каждом построении.

5.4.1 Проектные решения системного уровня

Р азработчик должен принимать участие в определении и документировании проектных решений

системного уровня (таких, как решения, относящиеся к проектированию режимов работы системы, и

решения, влияющие на выбор и проектирование компонентов системы).

Р езультаты должны быть включены в раздел проектных решений системного уровня документа

«Описание проекта системы/подсистемы» ( 12.15 ). В зависимости от условий контракта часть

проекта, имеющая отношение к интерфейсам, может быть включена в Описание проекта системы/

подсистемы или в Описание проекта интерфейса ( 12.17 ), а часть проекта, имеющая отношение к базам

данных, - в Описание проекта системы/подсистемы или в Описание проекта базы данных ( 12.18 ).

П римечание - Проектные решения являются прерогативой разработчика, если они формально не

преобразованы в требования в процессе выполнения контракта. Разработчик ответствен за выполнение

всех требований и демонстрацию этого выполнения посредством квалификационного тестирования

(8.5.4). Реализация проектных решений, действующих как «внутренние требования» разработчика,

должна быть подтверждена внутренним тестированием разработчика, выполнение которого нет

необходимости демонстрировать заказчику.

5.4.2 Проектирование архитектуры системы

Р азработчик должен участвовать в определении и документировании проекта архитектуры системы

(идентификации компонентов системы, их интерфейсов и концепции их совместного выполнения) и

прослеживании соответствия между компонентами системы и системными требованиями. Результат этих

работ должен быть включен в документ «Описание проекта системы/подсистемы» ( 12.15 ).

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

включена в Описание проекта системы/подсистемы или в Описание проекта интерфейса ( 12.17 ).


Поделиться:



Последнее изменение этой страницы: 2017-05-05; Просмотров: 568; Нарушение авторского права страницы


lektsia.com 2007 - 2024 год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! (0.065 с.)
Главная | Случайная страница | Обратная связь