Создание модели ПЛК для проектов АСПСиПТ

Разработка проекта по АСПСиПТ

Разработка проекта по АСПСиПТ состоит из 3 основных частей:

1. Анализ исходных данных и формирование замечания проектному институту при выявлениях несоответствиях.
2. Внесение исходных данных в xls файлы:
   • Модель плк
   • EventLists
   • ЗКПС
   • NetSwitches
3. Разработка программного обеспечения :
   • Unimod PRO 2
   • DevStudio
   • Alpha.HMI

1. Анализ исходных данных

Разработка любого проекта АСПСиПТ начинается с тщательного анализа входных данных. Цель данного этапа — своевременно выявить несоответствия в предоставленной документации и направить замечания проектной организации для их устранения.

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

1. Электрическая схема подключения оборудования

• Шифр документа: оканчивается на ZK 7510.001
• Описание: Разрабатывается сторонней проектной организацией. Схема отображает электрические соединения датчиков и исполнительных механизмов. Состав, наименования и количество устройств должны строго соответствовать структурной схеме и документу S6. Также должна быть обеспечена полная согласованность по последовательности подключения и адресации.

2. Структурная схема

• Шифр документа: оканчивается на ZX 7510.001
• Описание: Разрабатывается сторонней организацией. На данной схеме отображается последовательность датчиков и исполнительных механизмов с распределением по зонам. Является основным документом, используемым при проведении заводских приёмочных испытаний (ЗПИ), в ходе которых проверяется соответствие реализованного программного обеспечения утверждённой проектной документации.

3. Матрица причин и следствий

• Шифр документа: оканчивается на LN 7510.001
• Описание: Определяет логику работы каждой зоны контроля пожарной сигнализации, включая алгоритмы формирования сигнала «Пожар» и действия, выполняемые исполнительными механизмами (включение/отключение, открытие/закрытие и т.д.).

Согласно требованиям нормативного документа «Свод правил АСПСиПТ СП 484.1311500.2020», пункт 6.4, реализуются три типа алгоритмов принятия решения о пожаре:

• Алгоритм А: Должен выполняться при срабатывании одного ИП без осуществления процедуры перезапроса. В качестве ИП для данного алгоритма могут применяться ИП любого типа, при этом наиболее целесообразно применение ИПР.
• Алгоритм В: Должен выполняться при срабатывании автоматического ИП и дальнейшем повторном срабатывании этого же ИП или другого автоматического ИП той же ЗКПС за время не более 60 с, при этом повторное срабатывание должно осуществляться после процедуры автоматического перезапроса. В качестве ИП для данного алгоритма могут применяться автоматические ИП любого типа при условии информационной и электрической совместимости для корректного выполнения процедуры перезапроса.
• Алгоритм С: Должен выполняться при срабатывании одного автоматического ИП и дальнейшем срабатывании другого автоматического ИП той же или другой ЗКПС, расположенного в этом помещении.

При использовании адресных автоматических ИП и получении сигнала «Неисправность» от одного или нескольких адресных автоматических ИП в помещении допускается формировать сигнал «Пожар» при срабатывании одного адресного автоматического ИП.

При использовании безадресных автоматических ИП, подключенных в разные, но взаимозависимые линии связи одной ЗКПС, в случае наличия извещения о неисправности одной линии связи или нескольких из них допускается формировать сигнал «Пожар» при срабатывании одного безадресного автоматического ИП.

Важно

Количество извещателей, контролируемых одной ЗКПС, не должно превышать 32 единиц. Превышение допустимого количества является нарушением пункта 6.3.4 СП 484.1311500.2020 и требует выдачи замечания проектной организации.

4. Документ S6 – общий перечень сигналов для ПЛК

• Шифр документа: оканчивается на LN 7510.001
• Описание: Разрабатывается проектировщиками группы автоматизации (ГА). Содержит полный список дискретных и аналоговых сигналов, датчиков и исполнительных механизмов, включая информацию об адресации и порядке подключения. Все сигналы из этого документа подлежат обязательной интеграции в программу контроллера.

5. Спецификация оборудования, изделий и материалов

• Шифр документа: оканчивается на LB 7510.001
• Описание: Содержит перечень всего используемого оборудования с указанием типов, моделей и поставщиков. Является справочным документом для верификации состава системы.

Выявление и оформление расхождений

В случае выявления несоответствий между документами (например, расхождения между структурной и электрической схемами, дублирование тегов, отсутствие сигналов в матрице причин и следствий при их наличии в других документах), формируется пакет замечаний.

Формат замечания:

• Чёткое описание расхождения.
• Указание на нарушенный нормативный документ (при наличии).
• Приложение скриншотов или фрагментов документации с выделением проблемы.

Направление замечаний:

По документу S6	ТСБиМОТ / ОНН / СПГ	Васильев Михаил
	ГПЗ	Гашутин Илья
По исходным данным	ТСБиМОТ	Сидоров Игорь, Мамаев Олег
	ГПЗ	Матвеев Николай, Хатеев Артём
	ОНН	Соловьёв Александр
	СПГ	Северюхин Дмитрий

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

2. Разработка проекта

В системе контроля версий (SVN) выделяют следующие проекты:

• GPP_AFA – проекты под ГПЗ
• LNG_AFA – проект под СПГ
• PSaLA_MST_AFA – проекты под ТСБиМОТ и ОНН

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

