Товары в корзине: 0 шт Оформить заказ

Купить ГОСТ Р 27.016-2020 — бумажный документ с голограммой и синими печатями. подробнее

Цена на этот документ пока неизвестна. Нажмите кнопку "Купить" и сделайте заказ, и мы пришлем вам цену.

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

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

Способы доставки

  • Срочная курьерская доставка (1-3 дня)
  • Курьерская доставка (7 дней)
  • Самовывоз из московского офиса
  • Почта РФ

 Скачать PDF

Модифицирован (MOD) IEC 62853:2018

Оглавление

Предисловие

Введение

1 Область применения

2 Нормативные ссылки

3 Термины и определения

4 Надежность открытых систем

5 Соответствие

6 Анализ процесса обеспечения надежности открытой системы

Приложение A (справочное). Пример моделей жизненного цикла для обеспечения надежности открытых систем

Приложение B (справочное). Образец свидетельства надежности

Приложение C (справочное). Интеллектуальная электросеть

Приложение ДА (справочное). Сведения о соответствии ссылочных национальных стандартов международным стандартам, использованным в качестве ссылочных в примененном международном стандарте

Библиография

 
Дата введения01.07.2021
Добавлен в базу01.01.2021
Актуализация01.01.2021

Этот ГОСТ находится в:

Организации:

06.08.2020УтвержденРосстандарт472-ст
РазработанЗАО НИЦ КД

Dependability in technics. Open systems dependability

Нормативные ссылки:

ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

ГОСТР

27.016—

2020

(МЭК 62853:2018)


Надежность в технике НАДЕЖНОСТЬ ОТКРЫТЫХ СИСТЕМ

(IEC 62853:2018, Open systems dependability, MOD)

Издание официальное


Москва

Стандартинформ

2020


Предисловие

1    ПОДГОТОВЛЕН Закрытым акционерным обществом «Научно-исследовательский центр контроля и диагностики технических систем» (ЗАО «НИЦ КД») на основе собственного перевода на русский язык международного стандарта, указанного в пункте 4

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 119 «Надежность в технике»

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 6 августа 2020 г. N? 472-ст

4    Настоящий стандарт является модифицированным по отношению к международному стандарту МЭК 62853:2018 «Надежность открытых систем» (IEC 62853:2018 «Open systems dependability». MOD) путем внесения технических отклонений, объяснение которых приведено во введении к настоящему стандарту.

Международный стандарт разработан Техническим комитетом МЭК 56.

Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5-2012 (пункт 3.5).

Сведения о соответствии ссылочных национальных стандартов международным стандартам, использованным в качестве ссылочных в примененном международном стандарте, приведены в дополнительном приложении ДА

5    ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N9 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (vvwiv.gosf.ru)

© IEC. 2018 — Все права сохраняются © Стандартинформ. оформление. 2020

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

4.4    Обеспечение надежности открытых систем

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

a)    установление понимания всеми заинтересованными сторонами системы ее цели, функционирования. окружающих условий и изменений и затем установление общей структуры понимания и четкого соглашения по всем этим вопросам;

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

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

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

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

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

4.5    Взаимосвязь устойчивости системы с отказоустойчивостью

Концепция устойчивости очень похожа для открытых и традиционных систем. Традиционное понятие устойчивости системы (см. 3.16. примечание 1) подчеркивает способность системы возвратиться к нормальному функционированию после нарушений работы, в то время как надежность открытых систем охватывает тот факт, что даже определение «нормальной эксплуатации» изменяется время от времени или в зависимости от точки зрения. Более свежая концепция устойчивости (примечание 2 в 3.16) рассматривает более широкий диапазон изменений и применима к надежности открытых систем. Различие состоит в том. что надежность открытых систем сосредоточена на случаях, где изменения и потребность в адаптации следуют из открытости системы, следовательно, сосредоточена на консенсусе и ответственности (подотчетности) заинтересованных сторон на всех стадиях жизненного цикла системы.

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

5 Соответствие

Для подтверждения надежности открытых систем на стадиях жизненного цикла системы необходимо представить свидетельства надежности, которые должны обеспечить демонстрацию следующего [8]. {9J.

а) обеспечения жизненным циклом системы выполнения установленных требований ко всем процессам. установленным в разделе 6;

b) адекватности этих требований для обеспечения надежности рассматриваемой системы.

Примечания

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

2    Открытым системам не свойственен набор достаточных условий. Каждое применение настоящего стандарта оценивают на соответствие требованиям с учетом качества дополнительного рассмотрения этого применения [см. перечисление Ь)] относительно особенностей текущей цели.

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

6 Анализ процесса обеспечения надежности открытой системы

6.1 Общие положения

В разделе 6 приведено описание четырех видов анализа процесса, которые связаны с четырьмя подходами, установленными в 4.4 [см. перечисления а) — d)]. Часть действий и задач, необходимых для выполнения процессов, приведена в соответствии с [1].

Каждый подход к надежности открытых систем требует выполнения ряда действий и задач, которые проходят сквозь стадии жизненного цикла. Концепция анализа процесса введена для того, чтобы объединить в группу связанные между собой действия, как описано в [1] (см. [1], приложение Е).

В разделе 6 приведены четыре вида анализа процесса в соответствии с точкой зрения, установленной в [1]. Анализ процесса проводят на основе следующей информации:

a)    наименование анализа процесса;

b)    цели анализа процесса:

c)    результаты анализа процесса:

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

В разделе 6 установлен каждый из четырех видов анализа процесса с учетом перечислений а) — d).

