Jump to content

    
Sign in to follow this  
Doka

Проектирование подсистемы питания с требованиями к потреблению в режиме сна

Recommended Posts

Приветствую!

У вопроса две части: теоретическая и практическая

 

Теоретическая: есть ли стандарты (SAE/ISO), которые регламентируют потребление автомобильной электроники в спящем режиме?

 

Практическая: Подходы к проектированию подсистемы питания с высокими требованиями к потреблению в режиме сна.

 

Допустим (ненаучно), всех always-on потребителей с режимом sleep можно разделить на три категории:

1. RKE - всегда активна в режиме sleep, приёмник всегда запитан и ждёт сигнала из эфира

2. IVI - автовыключение по таймауту, если питание от батареи, как такового режима sleep нету, но можно задействовать механизм включения следующий: нажатие на кнопку включения замыкает ключ (MOSFET?) подачи напряжения на схему устройства, после чего МК устройства сам эмулирует "нажатие кнопки" , т.е. питание ключа (кнопку можно отпускать) - т.о. обеспечивается нулевое потребление в sleep и возможность включения устройства

3. ВСМ (допущение) - МК запитанный через низкопотребляющий LDO в sleep слушает шину CAN и по приёму определённого сообщения просыпается (если надо - то замыкает ключом цепь для питания более мощной начинки DC/DC)

 

Конечно из всего этого изобилия наверняка на самом деле потребляет только RKE, а всё остальное отрубается при постановке машины на охрану (у многих современных авто после постановки на охрану через 30сек что-то сильно щёлкает - такое ощущение, что мощное реле отключает всех потребителей), но с другой стороны, когда в режиме охраны включаешь с брелока салонный свет или открываешь электробагажник ничего не щёлкает - то есть как минимум ВСМ также запитан и переведен в режим sleep

 

Собственно интересуют подходы к проектированию архитектуры подобной системы питания в случае, близком к 3му варианту: но что-то у меня не очень складывается картинка - неужели там ставят помимо LDO еще и dedicated-uC чтобы из режима sleep слушать CAN? Или объединяют всё-же функционал в одном uC для sleep & non-sleep режимов?