• GPP_AFA - svn://nashgit.ru/automiq/Projects/GPP_AFA
• LNG_AFA – svn://nashgit.ru/automiq/Projects/LNG_AFA
• PSaLA_MST_AFA – svn://nashgit.ru/automiq/Projects/PSaLA_MST_AFA

После успешной выгрузки проекта на локальный компьютере появится папка с проектом.

Рассмотрим структуру на примере проекта PSaLA_MST_AFA (ТСБиМОТ).

Внутри проекта находятся следующие папки:

• JSC – основной пласт для разработки проекта. Здесь содержатся модели ПЛК, модели для базовых типов, лист событий для генерации подписей и наименований, ЗКПС, коммутаторы, результирующие файлы.

JSC
├── Conf (глобальный уровень)
│   ├── Models
│   │   └── ObjTypes
│   └── NetSwitches
└── USR
    └── PRJ (локальный уровень)
        ├── Conf
        │   ├── Models
        │   │   └── PLC
        │   │       ├── Logic
        │   │       └── CauseEffect
        │   ├── EventLists
        │   └── NetSwitches
        └── ResultFiles

3. Модель ПЛК

Модель ПЛК состоит из 17 основных листов (количество может варьироваться) и 8 вспомогательных (перед этими листами стоит @. Данный символ обозначает, что элемент (в данном случае лист) закомментирован и в разработке не принимает участие). Данные в каждом листе обрабатываются построчно, начиная со строки, где в первом столбце встречается буква d. По сути, d можно истолковывать как do - делать. Если в первом столбце будет написано @, то эта строка будет пропускаться для выполнения, если будет не заполнено, то будет переход на следующий лист.

Рассмотрим каждый лист подробнее.

1. PlcOptions

На данном листе необходимо заполнить следующие столбцы:

• opt.plcName - наименование ПЛК по проекту
• UnimodFolder – путь к проекту unimod, относительно структуры проекта. Если предполагается, что проект будет лежать внутри папки unimod, то достаточно указать эту папку, которая будет создана в дальнейшем или через знак «/», если будет более сложная структура.
• Description – наименование титула (Брать с ИД)

2. OBJ.PLC_Modules

Префикс OBJ на листах говорит о том, что объекты будут добавлены в глобальный словарь Unimod.

Столбец	Описание
ModuleId	Порядковый номер модулей. Берётся из КД или из S6.

Рисунок 1 - “Диагностический тег в S6”

Столбец	Описание
PathDevStudio	Путь для автоматического добавления объекта в devstudio. Для модулей ввода/вывода и ПЛК имеет вид: root.[Наименование шкафа].Diagnostic. Это типовой путь.
HmiTag	Название кадра для добавления объектов на верхний уровень. Соответствует наименованию шкафа.
ADDR_MOD	Адрес для модулей ввода/вывода ПЛК. Такой же адрес в дальнейшем необходимо будет выставить на физических модулях ПЛК в шкафу.
type	Тип модуля (например, UNIMOD2x_16DI).
TAG	Уникальный тег модуля.
parentDescr	Наименование модуля.
EqtDescr	Описание оборудования.
SystemPosition	Позиция модуля.
OBJTYPENAME	Тип объекта.
Template	Шаблон для типового объекта.
localObject	Идентификатор на каком уровне (глобальном или локальном) искать типовой объект. По умолчанию все объекты находятся на глобальном уровне.
isMapped	Идентификатор о необходимости выдавать данные на верхний уровень.
DeadbandDS	Зона нечувствительности по значению. Должен быть равен 1.
HistoryPeriodDS	Зона нечувствительности по времени. Должен быть равен 5000.
DataCategory	Категория данных.
Ip1	Основной IP-адрес первого сетевого интерфейса модуля.
IpRes1	Резервный IP-адрес первого сетевого интерфейса модуля.
Ip2	Основной IP-адрес второго сетевого интерфейса модуля.
IpRes2	Резервный IP-адрес второго сетевого интерфейса модуля.
NTP1	Основной сервер времени (NTP) для синхронизации.
NTP2	Резервный сервер времени (NTP) для синхронизации.
TZ	Часовой пояс.
SyncPeriod	Период синхронизации времени (мс).
ch1, ch2, …, ch32	Параметры каналов модуля. Содержат конфигурацию для каждого из 32 каналов (например, тип сигнала, фильтрацию и т.д.).

Расшифровка значений в столбцах ch1, ch2, …, ch32:

• 0 — Канал отключен.
• 1 — Канал настроен на вход 0-10 В.
• 2 — Канал настроен на вход 4-20 мА.
• 3 — Канал настроен на вход 0-20 мА.

Примечание

Возможные значения для столбца OBJTYPENAME — модели диагностики модулей и ПЛК, содержащие описания для OBJTYPENAME, расположены в каталоге JSC\Conf\Models\ObjTypes\Diagnostic\Unimod2\.

