TTAN.IO Robotics / integration model
TTAN.IO Robotics is designed to integrate with the systems already running the plant — ROS 2, DDS, PLC/MES, HMI, vendor controllers, safety systems, AI services and non-ROS robot platforms. It does not require those controls to be removed or weakened. TTAN.IO adds a separate cybersecurity decision boundary around physical action, runtime evidence and recovery.
Connectivity is not authority. Authentication is not physical authority. ALLOW is not DISPATCH.
Safety, middleware security, vendor controls and OT security remain active in their own domains. TTAN.IO consumes their evidence where useful and adds command-level physical-action governance.
Two deployment modes
TTAN.IO separates telemetry visibility from command authority. A customer can begin with evidence collection and later introduce governed dispatch without redesigning the entire robotics environment.
TTAN.IO receives controller state, ROS/DDS telemetry, PLC/MES context, provider events, network data and sensor evidence. It can correlate and reconcile what happened without being in the command path.
No physical authority is created.This mode is suitable for assessment, baseline building, anomaly analysis, incident reconstruction and pre-production validation.
When explicitly integrated inline, a requested action is normalized and checked against identity, baseline, policy, current state, execution readiness and exact command binding before the existing provider/controller path is used.
TTAN.IO governs eligibility; the existing controller still executes.Vendor adapters translate and dispatch only the already-authorized material. They do not invent or widen authority.
Where TTAN.IO sits
HMI, MES, PLC, operator application, ROS 2 node, planner, vendor cloud, script or AI service.
Source context, normalization, identity, approved behavior, policy, mission validation and bounded decision semantics.
Fresh-state checks, anti-replay, provider-path validation and binding to the exact command that may be dispatched.
ROS/DDS action path, vendor API, robot controller or industrial execution interface performs the physical operation.
Robot state, controller feedback, PLC/interlocks, ROS/DDS telemetry, vision, LiDAR, force/torque, IMU, network/provider evidence.
Evidence is collected without automatically trusting any single reporting source.
Expected, requested, authorized, executed and observed state are compared to determine what can actually be claimed.
Verified outcome, deviation, HOLD, HUMAN_REQUIRED, incident evidence or controlled recovery state.
The command path is privileged and fail-closed. The observation path is evidence-oriented and can ingest multiple independent sources. A telemetry source cannot create command authority merely because it can report robot state.
Governed dispatch pipeline
Establish who or what asked and from which trusted source context.
Bind the request to the exact robot, capabilities, tools, zones and approved behavior.
Evaluate the physical meaning of the requested action against policy and context.
Re-check current state, provider path and security preconditions immediately before dispatch.
Bind authority to the exact command material so changed parameters invalidate old authority.
Verify what really happened using controller, sensor, PLC and independent evidence.
Integration matrix
| Existing layer | TTAN.IO consumes | TTAN.IO preserves | TTAN.IO adds |
|---|---|---|---|
| ROS 2 / DDS Security | Participant identity, permissions context, protected middleware telemetry and action feedback | DDS governance, permissions, certificates, enclaves and cryptographic transport | Semantic physical-action validation and exact command authority |
| PLC / MES / HMI | Production intent, line state, interlock context and operator workflow evidence | Existing production logic and process ownership | Bounded robot mission validation and attributable command lineage |
| Safety PLC / E-stop / interlocks | Relevant safety/interlock state as evidence when available | Independent functional-safety authority | Cyber HOLD and security re-entry governance without replacing safety |
| Vendor controller / API | Controller state, capabilities, version/provider context and execution feedback | Vendor-native safety, credentials, limits, firmware and execution semantics | Provider-neutral pre-dispatch authorization and post-execution reconciliation |
| PKI / mTLS / workload identity | Authenticated peer and workload identity | Existing CA, certificate lifecycle and channel security | Separation between identity, application permission and physical authority |
| Secure boot / TPM / attestation | Trusted startup, version or attestation evidence where available | Hardware root of trust and firmware verification | Ability to make trusted platform state a condition of execution readiness |
| OT / CPS monitoring | Asset, network and anomaly context when useful | SOC, IDS, vulnerability management and network monitoring | Per-robot physical mission authority and evidence reconciliation |
| AI / agent / planner | Recommendation, plan or interpreted intent | Model remains advisory | Deterministic security boundary before any model output can become physical work |
Supported architectural patterns
TTAN.IO can consume ROS/DDS identity and telemetry while leaving DDS Security enabled. Security decisions happen above middleware transport trust.
Complement, do not replacePLC, HMI, MES and vendor-controller workflows can use the same boundary even when no model, agent or ROS participant exists.
AI not requiredAI can recommend missions, interpret perception or explain anomalies, but it cannot silently widen capability or release physical authority.
AI remains advisoryPer-robot identity, approved programs, tools, zones and cell/line context can be bound into execution decisions and evidence.
Cell-aware governanceMission, destination, zone, speed/context and observed navigation state can be treated as security-relevant execution material.
Mobile mission integrityProvider adapters may change while the security meaning of identity, capability, authority, observation and recovery stays stable.
Vendor-neutral semanticsWhy customers do not need rip-and-replace
A plant can keep its robot vendor, controller, PLC, MES, HMI, ROS 2 stack, DDS Security, safety PLC, E-stop, OT monitoring and PKI. TTAN.IO integrates around those systems rather than asking the customer to replace them.
That reduces deployment risk because existing certified or operationally mature controls keep their authority. TTAN.IO focuses on the cybersecurity decision those controls do not answer by themselves: whether this exact physical action is admissible now and what evidence proves the outcome.
Preserve every stronger control already in place. Add the missing physical-action security boundary.