Автоматика как фактор безопасности в современных транспортных средствах

[WWs]

У подготовленных не вызывает.

Вызывает. Человеческая природа такова. Пилоты имеют преимущество в контроле за здоровьем и помереть от стресса не имеют права. И то случается...

 

[WWs]

Вот для этого и предназначена тренировка и доведение до автоматизма.

Оба Боинга мах упали потому что экипажи не распознали "банальную" ситуацию ухода стабилизатора ибо она была замаскирована поведением системы. Ни чем им тренировка не помогла.

 

[del_fin-1]

Для Арийца. Почитайте про Як-130 что ли. Все то же самое - крылья, рули со стабилизаторами, закрылками-элеронами, колесами-моторами... Только вот самолёты разные...

 

[Black Semargl]

Код отработал как и должен был. Выдали проектировщикам ТЗ брать данные с одного датчики и не проверять - код точно так и отработал.

К каждому из двух компьютеров подключён только один датчик. Так что другого ТЗ и быть не могло.
Но скорей постановщики задачи даже не задумывались о надёжности входного параметра. Это же задача железячников, а не программистов.

 

[Ariec 71]

Для Арийца. Почитайте про Як-130 что ли. Все то же самое - крылья, рули со стабилизаторами, закрылками-элеронами, колесами-моторами... Только вот самолёты разные...

К чему посыл. Как то оформите свою мысль. А што не МиГ 31 например.

 

[whitestyle]

К каждому из двух компьютеров подключён только один датчик. Так что другого ТЗ и быть не могло.
Но скорей постановщики задачи даже не задумывались о надёжности входного параметра. Это же задача железячников, а не программистов.

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

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

 

[Отто Кац]

Ariec 71, вас конечно понять сложно, перевод нужен
VirPil и eton, ариец вам пытается донести простую мысль - неважно по какой причине, ну может действительно коротнет что, но самоход стабилизатора на пикирование на NG возможен как и на MAХ, с максимально возможной для привода скоростью (оно ж коротнуло, им никто не управляет). При этом возможна и птичка в ПВД. Справятся ли пилоты с NG с такой ситуацией? Никакого MCAS на NG нет, а ситуация возможна...

 

[Ariec 71]

вас конечно понять сложно, перевод нужен

И спел, и станцевал. Ну как ещё то.

 

[WWs]

Справятся ли пилоты с NG с такой ситуацией? Никакого MCAS на NG нет, а ситуация возможна...

Справятся потому что именно этому, непрерывному самоходу стабилизатора, их учат и регулярно тестируют.

 

[VirPil]

К каждому из двух компьютеров подключён только один датчик. Так что другого ТЗ и быть не могло.

Почему? Ведь сигналы IAS/AoA disagree именно сравнением получаются, так что есть модуль/код сравнения. И МКАС доработано програмным путем. Разве тянули еще провода, коммутароры и т.д.?

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

Что не задумывались это точно. Но это задача именно проектировщиков, которые дают ТЗ. А ниже уже решают, каким путем делать. Сейчас все программно делают.

ариец вам пытается донести простую мысль - неважно по какой причине, ну может действительно коротнет что, но самоход стабилизатора на пикирование на NG возможен как и на MAХ, с максимально возможной для привода скоростью

А, тогда да. Но не только на НГ или МАХ, а и вообще везде, где есть такой стабилизатор.

 

[eton]

Ariec 71, вас конечно понять сложно, перевод нужен
VirPil и eton, ариец вам пытается донести простую мысль - неважно по какой причине, ну может действительно коротнет что, но самоход стабилизатора на пикирование на NG возможен как и на MAХ, с максимально возможной для привода скоростью (оно ж коротнуло, им никто не управляет). При этом возможна и птичка в ПВД. Справятся ли пилоты с NG с такой ситуацией? Никакого MCAS на NG нет, а ситуация возможна...

