"ГОСТ Р МЭК 61508-3-2012. Национальный стандарт Российской Федерации. Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 3. Требования к программному обеспечению"
(утв. и введен в действие Приказом Росстандарта от 29.10.2012 N 588-ст)

Применение на добровольной основе раздела 6 обеспечивает соблюдение требований технического регламента Таможенного союза "О безопасности железнодорожного подвижного состава" (ТР ТС 001/2011) (Решение Комиссии Таможенного союза от 15.07.2011 N 710).

Применение на добровольной основе раздела 7 обеспечивает соблюдение требований технического регламента Таможенного союза "О безопасности железнодорожного подвижного состава" (ТР ТС 001/2011) (Решение Комиссии Таможенного союза от 15.07.2011 N 710).

Стадия жизненного цикла ПО системы безопасности (номер стадии соответствует номеру блока на рисунке 3)	Задача	Область применения	Номер пункта или раздела	Входные данные	Выходные данные
10.1. Спецификация требований к ПО системы безопасности	Указать требования: к системе программируемой электроники (ПЭ); к ПО, связанному с безопасностью, в виде требований к функциям безопасности ПО и к стойкости к систематическим отказам ПО. Указать необходимые для реализации требуемых функций безопасности требования к функциям безопасности ПО для каждой Э/Э/ПЭ системы, связанной с безопасностью. Указать требования к стойкости к систематическим отказам ПО для каждой Э/Э/ПЭ системы, связанной с безопасностью, необходимые для достижения уровня полноты безопасности, указанного для каждой функции безопасности, назначенной этой Э/Э/ПЭ системе, связанной с безопасностью	ПЭ система. Система ПО	7.2.2	Спецификация требований к Э/Э/ПЭ системе безопасности в результате распределения (см. МЭК 61508-1). Спецификация требований к Э/Э/ПЭ системе безопасности (из МЭК 61508-2)	Спецификация требований к ПО системы безопасности
10.2. Планирование подтверждения соответствия для аспектов ПО безопасности системы	Разработать план подтверждения соответствия для аспектов ПО безопасности системы	ПЭ система. Система ПО	7.3.2	Спецификация требований к ПО системы безопасности	План подтверждения соответствия для аспектов ПО безопасности системы
10.3. Проектирование и разработка ПО	Архитектура: - разработать архитектуру ПО, которая соответствует указанным требованиям к ПО, связанному с безопасностью, для необходимого уровня полноты безопасности; - оценить требования, предъявляемые к ПО со стороны архитектуры аппаратных средств Э/Э/ПЭ системы, связанной с безопасностью, включая значение взаимодействия между программным обеспечением и аппаратными средствами Э/Э/ПЭ системы, для безопасности управляемого оборудования	ПЭ система. Система ПО	7.4.3	Спецификация требований к ПО системы безопасности. Проект архитектуры аппаратных средств Э/Э/ПЭ системы (из МЭК 61508-2)	Описание проекта архитектуры ПО. Спецификация проверки интеграции архитектуры ПО. Спецификация проверки интеграции ПО/ПЭ (как требует МЭК 61508-2)
	Инструментальные средства поддержки и языки программирования: - выбрать подходящий набор инструментальных средств, включая языки программирования и компиляторы, системные интерфейсы времени выполнения, пользовательские интерфейсы и форматы и представления данных для требуемого уровня полноты безопасности в течение всего жизненного цикла ПО системы безопасности для верификации, подтверждения соответствия, оценки и модификации	ПЭ система. Система ПО. Инструментальные средства поддержки. Язык программирования	7.4.4	Спецификация требований к ПО системы безопасности. Описание проекта архитектуры ПО	Инструментальные средства поддержки и стандарты кодирования. Выбор инструментов разработки
10.3. Проектирование и разработка программного обеспечения	Детальное проектирование и разработка (проект программной системы): - спроектировать и реализовать ПО, которое соответствует указанным требованиям к ПО системы безопасности для необходимого уровня полноты безопасности; ПО должно быть пригодным к анализу и верификации и поддерживать возможность безопасной модификации	Проектирование архитектуры основных компонентов и подсистем ПО	7.4.5	Описание проекта архитектуры ПО. Инструментальные средства поддержки и стандарты кодирования	Спецификация проекта системы ПО. Спецификация тестирования интеграции системы ПО
	Детальное проектирование и разработка (проект отдельных программных модулей): - спроектировать и реализовать ПО, которое соответствует указанным требованиям к ПО системы безопасности для необходимого уровня полноты безопасности; ПО должно быть пригодным к анализу и верификации и поддерживать возможность безопасной модификации	Проект системы ПО	7.4.5	Спецификация проекта системы ПО. Инструментальные средства поддержки и стандарты кодирования	Спецификация проекта программного модуля. Спецификация тестирования программного модуля
	Детальная реализация исходного текста: - спроектировать и реализовать ПО, которое соответствует указанным требованиям к ПО системы безопасности для необходимого уровня полноты безопасности; ПО должно быть пригодным к анализу и верификации и поддерживать возможность безопасной модификации	Отдельные программные модули	7.4.6	Спецификация проекта программного модуля. Инструментальные средства поддержки и стандарты кодирования	Листинг исходного текста. Обзорный отчет по исходному тексту
	Тестирование программных модулей: - верифицировать выполнение требований к ПО, связанному с безопасностью (в терминах требуемых функций безопасности и стойкости к систематическим отказам ПО); - показать, что каждый программный модуль выполняет предназначенные для него функции и не выполняет непредусмотренных действий; - гарантировать в той мере, насколько это уместно, что конфигурация данных ПЭ систем выполняет указанные требования к стойкости к систематическим отказам ПО	Программные модули	7.4.7	Спецификация тестирования программного модуля. Листинг исходного текста. Обзорный отчет по исходному тексту	Результаты тестирования программного модуля. Верифицированные и проверенные программные модули
10.3. Проектирование и разработка ПО	Проверка интеграции ПО: - верифицировать выполнение требований к ПО системы безопасности (в терминах требуемых функций безопасности и стойкости к систематическим отказам ПО); - показать, что каждый программный модуль выполняет предназначенные для него функции и не выполняет непредусмотренных действий; - гарантировать в той мере, насколько это уместно, что конфигурация данных ПЭ систем выполняет указанные требования к стойкости к систематическим отказам ПО	Архитектура ПО. Система ПО	7.4.8	Спецификация тестирования интеграции программной системы	Результаты тестирования интеграции программной системы. Верифицированная и проверенная программная система
10.4. Интеграция программируемой электроники (аппаратные средства и программное обеспечение)	Интегрировать ПО с выбранной программируемой электронной аппаратурой. Объединить ПО и аппаратные средства в связанных с безопасностью программируемых электронных устройствах для того, чтобы гарантировать их совместимость и выполнение требований к необходимому уровню полноты безопасности	Аппаратное обеспечение программируемой электроники. Интегрированное ПО	7.5.2	Спецификация тестирования интеграции архитектуры ПО. Спецификация тестирования интеграции программируемой электроники (МЭК 61508-2). Интегрированная программируемая электроника	Результаты тестирования интеграции архитектуры ПО. Результаты тестирования интеграции программируемой электроники. Верифицированная и проверенная интегрированная программируемая электроника
10.5. Процедуры эксплуатации и модификации ПО	Предоставить информацию и процедуры, относящиеся к ПО и необходимые для того, чтобы гарантировать соблюдение функциональной безопасности Э/Э/ПЭ систем, связанных с безопасностью, во время эксплуатации и модификации	Аппаратное обеспечение программируемой электроники. Интегрированное ПО	7.6.2	По необходимости вся информация, описанная выше	Процедуры эксплуатации и модификации ПО
10.6. Подтверждение соответствия аспектов ПО безопасности системы	Обеспечить гарантию, что интегрированная система соответствует указанным требованиям к ПО, связанному с безопасностью, для заданного уровня полноты безопасности	Аппаратное обеспечение программируемой электроники. Интегрированное ПО	7.7.2	План подтверждения соответствия аспектов ПО безопасности системы	Результаты подтверждения соответствия ПО безопасности системы. Принятое ПО
Модификация ПО	Внести поправки, улучшения или модификации в принятое ПО, гарантируя, что требуемый уровень стойкости к систематическим отказам ПО будет сохранен	Аппаратное обеспечение программируемой электроники. Интегрированное ПО	7.8.2	Процедуры модификации ПО. Результаты модификации ПО	Результаты анализа влияния модификации ПО. Журнал модификации ПО
Верификация ПО	Протестировать и оценить выходные данные для заданной стадии жизненного цикла ПО системы безопасности для того, чтобы гарантировать правильность и соответствие выходным данным и стандартам для этой стадии	Зависит от стадии	7.9.2	Соответствующий план верификации (зависит от стадии)	Соответствующий отчет по верификации (зависит от стадии)
Оценка функциональной безопасности ПО	Изучить и принять решение по функциональной безопасности аспектов ПО, которая обеспечивается Э/Э/ПЭ системами, связанными с безопасностью	Для всех стадий, перечисленных выше	8	План оценки функциональной безопасности ПО	Отчет по оценке функциональной безопасности ПО

Раздел 8 содержит правила и методы исследований (испытаний) измерений, в том числе правила отбора образцов, необходимые для применения и исполнения требований технического регламента Таможенного союза "О безопасности железнодорожного подвижного состава" (ТР ТС 001/2011) и осуществления оценки (подтверждения) соответствия продукции (Решение Комиссии Таможенного союза от 15.07.2011 N 710).

HR	Настоятельно рекомендуется применять этот метод или средство для данного уровня полноты безопасности. Если метод или средство не используется, то на этапе планирования системы безопасности этому должно быть дано подробное объяснение со ссылкой на Приложение C, и это объяснение должно быть согласовано с экспертом
R	Метод или средство рекомендуется применять для данного уровня полноты безопасности, но степень обязательности рекомендации ниже, чем в случае рекомендации HR
-	Для данного метода или средства рекомендации ни за, ни против не приводятся
NR	Данный метод или средство не рекомендуется для этого уровня полноты безопасности. Если данный метод или средство применяют, то на стадии планирования системы безопасности этому должно быть дано подробное обоснование со ссылкой на Приложение C, которое следует согласовать с экспертом

Метод/средство <1>	Ссылка	УПБ1	УПБ2	УПБ3	УПБ4
1a. Полуформальные методы	Таблица B.7	R	R	HR	HR
1b. Формальные методы	B.2.2, C.2.4	-	R	R	HR
2. Прямая прослеживаемость между требованиями к системе безопасности и требованиями к программному обеспечению системы безопасности	C.2.11	R	R	HR	HR
3. Обратная прослеживаемость между требованиями к системе безопасности и предполагаемыми потребностями безопасности	C.2.11	R	R	HR	HR
4. Компьютерные средства разработки спецификаций для поддержки перечисленных выше подходящих методов/средств	B.2.4	R	R	HR	HR
<1> Методы/средства следует выбирать в соответствии с уровнем полноты безопасности. Альтернативные или эквивалентные методы/средства обозначают буквами, следующими за числом. Следует применять только один из альтернативных или эквивалентных методов/мероприятий. Выбор альтернативных методов должен быть обоснован в соответствии со свойствами, приведенными в Приложении C, желательно для каждого применения. Примечания. 1. Спецификация требований к программному обеспечению системы безопасности всегда будет требовать описания задачи на естественном языке и использования необходимой системы математических обозначений, отражающих содержание Приложения. 2. Таблица отражает дополнительные требования для ясного и точного определения требований к программному обеспечению системы безопасности. 3. См. таблицу C.1. 4. Ссылки (являющиеся справочными, а не обязательными) "B.x.x.x", "C.x.x.x" во второй графе указывают на подробные описания методов/средств, изложенные в приложениях B и C [5].

Метод/средство <1>	Ссылка	УПБ1	УПБ2	УПБ3	УПБ4
1. Обнаружение ошибок	C.3.1	-	R	HR	HR
2. Коды обнаружения ошибок	C.3.2	R	R	R	HR
3a. Программирование с проверкой ошибок	C.3.3	R	R	R	HR
3b. Методы контроля (при реализации процесса контроля и контролируемой функции на одном компьютере обеспечивается их независимость)	C.3.4	-	R	R	-
3c. Методы контроля (реализация процесса контроля и контролируемой функции на разных компьютерах)	C.3.4	-	R	R	HR
3d. Многовариантное программирование, реализующее одну спецификацию требований к программному обеспечению системы безопасности	C.3.5	-	-	-	R
3e. Функционально многовариантное программирование, реализующее различные спецификации требований к программному обеспечению системы безопасности	C.3.5	-	-	R	HR
3f. Восстановление предыдущего состояния	C.3.6	R	R	-	HR
3g. Проектирование программного обеспечения, не сохраняющего состояние (или проектирование ПО, сохраняющего ограниченное описание состояния)	C.2.12	-	-	R	HR
4a. Механизмы повторных попыток парирования сбоя	C.3.7	R	R	-	-
4b. Постепенное отключение функций	C.3.8	R	R	HR	HR
5. Исправление ошибок методами искусственного интеллекта	C.3.9	-	NR	NR	NR
6. Динамическая реконфигурация	C.3.10	-	NR	NR	NR
7. Модульный подход	Таблица B.9	HR	HR	HR	HR
8. Использование доверительных/проверенных элементов программного обеспечения (при наличии)	C.2.10	R	HR	HR	HR
9. Прямая прослеживаемость между спецификацией требований к программному обеспечению системы безопасности и архитектурой программного обеспечения	C.2.11	R	R	HR	HR
10. Обратная прослеживаемость между спецификацией требований к программному обеспечению системы безопасности и архитектурой программного обеспечения	C.2.11	R	R	HR	HR
11a. Методы структурных диаграмм <2>	C.2.1	HR	HR	HR	HR
11b. Полуформальные методы <2>	Таблица B.7	R	R	HR	HR
11c. Формальные методы проектирования и усовершенствования <2>	B.2.2, C.2.4	-	R	R	HR
11d. Автоматическая генерация программного обеспечения	C.4.6	R	R	R	R
12. Автоматизированные средства разработки спецификаций и проектирования	B.2.4	R	R	HR	HR
13a. Циклическое поведение с гарантированным максимальным временем цикла	C.3.11	R	HR	HR	HR
13b. Архитектура с распределением	C.3.11	R	HR	HR	HR
13c. Управление событиями с гарантированным максимальным временем реакции	C.3.11	R	HR	HR	-
14. Статическое выделение ресурсов	C.2.6.3	-	R	HR	HR
15. Статическая синхронизация доступа к разделяемым ресурсам	C.2.6.3	-	-	R	HR
<1> Методы/средства следует выбирать в соответствии с уровнем полноты безопасности. Альтернативные или эквивалентные методы/средства обозначают буквами, следующими за числом. Следует применять только один из альтернативных или эквивалентных методов/мероприятий. Выбор альтернативных методов должен быть обоснован в соответствии со свойствами, приведенными в Приложении C, желательно для каждого применения. <2> Из группы 11 "Структурированные методы" следует применять метод 11a, только если метод 11b не подходит для предметной области с УПБ3 + УПБ4. Примечания. 1. Некоторые методы в таблице A.2 посвящены концепциям проектирования, другие тому, как проект представляется. 2. Приведенные в настоящей таблице средства, касающиеся устойчивости к ошибкам (контроль ошибок), должны рассматриваться совместно с требованиями по МЭК 61508-2 к архитектуре и контролю ошибок для аппаратных средств программируемых электронных устройств. 3. См. таблицу C.2. 4. Группа методов 13a - 13c применяется только к системам и программному обеспечению с требованиями к синхронизации системы безопасности. 5. Метод 14: использование динамических объектов (например, при работе со стеком или с неупорядоченным массивом) может наложить требования на доступную память и время выполнения. Метод 14 не должен быть применен, если используется компилятор, который гарантирует, что: a) перед выполнением будет выделено достаточно памяти для всех динамических переменных и объектов или в случае ошибки при выделении памяти будет достигнуто безопасное состояние; b) время отклика соответствует заданным требованиям. 6. Метод 4a: устранение неисправностей с помощью повторных попыток часто подходит при любом УПБ, но должен быть установлен предел для числа повторений. 7. Ссылки (являющиеся справочными, а не обязательными) "B.x.x.x", "C.x.x.x" во второй графе указывают на подробные описания методов/средств, изложенных в приложениях B и C [5].

Метод/средство <1>	Ссылка	УПБ1	УПБ2	УПБ3	УПБ4
1. Выбор соответствующего языка программирования	C.4.5	HR	HR	HR	HR
2. Строго типизированные языки программирования	C.4.1	HR	HR	HR	HR
3. Подмножество языка	C.4.2	-	-	HR	HR
4a. Сертифицированные средства и сертифицированные трансляторы	C.4.3	R	HR	HR	HR
4b. Инструментальные средства, заслуживающие доверия на основании опыта использования	C.4.4	HR	HR	HR	HR
<1> Методы/средства следует выбирать в соответствии с уровнем полноты безопасности. Альтернативные или эквивалентные методы/средства обозначают буквами, следующими за числом. Следует выполнять только один из альтернативных или эквивалентных методов/мероприятий. Выбор альтернативных методов должен быть обоснован в соответствии со свойствами, приведенными в Приложении C, желательно для каждого применения. Примечания. 1. См. таблицу C.3. 2. Ссылки (являющиеся справочными, а не обязательными) "B.x.x.x", "C.x.x.x" во второй графе указывают на подробные описания методов/средств, изложенных в приложениях B и C [5].

Метод/средство <1>	Ссылка	УПБ1	УПБ2	УПБ3	УПБ4
1a. Методы структурных диаграмм <2>	C.2.1	HR	HR	HR	HR
1b. Полуформальные методы <2>	Таблица B.7	R	R	HR	HR
1c. Формальные методы проектирования и усовершенствования <2>	B.2.2, C.2.4	-	R	R	HR
2. Средства автоматизированного проектирования	B.3.5	R	R	HR	HR
3. Программирование с защитой	C.2.5	-	R	HR	HR
4. Модульный подход	Таблица B.9	HR	HR	HR	HR
5. Стандарты для проектирования и кодирования	C.2.6, таблица B.1	R	HR	HR	HR
6. Структурное программирование	C.2.7	HR	HR	HR	HR
7. Использование доверительных/проверенных программных модулей и компонентов (по возможности)	C.2.10	R	HR	HR	HR
8. Прямая прослеживаемость между спецификацией требований к программному обеспечению системы безопасности и проектом программного обеспечения	C.2.11	R	R	HR	HR
<1> Методы/средства следует выбирать в соответствии с уровнем полноты безопасности. Альтернативные или эквивалентные методы/средства обозначают буквами, следующими за числом. Следует выполнять только один из альтернативных или эквивалентных методов/средств. <2> Из группы 1 "Структурированные методы" следует использовать метод 1a, только если метод 1b не подходит для предметной области с УПБ3 и УПБ4. Примечания. 1. См. таблицу C.4. 2. Все еще обсуждается пригодность разработки объектно-ориентированного программного обеспечения для систем, связанных с безопасностью. Руководящие указания по использованию объектно-ориентированного подхода при разработке архитектуры и в проектировании см. приложение G МЭК 61508-7. 3. Ссылки (являющиеся справочными, а не обязательными) "B.x.x.x", "C.x.x.x" во второй графе указывают на подробные описания методов/средств, изложенных в приложениях B и C [5].

Метод/средство <1>	Ссылка	УПБ1	УПБ2	УПБ3	УПБ4
1. Вероятностное тестирование	C.5.1	-	R	R	HR
2. Динамический анализ и тестирование	B.6.5, таблица B.2	R	HR	HR	HR
3. Регистрация и анализ данных	C.5.2	HR	HR	HR	HR
4. Функциональное тестирование и тестирование методом "черного ящика"	B.5.1, B.5.2, таблица B.3	HR	HR	HR	HR
5. Тестирование рабочих характеристик	Таблица B.6	R	R	HR	HR
6. Тестирование, основанное на модели	C.5.27	R	R	HR	HR
7. Тестирование интерфейса	C.5.3	R	R	HR	HR
8. Управление тестированием и средства автоматизации	C.4.7	R	HR	HR	HR
9. Прямая прослеживаемость между спецификацией проекта программного обеспечения и спецификациями тестирования модуля и интеграции	C.2.11	R	R	HR	HR
10. Формальная верификация	C.5.12	-	-	R	R
<1> Методы/средства следует выбирать в соответствии с уровнем полноты безопасности. Примечания. 1. Тестирование программных модулей и интеграции относится к процессам верификации (см. таблицу A.9). 2. См. таблицу C.5. 3. Формальная проверка может уменьшить размер и объем занимаемой памяти модуля, поэтому необходимо тестирование интеграции. 4. Ссылки (являющиеся справочными, а не обязательными) "B.x.x.x", "C.x.x.x" во второй графе указывают на подробные описания методов/средств, изложенных в приложениях B и C [5].

Метод/средство <1>	Ссылка	УПБ1	УПБ2	УПБ3	УПБ4
1. Функциональное тестирование и тестирование методом "черного ящика"	B.5.1, B.5.2, таблица B.3	HR	HR	HR	HR
2. Тестирование рабочих характеристик	Таблица B.6	R	R	HR	HR
3. Прямая прослеживаемость между требованиями проекта системы и программного обеспечения к интеграции программных и аппаратных средств и спецификациями тестирования интеграции программных и аппаратных средств	C.2.11	R	R	HR	HR
<1> Методы/средства следует выбирать в соответствии с уровнем полноты безопасности. Примечания. 1. Интеграция программируемых электронных устройств относится к процессам верификации (см. таблицу A.9). 2. См. таблицу C.6. 3. Ссылки (являющиеся справочными, а не обязательными) "B.x.x.x", "C.x.x.x" во второй графе указывают на подробные описания методов/средств, изложенных в приложениях B и C [5].

Метод/средство <1>	Ссылка	УПБ1	УПБ2	УПБ3	УПБ4
1. Вероятностное тестирование	C.5.1	-	R	R	HR
2. Моделирование процесса	C.5.18	R	R	HR	HR
3. Моделирование	Таблица B.5	R	R	HR	HR
4. Функциональное тестирование и тестирование методом "черного ящика"	B.5.1, B.5.2, таблица B.3	HR	HR	HR	HR
5. Прямая прослеживаемость между спецификацией требований к программному обеспечению системы безопасности и планом подтверждения соответствия программного обеспечения системы безопасности	C.2.11	R	R	HR	HR
6. Обратная прослеживаемость между планом подтверждения соответствия программного обеспечения системы безопасности и спецификацией требований к программному обеспечению системы безопасности	C.2.11	R	R	HR	HR
<1> Методы/средства следует выбирать в соответствии с уровнем полноты безопасности. Примечания.
ИС NORMPROD: примечание. В официальном тексте документа, видимо, допущена опечатка: имеется в виду таблица C.7, а не таблица C.6.
1. См. таблицу C.6. 2. Ссылки (являющиеся справочными, а не обязательными) "B.x.x.x", "C.x.x.x" во второй графе указывают на подробные описания методов/средств, изложенных в приложениях B и C [5].

Метод/средство <1>	Ссылка	УПБ1	УПБ2	УПБ3	УПБ4
1. Анализ влияния	C.5.23	HR	HR	HR	HR
2. Повторная верификация измененных программных модулей	C.5.23	HR	HR	HR	HR
3. Повторная верификация программных модулей, на которые оказывают влияние изменения в других модулях	C.5.23	R	HR	HR	HR
4a. Повторное подтверждение соответствия системы в целом	Таблица A.7	-	R	HR	HR
4b. Регрессионное подтверждение соответствия	C.5.25	R	HR	HR	HR
5. Управление конфигурацией программного обеспечения	C.5.24	HR	HR	HR	HR
6. Регистрация и анализ данных	C.5.2	HR	HR	HR	HR
7. Прямая прослеживаемость между спецификацией требований к программному обеспечению системы безопасности и планом модификации программного обеспечения (включая повторные верификацию и подтверждение соответствия)	C.2.11	R	R	HR	HR
8. Обратная прослеживаемость между планом модификации программного обеспечения (включая повторную верификацию и подтверждение соответствия) и спецификацией требований к программному обеспечению системы безопасности	C.2.11	R	R	HR	HR
<1> Методы/средства следует выбирать в соответствии с уровнем полноты безопасности. Альтернативные или эквивалентные методы/средства обозначают буквами, следующими за числом. Следует выполнять только один из альтернативных или эквивалентных методов/мероприятий. Выбор альтернативных методов должен быть обоснован в соответствии со свойствами, приведенными в Приложении C, желательно для каждого применения. Примечания. 1. См. таблицу C.8. 2. Методы группы 1 "Анализ влияния" являются необходимой частью метода "Регрессионного подтверждения соответствия". См. МЭК 61508-7. 3. Ссылки (являющиеся справочными, а не обязательными) "B.x.x.x", "C.x.x.x" во второй графе указывают на подробные описания методов/средств, изложенных в приложениях B и C [5].

Метод/средство <1>	Ссылка	УПБ1	УПБ2	УПБ3	УПБ4
1. Формальное доказательство	C.5.12	-	R	R	HR
2. Анимация спецификации и тестирования	C.5.26	R	R	R	R
3. Статический анализ	B.6.4, таблица B.8	R	HR	HR	HR
4. Динамический анализ и тестирование	B.6.5, таблица B.2	R	HR	HR	HR
5. Прямая прослеживаемость между спецификацией проекта программного обеспечения и планом верификации (включая верификацию данных) программного обеспечения	C.2.11	R	R	HR	HR
6. Обратная прослеживаемость между планом верификации (включая верификацию данных) программного обеспечения и спецификацией проекта программного обеспечения	C.2.11	R	R	HR	HR
7. Численный анализ в автономном режиме	C.2.13	R	R	HR	HR
Тестирование и интеграция программного модуля	См. таблицу A.5
Проверка интеграции программируемых электронных устройств	См. таблицу A.6
Тестирование программной системы (подтверждение соответствия)	См. таблицу A.7
<1> Методы/средства следует выбирать в соответствии с уровнем полноты безопасности. Примечания. 1. Для удобства все процессы, связанные с верификацией, были объединены в настоящей таблице. Это, однако, не накладывает дополнительных требований на элементы верификации, связанные с динамическим тестированием, в таблицах A.5 и A.6, которые сами по себе относятся к процессам верификации. Настоящая таблица также не требует проведения верификационного тестирования в дополнение к подтверждению соответствия программного обеспечения (см. таблицу B.7), которая в настоящем стандарте представляет демонстрацию соответствия спецификации требований к системе безопасности (конечную верификацию). 2. Требования к верификации включены в МЭК 61508-1 - МЭК 61508-3. Следовательно, первая верификация системы, связанной с безопасностью, относится к ранним спецификациям системного уровня. 3. На ранних стадиях жизненного цикла программного обеспечения системы безопасности верификация является статической, она может включать в себя, например, изучение, просмотр, формальную проверку. Когда программа готова, становится возможным проведение динамического тестирования. Для верификации требуется объединение информации обоих типов. Например, верификация программного модуля статическими средствами включает в себя такие методы, как просмотр программ, прогон, статический анализ, формальная проверка. Верификация программ динамическими средствами включает в себя функциональное тестирование, тестирование методом белого ящика, статистическое тестирование. Использование проверок обоих типов позволяет утверждать, что каждый программный модуль удовлетворяет соответствующей спецификации. 4. См. таблицу C.9. 5. Ссылки (являющиеся справочными, а не обязательными) "B.x.x.x", "C.x.x.x" во второй графе указывают на подробные описания методов/средств, изложенных в приложениях B и C [5].

Метод/средство <1>	Ссылка	УПБ1	УПБ2	УПБ3	УПБ4
1. Таблица контрольных проверок	B.2.5	R	R	R	R
2. Таблицы решений (таблицы истинности)	C.6.1	R	R	R	R
3. Анализ отказов	Таблица B.4	R	R	HR	HR
4. Анализ отказов по общей причине различного программного обеспечения (если различное программное обеспечение используется)	C.6.3	-	R	HR	HR
5. Структурные схемы надежности	C.6.4	R	R	R	R
6. Прямая прослеживаемость между требованиями раздела 8 и планом оценки функциональной безопасности программного обеспечения	C.2.11	R	R	HR	HR
<1> Соответствующие методы/средства следует выбирать в соответствии с уровнем полноты безопасности. Примечания. 1. См. таблицу C.10. 2. Ссылки (являющиеся справочными, а не обязательными) "B.x.x.x", "C.x.x.x" во второй графе указывают на подробные описания методов/средств, изложенных в приложениях B и C [5].

Метод/средство <1>	Ссылка	УПБ1	УПБ2	УПБ3	УПБ4
1. Использование стандартов кодирования для сокращения вероятности ошибок	C.2.6.2	HR	HR	HR	HR
2. Не использовать динамические объекты	C.2.6.3	R	HR	HR	HR
3a. Не использовать динамические переменные	C.2.6.3	-	R	HR	HR
3b. Проверка создания динамических переменных в неавтономном режиме	C.2.6.4	-	R	HR	HR
4. Ограниченное использование прерываний	C.2.6.5	R	R	HR	HR
5. Ограниченное использование указателей	C.2.6.6	-	R	HR	HR
6. Ограниченное использование рекурсий	C.2.6.7	-	R	HR	HR
7. Не использовать неструктурированное управление в программах, написанных на языках высокого уровня	C.2.6.2	R	HR	HR	HR
8. Не использовать автоматическое преобразование типов	C.2.6.2	R	HR	HR	HR
<1> Методы/средства следует выбирать в соответствии с уровнем полноты безопасности. Альтернативные или эквивалентные методы/средства обозначают буквами, следующими за числом. Следует применять только один из альтернативных или эквивалентных методов/мероприятий. Выбор альтернативных методов должен быть обоснован в соответствии со свойствами, приведенными в Приложении C, желательно для каждого применения. Примечания. 1. Методы 2, 3a и 5: использование динамических объектов (например, при реализации стека или динамически распределяемой области памяти) может наложить ограничения на объем доступной памяти и время выполнения. Методы 2, 3a и 5 не должны применяться, если используется компилятор, который обеспечивает, что: a) для всех динамических переменных и объектов перед выполнением будет выделено достаточно памяти, а в случае ошибки выделения памяти система перейдет в безопасное состояние; b) время реакции системы соответствует заданным требованиям. 2. См. таблицу C.11. 3. Ссылки (являющиеся справочными, а не обязательными) "B.x.x.x", "C.x.x.x" во второй графе указывают на подробные описания методов/средств, изложенных в приложениях B и C [5].

Метод/средство <1>	Ссылка	УПБ1	УПБ2	УПБ3	УПБ4
1. Выполнение тестового примера, связанного с анализом граничных значений	C.5.4	R	HR	HR	HR
2. Выполнение тестового примера, связанного с предполагаемой ошибкой	C.5.5	R	R	R	R
3. Выполнение тестового примера, связанного с введением ошибки	C.5.6	-	R	R	R
4. Выполнение тестового примера, сгенерированного на основе модели	C.5.27	R	R	HR	HR
5. Моделирование реализации	C.5.20	R	R	R	HR
6. Разделение входных данных на классы эквивалентности	C.5.7	R	R	R	HR
7a. Структурный тест со 100%-ным охватом (точки входа) <2>	C.5.8	HR	HR	HR	HR
7b. Структурный тест со 100%-ным охватом (операторы) <2>	C.5.8	R	HR	HR	HR
7c. Структурный тест со 100%-ным охватом (условные переходы) <2>	C.5.8	R	R	HR	HR
7d. Структурный тест со 100%-ным охватом (составные условия, MC/DC) <2>	C.5.8	R	R	R	HR
<1> Методы/средства следует выбирать в соответствии с уровнем полноты безопасности. <2> Если 100%-ный охват не может быть достигнут (например, охват оператора кода защиты), то должно быть дано соответствующее объяснение. Примечания. 1. Анализ с использованием тестовых примеров проводят на уровне подсистем, он основывается на спецификациях и/или спецификациях и текстах программ. 2. См. таблицу C.12. 3. Ссылки (являющиеся справочными, а не обязательными) "B.x.x.x", "C.x.x.x" во второй графе указывают на подробные описания методов/средств, изложенных в приложениях B и C [5].

Метод/средство <1>	Ссылка	УПБ1	УПБ2	УПБ3	УПБ4
1. Выполнение тестового примера на основе причинно-следственных диаграмм	B.6.6.2	-	-	R	R
2. Выполнение тестового примера, сгенерированного на основе модели	C.5.27	R	R	HR	HR
3. Макетирование/анимация	C.5.17	...	-	R	R
4. Разделение входных данных на классы эквивалентности, включая анализ граничных значений	C.5.7, C.5.4	R	HR	HR	HR
5. Моделирование процесса	C.5.18	R	R	R	R
<1> Методы/средства следует выбирать в соответствии с уровнем полноты безопасности. Примечания. 1. Анализ с использованием тестовых примеров выполняется на уровне систем программного обеспечения и он основывается только на спецификациях. 2. Полнота моделирования будет зависеть от уровня полноты безопасности, сложности и применения. 3. См. таблицу C.13. 4. Ссылки (являющиеся справочными, а не обязательными) "B.x.x.x", "C.x.x.x" во второй графе указывают на подробные описания методов/средств, изложенных в приложениях B и C [5].

Метод/средство <1>	Ссылка	УПБ1	УПБ2	УПБ3	УПБ4
1a. Причинно-следственные диаграммы	B.6.6.2	R	R	R	R
1в. Анализ методом дерева событий	B.6.6.3	R	R	R	R
2. Анализ методом дерева отказов	B.6.6.5	R	R	R	R
3. Анализ функциональных отказов программного обеспечения	B.6.6.4	R	R	R	R
<1> Методы/средства следует выбирать в соответствии с уровнем полноты безопасности. Альтернативные или эквивалентные методы/средства обозначают буквами, следующими за числом. Следует применять только один из альтернативных или эквивалентных методов/мероприятий. Выбор альтернативных методов должен быть обоснован в соответствии со свойствами, приведенными в Приложении C, желательно для каждого применения. Примечания. 1. Предварительно должен быть проведен анализ рисков для определения, к какому уровню полноты безопасности следует отнести программное обеспечение. 2. См. таблицу C.14. 3. Ссылки (являющиеся справочными, а не обязательными) "B.x.x.x", "C.x.x.x" во второй графе указывают на подробные описания методов/средств, изложенных в приложениях B и C [5].

Метод/средство <1>	Ссылка	УПБ1	УПБ2	УПБ3	УПБ4
1. Диаграммы потоков данных	C.2.2	R	R	R	R
2a. Метод конечных автоматов	B.2.3.2	-	R	HR	HR
2b. Формальные методы	B.2.2, C.2.4	-	R	R	HR
2c. Моделирование во времени сетями Петри	B.2.3.3	-	R	HR	HR
3. Моделирование реализации	C.5.20	R	HR	HR	HR
4. Макетирование/анимация	C.5.17	R	R	R	R
5. Структурные диаграммы	C.2.3	R	R	R	HR
<1> Методы/средства следует выбирать в соответствии с уровнем полноты безопасности. Альтернативные или эквивалентные методы/средства обозначают буквами, следующими за числом. Следует выполнять только один из альтернативных или эквивалентных методов/мероприятий. Выбор альтернативных методов должен быть обоснован в соответствии со свойствами, приведенными в Приложении C, желательно для каждого применения. Примечания. 1. Если какой-то конкретный метод не перечислен в таблице, не следует считать, что он был исключен из рассмотрения. Этот метод должен соответствовать требованиям настоящего стандарта. 2. Количественное значение вероятностей не требуется. 3. См. таблицу C.15. 4. Ссылки (являющиеся справочными, а не обязательными) "B.x.x.x", "C.x.x.x" во второй графе указывают на подробные описания методов/средств, изложенных в приложениях B и C [5].

Метод/средство <1>	Ссылка	УПБ1	УПБ2	УПБ3	УПБ4
1. Проверка на критические нагрузки и стресс-тестирование	C.5.21	R	R	HR	HR
2. Ограничения на время ответа и объем памяти	C.5.22	HR	HR	HR	HR
3. Требования к реализации	C.5.19	HR	HR	HR	HR
<1> Методы/средства следует выбирать в соответствии с уровнем полноты безопасности. Примечания. 1. См. таблицу C.16. 2. Ссылки (являющиеся справочными, а не обязательными) "B.x.x.x", "C.x.x.x" во второй графе указывают на подробные описания методов/средств, изложенных в приложениях B и C [5].

Метод/средство <1>	Ссылка	УПБ1	УПБ2	УПБ3	УПБ4
1. Логические/функциональные блок-схемы	См. примечание 1	R	R	HR	HR
2. Диаграммы последовательности действий	См. примечание 1	R	R	HR	HR
3. Диаграммы потоков данных	C.2.2	R	R	R	R
4a. Конечные автоматы/диаграммы переходов	B.2.3.2	R	R	HR	HR
4b. Моделирование во времени сетями Петри	B.2.3.3	R	R	HR	HR
5. Модели данных сущность - связь - атрибут	B.2.4.4	R	R	R	R
6. Диаграммы последовательности сообщений	C.2.14	R	R	R	R
7. Таблицы решений и таблицы истинности	C.6.1	R	R	HR	HR
8. UML	C.3.12	R	R	R	R
<1> Методы/средства следует выбирать в соответствии с уровнем полноты безопасности. Альтернативные или эквивалентные методы/средства обозначают буквами, следующими за числом. Следует выполнять только один из альтернативных или эквивалентных методов/мероприятий. Выбор альтернативных методов должен быть обоснован в соответствии со свойствами, приведенными в Приложении C, желательно для каждого применения. Примечания. 1. Логические и функциональные блок-схемы и диаграммы последовательности действий приведены в [7]. 2. См. таблицу C.17. 3. Ссылки (являющиеся справочными, а не обязательными) "B.x.x.x", "C.x.x.x" во второй графе указывают на подробные описания методов/средств, изложенных в приложениях B и C [5].

Метод/средство <1>	Ссылка	УПБ1	УПБ2	УПБ3	УПБ4
1. Анализ граничных значений	C.5.4	R	R	HR	HR
2. Таблица контрольных проверок	B.2.5	R	R	R	R
3. Анализ потоков управления	C.5.9	R	HR	HR	HR
4. Анализ потоков данных	C.5.10	R	HR	HR	HR
5. Предположение ошибок	C.5.5	R	R	R	R
6a. Формальные проверки, включая конкретные критерии	C.5.14	R	R	HR	HR
6b. Сквозной контроль (программного обеспечения)	C.5.15	R	R	R	R
7. Тестирование на символьном уровне	C.5.11	-	-	R	R
8. Анализ проекта	C.5.16	HR	HR	HR	HR
9. Статический анализ выполнения программы с ошибкой	B.2.2, C.2.4	R	R	R	HR
10. Временной анализ выполнения при наихудших условиях	C.5.20	R	R	R	R
<1> Методы/средства следует выбирать в соответствии с уровнем полноты безопасности. Альтернативные или эквивалентные методы/средства обозначают буквами, следующими за числом. Следует выполнять только один из альтернативных или эквивалентных методов/мероприятий. Выбор альтернативных методов должен быть обоснован в соответствии со свойствами, приведенными в Приложении C, желательно для каждого применения. Примечания. 1. См. таблицу C.18. 2. Ссылки (являющиеся справочными, а не обязательными) "B.x.x.x", "C.x.x.x" во второй графе указывают на подробные описания методов/средств, изложенных в приложениях B и C [5].

Метод/средство <1>	Ссылка	УПБ1	УПБ2	УПБ3	УПБ4
1. Ограничение размера программного модуля	C.2.9	HR	HR	HR	HR
2. Управление сложностью программного обеспечения	C.5.13	R	R	HR	HR
3. Ограничение доступа/инкапсуляция информации	C.2.8	R	HR	HR	HR
4. Ограниченное число параметров/фиксированное число параметров подпрограммы	C.2.9	R	R	R	R
5. Одна точка входа и одна точка выхода в каждой подпрограмме и функции	C.2.9	HR	HR	HR	HR
6. Полностью определенный интерфейс	C.2.9	HR	HR	HR	HR
<1> Методы/средства следует выбирать в соответствии с уровнем полноты безопасности. Использование одного метода является, по-видимому, недостаточным. Следует рассматривать все подходящие методы. Примечания. 1. См. таблицу C.19. 2. Ссылки (являющиеся справочными, а не обязательными) "B.x.x.x", "C.x.x.x" во второй графе указывают на подробные описания методов/средств, изложенных в приложениях B и C [5].

Метод/средство <1>	Ссылка	УПБ1	УПБ2	УПБ3	УПБ4
1a. Полуформальные методы	Таблица B.7	R	R	HR	HR
1b. Формальные методы	B.2.2, C.2.4	-	R	R	HR
2. Прямая прослеживаемость между требованиями к системе безопасности и требованиями к программному обеспечению системы безопасности	C.2.11	R	R	HR	HR
3. Обратная прослеживаемость между требованиями к системе безопасности и предполагаемыми потребностями безопасности	C.2.11	R	R	HR	HR
4. Компьютерные средства разработки спецификаций для поддержки перечисленных выше подходящих методов/средств	B.2.4	R	R	HR	HR

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

Методы/средства	Свойства
	Полнота охвата потребностей безопасности программным обеспечением	Корректность охвата потребностей безопасности программным обеспечением	Отсутствие ошибок в самой спецификации, включая отсутствие неоднозначности	Ясность требований к системе безопасности	Отсутствие неблагоприятного взаимовлияния функций, не связанных с безопасностью, и функций безопасности, реализуемых программным обеспечением системы безопасности	Способность обеспечения проведения оценки и подтверждения соответствия
1a. Полуформальные методы	R1 Дружественный или зависящий от предметной области метод спецификации и нотация, используемые специалистами в проблемной области	R1 Дружественный или зависящий от предметной области метод спецификации и нотация, используемые специалистами в проблемной области. R2 Верификация спецификации согласно критерию охвата	R1 Метод и нотация, которые помогают предотвратить или обнаружить внутреннюю несогласованность, отсутствующее поведение или математически несовместимые выражения. R2 Проверка спецификации согласно критериям охвата. R3 Проверка спецификации, основанная на систематическом анализе и/или систематическом предотвращении определенных типов отказов внутри спецификации	R1 Определяемая нотация, ограничивающая возможность для непонимания. R2 Применение пределов сложности в спецификации	-	R1 Определяемая нотация, снижающая неоднозначность в спецификации

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

Методы/средства	Свойства
	Полнота охвата потребностей безопасности программным обеспечением	Корректность охвата потребностей безопасности программным обеспечением	Отсутствие ошибок в самой спецификации, включая отсутствие неоднозначности	Ясность требований к системе безопасности	Отсутствие неблагоприятного взаимовлияния функций, не связанных с безопасностью, и функций безопасности, реализуемых программным обеспечением системы безопасности	Способность обеспечения проведения оценки и подтверждения соответствия
1a. Полуформальные методы				R1 Определяемая нотация, ограничивающая возможность для непонимания. R2 Применение пределов сложности в спецификации

УПБ	Строгость R
1/2	R1
3	R2 (если возможно)
4	Наиболее высокая возможная строгость

Методы/средства	Свойства
	Полнота охвата потребностей безопасности программным обеспечением	Корректность охвата потребностей безопасности программным обеспечением	Отсутствие ошибок в самой спецификации, включая отсутствие неоднозначности	Ясность требований к системе безопасности	Отсутствие неблагоприятного взаимовлияния функций, не связанных с безопасностью, и функций безопасности, реализуемых программным обеспечением системы безопасности	Способность обеспечения проведения оценки и подтверждения соответствия
1a. Полуформальные методы	R1 Дружественный или зависящий от предметной области метод спецификации и нотация, используемая специалистами в проблемной области	R1 Дружественный или зависящий от предметной области метод спецификации и нотация, используемая специалистами в проблемной области. R2 Верификация спецификации согласно критерию охвата	R1 Метод и нотация, которые помогают предотвратить или обнаружить внутреннюю несогласованность, отсутствующее поведение или математически несовместимые выражения. R2 Проверка спецификации согласно критериям охвата. R3 Проверка спецификации, основанная на систематическом анализе и/или систематическом предотвращении определенных типов отказов внутри спецификации	R1 Определяемая нотация, ограничивающая возможность для непонимания. R2 Применение пределов сложности в спецификации	-	R1 Определяемая нотация, уменьшающая неоднозначность в спецификации
1b. Формальные методы	R1 Дружественный или зависящий от предметной области метод спецификации и нотация, используемая специалистами в проблемной области	R1 Дружественный или зависящий от предметной области метод спецификации и нотация, используемая специалистами в проблемной области. R2 Верификация спецификации согласно критерию охвата. R3 Гарантия правильности на ограниченных аспектах поведения	R1 Метод и нотация, которые помогают предотвратить или обнаружить внутреннюю несогласованность, отсутствующее поведение или математически несовместимые выражения. R2 Проверка спецификации согласно критериям охвата. R3 Проверка спецификации, основанная на систематическом анализе и/или систематическом предотвращении определенных типов отказов внутри спецификации	- Примечание. Может усложнить достижение этого свойства, если метод не является дружественным для приложения или не зависящим от предметной области	-	R1 Уменьшает неоднозначность в спецификации
2. Прямая прослеживаемость между спецификацией требований к безопасности системы и требованиями к безопасности программного обеспечения	R1 Уверенность в том, что спецификация требований к безопасности программного обеспечения получает системные требования к безопасности	-	-	-	-	-
3. Обратная прослеживаемость между требованиями к системе безопасности и предполагаемыми потребностями в безопасности	-	R1 Уверенность в том, что спецификация требований к программному обеспечению системы безопасности не содержит ненужной сложности	-	R1 Прослеживаемость потребностей безопасности управляемого оборудования улучшает понятность	R1	R1
4. Компьютерные средства разработки спецификаций для поддержки перечисленных выше подходящих методов/средств	R1 Инкапсуляция знаний проблемной области управляемого оборудования и программной среды. R2 Если перечень вопросов, которые необходимо учесть в таблице контрольных проверок, определен, обоснован и охватывает проблему	R1 Методы функционального моделирования. R2 Функциональное моделирование в соответствии с определенными и обоснованными критериями охвата	R2 Синтаксическая и семантическая проверки, чтобы убедиться в том, что соответствующие правила выполнены	R1 Анимация или просмотр спецификации	R1 Идентификация связанных и несвязанных с безопасностью функций	R1 Помощь в прослеживаемости и в охвате. R2 Измерение прослеживаемости и охвата

Методы/средства	Свойства
	Полнота спецификации требований к программному обеспечению системы безопасности	Корректность спецификации требований к программному обеспечению системы безопасности	Отсутствие собственных ошибок проекта	Простота и ясность	Предсказуемость поведения	Верифицируемость и тестируемость проекта	Отказоустойчивость	Защита от отказов по общей причине, вызванной внешним событием
1. Обнаружение ошибок	-	-	-	- Достижение этого свойства может быть сложным	R1 Контроль логики выполнения программы	-	R1 (R2, если цели охвата определены, обоснованы и выполнены)	R1 или -
2. Коды обнаружения ошибок	-	-	-	- Достижение этого свойства может быть сложным	- Достижение этого свойства может быть сложным	-	R1 (R2, если цели охвата определены, обоснованы и выполнены). Эффективен для конкретных областей применения, например для передачи данных	R1 Эффективен для конкретных областей применения, например для передачи данных
3a. Программирование с проверкой ошибок	-	R2 С помощью постусловий проверяется соответствие детальным требованиям	-	R2 Предусловия ограничивают входное пространство	R2 Постусловия проверяют выходы, которые должны быть ожидаемыми либо приемлемыми	R2 Предусловия ограничивают входное пространство и, следовательно, необходимое тестируемое пространство	R3 Эффективен для конкретных отказов	R3 Эффективен для конкретных отказов
3b. Методы контроля (при реализации процесса контроля и контролируемой функции на одном компьютере обеспечивается их независимость)	-	-	R2 Независимый контроль реализует минимальные требования безопасности	R2 Независимый контроль обеспечивает неявное разнообразие	R2 Независимый контроль простым способом реализует лишь минимальные требования безопасности	R2 Независимый контроль реализует лишь минимальные требования безопасности	R1 (R2, если цели охвата определены, обоснованы и выполнены)	R1 (R2, если цели охвата определены, обоснованы и выполнены)
3c. Методы контроля (реализация процесса контроля и контролируемой функции на разных компьютерах)	-	-	R2 Независимый контроль реализует минимальные требования безопасности	R2 Независимый контроль обеспечивает неявное разнообразие	R2 Независимый контроль простым способом реализует лишь минимальные требования безопасности	R2 Независимый контроль реализует лишь минимальные требования безопасности	R1 (R2, если цели охвата определены, обоснованы и выполнены)	R1 (R2, если цели охвата определены, обоснованы и выполнены)
3d. Многовариантное программирование, реализующее одну спецификацию требований к программному обеспечению системы безопасности	-	-	R1	- Примечание. Достижение этого свойства может быть сложным, если реализуется в одной исполнимой программе	-	-	R1 Если отказ одной программы не оказывает негативное влияние на другие. R2 Если цели охвата определены, обоснованы и выполнены. Не защищает от отказов в спецификации требований	R1 Если отказ одной программы не оказывает негативное влияние на другие. R2 Если цели охвата определены, обоснованы и выполнены. Не защищает от отказов в спецификации требований
3e. Функционально многовариантное программирование, реализующее различные спецификации требований к программному обеспечению системы безопасности. Обычно это требуется, если применяются датчики, работающие на различных физических принципах	-	-	R1	- Примечание. Достижение этого свойства может быть сложным, если реализуется в одной исполнимой программе	-	-	R1 Если отказ одной программы не оказывает негативное влияние на другие	R1 Если отказ одной программы не оказывает негативное влияние на другие. Защищает от отказов в спецификации требований
3f. Восстановление предыдущего состояния	-	-	- Примечание. Достижение этого свойства может быть сложным	-	- Примечание. Достижение этого свойства может быть сложным	-	R2	R1 (R2, если цели охвата определены, обоснованы и выполнены)
3g. Проектирование программного обеспечения, не сохраняющего состояние (или проектирование программного обеспечения, сохраняющего ограниченное описание состояния)	R2 Если несохранение или сохранение ограниченного описания состояния предусмотрено в требованиях к системе безопасности	R2 Если несохранение или сохранение ограниченного описания состояния предусмотрено в требованиях к системе безопасности	R2 Если несохранение или сохранение ограниченного описания состояния предусмотрено в требованиях к системе безопасности	R1 R2 Если определены, обоснованы и выполнены ограничения для определенного возможного числа состояний	R1 R2 Если определены, обоснованы и выполнены ограничения для определенного возможного числа состояний	R1 R2 Если определены, обоснованы и выполнены цели верификации/тестового охвата возможных состояний	R1 Если это приводит к самовосстановлению проекта. R2 Если определены, обоснованы и выполнены цели самовосстановления	R1 Если это приводит к самовосстановлению проекта. R2 Если определены, обоснованы и выполнены цели самовосстановления
4a. Механизмы повторных попыток парирования сбоя	-	-	-	-	Достижение этого свойства может быть сложным	-	R1 (R2, если цели охвата определены, обоснованы и выполнены)	R1 (R2, если цели охвата определены, обоснованы и выполнены)
4b. Постепенное отключение функций	-	-	- Примечание. Достижение этого свойства может быть сложным	-	-	-	R1 R2, если цели охвата определены, обоснованы и выполнены	R1 R2, если цели охвата определены, обоснованы и выполнены
5. Исправление ошибок методами искусственного интеллекта	-	- Примечание. Достижение этого свойства может быть сложным	- Примечание. Достижение этого свойства может быть сложным	- Примечание. Достижение этого свойства может быть сложным	R1 Примечание. Достижение этого свойства может быть сложным	- Примечание. Достижение этого свойства может быть сложным	-	-
6. Динамическая реконфигурация	-	- Примечание. Достижение этого свойства может быть сложным	- Примечание. Достижение этого свойства может быть сложным	- Примечание. Достижение этого свойства может быть сложным	- Примечание. Достижение этого свойства может быть сложным	- Примечание. Достижение этого свойства может быть сложным	-	-
7. Модульный подход	-	R1 R2, если цели декомпозиции определены, обоснованы и выполнены. В противном случае только R1	R1 Если отсутствие конкретных типов собственных ошибок в проекте может быть верифицировано независимо для каждого модуля. R3 Если отсутствие конкретных типов собственных ошибок в проекте может быть строго обосновано при проектировании модуля	R1 R2, если цели декомпозиции определены, обоснованы и выполнены	R1 R2, если цели декомпозиции определены, обоснованы и выполнены	R1 R2, если цели декомпозиции определены, обоснованы и выполнены	R1 Если модули, на которые не влияет отказ модуля, способствуют ослаблению отказа/восстановлению отказавшего модуля. R3 Если появление конкретных отказов может быть строго обосновано	R1 Если модули, на которые могут влиять внешние события и которые могут повлиять на несколько каналов одновременно, выявлены и полностью проверены. R3 Если появление конкретных внешних событий может быть строго обосновано
8. Использование доверительных/проверенных элементов программного обеспечения (при наличии)	-	R1 R2 R3 Если элемент вносит существенный вклад в выполнение требований к системе безопасности и правильно используется	R1 R2 R3 Элементы, проверенные на практике. Такая способность каждого элемента должна быть обоснована	R1 Модульный подход декомпозирует полную сложность на хорошо понятные блоки	R1 R2 R3 Элементы, проверенные на практике	-	R1 R2, если возможности отказоустойчивости незамедлительно предоставляются элементом и правильно используются или если вокруг элемента построен уровень защиты	R1 R2, если защита от внешних событий, которые могут повлиять на несколько каналов одновременно, незамедлительно предоставляется элементом и правильно используется или если вокруг элемента построен уровень защиты
9. Прямая прослеживаемость между спецификацией требований к программному обеспечению системы безопасности и архитектурой программного обеспечения	R1 Уверенность в том, что архитектура соответствует требованиям к программному обеспечению системы безопасности	-	-	-	-	-	-	-
10. Обратная прослеживаемость между архитектурой программного обеспечения и спецификацией требований к программному обеспечению системы безопасности	-	R1 Уверенность в том, что архитектура излишне не усложнена	-	-	-	-	-	-
11a. Методы структурных диаграмм	-	R1	-	R1 (Графические описания легче понять)	-	R1 (Структурируемые проекты легче верифицировать и тестировать)	-	-
11b. Полуформальные методы	R1 Дружественные или зависящие от предметной области метод спецификации и нотация	R1 Дружественные или зависящие от предметной области метод спецификации и нотация	R2 Может выявить внутреннюю несогласованность или неработоспособность или математически некорректные выражения	-	R2 (Предоставляет свидетельства для предсказуемости)	R2 (Предоставляет свидетельства для внутренней согласованности модели проекта)	-	-
11c. Методы формального проектирования и усовершенствования	R1 Дружественные или зависящие от предметной области метод спецификации и нотация	R1 Обеспечивает точное определение ограниченных аспектов поведения, которые должны соответствовать предметной области	R3 Может выявить внутреннюю несогласованность или неработоспособность или математически некорректные выражения	- Примечание. Достижение этого свойства может быть сложным	R2 Предоставляет доказательства для предсказуемости	R2	-	-
11d. Автоматическая генерация программного обеспечения	R1 Если исполнимое программное обеспечение автоматически сгенерировано в соответствии со спецификацией требований или проектом, который, как было показано, является корректным. R2 Если у инструментов генерации, как было показано, есть соответствующая история использования	R1 Если исполнимое программное обеспечение автоматически сгенерировано в соответствии со спецификацией требований или проектом, который, как было показано, является полным. R2 Если у инструментов генерации, как было показано, есть соответствующая история использования	R1 Если инструменты генерации гарантируют предотвращение определенных внутренних отказов проекта. R2 Если у инструментов генерации, как было показано, есть соответствующая история использования	-	-	-	R1 R2 R3 Если способность к отказоустойчивости генерируется автоматически	-
12. Компьютерные средства разработки спецификаций и проектирования	R1 Инкапсуляция знаний проблемной области управляемого оборудования и программной среды. R2 Если определена, обоснована и охвачена таблица контрольных проверок, а также учтены ее проблемы	R1 Осуществление обратной прослеживаемости требований. Функциональные методы моделирования. R2 Функциональное моделирование согласно определенным и обоснованным критериям охвата	R2 Семантические и синтаксические проверки для гарантирования того, что соответствующие правила выполнены	R1 Анимация и просмотр	-	R2 Семантические и синтаксические проверки, чтобы гарантировать, что соответствующие правила выполнены	-	-
13a. Циклическое поведение с гарантированным максимальным временем цикла	-	R1 Для вопросов синхронизации в спецификации. R3 Если максимальное время цикла определено строгим выводом	R1 Для вопросов синхронизации в спецификации. R3 Если максимальное время цикла определено строгим выводом	-	R1 Для вопросов синхронизации в спецификации. R3 Если максимальное время цикла определено строгим выводом	R1 Для вопросов синхронизации в спецификации. R3 Если максимальное время цикла определено строгим выводом	-	-
13b. Архитектура с распределением	R3 Полнота гарантируется распределением (только для свойств синхронизации)	R3 Корректность гарантируется распределением (только для свойств синхронизации)	R3 Строгая гарантия от внутренних отказов синхронизации	R1 Определяемая нотация значительно снижает непонимание, в основе подхода - использование предсказуемости	R3 Неблагоприятное влияние: полное разделение во времени, поэтому влияния отсутствуют	R3 Существенное сокращение усилий, необходимых для тестирования и сертификации системы	R2 Прозрачная реализация отказоустойчивости	R3 Внешние прерывания не могут вмешаться в расписание с распределенным временем, приоритетом для которого являются задачи, критические к безопасности
13c. Управление событиями с гарантированным максимальным временем реакции	-	-	-	R1 Архитектуры, управляемые событиями, могут быть непонятными	R2 Архитектуры, управляемые событиями, могут быть непонятными	R1 Делает тестирование более предсказуемым	-	-
14. Статическое выделение ресурсов	R1	R1	R1	R1 Делает проектирование более понятным	R2 С архитектурой, определяющей использование ресурсов	R1 Делает тестирование более предсказуемым	-	-
15. Статическая синхронизация доступа к разделяемым ресурсам	-	R1 Обеспечивает предсказуемость при доступе к ресурсам	R1 R3, если поддерживается строгими выводами, обеспечивающими корректность синхронизации	R1 Делает проектирование более понятным	R1 R3, если поддерживается строгими выводами, обеспечивающими корректность синхронизации	-	-	-

Методы/средства	Свойства
	Поддержка разработки программного обеспечения с требуемыми свойствами программного обеспечения	Четкость работы и функциональность инструментальных средств	Корректность и воспроизводимость результата
1. Выбор соответствующего языка программирования	R2 Если строгая типизация, ограниченное преобразование типов. R3 Если определены семантики для формального вывода	-	-
2. Строго типизированные языки программирования	R2	-	-
3. Подмножество языка	R2 В зависимости от выбранного подмножества	R1	R2 В зависимости от выбранного подмножества
4a. Сертифицированные средства и сертифицированные трансляторы	-	R2	R2
4b. Инструментальные средства, заслуживающие доверия на основании опыта использования	R1 Если класс обнаруживаемых программных ошибок определяется систематически. R2 Если существует объективное доказательство подтверждения соответствия эффективности инструментального средства	R1 Если инструментальное средство поддержки не является специальным для данной проблемной области. R2 Если инструментальное средство поддержки было создано специально для данной проблемной области	R1 R2 Если существует объективное доказательство подтверждения соответствия эффективности инструментального средства, например набор средств для подтверждения соответствия компиляторов

Методы/средства	Свойства
	Полнота спецификации требований к программному обеспечению системы безопасности	Корректность спецификации требований к безопасности программного обеспечения	Отсутствие собственных ошибок проекта	Простота и ясность	Предсказуемость поведения	Верифицируемость и тестируемость проекта	Отказоустойчивость	Отсутствие отказов по общей причине
1a. Методы структурных диаграмм	R2	R1	R1	-	-	R1 Структурированные проекты более готовы к верификации и тестированию	-	-
1b. Полуформальные методы	R2	R2	R2	-	R2	R2	-	-
1c. Методы формального проектирования и усовершенствования	-	R3	R3	- Примечание. Достижение этого свойства может быть сложным	R3 (Предоставляет свидетельства для предсказуемости)	R2	-	-
2. Средства автоматизированного проектирования	R2 Автоматизированное средство разработки спецификации, применяющее семантические и синтаксические проверки и гарантирующее, что соответствующие правила удовлетворены	R1	R2 Автоматизированное средство разработки спецификации, применяющее семантические и синтаксические проверки и гарантирующее, что соответствующие правила удовлетворены	-	-	R2 Основанные на CASE технологии средства поддержки тестового охвата и статической проверки	-	-
3. Программирование с защитой	-	-	-	- Примечание. Достижение этого свойства может быть сложным	- Примечание. Достижение этого свойства может быть сложным	-	R1 (R2, если цели охвата определены, обоснованы и выполнены)	R1 (R2, если цели охвата определены, обоснованы и выполнены)
4. Модульный подход	-	-	R1	R1	R1	R1	-	-
5. Стандарты для проектирования и кодирования	-	-	R1	R1	R1	R1	-	-
6. Структурное программирование	-	R1	R1	R1	R1	R1	-	-
7. Использование проверенных/верифицированных программных модулей и компонентов (по возможности)	-	-	R1 Элементы, проверенные на практике	R1 Модульный подход декомпозирует сложность всей системы на хорошо понятные блоки	R1 Поведение элемента уже известно	-	-	-
8. Прямая прослеживаемость между спецификацией требований к программному обеспечению системы безопасности и проектом программного обеспечения	R1 Уверенность в том, что проект соответствует требованиям к программному обеспечению системы безопасности	-	-	-	-	-	-	-

Методы/средства	Свойства
	Полнота тестирования и интеграции в соответствии со спецификацией проекта программного обеспечения	Корректность тестирования и интеграции в соответствии со спецификацией проекта программного обеспечения (успешное выполнение)	Воспроизводимость	Точно определенная тестируемая конфигурация
1. Вероятностное тестирование	R1 (R2, если цели охвата набором тестовых данных, отражающих реальные условия функционирования программы, определены, обоснованы и выполнены)	R1 (R2, если необходимые результаты определены, обоснованы и выполнены)	-	-
2. Динамический анализ и тестирование	R1 (R2, если цели охвата структурированием определены, обоснованы и выполнены)	R1 (R2, если необходимые результаты определены, обоснованы и выполнены)	-	-
3. Регистрация и анализ данных	-	R1	R1 Способствует согласованности процедур тестирования	R2 Если журналы записей об отказах/тестах включают в себя подробную информацию о серии базовых программ
4. Функциональное тестирование и тестирование методом "черного ящика"	R1 (R2, если цели охвата набором тестовых данных, отражающих реальные условия функционирования программы, определены, обоснованы и выполнены)	R1 (R2, если необходимые результаты определены, обоснованы и выполнены)	-	-
5. Тестирование рабочих характеристик	-	R1 (R2, если необходимые результаты определены, обоснованы и выполнены)	-	-
6. Тестирование, основанное на модели (МВТ)	R2 МВТ позволяет на ранних стадиях выявлять неоднозначности в спецификации и проекте. МВТ используется начиная с требований. R3 Если при моделировании используются формальные выводы и генерация тестовых примеров (TCG)	R2 Оценка результатов и комплектов регрессионных тестов - ключевое преимущество МВТ. R3 Если применять формальные модели, то можно получить объективные данные по охвату тестами	R3 МВТ (с TCG) направлен на автоматическое выполнение сгенерированных тестов	R2 МВТ работает автоматически, тестируемая конфигурация должна быть точно определена; выполнение сгенерированных тестов подобно тестированию методом "черного ящика" с возможностью измерения уровня охвата исходного кода
7. Тестирование интерфейса	-	R1 (R2, если необходимые выходы определены, обоснованы и выполнены)	-	-
8. Управление тестированием и средства автоматизации	R1 (R2, если цели охвата тестами определены, обоснованы и выполнены)	-	R1 Автоматизация способствует согласованности	R2 Обеспечивает воспроизводимость тестирования
9. Прямая прослеживаемость между спецификацией проекта программного обеспечения и спецификациями тестирования модуля и интеграции	R1 Уверенность в том, что спецификация тестов соответствует требованиям к программному обеспечению системы безопасности	-	-	R2 Уверенность в четкой основе тестируемых требований
10. Формальная верификация	R3 Если для создания тестовых примеров используется формальный вывод для того, чтобы показать, что все аспекты проекта были реализованы	R3 Дает объективные данные о выполнении всех требований к программному обеспечению системы безопасности	R1 Если средства поддержки недоступны. R2 Если инструмент поддерживается	-

Методы/средства	Свойства
	Полнота интеграции в соответствии со спецификацией проекта	Корректность интеграции в соответствии со спецификацией проекта (успешное выполнение)	Воспроизводимость	Точно определенная конфигурация интеграции
1. Функциональное тестирование и тестирование методом "черного ящика"	R1 (R2, если цели охвата набором тестовых данных, отражающих реальные условия функционирования программы, определены, обоснованы и выполнены)	R1 (R2, если необходимые результаты определены, обоснованы и выполнены)	-	-
2. Тестирование выполнения	-	R1 (R2, если необходимые результаты определены, обоснованы и выполнены)	-	-
3. Прямая прослеживаемость между требованиями проектирования системы и программного обеспечения к интеграции программных и аппаратных средств и спецификациями тестирования интеграции программных и аппаратных средств	R1 Уверенность в том, что спецификации тестирования интеграции программных и аппаратных средств соответствуют требованиям интеграции	-	-	R2 Уверенность в четкой основе тестируемых требований

Методы/средства	Свойства
	Полнота подтверждения соответствия в соответствии со спецификацией проекта программного обеспечения	Корректность подтверждения соответствия в соответствии со спецификацией проекта программного обеспечения (успешное выполнение)	Воспроизводимость	Подтверждение соответствия точно определенной конфигурации
1. Вероятностное тестирование	R1 (R2, если цели охвата набором тестовых данных, отражающих реальные условия функционирования программы, определены, обоснованы и выполнены)	R1 (R2, если необходимые результаты определены, обоснованы и выполнены)	-	-
2. Моделирование процесса	R1	R1 (R2, если необходимые результаты определены, обоснованы и выполнены)	-	R2 Дает определение внешнего окружения
3. Функциональное тестирование и тестирование методом "черного ящика"	R1 (R2, если цели охвата набором тестовых данных, отражающих реальные условия функционирования программы, определены, обоснованы и выполнены)	R1 (R2, если необходимые результаты определены, обоснованы и выполнены)	-	-
4. Прямая прослеживаемость между спецификацией требований к программному обеспечению системы безопасности и планом подтверждения соответствия программного обеспечения системы безопасности	R1 Уверенность в том, что план подтверждения соответствия программного обеспечения системы безопасности охватывает требования к программному обеспечению системы безопасности	-	-	R2 Уверенность в четкой основе тестируемых требований
5. Обратная прослеживаемость между планом подтверждения соответствия программного обеспечения системы безопасности и спецификацией требований к программному обеспечению системы безопасности	-	R1 Уверенность в том, что план подтверждения соответствия программного обеспечения системы безопасности не содержит излишней сложности	-	R2 Уверенность в четкой основе тестируемых требований

Методы/средства	Свойства
	Полнота модификации в соответствии с требованиями к модификации	Корректность модификации в соответствии с требованиями к модификации	Отсутствие собственных ошибок проекта	Предотвращение нежелательного поведения	Верифицируемость и тестируемость проекта	Регрессионное тестирование и охват проверкой
1. Анализ влияния	-	-	-	R1	R1	R1
2. Повторная верификация измененных программных модулей	R1 (R2, если существуют объективные цели проверки)	R1 (R2, если существуют объективные цели проверки)	R1 (R2, если существуют объективные цели проверки)	-	-	R1/R2 (R2, если существуют объективные цели проверки)
3. Повторная верификация программных модулей, на которые оказывают влияние изменения в других модулях	R1 (R2, если существуют объективные цели проверки)	R1 (R2, если существуют объективные цели проверки)	R1 (R2, если существуют объективные цели проверки)	-	-	R1 (R2, если существуют объективные цели проверки)
4a. Повторная верификация системы в целом	R1 (R2, если существуют объективные цели проверки)	R1 (R2, если существуют объективные цели проверки)	-	R1 (R2, если существуют объективные цели проверки)	-	R1 (R2, если существуют объективные цели проверки)
4b. Регрессионное подтверждение соответствия	R1 (R2, если существуют объективные цели проверки)	R1 (R2, если существуют объективные цели проверки)	-	R1 (R2, если существуют объективные цели проверки)	-	R1 (R2, если существуют объективные цели проверки)
5. Управление конфигурацией программного обеспечения	-	-	-	-	-	R1
6. Регистрация и анализ данных	R1	R1	-	-	-	-
7. Прямая прослеживаемость между спецификацией требований к программному обеспечению системы безопасности и планом модификации программного обеспечения (включая повторные верификацию и подтверждение соответствия)	R1 Уверенность в том, что план модификации программного обеспечения (включая повторные верификацию и подтверждение соответствия) соответствует требованиям к программному обеспечению системы безопасности	-	-	-	-	-
8. Обратная прослеживаемость между планом модификации программного обеспечения (включая повторные верификацию и подтверждение соответствия) и спецификацией требований к программному обеспечению системы безопасности	-	R1 Уверенность в том, что план модификации программного обеспечения (включая повторные верификацию и подтверждение соответствия) не содержит излишней сложности	-	-	-	-

Методы/средства	Свойства
	Полнота верификации в соответствии с предыдущей стадией	Корректность верификации в соответствии с предыдущей стадией (успешное выполнение)	Воспроизводимость	Верификация точно определенной конфигурации
1. Формальное доказательство	-	R3	-	-
2. Анимация спецификации и тестирования	R1	R1	-	-
3. Статический анализ	-	R1/R2/R3 (Строгость может меняться от возможностей подмножества языка до формального анализа)	-	-
4. Динамический анализ и тестирование	R1 (R2, если цели охвата структурированием определены, обоснованы и выполнены)	R1 (R2, если необходимые результаты определены, обоснованы и выполнены)	-	-
5. Прямая прослеживаемость между спецификацией проекта программного обеспечения и планом верификации (включающим в себя верификацию данных) программного обеспечения	R1 Уверенность в том, что план верификации программного обеспечения (включающий в себя верификацию данных) соответствует требованиям к программному обеспечению системы безопасности	-	-	R2 Уверенность в четкой основе тестируемых требований
6. Обратная прослеживаемость между планом верификации (включающим верификацию данных) программного обеспечения и спецификацией проекта программного обеспечения	-	R1 Уверенность в том, что план верификации программного обеспечения (включающий в себя верификацию данных) не содержит излишней сложности	-	R2 Уверенность в четкой основе тестируемых требований
7. Численный анализ в автономном режиме	-	R1 Высокая уверенность в ожидаемой точности вычислений (R2 при объективных критериях приемки. R3, если используется вместе с объективным систематическим доказательством, обосновывающим критерии приемки)	-	-

Методы/средства	Свойства
	Полнота оценки функциональной безопасности в соответствии с требованиями настоящего стандарта	Корректность оценки функциональной безопасности в соответствии с проектными спецификациями (успешное выполнение)	Доступное для анализа решение всех выявленных проблем	Возможность модификации оценки функциональной безопасности после изменения проекта без необходимости проведения серьезной переработки оценки	Воспроизводимость	Своевременность	Точно определенная конфигурация
1. Таблица контрольных проверок	R1	R1	R1	-	R1	-	-
2. Таблицы решений (таблицы истинности)	R1	R2	-	-	R2	-	-
3. Анализ отказов	R2	R2	R1 (Анализ отказов основан на согласованных списках отказов)	-	R1 (Анализ отказов основан на согласованных списках отказов)	-	-
4. Анализ отказов по общей причине различного программного обеспечения (если различное программное обеспечение используется)	R2	R2	R1 (Если анализ отказов по общей причине основан на согласованных списках источников общих причин)	-	R1 (Если анализ отказов по общей причине основан на согласованных списках источников общих причин)	-	-
5. Структурные схемы надежности	R1	R1	-	-	-	-	-
6. Прямая прослеживаемость между требованиями раздела 8 и планом оценки функциональной безопасности программного обеспечения	R1 Уверенность в том, что план оценки функциональной безопасности программного обеспечения соответствует требованиям раздела 8	-	-	-	-	-	-

Методы/средства	Свойства
	Полнота спецификации требований к программному обеспечению системы безопасности	Корректность спецификации требований к программному обеспечению системы безопасности	Отсутствие собственных ошибок проекта	Простота и ясность	Предсказуемость поведения	Верифицируемость и тестируемость проекта	Отказоустойчивость/обнаружение отказов	Отсутствие отказов по общей причине
1. Использование стандартов кодирования для сокращения вероятности ошибок	-	-	R1	R1 Запрещает отдельные конструкции языка	R1	R1	-	-
2. Не использовать динамические объекты	-	-	R1/R2/R3 В зависимости от используемого языка	-	R1/R2 В зависимости от используемого языка	R1/R2 В зависимости от используемого языка	-	-
3a. Не использовать динамические переменные	-	-	R1/R2/R3 В зависимости от используемого языка	-	R1/R2 В зависимости от используемого языка	R1/R2 В зависимости от используемого языка	-	-
3b. Проверка создания динамических переменных при выполнении программы	-	-	R1/R2/R3 В зависимости от используемого языка	-	R1/R2 В зависимости от используемого языка	R1/R2 В зависимости от используемого языка	-	-
4. Ограниченное использование прерываний	-	-	R1/R2 В зависимости от используемого языка	R1 Повышает ясность логики и последовательностей событий	R1/R2 В зависимости от используемого языка	R1/R2 В зависимости от используемого языка	-	-
5. Ограниченное использование указателей	-	-	R1/R2 В зависимости от используемого языка	R1 Повышает ясность логики	R1/R2 В зависимости от используемого языка	R1/R2 В зависимости от используемого языка	-	-
6. Ограниченное использование рекурсий	-	-	R1/R2 В зависимости от используемого языка	-	R1/R2 В зависимости от используемого языка	R1/R2 В зависимости от используемого языка	-	-
7. Не использовать неструктурированное управление в программах, написанных на языках высокого уровня	-	-	R1/R2 В зависимости от используемого языка	R1 Повышает ясность логики	R1/R2 В зависимости от используемого языка	R1/R2 В зависимости от используемого языка	-	-
8. Не использовать автоматическое преобразование типов	-	R2 Предотвращает погрешности округления	R2 Предотвращает погрешности округления	R1	R1	-	-	-

Методы/средства	Свойства
	Полнота тестирования и верификации в соответствии со спецификацией проекта программного обеспечения	Корректность тестирования и верификации в соответствии со спецификацией проекта программного обеспечения (успешное выполнение)	Воспроизводимость	Точно определенная тестируемая и верифицируемая конфигурация
1. Выполнение тестового примера, связанного с анализом граничных значений	-	R1 (R2, если заданы объективные критерии для граничных значений)	-	-
2. Выполнение тестового примера, связанного с предполагаемой ошибкой	-	R1	-	-
3. Выполнение тестового примера, связанного с введением ошибки	-	R1	-	-
4. Выполнение тестового примера, сгенерированного на основе модели	R2 МВТ используется начиная с требований и позволяет на ранних стадиях выявлять ошибки при проектировании и разработке программного обеспечения. R3 Если при моделировании используются формальные выводы и генерация тестовых примеров (TCG)	R2 Оценка результатов и комплектов регрессионных тестов - ключевое преимущество МВТ, что облегчает понимание последствий указанных требований. R3 Если применяются формальные модели, то можно получить объективные данные по охвату тестами	R3 МВТ (с TCG) направлен на автоматическое выполнение сгенерированных тестов	R2 МВТ работает автоматически, тестируемая конфигурация должна быть точно определена; выполнение сгенерированных тестов подобно тестированию методом "черного ящика" с возможностью измерения уровня охвата исходного кода
5. Моделирование реализации	-	R1 (R2, если цель - требования к производительности)	-	-
6. Разделение входных данных на классы эквивалентности	R1 Если профиль входных данных четко определен и прост в управлении своей структурой	R1 (Если разбиения, скорее всего, не содержат нелинейности, т.е. все члены класса являются действительно эквивалентными)	-	-
7. Структурное тестирование	-	R1 (R2 - существуют объективные цели охвата структурированием)	-	-

Методы/средства	Свойства
	Полнота тестирования, интеграции и подтверждения соответствия в соответствии со спецификациями проекта	Корректность тестирования интеграции и подтверждения соответствия в соответствии со спецификациями проекта (успешное выполнение)	Воспроизводимость	Точно определенная конфигурация для тестирования, интеграции и подтверждения соответствия
1. Выполнение тестового примера, на основе причинно-следственных диаграмм	R1	R1	-	-
2. Выполнение тестового примера, сгенерированного на основе модели (МВТ)	R2 Тестирование, основанное на модели, обеспечивает автоматическую генерацию эффективных контрольных примеров/процедур, используя модели системных требований и заданной функциональности. МВТ облегчает раннее выявление ошибок и понимание последствий указанных требований. R3 Если при моделировании используются формальные выводы и генерация тестовых примеров (TCG)	R2 МВТ основан на моделях (в основном функциональных/поведенческих), формируемых на основании требований. R3 Если применяются формальные модели, то можно получить объективные данные по охвату тестами	R3 МВТ (с TCG) направлен на автоматическое выполнение сгенерированных тестов	R2 МВТ работает автоматически, тестируемая конфигурация должна быть точно определена
3. Макетирование/анимация	-	R1	-	-
4. Разделение входных данных на классы эквивалентности, включая анализ граничных значений	R1 Если профиль входных данных четко определен и прост в управлении своей структурой	R1 (Если разбиения, как правило, не содержат нелинейности, то есть все члены класса являются действительно эквивалентными)	-	-
5. Моделирование процесса	-	R1	-	R2 Дает определение внешнего окружения

Методы/средства	Свойства
	Полнота оценки функциональной безопасности в соответствии с требованиями настоящего стандарта	Корректность оценки функциональной безопасности в соответствии с проектными спецификациями (успешное выполнение)	Доступное для анализа решение всех выявленных проблем	Возможность модификации оценки функциональной безопасности после изменения проекта без необходимости проведения серьезной переработки оценки	Воспроизводимость	Своевременность	Точно определенная конфигурация
1a. Причинно-следственные диаграммы	R2	R2	-	-	-	-	-
1в. Анализ методом дерева событий	R2	R2	-	-	-	-	-
2. Анализ методом дерева отказов	R2	R2	-	-	-	-	-
3. Анализ функциональных отказов программного обеспечения	R2	R2	-	-	-	-	-

Методы/средства	Свойства
	Полнота подтверждения соответствия в соответствии со спецификацией проекта программного обеспечения	Корректность подтверждения соответствия в соответствии со спецификацией проекта программного обеспечения (успешное выполнение)	Воспроизводимость	Точно определенная конфигурация подтверждения соответствия
1. Диаграммы потоков данных	-	R1	-	-
2a. Метод конечных автоматов	R3	R3	-	-
2b. Формальные методы	R3	R3	-	-
2c. Моделирование во времени сетями Петри	-	R1	-	-
3. Моделирование реализации	-	R1	-	-
4. Макетирование/анимация	-	R1	-	-
5. Структурные диаграммы	-	R1	-	-

Методы/средства	Свойства
	Полнота тестирования и интеграции в соответствии со спецификациями проекта	Корректность тестирования и интеграции в соответствии со спецификациями проекта (успешное выполнение)	Воспроизводимость	Точно определенная тестируемая и интегрируемая конфигурация
1. Проверка на критические нагрузки и стресс-тестирование	-	R1 (R2, если установлены объективные цели)	-	-
2. Ограничения на время ответа и объем памяти	-	R1 (R2, если установлены объективные цели)	-	-
3. Требования к реализации	-	R1 (R2, если установлены объективные цели)	-	-

Методы/средства	Свойства
	Полнота спецификации требований к программному обеспечению системы безопасности	Корректность спецификации требований к программному обеспечению системы безопасности	Отсутствие собственных ошибок в проекте	Ясность требований к системе безопасности	Отсутствие неблагоприятного взаимовлияния функций, не связанных с безопасностью, с системой безопасности, реализуемой программным обеспечением	Простота и ясность	Предсказуемость поведения	Верифицируемость и тестируемость проекта	Отказоустойчивость/обнаружение отказов	Отсутствие отказов по общей причине от внешних событий
1. Логические диаграммы/диаграммы функциональных блоков	R2	R2	R2	-	-	R1	R2	-	-	R1
2. Последовательностные диаграммы	R2	R2	R2	-	-	R1	R2	-	-	R2
3. Диаграммы потоков данных	R1	R1	R1	-	-	R1 Подходит для обработки транзакций	-	-	-	R1
4a. Конечные автоматы/диаграммы переходов	R2	R2	R2	-	-	R1 Математически полная спецификация последовательности событий	R2	-	-	R2
4b. Моделирование во времени сетями Петри	R2	R2	R2	-	-	R1 Определяет взаимодействия в реальном времени	R2	-	-	R2
5. Модели данных сущность - связь - атрибут	R1	R1	R1	-	-	R1	-	-	-	R1
6. Диаграммы последовательности сообщений	R2	R2	R2	-	-	R1	R2	-	-	R2
7. Таблицы решений и таблицы истинности	R2	R2	R2	-	-	R1 Для комбинационной логики	R2	-	-	R2

Методы/средства	Свойства
	Полнота верификации в соответствии с предыдущей стадией	Корректность верификации в соответствии с предыдущей стадией (успешное выполнение)	Воспроизводимость	Точно определенная верифицируемая конфигурация
1. Анализ граничных значений	-	R1 (R2, если заданы объективные критерии для граничных значений)	-	-
2. Таблица контрольных проверок	-	R1	-	R1
3. Анализ потоков управления	-	R1	-	-
4. Анализ потоков данных	-	R1	-	-
5. Предположение ошибок	-	R1	-	-
6a. Формальные проверки, включая конкретные критерии	R2	R2	-	R2
6b. Сквозной контроль (программного обеспечения)	R1	R1	-	R1
7. Тестирование на символьном уровне	-	R2 R3, если применяется для формально определенных предусловий и постусловий и выполняется инструментальным средством, использующим математически строгий алгоритм	-	-
8. Анализ проекта	R2	R1 R2 (с объективными критериями)	-	R2
9. Статический анализ выполнения программы с ошибкой	-	R1 R3 для определенных классов ошибок, если выполняется инструментальным средством, использующим математически строгий алгоритм	-	-
10. Временной анализ выполнения при наихудших условиях	R1	R3	-	R2

Методы/средства	Свойства
	Полнота спецификации требований к программному обеспечению системы безопасности	Корректность спецификации требований к программному обеспечению системы безопасности	Отсутствие собственных ошибок проекта	Простота и ясность	Предсказуемость поведения	Верифицируемость и тестируемость проекта	Отказоустойчивость/обнаружение отказов	Отсутствие отказов по общей причине
1. Ограничение размера программного модуля	-	-	R1	R1	R1	R1	-	-
2. Управление сложностью программного обеспечения	-	-	R1	R1	R1	R1	-	-
3. Ограничение доступа/инкапсуляция информации	-	-	R1	R1	R1	R1	-	-
4. Ограниченное число параметров/фиксированное число параметров подпрограммы	-	-	R1	R1	R1	R1	-	-
5. Одна точка входа и одна точка выхода в каждой подпрограмме и функции	-	-	R1	R1	R1	R1	-	-
6. Полностью определенный интерфейс	-	-	R2	R1	R1	R1	-	-

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

Требование по МЭК 61508-2	Обеспечение/средства, важные для пользователей	Примечание
7.2	Программное обеспечение	-
7.2.3.1	Прикладное программное обеспечение	-
7.2.3.2 - 7.2.3.6	Программное обеспечение	-
7.2.3.3	Только аппаратные средства	-
7.3	Программное обеспечение	7.3.2.2, перечисление f), - только аппаратные средства
7.4	Программное обеспечение	-
7.4.2.1 - 7.4.2.12	Программное обеспечение	-
7.4.2.13, 7.4.2.14	Только аппаратные средства	-
7.4.3.1 - 7.4.3.3	Программное обеспечение	-
7.4.3.4	Только аппаратные средства	-
7.4.4	Только аппаратные средства	-
7.4.5	Только аппаратные средства	-
7.4.6	Программное обеспечение	7.4.7.6 - только аппаратные средства
7.4.7	Программное обеспечение	7.4.7.1, перечисления a), b), - только аппаратные средства
7.4.8	Только аппаратные средства	-
7.4.9.1 - 7.4.9.3	Программное обеспечение	-
7.4.9.4, 7.4.9.5	Только аппаратные средства	-
7.4.9.6, 7.4.9.7	Программное обеспечение	-
7.4.10	Программное обеспечение	-
7.4.11	Только аппаратные средства	-
7.5	Программное обеспечение	-
7.6	Программное обеспечение	-
7.6.2.1, перечисление a)	Аппаратные средства	-
7.6.2.4	В основном аппаратные средства	-
7.7	Программное обеспечение	7.7.2.3, 7.7.2.4 - в основном прикладное программное обеспечение
7.8	Программное обеспечение	-
7.9	В основном прикладное программное обеспечение	-
8	Программное обеспечение	-
Приложение A.1	В основном аппаратные средства	-
Приложение A.2 и таблицы	В основном аппаратные средства	Таблица A.10 - программное обеспечение
Приложение A.3	В основном аппаратные средства	Таблицы A.17, A.18 - содержат некоторые аспекты программного обеспечения
Приложение B, все таблицы	Программное обеспечение	-
Приложение C	Аппаратные средства	-
Приложение D	Программное обеспечение	D.2.3 - только аппаратные средства
Приложение E	Только аппаратные средства	-
Приложение F	Только аппаратные средства	-

Термин	Неформальное определение
Связность	Мера прочности связей между данными и подпрограммами внутри одного модуля
Связывание	Мера прочности связей между модулями
Инкапсуляция	Ограничение внешнего доступа к внутренним (личным) данным и подпрограммам; термин используется главным образом с объектно-ориентированными программами
Независимость	Мера отсутствия связей между частями программы; антоним понятия "связывание"
Модуль	Выполняющая некоторую функцию ограниченная часть программного обеспечения, которая может иметь собственные данные: класс, иерархию классов, подпрограммы, блок, модуль, пакет и др. в соответствии с языком программирования
Интерфейс	Хорошо определенный набор заголовков подпрограмм, обеспечивающий доступ к модулю
Случайные данные (данные "бродяги")	Полученные данные, не используемые в модуле, но передающиеся в другой модуль

Связывание	Определение	Объяснение	Обоснование	Примечание
Связывание с помощью интерфейсов, инкапсуляция	Связывание только для хорошо определенного множества подпрограмм	Доступ к модулю или к его данным только через подпрограммы; любое изменение величины переменной, любой вопрос о величине такой переменной или любой сервис, требуемый от модуля, выполняется через вызов подпрограммы	Заголовки подпрограмм (сигнатуры) модулей объясняют доступные сервисы. Если требуется изменить модуль, то часть этих изменений может быть выполнена в самом модуле, не затрагивая другие модули. Поддерживает слабое связывание - в целом рекомендуется	В основном для объектно-ориентированных программ, классов, иерархии классов, библиотек; не для подпрограмм
Связывание с помощью данных списка параметров	Передача только данных списка параметров или идентификаторов подпрограмм	Доступ к модулю или к его данным только через переменные или объекты, указанные в заголовке подпрограммы; любое изменение величины переменной, любой вопрос о величине такой переменной являются явными	Заголовок подпрограмм содержит данные или объекты, включенные в вызов подпрограммы. Поддерживает слабое связывание - в целом рекомендуется	Внутри классов объектно-ориентированных программ этот принцип обычно не встречается. К локальным переменным можно получить прямой доступ. Строгое следование этому принципу может также привести к случайным данным. Для того чтобы этого избежать, данный принцип должен быть нарушен
Структурное связывание	Передаваемые данные содержат больше данных, чем необходимо	В получающую подпрограмму передается больше данных, чем это необходимо для выполнения требуемой функции	Лишние данные обеспечивают получающий модуль информацией, которая не нужна для его выполнения. Эти данные могут привести к недоразумениям при взаимодействии модулей, что, однако, не осуждается	Обычно этот недостаток может быть легко скорректирован
Связывание по управлению	Связывание, которое осуществляет непосредственное управление получающим модулем	Передача данных, которая может выполнить только передачу управления на другой модуль и во многих случаях характеризуется передачей одного бита	Более тесное связывание, чем предыдущее, так как требует немедленного действия, предписывая получающей подпрограмме что-либо выполнить. Необходимо проявлять осторожность. В целом не рекомендуется	Не всегда можно избежать. Например, может быть необходима при завершении действия или подтверждении соответствия значения
Глобальное связывание	Связывание с помощью глобальных данных	Модули могут получить доступ к данным, к которым другие модули имеют прямой доступ, или один модуль может получить прямой доступ к данным, принадлежащим другому модулю	Заголовок подпрограмм не указывает на то, какие данные используются и откуда. Трудно понять функции подпрограмм и предсказать последствия любых изменений кода	В целом критикуемый вид связывания. Например, может быть востребован исключительно для того, чтобы избежать случайных данных. Необходимо использовать только очень ограниченно, в соответствии с ясно определенным и документально оформленным стандартом кодирования
Связывание по контенту	Прямой переход в другие модули, оказывающий влияние на условие в условных операторах в этих модулях, или прямой доступ к данным в других модулях	Реализуется в программах на языке ассемблера; не реализуется на всех языках высокого уровня. Может ускорить выполнение программы и уменьшить трудоемкость кодирования	Критикуемый вид связывания. Отдельный модуль можно понять только на том уровне, на котором понятны все соединенные с ним модули. Делает программу чрезвычайно трудной для понимания и изменения	В некоторых языках программирования даже невозможен. Допускается всегда игнорировать

Обозначение ссылочного международного стандарта	Степень соответствия	Обозначение и наименование соответствующего национального стандарта
ИСО/МЭК Руководство 51:1990	IDT	ГОСТ Р 51898-2002 "Аспекты безопасности. Правила включения в стандарты"
МЭК Руководство 104:1997	-	<*>
МЭК 61508-1:2010	IDT	ГОСТ Р МЭК 61508-1-2012 "Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 1. Общие требования"
МЭК 61508-2:2010	IDT	ГОСТ Р МЭК 61508-2-2012 "Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 2. Требования к системам"
МЭК 61508-4:2010	IDT	ГОСТ Р МЭК 61508-4-2012 "Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 4. Термины и определения"
<*> Соответствующий национальный стандарт отсутствует. До его утверждения рекомендуется использовать перевод на русский язык данного международного стандарта. Перевод данного международного стандарта находится в Федеральном информационном фонде технических регламентов и стандартов. Примечание. В настоящей таблице использовано следующее условное обозначение степени соответствия стандартов: - IDT - идентичные стандарты.

[1] IEC 61511 (all parts)	Functional safety - Safety instrumented systems for the process industry sector
[2] IEC 62061	Safety of machinery - Functional safety of safety-related electrical, electronic and programmable electronic control systems
[3] IEC 61800-5-2	Adjustable speed electrical power drive systems - Part 5-2: Safety requirements - Functional
[4] IEC 60601 (all parts)	Medical electrical equipment
[5] IEC 61508-7:2010	Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 7: Overview of techniques and measures
[6] IEC 61508-6:2010	Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 6: Guidelines on the application of IEC 61508-2 and IEC 61508-3
[7] IEC 61131-3	Programmable controllers - Part 3: Programming languages