Господа и коллеги!
Опять тема новая в этом форуме, но нужная. Скептике могут проверить в поиске....
Заранее приношу прощение, если что-то пропустил из важного.... Возможно только 10 вариантов. Прошу также модераторов не удалять сообщения, которые им покажутся рекламными.
Аргументация в опросе по SCADA....
Начинающим всегда трудно сделать выбор, поэтому их интересуют следующие вопросы:
1. Легкость и простота освоения.
2. Наличие основных функций.
3. Приемлемая цена.
4. И другое...
У меня есть надежда, что Вы не только дадите свой ответ по опросу, но и возможно обоснуете его и ответите на вопросы. Уверен, что и Вы когда-то только начинали...
Не знаю позволит ли механизм опроса давать ответы несколько раз. Скорее всего нет. Поэтому просьба первый вариант ответа пусть будет наиболее часто используемым в вашей практике.
Цели опроса:
1. Постараться получить картину востребованности протоколов и технологий на нашем рынке автоматизации зданий.
2. Помочь с выбором новичкам.
3. Ну и другие....
Заранее благодарен всем за участие, знаю, как трудно принимают участие в опросах специалисты.
Понимаю, что много специалистов не смогут или не захотят ответить. Конечно, данные нельзя будет считать совершенно объективно отражающими наш рынок, но надо начинать...
Опрос в этой ветке вполне закономерен. Не буду повторяться почему....
На мой взгляд, с точки зрения автоматизации и диспетчеризации инжереных систем существует 2 принципиальных варианта:
1. Сквозная автоматизация (уровни локальной автоматики, диспетчерский уровень, средства организации сети передачи данных) с использованием полной линейки оборудования одного производителя (например Johnson Controls, Honeywell, ...).
2. Диспетчеризация инжереных систем, локальная автоматика которых построена на различном оборудовании.
В первом случае все достаточно четко - система строится в соответствии с принципами построения, позволяющими наиболее эффективно использовать железо, софт и протоколы передачи данных производителя. Здесь практически всегда системным интегратором выступает всего одна компания, автоматизирующая все снизу доверху.
Второй случай - это сборная солянка. Вентиляционщики ставят свое оборудование, электрики -свое, сантехники - свое, и т.д. И когда заказчик начинает говорить о диспетчеризации всего этого - вот тут-то цирк и начинается.
Проводится анализ возможности привязки к каждой из систем (хорошо, если железо поддерживает стандартные протоколы), принимается решение по линиям передачи данных (прокладывать собственные исключительно для диспетчеризации или использовать существующие). Почти всегда возникает потребность установки дополнительных модулей ввода/вывода.
Если локальная автоматика бюджетная (читай - отечественная) - это почти всегда RS-485 (Modbus какой-нибудь). Если уровень локальной автоматики повыше - почти всегда Lon.
Как передавать данные?
Можно тянуть собственные сети.
Можно интегрировать в существующую Ethernet здания.
Все зависит от проекта и используемого оборудования.
Поэтому я не голосовал - я не знаю, какой протокол я использую для диспетчеризации - всегда есть 2-3 только из перечисленных.
Кроме того, список протоколов не совсем корректен - здесь и аппаратные интерфейсы (RS-232, 485, Ethernet), и программные протоколы.
И еще (перекликаясь с темой Scada): если речь идет не о протоколах передачи данных, а о ТЕХНОЛОГИИ диспетчеризации, то для сборной солянки (вариант 2), ничего лучше OPC для объединения разных систем нет. SCADA системе без разницы, как и откуда OPC-сервер берет данные, соответственно программисту системы диспетчеризации без разницы по каким протоколам идет обмен данными.
Sagan по-моему можно добавить третий вариант, когда сборная солянка, но вся автоматика разрабатывается по требованиям системного интегратора на едином протоколе.
Например, при реализации всего на LonWorks результат получается вполне приемлемым.
Vasiliy,
Полностью с Вами согласен. LON - оптимальный вариант, и если удается выдать задание разработчикам локальных систем, все вопросы снимаются.
Но у нас периодически возникают ситуации, когда диспетчеризация "выплывает" уже после того, как заключены договоры и выполняются проекты по основным системам.
Поэтому требования по интеграции мы иногда просто не имеем возможности подсунуть. Более того, в подобных случаях, встречаемся со своеобразным "пассивным сопротивлением" со стороны тех, кому выпало счастье делать локальную автоматику - люди четко определяют свои границы ответственности, а все остальное (всякая там диспетчеризация) их не волнует.
Остается только влиять через Заказчика...
А вот мне интересно, здесь 25% ответили, что для диспетчеризации Ethernet используют. А контроллеры у них что, сразу TCP пакеты выдают. Или, все-таки, через преобразователь? А если, через маршрутизатор, то в корне не верно говорить, что для диспетчеризации используется Ethernet, это равносильно тому, как сказать, что для диспетчеризации я использую PCI, мотивируя тем, что у меня LON адаптер п PCI шину вставляется.
Цитата(Sagan @ Aug 30 2006, 08:00 )
Но у нас периодически возникают ситуации, когда диспетчеризация "выплывает" уже после того, как заключены договоры и выполняются проекты по основным системам.
Поэтому требования по интеграции мы иногда просто не имеем возможности подсунуть. Более того, в подобных случаях, встречаемся со своеобразным "пассивным сопротивлением" со стороны тех, кому выпало счастье делать локальную автоматику - люди четко определяют свои границы ответственности, а все остальное (всякая там диспетчеризация) их не волнует.
Остается только влиять через Заказчика...
Ну так я же не спорю, сам неоднократно разбирался с проектами нарисованными "бабушками" на таком железе, что там "сухого" контакта не найдешь, не говоря уже о LON
Один раз мне на вопрос относительно диспетчеризации котельной Viessmann сказали следующее: "(возмущенно) У нас нет никакого LonWorks!!! У нас ЛОН-шина"

Оказалось, что все там хорошо у Viessmann с LonWorks.
А женщина-электрик при моей попытке договорится с ней о том, чтобы она в задании заводу на ГРЩ, написала пункт о предусмотрении возможности установки трансформаторов тока для WattNode, выдала такую фразу:"Вы ко мне тут со своими интерфАйсами не приставайте"
Цитата(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 контроллеры, очень удобно, не тянуть километры витой пары а воспользоваться свобдным портом в ближайшем хабе.
Хорошо, когда хабов везде понатыкано

а то еще и Ethernet тянуть надо, да плюс еще ограничения на кабельное расстояние между устройствами...
Поднимаю тему.
Варианты протоколов диспетчеризации чиллера + системы фанкойлов:
- LON
- TREND
Может ли кто-нибудь объяснить, чем ПРИНЦИПИАЛЬНО отличаются эти два варианта? Заранее благодарен.
Уточняю интересующие моменты по протоколам диспетчеризации:
- количество и сущность включённых в комплект функций
- в чём превосходство LonWorks над TREND
TREND - проприетарный протокол фирмы TREND. У него такие же преимущества (и недостатки), как и у других проприетарных протоколов.
Да с бакнетом негусто....
soliton-ua
26.1.2010, 14:19
Странно, все-таки, что для опроса смешаны логические и физические протоколы передачи данных.
Видимо, подразумевается (Ethernet -> Прочие по Ethernet), то-же с RS232, 485.
Для просмотра полной версии этой страницы, пожалуйста,
пройдите по ссылке.