Приложение Б (справочное). Методы/средства для исключения систематических отказов СБЗС-систем

Приложение Б
(справочное)

Методы/средства для исключения систематических отказов СБЗС-систем (см. ГОСТ Р 53195.3 и ГОСТ Р 53195.4)

Примечания

1 Часть мер (методов/средств) данного приложения относятся к методам/средствам для программного обеспечения, но они не дублируют методы/средства, приведенные в приложении В.

2 Методы/средства, представленные в настоящем приложении, не являются исчерпывающими. СБЗС-системы непрерывно развиваются, и методы/средства исключения систематических отказов совершенствуются. При выборе конкретных методов/средств следует ориентироваться, в первую очередь, на стандартизованные методы/средства. В случае применения новых методов/средств всегда следует формировать и сохранять доказательственные материалы, демонстрирующие эффективность новых методов/средств по сравнению с методами/средствами, приведенными в настоящем приложении.

Б.1 Общие методы и средства

Б.1.1 Управление проектами

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.3 (таблицы Б.1 - Б.6).

Цель: устранение отказов путем совершенствования организационной модели, правил и средств по разработке и тестированию СБЗС-систем.

Описание: наиболее значимыми являются методы/средства, направленные:

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

- на установление в руководствах по взаимосвязанным проектам и конкретным проектам регулирующих правил, мер и мероприятий для создания и оценки соответствия СБЗС-систем;

- на применение следующих наиболее важных базовых принципов:

- выбор проектной организации и установление:

- задач и ответственности подразделений организаций;

- уполномочивающих подразделений по обеспечению качества;

- порядка обеспечения независимого от разработчика подтверждения качества (внутреннее инспектирование);

- на определение и принятие плана последовательных действий (модели действий):

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

- дополнение (обновление) проекта;

- на определение стандартной последовательности для внутреннего инспектирования:

- планирование, выполнение и проверка инспектирования (теория инспектирования);

- разделение механизмов для комплектующей продукции;

- сохранение результатов повторных проверок;

- на управление конфигурацией:

- администрирование и проверка версий;

- обнаружение влияний модификаций;

- согласование инспектирования после модификаций;

- на введение количественной оценки мер по обеспечению качества:

- установление требований;

- статистика отказов;

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

Стандартизованные методы/средства по аспектам менеджмента качества, менеджмента риска и управления проектами подробно описаны в ГОСТ Р ИСО 9000, ГОСТ Р ИСО 9001, ГОСТ Р ИСО 10006, ГОСТ Р ИСО/МЭК 16085.

Б.1.2 Документация

Примечания

1 На этот метод/средство дана ссылка в ГОСТ Р 53195.3 (таблицы Б.1 - Б.6).

2 См. также ГОСТ Р 53195.2 (раздел 5 и приложение A).

Цель: устранение отказов и упрощение оценки соответствия СБЗС-систем требованиям безопасности с помощью систем документирования каждого шага процесса разработки.

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

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

- руководств, которые:

- устанавливают требования к групповому плану;

- имеют контрольный список содержания;

- устанавливают формат документа;

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

К индивидуальным средствам относятся:

- разделение в документации:

- требований к системе;

- описания системы (документации пользователя);

- описания разработки (включая внутреннюю инспекцию);

- группирование проектной документации в соответствии с жизненным циклом СБЗС-системы;

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

- ясная идентификация составляющих частей документаций;

- формализованное обновление версий;

- выбор ясных и понятных средств описания:

- формализованная нотация определений;

- естественный язык для введений, обоснований и представления намерений;

- графическое представление примеров;

- семантическое определение графических элементов;

- директории специальных слов.

Следует ориентироваться на стандартизованные требования к документации. Эти требования подробно описаны в [55], а также устанавливаются в документах по стандартизации системы программной документации.

Б.1.3 Разделение систем, связанных с безопасностью, и систем, не связанных с безопасностью

Примечание - На этот метод/средство дана ссылка в МЭК ГОСТ Р 53195.3 (таблицы Б.1 и Б.6).

Цель: предотвращение влияния связанных с безопасностью систем на системы, не связанные с безопасностью, в непредвиденных ситуациях.

Описание: в спецификации требований к СБЗС-системам должно быть определено, возможно ли разделение систем, связанных с безопасностью, и систем, не связанных с безопасностью. Должны быть установлены соответствующие четкие требования по этому вопросу. Четкое разделение требований снижает затраты на тестирование СБЗС-систем.

