Приложение В (справочное). Пример разработки прикладной программы логического решающего устройства ПСБ с помощью функциональных блок-схем

Приложение В
(справочное)

Пример
разработки прикладной программы логического решающего устройства ПСБ с помощью функциональных блок-схем

В.1 Общие положения

Следующие примеры описывают:

- метод организации действий, связанных с разработкой ППО, удовлетворяющий МЭК 61511-1:2016 (подраздел 6.3);

- формирование СТБ ППО на основе СТБ ПСБ, тем самым отвечая на вопрос МЭК 61511-1:2016 (пункт 10.3.2);

- разработку и реализацию двух функций останова в ППО, удовлетворяющих МЭК 61511-1:2016 (пункты 7.2.2 и 11.5.2, раздел 12 и пункт 15.2.2).

В.2 Принципы разработки и подтверждения соответствия прикладных программ

Чтобы помочь инженерам, разрабатывающим ППО, спроектировать такие ФБ ПСБ, эффективность которых можно предсказать и полнота безопасности которых будет соответствовать запрошенной (например УПБ 3) необходимо иметь эффективную методологию разработки.

При традиционном подходе инженеры по проектированию ППО способны провести полное испытание проекта ППО только на последних этапах проектирования, когда уже доступна реальная структура аппаратных средств. Такой метод является очень неэффективным, так как при обнаружении ошибки на данном этапе им придется вернуться к соответствующей стадии проектирования, чтобы исправить эти ошибки и выпустить новую версию, что, в свою очередь, приведет к значительному увеличению временных и денежных затрат, связанных с разработкой конечного продукта.

Традиционный подход к созданию спецификации ППО, основанный на тексте, недостаточно эффективен при работе с расширенными, сложными требованиями к безопасности, которые, как правило, представлены в спецификациях на ФБ ПСБ.

Наиболее эффективным инструментом для решения таких проблем является проектирование, основанное на модели (MBD). MBD является математическим и визуальным методом рассмотрения проблем, связанных с проектированием сложных систем безопасности, и этот метод успешно применяется во множестве приложений. Он предоставляет эффективный подход для преодоления трудностей стадии разработки жизненного цикла системы безопасности. Данный подход и этот пример включают следующие шаги:

- моделирование СТБ ППО с помощью:

- идентификации рассматриваемых элементов ПСБ;

- описания их поведения, используя надлежащий язык моделирования;

- анализ и синтез поведения предусмотренной реализации СТБ ППО с учетом их выполнения;

- демонстрацию соответствия реализации ППО требованиям СТБ, необходимую для документального оформления процесса подтверждения соответствия и выполнения требований МЭК 61511-1:2016 (подраздел 12.5 и раздел 15).

Это позволяет найти и исправить ошибки на ранних стадиях проектирования ППО, когда влияние временных и финансовых факторов минимально. В методологии MBD повторное проектирование выполняется более легко как для обновления ППО, так и для разработки более развитого ППО с расширенными возможностями. MBD предоставляет общую среду проектирования для всех разработчиков, облегчая общие коммуникации, анализ данных и верификацию ППО для различных групп разработчиков.

Текстовые спецификации и симуляция применялись довольно долгое время, но они очень неэффективны и неадекватны при работе с расширенными и сложными характеристиками ФБ ПСБ, так как эти средства по своей сути абсолютно не представимы графически и не имеют математического аппарата для оценки результата. В связи с ограничениями графических инструментальных средств инженеры по проектированию привыкли во многом полагаться на традиционное текстовое программирование и математические модели. И это являлось основной причиной неуверенности в обеспечении полноты безопасности, так как разрабатываемые модели в программах, основанных на тексте, являлись не только сложными и требующими больших затрат времени, но и были значительно подвержены ошибкам. Отладка модели и исправление ошибок являлось трудоемким процессом. Требовалось множество прогонов и исправления ошибок для достижения окончательной модели без сбоев, так как функциональная модель претерпевает незаметные изменения при ее преобразовании для различных стадий проектирования. На сегодняшний день подобные трудности преодолеваются при помощи специальных средств графического моделирования, поддерживаемых пакетами для разработки программ, удовлетворяющими МЭК 61511-1:2016 (подраздел 12.6) и охватывающими весь жизненный цикл ППО системы безопасности, представленный в МЭК 61511-1:2016 (пункт 6.3.1). Это позволяет в едином репозитарии как разрабатывать спецификации, так и осуществлять этап реализации, в результате появляется возможность подтвердить свойства полноты безопасности при достаточно низких затратах по сравнению с ручными методами. Подобные общие принципы разработки ППО, представленные данным примером, легли в основу реализации практики проектирования, основанной на модели.

