ФЕДЕРАЛЬНОЕ АГЕНТСТВО · Web viewIEC 62671:2013, Nuclear power plants -...

ФЕДЕРАЛЬНОЕ АГЕНТСТВО

ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

Н А Ц И О Н А Л Ь Н Ы Й

С Т А Н Д А Р Т

Р О С С И Й С К О Й

Ф Е Д Е Р А Ц И И

ГОСТ Р МЭК 62138(Проект, редакция 1)

СИСТЕМЫ КОНТРОЛЯ И УПРАВЛЕНИЯ, ВАЖНЫЕ ДЛЯ

БЕЗОПАСНОСТИ АТОМНОЙ СТАНЦИИПрограммное обеспечение компьютерных систем, выполняющих

функции категорий B и C

(IEC 62138:2018, IDT)

Настоящий проект стандарта не подлежит применению до его утверждения

Москва

Стандартинформ

2020


Предисловие

1 ПОДГОТОВЛЕН Акционерным обществом «Русатом

Автоматизированные системы управления» (АО «РАСУ») на основе

собственного перевода на русский язык англоязычной версии стандарта,

указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 322

«Атомная техника»

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального

агентства по техническому регулированию и метрологии от . 20 г. №

4 Настоящий стандарт идентичен международному стандарту

МЭК 62138:2018 «Системы контроля и управления важные для

безопасности атомной станции. Программное обеспечение компьютерных

систем, выполняющих функции категорий В и С [IEC 62138:2018 Nuclear

power plants – Instrumentation and control important to safety – Software

aspects for computer-based systems performing category В or С functions]»

Наименование настоящего стандарта изменено относительно

наименования указанного международного стандарта для приведения в

соответствие с ГОСТ Р 1.5–2012 (пункт 3.5)

При применении настоящего стандарта рекомендуется использовать

вместо ссылочных международных стандартов соответствующие им

национальные стандарты Российской Федерации, сведения о которых

приведены в дополнительном приложении ДА

5 Положения настоящего стандарта действуют в целом в отношении

сооружаемых по российским проектам атомных станций за пределами

Российской Федерации, а также в отношении сооружаемых на территории

Российской Федерации атомных станций в части, не противоречащей

требованиям Федеральных норм и правил в области использования

атомной энергии

6 ВВЕДЕН ВПЕРВЫЕ

II


Правила применения настоящего стандарта установлены в статье

26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации

в Российской Федерации». Информация об изменениях к настоящему

стандарту публикуется в ежегодном (по состоянию на 1 января

текущего года) информационном указателе «Национальные стандарты»,

а официальный текст изменений и поправок – в ежемесячном

информационном указателе «Национальные стандарты». В случае

пересмотра (замены) или отмены настоящего стандарта

соответствующее уведомление будет опубликовано в ближайшем

выпуске ежемесячного информационного указателя «Национальные

стандарты». Соответствующая информация, уведомление и тексты

размещаются также в информационной системе общего пользования – на

официальном сайте Федерального агентства по техническому

регулированию и метрологии в сети Интернет (www.gost.ru)

III


Содержание

1 Область применения...........................................................................................

2 Нормативные ссылки..........................................................................................

3 Термины и определения.....................................................................................

4 Обозначения и сокращения................................................................................

5 Ключевые концепции и допущения..................................................................

5.1 Общие положения.........................................................................................

5.2 Типы программного обеспечения................................................................

5.3 Типы данных конфигурации........................................................................

5.4 Жизненные циклы безопасности и программного обеспечения..............

5.5 Принципы градации......................................................................................

6 Требования к программному обеспечению СКУ класса 2 и 3........................

6.1 Применение требований...............................................................................

6.2 Общие требования.........................................................................................

6.2.1 Жизненный цикл безопасности программного обеспечения.

Обеспечение качества программного обеспечения.....................................

6.2.2 Верификация...............................................................................................

6.2.3 Управление конфигурацией..................................................................

6.2.4 Выбор и использование инструментальных программ......................

6.2.5 Выбор языков.........................................................................................

6.3 Выбор ранее разработанного программного обеспечения........................

6.3.1 Общие положения..................................................................................

6.3.2 Документация по безопасности............................................................

6.3.3 Свидетельство корректности................................................................

6.3.4 Функциональная пригодность..............................................................

6.3.5 Выбор и использование цифровых устройств ограниченной

функциональности..........................................................................................

6.4 Спецификация требований к программному обеспечению......................

IV


6.4.1 Общие положения..................................................................................

6.4.2 Цели.........................................................................................................

6.4.3 Исходная информация...........................................................................

6.4.4 Содержание.............................................................................................

6.4.5 Свойства..................................................................................................

6.5 Проект программного обеспечения.............................................................

6.5.1 Цели.........................................................................................................

6.5.2 Исходные данные...................................................................................

6.5.3 Содержание.............................................................................................

6.5.4 Свойства..................................................................................................

6.6 Реализация нового программного обеспечения.........................................

6.6.1 Общие требования......................................................................................

6.6.2 Конфигурация программного обеспечения и устройств,

содержащих программное обеспечение.......................................................

6.6.3 Реализация с помощью проблемно-ориентированных языков.........

6.6.4 Реализация с помощью универсальных языков..................................

6.7 Программные аспекты интеграции системы..............................................

6.7.1 Общие положения..................................................................................

6.8 Программные аспекты валидации системы................................................

6.8.1 Общие положения..................................................................................

6.9 Инсталляция программного обеспечения на штатном месте...................

6.9.1 Общие положения..................................................................................

6.10 Протоколы отклонений от нормы...............................................................

6.11 Модификация программного обеспечения.................................................

6.11.1 Общие положения................................................................................

V


6.12 Обеспечение защиты от отказов по общей причине, которые

возникли вследствие программного обеспечения..............................................

Приложение А (справочное) Стандартный перечень документации на

программное обеспечение..................................................................

Приложение B (справочное) Соотношение данного стандарта и МЭК

61513:2011............................................................................................

Приложение С (справочное) Взаимосвязь данного стандарта и МЭК 61508.....

Приложение ДА (справочное) Сведения о соответствии ссылочных

международных стандартов ссылочным национальным

стандартам Российской Федерации...................................................

Библиография............................................................................................................

VI


Введение

а) Технический опыт, основные вопросы и структура стандарта

В данном международном стандарте содержатся требования к

программному обеспечению компьютерных систем контроля и управления

(СКУ), выполняющих функции категории В или С в соответствии с МЭК

61226. Данный стандарт дополняет МЭК 60880, в котором указаны

требования к программному обеспечению СКУ, выполняющих функции

категории А.

Данный стандарт соответствует стандарту МЭК 61513:2011 и

дополняет его. Мероприятия, которые в основном относятся к системе

(например, интеграция, валидация и установка) не рассматриваются в

полной мере в данном документе: требования, которые не касаются

программного обеспечения указаны в МЭК 61513:2011.

В данном стандарте учитывается текущая практика разработки

программного обеспечения для СКУ, в частности:

использование ранее разработанного ПО, оборудования и

комплекса оборудования, которые не обязательно были разработаны по

стандартам атомной промышленности;

использование проблемно-ориентированных языков.

b) Положение настоящего стандарта в структуре серии стандартов

подкомитета ПК 45А МЭК

МЭК 61513 является документом МЭК ПК 45A первого уровня, в

нем содержатся рекомендации к СКУ на системном уровне.

МЭК 62138 является документом МЭК ПК 45A второго уровня, он

дополняет МЭК 61513 в отношении разработки программного обеспечения

СКУ, выполняющих функции категории В или С.

С более подробной информацией по поводу структуры серии

стандартов МЭК ПК 45A можно ознакомиться в п. d) данного введения.

VII


с) Рекомендации и ограничения в отношении применения

настоящего стандарта

Данный документ не предназначен для использования в качестве

технического руководства для программного обеспечения общего

назначения. Он применяется к программному обеспечению СКУ,

выполняющих функции категории В или С для новых атомных станций, а

также для обновления или модернизации действующих станций.

Для действующих станций применим только ряд требований, и эти

определенные требования должны быть установлены в начале любого

проекта.

Цель указаний, представленных в данном стандарте, заключается в

том, чтобы максимально снизить вероятность возникновения скрытых

программных сбоев, которые могут привести к системным отказам из-за

единичного программного сбоя, либо нескольких программных сбоев (т. е.

отказы по общей причине из-за ПО).

В данном документе не содержится четкой информации о том, каким

образом защитить ПО от угроз, возникающих в результате вредоносных

атак, т. е. по поводу кибербезопасности для компьютерных систем. В МЭК

62645 содержатся требования к программам по обеспечению безопасности

для компьютерных систем.

Для гарантии того, что данный документ будет актуален и в

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

вопросах, а не на конкретных технологиях.

d) Описание структуры серии стандартов ПК 45А МЭК и

взаимосвязи этих стандартов с другими документами МЭК и документами

других организаций (МАГАТЭ, ИСО)

Стандарты МЭК 61513 и МЭК 63046 относятся к документам

верхнего уровня среди серии стандартов МЭК ПК 45A. В стандарте МЭК

61513 приводятся общие требования к СКУ и оборудованию, которое

используется для выполнения функций, важных для безопасности на

VIII


атомных станциях (АС). В стандарте МЭК 63046 содержатся общие

требования к системам электроснабжения АС; он охватывает системы

электроснабжения, включая СКУ. МЭК 61513 и МЭК 63046 должны

рассматриваться совместно и на одном уровне. Стандарты МЭК 61513 и

МЭК 63046 формируют структуру серии стандартов МЭК ПК 45A и

устанавливают основу в виде общих требований к системам контроля и

управления, а также к электрическим системам для атомных станций.

Стандарты МЭК 61513 и МЭК 63046 непосредственно ссылаются на

другие стандарты МЭК ПК 45A, когда речь идет о темах, которые

касаются определения категории функций, а также классификации систем,

квалификации, разделения, мер по предотвращению отказов по общей

причине, конструкции пункта управления, электромагнитной

совместимости, кибербезопасности, характеристик программного и

аппаратного обеспечения для программируемых цифровых систем,

координации требований в области безопасности и защиты, и управления

старением. Стандарты, на которые приводятся прямые ссылки в данных

стандартах второго уровня, должны рассматриваться совместно с МЭК

61513 и МЭК 63046 как единый комплект документов.

На третьем уровне стандарты МЭК ПК 45A, на которые нет прямых

ссылок в МЭК 61513 или МЭК 63046, являются стандартами,

относящимися к конкретному оборудованию, техническим методам, либо

конкретной деятельности. Обычно, данные документы, в которых

содержатся ссылки по общим темам на документы второго уровня, можно

использовать самостоятельно.

Документы четвертого уровня расширяет серию стандартов МЭК ПК

45A, они относятся к техническим отчетам, которые не являются

нормативными документами.

С помощью серии стандартов МЭК ПК 45А последовательно

внедряются и конкретизируются принципы безопасности и защиты, а

также основные аспекты, предусмотренные в соответствующих стандартах

IX

ГОСТ Р МЭК 62138(Проект, редакция 1)безопасности МАГАТЭ и в соответствующих документах, которые

относятся к серии стандартов МАГАТЭ по физической ядерной

безопасности. В частности, сюда входят требования МАГАТЭ SSR-2/1,

которые устанавливают требования безопасности, относящиеся к

конструкции АС, руководство по безопасности МАГАТЭ SSG-30,

содержащее классификацию структур, систем и компонентов на АС по

безопасности, руководство по безопасности МАГАТЭ SSG-39, в котором

содержится информация по проектированию СКУ для АС, руководство по

безопасности МАТАТЭ SSG-34, касающееся конструкции

электроэнергетических систем АС, и руководство NSS17 по компьютерной

безопасности на ядерных объектах. Термины и определения, которые

используются в стандартах ПК 45A, соответствуют терминам,

используемым МАГАТЭ.

Для МЭК 61513 и МЭК 63046 принята форма представления,

аналогичная форме представления базовой публикации по безопасности

МЭК 61508, с его структурой общего жизненного цикла безопасности и

структурой жизненного цикла системы. Что касается ядерной

безопасности, в стандарте МЭК 61513 и МЭК 63046 приводится

интерпретация общих требований МЭК 61508-1, МЭК 61508-2 и МЭК

61508-4 для применения в атомной отрасли. В этой структуре МЭК 60880,

МЭК 62138 и МЭК 62566 соответствуют МЭК 61508-3 применительно к

атомной отрасли. В МЭК 61513 и МЭК 63046 есть ссылки на стандарты

ИСО, а также на документы МАГАТЭ GS-R-3, МАГАТЭ GS-G-3.1 и

МАГАТЭ GS-G-3.5 по вопросам, связанным с обеспечением качества. На 2

уровне, касающемся ядерной безопасности, МЭК 62645 является

исходным документом для стандартов безопасности МЭК ПК 45A. Он

основывается на действующих принципах высокого уровня, а также

базовых концепциях общих стандартов безопасности, в частности ИСО /

МЭК 27001 и ИСО / МЭК 27002; данный стандарт адаптирует и дополняет

их в соответствии с ядерным контекстом, и координирует с серией IEC

X


62443. На 2 уровне, который относится к пунктам управления, стандарт

МЭК 60964 является исходным документом для стандартов, применимых к

пунктам управления по МЭК ПК 45А. МЭК 62342 является исходным

документом для стандартов по управлению старением в рамках МЭК ПК

45А.П р и м е ч а н и я

1. Предполагается, что при проектировании СКУ на АЭС, реализующих стандартные функции

безопасности (например, обеспечение безопасности работников, защита активов, химическая

безопасность, энергетическая безопасность технологических процессов), будут применяться

международные или национальные стандарты.

2. В 2013 г. была расширена сфера ответственности МЭК ПК 45А, чтобы охватить вопросы,

связанные с электрическими системами. В 2014 и 2015 гг. в рамках МЭК ПК 45А были приняты решения

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

электрических систем. Эксперты МЭК ПК 45A рекомендовали разработать независимый стандарт на том

же уровне, что и МЭК 61513, для установления общих требований к электрическим системам. В

настоящее время для решения этой задачи запущен проект МЭК 63046. Когда будет опубликован МЭК

63046, Примечание 2, указанное во введении, будет неактуально.

XI


Н А Ц И О Н А Л Ь Н Ы Й С Т А Н Д А Р Т Р О С С И Й С К О Й Ф Е Д Е Р А Ц И И

СИСТЕМЫ КОНТРОЛЯ И УПРАВЛЕНИЯ, ВАЖНЫЕ ДЛЯ

БЕЗОПАСНОСТИ АТОМНОЙ СТАНЦИИ

Программное обеспечение компьютерных систем, выполняющих

функции категорий В и С

Nuclear power plants – Instrumentation and control important to safety – Software

aspects for computer-based systems performing category В or С functions

Дата введения – 20 –

1 Область применения

Настоящий стандарт содержит требования к программному

обеспечению компьютерных систем контроля и управления (СКУ),

выполняющих функции безопасности категории В или С, определенные в

МЭК 61226. Данный стандарт дополняет МЭК 60880, который содержит

требования к программному обеспечению компьютерных систем СКУ,

выполняющих функции безопасности категории А.

Настоящий стандарт также согласован с МЭК 61513 и дополняет его.

Действия, относящиеся главным образом к системному уровню (например,

интеграция, валидация и монтаж), в настоящем стандарте подробно не

рассматриваются: неспецифичные для программного обеспечения

требования, изложены в МЭК 61513.

Взаимосвязь между категориями функций и классами систем описана в

МЭК 61513. Поскольку данная система СКУ, которая была

классифицирована по безопасности, может выполнять функции различных

категорий безопасности и даже функции, которые не были

классифицированы по безопасности, требования настоящего документа

добавляются к классу безопасности СКУ (класс 2 или класс 3).

Проект, редакция 1

1


Данный документ не предназначен для использования в качестве

технического руководства для программного обеспечения общего

назначения. Он применяется к программному обеспечению СКУ, которые

относятся к классам безопасности 2 или 3, для новых АС, а также для

обновления или модернизации действующих станций.

Для действующих станций применим только ряд требований, и эти

определенные требования должны быть установлены в начале любого

проекта.

Цель указаний, представленных в данном документе, заключается в

том, чтобы максимально снизить вероятность возникновения скрытых

программных сбоев, которые могут привести к системным сбоям, из-за

одного или нескольких программных сбоев (т.е. отказы по общей причине

из-за ПО).

В данном документе не содержится четкой информации о том, каким

