česky english Vítejte, dnes je středa 26. leden 2022

Řízení napájení v embedded systémech

DPS 1/2014 | Vývoj - články
Autor: Colin Walls, Mentor Graphics

Pro stále větší počet embedded systémů je spotřeba energie kritickým faktorem, který je třeba vzít v úvahu již při jejich návrhu. I když se primárně jedná o „hardwarový problém“, stále více se týká také vývoje softwaru.

Rostoucí požadavky na možnosti připojení, především bezdrátového, přinášejí také zvýšené požadavky na nízkou spotřebu embedded zařízení. Běžně se optimalizace napájení řešila v celém procesu návrhu poměrně pozdě (např. když už bylo zařízení hotové a ukázalo se, že má příliš velkou spotřebu). Takový přístup je však v současnosti nedostatečný a otázka napájení se musí řešit od samého začátku projektu.

Základní podmínkou je vybrat si hardware, který umí šetřit energii. Především se jedná o vlastnosti, které je možné řídit softwarově, s čímž na druhé straně souvisí také volba operačního systému a ovladačů zařízení. Je nutné definovat napájecí profily související jednak s funkcionalitou zařízení, jednak s tím, co se od zařízení v daný okamžik očekává. To nám umožňuje stanovit měřitelné cíle a ty aplikovat v celém vývojovém procesu.

Obr. 1 ilustruje klíčové faktory, které ovlivňují spotřebu energie:

  • volba správného hardwaru
  • využití zařízení
  • volba operačního systému
  • problematika ovladačů
  • aplikační kód (má na spotřebu nejmenší přímý vliv)

Řízení napájení v embedded systémech 1

Obr. 1 Napájecí pyramida

Volba hardwaru

I když jsme naznačili, že spotřeba energie je také záležitostí softwaru, největší vliv na napájení má hardware, protože nabízí nejvíce možností pro úsporu energie. Napájení je ovlivněno těmito vlastnostmi CPU:

  • Schopnost vypínat určité bloky, např. periferie, v okamžiku, kdy nejsou potřeba.
  • Podpora tzv. „Dynamic Voltage and Frequency Scaling (DVFS)“ – umožňuje softwarově upravit výkon CPU nastavením hodinové frekvence a napájecího napětí. To vede k definování provozních bodů, což jsou konkrétní hodnoty napětí/frekvence.
  • Dostupnost režimů s nízkou spotřebou.

Návrh ostatních částí systému okolo CPU musí být samozřejmě kompatibilní s použitím těchto funkcí.

Využití zařízení

Prvním krokem při návrhu embedded softwaru zaměřeného na spotřebu je definovat možnosti využití zařízení. Ty odpovídají konkrétním funkcím, které zařízení provádí. Tyto funkce mohou nebo nemusí zahrnovat interakci uživatele. K ilustraci tohoto konceptu použijeme hypotetický příklad: přenosné, bateriově napájené zařízení pro lékařské účely, které monitoruje vitální funkce pacienta. Údaje mohou být zobrazovány na displeji přístroje a posílány přes Wi-Fi do počítače v nemocnici.

V tomto příkladu lze definovat tyto případy využití:

1) Zařízení provádí kompletní měření.

2) Zařízení posílá sadu naměřených dat.

3) Uživatel si kontroluje vlastní naměřené údaje na zabudovaném displeji.

4) Zařízení je v nečinném stavu a čeká na další měření.

Pokud se podíváme na případy využití a spotřeby, potom můžeme určit funkcionalitu potřebnou pro každý případ. Ty nám jasně řeknou, které ovladače, nebo spíše hardwarové bloky, budou zapnuty pro každý konkrétní případ. Spotřebu energie pro každý případ využití můžeme vypočítat na základě očekávané spotřeby a očekávané délky doby potřebné pro provedení daného případu. Při vynásobení očekávaným opakováním za den dostaneme spotřebu, a tím využití kapacity baterie v závislosti na čase viz – tabulka 1.

