RTLS voor IT en OT.

RTLS-implementaties falen voor de beveiligingsbeoordeling wanneer ze als IT-projecten worden behandeld in plaats van OT-projecten.

Het juiste uitgangspunt is een Purdue-modelbewuste architectuur: waar staan de anchors, gateways en middleware? Welke zone? Welke leidingen? Moderne RTLS-platforms ondersteunen IEC 62443-georiënteerde segmentatie,

wederzijdse TLS, rolgebaseerde toegang en auditlogging, maar alleen wanneer het vanaf gate 1 is ontworpen.

Het achteraf inbouwen van beveiliging nadat de architectuur is ondertekend kost meer dan herontwerpen.

Locatiegegevens zijn van nature gevoelig: het kan personeel identificeren, proceskennis blootleggen en regelgeving blootstellen (AVG, bedrijfsraad).

Het rechter controlevlak scheidt ruwe positietelemetrie van afgeleide analyses, past rolgebaseerde toegang toe op de API-laag en registreert elke query.

De standaardinstellingen op de meeste leveranciersplatforms zijn verkeerd voor Europese bedrijfscontexten. Ze hebben expliciete afstelling nodig.

Drie integratiepatronen werken op ondernemingsniveau: streaming (MQTT of Kafka voor hoogfrequente positiegebeurtenissen in een digitale tweeling of analyselaag),

API-gedreven (REST of gRPC voor de WMS, MES of EMR om locatie op aanvraag te halen), en ESB-gemedieerd (waarbij je al een enterprise servicebus draait, MuleSoft, Boomi).

Het verkeerde patroon vergrendelt je in het datamodel van de leverancier. Wij ontwerpen voor het patroon dat jouw stack al gebruikt.

Moderne inkoop vereist SBOM-, SOC 2- of ISO 27001-attestatie en patchbeheerverplichtingen van RTLS-leveranciers. Niet alle leveranciers voldoen aan die norm, en degenen die dat wel doen, zijn niet altijd de technisch sterkste.

We voeren leverancierscontrole uit op jouw specifieke beveiligingspositie (vaak direct met je CISO) en stellen een scorecard op die bestand is tegen een beoordeling door derden.

IT and OT jointly own whether locating stays maintainable. Criteria:

• Gedeelde RACI: wie gateways patcht, wie eigenaar is van certificaten en wie wijzigingsvensters goedkeurt.
• Eerst segmenteren: aparte paden waar het risico dat vraagt; BLE of Wi-Fi op bestaande apparatuur alleen met een expliciete risicoacceptatie.
• Integration patterns that scale: normalized location events into MES/WMS/ERP/EHS via APIs or brokers, not one-off scripts.
• Exitpakket: inloggegevens, revisietekeningen, tagregisters en data-exports blijven van jou.

Suppliers pitch single-pane platforms. SIs pitch turnkey installs. Enterprise architects should buy a locating data layer that can survive a hardware swap.

• Unclear ownership between IT networking and OT engineering after go-live.
• Puntintegraties die breken bij versie-upgrades van de leverancier.
• Spectrum and channel plans ignored until production interference appears.
• Identity tied to supplier cloud tenancy with no enterprise IdP.
• No capacity model for tag and event growth across sites.

• Document the reference architecture for our Purdue zones and identity provider.
• Welke open protocollen en exportformaten krijgen we vanaf dag één?
• Who supports firmware, certificates and reader health after warranty, named SLA?
• How do you deduplicate and time-order events before they hit MES/WMS?
• What is the migration path if we change radio suppliers in year three?

TRACIO delivers buyer-side architecture and programme governance for locating (RF survey, segmentation, integration design and supplier scrutiny) without a hardware or platform SKU. We keep both sides of the IT/OT split in a single RACI the steering group can audit.