Новые идеи, непонятные моменты и т.п.
| Автор |
Сообщение |
|
Сообщение создано: 27. 11. 2009 [14:59]
|
|
kuzulis
Денис Шиенков
Создатель темы
Зарегистрирован(а) с: 10.07.2009
Сообщения: 128
|
Доброго времени!
Сколько я ни читал документацию, ни пытался в никнуть в идею, ничего не получается что-то еще и у меня возникли непонятные аспекты icon_smile.gif
1. Непонятен (неявен) аспект конфигурирования отдельно рабочей станции и сервера.
2. Непонятен аспект места хранения конфигурации сервера и раб станции.
3. Непонятен аспект выполнения исполняемого файла.
Поясню
Я представлял архитектуру Open Scada как клиент - серверную и в случае использования имеющую один конфигурационный файл для всех типов задач (Пусть останется OScada.xml).
Т.е. с четко разделенной структурой на сервера и рабочие станции и разделил бы исполняемый файл на несколько штук:
1. Исполняемый файл чисто сервера, например: OScadaServer
1.1 При запуске этого файла он производит чтение конфигурационного файла OScada.xml в котором берет базовую информацию (точнее только часть информации предназначенной только для него) о путях к БД конфигурации, Архивов, Алармах, логики работы, безопасности и т.п.
При этом пути могут быть как:
- локальные (путь к директории) - в файловой системе текущего сервера
- так и удаленные (IP адреса и порты) - т.е на других каких либо серверах и т.п..
Также в этом файле указывались бы:
- пути (адреса и порты) к другим серверам OScadaServer, а также их статусы (типа основной, резервный №1 , резервный №N) и другие характеристики
- пути (адреса и порты) сконфигурированных рабочих станций которые будут подключаться к серверу.
1.2 После чтения конфигурации - сервер создавал бы соответствующие струкруры данных, интерфейсы и т.п. и приступал бы к работе: сбору данных, анализу, архивированию, формированию данных и событий и отдаче их на рабочие станции по запросу последних или по мере поступления событий.
т.е. в БД сервера хранились бы все исчерпывающие данные обо всем!!!
1.3. Этот исполняемый файл был бы просто файлом-демоном (без ГУИ и т.п.) , который можно было запускать как на встраиваемых системах, так и на мощных серверах.
1.4. Также этот файл при своем запуске "поднимал" бы все необходимые интерфейсы, включая Self для обмена данными с рабочими станциями и конфигуратором (см. ниже)
2. Для конфигурирования конфигурации сервера и алгоритмов его работы, например: OScadaServerConfigurаtor
2.1 При запуске этого файла он производит чтение конфигурационного файла OScada.xml из которого берет базовую информацию (точнее только часть информации предназначенной только для него) о путях к а IP адресам серверов.
т.е если и конфигуратор и сам сервер запущены на одной машине - то файл OScada.xml может быть один для всех.
2.2 При этом этот конфигуратор может (должен) иметь ГУИ. Здесь гуй, а также сам файл может быть выполнен на любом фреймворке, хоть на Qt4, хоть Java, хоть GTK и под любым компилятором и языком и т.п. , но по умолчанию к примеру сделать на Qt4 (как и есть сейчас)
2.3. При запуске - конфигуратор коннектится к серверам и отображает все найденные сервера, их режимы, статусы и прочее что необходимо.
2.4. Для конфигурирования серверов конфигуратор общается с выбранным сервером посредством протокола Self, давая серверу команды на создание новых точек в БД и т.п. и т.д.
2.5. Через конфигуратор можно также было бы управлять за работой серверов, менять их приоритеты и т.п. и т.д.
3. Для конфигурирования и работы рабочей станции, например OScadaWorkStation
3.1. Тут в принципе можно было бы его тоже поделить на 2 части: на исполняемый файл среды визуализации и исполняемый файл среды конфигурирования визуализации.
3.2. При запуске OScadaWorkStation - происходило бы опять же чтение того же конф. файла OScada.xml, из которого бралась бы БАЗОВАЯ информация о путях к серверам, другим станциям, путям к БД виджетов и т.п.
-----------------------
т.е ИМХО, не нужно весь функционал пихать в один исполняемый файл openscada (как это сделано сейчас), при этом бы был выигрыш для разработки. И т.п. т.к. каждый разработчик пилил бы "свою" часть.
Вот в принципе я думал о таких концепциях Open Scada. о распределенных и т.п.
Сие мое сочинение не претендует на полноту, т.к. это просто общие, базовые вещи - с моей точки зрения видения проекта icon_smile.gif
т.к. в теперешнем/существующем состоянии проекта существует очень большой фактор непонятности, запутанности, неочевидности некоторых моментов и т.п.
во всей документации я не нашел информации, которая смогла бы как-то прояснить весь процесс взаимодействия основных модулей и т.п. и т.д. Комментариев в исходном коде очень мало и они неочевидны вообще, т.е. код трудно читать и воспринимать, тем более, некоторые переменные названы и сокращены до неузнаваемости и непонимания их сути. Вы уж извините, но для меня это так!
Комментарии в стиле Doxygen очень были бы кстати!!!
ЗЫ: все что я предложил/представил/предположил выше (концепцию и мое вИдение проблемы) относится только к режимам без WEB доступа
ЗЫЗЫ: жду комменариев
ЗЫЗЫЗЫ: я хочу помочь проекту чем могу, но очень тяжело, т.к. концепции и видение "мира" не очень совпадают с мнением авторов и от этого еще тяжелее icon_smile.gif
|
|
Сообщение создано: 27. 11. 2009 [15:44]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
kuzulis wrote:
Я представлял архитектуру Open Scada как клиент - серверную и в случае использования имеющую один конфигурационный файл для всех типов задач (Пусть останется OScada.xml).
Т.е. с четко разделенной структурой на сервера и рабочие станции и разделил бы исполняемый файл на несколько штук:
OpenSCADA гараздо гибче и имеет более прогрессивную архитектуру, а именно распределённую.
В конфиге и так можно хранить конфигурацию разных станций и поделить можно как угодно.
kuzulis wrote:
во всей документации я не нашел информации, которая смогла бы как-то прояснить весь процесс взаимодействия основных модулей и т.п. и т.д. Комментариев в исходном коде очень мало и они неочевидны вообще, т.е. код трудно читать и воспринимать, тем более, некоторые переменные названы и сокращены до неузнаваемости и непонимания их сути. Вы уж извините, но для меня это так!
Комментарии в стиле Doxygen очень были бы кстати!!!
А не мальнького документа API Вам не достаточно: http://wiki.oscada.org/Doc/API ?
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 27. 11. 2009 [16:02]
|
|
kuzulis
Денис Шиенков
Создатель темы
Зарегистрирован(а) с: 10.07.2009
Сообщения: 128
|
OpenSCADA гараздо гибче и имеет более прогрессивную архитектуру, а именно распределённую.
В конфиге и так можно хранить конфигурацию разных станций и поделить можно как угодно.
Дык зачем тогда одни бинарик на всё?
Я тоже про распределенную конфигурацию говорю.
Неочевидно же всё!
Вот пример:
1. Установить "сервер" на у-во типа MOXA UC7400 , т.е. весь сбор данными и т.п. выполняет этот девайс. (малый объем флэш памяти)
2. БД архивов, трендов и т.п. хранить на другом уже "нормальном" сервере .
3. Рабочую станцию организовать еще на отдельном АРМ
т.е. в итоге должно быть три кампа: UC7400, Сервер БД, АРМ
Как такая конфигурация будет выполнена? А?
В текущем состоянии это неочевидно вообще! (ИМХО)
А вы думаете это очень удобно? Просматривать код и переключаться в документацию в браузер??
тем более, сразу забывается то что только что посмотрел из-за переключения внимания и теряется связь (цепочка) между тем что видел до этого 
ИМХО, проще сразу в коде видеть что и кто есть!
[Сообщение редактировалось 1 раз(а), в последний раз 27.11.2009 в 16:04.]
|
|
Сообщение создано: 27. 11. 2009 [16:19]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
kuzulis wrote:
OpenSCADA гараздо гибче и имеет более прогрессивную архитектуру, а именно распределённую.
В конфиге и так можно хранить конфигурацию разных станций и поделить можно как угодно.
Дык зачем тогда одни бинарик на всё?
А зачем потом решать неочевидные проблемы производительности и взаимодействия в отдельных бинарниках?
kuzulis wrote:
Неочевидно же всё!
К сожалению OpenSCADA не решает проблем отсутствия фантазии и воображения отдельных пользователей.
kuzulis wrote:
Вот пример:
1. Установить "сервер" на у-во типа MOXA UC7400 , т.е. весь сбор данными и т.п. выполняет этот девайс. (малый объем флэш памяти)
у меня сейчас подобное завёрнуто в прошивку PLC размером в 30Мб вместе с ОС. Что я сделал не так?
kuzulis wrote:
2. БД архивов, трендов и т.п. хранить на другом уже "нормальном" сервере .
3. Рабочую станцию организовать еще на отдельном АРМ
И это у меня отдельно. Что опять не так?
kuzulis wrote:
т.е. в итоге должно быть три кампа: UC7400, Сервер БД, АРМ
Как такая конфигурация будет выполнена? А?
Абсолютно просто. Если бы Вы не отвергали RPM, а глянули как сейчас собирается OpenSCADA, то вы бы поняли. А там есть как раз три виртуальных пакета, которые ставят только то что нужно для конкретного случая, а именно:
- openscada-plc - для контроллеров, среда исполнения.
- openscada-server - для SCADA-сервера.
- openscada-visStation - визуальная SCADA-станция.
kuzulis wrote:
А вы думаете это очень удобно? Просматривать код и переключаться в документацию в браузер??
тем более, сразу забывается то что только что посмотрел из-за переключения внимания и теряется связь (цепочка) между тем что видел до этого
ИМХО, проще сразу в коде видеть что и кто есть!
А плохому танцору Вы вкурсе что мешает?!
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 27. 11. 2009 [17:41]
|
|
kuzulis
Денис Шиенков
Создатель темы
Зарегистрирован(а) с: 10.07.2009
Сообщения: 128
|
А зачем потом решать неочевидные проблемы производительности и взаимодействия в отдельных бинарниках?
К сожалению OpenSCADA не решает проблем отсутствия фантазии и воображения отдельных пользователей.
Ну вот смотрите:
допустим все девайсы (что я привел выше) с нуля. И я с нуля собираюсь создать проект.
Проект я буду создавать к примеру с ноутбука, который включу в сеть Eth.
1. Предварительно я скопировал исполняемый файл scadaServer в MOXA и файл scadaWorkStation на АРМ.
Потом беру и устанавливаю на ноут конфигуратор scadaServerConfigurator.
2. Запускаю на MOXA программу-сервер с нуля, без конфига. При этом она создает пустой конфиг у себя и ждет подключения конфигуратора по сети.
3. Запускаю на ноуте конфигуратор-сервера. В менюшке ввожу IP адрес сервера(MOXA). Коннекчусь. При успехе в конфигураторе отображается информация о том что проект пустой и другая служебная инфа о состоянии сервера.
4. В конфигураторе сервера перехожу в режим создания проекта. т.е. создаю имя проекта, транспорты, алгоритмы выполнеия и контроля процесса , пути к серверу БД архивов, трендов и т.п. (т.е. ввожу IP адрес сервера БД), тэги, и т.д. и т.п.
При этом сервер MOXA создает у себя в конф файле нужные ему настройки , а также создает у себя БД с нужной конфигурацией проекта.
5. Потом в ноуте жмакаю что-то типа "запустить сервер" - и смотрю как пошел процесс работы сервера , могу просмотреть тэги и т.п. при необходимости, правильно или нет они читаются и т.п., правильно ли МОХА опрашивает удаленные устройства к примеру по Modbus, Eth и т.п.
Смотрю, правильно ли отображаются тревоги, как идет запись данных в сервер БД и т.п.
6. Если все хорошо - то отключаю ноутбук .. т.к. он больше не нужен.
6. Потом на АРМ запускаю конфигуратор визуализации, прописываю путь в менюшке к серверу MOXA, коннекчюсь к нему.
7. Далее импортирую с сервера тэги и т.п.
8. Далее Рисую мнемокадры и привязываю к тэгам и т.п. В общем рисую визуализалку.
9. При этом конфигуратор визуализации создает конф. файл + создает там где я ему задал БД и т.д.
10. Если все ОК - то запускаю визуализатор..
11.. ВСЁ .. Проверяю - работает он или нет....
Вот так я предполагал примерно процесс создания проекта (в общем)
у меня сейчас подобное завёрнуто в прошивку PLC размером в 30Мб вместе с ОС. Что я сделал не так?
трололо, а у меня в кармане гвоздь.. Вы считаете, той инфы, что Вы сейчас написали достаточно для других? Это Вам может быть все понятно. Так что не нужно заниматься "трололо" - а говорите по делу, как, что, нужно делать с НУЛЯ!
И это у меня отдельно. Что опять не так?
Где? Я не вижу!!!
Абсолютно просто. Если бы Вы не отвергали RPM, а глянули как сейчас собирается OpenSCADA, то вы бы поняли. А там есть как раз три виртуальных пакета, которые ставят только то что нужно для конкретного случая, а именно:
- openscada-plc - для контроллеров, среда исполнения.
- openscada-server - для SCADA-сервера.
- openscada-visStation - визуальная SCADA-станция.
Причем тут RPM ?
Что нужно? Напишите отдельно конкретно - что нужно сувать в тот или иной пакет, подробно что и зачем!
В чем разница среды исполнения от сервера и от станции?
Ведь по сути - это все один и тот же исполняемый бинарик. В *.xml файле?
А плохому танцору Вы вкурсе что мешает?!
трололо. А хороший программист, если хочет, чтобы и другие поняли что он там "накодил" - комментирует свое творение прямо в коде. А если код пуст - то никакого желания и настроения нету разбираться.
---
Ну да, куда уж нам, обычным смертным...
|
|
Сообщение создано: 27. 11. 2009 [18:14]
|
|
almaz
Almaz Karimov
Contributor
Зарегистрирован(а) с: 25.09.2008
Сообщения: 516
|
to kuzulis:
Вы не совсем правильно поняли концепцию OpenSCADA. Это не просто клиент-серверная архитектура в обычном понимании. Это сеть распределённых вычислений.
И как эта сеть будет работать решаете только Вы. Зависит от того какие буковки будете вбивать в полях настроек .
Каждый комп сети может быть и сервером, и ПЛК, и АРМ одновременно. А деление на сервер, АРМ, ПЛК на разных компах условно.
Допустим имеем Ethernet-сеть с n-ым количеством компьютеров. На каждом запущена OpenSCADA.
1. Любой комп может хранить свою конфигурацию в БД на любом из компов сети (включая себя ). Если воспользоваться сетевой файловой системой nfs можно даже файл конфигурации хранить на любом другом.
2. С любого компа можно отразить (зеркалировать) его данные на любой другой посредством шлюза DAQGate.
3. С любого компа можно настраивать дерево OpenSCADA любого другого. И всех одновременно.
4. С любого компа можно отобразить визуализацию любого другого. И себя. И нескольких одновременно.
5. Ну и много чего еще...
Самое главное следить чтобы не образовалось "колец" связей, "рекурсии". Хотя может и это будет работать.
И всё это делает великий протокол Self.
PS Так что та последовательность действий, которую Вы написали выше правильна. Как и множество других возможных.
PS И замените мышку. У Вас похоже колёсик сломан. Слишком быстро прокручивает Вики и Вы не успеваете понять суть  .
[Сообщение редактировалось 2 раз(а), в последний раз 27.11.2009 в 18:23.]
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Сообщение создано: 27. 11. 2009 [19:13]
|
|
almaz
Almaz Karimov
Contributor
Зарегистрирован(а) с: 25.09.2008
Сообщения: 516
|
В связи с тем, что тема называется "Новые идеи..." добавлю кое-что. Давно собирался написать.
В настоящее время слои между железом (материя) и пользователем (разум) представляют следующую картину:
железо - драйверы - операционная система - пользовательская программа - пользователь
Делаю смелое заявление, что OpenSCADA может стать началом возникновения дополнительного слоя. Для этого слоя операционная система будет представлять своеобразный "драйвер" к одной единице оборудования:
железо - драйверы - операционная система - OpenSCADA - пользовательская программа - пользователь
Конечно, нужны компы побыстрее, но в этом направлении технологии продвигаются безостановочно.
PS Уже сейчас OpenSCADA представляет своеобразную "операционную систему" для сети компьютеров.
[Сообщение редактировалось 1 раз(а), в последний раз 27.11.2009 в 19:19.]
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Сообщение создано: 27. 11. 2009 [20:15]
|
|
kuzulis
Денис Шиенков
Создатель темы
Зарегистрирован(а) с: 10.07.2009
Сообщения: 128
|
Вы не совсем правильно поняли концепцию OpenSCADA. Это не просто клиент-серверная архитектура в обычном понимании. Это сеть распределённых вычислений.
И как эта сеть будет работать решаете только Вы. Зависит от того какие буковки будете вбивать в полях настроек icon_smile.gif .
Каждый комп сети может быть и сервером, и ПЛК, и АРМ одновременно. А деление на сервер, АРМ, ПЛК на разных компах условно.
Допустим имеем Ethernet-сеть с n-ым количеством компьютеров. На каждом запущена OpenSCADA.
1. Любой комп может хранить свою конфигурацию в БД на любом из компов сети (включая себяicon_smile.gif ). Если воспользоваться сетевой файловой системой nfs можно даже файл конфигурации хранить на любом другом.
2. С любого компа можно отразить (зеркалировать) его данные на любой другой посредством шлюза DAQGate.
3. С любого компа можно настраивать дерево OpenSCADA любого другого. И всех одновременно.
4. С любого компа можно отобразить визуализацию любого другого. И себя. И нескольких одновременно.
5. Ну и много чего еще...
Самое главное следить чтобы не образовалось "колец" связей, "рекурсии". Хотя может и это будет работать.
И всё это делает великий протокол Self.
ну это всЁ НЕЯВНО!!! это понятно, что нет ничего невозможного! Но я в конфигураторе не нашел нигде упоминания о IP адресах этих самых узлов/станций в сети !
И опять же. Каким образом в моем случае например (см. ту конфу что я привел выше) сконфигурировать MOXA ТС7400 ?
Ну кину я туда бинарик, ну кину конф. файл(с каким содержимым??) по FTP . Ну запущу бинарик по ssh. А как сконфигурировать дальше то?
Как проверить что оно работает так как нужно?
MOXA 7400 (и т.п.) - это встраиваемый комп на процессоре ARM , который имеет 2хEth порта + 8 serial портов. (такая маленькая коробочка)
Ну и как я его буду дальше конфигурировать? Каким образом? И что должно быть (начальная информация) в конфиге в /etc MOXA?
Вот эти начальные моменты вызывают трудности. 
|
|
Сообщение создано: 27. 11. 2009 [21:48]
|
|
almaz
Almaz Karimov
Contributor
Зарегистрирован(а) с: 25.09.2008
Сообщения: 516
|
Всё задаётся ЯВНО!
В ветке дерева Вашего компа "Транспорты" (в самом корне ветки) вбиваете все компы Вашей сети.
Далее в ветке "Пользовательские интерфейсы" - "Рабочий пользовательский интерфейс" выбираете хост для конфигурирования и всё! Это нужно для того, чтобы местный интерфейс работал для удаленного компа.
В конф-файле достаточно указать с какой БД грузить конфигурацию OpenSCADA данного компа. Там же и IP.
Вместо конф-файла можно подсунуть ссылку на файл по nfs.
PS По ssh не надо запускать. Лучше сконфигурьте демоном с автозапуском при загрузке. Длительной работы по ssh не будет. Проверено!
PSPS А под ARM уже запустили OpenSCADA? А какая ось? Debian иль Gentoo? Или Вы хотите чтобы бинарник под Intel пошёл под ARM?
PSPSPS Что-то слабоват Моха для серьёзных задач. Для простых подойдет. Обязательно следите за нагрузкой на проц. Если, конечно, OpenSCADA на нём работает .
[Сообщение редактировалось 3 раз(а), в последний раз 27.11.2009 в 22:36.]
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Сообщение создано: 28. 11. 2009 [08:32]
|
|
almaz
Almaz Karimov
Contributor
Зарегистрирован(а) с: 25.09.2008
Сообщения: 516
|
Вопрос работы OpenSCADA на ARM довольно интересен.
Не нашёл ту железку, которую Вы указывали, но посмотрел MOXA UC-7410-LX Plus, универсальный коммуникатор с 8 портами RS-232/422/485, двумя 10/100 Ethernet, Linux OS 2.6
Её можно применить для ввода-вывода данных по последовательным каналам и для несложной обработки. Для более сложных задач слабоват.
Процессор Intel XScale серии PXA 27x. Архитектура ARM 5TE. Linux ядро 2.6, более ранние модели - ядро 2.4
Потребуется откомпилировать OpenSCADA на этой железке. Работа непростая, с возможными изменениями исходного кода OpenSCADA. Да и зависимости (доп пакеты) надо будет искать-собирать.
Может быть проще это выполнить на каком-нибудь эмуляторе ARM.
http://www.thefreecountry.com/emulators/arm.shtml
На английском форуме была начата работа по сборке OpenSCADA на ARM, но, видимо, до конца не доведена...
http://oscada.org/index.php?id=24&L=0&tx_mmforum_pi1[action]=list_post&tx_mmforum_pi1[tid]=87
[Сообщение редактировалось 1 раз(а), в последний раз 28.11.2009 в 08:50.]
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
|
