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

1. Заслонка.
2. Фильтр.
3. Секция нагрева.
4. Вентилятор.

И обвешаем ее конечными устройствами со встроенными Lonworks реальных производителей. Модели писать не буду ибо лень. В общем:

1. Заслонка. Привод Belimo. Перед заслонкой датчик наружной температуры Thermokon.
2. Фильтр. Датчик реле перепада давления, подключенный к модулю ввода дискретных сигналов Thermokon.
3. Секция нагрева. Насос Wilo. Датчик температуры Thermokon. Термостат, подключенный к модулю ввода дискретных сигналов Thermokon. Клапан регулирующий с приводом Belimo.
4. Вентилятор. Частотный преобразователь Danfoss. Датчик температуры Thermokon.

Для управления вешаем какую-нибудь простенькую панельку, например Telda.

Преимущества:

1. Нет щита автоматики.
2. Меньше проводов, гофры, лотков и т.п.
3. Меньше монтажа.
4. Проще настройка.
5. ...

Недостатки:
1. Цена.
2. ...

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

Если вся эта система будет глючить, то концов не сыщите. Ну во первых какое то устройство должно управлять включением/отключением, менять задания, принимать сигнал о пожаре и вообще управлять всей системой. Иначе получится всадник без головы. Чем плохо подключение датчиков по протоколу? Проверить правильность исполнения протокола каждым устройством в смонтированной системе врят ли удастся, и придется гадать на кофейной гуще. Например у вас температура не соответствует реальной. Кто виноват, датчик или ПИД регулятор? А если система встала по перепаду давления, а ремни на вентиляторе в норме? Если же есть щит автоматики с контроллером и стандартные датчики, вы не доверяете сведениям контроллера, то тестером элементарно проверить кто врет, контроллер или датчик. Померять контакты датчика перепада давления на клеммах контроллера и непосредственно на датчике тоже просто.

Итак, понеслось...



Если так, то аналогично должна глючить сеть, скажем целиком выполненная на контроллерах Lonworks.



Допустим в данном контексте включением/выключением управляет оператор SCADA системы, рассматриваемая приточка является куском распределенной сети Lonworks инженерных систем здания.



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

Kass, аргументы против приняты, но скажем так они не очень критичные. Во всем можно разобраться.

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



Ну Скада всем не управляет. Она только дает команду на включение. А где сами триггеры стоят, кто жалюзи открывает, кто насос включает, где ПИД стоит? Надеяться на Скаду нельзя. Это писюк под виндами. Он может повиснуть, быть отключен, хаб где то сдох, при этом вентиляция не должна работать? А ведб если вы все на скаду повесите, то заслонка открыться успела, насос не влючили, вентилятор включили и комп со скадой отключился. Кто в этот момент замерзание обрабатывать будет? Т.е. велика вероятность эфекта парализованого человека, у которого что то работает, а что то нет. Даже господь Бог сделал так, что если у человека что то глючит, так он сознание теряет. При этом ни руки ни ноги ничего не делают. Ведь человек как пример идеала интеллекта имеет в этом роде централизованную систему.


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

А самое главное надо понять мотивацию. Для чего все это? Зачем от добра добра искать? Зачем себе создавать преграды, что бы потом их героически преодолевать?

1.Прочитал, подумал, чувствую не до конца понял мысль автора темы...
Обычно децентрализованной называют несколько другую систему...
2.Вот Kass добавил и получилось, что у децентрализованной системы нельзя тестером проверить сигналы...
Хотя ему известно, как можно, например в KNX(децентрализованная технология), проверить информацию телеграмм. Да нужно ПО, нужно знать как им пользоваться и иногда это сложнее, чем тестером...Но когда глючит система... По большому зданию бегать с тестером или из одного места на РС? А если только одна установка, то я с ним соглашусь и двумя руками буду голосовать за щит и тестер.
3.Странный вопрос, в чем сомнения по функционированию?
4.Может в этом вопросе и кроется Ваш интерес? В таком случае можно подробнее?? Не хотите в форуме можно в личку.
То, что Вы рассматриваете логически, мне давно хотелось реализовать на практических занятиях в Центре. Может стоит объединить усилия?

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

