Всем привет. Решил я сравнить разные технологии автоматизации и столкнулся вот с каким вопросом:
Можно ли сеть БАКнет сделать децентрализованной (как LON ли KNX)? В многочисленной неспециальной
литературе встретил лишь прокламации на тему "Ставь бакнет потомучто он одобрен федерацией стоматологов" и накакой четкой модели сетевого обмена. В специальной литературе в явном виде ответа не нашел. Некоторые замечания что возможен обмен как типа точка-точка
так и мастер-слэв лишь еще больше путают следы. Как увзать .... скажем 20 бакнет устройств в одну работающую сеть с интенсивным обменом данными без хост-контроллера?

У данного протокола изначально было другое предназначение - объединение систем, а не устройств. Это протокол более высокого уровня (иерархически) чем ЛОН или КНХ. Можно сделать все, что угодно, НО большинство мнений (с кем я общался) сводится к следующему: БАКнет лучше подходит для интеграции разнородных систем в здании, для интеграции продуктов - ЛОН или КНХ.

Американцы в своих системах закладывают БАКнет и на полевом уровне, в Еврое и России больше тяготеют к использованию других протоколов тут или вообще без каких-либо протоколов.

BACNet, по сути своей, очень похож на С++, С#, Delphi. Я работал с реализацией Siemens SBT. Очень удобная штука для СТАНДАРТНЫХ объектов, которыми, по сути своей, являются почти ВСЕ объекты АВОК. Централизация примерно такая же, как у LON, но следует признать - LON для любителей НИЖНЕГО уровня (как Assembler). Если бы приходилось ВЫБИРАТЬ из протоколов, то я бы ОДНОЗНАЧНО выбрал бы BACNet, как наиболее ПРИСПОСОБЛЕННЫЙ ДЛЯ ИНЖЕНЕРОВ Надо просто прочитать РЕАЛИЗАЦИЮ протокола на выбранном оборудовании, т.к. реализации в полном объеме ( смотрю Инет) я просто не видел.

Модельная задача такая: 20 устройств разных производителей, передача сообщений происходит в рамках протоколов TCP/IP на различных физических средах. Меня интересует как настроить обмен данными между устройствами без центрального хост контроллера.

Мое представление о настройке сети следующее:
В каждом устройстве должна храниться таблица привязки устройств к их IP адресам (либо получать данную информацию от BBMD).
Каждое устройство конфигурируется таким образом, чтобы знать с какого устройства читать переменную.
Так вот какими программными средствами настраивается децентрализованная сеть?

Модельная задача - это хорошо, но не понятно. Даже LON не "катит" в модели, т.к. количество "тонкостей" зашкаливает.
1) Что за устройства? Попадают ли они под описание object?
2) Что значит "децентрализовано"?
3) Причем здесь IP- адреса? Объекты описываются их местом в сети. Остальное - средства протокола.

1. Контроллеры вентустановок, ИТП, руфтопов, холодильных машин. Устройства содержат стандартный диапазон BACnet объектов.
2. "Децентрализованно" подразумевает отсутствие контроллера основной функцией которого является обработка и передача переменных из одного устройства в другое. Система диспечерезации настроена толька на "измерение" переменных, но не производит никаких вычислений и передачи параметров из одного устройства в другое.
3. А адреса притом, что средства протокола как конкретная реализация подразумевают маршрутизацию сообщений. Для ЛОН этим занимается чип NEURON, но там уровень железа похож на немаршрутизируемый Ethernet --- все слушают всё. Каждое устройство для себя фильтрует лишнее.

Я полагаю что для бакнет/IP я полагаю тоже самое: Что-то должно направить пакет с датаграммой BACnet на конкретный узел(контроллер) в сети. И это что-то должно иметь таблицу соответствия IP адреса конкретному устройству, так как TCP/IP исключительно маршрутизируемый протокол. Если сеть децентрализованная, то такая таблица должна присутствовать в каждом устройстве. Вопрос в следующем: Какой инструмент (процесс или устройство) эту таблицу создает?