Эти четыре вида анализа процесса выполняют совместно для достижения целей надежности открытых систем. Вместе с процессами жизненного цикла системы и другими видами анализа процесса они формируют модель жизненного цикла системы, как это требуется в соответствии с [1J (см. [1], приложение А).

Примечания

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

2    В предпоследнем абзаце 4.4 показано соотношение между четырьмя видами анализа процесса. В приложении А.2 подробно описаны соотношения на примере модели жизненного цикла.

В остальной части раздела 6 каждый подпункт (т. е. 6./) обеспечивает анализ процесса и организован следующим образом.

Наименование подпункта 6./ является наименованием анализа процесса (а).

В 6./.1 «Цель» установлена цель анализа процесса (Ь). В первом абзаце установлена основная цель, а в следующих абзацах приведены пояснения.

В 6.л2 «Результаты» перечислены выходы (результаты) процесса (с). В некоторых случаях результаты представлены иерархически. В приложении В представлена структура аргументов для свидетельств надежности, использующих результаты. Это обеспечивает некоторые соотношения для выбора результатов.

Содержание 6./.3 «Процессы, действия и задачи» представляет собой основную часть настоящего стандарта. Представлен перечень процессов, действий и задач (d). установленных в (1). которые осуществляют анализ процесса вместе с рекомендациями по реализации надежности открытых систем. Для каждого процесса, указанного в [1], приведен дополнительный абзац, в котором описана его связь с анализом процесса, а также приведено более подробное описание соответствующих действий и задач с признаками результатов анализа процесса. Описания в б.г'.З должны быть использованы вместе с описаниями в [1], которые обеспечивают определение и условия применения связанных процессов, действий и задач.

В б./'.З приведены ссылки на разделы [1J и настоящего стандарта. Их различают следующим образом. Угловые скобки (< >) использованы для обозначения номера раздела в [1] и нриведени наиме-нование элемента перечня действий или задач процесса. Например. «<6.4.2> Процесс определения требований и потребностей заинтересованных сторон» относится к 6.4.2 из [1]. а в пределах содержания <6.4.2>, «<а)1)>» относится к задаче «1) Идентификация заинтересованных сторон, которым необходимы сведения о системе в течение всего жизненного цикла» в пределах действия, «а) Подготовка определения требований и потребностей заинтересованных сторон». Для двухуровневого перечня ссылки на элемент перечня уровня 1. например «<а)>». относится ко всем элементам уровня 2 <а)1)>, <а).2)>.... <а)л)>. которые составляют элемент уровня 1 <а)>. Квадратные скобки ([)) использованы для ссылки на элемент перечня результатов анализа процесса в 6./.2 настоящего стандарта.

6.2 Анализ процесса достижения консенсуса

6.2.1    Цель

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

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

Цель анализа может быть достигнута при осознании следующего.

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

Установление общего понимания и четких соглашений обеспечивает общие превентивные меры по отношению к непредвиденным событиям.

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

Достижение цели включает следующее:

-    установление общего понимания и четких соглашений среди заинтересованных сторон [6.2.2. результаты а)1) — а)7)];

-    поддержка понимания и соглашений [Ь)1) — Ь)5)].

Связь между целью и результатами анализа описана в В.2.

6.2.2    Результаты

а) Установлены общее понимание и четкие соглашения между заинтересованными сторонами.

1)    Идентифицированы заинтересованные стороны системы.

Примечание 1 — Перечень заинтересованных сторон изменяется во времени в зависимости от точки зрения.

2)    Установлена структура базового понимания для всех заинтересованных сторон. Эта структура включает термины и основные предположения об окружающей среде системы.

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

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

Примечание 2 — Конфликты интересов могут включать в себя права на интеллектуальную собственность.

5)    На основе понимания [см. 3)] разработаны и документированы четкие соглашения. Записи включают отчеты о разработке и причинах, по которым различные компоненты соглашений можно считать целесообразными и выполнимыми.

6)    Различия в интерпретации документов соглашения находятся в пределах приемлемого диапазона.

7) Результаты, указанные выше, достигнуты справедливым и беспристрастным для всех заинтересованных сторон способом.

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

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

Ь) Осуществляется поддержка общего понимания и четкого соглашения среди заинтересованных стирои.

1)    Установлена политика управления изменениями соглашений.

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

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

Примечание 6 — Такие изменения могут потребоваться на этапе реагирования и восстановления после отказа.

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

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

Примечание 8 — Консенсус гложет быть ограничен частью действий или некоторыми заинтересованными сторонами, в то время как изменения остальных действий или заинтересованных сторон изменения не оказывают влияния. Заинтересованные стороны могут решить не принимать участия в вопросах, которые не имеют для них значения или имеют незначительное значение. Часто действиями управляет небольшая группа назначенных заинтересованных сторон, в то время как остальная часть заинтересованных сторон соглашается с этим, пока работа является для них приемлемой и их жизненно важные интересы не затронуты.

Примечание 9 —Действия для вовлечения заинтересованных сторон описаны в ГОСТ Р ИСО 60300-1. пункт 5.3 (третье перечисление).

4)    Определена ответственность за выполнение и одобрение свидетельства надежности.

5)    Достижение консенсуса, записи о его разработке и причины, по которым консенсус считают допустимым и осуществимым, зарегистрированы в отчете о свидетельствах надежности (см. [9J).

6.2.3 Процессы, действия и задачи

Анализ процесса достижения консенсуса должен быть выполнен с использованием действий и задач следующих процессов (см. [1J).

Примечание 1 — Далее в угловых скобках (< >) указаны номера подпунктов и их наименования в [1]. В квадратных скобках ([ J) указаны элементы перечня результатов анализа процесса из настоящего стандарта. Более подробная информация приведена в последнем абзаце 6.1.

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

-    <а)1)>: Стратегия приобретения должна быть направлена на достижение общего понимания и четких соглашений в соответствии с [а)].

-    <с)1), с)4)>: Разработку и согласование изменений соглашения между покупателем и поставщиком необходимо проводить справедливо и внимательно (а)7)].

-    <d)>: Мониторинг соглашения является частью политики и направлен на точную поддержку соглашения [Ь)1). Ь)2), Ь)3)].

