SCADA под Linux (Есть ли законченный продукт? Желательно OpenSource...)

Софт под Linux, разные программы, но только связанные с Linux

Модератор: /dev/random

Аватара пользователя
Zeus
Сообщения: 694

Re: SCADA под Linux

Сообщение Zeus »

ussachev писал(а):
05.04.2007 18:07
В настоящее время я тоже столкнулся с необходимостью найти SCADA систему, работающую под linux.
Недостаточно знаком с архитектурой реализации SCADA систем, поэтому самостоятельная разработка под большим вопросом. Однако, если Ваш проект будет запущен, готов поучаствовать.

Структура там несложная.
Думал, было, изложить её на narod.ru, но решил, что там всё довольно примитивно.

А вот программная реализация этой структуры: вот ею я сейчас и занимаюсь.
Процесс идёт не очень быстро, т.к. я делаю это в свободное время, а его часто бывает очень немного.
Спасибо сказали:
mrcashe
Сообщения: 18

Re: SCADA под Linux

Сообщение mrcashe »

Да, тема скорее жива, чем мертва!.. И это радует!
Тоже время от времени озабочиваюсь ею, но каждый раз останавливаюсь из-за нехватки времени и необязательности получения результата. Может после обнаружения этой ветки снова сдвинусь с места:-)
Согласен с Zeus - нужна система библиотек, не использующая "прелести" CORBA, OPC на COM и т.д. и т.п. И языки, в принципе, правильно выбраны.
Дважды начинал ваять движок. Первый раз - на плюсах. Не очень красиво получается. По-моему, плюсы надо использовать уровнем повыше. Всё-таки, подход к ОО программированию на Си от дядюшки Столлмэна, просто гениален! Вот я и начал писать на Сях. Впрочем, дело дошло только до эскизного проекта - на уровне ашников и почти ничего не делающих скелетов модулей. Вот иногда открою, просмотрю ещё разок, кое-что не понравится - исправлю, и... Опять закрою до лучших времён...
Конечно, такие системы в Unix жили бы, как рыба в воде! Если бы был спрос. Более того, под Unix такую систему и сделать проще, чем под маздай. В первую очередь за счёт наличия операции монтирования ФС. Вот у меня именно такая идея. Объекты адресуются обычными путями Unix. Вдобавок, каждый объект имеет тип. Этот тип похож на тип MIME и также многокомпонентен, как и путь. Использовать его или нет - дело приложения более высокого уровня. Таким образом, путь определяет экземпляр объекта, тип - его класс. А вот в качестве методов выступает фиксированный набор файлоподобных операций, например, чтение, запись, удаление, изменение прав доступа и т.д. Для конкретного класса эти методы, разумеется, можно перегружать.
То есть, моё мнение такое: мы должны быть способны в конечном итоге смонтировать какую-нибудь scadafs в каталог, скажем, /scada на любом хосте в сети и иметь в нём всё то, что имеет соседний хост. Стандарт POSIX нам любезно предоставляет интерфейс функции ioctl(), при помощи которого мы можем делать почти всё, что угодно. Кстати, отсюда и окончательный выбор языка - Си.
Немалое значение имеет и состав зависимостей. Я пробую разные комбинации, но пока не достиг каких-то оптимальных результатов. Наверное, ещё рановато. Подмывает использовать glib-gtype-gobject как основу, но, кажется, это невкусный вариант:-(
Графический фронт-энд для свободной SCADA в этом случае будет выглядеть a la file manager. Конкретные панели управления могут быть представлены в виде каталога с определёнными опциями сортировки. Дополнительно можно использовать файлы .desktop от opendesktop.org. В конце концов, разве рабочий стол не есть панель управления? Ну, а на счёт того, какой графический пакет использовать, могу ответить: только GTK из-за наличия лицензии LGPL. Qt не имеет лицензии LGPL. wxWidgets - стиль API виндовозный, не хотелось бы возиться с этим навозом. Для любителей плюсов есть gtkmm. Конечно, gtkmm медленнее Qt. Зато есть перспектива развития пакетов pango, cairo, средства которых в данном случае весьма к месту.
Спасибо сказали:
Аватара пользователя
Zeus
Сообщения: 694

Re: SCADA под Linux

Сообщение Zeus »

mrcashe писал(а):
10.04.2007 11:36
Да, тема скорее жива, чем мертва!.. И это радует!
Тоже время от времени озабочиваюсь ею, но каждый раз останавливаюсь из-за нехватки времени и необязательности получения результата. Может после обнаружения этой ветки снова сдвинусь с места:-)
Согласен с Zeus - нужна система библиотек, не использующая "прелести" CORBA, OPC на COM и т.д. и т.п. И языки, в принципе, правильно выбраны.
Дважды начинал ваять движок. Первый раз - на плюсах. Не очень красиво получается. По-моему, плюсы надо использовать уровнем повыше. Всё-таки, подход к ОО программированию на Си от дядюшки Столлмэна, просто гениален! Вот я и начал писать на Сях. Впрочем, дело дошло только до эскизного проекта - на уровне ашников и почти ничего не делающих скелетов модулей. Вот иногда открою, просмотрю ещё разок, кое-что не понравится - исправлю, и... Опять закрою до лучших времён...
Конечно, такие системы в Unix жили бы, как рыба в воде! Если бы был спрос. Более того, под Unix такую систему и сделать проще, чем под маздай. В первую очередь за счёт наличия операции монтирования ФС. Вот у меня именно такая идея. Объекты адресуются обычными путями Unix. Вдобавок, каждый объект имеет тип. Этот тип похож на тип MIME и также многокомпонентен, как и путь. Использовать его или нет - дело приложения более высокого уровня. Таким образом, путь определяет экземпляр объекта, тип - его класс. А вот в качестве методов выступает фиксированный набор файлоподобных операций, например, чтение, запись, удаление, изменение прав доступа и т.д. Для конкретного класса эти методы, разумеется, можно перегружать.
То есть, моё мнение такое: мы должны быть способны в конечном итоге смонтировать какую-нибудь scadafs в каталог, скажем, /scada на любом хосте в сети и иметь в нём всё то, что имеет соседний хост. Стандарт POSIX нам любезно предоставляет интерфейс функции ioctl(), при помощи которого мы можем делать почти всё, что угодно. Кстати, отсюда и окончательный выбор языка - Си.
Немалое значение имеет и состав зависимостей. Я пробую разные комбинации, но пока не достиг каких-то оптимальных результатов. Наверное, ещё рановато. Подмывает использовать glib-gtype-gobject как основу, но, кажется, это невкусный вариант:-(
Графический фронт-энд для свободной SCADA в этом случае будет выглядеть a la file manager. Конкретные панели управления могут быть представлены в виде каталога с определёнными опциями сортировки. Дополнительно можно использовать файлы .desktop от opendesktop.org. В конце концов, разве рабочий стол не есть панель управления? Ну, а на счёт того, какой графический пакет использовать, могу ответить: только GTK из-за наличия лицензии LGPL. Qt не имеет лицензии LGPL. wxWidgets - стиль API виндовозный, не хотелось бы возиться с этим навозом. Для любителей плюсов есть gtkmm. Конечно, gtkmm медленнее Qt. Зато есть перспектива развития пакетов pango, cairo, средства которых в данном случае весьма к месту.

Хм... много нового и интересного...
Сейчас вчитываться и вдумываться некогда - дома перечитаю.
Может где-то можно поподробнее почитать про такую идеологию?
Вопрос "после первого прочтения": вот у Вас закладываются красивые Unix-подобные решения.
А если придётся портировать систему на платформу, куда такие механизмы просто так не перенесёшь?
Кстати, насчёт именования компонентов подобно файлам в файловой системе: у меня такое тоже будет предусмотрено (точнее - перекочует из идеи нашей, конторской SCADA): удобная штука при установке массовых связей.
Например таймер должен раскидывать сообщения(события) во все компоненты на определённый вход tick.
Вот у него и прописывается что-то вроде: from="timer.sec" to="*.tick"
Или какой-то сигнал запрещает управление вентиляторами: from="signals/coolerControl.value" to="objects/coolers/*.forbidControl"
Что-то вот подобное предполагается.

А в структуру и идеологию ядра системы я ничего платформенно-зависимого закладывать не хочу.
У меня подход такой:
Компоненты имеют аттрибуты (a-la CORBA attributes).
Это - абстракция на уровне XML-описания компонента, которой соответствуют методы установки/чтения в С++ классе компонента.
Этими аттрибутами компоненты связываются друг с другом. Аттрибуты могут быть различных типов: long, string, double, complex...
Главное, чтобы совпадали по типам - иначе выбросится исключение и куда-то в диагностическую подсистему запишется сообщение об ошибки в конфигурации "Несовпадение типов аттрибутов".
Таким я вижу стандартный (поддерживаемый движком SCADA) механизм взаимодействия компонентов.
Однако, компоненты - обычные С++ классы и, конечно, могут взаимодействовать друг с другом и другими средствами: через указатели, ссылки, с помощью сторонних библиотек (CORBA та же) - т.е. в этом смысле программист не ограничен.
Спасибо сказали:
mrcashe
Сообщения: 18

Re: SCADA под Linux

Сообщение mrcashe »

Может где-то можно поподробнее почитать про такую идеологию?

К сожалению, пока только здесь. Вообще-то, такую "идеологию" я закладываю не с целью создать SCADA систему, а скорее, создать средство IPC как альтернативу CORBA.

Вопрос "после первого прочтения": вот у Вас закладываются красивые Unix-подобные решения.
А если придётся портировать систему на платформу, куда такие механизмы просто так не перенесёшь?


Ну, ничего такого страшного! Ведь на самом деле разрешением имён и поиском компонент будет заниматься не ядро, а демон (он же сервис). Его возможно портировать, но я не горю желанием привинчивать его к винде. На Unix же это очень просто делается при помощи fuse (Filesystem in User SpacE). К тому же, это вовсе не так обязательно - выводить пространство имён SCADA в пространство ФС. То есть, всегда есть возможность воспользоваться функциями API данного гипотетического пакета, у которого и названия ещё нет. Портировали же GTK на WINAPI.

Вот у него и прописывается что-то вроде: from="timer.sec" to="*.tick"


Если представить, что система смонтирована, то структурированные компоненты будут представлены в виде каталогов. В каталоге может находиться файл с именем tick. Тогда берём в руки /bin/sh и пишем:
# find /scada -name "*.tick" -exec echo "1" > '{}' ';'
Если на системе нет /bin/sh (Windows), пользуемся API.
Да, конечно, идеология несколько другая. Всё дело в том, что состав методов объектов фиксирован. Можно только перегружать существующие, но невозможно вводить дополнительные.

А в структуру и идеологию ядра системы я ничего платформенно-зависимого закладывать не хочу.


Идеология может слабо зависеть или вовсе не зависеть от ОС. Файлы - они на любой платформе файлы. И даже в вындовс есть аналог вызова ioctl(). А вот реализация, безусловно, будет различной. Сетевые системы разные, библиотеки многопоточности - тоже.

Ну, на сегодня хватит, поехал я домой, ибо у нас уже вечер.
Спасибо сказали:
Zoro
Сообщения: 4

Re: SCADA под Linux

Сообщение Zoro »

интересное решение, я за этот проект всеми руками за...
Спасибо сказали:
Аватара пользователя
Zeus
Сообщения: 694

Re: SCADA под Linux

Сообщение Zeus »

Zoro писал(а):
15.04.2007 00:02
интересное решение, я за этот проект всеми руками за...

За какое именно решение?
С файловой системой /scada?
Спасибо сказали:
Аватара пользователя
t.t
Бывший модератор
Сообщения: 7390
Статус: думающий о вечном
ОС: Debian, LMDE

Re: SCADA под Linux

Сообщение t.t »

Zeus писал(а):
05.04.2007 18:17
на narod.ru
Позвольте один совет: если надумаете уже что-либо размещать, то "ты туда не ходи, ты сюда ходи" (© все знают) -- на sourceforge.net, место гораздо более подходящее для OpenSource-проекта.

Кстати, тема приняла такой оборот, что явно ей место в "проектах форума". Zeus, переношу?
¡иɯʎdʞ ин ʞɐʞ 'ɐнɔɐdʞǝdu qнεиж
Спасибо сказали:
Аватара пользователя
Zeus
Сообщения: 694

Re: SCADA под Linux

Сообщение Zeus »

t.t писал(а):
15.04.2007 21:28
Позвольте один совет: если надумаете уже что-либо размещать, то "ты туда не ходи, ты сюда ходи" (© все знают) -- на sourceforge.net, место гораздо более подходящее для OpenSource-проекта.

Хорошо. Посмотрю в сторону sourceforge.

t.t писал(а):
15.04.2007 21:28
Кстати, тема приняла такой оборот, что явно ей место в "проектах форума". Zeus, переношу?

Я её изначально там думал разместить, но мне местные темы показались какие-то "не программёрские".
Не будет так, что там на неё программёры "забьют"? Ну, точнее, не увидят, не обратят внимание и т.п.?

А так, в общем - я не против переноса.
Спасибо сказали:
Аватара пользователя
t.t
Бывший модератор
Сообщения: 7390
Статус: думающий о вечном
ОС: Debian, LMDE

Re: SCADA под Linux

Сообщение t.t »

Zeus писал(а):
15.04.2007 22:04
Не будет так, что там на неё программёры "забьют"? Ну, точнее, не увидят, не обратят внимание и т.п.?
Так я перенесу так, что в этом разделе ссылка останется.

Zeus писал(а):
15.04.2007 22:04
А так, в общем - я не против переноса.
Тогда поехали.
¡иɯʎdʞ ин ʞɐʞ 'ɐнɔɐdʞǝdu qнεиж
Спасибо сказали:
polyakstar
Сообщения: 2
ОС: ubuntu

Re: SCADA под Linux

Сообщение polyakstar »

Zeus писал(а):
15.04.2007 22:04
Тогда поехали.


а можно отписаться в форум или в личку куда поехали? заинтересовало. хотел бы следить за вашим проектом.
Спасибо сказали:
Аватара пользователя
Zeus
Сообщения: 694

Re: SCADA под Linux

Сообщение Zeus »

Проект движется неприлично медленно ввиду полного отсутствия личного времени: работа, ремонт дома, ожидание пополнения семейства - чаще всего удаётся только поспать.

Продумываю взаимодействие компонентов, чтобы оно было надёжным, устойчивым от ошибок программистов.
Читаю книги по проектированию ООП.

Короче, пока предъявить нечего.
Спасибо сказали:
gordboris
Сообщения: 3
ОС: Windows

Re: SCADA под Linux

Сообщение gordboris »

Реализовал я нечто в чем-то похожее. Модуль-драйвер на java. Считывает с модулей удаленной перефирии фирмы (ICPCON) I70.. Пишет\читает базу MySQL. php(Apache) пишет\читает\отображает данные из базы. Кроме того в этом же модуле реализован SoftPLC. Т.е по факту у меня получился эдакий распределенный SoftPLC. Хотелось бы примкнуть к реализации вашего проекта. У вас задумки, конечно крутые, но наверно сложно реализовать будет. У вас уж больно глобальный замах. Может лучше отладить что есть. Степень общей завершенности 50%. Делал все под виндой. Но с замахом на независимость от ОС. В процессе понял что надо не свой модуль-драйвер писать, а использовать ОРС интерфейс(сервер). А вот свой SoftPLC это полезно. Готов к сотрудничеству и дискуссии. Кстати проекты FreeSCADA и LinuxSCADA похоже мертвы.
Спасибо сказали:
Аватара пользователя
Subj
Сообщения: 151
Статус: Useful
ОС: win

Re: SCADA под Linux

Сообщение Subj »

http://avts.ru/ - так, на всякий случай (не реклама если что).
Building better software with Ada
Спасибо сказали:
gordboris
Сообщения: 3
ОС: Windows

Re: SCADA под Linux

Сообщение gordboris »

Subj писал(а):
28.02.2008 11:09
http://avts.ru/ - так, на всякий случай (не реклама если что).

Да, интересно. Все о чем я могу только мечтать.
Спасибо сказали:
Аватара пользователя
Subj
Сообщения: 151
Статус: Useful
ОС: win

Re: SCADA под Linux

Сообщение Subj »

gordboris писал(а):
28.02.2008 12:16
Subj писал(а):
28.02.2008 11:09
http://avts.ru/ - так, на всякий случай (не реклама если что).

Да, интересно. Все о чем я могу только мечтать.


http://www.osp.ru/os/1999/09-10/177813/

интересная статья, ссылку вырыл на том же автс
Building better software with Ada
Спасибо сказали:
gordboris
Сообщения: 3
ОС: Windows

Re: SCADA под Linux

Сообщение gordboris »

Subj писал(а):
28.02.2008 12:43
gordboris писал(а):
28.02.2008 12:16
Subj писал(а):
28.02.2008 11:09
http://avts.ru/ - так, на всякий случай (не реклама если что).

Да, интересно. Все о чем я могу только мечтать.


http://www.osp.ru/os/1999/09-10/177813/

интересная статья, ссылку вырыл на том же автс

Да, спасибо почитал. Мне больше понравилась реализация KURT. Сайт проекта KURT
Последнее обновление 2005 года, для ядра 2.4.18. А какое у нас последнее стабильное?
Спасибо сказали:
polyakstar
Сообщения: 2
ОС: ubuntu

Re: SCADA под Linux

Сообщение polyakstar »

Zeus писал(а):
14.12.2007 19:44
Проект движется неприлично медленно ввиду полного отсутствия личного времени: работа, ремонт дома, ожидание пополнения семейства - чаще всего удаётся только поспать.

Продумываю взаимодействие компонентов, чтобы оно было надёжным, устойчивым от ошибок программистов.
Читаю книги по проектированию ООП.

Короче, пока предъявить нечего.

Предъявляй что есть. хоть идеи, общую концепцию.
Готов предоставить хост под проект, возможно, в силу своих умений, поучаствовать - но только если проект будет живой.
Спасибо сказали:
xlps
Сообщения: 1

Re: SCADA под Linux

Сообщение xlps »

Реально работающая система:

www.linux.org.ru/view-message.jsp?msgid=1745120
www.linux.org.ru/view-message.jsp?msgid=1991292

Модульная структура, связь через IPC, slot
Нижний уровень: Linux, C/C++, Qt
Верхний Linux, PHP, Apache, ImageMagick
БД - бинарные файлы
Обмен данными между уровнями - Modbus/TCPIP

Кому интересно, могу поделиться.
Спасибо сказали:
l669
Сообщения: 1

Re: SCADA под Linux

Сообщение l669 »

Вот еще по теме Linux и SCADA http://s3.com.ua Правда нижний уровень пока только под QNX. Но авторы обещают, что могут перенести , куда угодно - он написан на ANSI C вообще.
Спасибо сказали:
Аватара пользователя
Zeus
Сообщения: 694

Re: SCADA под Linux

Сообщение Zeus »

Значит так.

1. Показывать чего-то работающего - нечего: занимался ремонтом, новорождённым ребёнком :) , программными экспериментами, изучал околоАСУТПшные вопросы.
2. Сейчас решил вернуться к SCADA и начать всё сначала, но "с участием общественности".

