Встреча : Статья

От	K
К	Alex~1
Дата	23.12.2007 12:24:34
Рубрики	Прочее;

Re: Ну и...

> Как я понял, с этим проблемы. Финансовые.

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

Теперь у нас есть перспективный заказ, но когда на том заводе
зачешутся, не известно. Там нужно будет объединять информационные
системы с цехов в единое целое, и там можно лихо продемонстрировать
Интернет-технологию. Но. . . это в будущем. А пока под рукой такого
заказа нет. Из местного представительства Якагавы мужики (русские, с
японцами удавишься иметь дело) нам иногда таскают договора (они делают
низ, контроллеры, мы - верх, программу), у них красивая ксива и
хорошие связи. Поэтому сделаем <картонную дурилку> и покажем
якагавцам. Пусть они потрясут свои связи и найдут договор, где мы
смогли бы продемонстрировать технологию. Когда найдется заказчик,
будет нормально платить, а мы сможем сконцентрироваться на работе, у
нас будет возможность нарастить <мясо> (от системы шифрации до
очередей в сервлете) на технологию и хорошо ее протестировать. А вот
когда будет объект сдан, у нас появится козырь, который мы не смогли
получить в моделировании и поэтому уступили объект москвичам, и этим
козырем можно будет размахивать у носа у кого-нибудь посерьезней.

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

> какую именно? Можно поподробнее?

Если Вы не программист, специализирующийся в Интернет-технологиях, то
мы будем просто месить воздух. Вам это нужно?

>>(хакеры могут плакать,
> При чем здесь хакеры и зачем им плакать?

Ну, Вы же слышали, что они заваливают сервера Пентагона или ЦРУ? С
данной технологией у них этот фокус не пройдет.

>>сбылась мечта идиотов - данные отделены от представления,
> Не понял. При передаче? При обработке? Данные, строго говоря,
> практически всегда отделены от представления, если не брать HTML,
> конечно.

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

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

От	Monco
К	K (23.12.2007 12:24:34)
Дата	24.12.2007 11:25:47

Re: Ну и...

>Хорошо, вот Вам задача, у Вас на каждом экране системы десятки данных,
>и они должны обновляться каждую секунду. Как это делается в нормальных
>системах? Просто раз в секунду идет запрос на данные (или к Базе
>Данных, или к Драйверам Устройств и т.д.) и данные на экране
>заменяются. А как это делается в Интернет-технологиях? Каждый раз
>изготавливается новый HTML и перебрасывается клиенту?

Ну так используйте AJAX. Вот только этой прррррррорывной технологии уже 3-4 года.

От	K
К	Monco (24.12.2007 11:25:47)
Дата	25.12.2007 08:32:49

Re: Ну и...

> Ну так используйте AJAX.

А я что использую? AJAX

От	Monco
К	K (25.12.2007 08:32:49)
Дата	25.12.2007 11:26:12

Re: Ну и...

>> Ну так используйте AJAX.
>
>А я что использую? AJAX

А какое отношение это имеет к созданию "новых технологий"?

От	K
К	Monco (25.12.2007 11:26:12)
Дата	26.12.2007 01:30:29

Re: Ну и...

> А какое отношение это имеет к созданию "новых технологий"?

Потерпишь, рбъясню, с примерами, и все будет просто как грабли. Плохо,
что на НГ нарвалмсь, задержка

От	Alex~1
К	K (23.12.2007 12:24:34)
Дата	23.12.2007 18:22:35

Re: Ну и...

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

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

>Теперь у нас есть перспективный заказ, но когда на том заводе
>зачешутся, не известно.

Опять-таки типичная ситуация, совершенно нормальная.

>Там нужно будет объединять информационные
>системы с цехов в единое целое, и там можно лихо продемонстрировать
>Интернет-технологию.

Вообще-то объединение информационных систем цехов (если речь идет об управлении производством и производственными процессами) - не та область, где оптимальным выбором являюься "Internet-технологии" в смысле применения HTTP, HTML, сервлетов и прочего в том же духе.

>Но. . . это в будущем. А пока под рукой такого
>заказа нет.

Опять-таки ни творчество, ни диалектика тут не при чем, увы.

>Из местного представительства Якагавы мужики (русские, с
>японцами удавишься иметь дело) нам иногда таскают договора (они делают
>низ, контроллеры, мы - верх, программу), у них красивая ксива и
>хорошие связи. Поэтому сделаем <картонную дурилку> и покажем
>якагавцам. Пусть они потрясут свои связи и найдут договор, где мы
>смогли бы продемонстрировать технологию. Когда найдется заказчик,
>будет нормально платить, а мы сможем сконцентрироваться на работе, у
>нас будет возможность нарастить <мясо> (от системы шифрации до
>очередей в сервлете) на технологию и хорошо ее протестировать. А вот
>когда будет объект сдан, у нас появится козырь, который мы не смогли
>получить в моделировании и поэтому уступили объект москвичам, и этим
>козырем можно будет размахивать у носа у кого-нибудь посерьезней.

Это понятный разговор, мне это, естественно, знакомо. Но Вам не кажется, что это в сторону от обсуждаемой темы?
Кстати, упоминание сервлета меня несколько насторожило. Дело в том, что сервлеты - технология далекая как от эффективности, так и (самое главное) от масштабируемости, и они практически никогда не является "ключевой" частью серьезных систем.

>Теперь понятен процесс создания <новых технологий>?

А Вы разве говорили о новых технологиях? :)

