В данном случае я не претендую на правоту
но написал нечто подобное только кратко

Прошу извинить, не всегда успеваю...
1. Влез немного в этот вопрос и вижу, что такое ПО появляется и в АСУЗ. Может мало используется, но оно есть.
2. Нет Вы не поняли. Тем более, что потом была ирония про миллион Лон-панелей.
Смотрите. Если мы говорим про управление, про то, что для чего-то допустим достаточно 4 клавиш(только для примера), то я с Вашим подходом полностью согласен. Действительно панели были, есть и будут. Правда мне не совсем понятно, что делать если на объект попали контроллеры с ...bus и панели с другим ...bus
А вот в здание, в жилом, так не получится, с промпанелями. А писал уже - требуется дизайн рамки, причем различный...пардон, под остальные выключатели...
3. Думал и об этом. Наверное надо пока оставить в стороне. Так как правильно говорить все-таки о ССВ(совокупной стоимости владения, а не только стоимости промконтроллера или еще ужаснее только модуля ввода/вывода), а это уведет нас в сторону от рассуждений о протоколах...Имхо.

Приветствую дорогой Kass! Спасибо, что приняли участие...
1. Где Вы видели на этом форуме гармоничный диспут? Не буду спорить по понятиям, а вот о предмете диспута мы все довольно хорошо вначале договорились...
2-3. Минимум комментариев (см. 15 пунктов ниже). Платформы мы договорились не трогать, а протоколы только обсуждать...
4. Для передачи нужна сеть и протокол? У Вас она одна и он один для всех задач?
5. Не совсем. Не будем повторяться, уже и ggg_ggg говорил, да и другие добавили.
Далее, во-первых есть международные стандарты для АСУЗ ISO 16484.
Во-вторых есть ГОСТ 22.1.12-2005.
В-третьих есть МГСН 4.19-05 с приложениями 13.1 и 13.2...

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

Тут дело уже не сколько в мастерах и пир-ту-пирах, а в возможности быстро тиражировать решения на объекте, причем не супер-специалистами (и не за супер-зарплату). Честно говоря, я не большой знаток Профибаса, потому вопрос, насколько профессионален должен быть специалист, которому доверят инсталляцию и эксплуатацию (в смысле внесеня доп. изменений) такой сети? А если накосячит?


Сорри, немного ступил.
Хотя все же есть один момент. В LON'е устройства включают в себя Functional blocks и связи между переменными могут осуществляться как в случае принадлежности этих функциональных блоков разным физическим устройствам, так и одному. Так называемый turnaround binding, в этом случае при отправке пакета устройство само определяет, что сообщение адресуется ему же, и в сеть оно не попадает. Применяется такое довольно часто. В случае мастер-слейва изменение такой связи означает либо изменение программы локального контроллера, либо дополнительный трафик в сети.


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


Ээээ... Почему неправильно??


Ну да, ЛОН как раз хорош при большом числе однотипных систем со связями peer to peer.
ИМХО, если речь идет о диспетчеризации трех вентустановок, ЦТП, пары прецизионников и тройки электрошкафов и несильного взаимного обмена между системами, то тут технические и инженерные преимущества протокола уходят на второй план, а важна стоимость конкретного железа.


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

Тема подувяла... Зайдем с другой стороны... Доказательство от обратного.
Обсудим ДРУГИХ, начнем с этой четверки:
1. Modbus
2. DeviceNET
3. PROFIBUS DP
4. CANOpen
Конечно можно добавлять...
А теперь вопросы. Кто из Вас их применяет для задач автоматизации зданий?
Почему?
Можете "на пальцах" рассказать про них?
Или ответить на мои простые вопросы?
З.Ы. Если есть трудности с изложением своих мыслей в формате Форума, то готов лично написать или позвонить, направить список вопросов или табличку для заполнения...

Не то что бы мы сильно специализировались на автоматизации зданий, но на вопросы о Modbus ответить могу.

Гранд мерси!
Как лучше? Прямо в форуме вопросы или типа таблички в почту?
Объясню разницу. Мне важнее информацию получить, чем доставить неудобство, случайно показав, что на какие-то моменты ответы не совсем получаются.

Всеравно. Не получающиеся ответы это повод лучше изучить тему

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

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



Именно это и используем.



Абсолютно верно.



Смотря где не критична. Очень часто не критична скорость, но задержки недопустимы.



Ну это элементарно. Если где то этого нет, то ужасно.



Тунелирование поддерживается сетевым оборудованием. Зачем дублировать? Берите любой VPN роутер и делайте тунели. Зачем автоматику сюда преплетать? Ей достаточно поддерживать IP.



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



Куда уж экономнее?



