Плюсы и минусы протоколов для АСУЗ., Диспут. Опции

[GYUR22]

Смысл в том, что Вы экономя 1 датчик делаете обе Ваши системы неработоспособными в случае выхода из строя одной из них. Такое производителю Вашего устройства представлялось глупым и он не реализовал это. Кстати, наверняка у указанных устройств есть выход температуры, а нет входа, так? Дайте ссылочку?!

Ссылочки к сожалению нет, но не суть
Не совсем ожидаемый вывод из моего поста - хотелось сказать что без уровня автоматизации далеко не всегда можно обойтись даже с протокололом (LON) который дает p2p.

[GYUR22]

Смысл в том, что Вы экономя 1 датчик делаете обе Ваши системы неработоспособными в случае выхода из строя одной из них. Такое производителю Вашего устройства представлялось глупым и он не реализовал это. Кстати, наверняка у указанных устройств есть выход температуры, а нет входа, так? Дайте ссылочку?!

Ссылочки к сожалению нет, но не суть
Не совсем ожидаемый вывод из моего поста - хотелось сказать что без уровня автоматизации далеко не всегда можно обойтись даже с протокололом (LON) который дает p2p.

[Pasekov]

Кстати вопрос очень верный задал коллега KDVectra, обязятельным условием является возможность загрузки программ(правда я не уверен что есть сети не допускающие этого).

Добавляю:
1. Желательно поддерживать свободную топологию, а не только шинную.
2. Быть не капризным к физ.среде (А может точнее. Пусть и требовать специального кабеля, но быть устойчивым к электромагнитным помехам).
3. Скорость передачи не так важна. Задержка прихода пакета(телеграммы, посылки) на несколько сотен миллисекунд - не критична.
4. Возможность загрузки программ в контроллеры удаленно(через сеть).
5. Наличие оборудования и ПО для IP-туннелирования.

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

[Andy79]

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

Откуда такая легенда? Основные промышленные протоколы являются открытыми, что и определило их популярность. Есть конфигурационные файлы устройства (GSD, EDS, FDT/DTM...) позволяющие подключать к мастерам или новые устройства того же производителя, или стронние устройства. DeveceNet'овские мастера с интеллектом выше минимального, так вообще простейшие слэйвы (например, пневмоострова) определяют автоматически.

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

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

[Сергей Долганов]

Не мудрено, что капризнячало в таком кабельном разнообразии, а кабели были ТПП, ВВГ ... ШУТКА. В этих условиях вообще ни один из привычных электрических интерфейсов на такой скорости не будет работать. Думается, скорее это ++ для ЛОНа, что все-таки работал.
Согласен с Vasiliy, ЛОН работает всегда и гарантированно, когда сделано по правилам.

Это был профибас вобщето

Автоматика вентсистем разработана фирмой A: в качестве контроллеров использованы Carel. У Carel большое количество интерфейсных карт и в том числе - LON. Решение по интеграции существует!
...
В качестве повысительных станций хоз-питьевого водопровода используются Grundfos. Существует в природе шлюз G10-LON. Решение по интеграции существует!
Добавляем сбор сигналов в виде "сухих" контактов с систем без встроенных коммуникаций, мониторинг вводов ГРЩ.
Вообщем, без замены чего либо с небольшими доработками можно получить нормальную систему диспетчеризации объекта. Причем все системы будут работать на едином протоколе. Соответственно нет необходимости менять контроллеры, искать и покупать дополнительные драйверы, OPC серверы. К тому же использование знакомого системному интегратору протокола приведет к сокращению времени ввода в эксплуатацию.

То есть не обородувания, а устройства управления сиречь контроллеров. Извините Василий, но тогда Ваш ЛОН с модбасом и рядом не валялся.

[Vasiliy]

То есть не обородувания, а устройства управления сиречь контроллеров. Извините Василий, но тогда Ваш ЛОН с модбасом и рядом не валялся.

