PL

Platforma

Federacyjna warstwa kontekstu NGSI-LD, adaptery do systemów, które już prowadzicie, i modele danych, które zachowują między nimi znaczenie.

Warstwa kontekstu

Każdy podłączony system dalej trzyma własną bazę danych. Nad nimi działa context broker NGSI-LD, który ma jeden opis każdej realnej rzeczy: ulicy, stacji transformatorowej, czujnika, pomieszczenia. Wasze aplikacje zadają wtedy brokerowi jedno pytanie, zamiast zadawać dwanaście pytań dwunastu systemom.

Encja NGSI-LD niesie swoje właściwości, swoje relacje i swój @context. To wystarczy, żeby zapytanie w rodzaju „każdy czujnik temperatury w tej dzielnicy i budynek, do którego należy” przeszło przez granice systemów bez kodu sklejającego pisanego na jedną okazję.

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"]
}
Latarnia uliczna jako encja NGSI-LD: stan, lokalizacja i relacja do ulicy, przy której stoi.

Jak brokery podają sobie dane

Jeden broker na całą organizację rzadko zostaje uzgodniony. Wydziały są właścicielami swoich danych i wypuszczają je ostrożnie, co jest zrozumiałe. Brokery rejestrują się więc nawzajem jako źródła kontekstu: zapytanie trafia do jednego brokera, wędruje do tego, który trzyma dane encje, i wraca jako jedna scalona odpowiedź.

Wodociągi zachowują swoją bazę i swoje reguły dostępu. Miejski dashboard i tak pokazuje ich dane obok pomiarów ruchu.

zapytanie jedna odpowiedź Transport context broker dane zostają u niego zarejestrowany jako źródło kontekstu Woda context broker dane zostają u niego Energia context broker dane zostają u niego
Zapytanie trafia do jednego brokera, a odpowiadają wszystkie trzy. Żadne dane nie zostały skopiowane.

Adaptery i pobieranie danych

W każdym projekcie większość pracy leży poniżej brokera.

  • IoT i telemetria: strumienie MQTT, LoRaWAN i OPC UA, normalizowane do encji i aktualizowane w miarę napływu pomiarów.
  • Dane przestrzenne: warstwy WFS, GeoJSON i PostGIS, żeby encje miały prawdziwą geometrię, a nie parę współrzędnych.
  • Obserwacje czujników: OGC SensorThings i usługi zgodne z STA dla szeregów czasowych.
  • Rejestry i pliki: bazy majątku, eksporty CSV, wyciągi BIM i IFC, dane katastralne.
  • Historia: zapytania temporalne odpowiadają, jak bliźniak wyglądał w zeszły wtorek, nie tylko jak wygląda teraz.
MQTT LoRaWAN OPC UA SCADA WFS · PostGIS GeoJSON SensorThings STA CSV · IFC BIM Adapter normalizuje NGSI-LD encje, odpytywalne
Co zasila kontekst: protokoły do środka, encje NGSI-LD na zewnątrz.

Modele, które zachowują znaczenie

Encja przechodzi między systemami tylko wtedy, gdy oba rozumieją przez nią to samo. Opieramy się na opublikowanych smart data models tam, gdzie pasują, i rozszerzamy je tam, gdzie nie pasują; każde rozszerzenie zostaje zapisane jako część dostawy. Powstałe konteksty JSON-LD są wasze, wersjonujecie je jak każdy inny artefakt i zabieracie ze sobą.

Utrzymanie

Stos jest open source. Działa na waszym Kubernetesie, na zarządzanym klastrze w wybranym regionie UE albo na jednym serwerze dla pilota. Dostajecie wdrożenie jako kod, modele, adaptery i runbook napisany dla kogoś, kogo w projekcie nie było. Jeśli później nas wymienicie, wszystko działa dalej.

Co zostawiamy innym

Nie sprzedajemy bliźniaków, dashboardów ani urządzeń. Wizualizacja należy do narzędzia, które wasze zespoły i tak otwierają rano, a my podajemy mu połączony kontekst do rysowania.

Zapytajcie o swoje systemy