>короче, послал этот регулятор подальше, так как в то
>время мне было явно не до всего этого геморроя. Вот так и гибнут
><новые технологии>. А живи в США, там быстро бы нашел кучу
>энтузиастов, которые попробовали с этой темы получить массу прелестных
>зелененьких бумажек, и дело завертелось бы.

У Вас страшно оптимистичное представление о том, насколько легко в США найти, по сути, инвестора.

>В СССР же какой-нибудь
>мелкий изобретатель должен был принести и прямо под нос сунуть уже
>готовый результат и затем умолять на коленях воспользоваться его
>изобретением.

При чем здесь СССР?

>Например, <новые технологии>
>должны создаваться из желания их создать, прямо из воздуха.

:)

>Если Вы не программист, специализирующийся в Интернет-технологиях, то
>мы будем просто месить воздух. Вам это нужно?

Я имею достаточное отчетливое представление об Internet-технологиях. Сейчас я уже не программист. Но был.

>> При чем здесь хакеры и зачем им плакать?
>
>Ну, Вы же слышали, что они заваливают сервера Пентагона или ЦРУ? С
>данной технологией у них этот фокус не пройдет.

Есть разное толкование терминов "хакер". В open-source, например, термин "хакер" имеет сугубо положительное значение. :)

>Хорошо, вот Вам задача, у Вас на каждом экране системы десятки данных,
>и они должны обновляться каждую секунду.

Сразу много вопросов. Но с ходу.
Десятки данных - это немного. Каждую секунду - тоже не бог весть как часто. Сколько у системы экранов - неясно. Насколько стабильно "число экранов у системы" - тоже.

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

>Как это делается в нормальных
>системах? Просто раз в секунду идет запрос на данные (или к Базе
>Данных, или к Драйверам Устройств и т.д.) и данные на экране
>заменяются.

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

>А как это делается в Интернет-технологиях? Каждый раз
>изготавливается новый HTML и перебрасывается клиенту?

Это зависит от клиента, в первую очередь. HTML как результат запроса подразумевает наличие клиента в виде броузера, возможно, с некоторыми наворотами (скриптами). Это странное решение для корпоративных производственных систем.

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

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

>Если Вы программист и Вам интересно, то мы можем обсудить все это.

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

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

От	Павел Чайлик
К	Alex~1 (23.12.2007 18:22:35)
Дата	26.12.2007 10:26:10

Есть вариант.

>>очередей в сервлете) на технологию и хорошо ее протестировать. А вот
>>когда будет объект сдан, у нас появится козырь, который мы не смогли
>>получить в моделировании и поэтому уступили объект москвичам, и этим
>>козырем можно будет размахивать у носа у кого-нибудь посерьезней.
>
>Это понятный разговор, мне это, естественно, знакомо. Но Вам не кажется, что это в сторону от обсуждаемой темы?
>Кстати, упоминание сервлета меня несколько насторожило. Дело в том, что сервлеты - технология далекая как от эффективности, так и (самое главное) от масштабируемости, и они практически никогда не является "ключевой" частью серьезных систем.

На счет ключевой части систем - совершенно верно. Хотя, можно извратиться и в рамках сервлета запустить целый сервер приложения, чем я 3 года назад занимался. Это решение имеет свои преимущества, хотя и не вполне стандартно. :))