Более подробное описание этих требований приведено в [18, 54].

Б.1.4 Разнообразие аппаратных средств

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.3 (таблицы A.16, A.17 и A.19).

Цель: обнаружение систематических отказов при выполнении действий УО, с использованием разнообразных компонентов с различными частотами и типами отказов.

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

Б.2 Спецификация требований к безопасности СБЗС-систем

Глобальная цель: разработка спецификации требований к СБЗС-системе, которая, по возможности, должна быть полной, не содержащей ошибок, свободной от противоречий и простой для проверки.

Б.2.1 Структурирование спецификации

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.3 (таблицы Б.1 и Б.6).

Цель: уменьшение сложности спецификации требований к СБЗС-системе, а также исключение ошибок интерфейсов между требованиями путем создания иерархической структуры частичных требований.

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

Более подробные описания стандартизованных структурируемых требований приведены в [55-58].

Б.2.2 Формальные методы

Примечание - На эти методы/средства дана ссылка в ГОСТ Р 53195.3 (таблицы Б.1 и Б.6).

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

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

Формальные методы/средства могут в общем случае предоставлять нотацию (в основном некоторые методы дискретной математики), средства для вывода описания в этой нотации и различные виды анализа для проверки на корректность различных свойств описаний.

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

Более подробное описание формальных методов/средств приведено в ГОСТ Р МЭК 61160.

Б.2.3 Полуформальные методы

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

Примечание - На эти методы/средства дана ссылка в ГОСТ Р 53195.3 (таблицы Б.1, Б.2 и Б.6) и в ГОСТ Р 53195.4 (таблицы A.1, A.2 и A.4).

Б.2.3.1 Общие положения

Цель: удостовериться в том, что проект удовлетворяет своей спецификации.

Описание: полуформальные методы представляют собой методы/средства создания описания системы на стадиях ее разработки, например при разработке спецификации, при проектировании или кодировании. Описание может быть в некоторых случаях проанализировано на ЭВМ или поддержано средствами анимации для отображения различных аспектов поведения системы. Анимация позволяет получить дополнительную уверенность в том, что система удовлетворяет как реальным требованиям, так и специфицированным требованиям.

Два полуформализованных метода описаны ниже.

Б.2.3.2 Метод конечных автоматов/диаграммы переходов состояний

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблицы Б.5 и Б.7).

Цель: моделирование, подготовка спецификации или реализация структуры управления системы.

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

Когда система усложняется или имеет естественную структуру, это может быть отражено в уровневой структуре автомата конечных состояний.

Спецификация или проект, выраженный в виде автомата конечных состояний, может быть проверен:

- на полноту (система должна иметь действие и новое состояние для каждого входа в каждом состоянии);

- на согласованность (только одно изменение состояния описывается для каждой пары состояние/вход);

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

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

Подробное описание данных методов/средств приведено в [57-59].

Б.2.3.3 Метод сетей Петри

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблицы Б.5 и Б.7).

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

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

Сеть Петри - это сеть позиций и переходов. Позиции могут быть "маркированными" или "немаркированными". Переход "активизирован", когда все его входы маркированы. В активизированном состоянии позиции разрешается (но не требуется) быть "возбужденной". Если позиция "возбуждена", вход, поступающий на переход, становится немаркированным, а вместо этого каждый выход из перехода оказывается маркированным.

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

Подробное описание сетей Петри приведено в [60-65].

Б.2.4 Автоматизированные средства разработки спецификации

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.3 (таблицы Б.1 и Б.6) и в ГОСТ Р 53195.4 (таблицы A.1 и A.2).

Б.2.4.1 Общие положения

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

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

Подробное описание этих методов/средств приведено в [57-59].

Б.2.4.2 Инструменты, не ориентированные на конкретный метод

Цель: предоставление пользователю с помощью подсказок и формирования связей между соответствующими частями возможности составления правильной спецификации.

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

Подробное описание этих методов/средств приведено в [57-59].

Б.2.4.3 Процедура, ориентированная на модель с иерархическим анализом

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

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

Подробное описание метода/средства приведено в [57-59].

Б.2.4.4 Сущностные модели

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

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

Подробное описание метода/средства приведено в [66-68].

Б.2.4.5 Стимул и отклик

Цель: предоставление пользователю возможности создания правильной спецификации путем идентификации взаимоотношений "стимул - отклик".