Řízení napájení v embedded systémech tabulka

V tomto příkladu tedy zařízení spotřebuje 137 mAh/den. Porovnejte tento údaj s kapacitou baterie (v mAh) a výsledkem je předpokládaná životnost baterie.

Optimalizace případů využití

V tomto příkladu vidíme dvě zřejmé možnosti pro další optimalizaci: přenos dat a kontrolu dat uživatelem.

Přenos dat spotřebovává většinu energie. Aktuálně je přenos dat prováděn v pětiminutových intervalech po dokončení každého měření. Přenos dat by se mohl provádět hromadně za 6 měření každých 30 minut. Přenos může být také samozřejmě iniciován náhlou změnou některého vitálního znaku. Displej pro zobrazení dat je druhým energeticky nejnáročnějším aspektem. Aktuálně jsou data na displeji zobrazena po dobu 30 sekund. Vzhledem k tomu, že většina ostatního hardwaru je přitom vypnutá, je jasné, že sem by se měla soustředit optimalizace (kratší čas zobrazení by mohl být dostačující).

Operační systém

Jelikož operační systém tvoří nejnižší vrstvu softwaru, která je nejblíže hardwaru, má přirozeně největší vliv na úspory energie. Proto má volba operačního systému největší vliv na energetickou účinnost návrhu. Od operačního systému očekáváme, že bude rychlý a dokáže efektivně využívat paměť. V případě energeticky optimalizovaných systémů je klíčovým požadavkem na operační systém, aby podporoval speciální funkce pro nízkou spotřebu, především dynamickou změnu napájecího napětí a frekvence (Dynamic Voltage and Frequency Scaling – DVFS) a režim bez zátěže a spánku CPU. Nejlepším návrhem pro OS použitý v tomto kontextu je normální napájecí rámec. Tato funkce odděluje problematiku napájení od jádra aplikačního kódu. BSP popisuje problematiku napájení a každý ovladač má dobře definované napájecí stavy.

BSP a ovladače

Pokud má OS napájecí rámec, můžeme specifikovat napájecí požadavky každého ovladače. Je třeba si vyjasnit tyto záležitosti:

  • Jaké napájecí stavy jsou podporovány: ON, STANDBY, SLEEP, OFF?
  • V kterých provozních bodech (kombinace napájecího napětí a taktovací frekvence CPU) bude ovladač použit?

Například:

  • Při stavu ON může být vyžadován provoz jak na 200 MHz, tak 100 MHz.
  • Při SLEEP může být frekvence snížena na 1 MHz a to by mělo být tolerováno.
  • Spolupráce s DVFS.
  • Vyrozumění OS o požadavcích na DMA přenos, protože ten může být nepříznivě ovlivněn úspornými režimy.

Hibernace/úspora

Mnoho embedded CPU má speciální režimy, které v klidovém stavu snižují spotřebu na minimum. Terminologie není standardizovaná, ale tyto stavy se obvykle nazývají Suspend (úsporný) a Hibernate (hibernace).

Úsporný režim je takový, kdy je veškerý hardware odpojen od napájení, kromě paměti RAM, která je uvedena do samoobnovovacího režimu a její obsah je chráněn. V tomto režimu je spotřeba energie významně snížena.

Režim hibernace je takový, kdy je obsah paměti RAM zkopírován do energeticky nezávislého úložiště a všechno je vypnuto. V tomto režimu může být spotřeba energie snížena téměř na nulu.

Za použití těchto režimů ale platíme cenu ve formě energie a času (rychlost reakce zařízení). Výše této ceny závisí na několika faktorech, ale energie potřebná pro přechod systému ze stavu ON do úsporného režimu nebo režimu spánku je značná. Stav systému musí být uložen a množství dat může být různé, opětovná inicializace periferií zase stojí čas. Při režimu spánku se spotřebovává také energie na uložení obsahu paměti RAM. Pokud má nevolatilní paměť omezený počet zápisů, může při neuváženém používání režimu spánku dojít ke zkrácení životnosti zařízení.

