[sasamy 9]

Если же рассуждать шире, то удел операционных систем - это всего лишь удобное средство отображения данных. На мой взгляд, поручать осям задачи управления в режиме 24/7/365 недопустимо из-за неизбежных сбоев в работе динамического ОЗУ.

 

Широта рассуждений поражает :) Гугл на который вы ссылаетесь уже перевел свои серверы работающие " 24/7/365" на микроконтроллеры с bare metal прошивками ?

[VslavX 0]

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

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

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

В реальной ситуации испытания, конечно, продолжатся (если разработчик не хочет потерять работу). Но, как появиться время/силы/возможности со сбоем надо будет разбираться.

Мало-мальски сложный софт - он модульный. Причины модульности вполне прозаические:

- снижается общая сложность проекта, до O*N, вместо O в степени. Отдельную часть проще разработать и поддерживать.

- повторное использование кода в разных проектах. Модули надо разрабатывать по возможности универсальными, с четко прописанными интерфейсами, тогда их можно повторно использовать.

Поэтому - если в проекте подозревается глюк, то его надо искать. С большой вероятностью глюк в универсальном модуле, если его не локализовать, то он будет расползаться по другим проектам.

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

 

[juvf 10]

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

А как иначе? Написал программу, протестил. Все ошибки вычестил. Но нет гарантии что их там нет. Для этого существуют тестеры. Тестеры тестируют, находят ошибки возврящяют продукт. Ошибки иправляются, тестеры опять проверяют. После нормального тщятельного тестирования в принцепе можно со 99,99% увереностью сказать что ошибок нет. Но тестеры тоже люди и тоже могут допустить ошибки. От этого ни кто не застрахован. Если продукт "серьёзный", то нужно сделать несколько цыклов тестирования.

Вот поэтому разработчик допускает, что ошибки могут быть (не есть, а могут быть). А если разраб отдает тестерам продукт, зная что там есть бага - смысыл его отдавать на тестирование/выпускать. Все равно вернут или будут рекламации.

 

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

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

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

Канечно ДА! И ни в коем случае не выпущю продукт зная что он сбоит. И ошибки обычно выявляются в более короткие сроки. И 10000 цыклов рабочего хода целый месяц - это уже скорее тест на износ.

Если этот агрегат есть управление ядерным реактором? Или бортовой компьютер авиалайнера? Наверно в суперджет100 и в фобасгрунт также писали прогу - за месяц 2 сбоя - можно считать изделие пригодным. )))

 

Ну а если это телефон, телевизор или медиаплеер? Если какой нить Sony будет выпускать сотки с 2-мя сбоями в месяц - это на руку конкурентам. Ни разу не видел чтобы телевизор где-то(у кого-то) завис. Зато дома медиаплеер время от времени глючит. Верну по гарантии и больше эту марку ни когда не куплю.

[Enthusiast 0]

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

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

Да, я считаю точно также. А Вы считаете, что программные решения надежнее аппаратных?

 

Широта рассуждений поражает :) Гугл на который вы ссылаетесь уже перевел свои серверы работающие " 24/7/365" на микроконтроллеры с bare metal прошивками ?

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

[juvf 10]

Поэтому оси и применяют даже в ущерб надежности.

ос != "ущерб надёжности"

[sasamy 9]

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

 

Ну вы как-то скачете из угла в угол - я же вам прямой вопрос задал про использование ОС vs bare metal, а вы с темы съежзаете. Хотя я могу ответить за вас - большинство задач на современном уровне развития без ОС вы просто не решите, автоматика и прочие биосы - это всего лишь исключение.

[haker_fox 60]

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

Вы схемотехник или руководитель, я угадал? :rolleyes:

 

Ну вот, давайте ОС заменим аппаратным решением. Как это будет выглядеть? Под ОС я подразумеваю не голый шедулер, но сервисы (мьютексы, очереди, что там еще есть?), драйвера, различные сетевые и не только службы. Как весь этот суп организовать аппаратно? Пусть даже на ПЛИС? Это возможно?

[Enthusiast 0]

Вы схемотехник или руководитель, я угадал? :rolleyes:

 

