Platformă

Stratul de context

Fiecare sistem pe care îl conectați își păstrează propria bază de date. Deasupra lor rulăm un context broker NGSI-LD care ține o singură descriere a fiecărui lucru real: o stradă, o stație de transformare, un senzor, o încăpere. Aplicațiile dumneavoastră pun apoi brokerului o singură întrebare, în loc să pună la douăsprezece sisteme douăsprezece întrebări diferite.

O entitate NGSI-LD își poartă proprietățile, relațiile și @context-ul. Atât e de ajuns pentru ca o interogare de tipul „fiecare senzor de temperatură din acest cartier și clădirea de care aparține" să traverseze granițele sistemelor fără cod de lipit scris pentru ocazie.

GET /ngsi-ld/v1/entities/urn:ngsi-ld:Streetlight:BB-1042

{
  "id": "urn:ngsi-ld:Streetlight:BB-1042",
  "type": "Streetlight",
  "powerState": { "type": "Property", "value": "off",
                    "observedAt": "2026-08-30T19:04:00Z" },
  "location": { "type": "GeoProperty",
                 "value": { "type": "Point", "coordinates": [19.146, 48.736] } },
  "refRoadSegment": { "type": "Relationship",
                       "object": "urn:ngsi-ld:RoadSegment:BB-Nam-SNP" },
  "@context": ["https://smartdatamodels.org/context.jsonld"]
}

Un stâlp de iluminat ca entitate NGSI-LD: o stare, o poziție, o relație cu drumul lângă care stă.

Trei feluri în care se conectează o aplicație

Locul unde stau datele odată ajunse decide câtă duplicare și sincronizare cară un proiect, așa că încadrăm fiecare aplicație într-unul din trei tipuri înainte să se construiască ceva.

Fără stare. Aplicația nu ține date proprii. Citește din broker și scrie înapoi în el, iar brokerul este singura sursă de adevăr.
Copie parțială. Aplicația are nevoie de un subset de entități în propria bază de date, pentru căutare full-text sau analiză grea pentru care brokerul nu este construit. Ținem acel subset sincronizat și documentăm ce se copiază.
În proprietatea aplicației. Aplicația vorbește deja NGSI-LD și își ține datele. Brokerul ține o înregistrare care arată spre ea și transmite interogările potrivite, așa că un sistem de furnizor se leagă la platformă fără ca nimic să fie stocat de două ori.

Cum împart brokerele

Un singur broker pentru toată organizația rar este acceptat. Departamentele sunt proprietarele datelor lor și sunt atente când le predau, ceea ce este rezonabil. Așa că brokerele se înregistrează unele la altele ca surse de context: o interogare ajunge la un broker, călătorește mai departe la brokerul sau adaptorul care ține acele entități și se întoarce ca un singur răspuns unit.

Compania de apă își păstrează baza de date și regulile de acces. Un panou al orașului arată în continuare datele de apă lângă numărătorile de trafic. Verificăm că nu s-a copiat nimic, în loc să presupunem: aceeași interogare restrânsă la entitățile stocate local returnează doar ceea ce deține acel broker.

O interogare ajunge la un broker și răspund toate trei. Niciun dat nu a fost copiat.

Cine ce vede

NGSI-LD lasă intenționat controlul accesului în afara standardului. Noi îl adăugăm în poarta din fața brokerului. Fiecare regulă numește un subiect, o acțiune, o resursă și o condiție: acest partener poate interoga aceste tipuri de entități în acest domeniu. Poarta verifică fiecare cerere față de motorul de politici, iar dacă motorul nu poate fi contactat, cererea este refuzată în loc să fie lăsată să treacă.

Pentru un geamăn partajat contează cum este aplicată regula. Poarta nu filtrează răspunsul după aceea. Rescrie interogarea înainte ca brokerul să o vadă, astfel încât interogarea să poată potrivi doar entități la care apelantul are dreptul, orice ar fi scris apelantul. Un partener care cere un domeniu pe care nu are voie să îl citească primește subsetul permis și nimic altceva, iar răspunsul rămâne un răspuns NGSI-LD obișnuit. Clienții nemodificați din spate continuă să funcționeze.

Între organizații

În interiorul unei organizații, federarea între brokere este de ajuns. Între un oraș și regiunea sa, sau o uzină și compania sa de utilități, proprietarul vrea un contract înainte să se miște primul octet. Fiecare organizație rulează un conector Dataspace Protocol lângă brokerul său. Conectorul consumatorului cere catalogul, negociază oferta și primește un punct de transfer; federarea brokerului arată apoi spre acel punct, nu direct spre partea cealaltă.

Negocierea are loc o dată pentru fiecare relație și durează câteva secunde. După aceea, o interogare federată prin conector costă cu 2 ms mai mult decât federarea simplă între brokere pentru o entitate și cu 4 ms pentru zece, măsurat între trei organizații peste o rețea de arie largă. Nu suveranitatea face federarea scumpă.

Adaptoare și preluarea datelor

Cea mai mare parte a muncii în orice proiect stă sub broker.

IoT și telemetrie: fluxuri MQTT, LoRaWAN și OPC UA, normalizate în entități și actualizate pe măsură ce sosesc măsurătorile. Un flux de transport public cu circa 400 de vehicule și un mesaj pe vehicul pe secundă este o sarcină obișnuită.
Geospațial: straturi WFS, GeoJSON și PostGIS, astfel încât entitățile să păstreze geometrie reală, nu doar o pereche de coordonate.
Observații de la senzori: OGC SensorThings și servicii compatibile STA pentru serii de timp.
Registre și fișiere: baze de date de active, exporturi CSV, extrase BIM și IFC, înregistrări cadastrale.

Ce alimentează contextul: protocoale înăuntru, entități NGSI-LD afară.

Modele care își păstrează sensul

O entitate călătorește între sisteme doar dacă amândouă înțeleg același lucru prin ea. Construim pe modelele Smart Data Models publicate acolo unde se potrivesc și le extindem acolo unde nu, iar fiecare extindere este scrisă ca parte a livrării. Contextele JSON-LD rezultate sunt ale dumneavoastră, le versionați ca pe orice alt artefact și le luați cu dumneavoastră.

Acordul asupra unui IRI de model este cel care face treaba. Când două organizații au publicat aceeași citire PM2.5 sub nume de atribut diferite, fiecare mapată la modelul comun, un consumator le-a primit pe amândouă sub o singură cheie, fără cod de traducere pe drum. Un atribut pe care nu îl mapase nimeni a rămas separat, iar acesta este rezultatul corect: platforma arată golul din vocabular în loc să îl ascundă.

Cum se operează

Stiva este open source: Scorpio ca context broker, Apache APISIX și Open Policy Agent pentru aplicarea politicilor, Keycloak pentru identitate, o distribuție Eclipse Dataspace Components ca conector, totul pe Kubernetes. Rulează pe clusterul dumneavoastră, pe un cluster gestionat într-o regiune UE aleasă de dumneavoastră, sau pe un singur server pentru un pilot. Primiți implementarea ca și cod, modelele, adaptoarele și un manual scris pentru cineva care nu a fost în proiect. Înlocuiți-ne mai târziu și totul continuă să meargă.

Ce nu există încă

Preferăm să auziți de la noi. Interogările federate acoperă starea curentă a entităților unui partener; istoricul lor tot trebuie replicat înainte de a putea fi desenat pe grafic. Scrierea în geamănul unui partener pe bază de contract este proiectată, dar încă nelivrată, așa că azi un partener citește. Sub sarcină programatică susținută, calea federată servește circa un sfert din debitul unei interogări directe, ceea ce este mult peste ce au nevoie panourile și merită știut înainte să puneți un API public deasupra.

Ce lăsăm altora

Nu vindem gemeni, panouri sau dispozitive. Vizualizarea merge către unealta pe care echipele dumneavoastră o deschid oricum dimineața, iar noi îi dăm un context unit din care să deseneze.