Virran- ja akunhallinta taktisille päätelaitteille

Akunkesto on tehtävärajoite, ei käyttäjäkokemuksen mittari. Kun ATAK:ia ja anturien integrointilisäosia ajava taktinen päätelaite (EUD) putoaa nollalataukseen kahdentoista tunnin partion yhdeksännellä tunnilla, seuraus ei ole ärtynyt käyttäjä – se on sotilas, joka on menettänyt samanaikaisesti blue-force-seurannan, sijaintiraportoinnin ja digitaalisen viestinnän. Taktisten sovellusten virranhallinta on siksi järjestelmäsuunnitteluongelma, joka vaatii samaa tarkkuutta kuin viivebudjetit, salauksen vaatimustenmukaisuus ja offline-first-arkkitehtuuri. Tämä artikkeli tarkastelee, miten lähestyä tätä ongelmaa: peruskulutuksen mittaamisesta ja komponenttitason budjettien asettamisesta GPS:n ja radion optimoinnin kautta lämpöhallintaan ja porrastettuihin rajoitettuihin käyttötiloihin matalan akun kenttäolosuhteissa.

Virtabudjetti: tehtäväkeston muuntaminen suunnitteluvaatimuksiksi

Tehtäväkesto määrittelee virtabudjetin. Jos operatiivinen vaatimus on 12 tuntia jatkuvaa EUD-käyttöä yhdellä latauksella, ja laitteessa on 4 000 mAh:n litiumioniakku 3,7 V:n nimellisjännitteellä (14,8 Wh käytettävissä olettaen 90 %:n purkaussyvyys), suurin sallittu keskimääräinen järjestelmäkulutus on noin 333 mA. Tämä ei ole sovelluskohtainen rajoite – se on koko järjestelmän budjetti, joka jaetaan näytön, SoC:n, GPS-alijärjestelmän, solukko- tai MANET-radion ja kaikkien käynnissä olevien sovellusten ja käyttöjärjestelmäpalvelujen kesken.

Sovelluskehittäjän vastuulla on ymmärtää, kuinka suuren osan tuosta 333 mA:sta heidän sovelluksensa kuluttaa koko operatiivisten skenaarioiden kirjossa: etualan navigointi aktiivisella karttarenderöinnillä; taustasijaintiraportointi laitteen ollessa rintaliivissä näyttö sammuksissa; purskemainen aktiivisuus tulitehtävän tai kontaktiraportin aikana. Jokaisella skenaariolla on erilainen kulutusprofiili, ja pahin tapaus määrittelee keston alarajan.

Komponenttikohtainen jako

Käytännöllinen jako ruggeroidulle Android-EUD:lle taktisessa käytössä voisi näyttää tältä: näytön taustavalo mukautuvalla kirkkaudella kuluttaa 60–100 mA ympäristön valosta riippuen; GPS-alijärjestelmä 1 Hz:n jatkuvalla taajuudella kuluttaa 20–35 mA; radio (LTE-modeemi tai MANET-radioliitäntä) jaksoittaisessa synkronointitilassa kuluttaa 60–100 mA merkittävine huippuineen lähetyspurskeiden aikana; SoC kohtuullisella CPU-kuormalla kuluttaa 60–90 mA; käyttöjärjestelmäpalvelut ja anturit kuluttavat yhdessä 20–40 mA peruskulutuksen. ATAK:ia aktiivisten lisäosien kanssa ajava sovelluspino istuu tämän päällä – vaikuttaen samanaikaisesti CPU:hun, GPS-kyselytaajuuteen ja radion herätystapahtumiin. Huonosti optimoitu lisäosakokonaisuus voi lisätä 50–100 mA kuormaa kuhunkin näistä kolmesta komponentista, romahduttaen 12 tunnin budjetin 6–7 tuntiin ennen ensimmäistä latauspistettä.

Mittaa ennen optimointia: virrankulutuksen profilointiperustaso

