RK3568 industrial gateway design considerations start before schematic capture. The important work is defining the equipment, sensors, display, network behavior, recovery paths and production handover that the board must support. The SoC is one part of that system—not the complete architecture.
1. Define the gateway system boundary before selecting interfaces
Write down every controlled device, sensor source, network peer, operator display and maintenance path. For each one, record the physical interface, protocol, throughput, update rate, timing tolerance, cable length, connector, isolation need, error behavior and ownership. This prevents a common failure mode: choosing a connector or peripheral because it is available on a development kit, then discovering that the field equipment has different electrical or recovery requirements.
Also define what the gateway does when the network is unavailable, one sensor becomes noisy, a controlled device stops responding or the display process crashes. Those behaviors affect storage, watchdogs, local state, logging and application architecture. They cannot be added reliably as a final UI feature.
2. Treat the BTB compute module and carrier board as one controlled interface
A BTB architecture can separate the compute core from application-specific I/O, but it creates an interface contract between the module and carrier. Freeze connector pin assignments, power sequencing, boot configuration, reset behavior, high-speed interfaces, unused-pin handling and mechanical constraints together. The carrier schematic should not be reviewed without the module documentation and the software boot assumptions beside it.
Use the official Rockchip RK3568 brief datasheet to confirm SoC-level capabilities, then verify module-specific implementation details against the selected module documentation. A general SoC feature list does not prove that a given module exposes the signal, voltage or lane configuration your product needs.
3. Budget power states and thermal paths, not only nominal consumption
Industrial gateways may power radios, displays, sensors and external peripherals while the processor changes load. Review input range, surge and reverse-polarity strategy, rail sequencing, peak current, brownout behavior, suspend/resume needs and the heat path from the RK3568 module into the enclosure. Bench bring-up should include deliberately disturbed inputs and sustained workload, not only a clean laboratory supply at room temperature.
Thermal decisions also affect software. CPU and accelerator load, display use, network traffic and background storage writes can produce different steady-state conditions. Define which temperatures and throttling events must be logged, what performance is acceptable when warm and whether the enclosure or mounting plate participates in heat spreading.
4. Design every external I/O for the real cable and environment
List whether interfaces leave the enclosure, share ground with other equipment or run beside motors and power wiring. Protection, filtering, common-mode behavior, isolation, connector retention and test access follow from that environment. The logic-level protocol name alone—UART, CAN, RS-485, Ethernet, USB, GPIO or an analog sensor input—is not enough to approve the circuit.
For multi-sensor acquisition, define timestamp ownership, sample alignment, calibration data, out-of-range handling and how the application distinguishes missing, stale and invalid values. The data model should preserve those states instead of replacing all of them with zero.
5. Make the Linux BSP and Device Tree part of the hardware review
Board bring-up depends on boot firmware, kernel configuration, Device Tree, clock and regulator definitions, pin control, storage layout and peripheral drivers agreeing with the schematic. The Linux kernel Device Tree documentation explains why hardware description is used for platform identification, runtime configuration and device population. In practice, each custom-board node should trace back to a reviewed schematic interface and a measurable bring-up check.
Decide early whether the product will track a vendor BSP, a maintained long-term kernel line or a controlled combination. Record the source repositories, exact revisions, patches, toolchain, build configuration and license obligations. “Linux boots” is not a reproducible release state unless another engineer can rebuild the same image and explain every product-specific change.
6. Separate reusable driver work from product-specific control logic
Keep hardware access, protocol framing, device state and business decisions in clear layers. A driver should expose explicit errors and observable state; it should not silently hide repeated resets or stale sensor data. Product logic should decide what an error means to the operator and the controlled equipment.
Before implementation, define probe and removal behavior, interrupt or polling strategy, timeouts, retry limits, concurrent access, suspend/resume, hot-plug expectations and diagnostic counters. For custom devices, create a small test utility that exercises the driver without requiring the entire application stack. That makes board bring-up and future failure analysis faster.
7. Design diagnostics, update and recovery paths into the first release
A gateway needs evidence when something fails outside the development bench. Establish persistent logs with bounded storage, software and configuration versions, boot reason, watchdog history, network state, device-health counters and time synchronization status. Decide what a field technician can export without exposing customer data or proprietary code.
Define safe update and rollback behavior for the boot chain, operating system, application and configuration. Test interrupted updates, corrupt configuration, full storage, repeated boot failure and unavailable network conditions. Recovery must be a documented operating path rather than an engineer-only serial-console trick.
8. Treat display integration as a system workload and service dependency
Record resolution, interface, orientation, touch input, brightness control, startup sequence, frame-rate need and acceptable recovery time. The display application should have an explicit state when device data is missing or stale. If a local display is optional, confirm whether the headless system can start, update and recover without it connected.
Display choices influence memory bandwidth, GPU use, boot time, thermal load and application packaging. Test the representative user interface together with network traffic, sensor acquisition and storage activity instead of validating each subsystem in isolation.
9. Freeze a production-handover package, not only a working prototype
Before a pilot build, reconcile schematic, layout, BOM, approved substitutions, fabrication outputs, assembly drawings, programming files, boot image, source revisions, configuration, test procedure and known deviations. Every released artifact should share a release identifier. If a component changes, use a controlled Change Request and reassess hardware, software, cost and schedule impact.
Plan fixtures and test access around measurable production checks: rail values, boot completion, storage, network links, critical peripherals, programmed identity and any safety-relevant outputs. Define pass/fail limits and how failures are recorded. A manual “looks good” check is not enough for a repeatable build.
10. A practical review checklist
- All field devices, sensors, networks and display paths have an owned interface definition.
- Module-to-carrier pins, sequencing and boot assumptions are frozen together.
- Peak power, brownout, sustained thermal load and recovery behavior have tests.
- External I/O has environment-appropriate protection and diagnostics.
- Device Tree nodes trace to schematic interfaces and bring-up checks.
- Driver errors, retries, timeouts and observable health counters are explicit.
- Update, rollback, watchdog and configuration-recovery paths are exercised.
- The production package ties PCBA files and source-code revisions to one release.
When to request an engineering assessment
An assessment is useful when the interface inventory is incomplete, the current development board no longer represents the product, the BSP or driver ownership is unclear, or a prototype must become a controlled pilot-build package. SYANKOR offers a time-bounded, high-level initial fit assessment at no charge. Detailed architecture, investigation and solution work is paid engineering.