Описание: взаимоотношения между объектами системы определены в нотациях "стимулы" и "отклики". Используется простой и легко расширяемый язык, который содержит элементы языка, представляющие объекты, взаимоотношения, характеристики и структуры.

Подробное описание данного метода/средства приведено в [69, 70].

Б.2.5 Таблица контрольных проверок

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.3 (таблицы Б.1, Б.2 и Б.6) и в ГОСТ Р 53195.4 (таблицы A.10 и Б.8).

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

Описание: метод/средство включает в свой состав набор вопросов, на которые должно дать ответ лицо, заполняющее таблицу контрольных проверок. Многие вопросы носят общий характер, и эксперт должен интерпретировать их как наиболее подходящие к конкретной оцениваемой системе. Таблицу контрольных проверок можно использовать на всех этапах всего жизненного цикла СБЗС-системы, жизненных циклов аппаратных средств и программного обеспечения. Метод/средство полезно в качестве инструмента, способствующего оценке функциональной безопасности.

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

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

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

Б.2.6 Экспертиза спецификации

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.3 (таблицы Б.1 и Б.6).

Цель: исключение некомплектности и противоречивости спецификации.

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

Более подробное описание метода/средства приведено в ГОСТ Р МЭК 61160.

Б.3 Проектирование и разработка СБЗС-систем

Глобальная цель: создание проекта СБЗС-системы в соответствии со спецификацией.

Б.3.1 Соблюдение стандартов и руководств

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.3 (таблица Б.2).

Цель: рассмотрение стандартов сектора применения (не устанавливаемых в настоящем стандарте) на предмет правильного их использования при разработке и проектировании СБЗС-системы.

Описание: при проектировании СБЗС-системы должны составляться руководства. Эти руководящие материалы должны, во-первых, приводить к созданию СБЗС-систем, которые практически свободны от ошибок, и, во-вторых, упрощать последующее подтверждение соответствия требованиям безопасности. Они могут быть универсальными, установленными только для данного проекта или установленными только для отдельного его этапа.

Б.3.2 Структурное проектирование

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.3 (таблицы Б.2 и Б.6).

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

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

- проектирование иерархически структурированных схем;

- использование изготовленных и прошедших тестирование частей схем.

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

Структурное проектирование более подробно описано в [70, 71].

Б.3.3 Использование надежно испытанных компонентов

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.3 (таблицы Б.2 и Б.6).

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

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

Более подробное описание этого метода/средства приведено в [72].

Б.3.4 Модульное проектирование

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.3 (таблицы Б.2 и Б.6).

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

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

Более подробное описание метода/средства приведено в [73, 74].

Б.3.5 Средства автоматизированного проектирования

Примечание - На эти средства дана ссылка в ГОСТ Р 53195.3 (таблицы Б.2 и Б.6) и в ГОСТ Р 53195.4 (таблица A.4).

Цель: обеспечение наиболее систематического выполнения процедур проектирования. Включение в проект подходящих автоматически спроектированных элементов, которые уже созданы и проверены.

Описание: инструменты автоматизированного проектирования (САПР) должны использоваться в процессе проектирования как АС, так и ПО во всех случаях, когда они доступны и обоснованы сложностью системы. Правильность выбора таких инструментов должна быть продемонстрирована конкретным тестированием, обширной предысторией удовлетворительного использования либо независимой верификацией результата их применения для конкретной проектируемой СБЗС-системы.

Более подробно методы/средства автоматизированного проектирования описаны в [75, 76].

Б.3.6 Моделирование

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.3 (таблицы Б.2, Б.5 и Б.6).

Цель: выполнение систематической и полной проверки электрических/электронных схем, их функционирования, а также корректное задание размеров их компонентов.

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

Этот метод/средство более подробно описан в [75, 76].

Б.3.7 Проверка (обзор и анализ)

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.3 (таблицы Б.2 и Б.6).

Цель: выявление рассогласований между спецификацией и реализацией.

Описание: заданные функции СБЗС-системы проверяют и оценивают для гарантирования того, что СБЗС-система соответствует требованиям, приведенным в спецификации. Все сомнительные вопросы относительно реализации и использования системы документируются с целью их последующего разрешения. В отличие от сквозного анализа во время процедуры проверки автор пассивен, а эксперт активен.

Б.3.8 Сквозной анализ

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.3 (таблица Б.6).

Цель: выявление рассогласования между спецификацией и реализацией.

Описание: заданные функции СБЗС-системы оцениваются для гарантирования того, что СБЗС-система соответствует требованиям, приведенным в спецификации. Все сомнительные вопросы относительно реализации и использования системы документируются с целью их последующего разрешения. В отличие от процедуры проверки во время сквозного анализа автор проекта активен, а эксперт пассивен.

Б.4 Процедуры эксплуатации и обслуживания СБЗС-систем

Глобальная цель: разработка процедур, исключающих ошибки во время эксплуатации и обслуживания СБЗС-систем.

Б.4.1 Инструкции по эксплуатации и обслуживанию

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.3 (таблица Б.4).

Цель: минимизация ошибок во время эксплуатации и обслуживания СБЗС-систем.

Описание: инструкции пользователя содержат важную информацию о способах использования и обслуживания систем. В особых случаях эти инструкции могут содержать также примеры общих способов установки СБЗС-систем. Все инструкции должны быть легко воспринимаемыми. Для описания сложных процедур и зависимостей должны использоваться рисунки и схемы.

Б.4.2 Удобство общения пользователя с системой

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.3 (таблица Б.4).

Цель: снижение сложности действий, выполняемых оператором во время эксплуатации СБЗС-систем.

Описание: правильность эксплуатации СБЗС-систем может зависеть в некоторой степени от оператора. Рассматривая соответствующий проект системы и проект рабочего места, разработчик СБЗС-систем должен предусмотреть меры, чтобы в период эксплуатации систем обеспечивалось следующее:

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

- необходимое вмешательство оператора было как можно более простым;

- возможность ущерба от ошибок оператора была минимизирована;

- средства вмешательства и средства индикации были спроектированы в соответствии с эргономическими требованиями;

- средства оператора были простыми, четко обозначенными и естественными для использования;

- оператор не был перенапряжен даже в экстремальной ситуации;

- обучение процедурам и средствам процесса вмешательства было адаптировано к уровню знаний и мотивации обучаемого оператора (пользователя).

Б.4.3 Удобство общения обслуживающего персонала с системой

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.3 (таблица Б.4).

Цель: упрощение процедуры обслуживания СБЗС-системы и проектирование необходимых средств для эффективной диагностики и ремонта.

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

- средства, относящиеся к техническому обслуживанию СБЗС-системы, требовались как можно реже или в идеале вообще не требовались;

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

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

Б.4.4 Сокращение работ на стадии эксплуатации

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.3 (таблицы Б.4 и Б.6).

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

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

- ограничения числа требуемых операций в рабочих режимах, например благодаря применению пультов управления;

- ограничения числа используемых в работе элементов контроля и управления;

- ограничения числа возможных в обычных условиях эксплуатации рабочих режимов.

Б.4.5 Эксплуатация только квалифицированным оператором

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.3 (таблицы Б.4 и Б.6).

Цель: исключение отказов, обусловленных ошибками оператора.

Описание: оператор СБЗС-системы должен быть обучен до такой степени, которая соответствует сложности и уровню безопасности СБЗС-системы. В обучение входит изучение основ технологического процесса эксплуатации СБЗС-системы и взаимосвязей между СБЗС-системой и УО.

Б.4.6 Защита от ошибок оператора

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.3 (таблица Б.6).

Цель: защищенность системы от всех прогнозируемых видов ошибок оператора.

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

Б.4.7 Защита от модификаций

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.3 (таблица A.18).

Цель: защита СБЗС-системы от модификаций аппаратных средств техническими средствами.

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

Б.4.8 Подтверждение ввода

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.3 (таблицы A.18 и A.19).

Цель: обеспечение обнаружения ошибки во время работы самим оператором до активизации УО.

Описание: ввод данных управления в УО через СБЗС-систему отображается оператору до передачи их в УО, с тем чтобы оператор имел возможность обнаружить и исправить ошибки. Проект системы должен как реагировать на неправильные, неспровоцированные действия оператора, так и учитывать нижние/верхние пределы скорости и направление реакции человека. Этим можно исключить, например, более быстрое, чем предполагается, нажатие клавиш оператором и настроить систему на восприятие двойного нажатия клавиши как одинарное или как повторное из-за того, что система (например, изображение на экране) слишком медленно реагирует на первое нажатие клавиши. Последовательное нажатие одной и той же клавиши не должно действовать более одного раза при вводе критических данных; нажатие клавиши "ввод" (enter) или "да" (yes) неограниченное количество раз не должно приводить к нарушению безопасности системы.

