Приложение Е (справочное). Пример получения прикладной программы из схемы трубопроводов и контрольно-измерительных приборов (СТ и КИП)

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

 

Пример
получения прикладной программы из схемы трубопроводов и контрольно-измерительных приборов (СТ и КИП)

 

Е.1 Типовой набор инструментальных средств прикладного программирования

Как правило, набор инструментальных средств, поддерживающий программирование ПЭ, включает следующие средства:

a) редактор конфигураций. Этот редактор используется, чтобы сконфигурировать подсистему входов/выходов ПСБ, входные/выходные переменные памяти и функции коммуникации;

b) редакторы языков. Эти редакторы использует прикладной программист при разработке программ, выполняющих все необходимые для данной системы функции (связанные и не связанные с безопасностью);

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

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

e) средства планирования работы ППО. Такие средства планирования поддерживают настройку порядка требуемой последовательности выполнения программ и скорости их выполнения;

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

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

h) средства мониторинга программ. Средства мониторинга позволяют пользователю просматривать данные, получаемые исполняемой программой, или на экране пользователя, или на реальном функциональном блоке, или на экране программы многоступенчатых диаграмм. Среда разработки может также предоставлять возможность наблюдения за исполнением программы-эмулятора. Кроме того, могут контролироваться программы, исполняемые логическим устройством;

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

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

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

- выражение для представления:

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

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

- требований к установлению последовательностей;

- обеспечения того, что ФБ ПСБ всегда функционирует в заданных временных ограничениях;

- предотвращения неопределяемого поведения;

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

- допущений при проектировании и зависимостей между ними;

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

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

- модификацию ППО. Сюда включают модульную организацию, прослеживаемость и документацию.

Е.2 Правила и ограничения для проектирования прикладных программ

Ниже приведен перечень указаний, подлежащих выполнению при разработке ППО ПСБ:

a) разделить ППО на отдельные ФБ ПСБ со своим УПБ для каждой ФБ ПСБ;

b) разобраться в архитектуре аппаратных средств каждой ФБ ПСБ и продублировать эту архитектуру аппаратных средств для каждого ППО ФБ ПСБ;

c) не оптимизировать ППО, если это ведет к излишней сложности (это часто требует привлечения опытного программиста для интерпретации ППО);

d) использовать методы разработки ППО, упомянутые в инструкциях поставщика (например, в руководстве по безопасности);

e) не объединять ППО одной ФБ ПСБ с прикладными программами любой другой ФБ ПСБ;

f) использовать язык ППО (например, по типу или по функции), средства которого отработаны, понятны и способны к выявлению и устранению ошибок;

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

h) декомпозировать ППО на модули, согласованные с последовательностью процесса (например, первый модуль - это общее ПО, которое не связано с ФБ ПСБ, но требуется в ПСБ; второй модуль - это первая ФБ ПСБ, относящаяся к запуску процесса; последний модуль - это последняя ФБ ПСБ, относящаяся к окончанию процесса);

i) тщательно проверить (например, моделированием, просмотром или проверкой) каждый модуль ППО и провести повторный независимый анализ (привлекая на этой и на всех последующих стадиях подразделения по эксплуатации и обслуживанию);

j) тщательно проверить комбинации модулей, образующие подсистемы процесса ПСБ, и провести их повторный независимый анализ;

k) тщательно испытать ППО ПСБ в целом и провести его повторный независимый анализ;

l) использовать ППО при проведении проверки аппаратных средств (например, для подтверждения правильности подсоединения входов/выходов к датчикам/исполнительным элементам);

m) включить проверки ППО в прогоны процесса (например, выполнение процесса без загрузки опасных материалов).

 

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

 

n) обеспечить доступность персонала сопровождения ППО при любой работе с ППО (например, при вводе в эксплуатацию);

o) не допускать взаимные блокировки между ФБ ПСБ.

Е.3 Правила и ограничения для прикладного программирования

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

a) запрещается использовать функции SKIP (пропустить) и JUMP (перепрыгнуть);

b) запрещается использовать функции NOT (отрицание);

c) запрещается использовать косвенную адресацию;

d) запрещается использовать алгоритмы сжатия;

е) запрещается использовать логику, основанную на результатах арифметических вычислений;

f) запрещается использовать логику вместе с устройствами, запоминающими внутреннее состояние (например, с триггерной памятью);

g) запрещается использовать текстовые переменные в ФБ ПСБ;

h) запрещается использовать функции или подпрограммы, включающие передачу переменных или параметров;

i) запрещается индивидуальная настройка библиотечных функций;

j) запрещается использовать прерывания;

k) запрещается блокировка данных;

l) запрещается размещение логических переменных внутри целочисленных переменных;

m) запрещается логическая инверсия физического состояния датчиков или исполнительных устройств;

n) запрещается разбиение блокировок ФБ ПСБ по нескольким логическим решающим устройствам;

o) запрещается использовать любые функции сетевых коммуникаций, кроме пассивных функций;

p) настоятельно рекомендуется использовать методы программирования, проверенные на объекте и прошедшие оценку безопасности;

q) настоятельно рекомендуется использовать стандартизированные модули (например, "типовые наборы");

r) настоятельно рекомендуется использовать алфавитно-цифровые описатели устройств для описания задачи и перекрестных ссылок для каждого датчика, исполнительного элемента (например, для соленоидных клапанов, клапанов, двигателей, аварийных сигналов), ПСБ и т.д., согласующиеся и связанные с проектными чертежами (например, схемы Т и КИП, компоновочные чертежи, логические диаграммы);

s) настоятельно рекомендуется использовать одобренные объектом и уже прежде проходившие оценку функции безопасности логического решающего устройства (например, аварийный останов, световые завесы, предохранительные затворы);

t) настоятельно рекомендуется разделять программирование логического решающего устройства ПЭ на три отдельные области: входной контур, контур логики, выходной контур:

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

- логические диаграммы должны изображаться вертикально в формате ступенчатой диаграммы (или на надлежащем ЯОИ), чтобы у каждой ступеньки слева были входы, а справа - выход;

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

u) подход к проектированию должен, как правило, базироваться на останове по отключению питания для перевода процесса в безопасное состояние; в случае систем, которым требуется останов по включению питания, требуются специальные меры предосторожности;

v) адресация входов/выходов логического решающего устройства и программирование логического решающего устройства должны быть организованы для зеркального отображения приложения процесса (например, начальное программирование и назначение входов/выходов должны быть связаны с циклом запуска приложения и продолжаться во время его разработки в таком же формате, какой диктует технологический процесс, заканчиваясь на функции останова);

w) функции поддержки, такие как контрольные испытания, ручное управление, байпас, аварийные сигналы и диагностика, должны быть идентифицированы как таковые и отделены от ФБ ПСБ;

x) следует обеспечить необходимые запасные входы/выходы, память и производительность обработки так, чтобы при будущих требованиях к модификации/расширению была возможность поддерживать ясность и способность для необходимого прикладного программирования;

y) диаграммы должны содержать перекрестные ссылки на местоположение многократного использования любого компонента ППО (например, входа, выхода, внутреннего регистра);

z) следует обеспечить соответствие порядка обработки в рамках ППО реакции в реальном времени.

 

Откройте актуальную версию документа прямо сейчас или получите полный доступ к системе ГАРАНТ на 3 дня бесплатно!

Получить доступ к системе ГАРАНТ

Если вы являетесь пользователем интернет-версии системы ГАРАНТ, вы можете открыть этот документ прямо сейчас или запросить по Горячей линии в системе.