Не фигня, г. Mars. На моем жизненном пути встречались истинные мастера. Пример. Фирма, занимается, скажем общо, автоматизацией пищевой промышленности. Демонстрационный зал. С десяток мониторов, на которых картинки будущего автоматизированного производства (SCADA то есть). Тонкость - чем дороже SCADA, чем лучше и больше монитор. Ну и красивей картинки, анимация - причем ФУНКЦИОНАЛ ОДИНАКОВ!!!!
Естественно, Зак падал на последний вариант. Тут его добивали - диспетчеризация(сиречь- SCADA) - ДАРОМ. Все, попался. Далее, все по сценарию- договор, смета и куча допработ. Замечу, оборудование - мировой бренд (топ-модели). Дилерские скидки ПОЛНОСТЬЮ окупали лицензию (runtime) на SCADA. И все вроде бы честно - хотите красиво, берите вот это. Только в редком случае люди на мишуру и бесплатный сыр не падали (когда специалисты работали, а не "откатные" манагеры). За все платили (и за SCADA тоже) - но цена была раз в 5 меньше. А красивые картинки дорисовывались потом (спецы все-таки).
Меня метода впечатлила, уже сам собирался внедрить ( вроде все без обмана, а маленькие хитрости простительны).
Но тут с директором произошла неприятность (даже в газетах и по ТВ сообщали). Все-таки, на всякую хитрую ... нашелся ....

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

Первые три пункта - несомненно, но и поддержка одной не стандартной сети это не признак хорошей SCADA-системы на мой взгляд.

З.Ы. С возвращением:)

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

Бизнес-практика такова, что дополнительные протоколы идут в качестве бонусов... отдельных денег за них платить не надо... И приличная СКАДА обязана поддерживать общепринятые, распространенные протоколы, типа модбаса рту... фиг бы с модбасом плюс и другими недавними новинками...
А так что получается - поставив Заку СКАДу с овенбасом я обрекаю его на:
1. Использование только железа ОВЕН
2. При несоблюдении п.1 - или установка ышо одной СКАДы, или выбрасывание уже купленной и установки многопротокольной...

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

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


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

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

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

И примеры тому - Овеновские ОПМ. Это и не СКАДы вовсе... Это - всего лишь часть ПТК.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

Сказали Вы.


Сказал я.


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

не сочтите за рекламу... тем более что я там не работаю больше. просто действительно техника неплохая. я про 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 можете дать?

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

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

Далеко от Овна ушли. Что касается единого протокола, то представьте, что Овен отладил свой ПЛК, написав удобный софт и вы получаете платформу с одним протоколом вообще - только ТСP/IP. И трудно сказать, что он с чем то не справляется.

TCP/IP (v4, но и v6.0) не справляется с двумя ОСНОВНЫМИ вещами - критична к монтажу (перезапросы удолбают), и нагрузкой на ЦП (DMA не всегда приемлем, а иначе "сажается" процессор. Размер пакета тоже проблематичен - при перезапросах малая длина пакета означает "кабздец",
а большая - "порожняк", причем засоряющий сеть. Пока самым реальным протоколом остается клон 485.

Ну про качество монтажа не стоит забывать ни в чем. А что касается загрузки процессора, то ИМХО в АРМ9 эта проблема не стоит, учитывая его производительность. Порожняк не так страшен при таких скоростях, как 10 МБ/сек, не говоря уже о 100 МБ/сек. Самое главное преимущество такого решения в том, что устройство не слышит весь мусор сети, т.к. мультиплексоры отправляют устройству только те пакеты, которые ему адресованы. Поэтому при глюках трудно загадить сеть. Представьте себе, что в сети глюкануло устройство, и перестало слушать сеть, и вещает всякий хлам в сети. Для общей шины 485 это конец обмену, а в изернете это далее свича не пойдет, отвалится только это устройство. Тоже самое происходит при обрыве или банальном неконтакте, - если в 485 вы теряете половину сети, то в изернете лишь одно устройство. При большом количестве контроллеров это очень важно.

При "вылете " концентратора "вылетает" сегмент - та же поблема Никто не спорит о достоинствах Ethernet - но он требует скоростных контролеров. А куда девать существующие? Я уже писал ранее - хорошо бы ориентироваться на перспективу при разработке. Тогда - да, есть смысл ориентироваться на Ethernet (не обязательно, но возможно TCP/IP). Согласен, клоны 485 отмирают, но как быть с ПЧ - основным продуктом, оснащенным этими клонами? Управлять ПЧ по сухим контактам и аналоговым входам - это позавчерашний день. Возможно, производители этих устройств будут оснащать их Ethernet как основным портом для управления. Но для этого он, Ethernet, должен стать доминирующим протоколом автоматизации, в том числе и промышленной . Этот процесс идет - но не так быстро, как хотелось бы.

А в чем разница. У Вашего контроллера, такая же история... А какое громкое название Протокол Ко***р

По-моему такие изобретения могут быть только у нас в России, Европа уже пережила эти НОУ ХАУ и применяют стандартный Ethernet c BACNet'ом.
Вот вендоры которые применят BACNet

Ethernet не протокол а всего-лишь физическая среда. Для нужд промышленности у этой физической среды куча недостатков - самый основной - длина сегмента ~100 м. Оптоволокно не решает этих проблем так как дорого само по себе (при использовании конвертеров), в прокладке требует осторожность, а в монтаже - специального инструмента.

Согласен, как раз для решения этой проблемы на контроллерах применяют интерфейс RS485

Ладно, будем ждать новостей от Rockwell Automation- все-таки отцов-основателей Ethernet/IP (IP- Industrial Protocol ).

Я уже пытался донести это простую мысль до г-на Kass в соседней ветке, увы понимания не достиг

В каком месте они отцы-основатели???


История Ethernet

Технология Ethernet была разработана вместе со многими первыми проектами корпорации Xerox PARC. Общепринято, что Ethernet был изобретён 22 мая 1973 года, когда Роберт Меткалф (Robert Metcalfe) составил докладную записку для главы PARC о потенциале технологии Ethernet. Но законное право на технологию Меткалф получил через несколько лет. В 1976 году он и его ассистент Дэвид Боггс (David Boggs) издали брошюру под названием «Ethernet: Distributed Packet-Switching For Local Computer Networks»[1].

Меткалф ушёл из Xerox в 1979 году и основал компанию 3Com для продвижения компьютеров и локальных вычислительных сетей (ЛВС). Ему удалось убедить DEC, Intel и Xerox работать совместно и разработать стандарт Ethernet (DIX). Впервые этот стандарт был опубликован 30 сентября 1980 года. Он начал соперничество с двумя крупными запатентованными технологиями token ring и ARCNET, которые вскоре были похоронены под накатывающимися волнами продукции Ethernet. В процессе борьбы 3Com стала основной компанией в этой отрасли.

ru.wikipedia.org

И причем здесь IP и Industrial Protocol, похоже, Rockwell разработали Industrial Protocol для себя, что-то большого распространения не заметно... В отличии от BACNet.