Должны быть предусмотрены процедуры временных пауз с возможностью выбора разных ответов ("да"/"нет" и т.п.), чтобы обеспечить возможность для размышления оператору, а системе - режим ожидания.

Недостаточная способность к перезагрузке СБЗС-системы делает ее уязвимой, если только программные/аппаратные средства не спроектированы с учетом этой ситуации.

Этот метод/средство более подробно описан в [77].

Б.5 Интеграция E/E/PE СБЗС-систем

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

Б.5.1 Функциональное тестирование

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.3 (таблица Б.3) и в ГОСТ Р 53195.4 (таблицы A.5 - A.7).

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

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

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

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

Более подробно этот метод/средство описан в [78-81].

Б.5.2 Тестирование методом "черного ящика"

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.3 (таблицы Б.3, Б.5 и Б.6) и в ГОСТ Р 53195.4 (таблицы A.5 - A.7).

Цель: проверка динамического поведения системы в реальных условиях функционирования; выявление несоответствия функциональной спецификации и оценка полезности и устойчивости.

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

- данных из допустимых диапазонов;

- данных из недопустимых диапазонов;

- данных предельных значений диапазонов;

- экстремальных значений;

- комбинаций перечисленных выше классов.

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

Более подробное описание этого метода/средства приведено в [62-64].

Б.5.3 Статистическое тестирование

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.3 (таблицы Б.3, Б.5 и Б.6).

Цель: проверка динамического поведения СБЗС-системы и оценка ее полезности и устойчивости.

Описание: статистическое тестирование выполняется с входными данными, выбранными в соответствии с операционным (эксплуатационным) профилем, который отражает частоту выполнения пользователем различных операционных сценариев работы. Именно операционный профиль "руководит" выбором тестов, результаты которых образуют статистическую выборку для выполнения контроля. Это означает, что первыми будут обнаруживаться отказы наиболее часто используемых компонентов системы и устраняться дефекты в наиболее часто выполняемых фрагментах кода.

Более подробное описание этого метода/средства приведено в [84-87].

Б.5.4 Натурные испытания

Примечания

1 На этот метод/средство дана ссылка в ГОСТ Р 53195.3 (таблицы Б.3 и Б.5).

2 В контексте ПО см. также аналогичные средства в В.2.10 настоящего стандарта, а в приложении Г - статистический подход.

Цель: использование натурных (полевых) испытаний в качестве одного из средств исключения неисправностей во время интеграции СБЗС-систем и/или в процессе подтверждения соответствия требованиям безопасности СБЗС-систем.

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

При использовании натурных испытаний должны быть соблюдены следующие требования:

- неизменность спецификации;

- 10 систем в различных применениях;

- часов работы и по меньшей мере один год сервисной поддержки.

Натурные испытания документируются производителем (поставщиком) и/или эксплуатирующей компанией. Эта документация должна содержать, по меньшей мере, следующие данные:

- точное обозначение (идентификацию) системы и ее компонентов, включая компоненты управления версией АС;

- сведения о пользователях и времени применения;

- время наработки в часах;

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

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

Данный метод/средство применим в большей степени к отдельным составляющим (подсистемам) СБЗС-систем. Его более подробное описание приведено в [88, 89].

Б.6 Оценка соответствия СБЗС-системы требованиям безопасности

Глобальная цель: оценка соответствия СБЗС-системы спецификации требований безопасности.

Б.6.1 Функциональное испытание в условиях окружающей среды

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.3 (таблица Б.5).

Цель: оценка, защищена ли СБЗС-система от типичных воздействий окружающей среды.

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

Стандартизованные требования к ряду воздействий подробно описаны в [58-60, 62, 90].

Б.6.2 Испытание на устойчивость к пиковым выбросам внешних воздействий

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.3 (таблицы Б.5 и Б.6).

Цель: проверка способности СБЗС-систем в условиях пиковых выбросов внешних электромагнитных воздействий.

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

Б.6.3 Статический анализ

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.3 (таблицы Б.5 и Б.6) и в ГОСТ Р 53195.4 (таблица A.9).

Цель: исключение систематических неисправностей, которые могут приводить к отказам в тестируемой системе вначале или после многих лет эксплуатации.

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

- анализ согласованности потока данных;

- анализ управления потоком (определение маршрутов, определение кода недоступности);

- анализ интерфейсов (исследование передачи переменных между различными программными модулями);

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

- применение тестирования к конкретным руководящим материалам (например, по вопросам: длина пути утечки тока и зазоры, расстояние между совокупностями модулей, расположение физических модулей, механически чувствительные физические модули, индивидуальное использование физических модулей при их внедрении).

Б.6.4 Динамический анализ

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.3 (таблицы Б.5 и Б.6) и в ГОСТ Р 53195.4 (таблицы A.5 и A.9).

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

Описание: динамический анализ СБЗС-систем выполняется, если подавать на вход близкой к эксплуатационному образцу элемента (модуля) системы, связанной с безопасностью, входные данные, типичные для заданного эксплуатационного окружения. Анализ признается удовлетворительным, если наблюдаемое поведение СБЗС-системы соответствует требуемому поведению. Любой отказ СБЗС-системы должен быть устранен, после чего следует проанализировать новые варианты эксплуатации.

Б.6.5 Анализ отказов

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.3 (таблицы Б.5 и Б.6).

Б.6.5.1 Виды отказов и анализ их последствий

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

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

Виды отказов и анализ их последствий подробно описаны в [89-91].

Б.6.5.2 Диаграммы последовательностей событий

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблицы A.10, Б.3 и Б.4).

Цель: моделирование СБЗС-системы с помощью диаграмм последовательностей событий для представления проекта системы в виде последовательности комбинаций базовых событий.

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

Диаграммы последовательности событий более подробно описаны в [92, 93].

Б.6.5.3 Анализ дерева событий

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица Б.4).

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

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

Более подробное описание этого метода/средства приведено в ГОСТ 27.310 и [94].

Б.6.5.4 Виды неисправностей, анализ влияний и анализ критичности

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблицы A.10 и Б.4).

Цель: ранжирование критичности компонентов, могущих вызвать нарушения, повреждения или ухудшение работы СБЗС-системы при одиночных ошибках, для определения, каким компонентам может потребоваться особое внимание и какие средства управления необходимы для обеспечения процессов проектирования или эксплуатации.

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

Более подробное описание данного метода/средства приведено в [95].

Б.6.5.5 Анализ дерева неисправностей

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица Б.4).

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

Описание: начиная с события, которое может непосредственно вызвать опасность или серьезные последствия ("вершины дерева событий"), анализ выполняют по ветвям дерева. Комбинации причины описываются логическими операторами (И, ИЛИ, НЕ и т.п.). Затем анализируют промежуточные причины тем же способом и т.д., возвращаясь к базовым событиям, по достижении которых анализ прекращают.

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

Более подробное описание данного метода/средства приведено в [96].

Б.6.6 Анализ наихудшего случая

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.3 (таблицы Б.5 и Б.6).

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

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

Более подробное описание данного метода/средства приведено в [97].

Б.6.7 Расширенные функциональные испытания

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.3 (таблицы Б.5 и Б.6).

Цель: обнаружение неисправностей на стадиях составления спецификации, проектирования и разработки системы; проверка поведения СБЗС-системы в случаях ввода редко встречающихся или неспецифицированных видов данных.

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

Более подробное описание данного метода/средства приведено в [98].

Б.6.8 Испытание в наихудших случаях

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.3 (таблицы Б.5 и Б.6).

Цель: тестирование ситуаций, специфицированных во время анализа наихудших случаев.

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

Б.6.9 Испытание с введением неисправностей

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.3 (таблицы Б.5 и Б.6).

Цель: внесение отказов в АС системы или их имитация и документирование реакции системы.

Описание: в настоящем стандарте представлен качественный метод оценки зависимости поведения системы от внесенных или имитированных неисправностей. Для описания местоположения и типа неисправностей, а также способа их внесения обычно используют детализированные функциональные блоки, принципиальные и структурные схемы. Например, электропитание может не поступать в различные модули; линии электропитания, линии общей шины или адресные линии могут быть разомкнуты или короткозамкнуты; компоненты или их порты могут быть разомкнуты или закорочены; реле могут быть замкнуты или разомкнуты, либо их действия могут выполняться в неправильные моменты времени и т.д. Возникающие в результате отказы системы классифицируют, например, как в МЭК 60812 (таблицы I и II), см. [99]. Обычно вводят одиночные неисправности в устойчивом состоянии системы. Однако в случае, когда тестом встроенной диагностики неисправность не обнаруживается или оказывается неочевидной, она может сохраниться в системе и вызвать следующую неисправность. При этом число неисправностей может быстро возрасти до сотен.

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

Более подробное описание данного метода/средства приведено в [90, 95].