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

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

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

Подписаться

Автор Тема:   И как же самому разработать SCADA
Sasha_24
Junior Member

Сообщений: 1
Откуда: Киев
Регистрация: Сентябрь 2006

написано 18 Сентября 2006 16:53ИнфоПравкаОтветитьIP

Дорогие специалисты….
Следующей ступенькой после разработки HMI готовыми генераторами типа Citect, WinCC, Vijeo look и т.д. , является разработка собственной SCADA.

В принципе задачи написать цельную SCADA типа Citect или WINCC нет. Нужно разработать перечень компонент, библиотек, ActiveX’ов , внедряя которые в стандартный Builder (типа VB или C++ Builder) можно будет получить хороший HMI То есть рисовалки, примитивы (короче вся клиентская часть SCADA) меня не интересует.

Может кто то имел опыт разработки следующих типовых для любой SCADA решений :

- каким образом работать с большим количество сигналов
- как сохранять данные в историю
- как организовать ядро «хорошего реального времени» - то есть управления с верхнего уровня должно приходить в ПЛК вовремя, а не тогда когда уже будет поздно.
- система приоритетов
- Какие алгоритмы лучше выбрать.
- Обязательно ли разрабатывать OPC Server, может просто выбрать самые популярные протоколы и написать под них драйвера. Ведь ModBus, ProfiBus,CAN являются открытыми протоколами.
- Посоветуйте на каком языке лучше разрабатывать подобную систему (VC++, Delphi, а может VB, и т.д.)
- и т. д.
- и т. д.
- и т. д.

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

СПАСИБО!

panteleys
Junior Member

Сообщений: 23
Откуда: Пермь, Россия
Регистрация: Апрель 2006

написано 19 Сентября 2006 06:20ИнфоПравкаОтветитьIP

Уважаемый Sasha_24! Появился вопрос: "А стоит ли вообще разарабатывать собственную SCADа?" Сейчас на рынке есть достаточно много SCADa пекетов на любой вкус. Любая программа имеет недостатки - это аксиома. Так что разработать SCADa пакет без недостатков не удастся по определению (если не Вы, то кто-то обязательно найдет недостатки). Потом на кого этот новый SCADa продукт будет ориентирован? Я работаю в нефтеперерабатывающей промышленности и покупать неизвестную SCADa не намерен. Да и потом возникнет вопрос технической поддержки разработанной Вами SCADa. Должен быть коолектив единомышленников, в общем кроме чисто технических вопросов возникаем много, много организационных вопросов. Хотя стремление сделать что-то самому очень даже позитивно и необходимо поощрять.

R0MER
Member

Сообщений: 85
Откуда: Russia
Регистрация: Июль 2003

написано 19 Сентября 2006 11:14ИнфоПравкаОтветитьIP

Вообще - создание собственной СКАДА с нуля будет полностью идентична попытке собрать своими силами собственный автомобиль у себя в гараже.
panteleys прав - прежде чем приступать к такому, лучше для начала просчитайте хорошенько экономическую выгоду от такого рода проекта. Не проще ли купить готовое решение (в автосалоне) с хорошей поддержкой (автосервисом), нежели ГОДАМИ доводить своё решение до нужного идеала? Ибо средств в последнее вы вбухаете ГОРАЗДО больше, чем в стоимость решения из "автосалона" с последующим фирменным "автосервисом"!

Sasha_24
Junior Member

Сообщений: 2
Откуда: Киев
Регистрация: Сентябрь 2006

написано 19 Сентября 2006 11:53ИнфоПравкаОтветитьIP

СПАСИБО за то что откликнулись...потому как темы промышленного программирования особо не интересны на форумах программистов и т.д.

Вот моя точка зрения:
- "А стоит ли вообще разрабатывать собственную SCADа", - я думаю стоит, но только не цельную со всеми ее "глюками" как у Citect или WinCC. Самым дешевым решением являеться разработка перечня компонент, которые были бы универсальны для любых систем быстрой разработки приложений под Windows (C++ Builder, VB, Delphi и т.д.).

Ну например компонента опроса образа переменных ПЛК:
- В VC++ пишем некий DLL с функцией типа ReadObraz(……)
- В VB подгружаем этот DLL и где то вызываем функцию ReadObraz(……), которая сходу вернет массив всех переменных образа.