Для поддержки проектирования и подтверждения соответствия будут последовательно реализованы, постепенно интегрированы и использованы следующие модели:

- функциональные модели:

- модель функциональной архитектуры аппаратных средств;

- модель физической архитектуры аппаратных средств;

- модель функциональной архитектуры ППО;

- модель архитектуры ППО;

- модели свойств безопасности:

- временных свойств;

- свойств полноты безопасности;

- модель проверки.

Эти модели интегрируются постепенно для того, чтобы последовательно продемонстрировать соответствие ППО спецификациям СТБ ППО.

Эти модели применяются:

- для проектирования как реализации спецификации, а именно подробной спецификации функциональной полноты и полноты безопасности;

- разработки ППО с автоматической компиляцией;

- выполнения полуавтоматического испытания при проверке модели, предназначенного для верификации соответствия каждого модуля ППО функциональным спецификациям и спецификациям безопасности;

- выполнения подтверждения соответствия, предоставляя исчерпывающую информацию о степени охвата испытанием и результатах испытаний.

В.3 Описание приложения

В.3.1 Общие положения

В данном примере рассматривается часть ПСБ, предназначенная для установки по производству сжиженного природного газа (LNG).

В.3.2 Описание процесса

Процесс, описанный в данном примере, является одним из процессов терминала сжиженного природного газа. Целью данной установки является получение LNG с кораблей для хранения и подготовки LNG к вводу в газораспределительную сеть.

В.3.3 Функции безопасности ПСБ

В.3.3.1 Общие положения

ПСБ для описанного выше процесса включает 7 ФБ ПСБ с УПБ 3 и 64 ФБ ПСБ с УПБ 2. Основное внимание в примере сосредоточено на одной ФБ ПСБ с УПБ 3 и одной ФБ ПСБ с УПБ 2. Приведенная ниже информация может рассматриваться как часть СТБ и применяться в качестве входных данных для СТБ ППО.

В.3.3.2 ФБ ПСБ 02.01 - Аварийный останов разгрузки LNG

Часть процесса, охватываемая этой функцией, представлена на рисунке В.1.

Целью этой функции с УПБ 2 является изоляция судна от объекта в случае, если в одном из трех резервуаров LNG выявлено сверхвысокое давление.

Запрос функции возникает, когда обнаруживается сверхвысокое давление и срабатывает реле датчика давления (датчики на рисунке В.1 не показаны) в любом из трех резервуаров LNG. Затем в результате выполнения функции происходит закрытие трех клапанов (XV1008, XV2008 и XV3008). Если затем по истечении заданного периода времени сверхвысокое давление по-прежнему не снижается, то закрываются два дополнительных клапана (XV1014 и XV2014). Клапаны останутся закрытыми до переустановки системы, даже если сигнал о сверхвысоком давлении исчезнет.

В.3.3.3 ФБ ПСБ 06.02 - Аварийное закрытие впускного клапана ORV

Часть процесса, обслуживаемая данной функцией, представлена на рисунке В.2.

Целью этой функции с УПБ 3 является отключение каждой открытой стойки выпаривателя (ORV) посредством закрытия впускного клапана XV1001 и запорного клапана XV1013 в случае обнаружения очень низкой температуры (датчики на рисунке В.2 не показаны) на отводящем трубопроводе с помощью реле датчика температуры. Эти клапаны не должны закрываться одновременно, чтобы избежать захвата газа в контуре между клапанами. Клапаны останутся закрытыми до переустановки системы, даже если сигнал об очень низкой температуре исчезнет. Закрытие обоих запорных клапанов приводит к опасному состоянию. Предотвращение опасного состояния соответствует УПБ 2.

В.3.4 Снижение риска и эффект "домино"

