The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Обсуждение проблем применения Linux в авионике, opennews (??), 02-Июл-23, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


6. "Обсуждение проблем применения Linux в авионике"  +2 +/
Сообщение от Аноним (6), 02-Июл-23, 10:29 
>не должно быть никаких систем с Linux, Windows, MacOS

А собственно почему не должно? Попробуйте аргументировать.
>Проще говоря универсально решения в этом случае нет

Наверное вы пробовали его найти, раз так утверждаете?

Ответить | Правка | Наверх | Cообщить модератору

13. "Обсуждение проблем применения Linux в авионике"  +1 +/
Сообщение от Аноним (7), 02-Июл-23, 10:40 
Это больше про большие объемы вычислений: выдриссированы под пользовательские системы с относительной низкой отзывчивостью. А значит в специфике среднее значение специалистов будет под сервера и клиент-серверные установки.
Ответить | Правка | Наверх | Cообщить модератору

19. "Обсуждение проблем применения Linux в авионике"  –2 +/
Сообщение от Аноним (6), 02-Июл-23, 10:51 
Про системы с высокой "отзывчивостью" вы видимо не в курсе? Про специальные линуксы, используемые в промышленности тоже не в курсе? Тады ой. Судя по общим словам - вы не специалист. Зачем тогда в диалог лезете?
Ответить | Правка | Наверх | Cообщить модератору

23. "Обсуждение проблем применения Linux в авионике"  +7 +/
Сообщение от Аноним (7), 02-Июл-23, 10:56 
Специальные линуксы не подходят под требования в авионике. Новость читали?
Ответить | Правка | Наверх | Cообщить модератору

30. "Обсуждение проблем применения Linux в авионике"  +5 +/
Сообщение от Аноним (6), 02-Июл-23, 11:10 
Ну так и обсуждайте новость в чем проблема! Я же не лезу на форум лингвистов или рыбаков со своим ценным мнением. Почему тут то всегда какие-то мамины попросëнки вылезают и рассказывают общими словами что в индустрии должно быть, а чего нет?
Ответить | Правка | Наверх | Cообщить модератору

110. "Обсуждение проблем применения Linux в авионике"  +/
Сообщение от Аноним (106), 02-Июл-23, 16:03 
Потому что могут! Нет он как бы того этого опен!
Ответить | Правка | Наверх | Cообщить модератору

89. "Обсуждение проблем применения Linux в авионике"  +/
Сообщение от Аноним (89), 02-Июл-23, 13:59 
В новости сказано, что теорию о ненадехности линукса высказали специалисты фирмы Боинг. На минуточку, это те самые люди, которые до сих пор борются с проблемами ПО в космическом корабле Старлайнер, а еще есть такой самолет Боинг737МАХ у которого вообще нет проблем с ПО, но пара самолетов упала
Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

113. "Обсуждение проблем применения Linux в авионике"  –2 +/
Сообщение от Аноним (112), 02-Июл-23, 16:23 
А твои самолёты как летают не похвастаешься? Боинг немного отличается в мелочах от твоей фанерки склееной в клубе авиамоделистов.
Ответить | Правка | Наверх | Cообщить модератору

128. "Обсуждение проблем применения Linux в авионике"  +/
Сообщение от Аноним (149), 02-Июл-23, 17:48 
А что, тот анон смог написать полетный софт хотя-бы фанерке? :)
Ответить | Правка | Наверх | Cообщить модератору

175. "Обсуждение проблем применения Linux в авионике"  +/
Сообщение от Аноним (175), 03-Июл-23, 06:46 
Когда упали? Что-то не слышал в последнее время о катастрофах
Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

178. "Обсуждение проблем применения Linux в авионике"  +/
Сообщение от Аноним (178), 03-Июл-23, 07:53 
Ребят, мне прям льстит, что вы меня с боингом сравниваете, буду стараться!
По поводу того почему падал 737МАХ, гугл вроде ни кого не банил еще, вот например:
https://ru.wikipedia.org/wiki/Boeing_737_MAX#%D0%9...
Ответить | Правка | Наверх | Cообщить модератору

