Действительно ли вам нужна ОС реального времени?

Первоначально опубликовано Владимир Е. Зюбин 1. Если Вы новорите realtime, а подразумеваете reliability, то может так и нужно говорить надежные ОС, или "ОС с повышенными надежностными характеристиками"...

Вполне возможно... Но тогда мы попадаем в новую засаду: термины "надежные ОС" или "ОС с повышенными надежностными характеристиками" - уже употребляются и в совершенно другом контексте.

Первоначально опубликовано Владимир Е. Зюбин Тогда об этом и надо говорить. Пояснять в каких случаях имеет смысл применять QNX, а в каких нет.

И даже не QNX в частности, а OS этого класса: pSOS, VxWorks, OS-9...
Так я и пытался это в обсуждении делать, но разговор всё время сползает на: "... а мне и OS/2 - FreeBSD - DOS - ... нравится". Ещё немного, и договоримся, что и Windows для critical mission "нравится".

Первоначально опубликовано Владимир Е. Зюбин К сожалению, проблемы "неадекватного интерфейса" - это не проблемы синхронизации, а проблемы дизайна... так написано в обсуждаемой статье.

А это - в статье неправильно написано ;-): их проблема, которая выглядит потребителю как "дизайн" - как раз имеет под собой основу "синхронизацию".

Первоначально опубликовано Olej Первоначально опубликовано Владимир Е. Зюбин 1. Если Вы новорите realtime, а подразумеваете reliability, то может так и нужно говорить надежные ОС, или "ОС с повышенными надежностными характеристиками"... Вполне возможно... Но тогда мы попадаем в новую засаду: термины "надежные ОС" или "ОС с повышенными надежностными характеристиками" - уже употребляются и в совершенно другом контексте.

Ну-ка, ну-ка...
Что вы имеете сказать о надежности употребляемых в qnx файловых систем ?

Первоначально опубликовано Olej Первоначально опубликовано Владимир Е. Зюбин Тогда об этом и надо говорить. Пояснять в каких случаях имеет смысл применять QNX, а в каких нет. И даже не QNX в частности, а OS этого класса: pSOS, VxWorks, OS-9... Так я и пытался это в обсуждении делать, но разговор всё время сползает на: "... а мне и OS/2 - FreeBSD - DOS - ... нравится". Ещё немного, и договоримся, что и Windows для critical mission "нравится".

"нравится" - никто не говорил. Говорят - "я использую и оно работает"
Что такое "critical mission" в общем случае непонятно...Вон у нас есть буржуйский лазерный технологический комплекс - так там стоит винда - и никаких нареканий на нее я не слышал - независимо от того - нравится она мне или не нравится. Правда винда конечно не простая и кроме нее еще есть пара "черных ящиков"...

Первоначально опубликовано Olej Первоначально опубликовано Владимир Е. Зюбин К сожалению, проблемы "неадекватного интерфейса" - это не проблемы синхронизации, а проблемы дизайна... так написано в обсуждаемой статье. А это - в статье неправильно написано ;-): их проблема, которая выглядит потребителю как "дизайн" - как раз имеет под собой основу "синхронизацию".

В статье черным по белому написано - в предыдущей версии была защита и ее убрали - это не относится никак ни к синхронизации, ни к дизайну ПО, а только к разрухе в головах. Почему я при начале работы по автоматизации чего-либо задаю вопрос "а что будет плохого, если зависнет компьютер/программа и как с этим вы - электронщики+конструкторы будете бороться ?",

Первоначально опубликовано Olej Первоначально опубликовано Владимир Е. Зюбин К стыду своему, не разу не слышал про "надежные ОС". В каком еще таком "совершенно другом контексте" употребляется слово "надежность", когда речь заходит об ОС? 8-) Мне сейчас лень лезть специально в документацию того же QNX, нам целая отдельная книжка есть ... обеспечение "высокой живучести" - коэффициента готовности 99.999% - 5 мес. простоя на год непрерывной работы. Ненадёжность, идущая от проблем realtime - это проблемы рассинхронизации приоритетных слоёв, нарушение логики выбранной процедуры диспетчирования... которая может возникать на миллисекундных интервалах, и дальше может восстанавливаться (это вот то "гарантированное время отклика") или нет (а это нарушение его "гарантированного возникновения").

1. Надежность и живучесть (robustness), да и коэффициент
готовности - это разные понятия, хотя, может, и
отдаленно связанные друг с другом.

2. Разговор о том, что realtime = надежность, подняли Вы.

3. Как мне кажется, пользователя мало интересуют
причины ненадежности, его интересует надежность.

4. Изначально меня просто интересовал термин
"надежные ОС", его _общепринятое_ определение, если
таковое есть, конечно...

Первоначально опубликовано Olej Первоначально опубликовано Владимир Е. Зюбин 1. Да. И QNX, и VxWorks, и OS-9. Для всех нужно определять случаи их использования. А для этого нужно знать их свойства и характеристики. А вот это и делает Dedicated Systems в своих отчётах (там свежий есть: QNX 6.2 vs VxWorks AE 1.1 vs Windows CE.NET vs ELDS 1.1 (emdedded RedHat Linux)).

В исследованиях DS видится большая проблема: эти
исследования (несомненно интересные) базируются не на
анализе исходного кода, а на неких экспериментах...
Эти исследования не затрагивает таких важных вещей, как
стоимость решения, качество поддержки, гарантии
производителя и т.п.

Первоначально опубликовано Olej Первоначально опубликовано Владимир Е. Зюбин 3. Кстати, почему бы и Windows в критических системах не употреблять? непонятно... мне вот Виндовоз не нравится, но чем Виндовоз принципиально от QNX отличается пока не очень ясно... Нет уж!... А как на счёт "пип - пип - пип - ... программа выполнила недопустимую операцию" во время... слепой посадки, скажем? СлабО?

Ну, на мой взгляд так же и у QNX может пропикать...
или не может? Имеются гарантии производителя?
Я так понимаю, нет.

Первоначально опубликовано Olej Первоначально опубликовано Владимир Е. Зюбин ...например, в случае Therac-25 при вводе/установке запредельных значений облучения это не отображалось на экране... ни цветом, ни звуком, ни знАком... ... и там же анализируется, что возникало это в тех очень редких случаев, когда оператор успевал очень быстро (<8sec.) осуществить 2 ввода, а общее поле данных не защищено, и не анализируется на изменения из 3-х программ... Только они на этой стороне не акцентировались.

Мне кажется, Вы несколько однобоко пытаетесь трактовать
неплохую статью. Вот я цитирую, на мой взгляд, ключевой абзац по анализу причин несчастных случаев на Therac-25:

"Можно долго перечислять проявившиеся в этом проекте (Therac-25 - В.З.) проблемы, например, касающиеся принципов построения человеко-машинного интерфейса (выдаваемые оператору сообщения о критических с точки зрения безопасности ситуациях выглядели как рутинные; при этом не включалась блокировка, препятствующая дальнейшей деятельности оператора и т.д.). Все это является отражением того факта, что – как позволяет утверждать ставшая доступной информация о проектных и технологических особенностях разработки – квалификация коллектива разработчиков и организация их работы не позволяли реализовать столь сложный и тонкий проект с обеспечением безопасности функционирования, необходимой в данной предметной области."

http://www.91.ru/Education/Books/Os/21.htm

Первоначально опубликовано Владимир Е. Зюбин 3. Как мне кажется, пользователя мало интересуют причины ненадежности, его интересует надежность.

Вы уже несколько раз упомянули пользователя (конечного потребителя) и гарантии...
Меня, в контексте данного обсуждения, мало занимает пользователь, и вовсе не потому, что я "не люблю" пользователя, или меня не занимают его проблемы... (и мои, когда мне придётся перед ним отдуваться ;-)).

Я ещё раз повторю: в этом разговоре.
В обсуждении инженеров, разработчиков и т.д., которые могут анализировать и выбирать OS... Но пользователю это - безразлично, по-большому счёту: OS для него - либо ваш инструмент, либо составная часть изделия.
Когда пользователь покупает автомобиль - его занимают, но не сильно - гарантии на карбюратор.
Так что давать гарантии, в конечном итоге - вам.

Первоначально опубликовано Владимир Е. Зюбин В исследованиях DS видится большая проблема: эти исследования (несомненно интересные) базируются не на анализе исходного кода, а на неких экспериментах... Эти исследования не затрагивает таких важных вещей, как стоимость решения, качество поддержки, гарантии производителя и т.п.

А мне кажется наоборот.
А потом уже, на основании и их в том числе оценок, свои прогнозы "стоимости решения, качества поддержки, гарантий
производителя" - будете делать - вы!

Первоначально опубликовано Владимир Е. Зюбин Ну, на мой взгляд так же и у QNX может пропикать... или не может? Имеются гарантии производителя? Я так понимаю, нет.

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

Нету на ПО - гарантий. А если кто их даёт - то он просто ведёт нечесную игру. По крайней мере я, относительно качественных параметров - гарантий не видел (см. ниже).