Ну вот, давайте ОС заменим аппаратным решением. Как это будет выглядеть? Под ОС я подразумеваю не голый шедулер, но сервисы (мьютексы, очереди, что там еще есть?), драйвера, различные сетевые и не только службы. Как весь этот суп организовать аппаратно? Пусть даже на ПЛИС? Это возможно?

Оба раза мимо: сейчас я просто студент :)

Я хочу сказать, что по возможности в разработке электронных устройств следует избегать использования операционных систем, исполняющихся из динамического ОЗУ, во избежание непредсказуемых сбоев в работе электронных устройств. Если же сложность разработки устройства не позволяет избежать применения ОС с динамическим ОЗУ для сокращения трудозатрат при разработке, то тогда лучше делить устройство на несколько независимых узлов аппаратно. Задачи управления следует решать без использования ОС, а взаимодействие с пользователем и прочие менее критичные к надёжности работы задачи выносить на аппаратуру, управляемую операционной системой из динамического ОЗУ. Имеющий разум и уши да услышит.

[MrYuran 16]

Я хочу сказать, что по возможности в разработке электронных устройств следует избегать использования операционных систем, исполняющихся из динамического ОЗУ

Большинство ембеддед-осей исполняется не только не из динамического, но и вообще не из ОЗУ.

[juvf 10]

Оба раза мимо: сейчас я просто студент :)

Я хочу сказать, что по возможности в разработке электронных устройств следует избегать использования операционных систем, исполняющихся из динамического ОЗУ, во избежание непредсказуемых сбоев в работе электронных устройств.

Не нужно ни чего избегать. Нужно избегать использовать ненадёжные аппаратные и програмные продукты.

 

Чем не нравится связка ос+диманическоеОЗУ? Что, ос както по другому будет работать в динамическом озу нежели в статическом? А связка ос+статическоеОЗУ надёжнее? Или связка суперлуп+диманическоеОЗУ надёжнее? ОС вообще не знает, что озу может быть динамическим или статическим, и что исполняемый код находится в озу или в пзу.

 

 

[_Pasha 0]

Кстати, в станции EWSD от Siemens тоже используется Unix в качестве базовой системы.

Помню эту конкуренцию, всё-таки, хорошо, что сиэстел попыталися сделать своё. Жаль, что энтузиазм также по экспоненте.. А нынче от завода Шевченко - тут промолчу.

[AlexandrY 3]

Большинство ембеддед-осей исполняется не только не из динамического, но и вообще не из ОЗУ.

 

Нынче не разберешь из чего они выполняются. Понаставили всяких акселераторов, промежуточных FIFO, кэшей.

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

И что с такими ошибками делать?

Еще не видел RTOS которые бы что-то с этим делали. В лучшем случае когда все пойдет в разнос удалят задачу.

В рамках RTOS реально сложно бороться с проблемами сырости аппаратуры и туманности спецификаций.

Проще использовать линейный код без переключений контекстов, динамических ссылок и HAL уровня и статический анализаторы кода с трассером и все тотально прошерстить. Проще в плане достижения реальной надежности.

 

 

 

[VslavX 0]

Нынче не разберешь из чего они выполняются. Понаставили всяких акселераторов, промежуточных FIFO, кэшей.

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

И что с такими ошибками делать?

Еще не видел RTOS которые бы что-то с этим делали. В лучшем случае когда все пойдет в разнос удалят задачу.

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

 

Проще использовать линейный код без переключений контекстов, динамических ссылок и HAL уровня и статический анализаторы кода с трассером и все тотально прошерстить. Проще в плане достижения реальной надежности.

Проще-то оно проще. И такой простой подход получается применять пока программы несильно сложнее уровня "Hello, world" пишутся. А потом, по мере усложнения программы начинаешь понимать, что HAL-уровень не просто так появился, и таки суперлуп себя изживает.

 

Вот у нас софт для основной линейки продуктов развивался так:

- 1992.. - линейный код, чистый ассемблер x86, примерно 16к кода

- 1995.. - линейный код, некоторые протоколы в фоне на прерываниях, все еще ассемблер x86, 32-64К кода

- 1996.. - ассемблер частично помирает, фоновые прерывания, 50+ процентов C

- 1997.. - первое портирование на другой контроллер (первые Мега103), доля C неудержимо растет

- 2000.. - уже есть опыт с Win32, хочется и на встраиваемой платформе такое поиметь, но ресурсов нету, суперлуп становится очень сложным и достаточно глючным, протоколы в фоне на прерываниях тоже плодятся, поддерживать с адекватным качеством становится не совсем просто

- 2006.. - появились 32-битники с ресурсами, с ценой которую уже можно иногда позволить, изучается вопрос RTOS, начинается разработка своей вытесняющей платформы.

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

- 2013..?? - перевод основного приложения на платформу RTOS. Ага, суперлуп до сих пор жив в основном коде приложения, но он на сегодня глючит и создает больше проблем чем RTOS-платформа. Это я называю - "загибается". Ну не получается весь этот разросшийся за два десятилетия функционал простым циклом нормально обработать. Сейчас изделие обрабатывает и обращения по разным протоколам, и различную периферию с кучкой протоколов, и оператор бывает с ним работает, и сетевые обращения, и веб-сервер, и по USB-MSD иногда могут данные забирать. И всем этим все еще пытается рулить суперлуп. Не, оно-то все крутится в "фоне", в своих задачах, но суперлуп с трудом уже может хотя бы просто адекватно рулить всем этим через свои убогие монопоточные интерфейсы.

 

В-общем, на сегодня я рассматриваю RTOS просто как не самый плохой способ модульной организации проекта. Не то чтобы очень уж хотелось ее применять, но жизнь (разрастание и повышающаяся сложность проектов) заставляет как-то организовываться. ИМХО, единственный относительно серьезный минус вытесняющей RTOS - она просит некоторые ресурсы - и память кода для размещения, и оперативную память для стеков. Все остальное вполне решаемо. Ну да, квалификация от системного/встраиваемого программиста требуется немного повыше чем для линейного "Hello, world", но не запредельная, да и расти профессионально всегда приятно. Проблема надежности у меня решается жестко - 10-15 процентов кода это ASSERT-ы. И надо сказать последние года три сработки ASSERT-ов меня вообще не беспокоят.

 

Ну и байка напоследок - благодаря RTOS я познакомился со своей будущей женой :)

Была некоторая физическая лаборатория, где сидела милая девочка-аспирантка и снимала параметры с экспериментальной установки. Лаборатория имела кое-какое финансирование, и прикупила одну из первых в университете IBM AT/286. Сначала девочка просто щелкала тумблерами на установке и вносила параметры в файл. Потом лаборатория прикупила нановольтметр с интерфейсом КОП (ака IEEE-488/GP-IB), и еще кое- какие КОП-онизированные приборы, ну и тут нарисовался я - молодой и красивый , с опытом разработки контроллера КОП для шины МПИ. Контроллер успешно был переработан для шины ISA, и написалась программа, которая сама щелкала тумблерами, снимала все параметры и писала в файл. Девочка была симпатичной, а тут еще и первая увиданная АТ-ишка с VGA-мониторчиком, и Wolf3D как раз появился. Ну глупо же было на целый рабочий день запускать экспериментальную программу (ну да, MS-DOS, и экспериментальный цикл непрерывный, с заливкой гелия и азота) и терять внимание девочки, и еще тратить время диковинного компьютера с цветным монитором.

Поэтому был написан такой себе резидентный вытесняющий двухзадачный планировщик. Програмка вставала резидентно, и меряла себе там в фоне по-необходимости. Написана она была достаточно просто на Паскале, писалась моей будущей женой и ее коллегами, грузить их всякими системными тонкостями было неприлично, пришлось "брать удар на себя" - все хитрости делал именно планировшик, помнится он даже контекст FPU переключал. Ну и AT/286 освобождалась для запуска Wolf3D - это был отличный повод наведываться в ту лабораторию. В-общем, первый опыт применения RTOS у меня достаточно успешный - девочка вышла за меня замуж и защитила диссертацию. Так что RTOS-ы не столь уж опасны (хотя.. как посмотреть ).

 

 

 

[haker_fox 60]

Оба раза мимо: сейчас я просто студент :)

Гм... это вариант я не учел :rolleyes:

Но он многое объясняет. Это Вас в Университете так учат, или Вы сами к таким выводам пришли?

Если перое - не бросайте Университет, но читайте больше самостоятельно, анализируйте как делают другие. Реально делают, а не для лекции.

Если второе - ну нормально, у каждого должно быть свое мнение. Правда, как показывает практика, практика (извините за тавтологию) немного иная :rolleyes:

 

[vshemm 0]

Оба раза мимо: сейчас я просто студент :)

Я хочу сказать, что по возможности в разработке электронных устройств следует избегать использования операционных систем, исполняющихся из динамического ОЗУ, во избежание непредсказуемых сбоев в работе электронных устройств.

...

Имеющий разум и уши да услышит.

 

Нынче не разберешь из чего они выполняются. Понаставили всяких акселераторов, промежуточных FIFO, кэшей.

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

И что с такими ошибками делать?

Еще не видел RTOS которые бы что-то с этим делали. В лучшем случае когда все пойдет в разнос удалят задачу.

В рамках RTOS реально сложно бороться с проблемами сырости аппаратуры и туманности спецификаций.

Проще использовать линейный код без переключений контекстов, динамических ссылок и HAL уровня и статический анализаторы кода с трассером и все тотально прошерстить. Проще в плане достижения реальной надежности.

 

Интересная мысль.... Вообще, надежность и применение ОС - понятия в общем случае слабо связанные, но я попытаюсь

показать, что надежность программно-аппаратного комплекса (прибора) может повысится из-за применения ОС.

 

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

некоторую математическую модель, которая по определению лишь приближенно описывает физическую реальность. Чтобы

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

ОС - не что иное, как дополнительный слой абстракции, набор сущностей придуманных умными людьми (типа Дейкстры,

Хоара и пр.) плюс развитый матаппарат, на основе которых описывать и верифицировать модели намного проще. Этот

слой также позволяет эффективно декомпозировать задачу на слабосвязанные части (модульность), что положительно

влияет на скорость и стоимость разработки, масштабируемость, сопровождение и т.д. (при прочих равных по сравнению

с суперлупом).

 

Теперь рассмотрим вопрос о количестве ошибок в программе. Чтобы убедиться, что их там нет, необходимо:

1. Формально верифицировать математическую модель программы.

2. Формально верифицировать исходный код программы на соответствие этой модели.

3. Формально верифицировать компилятор на правильную кодогенерацию под определенную железную архитектуру.

4. Верифицировать железо на соответствие архитектурной модели под которую компилятор производит кодогенерацию.

До тех пор, пока этого не сделано, ошибки в программе есть.

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

а пользовательского кода становится меньше и матмодель проще.

 

Не стоит забывать, что дополнительный слой абстракции вносит свой оверхед в общую сложность, и для простых задач

применять ОС может быть невыгодно. Кроме того, ОС бывают разные, как по функциональным возможностям, так и по

областям применения (и по стоимости, сертификации и т.д.) - критериев масса.

 

В уже упоминавшейся NASA есть интересный документ [1], в котором хоть и тезисно, но рассматриваются подобные

вопросы проектирования. В частности, вопрос выбора "без ОС" vs "одна из существующих ОС" vs "разработка своей ОС".

Настоятельно рекомендую к прочтению. Более глубоко вопросы дизайна эмеддед систем рассматриваются в [2] - тоже

must read, имхо.

 

------

[1] http://www.hq.nasa.gov/office/codeq/doctree/871913.pdf

[2] http://www.ee.ui.ac.id/muis/course_file/Re...nd_Analysis.pdf

 

P.S. Я специально не касался ошибок при эксплуатации (а-ля сбои из-за случайных частиц и прочего), т.к. это

отдельная тема. Но и там ОС выигрывают у суперлупа из-за уже существующих моделей при fault/failure кейсах.

А если AlexandrY не видел такие ОС, которые бы "что-то с этим делали", то это не значит, что их нет.

Даже если сравнивать программно-аппаратное решение с чисто аппаратным, однозначно сказать что последнее

надежнее - нельзя (опять же, смотрим [1] и [2]).