SDS Networking
Software-Defined Systems (SDS) depend on predictable, secure, and high-bandwidth networks. Vehicles, robots, depots, microgrids, and industrial lines all require low-latency control traffic and bulk data flows to share the same physical network without interfering with safety-critical behavior.
This page focuses on in-asset and on-site networks, with an emphasis on Ethernet, Time-Sensitive Networking (TSN), and their relationships to legacy buses such as CAN, LIN, and fieldbuses.
Networking Roles in SDS
Networks in SDS do three main jobs: carry control signals, stream sensor data, and move configuration and telemetry.
| Role | Description | Examples |
|---|---|---|
| Control traffic | Low-latency, often periodic messages | Motor commands, inverter setpoints, PLC IO signals |
| Sensor and perception data | High-bandwidth streams | Cameras, radar, lidar, high-rate metering |
| Configuration and OTA | Less frequent, larger payloads | Firmware images, configurations, model updates |
| Telemetry and logs | Event and timeseries data for observability | Health metrics, fault reports, usage statistics |
Legacy Buses vs Ethernet
Legacy buses remain important, but Ethernet and TSN are now the backbone for SDS.
| Bus / Network | Characteristics | Typical Use |
|---|---|---|
| CAN / CAN FD | Robust, low-speed, message-based | Vehicle ECUs, BMS, actuators |
| LIN | Very low-speed, low-cost | Simple actuators, switches, comfort features |
| Classical fieldbuses (Profibus, DeviceNet, etc.) | Industrial serial and bus-based networks | Legacy factory IO and drives |
| Ethernet (non-TSN) | High bandwidth, best-effort delivery | Infotainment, non-critical monitoring, bulk transfers |
| TSN-enabled Ethernet | Deterministic timing on Ethernet | Control loops, synchronized drives, mixed-criticality traffic |
Time-Sensitive Networking (TSN) Basics
TSN is a family of IEEE standards that bring determinism and quality-of-service guarantees to Ethernet, allowing time-critical and best-effort traffic to coexist on the same network.
| TSN Capability | Purpose | Example Standards |
|---|---|---|
| Time synchronization | Align clocks across devices with sub-microsecond accuracy | IEEE 802.1AS |
| Traffic shaping | Control how frames are queued and transmitted | IEEE 802.1Qav, 802.1Qbv |
| Resource reservation | Reserve bandwidth for critical flows | IEEE 802.1Qat, 802.1Qcc |
| Frame preemption | Allow high-priority frames to interrupt lower-priority frames | IEEE 802.1Qbu, 802.3br |
Network Design Patterns in SDS
SDS networks are typically organized in layers, similar to SDS compute and control architectures.
| Layer | Function | Examples |
|---|---|---|
| Device / field layer | Connect sensors, actuators, and local controllers | CAN, LIN, IO-link, low-level Ethernet segments |
| Zonal / cell layer | Aggregate traffic from local devices | Zonal controllers, robot cells, microgrid segments |
| Backbone layer | Provide high-bandwidth links for critical and non-critical traffic | TSN-capable Ethernet switches and links |
| Site and WAN layer | Connect assets and sites to central systems | Industrial Ethernet, fiber, 5G, SD-WAN |
Quality of Service (QoS) and Mixed-Criticality
To safely share one network among multiple traffic types, QoS and traffic classes must be defined explicitly.
| Traffic Class | Requirements | Typical Payloads |
|---|---|---|
| Hard real-time control | Bounded latency and jitter, very low loss | Drive control, braking, protection relays, robot joint control |
| Soft real-time monitoring | Low latency but tolerant of some loss | Health metrics, status updates, production counters |
| Bulk data and OTA | High throughput, tolerant of latency | Firmware downloads, batch logs, model transfers |
| Non-critical IT traffic | Best-effort, lower priority | Operator web access, file transfers, email |
Security and Segmentation
Networks in SDS cross safety and trust boundaries. Segmentation and security are mandatory.
| Technique | Purpose | Examples |
|---|---|---|
| Network segmentation | Limit blast radius of faults or intrusions | Separate safety domains, DMZs for external access |
| Firewalls and gateways | Control traffic between domains | Vehicle secure gateways, OT/IT boundary firewalls |
| Encryption and authentication | Protect data and verify endpoints | TLS, IPsec, device certificates |
| Monitoring and IDS | Detect abnormal behavior | CAN intrusion detection, OT network monitoring |
Network Design Questions for SDS
Effective SDS network design starts with a small set of practical questions.
| Question | Design Impact |
|---|---|
| What traffic truly needs hard real-time guarantees? | Determines which flows use TSN features vs best-effort paths |
| How will you isolate safety-critical domains? | Drives segmentation, gateway design, and firewall policies |
| What happens when links fail or degrade? | Requires redundancy, alternate paths, and graceful degradation |
| How will OTA and bulk transfers avoid disrupting control traffic? | Influences QoS, scheduling, and traffic shaping policies |
| How will you observe network behavior? | Requires metrics, flow logs, and visibility at key points |
Networks and TSN are foundational for SDS. They connect central compute, zonal controllers, OT devices, and cloud systems into a coherent, time-aware platform that can support both safety-critical control and advanced AI workloads.