Obliczenia poboru mocy w IoT

W słowniku obecnie modnych skrótów technologicznych, IoT czyli Internet Rzeczy (Internet of Things), zostało niedawno uzupełnione o IIot, czyli Przemysłowy Internet Rzeczy (Industrial Internet of Things). Jest to hasło spokrewnione z takimi określeniami, jak Przemysł 4.0 (Industry 4.0) i Inteligentne Fabryki (Smart Factory). Jedną z cech takiego nowego środowiska przemysłowego jest zastąpienie, lub uzupełnienie okablowania czujników i urządzeń gromadzących dane, komunikacją bezprzewodową. Czujniki będzie więc można swobodnie rozmieścić, gdzie tylko są potrzebne i będą one zasilane bateryjnie, wykorzystując tak niewiele mocy, by mogły pracować przez wiele lat bez potrzeby zajmowania się nimi.

Tak jak to bywa z wieloma innowacjami inżynieryjnymi, niektóre z aspektów tej koncepcji nie są tak nowe, jak mogłoby się wydawać. Idea bezprzewodowych sieci czujnikowych istniała od przynajmniej 20 lat. Podgrupa IEEE, pracująca nad personalnymi sieciami bezprzewodowymi zdefiniowała standard 802.15.4 w 2003 roku, a pierwsze wersje ZigBee – protokołu, na którym początkowo skoncentrowano uwagę – pojawiły się w 2004 roku. Od tego czasu opracowano wiele odmian komunikacji bezprzewodowej i wprowadzono dodatkowe funkcje, w efekcie czego obecnie projektanci mają wybór różnorodnych otwartych lub własnościowych protokołów. Łączność bezprzewodowa, o ile wciąż jest kluczowym czynnikiem umożliwiającym powstawanie niektórych rozwiązań, jest tylko jednym z punktów, gdzie należy podjąć ważne decyzje. Natomiast tym, co wpłynie na sposób wykonania całego projektu, jest zużycie mocy.

Tabela 1. Standardy bezprzewodowe IoT

Tabela 1. Standardy bezprzewodowe IoT

*Zużycie mocy jest podane w przybliżeniu, w oparciu o pobór energii modułów komunikacyjnych firm Texas Instruments, STMicroelectronics i Microchip przy napięciu zasilania równym 3 V.

Zaprojektowanie systemu zasilania dla takiego czujnika wiąże się z szeregiem wyzwań. Źródłem energii będzie najczęściej bateria lub akumulator, który także może stanowić zapasowe ogniwo. Można też wykorzystać dwuwarstwowy kondensator (superkondensator), lub jakąś kombinację tych źródeł. W tym ostatnim przypadku, energia potrzebna do ponownego naładowania ogniwa może pochodzić z otoczenia – najczęściej z panelu fotowoltaicznego. W dowolnym z tych przypadków, dostępna moc będzie ograniczona. Zapas energii zgromadzony w baterii pastylkowej lub paluszku AA będzie musiał wystarczyć na lata pracy, bez potrzeby wzywania technika, który wymieni ogniwo. Projekty IoT o małym poborze mocy działają przez lata, zamiast przez godziny, jak to bywa w przypadku innych urządzeń zasilanych bateryjnie.

W rzeczywistości, niektóre parametry gotowego urządzenia, wymienione w jego specyfikacji, a podlegające także pod gwarancję, nie mogą być w pełni przetestowane. Nikt nie może sobie pozwolić na uruchomienie prototypu na okres 10 lat, przed wprowadzeniem go na rynek. Dlatego obietnice 10-letniej żywotności baterii bazują w pewnej mierze na ekstrapolacji. Oznacza to też, że projektant będzie musiał zaufać pomiarom, obliczeniom i przewidywaniom, które pozwalają oszacować czas życia baterii.

Podstawowym elementem omawianych systemów IoT jest czujnik, który mierzy określone wartości ze świata rzeczywistego. Istotne są też pewne możliwości przetwarzania sygnałów i danych. W końcu znaczenie ma interfejs komunikacyjny, który pozwoli przekazać zmierzone dane dalej. Taki węzeł czujnikowy powinien wybudzać się co jakiś czas, nawiązywać łączność z nadrzędnym wobec niego kontrolerem, przekazywać dane i ponownie zapadać w stan uśpienia. Czas pracy na baterii jest zależny od łącznie pobranego ładunku. Minimalizacja tej konsumpcji w dłuższej perspektywie oznacza, że konieczna jest minimalizacja zużycia energii w trakcie każdego cyklu pracy. W wielu przypadkach czujnik będzie pracował tylko przez niewielki ułamek czasu. Pomiar, który trwa kilka milisekund może być wyzwalany raz na sekundę, raz na minutę czy nawet rzadziej. Dlatego moc zużywana w trybie uśpienia może zdominować łączny pobór energii.