Анализ рисков устанавливает, что запрос к обеим ФБ ПСБ в одно и то же время может быть опасен и не должен происходить.

В.4 Выполнение жизненного цикла прикладной программы системы безопасности

В.4.1 Общие положения

Настоящий подраздел последовательно описывает:

- входные данные, необходимые для разработки СТБ ППО, получаемые из СТБ;

- разработку СТБ ППО (МЭК 61511-1:2016, пункт 10.3.2);

- проектирование архитектуры ППО (МЭК 61511-1:2016, раздел 12);

- моделирование, проектирование и испытание ППО (МЭК 61511-1:2016, пункты 12.3 и 12.4);

- испытание и моделирование интеграции ППО (МЭК 61511-1:2016, пункты 12.4 и 12.5);

- создание ППО;

- участие в подтверждении соответствия ПСБ (МЭК 61511-1:2016, раздел 15).

Рисунок В.1 - Технологическая схема для ФБ ПСБ 02.01

Рисунок В.2 - Технологическая схема для ФБ ПСБ 06.02

В.4.2 Входные данные для разработки СТБ прикладной программы

В.4.2.1 Общие положения

Далее представлены входные данные, получаемые от предыдущих стадий жизненного цикла.

В.4.2.2 Функциональная спецификация

Функциональная спецификация, возникающая из уточнения требований, описанных на рисунках В.1 и В.2, представлена на рисунке В.3. Эти схемы описывают ожидаемое поведение ФБ ПСБ перед принятием любых решений о будущих необходимых аппаратных средствах и прикладном программном обеспечении для реализации этих функций.

Рисунок В.3 - Функциональная спецификация ФБ ПСБ 02.01 и ФБ ПСБ 06.02

В.4.2.3 Функциональная архитектура аппаратных средств

Эти схемы показывают архитектуру аппаратных средств, необходимую для реализации ФБ ПСБ перед применением ограничителей HFT и каких-либо других требований СТБ.

ФБ ПСБ 02.01

Функциональная архитектура аппаратных средств представлена на рисунке В.4.

Рисунок В.4 - Функциональная архитектура аппаратных средств ФБ ПСБ 02.01

ФБ ПСБ 06.02

Функциональная архитектура аппаратных средств представлена на рисунке В.5.

Рисунок В.5 - Функциональная архитектура аппаратных средств ФБ ПСБ 06.02

В.4.2.4 Типичная спецификация аппаратных средств для соленоидных клапанов (SOV)/клапанов с электроприводом (MOV)

Схема трубопроводов и контрольно-измерительной аппаратуры, как правило, описывает все интерфейсы аппаратных средств и ППО устройства. На рисунке В.6 показаны интерфейсы аппаратных средств и ППО, предназначенные для реализации с SOV как в ОСУП, так и в ПСБ.

Рисунок В.6 - Спецификация аппаратных средств для реализации с SOV, выделенная из схем трубопроводов и контрольно-измерительной аппаратуры

В.4.2.5 Спецификация архитектуры аппаратных средств на физическом уровне

Уточнение полученных требований, описанных на рисунках В.4 и В.5, ведет к определению реальных аппаратных средств, предназначенных для использования, и их окончательной архитектуре, как это представлено на рисунках В.7 и В.8.

Примечания

1 Описание применения требований к отказоустойчивости аппаратных средств, полученных из требований в МЭК 61511-1:2016 (раздел 11), в настоящем примере не обсуждается.

2 В данном примере канал связи между ОСУП и ПСБ является дискретным (реализован аппаратно).

Рисунок В.7 - Физическая архитектура аппаратных средств ФБ ПСБ 02.01

Рисунок В.8 - Физическая архитектура аппаратных средств ФБ ПСБ 06.02

В.4.3 Проектирование и разработка прикладной программы

В.4.3.1 Общие положения

Настоящий пункт включает примеры для описания следующих шагов:

- разработка СТБ ППО;

- проектирование функциональной архитектуры ППО;

- функциональное проектирование, моделирование и испытание ППО;

- моделирование и испытание интеграции ППО.

В.4.3.2 СТБ прикладной программы

В.4.3.2.1 Общие положения

СТБ ППО может быть организована следующим образом:

- функциональные требования, соответствующие ожидаемым поведениям:

- требования к устройствам (датчикам и исполнительным устройствам);

- требования к блокировкам каждой ФБ ПСБ;

- требования к блокировкам между ФБ ПСБ;

- требования к полноте безопасности, соответствующие поведениям, которых следует избегать:

- на уровне устройства;

- на уровне ФБ ПСБ;

- на более высоком уровне, таком как уровень объекта (завода).

В.4.3.2.2 Спецификация функциональных требований к прикладной программе

В.4.3.2.2.1 Функциональные требования к устройству

Функциональные требования к устройству могут быть описаны для каждого типа устройства и разделены на требования:

- к базовым эксплуатационным режимам устройства и

- функциональной спецификации устройства.

Пункт В.4.3.2 содержит пример для SOV.

Общие рабочие режимы исполнительных устройств: конечный автомат для рабочих режимов соленоидного клапана (SOV) определен в таблице В.1.

Таблица В.1 - Спецификация режимов работы

Название состояния	Описание
Запрос	Когда условия безопасности генерируют последовательность действий по безопасности, то поступает запрос на управление клапаном логикой более высокого уровня. Подобный запрос имеет наивысший приоритет по сравнению с любым другим рабочим режимом. Затем устройство фиксируется в запрошенном режиме. Его отдельные компоненты становятся недоступны, а клапан управляется только логикой более высокого уровня. Когда логика снимает условия безопасности, осуществляется принудительный переход из рабочего режима в режим УДАЛЕНИЯ, после этого оператор может изменить режим работы
Удаление	Управление клапаном осуществляется с помощью команд открытия и закрытия человеко-машинного интерфейса ОСУП. Это состояние является начальным
Локальное	Управление клапаном осуществляется с помощью командных кнопок открытия и закрытия, расположенных рядом с клапаном
Неисправен	Данный режим возможен, только если клапан уже находится в своем безопасном положении. Все локальные и удаленные команды оператора становятся недоступны. Управление осуществляется с помощью условий безопасности
Обслуживание	Данный режим возможен, только если клапан уже находится в безопасном положении. Осуществляется принудительный переход в состояние "Неисправен", и все аварийные сигналы блокируются

Функциональная спецификация SOV.

Устройство является запорным электромагнитным клапаном, управляемым от ПСБ и ОСУП.

Предполагается, что в случае опасности, от которой защищает ФБ ПСБ, SOV имеет единственное и постоянное безопасное положение. Это положение закрытое.

SOV является автономным устройством: он воспринимает отдельные команды от ОСУП и может при определенных обстоятельствах находиться под управлением логики более высокого уровня. Логика управления таким устройством, как SOV, называется "типовым набором".

Типовой набор для данного SOV позволяет реализовать следующее:

- команды открытия и закрытия от станций оператора ОСУП;

- локальные команды открытия и закрытия, поступающие от объекта через ОСУП;

- переход в безопасное положение, инициированный ПСБ или ОСУП;

- передачу по кабелю команды открытия и закрытия из ПСБ;

- выбор рабочего режима на станции оператора ОСУП с помощью программируемого переключателя;

- реорганизацию команд в следующих случаях:

- реорганизацию команд при получении информации от концевых переключателей при инициализации;

- реорганизацию команд при блокировках логики более высокого уровня в запрошенном режиме;

- реорганизацию команд по командам объекта в режиме объекта;

- реорганизацию команд при безопасном состоянии в случае действий по обеспечению безопасности;

- работу в состоянии обслуживания;

- визуализацию положения клапана на основе информации от двух концевых переключателей;

- генерацию аварийного сигнала о конфликте (при открытии или закрытии, одновременном распознавании обоих концевых переключателей, отказе концевого переключателя). Чтобы избежать генерации ложных аварийных сигналов о конфликте, информация концевого переключателя задерживается, чтобы позволить ПСБ передать команду в ОСУП;

- обнаружение отказов ОСУП и ПСБ;

- модификацию настройки и параметров настройки.

Параметры: задержка обнаруженного конфликта.

Доступ только на уровне обслуживания.

В.4.3.2.2.2 Функциональные требования к ФБ ПСБ

Функциональные требования для каждой функции безопасности описаны в СТБ.