Итак, рабочее название проекта: Jupiter.
Обсуждаем концепцию проектирования и для начала - пространный документ: Основные положения
Задавайте вопросы, предлагайте дополнения и уточнения.

Сейчас готовится более предметный и интересный документ: "Направления разработки".
Спасибо сказали:
Аватара пользователя
Expert
Сообщения: 73
ОС: Slackware Linux 14.1

Re: SCADA под Linux

Сообщение Expert »

я вот пока доковыриваю openSCADA котоая Савоченко, поставил 0.6.1 версию пока норм,все устраивает... правда не то все ж, и глюки есть.
Все глюки Windows исправляются установкой Linux
Спасибо сказали:
mke61
Сообщения: 1
ОС: Linux

Re: SCADA под Linux

Сообщение mke61 »

Здравствуйте! Мои 5 копеек.... :-)
По поводу выбора языков программирования... Может поздно - но "лучше поздно чем никогда"(с).... :-)
Есть компромисс между обоими взглядами - язык vala - это что то вроде "native C#" - пишешь на аля C# - на выходе код "Сишный" и нативный для конкретной ОС.... Очень удобно... Просто С# действительно хороший вариант... Резко увеличивается скорость разаработки - имхо...
Спасибо сказали:
MiK13
Сообщения: 1164
ОС: Linux Debian

