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

[Pasekov]

Вот такую «новую» тему хочется предложить.
Предварительно обсудил ее с товарищем, так что диспут должен получиться.
Предварительное название темы: "Преимущества протоколов LonTalk, BACnet(вписать нужное) перед промышленными протоколами для автоматизации зданий" - чуть длинновато... Пришлось сократить…
В теле темы можно рассмотреть задачи АСУЗ (применительно к протоколам), сами протоколы, их сравнить...
У меня было предложение, что может надо технологии, а не протоколы, но это оказалось не совсем понятно….

Начнем с более простого…
Откуда «ноги» у темы растут, спросите Вы?
1) Область АСУТП более старая и большая, чем АСУЗ.
2) Специалистов, профессионалов, использующих промышленные протоколы в десятки раз больше, чем тех, кто хотя бы слышал об АСУЗ.
3) Очень большое количество специалистов не понимают (не знают, не считают), что могут быть хоть какие-то преимущества у протоколов LonTalk, BACnet (вписать нужное).

Поэтому, попытка разобраться (поговорить), на мой взгляд, того стоит. Но есть несколько простых просьб:
1) Не надо никого стараться переубедить. Просто приводите аргументы. Здесь почти все уже большие….(Иначе тему бы начали в Песочнице).
2) Это диспут, а не соревнование. Победители будут весьма условны. Предлагаю вести счет г. LEX. Он поможет (и счет и Lex). Но если Lex не захочет, будем «играть» без счета….
3) Вопрос не стоит так: « На чем можно делать АСУЗ?» Ибо ответ очевиден: «На всем, ну или почти на всем».
4) Мы делаем попытку в первую очередь для себя, а не для того, чтобы услышать в очередной раз «рекламу».
5) Желающим высказать свое мнение, но не согласным с вышеозначенным – просьба НЕ БЕСПОКОИТЬСЯ.
З.Ы. Опрос организуем через некоторое время, чтобы он был точнее в своей постановке.

[Pasekov]

Вот такую «новую» тему хочется предложить.
Предварительно обсудил ее с товарищем, так что диспут должен получиться.
Предварительное название темы: "Преимущества протоколов LonTalk, BACnet(вписать нужное) перед промышленными протоколами для автоматизации зданий" - чуть длинновато... Пришлось сократить…
В теле темы можно рассмотреть задачи АСУЗ (применительно к протоколам), сами протоколы, их сравнить...
У меня было предложение, что может надо технологии, а не протоколы, но это оказалось не совсем понятно….

Начнем с более простого…
Откуда «ноги» у темы растут, спросите Вы?
1) Область АСУТП более старая и большая, чем АСУЗ.
2) Специалистов, профессионалов, использующих промышленные протоколы в десятки раз больше, чем тех, кто хотя бы слышал об АСУЗ.
3) Очень большое количество специалистов не понимают (не знают, не считают), что могут быть хоть какие-то преимущества у протоколов LonTalk, BACnet (вписать нужное).

Поэтому, попытка разобраться (поговорить), на мой взгляд, того стоит. Но есть несколько простых просьб:
1) Не надо никого стараться переубедить. Просто приводите аргументы. Здесь почти все уже большие….(Иначе тему бы начали в Песочнице).
2) Это диспут, а не соревнование. Победители будут весьма условны. Предлагаю вести счет г. LEX. Он поможет (и счет и Lex). Но если Lex не захочет, будем «играть» без счета….
3) Вопрос не стоит так: « На чем можно делать АСУЗ?» Ибо ответ очевиден: «На всем, ну или почти на всем».
4) Мы делаем попытку в первую очередь для себя, а не для того, чтобы услышать в очередной раз «рекламу».
5) Желающим высказать свое мнение, но не согласным с вышеозначенным – просьба НЕ БЕСПОКОИТЬСЯ.
З.Ы. Опрос организуем через некоторое время, чтобы он был точнее в своей постановке.

[Lex]

Эээээээ, а почему Lex ?

[Abysmo]

У LonTalk - свободная топология, у промышленных - шинная.

[Pasekov]

... а почему Lex ?

А почему не Lex?
Оценки аргументам давать умеете-раз.
Четыре звезды-два.
География-середина России - три.

[Andy79]

У LonTalk - свободная топология, у промышленных - шинная.

Это не совсем так, у каждого промышленного протокола своя "фишка". На счет свободной топологии: вспомним ASi.

[s60]

LON

Исходная цель: создать Fieldbus-систему, которая, с точки зрения корпорации
Echelon, покрывала бы до 80% возможных применений Fieldbus. Для быстрого
распространения система должна была концептуально поддерживать
децентрализованное функционирование и предлагать пользователю универсальную
поддержку. Эти требования воплотились в Fieldbus-системе, которая значительно
выделяется среди других, хотя при детальном сравнении с Fieldbus-системами
обнаруживает некоторые общие черты. Сравнение коммуникационных уровней модели
ISO/OSI приводит к следующим выводам:
— LON благодаря Neuron Chip осуществляет дифференциальное манчестерское
кодирование (Differential Manchester Coding), которое применяется и в других системах,
например в Fieldbus-системах стандарта IEC. Его преимущество заключается в том, что
питание устройств осуществляется прямо через шину, а трансформаторы можно
изолировать от остальных устройств. На физическом уровне LON поддерживает
различные скорости передачи и передающие среды, в то время как другие Fieldbus-
системы не так универсальны. Это — серьезное преимущество LON (например в плане
совместимости и взаимодействия). Наиболее распространенная скорость передачи
данных в LON — 78 Кбит/с получена при трансформаторном сопряжении и так
называемом трансивере с произвольной топологией. Топология сети может быть

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

произвольной в рамках максимальной общей длины шины (500 метров);
— LON использует метод доступа к шине CSMA, который другими Fieldbus-
системами не используется, допускающий обусловленные коллизиями сбои при
передаче сообщений, но ограничивающий вероятность их возникновения. Для
предотвращения сбоев используется принцип «основное устройство-подчиненное
устройство» (Master-Slave, иногда с меняющимися основными устройствами),
маркерная передача или CSMA/CA, при котором осуществляется побитовый арбитраж;
— схема адресации, используемая в LON, предусматривает разделение сетей на
подсети, то есть сегментацию сети с помощью маршрутизаторов. Поскольку во многих
Fieldbus-системах определены только коммуникационные уровни 1, 2 и 7, для них
логически существует только одна сеть, что делает невозможной изоляцию
коммуникационной нагрузки;
— транспортный уровень в LON реализован ограниченно. Он предоставляет в
распоряжение пользователя службу подтверждения, но не фрагментирует длинные
блоки данных на несколько коротких;
— на сессионном уровне LON обладает способностью к идентификации,
которой лишены другие Fieldbus-системы. Идентификация обеспечивает защиту
коммуникационной сети LON от несанкционированного доступа и может применяться
в системах, требующих повышенной безопасности;
— на прикладном уровне LON предлагает очень удобный, с точки зрения
разработки программного обеспечения, вид коммуникации — связь через сетевые
переменные. Прикладная программа предполагает возможность запроса данных каких-
либо узлов специальной командой. В то же время она предусматривает передачу
информации другим узлам;
— очень важная особенность LON-наличие широкого набора сообщений для
сетевого менеджмента. Их используют утилиты конфигурации, инсталляции и
сопровождения сети.
В настоящее время ситуация в области реализации LON такова:
— существует два вида нейронных чипов (Neuron Chip), которые выпускаются
двумя различными производителями. Протокол обмена данными не только
стандартизирован, но и реализован для некоторых других Fieldbus-систем, таких как
INTERBUS-S или CAN. На этих чипах выполняются пользовательские приложения,
которые связываются с протоколом инструментарием разработчика;
— компилятор и компоновщик (редактор связей), а также коммуникационное
программное обеспечение (в инструментарии разработчика) поставляются только
корпорацией Echelon. Однако в ближайшем будущем ситуация может измениться
благодаря открытой публикации LON-протокола в 1996 году;
— вопрос совместимости играет особую роль во всех Fieldbus-системах,
поскольку один производитель не в состоянии охватить весь спектр Fieldbus-систем и
поставить все их компоненты. Благодаря реализации коммуникационного протокола в
одном чипе и разработке пользовательских программ единым инструментарием,
некоторые препятствия совместимости устраняются уже в самом начале. Другие
Fieldbus-системы, такие как INTERBUS-S или ЕШ, имеют схожую основу. То, что
этого для достижения полной совместимости недостаточно, было обнаружено довольно
быстро. В LON были введены так называемые стандартные типы сетевых переменных,
которые, как минимум, обеспечивают полную совместимость типов данных. Кроме
того, была основана Ассоциация по совместимости LonMark (LonMark Interoperability
Association), которая вырабатывает руководства по разработке прикладных объектов и
их функциональных профилей, что означает следующий шаг в направлении
совместимости. Другие работающие в области Fieldbus-технологий организации
получили профили для всех классов приложений, а также подвели к необходимости
использования тестов на совместимость и сертификации продуктов на базе Fieldbus-
систем. Вероятно, в будущем продукты LON будут также подвергаться тестированию и
сертификации.
Концептуальное развитие LON проходило не так, как других Fieldbus-систем,
большинство которых было рассчитано на узкий спектр применения. Позже начались
работы по их универсализации. LON же предназначалась для широкого использования,
и этот принцип отразился в ее конструктивных особенностях. Например, поддержка
устройств ввода/вывода встроенным программным обеспечением включает не только
обмен аналоговыми и двоичными данными, но и протоколы передачи для магнитных
карт, устройств инфракрасного управления, дифференциальных кодеров, UART и
последовательного обмена UART и устройств последовательного обмена данными со
специальными запоминающими устройствами (Touch Memories).
Другой концептуальной особенностью является четкая поддержка
децентрализованной структуры систем. Поэтому:
— разделения абонентов шины (узлов) на основные и подчиненные устройства
не происходит;
— инициатором передачи данных по умолчанию выступает отправитель, опрос
является исключением;
— программы в Neuron Chip активизируются событиями, например, получением
данных.

