X-Net-ATS

X-NET-ATS / ARCHITECTURE & SECURITY

Know the system.
Understand its security.

See what X-Net-ATS is made of, how its components connect, and which data and permissions need protection. Understand the links between product architecture, deployment topology and security mechanisms.

01
ArchitectureIdentify components and their responsibilities
02
TopologySee connections and information flows
03
SecurityEstablish boundaries around objects and relationships

01 / SYSTEM ARCHITECTURE

Knowledge, management and sensing.
Distinct roles. One system.

Public knowledge and field evidence meet in Platform.
Verification and confirmation create your own asset and relationship records.

Public knowledge service
X-Net-ATS Knowledge

Product knowledge / source evidence / query and match

Public, reusable knowledge
Public knowledge queries and responses
Customer environmentCustomer Data
Identify / connect / confirm / manage

Platform × N

Assets / actual topology / management records

Scoped tasksField evidence
Field sensing

Sensor × N

Collect observations by network zone.
Submit standardized evidence.

Serial numbers, site IPs, asset locations, personnel information and actual topology stay in the customer environment.

Knowledge

An independent source of public knowledge

Maintain product identities, specifications and source evidence. Provide lookups and matching through an API, with separate candidate, verification and publication states.

Managed objects: reusable product knowledge

Platform

The management center for customer facts

Manage assets, interfaces, connections, actual topology, responsibilities, permissions and audits. Turn external knowledge and field discoveries into candidates for verification.

Managed objects: customer assets and actual relationships

Sensor

A collection node for field facts

Run authorized tasks, recording collection methods, targets and times. Persist observations in a local queue before submitting them to Platform.

Managed objects: tasks, observations and local queues

02 / CONNECTION TOPOLOGY

Make connections clear.
Make trust boundaries concrete.

An example with one customer-side Platform and multiple sensors by network zone.
IT and OT connections are shown together.

People and browsersSign in / view / manage
Management access over HTTPS
PUBLIC SERVICE BOUNDARY

Knowledge

Query and matching API

Public knowledge data
Independent database and access credentials
Platform initiates queriesHTTPSKnowledge and sources return
People and browsersManagement access over HTTPS
CUSTOMER MANAGEMENT BOUNDARY

Platform

Browser endpoint / HTTPSSensor endpoint / mTLS
Application service / Go API
Customer database / PostgreSQL
Database access is limited to the application network
Sensor initiates connectionsmTLSTask polling / evidence uploads / acknowledgments
FIELD COLLECTION BOUNDARY
Sensor / IT zoneCollect within authorized scope
Sensor / OT zoneCollect within authorized scope

Persistent local queue
Clear after Platform acknowledgment

The arrow shows Sensor initiating a connection. Tasks and evidence are exchanged over that controlled channel. Network and device conditions determine field zones and collection methods.
01

Separate user access and sensor connections

Browser and Sensor endpoints handle sessions and device identities separately. Permission checks run on the server.

02

Platform connects to Knowledge

Platform initiates knowledge queries. Sensor focuses on the field, while Platform connects knowledge with observations.

03

Independent databases

Platform queries Knowledge through an API. Customer and public knowledge databases are managed separately, preserving their data boundaries.

03 / SECURITY MECHANISMS

Identity, channels, data and actions.
Each has a defined boundary.

Security mechanisms map to specific components and connections.
They govern identity verification, authorized scope, fact confirmation and audit records.

01 / IDENTITY

Each sensor has its own identity

Sensor identity derives from the device public key. Initial registration combines a one-time token with a signed device challenge. Communication certificates support renewal and revocation.

02 / CHANNELS

Verify both ends of a connection

Browser access and knowledge queries use HTTPS. Regular Sensor control connections use mTLS after registration to verify Platform and Sensor identities.

03 / PERMISSIONS

Authorize actions on the server

Platform uses session authentication, role checks and granular asset permissions. Information access and management writes are controlled separately.

04 / DATA

Keep customer facts in the customer environment

Knowledge queries submit only the minimum information needed for product identification. Asset IDs, personnel, precise locations and actual topology stay in the customer environment.

05 / FACTS

Separate observations from authoritative records

Field discoveries first create evidence and candidates. Operators verify them before adding them to the inventory. External knowledge is applied after reviewing differences and sources.

06 / TRACEABILITY

Record identity and management actions

Sensor registration, renewal, revocation and asset changes are auditable. Observations retain sources, tasks, collection times and methods as verification evidence.

From field evidence to trusted records

Retain what was observed, the supporting evidence and who confirmed it.

  1. 01CollectDefine tasks and scope
  2. 02PersistLocal queue and Platform acknowledgments
  3. 03InterpretConnect knowledge and sources
  4. 04ConfirmVerify objects and relationships
  5. 05RecordCreate authoritative customer records

This page describes product architecture and implemented mechanisms. Collection protocols, adapters and extended capabilities evolve with product versions.

X-NET-ATS

Clear objects. Visible relationships. Security grounded in evidence.

Knowledge-driven / Distributed sensing / Intelligent management

Explore the products