Значение OBJTYPENAME	Тип модуля	Описание	Применение
CPU_Diag_M1201E	Диагностика ПЛК	Модель типового объекта для диагностики контроллера M1201E.	Применяется для ПЛК серии Unimod 2 (M12xx).
CPU_Diag_M401E	Диагностика ПЛК	Модель типового объекта для диагностики контроллера M401E.	Применяется для ПЛК серии Unimod 2 (M4xx).
CPU_Diag_PLC	Диагностика ПЛК	Универсальная модель диагностики ПЛК.	Применяется для различных ПЛК, где не требуется специфичная диагностика.
CPUDiag_M501E	Диагностика ПЛК	Модель типового объекта для диагностики контроллера M501E.	Применяется для ПЛК серии Unimod 2 (M5xx).
M1231V	Аналоговый вход	Модуль аналогового ввода на 8 каналов 0-10 В, 0-20 мА, 4-20 мА.	Применяется для ПЛК серии Unimod 2 (M12xx).
M1245A	Аналоговый вход	Модуль аналогового ввода на 8 каналов 0-10 В, 0-20 мА, 4-20 мА.	Применяется для ПЛК серии Unimod 2 (M12xx).
M1251O	Дискретный выход	Модуль дискретного вывода на 16 каналов.	Применяется для ПЛК серии Unimod 2 (M12xx).
M1252D	Дискретный вход	Модуль дискретного ввода на 32 канала.	Применяется для ПЛК серии Unimod 2 (M12xx).
M1252DS	Дискретный вход	Модуль дискретного ввода на 32 канала с возможностью опроса по шлейфу (SLAN).	Применяется для ПЛК серии Unimod 2 (M12xx) в проектах АСПСиПТ.
M431V_v4_x2	Аналоговый вход	Модуль аналогового ввода на 8 каналов 0-10 В, 0-20 мА, 4-20 мА.	Применяется для ПЛК серии Unimod 2 (M4xx).
M441R_v3_x2	Резервный аналоговый вход	Резервная версия модуля M431V.	Применяется для ПЛК серии Unimod 2 (M4xx) в качестве резерва.
M445A_v3_x2	Аналоговый вход	Модуль аналогового ввода на 8 каналов 0-10 В, 0-20 мА, 4-20 мА.	Применяется для ПЛК серии Unimod 2 (M4xx).
M451O_v2_x2	Дискретный выход	Модуль дискретного вывода на 16 каналов.	Применяется для ПЛК серии Unimod 2 (M4xx).
M452D_v3_x2	Дискретный вход	Модуль дискретного ввода на 32 канала.	Применяется для ПЛК серии Unimod 2 (M4xx).
M548A_PLC	Аналоговый вход	Модуль аналогового ввода на 16 каналов 0-10 В, 0-20 мА, 4-20 мА.	Применяется для ПЛК серии Unimod 2 (M5xx).
M551OS_v3_PLC	Дискретный выход	Модуль дискретного вывода на 16 каналов.	Применяется для ПЛК серии Unimod 2 (M5xx).
M551OS_v4_PLC	Дискретный выход	Модуль дискретного вывода на 16 каналов.	Применяется для ПЛК серии Unimod 2 (M5xx).
M552D_v4_PLC	Дискретный вход	Модуль дискретного ввода на 32 канала.	Применяется для ПЛК серии Unimod 2 (M5xx).
M552D_v5_PLC	Дискретный вход	Модуль дискретного ввода на 32 канала.	Применяется для ПЛК серии Unimod 2 (M5xx).
M558D_PLC	Дискретный вход	Модуль дискретного ввода на 32 канала.	Применяется для ПЛК серии Unimod 2 (M5xx).
M558O_PLC	Дискретный выход	Модуль дискретного вывода на 32 канала.	Применяется для ПЛК серии Unimod 2 (M5xx).
M558O_v2_PLC	Дискретный выход	Модуль дискретного вывода на 32 канала.	Применяется для ПЛК серии Unimod 2 (M5xx).

MB.TcpDevs

Префикс MB на листе указывает, что данные с этого листа будут в дальнейшем использованы для формирования связи Modbus в среде Unimod 2.

Рисунок 2 - “Пример листа MB.TcpDevs”

Данные для этого листа формируются на основе структурной схемы или КД (в зависимости от того, кто раньше выпустит документ). При этом структурная схема должна быть согласована с КД, которую формируют проектировщики группы автоматизации (ГА).

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

Рисунок 3.2 – Пример структурной схемы

Ключевые столбцы листа MB.TcpDevs

Столбец	Описание
modbus.gate	Имя шлюза Modbus (в Unimod). Формируется как PIxxx_yyy (номер преобразователя + порт). Заполняется только в случае, если на один контакт преобразователя подключается более одного устройства. Например, PI002_502.
modbus.name	Имя устройства в Unimod (например, KAU2_9030, MOPS3). Это фактическое наименование подключаемого оборудования и его порядковый номер. Можно брать из структурной схемы.
TAG	Уникальный тег оборудования. Будет использоваться внутри глобального словаря и программах. Формируется как наименование_шкафа + имя_устройства. В теге не должно быть кириллических символов и знаков «-». Только нижнее подчёркивание (_).
iTCPAddr_1, iTCPAddr_2, iTCPAddr_3, iTCPAddr_4	IP-адрес преобразователя (основной). Берётся из IP-карты проекта.
modbus.ipPort	Основной порт Modbus. Нумерация портов начинается с 502. У каждого подключения будет свой порт с наращиванием на 1 (кроме случаев, когда на один порт заводится несколько устройств).
iTCPAddrReserv_1, iTCPAddrReserv_2, iTCPAddrReserv_3, iTCPAddrReserv_4	Резервный IP-адрес преобразователя. Берётся из IP-карты проекта.
modbus.ipPortRes	Резервный порт Modbus. Нумерация должна быть такой же, как и у основного порта.
Slave	Адрес устройства, который физически будет выставлен на устройстве и сконфигурирован в преобразователе интерфейсов. В проекте принято нумеровать адрес начиная с 1 с шагом 1, если на 1 канал подключается 1 устройство, и сквозную нумерацию, если на 1 канал подключается несколько устройств.
%JSC%\Conf\Models\System\Modbus\Devices\$S\Frames$S.xls	Путь к файлу с описанием фреймов (запросов) для оборудования. Для КАУ-2 это KAU2_9030, для МОПС — Mops3Ext, для МУПС — MUPS3. Переменная $S подменяется на имя файла без расширения.

Примечание: Листы с описанием фреймов (например, FramesKAU2_9030.xls) находятся в каталоге JSC\Conf\Models\System\Modbus\Devices\.

4. OBJ.TechObject

Данный лист заполняется адресными датчикам и исполнительными механизмами, которые подключаются КАУ. Для заполнения используется документ S6, при его отсутствии заполнять необходимо на основе электрической схемы подключения.

Рисунок 4.1 – Пример листа OBJ.TechObject

Столбец	Описание
PathDevStudio	Путь для автоматического добавления объекта в devstudio. Для оборудования в помещении: root.[Наименование титула].[Окончание наименования шкафа].Zone_[Номер зоны].Room_[Номер помещения] Пример: root.M0_85_050.JF_CA_1001.Zone_1.Room_104 Для оборудования в шкафу: Путь совпадает с путем для модулей ввода/вывода, например, root.M0_85_050.JF_CA_1001.Diagnostic.
HmiTag	Название кадра для добавления объектов на верхний уровень. Для оборудования в помещении: root.[Наименование титула].Zone_[Номер зоны] Пример: root.M0_85_050.Zone_1 Для оборудования в шкафу: Путь совпадает с HmiTag для модулей ввода/вывода, например, M0_85_050.Diagnostic.
TAG	Уникальный тег объекта. Тег для КАУ должен быть таким же, как и в листе MB.TcpDevs. Для устройств, подключенных к КАУ, тег берется из документа S6 (при наличии) или из электрической схемы. В теге не должно быть кириллических символов и знаков «-». Только нижнее подчёркивание (_).
parentDescr	Наименование оборудования. • BTM – извещатель ручной • BTH – извещатель дымовой • BTF – извещатель пламени • BTK – извещатель тепловой • BGB – извещатель магнитоконтактный • BIAL – оповещатель световой (L – LIGHT) • BIAS – оповещатель звуковой (S – SOUND) • BIALS – оповещатель свето-звуковой • SIB – устройство дистанционного пуска • IZ/BR – изолятор шлейфа • FCL/AR – Релейный модуль • MDU – модуль дымоудаления
EqtDescr	Описание оборудования.
SystemPosition	Позиция (например, 1).
OBJTYPENAME	Тип объекта. Определяется по таблице соответствия ниже.
Template	Шаблон для типового объекта. Выбирается в соответствии с типом объекта и требуемой функциональностью (например, main, IPR, UDP, main_warn).
InstallPlace	Место установки. Применяется только для дымовых извещателей (BTH). Определяется по матрице причин и следствий.
Type	Тип датчика. Необходим для корректного отображения символа на HMI.
localObject	Идентификатор на каком уровне (глобальном или локальном) искать типовой объект. По умолчанию все объекты находятся на глобальном уровне.
isMapped	Идентификатор о необходимости выдавать данные на верхний уровень.
DeadbandDS	Зона нечувствительности по значению. Должен быть равен 1.
HistoryPeriodDS	Зона нечувствительности по времени. Должен быть равен 5000.
DataCategory	Категория данных. Оставлять не заполненным.

Таблица соответствия типовых блоков и оборудования:

Типовой блок	Оборудование	Шаблон	Комментарий
AMP_LOOP_0_PLC	АМП-4-R3 (ШС), АМП-10-R3 (ШС)	main_ala, main_warn	Шаблоны отличаются уровнем логирования (предупреждение/авария).
AMP_RM_0_PLC	АМП-4-R3 (РМ), АМП-10-R3 (РМ)	main
AMP_RMK_0_PLC	АМП-4-R3 (РМ-К), АМП-10-R3 (РМ-К)	main
AM_0_PLC	АМ-1-R3, АМ-4-R3	main_ala, main_warn	Шаблоны отличаются уровнем логирования (предупреждение/авария).
AnMon2_PLC	Аналоговый сигнал	main	Используется для температуры шкафа.
CAUSE_EFFECT_A_PLC	Алгоритм А	main, ext
CAUSE_EFFECT_B_PLC	Алгоритм B	main
CAUSE_EFFECT_C_PLC	Алгоритм С	main
DI_MOPS	Дискретный сигнал, подключенный к МОПСу	main
DiMon1_PLC	Дискретный сигнал для диагностики шкафа (высокая температура, питание, дверь открыта)	main
DO_CC_PLC	Дискретный сигнал, подключенный к МУПСу	main
FB_FACP_PLC	Блок управления УПИ	main
FireFighting_PLC	Блок пожаротушения	main	Используется при отсутствии в проекте МПТ.
IO10220_0_PLC	ИО 10220-2 (СМК)	main
IZ_0_PLC	ИЗ-1-R3	main
KAU2_9030_PLC	КАУ-2-9030-R3	main
ManualCallPoint_1_PLC	ИПР 513-11-R3, УДП 513-11-R3, ИП 535-1В Ех, УДП-1 Ех	IPR, UDP	Выбрать шаблон в зависимости от типа (ИПР или УДП).
ManualCallPoint_2_PLC	ИПР 513-11ИКЗ-А-R3, УДП 513-11ИКЗ-R3	IPR, UDP	Выбрать шаблон в зависимости от типа (ИПР или УДП).
Mops3_PLC	МОПС3	main
MPT_PLC	МПТ-1-R3	main
Mups3_PLC	МУПС3	main
Notifier_0_PLC	Оповещатели, подключенные к МУПСу	main
Notifier_1_PLC	ОПОП1-R3, ОПОП-124-R3	main
RCM_0_PLC	МДУ-1-R3, МДУ-1С-R3	main
RelayModule_0_PLC	РМ-1-R3, РМ-4-R3, РМ-1КЕх	main	Для РМ-1КЕх отсутствует сигнал “Ток нагрузки выходит за допустимые пределы”.
RM_1K_PLC	РМ-1К-R3, РМ-4К-R3	main
SpotDetector_1_PLC	ИП 212-64-R3, ИП 212/101-64-PR-R3, ИП 101-29-PR-R3, ИП-212-Ех	main_ala, main_warn	Шаблоны отличаются уровнем логирования (предупреждение/авария).
TULIP_64_2_EX_PLC	Тюльпан ИК+УФ, Тюльпан ИК, Тюльпан ИК Ex	main_ala, main_warn	Подходит для всех видов “Тюльпанов”. Различие в неиспользуемых битах.
UPS_IVEPR_1_PLC	ИВЭПР 24/2,5 – RS-R3, ИВЭПР 24/3,5 – RS-R3, ИВЭПР 24/5 – RS-R3	main
TriggerLockingDev_PLC	ЗПУ	main	Отличие от DO_CC_PLC — отсутствует управление от оператора.

Примечание: Значение столбца Template должно соответствовать выбранному OBJTYPENAME согласно таблице выше.

Значение столбца InstallPlace применимо только для дымовых извещателей (BTH) и определяется по матрице причин и следствий.

Рисунок 4.2 – Пример определения места установки

5. OBJ.KGPA

Данный лист заполняется исполнительными механизмами, которые подключаются к МУПСам, а также на этом листе объявляются МОПСы (при этом оборудование, которое подключается к МОПСам, заполняется на другом листе). Для заполнения используется документ S6, при его отсутствии заполнять необходимо на основе электрической схемы подключения. Удобнее всего заполнять по-канально.

Столбец	Описание
PathDevStudio	Путь для автоматического добавления объекта в devstudio. Формируется как root.[Название основного титула].[Окончание наименования шкафа].PAGA Пример: root.M0_85_050.JF_CA_1001.PAGA Для оборудования, располагаемого в шкафу, путь будет таким же, как для модулей ввода/вывода.
HmiTag	Название кадра для добавления объектов на верхний уровень. Для оборудования в шкафу: Путь совпадает с HmiTag для модулей ввода/вывода. Для устройств: root.[Название титула].PAGA.
TAG	Уникальный тег устройства. Тег для МУПСа должен быть таким же, как и в листе MB.TcpDevs. Для устройств, подключенных к МУПСу, тег берется из документа S6 (при наличии) или из электрической схемы. В теге не должно быть кириллических символов и знаков «-». Только нижнее подчёркивание (_).
parentDescr	Наименование оборудования. • BIAL – оповещатель световой (L – LIGHT) • BIAS – оповещатель звуковой (S – SOUND) • BIALS – оповещатель свето-звуковой
EqtDescr	Описание оборудования.
SystemPosition	Позиция (например, 1).
OBJTYPENAME	Тип объекта. Определяется по таблице соответствия ниже.
Template	Шаблон для типового объекта. Выбирается в соответствии с типом объекта.
InstallPlace	Место установки. Не заполняется.
Type	Тип датчика. Необходим для корректного отображения символа на HMI.
localObject	Идентификатор на каком уровне (глобальном или локальном) искать типовой объект. По умолчанию все объекты находятся на глобальном уровне.
isMapped	Идентификатор о необходимости выдавать данные на верхний уровень.
DeadbandDS	Зона нечувствительности по значению. Должен быть равен 1.
HistoryPeriodDS	Зона нечувствительности по времени. Должен быть равен 5000.
DataCategory	Категория данных. Оставлять не заполненным.

Таблица соответствия типовых блоков и оборудования:

Типовой блок	Оборудование	Шаблон	Комментарий
DO_CC_PLC	Дискретный сигнал, подключенный к МУПСу	main
Mops3_PLC	МОПС3	main
Mups3_PLC	МУПС3	main
Notifier_0_PLC	Оповещатели, подключенные к МУПСу	main
TriggerLockingDev_PLC	ЗПУ	main	Отличие от DO_CC_PLC в том, что нет управления от оператора.

6. OBJ.DI_MOPS

