Автоматика как фактор безопасности в современных транспортных средствах
Sergey-nn
циник в розовых очках
Эммм...
А какое отношение функционирование самолета имеет к архитектуре ПО?
Почему военной?
По современным веяниям программист вообще не должен знать для какого объекта его ПО.
Sergey-nn
циник в розовых очках
VirPil
Старожил
А что не так? Речь была о том, что те, кто отвечают и за "описание структуры программной системы", и за кодирование не определяют, как работает МКАС.
Sergey-nn
циник в розовых очках
Читаем определение еще раз и внимательно:
Таки кто ЗАКАЗЧИК то?
Боинг?
Соответственно архитектуру ПО выбирает НЕ он. Выбирает та самая "програмистская контора" которая получила заказ.
И к логике управления стабилизатором АРХИТЕКТУРА ПО отношения не имеет вовсе.
Kit.
Старожил
Вы уже забыли, о чём спорите?
VirPil
Старожил
Вы думаете, что Боинг это не у себя разрабатывает, а отдает на аутсорсинг индийцам?
Так и я том же. К программистам (в широком смысле слова) по МКАСУ претензий быть не может.
Sergey-nn
циник в розовых очках
В данном случае это совершенно НЕ важно.
Термин Вы использовали совершенно не понимая его сути.
Kwispel
Летучий галландец
Virus_KNet
2D Pilot
Ммм... Насколько я знаю, не совсем так. Отраслевой комитет по стандтизации задает некоторые условия. Ну, начиная от требований к экологии, безопасности и прочего, и заканчивая обязательными протоколами диагностики. А вот как, на чём, и каких производителей использовать для написания кода и аппаратной реализации - комитету практически до лампочки. Никто уже практически не разрабатывает свое. Европейцы лепят Bosch, япы - Denso ( ну грубо говоря и немного утрируя). Я согласен с тем, что в авиастроении та же кухня. Поэтому тут скорее всего производитель этой системы накосячил. Хз кто это. Tales там, или ещё кто-то. Странно, что боинг молчит и никого не сдаёт.
Лично я уверен на сто процентов. Архитектура и общие требования боинг (ну или поставщик этого оборудования для боинга), потом проектные образцы, испытания (причём не факт, что на боинге), потом серия. Поэтому, кмк, тут многоуровневый аутсорс. И соответственно "кодеры" вообще могли не знать, что они собственно пишут, и для чего. В ТЗ
- "на входе вот такие сигналы, вот в таком диапазоне, вот в таких попугаях. Зависимость выходного сигнала должна быть по такому закону"
-"так тут два сигнала на входе?"
- "Тебе два надо?"
-"Нет."
-"Ну так бери любой..."
А я бы всё-таки расстрелял...) на всякий случай) Потому что когда сказали "любой ", то нормальный погромист как минимум задумается - а зачем из там два? Тот ли я беру? Нужно ли их сравнивать, считать ошибку, аппроксимировать..." А тут тупо вбили
"#1" и ушли на перекур. И потом этот баг (или фича) проскочила каким-то образом все тесты. Все, кроме Индонезийских бета-тестеров...
Пассажиры..."А судьи кто?..."
Последнее редактирование:
Drusha
From LED with love
А вы уверены, что программист должен это знать?
Kit.
Старожил
AUTOSAR - это, по-вашему, что?
Откуда "два"? По жизни там охренилиард сигналов. В ТЗ указан один из них, вполне возможно, что и синтетический.
VirPil
Старожил
А кого им сдавать, самих себя? Кто сам МКАС придумал и разработал его алгоритм?
Не говорят "любой". Есть четкое ТЗ, берем сигнал Х, в зависимости от его значения делаем так.
Sergey-nn
циник в розовых очках
есть ли?
Есть человек который на начальном этапе разработки может точно сказать все параметры системы управления лайнером?
Сильно сомневаюсь
Весьма вероятно что ТЗ писал человек "старой закваски", т.е. привыкший к плотному взаимодействию всех участников разработки. Возможно даже сделал пометку "уточнить при отладке". А в реальности ПО отдали на аутсорс (или в отдел программистов работающих подобно аутсорсу).
Те поставили
и у них все заработало.
Т.к. ни кто реально не прописал однозначного ТЗ (в надежде на дальнейшую отладку) ровно так же это не появилось в методике испытаний
Зато появился шустрый менагер который организовал продажу индикации рассогласования датчиков как "люксовую фичу". Он же не технарь - он продаван. Вот он и продает....
Таким образом если программистов рассматривать как "абстрактных кодеров" - претензий никаких.
Вот только по уму они должны быть участниками разработки, и тогда программист позвонил БЫ в соседний отдел и обговорили что и как.
Последнее редактирование:
Kit.
Старожил
В общем, как обычно.
"Старая закваска" - это Waterfall, там как раз есть такой человек из вашего первого предложения и нет "плотного взаимодействия всех участников".
VirPil
Старожил
Ну какая "старая закваска"? Это авиация, стандарты разработки четко описывают, кто и что делают. На каждый чих есть спецификации, и по ним работают. Конечно, и рядовой кодер может высказать свое мнение, но сказать "я сделаю все по другому" он не может.
constructor
Старожил
Умов-то много. По чьему-то уму должен быть, а по чьему-то уму не должен. Когда человека нанимают на работу, ему объясняют, что и как. Вот как объяснили, так он и работает.
Virus_KNet
2D Pilot
О. Я даже не в курсе был)) Спасибо. Судя по всему это попытка европейцев "пересадить всех на USB TYPE-C, только в автомобильной индустрии) Выглядит вполне логично, но во первых, судя по их сайту и данным педивикии - они к работе реальной приступили только в 20-ом году. И даже несмотря на то, что очень сильных производителей электронных устройств в европе хватает, а точнее именно по этому - я думаю вряд-ли все сразу перейдут на эту архитектуру. Поскольку портировать разработки собственного отдела R&D, который живёт уже где-то в 2028 году будет невозможно. (У меня есть несколько исходников компании BMW, системы мультимедиа ID8, а также SecureCoding 2.0, датированные 2017 годом, а впервые вышло это в серию в 2021. И то, только в топовых моделях, и то частично. И в 2024 ещё далеко не на всех есть) Или это попытки Американцев прибрать к рукам инженерные наработки, которыми Bosch и иже с ним не хотят делиться... Но, это моё IMHO. Но за информацию спасибо. Надо почитать, будет понятнее, куда все это катится.
ИМХО, вряд-ли. Если все это по airinc общается, то по запросу у ADIRU (или как он там у боинга называется) за конкретным ID мы получаем конкретное значение того самого датчика, который нам нужен. Правый один айди, левый другой. Поэтому там конечно охринилиард, но не сам по себе. А по запросам между модулей. А поскольку MCAS это надстройка (лень листать тему, какой именно из блоков так проапгрейдили), то конкретное тз, с конкретным перечнем сигналов команда разрабов включая архитектора получила. И просто ради интереса, хотелось бы всё таки когда нибудь узнать, кто оказался таким оленем.
А вот хз, честно говоря. Самому интересно. Придумал наверное всё же боинг. А вот кто им делает систему управления я не помню. Где-то в жтой ветке вроде было, мкас - програминая часть какого модуля? Поиском что-то не нахожу. Вот чей модуль, тот и разработчик. Тот собственно и в ответе перед боингом, за его (боинга) попадалово со стоявшими MAX'ами.
(за катастрофу в ответе пилоты на 99%, ИМХО.)
ВОТ ТАК И СДЕЛАЛИ! В том-то и прикол.) А по факту там 2 сигнала. X первый флюгер, Y - второй...
Virus_KNet
2D Pilot
Вот прям реально. Мне кажется, это попадание в десятку. Именно так и было. Может чуток с нюансами, но именно по этому сценарию. Только тот, кто делал эту надстройку не знал, что есть ещё и Y.
И что X может быть не валидным. И возможно, даже не знал, что это вообще нужно для самолёта.
Virus_KNet
2D Pilot
Не уверен. Я не знаю, знал ли погромист о том, что вообще означают эти данные. Дали ли ему в ТЗ параметры именно с углами атаки, или просто ID блока, и синтаксис запроса, с которого нужно получить какие-то данные в попугаях, и которые по определённому в ТЗ закону, и при определённых в ТЗ условиях нужно обработать, и выдать определённую в ТЗ команду на определенный в ТЗ адрес исполнительного устройства. И знал ли он, что их там два? Если знал - то мой ответ Вам - да. Должен. Если у меня есть два значения, которые практически идентичны, но в них бывает какая-то разбежка - я буду выяснять, что за фигня, и что из этих двух (а порой и четырех) мне нужно, и что будет, если я использую не тот.