Изучал начинку блоков салонной электроники корейских авто - так там всё достаточно бедно - такое ощущение, что поставить DC/DC для них непозволительная роскошь везде понатыканы огромные LDO с рассеянием тепла в плату(((((

 

Задача - понять принципы проектирования подобных блоков (класса ВСМ) с минимальным потреблением в режиме sleep (кстати каким? 1мА - много? .. а 5мА?) и докучи оптимизированным по ВОМ, чтобы не раздувать дублирование функционала.

Share this post


Link to post
Share on other sites

Что такое sleep режим прежде надо договориться.
Скажем сейчас имею  дело с экономичным  дивайсом, так его микроконтроллер поддерживает 4-е режима пониженного потребления.

  • Sleep mode
  • Software Standby mode
  • Snooze mode
  • Deep Software Standby mode

Что дивайс может делать в том или ином режиме и сколько будет потреблять так просто не выяснить.
В SoC-е есть разветвленный коммутатор сигналов прерываний и событий, разные способы деактивации внутренней периферии и сохранения ее состояния. 
Поскольку статично  эти режимы не используют. Все время идет переключение между ними и очень большое значение имеет эффективность софта и профайлинг. 
Надо как минимум иметь механизм измерения собственного тока во всех режимах и измерения задержек переключения (старта осцилляторов, активации контроллеров памяти, старта внутренних DC/DC и проч.)  Т.е. я б акцентировал внимание на адаптивных алгоритмах экономии энергии, эффективном софте а не на железе.
 

Share this post


Link to post
Share on other sites

Doka, по ссылке ниже очень хорошая презентация от конкурентов. Если коротко, то обычно делают так(один из случаев) - МК выключен, питание подано на трансивер (например CAN), если нужно разбудить устройство, то по шине передается wake-up пакет и трансивер включает питание МК (выходом INH).

В некоторых случаях, основной МК имеет внутри дополнительне 8-битное ядро с малым потреблением(десятки мкА). Это ядро следит за определенными событиями и активирует основное ядро/ядра по необходимости. Питается все это обычно через LDO с низким током покоя(quiescent current). Например TPS7B82 (TI).

 

Link

Edited by mishin

Share this post


Link to post
Share on other sites
On 5/1/2019 at 2:41 PM, AlexandrY said:

Что такое sleep режим прежде надо договориться.

в общем случае это режим сколь угодно долгого питания от батареи (двигатель заглушен)

как пример: тот же RKE - питается от батареи и сколь угодно долго (т.е. всегда) ждёт из эфига сигнала о снятии с охраны/разблокировке дверей.

 

On 5/1/2019 at 2:41 PM, AlexandrY said:

В SoC-е есть разветвленный коммутатор сигналов прерываний и событий, разные способы деактивации внутренней периферии и сохранения ее состояния. 
Поскольку статично  эти режимы не используют.

здесь SoC - SoC'ам рознь...

всякие СнК для батарейного питания годами (типа BLE) действительно сильно вылизаны с точки зрения архитектуры, имею возможность независимой работы периферии при остановленном/отключенном ядре - там понятно ради чего экономия, но в автомобиле в общем случае батарейка поболе чем CR2032, поэтому, кмк, тут немного другие подходы...

 

Поисследовал электрические схемы современных европейских брендов и немного изменилась картина:

  • куча релюшек (обычных механических релюшек!!!), чтобы в sleep отключать намертво всё, что не требуется в sleep
  • ни один модуль с CAN не запитан в  sleep, будь то RKE или дистанционное управление вебасто
  • в sleep остаётся подключеным к шине питания весьма ограниченное число модулей и все они коммуницируют по LIN (RKE, СЕМ, внутрисалонные датчики детекта движения/сердцебиения, etc)
On 5/1/2019 at 2:41 PM, AlexandrY said:

очень большое значение имеет эффективность софта и профайлинг

 

On 5/1/2019 at 2:41 PM, AlexandrY said:

Т.е. я б акцентировал внимание на адаптивных алгоритмах экономии энергии, эффективном софте а не на железе.

тут же не только ядро крутится и потребляет, а надо соизмерять с потреблением сенсоров (ISM риадиприемник, сенсоры движения/сердцебиения, сенсор наклона, etc ), кмк, на фоне которых потреблением СнК можно пренебречь

 

 

 

Share this post


Link to post
Share on other sites
On 5/6/2019 at 4:57 PM, mishin said:

В некоторых случаях, основной МК имеет внутри дополнительне 8-битное ядро с малым потреблением(десятки мкА). Это ядро следит за определенными событиями и активирует основное ядро/ядра по необходимости.

вот я тоже прихожу к этой концепции, что нужен служебный контроллер питания для режима sleep на каком-нить диетическом восьмибитнике, который в т.ч. будет коммутировать питание на основную схему.

 

On 5/6/2019 at 4:57 PM, mishin said:

Питается все это обычно через LDO с низким током покоя(quiescent current). Например TPS7B82 (TI).

спасибо за ссылку на документ и наводку на бюджетный  Automotive, AEC-Q100 LDO!

 

Еще по ссылке описано интересное состояние, хотя напрямую к sleep не относящееся:

Infotainment mode: Driver is in the car but ignition is off

также приведен порядок величин на потребление в sleep режиме: < 100 μA requirement

 

Share this post


Link to post
Share on other sites
8 минут назад, Doka сказал:

Еще по ссылке описано интересное состояние,

Обычное состояние, первое положение ключа зажигания.

То что по ссылке уже сильно устарело, KL15 в авто больше не делают.

Share this post


Link to post
Share on other sites
36 minutes ago, Vasily_ said:

Обычное состояние, первое положение ключа зажигания.

вообще на современных авто IVI может включаться/работать без вставки ключа зажигания.

в этом режиме отключение происходит по таймауту - если нету вмешательства пользователя в работу IVI свыше некоторого лимита времени

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this