Skip to content

Architecture

Deze pagina beschrijft de architectuur van SensRNet zoals deze is ontworpen en wordt uitgedacht. Dit is nog steeds aan wijzigingen onderhevig, hoewel de grote lijn wel duidelijk wordt.

Deze architectuur is gebaseerd op een aantal Key Concepts.

De architectuur van SensRNet heeft een holistische benadering van het beheer van sensoren op nationaal niveau:

Holistische benadering

De 'solution' is dan ook een netwerk van deelnemers, nodes in een netwerk, waarin elk bevoegd gezag een node is met eigen applicatie en infrastructuur om het beheer van sensoren uit te voeren. Onderdeel van die infrastructuur is het standaard Component Sync dat er voor zorgt dat data gedeeld wordt in het netwerk, met alle andere nodes.

Solution

Walking skeleton

De realisatie van het SensRNet, het Nederlandse nationale sensorenregister, wordt in stappen, plateaus aangepakt. Daarbij wordt getracht zoveel mogelijk hergebruik te doen van bestaande software en systemen en is de uitvoering gericht op samenwerking. Zo wordt eerst de focus gelegd op het aantonen van het totaal in een 'zeer dunne uitvoering', een zogenaamde 'walking skeleton'.

Componenten

Components

SensRNet bestaat uit een aantal componenten:

  1. Registry Graphical User Interface (GUI) / frontend / webapp
  2. Registry backend
  3. Sync
  4. Centrale voorziening van alle sensoren op de kaart / centrale viewer

In een 'Registry Node' worden de componenten 1 en 2 uitgevoerd en component 4 bevindt zich alleen in de centrale voorziening. Component 3 draait in elke node en voorziet in de synchronisatie van data en directe koppelingen tussen alle nodes.

Component Registry

Het beheer van sensoren, de 'registry', bestaat uit twee componenten die nauw samenwerken: een frontend en backend. De backend biedt APIs aan de frontend. Voor de (geo-services) WMS/WFS is een aparte server aan dezelfde database gekoppeld.

SensRNet Registry Components

Er kunnen meerdere varianten bestaan voor de verschillende componenten voor de verschillende behoeftes van de diverse bevoegde gezagen.

Voor de basis van en/of als voorbeeld van deze twee componenten, wordt gekeken naar:

  1. Slimme apparaten van Gemeente Amsterdam (en ook Persoonsgegevensverwerking in de openbare ruimte)
  2. SensorPilot, uitgevoerd PoC in 2018 door Gemeente Eindhoven en Kadaster

Component Sync

SensRNet Sync

Sync is de synchronisatie van alle 'shared data' in het netwerk. Daarnaast biedt deze component APIs voor directe calls tussen specifieke nodes.

SensRNet Sync

  1. Synchronisatie van events van elke node met alle nodes

Events zijn de ‘core API’ in het netwerk; alle ‘shared data’ is gemodelleerd als events. De huidige situatie kan worden afgeleid door alle events ‘af te spelen’ tot nu. Alle events vormen samen de sensorenregistratie in het netwerk. Dit heeft grote overeenkomsten met een ‘event store’ in een event-sourced systeem of transacties in een distributed ledger (DLT/blockchain). Volgorde van ontstaan en het samenvoegen van de events vanuit de verschillende nodes is onderdeel van de functionaliteit.

Events zijn (oa) EigenaarGeregistreerd, SensorToegevoegd, SensorVerwijderd, SensorInfoGewijzigd, SensorVerplaatst (geo-locatie) voor de sensorenregistratie, maar mogelijk ook ‘netwerk administratie’ events als NodeToegevoegd, NodeVerwijderd, NodeAdresGewijzigd.

implementatie: MultiChain

  1. Directe API calls voor specifieke acties voor of data van een specifieke node

Voor extra informatie over een bepaalde sensor of eigenaar, kan een specifieke API aangeroepen worden op de node waar die sensor of eigenaar geregistreerd is. Voor de functionaliteit ‘contact opnemen met eigenaar’ wordt het bericht naar de node gestuurd – via een API call op die node – waar meer (private) details bekend zijn van de eigenaar van de betreffende sensor.

Environments

Een omgeving (environment) bestaat uit meerdere containers die samen een node vormen. Om deze in samenhang te kunnen draaien en om de operatie (Operations) gemakkelijk te maken, is gebruik van Kubernetes als uitgangspunt genomen voor SensRNet en omgevingen (environments).

SensRNet Environments & Containers

Details van de deployment (uitrollen) van de componenten is apart beschreven.

Test environments

Voor het testen wordt gebruik gemaakt van Kadaster infrastructuur in Azure/KadasterLabs. Daarin worden twee 'Registry nodes' opgezet die twee verschillende gemeenten simuleren. Daarnaast natuurlijk de 'Publishing node' die standaard bij Kadaster blijft draaien.

SensRNet Test Environments