Автоматика как фактор безопасности в современных транспортных средствах

Их много, и если в кабине нет никакого управления ей, и ее отказ не требует знания именно о ней, то может и не быть.

Доллежаль вон целый реактор спроектировал.
Прямо совсем-совсем один?

Не может человек с программистским образованием оценивать ТЗ по аэродинамике, процессам в ядерном реакторе и т.д. И наоборот тоже.

Нет смысла делать хардварь, под чужой софтварь.
Только порядок обратный. Сделали компьютер, а потом под него пишут программы.
 
Да, вот как бы несколько вернуть обсуждение в ветке к истокам. К принципам, так сказать.
 
Вот только пилотам о этой системе не сообщили вовсе
Так что пилот должен быть с зачатками провидца - грамотность "от Боинг" тут не поможет
 
А этого и не требуется.
Зато он может оценивать ответственность поставленной задачи и логические дыры (как в случае с теми датчиками угла атаки).
А так же может предложить математические модели для решения проблем валидации.
 
пилот должен быть с зачатками провидца
Пилот должен тупо выполнять процедуры "убегание стабилизатора" или "ненадежные показания скорости", которым в обед сто лет.

Может, кто же спорит. Может кто-то что-то и предлагал. И ему объяснили, почему он не прав.
 
С чего бы это? FCC - это ж просто компьютер.
Ну блин... А как по другому? Вы заказываете у поставщика оборудование. Это подразумевает под собой хард + софт. Это же не Protected Mode, где можно уровень аппаратных абстракций реализовать, и впихнуть софт под любое железо. Там всё Real-time. Одно под другое разрабатывается. Вы же не думаете, что боинг сначала сам написал софт под отсутствующие контроллеры, с обработкой всех инструкций, прерываний и т.д, а потом заказал под него всю аппаратку? Глупо. Дорого. Геморройно до безобразия. В обратную сторону тоже. Это так не делается. Тупо дорого выйдет. Гораздо дешевле заказать оборудование под ключ. А мистер Боинг деньги считать умеет.
 
Должно быть. Имхо. Обязательно. Пилот, с учётом того, что большую часть времени полёта занимается именно управлением и контролем систем - ОБЯЗАН знать эти системы. Иначе как их можно контролировать?
Прямо совсем-совсем один?
Вот прям практически в одно лицо)) Нет, понятно, что я утрирую. Но он, как генконструктор представлял, как должны работать СВРК к примеру, и что им можно по функционалу, а что нельзя. И (я не уверен, но скорее всего так), что все системы после разработки проходили через его стол. И без его резолюции дальше не могли идти. По сути, выражаясь современным языком - он архитектор проекта. Правда и он слегка расчитывал на то, что за пультами БЩУ будет сидеть очень хорошо обученный персонал... А передали когда-то АЭС из минсредмаша в МинЭнерго... И недалеко от Киева выполнил взлёт один из энергоблоков... Это как передать управление из Росавиации в Минкульт... Я бы пересел на поезд. Причём метро. Но это уже оффтоп. Простите.
Вы правы. Не может. Для этого есть руководитель отдела, практически архитектор электронной части проекта. ( с него по-идее и весть спрос за косяк) Тот, у кого техническое образование, он знает, что нужно от аэродинамики, и может сформулировать ТЗ погромистам. Который знает как написать код, но этим не занимается. У него кау раз задача, поставить задачу максимально точно своему отделу. Для этого у него тоже есть совещания с руководством других отделов. Мож шасситам там что-то из сигналов нужно. Ну и т.д. Я думаю вы поняли.
Да не делается так. Точнее попытки есть, как уже к примеру упомянул Kit. в случае AUTOSAR. Но это лишь попытки. И то, что-то мне подсказывает, что нихрена тут не забота о производителях/потребителях. У них какой-то свой шкурный интерес, только мне пока некогда разбираться в чём именно. Обычно, для экономии ресурсов- создаётся задача. Под нее выбирается разработчик, он уже исходя из ТЗ выбирает аппаратную базу и пишет под неё софт. Ксли по ТЗ заказчика нужно 6 логических выходов, 4 силовых, и 2 аналоговых, то и сделают ровно столько сколько нужно. Никто не будет пихать туда более "широкие" микросхемы, и вешать лишние лапы в воздух. За ОЧЕНЬ ркдким исключением. Это тупо дороже. Поэтому если софт и хард будут делать разные люди - будут проблемы. Или программные костыли, из-за того, что все нюансы не учли, или слишком дорогая получится аппаратка, поскольку слишком расширенная получается. Ну или что-то типа МКАСа получается...) Короче, это всё очень сильно взаимосвязано в построении рил-тайм систем. Дешевле и практичнее сделать это в одном месте. Или у себя, ксли возможности позволяют, илитна стороне, но сразу одним куском.
Не сможет, как мне кажется. Этим не программист должен заниматься. А как минимум шеф отдела. Это задача организационная, а не програмистская. ИМХО.
Со времен лампового 737.
Убегание стаба - когда он все время маслает. А тут он по 10 секунд и затыкался. Сбивает с толку. Вы же можете представить себе три ситуации, в одной у вас электрочайник после включения через некоторое начинает шуметь, и вскоре закипает. А во второй он то шумит, то нет. Вы подошли, он опять шумит. "Хрен его знает. Может показалось" и в третьем - молчит как партизан. В каком случае вы быстро поймёте, что он отправляется в лучший мир? И кстати, второй случай в инструкции не упомянут. "А зачем? Управлять нечем, индикации нет. Зачем описывать?" ©
 
