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