Я понял. Что касается диспута о технологиях - не та ветка. Простите, но прочитайте для начала описание протокола BACNet. После этого можно приступать к обсуждению. Иначе - чистый флуд.

Всем спасибо. Теперь многое стало понятней. Далее в деталях почитаю стандарт.

BACnet в Америке, в дополнение к "....Американцы в своих системах закладывают БАКнет и на полевом уровне, в Еврое и России больше тяготеют к использованию других протоколов тут или вообще без каких-либо протоколов...."

Думаю что про БАКнет на полевом уровне полезней всего будет эта статья: http://www.bacnet.ru/ru/bacfield/bacfield.htm

Статья очень интересная, но для полного понимания и достойного сравнения хотелось бы к ней спецификацию оборудования, схему, проект...

Мы для мастер-класса по бакнету пробывали конечно не 20 устройств, а 1 независимую СКАДу (Сайтект взяли) и несколько бакнет контроллеров от разных фирм + к ним еще присоединены были полевые девайсы. Все заработало 20 видов софта не потребовалось... одна скада подтянула все устройства в сети. Так что не ясно какую мысль г. Пасеков своим постом хотел выразить?

г.П, как вы его назвали, думаю хотел выразить следующее (смотрите внимательнее его пост):
существует потребность в специализированных программных продуктах производителей контроллеров БАКнет для связи этих контроллеров друг с другом (между собой), подчеркиваю, не со СКАДой, а сетевое взаимодействие друг с другом.


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

Это не вполне соответствует действительности.
Программное обеспечение определённого производителя позволяет запрограммировать контроллеры этого же производителя таким образом, чтобы они обменивались данными с любыми другими BACnet устройствами.

2 Дмитрий Казаков,

БАКнет - это протокол другого уровня, чем ЛОН или КНХ. Здесь нет универсального софта для объединения сетевых устройств "горизонтально" (или по крайней мере я про это ничего не слышал). Главное назначение данного протокола - объединить системы от разных производителей, а не объединять устройства. Есть специализированный софт от Симетрикса, который помогает настроить совместную работу в сети БАКнет устройств от разных производителей: анализатор пакетов - с его помощью можно видеть кто в сети общается с кем и тд. Но как говорят сами разработчики этого софта, он нужен в 1-ю очередь для настройки мультивендорных сетей.

По поводу - почему я дал ссылку на "Применение БАКнет на полевом уровне" - чтобы показать различия в построении БАКнет сетей в США и Европе.

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

Покажите мне практическую задачу, где у вас буедт 20 БАКнет контроллеров и ни одной СКАДы?

Читал Я Ваши высказывания, читал...

Попытался "перенести" на интересующий меня "простой" пример:

шлюз DIII-net <> BACnet (Daikin) и шлюз BACnet<>EIB (последний, кстати, пока неизвестен).

Правильно ли Я понял, что для их связи по BACnet, мне понадобится две программы от двух производителей, причем не бесплатные?

в данной ветке вы сами себя запутали термином "программное обеспечение/программный продукт"... что вы под этим понимаете? Плюс еще программное-системное...

Изначальный вопрос был такой:

Отвечаю (по своему опыту):

1) Про децентрализованные БАКнет системы я никогда не слышал, скорее всего, потому что этот протокол создавался как раз для обратной задачи.
2) Если это BACnet/IP, то о каких других физ.средах идет речь? Если есть другие физ.среды, то и протокол будет другой (BACnet/ARCnet, BACnet/PTP...). Если речь не про БАКнет вообще - а просто про TCP/IP, то этот пункт я снимаю.
3) Снова отмечу, что про такие решения на БАКнете я не знаю.

Ну как бы нет.
Если берём самый крайний случай, т.е. каждый из 20 производителей общается со всеми 19 остальными (что на мой взгляд довольно-таки нереалистично), то вполне достаточно 10 программ. Поскольку программируемые контроллеры могут (как правило) и читать из, и писать в другие устройства.
При желании можно обойтись и одним главным контроллером, который будет осуществлять весь обмен информацией (т.е. читать из одних устройств и писать в другие). Тогда программа нужна только одна. Разумеется, если этот контроллер встанет, то всё остановится.

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