Да дело не в телеграммах. Я могу и консолью посмотреть, что у меня на входах. Но! Это мы видим только то, что видит контроллер. Если сбит цикл чтения или неверное опорное напряжение, то он будет видеть не ту температуру, которая на самом деле в канале или в обратке. Он вам честно покажет +20, когда на самом деле 0. Вот тут то и требуется именно то, о чем я говорю. И определить это можно только тестером. И если у меня подключен термистор к аналоговому входу, я могу в соответствии с таблицей преобразования параметра проверить по сопротивлению, что именно я получаю от контроллера, причем в нескольких точках системы. Если датчик токовый, то я могу померять ток и проверить по таблице температуру. Если параметр передается по цифре, то не важно какая система, централизованная или нет, проверить многократно сложнее.

Например?



Kass старый "волк", его хлебом не корми, дай с тестером полазить. Эта тема не для него.



А потому что я на практике ни разу не видел такого решения, хотя шкурой чую, что оно в принципе ен отличается от управления жалюзьми, светом и т.п. в т.н. "умном доме", построенном на Lonworks.



У меня есть шкурный интерес к производству некоторых компонентов такой системы. Стиль работы отечественных подрядчиков и заказчиков как нельзя лучшее для нее подходит, плюс еще несколько факторов. Цель данной темы отчасти развеить мои сомнения, отчасти подтвердить востребованность данных изделий. К сожалению в области Lonworks я всего-лишь теоретик - ни одной системы на нем не сделал - у меня все на Ethernet / Modbus-TCP.

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

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

Мотивацию надо понять в следующем. Зачем менять устоявшиеся стандарты? Кого не устраивают 0-10В, 4-20мА, сухой контакт? Ради чего надо все заморочить, если при этом эксплуатация становится проблематичной. Вы учтите, что на подавляющем большинстве предприятий в эксплуатации КИПовцы прекрасно знают аналоговые и дискретные сигналы и умеют пользоваться тестером. Проблем у них с этим нет. Зачем им впихивать весь этот геморой, если нет никакого преимущества? Опишите хоть одно существенное преимущество, ради которого стоит все это городить?


Разница огромная. Если в умном доме у вас работает управление светом, а вот жалюзи отвалились, то ничего страшного. В приточке все слишком взаимосвязано. И если не работает насос, нельзя что бы работал вентилатор, либо были открыты жалюзи. Там либо работает все, либо все отвалилось. Ощутима разница?

Их слишком много, и в итоге они ведут к одному большому преимуществу - цена. Вот только некоторые, основные:

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

2. Меньшее количество кабельной арматуры (труб, лотков…).
См. п. 1

3. Меньшее количество монтажных работ.
См. п. 1 и п. 2

4. Отсутствие шкафа автоматики.
Процессор обработки сигналов переносятся непосредственно в полевое устройство.

5. Высокая надежность системы.
Отказ одного датчика не ведет к отказу работы остальных, как в случае с единым контроллером.

6. Легкость конфигурирования, перенастройки и обслуживания.

7. Сопоставимая цена.

8. Меньшее количество проектных работ.
Уменьшается количество листов схем проекта из-за упрощения принципиальных электрических схем.

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

10. Легкость ремонта и обслуживания.
Старое выкинул - новое вставил. Без разбора шкафа автоматики.

А исполняемая программа где будет находиться? Все равно будет контроллер или промышленный РС.
Не... Как вариант запрограммировать Neuron Chip (если это LonWorks устройство). Но, честно говоря, не
знаю хватит ли памяти для прописывания алгоритма приточной установки по нейронам. Идея вообщем интересная.
Интересно, а попытки реализации таких решений у кого-нибудь были.


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

Да именно об этом речь и идет Ждем, пока спецы по Lon откликнуться...

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



Из вышеперечисленного не следует.



Шкаф автоматики у вас останется. Вы должны где то разместить автоматы защиты, блоки питания или трансформаторы, шины заземления, органы местного управления и т.д.



