Autonomous industrial vehicles need a reliable communication layer between onboard networks, cellular infrastructure, and remote systems. In a mining truck, Robotaxi, autonomous heavy truck, sweeper, or port vehicle, the gateway may connect vehicle controllers and Ethernet networks to a cellular network and fleet platform.

That does not make every vehicle gateway the same.

A gateway designed mainly for mobile broadband has very different requirements from an automotive or industrial gateway that must interface with CAN FD, automotive Ethernet, GNSS, and vehicle power systems. The right choice depends on the vehicle architecture, the communication paths that need to be supported, and the conditions in which the vehicle operates.

For this reason, vehicle gateway selection should start with the vehicle communication architecture, not with the highest 5G speed listed on a datasheet.

Why 5G Speed Is Only One Part of Vehicle Gateway Selection

A vehicle gateway can perform several communication functions at the same time. Depending on the architecture, it may provide cellular connectivity, vehicle-network interfaces, routing, network segmentation, positioning, time synchronization, and remote device management.

Consider a typical autonomous vehicle.

A vehicle controller may exchange data through CAN or CAN FD. Domain controllers and other onboard computers may use automotive Ethernet. GNSS provides positioning information. A cellular connection links the vehicle with a cloud platform, fleet-management system, or remote operational infrastructure.

These communication paths do not have the same requirements.

A gateway with high cellular throughput but no suitable vehicle-network interfaces may still be unsuitable for the project. Conversely, a gateway with extensive vehicle interfaces may be unnecessary for a simple application that only requires remote connectivity.

The first engineering question is therefore not “How fast is the 5G modem?” but “What communication functions must the gateway perform in this vehicle?”

That distinction makes the rest of the selection process much clearer.

1. Cellular Connectivity and Network Redundancy

Cellular coverage can change significantly along an industrial route. A mining truck may move between different working areas. An autonomous heavy truck may cross regions with different coverage conditions. A port vehicle may operate around buildings, containers, and other structures that affect radio performance.

For these applications, cellular architecture deserves careful evaluation.

A vehicle gateway may use one or more cellular modules and may support multiple SIM or eSIM configurations. Depending on the hardware and software design, multiple cellular connections can be used for network redundancy, link management, or other connectivity strategies.

One point needs to be made clear during procurement:

Dual SIM is not the same as 5G carrier aggregation.

Dual SIM can support SIM selection or network redundancy. Two cellular modules can provide a different architecture from a single modem with multiple SIMs. Carrier aggregation, meanwhile, is a modem-level mechanism for combining supported component carriers.

The supplier documentation should therefore specify what happens when a link becomes unavailable. Questions worth asking include:

• Can another configured link take over?
• Can two cellular links remain available simultaneously?
• How are routes selected between links?
• Is link health monitored?
• Can policies be applied to different traffic types?

Features such as link detection, policy routing, and link backup can be useful, but their practical behavior needs to be validated under the operator networks used by the project.

2. CAN FD and Automotive Ethernet

The vehicle interfaces often determine whether a gateway can be integrated into the existing E/E architecture.

CAN and CAN FD remain important for communication with vehicle ECUs and controllers. Automotive Ethernet is increasingly used for higher-bandwidth communication between domain controllers, onboard computers, and other electronic systems.

When evaluating a vehicle gateway, check the interfaces against the actual network topology rather than simply counting ports.

For example, a project may require CAN FD for vehicle status and control-related data while using 100BASE-T1 or 1000BASE-T1 to communicate with other onboard systems. A conventional Ethernet port may be needed for a service network or external infrastructure.

Interface type matters because these networks are not interchangeable. Wiring, physical-layer requirements, bandwidth, topology, protocol handling, and network management all need to fit the vehicle design.

VLAN support can also become relevant when different traffic classes need to remain logically separated. Policy routing can be useful when the gateway has multiple network paths or when different destinations require different routing policies.

For a production vehicle, it is better to map the gateway ports to the vehicle’s communication diagram before choosing the hardware. This quickly exposes missing interfaces and unnecessary ones.

3. GNSS and Time Synchronization

GNSS is commonly used for fleet tracking, vehicle positioning, navigation-related functions, and operational management.

It should not, however, be treated as a guarantee of centimeter-level positioning.

Position accuracy depends on the receiver, antenna, correction source, surrounding environment, and system configuration. RTK capability, where required, must be evaluated at the receiver and system level rather than inferred from the presence of a GNSS interface.

Timing is a separate requirement.

Vehicle networks that contain multiple controllers may need a common time base for data correlation and coordinated operation. Depending on the architecture, Precision Time Protocol technologies such as IEEE 1588v2 or IEEE 802.1AS/gPTP may be relevant.

This means a gateway can have two distinct roles:

GNSS for positioning and time synchronization for network timing.

They should not be treated as the same function.

Before procurement, define whether the project needs ordinary GNSS positioning, a higher-accuracy positioning architecture, network time synchronization, or a combination of these functions.

