Децентрализованная система для управления приточкой, Обсудим преимущества и недостатки? Опции

[Abysmo]

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

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. ...

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

Сообщение отредактировал Abysmo - 20.6.2007, 17:34

[Abysmo]

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

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. ...

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

Сообщение отредактировал Abysmo - 20.6.2007, 17:34

[Kass]

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

[Abysmo]

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

Если вся эта система будет глючить, то концов не сыщите.

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

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

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

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

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

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

Сообщение отредактировал Abysmo - 20.6.2007, 18:53

[Kass]

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

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

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

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

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

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

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

[Pasekov]

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

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

[Pasekov]

... Даже господь Бог сделал так, что если у человека что то глючит, так он сознание теряет. При этом ни руки ни ноги ничего не делают. Ведь человек как пример идеала интеллекта имеет в этом роде централизованную систему.
...А самое главное надо понять мотивацию. Для чего все это?

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

[Kass]

Хотя ему известно, как можно, например в KNX(децентрализованная технология), проверить информацию телеграмм. Да нужно ПО, нужно знать как им пользоваться и иногда это сложнее, чем тестером...Но когда глючит система... По большому зданию бегать с тестером или из одного места на РС? А если только одна установка, то я с ним соглашусь и двумя руками буду голосовать за щит и тестер.

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

[Abysmo]

Обычно децентрализованной называют несколько другую систему...

Например?

Хотя ему известно, как можно, например в KNX(децентрализованная технология), проверить информацию телеграмм. Да нужно ПО, нужно знать как им пользоваться и иногда это сложнее, чем тестером...Но когда глючит система... По большому зданию бегать с тестером или из одного места на РС? А если только одна установка, то я с ним соглашусь и двумя руками буду голосовать за щит и тестер.

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

Странный вопрос, в чем сомнения по функционированию?

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

Может в этом вопросе и кроется Ваш интерес? В таком случае можно подробнее?? Не хотите в форуме можно в личку.
То, что Вы рассматриваете логически, мне давно хотелось реализовать на практических занятиях в Центре. Может стоит объединить усилия?

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

[Kass]

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

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

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

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

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

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

[Abysmo]

Опишите хоть одно существенное преимущество, ради которого стоит все это городить?

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

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

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

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

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

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

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

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

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

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

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

Сообщение отредактировал Abysmo - 20.6.2007, 20:53

[aaa]

Процессор обработки сигналов переносятся непосредственно в полевое устройство

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

Если параметр передается по цифре, то не важно какая система, централизованная или нет, проверить многократно сложнее

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

[Abysmo]

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

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

[Kass]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Взводатор]

мы видим только то, что видит контроллер. Если сбит цикл чтения или неверное опорное напряжение, то он будет видеть не ту температуру, которая на самом деле ... Он вам честно покажет +20, когда на самом деле 0. ... И определить это можно только тестером.

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

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

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

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

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

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

[Kass]

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

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

Сообщение отредактировал Kass - 21.6.2007, 11:27

[Abysmo]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это все есть.

Сообщение отредактировал Abysmo - 21.6.2007, 12:10

[Fanat]

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

[Abysmo]

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

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

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

[Гость_mike-altai_*]

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

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

Сообщение отредактировал mike-altai - 21.6.2007, 17:00

[Pasekov]

1.Например?
2.Kass старый "волк", его хлебом не корми, дай с тестером полазить. Эта тема не для него.
3.У меня есть шкурный интерес к производству некоторых компонентов такой системы. .. плюс еще несколько факторов. Цель данной темы отчасти развеить мои сомнения, отчасти подтвердить востребованность данных изделий.

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

[Kass]

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

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

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

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

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

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

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

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


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

[Pasekov]

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

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

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

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

В паспорте на каждый градус приводится соответствующая температура.

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

Теперь так же подробно поясните процесс проверки цифрового датчика.

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

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

[Kass]

Что в цифре сложнее разобраться, чем в аналоге? Зачем вообще, с его точки зрения, нужно было изобретать РС, когда все считали на счетах и лог. линейках.

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

[Pasekov]

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

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

[Kass]

Преподавать не хотите?

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

2. Я спрашивал про мотивацию особенности Вашей позиции в споре. Мне она не понятна. Здесь никто не ратует за всеобщую автоматизацию(интеграцию), скрещивание ежа с ужом и так далее...

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

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

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

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

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

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

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

Сообщение отредактировал Kass - 21.6.2007, 23:33

[Abysmo]

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

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

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

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

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

Сообщение отредактировал Abysmo - 21.6.2007, 21:50

[Kass]

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

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

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

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

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

[Гость_mike-altai_*]

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

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

Датчик темпрературы DS18B20:
Точность ±0.5°C от -10°C до +85°C
Измеряет температуру от -55°C до +125°C (от -67°F до +257°F)
Настраиваемое пользователем разрешение от 9 до 12 бит
Преобразует температуру в 12-битовое слово за 750 мс (максимум)

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

Сообщение отредактировал mike-altai - 22.6.2007, 8:54

Прикрепленные файлы

 DS18B20en.pdf ( 149,17 килобайт ) Кол-во скачиваний: 29

 

[Сергей Долганов]

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

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

Сообщение отредактировал Сергей Долганов - 22.6.2007, 10:20

[Abysmo]

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

Принято

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

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

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

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