[AlexandrY 3]

pps я вообще не вижу разницы между программой на "час" и "24/7/365". я пишу все программы так, чтобы они работали "24/7/365".

А что, кто то пишет по другому?

 

Все пишут уже давно по другому ;)

 

Зачем скажем писать беспроводной коммуникационный стек протоколов супер надежно если он все равно ляжет по причине ненадежности физического уровня?

Или зачем писать супернадежный софт для персонального компьютера где сбои де-факто уже норма.

Или зачем писать надежный софт для нано-спутника который через пару суток все равно сгорит в атмосфере?

Писать надежно под RTOS очень тяжело.

И даже не из-за утечек памяти. Утечки как раз легко отслеживаются (хотя борьба с фрагментацией очень сложна).

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

Не те размеры стеков и буфферов, не те размеры очередей, не учтенная интенсивность сообщений, неправильное распределение приоритетов и т.д. рисков куча.

Все модели планировщиков в RTOS основываются на том, что разработчик точно знает время выполнения своих задач.

В жизни это невозможно.

Т.е. по сути оптимизировать планировщик можно только для очень примитивных частных приложений.

В реальных приложениях планировщик скорее всего будет давать сбои. Это будет приводить к потере данных, к потере сообщений, рассинхронизации действий и т.д.

Т.е. не то что бы приведет к отказу, но приведет к потере качества функционирования, глючности.

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

Поинтересуйтесь как в NASA смотрят на проблему глючности.

 

[haker_fox 61]

ps есть конечно оси кривые, с дырами. например scmRTOS. Конечно такая ось принесёт только проблемы и не только в режиме 24/7/365.

Извините, но что Вам не нравится в scmRTOS? Какие дыры Вы в ней нашли, и когда?

Пара девайсов работают под этой осью. Один почти полтора года, другой - полгода.

 

. Никто не мешает воспользоваться поисковиком.

Да я не задавал конкретного вопроса :rolleyes:

2. Да нет, я говорил об обычной телефонной связи, для опробования качества которой необходимо лишь поднять трубку домашнего телефона.

При поднятии мы слышим гудок, который возможно вырабатывается генератором на каком-нить ОУ. Там ОСи нет. Но далее следует набор нормера, которы должен быть проанализирован, абонент должен быть обслужен. Мне кажется, если речь не идет о старой АТС, то в новых, вполне возможно, ОС применяются по полной. Есть ли у Вас более точные сведения, если Вы заговорили о телефонной связи? Мне самому инетересно :rolleyes:

[juvf 17]

Зачем скажем писать беспроводной коммуникационный стек протоколов супер надежно если он все равно ляжет по причине ненадежности физического уровня?

Или зачем писать супернадежный софт для персонального компьютера где сбои де-факто уже норма.

Или зачем писать надежный софт для нано-спутника который через пару суток все равно сгорит в атмосфере?

 

УЖ0С!!!

 

Я не понимаю отличие "писать супернадежный софт" и "писать софт". В чём разница? я не пишу супернадежный софт, я пишу софт. Хочешь пользуй 1 час, хочешь круглые сутки, хоть на микроконтроллере, хоть для ПК.

 

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

УЖОС!!! Гнать таких разработчиков. Ни на одном предприятии, на которых я работал, ни на одном предприятии, на которых работают мои знакомые такой практики нет. Бывает выпуск глючной продукции, но эти глюки выявляются после выпуска продукции. Т.е. в момент выпуска продукции разраб считает что ошибок нет, он допускает что там могут быть ошибки, но все известные ошибки устранены. А выпуск глючной продукции - это как правило результат плохово тестирования.

 

Писать надежно под RTOS очень тяжело.

Ну за всех говорить не нужно. наверно Вам Писать надежно под RTOS очень тяжело.

 

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

Не те размеры стеков и буфферов, не те размеры очередей, не учтенная интенсивность сообщений, неправильное распределение приоритетов и т.д. рисков куча.

Ну мне вот сложнее сделать межзадачное взаимодействие в суперпуле, а в ртос легче.

Можно и в С/С++ себе в ногу стрельнуть - неправельное обращение к памяти, обрашение по неправильному указателю.... и прога легла. Это не значит что с/с++ ненадёжные языки инужно писать на асме.

 

