Comment PDS collabore avec les constructeurs OEM de véhicules industriels et les intégrateurs de systèmes

PDS peut fournir une plateforme embarquée standard ou adaptée, mais le système machine final reste un projet d’ingénierie partagé. Le périmètre chiffré par PDS peut inclure le boîtier, l’écran, la plateforme de calcul, certaines E/S, l’image du système d’exploitation, le matériel de positionnement et le faisceau. Les protocoles véhicule, la logique applicative, les services de correction, le matériel de commande, les décisions de sécurité et l’acceptation du système installé restent à la charge des parties désignées dans la spécification du projet.

Commencer par une matrice des responsabilités, et non par une liste de fonctions

Un catalogue indique les fonctions qu’une plateforme peut prendre en charge ; il n’attribue pas les responsabilités d’ingénierie. Avant de figer le matériel, l’équipe doit affecter chaque fonction à un responsable et à une méthode d’acceptation. Le parcours de projet OEM/ODM de PDS utilise la machine, le flux de travail de l'opérateur, les interfaces, la chaîne de positionnement et le cycle de vie comme point de départ. Le profil de l’entreprise PDS donne le contexte plus large de la marque et du produit.

Choisissez une plateforme standard avant de décider quoi personnaliser

Un projet peut partir de la gamme actuelle d’ordinateurs embarqués PDS et choisir le format le plus proche du flux de travail réel. Par exemple, le T8 Pro est une direction de 8 pouces à calcul plus élevé pour le travail avec caméra ou multi-écrans, tandis que le T10B est une plateforme de 10,1 pouces proposée actuellement sous Android ou Linux embarqué. Ces indications sont des points de départ ; le processeur, la mémoire, les E/S, le positionnement, les fonctions sans fil et les caractéristiques environnementales exigent toujours une configuration sous contrôle documentaire.

La personnalisation devrait résoudre une lacune documentée. Il peut s'agir d'un détail du boîtier, d'une marque, d'une carte des connecteurs, d'un faisceau, d'un module, d'une image du système d'exploitation, d'un pilote, d'un comportement de démarrage ou d'une API. Si une plate-forme standard répond déjà aux exigences, des modifications inutiles ajoutent du travail de validation et de cycle de vie sans améliorer la tâche de l'opérateur.

Définir séparément le boîtier et l'environnement installé

L'évaluation d'un boîtier n'évalue pas automatiquement l'ensemble du système installé. CEI 60529 définit les indices IP des enveloppes, tandis que l’installation finale comprend aussi les connecteurs accouplés, les entrées de câble, les évents, les joints, le support et la procédure de maintenance. Le projet doit identifier la configuration testée et préciser si les connecteurs étaient accouplés.

Appliquez la même méthode à la température, aux chocs et aux vibrations. Consignez le point de montage, les vibrations continues, les impacts, l’exposition au soleil, la méthode de nettoyage et les sources de chaleur autour du terminal. Le support et le faisceau représentatifs de la production font partie de l’essai sur véhicule, car l’essai du boîtier seul ne prouve ni la lisibilité, ni la tenue des connecteurs, ni la durée de vie des câbles.

Distinguer la plage d’entrée électrique de la validation de l’alimentation véhicule

Une plage de tension d’entrée étendue n’est qu’un point de départ. Le terminal installé peut subir le lancement du moteur, les transitions de contact, une inversion de polarité, des transitoires de charge, des différences de masse et des coupures inattendues. ISO 7637-2 décrit les méthodes d'essais transitoires menés pour les équipements de véhicules routiers 12 V et 24 V, tandis que ISO 16750-2 couvre les charges électriques et note l’influence du faisceau de câbles. Les normes exactes et la gravité requises pour un projet hors route ou régional doivent être convenues plutôt que supposées.

Les questions fonctionnelles comptent autant que l’impulsion électrique : quel signal correspond au contact, combien de temps l’arrêt peut-il prendre, quelles données doivent être enregistrées et quel état apparaît après le redémarrage ? PDS peut configurer le comportement du terminal inclus dans son périmètre ; le signal véhicule et le processus complet de reprise exigent une validation au niveau système.

Attribuer explicitement l'intégration CAN, série et caméra

Un port CAN prouve la présence d'une interface matérielle ; il ne fournit pas la base de données CAN du client, l'interprétation J1939, les messages propriétaires ou l'autorisation de commander une machine. La documentation Linux sur SocketCAN, par exemple, décrit une interface standard du système d’exploitation pour le réseau CAN ; les identifiants applicatifs, l’échelonnage, la logique d’état et le traitement des défauts restent propres au projet.

Pour chaque interface, documentez le responsable du protocole, la norme électrique, le débit, le connecteur, le besoin d’usage simultané et le comportement en cas de panne. Pour les caméras, précisez aussi la norme du signal, la résolution, le nombre, le déclenchement, la latence et le besoin d’enregistrement ou d’affichage. Une plateforme qui accepte plusieurs entrées peut encore nécessiter une validation avec la charge simultanée exacte du projet.

Traitez RTK comme une chaîne, pas comme une case à cocher de module

Un terminal compatible RTK ne garantit pas une précision fixe dans toutes les conditions. Le positionnement dépend de la conception du récepteur et des antennes, de la visibilité des satellites, des trajets multiples, des données de correction, des communications, de la configuration et de la gestion des états dégradés par l’application. Les recommandations du gouvernement américain sur la précision du GPS indiquent également que la précision obtenue dépend de l’environnement et des caractéristiques du récepteur.