Вот как раз обрыв слаботочного провода у вас приводит к отказу системы влюбом случае. Ранее если у вас оборвался провод от датчика перепада на фильтре система продолжала работать выдав сигнал о загрязнении фильтра. Потом все то, что я описывал в предыдущем посте. Я давно занимаюсь разными цифровыми потоками и протоколами. Вот не далее как сегодня отвалилась исходящая связь на нашей АТС. Трассировка показывает, что по потоку по протоколу ISDN PRI я на свой сетап получаю релис комплит вместо калл просединг. Оказалось подглючивает шлюз G703 - IP. Оператор предлагает сделать мою станцию мастером, а шлюз слейвом, хотя если задуматься, то с какой стати? Вот отложили на вечер эксперименты. Но если АТС имеет широчайший набор средств диагностики потока (хотя требует очень высокого уровня знания персонала), то АСУ такого не имеют, да и врят ли кто из персонала знает служебные команды и сообщения, что бы их расшифровывать. А значит как я вам говорил, будет просто гадание на кофейной гуще. Кто нибудь знает какие помехоустойчивые коды используются протоколами и систему команд протоколов?



И какая же легксть? Если ранее вы подключили термистор или пресостат и более ничего не конфигурируете, то теперь вам потребуется еще и конфигурирование.



Цена при всем этом значительно выше.



Это ни есть хорошо, т.к. за каждый лист мне платят. Вам просто меньше заплатят за проект.



То же самое и у меня все просто. Я на каждом щите вывожу 485 интерфейс. Надо что то добавить, я вешаю дополнительный щит и просто кидаю витую пару на старый щит. Тот пример, что я вывешивал именно постепенно и строился и продолжает строиться. Появляются все новые и новые щиты, котоые включаются в имеющуюся систему. ТОлько мне ничего не приходится конфигурировать. Подключил и все работает.


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


А ПИД регуляторы где будут? А где будет местное управление?

Не только и не столько. Температуру измеряют термометром и по контрольному же термометру тарируют датчики, а тестер всего лишь показывает сопротивление - даже не соответствие его с температурой. Пользоватья лишь тестером - в высшей степени неоправданный оптимизм.
И потом, кто же мешает сверить показания контрольного термометра с тем, что выдает датчик и/или видит контроллер. Методом замещения узлов можно найти причину даже без тестера.


Кто к кому подключен, кто что получает, от кого и где?


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

С уважением Взводатор.

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

И понятие "всего лишь цифровой", звучит типа "нужен всего лишь бентли". Какая мелочь то? А если у вас в штате 10 наладчиков мотается по всей округе, то всего лишь 10 цифровых тестеров нужно.

Питание так же, как и слаботочку можно сделать по топологии "линия". Например в лотке вдоль установки идет один кабель ВВГ, от него отводы к каждому силовому потребителю. Автомат защиты ставится непосредственно на потребителе. Питание устройст и управление - одним 4-5 жильным кабелем типа "витая пара".



Согласен. Размеры его будут малы. Автоматы защиты - непосредственно на устройствах. По аналогии с частотниками IP54 со встроенными предохранителями.



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



Ну если раньше Вы программировали алгоритм, то от этого никуда не деться. Только теперь Ваш алгоритм "размазан" по отдельным датчикам / исполнительным механизмам.



Согласен, однако Сегнетикс например смог побить миф о "дороговизне" автоматики.



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



Да, такие проблемы имеют место быть. Впрочем если сломался "Контар", то Вы все равно приедете с новым и на месте его будете программировать.




Это все есть.

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

В принципе данное обстятельсов справделиво для Master-Slave топологии.

Ксттае можно сделать очень дешевые датчики с Modbus на борту, однако тут свои недостатки присутствуют...

Обязательно Modbus?
Датчики температуры DS18B20 (Даллас Семикондуктор) подключаются по 2х проводной линии. Используются в щитах автоматики приточных установок VTS (это где калькулятор на дверце приклеен).
Мы так-же использовали эти датчики для контроллера КПВ-1, сделанного по нашему заказу. На заказ нам разработали плату преобразователя 0-10В для этих датчиков. С этой платой датчик можно к аналоговому входу контроллера цеплять. Стоимость датчика около 100р.

1. Система LonWorks для здания.
2. Но он активно и правильно выступает и пытается нас убедить. Только в чем? Что нельзя измерить цифру тестером? Что в цифре сложнее разобраться, чем в аналоге? Зачем вообще, с его точки зрения, нужно было изобретать РС, когда все считали на счетах и лог. линейках.
3. Спасибо за откровенное пояснение. Хочется получить приглашение в гости и переговорить...