Последнее редактирование:
Ну блин... А как по другому?
Ну вот как BMW, например, заказывает железо ящика у Боша, а а прошивку к нему - у нас.

С чего бы это?

Это вообще ложная дихотомия. Возьмите QNX, например - там и то, и то.

Референсные драйвера контроллеров поставляются разработчиками чипов, а не ящиков. Вы же не думаете, что микросхемы для FCC проектируются разработчиком FCC?

Глупо. Дорого. Геморройно до безобразия.
 
Сколько я помню, словосочетание MCAS в первоначальном варианте FCOM было обьявлено, но описания не было.

А по поводу проектирования, это для совсем другой ветки - но полагаю управление ядерным реактором как и управление АМС было на основе электро-механической "логики".
 
Софт заточенный под железо это тупик. Как бы вся история вычислительной техники об этом, IBM PC/XT свободно работал как на "правильной" CP/M так и на "ущербном" (но дешевом) PCDOS. Даже Яблоко это было вынужденно признать после многих лет использования "своего" софта.
То что Вы предлагаете - реализуется на ПЛМ/ПЛИС.
Мне где то попадались статейки про разработку софта для Арбуза , почитайте за "Scade".
А вот переписывать софт, при смене элементной базы "
Глупо. Дорого. Геморройно до безобразия.
"
 
А вот переписывать софт, при смене элементной базы "
Приходится не всегда. Можно делать процессоры совместимые "сверху вниз". И потом, уж если ставить новый процессор, то как-то странно оставлять старую программу.
 
Замена процессора стоит на порядки дешевле чем новое ПО
Тем более "кривовата" замена ПО при смене элементной базы когда речь идет о весьма мелкосерийных производствах (а авиация с т.з. микроэлектроники вся крайне мелкосерийна)
Так что при уходе с рынка тех или иных "мелкосхем", стараются найти полностью логически - совместимый аналог, или заменить на новое с минимально возможными адаптациями.
Реальная замена ПО будет производиться только при изменении требований именно к логике функционирования. Либо если оно написано с жесточайшей завязкой на железо (что в современном мире вряд ли )
 
В реализации новой версии нашего автономного вождения мы переходим с Intel на ARM. Понятно, что новые фичи приходится дописывать, но в остальном практически весь наш код просто перекомпилируется другим тулчейном от того же поставщика (BlackBerry). Unit tests и software component tests для одного и того же кода гоняются на обеих платформах.

И это на C++. Тем же, кто пишет на какой-нибудь Аде, должно быть тем более без разницы.
 
Вы ошибаетесь в исходном постулате
Мы говорим не о массовке, а о практически штучных изделиях.
Ну будет стоить проц не 10 баксов, а 20. Что это изменит в ценнике самолета?
А вот полная замена ПО из за его жесткой завязки на железо - вещь крайне геморная и дорогая. Над этим не один месяц будут работать десятки программистов, и платить им надо не 10 баксов... Поэтому в авиации много дешевле заложить избыточные возможности в железо и сваять под него максимально "железонезависимый" софт, чем потом перелопачивать все от и до.
 