А вот ошибочка на счет масштабируемости.
Вполне можно добиться и масштабируемости, если использовать тот же Томкат. Такая у меня сейчас задача стоит. Буду делать.
Хотя, у меня вся логика в Oracle сосредоточена и там все масштабирование (на оракле вопрос с кластеризацией решен), а от Томката просто требуется уметь работать в кластере и с кластером.

Не знаю зачем там "поцехам" понадобилось такое решение. Но все может быть :)))

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

Правда, с таким решением не стоит обижаться на заказчика, предпочитающего какое-нибудь стандартное (предсказуемое) решение. :))

Я и сам уже наобижался вдоволь.
Так что, ув. тов. Карамышев, я смеюсь сам над собой :))))

P.S. .... ладно, хватит... не буду больше писать :))))

От	K
К	Павел Чайлик (26.12.2007 10:26:10)
Дата	26.12.2007 13:12:10

Re: Есть вариант.

> Хотя, можно извратиться и в рамках сервлета запустить целый сервер
> приложения

> Вполне можно добиться и масштабируемости, если использовать тот же
> Томкат.

> Не знаю зачем там "поцехам" понадобилось такое решение. Но все может
> быть :)))

> Думаю, что можно извратиться и заставить сервлеты двух и более
> Томкатов работать, распределяя нагрузку.

Вот мы тут в разговоре с самого начала и напоролись на <системную
проблему>. НЕЛЬЗЯ сервлет заставлять заниматься ничем иным, кроме как
тем, чем он и должен заниматься, т.е. кроме как принимать <запросы> и
отправлять <ответы> (у нас в форме текста, xml-файл - очень удобно,
так как просто). Всем остальным должны заниматься системы вне
сервлетов и никакого отношения к сервлетам не имеющие, впрочем, как и
никакого отношения не имеющие и к интернету. Для них (обработчиков
запросов) совершенно без разницы, от кого запрос, или от своей
подсистемы, или от удаленной системы, или от сервлета, или напрямую от
браузера через RMI-механизм. Все должны заниматься СВОИМИ функциями и
категорически запрещено совмещать их с иными. И тогда, все остальные
проблемы исчезают.

Если вы такие умные - почему строем не ходите?

От	Павел Чайлик
К	K (26.12.2007 13:12:10)
Дата	26.12.2007 15:50:14

Мы ходим строем. У нас просто шаг такой :)))

>> Хотя, можно извратиться и в рамках сервлета запустить целый сервер
>> приложения
>
>> Вполне можно добиться и масштабируемости, если использовать тот же
>> Томкат.
>
>> Не знаю зачем там "поцехам" понадобилось такое решение. Но все может
>> быть :)))
>
>> Думаю, что можно извратиться и заставить сервлеты двух и более
>> Томкатов работать, распределяя нагрузку.
>
>Вот мы тут в разговоре с самого начала и напоролись на <системную
>проблему>. НЕЛЬЗЯ сервлет заставлять заниматься ничем иным, кроме как
>тем, чем он и должен заниматься, т.е. кроме как принимать <запросы> и
>отправлять <ответы> (у нас в форме текста, xml-файл - очень удобно,
>так как просто). Всем остальным должны заниматься системы вне
>сервлетов и никакого отношения к сервлетам не имеющие, впрочем, как и
>никакого отношения не имеющие и к интернету. Для них (обработчиков
>запросов) совершенно без разницы, от кого запрос, или от своей
>подсистемы, или от удаленной системы, или от сервлета, или напрямую от
>браузера через RMI-механизм. Все должны заниматься СВОИМИ функциями и
>категорически запрещено совмещать их с иными. И тогда, все остальные
>проблемы исчезают.

Так и это тоже уже давно изобрели. :)))
Я сам лично для себя изобрел.
Был просто счастлив, пока не прочел об этом в литературе :))))

>Если вы такие умные - почему строем не ходите?

От	K
К	Павел Чайлик (26.12.2007 15:50:14)
Дата	26.12.2007 20:25:38

Re: Мы ходим...

> Так и это тоже уже давно изобрели. :)))
> Я сам лично для себя изобрел.
> Был просто счастлив, пока не прочел об этом в литературе :))))

И поэтому мы как начинаем что-то разбирать на части, так у нас волосы
дыбом встают? Видели как Microsoft применила свою технологию Active-X
в Office?

От	Monco
К	K (26.12.2007 20:25:38)
Дата	27.12.2007 01:39:41

Re: Мы ходим...

