ГОСТ Р МЭК 61511-1—2011
П р и м е ч а н и е — Между структурами аппаратных средств и архитектурами ПО существует итерационное
взаимодействие (см. рисунок 11). поэтому спецификацию совместных испытаний ПЭ технических средств и ПО
необходимо обсудить с разработчиком аппаратных средств (см. 12.5).
12.4.4 Требования к средствам поддержки, руководству пользователя и прикладным языкам
12.4.4.1 Должен быть выбран подходящий набор инструментальных средств, включающий подмно
жество языка прикладного программирования, средства управления конфигурацией, моделирования, сред
ства испытаний и. при необходимости, средства измерений при автоматических проверках.
12.4 4.2 Следует рассмотреть пригодность соответствующих средств (необязательно тех. которые
применялись при первоначальной разработке системы)для удовлетворения потребностей соответствую
щих служб в течение всего жизненного цикла ПСБ.
П р и м е ч а н и е — Выбор средств разработки зависит от характера работ по созданию ППО. встроенного
ПО и программной архитектуры (см. 12.4.3).
12.4.4.3 Следует установить подходящий набор процедур применения инструментальных средств,
учитывающих ограничения руководства по безопасности, известные слабые места, способные привести к
появлению ошибок в ППО. и любые ограничения зоны ранее проведенных проверки и подтверждения
соответствия.
12.4.4.4 Выбранный прикладной языкдолжен:
- использоватьтранслятор/компилятор. пригодность которого для данного случая должна быть оце
нена;
- быть полностью и однозначно определен либо ограничен однозначно определенными функциями;
- соответствовать характеристикам данного случая применения:
- обладать свойствами, облегчающими выявление программных ошибок: и
- поддерживать свойства, соответствующие выбранному методу проектирования.
12.4.4.5 Если требования 12.4.4.4 не могут быть выполнены, то при описании проекта архитектуры
ППО (см. 12.4.3) следуетдокументально оформить обоснование использования применяемого языка про
граммирования. В обосновании должны быть подробно рассмотрены пригодность языка программирова
ния. а такжедополнительные мероприятия, направленные на смягчение установленных его недостатков.
12.4.4.6 Процедуры применения прикладного языка должны быть хорошо проверены практикой про
граммирования. недопустимо использовать небезопасные особенности языка (например, неустановлен
ные характеристики, неструктурированные разработки), следует определять проверки на наличие ошибок в
конфигурации и устанавливать процедуры документирования прикладной программы.
12.4.4.7 Руководство по безопасности должно охватывать следующие вопросы (при их уместности):
a) применение диагностики для выполнения функций безопасности;
b
)перечень сертифицированных или верифицированных библиотекбезопасности;
c) логику обязательных проверок и остановов системы;
d) применение контрольных устройств;
e) требования и ограничения на средства и языки программирования;
f) уровни полноты безопасности, для которых подходитданное устройство или система.
12.4.4 8 Пригодность используемых инструментальных средств должна быть проверена.
12.4.5 Требования к разработке ППО
12.4.5.1 Чтобы начатьдетальное проектирование ППО. необходимо располагать следующей инфор
мацией:
a) спецификациями требований к безопасности ПО (см. 12.2);
b
)описанием проекта архитектуры ППО (см. 12.4.3). включающим в себя логику прикладной задачи
и функции, обеспечивающие отказоустойчивость, перечень входных и выходных данных, применяемые
общие программные модули и инструментальные средства их поддержки, а также процедуры программи
рования ППО.
12.4.5.2 ППО следует создавать с использованием структурных методов, чтобы обеспечить:
- модульность функций;
- проверяемость функций (включая отказоустойчивость) и внутренней структуры;
- способность к безопасной модификации:
- прослеживаемость для анализа и объяснения прикладных функций и связанных с ними огра
ничений.
50