-    <d)1)>: Оценка выполнения соглашения должна включать оценку его справедливости и беспристрастности [а)7)].

<6.1.2> Процесс поставки устанавливает и поддерживает соглашение между покупателем и поставщиком. которое является частью четких соглашений в соответствии с [а). Ь)]. Поставщики должны

Ю

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

-    <а)1)>: Идентификация покупателей является частью идентификации заинтересованных сторон (а)1)].

-    <а)2)>: Стратегия поставки должна разъяснять способы ее выполнения (а)).

-    <с)1), с)4), d)1)>: Согласование соглашения и его выполнение должны быть реализованы справедливо и беспристрастно [а)7)].

-    <d)2)>: Оценка выполнения соглашения должна включать оценку его справедливости и беспристрастности [а)7)].

<6.2.1 > Процесс управления моделью жизненного цикла должен установить связи между процессами жизненного цикла, что позволяет получить все результаты анализа процесса (а), Ь)).

<6.2.5> Процесс менеджмента качества формулирует аспекты общего понимания и четких соглашений в виде управляемых показателей качества. Он также управляет качеством общего понимания и четких соглашений [а). Ь)).

-    <а)1)>: Политика, цели и процедуры менеджмента качества должны быть направлены на уровень общего понимания и согласия по отношению к точным соглашениям (а), Ь)]. Заинтересованные стороны должны выработать общее понимание и четкие соглашения относительно менеджмента качества, учитывая, что не существует одной организации, которая осуществляет менеджмент качества системы в целом (а), Ь)].

-    <а)2), а)3)>: Общее понимание менеджмента качества должно признавать, что определение обязанностей и критериев оценки несовершенно и может быть изменено, а заинтересованные стороны должны быть готовы действовать, когда необходимо, вне определенной для них ответственности ради всеобщего качества [Ь)].

-    <а)3)>: Критерии оценки должны быть справедливыми и беспристрастными (а)7)).

<6.2.6> Процесс менеджмента знаний обеспечивает общее понимание.

-    <а)1), Ь)1), с)1)>: Стратегия менеджмента знаний, классификация разделения и систематизации знаний в организации должны обеспечить структуру базового понимания всех заинтересованных сторон (а)2)].

-    <d)>: Поддержка знаний должна быть интегрирована в поддержку общего понимания и четких соглашений [Ь)].

<6.3.1 > Процесс планирования проекта воплощает общее понимание и четкие соглашения, такие как планы (а). Ь)].

-    <а). Ь)1) — Ь)6)>: Определение и планирование проекта (цели, ограничения, область применения. модель жизненного цикла, структура распределения работ, график, критерии выполнения стадий жизненного цикла, затраты и бюджет, функции, обязанности, ответственность персонала и т. д.) должны отражать общее понимание и четкие соглашения и. в свою очередь, углублять и разъяснять их, формируя основу их поддержки [а)2). а)3). а)5). а)6). Ь)1), Ь)2), Ь)3)].

-    <Ь)4)>: Ответственность за свидетельства надежности должна быть определена в планах проекта (Ь>4)).

-    <Ь)7)>: Планы обмена информацией и выполнения анализа должны быть частью разработки и поддержки четких соглашений; анализ должен обеспечивать и документировать обоснование положений соглашений (а)5). Ь)2). Ь)5)].

<6.3.2> Процесс оценки и управления проектом направлен на поддержание общего понимания и четких соглашений при появлении изменений.

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

<6.3.3> Процесс менеджмента принимаемых решений обеспечивает разрешение конфликтов, возникающих при установлении и поддержании общего понимания и четких соглашений, а также управляет решениями по принятию единодушных мнений (а), Ь)].

-    <а)1)>: Стратегия менеджмента принимаемых решений должна включать предварительно согласованный арбитражный процесс (а}4)].

-    <а)3)>: Помимо заинтересованных сторон с конфликтом интересов те стороны, интересы которых затрагивают решения, должны быть идентифицированы и вовлечены [а)1). а)7)].

-    <Ь)2)>: Желаемый результат и критерии выбора должны быть определены справедливым и беспристрастным способом при помощи рекурсивного применения анализа процесса достижения консенсуса [а)6), а)7)].

и

-    <с)2). с)3)>: Записи резолюций, обоснования решений и предположений, прослеживания и оценки должны обеспечить учет формирования консенсуса и доказательства его справедливости и беспристрастности (а)7). Ь)5)].

Примечание 2 — Инициирование анализа процесса достижения консенсуса и инициирование процесса менеджмента принимаемых решений являются взаимно рекурсивными. Достижение консенсуса требует принятия решения, и каждое решение требует консенсуса по желаемым результатам и критериям выбора.

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

-    <а)1), а)5)> Стратегия управления информацией и действиями по поддержке информации должна включать политику управления изменениями соглашений [Ь)1)]. поддержку консенсуса заинтересованных сторон [Ь)2)), анализ процесса достижения консенсуса [Ь)3)]. Эти действия должны сократить различив интерпретаций [а)6>] и поддерживать справедливость и беспристрастность для всех заинтересованных сторон (а)7)].

-    <а)2)>: Управляемые элементы информации должны включать перечень идентифицированных заинтересованных сторон [а)1)]. структуру ссылок [а)2)], понимание цели системы и т. д. (а)3)], согласованный арбитражный процесс (а)4)], четкие соглашения [а)5)], свидетельства надежности [Ь)4)]. учет разработок и обоснование консенсуса (Ь)5)].

-    <а)3)>: Назначение обязанностей и полномочий по управлению информацией включает назначение обязанностей и полномочий в области свидетельства надежности (Ь)4)].

-    <а}4)>: Форматы и структура элементов информации являются частью структуры в соответствии с [а)2)]. их содержание должно отражать общее понимание [а)3), а)5)].

