Начинаем работать на новом объекте в котором планируется довольно большое количество оборудования для автоматизации. Основные контроллеры для системы - Pixel и SMH2Gi. На этом объекте планируется система диспетчеризации. Количество контроллеров запросто перевалит за 200-300 штук. Кроме сегнетиков еще будут другое оборудование подключенное по модбасу и по бакнету. Сейчас вотвыбираю SCADA -систему для диспетчерского ПК. Наши недорогие решения (TM6 и MasterSCADA) я "отмел" сразу... У ТМ6 проблемы с "перевариванием" графики, мы делали объект раз в 5 меньше, и она с ним кое-как справляется. Мастерскада тоже не отличается стабильностью, а объект серьезный, перезагружать комп каждый день - не вариант. Т.е. нужно надежную и мощную систему. Рассматриваю сейчас разные варинты (Citect, Genesis32, InTouch). Подскажите варинты и их достоинства и недостатки...

Добрый день.

Если бы не MODBUS как основной протокол для Segnetics, то обратил бы ваше внимание на софт Delta Controls. Описание прилагается.
Основных минусов - два:
1) импортозамещение;
2) наш основной протокол - BACnet, поэтому MODBUS надо будет шлюзовать - т.е. доп оборудование...

ORCAview - АРМ на WIndows: одно рабочее место - одна лицензия. enteliWEB - web-портал в систему АСУ здания.
В оба софта входят модули конфигурирования и программирования наших контроллеров. Может входить граф редактор.
ORCAview не имеет ограничения по тегам, enteliWEB - имеет на входы/выходы.

А что Ваша скада не умеет работать с OPC-серверами?

OPC <-> BACnet от Kepware или Simetrics. Напрямую - нет. Мы же производим комплекс: и контроллеры и софт на BACnet, а не одну SCADA для любых контроллерных зоопарков
http://91.195.171.91/enteliweb - наш офис в демо режиме. demo / demo

Просто OPC это стаднарт для СКАДА-систем. И бОльшая часть таких систем умеет с интерфейсом OPC работать... Если Ваша СКАДА не умеет - то я от нее откажусь.

У нас не SCADA в общепринятом смысле, которая поддерживает много-много разных протоколов. Для построения АСУ здания BACnet обеспечивает все необходимые функции автоматизации, диспетчеризации и энергосбережения. Наше ПО позволяет строить системы диспетчеризации на BACnet как основном протоколе и шлюзовать туда все остальное. OPC это не протокол, это описание интерфейса обмена данными, придуманный Биллом Гейтсом (не лично, конечно ) OLE for Process Control. А сертифицированное BACnet оборудование и ПО производия более 800 компаний в мире - выбор есть

SCADA в общепринятом смысле не поддерживает много-много разных протоколов. Она поддерживает стандрат интрефейса OPC, а уже через него можно подключить много-много протоколов. Есть скады, которые содержат встроенные драйверы, но они также поддерживают и OPC.
В принципе мне все понятно. Мне нужна стандартная скада, которая умеет работать с OPC. Другие варианты я не рассматриваю.

TAC Vista. И графика и работа с OPC и модуль генератора отчетов для Excel

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

А можно с этого момента поподробнее? Как то не сталкивался до сих пор с нестабильностью Мастерскада. При каких условиях она возникает?

Был не так давно на объекте. Там около 30-40 контроллеров Pixel c модулями Ethernet. Вентиляция, тепловые узлы, управление освещением. Ничего сверхестественного. Диспетчеризация реализована на MasterScada. Скада виснет 1-2 раза в неделю. Порой теряет связь с одинм и тем же контроллером и находит её после 2-3 перезагрузок. Знаю программиста, который делал данную систему - с руками у него вроде как все в порядке. Еще одни знакомые делают подобную систему в другом здании, также на MasterSCADA, говорят что бывают проблемы. Когда я им сказал ориентировочное количество сигналов (20-30 тысяч) - сказали что лучше взять что по серьезнее.

Виснет - скада, а связь с контроллером может терять кто-другой, например его ОРС-сервер

Кстати да, у нас были проблемы с Lectus OPC и некоторыми другими серверами при на порядок меньшем количестве сигналов. Не стоит сразу во всем винить скаду, стоит разобраться подробнее.

Посмотрите InduSoft. Сами используем её уже давно для диспетчеризации котельных, которые находятся у нас на эксплуатации.

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

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

Как вам правильно сказали "виснет" и "теряет связь" - это не одно и тоже. За связь с контроллерами отвечает ОРС сервер. Если использовать Lectus, то такие проблемы могут быть.
Мы внедряли проект на Pixel-и, Modbus Universal, MasterSCADA + MasterSCADA-Vent на 350 вентустановок. Все работает стабильно.


У нас есть примеры внедрений на 100 тысяч тегов.

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

Также посмотрите на Reliance, используем уже шестой год, работает стабильно и с тысячами тегов. Умеет описи, можо купить драйверы на бакнет и модбас (драйвер бакнет стоит заметно дешевле матриконовского OPC-сервера для бакнет). Среда исполнения поддерживает на 100% русский интерфейс, но среда разработки - только английский и чешский, Web-клиент - аналогично, все системные тексты на одном из этих языков на выбор.

В обоих системах в случае с сегнетиксом будет некоторый геморрой, связанный с тем, что переменные на чтение/запись с сохранением в памяти контроллера имеют свойство иметь разые адреса на чтение и на запись, что приведёт к необходимости задания экшна на каждый такой тег в Reliance или использование Genie с двумя тегами на уставку в Citect (хотя можно и с одним, если исхитриться с именованием тегов в описи).


Уже давно ведь есть платформо-независимый OPC UA, правда я не встречал под него много скад и серверов. Из скад недавно видел что есть такая Ignition, но она при этом не умеет OPC DA и построение у неё достаточно нетрадиционное, а ещё вряд ли у нас где-то продаётся. А из серверов - матриконовский универсальный wrapper DA-UA.

Не только:
http://insat.ru/products/?category=1271
Скоро перенесем UA и в Modbus Universal.
MasterSCADA в скором времени также будет поддерживать UA.
Есть также туннель базирующийся на UA:
http://insat.ru/products/?category=1602

Какой там OPC сервер я не смотрел. Вполне может быть такое что виснет он. Лично я с мастерскадой не работал, НО... вот что меня "напрягает".
1. Система будет большая и распределенная. Такие системы реализуют не так уж и часто.
2. Работал довльно много на TraceMode 6. Делал системы в 200-500 каналов - они работали просто отлично. Не пользовался никакими OPC-серверами и все просто "летало". Но вот сделали систему на 5000 переменных, реализовали периодическую запись данных во внешнюю СУБД, архивируем большое количетсво переменых и строим графики.... и вот когда мы "в тупую" как обычно все это реализовали - скада начала виснуть один раз в 1-2 часа. Виснуть не ОРС а именно сама скада. Техподдержка ТМ6 сказала мол ничего не знаем, делать не будем разбирайтесь сами. Мол у вас там может винда виснет может еще какая халера... по логу было видно что постоянно отваливается связь с Pixel-ями по Эзернету и снова восстанавливается. РАзговры с Адастрой на тему того, что было бы неплохо работу с модбасом в этом направлени улучшить ничего не дали. Они в итоге сказали мол делайте через OPC сервер. В итоге все данные по модбасу мы перекинули в OPC, поигрались с приоритетами программ и периодичностью выполнения и это разгрузило саму скаду - она виснуть перестала. Но мы на это убили столько времени, столько нервов себе попортили, что опять ввязываться в такую авантюру с отечественным разработчиком я не хочу. Естетсвенно если будут проблемы с "буржуйской" скадой - там ответ будет тот же "У нас все работает - разбирайтесь со своим софтом", да вот только думаю, что с приличной скадой подобных проблем будет вылазить меньше.



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

Расскажите по подробнее.
На 100 тысяч тегов или IO каналов? И если IO - то как это было реализовано?
Ну и опять же - это все слова.

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

Посмотрите на ОИК диспетчер (Aris scada), работает стабильно с 20к тегами с ТУ на протяжении 7 лет, проблем небыло

Несколько странная логика. Дальше то вы все пишите про TraceMode.


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

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

Только слова потому, что никто (а особенно менеджеры) не будут писать о "больных" сторонах реализованных проектов.

Дайте описание большого проекта на 100к тегов...
Еще тут ключевое "внедренный нашим инженерным отделом". При обнаружении глюков, зная досконально свою систему можно сделать "заплатки" и подогнать его под конкретный проект, и добиться тем самым нужного результата. При этом, если проблемы возникнут у рядового пользователя то тут начнется "переустановите Windows, вдруг поможет", "Поставьте 16 Гб оперативной памяти вместо 8 Гб", "Замените видеокарту (а в моем случае этого нельзя было сделать)", "мы не знаем в чем ваша проблема тестируйте, пробуйте у нас все работает это ваши проблемы" и т.д..


Потому что эти системы TM6 и MasterSCADA "одного поля ягоды". Мастерскада даже дешевле стоит. Отчего бы?
PS А еще мне не нравится лицензирование в мастерскаде... слишком все запутанно.

PcVue
Имеет встроенный OPC-сервер с поддержкой кучи протоколов.
Также, можно подключаться к стороннему OPC-серверу.

Хотя, последнее время меня одолевают сомнения в вопросе целесообразности интеграции OPC-сервера со скадой.

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