Ну в приведенном мной примере Modbus можно найти у Carel и Danfoss, а остальное предлагаете выкинуть и поставить контроллеры с Modbus? Если да, то оцените стоимость работ и материалов, а потом вместе посмеемся.

[Гость_ggg__ggg_*]

Сразу подчеркну - ИМХО!!!
Я думаю, что основной идеей топика было попробовать не столько сравнить так называемые "промышленные протоколы" с "домостроевскими" (точнее - HVAC его частью, т.к. "охранка" и "пожарка" - отдельная "песня"), сколько понять, ОТКУДА и ПОЧЕМУ на свет появились LON,EIB,BACNet, .
Для чего их придумали, так сказать. Ведь совершенно очевидно, что здание можно автоматизировать на уже имевшихся протоколах.
Таким образом, сравнение надо вести в по следующим параметрам:
- экономия на монтаже (качество и количество кабелей, репиторы, концентраторы, требование к квалификации монтажников, возможность расширения системы (ДОПы - куда без них!!!) и стоимость этого расширения)
- затраты на первоначальную конфигурацию, а, главное, на внесение изменений в текущую конфигурацию, если такая конфигурация вообще требуется.
- запас по пропускной способности каналов - опять же в случае ДОПов.
- требования к квалификации программистов при разработке, отладке и, ГЛАВНОЕ, "ремонте" системы, а также наличие штатных коммерческих (лучше-бесплатных ) СРЕДСТВ ДИАГНОСТИКИ систем, в том числе собственно сети. Спорный аспект.
Таки аспекты, как ОТКРЫТОСТЬ (наличие БЕСПЛАТНЫХ описаний протокола и библиотек для обработки стека) так же можно учитывать, но это вопрос второго порядка.
Думаю, коллеги, что примеры типа "у меня работает, хотя и не должно" не является существенным аргументом, хотя, безусловно, и такие факты вносят свои "пять копеек".

[KDVectra]

... т.к. "охранка" и "пожарка" - отдельная "песня

Забыт "доступ", и, хочется задать вопрос, почему "отдельная "песня""???
Почему эти системы так легко "вываливаются" из АЗ или ИЗ?

[Сергей Долганов]

Я думаю, что основной идеей топика было попробовать не столько сравнить так называемые "промышленные протоколы" с "домостроевскими" (точнее - HVAC его частью, т.к. "охранка" и "пожарка" - отдельная "песня"), сколько понять, ОТКУДА и ПОЧЕМУ на свет появились LON,EIB,BACNet, .

Идея была именно такая

Забыт "доступ", и, хочется задать вопрос, почему "отдельная "песня""???
Почему эти системы так легко "вываливаются" из АЗ или ИЗ?

Имхо потому, что большая часть идей в области интеграции пожарки и охранки с инженерными системами носит откровенно мифический характер. Или Вы имеете ввиду "интеграцию всего в один АРМ"?

[Гость_ggg__ggg_*]

"Отдельная песня" , с моей точки зрения - потому, что это функционально законченные системы, со своими линиями связи, оборудованием и софтом. Конечно, можно их и интегрировать (особенно СКД и ОС) в общую SCADA, но -зачем? Обмен инфой - да, полезен, но он может осуществляться на уровне АРМ для этих систем или "сухих контактов", к тому же что полезного могут передать контроллеры подсистем HVAC в "пожарку", "охранку" и СКС ? Да и Службы Эксплуатации, как правило, разные.

Сообщение отредактировал ggg__ggg - 2.10.2008, 16:58

[Сергей Долганов]

Ну в приведенном мной примере Modbus можно найти у Carel и Danfoss, а остальное предлагаете выкинуть и поставить контроллеры с Modbus? Если да, то оцените стоимость работ и материалов, а потом вместе посмеемся.

Это потому что Вы подобрали удобных себе производителей автоматики (достаточно идеальных к слову). Чаще встречается вентиляция на ТРМ32, котельная лого или альфе, холодидьная машина на чудо-контроллере микрочиллер и насосная станция на "пускателях"и весь Ваш лон (как и мой профибас или модбас) нервно курят в сторонке. Так что убедить меня списком оборудования вратли получится, промышленные протоколы поддерживает уж никак не меньшее число производителей.