Łączna moc zużywana w trakcie każdego cyklu pracy jest – co oczywiste – sumą mocy z każdej chwili tego cyklu. Zakładając stałe napięcie zasilania, moc ta będzie równa polu pod wykresem prądu pobieranego w czasie. Arytmetyka jest tu prosta, ale implikacje dla architektury projektu już niekoniecznie.

Uwaga naturalnie skupi się wokół zapotrzebowania na moc mikrokontrolera, który będzie stanowić serce takiego układu czujnikowego. MCU spędza – powiedzmy – 99% swojego czasu w stanie uśpienia, a więc im mniej mikroamperów pobieranych w tym stanie, tym lepiej. Mikrokontroler może oferować kilka stanów ograniczonego poboru mocy, a więc trybów głębszego lub mniej głębokiego uśpienia, które cechują się mniejszą lub większą liczbą aktywnych obwodów peryferyjnych. Czas wybudzania do normalnego trybu będzie zazwyczaj trwał dłużej, im głębszy był stan uśpienia i trzeba też uwzględnić moc zużywaną właśnie na wybudzanie. Głęboki stan uśpienia, mikrosekundy poświęcone na wybudzenie… w tym momencie projektant może poczuć, że potrzebny jest do tego arkusz kalkulacyjny.

Taki sposób rozumowania można zastosować do każdego bloku funkcjonalnego w każdym projekcie urządzenia IoT. Czy sensor można odczytać natychmiast po wybudzeniu, czy potrzebuje on czasu by się ustabilizować? A może potrzebne jest wzmocnienie i przefiltrowanie sygnału analogowego, zanim nastąpi konwersja na sygnał cyfrowy? Czy warto więc, sumarycznie rzecz ujmując, wyłączyć te elementy na okres trybu uśpienia? Jeśli tak, to czy czas potrzebny na ustabilizowanie się wzmacniaczy operacyjnych i innych mieści się w oknie wzbudzania mikrokontrolera, czy też należy go zaplanować oddzielnie? Jeśli bramkowanie napięcia do poszczególnych bloków ma sens, to może warto użyć układ scalony do zarządzania zasilaniem, który pozwoli szczegółowo kontrolować wybudzanie i usypianie? Ale wtedy przecież i on sam będzie ciągle pobierał choćby niewielki prąd.

Wracając do początku, wybrany interfejs komunikacyjny również będzie wpływał na zużycie mocy i będzie wiązał się z pewnymi ograniczeniami. Łącze radiowe będzie wymagało czasu i określonej mocy by nawiązać połączenie, zanim jakiekolwiek dane zostaną przesłane.

W obliczeniach należy uwzględnić też baterie i akumulatory. Pierwszym wymogiem jest by ogniwa były w stanie dostarczyć maksymalną moc, jaka będzie potrzebna w aplikacji. Następnie należy oszacować średnie zużycie mocy i ekstrapolować je by obliczyć przewidywany czas życia oraz potrzebną pojemność akumulatora. Popularne baterie CR2032 mają pojemność nominalną na poziomie 210-220 mAh. Jeśli mikrokontroler ma pracować w trybie uśpienia przez 10 lat, musiałbym pobierać 3 µA (220 mAh / 87600 godzin) lub mniej. Ta prosta kalkulacja nie bierze pod uwagę samorozładowania się. Przykładowo firma Energizer informuje, że jej baterie CR2032 rozładowują się w tempie 1% na rok. Ponadto nominalna pojemność jest podawana przy określonym obciążeniu: 240 mAh przy 15 kΩ i napięciu 2 V (lub 200 µA gdy bateria jest nowa). Rzeczywista pojemność będzie więc różna, przy czym zazwyczaj maleje jeśli pobierany prąd jest większy. Jedną z dziedzin, w której następuje poprawa jest dopuszczalna długość przechowywania baterii. Obecnie markowe ogniwa alkaliczne lub Li-MnO2 są sprzedawane nawet jako „przechowujące energię na 10 lat pracy”. W przeszłości trudno było znaleźć jakiekolwiek baterie, które w ogóle gwarantowały że będą używalne po 10 latach od zakupu.