образом защитить ПО от угроз, возникающих в результате вредоносных атак,

т. е. по поводу кибербезопасности для компьютерных систем. В МЭК 62645

содержатся требования к программам безопасности для компьютерных

систем.

2 Нормативные ссылки

В тексте данного стандарта приводятся ссылки на следующие

документы таким образом, чтобы часть или полное содержание данных

документов устанавливало требования настоящего стандарта. Что касается

документов с датами, применяются только те версии, которые приводятся в

данном документе. Что касается документов без даты, применяется

последняя версия документа, на который приводится ссылка (включая любые

поправки):

IEC 60880:2006, Nuclear power plants - Instrumentation and control

systems important to safety - Software aspects for computer-based systems

performing category A functions (Атомные электростанции. Системы контроля

2


и управления, важные для безопасности. Программное обеспечение

компьютерных систем, выполняющих функции категории А)

IEC 61226, Nuclear power plants - Instrumentation and control important to

safety - Classification of instrumentation and control functions (Атомные

электростанции. Системы контроля и управления, важные для безопасности.

Классификация функций контроля и управления)


important to safety - General requirements for systems (Атомные

электростанции. Системы контроля и управления, важные для безопасности.

Общие требования)


important to safety - Selection and use of industrial digital devices of limited

functionality (Атомные электростанции. Системы контроля и управления,

важные для безопасности. Выбор и использование промышленных цифровых

устройств ограниченной функциональности)

3 Термины и определения

В настоящем стандарте применены следующие термины с

соответствующими определениями:

3.1 анимация (animation): Процесс, посредством которого указанное

в спецификации поведение демонстрируется с реальными значениями,

полученными из задающих поведение выражений и некоторых входных

величин.

[МЭК 60880:2006, п. 3.1]

3.2 прикладная функция (application function): Функция системы

контроля и управления по выполнению задачи, связанной с контролируемым

процессом, а не с функционированием самой системы.

[МЭК 61513:2011, п. 3.1]

3.3 прикладное программное обеспечение (application software):

Часть программного обеспечения системы контроля и управления, которое

3

ГОСТ Р МЭК 62138(Проект, редакция 1)обеспечивает выполнение прикладных функций.

П р и м е ч а н и я

1. Прикладное программное обеспечение отличается от системного.

2. Прикладное программное обеспечение относится к конкретной станции и не должно

рассматриваться как ранее разработанное ПО.

[МЭК 61513:2011, п. 3.2 с изменениями (изменены примечания)]

3.4 проблемно-ориентированный язык (application-oriented

language): Компьютерный язык, специально разработанный для

определенного типа применений и используемый лицами, являющимися

специалистами в данном типе применений. П р и м е ч а н и я

1. Группы оборудования обычно характеризуются проблемно-ориентированными языками,

обеспечивающими удобное приспособление оборудования к специфичным требованиям.

2. Проблемно-ориентированные языки могут использоваться для обеспечения функциональных

требований к системе контроля и управления и/или для установления или разработки прикладного

программного обеспечения. Они могут базироваться на текстах, графике или на том и другом.

3. Например, языки функциональных блок-схем, языки, определенные МЭК 61131-3.

4. См. также термин "универсальный язык".

[МЭК 60880:2006, п. 3.3 с изменениями (дополнение к примечанию 4)]

3.5 отказ по общей причине, ООП (common cause failure, CCF):

Отказ двух или более структур, систем или компонентов, явившийся

результатом определенного события или причины. П р и м е ч а н и е – Общие причины могут быть внешними или внутренними по отношению к СКУ.

[МАГАТЭ Глоссарий по безопасности, издание 2016 г.]

3.6 сложность (complexity): Степень трудности понимания и

верификации проекта, реализации или поведения системы, или компонента.

[МЭК 61513:2011, п. 3.9]

3.7 компьютерная программа (computer program): набор

упорядоченных команд и данных, которые описывают операции в форме,

приемлемой для их выполнения компьютером.П р и м е ч а н и е – Сюда входят традиционные программы, которые были написаны на языках

общего назначения. Сюда также входят программы, написанные на проблемно-ориентированных языках.

[МЭК 60880:2006, п. 3.10 с изменениями (дополнение к примечанию)]

3.8 компьютерный элемент (computer-based item): Элемент,

4


который основан на программных инструкциях, работающих на

микропроцессорах или микроконтроллерах.П р и м е ч а н и я

1. В данном случае, термин «элемент» может быть заменен на термины «система», «оборудование»

или «устройство».

2. Компьютерный элемент является видом программируемого цифрового элемента.

3. Этот термин эквивалентен термину «программный элемент».

3.9 управление конфигурацией (configuration management):

Процесс определения и документального оформления характеристик

структур, систем и компонентов (включая компьютерные системы и

программное обеспечение), а также процесс обеспечения гарантии того, что

разработка, оценка, согласование, выпуск, внедрение, проверка, запись, а

также включение изменений данных характеристик в документацию было

проведено надлежащим образом.

[Глоссарий по безопасности МАГАТЭ, издание 2016 г.]

3.10 кибербезопасность (cybersecurity): комплекс мероприятий и мер,

которые направлены на предотвращение, обнаружение и реагирование на

цифровые атаки с целью:

раскрыть информацию, которая может быть использована для

совершения злонамеренных действий, которые могут привести к

возникновению аварии, небезопасной ситуации или снижению

производительности станции (конфиденциальность);

злонамеренно модифицировать функции, что может привести к

нарушению реализации или целостности задачи, которую выполняют

компьютеризированные системы контроля и управления CB&HPD (включая

потерю контроля), что в свою очередь может привести к возникновению

аварии, небезопасной ситуации, или снижению производительности станции

(целостность);

злонамеренного препятствования или блокировки доступа, либо

предотвращения передачи информации, данных или ресурсов (включая

потерю функции мониторинга), что может привести к нарушению

5

ГОСТ Р МЭК 62138(Проект, редакция 1)реализации или целостности задачи, которую выполняют СКУ, что в свою

очередь может привести к возникновению аварии, небезопасной ситуации,

или снижению производительности станции (доступ).П р и м е ч а н и е – Данное определение адаптировано к сфере применения стандарта МЭК 62645. В

его основе лежит способность предотвращать, обнаруживать и реагировать на злоумышленные действия с

помощью цифровых средств систем контроля и управления CB&HPD. Известно, что термин

«кибербезопасность» имеет более широкое значение в других стандартах и руководствах, он часто

охватывает угрозы, которые не связаны со злым умыслом, человеческие ошибки и защиту от стихийных

бедствий, что не входит в содержание МЭК 62645.

[МЭК 62645:2014, п. 3.6 с изменениями (удаление примечания 2)]

3.11 специализированная функциональность (dedicated

functionality): свойство устройств, предназначенных для выполнения только

одной ясно определенной функции либо лишь очень узкого диапазона

функций, включая, например, снятие и оповещение о значении

технологического параметра или переключение источника электропитания

переменного тока на постоянный ток. Данная функция (или узкий диапазон

функций) является внутренне присущей устройству, а не полученной в

результате программирования пользователем.П р и м е ч а н и я

1. Вспомогательные функции (например, самодиагностика, самокалибровка, передача данных)

могут также быть реализованы внутри устройства, но они не изменяют фундаментальную узкую область

применимости устройства.

2. Слово «специализированный» в том смысле, в котором оно используется в данном стандарте,

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

условиях.

[МЭК 62671:2013, п. 3.7]

3.12 спецификация проекта (design specification): Документ или

комплект документов, который описывает устройство и работу изделия и

используется в качестве основы для применения и интеграции изделия.

3.13 документация по безопасности (documentation for safety):

Документ или комплект документов, который указывает, каким образом

продукт может безопасно использоваться для решения прикладных задач,

важных для безопасности.

6


П р и м е ч а н и е – Данное определение используется в контексте ранее разработанного ПО (см.

6.3).

3.14 динамический анализ (dynamic analysis): Процесс оценки

системы или компонента, основанный на их поведении в процессе работы. В

противоположность статическому анализу.

[МЭК 60880:2006, п. 3.15]

3.15 электрическое/ электронное/ программируемое электронное

изделие, Э/Э/ПЭ изделие (electrical/electronic/programmable electronic item,

E/E/PE item): Изделие, которое основано на электрической (Э) и/или

электронной (Э) и/или программируемой электронной (ПЭ) технологии.П р и м е ч а н и е – В данном определении слово «изделие» может быть заменено на слова: система,

оборудование или устройство.

[МЭК 61508-4:2010, п. 3.2.13, с изменениями (добавлено понятие

«изделие» и внесены изменения в примечание)]

3.16 комплекс оборудования (equipment family): Набор приборных и

программных компонентов, которые могут работать совместно в одной или

более определенных структурах (конфигурациях). Разработка специальной

конфигурации для АС и соответствующего прикладного программного

обеспечения может поддерживаться программными средствами;

обеспечивает набор стандартных операций (библиотеку прикладных

функций), которые могут быть объединены, образуя специальное прикладное

программное обеспечение.П р и м е ч а н и я

1. Комплекс оборудования может быть изделием определенного изготовителя или набором изделий,

соединенных и настроенных поставщиком.

2. Термин «платформа оборудования» иногда используется как синоним термина «комплекс

оборудования».

[МЭК 61513:2011, п. 3.17 с изменениями (удаление примечания 1)]

3.17 погрешность (error): Разность между рассчитанным,

наблюдаемым или измеренным значением величины или параметра и

истинным, установленным или теоретическим значением величины или

параметра.

7


П р и м е ч а н и е – См. также термины: «ошибка персонала», «неисправность», «отказ».

[МЭК 61513:2011, п. 3.18, с изменениями (добавление примечания 1)]

3.18 рабочая программа (executable code): Программное обеспечение,

которое включено в специализированную систему.П р и м е ч а н и е – Рабочая программа обычно включает в себя команды, которые должны

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

3.19 отказ (failure): Неспособность конструкции, системы или

компонента функционировать в пределах критериев приемлемости.П р и м е ч а н и я

1. Под вышедшим из строя оборудованием понимается то оборудование, которое не может

выполнять свои функции, вне зависимости требуются ли они в данный момент или нет. Например, отказ

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

тестирования, либо при отказе системы, в качестве резерва которой она выступает.

2. Отказ является результатом сбоя аппаратного или программного обеспечения, системного сбоя,

ошибки оператора, либо технического обслуживания, а также связанной с ним траектории сигнала, которая

приводит к отказу.

3. См. также термины: «ошибка персонала», «неисправность», «погрешность».

[Глоссарий по безопасности МАГАТЭ, издание 2016 г.]

3.20 неисправность (fault): Дефект в компоненте технического

обеспечения, программного обеспечения или системы.П р и м е ч а н и я

1. Причиной дефектов могут быть случайные неисправности, которые возникают, например, в

результате деградации технического обеспечения, а также систематические неисправности, например,

дефекты ПО, которые возникают вследствие ошибок в проекте.

2. Дефект (особенно дефект, связанный с проектированием) может оставаться незамеченным до тех

пор, пока сохраняются условия, при которых он не отражается на выполнении функции, т.е. пока не

произойдет отказ.

3. См. также термины: «ошибка персонала», «погрешность», «отказ».

[МЭК 61513:2011, п. 3.21, с изменениями (внесены изменения в

примечание 3)]

3.21 аппаратно-программное обеспечение (firmware): Программное

обеспечение, которое тесно связано с особенностями аппаратных средств, на

которые оно установлено. П р и м е ч а н и е – Наличие аппаратно-программного обеспечения, как правило, очевидно

пользователю аппаратного средства и может фактически рассматриваться как неотъемлемая часть

разработки аппаратных средств (хорошим примером такого программного обеспечения является микрокод

8


процессора). Как правило, аппаратно-программное обеспечение может изменяться только пользователем

посредством замены компонентов аппаратных средств (например, микросхемы процессора, карты,

программируемого постоянного запоминающего устройства), которые используют это программное

обеспечение с компонентами, использующими измененное программное обеспечение (аппаратное

программное обеспечение). В этом случае конфигурационное управление компонентами аппаратных

средств пользователями оборудования фактически обеспечивает конфигурационное управление аппаратно-

программным обеспечением. Аппаратно-программное обеспечение, как указано в стандарте МЭК 60987,

является программным обеспечением, встроенным в аппаратное средство.

[МЭК 60987:2007, п. 3.4]

3.22 функциональная валидация (functional validation): Проверка

правильности применения спецификаций прикладных функций относительно

исходных требований к функциям и эксплуатационным характеристикам

станции. Функциональная валидация дополняет валидацию системы, в ходе

которой оценивается ее соответствие спецификации функций.

[МЭК 61513:2011, п. 3.23]

3.23 универсальный язык (general-purpose language): Компьютерный

язык, разработанный для всех видов применения.П р и м е ч а н и я

1. Программное обеспечение операционной системы групп оборудования обычно реализуется с

использованием универсальных языков.

2. Например: Ада, Си, Паскаль.

3. См. также термин «проблемно-ориентированный язык».

[МЭК 60880:2006, п. 3.20 с изменениями (добавлено примечание 3)]

3.24 ошибка персонала (human error (or mistake): Действие (или

бездействие) человека, которое приводит к незапланированному результату.П р и м е ч а н и е – См. также термины: «неисправность», «погрешность», «отказ».

[МЭК 61513:2011, п. 3.26 с изменениями (добавлено примечание 1)]

3.25 архитектура контроля и управления (I&C architecture):

Организованная структура важных для безопасности систем контроля и

управления станции.

[МЭК 61513:2011, п. 3.27]

3.26 система контроля и управления (I&C system): Система,

основанная на Э/Э/ПЭ изделиях, которые выполняют функции контроля и

9

ГОСТ Р МЭК 62138(Проект, редакция 1)управления, а также функции обслуживания и мониторинга, относящиеся к

работе самой системы.П р и м е ч а н и я

1. Этот термин используется как общий, включающий в себя все элементы системы, такие как

внутренние источники электроснабжения, датчики и другие устройства ввода данных, магистрали передачи

данных и другие каналы связи, интерфейсы с исполнительными механизмами и прочими устройствами

вывода. Различные функции внутри системы могут использовать специальные или общие ресурсы.

2. Элементы, включенные в конкретную СКУ определены в спецификации границ системы.

3. См. также термин Э/Э/ПЭ изделие и примечания к нему.

4. В соответствии с их стандартным функционалом, МАГАТЭ подразделяет системы СКУ на

системы автоматизации / управления, системы ЧМИ, системы блокировки и системы защиты.

3.27 интеграция (integration): Последовательная сборка компонентов и

их проверка внутри завершенной системы.

3.28 библиотека (library): Набор связанных элементов программного

обеспечения (ПО), сгруппированных вместе, но индивидуально отбираемых

для включения в окончательный продукт ПО.

[МЭК 60880:2006, п. 3.24]

3.29 режим эксплуатации (mode of operation): Функциональное

состояние элемента, которое обеспечивает определенный рабочий режим

(например, режим инициализации, нормальный режим, неполный режим в

случае наличия ошибки в элементе).

3.30 операционное программное обеспечение системы (operational

system software): Программное обеспечение, которое функционирует на

основном процессоре во время работы системы (например, операционная

система, входные/выходные драйверы, обработчик исключительных

ситуаций, ПО коммуникаций, библиотеки прикладного программного

обеспечения, самодиагностика, управление резервированием и смягченной

деградацией).

3.31 параметр (parameter): Элемент данных, управляющий поведением

СКУ и/или ее программного обеспечения, который может быть изменен

операторами во время работы станции.

3.32 ранее разработанное программное обеспечение (pre-developed

10


software): Программное обеспечение, которое уже существует и доступно как

коммерческий или запатентованный продукт, готовый к использованию.П р и м е ч а н и я

1. В данном документе ранее разработанное программное обеспечение можно разделить на 2

различных вида:

a) комплексное операционное программное обеспечение системы

b) компоненты программного обеспечения.

2. Ранее разработанное программное обеспечение можно разделить на программное обеспечение

общего назначения, которое не разрабатывалось для определенного технического обеспечения, и

программное обеспечение, интегрированное в компоненты оборудования, которое применяется совместно с

оборудованием.

3. В настоящем стандарте этот термин не охватывает инструментальные программы, даже если они

были ранее разработаны.

4. Прикладное программное обеспечение относится к конкретной станции и не должно

рассматриваться как ранее разработанное ПО.

[МЭК 60880:2006, п. 3.28 с изменениями (добавлены примечания)]