4. Environmental and Power Requirements

Industrial vehicles place constraints on electronics that are easy to underestimate during a prototype project.

A mining vehicle may experience continuous vibration and large temperature changes. An outdoor autonomous vehicle can remain powered for extended periods. Vehicle electrical systems can also expose onboard equipment to transient conditions that are not present in office or data-center deployments.

The gateway specification should therefore be checked against the actual electrical and environmental design.

Important items include:

• DC input voltage range
• operating temperature
• reverse-polarity protection
• overvoltage and overcurrent protection
• watchdog behavior
• mounting conditions
• connector and cable arrangement

A wider input range can simplify integration across different vehicle electrical systems, but it does not remove the need to validate the gateway against the vehicle’s actual power architecture.

The same principle applies to temperature and mechanical design. “Industrial-grade” is not a substitute for checking the published operating limits and the project’s environmental test requirements.

5. Network Management and Software Support

A fleet of ten vehicles can be managed differently from a fleet of several hundred. Once devices are distributed across a large operating area, physical access becomes expensive and slow.

Remote management is therefore more than a convenience.

Depending on the gateway, useful functions may include remote configuration, device monitoring, link diagnostics, routing configuration, VLAN management, and remote firmware upgrades.

Software integration also matters. An OEM or autonomous-driving solution provider may need the gateway to fit into an existing network-management architecture. API or SDK access, configuration interfaces, logging, and software lifecycle support may become important during system integration.

The operating system itself is not the main selection criterion. A platform may use Linux, OpenWrt, or another embedded environment. What matters to the vehicle project is whether the software stack exposes the functions needed for deployment and long-term maintenance.

For procurement, ask not only “What software does the gateway run?” but also:

“How will the engineering team configure, monitor, troubleshoot, and update this device after it is installed in the vehicle?”

6. Edge Processing: Useful, but Not a Substitute for AD Computing

Some vehicle gateways include local processing resources.

That can be useful for network services, local data handling, protocol processing, traffic filtering, or application-specific edge functions. It does not mean that the gateway should replace the autonomous-driving compute platform.

In most autonomous vehicle architectures, perception, sensor fusion, path planning, and decision-making are handled by dedicated computing systems or domain controllers.

The gateway’s role is different.

It can provide the communication path that connects those systems to vehicle networks, cellular infrastructure, positioning services, and remote platforms.

Keeping those roles separate helps avoid a common purchasing mistake: selecting computing capacity that the communication gateway does not actually need, or assuming that a gateway with edge processing can replace an AD controller.

The required processing capability should be derived from the software functions that will actually run on the gateway.

7. Mechanical Integration and Connectivity Hardware

A gateway can meet every software requirement and still be difficult to deploy if the physical integration has not been considered.

Vehicle projects need to account for installation space, antenna placement, cable routing, service access, connector type, and enclosure design.

The cellular and GNSS antenna layout deserves particular attention. Cable length, antenna position, surrounding metal structures, and installation location can all affect wireless performance.

The same applies to Ethernet and CAN wiring. The gateway should fit the vehicle’s physical network layout without forcing unnecessary cable changes.

This becomes increasingly important when a prototype is converted into a repeatable fleet configuration. A solution that works in one engineering vehicle may require a different mechanical arrangement when production vehicles are deployed at scale.

Vehicle Gateway Requirements by Autonomous Fleet Scenario

The same gateway architecture does not necessarily suit every autonomous vehicle.

Autonomous Mining Trucks

Mining applications typically place strong demands on environmental durability, network availability, vehicle interfaces, and remote fleet connectivity.

A gateway may connect CAN FD and Ethernet networks with cellular infrastructure and a fleet-management platform. Where cellular conditions vary across the operating area, redundant cellular connectivity may also be considered.

The gateway should be selected together with the mine’s communication architecture, electrical system, and operating environment.

Robotaxi

Robotaxi platforms usually contain multiple onboard computing and control systems. The gateway may operate alongside autonomous-driving computers, vehicle controllers, and other domain-level electronics.

Here, automotive Ethernet and CAN FD compatibility can matter as much as cellular connectivity.

The gateway is primarily a communication and network-management component. It should not be positioned as the system responsible for autonomous-driving perception or decision-making.

For Robotaxi programs, the interface between the gateway and the rest of the E/E architecture should be defined early. This avoids using the gateway as a catch-all device for functions that belong elsewhere in the vehicle.

Autonomous Heavy Trucks and Robotrucks

Long-distance autonomous trucks can encounter large differences in cellular coverage along a route.

Network redundancy, GNSS, vehicle interfaces, remote management, and environmental operating range may therefore be important selection criteria.

The engineering team should also test the gateway’s behavior under degraded connectivity. Knowing that a device supports link backup is useful; knowing how the configured system behaves during a real network interruption is more useful.

Autonomous Sweepers

Autonomous sweepers often operate in campuses, municipal areas, industrial parks, and other structured environments.