Tabela 2. Przechowywanie energii

Tabela 2. Przechowywanie energii

Podobnie, choć stosowanie techniki energy harvestingu wraz z jakimś sposobem gromadzenia energii może zmniejszyć wymóg ograniczenia zużycia mocy, konieczność pracy urządzenia przez dekadę oznacza też, że ogniwa akumulatorów stracą część swojej pojemności. Do szacunków odnośnie pojemności ogniw po dłuższym czasie należy podchodzić bardzo ostrożnie, gdyż możliwe że będą one pracować w wymagających warunkach – tj. np. w niskich temperaturach.

Pomimo zaplanowania długiego czasu pracy na baterii, urządzenie IoT powinno zostać tak zaprojektowane, by pozwoliło poinformować swój kontroler o zbliżającym się niedoborze energii. Jeśli wśród wbudowanych obwodów analogowych pozostał wolny jakiś komparator lub wzmacniacz operacyjny, można go wykorzystać do detekcji spadku napięcia zasilania poniżej określonego poziomu. Można też, poświęcając na to kilka dodatkowych cykli procesora, przeliczać takie dane za pomocą konwertera A/C. W obu przypadkach chodzi o znalezienie takiego momentu, który pozwoli jeszcze na przesłanie odpowiedniej wiadomości do operatora.

Jednakże to na obliczeniach zużycia mocy przez mikrokontroler można najwięcej zyskać. Kluczowe parametry, które powinny wpłynąć na wybór podzespołu obejmują pobór mocy przez MCU, wyrażony w µA/MHz, odpowiedni zestaw obwodów peryferyjnych, a wśród nich przede wszystkim przetwornik analogowo-cyfrowy o odpowiednich cechach. Ważna jest też złożoność kodu, a więc liczba cykli potrzebnych do wykonania operacji od momentu wybudzenia procesora do jego ponownego uśpienia.

Wybór mikrokontrolera