Данный лист заполняется сигналами, которые приходят на дискретный модуль входа. Для заполнения используется документ S6, при его отсутствии заполнять необходимо на основе КД.

Столбец	Описание
PathDevStudio	Путь для автоматического добавления объекта в devstudio.
HmiTag	Название кадра для добавления объектов на верхний уровень.
TAG	Уникальный тег устройства. Берётся из S6 (при наличии), а в её отсутствии из электрической схемы подключения. В теге не должно быть кириллических символов и знаков «-». Только нижнее подчёркивание (_).
Inverse	Необходимость инвертирования сигналов. Для сигналов от МОПСа это не требуется.
parentDescr	Наименование оборудования.
EqtDescr	Описание оборудования.
SystemPosition	Позиция (например, 1).
OBJTYPENAME	Тип объекта. Для оборудования, подключённого к МОПСам, всем ставится DI_MOPS.
Template	Шаблон для типового объекта. Ставится main.
InstallPlace	Место установки. Не заполняется.
Type	Тип датчика. Необходим для корректного отображения символа на HMI.
Label	Метка событий. Для обычных событий выбирается bit_coming. Для событий от оператора — cmdComing. В данном случае метка всегда будет bit_coming.
AlarmLevel	Уровень аварий.
localObject	Идентификатор на каком уровне (глобальном или локальном) искать типовой объект. По умолчанию все объекты находятся на глобальном уровне.
isMapped	Идентификатор о необходимости выдавать данные на верхний уровень.

Краткое описание уровней аварий (AlarmLevel):

• Alarm: Авария — критическое состояние, требующее немедленного вмешательства. Требует квитирования.
• WarningHi, WarningLo: Предупреждение — состояние, приближающееся к аварийному. Требует внимания оператора. Требует квитирования.
• Invalid: Недостоверность — сигнал не может быть доверен (например, обрыв линии). Требует квитирования.
• Fault: Неисправность — техническая неисправность оборудования. Требует квитирования.
• Process: Событие процесса — информационное сообщение о нормальном ходе технологического процесса. Не требует квитирования.
• Maintenance: Ремонт — оборудование находится в режиме обслуживания. Не требует квитирования.
• extCmd: Внешняя команда — сигнал, инициированный оператором. Не требует квитирования.
• Imitation: Симуляция — сигнал находится в режиме тестирования. Не требует квитирования.

7. OBJ.DI

Данный лист заполняется сигналами, которые приходят на дискретный модуль входа. Для заполнения используется документ S6, при его отсутствии заполнять необходимо на основе КД.

Столбец	Описание
ModuleId	Порядковый номер модуля. Должен соответствовать номеру, который был указан в листе OBJ.PLC_Modules.
Channel	Канал модуля, на который будет приходить сигнал (например, DI0, DI1).
PathDevStudio	Путь для автоматического добавления объекта в devstudio. Формируется как root.[Наименование титула].[окончание наименования шкафа].Diagnostic.DI Пример: root.M0_85_050.JF_CA_1001.Diagnostic.DI
HmiTag	Название кадра для добавления объектов на верхний уровень. Формируется как [Наименование титула].DI Пример: M0_85_050.DI

Рисунок 5 – Диагностический тег в настройках

Столбец	Описание
TAG	Уникальный тег сигнала. Пример: M0_85JEXA5401
parentDescr	Наименование сигнала.
EqtDescr	Описание оборудования.
SystemPosition	Позиция (например, 1).
Inverse	Необходимость инверсии. Необходимо для сигналов: “Неисправность питания”, “Высокая температура”, “ИБП (1/2/3) Неисправность АКБ”.
OBJTYPENAME	Тип объекта. Всегда будет использоваться DiMon1_PLC.
Template	Шаблон для типового объекта. Всегда будет использоваться main.
Label	Метка. Всегда будет использоваться bit_coming.
AlarmLevel	Уровень аварий. В зависимости от того, за что сигнал отвечает, уровень аварии может быть различным. Если это информационный сигнал, то уровень аварий будет Process, если ошибка/неисправность – WarningHi, если пожар – Alarm.
localObject	Идентификатор на каком уровне (глобальном или локальном) искать типовой объект. По умолчанию все объекты находятся на глобальном уровне.
isMapped	Идентификатор о необходимости выдавать данные на верхний уровень.
DeadbandDS	Зона нечувствительности по значению. Должен быть равен 1.
HistoryPeriodDS	Зона нечувствительности по времени. Должен быть равен 5000.
DataCategory	Категория данных. Оставлять не заполненным.

Внимание

Наименование сигналов в документе S6 не соответствует наименованиям внутри модели ПЛК. Это сделано намеренно для привлечения внимания оператора к важным событиям.

8. OBJ.DO

Данный лист заполняется сигналами, которые приходят на дискретный модуль выхода. Для заполнения используется документ S6, при его отсутствии заполнять необходимо на основе КД.

Столбец	Описание
ModuleId	Порядковый номер модуля. Должен соответствовать номеру, который был указан в листе OBJ.PLC_Modules.
Channel	Канал модуля, на который будет приходить сигнал (например, DO0, DO1).
PathDevStudio	Путь для автоматического добавления объекта в devstudio. Формируется как root.[Наименование титула].[окончание наименования шкафа].Diagnostic.DO Пример: root.M0_85_050.JF_CA_1001.Diagnostic.DO
HmiTag	Название кадра для добавления объектов на верхний уровень. Формируется как [Наименование титула].DO Пример: M0_85_050.DO
TAG	Уникальный тег сигнала. Пример: M0_851HL15401