В.4.3.2.2.3 Функциональные требования к блокировкам между ФБ ПСБ

На данном уровне функциональные требования отсутствуют.

В.4.3.2.3 Спецификация требований к полноте безопасности

В.4.3.2.3.1 Требования к полноте устройства

Существуют следующие требования к полноте безопасности устройства:

- никакая комбинация блокировок не должна мешать команде устройства, реализующей переход в его безопасное положение при появлении запроса;

- никакая комбинация блокировок не должна задерживать команду SOV более чем на 100 мкс;

- никакая комбинация блокировок не должна приводить к неопределенному или нестабильному состоянию физического устройства при выполнении команды;

- все условия перехода конечного автомата должны быть исчерпывающими и исключительными;

- должны быть определены действия каждого условия конечных автоматов.

В.4.3.2.3.2 Требования к полноте ФБ ПСБ

Существуют следующие требования к полноте ФБ ПСБ:

- если входные данные действительны, то никакая комбинация блокировок не должна помешать ФБ направить запрос типовому набору ППО для SOV;

- никакая комбинация блокировок не должна задерживать запрос к SOV более чем на 100 мкс;

- никакая комбинация блокировок не должна приводить к неопределенному или нестабильному состоянию физического устройства при выполнении команды.

В.4.3.2.3.3 Требования к полноте блокировок между ФБ УПБ

Существуют следующие требования к полноте ФБ ПСБ:

- никакая комбинация блокировок или запросов не должна приводить к одновременному запросу к ФБ ПСБ 02.01 и ФБ ПСБ 06.02.

В.4.3.3 Проектирование функциональной архитектуры прикладной программы

В.4.3.3.1 Проектирование архитектуры

Деятельность по проектированию архитектуры ППО должна обеспечить, чтобы результирующая архитектура:

- соответствовала МЭК 61511-1:2016 (пункт 12.4.4);

- никаким образом не ухудшала систематическую полноту архитектуры аппаратных средств, заданную в СТБ.

Архитектура ППО строится иерархически. Предлагаются следующие уровни и модули ППО:

- типовой набор для ППО устройств: в данном примере рассматриваются соленоидные клапаны; датчики давления и температуры. Эти модули содержат логику, необходимую для управления устройством, сбора и обработки входных данных, стандартных сложных функций, таких как голосование;

- логика ФБ ПСБ: блокирование модулей ППО для реализации ожидаемого поведения ФБ ПСБ;

- логика объекта: блокирование ФБ ПСБ.

Эти модули ППО описаны с помощью графического языка автоматизированной среды проверки моделей и представляют собой модели, отражающие ожидаемое поведение разрабатываемых модулей ППО. Все эти модули представляют завершенное ППО, которое создано для ФБ ПСБ, и может быть скомпилировано и загружено в целевые логические решающие устройства.

Список необходимых модулей (ограничен рассматриваемым примером):

- типовой набор SOV;

- голосование "2 из 3";

- обработка коммуникаций сети;

- обработка датчиков;

- логика ФБ ПСБ 02.01;

- логика ФБ ПСБ 06.02.

Все модули объединены (интегрированы) в соответствии со структурой, описанной на рисунке В.9.

В.4.3.3.2 Требования к полноте безопасности, полученные из архитектуры

В.4.3.3.2.1 Общие положения

Данная архитектура никаким образом не должна подвергать риску систематическую полноту безопасности физических аппаратных средств, определенную в В.4.3.3.1.

Рисунок В.9 - Иерархическая структура интеграции моделей

Эта проблема далее более подробно не обсуждается, так как она непосредственно зависит от характеристик выбранных логических решающих устройств. Но, как минимум, выясняется, что для ФБ ПСБ 02.01 есть необходимость анализа последствий распределения модулей ППО между CPU 1 и CPU 2 на систематическую полноту безопасности этой ФБ ПСБ. Для этого требуется анализ комбинаций видов отказов аппаратных средств вместе с видами отказов ППО. Такой анализ, как правило, выполняется с помощью построения дерева отказов, включая в него отказы, характерные для модулей ППО (независимые от аппаратных средств, на которых оно установлено), и направлен на определение того, существует ли отказ системы вследствие отказа одного элемента, который негативно влияет на ОАС.

