Vítejte, dnes je
pátek
27.
prosinec 2024
Odborný časopis a portál zaměřený na vývoj a výrobu elektroniky 
S rozvojem průmyslového internetu věcí sledujeme trend, kdy místo toho, abychom zapojovali několik samostatných součástek, realizujeme větší počet funkcí spíše v rámci jediného SoC. Mimo jiné tím dosáhneme útlejší rozpisky, menšího rizika spojeného s vývojem a také menších fyzických rozměrů.
Jako skvělý příklad nám poslouží „Wi-Fi MCU“, které spojí možnosti bezdrátového rozhraní s procesorem a GPIO, takže se lze přizpůsobit potřebám různorodých aplikací. Pokud chceme rozumně vybírat z nabídky, musíme ale při specifikaci takového prvku zvážit řadu faktorů, kterým je také zapotřebí porozumět.
Trh v současné době nabízí možnosti levného řešení vzájemné propojitelnosti přes Wi-Fi, nicméně často třeba na úkor počtu dostupných periférií. To znamená, že volba nejlepšího MCU s podporou Wi-Fi nebude jednoduchá a taky bez rizika. Od mikrokontroléru totiž vyžadujeme nejen robustní bezdrátovou konektivitu, ale také špičkové funkce samotného MCU. Pokud kterýkoli z těchto předpokladů chybí, celý projekt se zpožďuje a nemusí dokonce ani vyjít. Mikrokontrolér je coby jádro celého systému nejdůležitější částí Wi-Fi MCU, takže je nezbytné prozkoumat jeho vlastnosti již na začátku vývoje, protože pozdější změna součástky si obecně žádá přepracování celého softwaru, včetně konfigurace souvisejících obvodů.
Analogově-číslicový převod se při výběru MCU s podporou Wi-Fi stává jednou z nejvíce přehlížených funkcí – a to navzdory skutečnosti, že v řetězci zajišťujícím zpracování signálu půjde za analogovým vstupem o součástku č. 1. To znamená, že ovlivní vlastnosti celého systému, takže je nezbytné porozumět jeho klíčovým parametrům, včetně toho, jak si s nimi poradí výrobce takového MCU.
Jednou z prvních vlastností, na kterou se vývojáři u ADC zaměřují, je počet bitů. To však může být zavádějící, protože v praxi bývá skutečný počet bitů nižší než dle specifikace v datasheetu. Někdy i výrazně. Mnohem důležitější zde proto bude efektivní počet bitů ENOB, které má A/D převodník pro svou činnost k dispozici. Bude vždy nižší než v dokumentaci, nicméně významná je právě bližší shoda mezi ENOB a specifikací z datasheetu, protože se mezi převodníky výrazně mění. Čím méně bitů je během převodu k dispozici, tím méně přesněji bude SoC reprezentovat vstupní signál.
Podobně jako všechny elektronické součástky budou rovněž A/D převodníky dále „přispívat“ s něčím, co signál ve výsledku negativně ovlivní. Půjde zde o chyby spojené s kvantizací a časováním, podobně jako změny, pokud jde o offset, zisk či linearitu. ADC jsou také nechvalně proslulé svou citlivostí vůči obrovským teplotním výkyvům, se kterými se průmyslové systémy IoT musí během provozu často potýkat – viz také obr. 1. Výrobce mikrokontrolérů s podporou Wi-Fi to každopádně dokáže zmírnit, takže se s výrobci každého MCU, který zde připadá v úvahu, určitě spojte a zjistěte jejich ENOB, chování se změnou teploty, linearitu a také přesnost. Pokud informace nelze poskytnout, jděte jinam.
Obr. 1 A/D převodníky nižší třídy bojují s přesností i linearitou a vyznačují se citlivostí vůči okolnímu prostředí, včetně teploty
Pokud jde o rozhraní, veškeré Wi-Fi MCU podporují přinejmenším několik standardů, takže se snadno předpokládá, že to bude i stačit. Jakmile se však vývojáři rozhodnou využít stejný mikrokontrolér v jiném návrhu, spláčou často nad výdělkem. Něco takového bude stále běžnější právě při konstrukci nebo též úpravách průmyslových systémů IoT, kde většina výrobních zařízení používá celou řadu strojů a také ovladačů, které v různou dobu postavili různí výrobci.
S tím, jak systém roste, se bude množství rozhraní pravděpodobně dále zvyšovat a přijde možná doba, kdy se bude hodit i podpora funkcí, jako jsou dotyková ovládání či zobrazování s LCD. Jestliže má SoC nějaké GPIO navíc, bude kromě toho možné ovládat větší počet relé, spínačů a dalších prvků s minimální, nebo dokonce žádnou potřebou sdílení vývodů. V takovém případě by pak rozhraní podporovaná ze strany dané součástky měla zahrnovat Ethernet MAC, USB, CAN, CAN-FD, SPI, I²C, SQI, UART a také JTAG (eventuálně též i podporu pro dotykové ovládání či displeje), takže nás nyní, ale také v dohledné budoucnosti nezaskočí prakticky žádný „scénář“.
Zabezpečení se stává základní otázkou pro každou aplikaci internetu věcí, ovšem v průmyslové sféře bude vyloženě kritickou záležitostí. Jakmile totiž hrozba pronikne do průmyslové sítě IoT, dokáže se následně šířit celým podnikem a možná i napříč celou firmou. O první úrovni požadovaného zabezpečení zde hovoříme v souvislosti s MCU a jeho vlastní šifrovací jednotkou, kde kódování a také ověřování probíhá buď postupně, nebo je řešeno paralelně. Šifrování může zahrnovat AES s klíčem o velikosti až 256 bitů, DES a TDES, zatímco autentizace pak SHA-1, SHA-256 a MD-5.
Vzhledem k tomu, že každý poskytovatel cloudové služby bude mít svou vlastní certifikaci, klíče a také přístupový proces (provisioning), zařízení stavěná pro takové účely nejsou jednoduchá a budou zde vyžadovat velké znalosti o šifrování. Když tedy vývojáři nechávají svůj produkt přistupovat ke cloudové službě, půjde o jeden z nejnáročnějších úkolů. Naštěstí tu máme výrobce, jako je společnost Microchip Technology, kteří umí takový proces zjednodušit a ušetřit tím obrovské množství času i peněz. Časová úspora včetně skutečnosti, že se tak vyhneme nejasnostem, má nesmírný význam. Vždyť také v rámci vývojového procesu dostaneme k dobru celé týdny, a možná ještě více, zatímco dále zajistíme, že veškeré požadavky, pokud jde o přístup a zabezpečení, budou splněny osvědčeným a prokazatelným způsobem.
Musíme však zdůraznit, že většina mikrokontrolérů s podporou Wi-Fi ukládá své „kredity“ v paměti Flash, kde jsou také data dostupná a citlivá na softwarové či fyzické útoky. Nejvyššího zabezpečení proto dosáhneme, pokud informaci uložíme ve speciálním bezpečnostním prvku, jehož data nelze přečíst na základě žádného vnějšího softwaru. Wi-Fi MCU od Microchipu, jako jsou WFI32 na obr. 2, takového přístupu využijí např. v rámci firemní platformy Trust&GO pro zajištění bezpečného přístupu MCU ve spojení s AWS IoT, Google Cloud, Microsoft Azure či sítěmi třetí strany (TLS).
Obr. 2 Wi-Fi modul WFI32 izoluje „kredity“ tím, že je ukládá hardwarovou cestou, takže jsou v zásadě odolné vůči útokům
Bezpečnostní prvky s dopředu řešeným přístupovým procesem, předkonfigurované či zákaznické, ukládají kredity generované uvnitř modulů HSM (Hardware Secure Module) daného prvku, když je vyroben, a chrání je před odhalením v průběhu další výroby, resp. po jejím skončení. Platforma Trust&GO zde přitom vyžaduje pouze docela levný vývojový kit od Microchipu, kdy má vývojář dále k dispozici návrhovou sadu, včetně „návodu“ k použití a vzorových kódů, takže lze vytvořit požadovaný soubor. Jakmile kód pro bezpečnostní prvek v jazyce C v aplikaci pracuje, lze s návrhem přejít do výroby.
Další požadovanou formou se stává nejnovější zabezpečení certifikované ze strany Wi-Fi Alliance. Poslední verzí je WPA3, které staví na předešlém WPA2, nicméně zde doplňuje funkce zjednodušující zabezpečení Wi-Fi, umožňuje robustnější ověřování, nahrává rostoucí odolnosti při šifrování a také hladkému provozu v síti. Aby mohla nová zařízení používat logo Wi-Fi Alliance, musí mít pokaždé certifikát s WPA3, což s ohledem na maximální možné zabezpečení platí pro každý čip i mikrokontrolér s podporou Wi-Fi. V případě vámi zvoleného Wi-Fi MCU si to každopádně ověřte.
Vždy je také možné, že mikrokontrolér s podporou Wi-Fi nedokáže komunikovat s některými přístupovými body dostupnými na trhu, třeba kvůli špatnému vf spojení, softwaru či dalším faktorům. Pokud se to stane u oblíbených AP, může to poškodit dobré jméno firmy. Nelze sice zaručit, že bude Wi-Fi MCU pracovat úplně s každým AP na naší planetě, nicméně problém je možné minimalizovat tím, že takový mikrokontrolér již dříve podstoupil testování „interoperability“ s nejrozšířenějšími AP na trhu. Zmíněnou informaci můžete nalézt na webových stránkách výrobce. Pokud se k ní nelze snadno dopracovat, výrobce kontaktujte. Jestliže pak selže i tato snaha, porozhlédněte se jinde.
Nakonec, ale nikoli s nejnižší prioritou, zde máme požadavek na podporu. Bez komplexní platformy – integrovaného vývojového prostředí IDE zůstane vývojář odkázán na informace z webu, které mohou být užitečné, srozumitelné nebo též hodnověrné, ale také nemusí být. Několik výrobců Wi-Fi MCU poskytuje například základní informace ohledně svého produktu, včetně instrukcí k návrhu prototypu, ovšem zde již končí a neřeší další přechod z této fáze vývoje až do výroby.
Aby to dávalo skutečně smysl, měl by daný výrobce poskytnout úplné IDE (viz také obr. 3), které bude počítat s každou analogovou i digitální funkcí vykonávanou takovým Wi-Fi mikrokontrolérem, včetně všech externích součástek vyžadovaných při realizaci konkrétního zadání. Hodit se budou i prostředky sloužící k vizualizaci toho, jak se změny v návrhu dotýkají celkových vlastností, resp. schopnost vyhodnotit vf parametry návrhu, stejně jako shodu s příslušnými směrnicemi. Některé ze základních nástrojů jsou k dispozici zdarma, zatímco u jiných se již něco málo platí. Patří sem i vývojové desky navržené s ohledem na rodinu Wi-Fi MCU konkrétního výrobce.
Obr. 3 Integrované vývojové prostředí, třeba jako v našem případě, snižuje riziko tím, že vývojářům pomůže při ladění a také s dalšími nástroji – od fáze prototypu až po konečný produkt
Trendem ve světě internetu věcí bude rostoucí zastoupení výkonu dostupného při zpracování přímo v daném místě sítě, spíše než jen v rámci cloudových datových center. Abychom něčeho takového dosáhli, bude nezbytné zapracovat tolik funkcí, jak jen to bude s minimálním dostupným prostorem a také počtem součástek vůbec možné. Wi-Fi MCU se stávají jedním z řady prvků SoC, které ušly dlouhou cestu, aby toho nakonec dosáhly. Místo diskrétních součástek se specifickými funkcemi zde totiž budou větší počet funkcí integrovat v rámci jediného obvodu.
Za předpokladu, že výrobce Wi-Fi mikrokontroléru dává k dispozici adekvátní prostředky, může být zapracování zmíněných součástek do vestavného subsystému internetu věcí docela snadné. V praxi to zahrnuje vysokou míru zabezpečení, otázku jasného přístupového procesu, pokud jde o přizpůsobení se požadavkům poskytovatelů cloudových služeb, a také komplexní IDE, které vývojáře provede od prototypu až k samotné výrobě.
