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

[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