Avmystifiera maskininlärning vid kanten genom verkliga användningsfall

kant är en term som syftar på en plats, långt från molnet eller ett stort datacenter, där du har en datorenhet (kantenhet) som kan köra (kant)applikationer. Edge computing är handlingen att köra arbetsbelastningar på dessa edge-enheter. Machine learning at the edge (ML@Edge) är ett koncept som ger möjligheten att köra ML-modeller lokalt till edge-enheter. Dessa ML-modeller kan sedan anropas av edge-applikationen. ML@Edge är viktigt för många scenarier där rådata samlas in från källor långt från molnet. Dessa scenarier kan också ha specifika krav eller begränsningar:

• Förutsägelser i realtid med låg latens
• Dålig eller obefintlig anslutning till molnet
• Juridiska begränsningar som inte tillåter att data skickas till externa tjänster
• Stora datamängder som måste förbehandlas lokalt innan svar skickas till molnet

Följande är några av många användningsfall som kan dra nytta av ML-modeller som körs nära den utrustning som genererar data som används för förutsägelserna:

• Säkerhet och säkerhet – Ett begränsat område där tunga maskiner arbetar i en automatiserad hamn övervakas av en kamera. Om en person kommer in i detta område av misstag, aktiveras en säkerhetsmekanism för att stoppa maskinerna och skydda människan.
• Förutsägbart underhåll – Vibrations- och ljudsensorer samlar in data från en växellåda i ett vindturbin. En avvikelsedetekteringsmodell bearbetar sensordata och identifierar om avvikelser med utrustningen. Om en avvikelse upptäcks kan kantanordningen starta en beredskapsmätning i realtid för att undvika att skada utrustningen, som att koppla in avbrotten eller koppla bort generatorn från nätet.
• Defektdetektering i produktionslinjer – En kamera tar bilder av produkter på ett löpande band och bearbetar ramarna med en bildklassificeringsmodell. Om en defekt upptäcks kan produkten kasseras automatiskt utan manuellt ingripande.

Även om ML@Edge kan hantera många användningsfall, finns det komplexa arkitektoniska utmaningar som måste lösas för att få en säker, robust och pålitlig design. I det här inlägget lär du dig lite detaljer om ML@Edge, relaterade ämnen och hur du använder AWS-tjänster för att övervinna dessa utmaningar och implementera en komplett lösning för din ML vid kantens arbetsbelastning.

ML@Edge översikt

Det finns en vanlig förvirring när det kommer till ML@Edge och Internet of Things (IoT), därför är det viktigt att klargöra hur ML@Edge skiljer sig från IoT och hur de båda skulle kunna gå samman för att ge en kraftfull lösning i vissa fall.

En edge-lösning som använder ML@Edge har två huvudkomponenter: en edge-applikation och en ML-modell (anropas av applikationen) som körs på edge-enheten. ML@Edge handlar om att kontrollera livscykeln för en eller flera ML-modeller som distribueras till en flotta av edge-enheter. ML-modellens livscykel kan starta på molnsidan (på Amazon SageMaker, till exempel) men slutar normalt på en fristående distribution av modellen på edge-enheten. Varje scenario kräver olika ML-modelllivscykler som kan bestå av många steg, såsom datainsamling; dataförberedelse; modellbygge, kompilering och distribution till kantenheten; modell lastning och körning; och upprepa livscykeln.

ML@Edge-mekanismen är inte ansvarig för applikationens livscykel. Ett annat tillvägagångssätt bör antas för detta ändamål. Att frikoppla ML-modellens livscykel och applikationslivscykeln ger dig friheten och flexibiliteten att fortsätta utveckla dem i olika takt. Föreställ dig en mobilapplikation som bäddar in en ML-modell som en resurs som en bild eller XML-fil. I det här fallet, varje gång du tränar en ny modell och vill distribuera den till mobiltelefonerna, måste du distribuera om hela applikationen. Detta tar tid och pengar och kan introducera buggar i din applikation. Genom att koppla bort ML-modellens livscykel publicerar du mobilappen en gång och distribuerar så många versioner av ML-modellen som du behöver.

Men hur korrelerar IoT med ML@Edge? IoT relaterar till fysiska objekt inbäddade med teknologier som sensorer, bearbetningsförmåga och mjukvara. Dessa objekt är anslutna till andra enheter och system över internet eller andra kommunikationsnätverk, för att utbyta data. Följande figur illustrerar denna arkitektur. Konceptet skapades ursprungligen när man tänkte på enkla enheter som bara samlar in data från kanten, utför enkel lokal bearbetning och skickar resultatet till en kraftfullare datorenhet som kör analysprocesser som hjälper människor och företag i deras beslutsfattande. IoT-lösningen är ansvarig för att kontrollera edge-applikationens livscykel. För mer information om IoT, se Sakernas Internet.