Сообщение отредактировал s60 - 29.9.2008, 13:53

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

Уважаемый s60, Вы к чему выложили этот кусок? Хотели показать сравнение с "некоторыми другими сетями"? Реальный плюс назвал г-н Abysmo (добалю слова "без репитеров"), в Вашей же тираде присутствует рекламная листовка в чистом виде.
Мастер-слейв технология лежит в основе большинства промышленых сетей, 78 кбит\с далеко не самая большая скорость на сегменте в 500м, весьма сомнительна.

[Гость_ggg__ggg_*]

По-поводу LON s60 "круто выдал". Особенно насчет скоростей. Реально - две их, причем 1250- backbone на 99,(9) %. Низкая скорость и дает возможность использовать "свободную топологию". то-бишь широкий разброс в волновых и активных сопротивлениях сети.
С моей точки зрения, надо рассматривать ДВА класса - клоны 485 ("microframe") и "mainframe", типичным представителем которых является Ethernet. Соответственно, исходя из объема "фрейма", первые предпочтительны для fieldbus, вторые - для взаимодействия между более высокоуровневыми системами, например контроллер-контроллер, контроллер-SCADA. Деление ВЕСЬМА УСЛОВНО, реальность более размыта.
Начнем с Ethernet- семейства. Идеология UDP (именно - ИДЕОЛОГИЯ!!!) очень эффективна в системах, построенных по принципу "прокукарекал - а там хоть не рассветай". Очень типичный случай для промсистем. Не хочу вдаваться в подробности - получиться КНИГА, а не пост.
Вариант TCP/IP как протокол "вопрос-ответ" не всегда "катит" в промсистемах - некогда ждать ответа. зато некая гарантия доставки инфы.
Естественно, коль пошли гарантии, то имеет смысл "закатывать" в посылку как можно больше полезных данных. Вот и mainframe-идеология "нарисовалясь".
Теперь о 485 и ему подобных. Чем меньше frame, тем меньше проблем. "Простенько и со вкусом". Идеальная "штучка" для fieldbus, особенно при
при низкой загрузке сетию В детали вдаваться - до утра не разобраться.
Идеология LON предполагала обмен короткими сообщениями, при этом предполагалась и UDPишная идеология. Значит, основа - 485.
BACnet ушел не очень далеко, но "уклон в объекты" обязывает. LONMARK расширяет номенклатуру и ОБЪЕМ SNVT. Тут и конец 1 части поста....


Сообщение отредактировал ggg__ggg - 30.9.2008, 6:22

[s60]

в Вашей же тираде присутствует рекламная листовка в чистом виде.

s60 выложил цитату из "Дитрих Д., Лой Д., Швайнцер Г.-Ю. ЛОН — технология. Построение распределенных приложений/Пер. с нем. "

[Гость_ggg__ggg_*]

2 часть "Марлезонского балета"...
Как "чистый "fieldbus" LONTalk (далее-LON) и Profibus почти "близнецы-братья". LON привлекательнее с точки зрения более низких требований к физической среде. Как только поднимаемся "выше" - тут и начинаются проблемы. LON содержит более развитую систему адресации, поддерживает тайм-ауты для ответа и прочие "приблуды" ISOшной модели. За это приходится платить РЕЗКИМ увеличением "накладных" расходов, что при низких скоростях очень неприятно. Profibus (DP) более незатейлив, но для передачи 3,5 и более байт требуется многосеансовость. Master-Slave идеология прекрасно работает для fieldbus, но для однорангового обмена - жуткий "тормоз". Соответственно, Profibus и ISOшная модель - мезальянс.
Теперь о предназначении. В АСУЗ время течет весьма неспешно, характерные времена - от 0.5 сек и выше. Принцип "хрен с ней, завтра докуем" можно смело брать как эпиграф к ЛЮБОМУ ТЗ на автоматизацию здания. Низкая скорость обмена с периферией совершенно не мешает жить, главное - удобство монтажа, поменьше (количественно и качественно) кабелей. Снижение качества кабелей дает весомую экономию, а если учесть, что автоматизация практически не приносит прибыли (по сравнению с промышленностью), то нечего и "огород городить". Кстати, выход и строя чего-либо в из автоматизированного в худшем случае вызовет временные неудобства, но до техногенной катастрофы, людских жертв дело вряд-ли дойдет. Отсюда и требования к реакции системы на внешнее воздействие и от протокола в этом вопросе зависит многое.
Конец второй части поста. Продолжение следует.....

[Pasekov]

1. К протоколам применяемым в автоматизации зданий (разумеется у нас) можно отнести следующий "компот":
Х-10, C-bus, KNX/EIB, LonTalk, BACnet и пожалуй IP. "Мелкотравчатые" протоколы, известные только их производителям предлагаю не рассматривать. И совсем не потому, что на них нельзя сделать...
2. Было бы интересно получить список соперников. Кто способен "нарисовать"?

У LonTalk - свободная топология, у промышленных - шинная.

3. Хотелось бы добавить к мыслям уважаемому Abysmo:
Топология сети (шины) должна определяться не возможностью протокола, а характером самого объекта.
Если мы рассмотрим известную классификацию S/M/L, то для квартиры сойдет практически любая шина, для здания больше подойдет древовидная структура (топология), а для L, в том числе в соответствие с нашими нормативными документами, не обойтись без сложной топологии с наличием по крайней мере одного кольца.
Будем одновременно все рассматривать?
4. С учетом трехуровневой модели, применяемой в автоматизации зданий, хотелось бы также заметить, что в большинстве структур(схем) автоматизации, предлагаемых производителями присутствует, по-крайней мере, два протокола.
Предлагается вести рассмотрение без учета уровней вообще(один универсальный протокол на всех уровнях) или мы ограничиваемся только полевым уровнем?

[Lex]

Во-первых, предлагаю "вести счет" ggg_ggg, т.к. судя по его постам, он "глубоко погрузился" в протоколы и может
более объективно оценивать.
Во-вторых, начнем пром. протоколы - modbus, profibus, profinet, CAN (или нет?), ASi (он же EIB?)...
В-третьих, IP хоть и переводится как internet protocol, протоколом не является, скорее транспортом.
2 Pasekov

...классификацию S/M/L...

ну и сделать два столбца "умный дом" и "интелл. здание"

С учетом трехуровневой модели...

И здесь можно рассмотреть два уровня - полевой и уровень автоматизации.

[GYUR22]

На всякий случай :
Есть LON на RS485 - который далеко не свободная топология

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

s60 смысл Вашей тирады от меня ускользает.

Теперь к коллеге ggg_ggg

Идеология LON предполагала обмен короткими сообщениями, при этом предполагалась и UDPишная идеология

Как Лон определяет какой снивит к нему пришел? Он не зашивает тип снивита в посылку?

LON привлекательнее с точки зрения более низких требований к физической среде.

Откуда такие сведения? Насколько я успел понять из своего короткого знакомства с лоном, он крайне капризен к физической среде.

Master-Slave идеология прекрасно работает для fieldbus, но для однорангового обмена - жуткий "тормоз".

Тормоз то он тормоз, да вот нужен ли одноранговый обмен это тоже вопрос
2Lex

Во-вторых, начнем пром. протоколы - modbus, profibus, profinet, CAN (или нет?), ASi (он же EIB?)...
В-третьих, IP хоть и переводится как internet protocol, протоколом не является, скорее транспортом.