Le projet doit préciser le récepteur, la géométrie de l’antenne ou des deux antennes, la source de correction, la liaison NTRIP ou radio, les régions visées, les états de qualité et la réponse attendue de l’opérateur. PDS peut fournir les composants de terminal convenus et l’intégration des états ; l’abonnement aux corrections, l’installation des antennes, la couverture et la réponse de la machine restent à la charge du responsable désigné. Utilisez la Liste de contrôle d'intégration RTK GNSS pour construire le plan d’essai complet.

Attribuer la propriété pour Android ou Linux intégré

« Fonctionne sous Android » ne constitue pas une spécification logicielle complète. Le projet doit consigner la version d’Android, l’image de référence AOSP ou autre, les services requis, les API matérielles, la signature, la méthode de mise à jour, le retour arrière et la responsabilité de l’assistance. Cet aperçu de la compatibilité Android explique qu’une implémentation Android et la compatibilité formelle sont deux notions distinctes ; les services Google ou l’accès à Play ne doivent jamais être déduits du seul nom du système d’exploitation.

Linux embarqué exige aussi des responsables désignés pour le BSP, le noyau, les pilotes, les bibliothèques, Qt ou un autre cadre applicatif, la politique des paquets, la maintenance de sécurité et la reprise sur le terrain. Le guide de choix entre Android et Linux pour les terminaux embarqués aide les équipes à attribuer cette responsabilité avant de choisir l’image finale.

Valider un échantillon représentatif de la production

Un échantillon utile doit représenter le boîtier prévu, la configuration de calcul et de mémoire, le plan des connecteurs, le faisceau, l'image du système d'exploitation, les pilotes, les antennes, les modules sans fil, les caméras et les périphériques. Il doit fonctionner à partir de la source d’alimentation du véhicule cible et exécuter l’application prévue. Dans le cas contraire, une démonstration réussie pourrait révéler une configuration qui ne sera jamais produite.

Trois exemples concrets de cette répartition

Excavatrice ou véhicule minier

Dans un terminal de construction ou minier, PDS peut fournir l’ordinateur en cabine, l’écran et les E/S convenues. Le constructeur de l’équipement ou l’intégrateur conserve la responsabilité des messages machine, des algorithmes de positionnement ou de nivellement, de la validation du support, de la pose des caméras et de l’acceptation sur site. Le Cas d'intégration de pelle T8 montre cette limite sans revendiquer un résultat client non divulgué.

Guidage agricole ou pilotage automatique

PDS peut fournir un terminal opérateur relié aux systèmes de positionnement et du véhicule. Le projet global doit toujours attribuer le service de correction, les antennes, l’application de guidage, le contrôleur de direction, l’actionneur, la logique de sécurité et l’acceptation sur le terrain. Un écran ou un module RTK ne doit pas être présenté comme pilotant seul la machine.

Flotte ou véhicule de transport en commun

Le terminal peut héberger l’interface conducteur et relier le positionnement, les communications, les données véhicule et les caméras. La plateforme de flotte, les règles de répartition, le réseau mobile, les décisions de confidentialité, la conservation des données et les procédures d’exploitation restent intégrés au service global du client.

Informations nécessaires à PDS pour l’examen d’un projet OEM ou d’intégration

• Véhicule ou machine, dessin ou photographies de la cabine, limites de montage et portée de l'opérateur.
• Source d’alimentation, signal de contact, temporisation d’arrêt et état de reprise requis.
• Tous les besoins simultanés CAN, série, Ethernet, USB, GPIO, audio, caméra et périphériques.
• Propriétaire de l'application, préférence du système d'exploitation, besoins en SDK/pilote, responsabilités en matière de mise à jour et de cybersécurité.
• Cible GNSS ou RTK, récepteur, antennes, source de correction, couverture et comportement dégradé.
• Marchés de destination, preuves requises, nombre d’échantillons, estimation annuelle et durée de vie attendue.
• Critères d'acceptation pour l'environnement, l'alimentation, les E/S, le comportement de l'application et le fonctionnement installé.

Questions fréquentes sur la collaboration avec PDS

PDS peut-il adapter une plateforme standard au lieu de concevoir à partir de zéro ?

C’est le point de départ du parcours OEM/ODM publié. L’équipe choisit la plateforme standard la plus proche, puis confirme les adaptations matérielles, structurelles, d’E/S, de firmware ou de logiciel qui sont justifiées et disponibles.

À qui appartiennent les définitions des messages CAN ?

Le projet doit désigner un responsable. PDS peut fournir le matériel CAN, les pilotes ou le travail d’intégration convenus, mais un connecteur ne donne pas accès à la base de messages du client et ne définit pas l’interprétation des états machine.

Un terminal classé IP rend-il l'installation complète classée IP ?

Non. Les preuves concernant le boîtier doivent être lues avec la configuration d’essai ; les connecteurs, le faisceau, le support, les entrées de câble et l’état en service de l’installation exigent une évaluation distincte.

À qui appartient l’image Android ou Linux ?

La propriété et la maintenance dépendent du projet chiffré. Consignez qui construit, signe, met à jour, prend en charge et restaure l’image, ainsi que les pilotes et services inclus.

Quels changements nécessitent une revalidation ?

Tout changement pouvant affecter l'acceptation (y compris le module de calcul, l'affichage, la mémoire, les E/S, le connecteur, le faisceau, l'antenne, la radio, l'image du système d'exploitation, le pilote, l'application ou le montage) doit être examiné par rapport à l'enregistrement de version contrôlée.

Comment un acheteur doit-il commencer ?

Complétez la liste de contrôle des spécifications de l’ordinateur embarqué, puis transmettez la machine, la matrice des responsabilités et l’objectif d’échantillon via la Demande de projet OEM PDS.