Скачать гост р мэк 61508-6

У нас вы можете скачать скачать гост р мэк 61508-6 в fb2, txt, PDF, EPUB, doc, rtf, jar, djvu, lrf!

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

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

Этот унифицированный подход был принят для разработки рациональной и последовательной технической политики для всех электрических систем обеспечения безопасности. При этом основной целью является содействие разработке стандартов для продукции и областей применения на основе стандартов серии МЭК Примечание - Примерами стандартов для продукции и областей применения, разработанных на основе стандартов серии МЭК , являются [1]-[3]. Обычно безопасность достигается за счет использования нескольких систем, в которых используются различные технологии например, механические, гидравлические, пневматические, электрические, электронные, программируемые электронные.

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

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

В то же время понятия "безопасный отказ" и "безопасный в своей основе отказ" могут быть использованы, но для этого необходимо обеспечить соответствующие требования в конкретных разделах стандарта, которым эти понятия должны соответствовать. Краткий обзор требований МЭК и МЭК и определение функциональной последовательности их применения содержится в приложении A. Пример методики расчета вероятности отказа аппаратных средств содержится в приложении B, которое следует применять совместно с МЭК пункт 7.

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

Примеры применения таблиц полноты безопасности программного обеспечения, приведенных в МЭК приложение A , для уровней полноты безопасности 2 и 3 описаны в приложении E. МЭК , пункт 3. Функция безопасности настоящего стандарта не применима к медицинскому оборудованию, удовлетворяющему требованиям серии горизонтальных стандартов МЭК [1]. В этом случае требования, методы проверки или условия проверки настоящего основополагающего стандарта по безопасности не будут применяться, если на них нет конкретной ссылки, или они не включены в публикации, подготовленные этими техническими комитетами.

Общие требования IEC Требования к программному обеспечению IEC Примеры методов определения уровней полноты безопасности IEC Анализ методов и средств IEC Overview of techniques and measures. В настоящем стандарте применены термины, определения и сокращения по МЭК Аварии оборудования могут возникать по причине физических отказов устройств неожиданные аварии оборудования , либо систематических отказов ошибки человека в технических условиях и конструкции конкретной системы при определенной комбинации причин приводят к систематическим отказам , либо некоторых внешних условий.

Основная задача настоящего стандарта заключается в том, чтобы установки и оборудование были обеспечены автоматизированными системами безопасности, а его основная цель состоит в предотвращении: Оценка риска основана на оценке как последствий или серьезности , так и частоты или вероятности опасного события. Уровень полноты безопасности 4 является наивысшим, а уровень полноты безопасности 1 - низшим см.

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

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

МЭК , раздел 8. Необходимы методы и средства, направленные против как случайных, так и систематических отказов аппаратных средств. Они, как указано выше, включают в себя соответствующую комбинацию средств по предотвращению неисправностей и управлению отказами. Если для обеспечения функциональной безопасности необходимы действия оператора, то приводятся требования к интерфейсу оператора.

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

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

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

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

МЭК , рисунок 4. Функциональные этапы применения МЭК представлены на рисунке A. Примечание - В ПЭ системах, связанных с безопасностью, для программного обеспечения выполняются аналогичные действия см.

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

Для каждой подсистемы компонента определяют: МЭК , приложение C. МЭК , пункт 7. МЭК , подпункт 7. Примечание - Модель расчета безотказности представляет собой математическую формулу, показывающую взаимосвязь между безотказностью и соответствующими параметрами, связанными с оборудованием и условиями его использования. Сравнивают результат с заданными характеристиками отказов, определенными в перечислении b , и требованиями для способа 1 см.