212. "Обсуждение проблем применения Linux в авионике"  +/
Сообщение от Аноним (197), 03-Июл-23, 14:12 
> Когда упали? Что-то не слышал в последнее время о катастрофах

Да вот есть у боинга чудная подсистемка, MCAS - https://en.wikipedia.org/wiki/Maneuvering_Characteristics_Au...

В энных версиях софта на 737MAX она вела себя специфично - вызывая проблемы в взаимодействии с пилотами. На это материлось довольно много пилотов - а 2, вот, угробились совсем, по сути не найдя взаимопонимания с этой системой. В 1-й раз боинг смог как-то отбрехаться, но когда история повторилась точно так же, все поняли что это не случайность. И там много интересного всплыло. И те матюки пилотов на MCAS, и скидки "своему" производителю при сертификации FAA. Вот там уже все конкретно огребли, MAX'ам запретили вылеты и тут уже чинить свои факапы боингу пришлось очень даже.

А по факту -2 самолета из-за в общем то дурного поведения софта.

Ответить | Правка | К родителю #175 | Наверх | Cообщить модератору

32. "Обсуждение проблем применения Linux в авионике"  +1 +/
Сообщение от Аноним (32), 02-Июл-23, 11:15 
Совершенно внезапно хардверные вопросы должны решаться в первую очередь с хардверной стороны, инженерные с инженерной. А дистрибутивчики - это больше про медиасистемы и картинки показывать. А то народ уже хочет прокладку между креслом и монитором использовать чуть ли не для решения проблем с загоревшимся двигателем
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

126. "Обсуждение проблем применения Linux в авионике"  +/
Сообщение от Аноним (149), 02-Июл-23, 17:34 
> Совершенно внезапно хардверные вопросы должны решаться в первую очередь с хардверной стороны, > инженерные с инженерной. А дистрибутивчики - это больше про медиасистемы и картинки
> показывать.

Картинки разные бывают. Glass cockpit - тоже как бы картинки показывает. А вот если там что-то пойдет не так, вероятно, пилоту придется здорово понервничать.

> А то народ уже хочет прокладку между креслом и монитором использовать чуть
> ли не для решения проблем с загоревшимся двигателем

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

Ответить | Правка | Наверх | Cообщить модератору

146. "Обсуждение проблем применения Linux в авионике"  +2 +/
Сообщение от Аноним (145), 02-Июл-23, 19:19 
>>не должно быть никаких систем с Linux, Windows, MacOS
>А собственно почему не должно? Попробуйте аргументировать.

Вы можете математически доказать, что они будут делать только то, что от них ожидают? То есть доказать, что код не содержит ошибок и уязвимостей? Конечно нет, поэтому в таких системах должно быть как можно меньше кода. Любая ошибка может стоить жизни сотням людей и принести ущерб в сотни миллионов $. Никакая экономия на программистах не сможет окупить и одну ошибку в коде. Ну и пишут надёжный код не на Си и даже не на Rust, пишут на языке Ada.

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

170. "Обсуждение проблем применения Linux в авионике"  +/
Сообщение от Бывалый смузихлёб (?), 03-Июл-23, 02:44 
Как и зачем можно математически доказать что-то для исходников, учитывая, что они потом компиляюццо и в самом железе могут происходить всякие внезапности ?

Всякие ОСРВ в т.ч для медицинского и иного с повышенными требованиями применения аккурат на сишке обычно и написаны

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

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

Ответить | Правка | Наверх | Cообщить модератору

233. "Обсуждение проблем применения Linux в авионике"  –2 +/
Сообщение от U202204161753 (?), 03-Июл-23, 16:55 
(
   " Читал SMS -ку, много думал "
А потом решил уточнить
)

  Интересно, что именно неожиданного в мажоритарном вычислителе 3 плюс один, памяти с ECC и коррекцией ошибок и всём во  этом на сапфире с золотыми контактами и керамической платой может произойти?

Всё что только можно придумать - уже ожидаемо.

  Далее - возможно, несвязанное:

Ada SPARK , шведы, сертифицированное для управления сердцем - читали?


P.S.

У пишущих на Си, скорее всего, не хватает базового образования.

Или чувства самосохранения.

Или всякие коррупционные схемы, т.е ложная уверенность, что их-то не посадят

Ответить | Правка | Наверх | Cообщить модератору

238. "Обсуждение проблем применения Linux в авионике"  +1 +/
Сообщение от Аноним (149), 03-Июл-23, 17:17 
> P.S. У пишущих на Си, скорее всего, не хватает базового образования.

Учитывая что на сях написано большая часть фирмвар в том числе на транспорте, например, automotive и последние линии защит в упрвлении опасными процессами то? Конечно "тойота" иногда случается, особенно как раз у любителей ртосов понавороченнее которые использование стека оценить не могут и выносят блок переменных за ним. Ну так и ариан5 случается. А общего у них то что и те и другие забили на best practices.

Ответить | Правка | Наверх | Cообщить модератору

250. "Обсуждение проблем применения Linux в авионике"  –1 +/
Сообщение от U202204161753 (?), 03-Июл-23, 17:38 
(
   С "Ариан-5" всё было не так.
  Я когда искал исходные коды к этому инциденту, сперва сам их написал, основываясь на коде с отключённой одной проверкой из трёх.

   И вот по этому коду, ушедшему в "продакшен" после 7-10 лет "по одному запуску в год" и нашёл нужный материал
)


"Тойота" - и есть та коррупционная схема. Работала пока продавали на подконтрольной территории. А в USA их "сдали" "органам". Ну далее - масса материала в Инете.


P.S.


> на сях написано большая часть фирмвар в том числе на транспорте, например, automotive и последние линии защит в упрвлении опасными процессами то?

Точно так же: сдать и на лесоповал.

И сохраняя в цикле этот инвариант, оставить вне забора из колючей проволоки только вменяемых. Тех что читали книги, а не просиживали штаны в ВУЗе.

(
    Не переживаем  - это мозговой штурм.

   Никто никого не посадит

  С чего бы это капиталистам этим озадачиваться? Их никогда не заботили индейцы и пролетарии.

У нас с ними разные цели.
См. про классы и т.п
)

Ответить | Правка | Наверх | Cообщить модератору

260. "Обсуждение проблем применения Linux в авионике"  +/
Сообщение от Аноним (149), 03-Июл-23, 18:13 
> С "Ариан-5" всё было не так.

Я расследователям верю несколько больше чем случайным фэйсам с опеннета. В любом случае, кейс показал что ада мягко говоря не панацея.

> Я когда искал исходные коды к этому инциденту, сперва сам их написал,

Не понимаю что доказывает самописный код.

> "Тойота" - и есть та коррупционная схема.

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

Во первых они взяли навороченный RTOS, повысив сложность системы.
Во вторых - квалификации кодеров не хватило на оценку worst case в использовании стека.
В третьих у них не было плана на случай если региона стека не хватит. Микроконтроллеры относительно простые системы, там нет страничной памяти и как максимум есть более простая железка для защиты нескольких регионов памяти. Поэтому чтобы поймать переполнение стека надо отдельно явно озаботиться вопросом. Чего в тойоте никто не сделал. Что довольно странно для автомотивщиков.
В четвертых, их лэйаут памяти параноей не страдал - и за стеком жили критичные переменные. Которые оно и перетирало. В том числе и описание чего водила педалью хотел.
В пятых, про идеи оценки валидности переменных, их кросс-верификацию и оценку корректности эволюции состояния систем они явно не слышали. Или кодеру было пох. Хотя любой вменяемый firmware safety guideline дает весьма здравые идеи что делать с критичными переменными как прикинуть что мы вообще в валидном состоянии работаем, что вот эту функцию вызвали в ходе нормального flow программы а не так что частица влетевшая в проц program counter скрутила, и так далее. Тойотеры были явно не в курсе этого или клали на это ....
В шестых, оказалось что они заткнули варнинги MISRA checker. А это уже совсем дно.

