2 В этой причинно-следственной цепочке один и тот же элемент («объект X») может рассматриваться как состояние F функционального блока уровня i, в которое он попадает в результате отказа, а также как причина отказа функционального блока уровня i - 1. Данный «объект X» объединяет концепцию «отказа» в МЭК 61508 и ИСО/МЭК 2382-14, в которой внимание акцентируется на причинном аспекте, как показано на рисунке 4c), и концепцию «отказа» из МЭС 60050(191), в которой основное внимание уделено аспекту состояния, как показано на рисунке 4d). В МЭС 60050(191) состояние F называется отказом, а в МЭК 61508 и ИСО/МЭК 2382-14 оно не определено.
3 В некоторых случаях отказ или ошибка могут быть вызваны внешним событием, таким как молния или электростатические помехи, а не внутренним отказом. Более того, ошибка (в обоих словарях) может возникать без предшествующего отказа. Примером такой ошибки может быть ошибка проектирования.
Рисунок 4 - Модель отказа
3.6.5 случайный отказ аппаратуры (random hardware failure): Отказ, возникающий в случайный момент времени, который является результатом одного или нескольких возможных механизмов ухудшения характеристик аппаратных средств.
Примечания
1 Существует много механизмов ухудшения характеристик, действующих с различной интенсивностью и в различных компонентах. Поскольку допуски изготовления приводят к тому, что компоненты в результате действия этих механизмов отказывают в разное время, отказы оборудования включают в себя много факторов, они происходят с предсказуемой частотой, но в непредсказуемые (т.е. случайные) моменты времени.
2 Основное различие между случайными отказами аппаратуры и систематическими отказами (см. 3.6.6) состоит в том, что интенсивность отказов системы (или другие подобные характеристики таких отказов), связанная со случайными отказами аппаратуры, может быть прогнозируема с достаточной степенью точности, но систематические отказы по своей природе не могут быть предсказаны точно. Это означает, что интенсивность отказов системы, связанных со случайными отказами аппаратуры, может быть охарактеризована количественно с достаточной степенью точности, тогда как отказы системы, связанные с систематическими отказами, не могут быть охарактеризованы статистически с достаточной точностью, поскольку события, приводящие к таким отказам, не могут быть предсказаны.
3.6.6 систематический отказ (systematic failure): Отказ, связанный детерминированным образом с некоторой причиной, который может быть исключен только путем модификации проекта, либо производственного процесса, операций, документации, либо других факторов.
Примечания
1 Корректирующее сопровождение без модификации обычно не устраняет причину отказа.
2 Систематический отказ может быть воспроизведен имитацией причины отказа [МЭС 191-04-19].
3 Примерами причин систематических отказов являются ошибки человека:
- в спецификации требований к безопасности;
- при проектировании, изготовлении, установке или эксплуатации аппаратных средств;
- при проектировании, реализации и т.п. программного обеспечения.
4 В настоящем стандарте отказы в системах, связанных с безопасностью, разделяются на случайные отказы аппаратуры и систематические отказы (см. 3.6.4 и 3.6.5).
3.6.7 опасный отказ (dangerous failure): Отказ, который может привести к тому, что система, связанная с безопасностью, перейдет в опасное состояние или в состояние ошибки при выполнении функции.
Примечание - Будут или не будут реализованы опасные последствия отказа, зависит от канальной архитектуры системы; в многоканальных системах опасные отказы с меньшей вероятностью ведут к итоговому опасному состоянию или состоянию отказа при выполнении функции.
3.6.8 безопасный отказ (safe failure): Отказ, который не переводит систему, связанную с безопасностью, в опасное состояние или в состояние отказа при выполнении функции.
Примечание - Будут или не будут реализованы опасные последствия отказа, зависит от канальной архитектуры системы; в системах с многоканальной архитектурой, предназначенных для повышения безопасности, безопасный отказ аппаратуры приведет к ошибочному отключению с меньшей вероятностью.
3.6.9 зависимый отказ (dependent failure): Отказ, вероятность которого не может быть выражена в виде простого произведения безусловных вероятностей отдельных событий, являющихся причиной отказа.
Примечание - Пусть P(z) вероятность события z. Два события А и В будут зависимы только тогда, когда Р(А+В) > Р(А)×Р(В).
3.6.10 отказ с общей причиной (common cause failure): Отказ, который является результатом одного или нескольких событий, вызвавших одновременные отказы двух и более отдельных каналов в многоканальной системе, ведущие к отказу системы.
3.6.11 ошибка (error): Расхождение между вычисленным, наблюденным или измеренным значением или условием и истинным, специфицированным или теоретически правильным значением или условием.
Примечание - Адаптировано из МЭС 191-05-24 путем исключения примечаний.
3.6.12 ошибка человека (human error, mistake): Действие или бездействие человека, которое может привести к непредусмотренному результату [ИСО/МЭК 2382-14-01-09].
Примечание - Адаптировано из МЭС 191-05-25 путем добавления слов «или бездействие».
3.7 Процессы жизненного цикла
3.7.1 жизненный цикл систем безопасности (safety lifecycle): Необходимые процессы, относящиеся к реализации систем, связанных с безопасностью, проходящие в течение периода времени, который начинается со стадии разработки концепции проекта и заканчивается, когда все Е/Е/РЕ системы, связанные с безопасностью, системы обеспечения безопасности, основанные на иных технологиях, и внешние средства уменьшения риска уже не используются.
Примечания
1 Термин «жизненный цикл систем функциональной безопасности» является более строгим и точным, однако прилагательное «функциональной» не является обязательным в данном случае в контексте настоящего стандарта.
2 Модели жизненного цикла систем безопасности, использованные в настоящем стандарте, приведены в МЭК 61508-1 (рисунки 2-4).
3.7.2 жизненный цикл программного обеспечения (software lifecycle): Процессы, происходящие в течение периода времени, который начинается с появления общей концепции программного обеспечения и заканчивается, когда программное обеспечение окончательно перестает эксплуатироваться.
Примечания
1 Обычно жизненный цикл программного обеспечения включает в себя стадии разработки требований, разработки программного обеспечения, тестирования, интеграции, установки, а также стадию модификации.
2 Программное обеспечение не может поддерживаться, точнее сказать, оно модифицируется.
3.7.3 управление конфигурацией (configuration management): Дисциплина идентификации компонентов системы, для осуществления контролируемых изменений компонентов этой системы и для поддержания преемственности и прослеживания компонентов системы на протяжении всего жизненного цикла.
Примечание - Более подробное описание управления конфигурацией приведено в МЭК 61508-7 (пункт С.5.24).
3.7.4 анализ влияния (impact analysis): Определение влияния, которое оказывает изменение в функции или в компоненте системы на другие функции или компоненты этой системы, а также других систем.
Примечание - В контексте программного обеспечения см. МЭК 61508-7 (пункт С.5.23).
3.8 Подтверждение мер безопасности
3.8.1 верификация (verification): Подтверждение выполнения требований путем исследования и сбора объективных свидетельств.
Примечания
1 Адаптировано из ИСО 8402 путем исключения примечаний.
2 В контексте настоящего стандарта верификация представляет собой выполняемую для каждой стадии жизненного цикла соответствующей системы безопасности (общей, E/E/PES систем и программного обеспечения) путем анализа и/или тестирования демонстрацию того, что для используемых входных данных компоненты удовлетворяют во всех отношениях набору задач и требований для соответствующей стадии.
ПРИМЕР - Процесс верификации включает в себя:
- просмотр выходных данных (документов, относящихся ко всем стадиям жизненного цикла систем безопасности) для того, чтобы убедиться в соответствии задачам и требованиям соответствующей стадии, с учетом конкретных входных данных для этой стадии;
- просмотр проектов;
- тестирование проектируемых продуктов для того, чтобы убедиться, что они работают в соответствии с их спецификациями;
- проверка интеграции, реализуемая внешними тестами, для всех систем, образующихся покомпонентным добавлением к исходной системе, и необходимая для того, чтобы убедиться, что все компоненты работают вместе в соответствии со спецификацией.
3.8.2 подтверждение соответствия (validation): Подтверждение соответствия требованиям путем испытаний и представления объективных свидетельств, выполнения конкретных требований к предусмотренному конкретному использованию.
Примечания
1 Адаптировано из ИСО 8402 путем исключения примечаний.
2 В настоящем стандарте имеется три фазы подтверждения соответствия:
- подтверждение соответствия общей системы безопасности (МЭК 61508-1 (рисунок 2));
- подтверждение соответствия E/E/PES системы (МЭК 61508-1 (рисунок 3));
- подтверждение соответствия программного обеспечения (МЭК 61508-1 (рисунок 4)).
3 Подтверждение соответствия представляет собой демонстрацию того, что рассматриваемая система, связанная с безопасностью, до или после установки удовлетворяет во всех отношениях спецификации требований к безопасности для этой системы. Следовательно, например, подтверждение соответствия программного обеспечения означает подтверждение путем испытаний и сбора объективных свидетельств того, что программное обеспечение удовлетворяет спецификации требований к безопасности программного обеспечения.
3.8.3 оценка функциональной безопасности (functional safety assessment): Исследование, основанное на фактах, предназначенное для того, чтобы оценить функциональную безопасность, достигаемую одной или несколькими Е/Е/РЕ системами, связанными с безопасностью, системами обеспечения безопасности, основанными на других технологиях, или внешними средствами снижения риска.
3.8.4 аудит функциональной безопасности (functional safety audit): Систематическое и независимое исследование, проводящееся с тем, чтобы определить, насколько эффективно реализованы процедуры, предназначенные для того, чтобы требования к функциональной безопасности согласовались с запланированными мероприятиями и насколько они пригодны для достижения поставленных целей.
Примечание - Аудит функциональной безопасности может выполняться как часть оценки функциональной безопасности.
3.8.5 контрольная проверка (proof test): Периодическая проверка, выполняемая для того, чтобы обнаружить отказы в системе, связанной с безопасностью, с тем чтобы при необходимости система могла быть восстановлена настолько близко к «исходному» состоянию, насколько это возможно в данных условиях.
Примечание - Эффективность контрольных проверок зависит от того, насколько близко к «исходному» состоянию восстанавливается система. Для того чтобы контрольная проверка была абсолютно эффективна, она должна быть в состоянии обнаруживать 100 % опасных отказов. Хотя на практике достигнуть 100 % не просто, если только это не Е/Е/РЕ система, связанная с безопасностью, имеющая низкую сложность, однако такая цель должна стоять. По крайней мере, все выполняемые функции безопасности должны проверяться в соответствии со спецификацией требований к безопасности E/E/PES системы. При использовании отдельных каналов эти проверки выполняются для каждого канала отдельно.
3.8.6 диагностический охват (diagnostic coverage): Частичное уменьшение вероятности опасных отказов аппаратуры, связанное с выполнением автоматических диагностических проверок.
Примечания
1 Определение может быть также представлено с помощью следующего уравнения, где DC представляет собой охват диагностический, λDD - вероятность обнаруженных опасных отказов, a λtotal - вероятность всех опасных отказов:
2 Охват диагностический может относиться ко всей системе, связанной с безопасностью, или к ее части. Например, охват диагностический может относиться к датчикам и/или к логической системе, и/или к концевым элементам.
3 Термины «охват безопасных отказов диагностикой» или «охват диагностический», включая безопасные отказы, используют соответственно для описания относительного уменьшения вероятности безопасных отказов или и опасных, и безопасных отказов в результате выполнения автоматических диагностических проверок.
3.8.7 интервал диагностических проверок (diagnostic test interval): Интервал между неавтономными проверками, предназначенными для того, чтобы обнаружить отказы в системах обеспечения безопасности с заданным охватом диагностикой.
3.8.8 обнаруженный (detected): По отношению к аппаратным средствам - выявленный с помощью диагностических проверок, контрольных проверок, вмешательства оператора (например, физического осмотра и ручной проверки) либо в ходе нормальной работы.
ПРИМЕР - Эти прилагательные используются для обнаруженных сбоев и обнаруженных отказов.
3.8.9 необнаруженный (undetected): По отношению к аппаратному обеспечению - не выявленный с помощью диагностических проверок, контрольных проверок, вмешательства оператора (например, физического осмотра и ручной проверки) либо в ходе нормальной работы.
ПРИМЕР - Это прилагательное используется для необнаруженных сбоев и необнаруженных отказов.
3.8.10 независимое лицо (independent person): Лицо, независимое и не связанное с процессами, происходившими во время конкретной стадии жизненного цикла подсистем безопасности E/E/PES системы в целом или программного обеспечения, которое выполняет оценку или приемку функциональной безопасности и которое не несет прямой ответственности за эти процессы.