Кроме того, определение архитектуры ППО позволяет определить выводимые из нее СТБ ППО, которые необходимо распределить для каждого модуля ППО.

В.4.3.3.2.2 Требования к целостности устройства

Требования к устройству:

- все условия перехода конечного автомата должны быть исчерпывающими и исключительными;

- действия каждого условия конечного автомата должны быть определены.

В.4.3.3.2.3 Требования к полноте функции безопасности ПСБ

Выводимые требования:

- никакая комбинация динамических значений переменных, обеспечивающих интерфейс между блокировками ФБ ПСБ и связанными с ней модулями, не должна приводить к неопределенному или нестабильному состоянию ФБ ПСБ.

Примечание - Это требование не повторяет требование В.4.3.3.1. В.4.3.3.1 связан с логикой функционального статического поведения. Настоящее требование связано с логикой динамического поведения, распределенного между двумя CPU и возникающего из проекта архитектуры.

В.4.3.3.2.4 Требования к полноте на уровне объекта

Никаких производных требований.

В.4.3.4 Функциональное проектирование, моделирование и испытание прикладной программы

В.4.3.4.1 Проектирование и испытание функциональных моделей модулей прикладной программы

Необходимые модули ППО, идентифицированные в архитектуре ППО, моделируются в автоматизированной среде разработки и проверки моделей. Помимо этого, создаются модели для описания:

- поведения физических устройств;

- поведения человеко-машинного интерфейса;

- необходимых свойств безопасности устройств;

- необходимых свойств безопасности ФБ ПСБ;

- необходимых свойств безопасности на уровне объекта;

- физического поведения объекта (блокировка техническими жидкостями);

- части логики ОСУП.

Это необходимо для обеспечения требующихся свойств моделируемых ФБ ПСБ их функциональным и физическим контекстом.

Все модули ППО интегрируются в одну функциональную модель для проверки в соответствии со структурой, описанной на рисунке В.10.

Рисунок В.10 - Иерархическая структура интеграции моделей, включающая модели свойств безопасности и логики ОСУП

В.4.3.4.2 Описание моделей

В.4.3.4.2.1 Уровень прикладных программ типового набора

Модель логики управления SOV из ОСУП.

Уточнение требований к режимам работы из таблицы В.1 позволяет получить подробное описание проекта логики управления SOV, представленное с помощью диаграммы состояний.

Пример таблицы переходов состояний приведен в таблице В.2.

Из таблицы переходов состояний В.2 может быть получена диаграмма переходов состояний, представленная на рисунке В.11.

Таблица В.2 - Таблица переходов состояний

Состояния/ Следующие состояния	Условие перехода	Действие
Запрос
Удаление	! 12HS1234D
Удаление
Запрос	12HS1234D
Объект	12HS1234B !12HS1234D
Отключено	12HS1234A !12HS1234D 12ZSL1234
Объект
Запрос	12HS1234D
Удаление	12HS1234C !12HS1234D
Отключено	12HS1234A !12HS1234D 12ZSL1234
Отключено
Запрос	12HS1234D
Удаление	12HS1234C !12HS1234D
Объект	12HS1234B !12HS1234D

Рисунок В.11 - Диаграмма переходов состояний

Результатом графической спецификации поведения SOV, соответствующей требованиям к интерфейсу на рисунке В.6 и рисунку В.11, является описание функционального блока, представленное на рисунке В.12.

Моделирование функций и интерфейсов ЧМИ не требуется, так как они являются только выходами и не повлияют на поведение SOV. Таким образом, рисунок В.12 может быть упрощен (см. рисунок В.13).

Рисунок В.12 - Структурная схема типового набора SOV

Рисунок В.13 - Упрощенная структурная схема модели типового набора SOV

Спецификация на рисунке В.13 должна быть реализована на графическом языке автоматизированной среды проверки модели. Реализация учитывает необходимость отделения части логики, связанной с ОСУП, от части, связанной с ПСБ. Результат такой реализации, например, приведен на рисунке В.14 (для ОСУП) и на рисунке В.15 (для ПСБ). Моделирование ОСУП требуется, в частности, когда между ОСУП и ПСБ существует интерфейс, необходимый для доказательства независимости ФБ ПСБ от ОСУП и подтверждения выполнения требований к полноте безопасности, например требования о том, что ОСУП ни в коем случае не может заблокировать ФБ ПСБ. Большинство средств проверки модели позволяют непосредственно исполнять такую проверку модели без выполнения шага, описанного на рисунках В.12 и В.13, которые приведены здесь для ясности понимания.