Re: SCADA под Linux

Сообщение MiK13 »

Здравствуйте!
Натолкнулся на эту тему и она меня заинтересовала. Но пока ничего конкретного сказать не могу. Попытаюсь поизучать материал по ссылкам, которые были приведены в этой теме. Хотя бы потому, что пока даже не представляю, что должно быть в такой системе и для чего это вообще нужно.
А заинтересовало меня это потому, что ещё около 15 лет назад наш отдел начал делать что-то подобное. Делали, правда, не один год, но в результате внедрили в трёх местах. Про одно месте текущей информации нет, в двух других пока работает. В одном месте начальник потихоньку переводит её на айфикс. Там порядка 40 объектов, на которых, в совокупности, около 1400 аналогвых сигналов. Сколько дискретных -- не знаю, но, по-моему, больше. Возможно управление дискретными сигналами. Используется телемеханика 4-х типов.
В другом месте система скромнее -- 24 объекта, на которых (по данным марта 2000 года, но не уверен, что с тех пор что-то изменилось) 349 аналоговых сигналов и 475 дискретрых. Управления нет, только сбор и протоколирование информации. Всё это выполняется на "сервере", в качестве которого используется 486 80 МГц, 8 МБ. В качестве ОС стоит OSR2, но она используется только для доступа к файлам. Сама программа написана на Borland Pascal и работает в DOS разделе (в первом месте такая же программа, но из-за большого числа сигналов я вынужден был её делать для защищённого режима).
Отображается протоколы событий и текущее состояние (в виде мнемосхем) на других компьютерах. Для связи используется сеть Windows, а также протокол NetBIOS через IPX (14 лет назад это для нас был наиболее удобный вариант)
Когда стал доступен Linux у меня возникла мысль перенести на него эту систему с минимальными извенениями. Мне в нём понравилось наличие механизма сообщений, что позволяло, не меняя основной программы сбора информации, легко добавлять новые типы телемеханики (как я тогда слышал -- это была серьёзная проблема: подключить телемеханику нового типа). Но дальше размышлений дело не пошло. Хотя у меня и есть чувство, что если серьёзно заняться, то можно сделать аналогичную систему под Linux очень быстро. Причём такую, которая могла бы собирать информацию как с нескольких десятков точек на нескольких объектах, так и с нескольких десятков тысяч точек на паре сотен объектов. Но не похоже, что кому-то это нужно. Как сказал один начальник, проще купить iFIX, и стоить это ничего не будет, т.к. его цена уже заложена в перечень работ по развитию. Правда, я не очень представляю, во что обойдётся её изучение теми, кто будет на её основе делать конкретные системы. А также что в ней такого ценного.
Спасибо сказали:
Volckoff
Сообщения: 13
ОС: Windows XP Prof