Om du redan har en IoT-applikation kan du lägga till ML@Edge-funktioner för att göra produkten mer effektiv, som visas i följande figur. Tänk på att ML@Edge inte är beroende av IoT, men du kan kombinera dem för att skapa en mer kraftfull lösning. När du gör det förbättrar du möjligheten för din enkla enhet att generera realtidsinsikter för ditt företag snabbare än att bara skicka data till molnet för senare bearbetning.

Om du skapar en ny edge-lösning från grunden med ML@Edge-funktioner är det viktigt att designa en flexibel arkitektur som stöder både applikationens och ML-modellens livscykler. Vi tillhandahåller några referensarkitekturer för edge-applikationer med ML@Edge senare i det här inlägget. Men först, låt oss dyka djupare in i edge computing och lära oss hur man väljer rätt edge-enhet för din lösning, baserat på miljöns begränsningar.

Edge computing

Beroende på hur långt enheten är från molnet eller ett stort datacenter (bas), måste tre huvudegenskaper hos kantenheterna beaktas för att maximera systemets prestanda och livslängd: dator- och lagringskapacitet, anslutningsmöjligheter och strömförbrukning. Följande diagram visar tre grupper av kantenheter som kombinerar olika specifikationer för dessa egenskaper, beroende på hur långt från de är från basen.

Grupperna är följande:

• MECs (Multi-access Edge Computing) – MEC:er eller små datacenter, kännetecknade av låg eller ultralåg latens och hög bandbredd, är vanliga miljöer där ML@Edge kan ge fördelar utan stora begränsningar jämfört med molnarbete. 5G-antenner och servrar på fabriker, lager, laboratorier och så vidare med minimala energibegränsningar och med bra internetanslutning erbjuder olika sätt att köra ML-modeller på GPU:er och processorer, virtuella maskiner, behållare och barmetallservrar.
• Nära kanten – Det är när mobilitet eller dataaggregation är krav och enheterna har vissa begränsningar när det gäller strömförbrukning och processorkraft, men fortfarande har en viss pålitlig anslutning, fast med högre latens, med begränsad genomströmning och dyrare än "nära kanten." Mobilapplikationer, specifika kort för att accelerera ML-modeller eller enkla enheter med kapacitet att köra ML-modeller, täckta av trådlösa nätverk, ingår i denna grupp.
• Längre kanten – I det här extrema scenariot har edge-enheter stor strömförbrukning eller anslutningsbegränsningar. Följaktligen är processorkraften också begränsad i många scenarier med långt framkant. Jordbruk, gruvdrift, övervakning och säkerhet samt sjötransporter är några områden där fjärrstyrda enheter spelar en viktig roll. Enkla kort, normalt utan GPU:er eller andra AI-acceleratorer, är vanliga. De är designade för att ladda och köra enkla ML-modeller, spara förutsägelserna i en lokal databas och vila till nästa förutsägelsecykel. Enheterna som behöver bearbeta realtidsdata kan ha stora lokala lagringar för att undvika att förlora data.

Utmaningar

Det är vanligt att ha ML@Edge-scenarier där du har hundratals eller tusentals (kanske till och med miljoner) enheter som kör samma modeller och edge-applikationer. När du skalar ditt system är det viktigt att ha en robust lösning som kan hantera antalet enheter som du behöver stödja. Detta är en komplex uppgift och för dessa scenarier måste du ställa många frågor:

• Hur använder jag ML-modeller på en flotta av enheter vid kanten?
• Hur bygger, optimerar och distribuerar jag ML-modeller till flera edge-enheter?
• Hur säkrar jag min modell när jag distribuerar och kör den vid kanten?
• Hur övervakar jag min modells prestanda och tränar om den om det behövs?
• Hur eliminerar jag behovet av att installera ett stort ramverk som TensorFlow eller PyTorch på min begränsade enhet?
• Hur exponerar jag en eller flera modeller med min edge-applikation som ett enkelt API?
• Hur skapar jag en ny datauppsättning med nyttolast och förutsägelser som fångas av edge-enheterna?
• Hur gör jag alla dessa uppgifter automatiskt (MLOps plus ML@Edge)?