[Sun technik]

Добавляю:
3. Скорость передачи не так важна. Задержка прихода пакета(телеграммы, посылки) на несколько сотен миллисекунд - не критична.

Всё-таки сотни миллисекунд - это уже много. Например, если есть регулирование чего-либо по замкнутому контуру по приращению (температурная уставка, диммирование освещения). Т.е. когда на панели жмут "плюсик" или "минусик" и в сеть посылается значение обратной связи+-приращение. При сервисе с подтверждением имеем минимум четыре пакета в сети на каждое действие. Добавим также задержки на обработку в самих модулях, а также наличие дополнительного трафика в сети.

4. Возможность загрузки программ в контроллеры удаленно(через сеть).

А еще лучше - возможность ОТЛАДКИ через сеть, жаль, что это есть у немногих.

к тому же что полезного могут передать контроллеры подсистем HVAC в "пожарку", "охранку" и СКС ? Да и Службы Эксплуатации, как правило, разные.

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

Сообщение отредактировал Sun technik - 2.10.2008, 18:08

[Sun technik]

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

В зданиях встречается такая вещь как локальное управление автоматикой в помещениях - освещение, климат, жалюзи. И у дизайнеров часто бывает много специфических требований к внешнему виду панелек управления, при том что Заказчик может желать такую функциональность, под которую подходящий пульт еще надо поискать. Ну и потом для таких систем стандартом де-факто являются сети peer-to-peer, особенно если требуется параллельное управление из нескольких мест.

[Сергей Долганов]

А еще лучше - возможность ОТЛАДКИ через сеть, жаль, что это есть у немногих.

Имеется, ага.

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

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

В зданиях встречается такая вещь как локальное управление автоматикой в помещениях - освещение, климат, жалюзи. И у дизайнеров часто бывает много специфических требований к внешнему виду панелек управления, при том что Заказчик может желать такую функциональность, под которую подходящий пульт еще надо поискать. Ну и потом для таких систем стандартом де-факто являются сети peer-to-peer, особенно если требуется параллельное управление из нескольких мест.

Взаимодействие пультов можно запрограммировать в контроллере (как в домушном так и в промышленном), панельки можно и поискать, а потом подумать как подключить в зависимости от поддерживаемого панелькой протокола.

[KDVectra]

Идея была именно такая
Имхо потому, что большая часть идей в области интеграции пожарки и охранки с инженерными системами носит откровенно мифический характер. Или Вы имеете ввиду "интеграцию всего в один АРМ"?

Позвольте не согласиться. "Мифический характер" будет носить до тех пор, пока мы сами будем относиться к этом как к мифу.
Да и в один АРМ бывает полезно, например, когда дежурный ночью осуществляет комплексный мониторинг как систем безопасности, так и автоматики, в т.ч. HVAC.

"Отдельная песня" , с моей точки зрения - потому, что это функционально законченные системы, со своими линиями связи, оборудованием и софтом. Конечно, можно их и интегрировать (особенно СКД и ОС) в общую SCADA, но -зачем? Обмен инфой - да, полезен, но он может осуществляться на уровне АРМ для этих систем или "сухих контактов", к тому же что полезного могут передать контроллеры подсистем HVAC в "пожарку", "охранку" и СКС ? Да и Службы Эксплуатации, как правило, разные.

Известны, несколько систем безопасности, которые используют стандартизированные протоколы, применяемые в автоматизации. Среди них есть и соотечественники, кстати. На АРМ - не всегда оптимально, а "сухарями" - .
Что касается служб эксплуатации, то разные службы в затратах дороже объединенной.

[Sun technik]

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

Таковы были технические условия от Заказчика, переубеждать и отказываться от части работ - не стали
Потом важен такой момент, что данные от пожарки пишутся в тот же архив, что и вся остальная BMS.

Взаимодействие пультов можно запрограммировать в контроллере (как в домушном так и в промышленном)

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