Optimointi ilman mittausta on arvailua. Ensimmäinen vaihe missä tahansa virrankulutuksen vähentämispyrkimyksessä on mitatun perustason luominen edustavan operatiivisen skenaarion kautta. Android Studion Energy Profiler tarjoaa CPU-wakelock-jälkiä, työn aikataulutusaktiivisuutta ja luokitellun virta-arvion, joka on hyödyllinen sen tunnistamiseen, mikä komponenttiluokka dominoi. Laitteistotarkkaan mittaukseen laturin ja laitteen väliin asetettu USB-virtamonitori tallentaa todellisen virrankulutuksen – Energy Profilerin arvot ovat mallinnettuja estimaatteja, jotka voivat poiketa mitatusta laitteistosta 15–30 %.

Perustasoskenaarion tulisi jäljitellä todellista kenttäkäyttöä: laite kannettuna rintaliivissä näyttö sammuksissa 40 minuuttia, jota seuraa 10 minuuttia aktiivista karttanavigointia, jota seuraa purske CoT-viestien lähetystä, jota seuraa toinen passiivisen kantamisen jakso. Tämän 60 minuutin syklin ajaminen kolmesti tuottaa edustavan keskikulutuksen, jota voidaan verrata kestobudjettiin. Pelkän aktiivikäyttötapauksen profilointi yliarvioi keskikulutuksen; pelkän näyttö sammuksissa -tapauksen profilointi aliarvioi sen.

Suurimpien kuluttajien tunnistaminen

Useimmissa taktisten sovellusten käyttöönotoissa kolme dominoivaa virrankuluttajaa ovat: (1) radio-alijärjestelmä, jota ohjaavat synkronointikyselyn taajuus ja keep-alive-käyttäytyminen; (2) GPS, jota ohjaavat päivitystaajuus ja se, käyttääkö sovellus FusedLocationProvideria vai raakaa GPS-laitteistoa suoraan; ja (3) taustapalvelujen pitämät CPU-wakelockit. Näytön taustavalo on merkittävä mutta on suurelta osin sovelluksen hallinnan ulkopuolella – käyttöjärjestelmä hallitsee näytön aikakatkaisua ja mukautuvaa kirkkautta. Radion, GPS:n ja wakelock-profiilin optimointi on se, missä sovellustason työ tuottaa suurimmat tuotot.

GPS-optimointi: liiketunnistava kysely

Jatkuva GPS 1 Hz:llä on harvoin tarpeen operaattorille, joka on ollut paikallaan tarkkailuasemassa 45 minuuttia. SoC:n GPS-moottori kuluttaa 20–35 mA aktiivisesti hankkiessaan ja seuratessaan satelliitteja; pulssitetussa tilassa 10 sekunnin päivitysvälillä vastaava kulutus laskee 2–5 mA:iin. Ero jatkuvan ja pulssitetun GPS:n välillä on suurin yksittäinen sovelluksen hallittavissa oleva optimointi useimmilla Android-EUD:illa.

Vakiototeutus käyttää laitteen kiihtyvyysanturia matalan tehon tilassa (5 Hz näytteistys, mitätön kulutus) paikallaanolojaksojen havaitsemiseen. Kun kiihtyvyyden suuruus pysyy kynnyksen alapuolella (tyypillisesti 0,3 m/s²) 30 peräkkäisen sekunnin ajan, sovellus vaihtaa GPS:n alennettuun päivitystaajuuteen – 0,1 Hz, yksi paikannus joka 10. sekunti. Kun liike havaitaan (kiihtyvyyspiikki yli 1,0 m/s²), taajuus palaa 1 Hz:iin yhdessä sekunnissa. Tämä liiketunnistava lähestymistapa on operatiivisesti läpinäkyvä: operaattorin näytetty sijainti päivittyy täydellä taajuudella liikkeen aikana eikä uhraa mitään staattisten pysähdysten aikana, samalla kun se palauttaa 15–25 % akun kokonaiskapasiteetista tyypillisissä partioi-ja-tarkkaile-tehtäväprofiileissa.