-    <Ь)1 )>: Разработка информации о четких соглашениях должна признавать согласованный арбитражный процесс разрешения конфликта интересов [a)4)J. Структура в соответствии с установленной в [а)2)] должна быть использована для преобразования информации в информацию, полезную для заинтересованных сторон.

-    <Ь)5)>: Изъятие информации с учетом разработки четких соглашений и их обоснования (Ь)5)] должно быть выполнено только после внимательного рассмотрения значения информации для изменения договорениостей и обеспечения ответственности на более позднее время, включая случаи, когда они появляются в результате реагирования на отказ.

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

-    <Ь). с)>: Оценка продукции или услуги и процесса должна быть частью поддержки общего понимания и четких соглашений (b)1), b)2)j.

-    <d)>: Запись действий по обеспечению качества должна обеспечивать отчет о достижении консенсуса (Ь)5)].

-    <е)>: Обработка проблем должна включать анализ необходимости модификации общего понимания и четких соглашений и их процессов (Ь)1), Ь)2), Ь)3)].

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

-    <а)2), Ь)2)>: Стратегия анализа и определение проблем области применения должны разъяснить структуру базового и общего понимания, они также должны быть справедливыми и беспристрастными (а)2), а)3), а)7)].

-    <Ь)1)>: После анализа проблемы должно быть получено подтверждение, что все заинтересованные стороны разделяют одно и то же понимание области применения, основ или причин проблем и возможностей, указанных в <Ь)1) примечание 1> (а)2), а)3), а)6)].

-    <с)1)>: Идентификация основных групп заинтересованных сторон должна учитывать, что заинтересованные стороны могут изменяться во времени, и каждая заинтересованная сторона может по своему понимать, какие субъекты являются основными группами заинтересованных сторон системы; каждая заинтересованная сторона должна быть идентифицирована вместе с ее функциями [а)1)]: предварительные концепции эксплуатации должны включать политику относительно функций системы, которая выражает общее понимание (а)2)].

-    <с)2)>: Идентифицированные классы решений должны быть распределены среди всех заинтересованных сторон, и каждая заинтересованная сторона должна быть в состоянии рассмотреть решения со своей точки зрения для обеспечения справедливости и беспристрастности (а)3), а)7)].

-    <d)>: Выполняющий оценку и метод оценки должны быть идентифицированы и согласованы всеми заинтересованными сторонами (а)7)].

-    <е)1 )>: Прослеживаемость результатов анализа до и после изменений должна быть поддержана в дополнение к прослеживаемости результатов анализа и других артефактов в одной итерации жизненного цикла [Ь)2), Ь)5)] (см. <6.4.1.1, примечание 2>).

<6.4.2> Процесс определения потребностей и требований заинтересованных сторон разрабатывает общее понимание и четкие соглашения относительно цели системы и т. д. в виде определения потребностей и требований заинтересованных сторон (а)3). а)5)].

-    <а)1)>: Идентификация заинтересованных сторон должна учитывать, что заинтересованные стороны могут изменяться во времени и каждая заинтересованная сторона может по-своему понимать, какие субъекты являются заинтересованными сторонами системы; каждая заинтересованная сторона должна быть идентифицирована вместе с ее функциями (а)1)].

-    <а)2)>: Стратегия определения потребностей и требований заинтересованных сторон должна обеспечивать справедливое и беспристрастное разрешение различных мнений и конфликтов, что помогает обеспечивать гарантию и целостность системы (а)4). а)7)] (см. <6.4.2.3 а)2) примечание»); стратегия должна быть направлена на достижение общего понимания политики в отношении функций системы (а)3)).

-    <Ь)1)>: Определение условий использования системы должно устранить разногласия в предположениях заинтересованных сторон справедливым и беспристрастным образом (а)2), а)3). а)7)].

-    <Ь)2). Ь)3), Ь)4)>: При определении явных и неявных потребностей следует обратить особое внимание на <Ь)2), примечание 1>; потребности заинтересованных сторон должны быть выявлены вместе с их предположениями о системе и ее среде; следует учесть, что различия в предположениях могут стать очевидными только после некоторого периода эксплуатации; различия, препятствующие обмену информацией о надежности среди заинтересованных сторон, могут быть препятствием в достижении консенсуса и могут привести к нерациональным решениям (а)2). а)3)]; сбор информации, идентификация. выбор и определение потребностей заинтересованной стороны должны быть справедливыми и беспристрастными (а)7)].

-    <с)>: Концепция эксплуатации должна включать политику относительно функций системы, которая должна отражать общее понимание (а)2)].

-    <f)>: Необходимо управлять изменениями определения потребностей и требований заинтересованных сторон [Ь)].

<6.4.3> Процесс определения требований к системе преобразовывает консенсус заинтересованных сторон в конкретные требования к системе. Это облегчает техническое обслуживание, как и оценку результатов анализа этого процесса [а). Ь)].

-    <Ь). с)>: До того как выбран особый набор технических требований, заинтересованные стороны должны достигнуть консенсуса относительно ожидаемых последствий и рисков, соответствующих этому набору для каждой заинтересованной стороны (а)5). а)6). а)7)].

<6.4.4> Определение структуры обеспечивает часть структуры исходных сведений и четких соглашений (а)2), а)5)].

-    <b)1)>: С точки зрения структуры необходимо формировать структуру исходного базового понимания (а)2)].

-    <f)2)>: Четкое принятие структуры должно формировать часть соглашений (а)5)).

<6.4.9> Процесс верификации является частью оценки четкого соглашения [а)6). Ь)2)).

-    <с)3)>; Согласие заинтересованной стороны с тем, что система соответствует требованиям, является частью четких соглашений в соответствии с [а)5)].

<6.4.11> Процесс валидации является частью оценки четких соглашений [а)6), Ь)2)].