Ага, а автомат какой поставите? У вас одно устройство может потреблять 1 Вт, а другое 11кВт. И как вы все это свяжите? А еще почитайте ПУЭ. Там речь вообще не идет ни о какой "линии".



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



Только алгоритм у меня выглядит графически единым целым. И самое главное при этом, что если что то работает не так, как это должно, я знаю кого напрячь. А вот вы написали алгоритм, глазами все правильно, а работает не правильно. Кого вы напряжете, если у вас 10 производителей на одной шине? Только танец с бубном.


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


Итак, из рассмотренного выше ни одного явного преимущества не выявлено. Тогда на оно нам на? В смысле зачем нам это все надо?

1. Все понятно. Нет никакого другого смысла. В LonWorks связи цифровые между контроллерами, так они везде цифровые. Ну немножко коряво последнее предложение, некоторые могут не понять - цифровые... дискретные. Преподавать не хотите?
2. Я спрашивал про мотивацию особенности Вашей позиции в споре. Мне она не понятна. Здесь никто не ратует за всеобщую автоматизацию(интеграцию), скрещивание ежа с ужом и так далее... Кто кому пытается "впихнуть", простите за выражение? Кто спорит, что сложить в уме быстрее, чем на РС или даже счетах?
То, что Вы отмечаете очевидную проблему при внедрение новых систем в службы эксплуатации, не останавливает технического прогресса. Но кто с Вами спорит, что использование нового должено быть обосновано?

Хороша или не хороша большая цена? Для конечного потребителя ответ однозначен, для Вас тоже. Чем дороже тем лучше.(Правда жизни). Почему тогда нужно заказчику предлагать дешевые контроллеры, на дорогих можно больше заработать. Лохотрон для заказчика? Или лишний лист проекта в силу относительно малой цены нельзя сравнить с лохотроном? Это опять к Вашей мотивации в споре...

Маленькая неточность?

Оно Вам надо? Это опять к манере ведения спора. Вы сами можете легко и подробно пояснить проверку. Если сами себя не убедите, то другие не помогут.

Я не придираюсь, я пытаюсь понять и сделать наш спор более конструктивным.

В цифре значительно сложнее разобраться, если используются примитивные устройства. Если речь идет о трассировке, мониторинге и диагностике цифровой сети, то это можно реализовать лишь в устройствах с мощными вычислительными ресурсами, и соответственно дорогими. Например в цифровых АТС городского типа это есть, как есть и возможность измерения абонетской аналоговой линии самой АТС. Большая АТС вам измерит и емкость, и индуктивность кабелей, покажет значение счетчика ошибок и проскальзываний, раскроет все служебные пакеты и выведет их в окно трассировки. А вот попробуйте в миниАТС Панасоник поставить на трассировку поток Е1. Только танец с бубном. Так и в вашей сети, которая собрана из примитивных слабых устройств. Там никакой диагностики не будет. И в случае чего только танец с бубном. Сравнение с ПиСи не удачно в данном контексте, т.к. скорее выступает на моей стороне. Это я предлагаю поставить в щит что то типа ПиСи, но специально для АСУ, Который то и данные выплевывает по эзернету как ПиСи, а вы пытаетесь его заменить несколькими калькуляторами, связанными по какому то унифицированному протоколу, принятый всем миром для связи калькуляторов.

Блинн!!
1.Так и я о том же.
2. Какая моя сеть? Предлагался просто пример с LonWorks, Вы его считаете притивным? Или Вы утверждаете, что в сети за исключением телефонной и эзернета не возможна диагностика?
3. Слава ал... Разобрались наконец, но похоже не до конца. Значит в щит можно ставить цифровой(ужасное слово) ПЛК, а использовать РС для диагностики нельзя потому, что с тестером проще???
4. Не пытался, не пытаюсь и не буду пытаться - "честное пионерское". Это надо же так спорить, что не видеть очевидного. Вы для связи контролеров в сети не унифицированный протокол используете? Вы же сами говорили, что дело не в протоколе и я с Вами соглашался.
Да и эзернет не протокол и Вы это знаете... Вам по жизни противники нужны или союзники?
Мне - союзники...

Своих то обучаю по-тихоньку. А о другом пока не думал... Если ректором, то...



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