Все это хорошо, но только на словах. Когда приходиться работать с тысячами переменных
такого рода путь будет «тормозным».

- "На кого этот новый SCADa продукт будет ориентирован",
Он будет чисто на внутреннее нужды фирмы. Он нужен будет не для того что бы его кому то продавать, а для того что бы не покупать брендовые за бешанные деньги.
Мы занимаемся комплексной разработкой технологического оборудования в химической и
пищевой промышленности и делаем АСУ для данного оборудования. В основном используем
спектр контроллеров таких фирм как SE, Siemens. Протоколы которые используются для обмена с верхним уровнем у данных контроллеров открыты и их совсем не много (ModBus TCP/IP,ProfiBus,..WAY подобны, может еще пару). Поэтому написать что-то, что понимало бы эти контроллеры не так уж и сложно.

Вопрос остается один....

Оптимальный внутренний мир ядра SCADA.
- Опросить образ переменных в ПЛК, и пошустрее это сделать
- Сохранить в историю, то что мы захотим
- Управление передавать "сразу".
- ну и т.д.

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

Может у кого то есть знакомые которые занимались подобным. Или какие то ссылки.

СПАСИБО за участие.

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

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

написано 19 Сентября 2006 17:59ИнфоПравкаОтветитьIP

Sasha_24
Он будет чисто на внутреннее нужды фирмы.
Тогда точно овчинка выделки не стоит. И любое урезание по ходу будет рассасываться.

Dmitry M. Gaidash
Member

Сообщений: 45
Регистрация: Сентябрь 2005

написано 20 Сентября 2006 21:38ИнфоПравкаОтветитьIP

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

panteleys
Junior Member

Сообщений: 24
Откуда: Пермь, Россия
Регистрация: Апрель 2006

написано 21 Сентября 2006 08:01ИнфоПравкаОтветитьIP

Ну вот! В общем все кто работает на рынке автоматизации (кроме автора темы) придерживаются тойже точки зрения что и я. У нас на предприятии тоже ребята писали под маленькие задачки всякие программки реализующие в той или иной степени финкции SCADa. Скорее всего на многих отечественны предприятиях есть такие специалисты. Я например о Ваших специалистах не слышал, а Вы о моих слышали? Скорее всего тоже нет. Сидят разарабатывают, а зачем? Спроси никто толком не ответит, ни они ни их начальство. Хорошо что есть такие программисты, но плохо то что начальство которое ими командует не знает зачем они нужны им в штате. Разработка SCADa пакета это совсем другая "вселенная" которая к автоматизации имеет чисто прикладное назначение. Мне как инженеру по АСУ главное надежность связи, скорость опроса и т.д. Удобство работы стоит далеко не на первом месте. Я делаю систему один раз (тут можно и помучоться, но согласен не хочется), а вот работать она будет 10-15 лет. Ну и зачем она мне нужна если все удобно и красиво, но связь отваливается с периодичностью раз в 2 недели? Нет прав Павел Мощицкий овчинка выделки не стоит.

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

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

написано 21 Сентября 2006 18:47ИнфоПравкаОтветитьIP

panteleys
все кто работает на рынке автоматизации (кроме автора темы) придерживаются тойже точки зрения что и я.
Нет, так дело не пойдет. Я бы выразился так: все, кто уже являются разработчиками SCADA или дистрибьютерами, придерживаются такой-же точки зрения.
Единственное с чем соглашусь, так с вредностью полумеры.
А от сляпанной на коленке "под себя" системы все равно придется уходить(c)
Dmitry M. Gaidash и И любое урезание по ходу будет рассасываться.(с)
Павел Мощицкий.

Valera
Member

Сообщений: 319
Откуда: novosibirsk
Регистрация: Май 2004

написано 22 Сентября 2006 05:51ИнфоПравкаОтветитьIP

Мощицкий Павел
Единственное с чем соглашусь, так с вредностью полумеры.
Microsoft уже встроила OPC API в свою .net, есть у ней и XP Embedded и ничто не мешает ей же написать framework под Линукс.. Жадность и всеядность этих мелкомягких все знают, не исключено,ИМХО, рынок SCADA-систем ожидает перетрях. К нашему, гг. автоматики, счастию

[Это сообщение изменил Valera (изменение 22 Сентября 2006 06:22).]

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

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

написано 22 Сентября 2006 19:39ИнфоПравкаОтветитьIP

Valera
К нашему, гг. автоматики, счастию
Вы про господство Linux-а? Это вряд-ли.

ColdFire
Member

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

написано 24 Сентября 2006 21:09ИнфоПравкаОтветитьIP

День добрый !

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

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

Если же подойти с технической точки зрения, то поскольку мы не только занимались, но и занимаемся темой ваших раздумий, вот вам тема для размышлений:
0) Умелый руководитель проекта может сделать софт, который на 100 тэгах будет отжирать 100% быстродействия новейшего сервера и реагировать на события по пол-дня
1) Забудьте о ядре реального времени и системе приоритетов, оно вам нафиг не надо и практически ни у кого его нет. А задачи, где миллионы тэгов генерятся "наверху" сотни раз в секунду решают мазохисты с проблемами планирования
2) А что для вас большое количество сигналов ? Типовые задачи, куда вашу систему пустят, врядли будут иметь больше единиц тысяч тэгов. Собственно известные мне лицензионные политики тех же Siemens, WW, GE и проч. ограничивают емкость системы числов в 32-64 тыс. тэгов. На таких объемах существенных проблем с передачей информации НЕТ - в особенности с настройками коммуникаций по-умолчанию.
3) Если вам нужен OPC - пишите под ним. Тем более что существует море более-менее стабильных готовых драйверов под него. Без OPC вы скоро убедитесь, насколько много уродливых и косых протоколов обмена существует, и что за каждый чих, выходящий за пределы "modbus ascii", с вас будут хотеть стянуть денег (в отдельных тяжелых случаях - посылать нахрен).
4) Единственная сложная техническая задача - это сохранение трендов в базу данных и вытягивание данных оттуда же обратно. Об этой задаче можно говорить часами, но если посмотреть к "брэндам" можно убедиться, что у них там с идеями не менее туговато, а с реализацией полный атас. Над человеческим решением данной задачи собственно и идет работа на протяжении последних уже лет пяти.
5) На мой взгляд на рынке сейчас ВООБЩЕ нет ни одной нормальной скады, в которой мой привиредливый глаз не находил бы неудобства - везде какой-нибудь атас

Dmitry M. Gaidash
Member

Сообщений: 46
Регистрация: Сентябрь 2005

написано 25 Сентября 2006 16:09ИнфоПравкаОтветитьIP

ColdFire
На мой взгляд на рынке сейчас ВООБЩЕ нет ни одной нормальной скады, в которой мой привиредливый глаз не находил бы неудобства - везде какой-нибудь атас
Напильник в зубы и вперед Как мы делаем это с WinCC

bessonov2
Junior Member

Сообщений: 6
Регистрация: Май 2006

написано 25 Сентября 2006 22:08ИнфоПравкаОтветитьIP

Sasha_24
Он будет чисто на внутреннее нужды фирмы. Он нужен будет не для того что бы его кому то продавать, а для того что бы не покупать брендовые за бешанные деньги.

Может не стоит прям таки замахиваться на SCADA?

Не знаю как на самом деле, но слышал мнение windows программёра, что на Delphi очень удобно делать большие проекты в группе. Если вопрос в деньгах, то не проще быстро склепаный "одноразовый" проект на Delphi + OPC?

Добавление от 25 Сентября 2006 23:35:

ColdFire
1) Забудьте о ядре реального времени и системе приоритетов, оно вам нафиг не надо и практически ни у кого его нет. А задачи, где миллионы тэгов генерятся "наверху" сотни раз в секунду решают мазохисты с проблемами планирования
Тем не менее SCADA под qnx всё же зачем то делают?

3) Если вам нужен OPC - пишите под ним. Тем более что существует море более-менее стабильных готовых драйверов под него. Без OPC вы скоро убедитесь, насколько много уродливых и косых протоколов обмена существует, и что за каждый чих, выходящий за пределы "modbus ascii", с вас будут хотеть стянуть денег (в отдельных тяжелых случаях - посылать нахрен).
Согласен... это просто болезнь нашей страны...


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

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

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

