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

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

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

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

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

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

Вы заказываете у поставщика оборудование. Это подразумевает под собой хард + софт.
С чего бы это?

Это же не Protected Mode, где можно уровень аппаратных абстракций реализовать, и впихнуть софт под любое железо. Там всё Real-time.
Это вообще ложная дихотомия. Возьмите QNX, например - там и то, и то.

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

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

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

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

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