ОВЕН ПЛК достойный аналог Siemens, TAC и т.п., поддержим отчественного произвоодителя Опции

[Гость_Игорь Борисов_*]

Я несколько о другом говорю. СКАДА под все протоколы зачем нужна? Для скрещивания ужа с ежом. Если кто то когда то и вляпался, то теперь они просто сменят производителя и все. Но зачем менять одного на десяток других??? Обычно проводится анализ, выбирается лидер не только по соотношению цена/качество, но и по уровню поддержки, ну и если госсектор, то и по уровню откатов, разумеется. Этот лидер и выбирается. Зачем мне надо выбирать нескольо разных производителей??? Ради танцев с бубном в перспективе?

В идеале - согласен. К сожалению - практика далека от идеала... И владелец мультипротокольной скады освобожден от гемороя выбора оборудования... хотя бы по одному пункту - по протоколу. А это уже дает ему бОльшую свободу выбора.

[Гость_Игорь Борисов_*]

Я несколько о другом говорю. СКАДА под все протоколы зачем нужна? Для скрещивания ужа с ежом. Если кто то когда то и вляпался, то теперь они просто сменят производителя и все. Но зачем менять одного на десяток других??? Обычно проводится анализ, выбирается лидер не только по соотношению цена/качество, но и по уровню поддержки, ну и если госсектор, то и по уровню откатов, разумеется. Этот лидер и выбирается. Зачем мне надо выбирать нескольо разных производителей??? Ради танцев с бубном в перспективе?

В идеале - согласен. К сожалению - практика далека от идеала... И владелец мультипротокольной скады освобожден от гемороя выбора оборудования... хотя бы по одному пункту - по протоколу. А это уже дает ему бОльшую свободу выбора.

[AlexG]

1. Разные протоколы могут быть использованы в разных системах. Другой нижний уровень еще не повод каждый раз использовать новую скаду. Освоение новой скады требует некоторых затрат, времени как минимум.
2. Еще не появился производитель выпускающий абсолютно все оборудование которое может понадобится в каждом конкретном случае. Можно конечно попробовать подобрать оборудование просто с одинаковым протоколом, но для этого это протокол должен быть стандартным
3. Есть еще вариант когда драйвера идут не в нагрузку к скаде "бесплатно", а оплачиваются отдельно.

[Kass]

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

Зачем вообще нужен какой то протокол? Чем старые добрые 0-10В, 4-20мА и дискреты не устраивают?

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

[Гость_a11oleg_*]

1. Разные протоколы могут быть использованы в разных системах. Другой нижний уровень еще не повод каждый раз использовать новую скаду. Освоение новой скады требует некоторых затрат, времени как минимум.
2. Еще не появился производитель выпускающий абсолютно все оборудование которое может понадобится в каждом конкретном случае. Можно конечно попробовать подобрать оборудование просто с одинаковым протоколом, но для этого это протокол должен быть стандартным
3. Есть еще вариант когда драйвера идут не в нагрузку к скаде "бесплатно", а оплачиваются отдельно.

1. Мне дико думать, что сейчас могут продаваться Скады под винду без OPC
2. Вот вот и сейчас даже самые безнадежные монополисты как правило выпускают драйвера OPC
3. Это - самый оптимальный вариант.
По моим личным тестам правильно написанный драйвер OPC может собирать с полевых шин очень большое количество тегов в секунду без притормаживания. Проблема так же идет и правильном написании скады. Например ТМ5 очень неудачно работал с OPC, существенно лучше стал TM6. Имхо наилучшая скада на OPC Genesis32.

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

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

В данный момент у меня SCADA работет по двум стандартным протоколам(PROFIBUS - горизонтальная сеть и PROFINET- вертикальная сеть). Я понимаю что я оплачиваю несомненно, а именно оплачиваю я гибкость и расширяемость системы.

[Kass]

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

Да не это вы оплачиваете. Я вам на одном протоколе сделаю сеть в десятки раз гибче и больше. Вы просто пытаетесь оправдать скрещивание оборудования.

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

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

[Kass]

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

Я более чем уверен, что в вашем компе установлен только TCP/IP. Что вам мешает использовать остальные протоколы? Попробуйте задействовать netbios и IPX/SPX. Если вам покажется, что ваша сеть стала лучше и гибче, то вы правы.

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

Я более чем уверен, что в вашем компе установлен только TCP/IP. Что вам мешает использовать остальные протоколы? Попробуйте задействовать netbios и IPX/SPX. Если вам покажется, что ваша сеть стала лучше и гибче, то вы правы.

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

[Kass]

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

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

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

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

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

[Kass]

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