Примечание - Существует множество методов моделирования, и аналитик должен выбрать наиболее соответствующий перечень некоторых методов, которые могут быть использованы, приведен в приложении B. Выбирают средства и методы для управления систематическими отказами аппаратных средств, отказами, вызванными влиянием окружающей среды, и эксплуатационными отказами см. МЭК , приложение A. МЭК в соответствующие аппаратные средства см. Учитывают аспекты, связанные с программным обеспечением [см.

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

При необходимости выполняют обновление планирования подтверждения соответствия системе безопасности в процессе разработки программного обеспечения. Примечание - На предыдущих стадиях жизненного цикла были: МЭК , подразделы 7.

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

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

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

МЭК , приложение D. Примечание - При выполнении приведенных выше действий допускается применять средства, альтернативные указанным в настоящем стандарте, при условии, что соответствующее обоснование документально оформляется в процессе планирования подтверждения соответствия системе безопасности см.

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

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

Исследуются два марковских подхода: Если для систем безопасности марковский подход не применим, то вместо него может быть использован метод Монте-Карло. На современных компьютерах расчет возможен даже для уровня УПБ4.

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

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

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

МЭК , пункт 3. В качестве основополагающих стандартов по безопасности данные стандарты предназначены для использования техническими комитетами при подготовке стандартов в соответствии с Руководствами МЭК В этом случае требования , методы или условия проверки настоящего основополагающего стандарта по безопасности не будут применяться , если это не указано специально , или будут включаться в стандарты , подготовленные этими техническими комитетами. Рисунок 1 - Структура настоящего стандарта.

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

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

Это решение зависит от многих факторов , включая характер применения , степень выполнения функций безопасности другими системами , а также социальные и экономические факторы см. Уровень полноты безопасности 4 является наивысшим , а уровень полноты безопасности 1 - самым низшим см. МЭК , подпункт 7. Однако следует подчеркнуть , что может быть использован любой эквивалентный подход к описанию жизненного цикла при условии , что в плане обеспечения безопасности проекта будут описаны эквивалентные положения см.

МЭК , раздел 6. В МЭК гарантия того , что нужный уровень полноты безопасности будет удовлетворительным для опасных случайных отказов аппаратных средств , основывается на: МЭК , таблицы 2 и 3 и.

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

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

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

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

Для различных уровней программного обеспечения требуются различные уровни гарантии того , что эти и связанные с ними принципы были правильно реализованы. В любом случае необходимо тесное сотрудничество , особенно при разработке архитектуры программируемой электроники , когда требуется анализировать компромиссы между архитектурами аппаратных средств и программного обеспечения на предмет их вклада в обеспечение безопасности см. МЭК , рисунок 4. Функциональные этапы применения МЭК представлены в настоящем приложении , рисунки А.

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

МЭК , подраздел 7. При необходимости анализ повторяют. Эту модель разрабатывают , проверяя отдельно каждую функцию безопасности , и определяют подсистему компонент , используемую для реализации этой функции. Для каждой подсистемы компонента определяют: МЭК , приложение С ;. МЭК , приложение С. МЭК , таблицы 2 и 3.

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

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

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

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

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

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

Обзор каждого из методов и средств со ссылками на источники информации о них , включая перекрестные ссылки на эти таблицы , представлен в МЭК , приложение С. Примеры применения таблиц полноты безопасности приведены в приложении Е настоящего стандарта , а МЭК включает в себя описание вероятностного подхода к определению полноты безопасности программного обеспечения для уже разработанного программного обеспечения см. МЭК , приложение D.

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

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

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

Примечание - Среднее время восстановления включает в себя время , необходимое для обнаружения отказа в соответствии с МЭК , подпункт 7. В настоящем приложении предполагаемое значение среднего времени восстановления одинаковое как для обнаруженных , так и необнаруженных отказов и включает в себя длительность диагностического тестирования , а не интервал между тестовыми испытаниями.

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

Пример - Если предполагаемое среднее время восстановления равно 8 ч , то оно включает в себя длительность диагностического тестирования , которое обычно не превышает 1 ч , а оставшаяся часть среднего времени восстановления - это действительное время ремонта. Примечание - Для канальных архитектур 1 оо 2, 1 oo 2 D и 2оо3 предполагается выполнение любого ремонта в оперативном режиме. Степень уменьшения вероятности зависит от диагностического покрытия ;. Примечание - Время безопасной работы определяется в МЭК , подпункт 7.

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

Средняя вероятность отказа по запросу для подсистемы датчиков. Средняя вероятность отказа по запросу для логической подсистемы. Средняя вероятность отказа по запросу для подсистемы оконечных элементов. Эквивалентное среднее время простоя канала для архитектур 1оо1, 1оо2, 2оо2 и 2оо3 это объединенное время простоя для всех компонентов канала подсистемы , ч.

Эквивалентное среднее время простоя голосующей группы для архитектур 1оо1, 1оо2, 2оо2 и 2оо3 это объединенное время простоя для всех каналов в голосующей группе , ч. Эквивалентное среднее время простоя канала для архитектуры 1 oo 2 D это объединенное время простоя для всех компонентов канала подсистемы , ч. Эквивалентное среднее время простоя голосующей группы для архитектуры 1 oo 2 D это суммарное время простоя для всех каналов в голосующей группе , ч.

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

Представляют каждую подсистему как одну либо более голосующих групп 1 оо 1, 1 оо 2, 2 оо 2, 1 oo 2 D или 2оо3. Данные таблицы предполагают , что среднее время восстановления для любого отказа после его обнаружения равно 8 ч. PFD Gi и PFD Gj - средние вероятности отказа в обслуживании для каждого из голосующей группы датчика или оконечного элемента , соответственно.

Данная архитектура предполагает использование одного канала , и любой опасный отказ приводит к нарушению функции безопасности при возникновении запроса на ее выполнение. Эквивалентное среднее время простоя канала t CE можно рассчитать , суммируя времена простоя для двух компонентов , t C 1 и t C 2 , прямо пропорционально вкладу каждого компонента в вероятность отказа канала: Среднюю вероятность отказа выполнения функции безопасности канала PFD в течение времени простоя t CE определяют из выражения.

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

Структурная схема и схема расчета надежности архитектуры 1 оо 2 приведены на рисунках В. Значение t CE вычисляют в соответствии с В. Для данной архитектуры 1 оо 1 средняя вероятность отказа по запросу PFD G равна.

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

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

Структурная схема и схема расчета надежности архитектуры 1 oo 2 D представлены на рисунках В. Значения эквивалентного среднего времени простоя отличаются от значений , приведенных для других архитектур в В. Эти значения определяют как. Средняя вероятность отказа по запросу PFD G для данной архитектуры равна. Данная архитектура состоит из трех каналов , соединенных параллельно с мажорированием выходных сигналов так , что выходное состояние не меняется , если результат , выдаваемый одним из каналов , отличается от результата , выдаваемого двумя другими каналами.

Предполагается , что любое диагностическое тестирование только фиксирует найденные сбои и не может изменить ни выходные состояния каналов , ни результат голосования. Структурная схема и схема расчета надежности архитектуры 2оо3 представлены на рисунках В. Значение t CE вычисляют по В. Рассмотрим функцию безопасности , для реализации которой нужна система SIL 2.

Пусть построенный на основе предыдущего опыта первоначальный вариант архитектуры всей системы включает одну группу из трех аналоговых датчиков давления с архитектурой 2оо3 на входе. Логическая подсистема рассматриваемой системы представляет собой PES с избыточностью с архитектурой 1оо2 D и управляет одним закрывающим и одним дренажным клапаном , так как для обеспечения функции безопасности необходима работа как закрывающего , так и дренажного клапана.

Архитектура всей системы представлена на рисунке В. Примечание - Настоящая таблица представляет собой фрагмент таблицы В. Данные , представленные в таблицах В. Следовательно , для функции безопасности: Для перевода системы , представленной на рисунке В.

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

Ниже приведен пример такой зависимости для архитектуры 1 оо 2, где T 2 - время между запросами к системе: В рассматриваемом примере расчеты проводились при следующих предположениях: То же , что и метод вычисления для режима низкой интенсивности запросов см.

Так как рассматриваемые в настоящем приложении вероятности малы , то используют формулу. PFH S - вероятность отказа в час для подсистемы датчиков ;. PFH L - вероятность отказа в час для логической подсистемы ;. PFH FE - вероятность отказа в час для подсистемы оконечных элементов. Структурная схема и схема расчета надежности архитектуры 1 оо 1 представлены на рисунках В.

Если предположить , что система , связанная с безопасностью , при обнаружении любого отказа переводит EUC в безопасное состояние , то для архитектуры 1 оо 1. Структурная схема и схема расчета надежности архитектуры 1 оо 2 представлены соответственно на рисунках В. Значение t CE вычисляют по формуле , приведенной в В. Вероятность отказа PFH G для архитектуры 1 оо 2 вычисляют по формуле. Структурная схема и схема расчета надежности архитектуры 2 оо 2 представлены соответственно на рисунках В.

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