Een taxonomie voor de IIoT

Koningen schaken op fijne glazen krukjes. Herinnert iemand zich dit nog?

Voor de meesten is dat waarschijnlijk wartaal. Maar niet voor mij. Dit geheugensteuntje helpt me de taxonomie van het leven te onthouden:koninkrijk, stam, klasse, orde, familie, geslacht, soort.

De breedte, diepte en verscheidenheid van het leven op aarde is overweldigend. Een taxonomie verdeelt soorten systemen logisch op basis van hun kenmerken. De Science of Biology zou onmogelijk zijn zonder een goede taxonomie. Het stelt wetenschappers in staat planten en dieren in logische typen in te delen, overeenkomsten te identificeren en regels te construeren om hele klassen van levende systemen te begrijpen.

Ook de breedte, diepte en verscheidenheid van het Industrial Internet of Things (IIoT) is overweldigend. De wetenschap van IIoT-systemen heeft een soortgelijk georganiseerde taxonomie van toepassingstypen nodig. Alleen dan kunnen we overgaan tot het bespreken van geschikte architecturen en technologieën om systemen te implementeren.

Het eerste probleem is het kiezen van divisies op het hoogste niveau. In het Dierenrijk zou je de meeste dieren kunnen bestempelen als "land-, zee- of luchtdieren". Die omgevingsbeschrijvingen helpen echter niet veel bij het begrijpen van het dier. De "architectuur" van een walvis lijkt niet veel op een octopus, maar lijkt erg op een beer. Om begrepen te worden, moeten dieren worden ingedeeld op basis van hun kenmerken en architectuur.

Het is ook niet handig om toepassingen te verdelen over hun bedrijfstakken, zoals 'medisch, transport en energie'. Hoewel deze omgevingen belangrijk zijn, zijn de toepasbare architecturen en technologieën eenvoudigweg niet verdeeld langs branchelijnen. Ook hier hebben we een dieper begrip nodig van de kenmerken die de belangrijkste uitdagingen definiëren, en die uitdagingen zullen de architectuur bepalen.

Ik realiseer me dat dit een krachtige, zelfs schokkende bewering is. Het houdt bijvoorbeeld in dat de op maat gemaakte standaarden, protocollen en architecturen in elke branche geen bruikbare manieren zijn om de toekomstige architecturen van IIoT-systemen te ontwerpen . Desalniettemin is het een duidelijk feit van de systemen in het veld. Net als bij de transformatie die het zakelijke internet werd, zullen generieke technologieën speciale benaderingen vervangen. Om ons begrip te vergroten en de belofte van het IIoT te realiseren, moeten we ons oude branchespecifieke denken opgeven.

Dus, wat kunnen we gebruiken voor divisies? Welke bepalende kenmerken kunnen we gebruiken om de zoogdieren te scheiden van de reptielen van de insecten van het IIoT?

Er zijn duizenden en duizenden vereisten, zowel functionele als niet-functionele, die kunnen worden gebruikt. Net als bij dieren, moeten we die paar vereisten vinden die de ruimte in bruikbare, grote categorieën verdelen.

De taak wordt vereenvoudigd door het besef dat het doel is om de ruimte te verdelen zodat we de systeemarchitectuur kunnen bepalen . Goede indelingscriteria zijn dus a) eenduidig ​​en b) impactvol op de architectuur. Dat klinkt misschien eenvoudig, maar het is eigenlijk heel niet-triviaal. De enige manier om het te doen is door ervaring. We zijn vroeg op onze zoektocht. Grote vooruitgang ligt echter binnen ons gezamenlijke bereik.

Op basis van RTI's uitgebreide ervaring met bijna 1000 real-world IIoT-toepassingen, stel ik hieronder een paar vroege onderverdelingen voor. Om zo scherp mogelijk te zijn, heb ik ook voor elke divisie "metrics" gekozen. De lijnen zijn natuurlijk niet zo strak. Maar de cijfers dwingen duidelijkheid, en dat is van cruciaal belang; zonder numerieke maatstaven (meterstokken?), gaat de betekenis te vaak verloren.

IIoT-taxonomievoorstel

Betrouwbaarheid [Metriek:continue beschikbaarheid moet beter zijn dan "99,999%"]

We kunnen niet tevreden zijn met de gemeenplaats "zeer betrouwbaar". Bijna alles "heeft" dat nodig. Om zinvol te zijn, moeten we specifieker zijn over de architectonische eisen om die betrouwbaarheid te bereiken. Dat vereist inzicht in hoe snel een storing problemen veroorzaakt en hoe erg die problemen zijn.

We hebben ontdekt dat de eenvoudigste en meest bruikbare manier om betrouwbaarheid te categoriseren, is door te vragen:"Wat zijn de gevolgen van een onverwacht falen van 5 minuten per jaar?" (We kiezen hier alleen voor 5 min/jr omdat dat de gouden specificatie "5-9s" is voor enterprise-class servers. Veel industriële systemen kunnen zelfs geen enkele milliseconden onverwachte downtime tolereren.)

Dit is een belangrijk kenmerk omdat het een grote invloed heeft op de systeemarchitectuur. Een systeem dat niet kan falen, zelfs voor een korte tijd, moet redundante computers, sensoren, netwerken en meer ondersteunen. Wanneer betrouwbaarheid echt cruciaal is, wordt het al snel een - of misschien wel de - belangrijkste architecturale driver.

