ГОСТ Р ИСО/МЭК 15026-2002; Страница 12

или поделиться

Ещё ГОСТы из 41757, используйте поиск в верху страницы

ГОСТ 15022-69 Ручки для литейных опок. Конструкция и размеры ГОСТ 15022-69 Ручки для литейных опок. Конструкция и размеры Handles for moulding boxes. Construction and dimensions (Настоящий стандарт устанавливает конструкцию и размеры ручек для литейных опок) ГОСТ 15027.1-77 Бронзы безоловянные. Метод определения меди ГОСТ 15027.1-77 Бронзы безоловянные. Метод определения меди Non-tin bronze. Method for the determination of copper (Настоящий стандарт устанавливает гравиметрический электролитический метод определения меди в безоловянных бронзах ) ГОСТ 15027.10-77 Бронзы безоловянные. Методы определения олова ГОСТ 15027.10-77 Бронзы безоловянные. Методы определения олова Non-tin bronze. Methods for the determination of tin (Настоящий стандарт устанавливает экстракционно-фотометрический метод определения олова с применением кверцетина, фотометрический метод определения олова с применением фенилфлуорона (при массовой доле олова от 0,01 до 0,5%), полярографический метод определения олова (при массовой доле олова от 0,001 до 0,5%) и атомно-абсорбционный метод определения олова (при массовой доле олова от 0,01 до 0,25% и от 0,25 до 0,5%) в бронзах безоловянных)

Страница 12

ГОСТ Р ИСО/МЭК 15026-2002

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

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

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

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

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

Для систем, отказ компонентов которых (например, программного средства) может привести к угрозе, уровень целостности системы частично основан на ограничении частоты отказа системы, согласованном с границами допустимого риска. Если отказ программного средства может привести к угрозе только в сочетании с другими подсистемами, находящимися в конкретном состоянии, возможно назначение менее строгого ограничения на частоту отказа данного средства, используемого в системе. Анализ частоты может быть использован для установления менее строгого ограничения на частоту отказа программного средства, соответствующего границам допустимого риска, и должен учитывать зависимости между подсистемами. Установленное верхнее ограничение частоты отказа программного средства может быть использовано при повторном расчете риска для определения наличия какого-либо изменения в классе риска и соответствующего снижения уровня целостности программного средства.

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

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

- аппаратные контрольные реле времени (аппаратный механизм);

- ручное восстановление (механизм, реализуемый человеком).

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

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

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