>И поэтому мы как начинаем что-то разбирать на части, так у нас волосы
>дыбом встают? Видели как Microsoft применила свою технологию Active-X
>в Office?

Как?

От	K
К	Alex~1 (23.12.2007 18:22:35)
Дата	23.12.2007 21:54:17

Re: Ну и...

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

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

> Вообще-то объединение информационных систем цехов (если речь идет об
> управлении производством и производственными процессами) - не та
> область, где оптимальным выбором являюься "Internet-технологии" в
> смысле применения HTTP, HTML, сервлетов и прочего в том же духе.

А как еще поступать с разбросанными по городу объектами? Один такой
заказ у нас в свое время ушел из под носа. И это хорошо, если только
по городу, а не на сотни км.

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

Это у них <не эффективная> и <не масштабируемая>, а мы сделаем и одно
и второе, не первый раз идем поперек общепринятых подходов.

> У Вас страшно оптимистичное представление о том, насколько легко в
> США найти, по сути, инвестора.

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

> Я бы с удовольбствием. Но в русле разговора о творчестве,
> качественных скачках, диалектики и прочего в том же духе, а не чисто
> технологически-прикланой задачи.

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

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

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

От	Alex~1
К	K (23.12.2007 21:54:17)
Дата	23.12.2007 22:19:41

Re: Ну и...

>Просто хотел Вам поподробнее рассказать, что
>такое создание технологий, чтобы понятна была вся эта дичь от
>Михайлова.

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

>А как еще поступать с разбросанными по городу объектами? Один такой
>заказ у нас в свое время ушел из под носа. И это хорошо, если только
>по городу, а не на сотни км.

Здесь важно не расстояние, а производительность и устойчивость каналов связи. HTTP - протокол взаимодействия слабосвязанных систем по своей природе. Вы описывали систему с жестко определенными потоками данных и жесткими связями ее элементов. Не в расстояниях здесь дело.

>Это у них <не эффективная> и <не масштабируемая>, а мы сделаем и одно
>и второе, не первый раз идем поперек общепринятых подходов.

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

>> Я бы с удовольбствием. Но в русле разговора о творчестве,
>> качественных скачках, диалектики и прочего в том же духе, а не чисто
>> технологически-прикланой задачи.
>
>Чтобы понять о чем речь, могу простенькую систему, на которой
>тренируюсь обычно, взять и прислать. С. Java знакомы? Сможете
>запустить?

Знаком. И запустить смогу. Только зачем?
Давайте все-таки "на пальцах", т.е. на концептуальном уровне.

>Там работает Java - приложение, которое изображает систему,
>а броузер уже лезет к нему.

Естественно, что броузер лезет к приложению, это его нормальное поведение. :) Броузер - это по определению клиент, а приложение в данном случае - по определению Web-сервер. :)

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

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

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

Суть на форумном уровне в разумном размере постинга можете сообщить?

От	K
К	Alex~1 (23.12.2007 22:19:41)
Дата	24.12.2007 00:07:20

Что-то тут подумал

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

От	Администрация (Кудинoв Игорь)
К	K (24.12.2007 00:07:20)
Дата	24.12.2007 00:43:41

никаких проблем

>иметь разрешение модератора, иначе накажут за флейм.

особенно если сможете изложить без личных выпадов.

От	K
К	Alex~1 (23.12.2007 22:19:41)
Дата	23.12.2007 23:20:49

Re: Ну и...

> Я наблюдал (и даже пару раз участвовал по мере сил) в создании новых
> технологий, мне это рассказывать не надо. Михайлов этой темы ну
> совсем не касался.

Как это он не касался. У него получение нового знания (а технология
оно и есть) не требует материальной заинтересованности. А именно она
то и заставляет крутиться как пропеллер НТР в США. Михайлов - "Ведь не
только научные тексты, но и тексты
художественные, политические, философские и т.д. тоже не являются
товаром, ведь они нужны не сколько читателю, сколько автору, являются
его обращением к миру".

> Здесь важно не расстояние, а производительность и устойчивость
> каналов связи. HTTP - протокол взаимодействия слабосвязанных систем
> по своей природе. Вы описывали систему с жестко определенными
> потоками данных и жесткими связями ее элементов. Не в расстояниях
> здесь дело.

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

> Неэффективность и немасштабируемость заложена в фундамент сервлетов
> и поведение контейнеров - это (архитектурно) древняя разработка. По
> сравнению с некоторыми другими технологиями. Идти против
> общепринятых подходов в данном случае значит идти против открытых
> стандратов. Известно, что таким способом повысить эффективность
> возможно. Но зачем тогда брать те же сервлеты? На них свет клином
> совершенно не сошелся.

Можно поподробнее? А то я в этих вопросах дуб. Для меня интернет же
просто вспаомогательная технология, не более.

> Много - это, например, сотни тысяч броузеров, отслеживаюших почти в
> режиме реального времени счет спортивного состязания, например,
> теннисного матча.

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

> Суть на форумном уровне в разумном размере постинга можете сообщить?

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

От	Михайлов А.
К	K (23.12.2007 23:20:49)
Дата	24.12.2007 00:29:47

Re: Ловим за руку.

>> Я наблюдал (и даже пару раз участвовал по мере сил) в создании новых
>> технологий, мне это рассказывать не надо. Михайлов этой темы ну
>> совсем не касался.
>
>Как это он не касался. У него получение нового знания (а технология
>оно и есть) не требует материальной заинтересованности. А именно она
>то и заставляет крутиться как пропеллер НТР в США. Михайлов - "Ведь не
>только научные тексты, но и тексты
>художественные, политические, философские и т.д. тоже не являются
>товаром, ведь они нужны не сколько читателю, сколько автору, являются
>его обращением к миру".

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

От	Вячеслав
К	K (23.12.2007 12:24:34)
Дата	23.12.2007 18:14:09

Не хотел влезать, т.к. и так последнее время в основном скандалю

но тут уже ни в какие ворота не лезет

> Например, был у нас заказ на моделирование крупного химического агрегата. Сели и подумали хорошо. Выяснили, как нужно делать модели по уму, и это могло вылиться в пределе в новую технологию моделирования.
Извините, но новая «технология моделирования» именно агрегатов химических производств (относительно простых объектов) сама по себе никому не нужна. А нужны новые методы создания САР или АСУ ТП, которые повышали бы качество управления технологическими процессами. Соответственно, здесь как об инновации, по-уму можно было бы говорить о создании нового метода расчета и проектирования САР и АСУ ТП, и только уже в контексте этого имело бы смысл говорить об инновационном моделировании.

> Начали реализацию. А тут приехали москвичи и нас бортанули. У них есть уже конкретная реализация. И объяснять руководству завода, что такие модели не рабочие, что нельзя при помощи интегралов и дифференциалов описать сложный объект, все это объяснять без толку.
Извините, но это полная ерунда. Есть три принципиальных подхода к расчету контуров САР, которые на современных продвинутых системах зачастую реализуются комплексно.
1. Предрасчет по известной модели, т.е. по тем самым интегралам и дифференциалам.
2. Создание адаптивных САР, т.е. таких, которые сами ведут статистику объекта и в зависимости от нее корректируют преднастройки регуляторов.
3. Создание интеллектуальной системы, моделирующей знания и умения дяди Васи — технолога по управлению конкретной установки.
В первом случае методов настройки по НЕ МАТЕМАТИЧЕСКИМ моделям (системам алгебраических и дифуравнений или их отображений в виде АФЧХ) НЕ СУЩЕСТВУЕТ. Т.е. можно обмоделироваться с помощью нейронных сетей, нечетких множеств и т.д. и т.п. и пр. новомодных штучек — для регулирования это будет бесполезным.
Во втором случае сбор статистики не является проблемой моделирования, и в смысле инноваций можно говорить лишь о новых методах расчета адаптационных корректировок и новых схемах адаптивных регуляторов, но отнюдь не о моделировании собственно объекта, т.к. все решения в этой области пляшут не от модели объекта, а от конкретных технологических требований (к примеру, допустимость перерегулирования, ограничения на частоту движения исполнительных механизмов и регулирующих органов или т.п.)
В третьем случае моделируется не агрегат, а дядя Вася — технолог.

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

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

> Например, был у меня алгоритм регулятора, если не потерял его, и он, вполне вероятно, смог бы произвести жуткий переполох, так как это из серии конечных технологий. Алгоритм в три пальца, но на мощности допотопного калькулятора он бы утер нос Супер-мупер-ЭВМ.
Вы будите удивлены, но 99,9% действующих алгоритмов регулирования могут работать, не то что на калькуляторе, а на старой советской базе УСЭППА, а на супер-пупер ЭВМ их реализуют пачками, да еще и имея нехилый резерв вычислительной мощности этих супер-пупер класса 386 или первого пня.

> Но как его отрабатывать? Это мне нужно связываться с какими-то мужиками, которые работают с регуляторами и которые могут подсказать на каких алгоритмах и как его можно протестировать. Затем хорошо изучить проблемную область, какие фокусы возникают при каскадном управлении или при возникновении замкнутых цепочек, а лучше перечитать еще и том ТАУ потолще. . . короче, послал этот регулятор подальше, так как в то время мне было явно не до всего этого геморроя.
Класс! Вы только что сформулировали фундаментальнейшую проблему современной ТАУ, в рамках которой Вас и отфутболили. Эта проблема заключается в отсутствии возможностей реализации отличнейших алгоритмов регулирования по причине отсутствия резерва по регулированию на реальных объектах. Т.е. на практике получается, что идеальный алгоритм есть, но реализовать его нельзя, потому что возможный канал управления изначально задействован на полный расход и качественно регулировать (к примеру по дифференциальной составляющей ПИД-регулятора) реально бывает нечем. И кому нужен этот Ваш алгоритм, если таких прекрасных алгоритмов вагон и маленькая тележка, а реально пользуются ан масс все тем же древним ПИ-регулятором, который не чувствителен к отсутствию резерва регулирования (т.е. в отсутсвии резерва точно не даст побочных эффектов), не дает статической погрешности и не дергает туды-сюды заслонку на трубопроводе. Более того, Вам абсолютно справедливо указали ту область в которой стоит копать — решение общих или частных задач по созданию устойчивых каскадных и многоканальных САР.

> Вот так и гибнут <новые технологии>. А живи в США, там быстро бы нашел кучу энтузиастов, которые попробовали с этой темы получить массу прелестных зелененьких бумажек, и дело завертелось бы.
Щаз, стали бы буржуи тратится на то, что заведомо не будет работать на реальном объекте.

> Хорошо, вот Вам задача, у Вас на каждом экране системы десятки данных, и они должны обновляться каждую секунду. Как это делается в нормальных системах? Просто раз в секунду идет запрос на данные (или к Базе Данных, или к Драйверам Устройств и т.д.) и данные на экране заменяются. А как это делается в Интернет-технологиях? Каждый раз изготавливается новый HTML и перебрасывается клиенту?
Именно. А Вы хотите заменить терминалы одного «супер-пупер» (с вычислительной мощностью одного писюка) на кучу писюков и сервер? Т.е. пытаетесь навесить на все тот же контроллер еще кучу не столь уж дешевых прибамбасов. Зачем? Чтобы хакеры имели потенциальную возможность влезть? ;)

От	K
К	Вячеслав (23.12.2007 18:14:09)
Дата	23.12.2007 21:54:16

Умерьте свои "понты"

> Извините, но новая <технология моделирования> именно агрегатов
> химических производств (относительно простых объектов) сама по себе
> никому не нужна.

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

> Соответственно, здесь как об инновации, по-уму можно было бы
> говорить о создании нового метода расчета и проектирования

Это совсем другие системы. Вы просто не в теме.

> Извините, но это полная ерунда. Есть три принципиальных подхода к
> расчету контуров САР, которые на современных продвинутых системах
> зачастую реализуются комплексно.

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

> Во втором случае сбор статистики не является проблемой
> моделирования, и в смысле инноваций можно говорить лишь о новых
> методах расчета адаптационных корректировок и новых схемах
> адаптивных регуляторов

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

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

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

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

Если Вы решили погавкать, то возьмите себе кого-нибудь другого для
перегавкивания. Вы же вот ничего не знаете и не понимаете в данной
области, а понтов как у дешевой попс певички. Не нужно мне свои
дешевые понты совать под нос. Речь о регуляторе зашла, когда делал
модель котельной, попытка полностью зарегулировать котельную приводила
к неустойчивости работы у мужиков, у КИП-цев, как раз специалистов по
регуляторам. Так как пришлось все равно моделировать и ПИД-регулятор,
решил его немножко модифицировать, потом позвал мужиков и показал, что
получилось в результате. Все ахнули, была даже идея реализовать и
попробовать на реальном объекте. Но забросил, так как очень много и
серьезно надо разбираться, пришлось бы все остальное отодвинуть в
сторону.

> Вы будите удивлены, но 99,9% действующих алгоритмов регулирования
> могут работать, не то что на калькуляторе, а на старой советской
> базе УСЭППА, а на супер-пупер ЭВМ их реализуют пачками, да еще и
> имея нехилый резерв вычислительной мощности этих супер-пупер класса
> 386 или первого пня.

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

