Vítejte, dnes je
středa
25.
prosinec 2024
Odborný časopis a portál zaměřený na vývoj a výrobu elektroniky 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:
Obr. 1 Napájecí pyramida
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:
Návrh ostatních částí systému okolo CPU musí být samozřejmě kompatibilní s použitím těchto funkcí.
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.
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.
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í).
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.
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:
Například:
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á.
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.
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:
Na příkladu medicínské aplikace můžeme zdokumentovat provozní body – viz obr. 2.
Obr. 2 SOC spotřeba proudu (mA) i.MX28 Board
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é.
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í.
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.