панельки можно и поискать, а потом подумать как подключить в зависимости от поддерживаемого панелькой протокола.

А существуют ли линейки панелей, подобные SVEA, Elka, Thermokon с промышленными интерфейсами?

[Сергей Долганов]

Позвольте не согласиться. "Мифический характер" будет носить до тех пор, пока мы сами будем относиться к этом как к мифу.
Да и в один АРМ бывает полезно, например, когда дежурный ночью осуществляет комплексный мониторинг как систем безопасности, так и автоматики, в т.ч. HVAC.

Коллега, приведите не мифический пример взаимодействия.
Дежурный ночью он кто? Инженер или громила с автоматом? Не надо лишать диспетчеризацию здравого смысла, инженеру инженерово, охраннику охранниково.

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

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

А существуют ли линейки панелей, подобные SVEA, Elka, Thermokon с промышленными интерфейсами?

Понятия не имею. А что это какие-то особенные панели без которых в здании не обойтись?

[Гость_ggg__ggg_*]

А про протоколы-то где ? Наличие девайсов под протокол - это COOL (опять рифма !), но ведь должны быть причины для того, чтобы кто-то старался разрабатывать что-то под данный протокол. Тема - именно про причины!

[KDVectra]

Коллега, приведите не мифический пример взаимодействия.
Дежурный ночью он кто? Инженер или громила с автоматом? Не надо лишать диспетчеризацию здравого смысла, инженеру инженерово, охраннику охранниково.

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

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

[Гость_ggg__ggg_*]

to KDVectra
Как Вы предлагаете передавать перечисленную Вами информацию :
- непосредственно с датчиков;
- с контроллеров системы СКД, ОС, ОПС
- с АРМ диспетчера ( из "головного" софта )данных систем.

[KDVectra]

to qqq___qqq,
не то, чтобы предлагаю, а имею некоторую практику такой информационной интеграции.
Последнее время, преимущественно, но не всё, на уровне контроллеров в технологии LON. Хотя, честно говоря, раньше доминировало информационное взаимодействие на уровне "головного" (верхнего) софта.
Кстати, взаимодействие на уровне контроллеров - один из "двигателей" развития протоколов.

[Сергей Долганов]

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

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

Давайте всеже вернемся к протоколам.

[Гость_ggg__ggg_*]

Связь на уровне контроллеров группы Н (HVAC) и группы С( СКД+ОПС+ОС), с моей точки зрения - ИЗЛИШЕСТВО. И вот почему.
1. Вам придется "увязывать" данные на уровне проекта. Не знаю, как у Вас, но обычно эти системы монтируют и настраиваю РАЗНЫЕ группы специалистов. Изменение в одном из проектов - это КАРАУЛ!!!
2. Открытый доступ из систем HVAC к группе С - это ДЫРИЩА в идеологии безопасности.
3. Нагрузка, создаваемая на информационную сеть, контроллерами HVAC весьма существенна, что может отрицательно сказаться на оперативности работы группы С. Значит, придется делать "широкий канал".
4. Группа Н имеет дело с "силой". Электрический пробой в этой группе (были случаи, когда на LON попадало 220В) выведет из строя ВСЮ систему жизнеобеспечения здания.
5. Обмен, как правило, односторонний (группа С->группа Н), к тому же группа С оперирует ОБОБЩЕННЫМИ данными, ( Вам придется выполнять задачу "головного" софта группы С на соответствующих контроллерах группы Н - хлопотное дело!!!), значит, гораздо удобнее и безопаснее работать на уровне АРМ, чем на уровне контроллеров.

[KDVectra]

Связь на уровне контроллеров группы Н (HVAC) и группы С( СКД+ОПС+ОС), с моей точки зрения - ИЗЛИШЕСТВО. И вот почему.
1. Вам придется "увязывать" данные на уровне проекта. Не знаю, как у Вас, но обычно эти системы монтируют и настраиваю РАЗНЫЕ группы специалистов. Изменение в одном из проектов - это КАРАУЛ!!!

