Профилирование энергопотребления умных часов¶

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

Рекомендации по архитектуре и прошивке приведены в статье Обзор энергосберегающего проектирования, а порядок измерений для проверки модели — в статье Измерение и проверка энергопотребления.

Обзор системы умных часов¶

Сначала определите границы модели. В рабочей книге смоделированы часы с питанием от аккумулятора, MCU, AMOLED-дисплеем, вибромотором и неразделённой категорией нагрузок Other. Размер, разрешение и яркость панели, архитектура радиотракта и отдельные датчики в ней не указаны. Значения тока дисплея ниже — входные параметры модели, а не результаты измерений или характеристики конкретной панели. Other обозначает границу детализации модели, а не один физический компонент.

Энергопотребление по сценариям¶

Сценарий — это целое действие пользователя или событие системы, а не работа отдельного компонента. Уведомление о сообщении может разбудить MCU, включить AMOLED-дисплей, запустить вибромотор и оставить фоновые нагрузки активными. Каждая строка Display в исходной матрице относится к AMOLED-дисплею. Строки компонентов сгруппированы по сценариям; рассчитанные суточные значения сохранены, чтобы их можно было сверить с источником. Частота событий и длительность, на которых основаны эти значения, приведены в следующем разделе.

*В рабочей книге столбец обозначен как “Power-Conversion Efficiency (%)”, но его формула рассчитывает лишь отношение напряжений, а не измеренный КПД стабилизатора. Подраздел «Проверка допущения о преобразовании питания» ниже объясняет, как это влияет на оценку автономности. Суточный расход заряда и проценты здесь округлены; точные формулы и значения доступны в скачиваемом файле. Для выбора приоритетов используйте расположенные ниже таблицы с ранжированием, а для проверки исходного тока или напряжения отдельной нагрузки возвращайтесь к этой матрице.

flowchart LR
    A["Задать ежедневное использование"] --> B["Задать ток и время работы каждой нагрузки"]
    B --> C["Суммировать mAh за сутки со стороны аккумулятора"]
    C --> D["Ранжировать вклад сценариев и компонентов"]
    D --> E["Измерить основные нагрузки на оборудовании"]
    E --> F["Уточнить допущения и повторить"]
    F --> B

Пересчёт сценария в суточный расход заряда¶

Если ток нагрузки уже задан со стороны аккумулятора, суточный расход заряда рассчитывается напрямую:

daily_charge_mAh = current_mA x active_time_seconds_per_day / 3600

Если нагрузка питается через стабилизатор, сначала рассчитайте ток со стороны аккумулятора, затем учтите время работы:

battery_current_mA = (load_voltage_V x load_current_mA) /
                     (battery_voltage_V x regulator_efficiency)

Используйте измеренный КПД стабилизатора при предусмотренном токе нагрузки. Заявленный максимальный КПД редко показателен для часов, которые большую часть суток работают при малой нагрузке.

Проверка допущения о преобразовании питания¶

Столбец «Power-Conversion Efficiency (%)» в рабочей книге рассчитывается как load voltage / battery voltage. Последующая формула расхода заряда делит на этот коэффициент и на напряжение аккумулятора, поэтому напряжения сокращаются. Суточный расход заряда в итоге равен току нагрузки, умноженному на время: ток аккумулятора принимается равным току нагрузки. Это не расчёт идеального преобразования мощности. Такой подход похож на модель линейного стабилизатора без учёта тока покоя; для импульсного стабилизатора он не является универсальным.

Например, нагрузка с током 1 mA при 3,3 V, питаемая от аккумулятора 3,87 V через идеальный преобразователь, потребляла бы от аккумулятора примерно 0,853 mA, тогда как рабочая книга учитывает 1 mA. Для реального преобразователя результат зависит от КПД и тока покоя. Поэтому одно лишь это допущение не позволяет определить, оптимистична или консервативна оценка автономности. Ранжирование полезно для первичной проверки принятых токов и длительностей, но не заменяет окончательный расчёт расхода заряда аккумулятора. Для окончательного бюджета продукта замените вспомогательный коэффициент измеренным КПД каждой линии питания в соответствующем диапазоне нагрузок. Учтите ток покоя, не добавляя его повторно, если он уже включён в измерение, а также потери в защите аккумулятора и цепи питания от зарядного устройства.

