ГОСТ Р МЭК 61508-3—2012
П р и м е ч ан и е — Способы, соответствующие данному требованию, включают в себя:
- устранение таких функций из проекта:
- отключение таких функций;
- использование соответствующей архитектуры системы (например, декомпозиция на части, упаковка в от
дельный файл, разнообразие, проверка достоверности выходов):
- широкое тестирование.
д) Должно быть доказано, что все вероятностные механизмы отказа элемента программного обе
спечения были идентифицированы и реализованы соответствующие меры их ослабления.
П р и м е ч ан и е — Соответствующие меры ослабления включают в себя:
- использование соответствующей архитектуры системы (например, декомпозиция на части, упаковка в от
дельный файл, разнообразие, проверка достоверности выходов):
- широкое тестирование.
h) При планировании использования элемента должны быть идентифицированы конфигурация
элемента программного обеспечения, среды выполнения программного и аппаратного обеспечения и
(при необходимости) конфигурация системы компиляции / редактирования связей.
i) Обоснованием использования элемента должно быть проведение для него процедуры под
тверждения соответствия только для тех применений, которые соответствуют предположениям руко
водства для этого элемента по безопасности применяемых изделий (см. приложение D МЭК 61508-2 и
приложение D настоящего стандарта).
7.4.2.14 7.4.2. насколько это уместно, должен применяться к данным и языкам генерации данных.
П р и м е ч ан и е — Руководящие указания по системам, управляемым данными, см. в приложении G.
a) Если ПЭ система обладает уже существующей функциональностью, которая сконфигурирована
данными и соответствует конкретным требованиям применения, то проект прикладного программного
обеспечения должен соответствовать степени конфигурируемости применения, существующей у пред
варительно поставляемой функциональности и сложности ПЭ системы, связанной с безопасностью.
b
) Если функциональность ПЭ системы, связанной с безопасностью, определена в значительной
степени или в основном конфигурационными данными, то для предотвращения появления отказов во
время проектирования, производства, загрузки и модификации данных конфигурации и уверенности,
что конфигурационные данные правильно формируют логику применения, должны использоваться со
ответствующие методы и средства.
c) Спецификация структур данных должна быть:
1) не противоречащей функциональным требованиям системы, включая данные применения;
2 ) полной;
3) внутренне непротиворечивой;
4) такой, чтобы структуры данных были защищены от изменения или повреждения.
d) Если ПЭ система обладает уже существующей функциональностью, которая сконфигурирова
на данными и соответствует определенным требованиям применения, то сам процесс конфигурации
должен быть соответственно документально оформлен.
7.4.3 Требования к проектированию архитектуры программного обеспечения
Примечания
1 Архитектура программного обеспечения определяетосновные элементыи подсистемы программногообес
печения. их взаимосвязь, способ реализации необходимых характеристик и. в частности, полноты безопасности.
Архитектура программного обеспечения также определяет общее поведение программного обеспечения и то. как
элементы программного обеспечения реализуют интерфейс и взаимодействуют между собой. Примеры основных
компонентов программного обеспечения включают в себя операционные системы, базы данных, подсистемы вво
да и вывода УО. коммуникационные подсистемы, прикладные программы, инструментальные средства програм
мирования и диагностики и т.п.
2 В некоторых отраслях промышленности архитектура программного обеспечения может называться «опи
сание функций или спецификация функций проекта» (хотя эти документы могут также включать в себя вопросы,
относящиеся к аппаратным средствам).
3 В некоторых случаях пользовательского прикладного программирования, в частности, в языках, использу
емых в программируемых логических контроллерах (П
Л
К) (приложение Е МЭК 61508-6). архитектура определяется
поставщиком как стандартная характеристика П
Л
К. Однако в соответствии с требованиями настоящего стандар та
к поставщику может быть предъявлено требование гарантировать пользователю соответствие поставляемого
продукта требованиям 7.4. Пользователь приспосабливает П
Л
К. используя стандартные возможности программи
рования. например многозвенные логические схемы. Требования 7.4.3—7.4.8 остаются в силе. Требование опре-
21