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

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

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

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

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

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

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

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

По-поводу 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 части поста....

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

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ключевые слова "короткое знакомство", а не "капризен". Расскажу историю. Есть в Питере завод. На заводе есть станки, прессы, бааальшие вентиляторы и прочее. Все вентоборудование, тепловые пункты сделаны на контроллерах с 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". Но это уже к извечной русской проблеме: сначала сломаем (сделаем не то), а потом мануалы читаем. Вообщем-то пример, как раз показывал, что сделанное не по правилам все равно работает.

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

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



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


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

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


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

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

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

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

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

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

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


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


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


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

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

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

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


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

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

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

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

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


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

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

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

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

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

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

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


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

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

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

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



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


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

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

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

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




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

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


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

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


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


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

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

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

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

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

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

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

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

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