Расчёт суточного расхода по использованию продукта¶

Один и тот же сценарий может давать незначительный вклад или определять основной расход — в зависимости от использования продукта. Для моделирования репрезентативного дня в рабочей книге включены следующие сценарии: базовое ожидание, уведомления, входящие вызовы, включение экрана при поднятии запястья, измерения пульса и SpO2, запись тренировки, будильники, мониторинг сна и синхронизация с приложением. NFC, звонки по Bluetooth и оба сценария AOD установлены в ноль и поэтому не входят в оценку автономности в 13,15 дня.

Пустые ячейки сценариев в исходной матрице оставлены намеренно. За каждой именованной строкой сценария идут нагрузки дисплея, вибромотора и Other. Они используют частоту и длительность из строки сценария выше, поэтому в источнике название указано только один раз.

Ранжирование сценариев лучше помогает выбрать действия, чем итоговое число дней автономности. Сначала проверяйте гипотезы оптимизации для самых крупных вкладов.

pie showData
    title Суточный расход заряда по включённым сценариям
    "Включение при поднятии запястья" : 4.9020
    "Уведомления" : 3.9996
    "Мониторинг сна" : 2.3040
    "Тренировка" : 2.1839
    "Ожидание" : 2.0679
    "Входящие вызовы" : 0.7999
    "Будильник" : 0.6910
    "Ручное измерение SpO2" : 0.3929
    "Автоматическое измерение пульса" : 0.2616
    "Синхронизация с приложением" : 0.0800

Два наиболее энергоёмких сценария взаимодействия с включённым экраном дают около половины суточного расхода заряда модели. Это проверяемый измерениями результат, а не общее утверждение, что дисплеи потребляют энергию. Прежде чем заниматься меньшими нагрузками, уточните реальное число включений при поднятии запястья, время работы экрана, яркость, порядок обновления изображения и политику уведомлений.

pie showData
    title Суточный расход по явно выделенным категориям
    "AMOLED-дисплей (9,56 mAh/сутки)" : 9.5595
    "MCU (4,62 mAh/сутки)" : 4.6163
    "Вибромотор (2,22 mAh/сутки)" : 2.2203
    "Прочие / неразделённые нагрузки (1,29 mAh/сутки)" : 1.2866

Последний сектор намеренно оставлен как Other / unallocated (прочие / неразделённые нагрузки). В рабочей книге нет отдельных значений со стороны аккумулятора для Bluetooth, акселерометра или гироскопа. Отключённый сценарий звонков по Bluetooth не означает нулевого потребления Bluetooth: синхронизация с приложением также может использовать радиоканал, но эта энергия отдельно не выделена. Аналогично, потребление датчиков может находиться в Other, однако предоставленные данные не позволяют разделить его между акселерометром и гироскопом.

Чтобы получить диаграмму с пятью категориями — MCU, дисплей, вибромотор, Bluetooth и объединённая категория акселерометра с гироскопом, — добавьте отдельные строки для ожидания и передачи по Bluetooth, режимов и долей времени работы акселерометра, а также режимов и долей времени работы гироскопа. Измерьте каждую строку на входе аккумулятора либо примените измеренный КПД стабилизатора, прежде чем добавлять её к суммарному значению mAh со стороны аккумулятора. Затем замените сектор Other / unallocated, а не добавляйте второй, пересекающийся сектор датчиков или Bluetooth.

Базовое потребление MCU, работа по сценариям и нагрузки датчиков¶

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

pie showData
    title Суточный расход заряда MCU по группам задач
    "Базовый режим ожидания" : 1.4854
    "Взаимодействие с включённым экраном" : 1.3013
    "Мониторинг сна" : 1.6640
    "Автоматическое измерение пульса" : 0.1656

Два сравнения помогают избежать ошибочного вывода:

• Базовая строка ожидания MCU и строки сценариев с включённым экраном: на базовое ожидание приходится 1,49 mAh/сутки — немного больше, чем 1,30 mAh/сутки, отнесённые к MCU во всех сценариях взаимодействия с включённым экраном. В этой модели снижение принятого базового тока столь же важно, как сокращение общей работы MCU в этих сценариях. Рабочая книга не выделяет энергозатраты на отрисовку графики отдельно.
• Базовая строка ожидания MCU и остальные явно указанные строки MCU: суммарно они дают 3,13 mAh/сутки, что в 2,11 раза больше базового ожидания. Самая большая отдельная строка вне базового ожидания — мониторинг сна: 1,66 mAh/сутки. Это отнесённая к сценарию нагрузка MCU, а не измерение только тока активного CPU.

В рабочей книге датчики не выделены в отдельную категорию. Их потребление может входить в Other, где также могут учитываться PMIC, радио, токи утечки и другие фоновые нагрузки. Всего эта категория даёт 1,29 mAh/сутки (7,28%). Даже если отнести весь расход Other к датчикам, явно выделенная категория MCU всё равно больше: 4,62 mAh/сутки против 1,29 mAh/сутки, то есть в 3,59 раза. Это сравнение категорий модели, а не прямое измерение кристалла MCU и датчиков. Реальную долю датчиков можно определить, только выделив их линии питания из общей категории Other.

От ранжирования к проектным решениям¶

Начинайте с наибольшего расчётного вклада и проверяйте порядок измерениями. Для этой модели разумна следующая последовательность:

1. Управление дисплеем: запишите полный профиль тока при включении экрана от поднятия запястья. Сначала уменьшайте ложные срабатывания, время включения, яркость, полную перерисовку экрана и ненужную анимацию, а уже затем добивайтесь снижения тока MCU на несколько микроампер.
2. Политика уведомлений: объединяйте несрочные уведомления, если это допустимо для пользовательского опыта. Проверьте, действительно ли каждое событие требует одновременно экрана и вибрации.
3. Ожидание с подключением: убедитесь, что после каждого события MCU входит в предусмотренный режим сна. Проверьте периодические таймеры, циклы опроса, обратные вызовы Bluetooth и запросы PM.
4. Вибросигналы: подбирайте амплитуду и длительность с помощью тестов восприятия. Более короткая или слабая вибрация может снизить расход энергии без ухудшения удобства использования уведомлений.
5. Длительная работа с датчиками: анализируйте мониторинг сна и запись тренировки как целые сценарии, включая долю времени работы датчиков, обработку данных, обращения к памяти и активность радио.

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

Проверка модели на оборудовании¶

Модель полезна, когда её регулярно уточняют по измерениям. Для каждой крупной нагрузки фиксируйте напряжение аккумулятора или источника питания, температуру, ревизию платы, версию прошивки, включённые радиоинтерфейсы, режим дисплея и диапазон измерения.

Как поддерживать достоверность модели¶

• Отключённые сценарии не включены в бюджет; это не означает отсутствия расхода энергии. Сейчас в рабочей книге для сценариев NFC, звонков по Bluetooth и AOD задан нулевой расход заряда.
• Разделяйте пользовательские функции и фоновую работу на отдельные сценарии. Это помогает явно обсуждать компромиссы при анализе продукта.
• По возможности измеряйте на входе от аккумулятора. Измерения отдельных линий питания тоже полезны, но перед расчётом автономности необходимо учесть потери стабилизатора и ток покоя.
• Меняйте по одному допущению и сравнивайте mAh за сутки, а не только мгновенный ток.
• Пересчитывайте профиль при изменении управления дисплеем, настроек Bluetooth, частоты измерений датчиков, политики управления питанием или существенной функции прошивки.

Основные выводы¶

• Автономность равна эффективной ёмкости аккумулятора, делённой на суточный расход заряда. Модель даёт 13,15 дня при доступных 232,5 mAh и расходе 17,68 mAh/сутки включённых нагрузок.
• В предоставленной базовой конфигурации в расходе преобладает поведение дисплея. Одни только включения экрана при поднятии запястья и уведомления о сообщениях дают около половины суточного расхода заряда.
• Ранжирование сценариев показывает, что измерять и оптимизировать сначала; оно полезнее единственного значения среднего тока.
• Прежде чем заявлять автономность продукта по прогнозу из рабочей книги, учтите реальный КПД преобразователя и ток покоя.
• Повторяйте цикл: моделируйте реальное использование, измеряйте основные сценарии, уточняйте допущения и затем оптимизируйте.

Последнее обновление: 2026-10-19