3.33 ранее разработанные элементы (pre-existing items):

Оборудование на основе аппаратного или программного обеспечения,

которое уже существует, доступно как коммерческий или запатентованный

продукт, готовый к использованию.П р и м е ч а н и е – Данное определение указано здесь для соблюдения соответствия с терминами и

определениями в МЭК 61513:2011, но оно не используется. В настоящем стандарте, который рассматривает

программное обеспечение, используется термин ранее разработанное ПО.

[МЭК 61513:2011, п. 3.36 с изменениями (внесены изменения в

приложение)]

3.34 программируемый цифровой элемент (programmable digital

item): Элемент, который основан на программных инструкциях или

программируемой логике, для выполнения функции.П р и м е ч а н и я



2. К основным видам программируемых цифровых элементов относятся компьютерные элементы и

элементы программируемой логики.

3. Данный термин используется в рамках МЭК ПК 45А в качестве эквивалента термину

«программируемый электронный элемент» (ПЭ элемент), указанный согласно МЭК 61508.

3.35 элемент программируемой логики (programmable logic item):

11

ГОСТ Р МЭК 62138(Проект, редакция 1)Элемент, который основан на логических компонентах с интегральной

схемой, состоящей из логических элементов со схемой взаимного

соединения, части которой программируются пользователем.П р и м е ч а н и я



2. Элемент программируемой логики является видом программируемого цифрового элемента.

3. См. также термин Э/Э/ПЭ изделие и примечания к нему.

3.36 самодиагностика (self-supervision): автоматическое испытание

рабочих характеристик аппаратной части системы и корректности

программного обеспечения компьютерной системы контроля и управления.

[МЭК 60671:2007, п. 3.8]

3.37 программное обеспечение (software): Программы (т.е. наборы

упорядоченных команд), данные, правила и любая связанная с этим

документация, имеющая отношение к работе компьютеризированных СКУ.

[МЭК 61513:2011, п. 3.51]

3.38 компонент программного обеспечения (software component):

Одна из составляющих частей программного обеспечения. Компоненты ПО

должны быть интегрированы для формирования комплексного программного

обеспечения.П р и м е ч а н и е – В данном стандарте ранее разработанный элемент ПО может рассматриваться в

качестве компонента ПО только если он внедрен в более крупное ПО для формирования операционной

системы. В частности, верификация и валидация комплексного программного обеспечения операционной

системы должна выполняться со встроенными программными компонентами. Интеграция может

осуществляться в рамках программного обеспечения, работающего на одном процессоре, например, для

операционных систем или библиотек реального времени. Интеграция может также выполняться в рамках

программного обеспечения, которое работает в тесной взаимосвязи на нескольких процессорах, например,

аппаратно-программное обеспечение коммуникационных модулей или модулей ввода-вывода.

3.39 разработка программного обеспечения (software development):

Все мероприятия жизненного цикла программного обеспечения, которые

направлены на создание программного обеспечения СКУ или программного

продукта и которые охватывают все фазы, начиная от подготовки

спецификации требований к программному обеспечению, до валидации и

12


установки.

3.40 модификация программного обеспечения (software

modification): Изменение в уже согласованном документе (документах),

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

стадии разработки программного обеспечения (например, для устранения ошибок, найденных на более

поздних стадиях разработки) либо уже после введения программного обеспечения в эксплуатацию.

[МЭК 60880:2006, п. 3.36]

3.41 жизненный цикл безопасности программного обеспечения

(software safety lifecycle): Необходимая деятельность при разработке и

эксплуатации программного обеспечения СКУ, важных для безопасности,

осуществляемая в течение всего периода времени, начиная с разработки

спецификации требований к программному обеспечению и заканчивая

выведением программного обеспечения из эксплуатации.

[МЭК 60880:2006, п. 3.37]

3.42 валидация программного обеспечения (software validation):

Тестирование и оценка интегрированной системы на соответствие

спецификациям функциональных, эксплуатационных характеристик и

интерфейсов, содержащихся в требованиях к СКУ.П р и м е ч а н и е – В данном стандарте валидация ПО рассматривается в качестве части валидации

системы.

3.43 статический анализ (static analysis): Процесс оценки системы или

компонента, базирующийся на ее (его) форме, структуре, содержании или

документации. В противоположность динамическому анализу.

[МЭК 60880:2006, п. 3.40]

3.44 системное программное обеспечение (system software):

Программное обеспечение, созданное для конкретного компьютера или

семейства оборудования с целью облегчения эксплуатации и обслуживания

этих объектов и связанных с ними программ. Например, операционные

системы, компьютеры, утилиты. Системное программное обеспечение

комплекса оборудования обычно состоит из операционного программного

13

ГОСТ Р МЭК 62138(Проект, редакция 1)обеспечения системы и поддерживающего программного обеспечения.

П р и м е ч а н и я

1. Операционное программное обеспечения системы: программное обеспечение, работающее на

целевом процессоре во время работы системы, например: операционная система, входные/выходные

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

программного обеспечения, самодиагностика, управление резервированием и смягченной деградацией.

2. Поддерживающее программное обеспечение: программное обеспечение, которое используется

при разработке, тестировании или технической поддержке другого ПО и таких систем, как компиляторы,

генераторы кодов, графические редакторы, автономная диагностика, инструменты верификации и

валидации и т.д.

3. См. также «прикладное программное обеспечение».

[МЭК 61513:2011, п. 3.58 с изменениями (добавлены примечания 2, 3 и

4)]

3.45 валидация системы (system validation): Подтверждение путем

проверки и предоставления других свидетельств того, что система в целом

соответствует спецификации требований (функциональность, время отклика,

устойчивость к дефектам и ошибкам, запас прочности).П р и м е ч а н и е – В Глоссарии МАГАТЭ по безопасности (версия 2016 г.) приводится два

следующих определения:

Валидация: Процесс определения является ли продукт или услуга приемлемыми для обеспечения

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

значительный элемент оценки, чем верификация.

Валидация системы компьютера: Процесс тестирования и оценки интегрированной компьютерной

системы (аппаратного и программного обеспечения) для обеспечения соответствия функциональным,

эксплуатационным и интерфейсным требованиям.

Во-первых, определение «валидация системы» является частным случаем валидации. Он относится

к конкретному продукту, а именно к валидации СКУ. Это соответствует определению МАГАТЭ. Во-вторых,

в определении МЭК приводится ссылка на валидацию, а именно на спецификацию требований, тогда как в

определении МАГАТЭ говорится только о «соответствующей функции».

[МЭК 61513:2011, п. 3.59]

3.46 систематический отказ (systematic fault): Отказ, обусловленный

определенной причиной, который может быть исключен за счет внесения

изменений в проект или в технологический процесс, эксплуатационную

операцию, документацию и т.п.

[МЭК 61513:2011, п. 3.60]

3.47 верификация (verification): Подтверждение экспертизой и

14


предоставлением объективного свидетельства того, что результаты

функционирования соответствуют целям и требованиям, определенным для

такого функционирования.

[МЭК 61513:2011, п. 3.62]

4 Обозначения и сокращения

В настоящем стандарте использованы следующие сокращения:

АС – Атомная станция

МЭК – Международная электротехническая комиссия

ООП – Отказ по общей причине

ПК – Подкомитет

ПО – Программное обеспечение

ППЗУ – Программируемое постоянное запоминающее устройство

ПЭ – Программируемый электронный

CB – Компьютеризированный

СКУ – Система контроля и управления

Э/Э/ПЭ – Электрическое/электронное/программируемое электронное

ЧМИ – Человеко-машинный интерфейс

5 Ключевые концепции и допущения

5.1 Общие положения

В разделе 5 представлены некоторые ключевые концепции и

допущения, которые касаются характера программного обеспечения и

вопросов его разработки для СКУ классов безопасности 2 или 3 и на которых

базируется нормативный документ.

5.2 Типы программного обеспечения

На рис. 1 представлены различные виды работы, выполняемой

программным обеспечением в типичной СКУ или в архитектуре контроля и

управления. Компоненты программного обеспечения могут часто

15

ГОСТ Р МЭК 62138(Проект, редакция 1)определяться как программное обеспечение системы или прикладное

программное обеспечение. Программное обеспечение системы может также

быть подразделено на операционное программное обеспечение системы,

встроенное в СКУ, важную для безопасности, и поддерживающее

программное обеспечение (или инструментальные программы), которое

является автономным либо встроенным в системы поддержки,

классифицируемые как не важные для безопасности. Программное

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

таких как датчики и исполнительные механизмы, устройства связи и

бесперебойного электропитания (БЭП).

Рисунок 1 - Типичные части программного обеспечения в компьютерных

СКУ

Программное обеспечение СКУ также подразделяют на ранее

разработанное программное обеспечение (которое обычно обеспечивает

функции, полезные для ряда СКУ) и новое (которое разработано для

16


конкретных задач СКУ). Требования настоящего стандарта, которым должно

соответствовать новое программное обеспечение, могут также быть

предъявлены и к ранее разработанному программному обеспечению.

Настоящий стандарт также содержит альтернативные требования, которым

должно, в частности, соответствовать ранее разработанное программное

обеспечение.

Многие современные комплексы оборудования обеспечены

ориентированными на прикладные задачи обширными инструментальными

средствами разработки, которые позволяют инженерам станции или

системным инженерам устанавливать свои требования к программному

обеспечению с использованием графических методов. Инструментальные

средства могут автоматически транслировать графические программы в

исполняемое прикладное программное обеспечение. При надлежащем

качестве этих инструментальных средств данный подход может применяться

для уменьшения риска появления ошибок.

5.3 Типы данных конфигурации

Во многих проектах систем широко используются данные

конфигурации. Данные конфигурации могут быть связаны с операционным

программным обеспечением системы или с прикладным программным

обеспечением. Данные конфигурации, связанные с прикладным

программным обеспечением, состоят, главным образом, из технических

данных станции, вытекающих из проекта станции, и обычно

подготавливаются проектантами станции, которые не обязаны иметь навыки

разработки программного обеспечения. Данные конфигурации могут быть

разделены следующим образом:

элементы данных, которые не предназначены для изменения

операторами станции в режиме реального времени и должны соответствовать

тем же требованиям, которые предъявляются к остальной части

программного обеспечения;

17


параметры, т.е. элементы данных, которые могут изменяться

операторами при эксплуатации станции (например, пределы срабатывания

аварийной сигнализации, установки, данные калибровки аппаратуры) и к

которым предъявляются специфичные требования.

5.4 Жизненные циклы безопасности и программного обеспечения

Рисунок 2 - Мероприятия жизненного цикла системы безопасности (в

соответствии с МЭК 61513:2011)

Программное обеспечение обычно вносит существенный вклад в

функции, выполняемые СКУ. Оно может также поддерживать

дополнительные функции, необходимые для самой системы (например,

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

18


подсистемами, синхронизацию подсистем). Таким образом, жизненный цикл

безопасности программного обеспечения в большинстве случаев тесно

связан с жизненным циклом безопасности системы. В частности,

спецификация требований к программному обеспечению является частью

или непосредственно вытекает из спецификации системы и проекта системы.

Хотя верификация компонентов программного обеспечения

несомненно является частью жизненного цикла безопасности программного

обеспечения, часто нет отдельной и четко установленной границы между

интеграцией программного обеспечения и интеграцией системы. Поэтому в

настоящем стандарте интеграция программного обеспечения

рассматривается как часть интеграции системы. Валидация программного

обеспечения также рассматривается как часть валидации системы.

19


П р и м е ч а н и е – Блоки, выделенные пунктиром, относятся к мероприятиям, на которые не

распространяются требования настоящего стандарта)

Рисунок 3 - Схема мероприятий, относящихся к программному обеспечению

в жизненном цикле системы безопасности

На рисунках 2 и 3 представлено соотношение между мероприятиями

жизненного цикла безопасности системы и жизненного цикла безопасности

программного обеспечения.

Необходимо отметить, что, хотя МЭК 61513:2011 устанавливает два

различных пути создания программного обеспечения (прикладное ПО и

операционное ПО системы, см рис. 2 и рис. 3), в настоящем стандарте

требования к созданию программного обеспечения объединены в четыре

группы:

6.6.1 - предусматривает требования, которые являются

применимыми независимо от того, какая техника создания используется;

6.6.2 - предусматривает требования, специфичные для

конфигурации ранее разработанного программного обеспечения и устройств,

содержащих программное обеспечение, в частности, для установления

параметров и других данных конфигурации;

6.6.3 - предусматривает требования, специфичные для разработки и

проверки программного обеспечения, написанного на проблемно-

ориентированных языках;

6.6.4 - предусматривает требования, специфичные для реализации и

верификации программного обеспечения, написанного на универсальных

языках.

Блоки схемы, обозначенные как «разработка/создание прикладного

программного обеспечения» и «разработка операционного программного

обеспечения системы», представляют большую и существенную часть

жизненного цикла безопасности программного обеспечения. На рис. 4 более

подробно показана деятельность, осуществляемая между составлением

спецификации требований к ПО и валидацией ПО с четким представлением

20


трех различных путей реализации проекта программного обеспечения

(конфигурация ранее разработанного программного обеспечения и

устройств, использование проблемно-ориентированных языков и

использование языков общего назначения).

Рисунок 4 - Мероприятия жизненного цикла безопасности программного

обеспечения по МЭК 62138

5.5 Принципы градации

Вследствие распределения функций в отношении безопасности по

категориям А, В и С (см. МЭК 61226) соответствующая градация была

введена и для требований к программному обеспечению СКУ, относящемуся

к классам безопасности 1, 2 и 3.

Информация по поводу программного обеспечения СКУ, которое

относится к классу безопасности 1, содержится в стандарте МЭК 60880.

Применение требований настоящего стандарта для класса безопасности

3 обеспечивает базовый уровень доверительности, соответствующий

программному обеспечению СКУ, важных для безопасности. При этом

руководствуются следующими принципами:

наличие программы обеспечения качества;

особое внимание уделяют тому, чтобы программное обеспечение:

21


• вносило необходимый вклад в функции, важные для

безопасности, и не оказывало на них отрицательного влияния,

• соответствовало положениям спецификации требований

программного обеспечения, которые устанавливают ограничения,

важные для безопасности;

обеспечение как можно более раннего информирования операторов

СКУ об ошибках и отказах программного обеспечения, которые могут

повлиять на функции, важные для безопасности, с тем чтобы можно было

предпринять необходимые действия;

наличие документально оформленных спецификаций требований к

программному обеспечению, спецификаций проекта, спецификаций

интеграции, спецификаций валидации (т.е. комплексное функциональное

тестирование) и спецификаций модификации.

Для класса безопасности 2 в дополнение к принципам, уже

изложенным для класса 3, в настоящем стандарте добавляют принципы:

базирующееся на тестированиях и проекте обоснования того, что

требование к характеристике, связанной с безопасностью (например, время

реакции), будет выполнено для всех заданных условий;

более жесткие требования к выбору ранее разработанного ПО;

более жесткие требования по верификации, управлению

конфигурацией ПО, выбору и использованию инструментальных программ и

языков программирования;

четкие требования к простоте, ясности, точности, проверяемости,

тестируемости и модифицируемости.

Если одно и то же требование применимо к обоим классам

безопасности, то степень необходимого обоснования соответствия может

зависеть от класса безопасности. В частности, для класса 3 эта степень может

быть меньшей по сравнению с классом 2. В дополнение к этому, степень

обоснования применительно к функциям, не определенным в качестве

важных для безопасности в рамках систем класса 2 или 3, зависит только от

22


того, насколько проект обеспечивает, что такие функции не могут

отрицательно влиять на функции, определенные в качестве важных для

безопасности.

6 Требования к программному обеспечению СКУ класса 2 и 3

6.1 Применение требований

Требования и рекомендации настоящего стандарта содержатся в

данном разделе 6. Требования и рекомендации, которые специально не были

отнесены к конкретному классу, применяются к системам как 2-го, так и 3-го

класса. Для требований и рекомендаций, которые применяются только к

системам класса 3 или класса 2, указана информация по этому поводу, также

эти требования и рекомендации выделены курсивом.

Все требования и рекомендации пронумерованы и начинаются с

отступа. Все остальные пункты носят информативный характер. В частности,

пункты без номера содержат примечания, которые относятся к

пронумерованному пункту выше, если не указано иное. В случае, если пункт

без номера содержит примечания к более чем одному пронумерованному

