PDS can provide a standard or adapted vehicle-computer platform, but the final machine system is a shared engineering project. A quoted PDS scope may include the enclosure, display, compute platform, selected I/O, operating-system image, positioning hardware and harness work. Vehicle protocols, application logic, correction services, control hardware, safety decisions and installed-system acceptance remain with the parties assigned in the project specification.
PDS works best as a vehicle-computing platform and integration partner. The project should state what PDS supplies, what the vehicle OEM or system integrator retains, which third-party services are required, and who owns validation after those parts are installed together.
Start with a responsibility map, not a feature list
A catalogue answers which functions a platform can support. It does not allocate engineering responsibility. Before hardware is frozen, the team should map every function to one owner and one acceptance method. The PDS OEM / ODM project path uses the machine, operator workflow, interfaces, positioning chain and lifecycle as the starting point. The PDS company profile gives the broader brand and product context.
| Scope area | Possible PDS scope | Scope normally retained elsewhere unless agreed |
|---|---|---|
| Terminal platform | Enclosure, display, compute, storage and published platform interfaces | Cab layout, final bracket position, sight-line approval and machine-level installation |
| Vehicle I/O | Selected CAN, serial, Ethernet, USB, GPIO and camera hardware; project connector or harness work | Message definitions, machine permissions, application protocol, peripheral compatibility and complete-system EMC behavior |
| Software | Supported Android or Linux image, drivers, SDK/API and agreed customization | Customer application, cloud service, data model, credentials, cybersecurity process and field operations |
| Positioning | Published GNSS or optional RTK receiver/radio options and terminal status interface | Antenna installation, correction service, coverage, coordinate workflow, control response and field accuracy acceptance |
| Release | Agreed sample configuration, terminal tests and controlled hardware/software baseline | Installed-vehicle acceptance, regulatory obligations, safety case, operator training and system support |
Choose a standard platform before deciding what to customize
A project can begin with the current PDS vehicle-computer range and select the format closest to the actual workflow. For example, the T8 Pro is a higher-compute 8-inch direction for camera or multi-display work, while the T10B is a 10.1-inch direction with current Android or embedded Linux options. Those labels are starting points; processor, memory, I/O, positioning, wireless and environmental details still need one controlled configuration.
Customization should solve a documented gap. It may involve an enclosure detail, branding, connector map, harness, module, OS image, driver, boot behavior or API. If a standard platform already satisfies the requirement, unnecessary changes add validation and lifecycle work without improving the operator's task.
Define the enclosure and installed environment separately
An enclosure rating does not automatically rate the complete installed system. IEC 60529 defines IP classifications for enclosures, while the final installation also includes mating connectors, cable entries, vents, seals, bracket and service procedure. The project should identify which configuration was tested and whether connectors were mated.
Do the same for temperature, shock and vibration. Record the mounting point, continuous vibration, impact events, sunlight exposure, cleaning method and heat sources around the terminal. A production-intent bracket and harness belong in the vehicle test because an enclosure test alone cannot prove display readability, connector retention or cable life.
Separate electrical input range from vehicle-power validation
A published wide-voltage input is only the beginning. The installed terminal may experience engine cranking, key transitions, reverse polarity, load events, ground offsets and unexpected power loss. ISO 7637-2 describes conducted transient test methods for 12 V and 24 V road-vehicle equipment, while ISO 16750-2 covers electrical loads and notes the influence of the wiring harness. The exact standards and severity required for an off-highway or regional project must be agreed rather than assumed.
The functional questions matter as much as the electrical pulse: which signal represents ignition, how long shutdown may take, what data must be saved, and what state appears after restart? PDS can configure the terminal behavior that is within scope, but the vehicle signal and complete recovery workflow require system-level validation.
Allocate CAN, serial and camera integration explicitly
A CAN port proves the presence of a hardware interface; it does not supply the customer's CAN database, J1939 interpretation, proprietary messages or permission to command a machine. Linux SocketCAN documentation, for example, describes a standard operating-system interface for CAN networking, while application-level identifiers, scaling, state logic and fault handling still belong to the project.
For every interface, document protocol owner, electrical standard, data rate, connector, simultaneous-use requirement and failure behavior. Cameras also need a defined signal standard, resolution, count, trigger, latency and record/display requirement. A platform that can accept several inputs may still need project validation for the exact concurrent workload.
Treat RTK as a chain, not a module checkbox
An RTK-capable terminal does not guarantee a fixed accuracy under every condition. Positioning depends on receiver and antenna design, satellite visibility, multipath, correction data, communications, configuration and the way the application handles degraded states. The U.S. government's GPS accuracy guidance likewise notes that achieved accuracy depends on environmental and receiver factors.
The project must name the receiver, antenna or dual-antenna geometry, correction source, NTRIP or radio path, target regions, quality states and operator response. PDS can supply agreed terminal components and status integration; the correction subscription, antenna installation, coverage and machine response remain with the assigned owner. Use the RTK GNSS integration checklist to build the full test plan.
Assign ownership for Android or embedded Linux
"Runs Android" is not a complete software specification. The project should record Android version, AOSP or other image baseline, required services, hardware APIs, signing, update method, rollback and support responsibility. The Android compatibility overview explains that an Android implementation and formal compatibility are distinct concepts; Google services or Play access must never be inferred from the operating-system name alone.
Embedded Linux also needs named owners for the BSP, kernel, drivers, libraries, Qt or other application framework, package policy, security maintenance and field recovery. The Android versus Linux vehicle-terminal guide helps teams make this ownership decision before choosing the final image.
Validate one production-intent sample
A useful sample should represent the intended enclosure, compute and memory configuration, connector map, harness, OS image, drivers, antennas, wireless modules, cameras and peripherals. It should operate from the target vehicle power source and run the intended application. Otherwise a successful demonstration may prove a configuration that will never be produced.
| Release step | Record to create | Question it must answer |
|---|---|---|
| System brief | Vehicle, operator task, environment, markets, quantity and lifecycle | What problem must the terminal solve? |
| Engineering map | Display, compute, positioning, I/O, harness, mounting and software ownership | Who supplies and integrates each part? |
| Sample validation | Production-intent configuration and written acceptance matrix | Does the installed system recover and perform in representative conditions? |
| Release control | Approved revision, image, connector map, tests and change owner | What exactly may be reproduced, and which change triggers revalidation? |
Three examples of the boundary in practice
Excavator or mining vehicle
In a construction or mining terminal, PDS may provide the in-cab computer, display and agreed I/O. The equipment builder or integrator retains machine messages, positioning or grade-control algorithms, bracket approval, camera installation and site acceptance. The T8 excavator integration case shows this boundary without claiming an undisclosed customer result.
Agricultural guidance or auto-steering
PDS may provide an operator terminal connected to positioning and vehicle systems. The wider project still assigns the correction service, antennas, guidance application, steering controller, actuator, safety logic and field acceptance. A display or RTK module should not be described as independently steering the machine.
Fleet or public-transport vehicle
The terminal may host the driver interface and connect positioning, communications, vehicle data and cameras. The fleet platform, dispatch rules, mobile network, privacy decisions, data retention and operating procedures remain part of the customer's wider service.
Information PDS needs for an OEM or integration review
- Vehicle or machine, cab drawing or photographs, mounting limits and operator reach.
- Power source, ignition signal, shutdown timing and required recovery state.
- All simultaneous CAN, serial, Ethernet, USB, GPIO, audio, camera and peripheral needs.
- Application owner, OS preference, SDK/driver needs, update and cybersecurity responsibilities.
- GNSS or RTK target, receiver, antennas, correction source, coverage and degraded behavior.
- Destination markets, required evidence, sample quantity, annual estimate and lifecycle expectation.
- Acceptance criteria for environment, power, I/O, application behavior and installed operation.
Frequently asked questions about working with PDS
Can PDS adapt a standard platform instead of designing from zero?
That is the intended starting point of the published OEM/ODM path. The team selects the closest standard platform, then confirms which hardware, structure, I/O, firmware or software differences are justified and available.
Who owns CAN message definitions?
The project must name the owner. PDS can provide agreed CAN hardware, drivers or integration work, but a connector does not grant the customer's message database or define how machine states are interpreted.
Does an IP-rated terminal make the full installation IP-rated?
No. Enclosure evidence must be read with its test configuration, and the installed connectors, harness, bracket, entries and service state need separate assessment.
Who owns the Android or Linux image?
Ownership and maintenance depend on the quoted project. Record who builds, signs, updates, supports and recovers the image, plus which drivers and services are included.
What changes require revalidation?
Any change that can affect acceptance—including compute module, display, memory, I/O, connector, harness, antenna, radio, OS image, driver, application or mounting—should be reviewed against the controlled release record.
How should a buyer start?
Complete the vehicle-computer specification checklist, then send the machine, responsibility map and sample target through the PDS OEM project inquiry.
