ШБЖ
Старожил
Однако же она (эта организация) пишет не только рекомендуемую практику, но и стандарты. Другой вопрос: как пишет?
Автоматика как фактор безопасности в современных транспортных средствах
Однако же она (эта организация) пишет не только рекомендуемую практику, но и стандарты. Другой вопрос: как пишет?
denokan
Старожил
ИКАО - это стандарты и рекомендации, которые договаривающиеся стороны согласились использовать, а если есть отличия - то сообщать о них другим сторонам в аэронавигационных публикациях. А как пишет? Появляется инициатива, создается рабочая группа, далее они работают, результат представляется на совещании ИКАО. Документ дорабатывается, согласуется и принимается.
Как-то так.
ШБЖ
Старожил
Я не о процедуре разработки. Я - о ее результатах. Если обновленный (и поданый с помпой) документ (Руководство, дополняющее стандарт) содержит отмененные 10 лет назад нормы, если он иллюстрирован кашей из устаревших и обновленных стандартных(!!!) символов, если в нем, несмотря на призывы к единообразию применения так и невозможно найти ответ: "как?"...
И, поверьте, их больше, чем один.
Yuha
Мамонт
Многие вещи должны (!) выявляться задолго до испытаний. Есть такая магическая аббревиатура АВПКО (FMECA)...
xDream
Новичок
Все больше кажется, что пилот нужен в первую очередь для того, чтобы было на кого повесить всех собак, в случае чего.
Да, автоматику невозможно обучить правильно реагировать на все мыслимые и не мыслимые нештатные ситуации.
Но, во-первых, автоматика (при условии ее исправности и отсутствии шапкозакидательского отношения в проектировании, как в случае с MCAS) никогда не проспит и не ошибётся в ситуации ей известной.
А во-вторых, что сделает человек в незнакомой ему ситуации тоже не известно, вполне может впасть в ступор или допустить ошибку. Это постфактум на диване можно рассуждать, что теоретически из сложившейся ситуации выход был, а значит виноват пилот.
А если на взлетной полосе гуманойд, а в автоматике при этом заложено взлетать, то виноваты службы, которые допустили появление гуманойда на полосе. Все гораздо проще становится.
Да, автоматику невозможно обучить правильно реагировать на все мыслимые и не мыслимые нештатные ситуации.
Но, во-первых, автоматика (при условии ее исправности и отсутствии шапкозакидательского отношения в проектировании, как в случае с MCAS) никогда не проспит и не ошибётся в ситуации ей известной.
А во-вторых, что сделает человек в незнакомой ему ситуации тоже не известно, вполне может впасть в ступор или допустить ошибку. Это постфактум на диване можно рассуждать, что теоретически из сложившейся ситуации выход был, а значит виноват пилот.
А если на взлетной полосе гуманойд, а в автоматике при этом заложено взлетать, то виноваты службы, которые допустили появление гуманойда на полосе. Все гораздо проще становится.
ШБЖ
Старожил
Осмелюсь сравнить менеджмент с пресловутой "пирамидой". (Подозреваю, что где-то он организован по уму, но речь не о таком.)
Нетрудно заметить, что жизнь современного человека настойчиво пытаются "оцифровать". Будь то стандартные процедуры на рабочих местах, будь то провека результатов освоения нового, будь то требования к найму рабсилы (если вдуматься, рабовладельческий строй фактически не отменен, он просто очень видоизменился), и т.д. На фоне всего этого главным становится соответствие каждого кем-то определенным уровням, количествам, способностям, что на самом деле в итоге сводится к упрощению управления: "да-нет".
Другая задача управления - эффективность. Которая, опять же - в итоге сводится к получению прибыли.
А прибыль - она всяко есть разница между вложенными средствами и полученными. И ее размер можно увеличить как повышая получаемые доходы, так и уменьшая затраты на вложение. Это - один из подводных камней коммерческой деятельности, которая нынче особенно регулируется "стандартными процедурами". Например, тендерами при закупках. Где в отличие от аукционов побеждает тот, кто предложит меньшую цену. Далее имеем конфликт между финансистами и внутренними потребителями закупок (сырья, софта, услуг и т.д.). Если в параметры решений о победителе заложена только цена, то ждать высокой эффективности от закупок нельзя.
Это - схема. Тупое ее выполнение на уровне прописанной процедуры, введенной в ранг правил - это та проблема, с которой сталкивается технический подход к решению задач беспилотной ГА.
А отсюда, из финансирования, растут уши (или ноги) абстрактного заменителя пилота в летательном аппарате.
Его сложность приводит к его же дороговизне. Как в исследовательской части, так и в организационной/практической, если первая часть получит некий приемлемый результат. А потом, как всегда:
В итоге все сведется к выработке "приемлемого уровня", на концепции которого и построена безопасность полетов. Как общество (в виде его представителей, взявших на себя отвественность за его определение) решит, так оно и будет доводиться "оцифрованным" пассажирам. Каким у тех будет внутренний конфликт или согласие между теорией вероятности и оценкой уровня надежности - сейчас сказать трудно. Люди доверчивы к заявлениям специалистов, а таковых по всем вопросам существования нынче уже переизбыток: поди разберись, где "британские ученые из калифорнийского университета", где просто шарлатаны, зарабатывающие в сети "лайки"...
Когда все они созреют человека морально для полетов "на микросхемах" - будет он летать, надеясь на "приемлемый уровень", нет, так вопрос отложится еще на некоторое неопределенное время. ИМХО.
ШБЖ
Старожил
Одна из проблем состоит ИМХО в том, что исторически человек осваивал летание, начиная с простых условий, которые он учился оценивать, постепенно усложняя свои задачи как по скорости, высоте, так и по метеоусловиям. И датчиком по-первости была лишь "пятая точка", откуда и шли сигналы на управление. Аэродинамика поначалу волновала только тех пилотов, кто сами свои самолеты конструировал.
Сейчас бы тоже начать (если уж так приспичило человеку разумному) с определенных ограничений условий полета, где мыслимые ситуации более конкретны. Но... А вдруг конкурент обгонит?
Yuha
Мамонт
Одни говорят - стакан наполовину полон, другие - наполовину пуст. Здесь вы, похоже, предпочли второй вариант... Лично я по-прежнему полагаю, что при любом уровне автоматизации пилот нужен для того, чтобы дать пассажирам шанс. В случае чего...
P.S.:
В авиации, случись что, ищут не виноватых, а причины произошедшего и сопуствующие произошедшему факторы, включая человеческий. Виноватых ищут профессиональные прокуроры...
brother_737
Тайм-аут
xDream
Новичок
Такое впечатление у меня сложилось от прочтения этой и соседних веток..
Согласен, он это, увы, вопрос экономии и прочей оптимизации.
Всю дорогу ведь идет война за уменьшение численности экипажа с целью удешевления перелетов.
Есть и другие факторы: может быть у пилота поедет крыша и он направит исправный самолет в землю, ведь бывало такое.
Может быть пилот уже давно забыл как управлять самолетом, т.к. сидел там только для спокойствия пассажиров, а обязательные тренировки ручных полетов кто-то уже потихоньку "оптимизировал".
Вообще, лично я за полностью автоматические самолеты, понятно что не сегодня и не пощелчку. И считаю что это будет шагом к светолому будущему, а не к пустому стакану.
Yuha
Мамонт
Что мне мешает с таким же оптимизмом смотреть в светлое будущее, так это тот простой факт, что ученые до сих пор так и не смогли сотворить не то чтобы искусственного человека, а даже такую тварь божью, как простейшая амеба ))) И никакого видимого прогресса на этом пути не наблюдается. Даже священное писание не очень приветствует стремление человека обыкновенного стать Всевышним. А наоборот - всячески порицает это, аки грех... )))
ШБЖ
Старожил
Yuha
Мамонт
Kit.,
Попробуйте взглянуть на то, что Вы делаете (автовождение) через призму вот этого документа:
http://kaf401.rloc.ru/TRPO/KT-178B.pdf
В авиации софт делают так. К сожаление более свежей версии Do-178C у меня под рукой нет...
Попробуйте взглянуть на то, что Вы делаете (автовождение) через призму вот этого документа:
http://kaf401.rloc.ru/TRPO/KT-178B.pdf
В авиации софт делают так. К сожаление более свежей версии Do-178C у меня под рукой нет...
incoming1
Новичок
Невозможно читать в таком корявом переводе.
Yuha
Мамонт
Спасибо за ссылку! Жаль, что там Do-178C нет...
incoming1
Новичок
Никогда не видел это документа. Только .pdf со отличиями Б и Ц. Например: https://www.adacore.com/uploads/books/pdf/DO178C-ED12C-Changes_and_Improvements-Sep2012.pdf
На ютубе есть пара видео с презентациями на тему Ц.
Kit.
Старожил
Или же потому, что Боинг просто не ожидает наличия разумной разницы в поведении пилота с 200 пассажирами за спиной между ситуациями "собака" и "карапуз"?
1. Заведомо катастрофические ситуации в автомобилестроении не нормируются. Опасные для жизни - 1е-7 - 1е-8 в час.
2. Вы там ниже ссылку на документ приводили - так вот примерно так же. По конкретно верификации алгоритмов автономного вождения требований от регуляторов пока нет, но BMW для себя предполагает 5 миллионов километров реальных дорог (с отработкой 2 миллионов различных сценариев) и 250 миллионов километров симулятора.
Я "проецирую порядок", предполагающий такую сложность системы, при которой не стоит рассчитывать на то, что средний программист в одиночку сможет предусмотреть все отказные состояния. Поэтому см. в т.ч. 2.3.1 вашего документа.
Не исключаю, что в атомной энергетике системы настолько проще, что это не является проблемой - но сомневаюсь.
Предположим, ваш отдел получает задание: добавить компонент MCAS в код уже существующего софта для FCC. Кого конкретно из программистов вашего отдела вы бы назвали "разработчиком софта" из цитаты выше?
Little Squirrel
Новичок
Извините что влезаю. но для систем ASIL D(он же SIL3/Level B) 10E9. Раньше(4-5 лет назад) трактовали как 10Е9 километров, теперь как operational hours. И это не до фатального исхода, именно до сбоя в системе. Методов же - набор, включая анализ кода, SIL, HIL, детерминистические тесты, накат километров. И классический набор Functional Safety анализов и валидаций.
Насчет того, что может и должен видеть програмист в такой системе. Я не знаком с процессами Боинга, но немножко знаю как подобные вещи делаются в Ханивеле и других safety related отраслях. Ситуация когда инжинер получает свой маленький модуль с ТЗ на него без общей картины. В данном случае на тот же MCAS просто будет стоять описание входного сигнала, что-то типа "очищеный АоА" без особого описания откуда и как этот сигнал берется. По идее процессов разработки на уровне SW инжинера ТЗ уже должно быть корректным и непротиворечивым, а все маленькие модули - достаточно изолированными друг от друга. Чтоб понять откуда данные берутся на самом деле часто нужно приложить немалые усилия, на которые в условиях конвейра может просто не быть времени. По рассказам коллег, пришедших из Ханивела, там за попытки выяснить лишнего больно щелкали по носу. Чтоб исполнитель не знал и не заморачивался делает ли он код для военной или цивильной системы.
Yuha
Мамонт
Вот отсюда и непонимание. Для справки:
Катастрофическая ситуация (КС) - это такое состояние, при котором предотвратить гибель людей практически невозможно. В автомобильном транспорте таких ситуаций не бывает? Теперь понятно, чего Вы не понимаете, проецируя свой опыт на авиацию...
А где я утверждал нечто подобное?
Вы и здесь проецируете свой опыт на другую отрасль. В авиации всегда есть системщики (или - интеграторы), отвечающие за всю систему вместе с железом и софтом. От них исходят требования к системе, аллокированные на софт. Они решают, какая часть требований к системе будет реализована в железе, а какая - в софте. Они снабжают разработчика софта всей необходимой информацией о системе и используемом в ней железе. Ну а под раздаботчиком софта я имею в виду профильное подразделение организации, разрабатывающей систему.
Yuha
Мамонт
Верно. Исполнитель конкретного рабочего задания может и не знать, что стоит за пределами этого задания. Однако сей факт не означает, что в Ханивел нет подразделений и групп, ведущих разработку на уровне системы (подсистемы) и хорошо понимающих задачу в комплексе. В авиации и ракетно-космической технике разработчики алгоритмов и программисты - это разные специалисты. И сделано так не потому, что одни - умеют программировать, а другие - нет, а исключительно для того, чтобы всегда можно было бы разобраться, где ошибка - в алгоритме или в коде...