пункту выше, то такие пункты содержат пометку «Касательно ххх и ууу, ...».

Цель настоящего документа состоит не в том, чтобы назначить

определенный набор документов, а в том, чтобы определить информацию,

которая должна быть документально оформлена. Принятая конкретная

иерархия и формат документации могут варьироваться при условии

соблюдения принципов, изложенных в настоящем документе. Для примера в

Приложении А представлен типовой перечень документации на ПО.

6.2 Общие требования

6.2.1 Жизненный цикл безопасности программного обеспечения.

Обеспечение качества программного обеспечения

23


6.2.1.1 Общие положения

Пункт 6.3.2 МЭК 61513:2011 предусматривает требования к

обеспечению качества на уровне СКУ. Данный подраздел содержит

следующие специфичные или особо важные дополнительные требования к

программному обеспечению.

6.2.1.2 Разработка программного обеспечения должна проводиться в

соответствии с жизненным циклом безопасности программного обеспечения.

Положения этого жизненного цикла безопасности программного

обеспечения должны быть определены в плане обеспечения качества.

План обеспечения качества может быть частью плана обеспечения

качества системы или отдельным планом обеспечения качества


6.2.1.3 Если для программного обеспечения используется отдельный

план обеспечения качества, то он должен быть совместим с планом

обеспечения качества системы. В плане обеспечения качества ПО

необходимо учитывать требования 6.3.2 МЭК 61513:2011, поскольку они

относятся к программному обеспечению.

6.2.1.4 Этап разработки жизненного цикла безопасности

программного обеспечения в плане обеспечения качества должен быть

разделен на конкретные мероприятия. Эти мероприятия должны включать в

себя действия, необходимые для достижения требуемого качества

программного обеспечения, и обеспечивать объективное свидетельство того,

что это качество достигнуто.

6.2.1.5 В спецификации мероприятий должны быть указаны:

их цели;

их отношения и взаимосвязь с другими мероприятиями;

исходные данные и результаты;

организация мероприятий и связанная с ними ответственность.

6.2.1.6 Должны быть также указаны необходимое содержание и

свойства исходных данных и результатов.

24


6.2.1.7 План обеспечения качества должен содержать требование о

том, чтобы выполнение каждого мероприятия возлагалось на компетентных

лиц, обеспеченных соответствующими ресурсами.


том, чтобы изменения в уже утвержденной документации были определены,

проанализированы и утверждены уполномоченными на это лицами.


том, чтобы методы, языки, инструменты, правила и используемые стандарты

были определены, оформлены документально, изучены и усвоены

соответствующими лицами.


том, чтобы в случае использования нескольких методов, языков,

инструментов, правил и/или стандартов было ясно, какие из них должны

использоваться для каждого мероприятия.


том, чтобы специфичные для проекта термины, выражения, сокращения и

условные обозначения были четко определены.


том, чтобы возникающие проблемы были отслежены и решены.

6.2.1.13 План обеспечения качества должен содержать требование

регистрации результатов его применения. В частности, должно содержаться

требование регистрации результатов верификации и анализа вместе с

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

согласованных решений. Любое отклонение от плана обеспечения качества

должно быть обосновано и оформлено документально.

6.2.1.14 Необходимо, чтобы план обеспечения качества содержал

требование о том, что полученная документация должна быть представлена в

виде комплекта документов, которые содержат взаимные перекрестные

ссылки, благодаря чему обеспечивается прослеживаемость соблюдения

25

ГОСТ Р МЭК 62138(Проект, редакция 1)требований итогового проекта.

6.2.2 Верификация

6.2.2.1 План верификации должен определять область верификации

программного обеспечения и предусматривать необходимые мероприятия.

6.2.2.2 В плане верификации должны учитываться требования МЭК

61513:2011 п. 6.3.2.2, поскольку они относятся к программному

обеспечению.

6.2.2.3 Верификация и анализ должны быть выполнены в

соответствии с документально оформленными положениями. В плане

верификации должно подтверждаться следующее:

результаты верификации находятся в рамках управления

конфигурацией;

для мероприятий имеются точно определенные исходные данные и

результаты мероприятий согласуются с этими исходными данными;

мероприятия реализуют указанные для них цели, а их результаты

обладают требуемыми содержанием и свойствами и соответствуют каждому

из согласованных решений;

результаты являются ясными, точными и своевременными;

результаты согласуются с каждым из применимых к ним правил;

результаты согласуются с применимыми для них требованиями

данного стандарта.

«Точно определенный» означает то, что текст понятен и не является

двусмысленным. «Ясный» означает то, что лица, которые должны читать

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

они ранее не участвовали в проекте, при условии, что они обладают

необходимыми знаниями. «Точный» означает, что двусмысленности

отсутствуют.

Объем мероприятий по верификации и анализу может зависеть от

масштаба и характера программного обеспечения, масштаба и характера

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

26


методов и инструментальных программ. Объем мероприятий может быть

уменьшен для конкретных требований, которые не определены в качестве

важных для безопасности (см. 6.4.4.7) и не могут отрицательно влиять на

функции, определенные в качестве важных для безопасности.

6.2.2.4 План верификации должен обеспечивать такое ведение

записей, при котором процесс верификации может быть проверен в полном

объеме, т.е. таким образом, чтобы можно было независимо подтвердить

внедрение плана верификации.

6.2.2.5 Верификация результатов мероприятий должна проводиться

компетентными лицами, не принимавшими участия в этих мероприятиях.

Это не означает, что лицо, являющееся автором одного документа, не

может верифицировать другой документ.

6.2.2.6 В число таких лиц должны входить представители структур,

связанных с использованием этих результатов, а также, при необходимости,

другие эксперты.

6.2.2.7 Верификации должны подвергаться: спецификация требований

к программному обеспечению, спецификация проекта программного

обеспечения и план валидации программного обеспечения.

6.2.2.8 Для класса 2, верификации должна подвергаться реализация

проекта и правила реализации.

6.2.2.9 Верификация ПО должна проводиться лицами, которые не

участвовали в процессе разработки программного обеспечения, подлежащего

верификации.

6.2.2.10 Для класса 2, лица, которые проводят верификацию, должны

быть независимы в административном плане от лиц, которые занимались

разработкой ПО.

6.2.3 Управление конфигурацией


Подпункт 6.3.2.3 МЭК 61513:2011 содержит требования по управлению

27

ГОСТ Р МЭК 62138(Проект, редакция 1)конфигурацией на уровне СКУ. В нем предусмотрены следующие

дополнительные требования, специфичные или особенно важные для


6.2.3.2 Управление конфигурацией программного обеспечения

должно быть выполнено согласно положениям плана управления

конфигурацией или плана обеспечения качества. Эти положения должны

согласовываться с положениями управления конфигурацией на уровне

системы.

6.2.3.3 Управление конфигурацией должно применяться к элементам,

связанным с правильностью программного обеспечения. В плане управления

конфигурацией должно быть определено, какие элементы программного

обеспечения или какие типы элементов программного обеспечения должны

находиться под управлением конфигурацией. В частности, в него должны

входить:

ключевые документы жизненного цикла безопасности (в

особенности документы, требующие верификации);

компоненты программного обеспечения, необходимые для

построения рабочей программы, и сама рабочая программа;

инструментальные программы, влияющие на правильность


6.2.3.4 В плане управления конфигурацией должны быть определены

технические средства для идентификации элементов программного

обеспечения и их версий, находящихся под управлением конфигурацией.

6.2.3.5 План управления конфигурацией должен обеспечивать

однозначное определение версии программного обеспечения, используемой в

данной версии системы или оборудования, и версии элементов, которые

вместе составляют данную версию программного обеспечения.

6.2.4 Выбор и использование инструментальных программ


28


Инструментальные программы могут играть важную роль в

предотвращении внесения дефектов в программное обеспечение или проект

системы, а также в обнаружение уже существующего дефекта. В частности,

инструментальные программы могут помочь в создании проекта архитектуры

СКУ и нового прикладного программного обеспечения или автоматизировать

это создание.

6.2.4.2 Инструментальные программы должны способствовать тем

этапам разработки, которые обеспечивают правильность программного

обеспечения и проекта системы.

Обычно предпочтительно уделить внимание не только качеству и

использованию отдельных инструментальных программ, но и их

совместимости с другими инструментальными программами, с тем чтобы

собранные вместе инструментальные программы составляли

взаимосвязанный набор. В целом, предпочтительней использовать известную

инструментальную программу с обширным опытом эксплуатации.

Использование других инструментальных программ может быть основано на

требованиях конкретного процесса разработки.

6.2.4.3 Для класса 2, комплексы оборудования, используемые для

создания СКУ, должны быть связаны с инструментальными программами,

снижающими риск внесения дефектов в новое прикладное программное


6.2.4.4 Для класса 3, комплексы оборудования, используемые для

создания СКУ, должны быть связаны с инструментальными программами,

снижающими риск внесения дефектов в новое прикладное программное


Касательно 6.2.4.3 и 6.2.4.4, эти инструментальные программы обычно

включают в себя поддержку проблемно-ориентированных языков, позволяя

операторам станции и системы устанавливать или верифицировать

прикладные функции. Другими существенными задачами для таких

29

ГОСТ Р МЭК 62138(Проект, редакция 1)инструментальных программ могут быть анимация, генерация кодов и

помощь в определении функционального набора тестовых примеров.

6.2.4.5 Комплексы оборудования, используемые при разработке

СКУ, должны быть связаны с инструментальными программами, что может

снизить риск появления дефектов в конфигурации их ранее разработанного

программного обеспечения и проекта системы.

Такие инструменты могут, например, помочь проектировщикам

системы в:

организации системы в виде соответствующего набора связанных

подсистем;

распределении прикладных функций между подсистемами;

конфигурировании подсистем, их коммуникаций и операционных

систем;

обеспечении необходимых ресурсов для всех режимов работы

системы;

учете существующих ограничений при проектировании и

реализации, в особенности обеспечивающих корректность и устойчивость

системы.

6.2.4.6 План обеспечения качества должен точно определять

инструментальные программы, которые могут повлиять на корректность


6.2.4.7 Для таких инструментальных программ должна быть

предоставлена документация пользователя, чтобы гарантировать их

соответствующее использование.

6.2.4.8 В плане обеспечения качества должны различаться

инструментальные программы, которые могут привести к сбоям в ПО и

инструментальные программы, которые могут привести только к тому, что

уже существующий сбой будет пропущен.

Например, генераторы кодов и компиляторы относятся к первой

категории инструментальных программ, тогда как статические анализаторы

30


кодов и генераторы контрольных примеров относятся ко второй категории

инструментальных программ.

6.2.4.9 Для класса 2, выбор и использование инструментальных

программ, которые могут привести к сбоям в ПО, должны производиться

согласно документально оформленных процедур и правил, направленных на

уменьшение или смягчение такого риска. Должно быть представлено

подтверждение их качества и способности приводить к правильным

результатам. При использовании инструментальных программ для генерации

заданного элемента или информации, их использование должно быть

прописано в соответствующих документах для возможности идентификации

данных программ.

6.2.4.10 Для класса 3, должно быть представлено подтверждение

качества инструментальных программ, которые могут привести к сбоям в

ПО, а также подтверждение их способности приводить к правильным

результатам.

6.2.4.11 Свидетельство качества инструментальных программ и их

способности приводить к правильным результатам должно базироваться на

опыте эксплуатации, квалификации или сертификации инструментальной

программы, сертификации поставщиков инструментальных программ для

соответствующей деятельности, гарантии применения соответствующих

процессов разработки инструментальной программы и/или ее тестирований.

Требуемая строгость доказательств должна определяться исходя из условий

использования инструментальной программы, степени проверки ее

результатов, вероятности обнаружения ошибок и серьезности последствий

ошибочных результатов, которые не были обнаружены. И наоборот, веские

доказательства (например, квалификация инструментальной программы в

соответствии с МЭК 60880) могут заменить проверку некоторых результатов.

31


6.2.4.12 Для класса 2, выбор и использование инструментальных

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

выполняться таким образом, чтобы снизить этот риск.

6.2.4.13 Для класса 2, должны быть внесены соответствующие записи

об использовании инструментальных программ, которые могут не выдать

информацию о сбоях ПО.

6.2.4.14 Для класса 2, когда инструментальная программа или версия

инструментальной программы, которая потенциально может привести к

сбоям в ПО, заменяется другой программой/версией, необходимо принять

меры предосторожности для обеспечения того, чтобы это не оказало

отрицательного влияния на корректность работы программного обеспечения.

Например, помимо качества и способности новой инструментальной

программы приводить к правильным результатам, возможно, потребуется

провести оценку ее совместимости с предыдущей инструментальной

программой.

6.2.5 Выбор языков

6.2.5.1 Используемые для создания программного обеспечения языки

(проблемно-ориентированные или универсальные) должны иметь точные и

документально оформленные синтаксис и семантику.

6.2.5.2 По возможности, предпочтение должно отдаваться проблемно-

ориентированным языкам.

6.2.5.3 Для класса 2, для конкретных компьютерных программ

допустимо использование машинно-ориентированного универсального языка

(например, языки ассемблер), однако такое использование должно быть

обосновано.

6.2.5.4 Если для создания одной рабочей программы используется

более одного языка, интерфейсы между языками должны быть оформлены

документально.

Интерфейс между языками включает в себя схемы передачи аргумента

и представление структур данных.

32


6.2.5.5 Для класса 2, используемые универсальные языки должны

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

компьютерных программ.

6.2.5.6 Используемые универсальные языки должны поддерживать

статический и прямой ввод переменных.

6.2.5.7 Для класса 2, необходимо использовать статический и прямой

ввод переменных.

6.2.5.8 Для класса 2, используемые языки и их соответствующие

библиотеки времени выполнения должны обеспечивать предсказуемое

поведение среды выполнения ПО.

Например, обычно не допускается случайное нарушение нормального

поведения программного обеспечения для сбора освобожденной памяти.

6.3 Выбор ранее разработанного программного обеспечения

6.3.1 Общие положения

Подпункт 6.2.3.2 МЭК 61513:2011 предусматривает общие требования

при выборе ранее разработанных компонентов (не обязательно компонентов

программного обеспечения). Настоящий подраздел 6.3 вводит следующие

дополнительные требования, специфичные или особенно важные для


Прикладное ПО относится к конкретной станции и не может считаться

ранее разработанным программным обеспечением.П р и м е ч а н и е – Одинаковое прикладное ПО может использоваться на различных блоках на

основе одного проекта станции и требований к безопасности. В этом случае, обоснования, которые

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

6.3.2 Документация по безопасности

6.3.2.1 Цели

6.3.2.1.1 Ранее разработанное программное обеспечение должно

сопровождаться документами, содержащими необходимую информацию для

использования этого программного обеспечения в СКУ.

33


В настоящем стандарте сопроводительный документ (пакет

документов), имеет наименование «документация по безопасности». Если

ранее разработанное программное обеспечение является частью

оборудования или комплекса оборудования, то такие документы могут быть

частью документации по безопасности на оборудование или семейство

оборудования.

Как правило, документация по безопасности включает в себя не только

документацию пользователя, которую предоставляет поставщик ранее

разработанного ПО. Например, в ней могут содержаться данные, полученные

по результатам дополнительного тестирования, измерений и/или анализов, а

также из опыта эксплуатации.

6.3.2.2 Содержание

6.3.2.2.1 Документация по безопасности должна включать в себя

описание:

предусмотренных функций;

интерфейсов с приложениями;

ролевых имен, типов, форматов, диапазонов и пределов входных,

выходных и исключающих сигналов, параметров и данных конфигурации

(если присвоены);

различных режимов работы и соответствующих условий перехода;

любых ограничений, относящихся к использованию ранее

разработанного программного обеспечения.

6.3.2.2.2 Для класса 2, где необходимо, такие ограничения должны:

обеспечивать достаточную степень уверенности в правильности

интегрированного программного обеспечения и проекта системы (например,

пределы, устанавливаемые при использовании динамически размещенных

ресурсов, таких как память, вычислительная мощность, полоса пропускания

канала связи, ресурсы операционной системы);

34


усиливать способность интегрированного ПО и СКУ быть

устойчивым к дефектам, обнаруживать ошибки и отказы и оповещать о них,

работать в указанных режимах и восстанавливаться после отказов;

обеспечивать уверенность в том, что ошибки операторов и отказы

других систем или оборудования, с которыми интегрированное ПО

взаимодействует или использует общие ресурсы, не будут приводить к

