RAZRAB.RU

РД 50-34.698-90 писал(а):5.6. Описание систем классификации и кодирования
Документ содержит перечень применяемых в АС зарегистрированных классификаторов всех категорий по каждому классифицируемому объекту, описание метода кодирования, структуры и длины кода, указания о системе классификации и другие сведения по усмотрению разработчика.

Вобщем, решил сделать анализ существующих систем кодирования (отраслевых, международных, корпроативных, своих). Только вот особо ничего не нашел кроме "ISA 5.1-2009 Instrumentation Symbols and Identification". Интересуют следующие вопросы:
1) зависит ли (как) система кодирования от типа объекта (тех. процесс, эелектротехника, АВОК .... )
2) зависит ли (как) система от типа обородувания/софта;
3) меняется ли система в процессе схемаТипаХ-схемаТипаY-маркировка_оборудования-PLC(DCS)-SCADA/HMI и если нет, то как вы "протягиваете" всю систему через все информационные потоки.
Спасибо.

Нащупал вот этот документ
Берём пункт 3.6.4. Я то понимаю, что DCS не для тонких кошельков, но можно эти же правила перенести на PLC+SCADA.
Два варианта названия: 110FICA-101-FE и 110FE-101
Да я бы чёкнулся,наверное, колупаясь в программе ПЛК или СКАДе, где бы использовались такие названия переменных/тегов.
Допустим префикс 110 по ихним же стандартам (ISA) можно поменять на символьное имя оборудования, например "T110" для танка или "PAST1" для пастеризатора. Получится типа такого:
PAST1-FICA-101-FE и T110-FE-101
Контур 101 тоже бы заменил на что-то символьное: mlk, wtr...
PAST1-FICA-mlk-FE и PAST1-FE-wtr
2-й вариант вроде получается где-то так как и называем. Если добавить туда суффиксы SP (уставка), Kp, Ti, Td то получается какой-то микс
PAST1_FE_wtr_SP, PAST1_FC_wtr_Kp, PAST1_FC_wtr_Ti
Неотмасштабированые значения были бы какими то такими:
PAST1_FE_wtr_raw
Но помнится в одной из фирм, где пришлось подрабатывать на ПНР, все контуры имели номера, по этому меня смущает символьный подход. Чем он плох?

san писал(а):Да я бы чёкнулся,наверное, колупаясь в программе ПЛК или СКАДе, где бы использовались такие названия переменных/тегов.

Я использую нотацию ГОСТ 2.710

И тэги соответственно такие же как в схеме: KM1, YA4, SB15, SA7, SQ3 и т.д.

Михайло писал(а):Я использую нотацию ГОСТ 2.710. И тэги соответственно такие же как в схеме: KM1, YA4, SB15, SA7, SQ3 и т.д.

Для АСУТП это не
подойдёт, разве что в контурах управления двигателями. Или получается и для АСУТП?

Я думаю, что все-таки все зависит от системы документации, которая применяется, а та - от специфики производства. Если говорить прямо, то мы АСУ не разрабатываем. Так - локальные установочки...

Михайло писал(а):Я думаю, что все-таки все зависит от системы документации, которая применяется, а та - от специфики производства. Если говорить прямо, то мы АСУ не разрабатываем. Так - локальные установочки...

Но операторские панели там есть? Как на панелях оборудование обозначается, как в электрической принципиалке?

Да, панели бывают. Но, как правило, панель не работает напрямую с оборудованием, так как есть посредник в виде ПЛК. При чем, чтобы постоянно не перепрошивать проект в панели, желательно не использовать тэги из схемы электрической принципиальной. Все, потому что сегодня лампочка на панели горит от путевого выключателя, а завтра она будет еще подмигивать при аварийной ситуации, то есть тэг лампы уже не соответствует тэгу путевого выключателя - приходится перепрошивать. Но все же несколько тэгов проскакивает и они обозначаются как железо на Э3.