Рисунок 7.1 – Тег DO в S6

Столбец	Описание
ActivateTag	Служит для автоматической привязки между блоком УПИ (FB_FACP_PLC) и дискретным выходом.

Рисунок 7.2 – ActivateTag в модели

Столбец	Описание
parentDescr	Наименование сигнала.
EqtDescr	Описание оборудования.
SystemPosition	Позиция (например, 1).
Inverse	Необходимость инверсии. В данном случае она не нужна.
OBJTYPENAME	Тип объекта. Всегда будет использоваться DiMon1_PLC.
Template	Шаблон для типового объекта. Всегда будет использоваться do.
Label	Метка. Не заполняется.
AlarmLevel	Уровень аварий. Не заполняется.
localObject	Идентификатор на каком уровне (глобальном или локальном) искать типовой объект. По умолчанию все объекты находятся на глобальном уровне.
isMapped	Идентификатор о необходимости выдавать данные на верхний уровень.
DeadbandDS	Зона нечувствительности по значению. Должен быть равен 1.
HistoryPeriodDS	Зона нечувствительности по времени. Должен быть равен 5000.
DataCategory	Категория данных. Оставлять не заполненным.

9. OBJ.AI

Данный лист заполняется сигналами, которые приходят на аналоговый модуль входа. Для заполнения используется документ S6, при его отсутствии заполнять необходимо на основе КД.

Столбец	Описание
ModuleId	Порядковый номер модуля. Должен соответствовать номеру, который был указан в листе OBJ.PLC_Modules.
Channel	Канал модуля, на который будет приходить сигнал (например, AI0, AI1).
PathDevStudio	Путь для автоматического добавления объекта в devstudio. Формируется как root.[Наименование титула].[окончание наименования шкафа].Diagnostic.AI Пример: root.M0_85_050.JF_CA_1001.Diagnostic.AI
HmiTag	Название кадра для добавления объектов на верхний уровень. Формируется как [Наименование титула].AI Пример: M0_85_050.AI
TAG	Уникальный тег сигнала. Пример: M0_85JTI5401

Рисунок 7.3 – Тег AI в S6

Столбец	Описание
parentDescr	Наименование сигнала.
EqtDescr	Описание оборудования.
SystemPosition	Позиция (например, 1).
Inverse	Необходимость инверсии. В данном случае она не нужна.
OBJTYPENAME	Тип объекта. Всегда будет использоваться AiProc1 для внутренней диагностики температуры шкафа.
Template	Шаблон для типового объекта. Всегда будет использоваться 4_20AFA для внутренней диагностики температуры шкафа.
UnitsIO	Единицы измерения на входе (MV). Заполняется входными единицами измерения. В данном случае mA.
Units	Преобразованные единицы измерения (PV). В данном случае C (градусы Цельсия).
ScaleLow	Нижняя граница шкалы преобразования. В данном случае для температуры шкафа равна -50.
ScaleHigh	Верхняя граница шкалы преобразования. В данном случае для температуры шкафа равна 50.
Hyst	Гистерезис. Должен быть равен 2.
Speed	Уставка скорости изменения параметра. Должна быть равна 95.
TimeThs	Уставка времени сработки порогов сигнализации. Должна быть равна 0.5.
LL	Нижняя аварийная уставка (Low Low). Должна быть равна 10.
L	Нижняя предупредительная уставка (Low). Должна быть равна 15.
H	Верхняя предупредительная уставка (High). Должна быть равна 30.
HH	Верхняя аварийная уставка (High High). Должна быть равна 40.
localObject	Идентификатор на каком уровне (глобальном или локальном) искать типовой объект. По умолчанию все объекты находятся на глобальном уровне.
isMapped	Идентификатор о необходимости выдавать данные на верхний уровень.
DeadbandDS	Зона нечувствительности по значению. Должен быть равен 1.
HistoryPeriodDS	Зона нечувствительности по времени. Должен быть равен 5000.
DataCategory	Категория данных. Оставлять не заполненным.

10. OBJ.CauseEffects

Данный лист заполняется перечнем зон контроля пожарной сигнализации (ЗКПС), которые находятся в документе “Матрица причин и следствий”.

Столбец	Описание
PathDevStudio	Путь для автоматического добавления объекта в devstudio. Формируется как root.[Наименование титула].[окончание наименования шкафа].[Зона] Пример: root.M0_85_050.JF_CA_1001.Zone_1
GroupPou	Не заполняется.
HmiTag	Название кадра для добавления объектов на верхний уровень. Формируется как root.[Наименование титула].[Зона] Пример: root.M0_85_050.Zone_1 Примечание: Для зоны HmiTag должен быть таким же, как и в листе OBJ.TechObject.
TAG	Уникальный тег сигнала. Формируется самостоятельно разработчиками. Состоит из наименования титула и номера зоны. Пример: M0_85_050_ZKPS1
parentDescr	Наименование зоны (например, Зона 1).
EqtDescr	Описание оборудования.
SystemPosition	Позиция (например, 1).
OBJTYPENAME	Тип объекта. В зависимости от алгоритма принятия решения о пожаре выбирается один из трех типов: CAUSE_EFFECT_A_PLC, CAUSE_EFFECT_B_PLC, CAUSE_EFFECT_C_PLC. Выбор определяется по матрице причин и следствий.