определенным режимам эксплуатации;

обеспечивать гарантию в том, что среда ранее разработанного ПО

представит все необходимые ресурсы в рамках всех условий работы СКУ.

6.3.2.2.3 Там, где это необходимо, документация по безопасности

должна также предоставлять информацию о характеристиках функций

(например, в виде времени срабатывания).

Функции, которые реализует ПО, включая те, которые относятся к

интерфейсам системы, могут различаться в зависимости от условий

эксплуатации на станции.

6.3.2.2.4 Для класса 2, документация по безопасности должна также

предоставлять информацию о:

выполненном самоконтроле, устойчивости к дефектам и режимах

отказа;

требованиях ранее разработанного ПО к среде выполнения

(например, касательно компонентов технических средств или другого ПО);

взаимосвязях и интерфейсах ранее разработанного ПО с

техническим обеспечением в той степени, которая необходима для

определения безопасного функционирования системы.

6.3.2.2.5 Для класса 2, документация по безопасности операционного

ПО системы ранее разработанного комплекса оборудования должна

содержать информацию, позволяющую (в сочетании с данными по

конкретному применению) делать правильные прогнозы относительно

ключевых элементов безопасности, важных для производительности

35

ГОСТ Р МЭК 62138(Проект, редакция 1)системы, включая, в частности, максимальное время отклика и максимальное

использование ресурсов.

Такая информация может быть представлена в виде данных, формул

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

времени отклика и использования ресурсов приложений. Когда ПО

предусматривает наличие широкого диапазона функций, интерфейсов и

возможностей для конфигурации, могут возникнуть сложности с получением

достаточной степени уверенности в правильности информации без сведений

о принципах работы программного обеспечения.

6.3.2.3 Свойства

6.3.2.3.1 Документация по безопасности должна быть четкой, не

допускающей двоякой интерпретации.

6.3.3 Свидетельство корректности

6.3.3.1 Общие требования

6.3.3.1.1 Должна быть подтверждена корректность ранее

разработанного программного обеспечения по отношению к его

документации по безопасности.

Обычно подтверждение является качественным, т.к. общепризнанных

методов количественной оценки не существует. На рис. 5 и рис. 6

представлен типичный процесс, которым можно воспользоваться. Однако,

известно, что это не единственный подход, можно воспользоваться и

другими.

6.3.3.1.2 При использовании дополнительных средств для

предоставления свидетельств корректности, на ранних этапах жизненного

цикла безопасности ПО должны быть определены критерии приемки с

соответствующим обоснованием. Данные критерии должны быть

обоснованы с учетом требований настоящего стандарта, соответствие

которым в полной мере не установлено.

6.3.3.1.3 Ранее разработанное ПО должно подразделяться на два вида:

a) Комплексное ПО операционной системы.

36


b) Компоненты программного обеспечения (операционная система,

работающая в режиме реального времени, библиотека, аппаратно-

программное обеспечение).П р и м е ч а н и е – Прикладное ПО разрабатывается специально для станции и не может считаться

ранее разработанным ПО (см. 6.3.1.1).

Данное разделение основывается на том, что для формирования

комплексного ПО операционной системы компоненты ПО должны быть

интегрированы в более крупное ПО. Это означает, что для компонентов ПО

появляются преимущества от процесса разработки комплексного

программного обеспечения операционной системы. Данный процесс

позволяет провести верификацию и валидацию их функциональности в

рамках использования в комплексном ПО операционной системы. Таким

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

ПО операционной системы с точки зрения его документации по безопасности

(см. рис. 5) является более требовательным, чем рекомендуемый подход к

обоснованию правильности компонентов ПО (см. рис. 6).

6.3.3.1.4 Элемент ранее разработанного ПО должен считаться

компонентом ПО только если он интегрирован в более крупное программное

обеспечение для формирования комплексного ПО операционной системы. В

дополнение к этому, элемент ранее разработанного ПО должен считаться

компонентом программного обеспечения только если более позднее

изменение конфигурации операционного ПО не привело к тому, что

компонент мог быть реализован другим способом, отличным от его

изначального использования (поскольку это будет означать, что при

квалификации комплексного операционного элемента компонент ПО не

будет квалифицирован соответствующим образом).

6.3.3.1.5 Верификация и валидация комплексного ПО операционной

системы должны включать встроенные компоненты ПО. Интеграция может

быть выполнена в ПО, которое функционирует на едином процессоре,

например, операционные системы, работающие в режиме реального времени,

37

ГОСТ Р МЭК 62138(Проект, редакция 1)или библиотеки. Интеграция может также выполняться в рамках

программного обеспечения, которое работает в тесной взаимосвязи на

нескольких процессорах, например, аппаратно-программное обеспечение

коммуникационных модулей или модулей ввода-вывода.

6.3.3.1.6 Для класса 2, процесс квалификации компонентов ПО (см.

рис. 6) должен применяться только к компонентам ранее разработанного ПО,

которые являются неавтономными исполняемыми программами.

Автономная исполняемая программа - это программное обеспечение,

которое может функционировать самостоятельно без каких-либо

дополнительных кодов.

К типичным автономным исполняемым программам относятся

операционные системы общего назначения, которые были разработаны для

использования на рабочих местах, поскольку после их установки они

автоматически выполняют множество задач, которые не были назначены

пользователем.

Чтобы запустить функционирование библиотек (например, библиотека

С), они должны вызываться дополнительным кодом. Библиотека может быть

скомпилирована и загружена на процессор, но она не будет функционировать

без кода, который был написан для вызова ее функций. Таким образом,

библиотека не относится к автономным исполняемым программам.

Операционные системы, работающие в режиме реального времени,

которые изначально разрабатывались для работы встроенного ПО, обычно не

относятся к автономным исполняемым программам, поскольку пользователь

должен четко определять каждую задачу, но это должно проверяться

отдельно в каждом конкретном случае.

6.3.3.1.7 Корректность компонента ПО с учетом его документации по

безопасности должна основываться на соответствующем положительном

опыте работы в достаточном объеме (см.6.3.3.3), либо на сертификации (см.

6.3.3.4) (см. рис. 6).

38


Рисунок 5 - Обзор типичного процесса квалификации ранее разработанного

комплексного ПО операционной системы

39


Рисунок 6 - Обзор типичного процесса квалификации компонентов ранее

разработанного ПО

6.3.3.1.8 Для того чтобы подтвердить корректность комплексного ПО

операционной системы с учетом его документации по безопасности, вначале

необходимо провести анализ соответствия требованиям общих подразделов

данного стандарта (6.2, 6.4 - 6.8 и 6.11).

6.3.3.1.9 Комплексное ПО операционной системы должно быть

утверждено, в случае если при данном анализе было установлено, что оно

соответствует требованиям общего подраздела данного стандарта (6.2, 6.4 -

6.8 и 6.11).

В случае если в ходе данного анализа было выявлено, что комплексное

ПО операционной системы имеет некоторые несоответствия требованиям

подразделов данного стандарта (6.2, 6.4 - 6.8 и 6.11), тогда данные

несоответствия могут быть компенсированы соответствующим

положительным опытом эксплуатации в достаточном объеме (см. 6.3.3.3). В

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

возможно прибегнуть к тестированию.

40


К данным несоответствиям относятся случаи, когда для программного

обеспечения операционной системы соблюдался и был документально

оформлен полный жизненный цикл безопасности ПО, но в рамках различных

фаз были соблюдены не все требования подразделов данного стандарта (6.2,

6.4 - 6.8 и 6.11).

Например, когда в рамках фазы спецификации требований к ПО (6.4)

были определены и документально оформлены требования к ПО СКУ, но они

не содержат всего объема информации, который требуется согласно 6.4.4.

6.3.3.1.10 В случае если при анализе было установлено, что

комплексное ПО операционной системы имеет несоответствия требованиям

6.2.4 , такие несоответствия должны компенсироваться соответствующим

положительным опытом эксплуатации в достаточном объеме (см. 6.3.3.3).

6.3.3.1.11 Если при анализе было выявлено, что комплексное ПО

операционной системы имеет существенные несоответствия требованиям

подразделов 6.2.2, 6.7 или 6.8, тогда эти несоответствия должны

компенсироваться дополнительным тестированием (6.3.3.2).

6.3.3.1.12 В случае если в ходе анализа было установлено, что

комплексное ПО операционной системы имеет существенные несоответствия

требованиям подразделов 6.2.1, 6.2.3, 6.2.5, 6.4, 6.5, 6.6 или 6.11 , то такой

жизненный цикл ПО считается неприемлемым. В таких ситуациях должны

быть внедрены соответствующие корректирующие мероприятия, чтобы

утвердить программное обеспечение. Целью данных корректирующих

мероприятий должно быть приведение в соответствие требованиям общих

подразделов настоящего стандарта (6.2, 6.4 - 6.6 и 6.11). В случае если

корректирующие мероприятия применить невозможно, то необходимо

отказаться от использования комплексного ПО операционной системы.

Что касается подразделов 6.3.3.1.11 и 6.3.3.1.12, к существенным

несоответствиям относятся случаи, когда не соблюдался и не был

документально оформлен полный жизненный цикл безопасности ПО.

41

ГОСТ Р МЭК 62138(Проект, редакция 1)Существенным несоответствием считается, если жизненный цикл

безопасности соблюдался, но не был документально оформлен.

Также примером существенного несоответствия считается, если не

была документально оформлена валидация.

6.3.3.1.13 Стратегия обоснования корректности ранее разработанного

ПО, касательно его документации по безопасности, должна быть одобрена

всеми участниками процесса разработки СКУ на раннем этапе.

Данная стратегия не может быть полностью разработана до завершения

анализа комплексного ПО операционной системы на соответствие

требованиям общих подразделов данного стандарта (6.2, 6.4 - 6.8 и 6.11),

поскольку она зависит от несоответствий, которые необходимо

компенсировать.

6.3.3.2 Дополнительные тестирования

6.3.3.2.1 Общие положения

Дополнительные тестирования могут использоваться в качестве

поддержки обоснования корректности ранее разработанного ПО при

следующих условиях:

6.3.3.2.2 Тестирования ранее разработанного программного

обеспечения, выполненные при создании СКУ, должны быть оформлены


6.3.3.2.3 Эти тестирования должны подтвердить, что в условиях

применения в СКУ ранее разработанное программное обеспечение и его

работа соответствуют документации по безопасности.

Условия использования могут касаться таких аспектов, как

конфигурация ранее разработанного программного обеспечения (особенно

установка параметров и данных конфигурации), использование функций и

интерфейсов, аппаратных средств, процессора и загрузки по требованию.

6.3.3.2.4 Для класса 2, правила, которые применяются к разработке

дополнительного тестирования, должны быть документально оформлены и

обоснованы.

42


6.3.3.2.5 В документации по дополнительным тестированиям должны

быть сделаны следующие записи:

использованная версия и конфигурация ранее разработанного ПО;

описание проведенных тестирований и использованное техническое

обеспечение с тем, чтобы была возможность повторить эти тестирования в

идентичных условиях;

принятые гипотезы и доказательство их достоверности;

полученные результаты и подтверждение их правильности;

заключения и согласованные решения.

6.3.3.3 Эксплуатационный опыт


Эксплуатационный опыт может быть принят во внимание для систем

более низкого класса безопасности, либо систем, которые не

классифицируются по безопасности. Эксплуатационный опыт может

использоваться как дополнительное доказательство корректности ранее

разработанного программного обеспечения, при следующих условиях:

6.3.3.3.2 Необходимо документально оформить объем опыта

эксплуатации.

6.3.3.3.3 Для класса 2, учитываемый опыт эксплуатации должен

соответствовать точно определенным версиям ранее разработанного ПО и

оборудования, в котором оно используется, если данное ПО специально

предназначено для этого конкретного оборудования.

6.3.3.3.4 Для класса 2, если весь эксплуатационный опыт или его часть

соответствует другим версиям ранее разработанного программного

обеспечения и/или оборудования, различия с версиями, которые

используются в СКУ, должны быть оценены и уместность данного

эксплуатационного опыта должна быть обоснована.

6.3.3.3.5 Для класса 2, необходимо предоставить документально

оформленное обоснование того, что учитываемый опыт эксплуатации

43

ГОСТ Р МЭК 62138(Проект, редакция 1)соответствует условиям использования данной системы контроля и

управления (предполагаемая конфигурация программного обеспечения

является одним из условий использования). В случае, если условия опыта

эксплуатации не отличаются может быть учтен эксплуатационный опыт

систем, которые относятся к более низкому классу эксплуатации, либо

систем, которые не классифицируются по безопасности.

6.3.3.3.6 Для класса 2, методы, использованные для накопления

принимаемого во внимание эксплуатационного опыта, должны быть

оформлены документально. В частности, необходимо предоставить

документальное подтверждение того, что отказы (если имели место быть),

которые были вызваны ранее разработанным программным обеспечением в

течение учтенного эксплуатационного опыта, были правильно обнаружены и

зафиксированы.

6.3.3.3.7 Для класса 2, Должно быть показано, что эти отказы были

правильно проанализированы и что соответствующие ошибки программного

обеспечения исправлены.

6.3.3.4 Сертификация


Ранее разработанное программное обеспечение, уже действующее в

системах, важных для безопасности (хотя не обязательно в СКУ атомных

электростанций), возможно, было аттестовано на соответствие некоторым

стандартам по безопасности. Свидетельство, обеспеченное такой

сертификацией, может быть использовано в качестве существенной

поддержки обоснования корректности ранее разработанного ПО при

следующих условиях:

6.3.3.4.2 Документ по безопасности, который используется при

сертификации ранее разработанного ПО, должен четко описывать процесс

разработки ПО.

6.3.3.4.3 Учитываемая сертификация должна быть документально

оформлена.

44


6.3.3.4.4 Должна быть документально прописана четкая

идентификация ранее разработанного сертифицированного ПО. Если данное

ранее разработанное ПО было сертифицировано как часть большего изделия

(например, как часть оборудования или комплекса оборудования), должна

быть также прописана четкая идентификация данного изделия.

6.3.3.4.5 Для класса 2, свидетельства, подтверждающие сертификацию,

подлежат оценке, в частности:

условия сертификации (например, условия использования и

допущения);

методы и инструменты, используемые для сертификации;

полученные результаты (например, свойства и/или измерения).

6.3.3.4.6 Для класса 2, должна быть обоснована значимость этих

условий и результатов для подтверждения корректности.

6.3.3.4.7 Для класса 2, необходимо обосновать эффективность методов

и инструментов, которые были использованы для сертификации.

6.3.3.4.8 Для класса 2, должен быть определен сертификационный

орган, и он должен быть компетентным в отношении аттестуемых свойств

и/или измерений.

6.3.3.4.9 Для класса 2, версия ранее разработанного

сертифицированного программного обеспечения должна быть такой же, что

используется в СКУ.

6.3.3.5 Модификация


Если проведена хорошо определенная и ограниченная модификация

ранее разработанного программного обеспечения, для которого уже

существует обоснование корректности, то для обновления или завершения

обоснования могут использоваться следующие требования в качестве замены

требований 6.3.3.1 - 6.3.3.4 . Изменение в конфигурации ранее

разработанного программного обеспечения не является модификацией при

45

ГОСТ Р МЭК 62138(Проект, редакция 1)условии, что его новая конфигурация остается в пределах, охватываемых

обоснованием корректности.

6.3.3.5.2 Модификация ранее разработанного программного

обеспечения должна быть оформлена документально.

6.3.3.5.3 Для класса 2, документация по модификации должна

содержать:

четкую идентификацию измененного программного обеспечения;

обстоятельства модификации, если программное обеспечение

является частью большего продукта (например, оборудования или комплекса

оборудования);

цели, спецификацию и ограничения модификации;

изменения, произведенные в документации по безопасности.

6.3.3.5.4 Для класса 3, документация по модификации должна

содержать:

четкую идентификацию измененного программного обеспечения;

обстоятельства модификации, если программное обеспечение

является частью большего продукта (например, оборудования или комплекса

оборудования);

цели, спецификацию и ограничения модификации;

изменения, произведенные в документации по безопасности.

Касательно 6.3.3.5.3 и 6.3.3.5.4, контекст модификации может,

например, отражать:

четкую идентификацию измененного большего продукта;

цели, спецификацию и ограничения модификации изделия;

модификации, которые должны быть внесены в остальную часть

продукта или которые могут иметь воздействие на ранее разработанное

программное обеспечение;