I nästa avsnitt ger vi svar på alla dessa frågor genom exempel på användningsfall och referensarkitekturer. Vi diskuterar också vilka AWS-tjänster du kan kombinera för att bygga kompletta lösningar för vart och ett av de utforskade scenarierna. Men om du vill börja med ett mycket enkelt flöde som beskriver hur du använder några av tjänsterna som tillhandahålls av AWS för att skapa din ML@Edge-lösning, är detta ett exempel:

Med SageMaker kan du enkelt förbereda en datauppsättning och bygga ML-modellerna som distribueras till edge-enheterna. Med Amazon SageMaker Neo, kan du kompilera och optimera modellen du tränade till den specifika kantenhet du valde. Efter att ha kompilerat modellen behöver du bara en lätt körtid för att köra den (tillhandahålls av tjänsten). Amazon SageMaker Edge Manager är ansvarig för att hantera livscykeln för alla ML-modeller som distribueras till din flotta av edge-enheter. Edge Manager kan hantera flottor på upp till miljontals enheter. En agent, installerad på var och en av edge-enheterna, exponerar de distribuerade ML-modellerna som ett API för applikationen. Agenten är också ansvarig för att samla in mätvärden, nyttolaster och förutsägelser som du kan använda för att övervaka eller bygga en ny datauppsättning för att träna om modellen om det behövs. Slutligen med Amazon SageMaker-rörledningar, kan du skapa en automatiserad pipeline med alla steg som krävs för att bygga, optimera och distribuera ML-modeller till din flotta av enheter. Denna automatiserade pipeline kan sedan utlösas av enkla händelser som du definierar, utan mänsklig inblandning.

Använd fall 1

Låt oss säga att en flygplanstillverkare vill upptäcka och spåra delar och verktyg i produktionshangaren. För att förbättra produktiviteten måste alla nödvändiga delar och rätt verktyg vara tillgängliga för ingenjörerna i varje steg av produktionen. Vi vill kunna svara på frågor som: Var finns del A? eller Var är verktyg B? Vi har flera IP-kameror redan installerade och anslutna till ett lokalt nätverk. Kamerorna täcker hela hangaren och kan strömma HD-video i realtid genom nätverket.

AWS Panorama passar bra in i det här fallet. AWS Panorama tillhandahåller en ML-apparat och hanterad tjänst som gör att du kan lägga till datorseende (CV) till din befintliga flotta av IP-kameror och automatisera. AWS Panorama ger dig möjligheten att lägga till CV till dina befintliga Internet Protocol (IP) kameror och automatisera uppgifter som traditionellt kräver mänsklig inspektion och övervakning.

I följande referensarkitektur visar vi huvudkomponenterna i applikationen som körs på en AWS Panorama Appliance. Panorama Application SDK gör det enkelt att fånga video från kameraströmmar, utföra slutsatser med en pipeline av flera ML-modeller och bearbeta resultaten med Python-kod som körs inuti en behållare. Du kan köra modeller från alla populära ML-bibliotek som TensorFlow, PyTorch eller TensorRT. Resultaten från modellen kan integreras med affärssystem på ditt lokala nätverk, så att du kan svara på händelser i realtid.

Lösningen består av följande steg:

1. Anslut och konfigurera en AWS Panorama-enhet till samma lokala nätverk.
2. Träna en ML-modell (objektdetektion) för att identifiera delar och verktyg i varje ram.
3. Bygg en AWS Panorama-applikation som hämtar förutsägelserna från ML-modellen, tillämpar en spårningsmekanism på varje objekt och skickar resultaten till en realtidsdatabas.
4. Operatörerna kan skicka frågor till databasen för att hitta delarna och verktygen.

Använd fall 2

För vårt nästa användningsfall, föreställ dig att vi skapar en instrumentbräda för fordon som kan stödja föraren i många situationer, som att undvika fotgängare, baserat på en CV25-bräda från Ambaralla. Att vara värd för ML-modeller på en enhet med begränsade systemresurser kan vara svårt. I det här fallet, låt oss anta att vi redan har en väletablerad OTA-leveransmekanism på plats för att distribuera de applikationskomponenter som behövs på kantenheten. Men vi skulle fortfarande dra nytta av möjligheten att göra OTA-distribution av själva modellen, och därigenom isolera applikationens livscykel och modelllivscykel.

Amazon SageMaker Edge Manager och Amazon SageMaker Neo passar bra för detta användningsfall.