Androidin FusedLocationProvideria (FLPP) käyttävissä sovelluksissa PRIORITY_BALANCED_POWER_ACCURACY:n asettaminen PRIORITY_HIGH_ACCURACY:n sijaan staattisten jaksojen aikana antaa käyttöjärjestelmän käyttää matkapuhelinverkon tukiasemien ja Wi-Fin kolmiomittausta karkean sijaintipaikannuksen ylläpitämiseen – riittävä blue-force-seurannan tarkoituksiin – pitämättä GPS-moottoria lainkaan aktiivisena. Ruggeroidun laitepinon tulisi olla validoitu vahvistamaan, että FLPP palaa siististi GPS:ään GNSS-only-ympäristöissä, joissa matkapuhelinverkon tukiasemat ja Wi-Fi eivät ole käytettävissä, mikä on normaali olosuhde monille taktisille käyttöönotoille.

Radion ja synkronoinnin optimointi

Radio-alijärjestelmä on usein taktisen EUD:n suurin yksittäinen virrankuluttaja. Joka kerta, kun sovellus käynnistää verkkotapahtuman – CoT-sijaintiraportin, synkronointitarkistuksen, karttalaatan noudon – radio herää matalan tehon lepotilasta, lähettää tai vastaanottaa, ja siirtyy sitten häntäaikajaksoon (tyypillisesti 5–20 sekuntia LTE:llä), jonka aikana se pysyy aktiivisena odottaen lisäliikennettä ennen lepoon palaamista. Sovellus, joka tekee 30 pientä verkkopyyntöä minuutissa, pitää radion jatkuvasti aktiivisena. Sovellus, joka niputtaa saman datan kahteen suurempaan lähetykseen, antaa radion levätä suurimman osan kustakin minuutista.

CoT-sijaintiraporttien niputus on vaikuttavin radio-optimointi ATAK-pohjaisille sovelluksille. Sen sijaan, että lähettäisi jokaisen GPS-paikannuksen erillisenä UDP-multicastina välittömästi, sovellus puskuroi sijaintiraportit paikalliseen jonoon ja tyhjentää jonon 30–60 sekunnin välein. Tyypillisellä partiolla taktisen kuvan ero 1 sekunnin ja 60 sekunnin sijaintipäivitystaajuuden välillä on operatiivisesti vähäpätöinen – blue-force-seuranta liikkuvalla partiolla ei vaadi alle minuutin tarkkuutta paitsi aktiivisen kontaktin aikana. Kontaktin aikana sovellus voi tilapäisesti palata välittömään lähetykseen, jonka käynnistää operaattorin asettama taktinen tapahtumalippu.

Taustasynkronointipalvelut tulisi toteuttaa Android WorkManagerilla NetworkType.CONNECTED-rajoituksilla ja setRequiresBatteryNotLow()-metodilla estämään ei-välttämättömät lähetykset ja lataukset suorittumasta, kun akku on jo matala. Karttalaattojen esinouto, analytiikkalokien lähetykset ja laiteohjelmiston päivitystarkistukset ovat kaikki ehdokkaita tälle akkuporttiselle aikataulutukselle. Keskeinen rajoite on, että näiden palvelujen ei tule kuluttaa akkua hiljaa – jokainen taustatyö tulisi kirjata aikaleimalla ja arvioidulla siirrettyjen tavujen määrällä, jotta virran auditointi voi kohdistaa radion herätystapahtumat tiettyihin sovelluskomponentteihin.

Lämpöhallinta ja SoC:n rajoitus

Lämpötila vaikuttaa suoraan sekä laitteen suorituskykyyn että akunkestoon. SoC:n liitoslämpötilan noustessa laitteen lämpöhallintayksikkö vähentää CPU:n ja GPU:n kellotaajuuksia rajoittaakseen lämmöntuotantoa – lämpörajoitus (thermal throttling). Rajoitettu laite vie kauemmin karttalaattojen renderöintiin, CoT-tapahtumien käsittelyyn ja analytiikan ajamiseen, mikä voi lisätä laskennallisesti intensiivisten operaatioiden seinäkelloaikaa ja, vastoin intuitiota, lisätä näihin tehtäviin kulutettua kokonaisenergiaa, vaikka huipputeho onkin rajattu.

