ГОСТ Р МЭК 60880—2010
Проблемно-ориентированные языки опираются на методы формализации (такие каклогические диаг раммы
или диаграммы функциональных блоков и т.п.). которые могут применяться для выражения всей или
части спецификации требований к программному обеспечению. Эти части могут использоваться в ка
честве входной информации для генерации исполняемого кода с помощью автоматизированных средств.
7.1.3.1 Рекомендуется, чтобы методы формализации обладали следующими свойствами: невысокая
сложность, ясность и стандартность расположения и представления, модульность, наличие соответствую
щих комментариев, отсутствие небезопасных элементов. Эти свойства, как правило, упрощают понима
ние. верификацию, тестирование и последующую модификацию.
7.1.3.2 В проблемно-ориентированных языках следует использовать формат, понятный для специа
листов. ответственных за анализ спецификации программного обеспечения, например, для технологов и
специалистов по контролю и управлению, имеющих дело с системами, для которых установлены функции
контроля и управления.
7.1.3.3 Рекомендуется, чтобы проблемно-ориентированные языки поддерживали простую структуру
программного обеспечения, например, линейные программы.
7.1.3.4 Рекомендуется, чтобы проблемно-ориентированные языки позволяли разработчикам учиты
вать спецификацию проекта архитектуры СКУ, например, давали возможность назначать функции компо
нентам системы и поддерживали способность проекта сохранять устойчивость к дефектам элементов тех
нического обеспечения.
7.1.4 Конфигурация ранее разработанного программного обеспечения
В данном пункте рассматривается ситуация, когда функции безопасности категории А обеспечивают
ся программным обеспечением с использованием данных конфигурации, т.е. данных, специфичных для
конкретного применения.
Ранее разработанное программное обеспечение может быть связано с комплексом оборудования
либо оно может быть отдельной программой, которая затем интегрируется с выбранной платформой техни
ческого обеспечения.
7.1.4.1 При использовании ранее разработанного программного обеспечениядолжна быть проведена
оценка его возможностей (см. 15.3)для обеспечения пригодностидля предназначенной роли.
Требования канализу пригодности приведены в 15.3.1.2. При существовании ограничения на исполь
зование программного обеспечения его пригодность может бытьдостигнута с помощью программного обес
печения. являющегося внешним по отношению к ранее разработанному программному обеспечению.
Для конфигурирования программногообеспечения предпочтителен подход, основанный на инстру
ментальных программах, который сужаетобласть возможных ошибок человека.
7.1.4.2 Все ограничения, связанные с данными, должны быть оформлены документально с указани
ем, например, допустимых форматовданных, диапазонов, правил вычислений.
7.1.4.3 Данные конфигурации должны быть оформлены документально.
7.1.4.4 Надлежащим образом должны быть обоснованы значения величин, используемых в сочета
нии с исходными проектными данными.
7.1.4.5 Прослеживаемость: рекомендуется, чтобы была возможность определить, когда и кем были
проведены изменения данных конфигурации.
7.1.4.6 Удобство сопровождения: процесс разработки должен обеспечивать с помощью структуриро
ванного подхода и использования комментариев кданным и/или сопроводительнойдокументацией понят
ность и сопровождаемость структуры данных втечение назначенного срока службы системы, к которой эта
структура принадлежит.
Для дальнейшего руководства по использованию инструментов прикладных данных см. 14.3.5.
7.2 Язык и связанные с ним трансляторы и инструментальные средства
7.2.1 Общие требования
При проектировании и реализации программного обеспечения систем класса 1нельзя требовать ис
пользования специальных языков, однако следующие положения могут рассматриваться в качестве об
щих основных правил для языков, используемых в этих целях:
7.2.1.1 Используемые языки должны соответствовать строгим (или строго очерченным) правилам
семантики и синтаксиса.
7.2.1.2 Синтаксис языка должен быть полностью и четко определен и оформлен документально.
7.2.1.3 В необходимыхслучаях использование языка должно быть ограничено «безопасным» сокра
щенным вариантом, например, примитивами, которые пригодны для определения необходимых функций.
16