Пробовали KKS, ну недели две на освоение ушло, в принципе удобно. Но, что-то не прижилось в отечественной энергетике.
Еще, очень понравились норвежские рекомендации Norsok, так как это единственный документ в котором есть рекомендации по кодировке внутренних тегов )))

Спасибо CHANt, вот помню что была такая, но с каким названием забыл. Там ещё IEC 61346 рядом, будет что анализировать.
------------час спустя-------------
О KKS нашёл что-то на русском, а вот IEC 61346 - только за грошики
----------ещё 10 мин спустя-------------------------------------
Беглый осмотр KKS привел меня к выводу, что для АСУТП он не очень годится, а заточен только для АСУ в энергетике. Но где-то читал что IEC 61346 более универсален, никто не сталкивался?

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

Лампа ж горит по функциональному признаку? Тогда получается функциональное обозначение более универсальное.

Пока сколько пробовал, остановился на двойной кодировке: входа-выхода именуются по схеме /типа SQ1.1, KM2; тепловые реле именуются как KMx - управление реле, KMx_temp - признак срабатывания/. Внутренние переменные несут более-менее функциональное обозначение /например, PressUp, Pusher1Forward и т.п./.
Может, конечно, и не прав, но...

И тут посмотрел, как один товарищ провода в проекте промаркировал, так в бешенном восторге: структура номера XX-XXX. Первые две цифры - группа. Например, 10 - фаза A, 20 - плюс источника 1, 40 - аналоговые входа, 50 - цифровые входа и т.д. Вторые три цифры - номер в группе. Глядя на схему сразу понятно, что провод 21-102 - 102-й провод, присобаченный к минусу источника 1, а провод 51-001 - 001 провод цифрового выхода /именно первый; на S7-200 это будет выход Q0.0/. Удобно - на номер глянул и сразу многое стало понятно за функционал провода.

Степа писал(а): Удобно - на номер глянул и сразу многое стало понятно за функционал провода.

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

Кодирую внешние сигналы как Михайло - по обозначению в схеме электрической принципиальной.

По внутренним переменным контроллера еще не до конца определился. Есть постоянно используемые переменные State, Control, Auto и т.п. с устоявшимся функциональным значением. Остальные переменные в последнее время тоже стараюсь делать однотипными Com1,Com2... (аналог промежуточного реле в релейной схеме: K1, K2... ). Выдумывать сокращения и аббревиатуры трудно, а потом тяжело вспомнить-расшифровать.

На курсах по Step7 советовали:
добавлять в начало:
i_ - для входных переменных
o_ - для выходных
t_ - для временных
io_ - для переменных вход-выход
добавлять в конец тип переменной:
_i - integer
_d - dword
_w - word
_r - real

i_Speed_d - входная переменная типа двойное целое

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

Михайло писал(а):На это смотришь единственный раз в жизни - когда составляешь таблицу символов, потом забываешь как в страшном сне.

Если ты живешь по принципу "сделал-сдал-забыл" - вполне согласен. У меня так не получается. Все равно спустя некоторое время приходится появиться около собственной разработки /а из рабочих моих разработок самой старой, как я говорил, уже лет 15/ и разбираться, что случилось, почему, как устранить. И начинаешь ценить любую помощь в разбирательстве. Если какая-то мелочь экономит секунду времени работы ремонтника или обслуживающего, то за нормативных в машиностроении времени жизни оборудования 5-7 лет /и обычных у нас 15-25/, такая мелочь даст десятки часов дополнительного времени работы оборудования. И цена выигрыша тут - несравненно выше потраченных конструкторами лишних пары минут на написание более длинного обозначения.
Кстати, подход здорово виден в компоновочных решениях. Если конструктор не способен думать за обслуживание, там такое выходит... Скажем, в жизни у меня в обслуживании был станок. Так чтобы там снять привод /массой килограмм 20-30/ для ремонта, надо было или изворачиваться как змея для открутить все провода от него, а потом помучиться выворачивая руками привод из окружающих компонентов или разобрать пол шкафа. Привод там сдыхал нечасто, но когда сдыхал, то... А если способен - к любому элементу подобраться можно легко и непринужденно. Пусть даже и ценой появления "лишнего" шкафа.

