7.4.1.5 Пятой целью требований настоящего подраздела является проверка выполнения требований к безопасности программного обеспечения (в отношении необходимых функций и уровня полноты безопасности программного обеспечения).
7.4.2 Общие требования
7.4.2.1 В зависимости от характера процесса разработки программного обеспечения ответственность за соответствие 7.4 может лежать только на поставщике, только на пользователе или на обеих сторонах. Распределение ответственности должно быть определено во время планирования безопасности (см. раздел 6).
7.4.2.2 В соответствии с требуемым уровнем полноты безопасности выбранный метод проектирования должен обладать характеристиками, которые облегчают:
a) абстракцию, разделение на модули и другие характеристики, контролирующие уровень сложности;
b) выражение:
- выполняемых функций,
- обмена данными между компонентами,
- информации, относящейся к последовательности и времени выполнения,
- ограничений на время выполнения,
- параллельного выполнения,
- структур данных и их свойств,
- проектных предположений и их зависимостей;
c) понимание разработчиками и другими лицами, которые должны иметь дело с проектом;
d) верификацию и оценку соответствия.
Примечание - См. также таблицы А.1 - А.10 (приложение А) и таблицы В.1 - В.10 (приложение В).
7.4.2.3 Тестируемость и способность к безопасной модификации должны быть предусмотрены на этапе проектирования для того, чтобы облегчить реализацию этих характеристик в окончательной версии системы, связанной с безопасностью.
Примечание - Примеры включают в себя эксплуатационные режимы в машиностроении и на обрабатывающих предприятиях.
7.4.2.4 Выбранный метод проектирования должен обладать характеристиками, которые облегчают модификацию программного обеспечения. К числу таких характеристик относят модульность, скрытие информации и инкапсуляцию.
7.4.2.5 Представление проекта должно основываться на нотации, которая является однозначно определенной или ограничена до однозначно определенных свойств.
7.4.2.6 Проект должен минимизировать настолько, насколько это возможно, ту часть программного обеспечения, которая относится к безопасности.
7.4.2.7 Если программное обеспечение должно реализовать функции как относящиеся, так и не относящиеся к безопасности, оно в целом должно рассматриваться как относящееся к безопасности, если только в проекте не продемонстрирована достаточная независимость между этими функциями.
7.4.2.8 Если программное обеспечение должно реализовать функции безопасности, имеющие различный уровень полноты безопасности, то следует считать, что все программное обеспечение имеет наивысший среди этих уровней, если только в проекте не будет продемонстрирована достаточная независимость функций, имеющих различный уровень полноты безопасности. Обоснование независимости должно быть документировано.
Примечание - Уровень полноты безопасности программного обеспечения должен быть не ниже чем уровень полноты функции безопасности, к которой оно относится. Однако уровень полноты безопасности компонента программного обеспечения может быть ниже, чем уровень полноты функции безопасности, к которой он относится, если этот компонент используется в сочетании с другими аппаратными компонентами, такими, что уровень полноты безопасности сочетания компонентов, по меньшей мере, равен уровню полноты безопасности функции безопасности.
7.4.2.9 В той степени, насколько это возможно, проект должен включать функции, выполняющие проверки и все диагностические тесты для того, чтобы обеспечить соблюдение требований к полноте безопасности Е/Е/РЕ системы, связанной с безопасностью (как установлено в МЭК 61508-2).
7.4.2.10 Проект программного обеспечения должен включать соразмерно требуемому уровню полноты безопасности средства самоконтроля потоков управления и потоков данных. При обнаружении ошибки должны быть выполнены соответствующие действия [см. таблицы А.2 и А.4 (приложение А)].
7.4.2.11 Если стандартное или ранее разработанное программное обеспечение должны использоваться как часть проекта [см. таблицы А.3 и А.4 (приложение А)], они должны быть четко идентифицированы. Способность программного обеспечения удовлетворять требованиям спецификации по отношению к безопасности программных систем (см. 7.2) должна быть обоснована. Эта способность должна основываться на данных по удовлетворительной работе в схожем приложении или быть предметом тех же самых процедур верификации и подтверждения соответствия, которые подразумеваются для любого вновь разрабатываемого программного обеспечения. Следует оценить ограничения, связанные с условиями, в которых работало программное обеспечение (например, зависимость от операционной системы и компилятора).
Примечание - Такое обоснование может быть разработано при планировании безопасности (см. раздел 6).
7.4.2.12 Настоящий подраздел (7.4) должен в той мере, насколько это возможно, применяться к данным, включая любой язык генерации данных.
7.4.3 Требования к архитектуре программного обеспечения
Примечания
1 См. также таблицы А.2 (приложение А) и В.7 (приложение В).
2 Архитектура программного обеспечения определяет основные компоненты и подсистемы программного обеспечения, их взаимосвязь, способ реализации необходимых характеристик и, в частности, полноты безопасности. Примеры основных компонентов программного обеспечения включают операционные системы, базы данных, подсистемы ввода и вывода производственных данных, коммуникационные подсистемы, прикладные программы, инструментальные средства программирования и диагностики и т.п.
3 В некоторых отраслях промышленности архитектура программного обеспечения может называться описанием функций или спецификацией функций проекта (хотя эти документы могут также включать вопросы, относящиеся к аппаратным средствам).
4 Для пользовательского прикладного программирования в языках с ограниченной изменчивостью, в частности в языках, используемых в ПЛК (МЭК 61508-6, приложение Е), архитектура определяется поставщиком как стандартная характеристика ПЛК. Однако в рамках настоящего стандарта к поставщику может быть предъявлено требование, гарантировать пользователю соответствие поставляемого продукта требованиям 7.4. Пользователь приспосабливает ПЛК, используя стандартные возможности программирования, например многозвенные логические схемы. Требования 7.4.3 - 7.4.8 сохраняют свою силу. Требование определения и документирования архитектуры может рассматриваться как информация, которую пользователь может использовать при выборе ПЛК (или эквивалентного ему устройства) для приложения.
5 В другом крайнем случае, в некоторых встроенных приложениях, использующих язык с полной изменчивостью, например в машине, управляемой микропроцессором, архитектура должна создаваться поставщиком специально для приложения (или класса приложений). Пользователь обычно не имеет инструментария для программирования. В этих условиях ответственность за обеспечение соответствия 7.4 ложится на поставщика.
6 Имеются системы, попадающие в промежуток между типами, упомянутыми в примечаниях 4 и 5, в таких случаях ответственность за соответствие разделяется между пользователем и поставщиком.
7 С точки зрения безопасности стадия разработки архитектуры программного обеспечения соответствует периоду, когда разрабатывается базовая стратегия безопасности для программного обеспечения.
7.4.3.1 В зависимости от характера разработки программного обеспечения ответственность за соответствие 7.4.3 может лежать только на поставщике, только на разработчике или на обеих сторонах (см. примечания, приведенные выше). Распределение ответственности должно быть документировано во время планирования безопасности (см. раздел 6).
7.4.3.2 Предлагаемый проект архитектуры программного обеспечения должен быть создан поставщиком программного обеспечения и/или разработчиком, описание архитектуры должно быть подробным. Описание должно:
a) содержать выбор и обоснование интегрированного набора методов и мероприятий, которые будут необходимы в течение жизненного цикла модулей безопасности для того, чтобы удовлетворить требования к безопасности программного обеспечения на заданном уровне полноты безопасности (см. 7.2). Эти методы и мероприятия включают стратегию проектирования программного обеспечения для обеспечения устойчивости к отказам (совместимую с аппаратными средствами) и для избежания отказов, в том числе (при необходимости) избыточность и разнообразие;
b) основываться на разделении на компоненты/подсистемы, для каждой из которых должна предоставляться следующая информация:
- являются ли они вновь разработанными, уже существующими или находящимися в частной собственности,
- проводилась ли верификация и если проводилась, то при каких условиях,
- связан ли каждый из этих компонентов/подсистем с безопасностью или нет,
- уровень полноты безопасности для компонента/подсистемы;
c) определять все взаимодействия между программными средствами и аппаратным обеспечением, а также оценивать и детализировать их значение;
d) использовать для представления архитектуры нотацию, которая является однозначно определенной или ограничена до подмножества однозначно определенных характеристик;
e) содержать набор проектных характеристик, которые должны использоваться для поддержания полноты безопасности всех данных. В число таких данных допускается включать входные и выходные производственные данные, коммуникационные данные, данные интерфейса оператора, данные сопровождения и данные, хранящиеся во внутренних базах данных;
f) определять тесты интеграции архитектуры программного обеспечения для того, чтобы обеспечить выполнение спецификации требований к безопасности программного обеспечения на заданном уровне полноты безопасности (см. 7.2).
7.4.3.3 Любые изменения, которые может потребоваться внести в специфицированные требования к Е/Е/РЕ системе, связанной с безопасностью, после использования мероприятий 7.4.3.2 должны быть согласованы с разработчиком Е/Е/РЕ систем и документированы.
Примечание - Итерационное взаимодействие между архитектурой аппаратных средств и программного обеспечения является неизбежным (см. рисунок 5), поэтому существует необходимость в обсуждении с разработчиком аппаратуры таких вопросов, как спецификация тестирования интеграции программируемой электронной аппаратуры и программного обеспечения (см. 7.5).
7.4.4 Требования к инструментальным средствам поддержки и языкам программирования
Примечания
1 См. также таблицу А.3 (приложение А).
2 Выбор инструментов для разработки зависит от характера процессов разработки программного обеспечения и его архитектуры (см. 7.4.3).
Если пользовательское прикладное программирование выполняется на языке с ограниченной варьируемостью при низких уровнях полноты безопасности, то круг необходимых инструментов и языков программирования может быть ограничен стандартными языками ПЛК, редакторами и загрузчиками. Ответственность за соответствие 7.4.4 будет лежать, следовательно, главным образом на поставщике.
При более высоких уровнях полноты безопасности могут потребоваться ограниченные подмножества языка ПЛК, а также средства верификации и отладки, такие как анализаторы кода и имитаторы. В этих условиях ответственность лежит и на поставщике, и на пользователе.
Инструментарий для встраиваемых приложений, использующий языки с полной варьируемостью, должен быть более разнообразным даже в случае низких уровней полноты безопасности. Ответственность за соответствие 7.4.4 будет лежать, главным образом, на разработчиках программного обеспечения. В их число входит поставщик ПЛК, который может использовать языки с полной варьируемостью в языке с низким уровнем варьируемости для обеспечения пользовательского прикладного программирования.
7.4.4.1 В зависимости от характера программного обеспечения ответственность за соответствие 7.4.4 может лежать только на поставщике, только на пользователе или на обеих сторонах (см. 7.4.4, примечание 2). Разделение ответственности должно быть документировано во время планирования безопасности (см. раздел 6).
7.4.4.2 Должен быть выбран набор интегрированных инструментальных средств, соответствующий требуемому уровню полноты безопасности и включающий языки программирования, компиляторы, средства управления конфигурацией и, при необходимости, автоматизированные средства тестирования. Следует учитывать способность инструментальных средств (необязательно тех, которые использовались при первоначальной разработке системы) выполнять необходимые задачи на протяжении всего жизненного цикла Е/Е/РЕ систем, связанных с безопасностью.
7.4.4.3 В той степени, в которой этого требует уровень полноты безопасности, выбранные языки программирования должны:
a) иметь транслятор/компилятор, который либо обладает сертификатом, подтверждающим соответствие национальному или международному стандарту, либо должен быть оценен для проверки его пригодности;
b) быть полностью и однозначно определенными либо ограниченными до подмножества однозначно определяемых элементов;
c) соответствовать характеристикам приложения;
d) обладать свойствами, облегчающими обнаружение ошибок программирования;
e) поддерживать характеристики, соответствующие методу проектирования.
7.4.4.4 Если требования 7.4.4.3 не могут быть выполнены, то при описании проекта архитектуры программного обеспечения (см. 7.4.3) следует документировать обоснование использования альтернативного языка программирования. В обосновании должны быть подробно рассмотрены пригодность языка программирования, а также дополнительные мероприятия, относящиеся к известным недостаткам языка.
7.4.4.5 Стандарты составления программ должны быть:
a) рассмотрены экспертом на предмет определения пригодности и
