Из этих примеров вытекает ответ на вопрос :

Зачем нужен единый протокол назовем к примеру Modbus Rus.
Чтобы свести к минимуму количество нестандартных протоколов.

Вот только вопрос был риторическим и вообще о другом.

Чтобы свести к минимуму количество нестандартных протоколов для начала надо прекратить их плодить.

Чтобы прекратить плодить, нужен единый протокол.

Вот это меня в отечественном народе потрясает больше всего. Зачем делать модбас рус если есть модбас просто?

Если почитать "описание реализации Модбас" и "описание релизация передачи данных через радиомодемы" - можно заметить, что они несовместимы по временным характеристикам.
Второе небольшое неудобство раскладка байтов в классическом Модбас, неудобно обрабатывать 3 (четырех) байтовые значения.

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

Например какие проблемы ?
А если есть варианты решения проблем Модбаса помогите, человек ищет :
Тема: RS-485 и Ethernet. Прозрачная замена кабельной линии.

Для Pasekov и Akirra. Дайте, пожалуйста пароли для "терминов" и "содержания". Очень хочется быть в теме.

Хе Хе
уже придуман общий протокол для всего BACnet называется (шютка )
На самом деле куча разных протоколов дает хлеб создателям OPC и Gateway так что ж вы его хотите отнять ?

Ничего не хотят отнять, хотят опять развести песню про "особый Русский путь". Потратить миллионы денег, набить кучу шишек и выпустить в конце концов устаревший к моменту выхода протокол.
Догонять, товарищи, легче с середины дистанции а не от старта.

Даже если кто то опубликует свой протокол как Modbus Rus, то остальные производители объявят ему войну.
Вся беда в нашем менталитете. Мы зачастую воспринимаем соседей по бизнесу как конкурентов, как врагов, а не компаньонов и друзей.
Поэтому поливание грязью вполне заменяют партнерские отношения.
Поливание грязью всего отечественного теми, кто что то лепит на зарубежном приводит к тому, что и все оборудование и проект и автоматику заказывают зарубежом. Зачем заказывать у местных кустарей, если они сами говорят, что в России ничего нормального не сделать. Поэтому в последнее время множество объектов переделываем за югославами, итальянцами и т.п.

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

+120 Абсолютно согласен. /с возвращением г.Kass/.
Только, если копнуть историю, можно вспомнить, что производители принтеров ставили различные разъемы продвигая свою продукцию.
И только "центроникс" положил конец безпределу.

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

Тема весьма интересная. Но, как и все hi-tech темы и направления развивается настолько стремительно, что к выходу книги поизойдет смена поколения оборудования/протоколов/решений.
Например, мы помогали партнерам в подготовке книги по вентиляции и кондиционированию воздуха в части автоматизации и диспетчеризации. Прошло 5 лет после выхода книги, базовые технологии сохранились, но обновилась линейка контроллеров, ПО системы диспетчерзации, вместо DDE основные производители используют OPC сервера.

Я задавал вопрос инженерам (из компании - производителя коммуникационного оборудования для промышленных сетей Ethernet, Тайвань) о цикле производства - от идеи до готового продукта. Ответ - не более 9 месяцев, иначе не будет перспектив для продаж. За год интенсивно продвинулись направления по PoE, IP видеонаблюдению, WiMax.

Производители контроллеров и систем для зданий, конечно-же более инерционны. Линейка продукции обновляется каждые в 3-5 лет. Но все-таки решения по удаленной диспетчеризации связаны больше с коммуникационными технологиями и решениями. Все таки - интерес в том, чтобы книга стала коммерческим продуктом, или информационным ресурсом? Если второе - то, наверно, лучше, чтобы это был обновляемый интернет-ресурс.

Относительно проблем информационной безопасности при удаленной диспетчеризации - это общая проблема информационных систем и решается теми-же средствами.
Один из плюсов таких систем - удаленное рабочее место для специалистов, чья квалификация в части СУЗ выше, чем квалификация персонала службы эксплуатации здания.
В Москве наш клиент успешно эксплуатирует три офисных здания, подключенные через телефонные модемы с относительно старенькой системой BMS.
Наши колллеги из Германии делились опытом проектов единой системы по диспетчеризации десятков зданий в разных городах. И никого не пугает подключение к сети internet, как наши "продвинутые" службы Заказчиков. Некоторые компании, удаленно сервисующие здания, получая только проценты от экономии энергоносителей, чувствуют себя весьма неплохо. Наши партнеры предоставляют доступ к серверам систем диспетчеризации городских теплопунктов и котельных как услугу для городских коммунальных служб.

Наверно утомил народ своим флером , но тема действительно перспективная.
Владимиру - удачи.

Значит книгу надо писать быстрее. Контроллеры сменятся, а идеология построения сетей останется, общий подход. Да и сами стандартные протоколы так быстро не меняются.



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


Полностью согласен.


Мне кажется, это лучший пост в теме. За пожелания - СПАСИБО!

Я вот отвечу. Не сочкану.

По поводу отчества (отечественные контроллеры, датчики, исп.мех-мы и т.д и т.п.) - хочу сказать, что только с внедрением (обязательным) систем диспетчеризации, использование НАШИХ контроллеров стало более безопасным.
По опыту - помню (никогда не забуду) как дежурили на одном ЦТП года 3 назад при наладке АСУ, 72 часа испытаний. Помню, как до этого "посадили" по давлению строящийся дом - и всю медь разорвало (на улице было -20 чтоли) в 10 этажном доме. Это проектировщики составили винегрет: Минитерм (лично подбирал параметры ПИД-регулирования), ECL Danfoss, частотники Danfoss, а более не помню, но много чего было.
К чему я - ранее ставили мы эти ECL Danfoss, настраивали и забывали - ну что может там сломаться? А поставишь наш ОВЕН - и душенька болит, неспокойно... Случалось то с нашей техникой разное и самое неожижанное. А контроля на месте не было. Поэтому НАШИ ставили редко, чаще буржуйные.
Но! Рынок и так нужно расширять - сколько объектов ждут своих героев, а тут еще и кризис - как снизить цену решения?

Ответ ВСЁ НАШЕ + диспетчеризация.

Поставил наши контроллеры, датчики, исп. механизмы - вывел в СКАДУ к главному инженеру - и эксплуатируй. Запал клапан - дом не "встанет" - аларм диспетчеру. Что-нибудь случилось (что с буржуйными не случается) - всё диспетчеру Аларм.

И вот пойдет быстрее процесс совершенствования Наших продуктов. Сломалось - вот архив скады - вот смотри, производитель, вот твой насос вышел из строя - вот, штаный был режим.

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

P.S. В Кузбассе не до разносолов.

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

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

2 CHANt:
Гм... Молодой человек, если честно, то я не понял пассаж про киповцев, селедку и наставление на путь истинный . Это относитя ко мне лично? В вашем выпаде нет ни строчки по теме. Может не моняли меня? Почитайте еще раз - я писал о том, что 3 года назад (точнее- 5 лет) отложился у меняф в сознании факт, что от нашего оборудования - только головная боль, проблемы и ор заказчика.
Тогда я не принимал решения в подборе оборудования, а когда стал сам проектировать АСУ - то старался обходить НАШЕ сторной. И только теперь (с массовым внедрением Дистанционного контроля, визуализации и диспетчеризации инженерных систем здания) решение об установке на тот или иной объет нашего оборудования кажется мне менее сомнительным.
Если вас так беспокоят пьяные КИПовцы - заведите ветку - "влияние пьяных киповцев на устойчивость АСУ ТП".

Я понял Вас, и не согласен с Вашим мнением. Считаю, что диспетчеризация не является панацеей от всех бед. Длительная и успешная работа систем автоматики зависит как от проектных решений, так и последующего текущего обслуживания, своевременных ремонтов, наличия у эксплуатанта соответствующих квалифицированных специалистов. Не мешало бы, чтобы горе топ-менеджеры и ресурсы выделяли для проведения ТОРО... В противном случае, через короткий промежуток времени, все превращается в груду хлама, и как Вы выражаетесь в "ор заказчика". В последнее время достаточно много предприятий разработчиков, исходя из конкретных условий, стараются взять на сопровождение свои системы, обеспечивая таким образом нормальные условия эксплуатации.

Не надо додумывать то, чего не было сказано. А раз избрали назидательный тон, то просветите дилетанта, к примеру, как Вы разрабатываете организационное обеспечение при проектировании АСУ, что включаете, на что обращаете внимание в документации в большей степени. Если Вас не затруднит.

Конечно, панацеи нет. На конкретных примерах это показать нетрудно. Но в книге и не предполагалось давать такой однозначной оценки.
Для нормальной эксплуатации могут применяться различные схемы. Если мы говорим об удаленной диспетчеризации, то она лишь способ. Не более. И в каждом конкретном проекте не всегда такой выбор лучший.

Вот и меня это интересует, чтобы потом ВСЕМ рассказать. Причем собрать разные точки зрения. Лучше с примерами. Тогда читатель сам сможет разобраться.

ещё одна жаркая тема ни о чём для желающих попи...еть ни о чём! Ну и как ребята, хоть 1 предложение своей "книги" написали???? Тема - явный кандидат в мусорку...
Давайте ещё создадим тему - "удачные конструкции вечного двигателя 1-го рода и рассуждения о нём" Буэ!!!

Согласен! Написать одно предложение в книгу, сложнее указания отправить тему в мусорку.

Доброе время суток!
ПРошу помочь!
Необходимо для обслуживания Подробное техническое описание
программы диспетчеризации - Excel Building Supervisor (Honeywell)
Прошу рассказать про возможные заморочки

СПАСИБО

И тема заглохла... где книга то? Смените название на: "как объяснить заказчику необходимость диспечеризации", будет иметь успех. а выкидывать на мусорку это не дело. Зак всегда сам разбереться хочет он наше оборудование или импортное, такой протокол или эдакий, а книги рассказывающий в картинках что это и чем грозит нет, поэтому и выбирают самое дешевое, а потом и урезают.. и в принципе не важно будет эта книга современной или нет, если она будет понятной обычному человеку без специального образования. Самым лучшим вариантом будет книга написанная вместе с производителем(ями) оборудования. (хотя бы тотже евроклимат).

Спасибо за пост.
1. Так тоже бывает.
2. Так авторов даже не набралось. Что-то никто не захотел бесплатно писать, а возможные спонсоры тоже активность не проявили. Но время не прошло даром (см. ниже).
3. Интересный поворот, но скорее всего правильный. Вот второй день размышляю над вашей этой мыслью.
4. Вот. Надо писать именно так. Согласен. Из трех моих рассылок по автоматизации зданий самой большой популярностью пользуется «Автоматизация зданий для Дилетантов». В короткой аннотации к ней говорится о возможности простым языком и без рекламы рассказывать об автоматизации зданий.
С 11 февраля прошлого года вышло 23 выпуска (хотя и был большой вынужденный перерыв). Из этих выпусков требуемую книгу, конечно, не составишь, но я получил опыт, который мало у кого на сегодня имеется. Кстати, и других авторов привлекал.
5. Выскажу имхо. Пока из китов (Siemens, Honeywell, JCI и Schneider Electric) никто не написал на русском языке ничего подобного. Вопрос:"Почему?" Ответ может выйти не совсем политкорректным. Хотя мысль привлечь именно производителей, а не крупных интеграторов тоже весьма интересна и смысла не лишена.
Но на этом форуме специалисты-интеграторы бывают, а вот из производителей почти никого и нет.

Я создал тему с запросом об открытии WIKI по автоматизации в рамках данного сайта. ИМХО это имеет много преимуществ перед бумажной книгой. Перечислю причины, которые первым делом приходят на ум:

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

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

Если на создание WIKI на этом сайте откажут, то можно создать отдельный ресурс. При отсутствии спонсора можно за бесплатно создать ресурс с доменным именем второго уровня.

А кому этот запрос был адресован?
Если просто тема, то скорее всего темой и останется. Как, например, с этой книгой.
Идея ваша не плоха, хорошо, если поддержат.
Но книга в бумажном виде все равно нужна. Просто, начав с WIKI, потом можно будет отредактировав материал сделать книгу.
Я за!!!

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

Как-то не очень хочется подводить отрицательный итог началу этой темы. Полагаю, что и так многим все понятно.
Поэтому попробуем с "другой стороны зайти".
Что такое книга? С одной стороны - это набор хорошего материала, структурированного и обобщенного одной темой. С другой - работа команды и некий бизнес процесс. Эта вторая сторона пока явно не работает.
Но тема ясна - АСУЗ и смежные вопросы, как их не называй. Актуальность только растет, причем в разных кругах.
Может стоит поискать нормальные статьи и привлечь этот материал и их авторов в книгу?
Задача не очень простая, но для всего коллектива форума подъемная.
При нахождении любой стоящей статьи требуется просто сообщить о ней или прислать ссылку и т.п.
Глядишь и начнет собираться материал, а уж обработать я смогу.

Задача конечно хорошая, но Вы сразу отвергли IP и GSM каналы, хотя сейчас при их помощи можно мониторить что угодно в любой точке где есть связь.
Здесь надо начать с прикладной теории управления: объекты, субьекты управления, способ управления, каналы связи (управления), виды обратных связей, уровни управления, иерархические структуры, способы отображения информации, методы повышения точности, устойчивости и т.п.
После этого подводить элементную базу, типовые задачи и типовые решения.
Контроль банкомата, управление насосами и счетчик на конвейере это достаточно разные системы, но объединены одной теорией, а значит возможна их интеграция.