На уровне проекта - не вопрос, не такая уж это проблема. Теперь по поводу "обычно", понимаете дело в том, что обычным это стало потому, что одни не берутся за СБ, другие - за АЗ. И все в один голос убедительно говорят о смысле и содержании этого "разделения труда". Что касается настройки, то вот что-что, а настроить (выполнить ПНР) СБ не представляет никаких проблем, особенно по сделанному проекту.

2. Открытый доступ из систем HVAC к группе С - это ДЫРИЩА в идеологии безопасности.

"Да бросьте Вы, Штирлиц". Настоящими идеологиями этого вопроса занимаются на атомных объектах, а в простой жизне - это скорее ... И дыр в реальных системах для "находчивых" и "выносливых" всегда можно найти. Соглашусь с Вами в том, что степень информационного взаимодействия Н к С надо определять при проектировании и в процессе эксплуатации иметь возможность контролировать это взаимодействие.

3. Нагрузка, создаваемая на информационную сеть, контроллерами HVAC весьма существенна, что может отрицательно сказаться на оперативности работы группы С. Значит, придется делать "широкий канал".

Для этого, например в LONе применяются маршрутизаторы, "отфильтровывающий" внутренний трафик систем.

4. Группа Н имеет дело с "силой". Электрический пробой в этой группе (были случаи, когда на LON попадало 220В) выведет из строя ВСЮ систему жизнеобеспечения здания.

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

5. Обмен, как правило, односторонний (группа С->группа Н), к тому же группа С оперирует ОБОБЩЕННЫМИ данными, ( Вам придется выполнять задачу "головного" софта группы С на соответствующих контроллерах группы Н - хлопотное дело!!!), значит, гораздо удобнее и безопаснее работать на уровне АРМ, чем на уровне контроллеров.

Позвольте Вас поправить, не "обощенными", а дискретными. И функции "головного" софта не надо возлагать на контроллеры Н, если контроллеры и Н и С способны друг друга понимать без "толмача". И дело оказывается не очень-то хлопотное. Главное, чтобы протокол и оборудование, реализующее решения на его базе, были ориентированы на такие задачи.

[Сергей Долганов]

На уровне проекта - не вопрос, не такая уж это проблема. Теперь по поводу "обычно", понимаете дело в том, что обычным это стало потому, что одни не берутся за СБ, другие - за АЗ. И все в один голос убедительно говорят о смысле и содержании этого "разделения труда". Что касается настройки, то вот что-что, а настроить (выполнить ПНР) СБ не представляет никаких проблем, особенно по сделанному проекту.

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

[Гость_ggg__ggg_*]

По поводу протоколов для группы С (СКД, ОС, ОПС). "Пожарка" - возможно, а вот ОС и СКД - тут сложнее. Если рассматривать все с со следующей позиции - лампочки мигают, картинка на мониторе есть, считыватель считывает - то НИКАКИХ проблем. Если рассматривать систему СКД и ОС именно как системы для ЖИЗНЕОБЕСПЕЧЕНИЯ здания - то тут и "жесткач" возникает. Кстати, по личному опыту - богатые дяди имеют тенденцию приглашать СПЕЦИАЛИСТОВ для оценки предложенных систем.
to KDVectra
Теперь о взаимодействии групп Н и С. Допустим, к Вам пришла инфа о том, что в помещении хххх открыты окна и есть человек в нем, Петя Иванов пришел на работу, а Иван Петров ушел. Что с ней делать дальше с точки зрения HVAC?

[KDVectra]

to qqq___qqq,
Вы извините, но СЦЕНАРИИ, как мне кажется, выходят за рамки текущей темы, посвященной ПРОТОКОЛАМ. Если Вы не возражаете, то можно открыть новую тему посвященную этому.

[Гость_ggg__ggg_*]

