1. Can Your IT Team Access the Linux/Android Kernel?

In China-supplied AGV systems, OS access is typically divided into three tiers:

Tier 1 — Closed System (very common in mid-range AGVs)

• No kernel access

• No SSH root access

• No system-level customization

• Only vendor UI / RCS interface

✔ Stable and safe
❌ Very limited flexibility

👉 This is a “black-box robot OS” model.

Tier 2 — Semi-Open System (industrial-grade AMRs)

• Linux OS partially exposed

• SSH access (sometimes restricted)

• Limited sudo privileges

• Core drivers locked

✔ IT can integrate monitoring tools
✔ Moderate flexibility
❌ Kernel modifications blocked

Tier 3 — Fully Open Industrial PC (high-end platforms)

• Full Linux access

• Kernel visibility

• Docker / container support

• Custom services allowed

✔ Maximum flexibility
❌ Higher responsibility on IT integration

Key takeaway

👉 Kernel access is not purely technical — it is a contract + product tier decision.

2. Do You Get Root Access?

In most AGV deployments:

Why vendors restrict root access

Because AGVs are safety-critical systems:

• Navigation stack

• Safety laser system

• Motion controller synchronization

Improper changes may lead to:

❌ Safety failure
❌ Certification invalidation
❌ System instability

Typical compromise model

• Application-layer access → allowed

• Core motion & safety layer → locked

3. Can You Install Custom Security Software?

Depends on system openness.

Usually allowed

• ✔ Linux user-space applications

• ✔ Monitoring agents

• ✔ Log collectors

• ✔ VPN clients (in some cases)

Usually NOT allowed

• ❌ Navigation kernel modifications

• ❌ Safety PLC logic changes

• ❌ Motion controller firmware replacement

4. Can You Use SNMP to Monitor AGV System Resources?

Yes — but only if supported by the vendor.

Option A — Native SNMP (best case)

Direct exposure of:

• CPU usage

• Memory usage

• Network status

• Battery status

Option B — RCS-level monitoring (most common)

• Metrics pushed to RCS server

• IT accesses via API/dashboard

Option C — Custom agent installation

If OS allows:

• Prometheus exporter

• Zabbix agent

• node_exporter

Important limitation

👉 SNMP is NOT standard unless explicitly required in procurement specs.

5. How Security Patching Is Usually Done (RCS + Robot OS)

There are three operational models:

Model 1 — Vendor-managed updates (most common)

• OTA updates via RCS

• Scheduled maintenance windows

• Signed patch packages

✔ Safe
❌ Limited control

Model 2 — Semi-managed updates

• Vendor provides patch package

• IT deploys on-site

• Rollback supported

✔ Balanced approach

Model 3 — Full IT-managed patching (rare)

• Vendor provides binaries only

• IT manages deployment pipeline

✔ Maximum control
❌ Higher operational risk

What gets patched

• RCS application

• Navigation logic

• Wi-Fi stack

• Linux kernel (rare)

6. Important Reality: ROS vs RCS

Many buyers confuse:

• ROS (Robot Operating System) → open-source framework

• RCS (Robot Control System) → proprietary fleet management

Reality in Chinese AGVs

• ❌ Not full ROS-based control

• ✔ ROS-inspired middleware architecture

👉 Patching is done at RCS level, not kernel-level ROS changes.

7. Will Modifying Internal Software Void Warranty?

In most contracts: YES

Actions that may void warranty

• OS image modification

• Unauthorized root access changes

• Navigation module replacement

• Safety logic alteration

Typically allowed (enterprise agreements)

• ✔ Network configuration

• ✔ VLAN/firewall setup

• ✔ Monitoring agents

• ✔ Integration middleware

Critical distinction

8. What You SHOULD Negotiate Upfront

If IT integration is important, require:

A. Open Integration Mode

• SSH access (controlled)

• API access

• Container support

B. Monitoring Interfaces

• SNMP (if possible)

• Prometheus endpoint

• REST telemetry API

C. Patch Policy Clarity

• Update frequency

• Rollback mechanism

• Approval workflow

D. Warranty-safe boundaries

Explicitly define:

• ✔ Allowed modifications

• ❌ Forbidden modifications

9. Real-World Best Practice (Enterprise Deployments)

Most large warehouses adopt this structure:

On AGV (robot layer)

• Locked OS

• Minimal local services

• Secure monitoring agent only

On RCS server (control layer)

• Full monitoring stack

• API integration

• Logging + analytics

• Dashboard systems

Why this works

• Robots remain stable and certified

• IT retains full visibility at system level

• Maintenance is centralized

Bottom Line

• Full kernel/root access → rare unless negotiated

• SNMP support → possible but not standard

• Security patching → usually vendor-controlled

• Modifications → often void warranty if touching core OS

Best architecture

👉 Keep AGVs locked and stable
👉 Extend IT control through RCS-level APIs and monitoring