AS-i и EIB разные вещи, PROFINET перемещайте к IP протоколам имхо.

Сообщение отредактировал Сергей Долганов - 30.9.2008, 16:43

[KDVectra]

Круто , вот это винегрет получается ...

Хотелось бы приостановить упоминание о 485 как о протоколе, ибо он таковым не является, опомнитесь, ведь это - физический интерфейс - не более.

Кстати, а давайте-ка, для начала, дадим "определение" протокола. Кажется, что каждый под этим понятием понимает своё.

[Andy79]

Во-вторых, начнем пром. протоколы - modbus, profibus, profinet, CAN (или нет?), ASi (он же EIB?)...

CAN по сути не протокол, а интерфейс. На базе CAN куча (по большей части закрытых протоколов), самые стандартизированые это открытые DeviceNet и CANOpen.
Так же еще из открытых пром. протоколов CompoNet, CC-Link, ControlNet, Interbus.

[Pasekov]

Во-первых, предлагаю ...
Во-вторых, начнем пром. протоколы - modbus, profibus, CAN (или нет?)...
В-третьих, IP хоть и переводится как internet protocol, протоколом не является, скорее транспортом.
4....ну и сделать два столбца "умный дом" и "интелл. здание"
5. И здесь можно рассмотреть два уровня - полевой и уровень автоматизации.

1. Посмотрим, что он сам скажет, но мне кажется, что у Вас со "счетом" - лучше получалось...
2. Кто еще добавит?
3. Нет вопросов. Похоже все однозначно понимают, что на сегодня вверху (на третьем уровне) альтернативе IP нет.
Пусть так, но вот что будет нести транспорт? Хорошо, давайте для начала оставим в покое Lon/IP, KNX/IP, BACnet/IP, PROFINET и т.д.
Разумно, предположить, что те протоколы, что победят на нижних уровнях, прорвутся и наверх....
4. Я привел не нашу классификацию, потому, что другой нет...
По поводу "У д" и "И З" Вы шутите. А ведь некоторые серъезно все воспринимают... рассылочку "Автоматизация Зданий для всех" 25 выпуск(про журналистов и статьи) посмотрите.
А может Вы правы? Например, протокол KNX - только для "умного дома", без BACnet - нельзя построить Интеллектуальное Здание....(Почти так вещает известный проповедник, не слышали?)
Я бы с Вами согласился, даже в СНИПы бы так и записал . Вот только куда тогда LonTalk деть? Или если он универсальный, то, страшно подумать, он лучше всех и вся? А как же тогда пром. протоколы? Они на что по Вашему тянут? На ИЗ тянут?
5. Согласен. Начнем снизу.

KDVectra Дата Сегодня, 18:35
Круто , вот это винегрет получается ...
Хотелось бы приостановить упоминание о 485 как о протоколе... Кстати, а давайте-ка, для начала, дадим "определение" протокола.

Се ля ви. Потому и тема диспутичная начата.
Полностью согласен о 485.
А может облегчим себе задачу? Все таки, надеюсь многие знают, или понимают, как и для чего рождались пром.протоколы... Чего совсем нельзя сказать о BKLах. Т.е. может сначала сформулируем, а чего мы хотим от протоколов АСУЗ?
Два-три "шара" уже есть:
1. Желательно поддерживать свободную топологию, а не только шинную.
2. Быть не капризным к физ.среде (А может точнее. Пусть и требовать специального кабеля, но быть устойчивым к электромагнитным помехам).
3. Скорость передачи не так важна. Задержка прихода пакета(телеграммы, посылки) на несколько сотен миллисекунд - не критична.

Я только обобщил. "Шары" закатали Abysmo, Lex, ggg_ggg, Сергей Долганов.

[KDVectra]

Всё-таки децентрализация (или одноранговый обмен)! Лично мне не нравятся мастер-слэйвовые системы и решения, уж больно зависимость от мастеров получается сильная. Опять же, свойство децентрализованной системы - распределение вычислений по сетевым устройствам, алгоритмы, рождающиеся засчет сетевого взаимодействия устройств прямо на нижнем уровне и т.п.

А вот ещё, загрузка микропрограмм по той же физ.среде информационного взаимодействия устройств.

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

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

[KDVectra]

К сожалению, каков бы ни был интеллект слэйва, но без мастера он ... на ниточке , конечно, способный работать как автономный контроллер. И ещё, далеко немногие мастера позволяют подключать к себе "чужие" слэйвы, а значит опять всё от одного производителя. И кстати, мастер-слэйвовое, т.е. централизованное, решение - это частный случай децентрализованного. Любая децентрализованная технология позволит реализовать централизованное решение, обратное - спорно и на практике не реализуемо.
Сергей, а не подскажите, как на практике выполняется загрузка микропрограммы в слэйв, подключенный к мастеру во время работы? (не конфигурации, а именно работающей микропрограммы)

Сообщение отредактировал KDVectra - 30.9.2008, 21:30

[KDVectra]

Про IP и протоколы нижнего уровня. Думаю полезно упомянуть наличие возможности и реальных средств для: а) туннелирование протокола через IP-сеть и б) переход к SOAP/XML.

[Vasiliy]

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

Ключевые слова "короткое знакомство", а не "капризен". Расскажу историю. Есть в Питере завод. На заводе есть станки, прессы, бааальшие вентиляторы и прочее. Все вентоборудование, тепловые пункты сделаны на контроллерах с LON. 4 корпуса, в 3х разбит 1 сегмент FT10 очень свободной топологии (никто о планировании сети даже и не думал). 4й корпус подключен через существующую локальную сеть. В качестве кабеля для связи использован экранированный кабель 5 категории, по 4 жилы кабеля скручены вместе и засунуты под 2 клеммы контроллеров. Кроме этого, экран висит на той же самой земле, что и станки, прессы, вентиляторы и т.п. И вот в этой чудной сети даже терминатора не было!!! Но сеть РАБОТАЛА! Да в LonScanere был частокол ошибок и количество перезапросов было немалым, и занятость канала была свыше 20%, что для сети порядка 30 контроллеров вентсистем и тепловых пунктов - много. Вообщем, установка терминатора и отдирание экранов в ряде щитов (в мою работу вообще не входила оптимизация сети, так что попался экран на глаза - откручивался, а не попался - ну и не очень-то хотелось) привело к снижению занимаемой полосы пропускания до 6,5%, хотя ошибки остались конечно. Вот такая история.
Замечу, что в нормально спроектированных сетях процент ошибок может быть равен 0.
Еще вспомнил. Как-то рассматривал внимательно один проект, жаловались люди мол ошибок в сети много. Вроде и работает, но как-то не очень. Как оказалось в здании на 800 метрах сегмента TP/XF-1250 стоит 2 роутера 1250/1250. В итоге длина сегмента в среднем ~270 метров, при рекомендованных 130, а вместо рекомендованного кабеля сечением 0,65 стоит кабель сечением 1,3. И ведь ладно б информация была бы труднодоступна или требовала серьезной проработки. Нет! На сайте Echelon в разделе Media & Wiring всего 2 документа и первым стоит нужный - "Junction Box and Wiring Guidelines for Twisted Pair LonWorks Networks". Но это уже к извечной русской проблеме: сначала сломаем (сделаем не то), а потом мануалы читаем. Вообщем-то пример, как раз показывал, что сделанное не по правилам все равно работает.

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

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

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

Не понял вопроса. Что значит как?

Ключевые слова "короткое знакомство", а не "капризен". Расскажу историю. Есть в Питере завод. На заводе есть станки, прессы, бааальшие вентиляторы и прочее. Все вентоборудование, тепловые пункты сделаны на контроллерах с LON. 4 корпуса, в 3х разбит 1 сегмент FT10 очень свободной топологии (никто о планировании сети даже и не думал). 4й корпус подключен через существующую локальную сеть. В качестве кабеля для связи использован экранированный кабель 5 категории, по 4 жилы кабеля скручены вместе и засунуты под 2 клеммы контроллеров.

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

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

Какого это оборудования? Очень частое заявление непонятного мне смысла.

[KDVectra]

Не понял вопроса. Что значит как?

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

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

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

Сообщение отредактировал KDVectra - 1.10.2008, 7:51

[Dmitry K.]

Разрешите тоже принять участие .

К контексте АСУЗ, нелишним будет вспомнить про стандарт на кабельную систему систем автоматизации здания, а именно ANSI/TIA/EIA-862. Т.о. говоря о протоколах АСУЗ давайте не забывать про стандарты на СКС.