Коррупция может какой-то вклад и имела но реально это хреновая организация процессов и некомпетентность в топике который это не прощает прежде всего. А регуляторы все же врядли могут сделать реальный аудит вооон какой фирмвари ECU даже если б и захотели.

> Точно так же: сдать и на лесоповал.

"Don't fix what isn't broken" имхо. Какая-нибудь MISRA довольно эффективна как antibug для сей. Но если варнинги чекера затыкать чтоб не мешали сборке проекта - будет примерно как у арианщиков. По похожим причинам.

> Тех что читали книги, а не просиживали штаны в ВУЗе.

В этом мире очень мало книг которые описывают real world системы - и реально существующие проблемы, а не всякие теоретические измышлизмы. Которые зачастую здорово отличаются от того что в реальных системах в реальном мире происходит.

> С чего бы это капиталистам этим озадачиваться? Их никогда не
> заботили индейцы и пролетарии.

А таки при регулируемом капитализме за criminal negligence могут и посадить. И индейцам не хочется быть пролетаями - они class action lawsuit хреначат на раз. А это дорого обходится и вредно для репутации.

> У нас с ними разные цели. См. про классы и т.п )

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

Ответить | Правка | Наверх | Cообщить модератору

279. "Обсуждение проблем применения Linux в авионике"  +/
Сообщение от U202204161753 (?), 04-Июл-23, 10:58 
(
   Про Ариан-5: постараюсь организовать репост конкретики.

   Т.е., в отличие от Тойоты, ваши сведения, примерно, как мои о Т.
)

По Тойота: о, спасибо!
Теперь хоть ясно, что там было.

Из статей на Хабре, наоброт, сложилось впечатление, что кроме как на формальностях японцев "подловить" не удалось.

Да, кстати, про Э.Дейкстра и Ко:
изобретателю семофоров ( или как они там) я бы доверял и остальными идеями.

Хотя бы для перестраховки: вдруг он все "грабли" изучил ещё лет за 10 - 15 до нашего рождения?

Про комбинаторный взрыв у Э.Д. что-то было.

Ответить | Правка | Наверх | Cообщить модератору

284. "Обсуждение проблем применения Linux в авионике"  +/
Сообщение от Аноним (197), 04-Июл-23, 17:05 
> По Тойота: о, спасибо!
> Теперь хоть ясно, что там было.

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

Японцы вообще в вопросах корп. культуры - сильно ниже того чем принято о них думать. А хайтек в свое время у них был благодаря усилиям США, а вовсе не потому что они сами офигенные разработчики. Белый человек отслюнявил им нехилый стек технологий, показав что дружить с ним выгодно.

Вон те знания не являются чем-то уникальным, если их знает анонимус с опеннета. А пришедший наниматься в здоровую корпу на такую работу тип должен вон те вещи как раз-два-три. Его наниматель должен это обеспечить. Как и общее управление проектом. А вот если это не получилось, да еще настолько брутально - пример почему все эти регуляторы и сертификаторы вообще нужны. Чтобы хоть какие-то лимиты на подобный трешак установить. В современном мире регуляторы жестко лагают относительно прогресса, разумеется. А новое знание о проблематике пишется кровью.

> Из статей на Хабре, наоброт, сложилось впечатление, что кроме как на
> формальностях японцев "подловить" не удалось.

Class action lawsuit против них "индейцы" в виде родственников померших водителей IIRC таки подавали. И "реклама" получилась очень даже, особенно у тематических лиц. Не думаю что эмбеддеры будут покупать себе что-то от тойоты, эти вспоминают тойоту в основном в контексте антибага и как делать не надо :))

> Да, кстати, про Э.Дейкстра и Ко: изобретателю семофоров ( или как они там)
> я бы доверял и остальными идеями.

Я никогда и никому не доверяю на 100%, даже себе. Очень мало чего в этом мире реально незыблемые и безусловные константы. Ну может планковская константа. И то я бы не поручился за это.

