На плате используются компоненты с автомобильным грейдом, больше никаких особенностей не видно. Производитель использует высоконадёжные дискретные элементы, прошедшие термотренировку и имеющие гарантированный FIT. Я не считал FIT для обвязки процессора, кмк, Demo Board не соответствует уровню ASIL-B (как минимум по покрытию обнаружения SPF/LPF). Но она будет использоваться только для разработки софта на столе до этапа готовности своего железа.
Информации о техпроцессах чипов у меня нет, рискну предполагаю, что там обычный техпроцесс без всяких КНИ. Но для исполнения могут использоваться ядра, работающие в режиме Lockstep. По сути, это 2 ядра, выполняющие одинаковые инструкции на одинаковых данных. При возникновении отличия в результате, процессор может быть переведён в Safety State. Также все критичные регистры "затроированны" (имеют 3 копии). Память и шина используют ECC SECDED (Single Error Correction Double Error Detection). Всё это увеличивает надёжность выполнения (как минимум вероятность обнаружить ошибку при её возникновении).
Добрый день! Elcipse - это FC_IDE и его генерируемые Makefile'ы? Тогда там под капотом там gcc. Интересно конкретику - какой именно чип, на каких ядрах запускаете код? Код в SRAM или Flash? В чём выражается неадекватность исполнения?
Немного занудства, не пробовали через gdb подключиться и поотлаживать?
7300 - очень интересный чип, но, по нашей информации, только находящийся в процессе сертификации.
Я собираю с оптимизацией -Os, сейчас запущен RTOS, под которым исполняется код, взаимодействующий с различной периферией. Пока всё работает как задумано. Но 4150 существенно отличается от 7300. Если не получится победить, могу свой проект запустить на 7300 на одном ядре.
Мы доверяем на основании заложенных Safety Mechanisms, соответствия ISO26262, сертификатов и здравого смысла.
Изучение сертификатов и Safety Manual было нами выполнено на этапе, предшествующем заказу отладочных плат. Другое дело SDK, который до получения платы был определённым "котом в мешке".
Мигание диодов - это простой пример, демонстрирующий сборку и запуск кода на этой платформе. Пока это первая статья, которая, если будет интерес, может превратиться в цикл: можем рассказать про использование модуля EIM (Error Injection Module), с помощью которого можно инжектировать ошибки, про софтовые Safety Mechanisms, решающие определённые задачи.
Выполняется FTA, по которому определяются критичные компоненты и оценивается надёжность Safety Related функций. Если в результате надёжность соответствует требованиям, то всё ОК.
Также используются различные Safety Mechanisms. Например, в микроконтроллере используется CCS, обеспечивающая переключение на внутренний генератор с формированием сообщения об ошибке при отсутствии/изменении параметров тактового сигнала. Плюс практически всегда используется Watchdog, переводящий исполнительные устройства в Safety State. Также работает Fault пин, который устанавливается при детектировании микроконтроллером ошибки в BIST или работе.
Может и добровольное, вот только, если с климатикой найти компоненты можно из индустриального грейда, то с надёжностью могут возникнуть сложности. Обычно на не AEC компоненты никто не считает отказы, соответственно никакого Reliability Report. Остаётся только по справочникам считать.
В не Safety Related устройствах применение возможно. В Safety Related - с большой осторожностью и расчётами.
ISO 26262 как раз и говорит о том, как проектировать системы с достаточной степень надёжности. По этому стандарту SWP должен проектироваться по ASIL-D, что приводит к вероятности отказа 10^-8 устройство-часов. Если интересно, можем обсудить конкретные Safety Mechanism, которые обеспечивают достаточный уровень надёжности, выше в комментариях люди упоминали про требования к датчикам и рулевой рейке. К ЭБУ требования не меньше - только lockstep/ecc/major voting и другие.
Что касается люфтов в рулевом управлении, то я не утверждал, что у каждого автомобиля они 10%, но они есть и увеличиваются по мере эксплуатации и износа рулевых карданов и рулевой рейки. Просто скажу, что они имеют место быть, и эти машины также ездиют по ДОПам. В качестве примера, можно порулить чем-то вроде УАЗ Буханка, чтобы убедиться.
Что касается вносимой электроникой задержек, то среднее время реакции человека на свет 100-200 мс. Допустим ЭБУ добавит 1мс (с точки зрения MCU это огромное время). Итого задержка, обусловленная ЭБУ в худшем случае составит 1%.
Решение можно найти. Если говорить о технических, то сразу видится как минимум 2 - возможность питания SBW/BBW без включения других систем именно для буксировки. Или использование тягового электродвигателя как генератора. Например, у самолётов предусмотрено выбрасывание небольшого генератора/насоса, который раскручивается набегающим потоком воздуха и обеспечивает работу аварийных систем.
В целом согласен, что внедрение системы приводит к целому кластеру проблем, которые не пришлось бы решать. Но это же решение продвигается маркеторологами - автомобиль как услуга. В идеале полностью отстранить человека от управления автомобилем и использовать автопилот.
Про обратную свзяь полностью согласен, но это современная тенденция - продвижение новых продуктов как требующих меньше навыков от пользователя. В случае автомобиля достаточно посмотреть на старые книги по обучению водителей (шофёров?). Человек, который раньше управлял автомобилем, владел навыками переборки карбюратора в полевых условиях, мог по звуку диагностировать поломку и т.д. И это действительно было необходимо! И сколько людей в современном мире купили бы автомобиль на таких условиях? Для расширения целевой аудитории происходит упрощение требований к водителю. Водитель из профессионала становится обычным человеком, выучившим (иногда и не выучившим) ПДД. Некоторые маркетологи смотрят за горизонт и видят автомобиль как услугу.
В мире авиастроения была похожая ситуация с Боингом и Эйрбасом, когда последний внедрил технологию fly-by-wire. В общем-то сейчас большинство лётчиком спокойно летают на самолётах обоих производителей, но лётчики-испытатели предпочитают Боинг, в котором ощущается обратная связь от сопротивления среды на штурвале.
Не рискну утверждать, что электронная система быстрее механической в произвольный момент, но она может иметь прогрессивную характеристику поворота колёс как функцую от поворота рулевого колеса. В этом смысле достижение требуемого угла поворота может быть действительно быстрее, чем в линейной функции механической связи.
К тому же механическая связь обеспечивает жёсткую передачу только в идеальных условиях. В реальных в каждом узле механической связи (или почти в каждом) по мере износа возникает люфт, который даже проверяется на техосмотре (10 градусов для легкового авто и 25 - для грузовика, если ничего не путаю). В общем случае, водитель сначала выберет люфт и только потом начнёт поворачивать колёса.
EGR как способ уменьшить количество кислорода в цилинде, что автоматически приводит к снижению требуемого количества топлива. Признаю, что обычно EGR используется для другого применения плюс имеет довольно ощутимые негативные нюансы.
У уже упомянутой тойоты была систем lean burn. Опять же это про другое, но там использовались сложная система впуска со спиральным каналом и классическим, который открывался внешним пневмоприводом. По уверениям производителя, применение завихрителя позволяло улучшить смесеобразование и уменьшить требуемое количество. На высоких нагрузках эта система отключалась.
Ну и сразу приходит в голову ограничение мощности через полное выключение подачи топлива в отдельные цилиндры.
На плате используются компоненты с автомобильным грейдом, больше никаких особенностей не видно. Производитель использует высоконадёжные дискретные элементы, прошедшие термотренировку и имеющие гарантированный FIT. Я не считал FIT для обвязки процессора, кмк, Demo Board не соответствует уровню ASIL-B (как минимум по покрытию обнаружения SPF/LPF). Но она будет использоваться только для разработки софта на столе до этапа готовности своего железа.
Информации о техпроцессах чипов у меня нет, рискну предполагаю, что там обычный техпроцесс без всяких КНИ. Но для исполнения могут использоваться ядра, работающие в режиме Lockstep. По сути, это 2 ядра, выполняющие одинаковые инструкции на одинаковых данных. При возникновении отличия в результате, процессор может быть переведён в Safety State. Также все критичные регистры "затроированны" (имеют 3 копии). Память и шина используют ECC SECDED (Single Error Correction Double Error Detection). Всё это увеличивает надёжность выполнения (как минимум вероятность обнаружить ошибку при её возникновении).
Добрый день! Elcipse - это FC_IDE и его генерируемые Makefile'ы? Тогда там под капотом там gcc. Интересно конкретику - какой именно чип, на каких ядрах запускаете код? Код в SRAM или Flash? В чём выражается неадекватность исполнения?
Немного занудства, не пробовали через gdb подключиться и поотлаживать?
7300 - очень интересный чип, но, по нашей информации, только находящийся в процессе сертификации.
Я собираю с оптимизацией -Os, сейчас запущен RTOS, под которым исполняется код, взаимодействующий с различной периферией. Пока всё работает как задумано. Но 4150 существенно отличается от 7300. Если не получится победить, могу свой проект запустить на 7300 на одном ядре.
Проблема была в подходе к проектированию и игнорирование требований безопасности при разработке
https://habr.com/ru/companies/first/articles/754008/
https://en.wikipedia.org/wiki/Maneuvering_Characteristics_Augmentation_System
Заказчику может стать резко не "без разницы", если отказ устройств будет носить систематический характер и приводить к тяжёлым последствиям.
Можно вспомнить ситуацию с электроусилителем или электронной педалью газа. Или вот отзыв Боингов 737 Max.
Мы доверяем на основании заложенных Safety Mechanisms, соответствия ISO26262, сертификатов и здравого смысла.
Изучение сертификатов и Safety Manual было нами выполнено на этапе, предшествующем заказу отладочных плат. Другое дело SDK, который до получения платы был определённым "котом в мешке".
Мигание диодов - это простой пример, демонстрирующий сборку и запуск кода на этой платформе. Пока это первая статья, которая, если будет интерес, может превратиться в цикл: можем рассказать про использование модуля EIM (Error Injection Module), с помощью которого можно инжектировать ошибки, про софтовые Safety Mechanisms, решающие определённые задачи.
Выполняется FTA, по которому определяются критичные компоненты и оценивается надёжность Safety Related функций. Если в результате надёжность соответствует требованиям, то всё ОК.
Также используются различные Safety Mechanisms. Например, в микроконтроллере используется CCS, обеспечивающая переключение на внутренний генератор с формированием сообщения об ошибке при отсутствии/изменении параметров тактового сигнала. Плюс практически всегда используется Watchdog, переводящий исполнительные устройства в Safety State. Также работает Fault пин, который устанавливается при детектировании микроконтроллером ошибки в BIST или работе.
Каждый Safety Goal разбирается индивидуально.
Может и добровольное, вот только, если с климатикой найти компоненты можно из индустриального грейда, то с надёжностью могут возникнуть сложности. Обычно на не AEC компоненты никто не считает отказы, соответственно никакого Reliability Report. Остаётся только по справочникам считать.
В не Safety Related устройствах применение возможно. В Safety Related - с большой осторожностью и расчётами.
ISO 26262 как раз и говорит о том, как проектировать системы с достаточной степень надёжности. По этому стандарту SWP должен проектироваться по ASIL-D, что приводит к вероятности отказа 10^-8 устройство-часов. Если интересно, можем обсудить конкретные Safety Mechanism, которые обеспечивают достаточный уровень надёжности, выше в комментариях люди упоминали про требования к датчикам и рулевой рейке. К ЭБУ требования не меньше - только lockstep/ecc/major voting и другие.
Что касается люфтов в рулевом управлении, то я не утверждал, что у каждого автомобиля они 10%, но они есть и увеличиваются по мере эксплуатации и износа рулевых карданов и рулевой рейки. Просто скажу, что они имеют место быть, и эти машины также ездиют по ДОПам. В качестве примера, можно порулить чем-то вроде УАЗ Буханка, чтобы убедиться.
Что касается вносимой электроникой задержек, то среднее время реакции человека на свет 100-200 мс. Допустим ЭБУ добавит 1мс (с точки зрения MCU это огромное время). Итого задержка, обусловленная ЭБУ в худшем случае составит 1%.
Решение можно найти. Если говорить о технических, то сразу видится как минимум 2 - возможность питания SBW/BBW без включения других систем именно для буксировки. Или использование тягового электродвигателя как генератора. Например, у самолётов предусмотрено выбрасывание небольшого генератора/насоса, который раскручивается набегающим потоком воздуха и обеспечивает работу аварийных систем.
В целом согласен, что внедрение системы приводит к целому кластеру проблем, которые не пришлось бы решать. Но это же решение продвигается маркеторологами - автомобиль как услуга. В идеале полностью отстранить человека от управления автомобилем и использовать автопилот.
Про обратную свзяь полностью согласен, но это современная тенденция - продвижение новых продуктов как требующих меньше навыков от пользователя. В случае автомобиля достаточно посмотреть на старые книги по обучению водителей (шофёров?). Человек, который раньше управлял автомобилем, владел навыками переборки карбюратора в полевых условиях, мог по звуку диагностировать поломку и т.д. И это действительно было необходимо! И сколько людей в современном мире купили бы автомобиль на таких условиях? Для расширения целевой аудитории происходит упрощение требований к водителю. Водитель из профессионала становится обычным человеком, выучившим (иногда и не выучившим) ПДД. Некоторые маркетологи смотрят за горизонт и видят автомобиль как услугу.
В мире авиастроения была похожая ситуация с Боингом и Эйрбасом, когда последний внедрил технологию fly-by-wire. В общем-то сейчас большинство лётчиком спокойно летают на самолётах обоих производителей, но лётчики-испытатели предпочитают Боинг, в котором ощущается обратная связь от сопротивления среды на штурвале.
Не рискну утверждать, что электронная система быстрее механической в произвольный момент, но она может иметь прогрессивную характеристику поворота колёс как функцую от поворота рулевого колеса. В этом смысле достижение требуемого угла поворота может быть действительно быстрее, чем в линейной функции механической связи.
К тому же механическая связь обеспечивает жёсткую передачу только в идеальных условиях. В реальных в каждом узле механической связи (или почти в каждом) по мере износа возникает люфт, который даже проверяется на техосмотре (10 градусов для легкового авто и 25 - для грузовика, если ничего не путаю). В общем случае, водитель сначала выберет люфт и только потом начнёт поворачивать колёса.
EGR как способ уменьшить количество кислорода в цилинде, что автоматически приводит к снижению требуемого количества топлива. Признаю, что обычно EGR используется для другого применения плюс имеет довольно ощутимые негативные нюансы.
У уже упомянутой тойоты была систем lean burn. Опять же это про другое, но там использовались сложная система впуска со спиральным каналом и классическим, который открывался внешним пневмоприводом. По уверениям производителя, применение завихрителя позволяло улучшить смесеобразование и уменьшить требуемое количество. На высоких нагрузках эта система отключалась.
Ну и сразу приходит в голову ограничение мощности через полное выключение подачи топлива в отдельные цилиндры.