Никакого лохотрона. Суть в том, что стомость проектных работ примерно 10% от всего проекта. И если в моем случае проект дороже на 30%, зато все остальное дешевле на 40%, то сумарно проект будет на 30-35% дешевле. Только моя работа с проектом оплачена. А если бы я делал по рассматриваемому тут варианту, то больше бы заработали производители оборудования, а я меньше. Т.е. я развел бы заказчика на деньги, но при этом не ради себя, а ради производителей оборудования. Причем многие из этих производителей мне даже софт не дадут бесплатно на стадии проектирования, а я им должен такие подарки дарить. При этом еще должен и усложнить заказчику жизнь проблемами в эксплуатации. В чем же логика?


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


Вы внимательно прочитайте первый пост, а то выпали из контекста. Там нет контроллера вообще, как и щита автоматики. Именно об этой сети и идет речь. Именно на нее я и ссылаюсь.

1. Lonworks - протокол для конечных устройств. Для здания Lontalk / IP и т.п. IP протоколы.
3. Смысл? Готовы профинансировать исследования/разработки?

Давайте упростим задачу, а то не все понимают философию Lonworks. Вопрос специально для господина Kass:

Если завтра Вам предложат набор датчиков, исполнительных механизмов с протоколом Modbus-RTU по EIA-485, которыми будт управлять Modbus-RTU Master вида аля Segnetics без или с минимальным набором встроенных входов/выходов и общей ценой набора сопоставимой или ниже Вашего щита автоматики - Вы рассмотрите возможность применения данного оборудования в своих проектах?

Технически, можно будет с каждого устройства снимать кучу показателей, что недостижимо при применении обычных аналоговых сигналов 4-20 мА или 0-10 В. Например с привода клапана - начиная от моторесурса и обратной связи и кончая ошибками типа механической перегрузки, схемы и т.п.

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


При применении обычных аналоговых сигналов все это есть. Моторесурс считается самим контроллером, т.к. именно он им упарвляет. Если взять привод Белимо (с которыми я работаю), то там есть и обратнаясвязь в виде того же 2-10В. Механической перегрузки у него нет. Если вы ее превысили, то обратная связь это покажет. Весь привод подключается UTP, и все есть. Зато, я могу вам распечатать графики того, что выдал на привод ПИД и положение, в котором он при этом был например за декабрь 2005 года. Я могу оценить скорость реакции привода на управляющее воздействие во времени, т.к. нет запаздывания передачи сигнала ОС по цифре. У меня разница между временем записи воздействия и чтением ОС ПОСТОЯННО и менее цикла программы.

Самый главный недостаток подключения датчиков по цифре - несоответствие времени получения значения со временем измерения. Т.е. если в 21:00:15.3 вы получили значение датчика, то вы не знаете, во сколько было сделано это измерение. А значит нет правильной работы ПИ и ПИД регуляторов, и никакой точности процессов.

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

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

Это в чистом виде централизованная система.
Мне кажется, что так до конца и не выяснили само понятие децентрализованная система управления. На склько я помню из своего курса ТАУ все АСУ и САУ бывают трех видов:
1. Централизованные - все управление сводится к одному устройству (ярчайший предстваитель - сети работающие по идеалогии Master-slave)
2. Децентрализованные - все управление сосредоточено по месту, связи между локальными устройствами управления отсутствуют.
3. Централизованно-децентрализованные системы - локальные устройства управления связаны меж собой в сети (вот место для LonWorks)

Принято



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

2. У АЦП есть такой параметр, как время преобразования. У хороших сигма-дельта АЦП это от около 100-500 мс, причем чем выше разрядность тем больше время.

3. Обработка сырого значения АЦП так же занимает процессорное время, посокльку например сигнал Термопары имеет нелинейную характеристики и в современном контроллере аппроксимируется полиномом. Чем выше порядок этого полинома тем точнее значение.

1. Вот и скажите, когда была измерена температура, полученная по CAN, которая у меня в архиве записана как 15:08:15.3?

2. Времяпреобразования АЦП есть и в датчике, и чуть выше приводится время 750 мсек (!). В контроллере время преобразования порядка 0.1-0.3 сек, и фактически равно времени цикла. Т.е. пока выполняется цикл программы, АЦП получает значение, в начале следующего цикла считывается это значение и учавствует в обработке, например подставляется в формулу ПИД регулирования. Полученное же значение по цифре измерено несколько циклов назад, а обрабатывается только в этом цикле. Теперь посмотрите на дифференциальную часть уравнения и подумайте, как она будет на это реагировать? Т.е. можно будет использовать только ПИ регулятор.