6.3 Анализ процесса обеспечения ответственности

6.3.1 Цель

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

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

Примечания

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

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

Цель анализа может быть достигнута при осознании следующего.

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

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

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

Достижение цели состоит из следующих действий:

-    установление связи между нарушением соглашения и его последствиями, которое включает обязательства ответственных заинтересованных сторон обеспечивать средства устранения последствий до событий, для работы с которыми назначена ответственность [6.3.2 результаты а) — е)];

-    выполнение действий предупреждения и реагирования на события, для выполнения которых назначена ответственность (f) — h)J;

-    представление достоверной информации заинтересованным сторонам и обществу в целом [от i)1) до i)5)].

Связь между целью и результатами анализа описана в приложении В.З.

6.3.2 Результаты

a)    Идентифицированы ключевые решения по управлению жизненным циклом системы и риски жизненного цикла системы, включая управление результатами процессов и анализа процессов.

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

b)    Для каждого ключевого решения по управлению жизненным циклом системы и контролю риска в процессе жизненного цикла системы идентифицировано ответственное физическое и юридическое лицо.

c)    Для каждого элемента каждого четкого соглашения идентифицированы ключевые решения, которые могут вызвать его отказ или нарушение.

Примечание 2 — Для нарушения соглашения, вызванного факторами вне системы, составляющие ключевые решения включают принятие риска и принятие результатов анализа несоответствующего риска.

Примечание 3 — Заинтересованные стороны, ответственные за нарушение соглашения, являются ответственными за ключевые решения, идентифицированные в качестве возможных причин нарушения.

d)    Для каждого нарушения каждого четкого соглашения оценены воздействия этого нарушения на неответственные заинтересованные стороны и общество в целом.

Примечание 4 — Оценка включает анализ контроля этих воздействий ответственными заинтересованными сторонами с имеющимися у них полномочиями и ресурсами.

Примечание 5 — Каждый элемент каждого четкого соглашения сформулирован так. что такой анализ возможен.

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

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

Примечание 7 — Соглашение относительно последствий и средств защиты от нарушения базового соглашения включает рассмотрение случая, когда нарушение вызвано изменениями, не рассмотренными в перечислениях а) — d).

0 Проводятся мониторинг и оценка ожидаемых и непредвиденных воздействий принятых решений на систему. В том числе мониторинг нарушения соглашений.

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

Примечание 8 — Обратные связи распознают непреднамеренные результаты и инициируют соответствующие действия.

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

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

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

i)    Ответственные заинтересованные стороны своевременно представляют неответственным заинтересованным сторонам и обществу в целом достоверную и уместную информацию.

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

Примечание 12 — Информация является достоверной и уместной, хогда она является всесторонней (1); понятной для получателей (2), позволяющей каждому получателю уменьшить собственный вред от отказа (3) и обоснованной и достоверной с точки зрения получателей.

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

2)    Заинтересованные стороны имеют правомерную уверенность и доверие к предоставленной информации о системе.

3)    После отказа достоверная и уместная информация выбрана и представлена заинтересованным сторонам конкретной системы, заинтересованным сторонам связанных систем и общественности.

Примечание 13 — Информация формируется в результате анализа процесса реагирования на отказ.

4)    Информация об изменениях требований к системе, ожиданий от работы системы, описания и показателей системы выбрана и представлена заинтересованным сторонам конкретной системы, заинтересованным сторонам связанных систем и общественности.

5)    При обнаружении информация о расхождениях в требованиях, ожиданиях, описаниях и показателях системы выбрана и предоставлена заинтересованным сторонам системы, заинтересованным сторонам связанных систем и общественности.

6.3.3 Процессы, действия и задачи

Анализ процесса обеспечения ответственности должен быть выполнен с использованием действий и задач процессов, приведенных в [1].

<6.1.1 > Процесс приобретения

- <с)>: Установление соглашения между покупателем и поставщиком (включая критерии приемки и обязанности покупателя) включает ключевые решения, управляющие жизненным циклом системы (а)];

их невыполнение является нарушением соглашения; ключевые решения, приводящие к нарушению и т. д„ должны быть идентифицированы в соответствии с (b), с), d), е)].

-    <d)>: Мониторинг соглашения является частью обратных связей (f). g)J.

<6.1.2> Процесс поставки

-    <с)>: Установление соглашения между покупателем и поставщиком, включая критерии приемки и обязательности покупателя, включает ключевые решения, управляющие жизненным циклом системы (а)]; его невыполнение является нарушением соглашения, ключевые решения, приводящие к нарушению и т. д., должны быть идентифицированы (b), с), d), е)]. Поддержка соглашения также должна обеспечивать результаты [0. д)].

-    <е)4)>: Ответственность за продукцию или услугу должна быть преобразована таким образом, чтобы гарантировать непрерывное достижение результатов (f), g), h), i)].

<6.2.1 > Процесс управления моделью жизненного цикла

-    <а)3)>: Установление функций и т. д. должно включать идентификацию физического или юридического лица, ответственного за каждое ключевое решение (Ь)].

-    <а)4)>: Определение бизнес-критериев и способов управления стадиями жизненного цикла включает ключевые решения (а). Ь)]. Отчеты об этих разработках должны быть документированы [i)].

-    <а)5)>: Установленный стандарт моделей жизненного цикла должен определить связи между процессами жизненного цикла, которые дают возможность получения всех результатов анализа процесса обеспечения ответственности [от а) до i)J.

<6.2.3> Процесс управления портфолио должен идентифицировать ключевые решения относительно управления взаимодействием между жизненными циклами системы и других систем (а)].

-    <а)3)>: Определение ответственности и полномочий является частью достижения (а). Ь)] и должно рассматриваться (с), d). е)] совместно.

-    <а)5)>: Распределение ресурсов ответственному физическому или юридическому лицу включает ключевые решения в соответствии с (а). Ь)].