> Хотя бы для перестраховки: вдруг он все "грабли" изучил ещё лет
> за 10 - 15 до нашего рождения? Про комбинаторный взрыв у Э.Д. что-то было.

Все? Очень сомневаюсь. Отраслевые понимания некоторых проблематик не такое уж старое знание. И оно всегда дополняется. Вот кто-то типа DJB выдал некоторые умные мысли, вида "меньше кода == меньше багов". Это и правда работает, но, увы, не всегда является приемлимым вариантом по другим параметрам.

Ответить | Правка | Наверх | Cообщить модератору

190. "Обсуждение проблем применения Linux в авионике"  +/
Сообщение от Игорь (??), 03-Июл-23, 10:09 
>> Ну и пишут надёжный код не на Си и даже не на Rust, пишут на языке Ada.

Про надежный код на Аде - смешно. Про взрыв ракеты Ариан-5 слышали? "Ракета разрушилась на 40-й секунде полёта из-за неверной работы бортового программного обеспечения". "Этот неудачный запуск стал одной из самых дорогостоящих компьютерных ошибок в истории." "центральный полетный модуль - 60 тысяч строк кода на языке Ада"

Ответить | Правка | К родителю #146 | Наверх | Cообщить модератору

193. "Обсуждение проблем применения Linux в авионике"  +/
Сообщение от Аноним (145), 03-Июл-23, 10:25 
> Про надежный код на Аде - смешно. Про взрыв ракеты Ариан-5 слышали?
> "Ракета разрушилась на 40-й секунде полёта из-за неверной работы бортового программного
> обеспечения". "Этот неудачный запуск стал одной из самых дорогостоящих компьютерных ошибок
> в истории." "центральный полетный модуль - 60 тысяч строк кода на
> языке Ада"

А теперь представь, что их не 60 тысяч, а 30 миллионов и без какого либо статического анализа. Будет лучше?

Ответить | Правка | Наверх | Cообщить модератору

204. "Обсуждение проблем применения Linux в авионике"  +/
Сообщение от Аноним (197), 03-Июл-23, 12:26 
> А теперь представь, что их не 60 тысяч, а 30 миллионов и
> без какого либо статического анализа. Будет лучше?

Ну вообще, корабли Маска вроде на МКС вроде летают, вот как раз с линухом. И почему без анализа? Линух много кто на автомате сканит, тестит, и много чего еще. Знаете что такое syzkaller? А есть такая вещь как syzbot, это пачка syzcaller'ов fuzz'ит кернел, а словив какой-то факап авто-бисектит до проблемного комита и даже ругается в рассылку и показывает на редиску пальцем.

Ответить | Правка | Наверх | Cообщить модератору

234. "Обсуждение проблем применения Linux в авионике"  +/
Сообщение от U202204161753 (?), 03-Июл-23, 17:03 
> пачка syzcaller'ов fuzz'ит кернел

А я вот то ли у Э. Дейкстра, то ли у Хоара читал, что тестирование не показатель отсутствия ошибок.

Т.е. ошиблись классики ?

( что-то "нутром чую - литр будет" и не ошиблись. И не зря с полсотни докторов наук Гриса переводили.

Причём вышло лучше, чем в оригинале на Globish)

Ответить | Правка | Наверх | Cообщить модератору

252. "Обсуждение проблем применения Linux в авионике"  +/
Сообщение от Аноним (149), 03-Июл-23, 17:44 
> А я вот то ли у Э. Дейкстра, то ли у Хоара читал, что тестирование
> не показатель отсутствия ошибок.

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

При том тесты бывают разные. Скажем юниттесты проверяют что накодили блок кода именно так как было задумано. А более глобальные - что оно после интеграции в целое ведет себя адекватно, т.к. на стыке взаимодействий кусков тоже можно отхватить чудес. А бывает вообще fuzzing. Потому что в даташите может и написано что датчик может выдавать от сих до сих, но, знаете, реальный мир может иметь свое мнение на этот счет и сдруевший датчик влет накормит систему какими-то совершенно неадекватными значениями. Если при этом софт навернется - ну, блин, ой. Поэтому долбежка рандомом не панацея но - при достаточной интенсивности успешно ловит неведому хрень.

