Alusta

Federoitu NGSI-LD-kontekstikerros käytäntöjen valvonnalla ja data-avaruuden konnektoreilla, sovittimet järjestelmiin joita jo ajatte, ja datamallit jotka säilyttävät merkityksensä niiden kaikkien läpi.

Kontekstikerros

Jokainen liittämänne järjestelmä pitää oman tietokantansa. Niiden yläpuolella ajamme NGSI-LD context brokeria, joka pitää yhtä kuvausta jokaisesta todellisesta asiasta: kadusta, sähköasemasta, anturista, huoneesta. Sovelluksenne kysyvät sitten brokerilta yhden kysymyksen sen sijaan että kysyisivät kahdeltatoista järjestelmältä kaksitoista eri kysymystä.

NGSI-LD-entiteetti kantaa ominaisuutensa, suhteensa ja @context-määrittelynsä. Se riittää siihen, että kysely kuten “jokainen lämpötila-anturi tällä alueella ja rakennus johon se kuuluu” ylittää järjestelmärajat ilman tilaisuutta varten kirjoitettua liimakoodia.

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"]
}
Yksi katuvalo NGSI-LD-entiteettinä: tila, sijainti ja suhde tiehen jonka varrella se seisoo.

Kolme tapaa liittää sovellus

Se, missä data asuu saapumisensa jälkeen, ratkaisee kuinka paljon kahdennusta ja synkronointia projekti kantaa, joten lajittelemme jokaisen sovelluksen yhteen kolmesta tyypistä ennen kuin mitään rakennetaan.

  • Tilaton. Sovellus ei pidä omaa dataa. Se lukee brokerilta ja kirjoittaa sinne takaisin, ja broker on ainoa totuuden lähde.
  • Osittainen kopio. Sovellus tarvitsee osajoukon entiteeteistä omaan tietokantaansa, kokotekstihakua tai raskasta analyysia varten, johon brokeria ei ole rakennettu. Pidämme tuon osajoukon synkassa ja dokumentoimme mitä kopioidaan.
  • Sovelluksen omistama. Sovellus puhuu jo NGSI-LD:tä ja pitää datansa. Broker pitää rekisteröinnin, joka osoittaa siihen, ja välittää osuvat kyselyt, joten toimittajan järjestelmä liittyy alustaan ilman että mitään tallennetaan kahdesti.

Miten brokerit jakavat

Yhtä brokeria koko organisaatiolle harvoin hyväksytään. Osastot omistavat datansa ja ovat varovaisia sen luovuttamisessa, mikä on järkevää. Siksi brokerit rekisteröityvät toisilleen kontekstilähteinä: kysely saapuu yhdelle brokerille, matkaa eteenpäin sille brokerille tai sovittimelle joka nuo entiteetit omistaa, ja palaa yhtenä yhdistettynä vastauksena.

Vesilaitos pitää tietokantansa ja pääsysääntönsä. Kaupungin näkymä näyttää silti vesidataa liikennelaskentojen vieressä. Tarkistamme ettei mitään kopioitu sen sijaan että oletamme sen: sama kysely rajattuna paikallisesti tallennettuihin entiteetteihin palauttaa vain sen mitä kyseinen broker omistaa.

kysely yksi vastaus Liikenne context broker pitää omat tietonsa rekisteröity kontekstilähteeksi Vesi context broker pitää omat tietonsa Energia context broker pitää omat tietonsa
Kysely saapuu yhdelle brokerille ja siihen vastaavat kaikki kolme. Mitään tietoa ei kopioitu.

Kuka näkee mitä

NGSI-LD jättää pääsynvalvonnan tarkoituksella standardin ulkopuolelle. Me lisäämme sen yhdyskäytävään brokerin eteen. Jokainen sääntö nimeää subjektin, toiminnon, resurssin ja ehdon: tämä kumppani saa kysyä näitä entiteettityyppejä tällä alueella. Yhdyskäytävä tarkistaa jokaisen pyynnön käytäntömoottoria vasten, ja jos moottoriin ei saada yhteyttä, pyyntö evätään sen sijaan että se päästettäisiin läpi.

Jaetun kaksosen kannalta ratkaisevaa on, miten sääntö pannaan täytäntöön. Yhdyskäytävä ei suodata vastausta jälkikäteen. Se kirjoittaa kyselyn uusiksi ennen kuin broker näkee sen, niin että kysely voi osua vain entiteetteihin joihin kutsujalla on oikeus, kirjoittipa kutsuja mitä tahansa. Kumppani, joka pyytää aluetta jota se ei saa lukea, saa sallitun osajoukon eikä mitään muuta, ja vastaus on yhä tavallinen NGSI-LD-vastaus. Muokkaamattomat asiakkaat sen takana jatkavat toimintaansa.

Organisaatioiden välillä