Если речь именно о сети, не о шине, то зачем изобретать велосипед, если интерфейс Ethrnet и протокол IP отвечает всем условиям?

Вот это как то не понятно. Т.е. что бы сеть мог настроить ветеринар или геолог?



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



ИМХО опять в IP все есть.

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

Простите, а что использование коммутаторов Ethernet разве не рашает для Вас задач устранения коллизий!? И неужели Вам не хватает 100 мегабитных портов? Какое же время отклика Вы пытаетесь достичь?

Насколько понимаю, в этом контексте туннелирование - это не VPN (не забываем, что VPN - Виртуальная Частная Сеть), а возможность трансляции данных протокола автоматизации через ЛВС для задач информационного связавыния разных сегментов. Это дает возможность разным фрагментам автоматики "общаться" друг с другом через ЛВС. Сама по себе поддержка IP не является способностью к взаимодействию отдельных частей.
Точно, вопрос только в том, что для каждого устройства нужен свой порт Ethrnet, свой фрагмент СКС, да и стоимость имплементации Ethrnet и стека протоколов IP пока высоковата. Т.о. совокупная стоимость владения будет неминуемо выше.

Мастер сдох - это не проблема. Для объектов 1 категории дублируются не только мастера, а подсети. К примеру щит управления регуляторами котельной двойной и вы всегда сможете сменить один комплект автоматики на другой прямо сдиспетчерского пульта. Если умер мастер, то переключается надругой комплект и все. Если работа оборудования не столькритична к примеру БУК. Ну помер там мастер, отключился котел, пропала готовность и включился резервный котел. Реакция слейвов при пропадании связи с мастером прописывается в алгоритме.
Чтение пременных из слейвов читается в начале цикла. Запись переменных в слейвы осуществляется в конце цикла. Весь обмен умещается в цикле. Для меня это самое важное.
Несколько мастеров в сегменте - это фантастика. Вы при первом включении об этом узнаете. Целостность данных можете сами обрабатывать как угодно, к примеру для аналоговых параметров фильтрами.



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


Тунелирование - это не VPN, но в роутере прописываются VPN ка раз для организации тунелей между VPN через интрасети. Для связывания сегментов используются маршрутизаторы. Причем тут тунели? Тунель может работать в одном сегменте, как и мост и не разделит вам сегменты сети. Здесь вы несколько путаетесь.

Не нужен каждому устройству порт Ethernet, а нужен только каждому мастеру. Для каждго ТОУ делается обственная система управления на шине со своим мастером, а уж системы объединяются через СКС на верхнем уровне. По верхнему уровню передаются несколько общих параметров, к примеру Тнар, Пожар, АВР... и параметры для диспетчеризации. Для таких параметров не так важно попадать точно в циклы систем.

Использую только Modbus, очень прост в реализации. Можно самому запрограммировать интерфейс и в контроллере, микроконтроллере и на сервере, шлем вручную командой ToCom набор байт, всё ясно и прозрачно. Смотрится любой терминалкой, особенно Modbus ASCI
На низких скоростях к RS485 шине можно лепить все что угодно, хоть реализовывать свободную топологию (2.4-9.6 кбит), на скорости 38.4 и выше, участки по сотни метров могут "оглохнуть", становятся нужны согласующие резисторы, шинная топология.
Устойчивость к помехам зависит опять же от скорости, длины проводов, качества витой пары, для диспетчеризации применяем не экранированную витую пару в сотни метров, иногда даже телефонные провода
Задержка существенно больше милисекунд (это не Ethernet) сотни милисекунд минимум. Оборудования с поддержкой Modbus немерянно, тунелирование через интернет, gprs проще простого, вплоть до того что Modbus устройство за сотни км можно опрашивать как находящееся на виртуальном СОМ порту компьютера.
Недостатки - ограниченное адресное пространство устройсв на одной шине, 255 и все...

Конкуренты Modbus, возможно, создавались в момент когда возможностей контроллеров не хватало чтобы поддерживать Ethernet (IP стек создать и обработать посложнее чем modbus посылку), а modbus протокол не обеспечивал нужной скорости. Появились замечательные быстрые протоколы связи, соответствующая аппратная поддержка. А потом пришел прогресс и Ethernet стал везде, по умолчанию, и в контроллерах, и в линиях связи.

А причем это к АСУЗ? Покажите пример хоть одного проекта хотябы с 200 устройств на одной шине. Ну может быть хоть 150.... или 100?


Я боюсь, что вы сильно путаете понятия шина и сеть. Они похожи, но между ними пропасть. У нас есть объекты, составные части которых разбросаны на 300 км. Вы бы как их связали по модбасу?

