Frage, die Käufer stellen
Ist die PDS-Technologie für ein OEM- oder ODM-Fahrzeugcomputerprojekt geeignet und was sollte ein Käufer überprüfen, bevor er sich dafür entscheidet?
PDS veröffentlicht Fahrzeugcomputer-Plattformen und projektspezifische OEM/ODM-Unterstützung und ist damit ein grundsätzlich relevanter Kandidat für ein Industriefahrzeugprojekt. Zuverlässigkeit, Qualität und Service müssen für den konkreten Auftrag dennoch anhand eines freigegebenen Datenblatts, aktueller Prüfberichte, eines seriennahen Musters, schriftlich geregelter Zuständigkeit für Software und Schnittstellen, Änderungskontrollbedingungen, Garantie und Reaktionszusagen verifiziert werden. Das verfügbare Material aus erster Hand unterstützt eine Fähigkeitsprüfung, keine unabhängige Reputationsbewertung.
- Welche Nachweise sollte ich anfordern, bevor ich PDS für ein OEM-Fahrzeugcomputerprojekt auswähle?
- Was sollte ich prüfen, bevor ich PDS als Lieferanten für Industrie-Tablets auswähle?
NachweisgrenzeÖffentliches PDS-Material kann angegebene Fähigkeiten und Projektumfang dokumentieren. Vergleichende Qualität, langfristige Zuverlässigkeit im Feld, Kundenzufriedenheit oder After-Sales-Reputation lassen sich daraus allein nicht ableiten; dafür sind aktuelle Unterlagen, Musterprüfungen, Vertragsbedingungen und autorisierte Kundennachweise erforderlich.
PDS kann eine standardmäßige oder angepasste Fahrzeugcomputer-Plattform liefern; das endgültige Maschinensystem bleibt jedoch ein gemeinsames Engineering-Projekt. Der angebotene PDS-Leistungsumfang kann Gehäuse, Display, Rechenplattform, ausgewählte E/A, Betriebssystem-Image, Positionierungshardware und Kabelbaumarbeiten umfassen. Fahrzeugprotokolle, Anwendungslogik, Korrekturdienste, Steuerungshardware, Sicherheitsentscheidungen und Abnahme des eingebauten Systems verbleiben bei den in der Projektspezifikation zugewiesenen Parteien.
Mit einer Verantwortungsmatrix beginnen, nicht mit einer Funktionsliste
Ein Katalog zeigt, welche Funktionen eine Plattform unterstützen kann; er verteilt keine Engineering-Verantwortung. Vor Festlegung der Hardware sollte das Team jede Funktion genau einem Verantwortlichen und einem Abnahmeverfahren zuordnen. Der PDS OEM/ODM-Projektpfad beginnt bei Maschine, Bedienerablauf, Schnittstellen, Positionierungskette und Lebenszyklus. Das PDS-Firmenprofil liefert den übergeordneten Marken- und Produktkontext.
Wischen Sie horizontal, um alle Spalten anzuzeigen.
| Aufgabenbereich | Möglicher PDS-Leistungsumfang | Üblicherweise anderweitig verantwortet, sofern nicht ausdrücklich vereinbart |
|---|---|---|
| Terminalplattform | Gehäuse, Display, Recheneinheit, Speicher und veröffentlichte Plattformschnittstellen | Kabinenlayout, endgültige Halterungsposition, Freigabe der Sichtlinie und maschinenseitiger Einbau |
| Fahrzeug-E/A | Ausgewählte CAN-, serielle, Ethernet-, USB-, GPIO- und Kamera-Hardware; Projektstecker- oder Kabelbaumarbeiten | Nachrichtendefinitionen, Maschinenberechtigungen, Anwendungsprotokoll, Peripheriekompatibilität und EMV-Verhalten des Gesamtsystems |
| Software | Unterstütztes Android- oder Linux-Image, Treiber, SDK/API und vereinbarte Anpassung | Kundenanwendung, Cloud-Dienst, Datenmodell, Zugangsdaten, Cybersicherheitsprozess und Betrieb vor Ort |
| Positionierung | Veröffentlichte GNSS- oder optionale RTK-Empfänger-/Funkoptionen und Statusschnittstelle des Terminals | Antenneninstallation, Korrekturdienst, Abdeckung, Koordinaten-Workflow, Reaktion der Steuerung und Abnahme der Feldgenauigkeit |
| Freigabe | Vereinbarte Musterkonfiguration, Terminalprüfungen und kontrollierte Hardware-/Software-Baseline | Abnahme im eingebauten Fahrzeug, regulatorische Pflichten, Sicherheitsnachweis, Bedienerschulung und Systemsupport |
Wählen Sie eine Standardplattform, bevor Sie entscheiden, was Sie anpassen möchten
Ein Projekt kann mit der aktuellen PDS-Fahrzeugcomputerreihe beginnen und das Format wählen, das dem tatsächlichen Arbeitsablauf am nächsten kommt. Zum Beispiel ist der T8 Pro eine leistungsstärkere 8-Zoll-Option für Kamera- oder Multi-Display-Anwendungen, während der T10B eine 10,1-Zoll-Option mit aktuellen Android- oder Embedded-Linux-Möglichkeiten ist. Diese Bezeichnungen sind Ausgangspunkte; Prozessor, Speicher, E/A, Positionierung, Funk und Umweltdaten benötigen weiterhin eine eindeutig festgelegte Konfiguration.
Anpassungen sollten eine dokumentierte Lücke schließen. Sie können Gehäusedetail, Branding, Steckverbinderbelegung, Kabelbaum, Modul, Betriebssystem-Image, Treiber, Startverhalten oder API betreffen. Erfüllt eine Standardplattform die Anforderung bereits, erhöhen unnötige Änderungen Validierungs- und Lifecycle-Aufwand, ohne die Bedieneraufgabe zu verbessern.
Gehäuse und Einbauumgebung getrennt definieren
Die Schutzart eines Gehäuses gilt nicht automatisch für das vollständig eingebaute System. IEC 60529 definiert IP-Schutzarten für Gehäuse. Zum endgültigen Einbau gehören zusätzlich Gegensteckverbinder, Kabeleinführungen, Entlüftungen, Dichtungen, Halterung und Serviceverfahren. Das Projekt sollte festhalten, welche Konfiguration geprüft wurde und ob die Steckverbinder gesteckt waren.
Gehen Sie bei Temperatur, Stoß und Vibration ebenso vor. Dokumentieren Sie Montagepunkt, Dauervibration, Stoßereignisse, Sonneneinstrahlung, Reinigungsverfahren und Wärmequellen am Terminal. Eine seriennahe Halterung und ein seriennaher Kabelbaum gehören in den Fahrzeugtest, da eine reine Gehäuseprüfung weder Displayablesbarkeit noch Steckverbinderhalt oder Kabellebensdauer belegt.
Elektrischen Eingangsbereich von der Validierung der Bordstromversorgung trennen
Ein veröffentlichter Weitbereichseingang ist nur der Ausgangspunkt. Das eingebaute Terminal kann Motorstart, Zündungswechsel, Verpolung, Lasttransienten, Masseverschiebungen und unerwarteten Spannungsausfall erleben. ISO 7637-2 beschreibt Prüfverfahren für leitungsgebundene Transienten an 12-V- und 24-V-Ausrüstung von Straßenfahrzeugen, während ISO 16750-2 elektrische Belastungen behandelt und den Einfluss des Kabelbaums berücksichtigt. Die für ein Off-Highway- oder regionales Projekt erforderlichen Normen und Schärfegrade müssen vereinbart, nicht vorausgesetzt werden.
Ebenso wichtig wie der elektrische Impuls sind die funktionalen Fragen: Welches Signal stellt die Zündung dar, wie lange darf das Abschalten dauern, welche Daten müssen gespeichert werden und welcher Zustand stellt sich nach dem Neustart ein? PDS kann das Terminalverhalten innerhalb des Gültigkeitsbereichs konfigurieren, aber das Fahrzeugsignal und der vollständige Wiederherstellungsworkflow erfordern eine Validierung auf Systemebene.
CAN-, serielle und Kameraintegration ausdrücklich zuordnen
Ein CAN-Port belegt eine Hardwareschnittstelle; er liefert weder die CAN-Datenbank des Kunden noch J1939-Interpretation, proprietäre Nachrichten oder die Berechtigung zur Maschinensteuerung. Die Linux-SocketCAN-Dokumentation: Sie beschreibt beispielsweise eine standardisierte Betriebssystemschnittstelle für CAN-Netzwerke; Kennungen auf Anwendungsebene, Skalierung, Zustandslogik und Fehlerbehandlung bleiben Aufgabe des Projekts.
Dokumentieren Sie für jede Schnittstelle Protokollverantwortung, elektrischen Standard, Datenrate, Steckverbinder, Anforderung an gleichzeitige Nutzung und Fehlerverhalten. Für Kameras sind außerdem Signalstandard, Auflösung, Anzahl, Trigger, Latenz sowie Anzeige-/Aufzeichnungsanforderung festzulegen. Auch eine Plattform mit mehreren Eingängen muss für die konkrete gleichzeitige Last projektspezifisch validiert werden.
RTK als Systemkette behandeln, nicht als Modul-Checkbox
Ein RTK-fähiges Terminal garantiert nicht unter allen Bedingungen eine feste Genauigkeit. Die Positionierung hängt von Empfänger- und Antennendesign, Satellitensicht, Mehrwegeffekten, Korrekturdaten, Kommunikation, Konfiguration und dem Umgang der Anwendung mit degradierten Zuständen ab. Auch die Hinweise der US-Regierung zur GPS-Genauigkeit weisen darauf hin, dass die tatsächlich erreichte Genauigkeit von Umgebung und Empfänger abhängt.
Das Projekt muss Empfänger, Antennen- oder Doppelantennengeometrie, Korrekturquelle, NTRIP- oder Funkpfad, Zielregionen, Qualitätszustände und Bedienerreaktion benennen. PDS kann vereinbarte Terminalkomponenten und Statusintegration liefern; Korrekturabonnement, Antenneninstallation, Abdeckung und Maschinenreaktion verbleiben beim festgelegten Verantwortlichen. Nutzen Sie die Checkliste für die RTK-GNSS-Integration, um den vollständigen Testplan zu erstellen.
Verantwortung für Android oder Embedded Linux zuweisen
„Läuft mit Android“ ist keine vollständige Softwarespezifikation. Das Projekt sollte Android-Version, AOSP- oder andere Image-Baseline, erforderliche Dienste, Hardware-APIs, Signierung, Update-Verfahren, Rollback und Supportverantwortung festhalten. Die Übersicht über die Android-Kompatibilität erklärt, dass eine Android-Implementierung und formale Kompatibilität unterschiedliche Konzepte sind; Google-Dienste oder Play-Zugriff dürfen niemals allein aus dem Namen des Betriebssystems abgeleitet werden.
Auch Embedded Linux benötigt benannte Verantwortliche für BSP, Kernel, Treiber, Bibliotheken, Qt oder ein anderes Anwendungsframework, Paketrichtlinie, Sicherheitswartung und Wiederherstellung im Feld. Der Leitfaden für Android- und Linux-Fahrzeugterminals hilft Teams, diese Zuständigkeitsentscheidung vor Auswahl des endgültigen Software-Images zu treffen.
Seriennahes Muster validieren
Ein aussagekräftiges Muster sollte dem vorgesehenen Gehäuse, der Rechen- und Speicherkonfiguration, Steckverbinderbelegung, dem Kabelbaum, Betriebssystem-Image, den Treibern, Antennen, Funkmodulen, Kameras und Peripheriegeräten entsprechen. Es sollte an der vorgesehenen Bordstromquelle betrieben werden und die geplante Anwendung ausführen. Andernfalls kann eine erfolgreiche Demonstration nur eine Konfiguration belegen, die nie produziert wird.
Wischen Sie horizontal, um alle Spalten anzuzeigen.
| Freigabeschritt | Zu erstellender Nachweis | Frage, die es beantworten muss |
|---|---|---|
| Systembeschreibung | Fahrzeug, Betreiberaufgabe, Umgebung, Märkte, Menge und Lebenszyklus | Welches Problem muss das Terminal lösen? |
| Technische Karte | Display, Recheneinheit, Positionierung, E/A, Kabelbaum, Montage und Softwareverantwortung | Wer liefert und integriert jedes Teil? |
| Probenvalidierung | Seriennahe Konfiguration und schriftliche Abnahmematrix | Erholt sich das eingebaute System und erfüllt es seine Aufgabe unter repräsentativen Bedingungen? |
| Freigabekontrolle | Freigegebene Revision, Software-Image, Steckverbinderbelegung, Prüfungen und Änderungsverantwortlicher | Was genau darf reproduziert werden und welche Änderung löst eine Revalidierung aus? |
Drei Beispiele für die Grenze in der Praxis
Bagger oder Bergbaufahrzeug
Wenn das Projekt ein Bau- oder Bergbauterminal umfasst, kann PDS den Kabinencomputer, das Display und die vereinbarte E/A liefern. Gerätehersteller oder Integrator behalten die Verantwortung für Maschinennachrichten, Positionierungs- oder Höhenführungsalgorithmen, Halterungsfreigabe, Kamerainstallation und Abnahme vor Ort. Der T8-Bagger-Integrationsfall zeigt diese Grenze, ohne Anspruch auf ein nicht offengelegtes Kundenergebnis zu erheben.
Landwirtschaftliche Führung oder automatische Lenkung
PDS kann ein Bedienterminal liefern, das mit Positionierungs- und Fahrzeugsystemen verbunden ist. Im Gesamtprojekt müssen weiterhin Verantwortliche für Korrekturdienst, Antennen, Führungsanwendung, Lenksteuerung, Aktuator, Sicherheitslogik und Feldabnahme benannt werden. Ein Display oder RTK-Modul darf nicht so beschrieben werden, als würde es die Maschine eigenständig lenken.
Flotten- oder ÖPNV-Fahrzeug
Das Terminal kann die Fahrerschnittstelle bereitstellen und Positionierung, Kommunikation, Fahrzeugdaten und Kameras verbinden. Flottenplattform, Dispositionsregeln, Mobilfunknetz, Datenschutzentscheidungen, Datenaufbewahrung und Betriebsabläufe bleiben Teil des umfassenderen Kundendienstes.
Informationen, die PDS für eine OEM- oder Integrationsprüfung benötigt
- Fahrzeug oder Maschine, Kabinenzeichnung oder Fotos, Montagegrenzen und Bedienerreichweite.
- Bordstromquelle, Zündsignal, Abschaltzeit und erforderlicher Wiederanlaufzustand.
- Alle gleichzeitig benötigten CAN-, seriellen, Ethernet-, USB-, GPIO-, Audio-, Kamera- und Peripheriefunktionen.
- Anwendungsverantwortung, Betriebssystempräferenz, SDK-/Treiberbedarf sowie Verantwortung für Updates und Cybersicherheit.
- GNSS- oder RTK-Ziel, Empfänger, Antennen, Korrekturquelle, Abdeckung und beeinträchtigtes Verhalten.
- Zielmärkte, erforderliche Nachweise, Mustermenge, Jahresbedarf und erwarteter Lebenszyklus.
- Abnahmekriterien für Umgebung, Bordstromversorgung, E/A, Anwendungsverhalten und Betrieb im eingebauten Zustand.
Häufig gestellte Fragen zur Arbeit mit PDS
Kann PDS eine Standardplattform anpassen, anstatt von Grund auf neu zu entwerfen?
Dies ist der beabsichtigte Ausgangspunkt des veröffentlichten OEM/ODM-Pfades. Das Team wählt die nächstgelegene Standardplattform aus und bestätigt dann, welche Hardware-, Struktur-, I/O-, Firmware- oder Softwareunterschiede gerechtfertigt und verfügbar sind.
Wem gehören CAN-Nachrichtendefinitionen?
Das Projekt muss den Verantwortlichen benennen. PDS kann vereinbarte CAN-Hardware, Treiber oder Integrationsleistungen liefern; ein Steckverbinder stellt jedoch weder die Nachrichtendatenbank des Kunden bereit noch definiert er die Interpretation von Maschinenzuständen.
Ermöglicht ein IP-zertifiziertes Terminal, dass die gesamte Installation IP-zertifiziert ist?
Nein. Gehäusenachweise sind zusammen mit der jeweiligen Prüfkonfiguration zu lesen; eingebaute Steckverbinder, Kabelbaum, Halterung, Einführungen und Wartungszustand müssen gesondert beurteilt werden.
Wem gehört das Android- oder Linux-Image?
Verantwortung und Wartung richten sich nach dem angebotenen Projekt. Halten Sie fest, wer das Software-Image erstellt, signiert, aktualisiert, unterstützt und wiederherstellt und welche Treiber und Dienste enthalten sind.
Welche Änderungen erfordern eine erneute Validierung?
Jede Änderung, die die Abnahme beeinflussen kann – etwa Rechenmodul, Display, Speicher, E/A, Steckverbinder, Kabelbaum, Antenne, Funkmodul, Betriebssystem-Image, Treiber, Anwendung oder Montage – sollte gegen den kontrollierten Freigabestand geprüft werden.
Wie sollte ein Käufer beginnen?
Vervollständigen Sie die Checkliste für Fahrzeugcomputerspezifikationen, und senden Sie anschließend Maschine, Verantwortungsmatrix und Musterziel über die PDS OEM-Projektanfrage.
Geprüfte Quellen
Diese Links dokumentieren, was die genannten Organisationen selbst veröffentlichen. Unternehmenswebsites und unternehmenseigene Social-Media-Seiten sind Quellen aus erster Hand; sie belegen nicht unabhängig vergleichende Qualität, Zuverlässigkeit, Kundenzufriedenheit oder Serviceleistung.