Edge Manager gör det enkelt för ML edge-utvecklare att använda samma välbekanta verktyg i molnet eller på edge-enheter. Det minskar tiden och ansträngningen som krävs för att få modellerna till produktion, samtidigt som du kan kontinuerligt övervaka och förbättra modellkvaliteten i din enhetsflotta. SageMaker Edge inkluderar en OTA-distributionsmekanism som hjälper dig att distribuera modeller i flottan oberoende av applikationen eller enhetens firmware. De Edge Manager-agent låter dig köra flera modeller på samma enhet. Agenten samlar in förutsägelsedata baserat på logiken som du kontrollerar, såsom intervaller, och laddar upp den till molnet så att du med jämna mellanrum kan träna om dina modeller över tid. SageMaker Edge signerar dina modeller kryptografiskt så att du kan verifiera att den inte har manipulerats när den flyttar från molnet till kantenheten.

Neo är en kompilator som en tjänst och passar särskilt bra i detta användningsfall. Neo optimerar automatiskt ML-modeller för slutsatser om molninstanser och edge-enheter för att köra snabbare utan förlust i noggrannhet. Du börjar med en ML-modell byggd med en av ramar som stöds och utbildad i SageMaker eller någon annanstans. Sedan väljer du din målmaskinvaruplattform, (se listan över enheter som stöds). Med ett enda klick optimerar Neo den tränade modellen och kompilerar den till ett paket som kan köras med den lätta SageMaker Edge-körtiden. Kompilatorn använder en ML-modell för att tillämpa prestandaoptimeringarna som extraherar den bästa tillgängliga prestandan för din modell på molninstansen eller edge-enheten. Du distribuerar sedan modellen som en SageMaker-slutpunkt eller på kantenheter som stöds och börjar göra förutsägelser.

Följande diagram illustrerar denna arkitektur.

Lösningsarbetsflödet består av följande steg:

1. Utvecklaren bygger, tränar, validerar och skapar den slutliga modellartefakten som måste distribueras till instrumentkameran.
2. Anropa Neo för att kompilera den tränade modellen.
3. SageMaker Edge-agenten installeras och konfigureras på Edge-enheten, i det här fallet instrumentkameran.
4. Skapa ett distributionspaket med en signerad modell och körtiden som används av SageMaker Edge-agenten för att ladda och anropa den optimerade modellen.
5. Distribuera paketet med den befintliga OTA-distributionsmekanismen.
6. Edge-applikationen interagerar med SageMaker Edge-agenten för att göra slutsatser.
7. Agenten kan konfigureras (om så krävs) för att skicka realtidsexempelindata från applikationen för modellövervakning och förfiningsändamål.

Använd fall 3

Anta att din kund utvecklar en applikation som upptäcker anomalier i mekanismerna i en vindturbin (som växellådan, generatorn eller rotorn). Målet är att minimera skadorna på utrustningen genom att köra lokala skyddsprocedurer i farten. Dessa turbiner är mycket dyra och placerade på platser som inte är lättillgängliga. Varje turbin kan utrustas med en NVIDIA Jetson-enhet för att övervaka sensordata från turbinen. Vi behöver då en lösning för att fånga in data och använda en ML-algoritm för att upptäcka anomalier. Vi behöver också en OTA-mekanism för att hålla programvaran och ML-modellerna på enheten uppdaterade.

AWS IoT Greengrass V2 tillsammans med Edge Manager passar bra i detta användningsfall. AWS IoT Greengrass är en IoT edge-runtime- och molntjänst med öppen källkod som hjälper dig att bygga, distribuera och hantera IoT-applikationer på dina enheter. Du kan använda AWS IoT Greengrass för att bygga edge-applikationer med förbyggda mjukvarumoduler, så kallade komponenter, som kan ansluta dina edge-enheter till AWS-tjänster eller tredjepartstjänster. Denna förmåga hos AWS IoT Greengrass gör det enkelt att distribuera tillgångar till enheter, inklusive en SageMaker Edge-agent. AWS IoT Greengrass ansvarar för att hantera applikationens livscykel, medan Edge Manager frikopplar ML-modellens livscykel. Detta ger dig flexibiliteten att fortsätta utveckla hela lösningen genom att distribuera nya versioner av edge-applikationen och ML-modeller oberoende. Följande diagram illustrerar denna arkitektur.

Lösningen består av följande steg:

1. Utvecklaren bygger, tränar, validerar och skapar den slutliga modellartefakten som måste distribueras till vindturbinen.
2. Anropa Neo för att kompilera den tränade modellen.
3. Skapa en modellkomponent med Edge Manager med AWS IoT Greengrass V2-integration.
4. Konfigurera AWS IoT Greengrass V2.
5. Skapa en slutledningskomponent med AWS IoT Greengrass V2.
6. Edge-applikationen interagerar med SageMaker Edge-agenten för att göra slutsatser.
7. Agenten kan konfigureras (om så krävs) för att skicka realtidsexempelindata från applikationen för modellövervakning och förfiningsändamål.