Their requirements may emphasize compact integration, vehicle data access, GNSS, stable remote connectivity, and fleet management rather than maximum cellular throughput.

This is a good example of why a gateway should be selected from the application’s actual data flow. A higher-speed modem does not automatically create a better vehicle communication system.

Smart-Port AGVs and Autonomous Terminal Vehicles

Port vehicles can have relatively defined operating areas but still require reliable communication with dispatching, fleet-management, and operational systems.

Ethernet topology, VLANs, routing policies, wireless connectivity, and cellular backup can become relevant depending on the network design.

Here the gateway should be considered as part of the entire port communication system rather than an isolated networking box.

Example: SV920 Vehicle Communication Platform

For autonomous vehicle projects that require cellular connectivity together with CAN FD, automotive Ethernet, GNSS, and network-management functions, the SV920 can be evaluated as an integrated vehicle communication platform.

According to the current product specification, the platform supports dual 5G cellular modules and SIM/eSIM configurations. Its vehicle-network interfaces include CAN FD and automotive Ethernet.

Capability	SV920
Cellular	Dual 5G modules
SIM	SIM / eSIM
Ethernet para automoción	2 × 1000/100BASE-T1
Ethernet	1 × 1000/100BASE-TX
CAN	4 × CAN FD
Positioning	GNSS
Wireless	Wi-Fi and Bluetooth
Time Synchronization	IEEE 802.1AS/gPTP, IEEE 1588v2
Network Functions	VLAN, policy routing, link detection, link backup
Device Management	Remote management, FOTA
Power Input	DC 9–48 V
Temperatura de funcionamiento	-40°C to +85°C

This combination can be useful when a project would otherwise require several separate communication devices for cellular connectivity, vehicle Ethernet, CAN FD, GNSS, and network management.

The right configuration still depends on the vehicle.

A Robotaxi may place more emphasis on automotive Ethernet integration. A mining truck may place greater weight on environmental conditions and redundant cellular connectivity. A port vehicle may require a particular Ethernet and VLAN architecture.

The product should therefore be evaluated against the vehicle’s network diagram and deployment requirements rather than selected as a universal solution for every autonomous platform.

Vehicle Gateway Procurement Checklist

Before approving a vehicle gateway for production deployment, it is useful to review the following items as a single engineering checklist.

Procurement Area	What to Check
Cellular	Modem architecture, supported bands, SIM/eSIM, redundancy strategy
Red de vehículos	CAN FD, 100BASE-T1, 1000BASE-T1, Ethernet ports, topology
GNSS	Receiver capability, antenna requirements, correction requirements
Timing	PTP/gPTP requirements and network architecture
Potencia	Input range and protection functions
Environment	Temperature, vibration, installation conditions
Software	Remote management, VLAN, routing, diagnostics, FOTA
Integration	APIs/SDKs, documentation, configuration interfaces
Lifecycle	Firmware maintenance, technical support, customization process
Validation	Network tests, vehicle integration tests, environmental tests

One additional question is worth asking before procurement:

Which functions belong in the gateway, and which belong in the T-Box, vehicle controller, autonomous-driving computer, or another domain controller?

The answer depends on the E/E architecture. In some vehicles, several communication functions may be integrated into one device. In others, separate devices may remain the better choice.

When a Vehicle Gateway Is Not the Right Solution

A vehicle gateway is not automatically the best answer to every connectivity requirement.

If the project only needs basic cellular access for a simple device, a conventional industrial router may be sufficient.

If the main requirement is autonomous-driving perception, sensor fusion, path planning, or high-performance AI inference, the central component should be an autonomous-driving computing platform rather than a vehicle gateway.

A T-Box may also be more appropriate when the primary requirement is telematics, basic vehicle data collection, positioning, and remote connectivity.

The distinction matters because purchasing decisions should follow system requirements rather than product categories.

A vehicle gateway becomes particularly useful when the project needs a combination of cellular connectivity and vehicle-network integration, especially where CAN FD, automotive Ethernet, GNSS, network management, and fleet operations need to coexist in the same communication architecture.

Conclusión

A vehicle gateway should be selected as part of the vehicle communication architecture, not as an isolated 5G networking device.

For autonomous mining trucks, Robotaxi, autonomous heavy trucks, sweepers, and smart-port vehicles, the priorities can be different. One project may need redundant cellular connectivity and environmental durability. Another may depend more heavily on automotive Ethernet, VLANs, and network management.

The practical selection process is to map the vehicle’s communication paths first, then evaluate the gateway against those requirements.

Check the cellular architecture. Check CAN FD and automotive Ethernet compatibility. Define GNSS and timing requirements. Verify power and environmental conditions. Review remote management and software integration. Finally, test the complete configuration under the actual operating conditions.

This approach gives engineering and procurement teams a more useful basis for choosing a vehicle communication gateway and avoids selecting hardware simply because it has a faster modem or a longer feature list.