Jedną z podstawowych decyzji do podjęcia będzie wybór architektury 8-, 16-, lub 32-bitowej. Sięgnięcie po 8-bitowy model będzie w wielu przypadkach skutkowało najmniejszym poborem prądu w trybie aktywnym. Przykładowo, przeglądając ofertę mikrokontrolerów PIC firmy Microchip, znaleźć można 8-bitowe układy PIC18F „K42” XLP, które pobierają 45 µA/MHz w trybie aktywnej pracy i mogą być taktowane z częstotliwością do 64 MHz (https://www.farnell.com/datasheets/2297480.pdf). Tymczasem 16-bitowy układ PIC24FJ256GA412/GB412 pobiera już 160 µA/MHz, podczas gdy 32-bitowy PIC32MX wymaga 250 µA/MHz. Tak jak się można było spodziewać, wraz z większą mocą idzie większa wydajność. Nawet w 8-bitowym modelu istnieje dużo opcji, którymi można obniżyć pobór mocy, np. poprzez wykorzystanie trzech oddzielnych trybów uśpienia rdzenia i dzięki różnym cechom XLP (eXtreme Low Power), które definiują m.in. parametry timera i oscylatora. Na liście obwodów peryferyjnych, zaraz po 12-bitowym przetworniku analogowo-cyfrowym, znajdują się cztery konfigurowalne komórki logiczne, które pozwalają zaimplementować proste kombinacyjne, lub sekwencyjne funkcje logiczne. Ten wydawałoby się, że mało znaczący dodatek może pozwolić zrezygnować z dodatkowego komponentu i wykonywać pewne operacje logiczne bez konieczności wzbudzania, lub przed wybudzeniem rdzenia.

Mikrokontroler o większej liczbie bitów w rejestrach może być preferowany np. gdy dane pochodzące z czujnika mają wysoką dokładność i konieczne jest stosowanie cyfrowych filtrów. To może spowodować znaczny wzrost potrzebnych cykli procesora w mniejszym rdzeniu, a więc oznacza że bardziej wydajny mikrokontroler umożliwi szybsze wykonanie obliczeń i ponowne przejście w stan uśpienia.

Microchip oferuje także 32-bitowe układy SAML21/22 32-bit (rdzeń ARM Cortex-M0+, pochodzący z oferty przejętej niedawno firmy Atmel, pracujący z zegarem do 48 MHz), które pobierają jedynie 32 µA/MHz. Jeśli więc takie podzespoły spełniają wymogi danej aplikacji (mają mniejszą maksymalną wydajność niż PIC32MX), wtedy i one mogą stanowić dobry wybór, szczególnie gdy zespół projektancki ma już doświadczenie w pracy z rdzeniami ARM.

Firma Texas Instruments ma duże doświadczenie w produkcji mikrokontrolerów o bardzo małym poborze mocy, w ramach serii MSP430 i kontynuuje jej rozwijanie. Możliwość „dostrojenia” aplikacji pod kątem zużycia mocy została zilustrowana cechami układów MSP430FG662x i MSP430FG642x, które obsługują nie tylko tryb aktywny. W trybie lekkiego uśpienia (standby) pamięć RAM jest podtrzymywana i system może szybo się wybudzić. W trybie uśpienia z zegarem czasu rzeczywistego (shutdown with RTC), pobór jest jeszcze mniejszy, a najmniejszy w trybie głębokiego uśpienia (shutdown), gdzie zegar już nie działa.

Przy napięciu 3 V, w trybie aktywnym układ pobiera 250 µA/MHz (i może pracować z taktowaniem do 20 MHz, co daje pobór mocy równy 5 mA). W trybie lekkiego uśpienia pobierane jest 3,4 µA, a w trybach zwykłego i głębokiego uśpienia jest to 0,9 µA i 0,2 µA, odpowiednio. Najbardziej dramatyczna zmiana następuje przy przejściu z trybu aktywnego do lekkiego uśpienia, gdy pobór mocy spada kilkaset razy. Jednakże różnica pomiędzy trybem lekkiego a zwykłego uśpienia jest bardzo ważna. Z jednego punktu widzenia jest to dalsze, niemal 4-krotne ograniczenie poboru mocy, ale równocześnie pracuje wbudowany zegar RTC, który może wybudzić procesor gdy jest to potrzebne. W dokumentacji podany jest także czas potrzebny na wybudzenie układu z trybu lekkiego uśpienia i w tym przypadku wynosi on 3 µs. W czasie tym mikrokontroler będzie pracował pobierając prąd na tym samym poziomie, co w przypadku trybu aktywnego. Wybudzanie tego samego układu (‘662x) z trybu uśpienia zajmuje już 2 ms, a nie 3 µs. Stąd obliczenia projektanta powinny odpowiednio porównać czas spędzony w uśpieniu z dodatkową mocą potrzebną do wybudzenia układu, by ocenić czy głębsze usypianie jest warte uwagi.

Przykład obliczeń czasu pracy na baterii w przypadku aplikacji IoT

Ilustracja 1.: Przykład obliczeń czasu pracy na baterii w przypadku aplikacji IoT

W powyższych akapitach założono, że skoro przewidywane jest zastosowanie komunikacji bezprzewodowej, wtedy samodzielne radiowe moduły lub układy scalone będą stanowiły elementy projektu. One również będą miały własne dokumentacje, w których podane zostaną informacje o czasie wybudzania oraz poborze mocy i prądu, zużywanych w trakcie pracy w trybie aktywnym. Należy je uwzględnić w całkowitym budżecie mocy, w odniesieniu do czasu gdy będą włączone. Farnell oferuje szeroki wybór modułów do sieci ZigBee, własnościowych sieci zgodnych z IEEE 802.15.4 i dla innych standardów. Do pokazania zużycia mocy na jednym z przykładów może posłużyć moduł Silicon Labs ETRX35x-LRS . Bazuje on na pojedynczym układzie scalonym, który budzi się z głębokiego uśpienia w 100 µs, zużywa około 30 mA gdy pracuje jako odbiornik i 50 – 140 mA w trakcie transmisji, zależnie od mocy wyjściowej. Z danych tych jednoznacznie wynika, że minimalizacja czasu komunikacji radiowej (szczególnie transmisji) jest kluczowa dla całkowitego budżetu mocy.

Kalkulator mocy IoT

Ilustracja 2.: Kalkulator mocy IoT

Innym sposobem realizacji projektu jest wykorzystanie pojedynczego mikrokontrolera ze zintegrowanymi obwodami radiowymi, gdzie MCU ma wystarczające możliwości by prowadzić zarówno pomiary, przetwarzać kod aplikacji, jak i obsługiwać stos komunikacyjny. Przykładem może być produkowany przez NXP bezprzewodowy mikrokontroler JN5179 , wspierający ZigBee i IEEE802.15.4. Ma on wbudowane 512 kB pamięci Flash i 32 kB RAM. Układ ten bazuje na rdzeniu ARM Cortex-M3 i ma programowalny zegar oraz transceiver radiowy, który może działać jako uniwersalne łącze, lub zgodnie z protokołem ZigBee. Układ radiowy w tym przypadku jest w stanie obniżyć swój pobór mocy do 100 nA. Mikrokontroler ma ponadto 10-bitowy przetwornik analogowo-cyfrowy i pozwala m.in. na monitorowanie napięcia akumulatora.

Istnieją także inne sposoby zaplanowania obsługi komunikacji radiowej, które będą narzucać własne wymagania odnośnie zużycia mocy. Przykładowo, jeśli w danym obszarze już teraz dostępne jest pokrycie sieci Wi-Fi (IEEE 802.11b/g/n), to może ono posłużyć jako wygodny sposób na zbieranie danych, ale kosztem zwiększonego poboru mocy. Widać to na przykładzie innego układu marki Silicon Labs, korzystającego ze scalaków Gecko (wciąż z rdzeniem ARM Cortex-M3) - WGM110 . Dokumentacja produktu informuje, że prąd pobierany w trakcie transmisji wynosi 261 mA, w trakcie odbioru spada do 8 mA, w trakcie bezczynności wynosi 2,2 mA, a w głębokim uśpieniu to jedynie 22 µA. W innym środowisku, gdzie potrzebny jest duży zasięg, stosownym może być sięgnięcie po standard LoRa

Jak pokazano powyżej, dobry podział systemu może być kluczem do osiągnięcia założonych celów odnośnie czasu pracy na baterii. Jest to prawdą także w obrębie układu samego sensora. W niektórych systemach można korzystać z analogowego czujnika temperatury, takiego jak Texas Instruments LMT84-Q1 . Wymaga on napięcia 1,5 V i daje około 10 µA prądu na wyjściu analogowym. Urządzenie to pobiera bardzo mało prądu - jedynie 8,1 µA. Musi zostać odpytane przez mikrokontroler, a analogowy odczyt następnie należy przetworzyć na dane cyfrowe za pomocą przetwornika wbudowanego w MCU, co zwiększa sumaryczny pobór prądu w trybie aktywnym. Korzystając z cyfrowego czujnika temperatury (również od TI), takiego jak TMP102 , nie będzie trzeba stosować przetwornika A/C w MCU, a ponadto sensor sam będzie mógł monitorować temperaturę i przesyłać alarm wzbudzający mikrokontroler w momencie, gdy ta przekroczy zadany zakres. To pozwala znacząco zmniejszyć pobór mocy, pozwalając procesorowi na pozostanie w trybie uśpienia przez dłuższy czas, jednocześnie stale monitorując temperaturę.

Jeśli projektant preferuje precyzyjne sterowanie poborem mocy, przydatny będzie układ zarządzania mocą (PMIC). Podzespoły tego typu są dostępne w różnorodnych odmianach u wielu producentów. Jednym z przykładów, użytecznym w przypadku zasilania bateryjnego urządzeń mających pracować przez długi czas jest produkowany przez Maxim Integrated MAX14720 . Świetnie się sprawdza w pracy z bateriami pastylkowymi lub alkalicznymi, gdzie rozmiar i skuteczność energetyczna są krytyczne. Zawiera w sobie pięć oddzielnych obwodów: przełącznik mocy, regulator liniowy, regulator obniżający, regulator obniżająco-podwyższający oraz układ monitorowania. Programowalny sterownik mocy można skonfigurować tak, by pracował w urządzeniu, które faktycznie ma mieć odcięte zasilanie, albo w urządzeniu, które jest ciągle włączone. Sterownik pozwala przesyłać sygnał resetu z opóźnieniem, podawać napięcia w sekwencji, monitorować naciśnięcia przycisków, by rozpoznawać różne akcje odnośnie włączenia czy wyłączenia urządzenia oraz wspiera restart systemu po jego twardym resecie.

Dodatkową funkcją jest odseparowanie baterii, które zaimplementowane elektronicznie, w pełni odłącza ogniwo zanim urządzenie zostanie faktycznie zainstalowane. Dzięki temu możliwe jest dostarczanie produktów od razu z bateriami. W ten sposób producent może mieć pewność, że użyta bateria będzie miała odpowiednio dobre parametry i zapewni przewidywany czas pracy.

Obliczenia poboru mocy w IoT. Data publikacji: 15 marca 2018 r. przez Farnell element14