Хорошие продукты и сервисы
Наш Поиск (введите запрос без опечаток)
Наш Поиск по гостам (введите запрос без опечаток)
Поиск
Поиск
Бизнес гороскоп на текущую неделю c 29.12.2025 по 04.01.2026
Открыть шифр замка из трёх цифр с ограничениями

ГОСТ Р МЭК 61508-3-2012; Страница 58

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

Ещё ГОСТы из 41757, используйте поиск в верху страницы ГОСТ Р 55235.2-2012 Практические аспекты менеджмента непрерывности бизнеса. Менеджмент активов. Руководство по применению требований к оптимальному управлению производственными активами (В настоящем стандарте установлены основные принципы применения требований стандарта ГОСТ Р 55235.1, а также приведено руководство по созданию, внедрению, поддержке и улучшению системы менеджмента производственных активов и ее взаимодействия с другими системами менеджмента. Настоящий стандарт не устанавливает обязательных методов внедрения требований стандарта ГОСТ Р 55235.1, но способствует их лучшему пониманию путем описания необходимых действий с производственными активами. Настоящий стандарт не содержит дополнительных требований, помимо требований, установленных в стандарте ГОСТ Р 55235.1. В настоящий стандарт включены и заключены в тонкие рамки положения из ГОСТ Р 55235.1) ГОСТ Р ИСО/ТС 10303-1063-2012 Системы автоматизации производства и их интеграция. Представление данных об изделии и обмен этими данными. Часть 1063. Прикладной модуль. Наличие изделия в составе другого изделия (Настоящий стандарт определяет прикладной модуль «Наличие изделия в составе другого изделия». В область применения настоящего стандарта входят:. - обозначение наличия изделия некоторой версии в структуре изделия;. - связь наличия изделия некоторой версии с определением этой версии изделия, из которой наличие изделия происходит;. - характеристика наличия изделия, которая определяется описанием изделия;. - количественная характеристика имеющихся в наличии изделий;. - обозначение наличия функции;. - уточнение концепции наличия изделия, позволяющее представить наличие составной части изделия. В область применения настоящего стандарта не входят:. - описание отношений в сборочной единице;. - связь с функциями или альтернативными решениями для элемента решения, в котором используется наличие изделия;. - описание сценариев использования наличия детали в семействе изделий) ГОСТ Р ИСО/ТС 10303-1103-2012 Системы автоматизации производства и их интеграция. Представление данных об изделии и обмен этими данными. Часть 1103. Прикладной модуль. Определение класса изделия (Настоящий стандарт определяет прикладной модуль «Определение класса изделий». В область применения настоящего стандарта входят:. - определение семейства схожих изделий, которые должны быть предложены на рынке, в качестве класса изделий;. - соотношения между классами изделий;. - формирование категорий спецификаций, которые могут быть использованы для того, чтобы описывать характеристики представителя класса изделий;. - представление в спецификации булевых выражений;. - представление правил зависимостей между спецификациями;. - связь категорий спецификаций, спецификаций, выражений спецификаций и правил зависимости спецификаций с классом изделий;. - элементы, входящие в область применения прикладного модуля ИСО/ТС 10303-1113 «Группа»;. - элементы, входящие в область применения прикладного модуля ИСО/ТС 10303-1060 «Идентификация концепции изделия». В область применения настоящего стандарта не входят:. - обозначение составных частей, которые должны быть использованы в представителях класса изделий;. - обозначение технологических процессов, которые должны использоваться для изготовления, сборки или управления представителями класса изделий)
Страница 58
Страница 1 Untitled document
ГОСТ Р МЭК 61508-3—2012
Уверенность, которую можно связать со свойствами спецификации требований к программному обеспече
нию системы безопасности, как основание для обеспечения безопасности программного обеспечения, зависит от
строгости методов, с помощью которых были достигнуты требуемые свойства спецификации требований к
про граммному обеспечению системы безопасности. Строгость метода неформально ранжируется по шкале от R1
до R3. где R1 наименее строгий и R3 — самый строгий метод.
R1 Без объективных критериев приемки или с ограниченными объективными критериями приемки. Напри
мер. тестирование методом «черного ящика», основанное на профессиональном суждении, полевые
испытания
R2 С объективными критериями приемки, которые могут дать высокий уровень уверенности в том. что не
обходимое свойство достигнуто (исключения должны быть определены и обоснованы): например, тест
или аналитические методы с метриками охвата, охват таблицами контрольных проверок
R3С объективным, систематическим рассуждением о том. что необходимое свойство достигнуто. Напри
мер. формальное доказательство, демонстрирующее соблюдение архитектурных ограничений, которые
гарантируют свойство
Данный метод не относится к этому свойству
Для каждого метода, обеспечивающего конкретное свойство, определяется одно из ранжированных значе
ний R1/R2/R3 в зависимости от уровня строгости этого метода.
Свойства
Методы/
средства
Полнота
охвата
потребностей
безопасности
программным
обеспечением
Корректность
охвата
потребностей
безопасности
программным
обеспечением
Отсутствие
ошибок в
самой
специфика
ции, включая
отсутствие
неоднознач
ности
Ясность
требований «системе
безопасности
Отсутствие неблаго
приятного взаимо
влияния функций,
не связанных с
безопасностью, и
функций безопас
ности. реализуемых
программным
обеспечением систе
мы безопасности
Способность
обеспечения
проведения
оценки и
подтверждения
соответствия
Полу
формаль
ные
методы
R1
Определяемая но
тация. ограничива
ющая возможность
для непонимания.
R2
Применение преде
лов сложности в
спецификации
В этом примере полуформальный метод со строгостью R1 обеспечивает ограниченную нотацию, которая
улучшает точность выражений, и со строгостью R2 еще болев ограничивает сложность спецификации, что в про
тивном случав могло бы привести к путанице.
С.1.2 Метод использования 1
Руководящий принцип. Если можно убедительно продемонстрировать, что требуемые свойства были до
стигнуты при разработке спецификации требований к программному обеспечению системы безопасности, то обо
снована уверенность в том. что спецификация требований к программному обеспечению системы безопасности
является соответствующей основой для разработки программного обеспечения с достаточным уровнем система
тической полноты безопасности.
Из таблицы С.1 видно, что каждый из методов по таблицеА.1 приложения А в той или иной степени обычно
обеспечивает выполнение одного или более из вышеупомянутых свойств по таблице С.1. которые относятся к
спецификации требований к программному обеспечению системы безопасности.
Однако важно отметить, что хотя таблица А.1 рекомендует конхретные методы, эти рекомендации не яв
ляются нормативными и фактически приложение А ясно показывает, что «Учитывая большое число факторов,
влияющих на стойкость к систематическим отказам программного обеспечения, невозможно создать алгоритм,
включающий методы и средства, который обеспечит необходимый результат для любого заданного применения».
53