Софт заточенный под железо это тупик.
С точки зрения вычислительной техники - да, безусловно. С точки зрения даже не софта, а если быть чуть более точным - Firmware, что согласитесь - несколько отличается от более общего понятия "софт". А у нас в обсуждаемом случае железо, которому 100 лет в обед., и задача сделать его максимально отказоустойчивым.
Ну вот я собственно и говорю, что одно дело PC, а ПО модулей, тем более real-time несколько иное. Имхо.
То что Вы предлагаете - реализуется на ПЛМ/ПЛИС.
Каюсь, у меня туго с русскоязычным обозначением элементной базы. Но по сути - большая часть вычислителей и работает как раз на ПЛИС, по крайней мере те фото, что можно найти в сети.
Что-то попадалось на древних как экскременты мамонта Motorola HC(08), микросхемах памяти от AMD, формфактор "конь", разве что окна под ультрафилотовое стирание не было. Были конечно какие-то фотки внутренностей блоков с ST32. Он уже на арм и 32 разрядный, но это уже что-то из совсем нового. Хотя в современном мире, оно уже тоже старое)
Его или слегка переписывать, или как минимум перекомпилировать точно придётся. А это, скорее всего приведёт к тому, что это нужно будет опять как-то сертифицировать наверное. Не уверен.
Замена процессора стоит на порядки дешевле чем новое ПО
А зачем его менять? Старые, но отлично работающие MCU Motorola 555/556 серии до сих пор можно купить хоть на развес. Просто как пример. Хотя они морально старые.
Да, но оно построено не на уникальном железе. Да, повышенной живучести, но вполне обычном. Так зачем менять элементную базу? Первые арбузы 90-ых годов меняют сразу блоками. Был MCDU на ЭЛТ, пришел срок - туда ставят LCD. Там естественно элементная база уже новая. Софт тем более. Боинг вообще как был механический, так и остался. В Airbus 7 минут ADIRU алайнится, а у Boeing те же семь минут лампы греются)
Промышленные серии мелкосхем на рынке, особенно при наличии спроса живут как-то очень долго. Причём не обязательно, что они находятся в производстве. Их просто видимо штампуют столько, чтобы ещё и внукам хватило. Имхо.
Ну, в любом случае поддержка Firmware и возможность UpDate там присутствует, и насколько можно судить по разным форумам и блогам переодически фирмварь там апдейтят. Что само по себе намекает на наличие BootLoader, а соответственно не то, чтобы совсем древний MCU. Поэтому, кмк, заязка на железо вряд-ли там прям вот жесточайшая, но практически уверен, чтт заточена под производителя MCU. Возможно конечно что и RISC-архитектура. К сожалению предметно ничего не могу сказать. К сожалению меня с отверткой пока к самолёту не подпускали.
Ну так блин) Вы ж не путайте банан с килькой. У вас ресурсов требуется, как для майнинга. Там и драйвера, и мультиядерность, и поточность и инструкций вагон. В авиастроении всё значительно проще. Пока.
Так вы по сути перекомпилили ядро, а остальное само взлетит. QNX-based я полагаю?
Блоки - да. Штучные. Но компоненты вполне массовые. Да, не для стиральных мвшин, но Automotive/Marine/Avionics. А их дофига. Да и экономить "на спичках" это давно уже в моде.
Понятно. Но если вам всё таки нужно перевести тот или иной блок на новое железо, то скорее всего это будет полноценный переход на что-то качественно новое, а поэтому программисты всё равно будут ваять. Никуда не денутся, и у них есть исходники, заново всё вряд-ли писать придётся. Они же не на асме пишут. Поэтому скомпилировать это по другой проц будет не очень большой задачей.
Всё зависит, кмк, от поколения этого самого железа. А "максимальная железонезависимость" достигается HAL (Hardware Abstract Layer) . А это уже драйвера, Protected Mode, IRQ и прочие радости Windows®)

P. S. Хотя я вполне допускаю, что я сильно не прав, поскольку всё-таки не являюсь в прямом смысле разработчиком МК. Но в любом случае дискуссия с образованными людьми сама по себе познавательна.
 
Последнее редактирование: