"Нестандартное" применение OpenSCADA
| 1 | 2 | 3 | Дальше | В конец
| Автор |
Сообщение |
|
Сообщение создано: 02. 12. 2009 [21:45]
|
|
almaz
Almaz Karimov
Contributor
Создатель темы
Зарегистрирован(а) с: 25.09.2008
Сообщения: 516
|
В ветке "Новые идеи ..." возникла идея, что OpenSCADA - это "операционная система" для сети компьютеров.
Далее приведу несколько возможных применений OpenSCADA в данной роли.
1. У меня на рабочем столе постоянно находится виджет KDE4 "Системный монитор". Он показывает нагрузку на процессор, на сетевые интерфейсы, на жёсткий диск. Также показывает объем свободной оперативной памяти и кэша, температуру процессора и т.д.
А ведь на OpenSCADA можно сделать такой монитор в два счёта. И не просто для локальной машины, а для сети компьютеров, а также можно прицепить мониторинг UPS и других железок, работающих по SNMP.
OpenSCADA - просто находка для системных администраторов.
А можно же этими железками ещё и управлять ... 
2. На OpenSCADA можно реализовать игры (локальные на слабых компьютерах, использующих ресурсы других компьютеров сети для обсчёта игровой ситуации; сетевые многопользовательские игры без определённого центра-сервера и с равномерным распределением нагрузки на компьютеры сети и т.д.).
OpenSCADA может пригодиться даже игрокам, так как она хороший симулятор технологических процессов. А чем игра не технологический процесс?
Интересно, когда будет поддержка OpenGL в ОС OpenSCADA? 
3. В случае добавления некоторых функций в модуль "Специальные" возможно на OpenSCADA реализовать различные примочки для ОС, типа виртуальной клавиатуры, удаленного терминала и др.
4. В такой ОС понятие "файловая система" может уйти вглубь системы (например, как сейчас поток процесса), ведь все данные можно распределенно-резервированно хранить в сетевых БД.
5. .... Думайте сами ...
OpenSCADA может пригодиться ооочень широкому кругу пользователей!!! 
PS Сейчас в DAQ собираются драйвера, схожие с драйверами операционной системы. Сейчас они, в основном, представляют средства обмена данными с различным железом АСУТП. А ведь можно разрабатывать драйвера очень разные для разных случаев применения ...
PSPS Если на OpenSCADA написать сетевую игру (даже самую простейшую) и пустить в Интернет на оценку пользователей - пиар обеспечен!
[Сообщение редактировалось 2 раз(а), в последний раз 02.12.2009 в 22:21.]
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Сообщение создано: 03. 12. 2009 [07:12]
|
|
Aleksey
Aleksey Popkov
Contributor
Зарегистрирован(а) с: 31.07.2008
Сообщения: 326
|
Алмаз. Я хочу тогоже самого, чего и тебя так вставило 
|
|
Сообщение создано: 03. 12. 2009 [07:39]
|
|
almaz
Almaz Karimov
Contributor
Создатель темы
Зарегистрирован(а) с: 25.09.2008
Сообщения: 516
|
Пожалуйста! Курил вот это:
http://ru.wikipedia.org/wiki/Minix
http://www.dz.ru/solutions/phantom
OpenSCADA по своей структуре напоминает микроядерную операционную систему Minix (minix3.ru, minix3.org), но, в отличие от той, работает на монолитном (почти) ядре Linux. Микроядро Minix3 работает на железе, а микроядро OpenSCADA - на Linux! Точнее на сети Linux-ов!!!
Зря спорили Линус Торвальдс и его учитель Эндрю Таненбаум о технологиях Minix и Linux. Обе могут работать совместно!!!
http://oreilly.com/catalog/opensources/book/appa.html
Ещё эта ОС Фантом... Посмотрим, что за ОС без файловой системы, когда выложут исходники...
[Сообщение редактировалось 2 раз(а), в последний раз 03.12.2009 в 07:51.]
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Сообщение создано: 03. 12. 2009 [08:00]
|
|
Aleksey
Aleksey Popkov
Contributor
Зарегистрирован(а) с: 31.07.2008
Сообщения: 326
|
Вот это растопырка. Мне понравилось )).
|
|
Сообщение создано: 04. 12. 2009 [00:02]
|
|
kuzulis
Денис Шиенков
Зарегистрирован(а) с: 10.07.2009
Сообщения: 128
|
+пицот.
Алмаз, вштырило Вас не по децки.. да еще ентот фантом покоя вам не дает.. ужос
ЗЫ: сточно на LOR или BOR !!! 
|
|
Сообщение создано: 05. 12. 2009 [13:45]
|
|
almaz
Almaz Karimov
Contributor
Создатель темы
Зарегистрирован(а) с: 25.09.2008
Сообщения: 516
|
Меня не "вштырило". Просто методично прорабатываю вопрос надёжности программно-технических систем.
Думаю, вопрос обеспечения надёжности - самый важный вопрос в применении программно-технических систем. Обеспечение надёжности позволит избежать от просто глюков и неприятных ситуаций до аварий и катастроф.
Есть 3 элемента ненадёжности: "железо", программы, пользователь.
1. Задача обеспечения надёжности "железа" решается просто: выбором надёжного производителя (элементы ненадёжности "железа" могут быть заложены только недобросовестным производителем), дублированием систем и/или своевременной заменой неисправных частей.
Естественно, повышению надёжности "железа" будут способствовать открытые обществу принципиальные электрические схемы, хорошо документированные описания внутренней структуры, интерфейсов и т.д. Здесь может быть применена лицензия GPL или аналог.
К категории "железа" можно отнести не только электронику, но и датчики, исполнительные механизмы, технологические конструкции и т.д. Открытая обществу документация также способствует увеличению надёжности.
Глобально задача надёжности "железа" решается:
а) уменьшением количества элементарных деталей;
б) контролем технических решений как можно большим количеством квалифицированных специалистов.
2. Задача обеспечения надёжности программ решается тоже просто: написанием безошибочного кода.
Но, так как мы люди и имеем право на ошибки, этим правом часто пользуемся.
При увеличении кода одного модуля более 1000 строк, один человек уже не в состоянии обеспечить безошибочность кода (это не я придумал - где-то читал). Но у каждого человека свой потенциал. Кто-то может обеспечить безошибочность и в 10 000 строк кода, а кто-то в 1 строке заплутает. Это моё мнение.
Глобально задача надёжности программ решается:
а) разбиением всего множества необходимых программ на отдельные модули;
б) повторным многократным использованием отлаженного безошибочного кода;
в) исключением/объединением модулей, решающих одинаковые задачи;
г) уменьшением количества строк кода отдельных модулей (оптимизация);
д) контролем кода как можно большим количеством квалифицированных специалистов.
3. Пользователь. Человеческий фактор. Ну это всем понятно: Кадры решают всё!
Рассмотрим теперь слои:
1. "Железо".
2. На "железо" в первую очередь накладываются различные "прошивки". Так как они часто достаточно небольшие, производители "железа" могут обеспечить безошибочность (иногда уже после выпуска продукции). Касательно "прошивок" конечный потребитель часто может обеспечить надёжность только обновлением версии или, наоборот, откатом на более старые.
Естественно, повышению надёжности "прошивок" будет способствовать доступность исходных кодов и возможность модификации (например, по лицензии GPL).
3. Следующим слоем накладывается операционная система:
а). Всем условиям написания безошибочного кода удовлетворяют микроядерные операционные системы. Из них свободная Minix3. Микроядро всего из 5000 строк кода. Вероятность программных сбоев стремится к 0%.
б). Довольно стабильно для многих применений работают операционные системы с монолитным ядром. Одна из свободных Linux. Вероятность программных сбоев, скажем условно, стремится к 0,5%, но не к 0%. Видели сообщение kernel panic? ОС Windows можно не рассматривать. Там изначально концептуально заложена 100% вероятность краха.
4. Следующий слой пользовательская программа. Пока что. В настоящее время идёт процесс возникновения ещё одного слоя "операционная система над сетью операционных систем". Не путать с сетевой операционной системой. Отсюда и борьба различных сетевых технологий, приблизившихся к этой роли. Облачные вычисления, .NET Framework, серверы приложений, java-технологии, браузеры и т.д.
OpenSCADA намного более других приблизилась в роль "операционной системы над сетью операционных систем". И в то же время не перестаёт быть пользовательской программой.
OpenSCADA удовлетворяет всем условиям написания безошибочного кода, так как представляет из себя микроядерную модульную программу. Вот оно - доказательство надёжности OpenSCADA. Более подробно в книге: Таненбаум Э.,Вудхалл А. Операционные системы. Разработка и реализация. 3-е изд. Питер. 2007г. 704с.
У меня на компьютере микроядро OpenSCADA (/usr/bin/openscada) занимает всего 12907 байт!!! Интересно сколько строк (приблизительно) на С++ это составляет?
В соответствии с вышеизложенным прошу всех заинтересованных рассмотреть вопрос портирования OpenSCADA на Minix3 (локализованная версия обещается к 23 февраля 2010 года).
Микроядерная OpenSCADA на микроядерном Minix3 образует сверхнадёжную систему для любых применений.
Сразу назову минусы Minix3:
1. Лицензия BSD. Она, в отличие от GPL, сохраняет свободу одним нарушать свободу других.
2. Присутствие не всех пакетов, необходимых для сборки OpenSCADA. Это вопрос времени. Все наработки ОС Linux применимы в Minix3. Они обе UNIX.
3. Драйвера оборудования только для самого распространённого и стандартизированного "железа". Тоже вопрос времени.
[Сообщение редактировалось 5 раз(а), в последний раз 05.12.2009 в 17:44.]
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Сообщение создано: 05. 12. 2009 [19:36]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
almaz wrote:
1. Задача обеспечения надёжности "железа" решается просто: выбором надёжного производителя (элементы ненадёжности "железа" могут быть заложены только недобросовестным производителем),
Очень даже не просто решается вопрос надёжности железа. Есть ключевая аксиома, что нет абсолютно надёжного оборудования. Это даже поняли наши специалисты, которые работают с Siemens.
Особым фактором ненадёжности железа являются драйвера. С чем я столкнулся, казалось бы для промышленного оборудования.
almaz wrote:
Задача обеспечения надёжности программ решается тоже просто: написанием безошибочного кода.
Это тоже далеко не просто решается. Особенно в современных системах для которых характерны четыре типа ошибок:
- ошибки собственного кода;
- ошибки использованных библиотек;
- ошибки окружения исполнения;
- ошибки интеграции собственного кода с библиотечным и окружением.
almaz wrote:
Но, так как мы люди и имеем право на ошибки, этим правом часто пользуемся.
При увеличении кода одного модуля более 1000 строк, один человек уже не в состоянии обеспечить безошибочность кода (это не я придумал - где-то читал). Но у каждого человека свой потенциал. Кто-то может обеспечить безошибочность и в 10 000 строк кода, а кто-то в 1 строке заплутает.
Делать ошибки это свойство любого человека, а не право. Не ошибается тот, кто ничего не делает.
А в случае с ПО есть масса рисков как для создания ошибок, так и для возникновения их в будущем. Поэтому и абсолютно надёжного и стабильного софта нет. Абсолютно стабильным ПО является ПО которое уже устарело, заброшено и ни кем не развивается. А любое современное ПО динамично как само по себе так и на границе с сторонними библиотеками и окружением исполнения.
А решением для создания надёжного и стабильного ПО, а также гарантия этого является именно техническая поддержка оного и высокий уровень качества её.
По поводу критерия ошибок на количество строк, то это вполне промышленный критерий индустрии ПО. И качественным считается ПО у которого порядка одной ошибки на 1000строк кода. А теперь если это наложить на объем OpenSCADA, то получим минимум 100 ошибок. И это нужно себе чётко представлять.
almaz wrote:
3. Следующим слоем накладывается операционная система:
а). Всем условиям написания безошибочного кода удовлетворяют микроядерные операционные системы. Из них свободная Minix3. Микроядро всего из 5000 строк кода. Вероятность программных сбоев стремится к 0%.
б). Довольно стабильно для многих применений работают операционные системы с монолитным ядром. Одна из свободных Linux. Вероятность программных сбоев, скажем условно, стремится к 0,5%, но не к 0%.
Как я выше написал нет ничего абсолютного, нужно говорить о степени. И микроядерная архитектура здесь вовсе не панацая. Скажем так, сильно Вам будет легче от того факта, что будет падать драйвер ФС разрушая при этом саму ФС, а микроядро при этом будет рабочее? Здесь более важен критерий целостной надёжности. И кстати, разделение модулей в Linux сейчас достаточно сильно позволяет исключать взаимовлияние, т.е. падение всей системы при крахе модуля. Говорю это как человек, собравший десяток модулей или подгружавщий закрытые модуля различных коммерческих производителей к ядру Linux.
Т.е. если вспомнить предыдущий тезис про техническую поддержку и широту поддержки оборудования, то Linux сейчас вне всякой конкуренции. И именно поэтому многие производители слазят с флагмана микроядерной архитектуры QNX на Linux, в ответственных задачах промышленного управления.
almaz wrote:
OpenSCADA удовлетворяет всем условиям написания безошибочного кода, так как представляет из себя микроядерную модульную программу. Вот оно - доказательство надёжности OpenSCADA. Более подробно в книге: Таненбаум Э.,Вудхалл А. Операционные системы. Разработка и реализация. 3-е изд. Питер. 2007г. 704с.
У меня на компьютере микроядро OpenSCADA (/usr/bin/openscada) занимает всего 12907 байт!!! Интересно сколько строк (приблизительно) на С++ это составляет?
Даже я никогда не говорю про абсолютную безошибочность кода OpenSCADA.
И кстати OpenSCADA имеет модульную архитектуру, а вовсе не микроядерную. И за образец скорее бралось именно ядро Linux, хотя я был знаком с QNX. Большой недостаток микроядерной архитектуры, при всех её достоинствах, это низкая производительность, причиной чему являются взаимодействия между модулями тонкими связями (сообщения). OpenSCADA исключает эту проблему путём использования прямых связей между модулями, но сохраняя возможность разнести функции модулей по отдельным процессам с использованием тонких связей, причём с большим выбором механизмов, а не только одного механизма, как в микроядерных архитектурах.
И кстати, то что Вы говорите занимает 12907 байт вовсе не ядро OpenSCADA. Ядро OpenSCADA это динамическая библиотека размером порядка 1.5Мб. И именно благодаря тому, что это библиотека можно функции модулей разносить по процессам с обменом посредством тонких связей и без накладных расходов на дублирование кода ядра.
almaz wrote:
3. Драйвера оборудования только для самого распространённого и стандартизированного "железа". Тоже вопрос времени.
Как показывает история MAC OS и OpenSalaris это ни сколько вопрос времени сколько вопрос поддержки ОС производителем железа или сообществом ОС. А именно вопрос большого сообщества очень критичен, особенно если учесть что в MAC OS, OpenSalaris и Minix фактически нет ничего особого, что перетянуло бы сообщество Linux.
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 05. 12. 2009 [20:46]
|
|
Aleksey
Aleksey Popkov
Contributor
Зарегистрирован(а) с: 31.07.2008
Сообщения: 326
|
Все снимаем шляпу перед ГУРУ, и ни спорим.
Роман прав во всем, как обычно )))
|
|
Сообщение создано: 06. 12. 2009 [00:29]
|
|
almaz
Almaz Karimov
Contributor
Создатель темы
Зарегистрирован(а) с: 25.09.2008
Сообщения: 516
|
Никто и не спорит. Вопрос надёжности методично прорабатывается.
Надёжность OpenSCADA меня устраивает даже очень, я же не ядерный реактор или космический корабль собираюсь автоматизировать. Но, если мои жалюзи будут управляться той же программой, которая управляет космическим кораблём, буду только доволен.
Про абсолютную надёжность "железа" я ничего не говорил, речь о максимально возможной, стремящейся в пределе к абсолютной. Отсюда и дублирование "железа", и своевременная замена неисправных.
Под "железом" я подразумевал именно "железо", без всяких драйверов и даже "прошивок". Может не будем пытаться программу выдавать за "железо"?
Поэтому драйвер никак не может быть фактором ненадёжности "железа".
Под надёжным производителем железа я подразумевал производителя фактически надёжного железа, а не разрекламированного как надёжного. А про такие железки, которые Вы упомянули, я написал в полукруглых скобках пункта 1. Много лет аналогичные железки покоя не дают (минимум 1 сбой в сутки). Даже дешёвый китайский непромышленный ширпотреб работает вот уже 3 месяца без единого сбоя. И стоимость всей системы автоматизации на уровне стоимости одной единицы часто выходящего из строя электронного блока "надёжного" производителя. Что уж тут говорить - просто очень выгодно торговать дорогими и часто выходящими из строя вещами. Про ПО таких железок вообще молчу.
Программа, в отличие от "железа", абсолютно надёжной быть может, так как можно просчитать все варианты её работы за промежуток времени в разумных пределах (при соответствующих условиях о которых я говорил ранее). Даже есть программы, которые отыскивают ошибки в других программах. Да и компьютеры пока ещё на жесткой предсказуемой логике. Надеюсь никто не использует аппаратный генератор случайных чисел для ветвлений в программе. Этим балуются только "защитники" кода, которым есть, что скрывать и ради чего сбоить (выходить из строя).
Согласен, что на практике этого тяжело (почти невозможно) добиться из-за постоянных изменений в других программах. А ведь там могут так понакодить. Просто никто не ставит основной целью создание надёжного (качественного) ПО. Очень жаль.
В таких условиях к ПО приходится применять методы увеличения надёжности "железа", что очень плохо.
Мы теряем важное свойство ПО на жесткой логике быть безошибочным.
По поводу ошибок в библиотеках:
Ядро программы использует вызовы в основном надёжных системных функций. Основная масса работы с ненадёжными библиотеками производится в модулях. Изоляция ядра от собственных модулей уже многократно повысит общую надёжность программы.
Согласен, что ошибаться это не право. Людям свойственно ошибаться. В этом рассуждении допустил ошибку. Если бы ничего не написал, то и не ошибся бы.
Вы меня поправили. То есть две головы всегда лучше, чем одна. Аналогично с обнаружением ошибок в коде. Чем больше людей работают с кодом, тем более вероятно, что все до единой ошибки будут выловлены.
По поводу критерия допустимости 1 ошибки на 1000 строк: качественным считается тот килограмм мёда в котором только 1 грамм дёгтя. Опять же, программы могут быть идеальными в отличие от материальной продукции. Отношение к программам как к материальной продукции в корне неверно. Но торговать программой как материальной продукцией очень выгодно (в ущерб потребителю и развитию ПО). Отсюда и попытки привязать ПО к материальной продукции (ключи, лиц.диски, контроллеры с защищёнными прошивками и т.д.), соответственно многократно подняв цену на материальную продукцию.
Производительность и надёжность. Не напоминает количество и качество в производстве?
Производительности всегда можно добиться, выбрав побыстрее железку. А безошибочности ПО ничем другим не добьёшься. Только методики которые я приводил ранее.
Вопрос. Намного может упасть производительность микроядерной архитектуры сравнительно с монолитно-модульной?
С микроядерными ОС ещё не работал, изучаю пока теорию. Хотя бы приблизительно узнать какова потеря быстродействия.
Допустим монолитно-модульная программа грузит процессор на X%. Эта же программа, переработанная в микроядерную, грузит процессор на K*X%.
Интересует приблизительная (по опыту) экспертная оценка K.
Если задача выполняемая ядром и другим модулем важнее целостности модуля, отвечающего за файловую систему, да и всей файловой системы, то лучше микроядро. Тем более отказавший модуль перезапустится, а потерь может и не быть.
Я предположил, что Minix3 со временем будет только расширять круг пользователей, соответственно среди них будут и производители железа. Может и ошибаюсь. Но соблюдение качества ПО вижу пока что только в микроядерных архитектурах.
Может большое число специалистов и способно выловить почти все ошибки из ядра Linux, но kernel panic тогда бы многие не увидели.
[Сообщение редактировалось 14 раз(а), в последний раз 06.12.2009 в 08:58.]
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Сообщение создано: 06. 12. 2009 [10:28]
|
|
Aleksey
Aleksey Popkov
Contributor
Зарегистрирован(а) с: 31.07.2008
Сообщения: 326
|
На эту тему можно долго рассуждать, приводить кучу доводов, что-то придумывать и т.д.
Ну для этого мы ж и работаем ))) стремимся создать идеальное ПО, кто как в этом процессе принимает участие. Кто тестит, патчит, кодит.
100 % надежного ПО я не встречал.
В совокупности Soft+Hard одно зависит от другого. Если рассматривать отдельно Hard общей картины надежности получить только со временем получиться. -Вывод из разговора с инженерами электронщиками. Часто контроллеры просто сбрасываются на ровном месте. Т.е. вроде прописаны данные настроечные, все работает какое-то время. А потом все слетает. Переписываем. И опять работает какое-то время. И т.д.
100 % рабочего железа наверное тоже трудно встретить ))))
|
| 1 | 2 | 3 | Дальше | В конец
|
|