> Т.е. ошиблись классики ?

Скорее имели синтетическое представление не от мира сего - особенно его актуальной версии. Могу сказать что всякие математические верификации имеют большую проблему: не работают для более-менее крупного софта из-за комбинаторного взрыва, при котором доказать что-то для ВСЕЙ системы в СБОРЕ что-то становится малореально. А даже если вы проверили отдельные мизерные кусочки это не доказывает что они вместе делают что-то адекватное. Более того - в штуке размером с самолет чертова куча разных систем взаимодействующих между собой. Писаных разными кодерами. И то что 2 разные тимы одинаково поняли формальное описание и все краевые случаи - мягко говоря не факт.

Как угодно но мир стал сложнее. В нем стало больше данных и все хотят больше фич. Если первые авиаторы сидели на воздухе, дергали рычаги от и до сами, то теперь хотят систему автоматической посадки, спутниковую навигацию, анализ топологии местности - и предупреждение что впереди гора, приборов постепенно стало столько что пилоты начали зашиваться, особенно в ситуации отличной от идеала. Не говоря о том что в сотнях проводков, тросиков и чего там еще все время что-то барахлит и из-за отсутствия средств самодиагностики хрен поймешь что. А разбирать самолет от и до перед каждым вылетом никто не будет. И пилот сталкивается с дилеммой, лететь ему абы как или резко и дорого обломать всем кайф под угрозой линча руководством - и все же пусть техники более плотно займутся. Заодно оказалось что умные машины могут лучше знать параметры машины и например не дать пилоту делать явно провальные действия. И ясен фиг логика всего этого - ни в раз не тривиальная. Как и коммуникации с продвинутыми датчиками, перекидывания кучей сообщений по шинам с пачкой систем и проч. Топологически современный транспорт это ездящие, летающие и плавающие сети компьютеров и микроконтроллеров. Это совсем другой паттерн. Со своими специфичными проблемами - но это лучше чем то что было до этого, назад никто не вернется.

> с полсотни докторов наук Гриса переводили.

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

> Причём вышло лучше, чем в оригинале на Globish)

Да вот как бы вам сказать... азы antibug coding годные для практических применений в управляющих системах мне вот например в основном в libera.chat програмеры объяснили + несколько ресурсов жестких профессиональных эмбедеров, которые гамна лаптем покушали на практике. То что так кто-то в РФ может я честно говоря сильно сомневаюсь. А вон та магия нехило работает, я более-менее смог в направление и в принципе я начинаю немного доверять своим сишным фирмварям. Бывает так что даже с 1 раза работает как надо, сразу без багов.

А некое "практическое" понимание топика - парочка firmware safety guideline'ов от компаний типа STMicro которые расписывают с чем вообще можно столкнуться (не, теоретики про половину этого тупо не в курсе и в их рассуждизмы сие зачастую не включено, так что система будет себя вести не так как предсказано ими). Это больше для автомотивщиков, но там видите ли люди тоже мрут если ECU или ABS сделает что-то не то, а это кучка проциков с фирмварой да исполниловкой и сетью - по сути "fly by wire lite". Стандартный паттерн дизайна систем.

Авиаторы еще более замороченные, у них всяких рулесов и гайдов еще больше. На что были причины. Тем не менее что касается софта и сертификации, как показали некоторые примеры это все не очень эффективно работает, если боинг игнорит вопли пилотов и даже падение 1 самолета от дурного алгоритма MCAS, и требуется чтобы еще 1 боинг расплющило точно так же, так что тогда даже какой-нибудь посторонний NTSB понимает что тут где-то подстава и имеет всех по полной.

Ответить | Правка | Наверх | Cообщить модератору

275. "Обсуждение проблем применения Linux в авионике"  +/
Сообщение от U202204161753 (?), 04-Июл-23, 10:34 
А каким рентгеном или ультразвуком не удастся "просвечивать" тросы?