Вообще-то создатели BACnetа и компании, производящие совместимые продукты, положили немало сил, чтобы убедить интеграторов, что полноценная система должна быть BACnet снизу-доверху. Даже термин специальный придумали: "native BACnet", чтоб отличать от тех систем, у который на уровнях automation и field используются другие протоколы, а BACnet только на уровне management.
Децентрализованные системы на BACnet вполне возможны. В том смысле, что для взаимного обмена информацией между контроллерами SCADA не нужна.

Про "Native" BACnet можно прочитать тут: http://www.autobuilding.ru/arc/detail.php?ID=1074
После подготовки этой статьи я много общался с американцами - все-таки четких границ этого термина нет и сейчас его используют все реже, т.к. появляется все больше БАКнет-совместимых девайсов, поэтому нет разницы единственный ли это протокол для данного производителя (типа ALC, Delta Controls) или шлюз используется...


Я не говорил, что это не возможно (даже Д.Билан поет про то что невозможное-возможно... ). Большинство контроллеров программируемые, все их можно настроить на взаимодействие друг с другом и последующей работы без участия СКАДы (гипотетически), просто (практически) я такой реализацией не сталкивался... Если у кого-то был реальный опыт - поделитесь, будет интересно.

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


Опыт был, контроллеры Alerton общались друг с другом безо всякой СКАДы.

Очень интересно... расскажите пожалуйста. Насколько мне известно, несколько лет назад продажами Алертона занималась компания Науцилус, но со слов ее представителя - реальных объектов, укомплектованных данным оборудованием, так и не было. Алертон была куплена Хоневелл и после этого выход компании на российский рынок прикрыли.

Про российские реалии ничего не скажу (мы -- ближнее зарубежье). Alerton начали использовать лет восемь назад, вполне благополучно. Интеграцией с другими производителями практически не занимались, да их и нет почти на местном рынке. Продажа Хоневеллу ничего не изменила (пока во всяком случае).
Про децентрализацию. В BACnet'e все устройства подразделяются на masters и slaves. Masters могут инициировать обмен данными с другими устройствами. Все контроллеры Алертон -- masters, однако в самом начале их нельзя было программировать для децентраллизованного обмена, весь обмен информацией производился т.н. "глобальным контроллером", который заодно служил местом хранения расписаний, тревог, трендлогов и роутером MS/TP--Ethernet. Через несколько лет Alerton активизировал-таки функцию обмена информацией с другими устройствами во всех своих контроллерах. Так что их систему можно назвать децентрализованной.

Точнее наверное сказать: сервер-клиент... по крайней мере так позициорует бАКнет коммуникацию американцы...


Расскажите пожалуйста (если не тайна): где, какие объекты делали на Алертоне, какие задачи решали - реально интересно, т.к. в России эта марка сильно не пошла (пока).

может у кого есть описание технологии BACNET

так вот здесь же всё есть:
http://www.bacnet.org/Tutorial/index.html

или Вы о чём?

Желающие могли сами разобраться как работает Бакнет с 3 по 6 марта в московском офисе компании Delta Controls. В рамках курса рассмотрены вопросы системной архитектуры, конфигурирования объектов контроллеров АСУ здания на базе BACnet, программирования, настройки системы в ORCAview.
Говоря проще: в сети БАКнет на 4 стендах с подключенными контроллерами (в том числе полевого уровня) и 4 станциями (PC) с установленным ПО ORCAview можно было "пощупать" основные элементы Бакнета.
Слушатели (в том числе и я) остались довольны. Для интересующихся могу дать более подробную информацию конфиденциально ( иначе господа подумают, что это реклама).

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

Ответ на второй вопрос следует из ответа на первый - никакого хост контроллера не надо.

Надеюсь понятно объяснил.

Я уже писал об этом, что для разных контроллеров(производителей) нужны свои программные средства для программирования, в том числе для настройки обмена информацией об объектах. "Некоторым" правда очень "не понравилось".
Надеюсь, что Wildrover еще раз пояснил очевидное...