В ПИ регуляторе вполне возможно не заметно, проблемы с ПИД регуляторами.

Наверное соглашусь Показания датчиков температуры обновляются с интервалом в 1 секунду.
Хотя, для приточной установки (Subj) это время не критично.

Вы знаете, если вы поставите быстродействующие привода на трехходовик, и задействуете Д составляющую, то скажется. У вас каков разброс Т в канале от задания во времени?

Не задействую
Там этого параметра нет. Привод имеет время хода 120 секунд. Разброс температуры примерно +/-0,5С.

Ну так это вполне закономерно. Не включена из-за описаной мной проблемы. А значит сознательное уменьшение функционала за счет интереса и прибыли производителя контроллеров и датчиков. Значит как результат более долгий выход на режим. Вот вам и последствия. Поэтому я и спрашиваю: зачем все это?

Мы ведь так и не нашли ни одного существенного преимущества. Так, только что то эфемерное. Зато недостатки налицо. ТОгда зачем вообще развивать это направление? ИМХО это тупиковая ветвь развития.

У Belimo все парамтеры настраиваются - время хода то же

Ладно, тему закрываю.

Не настраивается. Например у NV-24 - 150сек, а у NVY-24 - 35 сек.

http://belimo.ru/files/p19.pdf

Модельный ряд приводов Belimo не ограничивается этими двумя моделями В тех, которые использую я, настраивается ВСЕ. Начиная от крутящего момента и кончая временем хода. Прямо с компьютера программой Belimo PC tools или с контроллера, функциональным блоком в CoDeSys. Так же они передают всю эту информацию прямо в контроллер и подключаются по шине - до 8 приводов.

http://www.belimo.eu/pdf/e/LM24A-MP_1_0_en.pdf

1. Своих понятно. Может стоит подумать. Уговоривать не буду, вроде понимаем, что это должно идти от души.. Если она не готова, то и нечего...
2. А я таких фраз и не употребляю. Дальше понятно...
3. Если в Вашем случае заказчик идет примерно на 19% стоимости проектных работ, то флаг Вам в руки.
4. Пример 1. Проект 100%, оборудование 90%, из них 50% Вы отдаете заработать производителям, и того Вам остается 55%. Ваш пример. Проект 67%, оборудование 54%, из них Вы отдаете 50% заработать производителю, итого Вам остается 40%. Т.е. в Вашем примере Вы заработаете примерно на 25% меньше. Предполагаю, что в случае более дешевого оборудования производитель Вам дает и меньшие скидки и тогда, если Вы отдаете 80% производителю, то Вам остается только 24% от заказа, т.е Вы заработаете меньше вдвое, а производители заработают почти одинаково.
Т.е. Ваши выводы не верны. Вы пытались убедить меня только фразой, а никак не доводами и математикой...
5. Действительно где логика? Вы никому ничего не должны. Ну давайте еще раз про софт. В мире не всегда софт к контроллерам бесплатен и что? Вы всех готовы записать в лохотронщиков?
А эксплуатация отдельная проблема.
6. У Вас наверное оговорка или ошибка в сообщение №15:В паспорте на каждый градус приводится соответствующая температура.
7. Вы придираетесь к автору темы. А это плохо, Вы себя ограничиваете в рассмотрении. Он говорил об идее. Или Вы не понимаете? Такая сеть не нужна для приточки, кто спорит, но Вы просто "кусаетесь и лаете" отстаивая очевидное.

1. Я говорил о системе LonWorks. То что на верхнем уровне скорее всего будет Lon/IP не вызывает сомнений, но система будет все равно децентрализованной.
3. Возможно моя информация Вам поможет, особенно что касается сбыта и т.д.
4. Конечно не все, но Лон ведь только для примера. Kass специально не понимает децентрализованных систем, он не готов принципиально воспринять цифровой обмен на первом уровне автоматизации, хотя на втором использует, а про третий молчит, понимая, что там вообще нет альтернативы(а ведь было время когда нигде не было цифры), его не убедишь покупать подобное оборудование. Без щитов автоматики совсем не получиться, хотя бы часть исполнительных устройств будут монтироваться в них.
Зачем Kassу устройства с которых нельзя снять информацию тестером? Информация с приводов ему не нужна или он ее собирается получать с контроллера(только как?) и т.д. И к сожалению таких большинство в России, он сам об этом писал.

