Asset tracking

Organisationer tappar sällan bort sina tillgångar. De tappar kontrollen över var de finns, vilket kostar lika mycket och är svårare att argumentera kring. Vagnar, burar, verktyg, rullbord, testutrustning och kärl rör sig genom en anläggning hela dagen, och frågorna som ställs om dem handlar nästan aldrig om koordinater:

• Hur många vagnar står i den här uppställningsplatsen just nu, och behöver någon fylla på?
• Har det här rullbordet lämnat området?
• Vilka av de här fyrtio enheterna har inte rört sig på en månad, och varför hyr vi in fler?
• Var sågs den senast, och av vad?

Alla fyra besvaras utifrån positionsdata, men ingen av dem besvaras av en position. Arbetet består i att göra om en ström av koordinater till ett antal per zon, och det är den delen som en karta i sig inte klarar.

Att alls få fram en position

Det finns ingen enda metod som fungerar överallt, och valet avgörs oftast av om tillgången lever sitt liv utomhus.

Metod	Var den passar	Vad den kostar dig
Inbyggd GNSS	Gårdsplaner, parkeringar, öppna ytor, allt som ser himlen	Ström. En positionsbestämning är det dyraste en batteridriven tracker gör, och därför är rapporteringen oftast rörelsestyrd snarare än periodisk
Wi-Fi MAC-skanning	Inomhus, där GNSS inte når. Trackern rapporterar de accesspunkter den hör och positionen härleds ur dem	Förutsätter ett någorlunda stabilt bestånd av accesspunkter
Närhet till en känd punkt	Uppställningsplatser, fack, grindar, lastkajer. Tillgången hör en beacon vid en zon och rapporterar vilken, över en signaltröskel	Ger dig zonen, inte metern. För räkning är det ändå oftast svaret
Gatewayposition	LoRaWAN-sensorer helt utan positioneringshårdvara	Grovt. Översättaren set-lnglat-from-gateway-location-chirpstack fyller i nodens position från närmaste gateway, vilket ofta räcker för att säga "på området"

Sensatives egen Square Tracker och den tåligare varianten Xtreme täcker de tre första, och Yggio tar emot vilken annan leverantörs tracker som helst via en översättare på samma sätt. Installationsmönstret nedan beror inte på vilken ni väljer.

Öglorna betyder mer än de ser ut att göra. En tracker sätts upp med lim, buntband eller skruv genom en monteringsram, så att utrusta en flotta kräver varken ström, kabeldragning eller borrning i något bärande - vilket är det som gör att märka upp ett par hundra vagnar till ett skiftarbete i stället för ett projekt.

En poäng värd att ta tidigt: noggrannhet är en budget, inte ett mål. En tracker som rapporterar varje minut med fem meters noggrannhet håller inte året ut på batteri, och ett antal per uppställningsplats behöver inte fem meter. Bestäm vad frågan tål innan ni väljer hårdvara.

Zoner är det ni faktiskt frågar efter

Ett geofence är en polygon, och Yggio jämför varje inkommande position mot de geofences som finns. Den jämförelsen ingår inte i den väg en rapport normalt tar, så en tracker läggs på geofrågeflödet

• se Dataflöden, timers och geofences. Flödet tillhör enheten, så trackers kan köra det medan temperatursensorerna på samma connector inte gör det.

Jämförelsen ger en åtkomsthändelse:

Händelse
access: enter	Trackern gick in i ett geofence
access: inside	Den rapporterade en ny position medan den redan var inne
access: exit	Den lämnade

Logiken ligger på geofencet snarare än på trackern. Ett geofence är kopplat till en egen IoT-nod, geofence-referensnoden, och räkningen görs av en översättare på den noden. Zonen håller tillståndet, eftersom det är zonen frågan handlar om.

general-geofence är den översättaren. Vid varje åtkomsthändelse underhåller den listan över tillgångar som finns inne och producerar:

Utdata
assets	Hur många tillgångar som finns inne
trackers	Hur många av dessa som är den typ ni räknar
assetList	Allt som finns inne, med namn, id, position, våningsplan, åtkomststatus och tidsstämpel
assetUpdate	Tillgången som just gick in, lämnade eller flyttade sig

Skillnaden mellan assets och trackers är den som gör det här användbart på en verklig anläggning. En uppställningsplats kan rymma både bagagevagnar och rullstolar; påfyllnadsfrågan gäller bara vagnarna. Matchning mot ett kontextuellt fält, till exempel assetType = Baggage Cart, räknar de ni bryr er om men rapporterar fortfarande allt som finns där.

Vad en zon gör när en tillgång tystnar

En tillgång lämnar en zon bara genom att rapportera att den lämnade. En tracker vars batteri tar slut inne i en uppställningsplats skickar aldrig något exit, så utan någon annan mekanism skulle antalet glida uppåt och stanna där.

Översättaren hanterar det med två kvarhållningsfönster: tillgångar som slutar rapportera tas bort efter removeIdleAssetsAfterHours (minst 24 h), och tillgångar som lämnat tas bort efter removeExitedAssetsAfterHours. Det är värt att förstå snarare än att lämna på standardvärdet, eftersom det är det som avgör hur länge ett felaktigt antal lever kvar. Det är en självläkande mekanism, inte en korrekthetsgaranti: om en skrivning går förlorad någonstans uppströms är antalet fel tills vilofönstret löper ut.

