Регистрация | Последние сообщения | Персональный список | Поиск | Настройка конференции | Личные данные | Правила конференции | Список участников | Top 64 | Статистика раздела | faq | Что нового v.2.3 | Чат
Skunk Forum - Техника, Наука, Общество » АСУТП »
Сложность HMI SCADA. (страница 1)

Версия для печати (настроить)
Страницы: 1 2

Новая тема | Написать ответ

Подписаться

Автор Тема:   Сложность HMI SCADA.
Павел Мощицкий
Member

Сообщений: 836
Откуда: Израиль. Бат-Ям
Регистрация: Январь 2004

написано 08 Апреля 2005 15:29ИнфоПравкаОтветитьIP

Наблюдается изменения требований к HMI. На какого пользователя ориентированы SCADA-пакеты? У меня складывается впечатление, что вначале они были ориентированы на программистов. Это объяснялось тем, что созданием и внедрением АСУ ТП занимались только системные интеграторы. Конечные пользователи не имели навыков, ресурсов и не знали как подступиться. Их хватало, и то не всегда, на сопровождение. Сейчас тенденция постепенно меняется, сами производства ставят АСУ ТП, что приводит к ужесточению требований на ср-ва разработки SCADA-пакетов. Они уже должны иметь интерфейс, понятный технологу. Как не крути, но пока я не вижу, кроме Adastr-ы, кто бы попытался реализовать механизм разработки с точки зрения разного пользователя. Я даже знаю такие редакторы представления данных, где и сам редактор мнемосхем найти сложно. Хотелось бы услышать, коллеги, на кого и до какой степени должны быть ориентированы универсальные SCADA-приложения? Степень их сложности, как говорится, золотая середина.

panteleys
unregistered
написано 11 Апреля 2005 07:20  ПравкаОтветитьIP

Выскажу свое мнение. По моим наблюдениям, SCADA системы должны быть ориентировынны в первую очередь на операторов установок, т.е. представление данных, мнемосхемы, тренды, архивы сигнализаций и т.д. должны быть максимально понятны, а механизмы легки в управлении. Это связано с тем, что все что мы делаем, мы делаем для оператора и ему с этим работать 24 часа в сутки 10 лет (как минимум). Далее SCADA пакет должен быть "заточен" под инженера АСУ ТП, а не под программиста. По моим наблюдениям, программист увлекается решением простых задач через написание программ, что нагружает станцию оператора, в результате чего тормозится отображение трендов, смена значений на дисплеях и т.д. (правда это не всегда). Самый главный недостаток, возникает при смене персонала (один программист написал, другой не желает в этом разбираться и попробуй заставь). Инженер АСУ, кроме знания пакета на уровне продвинутого пользователя, обязан знать технологию и представлять как это все работает. Это иногда приводит к изменению схем управления (одноконтурная схема на какскадную или комбинированную и т.д.). Да и задачи по отображению мнемосхем пытается решить максимально простым способом с применением стандартных функций SCADA пакета.

ColdFire
Member

Сообщений: 52
Откуда: Россия
Регистрация: Ноябрь 2004

написано 14 Апреля 2005 15:08ИнфоПравкаОтветитьIP

Мне вообще не нравится существующая система разработки в АСУТП, начиная от средств программирования контроллеров и заканчивая SCADA.

Судя по мануалам систем, с которыми я работал, а также рекламным проспектам и т.д. все эти вещи изначально (за границей) делались с упором на технолога, то есть чтобы технолог мог на доступном ему языке описать процесс, и все бы заработало. На мой взгляд это полный бред - в особенности на западе, где все специалисты крайне узки и технолог никогда не стал бы заниматься разработкой АСУТП. В итоге получили то, что имеем - недопродукты, в которых чтобы решить более-менее серьезную приходится с ног на голову вставать. В первую очередь я отношу это к языкам группы Ladder Logic, State Logic и подобным из IEC1131. Ребята у нас вроде Siemens хвалят в плане среды программирования, что в ней гибкости больше, но я именно с ней не работал.

То же самое касается и существующих систем визуализации. Мы вроде как не в каменном веке живем, и возможности техники
позволяют реализовывать КАЧЕСТВЕННУЮ графику. А не убожество, в качестве базы предлагаемое вместе с Intouch и многими другими пакетами, где труба на трубу или бак на бак не похожи. В итоге тратится море времени на рисование всех объектов в Paint с последующей раскраской в 10 цветов и вставлением 10 картинок одна над другой, потому что система не позволяет все сделать по-человечески. Поверьте мне, качественная анимация, вставленная в нужные места, выглядит намного лучше чем ее отсутствие (но и избыток анимации тоже опасен, поскольку отвлекает).

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

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

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

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

bessonov
Member

Сообщений: 85
Откуда: Россия
Регистрация: Август 2003

написано 14 Апреля 2005 20:50ИнфоПравкаОтветитьIP

ColdFire
Мне вообще не нравится существующая система разработки в АСУТП, начиная от средств программирования контроллеров и заканчивая SCADA.
Приведите пожалуйста примеры. Чем не нравиться и почему.

Судя по мануалам систем, с которыми я работал, а также рекламным проспектам и т.д. все эти вещи изначально (за границей) делались с упором на технолога, то есть чтобы технолог мог на доступном ему языке описать процесс, и все бы заработало.
Думаю что SCADA и IEC1131 предназначены для того чтобы сделать АСУ ТП максимально быстро. Т.е. их смысл в уменьшении времени на разработку и ввод в эксплуатацию.

То же самое касается и существующих систем визуализации. Мы вроде как не в каменном веке живем, и возможности техники
позволяют реализовывать КАЧЕСТВЕННУЮ графику.

Что есть качественная графика и не качественная?

Добавление от 14 Апреля 2005 20:56:

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

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

ColdFire
Member

Сообщений: 53
Откуда: Россия
Регистрация: Ноябрь 2004

написано 15 Апреля 2005 15:17ИнфоПравкаОтветитьIP

цитата:
bessonov писал:
ColdFire
Мне вообще не нравится существующая система разработки в АСУТП, начиная от средств программирования контроллеров и заканчивая SCADA.
Приведите пожалуйста примеры. Чем не нравиться и почему.

Судя по мануалам систем, с которыми я работал, а также рекламным проспектам и т.д. все эти вещи изначально (за границей) делались с упором на технолога, то есть чтобы технолог мог на доступном ему языке описать процесс, и все бы заработало.
Думаю что SCADA и IEC1131 предназначены для того чтобы сделать АСУ ТП максимально быстро. Т.е. их смысл в уменьшении времени на разработку и ввод в эксплуатацию.

То же самое касается и существующих систем визуализации. Мы вроде как не в каменном веке живем, и возможности техники
позволяют реализовывать КАЧЕСТВЕННУЮ графику.

Что есть качественная графика и не качественная?

Добавление от 14 Апреля 2005 20:56:

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

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


Понятие "быстрая" разработка непонятно что к чему относится. Если речь идет о проекте целиком (в смысле, не о стадиях ТП/РП, а о реализации задачи), то какое отношение к этому имеет скорость _кодирования_ ? Разбивка по стадиям в тех проектах, которые мы делаем, получается примерно такая (я говорю только о блоке АСУТП):
1) Препроектное обследование и ТЗ - ~1 месяца
2) Проектирование - от месяца до трех-четырех по более сложным проектам
3) Поставка оборудования - примерно 3-4 месяца, включая тестирование и сборку шкафов. Обычно заказ оборудования начинается на первых неделях проектирования, а мелочь докупается по ходу проекта.
4) Монтаж на объекте подрядчиками - редко кто укладывается в месяц. Как правило, монтаж идет месяца два-три. А по крупным проектам и то больше.
5) Наладка - в зависимости от проекта, от недели до месяцев, в зависимости от стадийности и местного раздолбайства.

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

По поводу качественной и некачественной графики. Псевдографика в текстовом режиме - это некачественная графика, я думаю
все с этим согласятся. Я имею в виду не жк-панельку 4" на стенке агрегата, а нормальный АРМ.
Вот по крайней мере мои требования к качественной графике:
- поддержка стандартных графических форматов (а то целый ряд продуктов кроме bmp, да wmf ничего не умеют)
- поддержка анимации, управляемой из системы, с прозрачностью. ActiveX с MPlayer я тоже вставлять умею,
вот только сделать с ним перекрывающиеся области невозможно, а чтобы управлять не будучи программистом вообще не получится. Кроме того, чтобы сделать AVI надо тоже хорошо извернуться.
- библиотека реалистично выглядящих графических объектов со встроенными в систему средствами управления.
а то вот с "прямоугольником" можно сделать почти все, что хочешь, а с "трубой" - фиг. промышленные экраны
давно умеют больше 16 цветов, а у нас куцый полуградиент.

Ну и пример из жизни. Вот, например, Photoshop - качественная графика. А Paint - нет. Кстати бесплатный GIMP - тоже качественная. Visio - скорее ближе к качественной. Но извините, GIMP не стоит ничего, как и Paint, да и Photoshop вместе с Visio стоят изрядно дешевле Intouch (WinCC, Citect, TM и т.д.). Почему же я заплатив $60K и даже больше получаю непонятно что ? Если за супернадежность - так я что-то не наблюдаю, чтобы оно работало лучше скажем того же Paint.
Если за промышленные драйвера - так диск с ними обновлялся последний раз еще в 90-х годах.

