ГОСТ Р МЭК 61508-3—2012
a) юридическое лицо [например, компания, автор(ы). и т. д.];
b
) описание,
c) входные и выходные данные;
d) историю управления конфигурацией.
7.4.4.14 Если выполняется автоматическая генерация кода или применяется автоматический
транслятор, то необходимо провести оценку пригодности автоматического транслятора для разработки
системы, связанной с безопасностью, для тех стадий жизненного цикла разработки, на которых приме
няют инструментальные средства поддержки разработки.
7.4.4.15 Если инструментальные средства поддержки классов Т2 и ТЗ. работающие в автоном
ном режиме, генерируют элементы для базовой конфигурации, то управление конфигурацией должно
гарантировать, чтобы информация об инструментальных средствах была записана в базовой конфигу
рации. В частности, информация об инструментальных средствах должна включать в себя;
a) идентификацию инструментального средства и его версии.
b
) идентификацию элементов базовой конфигурации, для которых использоваласьданная версия
инструментального средства.
c) последовательность использования инструментального средства (включая параметры инстру
ментального средства, опции и выбранные сценарии) для каждого базового элемента конфигурации.
П р и м е ч ан и е — Цель настоящего подпункта состоит в том. чтобы позволить реконструировать базовую
конфигурацию.
7.4.4.16 Управление конфигурацией должно гарантировать, что для инструментальных средств в
классах Т2 и ТЗ используются только квалифицированные версии.
7.4.4.17 Управление конфигурацией должно гарантировать, что используются только инструмен
тальные средства, совместимые друг с другом и с системой, связанной с безопасностью.
П р и м е ч ан и е — Аппаратные средства системы, связанной с безопасностью, могут также наложить огра
ничения на совместимость программного обеспечения инструментальных средств, например, эмулятор процессо ра
должен быть точной моделью реальной электроники процессора.
7.4.4.18 Каждая новая версия инструментального средства поддержки, работающего в автоном
ном режиме, должна быть квалифицирована. Эта квалификация может опираться на доказательства,
представленныедля более ранней версии, при наличии достаточных доказательств, при условии, что;
a) функциональные различия (при наличии) не будут влиять на совместимость инструментально
го средства с остальной частью набора инструментальных средств и
b
) новая версия вряд ли будет содержать принципиально новые, неизвестные отказы.
П р и м е ч ан и е — Доказательство того, что новая версия вряд ли будет содержать принципиально новые,
неизвестные отказы, может быть основано на ясной идентификации выполненных изменений, анализе действий по
проверке и подтверждению соответствия, выполняемыхдля новой версии, и любом существующем опыте рабо ты
других пользователей с новой версией.
7.4.4.19 В зависимости от характера разработки программного обеспечения ответственность за
соответствие требованиям 7.4.4 может лежать на нескольких сторонах. Распределение ответственно
сти должно бытьдокументально оформлено во время планирования системы безопасности (см. раздел 6
МЭК 61508-1).
7.4.5Требования к детальному проектированию и разработке — проектирование системы
программного обеспечения
П рим ечан ия
1 Под детальным проектированием понимается разделение основных элементов архитектуры на систему
программных модулей, проектирование отдельных программных модулей и их программирование. В небольших
приложениях проектирование программных систем и архитектуры может быть объединено.
2 Характер детального проектирования и разработки может изменяться в зависимости от характера про
цессов разработки программ и архитектуры программного обеспечения (см. 7.4.3). Если прикладное программи
рование выполняется, например, с помощью языков многозвенных логических схем и функциональных блоков, то
детальное проектирование может рассматриваться скорее как конфигурирование, чем как программирование. Тем
не менее, правильный стиль программирования состоит в структурировании программного обеспечения, включая
организацию модульной структуры, которая выделяет (насколько это возможно) блоки, связанные с безопасно
стью; в использовании проверок на попадание в интервал допустимых значений и других возможностей защиты от
ошибок при вводе исходных данных; в использовании ранее верифицированных программных модулей; в при
менении проектных решений, которые облегчают выполнение будущих модификаций программного обеспечения.
26