Комментарии 45
По состоянию на 2020 год ПО одной из моделей Boeing обновляли вручную через каждые 28 дней, используя 3,5” дискеты.
Это давно известный факт, обычный пример легаси, так делали с начала 90х по середину нулевых
в новых самолетаъ обновляют софт (на самом деле БД навигации) более адекватным способом
вообще на тему
мне оч нравится этот ЖЖ про описание всяких нутрей
прям максимально подробно про дискетки
Дело не в том, что его обновляли каким то там способом при помощи древних флопиков, дело в том что его обновляли слишком часто для "зрелой" модели пассажирского авиалайнера, находящегося в коммерческой эксплуатации. Это практически прямым текстом свидетельствует о том, что пытались заткнуть какие-то баги и делали это впопыхах как-нибудь, без качественного тестирования и с непонятными результатами.
Если почитать ссылки которые я привел, там написано что "БД навигационной информации обновляется раз в 28 дней, дискетками" ...и, цитирую еще раз "ПО одной из моделей Boeing обновляли вручную через каждые 28 дней, используя 3,5” дискеты"
тут легко напрашивается вывод о том что речь именно об обновлении навигационных карт, а не ПО, это явный косяк журналиста или кто там статью писал
На любом самолёте раз в месяц обновляют AIRAC, чаще всего с 3.5" дискеты.
Интересно, что известно о тех двоих инженерах Боинг, которые «устранены» / «умерли при загадочных обстоятельствах» ?
> Предположительно баг запускало пересечение определенных координат GPS.
Как могут пересекаться координаты GPS? Самолёт оказывается одновременно в двух точках? Может, ещё и сама GPS виновата?
Подозреваю, в оригинале что-то другое сказано.
Софт для Boeing-737 Max писался аутсорсерами из двух индийских компаний, зарабатывающими $9 в час.
А если бы они зарабатывали $90 или $900 в час, то сразу бы к ним доверия было на порядки больше?
Как могут пересекаться координаты GPS? Самолёт оказывается одновременно в двух точках?
не помню откуда и применительно ли к боингу, но в памяти всплывает баг когда разработчики не учли что координаты lat/lon в определенном месте на земном шаре становятся отрицательными, а разработчики их сделали строго неотрицательными..соответсвенно при их пересечении у навигации крыша уезжала наглухо
p.s. помоему это у военных самолетов была какаято история
А если бы они зарабатывали $90 или $900 в час, то сразу бы к ним доверия было на порядки больше?
Ну это хотябы миддлы-сеньоры были...насколько эта градация к большинству оутсорсеров индусов применима
Какая разница, кто они были и сколько зарабатывали? Качество софта не напрямую связано с ЗП программистов. Они могут брать хоть $9000 в час, но это не гарантирует отсутствие багов.
Вообще говоря - связанно. Большие деньги просто так не платят и хорошенько так спрашивают за результат. Ну если не совсем придурки в начальстве. Т.е. понятно что есть некий оптимум выше которого - пойдут зазнавшиеся "звёзды".
Но в общем и целом за низкую цену код будет хуже чем за более высокую (опять-таки если не щёлкать клювом) - это по личному опыту закупок разработок.
Корреляция есть, но не такая, чтобы называть основной причиной и «напрямую связанной». Качество - это, в первую очередь, процессы бизнеса, которые ориентированы на качество.
Приемочные испытания, aka qa, здесь основное.
Качество непосредственно кода - это про стоимость его поддержки и модернизации.
Работал одно время на Automotive проекте. Строгие процессы ASPICE. Документация и тесты на каждый чих. Нормальный код в тех сервисах, развитием которых занималась наша команда. А потом как-то пришлось додебажиться до низкоуровневого кода, которым занималась команда из Индии.
switch по командам и логика обработки каждой написана прямо там в свиче, без вынесения в функции, без всяких примудростей. Итого функция больше 1000 строк кода и выглядела как "тут нагажено".
И никого ж ничего не смущало, ни разработчиков, ни заказчика
Зато это гарантирует рыночную борьбу за 9000 в час, потому что мало кто готов столько заплатить. Банальная кривая спроса к предложению выровняет качество к цене. Выравнивание будет не идеальным и с прострелами в статистических данных, но если сравнивать шансы на высокое качество от средне рыночной цены и по нижнему краю - шанс на качество по нижнему краю будет пропорционально ниже. Можно возразить и привести примеры какого-нибудь не эластичного спроса, а также распилы и всякие схемы, только вот для 9000 баксов в час об этом можно было бы подумать, а в случае 9 - это просто выбрали самых дешевых, вероятно KPI был на процент экономии, без других пунктов.
Качество софта не напрямую связано с ЗП программистов.
Софт для Boeing-737 Max писался аутсорсерами из двух индийских компаний, зарабатывающими $9 в час
по слухам HCL, и Cyient работали с Boeing, действительно зарплата в Индии порядка $9 в час, но к примеру HCL это 30К+ людей только вне Индии, среди клиентов в US кроме Boeing - Autodesk, Merck, Verizon, типа все кому не лень с ними работают, вполне возможно Boeing просто стрелочника ищут
Так и я про то, что низкая ЗП в Индии не обязательно означает низкое качество кода. И я не очень верю, что их код без какого-либо ревью брался сразу в продакшн.
И я не очень верю, что их код без какого-либо ревью брался сразу в продакшн.
помнится у мена на одном проекте целую серию митингов организовали на тему "почему мы убрали ревью архитектора проекта и сократили количество ревьюверов с 3х до 1 и вообще пусть люди сразу пишут код в прод, а то TTM падает"
так что я бы даже не удивился что там и такое есть
Ряд, что работаете в такой же серьёзной корпорации :)
парадоксально, но эта компания (крупный единорог из США) пока самая продвинутая в моей карьере и по процессам и по подходу к разработке, я до сих пор печалюсь что мне пришлось её покинуть. (а их глюки в процессах...это отдельная история, из-за любым многими бирюзового подхода)
а вот компании уровня Боинга, обычно рассадники какогото адского беспредела в этом плане. вот относительно недавно у меня был проект с крупным полугосударственным производством, мы им отдавали вопросы с требованиями к ПО...так они гуглили каждое второе слово из запросов потому что не в курсе про что мы вообще спрашиваем...докер какойто, кубер...они впервые такое слышат...при этом у них типа крупный ИТ отдел...и девайсы делают очень ответственные
они блин реально у меня спрашивали расшифровку CI/CD
Не всегда разработка крутых девайсов связана со всеми этими терминами. Либо люди всё это используют, но не называют всякими мудрёными словами, а просто работают. В конце концов, компании бывают и небольшими, но успешно реализующими все производственные процессы.
Последний раз когда я был в компании без мудреных терминов, деплой в прод (очень серьёзный онлайн) выглядел как "отправляем jar файл Иванычу в отдел эксплуатации, он выложит"...а иваныч подкладывал руками через ftp файлик в прод и через консоль писал
/etc/init.d/tomcat restart
и так делал для каждого из десятка присланных файликов... уже более 10 лет... потом тыкал f5 в окошке мониторинга томката..и если сервис не появлялся, возвращал старый файлик и писал обратное письмо что не завелось...
вспоминая те времена, прям дух захватывает какие крутые у нас релизы были...;)
есть очень большая вероятность что ваша жена или девушка, если они ходят по всяким женским бутикам в крупных ТРЦ, да даже вы сами если кроссовки некоторых известных брендов покупали в фирменных магазинах, натыкались на глюки бонусных систем...вот это оно самое было... (nda уже не действует, но не буду называть наших клиентов и компанию, их у нас было много и они очень известные)
ИМХО, Иваныч в этой цепочке мог выступать еще одним проверяющим звеном. Не знаю, конечно, так ли это было, но он мог, например, заодно посмотреть, тот ли ему файл вообще дали. А тупой скрипт может просто скопировать файл нулевого размера поверх предыдущего хорошего файла.
потом тыкал f5 в окошке мониторинга томката..и если сервис не появлялся, возвращал старый файлик и писал обратное письмо что не завелось...
Ну вот, тоже дополнительный контроль :-)
Про ТРЦ и бонусы - такое сплошь и рядом бывает и в весьма больших и крутых торговых сетях. И попробуй им докажи, что ты не верблюд. "Вы для нас очень важный клиент, мы уже работаем над вашим вопросом" - вот это всё.
работал с разными компаниями из Bangalore достаточно, типа два варианта - берете что-нибудь из готового, и они могут сделать porting или доработать до требуемого уровня, сами делаете интеграцию, tele общение в основном, или они могут прислать людей с которыми обсуждаете ТЗ, размещаете где-нибудь поблизости, работают как контрактники, в обоих случаях код ревью и пр. сколько угодно, уровень людей сильно зависит от приоритета клиента, если клиент важный, или личные связи налажены уровень намного выше среднего, примерно так, остальное от Вас зависит, личным примером лучше всего, но если вожжи брошены, работают как все :)
О, вы из Боинга!
Это заставляет задуматься о качестве программных продуктов перечисленных вами компаний...
Насколько я помню у военных была фигня с высотой. Поэтому при полёте на Мёртвым морем самолёт слегка переглючило. С координатами обычно так не путаются.
Как могут пересекаться координаты GPS? Самолёт оказывается одновременно в двух точках? Может, ещё и сама GPS виновата?
Имелось ввиду когда самолёт пересекает определённые широты/долготы в процессе полёта. Хрен поймёшь что там происходит - вроде аэродромов точно на экваторе и линии смены дат особо нет. Может в районе Гринвича и 0-го меридиана какое-нибудь деление на ноль срабатывало?
Вот и хочется понять, что там имелось ввиду, а не просто осознать кривость перевода.
Эээ, я конечно извиняюсь, но у lat и lon ровно половина значений является отрицательной, и ни одному вменяемому разработчику не придёт в голову делать их uint.
Скорее всего, имеется в виду, что в некоторых точках Земли высота рельефа по MSL может быть отрицательной. Но и это прекрасно известно всем разработчикам авионики. Как и то, что можно накрутить отрицательную высоту на высотомере с помощью изменения давления.
Эээ, я конечно извиняюсь, но у lat и lon ровно половина значений является отрицательной
Э-э-э, я извиняюсь, но широты и долготы - строго положительны в географии и "аналоговой" навигации. Поэтому при "водопадном" проектировании - вам uint уже сверху опытный дедушка-навигатор спустит в согласованном в десяти инстанциях техзадании. И никто ради вашего удобства пересогласовывать не будет.
Э-э-э, я извиняюсь, но широты и долготы - строго положительны в географии и "аналоговой" навигации.
Только в современном самолете не аналоговая навигация, а цифровая
и цитирую вики
Отрицательные знаки координат представляются либо знаком «−», либо буквами:
«S» или «ю. ш.» — южная широта,
«W» или «з. д.» — западная долгота.
Логично что в цифровом виде довольно напряжно вместо минуса использовать S и W
еще как пример
Я уж не знаю как там у вас в географии, но у нас в реальной авионике, FFS тренажерах и симуляторах lat и lon меряются от -90 до 90 и от -180 до 180. И реальная база данных AIRAC тоже работает в таких координатах. И весь онлайн софт для реальных полётов тоже так работает.
Там больше приколов с линией перемены дат. Предположим, на твоем самолете обновили airac до 2407, он начинает действовать с 2024-07-11T00:00Z, у тебя рейс из Токио в США, запланированный как раз на 11 июля. В районе 180 меридиана твои оба FMC решают сменить дату на 10 июля, а заодно использовать предыдущую версию airac 2406. У тебя пропадают указанные в legs фиксы, vor/dme, появляются discontinuities, в разделе prog какие-то заоблачные числа по поводу оставшегося топлива на точке прибытия, landing weight превышает все мыслимые нормы.
В общем тестировать надо не только плюс/минус в Lat/Lon/MSL, но и такие вещи, как внезапный переход из +180 в -180 (а он может еще быть неоднократным в процессе полета вдоль линии перемены дат)
Вопрос от пилотов: а это прямо реальный кейс? На каком типе оно случилось?
Гипотетический. Я про то, что надо тестировать не только в районе нуля, но и в граничных случаях. Не даром про этот кейс упоминается в статьях вида "вы работаете с временем неправильно"
Ааа это чисто гипотетически. Ну так зато этот коммент вызвал обсуждение в нашем пилотском чате. Оказывается разные FMS-ки работают с этим по-разному. Но ни на одном из упоминаемых типов (а это 737, 320 и прочие самые ходовые типы) цикл во время полёта не меняется автоматически, только вручную. Заодно выяснили как оно там леталось с просроченной БД в 22 году.
Если человек зарабатывает 9$ в час, вероятно, ему не хватает навыков зарабатывать больше.
Если человек зарабатывает 90$ в час, вероятно, ему хватает навыков, чтоб платили не меньше.
Так что, да, доверия было бы больше.
В реальности главная проблема была в том, что модель 737 исчерпала себя и не выдерживала конкуренции с "А". Вариантов было два:
делать принципиально новую и выйти на рынок лет через 10
попытаться в очередной раз оживить "почти мертвую" лошадь
Способ два не требовал много денег, не требовал полной пересертификации летных экипажей и позволял какое-то время быть на рынке. Проблема была в физике, но решили, что это не существенно и можно обойти путем "активной" помощи пилотам.
В итоге, ИТ решением попытались решить проблему, которые выходила за рамки ИТ области. Да, теоретически, более качественные "ИТ-заплатки" могли "работать" лучше, но физика все равно была против.
--------------
Ну и надо понимать, что софт для самолета - в любом случае представляет собой огромное легаси и просто "взять и переписать" не выйдет
Сумма в масштабах боинга звучит как несущественная, честно говоря.
Боинга с начала 2000-х больше нет. В руководстве с тех пор осталось только менеджерьё из McDonnell-Douglas, которое пришло туда после покупки Боингом их разорившейся компании, а в итоге повыгоняло всех боинговцев. Полагаю, компанию уже не спасти, эти ребята разорили Дуглас и уверенно ведут по той же тропинке Боинг. Тут всю эту клоунскую верхушку менять надо, но на это кишка тонка, у них и в правительстве связи, и особо недовольные их деятельностью внезапно умирают в несвойственном для этого возрасте. Такие дела.
Boeing заплатит $243 миллиона за мошенничество