написано 26 Сентября 2006 00:36ИнфоПравкаОтветитьIP

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

Добавление от 26 Сентября 2006 00:38:

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

ColdFire
Member

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

написано 26 Сентября 2006 02:06ИнфоПравкаОтветитьIP

bessonov2
Полностью согласен - Delphi в связке с какой-нибудь коммерческой библиотекой VCL графики, или с собственной графикой (реально делается за неделю) плюс OPC или DDE драйвер - прекрасное решение.

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

Проблема с хранением трендов на самом деле существует, как только выходишь за рамки формата "100 тэгов x 1 раз в минуту x 3 дня хранения". Существующие "живые" решения на рынке основаны или на собственных СУБДРВ (что в принципе реализуется за пару дней с неплохим результатом, если забыть о совместимости), либо надстройках над MSSQL вроде InSQL (кривых от рождения), либо паковке в BLOB в тот же MSSQL. Кстати буквально в минувший год как грибы начали появляться именитые решения на базе MySQL - я сам гонял тесты, вышла вполне реальная цифра 10000 inserts за 5.2 секунды на обычной машинке.

Dmitry M. Gaidash
Member

Сообщений: 47
Регистрация: Сентябрь 2005

написано 26 Сентября 2006 11:14ИнфоПравкаОтветитьIP

Павел Мощицкий
Пока нет быстрых реляционных БД. Имеющие, псевдореляционны, в них просто имеются SQL-запросы, но структура другая
WinCC версии 6.0 работает с настоящей MS SQL, версия 5.0 работала с настоящей же Sybase SQL Anywhere (это не сильно ей помогало, правда), так что неправда Ваша, Павел. MS SQL довольно шустро пашет, читайте ниже.

ColdFire
Проблема с хранением трендов на самом деле существует, как только выходишь за рамки формата "100 тэгов x 1 раз в минуту x 3 дня хранения"
Какие требования к хранению трендов предъявляете Вы? На той же WinCC реализуется долговременное хранение архивов, возможности очень широкие - дискретизация от 20 мс (можно и меньше, если надо, но 20 мс - это то, что делаем мы) до длительного хранения данных месяцами с различными алгоритмами усреднения и накопления. Скорость архивирования WinCC 6.0 - 10000 (десять тысяч) тэгов в секунду. Это заслуга MS SQL, на Sybase было в разы медленнее.

bessonov2
Junior Member

Сообщений: 7
Регистрация: Май 2006

написано 26 Сентября 2006 20:35ИнфоПравкаОтветитьIP

ColdFire
Не видел ни одной коммерческой скады под qnx.

Я тоже не видел, только слышал

ссылка

[Это сообщение изменил bessonov2 (изменение 26 Сентября 2006 22:53).]

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

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

написано 26 Сентября 2006 23:03ИнфоПравкаОтветитьIP

Dmitry M. Gaidash
MS SQL довольно шустро пашет, читайте ниже.
10000 (десять тысяч) тэгов в секунду
Сколько? Ну ты и дал. Мы на MS SQL 30 тыс. получали.

Dmitry M. Gaidash
Member

Сообщений: 48
Регистрация: Сентябрь 2005

написано 27 Сентября 2006 00:28ИнфоПравкаОтветитьIP

Павел Мощицкий
Я "дал" реальную цифру для сервера архивирования А то, что вы там на сферической коленке в вакууме получали, вряд ли кому интересно Если нужны еще более серьезные требования к архивированию (сотни тысяч или даже милллионы тэгов, которые хранятся длительное время), то есть соответствующие продукты (IT Historian, например) - это я к тому, что не стоит писать про несуществующие проблемы с хранением тэгов

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

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

написано 28 Сентября 2006 02:05ИнфоПравкаОтветитьIP

Dmitry M. Gaidash
А то, что вы там на сферической коленке в вакууме получали, вряд ли кому интересно
Дима, цыплят по осени считают.

Ваш ответ:

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


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

Все время MSK

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

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

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

Copyright © skunksworks.net, 2000-2018

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


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