Автоматизатор писал(а):Выдумывать сокращения и аббревиатуры трудно, а потом тяжело вспомнить-расшифровать.

Если тяжело выдумывать, то сокращение неочевидное. Действительно будет тяжело вспомнить...

Задачи задачам рознь. Но мой коллега со стажем когда-то научил меня сначала хорошо продумывать систему наименования переменных, а потом их создавать. Ну очень мощно получается, так как при нескольких сотнях переменных не приходится лазить и искать их при выводе в таблицу просмотра, когда знаешь что тебе нужно вывести. Вспоминаю первые проекты с названиями типа: Конечно чтоб разобраться мог совсем далёкий человек от проекта это нормально, но нужно когда составлять какие-то выражения скажем в ST, оплучается что-то такое: Как вам?
А могло быть что-то такое:

Степа писал(а):Все равно спустя некоторое время приходится появиться около собственной разработки /а из рабочих моих разработок самой старой, как я говорил, уже лет 15/ и разбираться, что случилось, почему, как устранить.

5 минут и опять забыл как в страшном сне. Перед лицом только схема Э3 и программа с символьными обозначениями. Таблица символов в принципе не может отнимать 72 часа из жизни.

P.S. Внутренние тэги можно класть в блоки DB с русскими названиями: например, Кнопка.Каретка_Вверх, Кнопка.Каретка_Вниз, Переключатель.Режим, Лампа.Готовность_привода, Лампа.Ошибка_привода. У Сименса это на ура проходит.

Михайло писал(а):P.S. Внутренние тэги можно класть в блоки DB с русскими названиями: например, Кнопка.Каретка_Вверх, Кнопка.Каретка_Вниз, Переключатель.Режим, Лампа.Готовность_привода, Лампа.Ошибка_привода. У Сименса это на ура проходит.

Это ты так провода именуешь сейчас?
Раньше этого вроде как не было...

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

Михайло писал(а):Провода - там цифирьки мало чего значащие, к ним обращаешься, когда в шкаф лезешь, чтобы провод отыскать.

Провода - это для монтажника и для наладчика. Скажем, к катушкам промежуточных реле подключаются провода исключительно 51-ХХХ и, например, 21-ХХХ /если у нас БП1 является источником оперативного питания/. Т.е. появление у реле какого-то другого провода - явная ошибка. К модулю выходов подключаются провода 51-ХХХ, 20-ХХХ и 21-ХХХ. Все, других быть не может. И т.д.
Проще работать и монтажнику и наладчику - если вдруг зачем-то наладчику провод понадобился.

Михайло писал(а):А еще есть программные тэги, которые напрямую с проводами не связаны. Для них особое обозначение. Особенно много этих тэгов у HMI, поэтому и примеров много по тэгам панели.

А за это говорится абзацем выше:

Пока сколько пробовал, остановился на двойной кодировке: входа-выхода именуются по схеме /типа SQ1.1, KM2; тепловые реле именуются как KMx - управление реле, KMx_temp - признак срабатывания/. Внутренние переменные несут более-менее функциональное обозначение /например, PressUp, Pusher1Forward и т.п./.
Может, конечно, и не прав, но...

Степа писал(а):Проще работать и монтажнику и наладчику - если вдруг зачем-то наладчику провод понадобился.

Монтажнику не проще. Пять цифр и еще знак дефиса... У него схема Э3 во главе угла, а не ПЛК всякие. Не нужно в монтажники специалистов по АСУТП направлять, там работа этого не требует.
Лучше трехзначное-четырехзначное что-нибудь. Без дефиса. AXX, где A - тип сигнала (0 - вход, 1 - выход, 2 - аналоговый вход и т.д. произвольно), ХХ - номер маркировки. Или АХХХ.