(
  Сами пилоты требуют вернуть старорежимный штурвал "с тросиками", как меру "последней надежды"
)


Я за комплекс мероприятий, но оснований не использовать как часть этих самых комплексных мероприятий, в том числе, и Ada SPARK не вижу.

Советские доктора наук при переводе книги Гриса не наломали дров, а, наоборот. Т.е. с этим частным случаем - всё Ок -ей.


  Боинг я здесь где-то рядом за 2 датчика с ручным (!) выбором исправного критиковал

Ответить | Правка | Наверх | Cообщить модератору

280. "Обсуждение проблем применения Linux в авионике"  +/
Сообщение от Аноним (197), 04-Июл-23, 12:04 
> А каким рентгеном или ультразвуком не удастся "просвечивать" тросы?

По всей длине? В том нагромождении? С каким-то более-менее гарантированным выводом? Плохо себе представляю как эти процессы могут быть быстрыми и не трудоемкими. Простой самолета - стоит ОЧЕНЬ дорого.

Как в цифровой системе проверить что у меня исполниловка работает? Дать ей команду отмотать воооон туда! И прочекать что концевик сработал или показания датчика положения ожидаемые. Если прокатило -> подсистема живая, а мы реально проверили функциональность. Быстро, автоматически, "от и до". Конечно раз в эн надо более подробную инспекцию, общего износа механики и проч. Но сильно реже.

А терь попробуйте за разумное время прочекать что у вас вся куча стрелочек вообще что-то показывает и это что-то реалистичное? Хорошо получается?

> ( Сами пилоты требуют вернуть старорежимный штурвал "с тросиками", как меру
> "последней надежды" )

Да вроде обычно делают некий абсолютно минимальный механический бэкап. Типа горизонта и чего еще по мелочи. К тому же голыми руками огромные поверхности пилот хрен пересилит. Ну а электрике и электронике можно аккумуляторы поставить и/или турбинку для набегающего возраста. Что и делают.

> Я за комплекс мероприятий, но оснований не использовать как часть этих
> самых комплексных мероприятий, в том числе, и Ada SPARK не вижу.

Зато их вижу я - Ada используется крайне маргинально и софта на ней и кодеров мизер. А тупые как дрова системы могут быть проблемой. Если UI горбатый и визуализация не доходчива для пилота или экзотичный софт не может допустим актуальные карты нормально отрисовывать, ценность такого улучшения сильно ниже чем могла бы быть. И вот уже кой-кто у...тся об гору, "потому что этой горы не было на карте". Ну и чем ему ада поможет? А была бы навигация попродвинутее - гора была бы на карте а у пилота было бы понимание что туда лететь ни-ни. И даже если софтина рендера карт на си++ каком, имхо, можно пережить. Если ситуацию вот именно комплексно рассматривать, с разных сторон.

> Советские доктора наук при переводе книги Гриса не наломали дров, а,
> наоборот. Т.е. с этим частным случаем - всё Ок -ей.

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

> Боинг я здесь где-то рядом за 2 датчика с ручным (!) выбором исправного критиковал

У боинга есть свои скелеты в шкафу, свое легаси (например, нельзя резко ломать ожидания пилотов) и свои бестолковости. Линейка 737 мягко говоря не молодая. А авиаторы точно не фронтир инноваций. И никто не говорил что у них все идеально. Но тут вроде разговор о том как двигаться вперед в будущем, какие проблемы, чем грозит, что можно сделать и проч. Заметьте, это через лет так 30, или сколько там, после появления линуха.

Ответить | Правка | Наверх | Cообщить модератору

227. "Обсуждение проблем применения Linux в авионике"  +/
Сообщение от U202204161753 (?), 03-Июл-23, 16:16 
> Про надежный код на Аде - смешно. Про взрыв ракеты Ариан-5 слышали?

Вот только Ada там ни при чём.
Т.е. код, конечно же, на ней, а вот причина организационная.

Материалы - общедоступны

Ответить | Правка | К родителю #190 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру