Выбор Scada

Суть - необходимо провести комплексную автоматизацию крупного предприятия пищевой промышленности (мукомольный завод).
Уровень автоматизации ~0. Есть пара контроллеров отечественных на базе Motorol-овского процессора с АРМ со SCADой TraceMode едва ли не досовской версии. Есть ещё 1 контроллер фирмы, название которой даже установить трудно. К нему программка на С, которая глючит иногда.
Вот, в принципе, и всё.
Ни аппаратный, ни программный базис пока окончательно не выбран. Однако, скорее всего, будут использоваться промышленные контроллеры и модули удалённого сбора информации Advantech.
А вот вопрос выбора SCADA-системы открыт.
После предварительного анализа мы остановились на Advantech Studio, Genesis32 и InTouch.

На первый взгляд, наиболее вероятно использование "родной" Advantech Studio.
Однако на производстве очень широко используются большое количество интеллектуальных устройств, причём различных производителей. Новые, только что поступающие на завод имеют достаточно широкий диапазон поддерживаемых протоколов. Однако с уже использующимися большие проблемы. Практически все они имеют возможность подключения к ПК. Однако каждый использует свой протокол, среди которых есть как стандартные (например, Modbus-RTU), так и свои собственные, не удовлетворябщие ни одному стандарту (особенно касается приборов 10-тилетней давности. ПО для таких приборов обычно представляет собой программу для ПК, написанную на С и тп). Ни о каких OPC-серверах вопрос даже не идёт. Имеются только формальные
описания протоколов, в лучшем случае исходники программ.
Заменить эти приборы в ближайшем будущем не планируют.
Поэтому на данном этапе очень остро встал вопрос о сопряжении всех этих приборов со SCADA.

Конкретный пример.
При дозировании некоторого вещества в тех. процессе используется отечественный прибор П1, выпущенный лет 10 назад. Он является частью системы телеизмерния, поэтому только передаёт на ПК информацию (расход в-ва и тп ), управляющие воздействия с ПК не предусматриваются. Сопряжение идёт через COM-порт.
Для связи с ПК используется уникальный протокол, аналогичный ASCII (передача данных идёт в виде последовательности байтового представления символов). Верхний уровень состоит из программы, написанной на Delphi. Данные с прибора заносятся в файл, отображаются в виде таблицы и в виде графиков. На данном этапе требуется реализовать верхний уровень в SCADA-системе - представление данных в виде графиков, таблиц, архива данных и тп средствами SCADA. В дальнейшем - интеграция данного АРМ в общую систему управлнения производства предприятия (на базе той же SCADA).

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

Конечно, мы направили запросы производителям, дистрибьютерам. Однако всегда есть "тонкие" моменты, которые никак не отражены в документации и проявляются только на практике. Поэтому буду благодарен за любую информацию, ссылку о том, как реализовать сопряжение конкретной SCADA с оборудованием, использующим уникальный протокол обмена.
Круг систем не ограничивается Advantech Studio, Genesis32 и InTouch. Рассматриаются также WinCC (если всё же предпочтение будет отдано Siemence), TraceMode, MasterScada, IFIX.

На мой взгляд, предпочтительно использовать Intouch.
В составе этой SCADA системы имеется такая программа как Rapid Modeler Kit. C ее помощью можно описать протокол обмена данными с устройством. А с другой стороны у нее (работает как сервер ввода вывода) стандартныйдля Intouch SuitLink или DDE. Я таким способом описал протокол DCON для которого нет сервера ввода-вывода.

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

Система строится по участкам. Первый этап (сейчас) - создание АРМ операторов для наиболее важных (с точки зрения заказчика) участков - нормирование конечного продукта, автоматизация подачи зерна на одном из элеваторов...
Возвращаясь к примеру. Оборудование не надо менять - сам по себе прибор с задачей справляется успешно (открытие-закрытие задвижки при подаче муки) и сбоев не было. Однако проблема в том, что он использует нестандартный протокол для передачи данных на ПК (через RS232). И такая ситуация повсеместно.

Предложение 1. Мы с таких приборов пытаемся брать токовые сигналы, заводим которые на контроллеры участковой системы, УСО которых приспособлено принимать сигналы от старых средств измерения.

Состав участковой системы: Контроллеры Trei (Isagraf), SCADA - iFix, сеть Ethernet.

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

Предложение 2. Если прибор имеет какую-то специализированную локальную систему отображения, то мы ее как правило оставляем, по любому придеться писать модуль экспорта данных из этой системы в SCADу. Мы такие программы называем "бросалки".

В SCAD-у iFix имеется возможность различными способоми передавать данные, через DDE, OPC, txt.

Первоначально опубликовано KostyaK Упс, забыл написать. Модератору: подобная тема недавно поднималась ("обзор SCADA"), однако в связи с тем, что 1) в обсуждении немного отклонились от темы - от обзора SCADA-систем перешли к анализу конкретного объекта;

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

Беда в том, что на вопрос "Объективное сравнение SCADA систем" (как и было подмечено в цитируемой фразе) мы всегда в ответ получаем невразумительный гомон наперебой продавцов, у которых единственная цель "продать свои полосатые палочки"... :(. Безусловно, область комплексных АСУТП - корумпирована как ни одна инженерная стезя, и тому есть основания ;)... но инженерный форум должен был бы быть не только лотком, где коробейники раскладывают товары :(.

Несколько лет читаю этот форум (хотя и без прямых интересов в АСУТП области), и так и не видел минимального сравнительного анализа, уровня выше "... а возьмите наше...". А обсуждать есть что:
- функциональность - здесь, как раз, практически все системы могут "всё", с отклонениями влево-вправо, которые тоже хорошо бы обсудить...
- "тяжеловесность" для персонала, начинающего использоать эту систему...
- уровень документированности;
- обеспечиваемый уровень надёжности и устойчивости (есть critical mission объеекты автоматизации - и есть не очень);
- уровень гибкости и возможности интеграции со специфическими средствами программирования логики ПЛК от самых разных производителей;
- уровень поддержки со стороны производителя - только не обещания "пришлите нам ... КБаксов - и мы пообучим всех ваших специалистов", а это можно услышать только из уст системных интеграторов, да ещё с продолжительным опытом использования, да ещё, желательно, которые не являются диллером какого-либо конкретно SCADA производителя...
- ... да и стоимость "реальная" ;), стоимость владения - не последнее дело: типы лицензирования и защиты, необходимые комплекты компонент, итоговые стоимости всей комплексной поставки...

И это ещё далеко не всё. А до тех пор, пока системы не будут сравниваться по таким ортогональным критериям - все разговоры будут сводиться к рекомендациям "... возьмите наше - оно самое лучшее...".

Попутно вопросы, может кто незаинтересованно ;) ответит:

1. Опыт работы со SCADA от Schneider Electric: Monitor Pro, в первую очередь, ну и "облегчённой" Vijeo Look? Да попутно - и с ПЛК от Schneider Electric, серии Quantum, к примеру...

2. А не использовал ли кто SCADA систем семейства RealFlex - RealFlex, FlexWin, RealWin... :
- система имеющая очень обширную географию использования во всём мире...
- "старше" многих других, ... да, в том числе, и самой MS Windows платформы...
- прозрачно переносимая между ОС: MS Windows - QNX 4.X - QNX 6.X ...
- ... и что "приятно подкупает" - SCADA не от производителя конкретного железа", но легко интегрирует самое разнородное оборудование.
http://www.dataconline.com/index.htm