Самолет от этого не падает.
Самолет от этого не падает.Правда? Отказ WXR не критичен? Во это новости...
Опа? Правда? Вы сделали мой день. Тем не менее без WXR по MEL можно лететь только при очень ограниченных условиях.Самолет от этого не падает.
Так я же не говорю, что скрипач не нужен. Нужен, но его отказ не является катастрофическим.без WXR по MEL можно лететь только при очень ограниченных условиях
Я не совсем корректно выразился. Я имел ввиду, что вы не станете выводить 3Д реалистичную картинку на основной дисплей, потому что тогда при проблемах с мощной видеокартой станет недоступной не только не критичная картинка с радара. То есть все равно сделаете критичные системы на проверенных чипах, а "навороты" отделите, потому что главная причина не в том, что современные компы нечем было бы занять в самолёте, а именно в том, что критическая часть делается на проверенных деталях.Это таки требует ресурсов. Но отказ данной системы не критичен.
Мне кажется, мажоритарная схема хороша при отказах свзанных с браком или эксплуатации. Отказ вызванный аппаратной ошибкой (например, когда процессор какую-либо команду выполняет не так, как задумано при определенных редких условиях) приведет хоть на сотне одинаковых компьютерах к одинаковой ошибке. Если только ставить компьютеры на разных процессорах.Например используя мажоритарную схему на трех разных аппаратных платформах, как в том же 777.
Спросите у эксперта Kit. , он вам раскажет про подходы к проектированию софта в автомотив, ключевые слова autosar, mcal.программы на МК вынуждены в большинстве случаев работать с переферией, потому что иметь прокладку в виде ОС и драйверов слишком жирно.
Вам не стоит идти в системщики. С таким подходом вместо результата вы будете находить причины почему не сделано. Здесь подход "с моей стороны пули вылетели" не работает.Ну вот мы и пришли к утверждению,
В 777 FBW на разных процессорах и с разнвм ПО в одном блоке PFC.Мне кажется, мажоритарная схема хороша при отказах свзанных с браком или эксплуатации. Отказ вызванный аппаратной ошибкой (например, когда процессор какую-либо команду выполняет не так, как задумано при определенных редких условиях) приведет хоть на сотне одинаковых компьютерах к одинаковой ошибке. Если только ставить компьютеры на разных процессорах.
Впрочем, если ошибки будут спорадическими, но частыми, но для эксплуатантов это все равно будет ад, который рано или поздно плохо кончится.
Впрочем, уверен, что в реальности, все будет прозаичнее: просто процесс создания авионике на сыром процессоре будет выглядеть как типичное "до готовности всего год", по причине того, что сырое нестабильное устройство никто не рискнёт ставить в самолёт.
А это смотря в каких условиях. В 99% случаев WXR критичен.Так я же не говорю, что скрипач не нужен. Нужен, но его отказ не является катастрофическим.
Вот, кстати,, слышал о таком и давно хотел узнать: это типичная практика или нет? Насколько это "роскошь" для разработчиков?В 777 FBW на разных процессорах и с разнвм ПО в одном блоке PFC.
Это не роскошь, это требование.Насколько это "роскошь" для разработчиков?
это типичная практика.Вот, кстати,, слышал о таком и давно хотел узнать: это типичная практика или нет? Насколько это "роскошь" для разработчиков?
За меня переживать в этой ситуации нужно меньше всего: "системщики" обычно по ту сторону, где выбирают "где лучше". Я бы больше беспокоился за конечных потребителей, ибо результаты их труда (производительность и уровень жизни, в конечном счёте) в современной экономике находятся в прямой зависимости от средств производства, инфраструктуры и т.п.. созданных и поддерживаемых "системщиками". Когда "умников" и "недостаточно идейных" "интеллектуалов" перестают слушать, то обычно оптимизм у большинтсва относительного быстро заканчивается )Вам не стоит идти в системщики. С таким подходом вместо результата вы будете находить причины почему не сделано. Здесь подход "с моей стороны пули вылетели" не работает.
Я и не переживаю. Вы задали вопрос, я вам ответил, исходя из ваших предыдущих постов.За меня переживать в этой ситуации нужно меньше всего
Ну что ж, значит задачи по созданию собственного процессора доя авионики умножаем на два. Ну хоть не так часто самолёты попадать будут - уже хорошо ))))это типичная практика.
Вот прямо вчера обсуждали с инженерами, как будем обеспечивать требование независимости отказов в разрабатываемом блоке.
Решили делать два независимых вычислителя на разной элементной базе.
В PFC не какие то "собственные процессоры для авионики" а обычные промышленные насколько я знаю. И их три разных, а блоков PFC тоже три... безопасность прежде всего.Ну что ж, значит задачи по созданию собственного процессора доя авионики умножаем на два. Ну хоть не так часто самолёты попадать будут - уже хорошо ))))
Ну мы тут обсуждаем гипотетическое создание отечественных процессоров и микроконтроллеров, которые можно было бы производить полностью в России . Так как их пока никаких нету, то соответвенно для двух разных нужно создать два для трех разных - три , ну и т.д.В PFC не какие то "собственные процессоры для авионики" а обычные промышленные насколько я знаю.
А можно просто создать 2-3 типовых процессора и архитектуру строить уже из учёта имеющихся ресурсов и возможностей... Все равно переделывать в блоках платы пин в пин не получится. А адаптировать уже имеющиеся алгоритмы под новое железо это не такая и сложная уж задача... Да потребует времени... Но любая разработка требует времени. Недостаток ресурсов, мощности, периферии также легко закрывается аппаратно установкой дополнительных компонентов, переходом на архитектуры с несколькими микроконтроллерами и разделением задач. Везде можно найти способ выкрутится.Ну мы тут обсуждаем гипотетическое создание отечественных процессоров и микроконтроллеров, которые можно было бы производить полностью в России . Так как их пока никаких нету, то соответвенно для двух разных нужно создать два для трех разных - три , ну и т.д.
Скорее сначала делают архитектуру, а потом на ее основе нужные процессоры , в том числе используя типовые блоки. Проблема в том, что даже имея доступ к готовым архитектурам и типовым блокам процессоры у нас создавали не то, чтобы быстро (все новое делается не быстро). Но когда процесс казалось бы вышел на финишную прямую и начали появляться плоды, произошло то, что произошло и нужно создавать почти все с начала. И задач при этом подросло: раньше можно было озадачиваться лишь теми направлениями, что лучше получаются или для создания которых есть ресурсы (человеческие прежде всего), то теперь нужно все и сразу и выбирать не приходится.А можно просто создать 2-3 типовых процессора и архитектуру строить уже из учёта имеющихся ресурсов и возможностей...
Я надеюсь мы не пойдем по кругу снова обсуждая разницу между возможностью выкрутится в каждом конкретном случае, которая почти всегда есть, и неоходимостью сразу решать проблемы по многим направлениям (часто взаимозависимым), которая не техническая, а скорее экономическая, финансовая и трудоресурсная так сказать? Я на этот счёт свою точку зрения уже озвучил.Да потребует времени... Но любая разработка требует времени. Недостаток ресурсов, мощности, периферии также легко закрывается аппаратно установкой дополнительных компонентов, переходом на архитектуры с несколькими микроконтроллерами и разделением задач. Везде можно найти способ выкрутится.
Да, лучше быть здоровым, богатым, и с процессором. Да ещё к процессору мануал доступный для скачивания "без регистрации и смс", отладочные платы и бесплатные образцы для ознакомления партнёрам. Больше доступности хорошей и разной. Если бы ещё и в текущей реальности и в этой жизни... Так мы бы тогда ух!Главное не это - главное чтобы эти 2-3 типовых процессора были доступны для разработчика...
Этого все хотят. И не только процессоры, а хорошо бы у нас производились и самолёты хорошие, и автомобили, и много чего ещё. На половине этого форума как раз обсуждается почему этого не наблюдаетсяИ самый лучший способ если бы они производились у нас
Противоречие утвержденияладно, 3 заход)... Ну и что вы выделили?
реальности. В частности.Например, в мк быстродействие вообще определяется топонормой флешпамяти.
Вообще-то мы говорим о мк, разработчиков которых не смутила идея сделать ядро с частотой выше 100 МГц. Вы их считаете некомпетентными? Или вы считаете некомпетентными тех, кто такие мк устанавливает в собственную продукцию?разве непонятно, что все эти игры с кешем, ускорителями флеш-памяти, выполнением кода из ОЗУ вызваны тем, что выполнение кода из флеш не обеспечивает полной утилизации ресурса ядра. На пальцах.
контроллер 1. более современный мк частота ядра - 72 МГц, флеш - 25 МГц; олдскульный контроллер 2. Частота ядра - 50 МГц, флеш - 25 МГц. Переход на более современный мк не обеспечит рост производительности в 72/50 = 1.4 раза. Так понятнее?
Реальность такова, что для уменьшения ограничений скорости флеша применяют те или иные ухищрения (кеш команд).реальности.
Я их не противопоставлял. Это ваши домыслы. Читайте внимательнее.современных микроконтроллеров (тех, об "импортозамещении" которых идёт речь) и микропроцессоров в целом.
Ну тогда потрудитесь узнать на какой частоте работает флеш в этом мк. Принципиальной разницы не будет.Вообще-то мы говорим о мк, разработчиков которых не смутила идея сделать ядро с частотой выше 100 МГц