1. Первый экипаж вовремя не распознал runaway. Возможно потому что работа MCAS больше похожа на обычную работу автотрима, чем на типичный runaway с замыканием, возможно потому что были заняты тряской и затяжелением штурвала скоростью и т.д. - т.е. более раздражающими факторами. В тысячно первый раз скажу что runaway нового МКАСного типа не распознал и единственный справившийся экипаж - они даже не смогли описать что именно произошло.
2. Второй экипаж запутал дебильный бюллетень. Может с высоты ваших диванов он восхищает вас своей изяшностью, красотой слога и запутанностью сюжета, но это явно не инструкция для парирования аварийной ситуации которую нужно выполнить в течении пары минут.
3. И 1. и 2. (MCAS и бюллетень) в принципе отсутствовали на NG.
4. Типичный Runaway - опасный отказ и одновременно редкий (это простая мысль кстати очень рекомендую начать носить ее, - опасные отказы должны быть редкими). MCAS не только увеличила вероятность этого отказа на несколько порядков но и спровоцировала сочетание Runaway c Airspeed Unreliable также требующим немедленных действий, но опасным больше тем что отключаются автоматы использующие показания скорости - чтобы свалить самолет на землю по Airspeed Unreliable нужно сначала потерять скорость а затем высоту что требует большего времени, чем незамеченная вовремя перекладка стабилизатора. Денис говорит что действия по Airspeed Unreliable имеют приоритет выполнения перед бюллетенем по MCAS и такие действия гарантировано спасли бы второй экипаж... ну не знаю - посмотрим как будут расставлены эти шаги в инструкции исправленного MAX.
Собственно бюллетень и иное протекание отказа (а также то что MAX и NG внезапно разные самолеты) не дают возможности носителям простых мыслей напрямую адекватно сравнивать реально произошедшую с реальными экипажами ситуацию с отказами MCAS из-за УА, с выдуманной практически невероятной ситуацией когда например мышь замкнула привод стаба на пикирование и одновременно с этим в пвд попала птица и все это на взлете с выдуманными исключительно на основании форумных высказываний экипажами. С таким же успехом можно фантазировать что в этой ситуации сделал бы Салли из одноименного фильма на A320. Тем более не стоит делать из таких фантазий столь далеко идущие "простые" выводы. Так если такие "простые далекоидущие" выводы провести еще чуть дальше и еще чуть-чуть "упростить" то окажется что весь парк остановили на пару лет и Б оказался в Ж всего лишь из-за двух пилотов, а это уже маразм. Если кто до сих пор не заметил - регуляторы уже все сравнили и свои выводы сделали. В общем вся эта простота из разряда "А если киту еще и хобот то кто сильнее - медведь или кабан?".

 

[VirPil]

Денис говорит что действия по Airspeed Unreliable имеют приоритет выполнения перед бюллетенем по MCAS и такие действия гарантировано спасли бы второй экипаж...

Дело даже не в приоритете. Выполни они Airspeed Unreliable, т.е. не убрали бы закрылки, и до МКАС бы вообще дело не дошло.

Второй экипаж запутал дебильный бюллетень.

А что там такого дебильного? Что про необходимость сначала открутить стаб, а потом выключать, иначе будет тяжело написано строчкой ниже как примечание?
Нужно быть гением, чтобы прочитать весь бюллетень и понять его целиком (причем до полета)? Или его читают как в старом номере, где одна читает рецепт, а вторая готовит:

- Всё обвалять
- Обваляла
- Читаю дальше: в муке

 

[eton]

Дело даже не в приоритете. Выполни они Airspeed Unreliable, т.е. не убрали бы закрылки, и до МКАС бы вообще дело не дошло.

А что там такого дебильного? Что про необходимость сначала открутить стаб, а потом выключать, иначе будет тяжело написано строчкой ниже как примечание?
Нужно быть гением, чтобы прочитать весь бюллетень и понять его целиком (причем до полета)? Или его читают как в старом номере, где одна читает рецепт, а вторая готовит:

ну что тут скажешь, простота хуже воровства.

 

[Kit.]

К каждому из двух компьютеров подключён только один датчик.

Это "напрямую". Но FCC обмениваются информацией между собой.

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

Гнать взашей таких "постановщиков".

 

[VirPil]

ну что тут скажешь, простота хуже воровства.

Это обо мне или экипажах?

 

[Virus_KNet]

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

Я имел ввиду как раз создание КАЧЕСТВЕННО других систем. Так как КОЛИЧЕСТВЕННО усложнять систему "кодом и количеством мелкосхем" не имеет особого смысла на мой взгляд. Так или иначе будут проявлятся какие-то криво реализованные алгоритмы типа той же mcas.

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

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

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

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

И надежность эта явно была достигнута не упрощением этих систем.

Согласен. Но, опять же плвторюсь - до определенного момента системы станлвятся надежнее, пока количество элементов не превысит определенные значения. Связи и перекрёстные ссылки в коде, особенно с учётом взаимодействия нескольких систем станут настолько сложными, что ни одна система проверки кода, а тем более не один программись никогда не ответят Вам, как поведёт себя система в некоторых случаях. Если вы далеки от темы разработки электронных систем с нуля (хард-/софтварных), могу рекомендовать статью от разработчика авионики.

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

Блин, мы с Вами разной логикой пользуемся? "архиьектура построения" это конечно очень важно. Но в основном с точки зрения минимизации строк кода, а соответственно вычислиьельных возможностей и памяти, а также возможности реализации количества функций. Надёжность тут скорее как производная. Отнюдь не прямая зависимость.

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