Kenttäolosuhteissa lämpörasitusta lisäävät ympäristön lämpötila ja auringonvalo. Ajoneuvon kojelautaan asennettu ruggeroitu Android-EUD suorassa auringonpaisteessa 40 °C:n ympäristölämpötilassa voi nähdä SoC-lämpötilojen olevan 20–30 °C ympäristöä korkeampia jatkuvan laskennan aikana – saavuttaen 80 °C:n rajoituskynnyksen 20 minuutissa. Sovellukset, jotka ylläpitävät korkeita CPU-kuormia jatkuvasti (esimerkiksi lisäosa, joka ajaa paikallista tietokonenäön päättelyä CPU:lla), laukaisevat luotettavasti rajoituksen näissä olosuhteissa.

Androidin PowerManager-lämpötilatila-API (saatavilla API-tasolta 29 alkaen) tarjoaa reaaliaikaisen lämpötilatilan viidellä tasolla: NONE, LIGHT, MODERATE, SEVERE, CRITICAL ja EMERGENCY/SHUTDOWN. Sovellusten tulisi rekisteröidä ThermalStatusListener ja vähentää laskentakuormaa MODERATE-tilassa – keskeyttäen ei-kriittisen taustaanalytiikan, vähentäen karttapeitteiden renderöintitarkkuutta, lykäten erä-synkronointioperaatioita – ennen kuin käyttöjärjestelmä pakotetaan rajoittamaan CPU:ta tahattomasti. Ennakoiva lämpöhallinta on parempi kuin reaktiivinen rajoitus, koska vapaaehtoinen kuorman vähentäminen on kohdistetumpaa ja sillä on pienempi viive kuin käyttöjärjestelmätason taajuusskaalauksella.

Rajoitetut käyttötilat: suunnittelu akun ehtymistä varten

Taktinen sovellus, joka yksinkertaisesti lakkaa toimimasta, kun akku saavuttaa 15 %, on epäonnistunut operatiivisessa vaatimuksessa. Oikea malli on sarja porrastettuja rajoitettuja tiloja, jotka säilyttävät korkeimman prioriteetin toiminnot – sijaintiraportoinnin, kriittiset hälytykset, digitaalisen äänen – akkutilan vähentyessä, alemman prioriteetin ominaisuuksien kustannuksella.

Kolmiportainen rajoitetun tilan rakenne toimii hyvin käytännössä. Vakiotila (akku yli 30 %) ajaa kaikkia ominaisuuksia täydellä kapasiteetilla: 1 Hz GPS, täysi karttarenderöinti, kaikki lisäosat aktiivisina, synkronointi normaaleilla väleillä. Vähennetty tila (15–30 %) keskeyttää karttalaattojen esinouton ja offline-tasojen päivitykset, vähentää GPS:n 0,2 Hz:iin liiketunnistavaa logiikkaa käyttäen, alentaa näytön kirkkauden alarajan 40 %:sta 20 %:iin ja pidentää CoT-synkronoinnin niputuksen 60 sekuntiin. Selviytymistila (alle 15 %) pysäyttää kaikki ei-välttämättömät taustapalvelut, keskeyttää analytiikka- ja visualisointilisäosat, vähentää GPS:n 0,1 Hz:iin ja ylläpitää vain blue-force-seurannan CoT-sijaintiraportit 1 minuutin välein. Operaattorille ilmoitetaan tilasiirtymistä pysyvällä, suljettamattomalla tilailmaisimella ohimenevän toast-ilmoituksen sijaan, joka saattaa jäädä huomaamatta.

Ulkoinen virta ja lataaminen kentällä

Sovellustason optimointi pidentää tehtäväkestoa mutta ei poista virtalogistiikan tarvetta. Taktisten EUD:iden kenttälatausvaihtoehtoja ovat aurinkopaneelit (5–20 W joustavat paneelit kannettuna reppussa, tehokkaita selkeän taivaan olosuhteissa), ajoneuvon virta USB-C PD:n kautta 15–65 W (latausaika 60–120 minuuttia 4 000 mAh:n akulle) ja akkupankit (20 000 mAh ulkoiset paketit, jotka tarjoavat 4–5 täyttä latausta painaen 160–180 g kukin).