Приведите пример сети на разных протоколах. Очень интересно.
СЕрьезные - это сети операторов, крупных объектов... У меня сейчас в работе СКС офисного здания 25 000 кв. м. с структуре газпрома. Как в СКС всунуть IPX? Мультиплексоры его просто не поддерживают. А как устройства IPX будут принимать оповещения маршрутизаторов???

Да поймите вы простую вещь. Скрещивание всегда ведет к урезанию возможностей обеих скрещиваемых сетей. Что касается протоколов, то все они имеют несовместимые возможности, от которых приходится отказываться при скрещивании. Т.е. при скрещивании имеет место каой то компромис, который урезает гибкость и возможности в ущерб совместимости оборудования. Например как вы включите в доменную структуру сети и AD в частности устройство IPX? А как оно будет общаться в сети с динамической маршрутизацией? Как оно будет слушать маршрутизаторы? Значит для скрещивания сеть должна быть примитивно одноранговой со статической маршрутизацией. При этом теряется вся гибкость сети IP.

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

Сеть на разных протокалах: 4х этажное здание энергоблока, на каждом этаже установлен мастер-контроллер с сетью PROFIBUS DP и PROFINET. По PROFIBUS к контроллеру подключаются ПЧ и УПП насосных групп и устройства распределенного ввода вывода. По PROFINET мастер-контроллеры соединяются с АРМ оператора. К этому энергоблоку подключаются 11 тепловых пунктов ранеее объединенных по тому же профибасу, к тому же энергоблоку присоединяется контроллеры вентиляции двух корпусов (ксенты).
Один АРМ и три сети.

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

[Kass]

Сеть на разных протокалах: 4х этажное здание энергоблока, на каждом этаже установлен мастер-контроллер с сетью PROFIBUS DP и PROFINET.

Да нет, давайте рассматривать сети компьютерные в продолжение, как понятные всем участникам беседы. Для рассмотрения вашего примера надо вникать в ТЗ задачи, что отнимет много времени. Приведите пример компьютерной сети или СКС с двумя протоколами. Я последнюю такую делал году эдак в 1995-м, именно из-за необходимости скрещивать.

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

Зачем мне флудить про СКС. Разговор был о SCADA-системах. Вы просили примера- вот Вам пример.

[Lex]

Действительно, не надо СКС....
А пример Вам пожалуйста...
Офисное здание:
- ИТП делала организация А с применением контроллеров Dan..
- Вентиляцию делала организация В с применением контроллеров ТА..
- Холодилки делала организация С с применением контроллеров Са..
- Электросчетчики делала организация Д с применением счетчиков Ал..
Заказчик почесал репу и подумал - хочу диспетчеризацию всего этого.
Причем не на уровне дискретов, а чтоб температуры видеть, уставки менять, наработку часов смотреть и пр,
и при этом без доп. полевых устройств.
Dan.. можно оборудовать Lon-картой, ТА.. тоже,
Са.. можно оборудовать Modbus-картой,
Ал.. вообще имеет закрытый проток и свою диспетчерскую, правда с ОРС.

И как тут обойтись одним протоколом Кон... ?

Сообщение отредактировал Lex - 30.8.2007, 14:42

[Гость_Игорь Борисов_*]

Действительно, не надо СКС....
А пример Вам пожалуйста...
И как тут обойтись одним протоколом Кон... ?

Ну какой же Вы, Lex, непонятливый... Сносим нахрен контроллеры Dan, Ca, TA, и счетчики Ал... Ставим везде Кон... и дарим Заку комп с монитором... и подключением к инету... Зак счастливо лазает по порносайтам и смотрит картинки на сайте Кон....

Сообщение отредактировал Игорь Борисов - 30.8.2007, 15:40

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

Ну какой же Вы, Lex, непонятливый... Сносим нахрен контроллеры Dan, Ca, TA, и счетчики Ал... Ставим везде Кон... и дарим Заку комп с монитором... и подключением к инету... Зак счастливо лазает по порносайтам и смотрит картинки на сайте Кон....

Вот и мне показалось, что речь идет о подобной "интеграции".

[Гость_Игорь Борисов_*]

Вот и мне показалось, что речь идет о подобной "интеграции".

Скока по объектам мотаюсь - на каждом свои "тараканы"... Вот недавно... Пищевое предприятие... Требование к шкафу - IP68! После долгих переговоров убалтываем на IP66, так до конца и не поняв в чем проблемма... Просветили местные рабочие... Технологическая линия моется водой под давлением 20 бар... ну, вроде и фиг с ним, шкаф от линии далеко, его мыть так по технологии не надо... просто протирать... Ага... Фигушки! Местный мойщик испытывает наслаждение, если ему удается залить эл.оборудование... и _специально_ пытается это сделать! Ловили с поличным, все равно все отрицает... По непонятным для нас причинам - уволить его невозможно, перевести на другую работу невозможно... вот и воюют кто кого... А шкафы приходится ставить IP66.

