Smart Port Container Number Recognition Solution
Container number recognition at port gates is best built on the RK3588 core board, where the core is synchronized multi-camera capture plus on-device OCR producing structured, reviewable records ready to write back. The platform pairs a 4×A76 + 4×A55 CPU with a 6TOPS NPU and accepts container, plate and box cameras at once, handling OCR, check-digit validation and plate matching, manual review and an all-in-one lane terminal, integrating with TOS and gate systems over agreed interfaces with local buffering. Hongyin Tech provides a free requirement review and complete-device customization, with selection advice within 48 hours.
Pain Points
- Peak-hour queues at gate lanes slow down as staff copy container numbers and inspect boxes by hand
- Damaged, distorted or multi-line container codes make generic OCR misread real passing vehicles
- At night and in backlight, plates and container codes are over- or underexposed, hard for one camera to cover
- Results must be written back to TOS and gate systems, and inconsistent interfaces mean repeated development
- Salt fog and high humidity at terminals push up failure rates for ordinary industrial PCs and cameras
Recommended Hardware Configuration
| SoC platform | RK3588 (4×Cortex-A76 + 4×Cortex-A55); refer to the datasheet for details |
|---|---|
| AI computing power | 6TOPS NPU running container OCR, check-digit validation and plate recognition on-device |
| Memory & storage | Optional LPDDR4/LPDDR5 with eMMC, caching lane images and records for resumable upload |
| Video input | Multi-channel MIPI CSI, GMSL and Gigabit Ethernet cameras for synchronized container, plate and box views |
| Network & interfaces | Dual Gigabit Ethernet with 4G backup; RS485 and digital I/O for barriers, loop detectors and fill lights |
| Enclosure & protection | Sheet-metal lane terminal with anti-corrosion coating and sealing, wide-temperature and surge protection |
Software Capabilities
- Container OCR: detects the code region, recognizes it line by line, and filters obvious misreads with ISO check-digit rules
- Multi-camera coordination: container, plate and box cameras capture on a shared trigger, with results linked by lane transaction ID
- Manual review: low-confidence records enter a review queue, and corrections are written back and retained as samples
- System integration: exchanges lane transactions with TOS and gate systems via HTTP/MQTT, intermediate tables or files per their interface documents
- Store-and-forward: keeps lane records and images locally, uploading in order and reconciling consistency after network recovery
Deliverables & Services
- Requirement review (free): map lane count, camera angles, lighting and trigger methods, and deliver the selection and integration plan
- Hardware design: core board selection, carrier board customization, multi-camera interfaces and lane terminal structure
- BSP/drivers/algorithms: system trimming, synchronized trigger drivers, OCR and plate model deployment with on-site tuning
- Prototype integration: on-site lane installation, real-vehicle sample collection and evaluation, TOS and gate system commissioning
- Low-volume and mass-production support: low MOQ, batch consistency control for anti-corrosion builds and firmware upgrades
FAQ
Q：Should a port gate use RK3588 or RK3576 for container recognition?
Choose RK3588 when several cameras capture in sync and OCR plus plate models run locally at the same time; RK3576 can be evaluated for a single lane with fewer cameras. RK3588 is 4×A76 + 4×A55 and RK3576 is 4×A72 + 4×A53, both with a 6TOPS NPU; video input and codec capability follow the datasheet. Share lane count, camera channels and TOS interface type for advice within 48 hours.
Q：What recognition rate can be achieved, and how is performance assured?
We do not promise a fixed recognition rate: container OCR accuracy is strongly scenario-dependent and must be calibrated on site. Camera angle and focal length, lighting, code damage and distortion, vehicle position and speed all matter. The usual path is to collect a batch of real lane images for offline evaluation, then fix camera positions, lighting and trigger logic, with acceptance based on field samples both parties agree on.
Q：How are the cost and rollout timeline of a lane upgrade assessed?
Cost has four parts: camera count and model, lane terminal structure, lighting and trigger hardware, and the effort of integrating with TOS and gate systems. A single lane usually starts with prototype validation before replication, paced by site construction windows and how quickly the TOS vendor cooperates. Use the free requirement review to fix the lane list and interface documents; we then provide a line-item effort estimate without promising a fixed lead time.
Q：How does the terminal integrate with TOS, and how is salt fog handled?
Integration follows the customer's existing TOS and gate system interface specifications, supporting HTTP/MQTT, database staging tables and file drops as defined by their documents; lane records and images are cached locally and uploaded automatically after an outage. For salt fog, the enclosure uses anti-corrosion coating and sealed design, with wide-temperature and surge protection verified by whole-device testing, and industry certifications submitted as each project requires.
Related Technical Articles
Share your scenario and requirements — free requirement review, selection advice within 48 hours.
Get a Free Quote →