> Эта проблема заключается в отсутствии возможностей реализации
> отличнейших алгоритмов регулирования по причине отсутствия резерва
> по регулированию на реальных объектах. Т.е. на практике получается,
> что идеальный алгоритм есть, но реализовать его нельзя, потому что
> возможный канал управления изначально задействован на полный расход
> и качественно регулировать (к примеру по дифференциальной
> составляющей ПИД-регулятора) реально бывает нечем.

Ну и бред. Ну Вы полностью не в теме. Вы что имели дело с
регулированием только тогда, когда клапан или полностью открыт или
закрыт? Отпад какой-то все эти Ваши <откровения>.

> Щаз, стали бы буржуи тратится на то, что заведомо не будет работать
> на реальном объекте.

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

> Именно. А Вы хотите заменить терминалы одного <супер-пупер> (с
> вычислительной мощностью одного писюка) на кучу писюков и сервер?
> Т.е. пытаетесь навесить на все тот же контроллер еще кучу не столь
> уж дешевых прибамбасов. Зачем? Чтобы хакеры имели потенциальную
> возможность влезть? ;)

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

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

От	Вячеслав
К	K (23.12.2007 21:54:16)
Дата	24.12.2007 17:00:58

Хлебнул клинского и пытаюсь умерять. Но вопросы остаются.

От	K
К	Вячеслав (24.12.2007 17:00:58)
Дата	25.12.2007 08:32:54

Re: Хлебнул клинского...

От	Вячеслав
К	K (25.12.2007 08:32:54)
Дата	26.12.2007 16:47:55

Клинское — чудесный напиток, надо еще глотнуть :)

> ???? У вас ушли старые технологи и операторы, на чем Вы нового хотя бы оператора учить будете? Кто его будет учить? Ему никакие инструкции не помогут. Оператора обучают несколько лет, и модель сегодня единственный выход.
Конечно мы тут в своем относительно благополучном регионе немного того, зажрались. В смысле у нас эта проблема настолько критически не стояла и не стоит. Разумеется и текучка, и общее падение уровня образования молодых наблюдается, но такого чтобы разрушилась преемственность производственной подготовки кадров... С другой стороны вон наш Оргсинтез как умер 15 лет назад, так в том состоянии и прибывает без всяких попыток реанимации. Соответственно у нас начальство смотрит на имитационки как на симпатичные мулечки и не более того. Хотя лет 10 назад по поводу них был ажиотаж, попил бабла и все такое пр. Теперь заглохло и кадры продолжают готовить по старинке, при этом грамотным старикам платят очень даже не плохо, заметно больше чем большинству офисной мелочи.

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

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

>> серьезная модель по которой оптимизируют управляющие воздействия - это куча дифуров.

> Чтобы <оптимизировать> модели не нужны вообще, там все автоматически строится.
Автоматически — не значит без моделей.
> Собирается статистика по параметрам, строится многовекторное поле и поехали кататься, искать заданный оптимум целевой функции.
Это все верно. Но просто Вы вроде писали о нехватки вычислительной мощности управляющих ЭВМ, соответственно я так понял, что Вы и имели ввиду те редкие случаи, когда в реальном времени используют сложные алгоритмы оптимизации. А иначе не понятно откуда у вас берется вычислительная перегруженность контроллеров? Или Вы все это писали про отдел ИТ (вычислительный центр), который непосредственно с производственными АСУ не связан?

> Одна беда - никто не знает настоящей целевой функции. Как-то мой приятель изрек - абсолютного оптимума нет, и он совершенно прав.
Это да.

>> А вот не серьезные (т.е. вспомогательные) модели типа всяких имитационных обучалок

> Эту несерьезную обучалку годы делает группа технологов и программистов. Вы просто не способны представить себе сложность данного объекта.
Способен. Я участвовал в таком проекте. Вылилось все в большой пшик. В смысле модель есть но она нафиг никому не нужна. Т.к. все равно есть грамотные старички, модель по сложности приближается к ХТС, да плюс ее надо постоянно подстраивать обслуживать — т.е. держать спецов уже не по железу, а по модели. Короче нормально ею пользоваться может только достаточно грамотный специалист, который и без нее уже с железом справляется.