Преобразователь интерфейсов RS-485/232 -> мультиплексор первичного доступа -> оптический мультиплескор -> SDH провайдера -> оптический мультиплескор -> кросс-коннектор - мультиплексор первичного доступа -> приемник информации. Возможны варианты ЦРРЛ, спутник... вариантов много

Это очень просто пока вы реализуете Modbus на самом минимальном уровне, когда начинается реализация дополнительных функций, оптимизация обмена, более полное следование стандартам все становится сложнее и интереснее. (особенно когда нужно что-то чего в Modbus никогда небыло, нет, и не будет)



В одной моей системке цикл обмена данными (всеми какие есть) по Modbus-RTU на скорости 28800 занимает 90 миллисекунд, можно было сделать и быстрее. Конечно далеко не с любым оборудованием можно рассчитывать на рекорды скорости



Вы забываете про существовавший когда-то быстрый и аппаратно поддержанный Modbus Plus и путаете протокол и интерфейс по которому производится обмен данными. Сам по себе протокол имеет небольшое отношение к скорости обмена, хотя в стандарте есть моменты которые могут делать скорости выше 19200 бесполезными (когда используется RS485 и т.п.)



Modbus-TCP и интернет

Используем DeviceNet, не только его конечно, есть системы и на Profibus, Modbus..., но чаще всего именно DeviceNet.
Из проектов близких по тематике к форуму, это вентиляция и водоснабжение пром. объектов.
Системы на DeviceNet получаются чуток по дешевле (по крайней мере у нас), чем на Profibus, да и менее капризная эта сетка. Ну, и возни меньше, чем с Modbus.
Очень радует и облегчает жизнь наличие 4 типов обмена данными со slave:
- Опрос (Polling): опрашивающее устройство поочередно запрашивает данные из каждого конкретного устройства сети либо посылает данные в это конкретное устройство.
  
- (Широковещательное) стробирование (Strobing): опрашивающее устройство посылает подчиненным устройствам общий запрос, после чего подчиненные устройства по очереди отсылают главному данные о своем состоянии (первым отвечает узел с номером 1, вторым с номером 2 и т.д.). Меняя порядок нумерации узлов, можно задавать приоритетность сообщений.
  
- Периодическая отсылка (Cyclic): сетевые устройства автоматически с установленной периодичностью передают центральному узлу сведения о своем состоянии. Сообщения данного типа, называемые иногда heartbeat-сообщениями (сообщениями типа "я живой").
  
- Изменение состояния (Change of State): отсылка сообщения происходит только по факту изменения состояния устройства. Данный метод отличается наименьшими временными затратами; при этом в крупных сетях его производительность может оказаться выше, чем в сетях с использованием метода опроса и с гораздо более высокой скоростью передачи. Метод Change of State является самым экономичным с точки зрения временных затрат, но, вместе с тем (иногда), и наименее точным, поскольку производительность и время отклика становятся статистическими, т.е. непредсказуемыми величинами.

То есть, например, используем Cyclic для аналоговых входов и опрашиваем их раз в 10 сек, а для остальных по Strobing.

+ Подача питающих 24 В по сетевому кабелю.

Если нужно, что бы узел работал по какому-то хитрому алгоритму при обрыве связи ставим микрокотроллер с поддержкой DeviceNet.

И все эти сложности только для точка-точка. А если нужно объединить в сеть множество точек? Вы себе хоть масштаб затрат представляете?

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

Тонко и метко. Гранд мерси в квадрате!
Файл в приложении. Пароль сбрасываю на личку.
Полученный материал будет использован для целей обучения.
Готов вместе обсудить и любые другие варианты...
Поэтому просьба давать картинки (слайды) и поясняющий краткий текст.
Я дал примерный план. По такому плану есть материал KNX/EIB, LonWorks. Могу показать для примера.