Det finns också forwardAccuracyLimit, som bortser från händelser vars rapporterade positionsnoggrannhet är sämre än en gräns. En dålig GNSS-fix vid kanten av en polygon ger annars enter- och exit-händelser som ingenting fysiskt har gjort.

Vad som byggs ovanpå

När tillgångarna väl är vanliga Yggio-enheter med positioner och zontillhörighet är resten plattformen:

• Antal per zon i en dashboard, per uppställningsplats, fack eller våningsplan. Se Dashboards.
• Påfyllnad och eskalering via regelmotorn - en uppställningsplats under en tröskel längre än några minuter skapar en uppgift, och eskalerar om ingen kvitterar.
• En karta över var saker finns, filtrerad på typ, kontextuell parameter eller egen fråga. Se Karta. (Inte Location Manager - den är avvecklad och ska inte användas för nya installationer.)
• Utnyttjande över tid, vilket oftast är det som motiverar installationen. En tillgång som inte har rört sig på en månad är antingen trasig, undanlagd, eller ett belägg för att flottan är större än den behöver vara. Det sista är fyndet som betalar projektet.
• In i de system folk redan använder - det öppna API:et och MQTT in i ett WMS, ERP eller underhållssystem, och Grafana eller Power BI för rapportering.

De röda, gula och gröna banden i en sådan dashboard är verksamhetens egna mål snarare än något som levereras som standard, och det är det som gör en ruta värd att titta på i stället för dekorativ.

Rapportering mot en servicenivå

Där antalen är avtalade är det samma siffror som reglerar avtalet. Rapporter körs schemalagt eller vid behov som Excel, CSV eller HTML, och bär de kolumner ett serviceavtal faktiskt diskuteras utifrån: mål mot utfall, och hur länge ett område legat under mål. Se Rapporter.

Siffror mot ett överenskommet mål, snarare än enbart diagram, är den skillnad som betyder något. Samma siffror tjänar sedan tre målgrupper utan att räknas om: skiftet som ska fylla på ett område i dag, den månatliga ledningsgenomgången, och avtalsgenomgången.

Eftersom tillgångarna är vanliga enheter gäller åtkomsträttigheter som vanligt: en entreprenör som ansvarar för en terminal ser den terminalens tillgångar och ingen annans.

Att driva det i stor skala

• Namnge zoner efter platsen, inte efter enheten. Ett larm som säger "Gång 14" går att agera på; ett som säger id:t på en geofence-referensnod gör det inte.
• Följ trackerhälsan som en egen signal. Batteri och senast sedd per tracker, så att en enhet som tystnat larmas som ett fel i stället för att i tysthet snedvrida ett antal.
• Räkna med att stämma av då och då. Räknesystem som bygger på parvisa enter- och exit-händelser samlar på sig fel över lång tid, och en periodisk återställning är billigare än att försöka göra avdrift omöjlig.
• Börja med de zoner som har ett beslut kopplat till sig. Ett geofence runt hela anläggningen säger lite. Ett geofence runt platsen någon måste gå till säger om de behöver göra det.

Att komma igång

Snabbaste vägen till ett beslutsunderlag är en tillgångstyp, i ett område, ordentligt mätt.

1 - Pilot. En tillgångstyp, en byggnad eller ett terminalområde. Ett begränsat antal trackers, kontrollerad LoRaWAN-täckning, en Yggio-tenant, och den karta och de regler teamet faktiskt behöver. Mät mot en utgångsnivå som är överenskommen i förväg - söktid, utnyttjande eller svinn - eftersom en pilot utan uttalad utgångsnivå inte går att diskutera efteråt.

2 - Drift. Justera zoner, larm och rapporter tillsammans med dem som använder dem, inte i förväg. Lägg till fältflödet i mobilen: skanna, besikta, lämna över. Integrera mot befintliga system via API:et där det gör nytta, i stället för överallt på en gång.

3 - Skala. Fler tillgångstyper, fler byggnader, fler anläggningar, på samma plattform, roller och datamodell. Utplacerade trackers får nya uppgifter över luften i stället för att bytas ut, och andra områden - energi, klimat, närvaro - ansluter till samma tenant.

Det här bör finnas på plats innan piloten startar:

• De tillgångstyper som gör mest ont, och ungefär hur många enheter det rör sig om.
• En områdes- eller planritning, och en bild av befintlig Wi-Fi- och LoRaWAN-täckning.
• En driftansvarig som kan säga vad "bra" innebär.

Det sista avgör mer än hårdvaran gör.

Relaterat

• Dataflöden, timers och geofences - geofrågeflödet och åtkomsthändelserna
• Karta - var enheterna finns, filtrerat och klustrat
• Regelmotorn - att göra ett antal till en uppgift
• Rapporter - schemalagd rapportering mot en servicenivå
• Square Tracker - trackerhårdvaran
• Lagerställ - samma trackers, men med Impact-appen
• Lokalutnyttjande - att mäta ytor i stället för saker
• Internpostutdelning - behovsstyrda rundor i stället för fast schema