Re: SCADA под Linux

Сообщение Volckoff »

Здравствуйте!

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

Основная идея - не "натягивать" идеи SCADA на требуемую ОС, а формализовать свойства и объекты ТОС, Реализовать ядро ТОС на общедоступных базовых протоколах и интерфейсах (не типа ОРС- DCOM).

Реализация - кроссплатформенная
Модель - распределенно-иерархическая.
Среда взаимодействия узлов - Ethernet (SCTP. UDP, TCP)

На практике получается компактно и довольно интересно.

Имеет смысл продолжать?
Спасибо сказали:
MiK13
Сообщения: 1164
ОС: Linux Debian

Re: SCADA под Linux

Сообщение MiK13 »

Volckoff писал(а):
19.05.2009 18:16
Имеет смысл продолжать?

Конечно
Спасибо сказали:
Volckoff
Сообщения: 13
ОС: Windows XP Prof

Re: SCADA под Linux

Сообщение Volckoff »

Темы:

1. Модель.
2. Структура
3. Организация взаимодействия "внутренняя"
4. Организация взаимодействия "внешняя"
5. Реализация отдельных подсистем

С чего начать?
Спасибо сказали:
MiK13
Сообщения: 1164
ОС: Linux Debian

Re: SCADA под Linux

Сообщение MiK13 »