>> Угу, а главное гораздо дешевле учить по книгам и путем стажировки у дяди Васи.
> И поэтому на Западе выкладывают миллионы долларов? Даже подготовить пилота применяя обучалку стоит дешевле в разы. А оператора опасного химического агрегата - тем более.
Ну, у запада совсем другие ресурсы и другие проблемы. Они вкладываются в имитационки вовсе не с целью решения проблемы кадрового голода.

>> Извините, но как вы в этом отчете учтете, к примеру, износ катализатора или изменение температуры ОС? В классических мат моделях можно хотя бы задать диапазон изменений, т.е. они позволяют проводить анализ.

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

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

> Да хоть и тысячи, считают то один хрен максимум двухконтурные САР

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

>> И? Если технологическая связь есть, то бишь куча труб проложена, то уж и кусок кабеля вместе с ними лежит.

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

> Не знаю, что у Вас за требования, но одно из главных всегда - беречь
исполнительный механизм (не дергать лишний раз), так как большинство
проблем и самая не надежная часть обычно и есть исполнительный
механизм.
ну так и я о том.

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

> Элементарно, Ватсон, у всех старых контроллеров ограниченное число контуров управления. Угадайте, почему?
Что ограниченно понятно, чтобы не справлялся — не бывает, точнее только если загрузить его «чужими» функциями.

>> А с этими процентами никакой продвинутый бумажный алгоритм не работает, а работает ПИ закон, хотя и он работает хуже чем на бумаге.

> Все верно, часто оставляют ПИ, так как Д может разнести систему (у меня и цель изначальная была, чтобы Д мне не мешал, модель не делал не устойчивой). Не знаю, чем Вы там регулируете, но любые задвижки стоят обычно на процентах 60, иначе с них при регулировании тогда действительно толку мало (это связано с их конструкцией).
Вот тут извиняйте, на 60% это только на тех объектах где штатно положен переменный статический режим (котельные, всяческие подогревы, подготовка сырья и т.п.). А в больших агрегатах к таковым относится как правило вспомогательное оборудование, которое обычно совсем не требовательно к качеству управления.

>> А там <вовне> тоже без контроллера обходятся? ;)

> Например, стоит устройство, навороченный счетчик чего-то там. К нему интерфейс, блок питания и сотик. Оператор может зайти по Интернету и скачать с устройства нужную информацию (текущие значения, архивы, коммерческие значения - счетчик на пломбе). Это реальная система. Но тоже можно делать и автоматически, а оператор сможет управлять распределенными устройствами. И это реальная система.
К этому претензий нет.

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

> Попроще там не возьмешь, зато можно взять другую архитектуру и на ней значительно сэкономить.
О-хо-хо. Признаю, наехал я на Вас зря, тут действительно есть место инновациям, только что в рамках принципа «голь на выдумку...».

От	Администрация (Кудинoв Игорь)
К	K (23.12.2007 21:54:16)
Дата	23.12.2007 22:43:12

Замечание за переход на личности.

Сбавляйте обороты.

От	Михайлов А.
К	K (23.12.2007 12:24:34)
Дата	23.12.2007 16:37:45

Продолжаете повторять клевету?

>Теперь понятен процесс создания <новых технологий>? А Михайлову
>кажется, что технология это взял и нарисовал утром, а вечером
>опубликовал. Получение <новой технологии> это серьезный процесс, и
>кто-то его должен оплачивать, так как должны работать люди, а им
>кушать надо.

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

>А живи в США, там быстро бы нашел кучу
>энтузиастов, которые попробовали с этой темы получить массу прелестных
>зелененьких бумажек, и дело завертелось бы.

Так они энтузиасты чего — технологии или зеленых бумажек? И каким же это чудом энтузиасты зеленых бумажек избавят вас от изучения проблемной области? Кстати, почему Вы таки не свалили из «этой стране» которая заставляет изобретателей «умолять на коленях»?

>Никакие не
>инопланетяне и не агенты сил зла уничтожили СССР, а Михайловы, которые
>создавали <правильный социализм>, и Кара-Мурзы, которые готовы были
>ради интересов своего социального строя оправдать что угодно, хоть
>полицейское государство, хоть коррупцию.

И церковь то же я развалил при попустительстве Кара-Мурзы?:) Так сказать «агенты инопланетных сил зла».:) Нет, это просто изумляет — оказывается в проблемах Карамышева виноваты Михайлов и Кара-Мурза и вообще все кроме самого Карамышева..

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

Проблема в том что у вас со всеми получается разговор ни о чем.