Уважаемый Palsan!
1. С чего Вы взяли, что IP и GSM отвергнуты?
2. А может с прикладной задачи? Учебники АСУ есть, но не по зданиям и сооружениям.
3. Такая схема для производителя хороша, а для пользователей? Писать, например, что ОВЕН подходит для всего?
4. Все так, но интеграция в здание обусловлена не только единой теорией. В АСУЗ скорее надо несколько сместить акцент подачи материала.

Давайте WIKI создадим. Кто это умеет делать? А дальше все, кто хочет, будут там писать по возможности. Это пока самое реальное.

Не вопрос. Wiki сделать можно. Я и сам немного разберусь.
Проблема в другом. Как отсюда перекинуть ресурсы готовых писать на Wiki? Как им сообщить об этом?
Не реально писать всем в почту. А общее объявление на форуме будет воспринято как реклама другого ресурса со всеми вытекающими неприятностями....

Первые люди придут туда, а потом по сарафанному радио и гуглю
Тем более, не собирается же Вики становиться конкурентом.

Где я написал, что Вики может стать конкурентом? Я-то считаю наоборот, но пардон, не все так считают.
Даже не намекаю, кто может так "подумать"...
Сарафанное радио и гугль - это здорово, вот только непонятно как "первые люди придут туда"?

Через личку можно пригласить, кто отзовется тут.

такой вопрос, а нельзя как-то прям на форуме образовать WIKIingenering?
совместить движки или интерфейсы в одном сайте авока, а не делать второй
не разбираюсь в этом, просто спрашиваю

и как в этот справочник будут заносить данные, один записал, а написал какой-нибудь бред, второй тут же поправляет, затем третий, потом опять первый все возвращает?
надо бы как-то тогда обсужденные здесь вопросы подытоживать, делать сводку - потом выкладывать,
с годами справочник вырастет,

если я с другой оперой влез, то извиняюсь, не прочитал тему полностью


если все же объединить форум с вики никак,
то у темы уже много тысяч просмотров, из них несколько тысяч человек и будут этими первыми

да, это наверно даже лучше, чем просто Вики.

Всем здрасти! Авторы, так держать!
Очень полезное дело вы задумали! Думаю что не только я буду благодарен, но и тысячи тысяч людей!
Интересует как обстоят дела с ресурсом? или с книгой? ссылки какие-нибудь есть?

...а никак не обстоят, нет Пасекова, и не будет уже никогда..там не только книга с ресурсом, там много чего нужного встало и, похоже, вряд ли будет двигаться дальше. Если, конечно, найдётся такой же, "идеализированный" продолжатель...
С уважением -
Бабий Сергей

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

На сегодняшний день лучшей современной книгой по автоматизации для меня является - Е.С.Бондарь, А.С.Гордиенко, В.А.Михайлов, Г.В.Нимич. Автоматизация систем вентиляции и кондиционирования воздуха. 2005. Жалко, что она только по вентиляции и кондиционированию.
А по оформлению проектов автоматизации - Клюев, Глазов, Дубровский, Клюев. Проектирование систем автоматизации технологических процессов. 1990.

Лучше уже и не напишешь. Если только скрестить их вместе и добавить автоматизацию других инженерных систем: тепловые пункты, холодильные центры и т.д.

Как-то заглохла тема. Для начала хотелось бы переосмыслить, в контексте темы, вопросы технического регулирования, пресловутого ПП №354 и сложивщейся коррупционной практики (стоимость тепла возрастает в 2...3 раза по дороге к потребителю). ТСЖ или совет собственников источник денег всё-таки. И он заинтересован в их экономии по определению, или хотя бы большей прозрачности расходования.

Сергей, не могли бы Вы пояснить это сообщение? Я правильно понял про "ТАМ"?...

Умер Владимир Пасеков. Уж 4 года тому. Вся надежда на его брата - Михаила!..

Алексей К.

Вот такую штуку сделали для 68 ИТП жилых домов и 1 котельная в системе. Очень много чего еще предстоит сделать, но работает уже с 2015 года.
http://npu-scart.ru/images/АРМ_17.06.2019_H.mp4

Not Found
The requested URL /images/АРМ_17.06.2019_H.mp4 was not found on this server.

Вот новая ссылка: http://npu-scart.ru/index.php/software-dev.../remote-control