Да я не о сценариях. Я о том, что данные с контроллеров группы С в "чистом виде" для группы Н БЕСПОЛЕЗНЫ. Нужен ОБРАБОТАННЫЙ "головным" софтом результат. Своими примерами я и хотел показать эту бесполезность. Открытые окна, наличие чела на работе или уход его с работы - это может быть и задание для Службы Безопасности ( "шухер"). Тут уж не до освещения и вентиляции.
Вообще-то, по моему опыту работы с ОС и СКД, требования к физическим параметрам сети и протоколам ПРЯМО противоположны требованиям (пожеланиям) для HVAC (резервирование, доступность кабелей, надежность и избыточность, устойчивость протокола к ФИЗИЧЕСКОМУ и ПРОГРАММНОМУ взлому (как следствие - МАКСИМАЛЬНАЯ ЗАКРЫТОСТЬ) и прочее).
Именно поэтому я считаю, что подсистемы группы С следует рассматривать отдельно от HVAC.

[Pasekov]

1. Я думаю, что основной идеей топика было попробовать не столько сравнить ...сколько понять, ОТКУДА и ПОЧЕМУ на свет появились LON, EIB, BACNet...
2... Ведь совершенно очевидно, что здание можно автоматизировать на уже имевшихся протоколах.
3.. а также наличие штатных коммерческих (лучше-бесплатных ) СРЕДСТВ ДИАГНОСТИКИ систем, в том числе собственно сети. Спорный аспект.
4.Таким образом, сравнение надо вести ...

1. Конечно же. Славно, что медленно, но верно наши ряды растут
2. А кто с этим спорит?
3. Прошу пояснить...Что спорно? Бесплатность?

4..... Добавляю еще:
1. Желательно поддерживать свободную топологию, а не только шинную.
2. Быть не капризным к физ.среде (А может точнее. Пусть и требовать специального кабеля, но быть устойчивым к электромагнитным помехам).
3. Скорость передачи не так важна. Задержка прихода пакета(телеграммы, посылки) на несколько сотен миллисекунд - не критична.
4. Возможность загрузки программ в контроллеры удаленно(через сеть).
5. Наличие оборудования и ПО для IP-туннелирования.
6. Экономичность на монтаже сети
7. Простота расширения сети и запас по пропускной способности
8. Требования к квалификации специалистов при разработке, пуско-наладке и эксплуатации
9. Наличие штатных инженерных программ, позволяющих осуществлять программирование контроллеров любых производителей, конфигурирование сети, ее диагностику

З.Ы. Разумеется, выделенная часть про производителей не носит жестко абсолютный характер, но тем не менее...

[Pasekov]

1. Чаще встречается вентиляция на ТРМ32, котельная лого или альфе, холодидьная машина на чудо-контроллере микрочиллер и насосная станция на "пускателях"и весь лон как и профибас или модбас нервно курят в сторонке.
2. Так что убедить меня списком оборудования врядли получится...

1. У нас? Да! Но что это доказывает? Что в таком случае совсем не нужны протоколы?
Да нет, просто в ТЗ не было ни одного из 9 пунктов, о которых говорилось...
Это отдельная большая тема, типа: А нужны вообще эти протоколы для автоматизации зданий?
Но мы вроде условились, что у нас чуть ли не трехуровневая модель...
2. Совершенно верно. Эти списки расчитаны на покупателей, коих здесь почти нет...

[Pasekov]

1. Имеется, ага.
2. Взаимодействие пультов можно запрограммировать в контроллере (как в домушном так и в промышленном), панельки можно и поискать, а потом подумать как подключить в зависимости от поддерживаемого панелькой протокола.

1. Прошу пояснить... Предполагаю, что не всем понятно, что имеется в виду.
2. Рискну добавить свою копейку... Дело в том, что у АСУЗ по сравнению с АСУ ТП есть один существенный ньюанс...
Это не только функциональность, но и дизайн конечных устройств. Конечно, формально к протоколам это никак не относится, но тем не менее...
Поэтому, не всегда можно в одном контроллере запрограммировать взаимодействие и не всегда можно подключить экономично, удобно и просто.
Пример, стали производители выпускать сенсорные панели с интерфейсом KNX, их стали более активно и широко использовать в проектах...