Proto je třeba si vždy klást otázku, zda energetické výhody úsporného režimu a režimu spánku vyváží jejich „cenu“. U zmíněného medicínského zařízení může tato cena záviset na intervalu měření a také na tom, jak často potřebujeme zařízení probudit. Podle nastavení měřicího intervalu může být pak cena za režim úspory/spánku buď efektivní, nebo drahá.

Vývoj aplikace

Aplikační kód je poslední vrstva softwaru v embedded systému. To znamená, že se jedná o poslední možnost pro optimalizaci napájení v aplikačním kódu. Je to ovšem také možnost, jak špatným kódem nepříznivě ovlivnit energetickou účinnost zařízení. OS se zabudovanými napájecími funkcemi (napájecí rámec) celou věc zjednodušuje, protože programátor se nemusí tolik soustředit na jemné detaily. S operačním systémem je aplikace tvořena mnoha nezávislými úlohami. Při použití rámce pro správu napájení má každá úloha zaregistrovanou svoji napájecí potřebu: které periferie se použijí (a které se vypnou) a minimální provozní bod (poskytnutí parametrů pro DVFS). OS se potom postará o řízení napájení společně s kontextovým přepínačem.

Měření a testování

Spotřeba by měla být měřena během celého vývojového procesu, a to hned od jeho začátku. Toho lze dosáhnout pečlivým plánováním: stanovením napájecích požadavků pro ovladače, definováním případů použití a jejich mapováním do aplikačního kódu. Při vyhodnocení, zda software splňuje požadovanou specifikaci, se normálně zaměřujeme na to, zda odpovídají požadavky na velikost a rychlost. Požadavky na napájení jsou ale stejně důležité. Softwaroví návrháři by to měli mít na paměti a spotřebu měřit. Především u ovladačů je nutné pečlivě testovat jejich napájecí funkcionalitu:

  • Správné zapínání/vypínání hardwaru
  • Spolupráce s DVFS
  • Vyrozumění OS o aktivitě DMA

Spotřeba a různé provozní body

Na příkladu medicínské aplikace můžeme zdokumentovat provozní body – viz obr. 2.

Řízení napájení v embedded systémech 2

Obr. 2 SOC spotřeba proudu (mA) i.MX28 Board

Dopad na životnost baterie

Při předpokládané době trvání každého provozního bodu můžeme odhadnout celkovou spotřebu zařízení. V našem příkladě to je 126 mAh. To se rovná 19 hodinám provozu na baterii, což by mělo být přijatelné. Pokud by nebylo implementováno žádné řízení napájení, zařízení by po celou dobu pracovalo v provozním režimu č. 3. To představuje spotřebu 470 mAh. Taková spotřeba odpovídá 5 hodinám provozu na baterii, což by nebylo praktické.

Konečná optimalizace

Při použití postupů popsaných v tomto článku bychom měli dosáhnout energetické účinnosti v rámci specifikací pro embedded návrhy. Existuje zde však stále prostor pro další optimalizaci. Když je implementace dokončena (nebo je před dokončením), je potřeba provést konečnou revizi případů použití na základě zkušeností s tímto zařízením. Zde může být prostor k úpravě provozních parametrů nebo dokonce k definování nových případů použití.

Závěr

Napájení bude stále důležitějším faktorem pro návrháře embedded systémů. Pryč je doba, kdy to byla záležitost jen hardwaru. Zásadní je podpora napájecích funkcí hardwaru pomocí operačního systému. Avšak nejdůležitějším pravidlem pro návrh nízkoenergetických aplikací je plánovat napájení předem a nečekat s jeho optimalizací až na závěr.

Partneři

eipc
epci
imaps
ryston-logo-RGB-web
mikrozone
mcu
projectik