ГОСТ Р МЭК 61508-3-2007 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 3. Требования к программному обеспечению.
ГОСТ Р МЭК 61508-3-2007
Группа Т51
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
ФУНКЦИОНАЛЬНАЯ БЕЗОПАСНОСТЬ СИСТЕМ ЭЛЕКТРИЧЕСКИХ, ЭЛЕКТРОННЫХ, ПРОГРАММИРУЕМЫХ ЭЛЕКТРОННЫХ, СВЯЗАННЫХ С БЕЗОПАСНОСТЬЮ
Часть 3
Требования к программному обеспечению
Functional safety of electrical, electronic, programmable electronic
safety-related systems. Part 3. Software requirements
ОКС 13.110
Дата введения 2008-06-01
Предисловие
Цели и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. N 184-ФЗ "О техническом регулировании", а правила применения национальных стандартов Российской Федерации - ГОСТ Р 1.0-2004 "Стандартизация в Российской Федерации. Основные положения"
Сведения о стандарте
1 ПОДГОТОВЛЕН Обществом с ограниченной ответственностью "Корпоративные электронные системы" и Техническим комитетом по стандартизации ТК 10 "Перспективные производственные технологии, менеджмент и оценка рисков" на основе собственного аутентичного перевода стандарта, указанного в пункте 4
2 ВНЕСЕН Управлением развития, информационного обеспечения и аккредитации Федерального агентства по техническому регулированию и метрологии
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 27 декабря 2007 г. N 582-ст
4 Настоящий стандарт идентичен международному стандарту МЭК 61508-3:1998 "Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 3. Требования к программному обеспечению" (IEC 61508-3:1998 "Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 3: Software requirements").
Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5 (подраздел 3.5).
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты, сведения о которых приведены в дополнительном приложении С
5 ВВЕДЕН ВПЕРВЫЕ
Информация об изменениях к настоящему стандарту публикуется в ежегодно издаваемом информационном указателе "Национальные стандарты", а текст изменений и поправок - в ежемесячно издаваемых информационных указателях "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячно издаваемом информационном указателе "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет
Введение
Системы, состоящие из электрических и/или электронных компонентов, в течение многих лет используются для выполнения функций безопасности в большинстве областей применения. Компьютерные системы [обычно называемые программируемыми электронными системами (PES)], применяемые во всех областях для выполнения задач, не связанных с безопасностью, во все более увеличивающихся объемах используются для решения задач обеспечения безопасности. Для эффективной и безопасной эксплуатации технологий, основанных на использовании компьютерных систем, чрезвычайно важно, чтобы лица, ответственные за принятие решений, имели в своем распоряжении руководства по вопросам безопасности, которые они могли бы использовать в своей работе.
Настоящий стандарт устанавливает общий подход к вопросам обеспечения безопасности для всего жизненного цикла систем, состоящих из электрических и/или электронных, и/или программируемых электронных компонентов [электрических/электронных/программируемых электронных систем (E/E/PES)], которые используются для выполнения функций безопасности. Этот унифицированный подход был принят для того, чтобы разработать рациональную и последовательную техническую концепцию для всех электрических систем, связанных с безопасностью. Основной целью при этом является содействие разработке стандартов.
В большинстве случаев безопасность достигается за счет использования нескольких систем защиты, в которых применяются различные технологии (например, механические, гидравлические, пневматические, электрические, электронные, программируемые электронные). Любая стратегия безопасности должна, следовательно, учитывать не только все элементы, входящие в состав отдельных систем (например, датчики, управляющие устройства и исполнительные механизмы), но также и все подсистемы, связанные с безопасностью, входящие в состав комбинированной системы, связанной с безопасностью. Таким образом, хотя данный стандарт посвящен в основном электрическим/электронным/программируемым электронным (Е/Е/РЕ) системам, связанным с безопасностью, он может также предоставлять общую структуру, в рамках которой рассматриваются системы, связанные с безопасностью, основанные на других технологиях.
Признанным фактом является существование огромного разнообразия использования E/E/PES в различных областях применения, отличающихся различной степенью сложности, опасностями и возможными рисками. В каждом конкретном случае необходимые меры безопасности будут зависеть от многочисленных факторов, которые являются специфичными для этого применения. Настоящий стандарт, являясь базовым стандартом, позволит формулировать такие меры в будущих международных стандартах для областей применения.
Настоящий стандарт:
- рассматривает все соответствующие стадии жизненного цикла систем безопасности в целом, а также подсистем E/E/PES и программного обеспечения (например, начиная от исходной концепции, проектирование, разработку, эксплуатацию, техническое обслуживание и вывод из эксплуатации), в ходе которых подсистемы E/E/PES используются для выполнения задач обеспечения безопасности;
- был задуман с учетом быстрого развития технологий; его структура является достаточно устойчивой и полной для того, чтобы удовлетворять потребностям разработок, которые могут появиться в будущем;
- делает возможной разработку стандартов, предназначенных для прикладных отраслей и посвященных вопросам обеспечения безопасности на базе E/E/PES; разработка стандартов для прикладных отраслей в рамках общей структуры, вводимой настоящим стандартом, должна приводить к более высокому уровню согласованности (например, в отношении принципов, положенных в основу, терминологии и т.п.) как для отдельных прикладных отраслей, так и для их совокупности; это приносит преимущества как в плане безопасности, так и в плане экономики;
- предоставляет метод разработки спецификаций для требований безопасности, необходимых для достижения требуемой функциональной безопасности Е/Е/РЕ систем, связанных с безопасностью;
- использует уровни полноты безопасности для задания планируемого уровня полноты безопасности для функций, которые должны быть реализованы Е/Е/РЕ системами, связанными с безопасностью;
- использует для определения уровней полноты безопасности подход, основанный на оценке рисков;
- устанавливает количественные величины отказов Е/Е/РЕ систем, связанных с безопасностью, которые связаны с уровнями полноты безопасности;
- устанавливает нижний предел для планируемой величины отказов в режиме опасных отказов, который может быть задан для отдельной Е/Е/РЕ системы, связанной с безопасностью; для Е/Е/РЕ систем, связанных с безопасностью, работающих:
Примечание - Отдельная Е/Е/РЕ система, связанная с безопасностью, необязательно предполагает одноканальную архитектуру.
- применяет широкий набор принципов, методов и мер для достижения функциональной безопасности Е/Е/РЕ систем, связанных с безопасностью, но не использует концепцию безаварийности, которая может иметь важное значение, когда виды отказов хорошо определены, а уровень сложности является относительно невысоким. Концепция безаварийности признана неподходящей из-за широкого диапазона сложности Е/Е/РЕ систем, связанных с безопасностью, которые находятся в области применения настоящего стандарта.
1 Область применения
1.1 Настоящий стандарт:
a) применяется совместно с МЭК 61508-1 и МЭК 61508-2;
b) применяется к любому программному обеспечению, являющемуся частью системы, связанной с безопасностью, либо используемому для разработки системы, связанной с безопасностью, в рамках области применения МЭК 61508-1 и МЭК 61508-2. Такое программное обеспечение называется программным обеспечением, связанным с безопасностью.
Программное обеспечение, связанное с безопасностью, включает в себя операционные системы, системное программное обеспечение, программы, используемые в коммуникационных сетях, интерфейсы пользователей и обслуживающего персонала, инструментальные средства поддержки, встроенные программно-аппаратные средства, а также прикладные программы.
Прикладные программы включают в себя программы высокого и низкого уровней, а также специальные программы на языках с ограниченной варьируемостью (МЭК 61508-4, пункт 3.2.7);
c) предусматривает определение функции безопасности и уровней целостности программного обеспечения.
Примечания
1 Если это уже было сделано как часть спецификации Е/Е/РЕ систем, связанных с безопасностью (МЭК 61508-2, пункт 7.2), то это не следует повторять в настоящем стандарте.
2 Определение функций безопасности и уровней полноты безопасности программного обеспечения представляет собой интерактивную процедуру; см. рисунки 2 и 6.
3 Структуру документации см. в МЭК 61508-1 (пункт 5 и приложение А). Структура документации может учитывать процедуры, используемые в компаниях, а также реальную практику, сложившуюся в отдельных прикладных отраслях.
d) устанавливает требования к стадиям жизненного цикла безопасности и действиям, которые должны предприниматься в процессе проектирования и разработки программного обеспечения, связанного с безопасностью (модель жизненного цикла безопасности программного обеспечения). Эти требования включают в себя применение мероприятий и методов, ранжированных по уровням полноты безопасности и предназначенных для того, чтобы избегать ошибок и отказов программного обеспечения и принимать необходимые меры при их возникновении;
e) предоставляет требования к информации, относящейся к подтверждению безопасности программного обеспечения, которая должна передаваться в организацию, выполняющую интеграцию систем E/E/PES;
f) предоставляет требования к подготовке информации и процедур, касающихся программного обеспечения, которое необходимо пользователям для работы и поддержки Е/Е/ РЕ систем, связанных с безопасностью;
g) предоставляет требования, предъявляемые к организациям, выполняющим модификацию программного обеспечения, связанного с безопасностью;
h) предоставляет вместе с МЭК 61508-1 и МЭК 61508-2 требования к инструментальным средствам поддержки, таким как средства разработки и проектирования, средства тестирования и отладки, средства управления конфигурацией.
Примечание - На рисунках 4 и 6 показана взаимосвязь между МЭК 61508-2 и МЭК 61508-3.
1.2 МЭК 61508-1-МЭК 61508-4 представляют собой основополагающие стандарты по безопасности, хотя этот статус не применяется в контексте Е/Е/РЕ систем, связанных с безопасностью, имеющих небольшую сложность (МЭК 61508-4, пункт 3.4.4). Как основополагающие стандарты по безопасности они предназначены для использования техническими комитетами при подготовке стандартов в соответствии с МЭК Руководство 104 и ИСО/МЭК Руководство 51. МЭК 61508-1-МЭК 61508-4 предназначены, кроме того, для использования в качестве самостоятельных стандартов.
В круг обязанностей технического комитета входит использование, где это возможно, основополагающих стандартов по безопасности при подготовке собственных стандартов. В этом случае требования, методы проверки или условия проверки настоящего основополагающего стандарта по безопасности не будут применяться, если это не указано специально, или они будут включаться в стандарты, подготовленные этими техническими комитетами.
Примечание - В США и Канаде до тех пор, пока там не будет опубликована в качестве международного стандарта предлагаемая реализация МЭК 61508 для обрабатывающих отраслей (т.е. МЭК 61511), вместо МЭК 61508 в обрабатывающих отраслях допускается использовать национальный стандарт, базирующийся на МЭК 61508 (т.е. ANSI/ISA S 84.01-1996).
1.3 На рисунке 1 показана общая структура МЭК 61508-1 - МЭК 61508-7 и указана роль МЭК 61508-3 в достижении функциональной безопасности Е/Е/РЕ систем, связанных с безопасностью. В МЭК 61508-6 (приложение А) описано применение МЭК 61508-2 и МЭК 61508-3.
Рисунок 1 - Общая структура настоящего стандарта
2 Нормативные ссылки
В настоящем стандарте использованы нормативные ссылки на следующие стандарты:
МЭК 61508-1:1998 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 1. Общие требования
МЭК 61508-2:2000 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 2. Требования к системам электрическим/электронным/программируемым электронным, связанным с безопасностью
МЭК 61508-4:1998 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 4. Термины и определения
МЭК 61508-5:1998 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 5. Примеры методов определения уровней полноты защиты
МЭК 61508-6:2000 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 6. Руководство по применению МЭК 61508-2:2000 и МЭК 61508-3:1998
МЭК 61508-7:2000 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 7. Анализ методов и средств
ИСО/МЭК Руководство 51:1999 Руководство по включению в стандарты аспектов, связанных с безопасностью
МЭК Руководство 104:1997 Подготовка публикаций по безопасности и использование основополагающих публикаций и групповых публикаций по безопасности
3 Термины и определения
В настоящем стандарте использованы термины по МЭК 61508-4.
4 Соответствие настоящему стандарту
Требования, которые следует выполнять для соответствия настоящему стандарту, приведены в МЭК 61508-1 (раздел 4).
5 Документация
Задачи и требования, предъявляемые к документации, приведены в МЭК 61508-1 (раздел 5).
6 Система управления качеством программного обеспечения
6.1 Цели
Цели подробно рассмотрены в МЭК 61508-1 (пункт 6.1).
6.2 Требования
6.2.1 В дополнение к требованиям, описанным в МЭК 61508-1 (пункт 6.2), предъявляются следующие требования.
6.2.2 Планирование функциональной безопасности должно определять стратегию поставок, разработки, интеграции, верификации, приемки и модификации программного обеспечения в той мере, в какой этого требует уровень полноты безопасности Е/Е/РЕ системы, связанной с безопасностью.
Примечание - Философия настоящего подхода состоит в использовании планирования функциональной безопасности в качестве возможности для приспособления настоящего стандарта для учета различной степени полноты безопасности, необходимой для компонентов Е/Е/РЕ систем, связанных с безопасностью. При совместном использовании компонентов Е/Е/РЕ систем, связанных с безопасностью, имеющих разные уровни полноты безопасности, следует учитывать требования пункта 7.4.2.8.
6.2.3 Система управления конфигурацией программного обеспечения должна:
a) использовать административные и технические средства контроля на протяжении всего жизненного цикла программ для того, чтобы управлять изменениями в программах и таким образом гарантировать выполнение указанных в спецификациях требований к безопасности программных средств;
b) гарантировать выполнение всех операций, необходимых для того, чтобы продемонстрировать достижение заданной полноты безопасности программного обеспечения;
c) осуществлять аккуратную поддержку с использованием уникальной идентификации всех элементов конфигурации, которые необходимы для обеспечения целостности Е/Е/РЕ систем, связанных с безопасностью. Элементы конфигурации должны включать в себя, как минимум, следующее:
- анализ безопасности и требования к безопасности,
- спецификацию программного обеспечения и проектные документы,
- исходный текст программ,
- план и результаты тестирования,
- ранее разработанные программные компоненты и пакеты, которые должны быть включены в Е/Е/РЕ систему, связанную с безопасностью,
- все инструментальные средства и системы разработки, которые использовались при создании, тестировании или выполнении иных действий с программным обеспечением Е/Е/РЕ систем, связанных с безопасностью;
d) использовать процедуры контроля над внесением изменений для предотвращения несанкционированных модификаций; документировать запросы на выполнение модификаций; анализировать влияние предлагаемых модификаций и утверждать либо отвергать модификации; подробно документировать модификации и выдавать полномочия на выполнение всех утвержденных модификаций; устанавливать основные параметры конфигурации системы для этапов разработки программного обеспечения и документировать (частичное) тестирование интеграции системы, которое подтверждает выполнение задач этапа (см. 7.8); гарантировать объединение и встраивание всех подсистем программного обеспечения (включая переработку более ранних версий);
Примечание - Для осуществления руководства и применения административных и технических средств контроля необходимы принятие управленческих решений и наличие полномочий.
e) документировать перечисленную ниже информацию, для того чтобы обеспечить возможность последующего аудита: состояние конфигурации, текущее состояние системы, обоснование и утверждение всех модификаций, подробное описание всех модификаций;
f) строго документировать каждую версию программного обеспечения, связанного с безопасностью. Обеспечить хранение всех версий программного обеспечения и всей относящейся к ним документации для обеспечения возможности сопровождения и выполнения модификаций на протяжении всего периода использования разработанного программного продукта.
Примечание - Дополнительную информацию по управлению конфигурацией см. в ИСО/МЭК 12207.
7 Требования к жизненному циклу программного обеспечения, связанного с безопасностью
7.1 Общие положения
7.1.1 Цели
Целью требований, излагаемых в настоящем подразделе, является разделение процесса разработки программного обеспечения на этапы и процессы (см. таблицу 1 и рисунки 2-5).
Таблица 1 - Обзор жизненного цикла модулей безопасности программного обеспечения
|
|
|
|
|
|
Стадия жизненного цикла безопасности (номер стадии соответствует номеру блока на рисунке 3) | Задача | Область применения | Номер пункта или раздела | Входные данные | Выходные данные |
9.1 Спецификация требований к безопасности программного обеспечения | Указать требования к безопасности программного обеспечения в виде требований к функциям безопасности программного обеспечения и требований к полноте безопасности программного обеспечения.
Указать необходимые для реализации требуемых функций безопасности требования к функциям безопасности программного обеспечения для каждой Е/Е/РЕ системы, связанной с безопасностью.
Указать требования к полноте безопасности программного обеспечения для каждой Е/Е/РЕ системы, связанной с безопасностью, необходимые для достижения уровня полноты безопасности, указанного для каждой функции безопасности, назначенной этой Е/Е/РЕ системе, связанной с безопасностью | PES.
Система программного обеспечения | 7.2.2 | Спецификация требований к безопасности E/E/PES (МЭК 61508-2) | Спецификация требований к безопасности программного обеспечения |
9.2 Планирование подтверждения соответствия требованиям к безопасности программного обеспечения | Разработать план подтверждения соответствия требованиям к безопасности программного обеспечения | PES.
Система программного обеспечения | 7.3.2 | Спецификация требований к безопасности программного обеспечения | План подтверждения соответствия требованиям к безопасности программного обеспечения |
9.3 Проектирование и разработка программного обеспечения | Архитектура:
разработать архитектуру программного обеспечения, которая удовлетворяет указанным требованиям к безопасности в отношении необходимого уровня полноты безопасности;
рассмотреть и оценить требования, предъявляемые к программному обеспечению со стороны архитектуры аппаратных средств Е/Е/РЕ системы, связанной с безопасностью, включая значение взаимодействия между программным обеспечением и аппаратурой Е/Е/РЕ системы для безопасности управляемого оборудования | PES.
Система программного обеспечения | 7.4.3 | Спецификация требований к безопасности программного обеспечения.
Проект архитектуры аппаратных средств E/E/PES (МЭК 61508-2) | Описание проекта архитектуры программного обеспечения.
Спецификация проверки интеграции архитектуры программного обеспечения.
Спецификация проверки интеграции программного обеспечения и программируемых электронных устройств (как требует МЭК 61508-2) |
| Инструментальные средства поддержки и языки программирования: выбрать подходящий набор инструментальных средств, включая языки программирования и компиляторы, для требуемого уровня полноты безопасности на весь период поддержки безопасности программного обеспечения с использованием верификации, подтверждения соответствия, оценки и модификации | PES.
Система программного обеспечения.
Инструментальные средства поддержки.
Языки программирования | 7.4.3 | Спецификация требований к безопасности программного обеспечения.
Описание проекта архитектуры программного обеспечения | Средства разработки и стандарты кодирования.
Выбор инструментов разработки |
| Детальное проектирование и разработка (проект программной системы):
спроектировать и реализовать программное обеспечение, которое удовлетворяет указанным требованиям к безопасности программного обеспечения в отношении необходимого уровня полноты безопасности; программное обеспечение должно быть пригодным к анализу и верификации и поддерживать возможность безопасной модификации | Проектирование архитектуры основных компонентов и подсистем программного обеспечения | 7.4.5 | Проектное описание архитектуры программного обеспечения.
Инструментальные средства поддержки и стандарты кодирования | Спецификация проекта программного обеспечения.
Спецификация тестирования интеграции системы программного обеспечения |
| Детальное проектирование и разработка (проект отдельных программных модулей):
спроектировать и реализовать программное обеспечение, которое удовлетворяет указанным требованиям к безопасности программного обеспечения в отношении необходимого уровня полноты безопасности; программное обеспечение должно быть пригодным к анализу и верификации и поддерживать возможность безопасной модификации | Проект системы программного обеспечения | 7.4.5 | Спецификация проекта программной системы.
Инструментальные средства поддержки и стандарты кодирования | Спецификация проекта программного модуля.
Спецификация тестирования программного модуля |
| Детальная реализация исходного текста:
спроектировать и реализовать программное обеспечение, которое удовлетворяет указанным требованиям к безопасности программного обеспечения в отношении необходимого уровня полноты безопасности; программное обеспечение должно быть пригодным к анализу и верификации и поддерживать возможность безопасной модификации | Отдельные программные модули | 7.4.6 | Спецификация проекта программного модуля.
Инструментальные средства поддержки и стандарты кодирования | Листинг исходного текста.
Обзорный отчет по исходному тексту |
| Тестирование программных модулей:
верифицировать выполнение требований к безопасности программного обеспечения в отношении требуемых функций и уровней полноты безопасности - показать, что каждый программный модуль выполняет предназначенные для него функции и не выполняет непредусмотренных действий | Программные модули | 7.4.7 | Спецификация тестирования программного модуля.
Листинг исходного текста.
Обзорный отчет по исходному тексту | Результаты тестирования программного модуля.
Верифицированные и проверенные программные модули |
| Проверка интеграции программного обеспечения:
верифицировать выполнение требований к безопасности программного обеспечения в отношении требуемых функций и уровней полноты безопасности - показать, что все программные модули, компоненты и подсистемы корректно выполняют предназначенные для них функции и не выполняют непредусмотренных действий | Архитектура программного обеспечения.
Система программного обеспечения |
| Спецификация тестирования интеграции программной системы | Результаты тестирования интеграции программной системы.
Верифицированная и проверенная программная система |
9.4 Интеграция программируемых электронных устройств (аппаратура и программное обеспечение) | Интегрировать программное обеспечение с выбранной программируемой электронной аппаратурой.
Объединить программное обеспечение и аппаратные средства в связанных с безопасностью программируемых электронных устройствах для того, чтобы удостовериться в их совместимости и выполнении требований к необходимому уровню полноты безопасности | Аппаратное обеспечение программируемой электроники.
Интегрированное программное обеспечение | 7.5.2 | Спецификация тестирования интеграции архитектуры программного обеспечения.
Спецификация тестирования интеграции программируемой электроники (МЭК 61508-2).
Интегрированная программируемая электроника | Результаты тестирования интеграции архитектуры программного обеспечения.
Результаты тестирования интеграции программируемой электроники.
Верифицированная и проверенная интегрированная программируемая электроника |
9.5 Процедуры, относящиеся к эксплуатации и сопровождению программного обеспечения | Предоставить информацию и процедуры, относящиеся к программному обеспечению и необходимые для того, чтобы гарантировать соблюдение функциональной безопасности Е/Е/РЕ систем, связанных с безопасностью, во время эксплуатации и сопровождения | Аппаратное обеспечение программируемой электроники.
Интегрированное программное обеспечение | 7.6.2 | По необходимости вся информация, описанная выше | Процедуры эксплуатации и сопровождения программного обеспечения |
9.6 Подтверждение соответствия безопасности программного обеспечения | Обеспечить гарантию, что интегрированная система соответствует указанным требованиям к безопасности программного обеспечения для заданного уровня полноты безопасности | Аппаратное обеспечение программируемой электроники.
Интегрированное программное обеспечение | 7.7.2 | План подтверждения соответствия безопасности программного обеспечения | Результаты подтверждения соответствия безопасности программного обеспечения.
Принятое программное обеспечение |
Модификация программного обеспечения | Внести поправки, улучшения или модификации в принятое программное обеспечение, гарантируя, что требуемый уровень полноты безопасности будет сохранен | Аппаратное обеспечение программируемой электроники.
Интегрированное программное обеспечение | 7.8.2 | Процедуры модификации программного обеспечения.
Результаты модификации программного обеспечения | Результаты анализа влияния модификации программного обеспечения. Журнал модификации программного обеспечения |
Верификация программного обеспечения | В той степени, в которой этого требует уровень полноты безопасности, протестировать и оценить выходные данные для заданной стадии жизненного цикла программного обеспечения, связанного с безопасностью, для того чтобы гарантировать правильность и совместимость по отношению к выходным данным и стандартам, для этой стадии | Зависит от стадии | 7.9.2 | План верификации (зависит от стадии) | Отчет по верификации (зависит от стадии) |
Оценка функций программного обеспечения | Изучить и представить на обсуждение функциональную безопасность, достигнутую Е/Е/РЕ системами, связанными с безопасностью | Стадии 9.1, 9.2, 9.3, 9.4, 9.5 и 9.6, указанные на рисунке 3 | 8 | План оценки функциональной безопасности программного обеспечения | Отчет по оценке функциональной безопасности программного обеспечения |
Рисунок 2 - Жизненный цикл безопасности E/E/PES систем
(стадия реализации)
Рисунок 3 - Жизненный цикл безопасности программного обеспечения
(стадия реализации)
Рисунок 4 - Соотношение между областями применения МЭК 61508-2 и МЭК 61508-3
Рисунок 5 - Полнота безопасности программного обеспечения
и жизненный цикл разработки (V-модель)
7.1.2 Требования
7.1.2.1 Жизненный цикл систем безопасности при разработке программного обеспечения должен быть выбран и специфицирован при планировании безопасности в соответствии с МЭК 61508-1 (раздел 6).
Примечание - Модель жизненного цикла систем безопасности, удовлетворяющая требованиям МЭК 61508-1 (раздел 7), может быть переработана в соответствии с конкретными потребностями проекта или организации.
7.1.2.2 Процедуры оценки качества и безопасности должны быть интегрированы в процессы жизненного цикла систем безопасности.
7.1.2.3 Каждая фаза жизненного цикла безопасности программного обеспечения должна быть разделена на элементарные процессы. Для каждой стадии должны быть определены область применения, входные данные и выходные данные.
Примечания
1 Более подробная информация о фазах жизненного цикла приведена в ИСО/МЭК 12207.
2 Выходные данные стадий жизненного цикла систем безопасности рассматриваются в МЭК 61508-1 (раздел 5). При разработке некоторых Е/Е/РЕ систем, связанных с безопасностью, выходные данные некоторых стадий жизненного цикла систем безопасности могут представлять собой отдельные документы, тогда как выходные данные от других стадий могут объединяться в один документ. Существенным является требование, чтобы выходные данные стадии жизненного цикла системы безопасности удовлетворяли ее предназначению. В случае простых разработок некоторые стадии жизненного цикла систем безопасности также могут объединяться (см. 7.4.5).
7.1.2.4 Если жизненный цикл модулей безопасности удовлетворяет требованиям, приведенным на рисунке 3 и в таблице 1, допускается изменять глубину, число и рабочий размер стадий V-модели (см. рисунок 5) в соответствии с полнотой безопасности и сложностью проекта.
Примечание - Полный список стадий жизненного цикла, приведенный в таблице 1, относится к большим системам, разрабатываемым с самого начала. Для небольших систем может оказаться целесообразным, например, объединить стадии проектирования системы программного обеспечения и проектирования архитектуры.
7.1.2.5 При условии выполнения всех задач и требований настоящего раздела допускается организовывать программный проект иначе, чем предписывается настоящим стандартом (т.е. использовать иную модель жизненного цикла систем безопасности).
7.1.2.6 Для каждой стадии жизненного цикла следует использовать соответствующие методы и мероприятия. Рекомендации приведены в приложениях А и В (руководство по выбору методов и мероприятий). Выбор методов из приложений А и В не гарантирует сам по себе достижения необходимой полноты безопасности.
7.1.2.7 Результаты процессов жизненного цикла систем безопасности программного обеспечения должны быть документированы (см. раздел 5).
7.1.2.8 Если на какой-либо стадии жизненного цикла модулей безопасности программного обеспечения возникает необходимость внести изменение, относящееся к более ранней стадии жизненного цикла, необходимо повторно выполнять эту стадию и стадии, следующие за ней.
7.2 Спецификация требований к безопасности программного обеспечения
Примечания
1 См. также таблицы А.1 (приложение А) и В.7 (приложение В).
2 Данная стадия представлена на рисунке 3 (см. 9.1).
7.2.1 Цели
7.2.1.1 Первой целью настоящего подраздела является определение требований к безопасности программного обеспечения как требований к функциям безопасности программного обеспечения и требований к полноте безопасности программного обеспечения.
7.2.1.2 Второй целью настоящего подраздела является определение требований к функциям безопасности каждой Е/Е/РЕ системы, которые нужны для реализации этих функций безопасности.
7.2.1.3 Третьей целью настоящего подраздела является определение требований к полноте безопасности для каждой связанной с безопасностью Е/Е/РЕ системы, необходимых для достижения уровня полноты безопасности, назначенного каждой функции безопасности, предназначенной для этой Е/Е/РЕ системы, связанной с безопасностью.
7.2.2 Требования
Примечание - В большинстве случаев эти требования выполняются комбинацией базового встраиваемого программного обеспечения и программных модулей, которые разработаны специально для конкретного приложения. Именно комбинация этих двух видов программного обеспечения позволяет достигать характеристик, описанных в подразделах, приводимых ниже. Точная граница между базовым и прикладным программным обеспечением зависит от выбранной архитектуры программной системы (см. 7.4.3 и рисунок 6).
|
|
|
Архитектура программируемой электроники | ||
Архитектура аппаратных средств РЕ | Архитектура программного обеспечения РЕ | |
Базовые и прикладные аппаратные средства РЕ | Встроенное программное обеспечение РЕ | Прикладное программное обеспечение РЕ |
Примеры:
- диагностические тесты,
- избыточные процессоры,
- сдвоенные платы ввода/вывода. | Примеры:
- коммуникационные драйверы,
- обработка отказов,
- управляющие программы. | Примеры:
- функции ввода/вывода, - производные функции (например, проверка датчиков, если она не предоставляется как утилита или встроенная программа). |
РЕ - программируемая электроника; NP - непрограммируемые устройства;
H/W - аппаратные средства; S/W программное обеспечение;
MooN - М из N (например - 1оо2 представляет собой 1 из 2).
Рисунок 6 - Взаимосвязь между архитектурой аппаратного и программного обеспечения
программируемой электроники
7.2.2.1 Если требования к безопасности программного обеспечения уже были определены в требованиях к Е/Е/РЕ системам, связанным с безопасностью (МЭК 61508-2, пункт 7.2), повторять их не требуется.
7.2.2.2 Спецификация требований к безопасности программного обеспечения должна быть выработана на основе требований к безопасности Е/Е/РЕ систем, связанных с безопасностью (МЭК 61508-2), и требований к планированию безопасности (см. раздел 6). Эта информация должна быть доступна для разработчика программного обеспечения.
Примечание - Это требование означает, что должно быть тесное взаимодействие между разработчиком E/E/PES и разработчиком программного обеспечения (МЭК 61508-2 и МЭК 61508-3). По мере того как требования к безопасности и архитектура программного обеспечения (см. 7.4.3) становятся более определенными, может проявляться влияние на архитектуру аппаратных средств E/E/PES, и по этой причине становится важным тесное взаимодействие между разработчиками аппаратных средств и программного обеспечения (см. рисунок 4).
7.2.2.3 Спецификация требований к безопасности программного обеспечения должна быть достаточно подробной для того, чтобы обеспечить стадии проектирования и внедрения информацией для обеспечения требуемой полноты безопасности и позволить выполнить оценку функциональной безопасности.
Примечание - Уровень детальности спецификации может изменяться в зависимости от сложности приложения.
7.2.2.4 Разработчик программного обеспечения должен просмотреть информацию, содержащуюся в 7.2.2.2, для того чтобы гарантировать, что требования определены адекватным образом. В частности, разработчик программного обеспечения должен учесть следующее:
a) функции безопасности;
b) конфигурацию или архитектуру системы;
c) требования к полноте безопасности аппаратных средств (программируемой электроники, датчиков и устройств привода);
d) требования к полноте безопасности программного обеспечения;
e) производительность и время отклика;
f) интерфейсы оборудования и оператора.
7.2.2.5 Разработчик программного обеспечения должен установить процедуры для устранения разногласий при назначении уровня полноты безопасности программного обеспечения.
7.2.2.6 В той степени, в которой этого требует уровень полноты безопасности, требования к безопасности программного обеспечения должны быть выражены и структурированы так, чтобы они:
a) были ясными, точными, недвусмысленными, пригодными для верификации, тестирования, поддержки и выполнения и соразмерными с уровнем полноты безопасности;
b) были пригодными для того, чтобы можно было определить их источник в спецификации требований к безопасности Е/Е/РЕ систем;
c) не содержали информации и описаний, которые являются двусмысленными и/или могут быть не поняты теми, кто использует документ на той или иной стадии жизненного цикла систем безопасности.
7.2.2.7 В требованиях к безопасности программного обеспечения должны быть подробно описаны все соответствующие режимы работы EUC, если только они не были уже адекватно определены в требованиях к безопасности Е/Е/РЕ систем, связанных с безопасностью.
Примечание - В большинстве случаев это требование будет достигаться объединением общего встроенного и специального прикладного программного обеспечения. Именно от этого объединения требуется обеспечение характеристик, удовлетворяющих требованиям к безопасности. Точное разделение между общим и специальным прикладным программным обеспечением зависит от выбранной архитектуры программного обеспечения (см. 7.4.3 и рисунок 4).
7.2.2.8 Спецификация требований к безопасности программного обеспечения должна определять и документировать все относящиеся к безопасности и иные необходимые ограничения, связанные с взаимодействием между аппаратными средствами и программным обеспечением.
7.2.2.9 В той степени, в которой этого требует описание проекта архитектуры аппаратных средств Е/Е/РЕ систем, спецификация требований к безопасности программного обеспечения должна учитывать следующее:
a) самоконтроль программного обеспечения (например, МЭК 61508-7, пункты С.2.5 и С.3.10 приложения С);
b) мониторинг программируемой электронной аппаратуры, датчиков и устройств привода;
c) периодическое тестирование функций безопасности во время выполнения программы;
d) разрешение тестирования функций безопасности во время работы EUC.
7.2.2.10 Если Е/Е/РЕ система, связанная с безопасностью, должна выполнять функции, не относящиеся к безопасности, эти функции должны быть четко указаны в спецификации требований к безопасности программного обеспечения.
7.2.2.11 Спецификация требований к безопасности программного обеспечения должна выражать необходимые характеристики безопасности продукта, а не проекта. С учетом 7.2.2.1-7.2.2.10, в зависимости от конкретных обстоятельств, должны быть определены следующие положения:
a) требования к функциям безопасности программного обеспечения:
- функции, которые позволяют EUC достигать или поддерживать безопасное состояние,
- функции, связанные с обнаружением, оповещением и обработкой ошибок аппаратных средств программируемой электроники,
- функции, связанные с обнаружением, оповещением и обработкой ошибок датчиков и устройств привода,
- функции, связанные с обнаружением, оповещением и обработкой ошибок в самом программном обеспечении (самоконтроль программного обеспечения),
- функции, связанные с периодическим тестированием функций в режиме реального времени,
- функции, связанные с периодическим тестированием функций в автономном режиме,
- функции, обеспечивающие безопасную модификацию PES,
- интерфейсы функций, не связанных с безопасностью,
- производительность и время отклика,
- интерфейсы между программным обеспечением и PES.
Примечание - Интерфейсы должны включать средства онлайнового и автономного программирования;
b) требования к полноте безопасности программного обеспечения:
- уровни полноты безопасности для каждой функции перечисления а).
Примечание - Назначение полноты безопасности компонентам программного обеспечения описано в МЭК 61508-5, приложение А.
7.3 Планирование подтверждения соответствия безопасности программного обеспечения
Примечание - Эта стадия представлена на рисунке 3 (см. 9.2).
7.3.1 Цели
Целью требований настоящего подраздела является разработка плана подтверждения соответствия безопасности программного обеспечения.
7.3.2 Требования
7.3.2.1 В ходе планирования должны быть определены процедурные и технические шаги, которые нужно использовать для того, чтобы продемонстрировать, что программное обеспечение удовлетворяет требованиям безопасности (см. 7.2).
7.3.2.2 План подтверждения соответствия безопасности программного обеспечения должен содержать следующие положения:
a) описание этапов подтверждения соответствия;
b) перечень лиц, осуществляющих подтверждение соответствия;
c) идентификацию соответствующих режимов работы EUC, включая:
- подготовку к использованию, а также установку и настройку,
- работу в режиме запуска и обучения, в автоматическом, ручном, полуавтоматическом и стационарном режимах,
- переустановку, выключение, сопровождение,
- предполагаемые ненормальные режимы;
d) идентификацию программного обеспечения, связанного с безопасностью, для которого должна быть проведена процедура подтверждения соответствия, для каждого режима работы EUC до момента его ввода в эксплуатацию;
e) техническую стратегию для подтверждения соответствия (например, аналитические методы, статистическое тестирование и т.п.) (см. 7.3.2.3);
f) средства (методы) и процедуры в соответствии с перечислением е), которые должны быть использованы для подтверждения соответствия каждой функции требованиям к функциям безопасности программного обеспечения (см. 7.2) и требованиям к полноте безопасности программного обеспечения (см. 7.2);
g) конкретные ссылки на требования к безопасности программного обеспечения (см. 7.2);
h) условия, в которых должны происходить процедуры подтверждения соответствия (например, при тестировании может потребоваться использование калиброванных инструментов и оборудования);
i) критерии прохождения/непрохождения подтверждения соответствия (см. 7.3.2.5);
j) политику и процедуры, используемые для оценки результатов подтверждения соответствия, в частности, при оценке отказов.
Примечание - Эти требования основаны на общих требованиях МЭК 61508-1, пункт 7.8.
7.3.2.3 Техническая стратегия для подтверждения соответствия программного обеспечения, связанного с безопасностью (см. таблицу А.7, приложение А), должна содержать следующую информацию:
Для получения доступа к полной версии без ограничений вы можете выбрать подходящий тариф или активировать демо-доступ.