Поинтересуйтесь как в NASA смотрят на проблему глючности.

а чото заставка крутилсь недавно на micrium - нас выбрала НАСА для Марса.

ps Есть док. фильм про то, как наса внедрила бортовой комп на апалоне. Там был супер надёжный комп и по было супероттестированние.

 

pps

Извините, но что Вам не нравится в scmRTOS? Какие дыры Вы в ней нашли, и когда?

Пара девайсов работают под этой осью. Один почти полтора года, другой - полгода.

Да в полне возможно. Порты разные, задачи разные. В одном "соусе" она годами работает, в другом киснет на глазах.

Не работал с ней. Работал коллега. На АРМе каком-то поднял. примерно год назад релиз, по мойму ещё 3.ххх была. Там проблемы была.... вроде при просыпании процессора. Точно не скажу. Так что-то там улетало и девайс ложился. Коллега продебажил и нашол багу в самой оси. На этом форуме выяснил что бага эта есть и что она не фиксица... ну по крайней мере на тот момент не было патча для ос с заплаткой. Он мне сказал "Запишы в записную книжку: scmRTOS ни когда не пользовать". Он много негатива про неё мне наговорил. Потом портировал проект в TNKernel - проблем не стало. С тех пор только на ней и пишет.

[a9d 0]

Если честно, но объяснение глючности scmRTOS прозвучало как "где-то бабка сказала".

Переловатил всю ветку по scmRTOS и не нашел подобной темы.

 

В некоторых камнях действительно есть "особенности" выхода из сна. Например в SoC CCxxxx некоторые регистры и области памяти обнуляются. Но это не имеет какого либо отношения к самой ОС.

[juvf 17]

Если честно, но объяснение глючности scmRTOS прозвучало как "где-то бабка сказала".

Да и ладно. Для себя пометку сделал. А спорить об этом - офтоп. Кому-то доказывать про ос, в которой ни когда не работал.... Увольте.

[_Pasha 0]

Я не понимаю отличие "писать супернадежный софт" и "писать софт". В чём разница? я не пишу супернадежный софт, я пишу софт. Хочешь пользуй 1 час, хочешь круглые сутки, хоть на микроконтроллере, хоть для ПК.

**

Ну мне вот сложнее сделать межзадачное взаимодействие в суперпуле, а в ртос легче.

1. Серьёзно, лучше Вас такое еще никто не высказал.

2. *уле там мудрить: создается глобальная структура данных и все обращения типо offsetof() даже с динам.типами, но это уже к плюсам. Плюсы плюсов, тсз :laughing:

[Enthusiast 0]

При поднятии мы слышим гудок, который возможно вырабатывается генератором на каком-нить ОУ. Там ОСи нет. Но далее следует набор нормера, которы должен быть проанализирован, абонент должен быть обслужен. Мне кажется, если речь не идет о старой АТС, то в новых, вполне возможно, ОС применяются по полной. Есть ли у Вас более точные сведения, если Вы заговорили о телефонной связи? Мне самому инетересно :rolleyes:

"Гугл".

Изменено 9 декабря, 2012 пользователем Enthusiast

[AlexandrY 3]

УЖОС!!! Гнать таких разработчиков. Ни на одном предприятии, на которых я работал, ни на одном предприятии, на которых работают мои знакомые такой практики нет. Бывает выпуск глючной продукции, но эти глюки выявляются после выпуска продукции. Т.е. в момент выпуска продукции разраб считает что ошибок нет, он допускает что там могут быть ошибки, но все известные ошибки устранены. А выпуск глючной продукции - это как правило результат плохово тестирования.

 

Прям логический парадокс: "здесь глюков нет, но они тут могут быть"

Речь то об одном и том же софте. Софт то не деградирует со временем, как железо.

Так от куда там могут быть глюки если сейчас там их нет?

Или это позиция "страуса"?

[mvm54 2]

При поднятии мы слышим гудок, который возможно вырабатывается генератором на каком-нить ОУ. Там ОСи нет. Но далее следует набор нормера, которы должен быть проанализирован, абонент должен быть обслужен. Мне кажется, если речь не идет о старой АТС, то в новых, вполне возможно, ОС применяются по полной. Есть ли у Вас более точные сведения, если Вы заговорили о телефонной связи? Мне самому инетересно :rolleyes:

 

"Архитектура программного обеспечения

Программное обеспечение станции 5ESS-2000 имеет модульную архитектуру, что обеспечивает высокую надежность станции, простоту введения новых услуг, поддержки и обслуживания. Для управления используются две операционные системы. ОС UNIX-RTR реализует административные функции процессора AM. ОС распределенной коммутации OSDS распределена по коммутационным модулям и обеспечивает следующие интерфейсы:

- с ОС UNIX-RTR для обеспечения услуг ввода/вывода и связи между процессами для других программных подсистем в AM;

- с программным обеспечением технического обслуживания для поддержки процессов обслуживания станции в CM и в коммутационных модулях;

- интерфейс передачи сообщений в коммутационных модулях для связи с другими коммутационными модулями и с AM;

- интерфейс коммутации пакетов в коммутационных модулях для связи с блоками пакетной коммутации.

OSDS обеспечивает среду распределенной обработки вызовов и позволяет разным программным процессам совместно эффективно использовать системные ресурсы."

 

Неубиваемое изделие.

[haker_fox 61]

Он мне сказал "Запишы в записную книжку: scmRTOS ни когда не пользовать".

Суровый у вас коллега! Интересно, когда он порекомендует Вам не использовать Windows :rolleyes:

 

"Гугл".

Обычно такое дают, когда ответить нечего... :crying:

 

"Неубиваемое изделие.

Ну вот, Enthusiast, есть там ОСи, и все работает. Не волнуйтесь :rolleyes:

 

Так от куда там могут быть глюки если сейчас там их нет?

Может быть имелись в виду глюки, зависящие от абстоятельств: действия пользователя, специфическая комбинация входных сигналов и т.п.?

[juvf 17]

Прям логический парадокс: "здесь глюков нет, но они тут могут быть"

Это вы себе надумали этот парадокс. Я такого не говорил: "здесь глюков нет, но они тут могут быть"

 

в момент выпуска продукции разраб считает что ошибок нет, он допускает что там могут быть ошибки, но все известные ошибки устранены.

 

Что тут не понятного и где тут парадодкс?

[AlexandrY 3]

"в момент выпуска продукции разраб считает что ошибок нет, он допускает что там могут быть ошибки, но все известные ошибки устранены."

 

Что тут не понятного и где тут парадодкс?

 

Значит не в порядке с головой у разработчика.

На каком основании он "считает", что ошибок нет если допускает, что они могут быть?

Это такой наивный сброс ответственности с себя.

 

Скажем реальная ситуация. Промышленный агрегат тестируется на 10000 циклов рабочего хода более месяца.

И всего за это время обнаруживается два сбоя, скажем непредвиденных остановки.

Вы что, броситесь искать причину такого глюка? Отмените все испытания, начнете их заново?

Вот тогда вас и погонят в шею!

Ну что, остается стоять и "считать" что глюков нет, и всех окружающих в этом уверять ;)))

 

 

[Enthusiast 0]

"Архитектура программного обеспечения

Программное обеспечение станции 5ESS-2000 имеет модульную архитектуру, что обеспечивает высокую надежность станции, простоту введения новых услуг, поддержки и обслуживания. Для управления используются две операционные системы. ОС UNIX-RTR реализует административные функции процессора AM."

 

Неубиваемое изделие.

Это доказывает лишь то, что разработчик данного изделия поступился надежностью работы устройства ради простоты, удобства и времени его разработки. Изделие явно не стало надежнее, используя операционную систему.

[IgorKossak 0]

Это доказывает лишь то, что разработчик данного изделия поступился надежностью работы устройства ради простоты, удобства и времени его разработки. Изделие явно не стало надежнее, используя операционную систему.

Ну это совсем смешно! Гляньте сюда.

Кстати, в станции EWSD от Siemens тоже используется Unix в качестве базовой системы. Вы и о разработчиках из Siemens скажете, что они "поступились надежностью работы устройства ради простоты, удобства и времени его разработки"?

[ViKo 1]

Ну что, остается стоять и "считать" что глюков нет, и всех окружающих в этом уверять ;)))

Все ситуации предусмотреть трудно. Если все тесты пройдены, это говорит о том что все существующие тесты пройдены. :) Не исключено, что на других тестах будет сбой.

Возьмем примеры с падениями космических аппаратов.