ГОСТ РМЭК 62061—2015
- указания по самоконтролю программного обеспечения и контролю аппаратных средств, осуществляемому
с помощью программного обеспечения;
- указания, позволяющие проверить все связанные с безопасностью функции управления во время работы
систем {например, тестирование в неавтономном режиме, время захвата для быстрых сигналов, совмещение со
схоростью сканирования).
Примечание — Указания для самоконтроля программного обеспечения, разработанные с учетом целей
безопасности и операционных ограничений (продолжительность непрерывной работы и т. д.), могут включать ис
пользование таких устройств, как сторожевые устройства, контроль загрузки центрального процессора, обратная
связь от выхода ко входу. Для контроля аппаратных средств, процессора, памяти, и т.д. должны быть включены в
спецификации указания по верификации связанной с безопасностью функции управления; например, возможность
периодической проверки правильности работы устройств безопасности.
Необходимо, чтобы функциональные требования былиопределены для каждого режима функционирования.
Должен быть указан переход от одного режима к другому.
Примечание — Функциональные режимы могут включать номинальный и один или более ухудшенных
режимов. Цель состоит в том. чтобы указать поведение во всех ситуациях и избежать неожиданного поведения в
неноминальных режимах.
С.2.3 Уже существующее программное обеспечение
Термин «-ужесуществующее» программное обеспечение относится к исходным модулям, которые не были раз
работаны специальнодля данной системы и будут интегрированы всозданное программное обеспечение. Оно вклю
чает в себя элементы программного обеспечения, созданного разработчикомдля предыдущих проектов, или является
коммерческидоступнымпрограммнымобеспечением(например, модулидлярасчетов, алгоритмысортировкиданных).
При работе с таким типом программного обеспечения, особенно в случав элементов коммерческих про грамм.
разработчик не всегда имеет доступ ко всем элементам, которые были необходимы для предыдущего удов
летворения требований (например, какие тесты были выполнены, доступна ли проектная документация). Поэтому
может быть необходимо всамый кратчайший момент конкретное взаимодействие с аналитиком.
Разработчикдолжен показать аналитику, как используется уже существующее программное обеспечение, а
также продемонстрировать, что оно имеет такой же уровень, как и другие элементы программного обеспечения.
Такая демонстрация должна быть выполнена;
a) с помощью тех же мероприятий по верификации уже существующего программного обеспечения, как и
для остальной части программного обеспечения;
b
) или с использованием практического опыта, где уже существующее программное обеспечение функци
онирует в аналогичной системе сопоставимой окружающей среды (например, может быть необходимо оценить
последствия изменения компилятора или другого формата архитектуры программного обеспечения).
Примечание — Цель взаимодействия с аналитиком по вопросам применения уже существующего про
граммногообеспечения — начатьс ним как можно раньше консультации о любыхвозможных трудностях, к которым
может привести применение этого типа программного обеспечения. Интеграция уже существующих исходных мо
дулей может быть причиной некоторых аномалий или небезопасного поведения, если они не были разработаны с
той же строгостью, как и остальное программное обеспечение.
Ужесуществующее программное обеспечение должно быть определено с помощью тех же принципов управ
ления конфигурацией и управления версиями, которые применяются костальному программному обеспечению.
Примечание — Управление конфигурацией и управление версиями должны осуществляться для всех
компонентов программного обеспечения независимо от их происхождения.
С.2.4 Проектирование программного обеспечения
Описание программного обеспечения должно включать всебя описание;
- программной архитектуры, которая определяет структуру, удовлетворяющую спецификациям;
- входов и выходов (например, в форме внутреннего и внешнего словаря данных) для всех модулей, состав
ляющих архитектуру программного обеспечения;
- прерываний;
- глобальных данных;
- каждого программного модуля (входы/выходы, алгоритм, особенности проектирования и т.д.);
- используемого модуля или библиотеки данных;
- уже используемого программного обеспечения.
Программное обеспечение должно быть модульным и написано в логическом порядке, чтобы упростить его
проверку и техническое обслуживание;
- каждый модуль или группа модулей должны соответствовать, если это возможно, некоторой функции в
спецификации(ях);
- необходимо, чтобы интерфейсы между модулями были как можно более простыми.
61