Realtime [metrisch:respons <100 ms]

Er zijn duizenden manieren om "realtime" te karakteriseren. Alle systemen moeten "snel" zijn. Maar om nuttig te zijn, moeten we specifiek begrijpen welke snelheidsvereisten architectuur aandrijven.

Een architectuur die een menselijke gebruiker tevreden kan stellen die niet bereid is langer dan 8 seconden op een website te wachten, zal nooit voldoen aan een industriële controle die binnen 2 ms moet reageren. We vinden dat de "knie in de curve" die een grote invloed heeft op het ontwerp, optreedt wanneer de reactiesnelheid wordt gemeten in enkele tientallen milliseconden (ms) of zelfs microseconden (µs). We zullen 100ms kiezen, simpelweg omdat dat ongeveer de potentiële jitter (maximale latentie) is die door een server of broker in het datapad wordt opgelegd. Systemen die veel sneller reageren dan dit, moeten doorgaans peer-to-peer zijn, en dat is een enorme architecturale impact.

Datasetschaal [Metrisch:Datasetgrootte> 10.000 items]

Nogmaals, er zijn duizenden dimensies om te schalen, waaronder het aantal "knooppunten", het aantal toepassingen, het aantal gegevensitems en meer. We kunnen de ruimte niet delen door al deze parameters. In de praktijk zijn ze verwant. Een systeem met veel gegevensitems heeft bijvoorbeeld waarschijnlijk veel knooppunten.

Ondanks de grote ruimte hebben we geconstateerd dat twee eenvoudige vragen correleren met architecturale vereisten. De eerste is "gegevenssetgrootte", en de knie in de curve is ongeveer 10.000 items. Als systemen zo groot worden, is het niet meer praktisch om elke data-update naar elke mogelijke ontvanger te sturen. Het beheren van de gegevens zelf wordt dus een belangrijke architecturale behoefte. Deze systemen hebben een "datacentrisch" ontwerp nodig dat de gegevens expliciet modelleert, waardoor selectieve filtering en levering mogelijk wordt.

Team- of applicatieschaal [Metriek:aantal teams of interagerende applicaties>10]

De tweede schaalparameter die we kiezen is het aantal teams of onafhankelijk ontwikkelde applicaties op het "project", met een breekpunt rond de 10. Wanneer veel onafhankelijke groepen ontwikkelaars applicaties bouwen die moeten interageren, domineert data-interfacecontrole de interoperabiliteitsuitdaging. Nogmaals, dit wijst vaak op de behoefte aan een datagericht ontwerp dat deze interfaces expliciet modelleert en beheert.

Uitdaging voor het ontdekken van apparaatgegevens [Metriek:>20 soorten apparaten met datasets met meerdere variabelen]

Sommige IIoT-systemen kunnen (of moeten zelfs) vóór runtime worden geconfigureerd en begrepen. Dit betekent niet dat elke databron en sink bekend is, maar alleen dat deze configuratie relatief statisch is.

Wanneer IIoT-systemen racks en racks van machines of apparaten integreren, moeten deze echter vaak tijdens het gebruik worden geconfigureerd en begrepen. Een HMI van een fabriekscontroller kan bijvoorbeeld de apparaatkenmerken van een geïnstalleerd apparaat of rack moeten ontdekken, zodat een gebruiker gegevens kan kiezen om te bewaken. De keuze uit "20" verschillende apparaten is willekeurig. Het punt:wanneer er veel verschillende configuraties zijn voor de apparaten in een rek, wordt deze "introspectie" een belangrijke architecturale noodzaak om handmatige gymnastiek te vermijden. De meeste systemen met dit kenmerk hebben veel meer dan 20 apparaattypes.

Distributiefocus [Metrisch:uitwaaieren> 10]

We definiëren "uitwaaieren" als het aantal gegevensontvangers dat moet worden geïnformeerd bij wijziging van een enkel gegevensitem. Dit heeft gevolgen voor de architectuur omdat veel protocollen werken via enkele 1:1-verbindingen. Het grootste deel van de bedrijfswereld werkt op deze manier, vaak met TCP, een 1:1 sessieprotocol. Voorbeelden zijn het verbinden van een browser met een webserver, een telefoonapp met een backend of een bank met een creditcardmaatschappij.

IIoT-systemen moeten echter vaak informatie naar veel meer bestemmingen verspreiden. Als een enkel gegevensitem naar veel bestemmingen moet gaan, moet de architectuur efficiënte meerdere updates ondersteunen. Wanneer de fan-out groter is dan 10, wordt het onpraktisch om deze vertakking te doen door een set van 1:1-verbindingen te beheren.

Collectiefocus [Metrisch:eenrichtingsgegevensstroom met ventilator in> 100]

Systemen die in wezen beperkt zijn tot het verzamelprobleem, delen geen significante gegevens tussen apparaten. In plaats daarvan verzenden ze veel informatie om te worden opgeslagen of geanalyseerd op servers op een hoger niveau of in de cloud.

Dit heeft een enorme architectonische impact. Verzamelsystemen kunnen vaak een hub-and-spoke "concent

[1] [2] 下一页