[Взводатор]

Игорь, распишите чуть подробней для несведущих - и на анекдот.ру

[Kass]

Зачем мне флудить про СКС. Разговор был о SCADA-системах. Вы просили примера- вот Вам пример.

Хорошо, давайте так, однако будет менее наглядно, т.к. компьютерные сети значительно более развиты, там изначально была масса протоколов, но все умерли оставив один. Если бы в вашем случае мастер-контроллеры поддерживали Ethernet и IP, то вам бы не пришлось строить сеть на профинет. Вы бы просто использовали для связи существующую компьютерную сеть или СКС.

[Kass]

Действительно, не надо СКС....
А пример Вам пожалуйста...
Офисное здание:
...

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

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

Хорошо, давайте так, однако будет менее наглядно, т.к. компьютерные сети значительно более развиты, там изначально была масса протоколов, но все умерли оставив один. Если бы в вашем случае мастер-контроллеры поддерживали Ethernet и IP, то вам бы не пришлось строить сеть на профинет. Вы бы просто использовали для связи существующую компьютерную сеть или СКС.

Какой один простите? Один стек протоколов, а протоколов в TCP\IP не мало, уверяю Вас (TCP и IP это уже 2 протокола ).
Мои контроллеры поддерживают изернет. В котельной, вот незадача, СКС нету вовсе.

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

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

Сообщение отредактировал Сергей Долганов - 31.8.2007, 9:31

[Kass]

Какой один простите?

Один протокол, используемый в АСУ. Сети контроллеров достаточно строить на одном протоколе. Для диспетчеризации оптимально использовать протокол, который использует сам АРМ. Если вы используете РС, который поддерживает TCP/IP, то вот вам и протокол для диспетчеризации, сбора данных и управления. Это если обойтись без мичуринства, а строить или реконструировать объекты как положено, централизовано, с единым архитектором и единым генподрядчиком.

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

Вобщем бесполезно Вам что-то доказывать Удаляюсь.

[Kass]

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

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

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

Сказали Вы.

Какой один простите?

Сказал я.

Один протокол, используемый в АСУ.

Ответили мне Вы.
Не кажется Вам это несколько странной логикой?

[taranov]

не сочтите за рекламу... тем более что я там не работаю больше. просто действительно техника неплохая. я про Xenta700. Если вы раньше ставили Xenta 911 или 511, то для перехода на X700 вам новых знаний и умений не надо. это новые lon контроллеры с Ethernet/ есть варианты с web и без него - под вашу задачу. до 20 модулей вешается на каждый. по цене при этом выигрывает у решения с X911/X511. новая аппаратная платформа, больше памяти. 16МБ на борту по моему. в общем налицо ориентация на ethernet с tcp|ip в качестве backbone, что имхо, очень правильно. При этом те-же инструменты разработчика, с некоторыми приятными добавлениями типа online menta на html странице, можно в один контролллер грузить несколько программ, так что работу программиста теперь можно поручить даже умственно отсталому - накидать в контроллер интересующие вас блоки menta... ну а стойкость операционки domino ( нет, не lotus notes, он тут не при чем :-) доказана..
Реплика qqq_qqq по поводу того, что " мне не нравится Vista, а я пришел из промавтоматики, а тут нагажено...." - ну а мне не нравится например в троллейбусе ездить... ну и что... это троллейбус никак не характеризует... а профессиональную оценку Vista можете дать?

Сообщение отредактировал taranov - 31.8.2007, 12:20

[Kass]

Сказали Вы.
Сказал я.
Ответили мне Вы.
Не кажется Вам это несколько странной логикой?

В таком случае я действительно потерял нить беседы. В первом моем ответе имелся в виду TCP/IP. Остальные как то тихонько умерли.

[Гость_ggg__ggg_*]

Г. Таранов - Вы активный лоббист ТАС и это приветствуется. ТАС предлагает продукты, мы их используем (материмся, но делаем..). Насчет "умственно отсталых" - это Вы крутовато, но Вам виднее .
Насчет единого протокола - было бы хорошо, если бы существовал такой протокол, который был бы весьма некритичен к монтажу среды (LON),
высокоскоростной (Industial Ethernet), с хорошо отработанным стеком и рассчитанный на передачу пакетов очень разной длины, помехозащищенный и т.д. Практика показывает - такого не придумали (надеюсь, пока). А так - приходится сопрягать в одной системе несколько или ставить кучу шлюзов (дорого).