Volckoff писал(а):
21.05.2009 11:07
Темы:

1. Модель.
2. Структура
3. Организация взаимодействия "внутренняя"
4. Организация взаимодействия "внешняя"
5. Реализация отдельных подсистем

С чего начать?

Ну начать можно с чего угодно :) Но логично именно в этом порядке. Только где и как это обсуждать? И как находить "общий знаменатель"?
Потому, что некоторое представление у меня по всем этим пунктам есть. Несколько лет назад я даже думал создать (точнее, перевести на линукс) ту версию, которая была уже внедрена в трёх местах. Правда, там, в основном был сбор данных, а управление -- только по командам оператора; выключить тот или иной дискретный сигнал. Но заказчикам тогда больше ничего и не нужно было.
Но система развиваться не стала. По причине того, что и заказов не было (развиваться предпочитале на основе систем типа i-Fix. Кроме того, начальник говорил, что основное условие -- должен быть OPC-серверю. А изучать его, да ещё в связи с линуксом, да ещё изучать многокилобаксовые системы у меня особого желания не было. И тематика работ потихоньку изменилась (хотя кое что и осталось).
Но я боюсь, что тут врядли может получиться что-нибудь серьёзное хотя бы потому, что у разных людей могут быть совершенно разные подходы к построению системы и найти "общий знаменатель" скорее всего, не получится.
Спасибо сказали:
Volckoff
Сообщения: 13
ОС: Windows XP Prof

Re: SCADA под Linux

Сообщение Volckoff »

Не найти "общий знаменатель" - это проблема сознания только конкретного человека. Многие не разбираются в аэродинамике, но это, с одной стороны, не мешает одним размышлять о самолетах, а с другой - не мешает спецам строить самолеты на основе вполне конкретных, опробованных на практике законов. У меня нет желания убеждать в правоте тех или иных выводов, которые я сделал. Разумна схема обсуждения - цель, способ достижения, довод, аргумент за, аргумент против. Лозунги типа "винды - говно" отбрасывают, в моём пространстве, изрёкшего за пределы восприятия. И, сразу надо оговориться, что есть "принципы построения" и есть конкретная реализация этих принципов. В конечном итоге все ОС построены на одних и тех же принципах, только вот реализации...

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

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

ПРИМЕЧАНИЕ: Возможна смешанная структура, но суть реализации этих систем различается ничтожно мало.

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

Пример:

TimeBlock: TimerOn(5000,OffBlock);
WaitBlock: Goto(WaitBlock); ;Ждать 5 сек

OffBlock: Block_RO.Command(OFF); ;Выключить блокир реле
Block_ESZ.Command(OFF);
SYTEM.SetState(AVOSTANOV);
DispCommand.Select(NONE);
goto(Deblock);

Это не интерпретатор, а функциональный процессор - одна инструкция - одна функция. Реализация - пара сотен строк кода.

Узлы должны быть реализованы на едином программном ядре (переносимость на уровне исходных кодов) возможно в разных аппаратных средах. Линукс здесь идеально подходит по многим параметрам, как "полигонная" система - для оттачивания функциональности.

Проработка модели системы на основе унификации объектов:

узел
параметр
событие

привело, например, к таким результатам, как единый ОРС-сервер на любую систему.

Возможность разносить и дублировать любой узел системы в рамках локальной сети.
Отсутствию специальных требований по объемам памяти и производительности контроллера

Унификации форматов хранения архивов (не путать с БД), да и БД тоже.
Потенциально - унификация графического представления разнородных систем на верхнем уровне. (Сколько в диспетчерских стоят разнокалиберных картинок на мониторах?).

Пока всё.

PS. А обсуждать можно и здесь. Тихо. Спокойно. Не люблю суеты... :rolleyes:
Спасибо сказали:
MiK13
Сообщения: 1164
ОС: Linux Debian

Re: SCADA под Linux

Сообщение MiK13 »

Volckoff писал(а):
22.05.2009 12:21
Не найти "общий знаменатель" - это проблема сознания только конкретного человека.
Может быть. Только что понимать под сознанием? Проблема может быть и в том, что ненахождение "общего знаменателя" (или пересечения множеств) может быть и из-за разного понимания того, что именно нужно (и для чего). А отсутствие пересечения может быть как и минусом, когда друг друга просто не понимают, так и плюсом, когда эти множества объединяют в одно.
Volckoff писал(а):
22.05.2009 12:21
Многие не разбираются в аэродинамике, но это, с одной стороны, не мешает одним размышлять о самолетах, а с другой - не мешает спецам строить самолеты на основе вполне конкретных, опробованных на практике законов.
Мне тут не нравится выражение "опробованных на практике законов". Законы надо не пробовать, а изучать. А пробовать и потом использовать на практике правила.
Volckoff писал(а):
22.05.2009 12:21
Разумна схема обсуждения - цель, способ достижения, довод, аргумент за, аргумент против.
Полностью согласен. Но тут есть одна проблема -- цель. Какая должна быть цель? И что под ней понимать?
Volckoff писал(а):
22.05.2009 12:21
Лозунги типа "винды - говно" отбрасывают, в моём пространстве, изрёкшего за пределы восприятия.
Я вообще не люблю лозунги. Предпочитаю конкретные предложения.
Volckoff писал(а):
22.05.2009 12:21
И, сразу надо оговориться, что есть "принципы построения" и есть конкретная реализация этих принципов. В конечном итоге все ОС построены на одних и тех же принципах, только вот реализации...
Это точно.

Опережу многие вопросы – я не пытаюсь открыть ничего нового. Я пытаюсь по-другому взглянуть на привычные вещи. Не хотелось ничего изобретать, а было желание собрать воедино решения из разных областей.
Volckoff писал(а):
22.05.2009 12:21
Итак. Модель. Объектная. Событийная. Сетка с узлами.
...

Пример:

TimeBlock: TimerOn(5000,OffBlock);
WaitBlock: Goto(WaitBlock); ;Ждать 5 сек

OffBlock: Block_RO.Command(OFF); ;Выключить блокир реле
Block_ESZ.Command(OFF);
SYTEM.SetState(AVOSTANOV);
DispCommand.Select(NONE);
goto(Deblock);

Это не интерпретатор, а функциональный процессор - одна инструкция - одна функция. Реализация - пара сотен строк кода.
Я не имел дела с подобными системами, поэтому ничего сказать не могу.
Volckoff писал(а):
22.05.2009 12:21
Проработка модели системы на основе унификации объектов:
узел, параметр, событие
привело, например, к таким результатам, как единый ОРС-сервер на любую систему.
Я когда-то пытался разбираться с OPC-сервером и ничего такого, что могло бы облегчить решение задач, которые требовались заказчику, я не обнаружил. За исключением того, что тогда можно было бы купить (за несколько кб) какую-то универсальную систему, на основе которой потом за несколько недель (а то и месяцев) можно было бы создать систему сбора и отображения информации на экране монитора.
Видимо, это связано с тем, что в тех местах, в которых мы делали такую систему, никакого автоматическиого управления не требовалось.
Система просто собирает информацию с нескольких десятков объектов, на каждом из которых от нескольких единиц, до нескольких сотен аналоговых и дискретных параметров. Система протоколирует все события: измерения значений аналоговых параметров, периодические измерения значений дискретных параметров (а также значения при их изменении), изменения зон аналоговых параметров (для каждого задаётся 6 границ: предупредительные, аварийные и достоверностные).
Это всё выполняется на отдельном компьютере. Все события архивируются в отдельные файлы, образующие недельный и годовой архивы (разбиты по суткам).
Диспетчер может просмотреть графики изменения любого параметра за любые сутки, а также протокол событий. Если событие аварийное (например, значение аналогового параметра вызодит за аварийную границу, или дискретный параметр принимает значение, объявленной аварийным), то выдаётся голосовое сообщение.
При просмотре архива событий возможна фильтрация по отдельным объектам, а также по типам событий: изменение границ, дискретные события, аварийные и т.д.
Также диспетчер имеет возможность посмотреть на мнемосхеме состояние любого объекта и значения аналоговых и дискретных параметров.
Оперетор также может: задать внеочередной опрос группы параметров, вручную ввести значение параметра, выдать команду на изменение значения дискретного параметра (при этом у него запрашивается пароль)... что-то ещё, что уже не помню.

Вот такую систему мы установили в трёх местах.
Никакого автоматического управления там не требовалось. А если и требовалось, то оно решалось на другом уровне (и не нами).
Поэтому я ничего не могу сказать о примере:

Код: Выделить всё

TimeBlock:    TimerOn(5000,OffBlock);
WaitBlock:    Goto(WaitBlock);        ;Ждать 5 сек

OffBlock:    Block_RO.Command(OFF);        ;Выключить блокир реле
        Block_ESZ.Command(OFF);
        SYTEM.SetState(AVOSTANOV);
        DispCommand.Select(NONE);
                goto(Deblock);

Потому, что тут, как я понимаю, идёт управление. А куда его можно "вставить", и, главное, кто его будет настраивать, я не представляю. Возможно, это какая-то часть более общей системы, и она будет использовать данные системы сбора и выдавать команды на управление... не знаю. По этой причине я и написал, что, возможно, не получится найти "общий знаменатель". Это с точки зрения пессимиста (который, понюхав руюку коньяку сказал, что он пахнет клопом). А с точки зреним оптимиста (который, понюхав раздавленного клопа сказал, что он пахнет коньяком) -- возможна независимая реализация разных элементов одной системы, которые потом можно будет собрать в одно целое.

По поводу почему мне понравился линукс (в том варианте, который у нас был реализован на DOSе). Мне в нём понравились очереди сообщений -- если появляется новая группа измеряемых параметров с телемеханики нового типа, то просто пишется новый демон, которые принимает данные и передаёт их общему цетру сбора информации. И его добавление никак не затрагивает остальные элементы системы.
По отображению -- можно передавать как конкретную информацию (во внутреннем представлении) на машины диспетчера и там отображать её любыми средствами, так и формировать web-страницы на центральном компьютере. А можно на нём же писать и простые программы, отображающие информацию на текстовом экране и просматривать её, подключившись по Telnet/SSH. А можно и иксовые программы запускать (об этом я думал только теоретически)
Спасибо сказали:
Ответить