Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Протоколы автоматизации и диспетчеризации
Диалог специалистов АВОК > ОБЩИЙ ФОРУМ > Автоматизация систем > LonWorks
Pasekov
Господа и коллеги!
Опять тема новая в этом форуме, но нужная. Скептике могут проверить в поиске....
Заранее приношу прощение, если что-то пропустил из важного.... Возможно только 10 вариантов. Прошу также модераторов не удалять сообщения, которые им покажутся рекламными.
Аргументация в опросе по SCADA....
Начинающим всегда трудно сделать выбор, поэтому их интересуют следующие вопросы:
1. Легкость и простота освоения.
2. Наличие основных функций.
3. Приемлемая цена.
4. И другое...

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

Цели опроса:
1. Постараться получить картину востребованности протоколов и технологий на нашем рынке автоматизации зданий.
2. Помочь с выбором новичкам.
3. Ну и другие....

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

Опрос в этой ветке вполне закономерен. Не буду повторяться почему....
Sagan
На мой взгляд, с точки зрения автоматизации и диспетчеризации инжереных систем существует 2 принципиальных варианта:

1. Сквозная автоматизация (уровни локальной автоматики, диспетчерский уровень, средства организации сети передачи данных) с использованием полной линейки оборудования одного производителя (например Johnson Controls, Honeywell, ...).

2. Диспетчеризация инжереных систем, локальная автоматика которых построена на различном оборудовании.

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

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

Если локальная автоматика бюджетная (читай - отечественная) - это почти всегда RS-485 (Modbus какой-нибудь). Если уровень локальной автоматики повыше - почти всегда Lon.
Как передавать данные?
Можно тянуть собственные сети.
Можно интегрировать в существующую Ethernet здания.

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

Поэтому я не голосовал - я не знаю, какой протокол я использую для диспетчеризации - всегда есть 2-3 только из перечисленных.

Кроме того, список протоколов не совсем корректен - здесь и аппаратные интерфейсы (RS-232, 485, Ethernet), и программные протоколы.

И еще (перекликаясь с темой Scada): если речь идет не о протоколах передачи данных, а о ТЕХНОЛОГИИ диспетчеризации, то для сборной солянки (вариант 2), ничего лучше OPC для объединения разных систем нет. SCADA системе без разницы, как и откуда OPC-сервер берет данные, соответственно программисту системы диспетчеризации без разницы по каким протоколам идет обмен данными.
Vasiliy
Sagan по-моему можно добавить третий вариант, когда сборная солянка, но вся автоматика разрабатывается по требованиям системного интегратора на едином протоколе.
Например, при реализации всего на LonWorks результат получается вполне приемлемым. wink.gif
Sagan
Vasiliy,

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

Но у нас периодически возникают ситуации, когда диспетчеризация "выплывает" уже после того, как заключены договоры и выполняются проекты по основным системам.
Поэтому требования по интеграции мы иногда просто не имеем возможности подсунуть. Более того, в подобных случаях, встречаемся со своеобразным "пассивным сопротивлением" со стороны тех, кому выпало счастье делать локальную автоматику - люди четко определяют свои границы ответственности, а все остальное (всякая там диспетчеризация) их не волнует.
Остается только влиять через Заказчика...
N@Z
А вот мне интересно, здесь 25% ответили, что для диспетчеризации Ethernet используют. А контроллеры у них что, сразу TCP пакеты выдают. Или, все-таки, через преобразователь? А если, через маршрутизатор, то в корне не верно говорить, что для диспетчеризации используется Ethernet, это равносильно тому, как сказать, что для диспетчеризации я использую PCI, мотивируя тем, что у меня LON адаптер п PCI шину вставляется.
Vasiliy
Цитата(Sagan @ Aug 30 2006, 08:00 )
Но у нас периодически возникают ситуации, когда диспетчеризация "выплывает" уже после того, как заключены договоры и выполняются проекты по основным системам.
Поэтому требования по интеграции мы иногда просто не имеем возможности подсунуть. Более того, в подобных случаях, встречаемся со своеобразным "пассивным сопротивлением" со стороны тех, кому выпало счастье делать локальную автоматику - люди четко определяют свои границы ответственности, а все остальное (всякая там диспетчеризация) их не волнует.
Остается только влиять через Заказчика...

Ну так я же не спорю, сам неоднократно разбирался с проектами нарисованными "бабушками" на таком железе, что там "сухого" контакта не найдешь, не говоря уже о LON laugh.gif
Один раз мне на вопрос относительно диспетчеризации котельной Viessmann сказали следующее: "(возмущенно) У нас нет никакого LonWorks!!! У нас ЛОН-шина" laugh.gif Оказалось, что все там хорошо у Viessmann с LonWorks.
А женщина-электрик при моей попытке договорится с ней о том, чтобы она в задании заводу на ГРЩ, написала пункт о предусмотрении возможности установки трансформаторов тока для WattNode, выдала такую фразу:"Вы ко мне тут со своими интерфАйсами не приставайте" laugh.gif
SIM
Цитата(N@Z @ Aug 30 2006, 09:29 )
А вот мне интересно, здесь 25% ответили, что для диспетчеризации Ethernet используют. А контроллеры у них что, сразу TCP пакеты выдают. Или, все-таки, через преобразователь? А если, через маршрутизатор, то в корне не верно говорить, что для диспетчеризации используется Ethernet, это равносильно тому, как сказать, что для диспетчеризации я использую PCI, мотивируя тем, что у меня LON адаптер п PCI шину вставляется.

Именно так! контроллеры сразу выдают Ethernet на OPC сервер
http://www.ipc2u.ru/catalog/N/N7/14739.html

Раньше использовали RS485, постепенно переходили на адаптеры RS485-Ethernet и теперь полностью на Ethernet контроллеры, очень удобно, не тянуть километры витой пары а воспользоваться свобдным портом в ближайшем хабе.
Lёxus
Хорошо, когда хабов везде понатыкано smile.gif а то еще и Ethernet тянуть надо, да плюс еще ограничения на кабельное расстояние между устройствами...
Barns
Поднимаю тему.
Варианты протоколов диспетчеризации чиллера + системы фанкойлов:
- LON
- TREND

Может ли кто-нибудь объяснить, чем ПРИНЦИПИАЛЬНО отличаются эти два варианта? Заранее благодарен.
Barns
Уточняю интересующие моменты по протоколам диспетчеризации:
- количество и сущность включённых в комплект функций
- в чём превосходство LonWorks над TREND
Abysmo
TREND - проприетарный протокол фирмы TREND. У него такие же преимущества (и недостатки), как и у других проприетарных протоколов.
GYUR22
Да с бакнетом негусто....
soliton-ua
Странно, все-таки, что для опроса смешаны логические и физические протоколы передачи данных.
Видимо, подразумевается (Ethernet -> Прочие по Ethernet), то-же с RS232, 485.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Форум IP.Board © 2001-2025 IPS, Inc.