Вот это уже интереснее Но пока сбывать нечего, но возможно скоро я к Вам обращусь! Заранее спасибо!!!



Как нестранно шина As-i в промышленности уже давно победила над сигналом 4-20 мА.

Почитал, нифига не понял, кроме разве того что все опять спорят с Kass-ом...

Мои мысли по инженерным системам вообще:

1. Законченный узел должен быть самодостаточным, и функционировать не взирая на обрывы всех шин и зависание всех компов... Т.е. - если, к примеру, это станция повышения давления - то вне зависимости от работоспособности модбасов, лонгворксов и профибасов она должна сама смотреть сухой ход на входе и созданное давление на выходе. Её работа должна зависеть от этих двух параметров, и быть независима от каких либо проблем с узлами диспетчирезации и удаленного управления, так как они только создают удобство для эксплуатации, а это не является непосредственной задачей станции.
2. Узел должен быть "прозрачным" для потребителя. Нет его. Вообще. Функция есть, а узла нет. ИМХО ни один потребитель не будет писать жалобы на то, что он не может наблюдать в онлайне работу насосов отопления. А вот на холод в квартире жаловатся будет.
3. Любые системы диспетчирезации и удаленного управления применяются исключительно для снижения затрат на эксплуатацию системы. Если нет сетевого контроля КНС - на ней нужно держать дежурных и платить им зарплату. Из года в год. А на сегодняшний день и в нашей стране уже остается все меньше возможностей платить зарплату в размере стоимости обеда в ресторане - соответственно затраты на содержание сотрудников растут. И очень скоро Заказчику будет выгоднее поставить сколько угодно дорогую систему контроля и диспетчирезации, чем держать для этих целей людей. Взять сегодняшнюю Москву. Средний зароботок низкоквалифицированного персонала - не менее 1000 баксов. Если держать на любом удаленном объекте дежурных - это минимум 3 человека. За год - 36 тысяч баксов. Дешевле заключить контракт с РоссКосмосом на диспетчирезацию через спутник.

Резюме: Во первых система должна работать максимально надежно и не от чего не зависеть. Во вторых она не должна напрягать мозги эксплуатации. В третьих - абсолютно не важна стоимость покупки системы, а важна сумма стоимости системы и стоимости её эксплуатации. Если отказ системы может привести к миллионным убыткам - только идиот будет искать систему по критерию "подешевле".

Можно поподробнее про шину As-i уже давно победившую в промышленности над системой 4-20 мА+HART?

Одного я видел. Он хотел "все видеть и "все делать вручную". Ответ моего коллеги: "Так а зачем тогда тебе жена?"

Абсолютно согласен!

С уважением Взводатор.

Дык, не проблема. Если готов за это заплатить. У меня тоже бывают заказы с многократным дублированием автоматики. В последнем было указано "обеспечить пуск насосов: 1 - в автоматическом режиме, 2 - кнопками Пуск\Стоп расположенными на дверце шкафа, 3 - кнопочными постами, расположенными в непосредственной близости от насосов, 4 - с удаленной панели оператора.

Абсолютно верно. И все это направление с цифровыми датчиками, передающие это по каким то протоколам перечеркивают эту концепцию. ИМХО тупиковая ветвь.


Не информацию. Я говорю об эксплуатации, которую вы пытаетесь максимально усложнить. У приводов есть выход сигнала обратной связи 0-10 или 2-10В. Заводите его на контроллер и видите реальное положение клапана.

А как в таком зоопарке рспределяются приоритеты? И что будет если 1, 2, 3 и 4 будут противоречить друг другу?

Расскажите-ка подробнее или ссылочку. Спасибо.

Ваши бы слова да Богу в уши

AS-i (Actuators/Sensors Interface) по большему счету промышленный аналог EIB. Почитать можно тут

Ну большие проекты возможно и проглотят такое удорожание. А на счет котельной или насосной на десяток насосов... Большие однако сомнения в целесообразности.
Хотя в целом мне понравилось, обмотать все одним кабелем и навешать на него датчиков. Заманчиво однако