"Нестандартное" применение OpenSCADA
Начало | Назад | 3 | 4 | 5 |
| Автор |
Сообщение |
|
Сообщение создано: 11. 12. 2009 [09:03]
|
|
almaz
Almaz Karimov
Contributor
Создатель темы
Зарегистрирован(а) с: 25.09.2008
Сообщения: 516
|
roman wrote:
Так вот если нет глубоких знаний, то постарайтесь не обвинять OpenSCADA в проблемах которых на самом деле нет и при этом без тени сомнения сразу толкать "ценные" идеи как решать эти самые проблемы, которых нет.
То о чём речь на последних 3 листах темы - не мои идеи. Это нереализованные возможности Ваших идей.
Никак не можем получить выводы из этих рассуждений, так как рассматриваем их в неправильной последовательности.
Прошу рассмотреть в таком порядке:
1. Улучшение производительности высокочастотной обработки данных;
2. Улучшение надёжности до максимально возможной.
Роман, жду Вашего мнения по пункту 1.
По п.2 прошу вариант запуска нескольких OpenSCADA с различными наборами модулей не рассматривать, так как это частные случаи дублирования ПО на одном компьютере, рассмотренные в концепции.
Да и вообще, по п.2 обсуждение бессмысленно пока нет выводов по п 1. И правильно что закрыли тему в разделе "Отслеживание ошибок". Это не ошибка ПО, для отслеживания которых предназначен раздел. Правильно выбран Linux в качестве базовой, так как более развит и распространён. Про перенос на свободные микроядерные ОС не будет речи пока они не достигнут такого же развития и распространённости.
PS Прошу в этой теме выкладывать сообщения только по существу "поднятых тут дебрей". Обсуждение неисправных единиц железок, мелких багов и прочего можно начать в других темах.
[Сообщение редактировалось 5 раз(а), в последний раз 11.12.2009 в 09:23.]
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Сообщение создано: 11. 12. 2009 [10:40]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
almaz wrote:
1. Улучшение производительности высокочастотной обработки данных;
2. Улучшение надёжности до максимально возможной.
Роман, жду Вашего мнения по пункту 1.
Максимальной производительности можно добиться только при прямом и тесном взаимодействии отдельных компонентов, а значит это прямой доступ к структурам памяти и исключение всяких интерпретаторов. Первое это модульная архитектура OpenSCADA с тесной интеграцией компонентов, второе это C++, а не Java и иже с ними.
Кроме того, тесная интеграция, для получения максимальной производительности ни коим образом не препятствует использование тонких связей, в виде протокола SelfSystem, для повышений общей надёжности. Суть в том, что я выделяю компоненты требующие высокой производительности в отдельный процесс, изолируя его тем самым. А остальные компоненты выделяются в отдельные процессы по надобности, с взаимодействием всего посредством тонких связей.
almaz wrote:
По п.2 прошу вариант запуска нескольких OpenSCADA с различными наборами модулей не рассматривать, так как это частные случаи дублирования ПО на одном компьютере, рассмотренные в концепции.
Дублирование здесь вообще не причём. Возможность разноса это ключевой критерий надёжности тех самых микроядерных ОС, а именно взаимодействие посредством тонких связей.
А как в конечном счёте эти самые связи используются, толи для построения рассосредоточенной (или распределённой) системы, толи для повышения надёжности путём выноса рискованных компонентров в отделные процессы, толи для прямого резервирования это уже дело конкретной задачи пользователя, а значит и отдельной конфигурации системы.
В результате OpenSCADA позволяет решать как ресурсоёмкие задачи, так и задачи с высокой надёжностью, а значит концепция правильна. Вопрос только в степени всего этого, а значит в оптимизации внутренних механизмов взаимодействия, как для повышения производительности прямых механизмов и тонких связей, так и для повышения общей степени стабильности и надёжности.
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 11. 12. 2009 [11:29]
|
|
Aleksey
Aleksey Popkov
Contributor
Зарегистрирован(а) с: 31.07.2008
Сообщения: 326
|
Aleksey wrote:
Воспроизводиться падение из-за модбас.
Роман поправит ))))))))))
Прошу прощения за вмешательство, но раз уж сюда писал про падение ModBus, сюда да и дополню.
ModBus стабилизирован, ноги недавней баги, Роман вывернул.
|
|
Сообщение создано: 11. 12. 2009 [20:56]
|
|
almaz
Almaz Karimov
Contributor
Создатель темы
Зарегистрирован(а) с: 25.09.2008
Сообщения: 516
|
roman wrote:
Максимальной производительности можно добиться только при прямом и тесном взаимодействии отдельных компонентов, а значит это прямой доступ к структурам памяти и исключение всяких интерпретаторов. Первое это модульная архитектура OpenSCADA с тесной интеграцией компонентов, второе это C++, а не Java и иже с ними. Это в случае, если пользователь окажется программистом на С++. Самой максимальной производительности добьётся программист на Ассемблере без ОС на голом железе без вызова подпрограмм, учитывая каждый такт процессора и каждый бит информации (сам с этим работал).
Полностью согласен, что необходимо прямое и тесное взаимодействие отдельных компонентов.
А возможно повышение производительности при внесении алгоритма обработки высокоскоростных данных прямо в модуль DAQ, который выполняет ввод-вывод данных с железа? Или механизмы вызова из одного модуля процедур другого не оказывают значительного влияния на производительность?
Сам отвечу на последний вопрос: да, пока они в одном процессе.
Без п1 бессмысленно рассматривать п.2.
Я понял, что модули по разным процессам не растащить. OpenSCADA представляет из себя функционально дерево объектов с корнем в ядре. Для создания микроядерной программы необходимым условием является своё дерево объектов в каждом модуле и в ядре.
Ошибка в концепции в предложении с упоминанием нестабильности есть, только она другого рода.
Прошу открыть тему "Концепция" в разделе "Отслеживание ошибок" для редактирования. Там напишу.
[Сообщение редактировалось 2 раз(а), в последний раз 11.12.2009 в 22:02.]
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Сообщение создано: 11. 12. 2009 [22:46]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
- OpenSCADA не нужна микроядерная архитектура в чистом виде точка
- Концепция правильна и меня полностью устраивает точка
- При степени завершения здания на 90% фундамент (концепция) не меняется точка
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 11. 12. 2009 [22:57]
|
|
almaz
Almaz Karimov
Contributor
Создатель темы
Зарегистрирован(а) с: 25.09.2008
Сообщения: 516
|
Там всего лишь неверно указана причина возникновения опасности.
Если под тесной интеграцией модулей с ядром я правильно понимаю наследование объектами модулей атрибутов и кода объектов ядра, то так:
Тесная интеграция модулей с ядром обеспечивает дополнительную стабильность благодаря повторному использованию отлаженного кода.
А причины возникновения опасности нужны какие-то другие...
PS Именно это предложение в концепции и сбило меня с толку и я начал искать опасность там, где её нет. Оно и дальше будет вводить людей в заблуждение. А шансов поправиться в той теме Вы мне не даёте.
[Сообщение редактировалось 1 раз(а), в последний раз 11.12.2009 в 23:44.]
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Сообщение создано: 12. 12. 2009 [12:00]
|
|
Aleksey
Aleksey Popkov
Contributor
Зарегистрирован(а) с: 31.07.2008
Сообщения: 326
|
almaz wrote:
PS Именно это предложение в концепции и сбило меня с толку и я начал искать опасность там, где её нет. Оно и дальше будет вводить людей в заблуждение. А шансов поправиться в той теме Вы мне не даёте.
Ну Слава Богу достигнуто понимание.
|
|
Сообщение создано: 16. 12. 2009 [13:00]
|
|
mke61
Марат Капилов
Зарегистрирован(а) с: 16.12.2009
Сообщения: 1
|
almaz wrote:
В ветке "Новые идеи ..." возникла идея, что OpenSCADA - это "операционная система" для сети компьютеров.
Далее приведу несколько возможных применений OpenSCADA в данной роли.
1. У меня на рабочем столе постоянно находится виджет KDE4 "Системный монитор". Он показывает нагрузку на процессор, на сетевые интерфейсы, на жёсткий диск. Также показывает объем свободной оперативной памяти и кэша, температуру процессора и т.д.
А ведь на OpenSCADA можно сделать такой монитор в два счёта. И не просто для локальной машины, а для сети компьютеров, а также можно прицепить мониторинг UPS и других железок, работающих по SNMP.
OpenSCADA - просто находка для системных администраторов.
А можно же этими железками ещё и управлять ... 
2. На OpenSCADA можно реализовать игры (локальные на слабых компьютерах, использующих ресурсы других компьютеров сети для обсчёта игровой ситуации; сетевые многопользовательские игры без определённого центра-сервера и с равномерным распределением нагрузки на компьютеры сети и т.д.).
OpenSCADA может пригодиться даже игрокам, так как она хороший симулятор технологических процессов. А чем игра не технологический процесс?
Интересно, когда будет поддержка OpenGL в ОС OpenSCADA? 
3. В случае добавления некоторых функций в модуль "Специальные" возможно на OpenSCADA реализовать различные примочки для ОС, типа виртуальной клавиатуры, удаленного терминала и др.
4. В такой ОС понятие "файловая система" может уйти вглубь системы (например, как сейчас поток процесса), ведь все данные можно распределенно-резервированно хранить в сетевых БД.
5. .... Думайте сами ...
OpenSCADA может пригодиться ооочень широкому кругу пользователей!!! 
PS Сейчас в DAQ собираются драйвера, схожие с драйверами операционной системы. Сейчас они, в основном, представляют средства обмена данными с различным железом АСУТП. А ведь можно разрабатывать драйвера очень разные для разных случаев применения ...
PSPS Если на OpenSCADA написать сетевую игру (даже самую простейшую) и пустить в Интернет на оценку пользователей - пиар обеспечен!
Сорри, что влезаю - свои 5 копеек... 
Существуют 2 вроде(?! непересекающихся стандарта - OPC и WSMAN...
Оба предназначены вроде(?) для разных целей...
Так вот - судя по описанию OPENSCADA действительно может заменить их обоих...
|
|
Сообщение создано: 17. 12. 2009 [08:25]
|
|
almaz
Almaz Karimov
Contributor
Создатель темы
Зарегистрирован(а) с: 25.09.2008
Сообщения: 516
|
roman wrote:
- OpenSCADA не нужна микроядерная архитектура в чистом виде точка Полностью согласен - не нужна. Так как микроядерная архитектура и так есть в чистом виде в режиме выполнения OpenSCADA (микроядро пишется самим пользователем в shell или JavaLikeCalc). Принято.
roman wrote:
- Концепция правильна и меня полностью устраивает точка То есть чтобы что-то было изменено оно должно перестать устраивать Вас. Принято.
roman wrote:
- При степени завершения здания на 90% фундамент (концепция) не меняется точка На ПО в отличие от зданий не действуют силы тяготения. Но тоже согласен, так как концепция правильна. Принято.
Aleksey wrote:
Ну Слава Богу достигнуто понимание. А поняли в чём была ошибка? В том, что я пытался приладить архитектуру режима исполнения (микроядерную) к внутренней архитектуре исходного кода OpenSCADA. Но я был направлен на эту ошибку не сам... И никто не поправил... Самому пришлось дойти.
mke61 wrote:
Существуют 2 вроде(?! непересекающихся стандарта - OPC и WSMAN...
Оба предназначены вроде(?) для разных целей...
Так вот - судя по описанию OPENSCADA действительно может заменить их обоих... Кроме этих ещё море узкопрофильных протоколов и программ. Но тут ещё надо "утрясти" кое-какие "концептуально-ядерные" нюансы (недокументированные возможности).
roman wrote: almaz wrote:
OpenSCADA удовлетворяет всем условиям написания безошибочного кода, так как представляет из себя микроядерную модульную программу. Вот оно - доказательство надёжности OpenSCADA. Более подробно в книге: Таненбаум Э.,Вудхалл А. Операционные системы. Разработка и реализация. 3-е изд. Питер. 2007г. 704с.
У меня на компьютере микроядро OpenSCADA (/usr/bin/openscada) занимает всего 12907 байт!!! Интересно сколько строк (приблизительно) на С++ это составляет?
Даже я никогда не говорю про абсолютную безошибочность кода OpenSCADA.
И кстати OpenSCADA имеет модульную архитектуру, а вовсе не микроядерную. И за образец скорее бралось именно ядро Linux, хотя я был знаком с QNX. Большой недостаток микроядерной архитектуры, при всех её достоинствах, это низкая производительность, причиной чему являются взаимодействия между модулями тонкими связями (сообщения). OpenSCADA исключает эту проблему путём использования прямых связей между модулями, но сохраняя возможность разнести функции модулей по отдельным процессам с использованием тонких связей, причём с большим выбором механизмов, а не только одного механизма, как в микроядерных архитектурах.
И кстати, то что Вы говорите занимает 12907 байт вовсе не ядро OpenSCADA. Ядро OpenSCADA это динамическая библиотека размером порядка 1.5Мб. И именно благодаря тому, что это библиотека можно функции модулей разносить по процессам с обменом посредством тонких связей и без накладных расходов на дублирование кода ядра.
А вот тут я был прав, так как OpenSCADA в режиме исполнения имеет микроядерную архитектуру (если запущено более одного экземпляра). А Вы меня отправили изучать внутреннюю архитектуру программы. OpenSCADA - микроядерная модульная программа. Микроядерная в режиме исполнения и модульная по внутренней архитектуре.
Так же я был прав в том, что OpenSCADA удовлетворяет всем условиям написания безошибочного кода (я же не сказал, что он безошибочен).
Только микроядро OpenSCADA было найдено неверно. Потому что его нет и пишется пользователем.
Вопрос надёжности OpenSCADA, считаю, полностью проработан.
Выводы:
1. OpenSCADA надёжна и остаётся только её тестировать и вылавливать баги.
2. Открыта одна недокументированная возможность OpenSCADA: микроядерность. Отсутствует безошибочное микроядро - менеджер запущенных на одной машине экземпляров OpenSCADA, выполняющий функцию их реинкарнации. Пока микроядро пишем сами в shell. В роли микроядра, как подсказал Роман, также можно использовать дополнительный экземпляр OpenSCADA.
PS Сейчас начинаю проработку вопроса гибкости и масштабируемости. Как только изучу необходимую документацию и достигну некоторых выводов, здесь выложу.
[Сообщение редактировалось 18 раз(а), в последний раз 21.12.2009 в 18:52.]
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Сообщение создано: 04. 05. 2010 [15:18]
|
|
almaz
Almaz Karimov
Contributor
Создатель темы
Зарегистрирован(а) с: 25.09.2008
Сообщения: 516
|
Вопрос гибкости и масштабируемости OpenSCADA привёл к довольно интересным выводам. Поэтому выкладываю.
Существующий уровень гибкости и масштабируемости позволяет настраивать сеть компьютеров на достаточно сложную обработку и хранение данных, позволяет организовать резервирование обработки и хранения данных, возможно дублирование ввода-вывода данных. Но распределение задач (процессов) между компьютерами выполняется вручную при создании проекта пользователем. Распределение хранения данных и резервирование систем также задаётся вручную. Межкомпьютерный перенос данных также задаётся вручную. Много чего ещё и всё вручную.
А как хорошо было бы работать только в одном дереве проекта, не заботясь о распределении всех задач и данных (автоматическое распределение)? При исключении любого компьютера сети его задачи автоматически переходили бы на другой компьютер (за исключением компьютеров, выполняющих ввод-вывод данных, здесь поможет только физическое дублирование)? Сейчас приходится настраивать несколько деревьев (одно как минимум на каждый компьютер).
Прошу не принимать данное как критику OpenSCADA. Ручная настройка позволяет произвести её тонко, минимизировав трафик между компьютерами, точно распределить нагрузку на каждый компьютер и др.
Далее пришёл к выводу, что задача распределения ресурсов компьютеров вообще не проблема OpenSCADA. Пошёл изучать децентрализованные распределённые файловые системы, децентрализованные распределённые базы данных, распределённые сети обработки данных, облачные вычисления. Целью поисков было найти "децентрализованный распределённый виртуальный сетевой компьютер". И представьте - целиком его не нашёл (хотя вот тут кое-что есть - распределённая ОС на реальных компьютерах: http://parallel.ru/krukov/). Только "комплектующие". Не его ли изобретают люди, разрабатывая вышеперечисленные программные комплексы? Может кто-то встречал такой "компьютер" (желательно gpl, opensource) в сети? Существующие ботнеты - зачаточное состояние такого "компьютера".
С точки зрения "децентрализованного распределённого виртуального сетевого компьютера" каждый реальный компьютер предоставляет только ресурсы. Программа, предоставляющая ресурсы, производит их виртуализацию. Даже администратор такого реального компьютера не должен иметь возможность узнать, что хранится и обрабатывается этими ресурсами. Исключение составляют ресурсы ввода-вывода данных.
"Комплектующие" такого компьютера:
1. "Децентрализованный распределённый процессор, совмещённый с ОЗУ". Существующие распределённые вычисления (http://ru.wikipedia.org/wiki/%D0%A0%D0%B0%D1%81%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D1%91%D0%BD%D0%BD%D1%8B%D0%B5_%D0%B2%D1%8B%D1%87%D0%B8%D1%81%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F).
2. "Децентрализованная распределённая файловая система". Наиболее подходящее - Freenet (http://ru.wikipedia.org/wiki/Freenet). Возможно в качестве хранилища использовать децентрализованные распределённые базы данных.
3. Ресурсы ввода-вывода. Периферия реальных компьютеров, прошедшая виртуализацию. Дисплей, клавиатура, мышь, платы ввода-вывода сигналов и т.д. Резервирование возможно выполняя ввод-вывод одних и тех же физических данных разными компьютерами.
Если все компьютеры сети находятся в своём распоряжении можно создать кластер ( http://www.open-mpi.org/ ). Но, чтобы работала такая схема, в OpenSCADA должны запускаться отдельные процессы вместо потоков. А это, как говорилось выше, потеря производительности (плата за гибкость, масштабируемость и универсальность). Может когда-нибудь будет возможность создания кластеров с распределением потоков на разные компьютеры... (?)
[Сообщение редактировалось 1 раз(а), в последний раз 11.05.2010 в 07:24.]
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
Начало | Назад | 3 | 4 | 5 |
|
|
