Их много, и если в кабине нет никакого управления ей, и ее отказ не требует знания именно о ней, то может и не быть.А должны быть.
Прямо совсем-совсем один?Доллежаль вон целый реактор спроектировал.
Не может человек с программистским образованием оценивать ТЗ по аэродинамике, процессам в ядерном реакторе и т.д. И наоборот тоже."утрата возможности контроля за всеми процессами разработки и производства".
Только порядок обратный. Сделали компьютер, а потом под него пишут программы.Нет смысла делать хардварь, под чужой софтварь.
А какой делать? Необходимо представлять хоть примерно, какие будут программы.Только порядок обратный. Сделали компьютер, а потом под него пишут программы.
Исходя из общих требований - число входных-выходных сигналов, требуемой производительности и т.д. А что именно он будет делать - не важно.А какой делать?
Да, вот как бы несколько вернуть обсуждение в ветке к истокам. К принципам, так сказать.Не, я понимаю, что объём задач серьёзно вырос с тех пор, но это абсолютно схожие по своей проблематике темы. "Утрата навыков ручного пилотирования в условиях тотальной автоматизации" и "утрата возможности контроля за всеми процессами разработки и производства"...
Вот только пилотам о этой системе не сообщили вовсеТот кто делал, может и не знал. А те кто делали, знали о сертификации. Но так как сертификация подразумевала грамотного пилота, то вариант прошел. А теперь даже не знаю, как они сертифицируют, для какого пилота. Они и сами не знают, я думаю так.
А этого и не требуется.Не может человек с программистским образованием оценивать ТЗ по аэродинамике, процессам в ядерном реакторе и т.д. И наоборот тоже.
Пилот должен тупо выполнять процедуры "убегание стабилизатора" или "ненадежные показания скорости", которым в обед сто лет.пилот должен быть с зачатками провидца
Может, кто же спорит. Может кто-то что-то и предлагал. И ему объяснили, почему он не прав.он может оценивать ответственность поставленной задачи и логические дыры ... А так же может предложить математические модели для решения проблем валидации.
А она была прописана?Пилот должен тупо выполнять процедуры "убегание стабилизатора"
Со времен лампового 737.А она была прописана?
Ну блин... А как по другому? Вы заказываете у поставщика оборудование. Это подразумевает под собой хард + софт. Это же не Protected Mode, где можно уровень аппаратных абстракций реализовать, и впихнуть софт под любое железо. Там всё Real-time. Одно под другое разрабатывается. Вы же не думаете, что боинг сначала сам написал софт под отсутствующие контроллеры, с обработкой всех инструкций, прерываний и т.д, а потом заказал под него всю аппаратку? Глупо. Дорого. Геморройно до безобразия. В обратную сторону тоже. Это так не делается. Тупо дорого выйдет. Гораздо дешевле заказать оборудование под ключ. А мистер Боинг деньги считать умеет.С чего бы это? FCC - это ж просто компьютер.
Должно быть. Имхо. Обязательно. Пилот, с учётом того, что большую часть времени полёта занимается именно управлением и контролем систем - ОБЯЗАН знать эти системы. Иначе как их можно контролировать?Их много, и если в кабине нет никакого управления ей, и ее отказ не требует знания именно о ней, то может и не быть.
Вот прям практически в одно лицо)) Нет, понятно, что я утрирую. Но он, как генконструктор представлял, как должны работать СВРК к примеру, и что им можно по функционалу, а что нельзя. И (я не уверен, но скорее всего так), что все системы после разработки проходили через его стол. И без его резолюции дальше не могли идти. По сути, выражаясь современным языком - он архитектор проекта. Правда и он слегка расчитывал на то, что за пультами БЩУ будет сидеть очень хорошо обученный персонал... А передали когда-то АЭС из минсредмаша в МинЭнерго... И недалеко от Киева выполнил взлёт один из энергоблоков... Это как передать управление из Росавиации в Минкульт... Я бы пересел на поезд. Причём метро. Но это уже оффтоп. Простите.Прямо совсем-совсем один?
Вы правы. Не может. Для этого есть руководитель отдела, практически архитектор электронной части проекта. ( с него по-идее и весть спрос за косяк) Тот, у кого техническое образование, он знает, что нужно от аэродинамики, и может сформулировать ТЗ погромистам. Который знает как написать код, но этим не занимается. У него кау раз задача, поставить задачу максимально точно своему отделу. Для этого у него тоже есть совещания с руководством других отделов. Мож шасситам там что-то из сигналов нужно. Ну и т.д. Я думаю вы поняли.Не может человек с программистским образованием оценивать ТЗ по аэродинамике, процессам в ядерном реакторе и т.д. И наоборот тоже.
Да не делается так. Точнее попытки есть, как уже к примеру упомянул Kit. в случае AUTOSAR. Но это лишь попытки. И то, что-то мне подсказывает, что нихрена тут не забота о производителях/потребителях. У них какой-то свой шкурный интерес, только мне пока некогда разбираться в чём именно. Обычно, для экономии ресурсов- создаётся задача. Под нее выбирается разработчик, он уже исходя из ТЗ выбирает аппаратную базу и пишет под неё софт. Ксли по ТЗ заказчика нужно 6 логических выходов, 4 силовых, и 2 аналоговых, то и сделают ровно столько сколько нужно. Никто не будет пихать туда более "широкие" микросхемы, и вешать лишние лапы в воздух. За ОЧЕНЬ ркдким исключением. Это тупо дороже. Поэтому если софт и хард будут делать разные люди - будут проблемы. Или программные костыли, из-за того, что все нюансы не учли, или слишком дорогая получится аппаратка, поскольку слишком расширенная получается. Ну или что-то типа МКАСа получается...) Короче, это всё очень сильно взаимосвязано в построении рил-тайм систем. Дешевле и практичнее сделать это в одном месте. Или у себя, ксли возможности позволяют, илитна стороне, но сразу одним куском.Только порядок обратный. Сделали компьютер, а потом под него пишут программы.
Не сможет, как мне кажется. Этим не программист должен заниматься. А как минимум шеф отдела. Это задача организационная, а не програмистская. ИМХО.А этого и не требуется.
Зато он может оценивать ответственность поставленной задачи и логические дыры (как в случае с теми датчиками угла атаки).
А так же может предложить математические модели для решения проблем валидации.
Убегание стаба - когда он все время маслает. А тут он по 10 секунд и затыкался. Сбивает с толку. Вы же можете представить себе три ситуации, в одной у вас электрочайник после включения через некоторое начинает шуметь, и вскоре закипает. А во второй он то шумит, то нет. Вы подошли, он опять шумит. "Хрен его знает. Может показалось" и в третьем - молчит как партизан. В каком случае вы быстро поймёте, что он отправляется в лучший мир? И кстати, второй случай в инструкции не упомянут. "А зачем? Управлять нечем, индикации нет. Зачем описывать?" ©Со времен лампового 737.
Ну вот как BMW, например, заказывает железо ящика у Боша, а а прошивку к нему - у нас.Ну блин... А как по другому?
С чего бы это?Вы заказываете у поставщика оборудование. Это подразумевает под собой хард + софт.
Это вообще ложная дихотомия. Возьмите QNX, например - там и то, и то.Это же не Protected Mode, где можно уровень аппаратных абстракций реализовать, и впихнуть софт под любое железо. Там всё Real-time.
Референсные драйвера контроллеров поставляются разработчиками чипов, а не ящиков. Вы же не думаете, что микросхемы для FCC проектируются разработчиком FCC?Одно под другое разрабатывается. Вы же не думаете, что боинг сначала сам написал софт под отсутствующие контроллеры, с обработкой всех инструкций, прерываний и т.д, а потом заказал под него всю аппаратку?
Глупо. Дорого. Геморройно до безобразия.
Сколько я помню, словосочетание MCAS в первоначальном варианте FCOM было обьявлено, но описания не было.Там далеко не все системы описаны.
И вы таким способом проектировали критически важные системы? Управление ядерным реактором, например.
Софт заточенный под железо это тупик. Как бы вся история вычислительной техники об этом, IBM PC/XT свободно работал как на "правильной" CP/M так и на "ущербном" (но дешевом) PCDOS. Даже Яблоко это было вынужденно признать после многих лет использования "своего" софта.Ну блин... А как по другому? Вы заказываете у поставщика оборудование. Это подразумевает под собой хард + софт. Это же не Protected Mode, где можно уровень аппаратных абстракций реализовать, и впихнуть софт под любое железо. Там всё Real-time. Одно под другое разрабатывается. Вы же не думаете, что боинг сначала сам написал софт под отсутствующие контроллеры, с обработкой всех инструкций, прерываний и т.д, а потом заказал под него всю аппаратку? Глупо. Дорого. Геморройно до безобразия. В обратную сторону тоже. Это так не делается. Тупо дорого выйдет. Гораздо дешевле заказать оборудование под ключ. А мистер Боинг деньги считать умеет.
"Глупо. Дорого. Геморройно до безобразия.
Приходится не всегда. Можно делать процессоры совместимые "сверху вниз". И потом, уж если ставить новый процессор, то как-то странно оставлять старую программу.А вот переписывать софт, при смене элементной базы "
Замена процессора стоит на порядки дешевле чем новое ПОПриходится не всегда. Можно делать процессоры совместимые "сверху вниз". И потом, уж если ставить новый процессор, то как-то странно оставлять старую программу.
В реализации новой версии нашего автономного вождения мы переходим с Intel на ARM. Понятно, что новые фичи приходится дописывать, но в остальном практически весь наш код просто перекомпилируется другим тулчейном от того же поставщика (BlackBerry). Unit tests и software component tests для одного и того же кода гоняются на обеих платформах.Приходится не всегда. Можно делать процессоры совместимые "сверху вниз". И потом, уж если ставить новый процессор, то как-то странно оставлять старую программу.
Вы ошибаетесь в исходном постулатеОбычно, для экономии ресурсов- создаётся задача. Под нее выбирается разработчик, он уже исходя из ТЗ выбирает аппаратную базу и пишет под неё софт. Ксли по ТЗ заказчика нужно 6 логических выходов, 4 силовых, и 2 аналоговых, то и сделают ровно столько сколько нужно. Никто не будет пихать туда более "широкие" микросхемы, и вешать лишние лапы в воздух. За ОЧЕНЬ ркдким исключением. Это тупо дороже. Поэтому если софт и хард будут делать разные люди - будут проблемы. Или программные костыли, из-за того, что все нюансы не учли, или слишком дорогая получится аппаратка, поскольку слишком расширенная получается. Ну или что-то типа МКАСа получается...) Короче, это всё очень сильно взаимосвязано в построении рил-тайм систем. Дешевле и практичнее сделать это в одном месте. Или у себя, ксли возможности позволяют, илитна стороне, но сразу одним куском.
С точки зрения вычислительной техники - да, безусловно. С точки зрения даже не софта, а если быть чуть более точным - Firmware, что согласитесь - несколько отличается от более общего понятия "софт". А у нас в обсуждаемом случае железо, которому 100 лет в обед., и задача сделать его максимально отказоустойчивым.Софт заточенный под железо это тупик.
Ну вот я собственно и говорю, что одно дело PC, а ПО модулей, тем более real-time несколько иное. Имхо.Как бы вся история вычислительной техники об этом, IBM PC/XT свободно работал как на "правильной" CP/M так и на "ущербном" (но дешевом) PCDOS.
Каюсь, у меня туго с русскоязычным обозначением элементной базы. Но по сути - большая часть вычислителей и работает как раз на ПЛИС, по крайней мере те фото, что можно найти в сети.То что Вы предлагаете - реализуется на ПЛМ/ПЛИС.
Его или слегка переписывать, или как минимум перекомпилировать точно придётся. А это, скорее всего приведёт к тому, что это нужно будет опять как-то сертифицировать наверное. Не уверен.Мне где то попадались статейки про разработку софта для Арбуза , почитайте за "Scade".
А вот переписывать софт, при смене элементной базы...
А зачем его менять? Старые, но отлично работающие MCU Motorola 555/556 серии до сих пор можно купить хоть на развес. Просто как пример. Хотя они морально старые.Замена процессора стоит на порядки дешевле чем новое ПО
Да, но оно построено не на уникальном железе. Да, повышенной живучести, но вполне обычном. Так зачем менять элементную базу? Первые арбузы 90-ых годов меняют сразу блоками. Был MCDU на ЭЛТ, пришел срок - туда ставят LCD. Там естественно элементная база уже новая. Софт тем более. Боинг вообще как был механический, так и остался. В Airbus 7 минут ADIRU алайнится, а у Boeing те же семь минут лампы греются)Тем более "кривовата" замена ПО при смене элементной базы когда речь идет о весьма мелкосерийных производствах (а авиация с т.з. микроэлектроники вся крайне мелкосерийна)
Промышленные серии мелкосхем на рынке, особенно при наличии спроса живут как-то очень долго. Причём не обязательно, что они находятся в производстве. Их просто видимо штампуют столько, чтобы ещё и внукам хватило. Имхо.Так что при уходе с рынка тех или иных "мелкосхем", стараются найти полностью логически - совместимый аналог, или заменить на новое с минимально возможными адаптациями.
Ну, в любом случае поддержка Firmware и возможность UpDate там присутствует, и насколько можно судить по разным форумам и блогам переодически фирмварь там апдейтят. Что само по себе намекает на наличие BootLoader, а соответственно не то, чтобы совсем древний MCU. Поэтому, кмк, заязка на железо вряд-ли там прям вот жесточайшая, но практически уверен, чтт заточена под производителя MCU. Возможно конечно что и RISC-архитектура. К сожалению предметно ничего не могу сказать. К сожалению меня с отверткой пока к самолёту не подпускали.Реальная замена ПО будет производиться только при изменении требований именно к логике функционирования. Либо если оно написано с жесточайшей завязкой на железо (что в современном мире вряд ли )
Ну так блин) Вы ж не путайте банан с килькой. У вас ресурсов требуется, как для майнинга. Там и драйвера, и мультиядерность, и поточность и инструкций вагон. В авиастроении всё значительно проще. Пока.В реализации новой версии нашего автономного вождения мы переходим с Intel на ARM.
Так вы по сути перекомпилили ядро, а остальное само взлетит. QNX-based я полагаю?Понятно, что новые фичи приходится дописывать, но в остальном практически весь наш код просто перекомпилируется другим тулчейном от того же поставщика (BlackBerry). Unit tests и software component tests для одного и того же кода гоняются на обеих платформах.
Блоки - да. Штучные. Но компоненты вполне массовые. Да, не для стиральных мвшин, но Automotive/Marine/Avionics. А их дофига. Да и экономить "на спичках" это давно уже в моде.Вы ошибаетесь в исходном постулате
Мы говорим не о массовке, а о практически штучных изделиях.
Ну будет стоить проц не 10 баксов, а 20. Что это изменит в ценнике самолета?
Понятно. Но если вам всё таки нужно перевести тот или иной блок на новое железо, то скорее всего это будет полноценный переход на что-то качественно новое, а поэтому программисты всё равно будут ваять. Никуда не денутся, и у них есть исходники, заново всё вряд-ли писать придётся. Они же не на асме пишут. Поэтому скомпилировать это по другой проц будет не очень большой задачей.А вот полная замена ПО из за его жесткой завязки на железо - вещь крайне геморная и дорогая. Над этим не один месяц будут работать десятки программистов, и платить им надо не 10 баксов...
Всё зависит, кмк, от поколения этого самого железа. А "максимальная железонезависимость" достигается HAL (Hardware Abstract Layer) . А это уже драйвера, Protected Mode, IRQ и прочие радости Windows®)Поэтому в авиации много дешевле заложить избыточные возможности в железо и сваять под него максимально "железонезависимый" софт, чем потом перелопачивать все от и до.