Да ладно))) Простите уж за сарказм, но вы далеки от истины. Особенно, что касается SoC. И что такое допустимый брак, и как появляются старшие и младшие линейки одной системы, я полагаю вы должны знать, раз ведёте подобную дискуссию. Это во-первых, а во вторых никто и никогда (очень сильно надеюсь) не станет реализовывать авионику на SoC, NAND и прочем сверхНЕстабильном дерь... Хм... мусоре.

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

Причем заметте! Это бобинг. Причём 737. Который ниразу не "гаджет с крыльями".
Но даже в этом случае разработчики "косякнули". И даже спустя год так и непонятно кто именно. Те, кто писал ТЗ, или те, кто писал код, или те, кто занимался верификацией и бета-тестингом... "Фирма "Донцов" - хрен найдешь концов..."
И чем более" наворочена" система, тем больше может быть проблем. Как и такого раздолбайского характера, так и таких, которые чуть аирбас не уронили. Насколько я знаю, проблему так и не отловили в алгоритме кстати. Я жк имел ввиду создание систем, близких к ИИ. Если у вас откажет все три IR, и самолет будет под управлением автоматики - он рухнет. Поскольку у аатоматики нету глаз, как минимум. Или соображалки, чтобы использовать к примеру стакан с водой. Я думаю вы понимаете, что я утрирую. Но мысль моя такова - тот кто сидит в кабине - ОБЯЗАН уметь управлять ВС, даже если у него не останется ни одной вспомогательной системы. Он обязан суметь зайти и выполнить посадку. Не нужно лететь на Кубу в директе. Но справится с любым отказом ВСПОМОГАТЕЛЬНЫХ систем пилот обязан.

прикрываясь кстати своей философией "Пилот всегда главный" которая у них почему-то выродилась в "Пилот всегда вывезет", притом что даже выключателя (MCAS, загрузки штурвала и много чего еще) у "главного" пилота нету.

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

Так что даже вопрос как считать пилота "главным"... дискуссионный.

Он конечно дискусилнный. Согласен. Наверное. Аирбас не хочет, чтобы пилот был "главнюком" в кабине. И пока что их системам, которые в разы сложнее боинговских споавляются очень неплохо. Гораздо лучше иных пилотов боинга. Но, мне ка, что проблема тут не в том, что автоматика непогрешима как папа римский, а в том, что пилоты летаьь разучились...
©Всё вышенаписанное является исключительно МНЕНИЕМ.

 

[Virus_KNet]

Я не помню катастроф вызванных именно багами в программе.

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

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

Теоретически - Вы правы. Статистически кстаи тоже. Но, я всё же не согласен.)) Датчик датчику рознь. Как и программа- программе. Какой-то гений же придумал мкас?)

Кроме того, в случае обнаружения ошибки, она будет исправлена раз и на всегда.

Я не готов за находку бага в софте заплатить жинью. А вы?

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

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

 

[whitestyle]

Блин, мы с Вами разной логикой пользуемся? "архиьектура построения" это конечно очень важно. Но в основном с точки зрения минимизации строк кода, а соответственно вычислиьельных возможностей и памяти, а также возможности реализации количества функций. Надёжность тут скорее как производная. Отнюдь не прямая зависимость.

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

и зависимость самая прямая.От решения надежности системы зависит количество «строк кода» и никак наоборот. Тут ещё вопрос, что есть производная.

 

[Отто Кац]

Аирбас не хочет, чтобы пилот был "главнюком" в кабине.

Где это он такое заявил?

The design of the cockpit is built according to 10 high level design requirements:
1. The flight crew is ultimately responsible for the safe operation of the aircraft
2. If required, the flight crew can exercise their full authority by performing intuitive actions, while
aiming at eliminating the risks of overstress or overcontrol
3. Accommodate for a wide range of pilot skill levels and experience acquired on previous aircraft
4. Ensure safety, passenger comfort, and efficiency, in that order of priority
5. Simplify the tasks of the flight crew, by enhancing situation and aircraft status awareness
6. The automation is considered as an additional feature available to the flight crew, who can decide
when to delegate and what level of assistance they need in accordance with the situation
7. The design of the Human Machine Interfaces (HMI) takes into account system features together
with the strengths and weaknesses of the flight crew
8. The state of the art of the human factors considerations are applied in the system design
process, in order to manage the potential errors of the flight crew
9. The overall cockpit design contributes to facilitate and to enhance the flight crew communication
(e.g. tasksharing, teamworking)
10. The use of new technologies and implementation of new functionalities are imposed by:
‐ Significant safety benefits
‐ Obvious operational advantages
‐ A clear response to the needs of the flight crew.

Ваще другое заявлено...

 

[Отто Кац]

а и вообще везде, где есть такой стабилизатор.

Не везде. На Airbus это не так. THS trim wheels тормозятся одним пальцем. Изи. Да и случаев самохода за 30 лет...чет негусто...

что в этой ситуации сделал бы Салли из одноименного фильма на A320

А он оказывается выдуманный? Из фильма...