Взгляд на протоколы АСУЗ (в контексте технологий), должен так же учитывать полноту охвата систем, так, чтобы, используя один протокол, можно было бы реализовать все системы ИЗ.

[GYUR22]

Опять же на всякий случай:
Если например есть стандартное LON устройство с уже четко определенным интерфейсом
то насколько разумею добавить трансфер на другое устройство не всегда можно - только при наличии необходимых выходов на первом например:
передо мной лежат два LON контроллера руфтопов но сделать так чтобы один управлял другим невозможно (например повесить термостат на один и через сеть гонять переменные) т.к. его выходы не отражают его входы (устройства абсолютно идентичны) а добавить переменную нельзя!? - только через МАСТЕР!?

зы Если не прав прошу внести ясность т.к. с LON общаюсь недавно
зы2 Если "Протокол RS485" всплыл после моего поста то внесу ясность - для LON есть много сред прередачи один из них RS485 , FT-10 это тоже частный случай среды передачи поэтому говорить что LON это свободная топология некорректно, что LON с трансивером FT-10 -свободная топология согласен.

[Vasiliy]

Какого это оборудования? Очень частое заявление непонятного мне смысла.

Оборудования самого разнообразного, использующегося в создании инженерных систем зданий.
На прошлой неделе был на объекте. Ситуация типичная для большинства объектов. Здание построили, помещения в аренду сдали, а теперь захотелось иметь диспетчеризацию. Моей целью было провести обследование и составить некое коммерческое предложение.
Результаты обследования:
Автоматика вентсистем разработана фирмой A: в качестве контроллеров использованы Carel. У Carel большое количество интерфейсных карт и в том числе - LON. Решение по интеграции существует!
Автоматика чиллера разработана фирмой Б: в качестве контроллеров использованы Johnson Controls FX15. У JCI есть варианты карт с N2 и LON. Решение по интеграции существует!
Автоматика тепловых пунктов разработана фирмой В: в качестве контроллеров использованы Danfoss ECL300. У Danfoss есть набор интерфейсных карт, в том числе ECA82 с LON. Решение по интеграции существует!
Автоматика котельных разработана фирмой Г: в качестве контроллеров использованы Viessmann Vitotronic (котельная естественно тоже от Viessmann). Vitotronic используют для связи LON. Решение по интеграции существует!
В качестве повысительных станций хоз-питьевого водопровода используются Grundfos. Существует в природе шлюз G10-LON. Решение по интеграции существует!
Добавляем сбор сигналов в виде "сухих" контактов с систем без встроенных коммуникаций, мониторинг вводов ГРЩ.
Вообщем, без замены чего либо с небольшими доработками можно получить нормальную систему диспетчеризации объекта. Причем все системы будут работать на едином протоколе. Соответственно нет необходимости менять контроллеры, искать и покупать дополнительные драйверы, OPC серверы. К тому же использование знакомого системному интегратору протокола приведет к сокращению времени ввода в эксплуатацию.

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

+1 Добавить особо нечего.

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

Бывает и такое. Устройство запрограммировано производителем и у них не было мыслей относительно указанного Вами применения.

только через МАСТЕР!?

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

[GYUR22]

В терминологии да - но не в смысле.
Резюмирую: для LON тоже может понадобится уровень - automation ( другими словами и в других сетях мастер)

[Vasiliy]

В терминологии да - но не в смысле.
Резюмирую: для LON тоже может понадобится уровень - automation ( другими словами и в других сетях мастер)

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

[Reefer]

Как Лон определяет какой снивит к нему пришел? Он не зашивает тип снивита в посылку?

Рекомендую внимательно ознакомиться с презентацией из аттачмента. Особенно начиная со страницы 113, как раз там про тип NV.

Откуда такие сведения? Насколько я успел понять из своего короткого знакомства с лоном, он крайне капризен к физической среде.

Ага... особенно когда использует Power Line. В свое время, когда слушал первый семинар Echelon, Сергей Чемишкян рассказывал, что есть опыт в Австралии, когда в качестве среды передачи данных использовали колючую проволоку, которой были огорожены пастбища. И ведь работало.

Сообщение отредактировал Reefer - 1.10.2008, 13:39

Прикрепленные файлы

 LonTalkProtocolSeminar.zip ( 260,03 килобайт ) Кол-во скачиваний: 95

 

[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, их стали более активно и широко использовать в проектах...

[KDVectra]

to qqq___qqq
"жесткач" - неконкретно. Жизнеобеспечение - понятие широкое. Если Вы хотите его обсудить - welcome.

Теперь о взаимодействии групп Н и С. Допустим, к Вам пришла инфа о том, что в помещении хххх открыты окна и есть человек в нем, Петя Иванов пришел на работу, а Иван Петров ушел. Что с ней делать дальше с точки зрения HVAC?

С точки зрения HVAC, можно как минимум, выключить кондиционер (если это летом), или уменьшить тепло в батареях (если зимой), т.к. вовсе незачем охлаждать/нагревать забортный воздух. Тоже касается вентиляции, особенно приточной. Теперь, ушел и Петя (Ивана давно уже нет), окна закрыты, поставил помещение под охрану, а свет на столе не выключил и кондиционер остался работать, ну, забыл. Так почему бы выключить устройства и не обесточить потребителей... Ночью - энергосберегающий режим, а утром, когда бы не пришел Петя и предъявил свой пропуск (карту) на проходной БЦ, HVAC в его помещении "просыпается" и готовит условия для его комфортной работы. Ну и т.п.

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

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

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

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

1. В ПО для промышленных контроллеров имеются средства для он-лайн отладки программ по сети.
2. Я понял что имелось ввиду Владимир. Те-же промышленные сенсорные панели выпускаются уже больше 10 лет с протоколом профибас к примеру.

С точки зрения HVAC, можно как минимум, выключить кондиционер (если это летом), или уменьшить тепло в батареях (если зимой), т.к. вовсе незачем охлаждать/нагревать забортный воздух. Тоже касается вентиляции, особенно приточной. Теперь, ушел и Петя (Ивана давно уже нет), окна закрыты, поставил помещение под охрану, а свет на столе не выключил и кондиционер остался работать, ну, забыл. Так почему бы выключить устройства и не обесточить потребителей... Ночью - энергосберегающий режим, а утром, когда бы не пришел Петя и предъявил свой пропуск (карту) на проходной БЦ, HVAC в его помещении "просыпается" и готовит условия для его комфортной работы. Ну и т.п.

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

[Гость_ggg__ggg_*]

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

[KDVectra]

to qqq___qqq, честое слово "тяжело" и не потому, что диалог превратился в спор, а потому, что он потерял нить.

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

Да, какие решения-то, каких нормальных, какой предыстории, какой совокупности??? Извините, набор слов...

Выполняет их "головной" софт. Именно поэтому логично получать информацию от него. На каком уровне - дело проектировщика, но нормальные консультанты скажут Заку, что ЛЮБОЙ контакт с сетью С - это потенциальная "дыра". Идеально - односторонний обмен. Как это организовать - это и есть задача для проектировщика. Не обязательно через "сухой контакт".

Конечно, софтом можно всё и передать и получить и т.п. Хотелось, лишь отметить, что если системы готовы аппаратно к интеграции, то за это уже нет необходимости платить, и можно реализовывать взаимодействие без "головного софта". Про "дыры", давайте не будем... В в состоянии оценить степень угрозы от несанционированного управления АЗ???

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

Посмотрите пост. Кажется Вы, что-то выдумали, ничего подобного там не было написано.

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

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

[Гость_ggg__ggg_*]

Расставим точки над Ё. Путаница произошла из-за терминологии. То, что применяется для зданий - это скорее системы Учета, чем ОС или СКУД. В том числе и Itrium. Ну нельзя сравнивать замок на обычном почтовом ящике и какой-нибудь , даже серийный, MultiLock или CISA. У них РАЗНОЕ назначение. Я уже писал, что на ДАННЫЙ момент многих Заков устраивают эти "поделки". Вроде все "как у взрослых", а по сути - "детский сад".
Я АБСОЛЮТНО согласен с тем, что такие системы МОЖНО и НУЖНО интегрировать с АСУЗ. С точки зрения безопасности им это НЕ ПОВРЕДИТ, а инфы дадут много.
Что делать с полученной инфой - это другой вопрос, скорее - тема для отдельного диспута. По теме топика - LON или MODBUS/485 очень хорошо "ложатся" под такие системы.

Сообщение отредактировал ggg__ggg - 6.10.2008, 19:43

[Reefer]

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

LON

Это не только функциональность, но и дизайн конечных устройств. Конечно, формально к протоколам это никак не относится, но тем не менее...

На каплер вешаем любую мордочку из поддерживаемых производителем: Gira, Jung, Berker... и каплер может быть хоть LON, хоть EIB, хоть е2i.

p.s. про дохлый EIB каплер помню, на HTB&H привезу.

[KDVectra]

Расставим точки над Ё. Путаница произошла из-за терминологии. То, что применяется для зданий - это скорее системы Учета, чем ОС или СКУД. ...

Поясните, пожалуйста, что Вы имеете ввиду под понятием "система Учета", и что такое "система Учета" в контексте ОС.

[Гость_ggg__ggg_*]

Поясню. Эти системы предназначены на 99,99% для РЕГИСТРАЦИИ событий. Их "интеллекта" хватает на простейшую логику, типа "совпал код на карточке с кодом в базе AND доступ в данное помещение разрешен = открыть дверь ". Основное - это человек. Это похоже на то, что Вы автоматизировали ИТП , вывели кучу сигналов на экран, но управление клапанами и частотниками оставили оператору. Про устойчивость к взлому и "обману" таких систем говорить просто смешно (ну, чисто замок на почтовом ящике !!!!).
PS Например, название "ВидеоНАБЛЮДЕНИЕ" говорит само за себя. Как говориться, "Пяльтесь на здоровье", потом прокрутите видеозапись и узнаете, что же там произошло и накажете нерадивых охранников, ежель они в живых остануться. Ну или как в кино, милиции запись улицы передадите. В том же кино часто показывают, как это видеонаблюдение обманывают. Правда, это в кино - профессинальные охранные системы так просто не обманешь. Кстати, "детектор вмешательства" и "защитные меры" - одна из ВАЖНЕЙШИХ фишек охранно-тревожных систем.

Сообщение отредактировал ggg__ggg - 6.10.2008, 22:57

[KDVectra]

Поясню. Эти системы предназначены на 99,99% для РЕГИСТРАЦИИ событий. Их "интеллекта" хватает на простейшую логику, типа "совпал код на карточке с кодом в базе AND доступ в данное помещение разрешен = открыть дверь ". Основное - это человек. Это похоже на то, что Вы автоматизировали ИТП , вывели кучу сигналов на экран, но управление клапанами и частотниками оставили оператору. Про устойчивость к взлому и "обману" таких систем говорить просто смешно (ну, чисто замок на почтовом ящике !!!!).

Уважаемый, Вы что-то перепутали, мы говорим о СКУД (СКД), а не об электронных замках. А ведь кто-то не поймет...

PS Например, название "ВидеоНАБЛЮДЕНИЕ" говорит само за себя. Как говориться, "Пяльтесь на здоровье", потом прокрутите видеозапись и узнаете, что же там произошло и накажете нерадивых охранников, ежель они в живых остануться. Ну или как в кино, милиции запись улицы передадите. В том же кино часто показывают, как это видеонаблюдение обманывают. Правда, это в кино - профессинальные охранные системы так просто не обманешь. Кстати, "детектор вмешательства" и "защитные меры" - одна из ВАЖНЕЙШИХ фишек охранно-тревожных систем.

Ну, а Видео сейчас Вы зачем сюда "притянули"? Или это "больная" тема. А-а-а-а, понял, Вы хотите сказать, что настоящая видеосистема - это система видеоОХРАНЫ, ну, что прав ?
К сожалению, Вы просто манипулируете словами, путая при этом, что есть требования по назначению и некие абстрактные представления. Для конструктивного диалога - будьте конкретнее и точнее.

[Гость_ggg__ggg_*]

Уважаемый KDVectra !
У меня нет НИКАКОГО желания устраивать диспуты типа "диалога глухого с немым". СКУД - Система КОНТРОЛЯ и УПРАВЛЕНИЯ Доступом. По-моему, из самого названия вытекают требования к таким системам. Однако КАЖДЫЙ имеет право интепретировать их по-своему. Если Зак принимает Вашу версию- значит Вы понимаете его правильно !
Охранно-тревожные системы - аналогичная ситуация. Вам платят деньги за Ваши решения - значит, Вы правильно понимаете задачу !
"Каждому- свое" - очень мудрые слова.

[Dmitry K.]

Расставим точки над Ё. Путаница произошла из-за терминологии. То, что применяется для зданий - это скорее системы Учета, чем ОС или СКУД. В том числе и Itrium. Ну нельзя сравнивать замок на обычном почтовом ящике и какой-нибудь , даже серийный, MultiLock или CISA. У них РАЗНОЕ назначение. Я уже писал, что на ДАННЫЙ момент многих Заков устраивают эти "поделки". Вроде все "как у взрослых", а по сути - "детский сад".

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

Сообщение отредактировал Dmitry K. - 7.10.2008, 8:00

[KDVectra]

Уважаемый qqq___qqq,
опять неправильная формула . Вы часто манипулируете словами, которые на кого-то естественно действуют, но это именно - манипуляции. К тому же, вместо того, чтобы последовательно и логично идти по пути нормального обсуждения, Вы, к сожалению, "расширяете поляну", нарушая последовательность диалога. Типичный пример с постом в котором Вы зачем-то упомянули видео системы???
Похоже, конструктива действительно не выйдет. Сожалею...

[Гость_ggg__ggg_*]

to Dmitry K.
Простите, а Вы -кто ? За какой продукт Вы "тельняшку рвете" ? Если вы заметили, я старался быть крайне корректным. Единственная торговая марка, которую я упомянул - это Itrium. Но и опять же - что, собственно сказал? Что данная система имеет крайне низкую устойчивость к взлому?
Хорошо, пусть она будет КРАЙНЕ устойчива к взлому - если Вас это удовлетворит. Мое мнение - это МОЕ мнение, никому не объяснять, ни доказывать свою точку зрения я НЕ ОБЯЗАН - это АЛЬФА и ОМЕГА ФОРУМА. Ну а если по делу - раньше, когда я этим занимался, обычно мы заключали Договор на тестирование системы ("санкционированный взлом"+ рекомендации по устранению). кстати, очень недешевое для Заказчика дело. Если у Вас есть результаты по такому тестированию - "снимаю шляпу" и приношу свои извинения - "погорячился, был неправ".

[Dmitry K.]

to Dmitry K.
Простите, а Вы -кто ? За какой продукт Вы "тельняшку рвете" ? Если вы заметили, я старался быть крайне корректным. Единственная торговая марка, которую я упомянул - это Itrium. Но и опять же - что, собственно сказал?...

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

[Гость_ggg__ggg_*]

Какой-то неправильный диалог! Посещать сайт не собираюсь - это РЕКЛАМА. Подпишитесь ЯВНО - и никаких проблем. "Реально сказать" - я же ЯВНО дал понять - только за деньги, причем за ПРИЛИЧНЫЕ деньги. "Любой труд должен быть оплачен" - это мой принцип, уж не серчайте.
А так, "на слабо" - не получится, уважаемый.

[Dmitry K.]

Какой-то неправильный диалог! Посещать сайт не собираюсь - это РЕКЛАМА. Подпишитесь ЯВНО - и никаких проблем. "Реально сказать" - я же ЯВНО дал понять - только за деньги, причем за ПРИЛИЧНЫЕ деньги. "Любой труд должен быть оплачен" - это мой принцип, уж не серчайте.
А так, "на слабо" - не получится, уважаемый.

Посещать Вас никто не просит. Явная подпись - ЭТО РЕКЛАМА (читайте внимательно правила форума).
В такой постановке, дальнейший диалог не интересен НИКОМУ, продолжение его бесцельно, денег всё-равно мы Вам не дадим. На "слабо" - это Ваши рефлексии.
Короче, творческих успехов.

[Гость_ggg__ggg_*]

Значит - Itrium! Я не ошибся в своих предположениях. Ну, тогда - ловите ! (цитаты с ОФИЦИАЛЬНОГО САЙТА)
1) "Гибкая структура ПО позволяет реализовать любые, даже самые специфические требования, предъявляемые к системе безопасности и автоматики здания. С помощью Itrium® soft можно создавать системы, ориентированные не на особенности оборудования, а на технологические требования Заказчика" - "ржу, не могу" - комментарии, думаю, излишни. Осбенно хорошо про "любые, даже самые специфические..."
2) "Поддержка большого числа традиционных средств и систем безопасности даёт возможность построения гетерогенных систем и их постепенной миграции к современным унифицированным сетевым архитектурам" - конкретно, просто и понятно.
3) "Система основана на распределённой, отказоустойчивой архитектуре, со встроенной кластеризацией и автоматическим архивированием".
Про отказоустойчивость и кластеризацию - где расчеты или хотя бы ссылки на СТАНДАРТНЫЕ методики, по которым проводились расчеты. "По ушам ездите", уважаемые. Сертификаты видел, тут все в порядке.
3)"Itrium® soft позволяет существенно расширить возможности оборудования, за счёт реализации программных дополнительных функций, таких как учёт рабочего времени, сменный график работы, глобальный контроль повторного прохода и т.д." - вот и Учет всплыл. "и т.д. " - "а я еще и на машинке вышивать могу..."
4) http://www.itrium.ru/whatsnew/258 - без комментариев. Полностью подтверждает мои слова о целевом назначении - мониторинг, учет, простейшая реакция на простейшие событие. Если ОТС и СКУД понимать как мониторинг и электронный замок с дистанционным управлением - "тагды-ой..." Согласен - С как СИГНАЛИЗАЦИЯ допускает такую трактовку, но уж больно примитивно как-то.
5)http://www.itrium.ru/soft/documentation/69 - прочитал почти все - не поленился. "Простенько и без вкуса". Особенно понравилась "Фотоиндетификация". Чё там ребята из CIA, RCA, КГБ и прочих мелких контор парились , Чего диссера писали про идентификацию объектов ?
Уважаемые! Это называется - ФОТОАРХИВ ! и ни хрена больше !!!!! Не надо терминами бросаться !!!!

демо0весию софта скачивать не стал - думаю, там совсем все печально (судя по скриншотам в документации). Резюме- творческих успехов!

Сообщение отредактировал ggg__ggg - 7.10.2008, 11:30

[Dmitry K.]

А знаете, что... я не хочу продолжать ЭТО.
И "ржать" ВЫ можете сколько угодно. Сожалею лишь о том, что под такое "дружеское ржания" не "рождается секрет" и тем, более невозможен диалог.
Ну что это такое: "Значит - Itrium! Я не ошибся в своих предположениях."? Какой Вы догадливый. Извините, но Вас пришлось "ткнуть носом" в подпись, чтобы Вы до этого догадались. О чем, тогда дальше говорить с собеседником фокусом внимания, которого является он и его взгляды.

За цитаты с сайта отдельное СПАСИБО, особенно учитывая, что речь в них идет о программном обеспечении комплексных систем безопасности. Но, ведь это мелочь, не так ли!!! Удивляюсь, насколько некоторые люди в порыве ярости готовы превращать в фекалии всё, что попадается под их руку. БРАВО Нет комментариев.

Вот и поговорили...

[KDVectra]

Во, как зацепились. Не на жизнь, а на смерть.

Возвращаясь к топику

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

?Может быть дополнить:
- Возможность протокола и наличие средств маршрутизации и фильтрации сетевого трафика. Сегментирование сети.
- Реализация различных типов информационного обмена: запрос/ответ, доставка пакета с подтверждением, многократный повтор.
- Возможность защиты коммуникации устройств средствами протокола.
- Приоритезация пакетов.
- Различные методы адресации: уникальный адресат, группа адресатов, широковещательная адресация.

Важность оценить не готов, но если нет возражений, давайте добавим.

[Pasekov]

LON

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

[Pasekov]

У меня нет НИКАКОГО желания устраивать диспуты типа...
Если Зак принимает Вашу версию- значит Вы понимаете его правильно !
"Каждому- свое" - очень мудрые слова.

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

Ну что возразишь, если ЗАК платит деньги? Ведь всем, надеюсь, известны случаи из истории, когда сначала покупали и только потом разбирались... Если мерило деньги, то раз продал, значит все хорошо... Зачем слушать и понимать специалистов? Они на форуме "ершистые". Только имеет ли это отношение к протоколам???

"Каждому свое..."Надпись на воротах "Бухенвальда"
Воздержусь от комментариев и аналогий... Замечу, что конечно наш диспут о протоколах, не преследует задачу, что бы все стали думать одинаково. Но хочется получить некоторые общие выводы, а не отдельные для каждого...

[Гость_ggg__ggg_*]

Речь как раз про протоколы. Мне кажется, что для "стандартных" ОС и СКУД Modbus/485 (или что-то близкое на 485) - идеальное решение.
Master-Slave технология так же идеально подходит для систем с централизованным управлением. Про ПС ничего не скажу - НЕ СПЕЦИАЛИСТ.
Если же рассматривать ОТС и СКУД как комплексную систему безопасности, то, как я уже писал, требования к протоколам несколько другие.
Применение LON, BACnet для "стандартных" ОС и СКУД возможно, только в чем будет состоять выигрыш? И на каком уровне интегрировать в LON или BACnet? На уровне регистраторов - хлопотно, на уровне контроллера сегмента - зачем ?

[GYUR22]

А может просто посмотреть чем хороши протоколы и подумать что каждому протоколу свое место?

1. Modbus и N2 ( и иже с ними)- простые нетребовательные к вычислительным ресурсам свободные протоколы не требующие лицензий или специальных чипов -чудесно для Field bus

2. LON - технология более продвинута и дорога, хороша тем что стандартизирована+ есть P2P, но необходимы специальные чипы и софт
плюс : стандартизация!, много сред передачи данных ,есть много устройств, почти pnp и все со всем работает
минус: практически невозможно сделать дешевое устройство на LON в связи с ценй 3150 + FTT-10 трансивер, ну и по мелочи

3. BACnet - технология выросшая на уже несколько иной системной базе более требовательна к системным ресурсам+есть P2P "hungry for code" не требует лицензий или специальных чипов
плюсы: много сред передачи данных, PNP, почти все со всем работает , динамично развивается
минус: пока мало устройств, сложная реализация стэка протокола

имхо

если что поправьте

ps из моей практики заказчикам в 95% случаев все равно какой протокол

Сообщение отредактировал GYUR22 - 8.10.2008, 13:59

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

А может просто посмотреть чем хороши протоколы и подумать что каждому протоколу свое место?

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

[Sun technik]

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

Будет ниже надежность системы. Получается, что панель будет взаимодействовать с некоторыми контроллерами через свой мастер-контроллер или же через общий мастер. А насчет разработки - все эти взаимодействия в случае применения того же LON'а осуществляются элементарно соединением нужных сетевых переменных, всё происходит моментально. К тому же во многих LON устройствах (и в большинстве KNX) и разрабатывать софт самому не надо - достаточно лишь выбрать нужные для конфигурации параметры.
Вот и вопрос - ЗАЧЕМ для задачи, где нужна связь point to point и уже существуют готовые решения, изобретать велосипед, который еще скорее всего проиграет в качестве?

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

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

А теперь вопрос: В ПО для промышленных контроллеров имеются средства для он-лайн отладки программ по сети.
Как с этим в ЛОНе?

У Sysmik'а в ПО для разработки приложений IPOCS такая функция есть. Больше ни у кого не помню.

[Pasekov]

У Sysmik'а в ПО для разработки приложений IPOCS такая функция есть. Больше ни у кого не помню.

О как!
А может и Refeer еще вспомнит? Dmitry K. - Вы тоже возвращайтесь в диспут...

А вот кстати и вопрос. Плюсы наличия возможности оттестить программу по сети для АСУ ТП, мне понятны. А вот для АСУЗ мне это кажется сомнительным +. Задачи в большинстве случаев не той важности, а если задача важная, то решать ее скорее всего надо по другому. Кроме этого, зачастую в АСУЗ предполагается "солянка" из оборудования и протоколов. И каким ПО это реально делать? И как? По очереди?
Что скажите ggg и Сергей? Насколько этот + принципиален в нашем диспуте, его стоит заносить в наши пункты?
Я 5 пунктов KDVectra заметил, но про фунцию тестирования было ранее, поэтому хотелось бы разобраться до конца, чтобы потом не забыть...

[GYUR22]

Ok
преимущества и недостатки-profibus, profinet и какие там еще есть промышленные протоколы - в студию!
а то непонятно разговор о чем ...

[Гость_ggg__ggg_*]

Отладка по сети ПО - удобно, но совсем не обязательно. Поясню. Отлаживать АЛГОРИТМЫ нужно находясь недалеко от оборудования, чтобы непосредственно наблюдать реакцию "железа". Проводить по сети диагностику системы или перенастройку - тоже проблематично по сети, т.к. тоже надо "живьем" наблюдать за реакцией. Удаленная загрузка ПО - это удобно, когда в однотипных системах найден общий баг или производится модернизация ПО. Кроме того, если очень надо, то есть другой, очень простой метод - один ноут подключается локально к контролеру, рядом - человек, который контролирует происходящее, а программист СТАНДАРТНЫМИ способом удаленно управляет ноутом. Метод широко применяется, когда лень выезжать на объект, а там есть интернет.
PS Кстати, Siemens SBT XWORKS поддерживает удаленную загрузку и отладку, но опять же желательно, что человек с рацией был рядом с оборудованием - "на всякий пожарный".

Сообщение отредактировал ggg__ggg - 9.10.2008, 6:33

[Dmitry K.]

...А теперь вопрос: В ПО для промышленных контроллеров имеются средства для он-лайн отладки программ по сети.
Как с этим в ЛОНе?

Что касается ЛОНа, то наиболее распространенным на сегодняшний день средством создания программ (микропрограмм) для устройств ЛОН является NodeBuilder компании Echelon (это не реклама). Этот инструмент позволяет писать и компилировать программы для нейрон-чипов. Этот же инструментарий позволяет компилировать Дебаговые версии программ, которые в реальном времени по сети можно отлаживать, в т.ч. с пошаговым выполнением. Это удобно, но не на объекте, так как отладка естественно загружает сеть своим трафиком, а значит "картина" сетевого взаимодействия реальной системы некоторым образом меняется. Из практики, ни один из наших разработчиков не отлаживал программы прямо на объекте никогда. В стендовых условиях конечно это удобно и очень полезно, особенно во взаимодействии с другими устройствами.
В отношении так называемой "программы сети" соглашусь с Sun technik "...осуществляются элементарно соединением нужных сетевых переменных, всё происходит моментально. К тому же во многих LON устройствах (и в большинстве KNX) и разрабатывать софт самому не надо - достаточно лишь выбрать нужные для конфигурации параметры."
"Программирование сети" выполняется средствами сетевого менеджмента (например, LonMaker для ЛОН), которыми можно промониторить работу устройств в сети, и протестировать устройства по сети можно, и статистику получить от устройств можно.

Резюме. Поддержу ggg___ggg - "Отладка по сети ПО - удобно, но совсем не обязательно."
Добавлю - Отладка "программы сети" по сети - необходима и обязательна.

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

Что касается ЛОНа, то наиболее распространенным на сегодняшний день средством создания программ (микропрограмм) для устройств ЛОН является NodeBuilder компании Echelon (это не реклама). Этот инструмент позволяет писать и компилировать программы для нейрон-чипов. Этот же инструментарий позволяет компилировать Дебаговые версии программ, которые в реальном времени по сети можно отлаживать, в т.ч. с пошаговым выполнением. Это удобно, но не на объекте, так как отладка естественно загружает сеть своим трафиком, а значит "картина" сетевого взаимодействия реальной системы некоторым образом меняется.

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

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

Это как плюс так и минус, быстрое программирование стандарных задач зачастую делает невозможным программирование не стандартных.

Будет ниже надежность системы. Получается, что панель будет взаимодействовать с некоторыми контроллерами через свой мастер-контроллер или же через общий мастер. А насчет разработки - все эти взаимодействия в случае применения того же LON'а осуществляются элементарно соединением нужных сетевых переменных, всё происходит моментально.

Аналогично эти задачи решаются и в профибасе. Просто не снивитами, а физическими адресами памяти.

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

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

[Гость_ggg__ggg_*]

С предложением г Сергея Долганова выделить вопрос цены в отдельную статью не согласен. Я думаю, что одна из причин распространение LON- технологии и была ЦЕНА ("свободная топология" - бонус ). Попробую пояснить свою мысль. 10 лет назад стоимость сетевых адаптеров была достаточно велика (я имею ввиду почти все промышленные протоколы, включая и Ethernet). Echelon "подсуетился" и предложил достаточно развитый протокол с фактически аппаратно реализованным стеком ( не совсем, конечно, аппаратно, но для ОЕМ-производителей практически так и есть), причем по ОЧЕНЬ невысокой цене. Простота интегрирования этого протокола в аппаратно-программный комплекс контроллера так же достаточно проста, а возможностей - море. Понятно, что Echelon обещал сделать нечто подобное для различных сред, включая и беспроводную сеть. Для пространственно-распределенных систем это просто "супер". Правда, и royalty и кредиты "всплыли", но - это " относительные центы" по тем временам. Заявление об "открытости" протокола тоже сыграло свою роль (потом $230 стали за текст брать). Вот и "клюнул" ОЕМ. Теперь же,
когда прогресс в развитии аппаратно-программных средств свел преимущество в цене" на нет", выяснилось, что не все так хорошо с этим LON.
Оборудование для Ethernet почти сравнялось LON. 485 вообще "копейки". Да и беспроводной Ethernet есть, а про LON- что-то не встречал.
Так что цена - это был один из важных факторов в "прорыве" LON.
Теперь насчет контроллеров. Nodebuilder - это для "простенького и голенького". Как я отмечал выше, тем и силен был Echelon, что дал готовый стек, который легко "прицепляется" к основному процессору. Тот же ТАС, WAGO, Siemens SBT интегрировали его в свои контроллеры. Процесс
отображения внутренних данных на SNVT практически скрыт от прикладного программиста. Да , иногда требуется сторонний софт типа LonMaker для конфигурирования сети, а иногда производитель автоматизирует и этот процесс (если в сети только его контроллеры). Так что, вынужден отметить - участие программиста в конфигурировании сети может быть и незначительным. НО не все так хорошо. Когда в сети задействованы устройства различных фирм, часто начинаются "заморочки" и "танцы с бубном".

Сообщение отредактировал ggg__ggg - 9.10.2008, 17:47

[GYUR22]

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

А кому кроме LON еще нужен сторонний софт для создания сети?

[Sun technik]

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

Сторонний софт для создания единого проекта сети преследует некоторые важные цели:
- разделение труда между инженерами. Одни занимаются разработкой ПО устройств, а другие - интеграцией в сеть. В последнее время мировые тенденции таковы, что интеграторы могут не иметь особого образования, это очень важно при инсталляции крупных объектов, где требуется ОЧЕНЬ МНОГО инженерных ресурсов (и соответственно финансирования этих работ). В то время как большинство систем - шаблонные. Рекомендую посмотреть, что делают для этого Neuron Systems, в их схеме установки с сетей должен быть один хороший специалист, который создает шаблоны для инсталляций, а потом менее профессиональный состав занимается пуско-наладкой объекта.
- в связи с "шаблонностью" систем максимально актуальны функции copy-paste при создании сети, а также быстрое внесение изменений в уже установленную сеть. Предположим, в 200 похожих системах нужно заменить одну из связей между устройствами. При этом настройки контроллеров могут быть индивидуальны, просто они подгрузятся отдельно. А в Вашем случае придется ковырять программу под каждую конфигурацию контроллеров и еще содержать архив файлов для каждого из них (вместо единой базы сети). Потом см. выше про разделение труда. ИМХО по возможности не стоит в случае, когда задача решается на "менее квалифицированном" уровне (то бишь переконфигурация сети, возможно, изменение настроек Configuration properties на устройствах), залезать на более выский уровень (изменение ПО контроллеров). Это очень важно и при последующей эксплуатации проекта. Кстати в сетевых инструментариях LON есть разделение уровней доступа, что очень полезно.

Это как плюс так и минус, быстрое программирование стандарных задач зачастую делает невозможным программирование не стандартных.

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

Не так уж дороги маленькие тачскрины нонче.

Много ли тач-скринов, которые Заказчику (т.е. с учетом накрутки цены поставщиком) обойдутся до 300 евро и устроят по дизайну? Учтем еще и источник питания, и какую-то коробку для его размещения (равно как и место для размещения и подвод питания), в то время как в KNX и LON'е куча панелек с питанием от линии.
Да и надо ли ставить тач-скрин, когда нужно 4 кнопки управления и мониторинг температурной уставки? Да, большинство климатических панелек имеют встроенный датчик для измерения температуры воздуха. В случае тач-скрина нужен будет внешний датчик и соответственно где-то аналоговый вход для него. Если датчик сетевой, то добавляется узел сети.
Сразу оговорюсь, что эти факторы по-настоящему важны когда речь идет не о трех панельках на объект, а когда их десятки.

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

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

Отладка по сети ПО - удобно, но совсем не обязательно. Поясню. Отлаживать АЛГОРИТМЫ нужно находясь недалеко от оборудования, чтобы непосредственно наблюдать реакцию "железа". Проводить по сети диагностику системы или перенастройку - тоже проблематично по сети, т.к. тоже надо "живьем" наблюдать за реакцией.

За реакцией можно наблюдать по дистанционно передающемуся состоянию хардварных входов-выходов. Естественно при этом предварительно система должна быть хорошо прозвонена и налажена, в общем должна быть УВЕРЕННОСТЬ в том, что ничего страшного не произойдет.
У меня были случаи наладки систем, состоящих из нескольких контроллеров, навороченно связанных друг с другом по сети peer-to-peer и сильно разнесенных дистанционно (например, система электроснабжения с резервированием, единая на несколько корпусов объекта). При этом возникала необходимость понять, почему же соседние контроллеры не выдают ожидаемую реакцию, а по одним лишь SNVT догадаться в чем дело - нереально.
Вообще беготня по большому объекту в момент стройки (когда часть лифтов не работает, а другая часть вечно занята строителями, проход по коридору закрыт в связи с укладкой плитки, ключи от венткамеры - у дяди Феди, который, говорят, ушел на минус 2-й этаж не то в раздевалку обедать, не то в ЦТП, не то на склад, ) - отнимает очень много полезного времени, причем часто нужно сделать какую-то 3-минутную ерунду, ради которой убьется полчаса.

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

Сторонний софт для создания единого проекта сети преследует некоторые важные цели:
- разделение труда между инженерами. Одни занимаются разработкой ПО устройств, а другие - интеграцией в сеть. В последнее время мировые тенденции таковы, что интеграторы могут не иметь особого образования, это очень важно при инсталляции крупных объектов, где требуется ОЧЕНЬ МНОГО инженерных ресурсов (и соответственно финансирования этих работ). В то время как большинство систем - шаблонные. Рекомендую посмотреть, что делают для этого Neuron Systems, в их схеме установки с сетей должен быть один хороший специалист, который создает шаблоны для инсталляций, а потом менее профессиональный состав занимается пуско-наладкой объекта.
- в связи с "шаблонностью" систем максимально актуальны функции copy-paste при создании сети, а также быстрое внесение изменений в уже установленную сеть. Предположим, в 200 похожих системах нужно заменить одну из связей между устройствами. При этом настройки контроллеров могут быть индивидуальны, просто они подгрузятся отдельно. .

Эти пункты важны для Ваших сетей, для ЛОНа в смысле. У меня, как Вы справедливо заметили, все связаны со всеми через мастер. Настройки сети можно подгрузить отдельно от программы.

А в Вашем случае придется ковырять программу под каждую конфигурацию контроллеров и еще содержать архив файлов для каждого из них (вместо единой базы сети). Потом см. выше про разделение труда. ИМХО по возможности не стоит в случае, когда задача решается на "менее квалифицированном" уровне (то бишь переконфигурация сети, возможно, изменение настроек Configuration properties на устройствах), залезать на более выский уровень (изменение ПО контроллеров). Это очень важно и при последующей эксплуатации проекта. Кстати в сетевых инструментариях LON есть разделение уровней доступа, что очень полезно

Зачем это программу ковырять? Архив каких файлов?

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

У Вас очень цивилизованая компания, я вам завидую, честно без издевок.

Много ли тач-скринов, которые Заказчику (т.е. с учетом накрутки цены поставщиком) обойдутся до 300 евро и устроят по дизайну? Учтем еще и источник питания, и какую-то коробку для его размещения (равно как и место для размещения и подвод питания), в то время как в KNX и LON'е куча панелек с питанием от линии.
Да и надо ли ставить тач-скрин, когда нужно 4 кнопки управления и мониторинг температурной уставки? Да, большинство климатических панелек имеют встроенный датчик для измерения температуры воздуха. В случае тач-скрина нужен будет внешний датчик и соответственно где-то аналоговый вход для него. Если датчик сетевой, то добавляется узел сети.
Сразу оговорюсь, что эти факторы по-настоящему важны когда речь идет не о трех панельках на объект, а когда их десятки.

Я не делал объектов с десятками панелек (имхо не очень это правильно). В ваших словах есть резон, согласен если заказчик хочет миллион панелек - ЛОН его выбор.

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

Давайте привязыватся к конкретной цене, которая будет определятся оборудованием в первую очередь. Расходы на ПО (не знаю как у Вас) -это зарплата программиста.

[s60]

Ok
преимущества и недостатки-profibus, profinet и какие там еще есть промышленные протоколы - в студию!
а то непонятно разговор о чем ...

Lightbus, PROFIBUS DP/FMS, Interbus, CANopen, DeviceNet, ControlNet, Modbus, Fipio, SERCOS, Ethernet TCP/IP, AS-i.......


поправьте, ежели что не так....

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

FMS умер. Вобщем и DP идет к тому же.

[Kass]

Вот такую «новую» тему хочется предложить.

ИМХО гармоничного диспута не получтся, т.к у всех свои понятия об АСУЗ. Большинство минималисты в АСУу, я скорее отношусь к максималистам. Если это еще положить огромное разнообразие используемых коллегами стандартов и брендов, то получится слишком широкая гамма для обсуждения. Критерии оценки тоже весьма размыты. К примеру первый работает всю жизнь на платформе А, используемой протокол Б, а другой уже вжился в платформу В на протоколе Д. Кто может рассудить в форме, кто более прав? Все сведется к фалометрии и не более. ИМХО если и говорить об АСУЗ, то только концептуально, не трогая протоколы или платформы.

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

В моих проектах подсистемы очень сильно взаимосвязаны и информации между ними передается море. Вот некоторые примеры:

1. "Охранка"-HVAC: Если помещение поставлено под охрану, то вентиляция в нем снижается до мимнимума, обесточиваются некоторые цепи, закрываются рольставни или жалюзи...
2. "Пожарка-HVAC: Если в помещении возгорание, то отключается вентиляция, включается дымоудаление. В крупных зданиях, где помещений сотни или тысячи, отключается не вся вентиляция в здании, а локальная зона. Сколько зон, столько и сигналов.
3. СКД - "Охранка": Если здание покунули все служащие определенного помещения, то помещение следует поставить на охрану автоматически. Как только пришел первый служащий из определенного помещения, то помещение надо снять с охраны.
4. СКД-HVAC: Производительность вентустановок зависит от количества людей, вошедших в здание и прописанных в зоне вентустановки. Т.е. если вентустановка работает на 8 этаж, на ктором максимум бывает 400 человек, то при наличии в здании 300 человек установка будет работать на 75% производительности. Если после работы 10 человек задержались, то ради этого вентиляция не должна работать на полную, она обеспечит приточным воздухом только эти 10 человек.
5. Видеонаблюдение-HVAC: В случае получения сигналов НСД, Протечка и многих других на АРМы выводится изображения с видеокамеры объекта автоматизации. В цифровых системах с использованием IP камер никаких проблем нет в использовании одной и той же камеры в разных системах.
6. Пожарка-Видеонаблюдение. При получении сигнала Пожар в помещении, на экран выводится видеоизображение с этого помещения.
7. "Охранка-Видеонаблюдение: Аналогично п.6 по сигналу тревога автоматически выводится изображение нужной камеры. Думаю не надо объяснять, что без этого найти в сотнях видеоэкранов нужный быстро не получится.

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

[Abysmo]

Вобщем и DP идет к тому же.

Почему? Мне кажется он просто станет аналогом AS-i, т.е будет связывать полевое оборудование, верхний уровень будут делать на Profinet.

[GYUR22]

Lightbus, PROFIBUS DP/FMS, Interbus, CANopen, DeviceNet, ControlNet, Modbus, Fipio, SERCOS, Ethernet TCP/IP, AS-i.......

не видно до сих пор чем же они лучше? или хуже? Архитектура, среды передачи,p2p, master-slave?
Wikiedia спасет:

1.PROFIBUS (DP, PA, FMS) -среда близка 485 есть и мастер слейв и обмен между мастерами
2.PROFINET -среда Ethernet относительно новая 2001г
3.As-i -промышленная шина свободная топология , спец кабель , плохо подходит для аналоговых сигналов
4. Modbus-практиески такой же домашний
5.CANopen - часто приеняется в автомобилях для сязи "внутренних органов", естьще просто среда CAN ( с любым протоколом)
6.DeviceNET - похоже на CAN утойства - клиенты возможен p2p

ps 1,2 -протоколы Siemens

поправьте ежели что

[Abysmo]

5.CANopen - часто приеняется в автомобилях для сязи "внутренних органов", естьще просто среда CAN ( с любым протоколом)
6.DeviceNET - похоже на CAN утойства - клиенты возможен p2p

Вы не совсем правы. CAN - физическая шина, в своем составе имеющая реализацию нескольких уровней. Т.е. он изначально разарбатывался для общения различных устройств внутри автомобиля, поэтому физически связанные CAN устройства могут общаться между собой без применения протокола (чего не может например Ethernet и EIA-232/485). CANOpen, DeviceNet, SDS и еще наверное десяток протоколов (например у российских счетчиков "Меркурий") - это надстройки на CAN, реализующие возможности верхних уровней, например передачу сообщений, адресацию и т.п.
CAN хорошая шина, но имеет один недостаток - скорость обмена жестко привязана к длине шины.

ps 1,2 -протоколы Siemens

Добавьте 3 пункт, родоначальником был Siemens.