С чего бы?
Это проект сделан на шаблонном проекте MasterSCADA-Vent, который вместе с конфигурацией OPC и документацией, находится у нас на сайте и его может использовать любой пользователь.


Почему? Разные компании, разные технологии, разные подходы.
Если по цене, то тем более странное рассуждение.


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

Так опишите "техническую" сторону проект на 100к тегов. Откуда считываются данные, что с ними далее делают... Как все это отображатеся, сколько экранов в итоге вышло, сколько переменных архивируются и как архивируются...


Выше стоимость продукта - больше денег можно потратить на разработку и доработку (нанять грамотных программистов и т.д. и т.п. Логика такая...
PS Ну и боюсь наступить на грабли того, что и с ТМ6 - скада может просто "не потянуть" такой объем данных с такими функциями.

К сожалению, у меня подробной информации по этому проекту нет - нужно узнавать у менеджеров.
Могу выслать описание к проекту на 300 вентустановок (там точек около 10 тысяч). Могу поискать проект на 40 тысяч переменных - опрос большого количества счетчиков по OPC HDA. Напишите на support.


Эта логика не всегда справедлива.


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

У меня тоже были проблемы с Мастер Скадой. Потом я их решил - как мне показалось, что ОРС сервер немного тупил при опросе электросчётчиков. Но потом я нашёл проблему в usb-свистке и самой линии, и уже год всё работает (целое здание в комплекте) без единой проблемы. Правда, до греха не довожу, раз в месяц приезжаю, перезагружаю систему. Сам я туповат в языках высокого уровня, но смог написать драйвер к водосчётчикам на костылях из примеров. Конечно, надо сидеть заниматься в любом случае. Это всё к топикстартеру.
Сейчас у меня стоит выбор на полностью завод, и вот это вопросец непростой. Надо будет связать бухгалтерию с установками, да с ПЛК разных производителей от Simatic до Mitsubishi и ещё и MES впрягается с локальной сетью. Есть там и Сегнетикс, и что-то моё, то ли ТАС, то ли Phoenix...

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


Вы делали на скриптах Modbus Universal MasterOPC?

У меня на ТМ6 12 зданий, связаны между собой оптоволокном. Сейчас то все работает, но вот оптимизацией пришлось очень плотно позаниматься. И самое неприятное - что мы на это времени не выделяли. Т.е. у нас были до этого объекты меньшего размера, и там было все отлично. Поэтому мы рассчитывали вытащить данные в систему и сдать, а месяца два-три на оптимизацию всего этого хозяйства в сроки не закладывали. И вот когда система стала вылетать а у нас через неделю комиссия для сдачи объекта, так как то совсем не весело стало. В итоге, когда мы сдавали свою работу комиссии, то про себя только о том и думали что не дай бог сейчас при ней (комиссии) у нас зависнет скада. Однако "пронесло", и после сдачи эксплуатация еще месяца 3 решала как будет работать с системой, набирала операторов и т.д.... За это время мы провели оптимизацию. А одно здание, без проблем это не показатель.

Думаете скада за надцать килобаксов Вам сама всё оптимизирует?

Рассчитываю на то, что у мощной скады обкатанной на большом количестве объктов не будет таких подводных камней, как у ТМ6. И не будет проблем с производительностью при обработке графики как у ТМ6.
Когда делали описанный мной объект, мы кончено сразу создавали оптимизированные карты переменных в контроллерах, так чтобы получалось как можно меньше запросов... но вот то, что ТМ6 тупо не потянет считывать через встроенные драйвера модбаса несколько тысяч переменных я, честно говоря, не ожидал. Я проходил у них расширенный курс обучения лет 6 назад, и там они говорили, мол OPC серверы глючные, пользуйтесь по возможности встроенными драйверами.. а оказалось, что они работают нормально только на небольших количествах переменных (100-300). А чем дальше - тем медленнее. Вот MasterOPC (от Мастерскады кстати говоря) отлично справился с этой задачей (мы в итоге все данные по модбасу организовали через него) и ни разу за все время использования он не завис. Это конечно большой плюс для МастерСКАДЫ но что-то я пока все-равно боюсь использовать её на таком большом и серьезном объекте.

Тогда я уже вообще ничего не понимаю Та часть по которой у Вас претензии к ТМ, в Мастерскаде Вами уже опробована с отличными результатами, в чём проблема то?

Боюсь связываться с отечественным продуктом на ответственном и реально большом объекте. Заказчику надо графику, и если я сделаю на своем "проверенном" решении боюсь что ТМ6 загубит графика. Как с этим в Мастерскада я не знаю. И как она потянет опрос и архивировнаие в реальном времени 20-30-40 тыщ переменных - я тоже не знаю. Ну и опробована не в мастерскаде а в ОПС-сервере их производства. Ну и в том опс-сервер около 2 тыщ переменных... остальные 3 тыщи - это счетчики и кондиционеры, которые читаются другим софтом.

Да елки-палки. У Вас же все претензии именно к связи. При чём тут сама скада?
В конце концов можно запросить у Инсата (думаю не откажут ) координаты реализованных крупных проектов и пообщаться со службой эксплуатации этих объектов. Всяко лучше будет, чем тут спрашивать.
Ну и не последний момент, про который Вы и сами писали, техподдержка. Вполне себе вменяемые люди в Инсате там работали на момент моего последнего к ним обращения. Кроме того в прайсе есть интересная позиция ""Техническая помощь по настройке программных продуктов компании на территории заказчика".
PS Блин, может показаться что я их рекламирую, хотя это вовсе и не так.

Да я уже с ними общаюсь. Только пока меня они не убедили.

С Инсатом или со службами эксплуатации?

С техподдержкой Инсата.

Ну это не то. Какой же производитель признается в недостатках своего продукта потенциальному клиенту Опыт с ТМ у Вас есть уже.

Да надо запросить телефоны эксплуатации внедренных систем

С МастерСкадой не рекомендую связываться, если у вас больше 100 тегов.
Indusoft - хороший вариант.
Reliance - еще лучше, на удивление неплохая скада.

По причине?

Интересна сама постановка вопроса: 20 - 30 - 40 тыщ переменных, кагбэ должна переваривать некая SCADA... Хотелось бы понять, кто будет анализировать эту туеву хучу переменных, для кого они? Может дело вообще не в каких либо SCADAх, а в нереальных и ненужных никому хотелках?

Как для кого - для эксплуатации. Несколько сотен приточных установок, хладоцентры, насосные, тепловые узлы, кондиционеры. Вот и набегает такое количество сигналов. Будет несколько рабочих мест диспетчеров. При чем тут нереальные и никому не нужные хотелки? У меня объект раз в 5 меньше -там под 5000 сигналов вылезло.

Да это все понятно. Непонятно только, кто в состоянии переварить этот объем информации, а переварив ее - делать что-то вразумительное. Есть такие таланты?

Делал тут недавно проект диспетчеризации одного предприятия... Куча разных производств и систем - от технологии до вентиляции, отопления, холодоснабжения и т.д. Причем различные технологические процессы делали разные компании и как правило на своем оборудовании - с чем привыкли работать - встречаются ПЛК от SIEMENS, Allen Bradley, DELTA, Schneider Electric и т.д. В общем зоопарк. И естественно переменных счет на десятки тысяч. Но никто не сидит и не пялится во все эти данные в мониторе компьютера. Все, что собрала СКАДА, используется не только для отображения параметров техпроцессов, но и для организации службы эксплуатации и ремонта. В общем система интегрируется с "1С Предприятие" для формирования всевозможных нарядов на текущие и капитальные ремонты, контроля наличия ЗИП на складах, получения параметров по простою и работе оборудования и много чего еще, что требует рутинной работы и можно автоматизировать за счет обработки поступающей информации. Я о том, что цель внедрения СКАДА - это не красивые картинки на экране компьютера. Цель - это повышение эффективности работы всевозможных систем путем оптимизации затрат на эксплуатацию, обслуживание и потребление ресурсов. То есть от внедрения СКАДы должен быть экономический эффект в виде снижения времени простоя оборудования, повышении его энергоэффективности, снижения затрат на эксплуатацию. Иначе - это просто выброшенные деньги.

Правильные утверждения: SCADA придумана для облегчения труда операторов - посмотрите на старые фото например Плана ГОЭЛРО - кругом вольтметры и самописцы - застрелишься все это оббегАть и анализировать что куда идет. Просто система управления объектом многоуровневая - на самом верху ERP (управленческий учет для бизнеса), ниже SCADA (технологи, инженеры, метрологи), сбоку ТОиР/EAM/CAFM/CMMS (упрощение эксплуатации и снижение стоимости ремонтов), ниже ПЛК/РСУ (управление самим технологическим процессом) далее КИП. Весь этот огород придуман, чтобы снизить стоимость владения объектом, увеличить энергосбережение, увеличить ROI. К сожалению, в наших проектах, заказчики ведутся на красивые картинки, не представляя всех возможностей грамотно спроеткиованной, собраной и эксплуатируемой АСУ здания или завода. Это виднв подходе к организации эксплуатации объекта и нуждам служб этой самой эксплуатации.

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

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

Очень неудобно ориентироваться в дереве тегов. Слишком тяжелая мышиная возня получается. Да и вообще в ней как-то всё нелогично и неудобно.