Yhden organisaation sisällä brokerien välinen federaatio riittää. Kaupungin ja sen maakunnan välillä, tai laitoksen ja sen verkkoyhtiön, omistaja haluaa sopimuksen ennen kuin ensimmäinen tavu liikkuu. Jokainen organisaatio ajaa Dataspace Protocol -konnektoria brokerinsa vierellä. Kuluttajan konnektori pyytää katalogin, neuvottelee tarjouksen ja saa siirtopäätepisteen; brokerin federaatio osoittaa sitten tuohon päätepisteeseen eikä suoraan vastapuoleen.

Neuvottelu tapahtuu kerran suhdetta kohti ja vie muutaman sekunnin. Sen jälkeen federoitu kysely konnektorin läpi maksaa yhden entiteetin osalta 2 ms enemmän kuin pelkkä brokerien välinen federaatio ja kymmenen osalta 4 ms, mitattuna kolmen organisaation välillä laajaverkon yli. Suvereniteetti ei ole se, mikä tekee federaatiosta kallista.

Sovittimet ja datan sisäänluku

Suurin osa työstä missä tahansa projektissa on brokerin alapuolella.

  • IoT ja telemetria: MQTT-, LoRaWAN- ja OPC UA -syötteet, normalisoituina entiteeteiksi ja päivitettyinä mittausten saapuessa. Joukkoliikenteen syöte, jossa noin 400 ajoneuvoa ja yksi viesti ajoneuvoa kohti sekunnissa, on tavallinen kuorma.
  • Paikkatieto: WFS-, GeoJSON- ja PostGIS-tasot, niin että entiteetit säilyttävät oikean geometrian eivätkä pelkkää koordinaattiparia.
  • Anturihavainnot: OGC SensorThings ja STA-yhteensopivat palvelut aikasarjoille.
  • Rekisterit ja tiedostot: omaisuustietokannat, CSV-viennit, BIM- ja IFC-poiminnat, kiinteistörekisteritiedot.
MQTT LoRaWAN OPC UA SCADA WFS · PostGIS GeoJSON SensorThings STA CSV · IFC BIM Sovitin normalisoi NGSI-LD entiteettejä, kyselyvalmiina
Mikä kontekstia ruokkii: protokollat sisään, NGSI-LD-entiteetit ulos.

Mallit jotka säilyttävät merkityksensä

Entiteetti matkaa järjestelmien välillä vain jos molemmat tarkoittavat sillä samaa. Rakennamme julkaistujen Smart Data Models -mallien päälle siellä missä ne sopivat ja laajennamme niitä siellä missä eivät, ja jokainen laajennus kirjataan osana toimitusta. Syntyvät JSON-LD-kontekstit ovat teidän, versioitte niitä kuten mitä tahansa artefaktia ja otatte ne mukaanne.

Sopu mallin IRI:stä on se joka tekee työn. Kun kaksi organisaatiota julkaisi saman PM2.5-lukeman eri attribuuttinimillä, kumpikin kytkettynä jaettuun malliin, kuluttaja sai molemmat yhden avaimen alta ilman käännöskoodia matkalla. Attribuutti jota kukaan ei ollut kytkenyt jäi erilleen, mikä on oikea lopputulos: alusta näyttää sanastoaukon sen sijaan että piilottaisi sen.

Miten sitä ajetaan

Pino on avointa lähdekoodia: Scorpio context brokerina, Apache APISIX ja Open Policy Agent valvontaan, Keycloak identiteettiin, Eclipse Dataspace Components -jakelu konnektorina, kaikki Kubernetesin päällä. Se ajaa teidän klusterissanne, hallitussa klusterissa valitsemallanne EU-alueella, tai yhdellä palvelimella pilottia varten. Saatte asennuksen koodina, mallit, sovittimet ja käsikirjan, joka on kirjoitettu jollekulle joka ei ollut projektissa. Vaihtakaa meidät myöhemmin ja kaikki jatkaa toimintaansa.

Mitä ei vielä ole

Kuulette sen mieluummin meiltä. Federoidut kyselyt kattavat kumppanin entiteettien nykytilan; niiden historia täytyy yhä replikoida ennen kuin sen voi piirtää kuvaajaksi. Kirjoittaminen kumppanin kaksoseen sopimuksen nojalla on suunniteltu mutta ei vielä toimitettu, joten tänään kumppani lukee. Jatkuvassa ohjelmallisessa kuormassa federoitu reitti tarjoaa noin neljänneksen suoran kyselyn läpimenosta, mikä on paljon enemmän kuin näkymät tarvitsevat ja hyvä tietää ennen kuin päälle laitetaan julkinen rajapinta.

Mitä jätämme muille

Emme myy kaksosia, näkymiä emmekä laitteita. Visualisointi menee sille työkalulle, jonka tiiminne muutenkin avaavat aamulla, ja me ojennamme sille yhdistetyn kontekstin josta piirtää.

Kysy järjestelmistänne