Använd fall 4

För vårt sista användningsfall, låt oss titta på ett fartyg som transporterar containrar, där varje container har ett par sensorer och strömmar en signal till beräknings- och lagringsinfrastrukturen som är utplacerad lokalt. Utmaningen är att vi vill veta innehållet i varje container, och godsets skick baserat på temperatur, luftfuktighet och gaser inuti varje container. Vi vill också spåra alla varor i var och en av containrarna. Det finns ingen internetuppkoppling under hela resan, och resan kan ta månader. ML-modellerna som körs på denna infrastruktur bör förbehandla data och generera information för att svara på alla våra frågor. Data som genereras måste lagras lokalt i månader. Edgeapplikationen lagrar alla slutsatser i en lokal databas och synkroniserar sedan resultaten med molnet när fartyget närmar sig hamnen.

AWS Snowcone och AWS snöboll från AWS Snow Family skulle kunna passa mycket bra i detta användningsfall.

AWS Snowcone är en liten, robust och säker edgedator- och datamigreringsenhet. Snowcone är designad enligt OSHA-standarden för en lyftbar enhet för en person. Snowcone gör att du kan köra avancerade arbetsbelastningar med hjälp av Amazon Elastic Compute Cloud (Amazon EC2) datoranvändning och lokal lagring i tuffa, frånkopplade fältmiljöer som oljeriggar, sök- och räddningsfordon, militärplatser eller fabriksgolv, såväl som avlägsna kontor, sjukhus och biografer.

Snowball lägger till mer datoranvändning jämfört med Snowcone och kan därför passa bra för mer krävande applikationer. Funktionen Compute Optimized tillhandahåller en valfri NVIDIA Tesla V100 GPU tillsammans med EC2-instanser för att accelerera en applikations prestanda i frånkopplade miljöer. Med GPU-alternativet kan du köra applikationer som avancerad ML och full motion videoanalys i miljöer med liten eller ingen anslutning.

Utöver EC2-instansen har du friheten att bygga och distribuera vilken typ av edge-lösning som helst. Till exempel: du kan använda Amazon ECS eller annan containerhanterare för att distribuera edge-applikationen, Edge Manager Agent och ML-modellen som individuella containrar. Den här arkitekturen skulle likna Use Case 2 (förutom att den kommer att fungera offline för det mesta), med tillägget av ett containerhanterarverktyg.

Följande diagram illustrerar denna lösningsarkitektur.

För att implementera denna lösning, beställ helt enkelt din Snow-enhet från AWS Management Console och starta dina resurser.

Slutsats

I det här inlägget diskuterade vi de olika aspekterna av edge som du kan välja att arbeta med baserat på ditt användningsfall. Vi diskuterade också några av nyckelkoncepten kring ML@Edge och hur frikopplingen av applikationens livscykel och ML-modellens livscykel ger dig friheten att utveckla dem utan något beroende av varandra. Vi betonade hur att välja rätt kantenhet för din arbetsbelastning och ställa rätt frågor under lösningsprocessen kan hjälpa dig att arbeta bakåt och begränsa rätt AWS-tjänster. Vi presenterade också olika användningsfall tillsammans med referensarkitekturer för att inspirera dig att skapa dina egna lösningar som fungerar för din arbetsbelastning.

---

Om författarna

Dinesh Kumar Subramani är Senior Solutions Architect med UKIR SMB-teamet, baserat i Edinburgh, Skottland. Han är specialiserad på artificiell intelligens och maskininlärning. Dinesh tycker om att arbeta med kunder i olika branscher för att hjälpa dem att lösa sina problem med AWS-tjänster. Utanför jobbet älskar han att umgås med sin familj, spela schack och njuta av musik i olika genrer.

Samir Araújo är AI / ML Solutions Architect på AWS. Han hjälper kunder att skapa AI / ML-lösningar som löser deras affärsutmaningar med hjälp av AWS. Han har arbetat med flera AI / ML-projekt relaterade till datorsyn, bearbetning av naturligt språk, prognoser, ML vid kanten och mer. Han gillar att spela med hårdvaru- och automatiseringsprojekt på fritiden, och han har ett särskilt intresse för robotik.

• Myntsmart. Europas bästa bitcoin- och kryptobörs.
• Platoblockchain. Web3 Metaverse Intelligence. Kunskap förstärkt. FRI TILLGÅNG.
• CryptoHawk. Altcoin radar. Gratis provperiod.
• Källa: https://aws.amazon.com/blogs/machine-learning/demystifying-machine-learning-at-the-edge-through-real-use-cases/