Продолжение моделирования.

Такой же подход применяется для моделирования:

- свойств безопасности данного SOV;

- других необходимых типовых наборов, которые будут использоваться в данном примере:

- голосования "2 из 3";

- свойств безопасности "2 из 3";

- обработки сетевых коммуникаций;

- свойств безопасности сетевых коммуникаций;

- обработки датчиков;

- свойств безопасности датчиков.

В.4.3.4.2.2 Уровень функции безопасности ПСБ

Такой же подход применим на уровне ФБ ПСБ для моделирования:

- блокировок ПСБ 02.01;

- свойств безопасности ПСБ 02.01;

- блокировок ПСБ 06.02;

- свойств безопасности ПСБ 06.02.

В.4.3.4.2.3 Уровень объекта

Такой же подход применим на уровне ФБ ПСБ к моделированию:

- блокировок объекта;

- свойств безопасности объекта;

- объекта.

В.4.3.4.3 Результаты тестирования моделей и исправление дефектов

Средство проверки моделей независимо запускают модели с целью обнаружения нарушений безопасного поведения. Если средство проверки моделей находит ошибки, то модели, в которых они обнаружены, корректируются и выполняются снова, пока эти систематические сбои проектирования не будут устранены.

В.4.3.5 Моделирование интеграции прикладной программы и тестирование

Предыдущие шаги позволили инженеру ППО:

- описать архитектуру ППО;

- описать содержание функциональных модулей ППО;

- продемонстрировать, что спецификации архитектуры и модулей:

- соответствуют функциональным спецификациям ППО;

- соответствуют спецификациям полноты безопасности ППО.

Недостаточно продемонстрировать, что концепция ППО является подходящей при интегрировании ППО в целевую архитектуру физических аппаратных средств, так как функциональное поведение ППО будет также зависеть от характеристик архитектуры физических аппаратных средств.

Эта стадия проектирования заключается в добавлении моделей, описывающих влияние распределения ППО в архитектуре целевых физических аппаратных средств, чтобы проверить, что СТБ по-прежнему выполняются. В случае их невыполнения модули ППО, и/или архитектуры ППО, и/или даже физическая архитектура будут модифицированы. Шаг, представленный на рисунке В.10, может быть пропущен, если физическая архитектура аппаратных средств известна на ранних стадиях жизненного цикла разработки ППО.

Последующие модели разрабатываются и добавляются в модель проверки в рамках следующей структуры, как описано на рисунке В.16.

В.4.4 Производство прикладных программ

Некоторые рабочие среды ППО позволяют генерацию прямого загружаемого кода из моделей, уже подвергавшихся проверкам. Некоторые из них, кроме этого, соответствуют МЭК 61508.

В.4.5 Верификация и тестирование прикладной программы

Если невозможно автоматически сгенерировать загружаемый код из прежде используемого средства или средства, соответствующего МЭК 16508, то ППО генерируется вручную и тестируется.

Рисунок В.14 - Реализация структурной схемы модели типового набора (для ОСУП)

Реализация модели логики управления SOV из ПСБ.

Рисунок В.15 - Реализация модели прикладных программ типового набора SOV (для ПСБ)

Рисунок В.16 - Полная модель для заключительной проверки модели реализации

В.4.6 Подтверждение соответствия

Для ППО, генерируемого автоматически из моделей с помощью средства, соответствующего МЭК 61511-1:2016, (пункт 12.6), подтверждение соответствия заключается в верификации документации средства проверки модели посредством анализа этой документации, чтобы убедиться, что все функциональные свойства и свойства полноты безопасности, описанные в СТБ ППО, были в действительности продемонстрированы.

В случае ППО, генерируемого вручную, подтверждение соответствия заключается в верификации того, что реализация строго соответствует предположениям моделей и тому, что все функциональные свойства и свойства полноты безопасности, описанные в СТБ ППО, были в действительности продемонстрированы в ходе испытаний.