Sovellukset, jotka ovat tietoisia lataustilasta – saatavilla Androidin BatteryManagerin kautta – voivat opportunistisesti ajaa lykättyjä korkeatehoisia tehtäviä laitteen latautuessa: karttalaattojen lataukset, tietokannan tiivistys, lokien lähetykset. Tämä opportunistinen lataustietoinen käyttäytyminen on akkoporttisen aikataulutuksen käänteinen: sen sijaan, että tukahduttaisi raskaan työn akun ollessa matala, se aikatauluttaa sen, kun virtaa on saatavilla. Laitteelle, joka viettää 90 minuuttia ajoneuvossa partio-osuuksien välillä, lataustietoinen sovellus voi saapua seuraavaan tavoitteeseen tuoreesti synkronoidulla karttavälimuistilla ja täydellä akulla ehtyneen ja vanhentuneen datan sijaan.

Virranhallinnan ja MANET-mesh-verkon välinen vuorovaikutus ansaitsee eksplisiittistä suunnittelua. MANET-radiot kuluttavat tyypillisesti 1–4 W omasta virtalähteestään USB:n tai Ethernetin kautta laitteeseen liitettyinä, mutta korkean kaistanleveyden MANET-liikenne (videon suoratoisto, suuret tiedostonsiirrot) voi laukaista jatkuvaa CPU- ja radioaktiivisuutta EUD:lla. MANET-radioihin integroituvien sovellusten tulisi kohdella MANET-liitettyä liikennettä täsmälleen kuten solukkoliikennettä aikataulutustarkoituksissa: niputettuna, lykättynä mahdollisuuksien mukaan ja akkutason porttisuuden alaisena ei-kriittisille siirroille.

Hyväksymistestaus virransuorituskyvylle

Virransuorituskyky on validoitava kenttärealistisissa olosuhteissa, ei vain laboratoriossa. Hyväksymistestien tulisi määrittää: kohdelaitemalli ja Android-versio (virrankäyttäytyminen vaihtelee merkittävästi laitteistoalustojen ja käyttöjärjestelmäjulkaisujen välillä); ympäristön lämpötila-alue (0 °C ja 40 °C antavat erilaiset profiilit); operatiivinen skenaario (partio, staattinen tarkkailuasema, ajoneuvoon asennettu); ja läpäisy/hylkäys-kriteeri (vähimmäismäärä käyttötunteja ennen kuin selviytymistila käynnistyy määritellyllä käyttömallilla). Jokaisen laitteen käyttöjärjestelmän laiteohjelmistopäivityksen ja jokaisen merkittävän sovellusjulkaisun tulisi ajaa virran hyväksymistesti uudelleen, koska käyttöjärjestelmäpäivitykset muuttavat rutiininomaisesti Doze-käyttäytymistä, JobSchedulerin niputusikkunoita ja GPS:n pulssituslogiikkaa tavoilla, jotka mitätöivät aiemmat mittaukset.

Kenttäpalaute on luotettavin signaali virrandilemmoille, jotka laboratoriotestaus jättää huomaamatta. Strukturoitu kenttävikaraportin malli, joka sisältää akkutilan tietyillä tehtävätunneilla, laitemallin, lämpötilaolosuhteet ja sovellusversion, antaa insinööritiimien diagnosoida virtaregressioita, jotka ilmenevät vain todellisissa operatiivisissa olosuhteissa – korkean korkeuden kylmä, jatkuva suora aurinko, pölyiset ympäristöt, jotka vähentävät lämmönhaihtumista. Kenttäraporttien korreloiminen instrumentoituja virtalokeja vastaan, jotka hyvin suunniteltu sovellus kirjoittaa paikallisesti, tarjoaa datan, jota tarvitaan vastuullisen komponentin tunnistamiseen ja korjaamiseen ennen seuraavaa käyttöönottoa.