верификацию и валидацию, выполняемые на уровне продукта.

6.3.3.5.5 Для класса 2, следует также установить изменения, внесенные

в проект ранее разработанного программного обеспечения.

46


6.3.3.5.6 Документально оформленное свидетельство (например,

основанное на визуальном анализе, анализах и/или тестированиях с

применением инструментальных программ), касающееся измененного

программного обеспечения, а возможно, и большего продукта, должно

подтверждать, что:

цели модификации достигнуты;

дефекты не были внесены;

модифицированное программное обеспечение соответствует его

обновленной документации по безопасности.

6.3.3.5.7 Для класса 2, достаточность этого свидетельства должна быть

обоснована, по возможности, с учетом сделанных модификаций и условий

использования в СКУ.

6.3.3.5.8 Необходимо актуализировать документацию по безопасности

таким образом, чтобы соблюдалась ее точность в отношении каких-либо

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

эксплуатацию и техническую поддержку системы, проводимые

пользователем, к которой относится ПО.

6.3.4 Функциональная пригодность


Цель настоящего пункта состоит в обеспечении соответствия ранее

разработанного программного обеспечения потребностям СКУ и того, что

оно не является слишком сложным для этих потребностей.

6.3.4.2 В случае, если используется документация по безопасности

ранее разработанного программного обеспечения, она должна быть

сопоставлена со спецификацией системы и проектом системы (если это

возможно). Несоответствия должны быть устранены.

6.3.4.3 Для класса 2, следует идентифицировать те функции ранее

разработанного программного обеспечения, которые не требуются в

спецификации требований к системе. Необходимо представить обоснование

47

ГОСТ Р МЭК 62138(Проект, редакция 1)того, что эти функции не оказывают негативного воздействия на

безопасность.

6.3.5 Выбор и использование цифровых устройств ограниченной

функциональности

В отношении цифровых устройств ограниченной функциональности в

качестве альтернативы данному стандарту может использоваться МЭК

62671. В МЭК 62671 указаны четкие критерии для определения возможности

применения к конкретным устройствам.

6.4 Спецификация требований к программному обеспечению


Настоящий подраздел 6.4 завершает и уточняет требования подпункта

6.2.3.4 МЭК 61513:2011.

6.4.2 Цели

6.4.2.1 Требования к программному обеспечению СКУ должны быть

определены и оформлены документально.

В настоящем стандарте соответствующий документ или пакет

документов именуется как «Спецификация требований к программному

обеспечению». В общем, его цель состоит в определении задач программного

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

факторы проекта и разработки, вероятно, придется определить, если это

потребуется при рассмотрении проекта СКУ или архитектуры СКУ.

6.4.2.2 Для класса 2, в спецификации требований к программному

обеспечению следует избегать излишней сложности проекта программного

обеспечения

6.4.2.3 Спецификация требований к программному обеспечению

должна быть такой, чтобы:

она способствовала уверенности в корректности проекта СКУ;

было показано соответствие СКУ требованиям МЭК 61513:2011.

Требования МЭК 61513:2011, относящиеся к спецификации

требований к программному обеспечению, содержатся главным образом в

48


6.2.2.3, 6.2.2.4, 6.2.2.5, 6.2.3.3, 6.2.3.5 и 6.2.4.


должна быть основой проекта программного обеспечения, валидации

программного обеспечения и возможных модификаций программного

обеспечения.

6.4.3 Исходная информация

6.4.3.1 Для класса 2, исходная информация для спецификации

требований к программному обеспечению должна включать в себя

спецификацию системы и документацию проекта системы.

Исходная информация может также включать в себя другие

документы, например:

специфичные ограничения проекта;

правила и стандарты, применимые к исходной информации;

требования, такие как независимость между функциями;

требования, относящиеся к целостности, например,

самодиагностика, чтобы привести выходы в безопасное состояние в случае

обнаружения отказов.

6.4.3.2 Для класса 2, структура спецификации требований к

программному обеспечению должна способствовать проведению

верификации, чтобы обеспечивать соответствие и полноту по отношению к

исходным документам.

Спецификация требований к программному обеспечению может

непосредственно ссылаться на исходные документы во избежание ненужных

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

также ссылаться на другие ранее существовавшие документы, такие,

например, как документация по ранее разработанному программному

обеспечению.


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

49


6.4.3.4 В ходе верификации спецификации требований к ПО (см. 6.2.2)

необходимо, в частности, проверить, что она в полной мере соответствует

исходным документам.

6.4.3.5 Ссылки на другие документы (при наличии), имеющиеся в

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

четкими и однозначными.

6.4.3.6 Для класса 2, в спецификации требований к программному

обеспечению следует избегать ненужного функционала.

В принципе, желательно, чтобы программное обеспечение не имело

большего числа возможностей, чем требуется, чтобы свести к минимуму ее

сложность. Тем не менее, поскольку существующая в промышленности

практика основана на использовании ранее разработанных компонентов,

может быть обосновано также включение невостребованных возможностей.

6.4.4 Содержание


должна определять:

прикладные функции, которые должны быть обеспечены

программным обеспечением;

различные режимы работы программного обеспечения и

соответствующие условия переходов;

интерфейсы и взаимодействие программного обеспечения с его

окружением (например, с операторами, остальной частью системы СКУ,

другими системами и оборудованием, с которыми оно взаимодействует или

разделяет ресурсы), включая ролевые имена, типы, форматы, диапазоны и

ограничения по входам и выходам;

параметры программного обеспечения, которые, при

необходимости, изменяются операторами во время эксплуатации, их ролевые

имена, типы, форматы, диапазоны и ограничения и проверки,

осуществляемые программным обеспечением в случае изменений этих

параметров;

50


требуемые рабочие характеристики (при необходимости);

указание на то, чего программное обеспечение не должно делать

или чего должно избегать (при необходимости);

при необходимости требования или допущения, устанавливаемые

программным обеспечением к его окружению.

6.4.4.2 В спецификации требований к программному обеспечению

следует также устанавливать параметры (например, загрузка по запросу),

подверженные воздействию окружения программного обеспечения, особенно

для наихудших условий.

Касательно 6.4.4.1 и 6.4.4.2,требования к функциям, интерфейсам и

характеристикам могут зависеть от режима работы, значений параметров,

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


6.4.4.3 В спецификации требований к программному обеспечению

следует определять режимы его работы при обнаружении ошибок или

отказов. Если для СКУ требуются периодические тестирования, то

спецификация требований к программному обеспечению должна также

определить требования к режиму выполнения таких тестирований.


должна содержать ограничения, которые должны быть учтены в проекте ПО

и при внедрении программного обеспечения, чтобы обеспечить корректность

и работоспособность.

Например, в спецификацию требований к программному обеспечению

могут входить ограничения:

направленные на обеспечение уверенности в правильности

программного обеспечения и проекта системы (например, пределы,

устанавливаемые при использовании динамически размещенных ресурсов,

таких как память, вычислительная мощность, полоса пропускания канала

связи, ресурсы операционной системы);

51


направленные на увеличение устойчивости ПО и СКУ к дефектам,

способности программного обеспечения обнаруживать ошибки и отказы и

оповещать о них, работать в указанных режимах и восстанавливаться после

отказов;

направленные на обеспечение уверенности в том, что ошибки

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

программное обеспечение взаимодействует или использует общие ресурсы,

не будут приводить к недопустимым результатам.


должна содержать ожидания, которые должны быть учтены в рамках проекта

ПО и внедрения программного обеспечения, чтобы обеспечить корректность

и работоспособность.


должна определить задачи программного обеспечения по своевременному

информированию операторов об ошибках или отказах, касающихся функций

СКУ, определенных в качестве важных для безопасности. Информация,

предоставляемая операторам, должна позволить им предпринимать любое

необходимое действие.


должна определять функции и требования, связанные с категорией

безопасности С или В.

6.4.5 Свойства

6.4.5.1 Для класса 2, языки, правила и документы, используемые для

разработки спецификации требований к программному обеспечению,

должны способствовать ее ясности и четкости, и их следует выбирать с

учетом использования этих объектов в соответствии с исходной

информацией, а также при проектировании и реализации нового


Так как конкретный формат спецификации не всегда обеспечивает

ясное, четкое и проверяемое выражение всего того, что требует определения,

52


в одной и той же спецификации требований к программному обеспечению

могут быть использованы различные и дополняющие друг друга форматы;

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

форматы, отличные от используемых для других функций.

6.4.5.2 Для класса 2, требования спецификации должны быть

выражены таким способом, чтобы их соблюдение могло быть объективно

оценено.

6.5 Проект программного обеспечения

6.5.1 Цели

6.5.1.1 Проект программного обеспечения должен быть оформлен


Соответствующий документ или пакет документов именуется

спецификацией проекта программного обеспечения. Если используется ранее

разработанное программное обеспечение, то в спецификации проекта

программного обеспечения может быть дана ссылка на соответствующий

документ.

6.5.1.2 Спецификация проекта ПО должна содержать обзор

организации и функционирования программного обеспечения (см. также

6.5.3.3).

6.5.1.3 Для класса 2, спецификация проекта программного

обеспечения должна способствовать достижению уверенности в качестве

проекта программного обеспечения и его корректности относительно

спецификации требований к программному обеспечению.

6.5.1.4 Спецификация проекта программного обеспечения должна

обеспечить свидетельство о том, что положения спецификации требований к

программному обеспечению, важному для безопасности, приняты во

внимание и будут соблюдаться при всех указанных в ней условиях.

6.5.1.5 Для класса 2, в спецификации проекта программного

обеспечения следует в документальной форме представлять меры,

53

ГОСТ Р МЭК 62138(Проект, редакция 1)гарантирующие раннее обнаружение любой ошибки или отказ программного

обеспечения и ее (его) нераспространение за установленные пределы. В

спецификации проекта программного обеспечения следует также

документально представлять действия, предпринимаемые при обнаружении

ошибки или отказа.


обеспечивать (в случае необходимости) устранение неблагоприятных

побочных эффектов, связанных с ошибками и отказами программного

обеспечения до его возвращения к нормальному режиму работы.


быть направлена на реализацию модулярности, возможности проводить

тестирования и техническое обслуживание.

6.5.1.8 Для класса 2, если это не приводит к чрезмерной сложности,

проект программного обеспечения СКУ должен облегчать:

анализ и тестирование программного обеспечения и его

компонентов;

локализацию дефектов;

идентификацию результатов модификации.


служить основой для реализации и интеграции программного обеспечения, а

также для возможных его модификаций.

6.5.2 Исходные данные

6.5.2.1 Исходные данные для процесса проектирования

программного обеспечения должны включать в себя спецификацию

требований к программному обеспечению и документацию по безопасности

на ранее разработанное программное обеспечение.

Исходные данные могут также включить в себя другие документы,

такие, например, как специфичные проектные ограничения и/или

применимые правила и стандарты.

6.5.3 Содержание

54



включать в себя спецификацию по:

полной организации программного обеспечения;

полному функционированию программного обеспечения при

условиях и режимах работы в соответствии со спецификацией требований к

программному обеспечению.

6.5.3.2 Полная организация программного обеспечения должна

обеспечить информацию:

о четкой идентификации и конфигурации ранее разработанного


о распределении ресурсов, компонентов и задач программного

обеспечения по подсистемам;

о распределении (под)функций и характеристик программного

обеспечения по определенным для него задачам;

об основных внутренних взаимосвязях, в частности, взаимосвязях

между задачами программного обеспечения.

6.5.3.3 Полное функционирование должно обеспечивать

информацию:

о взаимодействиях, протоколах связи и информационных потоках;

об установлении последовательностей и временных ограничений;

об использовании ресурсов;

о синхронизации, особенно при использовании разделенных

ресурсов.


обеспечения должен быть документально отражен порядок соблюдения

важных для безопасности требований к программному обеспечению при всех

заданных условиях. При использовании ранее разработанного программного

обеспечения подтверждение важных для безопасности свойств программного

обеспечения должно основываться на прогнозной информации,

55

ГОСТ Р МЭК 62138(Проект, редакция 1)содержащейся в соответствующей документации по безопасности (см.

6.3.2.2.5).


обеспечения и в документации по проектированию системы должны быть

установлены и обоснованы меры, предпринимаемые для уменьшения

влияния известных и ожидаемых режимов отказов любого ранее

разработанного программного обеспечения, для которых использованы

дополнительные меры по подтверждению корректности (см. 6.3.3).


обеспечения должны быть установлены правила реализации программного


6.5.3.7 Для класса 2, в частности, должны быть установлены правила

конфигурирования и использования ранее разработанного программного

обеспечения с тем, чтобы обеспечить использование этого программного

обеспечения контролируемым образом, согласующимся с соответствующей

документацией по безопасности.

6.5.3.8 Для класса 2, спецификация проекта программного

обеспечения должна включать в себя детальный проект любого нового

программного обеспечения, реализованного на универсальном языке.

6.5.3.9 В спецификации компонента такого программного

обеспечения следует указывать:

функции, обеспечиваемые компонентами с их взаимосвязями,

ролями, типами, форматами, диапазонами и ограничениями для входов и

выходов сигналов об аномальном состоянии, данных конфигурации;

рабочие характеристики, например, время отклика, точность (если

это необходимо);

требования компонентов к их окружению, например, потребность в

динамически распределяемой памяти, ресурсам операционной системы и т.п.

(если это необходимо);

56


любая другая информация, о которой пользователи компонента

должны быть осведомлены;

любые важные ограничения по реализации.


обеспечения должна содержаться информация, с помощью которой

возможно построить корректные прогнозы по поводу ключевых элементов

для безопасной работы системы, включая, в частности, максимальное время

отклика и максимальное использование ресурсов.

Данная информация может быть представлена в форме данных, формул

и/или моделей, которые возможно использовать для расчета наихудшего

времени отклика и использования ресурсов приложений.

6.5.4 Свойства


обеспечения должен быть четко и ясно представлен проект программного



обеспечения должен быть четко и ясно представлен проект программного


Касательно 6.5.4.1 и 6.5.4.2, основной подход может базироваться на

принципе «сверху-вниз», но некоторые документы могут также содержать

информацию, которая обращает внимание на особо важные аспекты

(например, устойчивость к отказам), учитываемые во всем программном

обеспечении или СКУ.

6.5.4.3 Для класса 2, формат и синтаксис, используемые в

спецификации проекта, должны способствовать этой четкости и ясности.

6.6 Реализация нового программного обеспечения

6.6.1 Общие требования


Требования настоящего пункта применимы ко всему новому

57

ГОСТ Р МЭК 62138(Проект, редакция 1)программному обеспечению, т.е. к конфигурации ранее разработанного

программного обеспечения и программам, написанным на проблемно-

ориентированных или универсальных языках.

6.6.1.2 Использование ранее разработанного программного

обеспечения должно быть верифицировано на соответствие документации по

безопасности и ограничениям, установленным спецификацией проекта


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

рабочую программу, должны быть оформлены документально и

верифицированы.

В процедурах обычно описывается каким образом должен быть

задействован набор инструментальных средств компиляции или генератор

кода для трансляции новых программ в рабочую программу. Они часто

являются автоматизированными.

6.6.1.4 Для класса 2, обновление рабочей программы после внесения

изменений в программы должно быть выполнено, по возможности,

автоматизированными средствами.

6.6.2 Конфигурация программного обеспечения и устройств,

содержащих программное обеспечение


Требование настоящего пункта является специфичным для

конфигурации настраиваемого программного обеспечения. Такое

программное обеспечение может быть ранее разработанным или новым. Тем

не менее, если данные конфигурации представляют собой выполняемую

программным обеспечением или системой обработку (т.е. когда они

фактически являются программой), то применяют требования 6.6.3

6.6.2.2 Конфигурация настраиваемого программного обеспечения и

устройств с встроенным программным обеспечением должна быть

оформлена документально.

6.6.3 Реализация с помощью проблемно-ориентированных

58


языков


Требования настоящего пункта являются специфичными для программ,

написанных на проблемно-ориентированных языках. В общем случае для

отражения всей или части спецификации требований к программному

обеспечению или спецификации проекта программного обеспечения могут

использоваться проблемно-ориентированные форматы (такие как логические

диаграммы или блок-схемы функций). Затем необходимы только

ограниченный детальный проект и некоторые усилия по реализации для

преобразования спецификации в программы, которые могут быть

автоматически транслированы в рабочую программу.

6.6.3.2 Части спецификации требований к программному

обеспечению и/или спецификации проекта программного обеспечения,

которые используются для получения рабочей программы с помощью

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

написанные на проблемно-ориентированных языках.

6.6.3.3 Для класса 2, программы, написанные на проблемно-

ориентированных языках, должны быть верифицированы на предмет

функциональной корректности и согласованности. Верификация должна

подтверждать, что:

все особенности проекта полностью поняты (т.е. не будет

неожиданного режима работы при всех указанных условиях);

указанный режим работы согласуется с целями, установленными

спецификацией требований к программному обеспечению.

Для улучшения понимания спецификаций и верификации их

функциональной корректности и согласованности могут быть применены

анимация, тестирования, проверка, сквозной контроль, формальный анализ и

доказательство.

6.6.3.4 Для класса 3, программы, написанные на проблемно-

59

ГОСТ Р МЭК 62138(Проект, редакция 1)ориентированных языках и относящиеся к функциям, важным для

безопасности, должны быть верифицированы на предмет функциональной

корректности и согласованности.

6.6.3.5 Должно быть разработано тестирование, в рамках которого

бы учитывались не только требования к внутренней структуре объекта, но и

к функциям объекта, подлежащего тестированию.

6.6.3.6 Для класса 2, диапазон функций должен быть определен до

проведения тестирования, чтобы подтвердить, что объект соответствует всем

необходимым требованиям к его поведению.

6.6.3.7 Для класса 2, в ходе тестирования необходимо

проконтролировать полученные структурные показатели в отношении

обоснованных критериев (например, утверждение, условие, переход, поток

данных), чтобы убедиться в отсутствии нежелательного поведения. Если эти

критерии не выполняются, то должно быть приведено обоснование.

6.6.3.8 Для класса 2, написанные на проблемно-ориентированных

языках программы должны соответствовать документально оформленным

правилам, разработанным для улучшения их ясности, модифицируемости и

проверяемости. Несоответствия должны быть обоснованы.

Набор правил может быть специфичным для языка или пакета

программ. Невысокая сложность, ясность и стандартные расположение и

представление, модульность, наличие необходимых комментариев,

отсутствие небезопасных особенностей языка и его инструментов - вот

примеры свойств, которые в общем случае облегчают понимание, проверку,

тестирование и последующую модификацию программ.

6.6.4 Реализация с помощью универсальных языков


Требование настоящего пункта является специфичным для программ,

написанных на универсальных языках.

6.6.4.2 Для класса 2, документально оформленная верификация

должна обеспечивать обоснование того, что программы, написанные на

60


универсальных языках, соответствуют их спецификации, как это определено

спецификацией проекта программного обеспечения.

Верификация может состоять из комбинации визуального анализа,

анализа с помощью инструментальных программ и/или тестирований.

Проверки программы, сквозной контроль, контрольные таблицы и

другие подобные методы часто являются мощными методами анализа,

которыми можно пользоваться для выявления дефектов программного


Анализы с помощью инструментальных программ могут проводиться

для формального доказательства того, что программа имеет (или не имеет)

заданные свойства. Например, анализы могут обеспечить уверенность в том,

что при данных условиях (например, при условии нахождения исходных

данных в пределах заданных диапазонов) программы или определенные

части программы не содержат дефектов определенного вида (например,

неинициализированных переменных, арифметического переполнения или

исчезновения значащих разрядов).

Тестирования могут быть выполнены на основном компьютере или с

помощью средств поддержки программных разработок.

6.6.4.3 Для класса 2, в документации по верификации должны

фиксироваться:

идентичность и версия проверяемых программ;

информация, необходимая для повторения верификации в

аналогичных условиях;

принятые гипотезы и обоснование их справедливости;

полученные результаты и подтверждение их корректности;

выводы и согласованные решения (в случае выявления ошибок);

обоснование соответствия критериям достаточности.

6.6.4.4 Должно быть разработано тестирование, в рамках которого

бы учитывались не только требования к внутренней структуре объекта, но и

61

ГОСТ Р МЭК 62138(Проект, редакция 1)к функциям объекта, подлежащего тестированию.

6.6.4.5 Для класса 2, диапазон функций должен быть определен до

проведения тестирования, чтобы подтвердить, что объект соответствует всем

необходимым требованиям к его поведению.

6.6.4.6 Для класса 2, в ходе тестирования необходимо

проконтролировать полученные структурные показатели в отношении

обоснованных критериев (например, утверждение, условие, переход, поток

данных), чтобы убедиться в отсутствии нежелательного поведения. Если эти

критерии не выполняются, то должно быть приведено обоснование.

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

соответствовать оформленным документально правилам, обеспечивающим

четкость, возможность модификации и тестируемость.

Набор правил может быть специфичным для языка или пакета

программ. Невысокая сложность, структурное программирование,

модульность, инкапсуляция, скрытая информация (для того, чтобы

пользователи программного продукта имели дело лишь с предоставляемым

им сервисом, но не с внутренней работой продукта), наличие

соответствующих комментариев, отсутствие опасных особенностей языка и

его инструментов являются примерами свойств, которые могут облегчить

понимание, верификацию, тестирование и последующую модификацию


6.6.4.8 Для класса 2, правила программирования следует выражать

так, чтобы их можно было верифицировать, и они должны быть нацелены на

раннее обнаружение и ограничение ошибок в программном обеспечении.

6.6.4.9 Для класса 2, если могут использоваться инструменты

статического анализа сложности кода, то правила должны устанавливать

допустимые метрические пределы.

6.6.4.10 Для класса 2, программы, написанные на универсальных

языках, должны быть верифицированы на соответствие применяемым

правилам и стандартам. Несоответствия должны быть обоснованы и должны

62


быть предприняты, документально оформлены и, при необходимости,

обоснованы соответствующие контрмеры.

Контрмеры в случае несоответствия могут представлять собой,

например, более полную верификацию.

6.7 Программные аспекты интеграции системы


Интеграция программного обеспечения рассматривается как часть

интеграции системы. Настоящий подраздел дополняет пункты 6.2.5, 6.3.4 и

6.4.5 МЭК 61513:2011, устанавливая дополнительные требования,

специфичные или особенно важные для программного обеспечения.

6.7.2 Интеграция программного обеспечения и/или его анализ

должны показать, что интегрированные система и программное обеспечение:

соответствуют тем положениям проекта, которые обеспечивают

выполнение указаний спецификации требований к программному

обеспечению, определенных в качестве важных для безопасности;

соответствуют ограничениям, изложенным в спецификации

требований к программному обеспечению, касающимся корректности и

работоспособности.

6.7.3 Для класса 2, если валидационные тестирования программного

обеспечения полагаются недостаточными для проверки программы, то

необходимая уверенность в правильности работы должна быть обеспечена

дополнительными интеграционными тестированиями программного

обеспечения либо более полной верификацией.

6.7.4 Интеграция программного обеспечения должна быть выполнена

согласно положениям плана интеграции системы или плана интеграции


6.7.5 Должны быть составлены отчеты по результатам выполнения

плана, используемого для интеграции программного обеспечения, например,

по результатам тестирований. В случае необходимости проведения

63

ГОСТ Р МЭК 62138(Проект, редакция 1)модификации программного обеспечения или системы должна быть

возможность повторения всех или части интеграционных тестирований для

оценки степени возможных изменений в работе программы.

6.7.6 Для класса 2, необходимо обеспечить согласованность

спецификации проекта ПО и соответствующего интеграционного

тестирования.

6.7.7 Для класса 3, необходимо обеспечить согласованность

спецификации проекта ПО и соответствующего интеграционного

тестирования.

6.8 Программные аспекты валидации системы


Во время валидации системы проводится тестирование аспектов ПО.

Настоящий подраздел дополняет пункты 6.2.6, 6.3.5 и 6.4.6 МЭК 61513:2011,

устанавливая дополнительные требования, специфичные или особенно

важные для программного обеспечения. В случае выявления несоответствий,

процесс валидации может быть продолжен с указанием обоснований, или

остановлен для устранения несоответствий перед проведением повторной

валидации.

6.8.2 Для класса 2, валидация программного обеспечения должна

показать, что интегрированное в завершенную систему СКУ, программное

обеспечение соответствует каждому из положений спецификации требований

к программному обеспечению, касающихся функциональности,

характеристик и интерфейса, и по своему назначению способствует

соответствию спецификации требований к системе. При этом должно быть

включено обоснование того, что:

установленные функции программного обеспечения правильно

выполняются, если их аргументы и исходные данные находятся в

диапазонах, указанных в спецификации требований к программному

обеспечению, а условия применения соответствуют указанным в этой

спецификации;

64


функции системы, реализация которых осуществляется с помощью

программного обеспечения, выполняются правильно в условиях применения,

определенных в спецификации требований к системе;

программное обеспечение обеспечивает защиту от ошибок

операторов и отказов других систем и оборудования в соответствии со

спецификацией требований к программному обеспечению;

функции ПО реализуются соответствующим образом в различных

режимах эксплуатации;

технические данные станции, используемые СКУ или

интегрированные в нее, являются правильными; в частности, валидация

программного обеспечения должна показать, что эти данные правильно

описывают системы и оборудование станции, с которыми программное

обеспечение взаимодействует или разделяет ресурсы и правильно

обращается к этим системам и оборудованию;

система должным образом обеспечивает защиту от ошибок

операторов и отказов других систем и оборудования.

Валидационное тестирование обычно проводится для ПО,

интегрированного в целевую СКУ. Если представлено соответствующее

обоснование, то при валидации допускается использовать техническое

обеспечение на платформе, идентичной штатной.

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

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

в частности, эксплуатацию при высокой коммуникационной нагрузке.

6.8.3 Для класса 3, в ходе валидации ПО должно быть

продемонстрировано, что программное обеспечение, интегрированное в

целевую СКУ, соответствует требованиям к функциям, работоспособности и

интерфейсам, важным для безопасности. При этом должно быть включено

обоснование того, что:

соответствующие функции ПО, важные для безопасности,

65

ГОСТ Р МЭК 62138(Проект, редакция 1)реализуются должным образом, когда их параметры и входы находятся в

пределах и условиях применения, определенных в спецификации требований

к программному обеспечению;

важные для безопасности функции системы, которые связаны с ПО,

реализуются должным образом в условиях применения согласно

спецификации требований к системе;

ПО обеспечивает защиту от ошибок операторов и отказов других

систем и оборудования, которая установлена в спецификации требований к

программному обеспечению;

функции ПО реализуются соответствующим образом в различных

режимах эксплуатации;

технические данные станции, используемые СКУ или

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

являются правильными; в частности, валидация программного обеспечения

должна показать, что эти данные правильно описывают системы и

оборудование станции, с которыми программное обеспечение

взаимодействует или разделяет ресурсы и правильно обращается к этим

системам и оборудованию.

Валидационное тестирование обычно проводится для ПО,

интегрированного в целевую СКУ. Если представлено соответствующее

обоснование, то при валидации допускается использовать техническое

обеспечение на платформе, идентичной штатной.

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

включать в себя работу функций при высокой коммуникационной нагрузке.

6.8.4 Валидация программного обеспечения должна быть выполнена в

соответствии с положениями плана валидации системы или ПО.

6.8.5 Для класса 2, план валидации программного обеспечения должен

устанавливать необходимые действия по валидации, а также показать, что

все указания спецификации требований к программному обеспечению,

касающиеся функциональности, характеристик и интерфейса, правильно

66


учтены при выполнении этих действий. В плане также должны быть

установлены основные этапы валидации программного обеспечения

(например, этап до размещения на штатное место, за которым следует этап

функционирования на штатном месте) и соответствующие средства, методы

и инструменты, которые при этом должны быть использованы.

6.8.6 Для класса 2, план валидации ПО должен обеспечивать

соответствие спецификации требований к программному обеспечению и

валидационных мероприятий.

6.8.7 Для класса 3, план валидации программного обеспечения должен

устанавливать необходимые действия по валидации, а также показать, что

все указания спецификации требований к программному обеспечению,

касающиеся функциональности, характеристик и интерфейса, правильно

учтены при выполнении этих действий. В плане также должны быть

установлены основные этапы валидации программного обеспечения

(например, этап до размещения на штатное место, за которым следует этап

функционирования на штатном месте) и соответствующие средства, методы

и инструменты, которые при этом должны быть использованы.

6.8.8 Для класса 3, план валидации ПО должен обеспечивать

соответствие спецификации требований к программному обеспечению и

валидационных мероприятий.

6.8.9 Должны быть составлены отчеты по результатам выполнения

плана, используемого при валидации программного обеспечения. В случае

необходимости проведения модификаций программного обеспечения или

системы должна быть возможность повторения всех или части

валидационных тестирований для оценки степени возможных изменений в

работе.

6.8.10Для класса 2, результаты валидации программного обеспечения

должны быть понятны лицам, компетентным в данной области, но не

участвовавшим непосредственно в процессе валидации.

67


6.8.11Для класса 3, результаты валидации программного обеспечения

должны быть понятны лицам, компетентным в данной области, но не

участвовавшим непосредственно в процессе валидации.

6.8.12В отчетах должны быть документально оформлены

конфигурация программного обеспечения и конфигурация окружающей

среды при проведении валидации, например, техническое обеспечение,

инструментальные программы (если использовались).

6.8.13 Группа, которая составляет план валидации программного

обеспечения, должна включать в себя, по крайней мере, одного человека, не

участвовавшего в разработке проекта и его реализации.

6.9 Инсталляция программного обеспечения на штатном месте


Пункт 6.2.7 МЭК 61513:2011 содержит требования к установке СКУ на

штатном месте. В настоящем подразделе приводятся дополнительные

требования, специфичные или особо важные для программного обеспечения.

6.9.2 Процедура инсталляции программного обеспечения на штатном

месте должна быть оформлена документально. Процедура должна

обеспечивать гарантированную инсталляцию правильной и полной версии


6.9.3 В процедуру инсталляции программного обеспечения на штатном

месте должны быть включены и детально описаны проверки и тестирования

на штатном месте, которые должны выполняться до начала

полномасштабной эксплуатации СКУ. В частности, должно быть

верифицировано выполнение условий, необходимых для правильной работы


Например, эти условия могут касаться средств технического

обеспечения, на которых установлено программное обеспечение, или других

систем, с которыми программное обеспечение взаимодействует или

разделяет ресурсы.

6.10 Протоколы отклонений от нормы

68


6.10.1 Если обнаружена неожиданная, очевидно неправильная,

необъяснимая или ненормальная работа программы после ее принятия в

эксплуатацию, то должен быть составлен протокол отклонения от нормы

работы программы.

6.10.2 В протоколе отклонения от нормы работы программы следует

указать подробности работы программы, конфигурацию программного

обеспечения и технического обеспечения и управляющих действий во время

анормальной работы. В протоколе также следует указать его обозначение,

составителя, а также место и дату составления.

6.10.3 Протоколы отклонения от нормы подвергают анализу.

Возникшие проблемы оформляют документально, отслеживают и решают.

6.10.4 Информация об отклонениях от нормы должна быть передана

разработчику и пользователям.

6.11 Модификация программного обеспечения


Решение о проведении модификаций программного обеспечения

зависит от его влияния на СКУ, поэтому такие решения подчинены

требованиям 6.2.8 и 6.4.7 МЭК 61513:2011. В данном подразделе

предусмотрены дополнительные требования, специфичные или особенно

важные для программного обеспечения.

6.11.2 Модификации программного обеспечения должны

разрабатываться и верифицироваться в соответствии с требованиями 6.2, 6.3,

6.4, 6.5 и 6.6. Они должны инсталлироваться в штатную аппаратуру в

соответствии с требованиями 6.9.

6.11.3 Интеграцию и валидацию модификаций программного

обеспечения следует проводить в соответствии с 6.7 и 6.8.

6.11.4 Если объем модификации не требует соблюдения требований

6.7 и 6.8 в полном объеме, интеграция модифицированного программного

обеспечения должна проводиться согласно регрессивному плану интеграции

69

ГОСТ Р МЭК 62138(Проект, редакция 1)программного обеспечения, а валидация - регрессивному плану валидации

программного обеспечения. Полнота и подробность этих планов должны

быть обоснованы с учетом объема каждой из модификаций, осуществленных

в спецификации требований к программному обеспечению и спецификации

проекта программного обеспечения. Должны быть составлены отчеты по

результатам реализации этих планов.

6.11.5 Для класса 2, если используется регрессивный подход, то

регрессивный план интеграции программного обеспечения и регрессивный

план валидации программного обеспечения должны обеспечить достаточную

уверенность в том, что модифицированное программное обеспечение

полностью соответствует новой спецификации требований к программному

обеспечению, а также, что:

цели модификации достигнуты;

ошибки не внесены;

модифицированное и/или вводимое ранее разработанное

программное обеспечение работает в соответствии с документацией по

безопасности и так, как того требует измененная спецификация проекта


другие модифицированные и/или новые компоненты программного

обеспечения соответствуют их спецификации.

6.11.6 Модификации программного обеспечения должны быть

оформлены документально в полном объеме. В частности, все связанные с

программным обеспечением документы, на которые повлияли модификации,

должны быть обновлены.

6.11.7 В документации по модификации программного обеспечения

следует указывать:

цели модификации программного обеспечения, включая любые

цели на уровне системы;

компоненты программного обеспечения, которые затрагиваются

или вновь создаются в процессе модификации;

70


идентификацию версий этих компонентов до и после модификации.

Цели модификации на уровне системы документируются в

соответствии с требованиями МЭК 61513:2011 (п. 6.4.7).

6.11.8 Для класса 2, в дополнение к информации, указанной выше, в

документации по модификации программного обеспечения следует

указывать:

любые изменения, произведенные в его спецификации;

любые ограничения, которые должны соблюдаться при выполнении

модификации;

ссылки на модифицированный проект и/или документы по

реализации.

6.11.9 Для класса 2, степень подробности документации по

модификации программного обеспечения должна быть такой, чтобы:

она обеспечивала уверенность в правильности измененного

программного обеспечения и СКУ;

могло быть подтверждено соответствие СКУ соответствующим

требованиям МЭК 61513:2011.

Соответствующие требования МЭК 61513:2011 описаны главным

образом в 6.2.2.3, 6.2.2.4, 6.2.2.5, 6.2.3.3, 6.2.3.5 и 6.2.4.

6.11.10 Должна быть проведена оценка влияния модификации

программного обеспечения на остальные части СКУ и другие системы, с

которыми программное обеспечение взаимодействует или разделяет ресурсы.

Все необходимые меры должны быть предприняты для обеспечения

правильной работы СКУ.

6.11.11 Должны быть оценены влияния на программное обеспечение

модификаций в остальной части СКУ или других системах, с которыми

программное обеспечение взаимодействует или делит ресурсы. Должны быть

предприняты все необходимые меры для обеспечения правильной работы

СКУ.

71


6.12 Обеспечение защиты от отказов по общей причине, которые

возникли вследствие программного обеспечения

Из-за ошибок в процессе разработки или внедрения могут возникать

систематические отказы. К таким отказам могут приводить ошибки

персонала или недоработки в рамках спецификации требований к системе/

ПО, либо ошибки и недоработки, которые произошли позже во время

разработки и внедрения ПО (как в разрабатываемой части, так и в

интегрированном уже существующем проекте). К систематическим сбоям

могут также приводить инструментальные программы, когда они также

работают со систематическими сбоями, которые возникли в процессе

разработки и внедрения. Таким образом, ПО может быть потенциально

подвержено скрытым систематическим сбоям, которые при определенных

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

ПО.

Информация по поводу потенциального возникновения ООП на уровне

системы содержится в стандартах ПК 45A более высокого уровня, а именно:

МЭК 61513:2011 5.4.2.6, в котором описана защита от ООП;

МЭК 61513:2011 5.4.4.2, в котором описана оценка надежности и

защиты от ООП.

В настоящем стандарте описываются процессы разработки и

верификации, а также требования, которые минимизируют потенциальные

систематические сбои ПО и, поскольку данные сбои могут приводить к ООП,

которые минимизируют возможные ООП, возникающие вследствие


72


73


Приложение А

(справочное)

Стандартный перечень документации на программное обеспечение

В таблице A.1 указан стандартный перечень документации на

программное обеспечение.

Т а б л и ц а А.1 Стандартный перечень документации на программное

обеспечениеСсылки на подразделы данного стандарта Номер раздела

Документы, которые относятся к изготовлению программного обеспечения

План обеспечения качества ПО* 6.2.1План верификации ПО 6.2.2План управления конфигурацией ПО* 6.2.3Документация по безопасности предварительно разработанного программного обеспечения

6.3

Спецификация требований к программному обеспечению 6.4Спецификация на разработку программного обеспечения 6.5Правила программирования 6.6.3.8, 6.6.4.7Отчет о верификации ПО 6.2.2, 6.6.3, 6.6.4План интеграции ПО* 6.7Отчет об интеграции ПО* 6.7План валидации ПО* 6.8Отчет о валидации ПО* 6.8Процедура установки ПО на штатном месте* 6.9Документы, которые относятся к отклонениям от нормы

Отчет об отклонениях от нормы 6.10Документы, которые относятся к модификации ПО

Документация по модификации ПО 6.11Регрессивный план интеграции программного обеспечения** 6.11Регрессивный отчет интеграции программного обеспечения** 6.11Регрессивный план валидации программного обеспечения** 6.11Регрессивный отчет валидации программного обеспечения** 6.11* Данные документы можно не предоставлять, если их содержание включено в документацию системы,

например, в план обеспечения качества системы, план управления конфигурацией системы, план интеграции системы, отчет об интеграции системы, план валидации системы, отчет о валидации системы, либо в процедуру по установке системы на штатном месте.

** Когда для данного объема модификации не требуется полного соответствия требованиям подразделов 6.7 и 6.8. Требования подразделов 6.2, 6.3, 6.4, 6.5, 6.6 и 6.9 всегда применяются к модификациям ПО и, следовательно, документы, относящиеся к данным подразделам, должны быть всегда в актуальном состоянии и отражать любые модификации.

74


Приложение B


Соотношение данного стандарта и МЭК 61513:2011

В таблице В.1 представлено соотношение данного стандарта и МЭК

61513:2011.

Т а б л и ц а B.1 Соотношение данного стандарта и МЭК 61513:2011Подразделы МЭК 61513:2011 Подразделы данного

стандарта5.4.2.5 Инструментальные программы 6.2.45.4.2.6 Защита от ООП 6.125.4.4.2 Оценка надежности и защиты от ООП5.6.2 Документация по проекту архитектуры 6.2.46 Жизненный цикл безопасности системы, рис. 5 5.46.2.2.3.3 Внутреннее поведение системы 6.3.2, 6.56.2.2.7 Квалификация 6.2.46.2.3.2 Выбор уже существующих компонентов 6.36.2.3.4 Спецификация программного обеспечения 6.46.2.4 Подробный проект системы и ее внедрение 6.5, 6.66.2.5 Интеграция системы 6.76.2.6 Валидация системы 6.86.2.7 Установка системы 6.96.2.8 Модификация проекта системы 6.116.3.2 План обеспечения качества системы 6.2.16.3.2.3 План управления конфигурацией системы 6.2.36.3.4 План по интеграции системы 6.76.3.5 План валидации системы 6.86.4.4 Подробная документация на разработку системы 6.5, 6.66.4.5 Документация по интеграции системы 6.76.4.6 Документация по валидации системы 6.86.4.7 Документация по модификации системы 6.116.5.3.3 Оценка программного обеспечения Все8.2 Требования к целям Все

75


Приложение С


Взаимосвязь данного стандарта и МЭК 61508

С.1 Общие положения

В данном приложении описана взаимосвязь между настоящим

стандартом и МЭК 61508-3:2010.

На системном уровне в МЭК 61513:2011 (Приложение D) указано

соотношение с МЭК 61508-1:2010, МЭК 61508-2:2010 и МЭК 61508-4:2010.

С.2 Сравнение содержания и концепций

МЭК 61508 в целом, относится к системам, связанным с

безопасностью, тогда как данный стандарт учитывает практику МАГАТЭ и

относится к системам, важным для безопасности (т.е. важным для ядерной

безопасности).

В МЭК 61508 описана оценка уровня интеграции безопасности,

который требуется для компьютерных систем, чтобы соответствующим

образом снижать риски. Для этого определяется степень влияния риска,

связанного с опасностью, оценивается частота и последствия опасности, а

также защита, которую должна обеспечить система для снижения риска

возникновения опасности до приемлемого уровня.

Как правило, в атомной энергетике традиционно используется

детерминистский метод, чтобы определить степень значимости системы для

безопасности, а также ее влияние на риск, который может привести к

прекращению деятельности.

В МЭК 61508 содержится требование об оценке функциональной

безопасности со стороны независимых лиц и организаций, опыт и

независимость которых увеличивается с увеличением SIL (см. часть 1).

В рамках атомной отрасли, операторы станции (которые прежде всего

несут ответственность за обеспечение ядерной безопасности) главным

образом отвечают за проведение соответствующей оценки функциональной

76


безопасности, однако данный процесс часто регулируется национальными

нормами в области атомной энергетики.

С.3 Соотношение данного стандарта и МЭК 61508-3:2010

Т а б л и ц а С.1 – Соотношение данного стандарта и МЭК 61508-3:2010МЭК 62138 МЭК 61508-3:2010

5.4 Жизненные циклы безопасности ПО и системы

7.1 Общие положения

6.2.1 Жизненный цикл безопасности программного обеспечения. Обеспечение качества программного обеспечения

6.2.2 Верификация 7.9 Верификация ПО6.2.3 Управление конфигурацией 6.2.3 Управление конфигурацией ПО6.2.4 Выбор и использование инструментальных

программ7.4.4 Требования к поддерживающим

инструментальным программам, включая языки программирования6.2.5 Выбор языков

6.3 Выбор ранее разработанного программного обеспечения

7.4.2 Общие требования

6.3.2 Документация по безопасности Приложение D (информативное) Руководство по безопасности для соответствующих изделий - дополнительные требования для элементов ПО

6.4 Спецификация требований программного обеспечения

7.2 Спецификация требований к программному обеспечению по безопасности

6.5 Разработка программного обеспечения 7.4 Проект и разработка ПО6.6 Внедрение программного обеспечения

6.7 Программные аспекты интеграции системы 7.5 Интеграция программируемой электроники (техническое и программное обеспечение)

6.8 Программные аспекты валидации системы 7.3 План валидации программных аспектов в области безопасности системы

7.7 Программные аспекты валидации системы в области безопасности

6.9 Инсталляция программного обеспечения на штатном месте

Данные сведения не содержатся в МЭК 61508-3, поскольку они описаны в МЭК 61508-1

6.10 Протоколы отклонений от нормы Данные сведения не содержатся в МЭК 61508-3, поскольку они описаны в МЭК 61508-1

6.11 Модификация программного обеспечения. 7.6 Процедуры эксплуатации и модификации ПО7.8 Модификация программного обеспечения.

6.12 Обеспечение защиты от отказов по общей причине, которые возникли вследствие программного обеспечения

В МЭК 61508-3 содержится информация по поводу защиты от отказов по общей причине, которые возникли вследствие программного обеспечения, в частности Приложения С и F.

77


Продолжение таблицы С.1

В атомном секторе данная оценка связана с процессом лицензирования и зависит от органов, которые занимаются вопросами безопасности, а также национальных норм.

8 Оценка функциональной безопасности

В МЭК 61508-1 содержатся требования к техническим знаниям и независимости лица (лиц), которое (которые) проводит (проводят) оценку, на основе уровня инноваций, технических новшеств и возможных последствий отказов. В дополнение к этому, большая часть организаций, которые проводят оценку по безопасности и сертификацию продуктов, имеют аккредитацию национальных органов.

78


Приложение ДА

(справочное)Сведения о соответствии ссылочных международных стандартов ссылочным национальным стандартам Российской Федерации

Т а б л и ц а ДА.1

Обозначение ссылочногомеждународного стандарта

Степень соответствия

Обозначение и наименованиесоответствующего национального

стандарта

МЭК 60880 IDT ГОСТ Р МЭК 60880-2010 Атомные электростанции. Системы контроля и управления, важные для безопасности. Программное обеспечение компьютерных систем, выполняющих функции категории А

МЭК 61226 IDT ГОСТ Р МЭК 61226-2011 Атомные станции. Системы контроля и управления, важные для безопасности. Классификация функций контроля и управления

МЭК 61513 IDT ГОСТ Р МЭК 61513-2020 Системы контроля и управления, важные для безопасности атомной станции. Общие требования

МЭК 62671 * -

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

** - готовится к изданию.

П р и м е ч а н и е – В настоящей таблице использованы следующие условные обозначения степени соответствия стандартов:

– IDT – идентичные стандарты.

79


80


Библиография[1] МЭК 61508-3:2010

(IEC 61508-3:2010)

Системы электрические/электронные/

программируемые электронные, связанные с

функциональной безопасностью. Часть 3.

Требования к программному обеспечению

(Functional safety of electrical/electronic/

programmable electronic safety-related systems

- Part 3: Software requirements)[2] МЭК 61508-4:2010

(IEC 61508-4:2010)

Системы электрические/электронные/

программируемые электронные, связанные с

функциональной безопасностью. Часть 4.

Определения и сокращения (Functional safety

of electrical/electronic/programmable electronic

safety-related systems - Part 4: Definitions and

abbreviations)[3] МЭК 61511-1-2016

(IEC 61511-1:2016)

Безопасность функциональная. Системы

безопасности приборные для промышленных

процессов. Часть 1. Термины, определения и

технические требования (Functional safety -

Safety instrumented systems for the process

industry sector - Part 1: Framework, definitions,

system, hardware and application programming

requirements)[4] МЭК 62645:2019

(IEC 62645:2019)

Атомные станции. Системы контроля,

управления и электроэнергетические

системы. Требования к кибербезопасности

(Nuclear power plants - Instrumentation, control

and electrical power systems - Cybersecurity

requirements)

81

ГОСТ Р МЭК 62138(Проект, редакция 1)[5] ИСО/МЭК 12207:2008

(ISO/IEC 12207:2008)

Системная и программная инженерия.

Процессы жизненного цикла программных

средств (Systems and software engineering --

Software life cycle processes)[6] ИСО 9001:2015

(ISO 9001:2015)

Системы менеджмента качества. Требования

(Quality management systems -- Requirements)[7] ИСО 90003:2018

(ISO 90003:2018)

Разработка программного обеспечения.

Руководящие указания по применению ISO

9001:2015 к компьютерному программному

обеспечению (Software engineering --

Guidelines for the application of ISO 9001:2015

to computer software)[8] МАГАТЭ SSR-2/1:2016

(IAEA SSR-2/1:2016)

Безопасность АЭС. Проектирование (Safety

of Nuclear Power Plants: Design)[9] МАГАТЭ SSG-39:2016

(IAEA SSG-39:2016)

Проектирование автоматизированных систем

контроля и управления для атомных

электростанций (Design of Instrumentation

and Control Systems for Nuclear Power Plants)[10] Глоссарий по

безопасности МАГАТЭ

(IAEA Safety Glossary)

Терминология, используемая в области

ядерной безопасности и радиационной

защиты, издание 2016 года (Terminology

Used in Nuclear Safety and Radiation

Protection Multilingual 2016 Edition)[11] МАГАТЭ GS-G-

3.5:2009

(IAEA GS-G-3.5:2009)

Система управления для ядерных установок

(The Management System for Nuclear

Installations)[12] IEEE 7-4.3.2:2010

(IEEE 7-4.3.2:2010)

Критерии цифровых устройств в системах

безопасности для атомных электростанций

(Criteria for Digital Computers in Safety

Systems of Nuclear Power Generating Stations)

82


[13] DO-178 ревизия C:2012

(DO-178 revision

C:2012)

Программные аспекты сертификации

бортовых систем и оборудования (Software

Considerations in Airborne Systems and

Equipment Certification)

83


УДК 621.311.3.049.75:006.354 ОКС 27.120.20

Ключевые слова: атомные станции, системы контроля и управления, важные для безопасности, программное обеспечение, оборудование, отказ по общей причине

Руководитель организации-разработчикаАО «РАСУ»

наименование организации

Генеральный директор А.Б. Буткодолжность личная подпись инициалы, фамилия

Руководитель разработки

Начальникуправления И.О. Мищенко

должность личная подпись инициалы, фамилия

Исполнитель Главный эксперт Д.А. Жидковдолжность личная подпись инициалы, фамилия

84

ФЕДЕРАЛЬНОЕ АГЕНТСТВО · Web viewIEC 62671:2013, Nuclear power plants -...

Documents

Transcript of ФЕДЕРАЛЬНОЕ АГЕНТСТВО · Web viewIEC 62671:2013, Nuclear power plants -...