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

[Гость_ggg__ggg_*]

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

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

[Гость_ggg__ggg_*]

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

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

[GYUR22]

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

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

[Sun technik]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[s60]

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

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


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

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

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

[Kass]

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

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

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

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

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

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

[Abysmo]

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

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

[GYUR22]

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

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

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

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

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

[Abysmo]

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

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

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

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

[GYUR22]

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

[Pasekov]

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

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

Сообщение отредактировал Pasekov - 13.10.2008, 21:16

[Pasekov]

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

Приветствую дорогой 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. Возможные методы адресации: уникальный адресат, групповой адрес, широковещательная адресация.

[Sun technik]

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

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

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

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

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

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

Я не делал объектов с десятками панелек (имхо не очень это правильно).

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

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

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

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

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

[Pasekov]

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

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

[AlexG]

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

[Pasekov]

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

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

Сообщение отредактировал Pasekov - 17.12.2008, 13:04

[AlexG]

Гранд мерси!
Как лучше? Прямо в форуме вопросы или типа таблички в почту?

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

[Kass]

4. Для передачи нужна сеть и протокол? У Вас она одна и он один для всех задач?

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

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

Ну и наши уже 15 пунктов для обсуждения:
1. Желательно поддерживать свободную топологию, а не только шинную.

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

2. Быть не капризным к физ.среде При использование специального(стандартного для протокола) кабеля быть устойчивым к электромагнитным помехам.

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

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

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

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

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

5. Наличие оборудования и ПО для IP-туннелирования.

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

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

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

7. Экономичность на монтаже сети.

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

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

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

[Kass]

9. Не высокие требования к квалификации специалистов при разработке, пуско-наладке и эксплуатации системы.

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

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

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

11. Возможности по сегментированию сети. Наличие возможностей протокола и оборудования для маршрутизации сетевого трафика.
12. Развитые возможности по реализации различных типов информационного обмена: запрос/ответ, доставка с подтверждением, многократный повтор.
13. Возможности защиты коммуникации и программ устройств средствами протокола.
14. Возможности протокола по присвоению сообщениям различных приоритетов.
15. Возможные методы адресации: уникальный адресат, групповой адрес, широковещательная адресация.

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

[KDVectra]

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

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

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

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

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

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

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

Точно, вопрос только в том, что для каждого устройства нужен свой порт Ethrnet, свой фрагмент СКС, да и стоимость имплементации Ethrnet и стека протоколов IP пока высоковата. Т.о. совокупная стоимость владения будет неминуемо выше.

[Kass]

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

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

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

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

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

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

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

[SIM]

1. Modbus

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

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

[Kass]

Использую только Modbus, очень прост в реализации. ... Недостатки - ограниченное адресное пространство устройсв на одной шине, 255 и все...

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

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

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

[CHANt]

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

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

[AlexG]

Использую только Modbus, очень прост в реализации. Можно самому запрограммировать интерфейс и в контроллере, микроконтроллере и на сервере, шлем вручную командой ToCom набор байт, всё ясно и прозрачно. Смотрится любой терминалкой, особенно Modbus ASCI

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

Задержка существенно больше милисекунд (это не Ethernet) сотни милисекунд минимум.

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

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

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

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

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

[Andy79]

Используем 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.

[Kass]

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

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

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

Сообщение отредактировал Kass - 19.12.2008, 14:53

[Pasekov]

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

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

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

 Протокол_Modbus.zip ( 5,04 килобайт ) Кол-во скачиваний: 17

 

[CHANt]

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

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

Масштаб? Да конечно. Мое предприятие было создано и занимается эксплуатацией систем связи, телемеханики и информационных технологий для энергосистемы области. Сотни объектов, 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) и почти всегда недогружена. Договориться можно и на обоюдовыгодных условиях. ИМХО: Основным сдерживающим фактором является недостаток информации - где ближайшая площадка доступа провайдера. Пока ещё не вышли на нормальную конкуренцию по услугам связи. Подчас и не знаешь, к какому оператору идти - информация строго конфиденциальна.

Сообщение отредактировал CHANt - 19.12.2008, 21:35