Но есть достаточно большой опыт эксплуатации, и не одного частного лица, а миллионов! Вы же не сможете отрицать, что Windows NT 4.0 намного (насколько? да, это вопрос) устойчивее Windows 98? Или кто-то станет? И этому постфактум даются обоснования - например Шилдт или Питрек, которые объясняет "почему". И объяснить это может именно с позиций "чёрного ящика" и путём реверс-инжиниринга и восстановления некоторых ключевых фрагментов кода. Как бы там ни было - эти объяснения выходят на уровень архитектурных основ, и опираются на них...

Если говорить об опыте - то по моему опыту добится "пип" от QNX - очень сложно, почти невозможно... Подвесить OS можно только специальными манипуляциями с её установочными параметрами, и такими манипуляциями, которые по логике не могут ни к чему привести, кроме краха системы.
"А, не любишь - сказали суровые сибирские мужики"(с).

Если говорить об архитектурных принципах, определяющих устойчивость - то же... Они просто должны её обеспечивать на порядок выше, чем у универсальных OS. Хотя бы то, что практически любую часть (!) OS можно выгрузить "на ходу" и запустить заново: драйвера, сетевые и файловые подсистемы... практически всё, за исключением, пожалуй, микроядра.

Теперь ещё об гарантиях. OS - это инструмент. Производитель гарантирует для него:
- наиболее широкий набор API (это - приёмов работы с этим инструментом);
- набор дополнительных модулей (драйверов, например, наиболее распространённого оборудования);
- некоторые технологии использования (например, технику создания индивидуальных драйверов);
...

Какие вы ещё видели гарантируемые параметры на ПО (не только OS)? Хоть от одного производителя одного из OS?
Какие могут дать гарантии производителя, если они производят patch-и чуть ли не ежемесячно - а по существу patch - это признание дефектности продукта. И это относится не только к OS, а к любому ПО.

ПО - являющееся интеллектуальной собственностью и объектом, защищаемым авторским правом (в отличие от патентного и т.п.). Это не совсем то-же, но близко: можно гарантировать на литературное произведение, что оно "будет читаться 15 лет"... или на музыкальное произведение, что оно "не содержит фальшивых частот в смысле 12-ти тоновой гаммы"?

И потом, гарантировать - это всегда предполагает: а).гарантиии в случае обнаружения дефекта б).гарантии чем-то.

Вы сможете всегда (пусть в большинстве? пусть иногда?) - квалифицировать дефект ПО? (даже воспроизвести его). Вы сможете даказать это юридически? Да и, в конечном итоге, гарантийные обязательства конечного потребителя будут относиться к вам - вы сможете перенести их на производителя инструментария (OS)? Думаю - нет.

Первоначально опубликовано Владимир Е. Зюбин Мне кажется, Вы несколько однобоко пытаетесь трактовать неплохую статью. Вот я цитирую, на мой взгляд, ключевой абзац по анализу причин несчастных случаев на Therac-25:

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

Как правило производители ПО гарантируют, что компакт-диск с этим ПО свободен от дефектов и если вы такие дефекты обнаружите, то фирма бесплатно этот компакт-диск заменит:-).

Если посмотреть юридические оговорки как на ПО так и на аппаратуру, то обычно явно и КРУПНЫМИ буквами пишется о том что производитель не несет ответственности за последствия применения своей продукции или за последствия того что заказчик не смог применить эту продукцию. Многие при этом пишут, что ни при каких условиях ответственность производителя не превышает стоимость продукта.

Поэтому если из-за программы стоимостью 400$ взорвалась атомная станция, производитель несет ответственность в размере 400$.

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

Помните нашумевшее зависание Windows во время презентации Била Гейтса. Это произошло из-за кривого драйвера принтера HP, а инженер готовивший презентацию, был немедленно уволен.

Кстати тут упоминался отчет по сранению ОС и в том числе RedHat embedded Linux. Наверное публике будет не безинтересно, что RedHat прекращает поддержку Линукса (окончательно в апреле 2004). Хороший пример того, как компания, получившая широкую известность под флагом бесплатного ПО, втихаря разработало платное ПО и теперь будет различными пряниками убеждать пользователей Линукса переходить на это платное ПО. Вот он звериный оскал капитализма :-).

С Уважением,

Сергей Сорокин

 

Первоначально опубликовано Olej И потом, гарантировать - это всегда предполагает: а).гарантиии в случае обнаружения дефекта б).гарантии чем-то.