-    <с)1)>: Отмена и приостановка проекта должны быть учтены своевременно [i)J.

<6.2.5> Процесс менеджмента качества

-    <а)1). а)3)>: Установление политики менеджмента качества и другого и определение критериев и методов оценки качества включают ключевые решения [а)] и результаты (b). с), d), е), h)]. которые должны быть рассмотрены совместно. Для идентификации и определения должна быть установлена ответственность.

-    <а)2)>: Определение ответственности и полномочий для внедрения менеджмента качества является частью достижения (Ь)].

-    <Ь)>; Оценка удовлетворенности потребителя является частью достижения (d). f). g)J.

-    <с)>: Планирование корректирующих и предупреждающих действий является частью обязательств ответственных заинтересованных сторон (е). h)]; планирование является частью обратных связей [g)J.

<6.2.6> В условиях, когда знания должны быть разделены между несколькими организациями, должен быть внедрен процесс менеджмента знаний (f), g), i)J. Достоверная информация в [i)] должна включать «уроки» прошлого опыта, который ответственные заинтересованные стороны использовали в своих решениях.

<6.3.1> Процесс планирования проекта; все определения и идентификации, осуществленные в этом процессе, включают ключевые решения [а)] и должны быть рассмотрены вместе с |b). с), d), е). h)].

-    <a)4)>: Четкая структура распределения работ должна сопровождаться назначением ответственности и идентификацией уместной информации для распространения (b). i)].

-    <b)4)>: Установленная ответственность должна включать идентификацию информации для распространения в случав отказа системы р)].

-    <Ь)6)>; Планирование приобретения включает ключевые решения (а)] и должно быть рассмотрено вместе с [Ь). с), d). е). h)].

<6.3.2> Процесс оценки и управления проектом

-    <а)1)>: Определение стратегии оценки и управления проектом включает ключевые решения (а)] и должно быть рассмотрено вместе с (b). с), d), е). h)J.

-    <Ь)>: Оценка проекта должна включать оценку в соответствии с [d)]. Результат должен быть обеспечен в информации об ответственности р)].

-    <с)>: Средства управления проектом должны включать обратные связи, упомянутые в (д)]. инициирование корректирующих действий [h)] и представление отчетной информации (i)].

Содержание

1    Область применения..................................................................1

2    Нормативные ссылки..................................................................1

3    Термины и определения................................... 2

4    Надежность открытых систем...........................................................4

5    Соответствие........................................................................7

6    Анализ процесса обеспечения надежности открытой системы................................8

Приложение А (справочное) Пример моделей жизненного цикла для обеспечения надежности

открытых систем.........................................................39

Приложение В (справочное) Образец свидетельства надежности.............................43

Приложение С (справочное) Интеллектуальная электросеть.................................55

Приложение ДА (справочное) Сведения о соответствии ссылочных национальных стандартов международным стандартам, использованным в качестве ссылочных

в примененном международном стандарте..................................60

Библиография........................................................................61

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

-    <а)1). с)3)>: Стратегия менеджмента принимаемых решений должна обеспечивать хорошие обратные связи [g)J.

-    <с)2), с)3)>: Записи о принимаемых решениях должны включать свидетельства того, что ответственность за принятие и контроль решений достигнута [i)J.

<6.3.4> Процесс менеджмента риска: ответственность за менеджмент идентифицированного риска. т. е. мониторинг и обеспечение контроля риска особенно важны. Это должно быть четко определено даже для риска, который не полностью понят [Ь), е). 0- h)].

-    <а)1). d)>: Определение стратегии менеджмента риска и решений по обработке риска включает ключевые решения (а)] и должно быть рассмотрено вместе с [b). с), d). е). h)].

<6.3.5> Процесс управления конфигурацией

-    <Ь), с)>: Идентификация конфигурации технических объектов и изменений в процессе управления конфигурацией включает ключевые решения (а)] и должна быть рассмотрена вместе с (Ь). с), d). e).h)J.

-    <d), е)>: Статус конфигурации, отчетность и оценка конфигурации должны обеспечивать часть достоверной информации в соответствии с [i)]. которая помогает приобрести уверенность и доверие заинтересованных сторон к информации о системе (i)2)].

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

<6.3.6> Процесс управления информацией должен обеспечивать достоверной информацией в соответствии с [i)J. В частности, должны быть достигнуты достаточная уверенность и доверие заинтересованных сторон [i)2)]. При обеспечении информацией необходимо учитывать совместную работу нескольких процессов жизненного цикла.

<а)1)>: Стратегия управления информацией должна поддерживать обратные связи о результатах решений при принятии новых решений [д)].

-    <а)2)>: Все процессы должны инициировать процесс управления информацией для сбора и управления данными о регистрации и другими свидетельствами, которые позволяют установить и обосновать адекватность и достоверность информации об ответственности: должно быть обеспечено объективное представление обоснований [i)2)].

-    <Ь)1 )>: Элементы информации должны быть собраны и использованы вместе с доказательствами их подлинности в форме, допускающей проверку пользователями информации (i)2)].

-    <Ь)3)>: Публикация, распределение или предоставление доступа к информации должны быть выполнены в соответствии с (i)J.

-    <b)5)>: Удаление информации включает ключевые решения. Удаление информации возможно только после внимательного изучения его влияния на обеспечение ответственности в будущем [от а) до i)].

<6.3.7> Процесс измерений должен формировать часть обратных связей (д)].

-    <а)3)>: Для обратных связей следует рассмотреть необходимую информацию для мониторинга непредвиденных результатов (0. g)J.

<6.3.8> Процесс обеспечения качества

-    <а)1)>: Определение стратегии обеспечения качества включает ключевые решения (а)] и должно быть рассмотрено вместе с [b). с), d). е), h)].

