[BugWrong]
Концепция
| Автор |
Сообщение |
|
Сообщение создано: 08. 12. 2009 [14:58]
|
|
almaz
Almaz Karimov
Contributor
Создатель темы
Зарегистрирован(а) с: 25.09.2008
Сообщения: 516
|
В концепции нашёл ошибку:
Для придания гибкости и высокой степени масштабируемости система OpenSCADA построена по модульному принципу. Тесная интеграция модулей с ядром системы накладывает большую ответственность на процесс написания модулей и вводит элемент нестабильности в систему, однако благодаря возможности создания распределённых конфигураций эта опасность сглаживается с сохранением высокой степени гибкости.
Хотя в начале текста сказано:
В качестве политики разработки данной системы выбраны 'open source' принципы. Выбор данной политики определяется необходимостью создания открытой, надёжной и общедоступной SCADA системы. Данная политика позволяет привлечь к разработке, тестированию, развитию, распространению и использованию продукта значительное количество разработчиков, энтузиастов и других заинтересованных лиц с минимизацией и распределением финансовых затрат.
Противоречие: В надёжной системе опасность сглаживается Опасность она или есть, или её нет.
А в чём проблема? Ясно написано: тесная интеграция модулей с ядром вводит элемент нестабильности в систему.
Вывод: Нестабильность ПО заложена изначально концептуально, а решать предлагается дублированием систем. То есть вместо устранения элементарной ошибки в корне предлагается приспособиться к ней любыми доступными способами. Вместо того, чтобы устранить опасность, она сглаживается. И это ради того, чтобы выиграть на 5-10% в быстродействии.
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Сообщение создано: 08. 12. 2009 [15:49]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
almaz wrote:
Для придания гибкости и высокой степени масштабируемости система OpenSCADA построена по модульному принципу. Тесная интеграция модулей с ядром системы накладывает большую ответственность на процесс написания модулей и вводит элемент нестабильности в систему, однако благодаря возможности создания распределённых конфигураций эта опасность сглаживается с сохранением высокой степени гибкости.
Это не ошибка.
almaz wrote:
Противоречие: В надёжной системе опасность сглаживается Опасность она или есть, или её нет.
Противоречия здесь нет.
Прекращайте уже выражаться абсолютизмами где они не уместны.
Опасность есть всега. От того, что я все модули разнесу по процессам для целостности в целом она не уменьшиться, если учесть, что любой из модулей, раз уж он запущен, важен.
А не уменьшится по причине простой аддитивности рисков каждого модуля.
Вынос наиболее рискованных модулей в отдельные процессы может только увеличить степень надёжности ядра, которое само по себе функций не выполняет, а следовательно и его надёжность сама по себе безсмысленна для задачи, да и не становиться абсолютной.
http://ru.wikipedia.org/wiki/Риск
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 08. 12. 2009 [18:14]
|
|
almaz
Almaz Karimov
Contributor
Создатель темы
Зарегистрирован(а) с: 25.09.2008
Сообщения: 516
|
В отношении программного обеспечения абсолютизм очень уместен, так как программы работают на жёсткой логике (каковыми являются нынче компьютеры) абсолютно предсказуемо. Кроме того, именно абсолютизм позволяет вытачивать программы до идеального состояния. Сколько человеко-часов нужно для предсказания всех вариантов работы (соответственно получения безошибочного кода) зависит от размера кода и сложности алгоритмов.
Элемент неопределённости вносит человек, генерируя, допустим, 1 ошибку на 1000 строк кода.
Пусть имеем 9 модулей кода по 1000 строк каждый, имеющие по 1 ошибке каждый и безошибочное ядро размером 1000 строк (исходя из абсолютной предсказуемости программ и при тщательной проверке многими людьми - это возможно). При этом время запуска каждого модуля и ядра составляет 1 сек.
При тесной интеграции модулей с ядром (монолитная архитектура) имеем опасность сбоя всей системы 0,0009. И время простоя (очень опасного состояния, так как не работает ничего) при автоматическом перезапуске получаем 10 сек.
При раздельной работе (микроядерная архитектура) нет опасности сбоя всей программы 0,0000.
При этом имеем опасность сбоя каждого модуля в отдельности 0,001 и время простоя (не очень опасного состояния, так как вероятность сбоя многих модулей одновременно чрезвычайно мала) 1 сек.
Ядро в данном случае представляет саму бесперебойную программу и выполняет функцию реинкарнации модулей в случае сбоев. Смысл состоит в том, что при сбое в одном модуле перезапускается только этот модуль. В случае монолитного ядра из-за сбоя в одном модуле перезапускается и ядро, и все другие модули. Выигрыш во времени простоев и отсутствии промежутков времени полной неработоспособности системы.
Теорема доказана.
Если выловить все ошибки и в модулях, монолитная архитектура будет предпочтительней. Только это очень трудоёмко. При разрастании модулей и постоянных в них изменениях почти невозможно. А поддерживать бесперебойным ядро очень даже реально.
PS Ни на чём не настаиваю, просто прошу данное иметь ввиду. Тем более, что этот мировой глобальный вопрос ещё не решён даже на уровне операционных систем. Подождём и поглядим как будет.
Существующим качеством OpenSCADA доволен (аналогов не вижу). OpenSCADA обеспечивает длительные сроки бесперебойной работы.
PSPS В связи с этим, пока в мире доминирует ОС Linux над микроядерными свободными ОС в концепции предлагаю вместо надёжной подразумевать формулировку достаточно надёжной, чтобы не было противоречия. Вносить изменения в текст концепции не предлагается, чтобы не потерять цель сделать её просто надёжной.
В достаточно надёжной системе опасность сглаживается - истина.
[Сообщение редактировалось 12 раз(а), в последний раз 08.12.2009 в 21:46.]
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Сообщение создано: 09. 12. 2009 [07:52]
|
|
kuzulis
Денис Шиенков
Зарегистрирован(а) с: 10.07.2009
Сообщения: 128
|
2 almaz,
поддерживаю на все 100 
тоже считаю, что хорошо бы модули отделить от ядра так, чтобы при падении како-го либо модуля - в целом система продолжала работать.
К примеру у нас проект выполнен с кучей протоколов и т.п. Вот к примеру падает какой-то из транспортов - связь с у-вами (которые относятся нему) прерывается - НО в целом система продолжает работать , пока не перезапустится снова этот модуль. При этом хорошо бы вести лог (статистику) падений модулей и т.п. чтобы можно было выявить причину и т.п.
|
|
Сообщение создано: 09. 12. 2009 [09:02]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
almaz wrote:
В отношении программного обеспечения абсолютизм очень уместен, так как программы работают на жёсткой логике (каковыми являются нынче компьютеры) абсолютно предсказуемо. Кроме того, именно абсолютизм позволяет вытачивать программы до идеального состояния. Сколько человеко-часов нужно для предсказания всех вариантов работы (соответственно получения безошибочного кода) зависит от размера кода и сложности алгоритмов.
Учим теорию алгоритмов!
Кроме того, раз уж Вы такой абсолютист, то пишем свою лицензию в которой всем даём полные гарантии. И через месяц Вы остаётесь голый, и с большой вероятностью за решёткой. Покажите мне хоть одну лицензию на ПО где нет пункта про отказ от всяких гарантий!
almaz wrote:
Элемент неопределённости вносит человек, генерируя, допустим, 1 ошибку на 1000 строк кода.
И эта ошибка не обязательно критичная, как Вы подразумеваете.
almaz wrote:
Пусть имеем 9 модулей кода по 1000 строк каждый, имеющие по 1 ошибке каждый и безошибочное ядро размером 1000 строк (исходя из абсолютной предсказуемости программ и при тщательной проверке многими людьми - это возможно). При этом время запуска каждого модуля и ядра составляет 1 сек.
Вовсе не 1000 строк в ядре, и даже для Hello world, пример уже забыли.
Из чего следует не корректный вывод далее! Теорема опровергнута.
almaz wrote:
PS Ни на чём не настаиваю, просто прошу данное иметь ввиду. Тем более, что этот мировой глобальный вопрос ещё не решён даже на уровне операционных систем. Подождём и поглядим как будет.
Существующим качеством OpenSCADA доволен (аналогов не вижу). OpenSCADA обеспечивает длительные сроки бесперебойной работы.
И это учтено, повторяю уже наверное раз пятый.
almaz wrote:
PSPS В связи с этим, пока в мире доминирует ОС Linux над микроядерными свободными ОС в концепции предлагаю вместо надёжной подразумевать формулировку достаточно надёжной, чтобы не было противоречия. Вносить изменения в текст концепции не предлагается, чтобы не потерять цель сделать её просто надёжной.
В достаточно надёжной системе опасность сглаживается - истина.
Есть нормальное и научное понятие степень надёжности или степень риска, и ничего тут придумывать не нужно.
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 09. 12. 2009 [09:03]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
kuzulis wrote:
тоже считаю, что хорошо бы модули отделить от ядра так, чтобы при падении како-го либо модуля - в целом система продолжала работать.
И это возможно изначально. Открываем глаза.
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 09. 12. 2009 [11:00]
|
|
almaz
Almaz Karimov
Contributor
Создатель темы
Зарегистрирован(а) с: 25.09.2008
Сообщения: 516
|
Алгоритмы (программы) существуют такими какие они есть только в информационном поле. И речь идёт о возможной безошибочности именно такого алгоритма. А существующая теория алгоритмов охватывает элементы материального поля и, соответственно, искажена. В ней под алгоритмом понимается копия алгоритма (отражение) в материальном поле. И теория алгоритмов после ёё изучения оставляет кучу нерассмотренных вопросов и неопределённостей!
Для предоставления полной гарантии на ПО, первое, необходимо полное понимание всеми, что такое ПО, и второе, безошибочность законов государств (так же как алгоритмы они какие есть существуют в информационном поле). Ни того, ни другого пока не наблюдается, поэтому предоставлять полные гарантии на ПО невозможно.
Учим более фундаментальные теории!
Ошибки лучше подразумевать именно критичными. Расчитывать, как говорится, на худшее, а надеяться на лучшее. Вспомним наиболее эффективный метод тестирования!
Когда говорится о безошибочности 1000 строк кода, подразумевается безошибочность именно этих 1000 строк кода. А любые другие участки кода анализируются, отлаживаются и доводятся до безошибочности отдельно. "Опровержение" опровергнуто!
Степень надёжности - это параметр характеризующий будущее поведение материального или информационного поля. Придуман из-за нехватки знаний и/или времени для предсказания вариантов поведения материального или информационного поля.
Сейчас физики как никогда приблизились к формулировке, так называемой, "Теории всего". Это сложная формула которая представляет единый закон поведения материального мира. В соответствии с этой формулой материальный мир абсолютно предсказуем. Сколько времени необходимо для предсказания зависит от объёмов, видов материи и поставленного вопроса.
Можете предсказать что будет с яблоком, если его отпустить на высоте 1 метр от поверхности Земли? Или будем говорить о степени риска, что оно не упадёт и зависнет в пространстве?
В отличие от материального поля, информационное поле пока не изучается отдельно, а постоянно в связке с материальным, что ошибочно.
Но многие законы информационного поля можно подчерпнуть из существующих наук и теорий. Попытайтесь из теории алгоритмов подчерпнуть только то, что касается возможного поведения информационного поля!
Сколько времени нужно для предсказания поведения информационного поля зависит от исходных данных, от сложности алгоритмов и их размера.
Можете предсказать результат операции ("Истина" Или "Ложь"). Или будем говорить о степени риска получения результата Ложь?
roman wrote:
Есть нормальное и научное понятие степень надёжности или степень риска, и ничего тут придумывать не нужно.
Откройте глаза!
PS Прежде чем что-то ответить, чётко определитесь для себя что такое материя и что такое информация.
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Сообщение создано: 09. 12. 2009 [11:21]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
Я уже устал Вам доказывать истины по которым работает весь мир.
И продолжать пустое занятие у меня просто нет времени.
Если Вас лично устраивает абсолютизм, то я уже говорил, пишите свою лицензию где гарантируете безотказность и нулевые риски, а потом доказывайте почему отказы всётаки есть, и при этом выплачивайте страховые риски.
Дальнейшее обсуждение я здесь прекращаю, поскольку это не ошибка, и попытки продолжить будут пресекаться путём удаления сообщений и полного блокирования темы.
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 14. 12. 2009 [08:47]
|
|
almaz
Almaz Karimov
Contributor
Создатель темы
Зарегистрирован(а) с: 25.09.2008
Сообщения: 516
|
Как выяснилось ошибка в концепции совершенно другого рода (можно даже сказать опечатка).
Тесная интеграция модулей с ядром улучшает стабильность системы, благодаря повторному использованию отлаженного кода. Под тесной интеграцией понимается не только нахождение модулей и ядра в одном процессе, но и наследование объектами модулей свойств и методов объектов ядра.
Поэтому вместо:
Для придания гибкости и высокой степени масштабируемости система OpenSCADA построена по модульному принципу. Тесная интеграция модулей с ядром системы накладывает большую ответственность на процесс написания модулей и вводит элемент нестабильности в систему, однако благодаря возможности создания распределённых конфигураций эта опасность сглаживается с сохранением высокой степени гибкости.
Можно сказать примерно следующее:
Для придания гибкости и высокой степени масштабируемости система OpenSCADA построена по модульному принципу. Тесная интеграция модулей с ядром улучшает стабильность системы, благодаря повторному использованию отлаженного кода. Хотя процесс разработки ПО накладывает большую ответственность, возможные ошибки вводят элемент нестабильности в систему. Возможность создания распределённых конфигураций сглаживает эту опасность.
Поэтому OpenSCADA была, есть и будет просто надёжной.
А микроядерная архитектура в режиме исполнения достигается, как и говорил Роман, запуском нескольких экземпляров OpenSCADA.
Каждый экземпляр настраивается на выполнение своей функции выбором соответствующего набора модулей (это не дублирование одних и тех же функций ПО).
Обмен данными между экземплярами OpenSCADA производится посредством DAQGate.
Безошибочное микроядро, выполняющее функцию реинкарнации экземпляров OpenSCADA, представляет из себя скрипт shell и разрабатывается для каждого случая применения индивидуально.
Такая конфигурация спокойно проходит самый эффективный тест ПО (внесение неисправностей) и позволяет использовать OpenSCADA в автоматических системах (без участия человека).
PS Роман, извиняюсь за произошедшее, но просто необходимо было прояснить вопрос надёжности системы и развеять подозрение на возможную ошибку в концепции. Тем более, что подозрение закладывается самой же концепцией.
[Сообщение редактировалось 10 раз(а), в последний раз 15.12.2009 в 07:05.]
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Сообщение создано: 18. 12. 2009 [16:41]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
almaz wrote:
Можно сказать примерно следующее:
Для придания гибкости и высокой степени масштабируемости система OpenSCADA построена по модульному принципу. Тесная интеграция модулей с ядром улучшает стабильность системы, благодаря повторному использованию отлаженного кода. Хотя процесс разработки ПО накладывает большую ответственность, возможные ошибки вводят элемент нестабильности в систему. Возможность создания распределённых конфигураций сглаживает эту опасность.
Тогда лучше так:
Для придания гибкости и высокой степени масштабируемости система OpenSCADA построена по модульному принципу. Тесная интеграция модулей с ядром улучшает стабильность системы в целом, благодаря повторному использованию отлаженного кода. Однако сам процесс разработки собственного кода модулей OpenSCADA накладывает большую ответственность, возможные ошибки вводят элемент нестабильности в систему. Возможность создания распределённых конфигураций сглаживает эту опасность.
almaz wrote:
Безошибочное микроядро, выполняющее функцию реинкарнации экземпляров OpenSCADA, представляет из себя скрипт shell и разрабатывается для каждого случая применения индивидуально.
Не скрипт shell, а скрипт OpenSCADA на JavaLikeCalc.
Learn, learn and learn better than work, work and work.
|
|
|