Масштаб? Да конечно. Мое предприятие было создано и занимается эксплуатацией систем связи, телемеханики и информационных технологий для энергосистемы области. Сотни объектов, 100% резервирование каналов связи, сотни тысяч сигналов, десятки АТС, много интерфейсов, протоколов... А после пилежки РАО еще и куча энергокомпаний... Да и цены наши для "своих" вполне демократичны, так как воспользоваться опорной сетью крупного провайдера "оптом" вполне приемлемо.
В этом году ввели в строй спутниковые каналы связи для передачи голосовой и технологической информации, не ах конечно, но вполне работоспособно. Передать с одной подстанции сотню сигналов, по стыку Ethernet с пропускной способностью 9600 бит/с, получилось. Задержка передачи по спутнику - 1,5 секунды. К таким задержкам, при голосовой связи, привыкать надо. Непривычно ) А вариантов других не было, хоть и дорого за аренду канала.
Есть и интересные факты. На одном из комплексов телемеханики (сервер ТМ одного из ПЭС) порядка 40 стыков RS-232 (коммуникационные контроллеры) работают по 100 парному телефонному кабелю ТПП на расстоянии порядка 250 метров до модемов, к модемам подходит ВЧ-связь и клс с разных направлений. Работают с 2001 года. Но и скорости п.д. там 100-200 бод. Не подумайте чего плохого.
Ethernet: Для межсерверного обмена телеинформацей между предприятиями (порядка 2-3 тыс. сигналов), отводим два тайм-слота (128 кбит/с) Протокол МЭК 870-5-104, транспорт ТСР/IP. Режим обмена - спорадический. Есть районы, где канал передачи данных всего 64 кбит/с, в том же протоколе и режиме, но в общем потоке данных, объем информации 500-700 сигналов. Приоритизация передачи технологической информации обеспечивается средствами QoS маршрутиризаторов Cisco.
Не важен тип протокола или интерфейса, а вот сколько мы готовы вложить в последнюю милю? Сейчас сотовые операторы часто ставят свои антенны на административные здания, а опорная сеть в основном ЦРРЛ (стык Е1) и почти всегда недогружена. Договориться можно и на обоюдовыгодных условиях. ИМХО: Основным сдерживающим фактором является недостаток информации - где ближайшая площадка доступа провайдера. Пока ещё не вышли на нормальную конкуренцию по услугам связи. Подчас и не знаешь, к какому оператору идти - информация строго конфиденциальна.

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

Kass, я может неправильно что-то сказал? Дело не в Модбас, да и какая разница СКС, что Вам нужно передать ее средствами. У нее свои транспортные протоколы, свои режимы передачи данных.
SIM выразился вполне понятно и Модбас можно инкапсулировать в транспортный протокол и передать средствами СКС в нужное место, и не важно сколько там сотен километров. Для него это будет виртуальный COM-порт на сервере. У меня сложилось впечатление, что мы обсуждаем одно и тоже только разными словами перемешивая логические соединения, протоколы и физические интерфейсы. Разногласие только в том, что Вы считаете необходимо использовать возможности маршрутизаторов, я же считаю, что и мультиплексоры PDH справятся с этой задачей не хуже. Тем более что вышестоящая СКС работает с обоими. А разделение и перенаправление слотов в потоке могут и осуществляют кросс-коннекторы (DXC). Часто мы используем смешанное решение, когда роутер (Cisco 805, это просто, к примеру) подключается портом RS-232 к мультиплексору первичного доступа. Вызвано тем, что не получается использовать VoIP в силу определённых требований к стыку диспетчерской связи, а его надо в обязательном порядке иметь. А тема затрат на эти решения бестолковая, мы с Вами можем привести кучу примеров где выгодно или то или другое, или комбинировано. Все зависит от задачи которую надо решить и сложившихся условий.
По "бардаку" - различие типов интерфейсов, оборудования и т.д. появлялись не сразу. Совсем недавно основным оборудованием были аналоговые системы (ИКМ и т.п.). Модернизировать разом крупную сеть связи невозможно. Идут инвестиции конечно, но не так все быстро. Это не беспорядок, это нормальное развитие отрасли. В этом плане критику Вашу не принимаю. Тем более что и упомянутые Вами решения у нас существуют в полном объеме. Да и все крупные операторы нашего региона имеют свои площадки доступа в нашем узле связи. Это выгодно всем.
Что касается протоколов для АСУЗ, эта тема как про SCADA или выбор контроллеров. ИМХО, как эксплуатационника - единая платформа одного производителя для объекта или взаимосвязанных объектов. Это снижает затраты на ЗИП, обучение персонала и сокращает время устранения неисправностей. По стоимости решений - "внедрение автоматизированных систем управления способствует росту рыночной капитализации предприятия в части текущей рыночной стоимости собственного капитала". О функциональной эффективности от внедрения систем можно говорить также до бесконечности

Да просто предыдущий коллега выссказался, что они используют только Модбас и все. А если вы влезли в СКС, то там Модбас сам по себе не будет понят сетевым оборудованием, а значит использование IP не избежать. Причем я как бы хотел провести явную грань, между протоколами общей шины и сетевыми протоколами. ИМХО нельзя все в кучу свалить.


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

KASS - поздравляю Вас, и всех коллег на форуме, с днем Энергетика! Пусть в ваших домах будет всегда светло и тепло, а в ваших семьях- мир и покой. Желаю всем крепкого здоровья, благополучия, и удачи!

Большое спасибо! И вам тех же благ!