Databus versus database:de 6 vragen die elke IIoT-ontwikkelaar moet stellen

n in een (waarschijnlijk gecentraliseerde) database, versus toekomstige gegevens die rechtstreeks naar de applicaties worden verzonden vanuit een gedistribueerde gegevensruimte.

Vraag 4:"De infrastructuur begrijpt, en kan daarom selectief de gegevens filteren." Geldt dat niet voor alle pub-sub, waar je je kunt inschrijven voor "evenementen" die voor jou interessant zijn?

De meeste pub-sub is erg primitief. Een applicatie "registreert interesse", en dan wordt alles gewoon naar die applicatie gestuurd. Een algoritme voor het detecteren van botsingen op kruispunten zou zich bijvoorbeeld kunnen abonneren op "voertuigposities". De infrastructuur verzendt vervolgens berichten van elke sensor die posities kan produceren, zonder kennis van de gegevens in dat bericht. Zelfs "content filtering" pub-sub biedt slechts zeer eenvoudige specificaties en vereist dat het systeem vooraf selecteert wat voor iedereen belangrijk is. Er is geen echte controle over de stroom.

Een databus is veel expressiever. Dat kruispunt zou kunnen zeggen:"Ik ben alleen geïnteresseerd in voertuigposities binnen 200 m, die met een snelheid van 10 m/s naar mij toe rijden. Als een voertuig in mijn specificaties valt, moet ik 200 keer per seconde worden bijgewerkt. U (de databus) moet mij garanderen dat alle sensoren die dit algoritme voeden, beloven gegevens zo snel te leveren...niet langzamer of sneller. Als een sensor 1000 keer per seconde wordt bijgewerkt, stuur me dan alleen elke 5e update. Ik moet ook weten dat je momenteel contact hebt met -live-sensoren (die ik definieer als produceren in de laatste 0,01sec) op alle mogelijke rijwegbenaderingen te allen tijde. Elke sensor moet 600 oude monsters kunnen opslaan (3 seconden waard), en me updaten met die oude gegevens als ik dat nodig heb het." (Dit zijn enkele van de 20+ QoS-instellingen in de DDS-standaard.)

Merk op dat een abonnementstoepassing in het primitieve pub-sub-geval erg afhankelijk is van de werkelijke eigenschappen van de producenten. Het moet er op de een of andere manier op vertrouwen dat ze leven (!), dat ze voldoende buffers hebben om de informatie die het nodig heeft op te slaan, dat ze het niet overspoelen met informatie en het ook niet te langzaam verstrekken. Als er 10.000 auto's 1000x/sec worden gedetecteerd, maar slechts 3 binnen 200 meter, zal het elke seconde 10.000*1000 =10m monsters moeten ontvangen om de 3*200 =600 te vinden waar het aandacht aan moet besteden. Het zal elke sensor 100x/seconde moeten pingen om er zeker van te zijn dat deze actief is. Als er redundante sensoren op verschillende paden zijn, moet het ze allemaal onafhankelijk pingen en op de een of andere manier ervoor zorgen dat alle paden bedekt zijn. Als er veel toepassingen zijn, moeten ze alle sensoren afzonderlijk pingen. Het moet ook het schema van de producenten kennen, enz.

De toepassing in het tweede geval ontvangt daarentegen precies de 600 monsters waar het om geeft, in de wetenschap dat er voor elk pad ten minste één sensor actief is. De stroomsnelheid is gegarandeerd. Voldoende betrouwbaarheid is gegarandeerd. De totale datastroom wordt met 99,994% verminderd (we hebben slechts 600/10 miljoen samples nodig en slimme middleware filtert bij de bron). Merk voor de volledigheid op dat het botsingsalgoritme volledig onafhankelijk is van de sensoren zelf. Het kan worden hergebruikt op elk ander kruispunt en het werkt met één sensor per pad of 17. Als het netwerk tijdens runtime te zwaar wordt belast om aan de gegevensspecificaties te voldoen (of als er iets niet werkt), wordt de toepassing onmiddellijk op de hoogte gebracht.

Vraag 5:Hoe verschilt een databus van een CEP-engine?

Kort antwoord:een databus is een fundamenteel gedistribueerd concept dat gegevens selecteert en levert van lokale producenten die voldoen aan een eenvoudige specificatie. Een CEP-engine is een gecentraliseerde uitvoerbare service die in staat is tot veel complexere specificaties, maar waarbij alle gegevensstromen naar één plek moeten worden verzonden.

Lang antwoord:een CEP-engine (Complex Event Processing) onderzoekt een inkomende gegevensstroom, op zoek naar patronen die u programmeert om deze te identificeren. Wanneer het een van die patronen vindt, kun je het programmeren om actie te ondernemen. De patronen kunnen complexe combinaties zijn van gegevens uit het verleden en inkomende toekomstige gegevens. Het is echter een enkele service die ergens op een enkele CPU draait. Het verzendt geen informatie.

Een databus zoekt ook naar datapatronen. De specificaties zijn echter eenvoudiger; het neemt beslissingen over elk gegevensitem terwijl het wordt geproduceerd. De acties zijn ook eenvoudiger; de enige actie die het kan ondernemen is om die gegevens naar een aanvrager te sturen. De kracht van een databus is dat deze fundamenteel gedistribueerd is. Het zoeken gebeurt lokaal op mogelijk honderden, duizenden of zelfs miljoenen knooppunten. De databus is dus een zeer krachtige manier om de juiste data uit de juiste bronnen te selecteren en naar de juiste plaatsen te sturen. Een databus is een soort gedistribueerde set CEP-engines, één voor elke mogelijke informatiebron, die automatisch wordt geprogrammeerd door de gebruikers van die informatie. Natuurlijk heeft de databus naast patroonovereenkomst nog vele andere eigenschappen, zoals schemabemiddeling, redundantiebeheer, transportondersteuning, een interoperabel protocol, enz.

Vraag 6:Welke applicatie dreef de DDS-standaard en databussen aan?

De vroege toepassingen waren in intelligente robots, "informatiesuperioriteit" en grote gecoördineerde systemen zoals het beheer van marinegevechten. Deze systemen hadden betrouwbaarheid nodig, zelfs wanneer componenten falen, gegevens die snel genoeg waren om fysieke processen te beheersen, en selectieve detectie en levering op schaal. Gegevensgerichtheid vereenvoudigde applicatiecode en gecontroleerde interfaces echt, waardoor teams van programmeurs in de loop van de tijd aan grote softwaresystemen konden werken. De DDS-standaard is een actieve, groeiende familie van standaarden die oorspronkelijk werd aangestuurd door zowel leveranciers als klanten. Het wordt veel gebruikt in veel branches, waaronder medische zorg, transport, slimme steden en energie.

Als je wilt weten hoe intelligente software het IIoT verovert, download dan zeker onze whitepaper over de toekomst van de auto-industrie, "The Secret Sauceof Autonomous Cars."

上一页  [1] [2]