<6.4.1 > Процесс анализа деятельности или назначения

-    <с)>: Описание области применения решений должно включать описание ответственности каждой идентифицированной основной заинтересованной стороны (Ь)].

<6.4.2> Процесс определения требований и потребностей заинтересованных сторон

-    <а)1). Ь), с). d)>: Идентификация заинтересованных сторон, определение потребностей заинтересованных сторон, определение концепции эксплуатации и других концепций жизненного цикла и определение требований заинтересованных сторон включают ключевые решения (а)] и должны быть рассмотрены вместе с [b), с), d), е). h)].

-    <b)2). d)3)>: Потребности заинтересованных сторон должны быть идентифицированы вместе с их ответственностью [b). с), d). е). h)].

-    <с)>: Концепция эксплуатации и другие концепции жизненного цикла должны включать определение ответственности основных групп заинтересованных сторон, идентифицированных в <6.4.1 >.

Введение

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

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

Настоящий стандарт детализирует требования ГОСТ Р МЭК 60300-1, поскольку устанавливает дополнительное руководство по менеджменту надежности открытых систем.

В настоящем стандарте приведено руководство по надежности открытых систем, основанное на четырех видах анализа процесса, каждый из которых выбирает и объединяет процессы, действия и задачи жизненного цикла системы в соответствии с [1J:

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

-    анализ процесса обеспечения ответственности;

-    анализ процесса реагирования на отказ;

-    анализ процесса достижения консенсуса.

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

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

В настоящем стандарте ссылки на международные стандарты заменены ссылками на национальные стандарты.

ГОСТ P 27.016—2020 (МЭК 62853:2018)

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Надежность в технике НАДЕЖНОСТЬ ОТКРЫТЫХ СИСТЕМ

Dependability in technics. Open systems dependability

Дата введения — 2021—07—01

1    Область применения

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

В настоящем стандарте детализированы требования ГОСТ Р МЭК 60300-1 по отношению к открытым системам. В настоящем стандарте определены виды анализа процесса на основании требований [1]. где идентифицирован набор процессов жизненного цикла системы.

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

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

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

2    Нормативные ссылки

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

ГОСТ 27.002 Набожность в технике. Термины и определения

ГОСТ IEC 61000-4-30 Электромагнитная совместимость (ЭМС). Часть 4-30. Методы испытаний и измерений. Методы измерений качества электрической энергии

ГОСТ Р 27.003 Надежность в технике. Управление надежностью. Руководство по заданию технических требований к надежности

ГОСТ Р 27.014 (МЭК 62347) Надежность в технике. Управление надежностью. Руководство по установлению требований к надежности систем

ГОСТ Р 27.302 Надежность в технике. Анализ дерева неисправностей

ГОСТ Р ИСО 15489-1 Система стандартов по информации, библиотечному и издательскому делу. Информация и документация. Управление документами. Часть 1. Понятия и принципы ГОСТ Р ИСО 26000 Руководство по социальной ответственности ГОСТ Р ИСО 31000 Менеджмент риска. Принципы и руководство ГОСТ Р ИСО/МЭК 31010 Менеджмент риска. Методы оценки риска ГОСТ Р 51897 Менеджмент риска. Термины и определения

ГОСТ Р 51901.12 (МЭК 60812) Менеджмент риска. Метод анализа видов и последствий отказов ГОСТ Р 51901.14 (МЭК 61078:2006) Менеджмент риска. Структурная схема надежности и булевы методы

Издание официальное

ГОСТ Р 56923/ISO/1EC TR 24748-3:2011 Информационные технологии. Системная и программная инженерия. Управление жизненным циклом. Часть 3. Руководство по применению ИСО/МЭК 12207 (Процессы жизненного цикла программных средств)

ГОСТ Р 57098/1SO/IЕС TR 24774 Системная и программная инженерия. Управление жизненным циклом. Руководство для описания процесса

ГОСТ Р 57100/ISO/1EC/IEEE 42010 Системная и программная инженерия. Описание архитектуры ГОСТ Р 57102/1S07IЕС TR 24748-2:2011 Информационные технологии. Системная и программная инженерия. Управление жизненным циклом. Часть 2. Руководство по применению ИСО/МЭК 15288

ГОСТ Р 58607/ISO/IEC/IEEE 24748-4:2016 Системная и программная инженерия. Управление жизненным циклом. Часть 4. Планирование системной инженерии

ГОСТ Р МЭК 60300-1 Менеджмент риска. Руководство по применению менеджмента надежности (МЭК 60300-1 Менеджмент надежности. Часть 1. Руководство по управлению и применению)

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

3 Термины и определения

В настоящем стандарте применены термины по ГОСТ 27.002, ГОСТ Р 51897 и [2], а также следующие термины с соответствующими определениями.

ИСО и МЭК поддерживают терминологические базы данных для использования в стандартизации по следующим адресам:

-    МЭК Electropedia: доступна на http://www.electropedia.org/;

-    ИСО. Интернет-онлайн-платформа: доступна на http://www.iso.org/obp.

3.1    ответственность (подотчетность) (accountability): Состояние ответственности за решения и деятельность перед руководящими органами организации, правовыми органами и заинтересованными сторонами организации.

Примечание 1 — Ответственность включает ответственность перед обществом в целом.

Примечание 2 — В соответствии с ГОСТ Р ИСО 26000: Ответственность включает обязательства со стороны руководства быть ответственным перед лицами, контролирующими организацию, за выполнение организацией правовых и обязательных требований. Ответственность за общее воздействие решений и действий организации на общество и окружающую среду также подразумевает ответственность организации за нарушения в результате ее решений и действий перед обществом в целом в зависимости от вида воздействий и обстоятельств.

Примечание 3 — Определение по ГОСТ Р ИСО 15489-1: Принцип, в соответствии с которым частные лица, организации и общество ответственны за свои действия.

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

Примечание 1 — В гарантийный случай входят следующие составляющие и их отношения:

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

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

-    доказательная база и. возможно, предположения, поддерживающие эти аргументы для претензии (претензий);

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

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

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

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

Примечание 1 — Консенсус не обязательно подразумевает полное единодушие.

3.5    свидетельства надежности (dependability case): Основанные на фактах аргументированные, прослеживаемые доводы в поддержку утверждения о том, что система удовлетворяет или будет удовлетворять требованиям к надежности.

Примечание 1 — Свидетельства надежности являются гарантийным случаем, в котором заявление высшего уровня относится к надежности.

3.6    обмен информацией о надежности (dependability communication): Непрерывный итеративный процесс, который выполняет заинтересованная сторона для обеспечения, выделения или получения информации и участия в диалоге с другими заинтересованными сторонами в отношении менеджмента надежности.

Примечание 1 — Обмен информацией о надежности в менеджменте надежности открытой системы мало чем отличается от обмена информацией о риске в менеджменте риска.

Примечание 2 — См. определение «обмен информацией и консультации» в ГОСТ Р 51897.

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

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

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

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

3.11    мониторинг (monitoring): Определение состояния системы, процесса или деятельности.

Примечание — При определении состояния может возникнуть необходимость в проведении проверки, наблюдения или глубокого изучения.

3.12    открытая система (open system): Система, границы, функции и структура которой изменяются во времени, по-разному распознаваемая и описываемая с различных точек зрения.

Примечания

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

2    Границы, функции и структура открытой системы не только изменяются во времени, но могут быть неопределенными в любой момент времени, их по-разному распознают различные заинтересованные стороны. Это уточняет определение системы в [2} для данного уровня абстракции и данной точки зрения. Границы могут быть четко определены на одном уровне абстракции, но они могут стать более неопределенными на более детальном уровне. Уровень детализации, необходимый для данной цели или заинтересованной стороны, может быть заранее не предопределен и не обязательно достижим.

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

4    У каждой существующей системы имеются аспекты и открытой системы, и обычной системы. Термин «открытая система» не используют для классификации систем. Термин применяют к системе, когда ее аспекты открытой системы являются существенными в данный момент.

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

3.13    надежность открытых систем (open system dependability): Способность системы адаптироваться к изменениям в целях, задачах, среде, фактическом функционировании и непрерывно обеспечивать ответственность за выполнение ожидаемых функций, как и когда это требуется.

3.14    процесс (process): Совокупность взаимосвязанных и (или) взаимодействующих видов деятельности. использующих входы для получения намеченного результата.

Примечания

1    В зависимости от контекста «намеченный результат» называется выходом, продукцией или услугой.

2    Входами для процесса обычно являются выходы других процессов, а выходы процессов обычно являются входами для других процессов.

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

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

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

6    Термин является одним из числа общих терминов и определений для стандартов ИСО на системы менеджмента, приведенных в приложении SL к Сводным дополнениям ИСО Директив ИСО/МЭК, часть 1. Исходное определение изменено: добавлены примечания 1—5 для разграничения понятий «процесс» и «выход».

3.15    анализ процесса (process view): Набор процессов, действий и задач, который обеспечивает ориентацию на конкретную озабоченность заинтересованных сторон в отношении системы таким способом, что охватывает весь жизненный цикл системы или его части.

3.16    устойчивость организации (resilience): Способность организации к адаптации в сложной и изменяющейся окружающей среде.

Примечания

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

2    Определение в [4]: Постоянство предоставления услуг, которому можно оправданно доверять при изменениях.

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

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

Примечания

1    Некоторые заинтересованные стороны могут иметь интересы, противоречащие интересам других сторон или системы.

2    Термин является одним из числа общих терминов и определений для стандартов ИСО на системы менеджмента.

4 Надежность открытых систем

4.1 Открытые системы

Открытые системы имеют следующие характеристики [5).

-    Открытые системы являются большими, сложными со сложными внутренними взаимосвязями.

-    Открытые системы могут включать компоненты, представляемые в виде черного ящика.

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

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

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

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

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

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

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

Примечание 2 — Некоторые из этих особенностей открытой системы присущи так называемой «системе систем» [6]. [7] и «неограниченным или слабо ограниченным системам».

Примечание 3 — Большая часть систем имеет такие особенности в той или иной степени. Система является открытой, если эти особенности системы являются существенными для работы в данный момент, независимо от того, является ли она системой систем.

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

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

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

По этим причинам, в том числе из-за невероятной сложности и масштаба системы, заинтересованным сторонам очень трудно определить, понять, контролировать систему и управлять системой с достаточной достоверностью. Непредвиденные изменения и отказы в различной степени являются частью особенности системы. Использование термина «открытая система» подчеркивает этот аспект систем.

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

4.2    Особенности надежности открытых систем

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

Менеджмент надежности, установленный в ГОСТ Р МЭК 60300-1. обычно применяют к открытым системам. настоящий стандарт следует использовать вместе с ГОСТ Р МЭК 60300-1. В ГОСТ Р МЭК 60300-1 установлены требования, согласно которым достижение улучшений обеспечено планированием, управлением действиями по улучшению и проведением анализа результатов улучшения. Теория надежности открытых систем детально разработана для открытых систем, в которых надежность непосредственно зависит от улучшений, выполняемых вследствие частых непредсказуемых изменений. Итеративный подход к жизненному циклу может быть применен для аккомодации таких изменений (см. приложение А).

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

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

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

4.3    Цель

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

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

-    непрерывно удалять факторы, вызывающие отказы и. следовательно, улучшать себя;

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

-    предупреждать, минимизировать и смягчать ущерб;

-    непрерывно обеспечивать функции, ожидаемые заинтересованными сторонами, в максимально возможной степени (постепенное ухудшение);

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

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

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