По поводу связок пример из последнего проекта: имеем Intouch (сам по себе). К нему по сути внешняя - логгер, но она умеет только собственный формат. Логгер в СУБД это уже другая программа, настраивается в другом месте, и фиг поймешь, какой именно механизм включен и через какой будут логи читаться. Тренды в базу данных умеет внешний пакет IndustrialSQL, причем живет он вообще независимо, и тэги имеет собственные, которые перетягиваются импортом-экспортом. А чтобы из InSQL тренды на экране показать, это отдельная компонента в Intouch, которая тэги берет уже те, которые в InSQL. А нормальный анализ данных умеет ActiveFactory, который тоже сам по себе, и умеет видеть InSQL. IO-сервера тоже живут сами по себе, и конфигурируются самостоятельно.

А средства программирования контроллеров - тоже сами по себе (ну кроме Siemens, нам вроде интегрировано, но сам не трогал - им другие ребята занимаются у нас). По сути получается, что одни и те же тэги по ходу создания АСУТП надо набить вручную раза четыре. Кое-где все-таки не вручную.

Вот собственно я и имел в виду говоря о недовольстве системой разработки.

Константин Власкин
unregistered
написано 16 Апреля 2005 19:17  ПравкаОтветитьIP

ColdFire а Вы не думаете, что отказываясь от использования SCADA пакетов придётся к работе привлекать высоко профессиональных программистов, чей труд будет требовать гораздо большей оплаты, чем программистов способных создать эквивалентную систему с помощью SCADA пакетов. И в результате оплата более профессиональных программистов компенсирует стоимость SCADA, а то и превысит её.

Yougi
unregistered
написано 17 Апреля 2005 14:54  ПравкаОтветитьIP

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

Павел Мощицкий
Member

Сообщений: 846
Откуда: Израиль. Бат-Ям
Регистрация: Январь 2004

написано 17 Апреля 2005 23:22ИнфоПравкаОтветитьIP

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

panteleys
unregistered
написано 18 Апреля 2005 07:19  ПравкаОтветитьIP

ColdFire, работали ли Вы с такими пакетами как Experion PKS "Honeywell", DeltaV "Emerson", Centum "Yokogawa"? Про Citect не спрашиваю понял, что работали (не совсем понял чем не нравится). У нас на заводе стоят все (не спорю зоопарк, но не от нас зависит). Все задачи коротые мы выдвигали пусконаладке (я эксплуатирую системы АСУ) они успешно реализовали. Задачи, правда, были тревиальны, но работает без сбоев и остановов по причине АСУ. Я лично так и не понял, зачем навороченная графика на станциях? Согласен, что она должна быть не убогой (графика Citect v5.0, а особенно v6.0 вполне подходит), но и 3D эффекты как в кино там лишние. Понятно, что теплообменник должен отличаться от трубы и емкости, но это не говорит о том, что он должен переливаться всеми цветами радуги.
- поддержка стандартных графических форматов (а то целый ряд продуктов кроме bmp, да wmf ничего не умеют). Это, простите, только для вашего удобства. На станции это никак не видно, а оператору все равно в каком формате эта картинка. У Вас по моему (может и ошибаюсь) подход не правильный. Хотите все сделать быстро и эффектно (для этого и красота нужна, алгоритмы на станции не видно) поэтому и хочется максимальных удобств. Потом когда такая пусконаладка уезжает, сам сидишь и правишь (а то опечаток больше чем пуговиц на космическом корабле), если, естественно, их за руку не словил.
По поводу связок пример из последнего проекта: имеем Intouch (сам по себе). К нему по сути внешняя - логгер, но она умеет только собственный формат. Логгер в СУБД это уже другая программа, настраивается в другом месте, и фиг поймешь, какой именно механизм включен и через какой будут логи читаться. Тренды в базу данных умеет внешний пакет IndustrialSQL, причем живет он вообще независимо, и тэги имеет собственные, которые перетягиваются импортом-экспортом. А чтобы из InSQL тренды на экране показать, это отдельная компонента в Intouch, которая тэги берет уже те, которые в InSQL. А нормальный анализ данных умеет ActiveFactory, который тоже сам по себе, и умеет видеть InSQL. IO-сервера тоже живут сами по себе, и конфигурируются самостоятельно.
Согласен на все 100%. Пакет должен быть законченным изделием, а не кучей подпрограмм собранных вместе и непонятно как связанных между собой. Да еще в добавок и за бешенные деньги.
А средства программирования контроллеров - тоже сами по себе (ну кроме Siemens, нам вроде интегрировано, но сам не трогал - им другие ребята занимаются у нас). По сути получается, что одни и те же тэги по ходу создания АСУТП надо набить вручную раза четыре.
Могу сказать про Experion PKS. Там одна база одна и в трендах, рапортах, отображении и т.д., очень удобно. Да и библиотека блоков достаточно большая.
Нет отраслей специфичных и не специфичных. Они все специфичны, а главное оборудование АСУ должно всегда работать вне зависимости от отрасли.
Извечный и давний спор: самому создавать специализированную SCADA, заточенную под предметную область или покупать готовую универсальную
Покупать только готовую, так важно не только пустить в работу, но и в дальнейшем обслуживать.
Задачи могут меняться, добавляться, а с кем консультироваться если есть вопросы, а если человек который сам создал специализированую SCADA уже не работает в данной отрасли? К кому побежишь? Только покупать готовую универсальную и известных брендов (если не жмут финансы). Это как с телевизорами, можно самому спаять под себя, а можно купить готовый "SONY" или "Горизонт". Шкала ценностей таже. А Вы какой телевизор выберете?