Рисунок 7.4 – Выбор алгоритма пожаротушения

Столбец	Описание
Template	Шаблон для типового объекта. Всегда используется main для явно объявленного типа алгоритма.
DisOnZeroAlarms	Идентификатор, который позволяет осуществлять автоматический сброс при отсутствии пожаров. По умолчанию выставляется FALSE.
ActLimitSp	Уставка срабатывания. В матрице причин и следствий это первая цифра в столбце “Мажоритарная логика”.
WaitTime	Время ожидания (сек). Используется для алгоритма B. По умолчанию заполняется цифрой 20.
SensorsCnt	Общее количество датчиков в зоне. Ручные извещатели (ИПР) в этот счетчик не включаются.
localObject	Идентификатор на каком уровне (глобальном или локальном) искать типовой объект. По умолчанию все объекты находятся на глобальном уровне.
isMapped	Идентификатор о необходимости выдавать данные на верхний уровень.
DeadbandDS	Зона нечувствительности по значению. Должен быть равен 1.
HistoryPeriodDS	Зона нечувствительности по времени. Должен быть равен 5000.
DataCategory	Категория данных. Оставлять не заполненным.

Примечание: В этот лист также вносятся вспомогательные блоки (например, для логики УПИ), которые не будут выдаваться на верхний уровень, но необходимы для формирования полной логики ПЛК.

11. CE.CauseEffects_ZKPS

Префикс CE на листе указывает, что он используется для формирования программ причинно-следственных связей (Cause-Effect) на основе матрицы причин и следствий.

Столбец	Описание
causeEffectTag	Имя зоны контроля пожарной сигнализации (ЗКПС), объявленной на листе OBJ.CauseEffects. Заполняется в ячейки с коричневым фоном (причина).
conditionTag	Теги датчиков, участвующих в формировании причины (например, M0_85_050_FA_BTH_001). Заполняется в ячейки с коричневым фоном (причина).

Рисунок 7.5 – Матрица ПСД, причины

Столбец	Описание
condFire	Сигнал активации пожара. Заполняется значением AFA_Output.DeviceTriggered в ячейки с коричневым фоном (причина).
condFault	Сигнал неисправности. Заполняется значением AFA_Output.Fault в ячейки с коричневым фоном (причина).
conInvalid	Сигнал недостоверности. Заполняется значением AFA_Output.Invalid в ячейки с коричневым фоном (причина).
condCommFailure	Сигнал обрыва связи. Заполняется значением AFA_Output.CommFailure в ячейки с коричневым фоном (причина).
destination	Результат выполнения условий причинно-следственной связи. В ячейки со светлым фоном вносятся теги исполнительных механизмов, на которые должна подаваться команда (например, AutoOnCmd, AutoCloseCmd).

Алгоритм заполнения:

• В столбец causeEffectTag (коричневый фон) вносится наименование ЗКПС, объявленное на листе OBJ.CauseEffects.
• В столбец conditionTag (коричневый фон) вносятся все датчики, относящиеся к этой ЗКПС по матрице причин и следствий.

Рисунок 7.6 – Матрица ПСД, следствия

• Столбцы condFire, condFault, conInvalid, condCommFailure заполняются соответствующими сигналами в ячейках с коричневым фоном.
• В столбец destination (светлый фон) вносятся все исполнительные механизмы, на которые должна быть подана команда при срабатывании причины (в матрице это механизмы с буквой “А”).

Данный алгоритм повторяется для каждой зоны контроля пожарной сигнализации.

12. CE.CauseEffects_UPI

Данный лист служит для формирования логики управления панелью оповещения (УПИ).

Столбец	Описание
causeEffectTag	Наименование титула (например, M0_85_050).
causeEffectFb	Формирование тега для глобального словаря по одной из задач: • ATTENTION – Внимание • FIRE – Пожар • FAULT – Неисправность • REPAIR – Обслуживание • POWER – Питание
conditionTag	Теги датчиков или сигналов, формирующих причину для соответствующей задачи.
condFire	Сигнал активации пожара (например, Activated, Attention).
condFault	Сигнал неисправности (например, Act).
conInvalid	Сигнал недостоверности.
condCommFailure	Сигнал обрыва связи.
destination	Результат выполнения условий (не используется для УПИ).

Правила заполнения по задачам:

• ATTENTION: Вносятся все зоны контроля пожарной сигнализации (ЗКПС), которые имеют алгоритм B или C с условием condFire = Attention (для алгоритма C) или ActWhenAny (для алгоритма B).
• FIRE: Вносятся все алгоритмы ЗКПС, которые были объявлены в матрице причин и следствий с условием condFire = Activated.
• FAULT: Вносятся дискретные сигналы от контроллера (CE_FACP) по высокой температуре, неисправности ИБП, а также модули ввода/вывода. Затем, по каждому титулу (например, CE_FACP_85_050), вносятся все датчики и исполнительные механизмы, которые есть у этого титула.
• REPAIR: Вносятся все датчики и исполнительные механизмы, которые есть у титула.
• POWER: Вносятся дискретные сигналы от контроллера (CE_FACP) по неисправности питания и работе от ИБП.