ColdFire
Member

Сообщений: 54
Откуда: Россия
Регистрация: Ноябрь 2004

написано 18 Апреля 2005 10:26ИнфоПравкаОтветитьIP

цитата:
Константин Власкин писал:
ColdFire а Вы не думаете, что отказываясь от использования SCADA пакетов придётся к работе привлекать высоко профессиональных программистов, чей труд будет требовать гораздо большей оплаты, чем программистов способных создать эквивалентную систему с помощью SCADA пакетов. И в результате оплата более профессиональных программистов компенсирует стоимость SCADA, а то и превысит её.

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

Добавление от 18 Апреля 2005 10:28:

цитата:
Yougi писал:
ColdFire, может быть проблема просто в отрасли? ЦБП довольно специфическая часть индустрии, практически все серьезные агрегаты ( машины, котлы, сортировка и проч. ) сделаны по индивидуальным проектам, подход нужен капитальный, требования - высокие, изношенность еще шибче, чем требования, начальство над оборудованием трясется. Отсюда и проблемы. И не зря, например, Метсо делает все сам - от железа, до контроллеров и SCADA, и заточенно это все под ЦБП.

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

Павел Мощицкий
Member

Сообщений: 850
Откуда: Израиль. Бат-Ям
Регистрация: Январь 2004

написано 18 Апреля 2005 15:31ИнфоПравкаОтветитьIP

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

panteleys
unregistered
написано 19 Апреля 2005 10:51  ПравкаОтветитьIP

Павел Мощицкий
Хотите поспорить? Так кто-ж хорошую качественную специализированную SCADA пишет одним программистом? А если он не один, так и должна быть преемственность, взаимозаменяемость.
Да я не спорить хочу. Я просто пытаюсь подвести (как и Вы) свои знания и навыки под общий знаменатель с вашими. Если взять программистов создать SCADA пакет под себя, потом его корректировать (преемственность, взаимозаменяемость), то что потом с ним делать? По сути мы создали свой SCADA пакет для одного объекта автоматизации (может для одного завода). А зачем если они и так есть. На каждом заводе создавать свой отдел для написания аналогов SCADA пакета? Или может определимся. Нас не устраивают существующие SCADы и мы решили написать свою и потом ее продавать или с ее помощью заниматься автоматизацией. Так это уже совсем другая цель (следовательно и метод решения).

bessonov
Member

Сообщений: 86
Откуда: Россия
Регистрация: Август 2003

написано 19 Апреля 2005 11:05ИнфоПравкаОтветитьIP

Я не специалист по SCADA, но знаю, что некоторые SCADA поддерживают формат avi.

panteleys
unregistered
написано 19 Апреля 2005 12:30  ПравкаОтветитьIP

Для тех кому интересно (есть пропаганда).
ссылка

ColdFire
Member

Сообщений: 55
Откуда: Россия
Регистрация: Ноябрь 2004

написано 20 Апреля 2005 09:52ИнфоПравкаОтветитьIP

цитата:
panteleys писал:
Для тех кому интересно (есть пропаганда).
ссылка

Мне особенно понравилась фраза "Косвенным показателем надежности пока считается количество инсталляций. Как известно, Трейс Моуд является лидером по количеству внедрений в России.". Логика прет изо всех щелей

Ваш ответ:

Коды форума
Смайлики


Ник:    Пароль       
Отключить смайлики
Страницы: 1 2

Все время MSK

Склеить | Разбить | Закрыть | Переместить | Удалить

Новая тема | Написать ответ
Последние сообщения         
Перейти к:

Свяжитесь с нами | skunksworks.net

Copyright © skunksworks.net, 2000-2018

Разработка и техническая поддержка: skunksworks.net


Рейтинг@Mail.ru Яндекс.Метрика