Solutions · Véhicules autonomes
Livrez une pile véhicule autonome.
Un OS à composants distribué pour les programmes de conduite autonome. Hôte de classe ROS2 sur silicium industriel. Prêt edge-AI — caméra, GPU, NPU partagent la mémoire. Micro services isolés en processus avec limites de ressources appliquées.
Périmètre, annoncé d'emblée
Ce que c'est, et ce que ce n'est pas.
Ce que MOS4 livre
- Le runtime — OS à composants distribué, conteneurs hot-swappables.
- Nœuds ROS2 hébergés via le micro service de pont ROS2.
- Perception multi-caméra avec mémoire partagée GPU-vers-NPU, sans copie pixel CPU.
- Couverture bus machine : J1939, ISOBUS, CANopen, Modbus, J1708, CAN-FD, DoIP.
- GNSS RTK, IMU, géofencing 1 000+ zones, et pipeline de traitement du signal pour la fusion de capteurs.
- Uplink de télémétrie avec attestation signée.
- Diagnostic à distance, reconfiguration et remédiation signée.
- Software bill of materials (SBOM) et artefacts de conformité pour la chaîne de preuves CRA.
Ce que MOS4 ne livre pas
- Une pile de conduite L4 (entièrement autonome) pour route ouverte.
- Cartes HD ou licences de tuiles cartographiques.
- Un certificat d'homologation pour les décisions d'autonomie.
- Vos modèles de perception, planification ou contrôle — nous hébergeons les vôtres.
- Un dossier de sûreté fonctionnelle de la machine intégrée.
- Une certification ADAS ou route ouverte automotive-safety.
Vous construisez pour la route ouverte ? MOS4 n'est pas le bon OS pour ce programme.
Le problème de l'acheteur
L'autonomie hors route ouverte est un monde à part.
Pas de processus d'homologation route. Pas de pile L4 (entièrement autonome) à acheter sur étagère. Vous détenez l'application autonomie, et il vous faut un OS qui héberge les nœuds ROS2 que vous avez déjà écrits, qui parle aux bus CAN et ISOBUS de la machine, qui exécute votre perception sur silicium classe IA, qui streame la télémétrie, qui accepte un reboot à distance quand quelque chose se fige, et qui est livré conforme CRA dès le premier jour.
Comment MOS4 s'inscrit
Cinq capacités pour une machine autonome.
ROS2 hébergé, pas réécrit
Un micro service de pont ROS2 connecte n'importe quel nœud ROS2 non modifié à MOS4 via un lien de processus local. Les nœuds de perception, planification et contrôle que vous livrez déjà restent là où ils sont — MOS4 les héberge sur une plateforme plus légère aux côtés de CAN, GNSS, télémétrie et remote care.
Perception sur silicium classe IA
Capture multi-caméra (MIPI-CSI, GMSL2, USB UVC), extraction de région d'intérêt avec mémoire partagée GPU-vers-NPU, et inférence de réseau de neurones embarquée. Jusqu'à ~100 TOPS sur la classe IA. Le CPU ne copie jamais les pixels dans le chemin d'inférence.
Bus machine, pas seulement CAN
J1939, ISOBUS (ISO 11783), CANopen, Modbus RTU/TCP, J1708, CAN-FD, DoIP — concurrents sur un même appareil. Les définitions de piles sont des fichiers de données ; ajouter un nouveau groupe de paramètres (PGN) ou signal (SPN) ne nécessite aucun changement de firmware.
Fusion de capteurs et plateforme de sûreté
GNSS RTK (Real-Time Kinematic) avec dead-reckoning IMU, géofencing 1 000+ zones évalué embarqué, et pipeline de traitement du signal pour la fusion de capteurs. Des patterns de décision basés sur les preuves sont disponibles pour les transitions de mode d'autonomie où une piste d'audit est requise.
Remote care intégré
Uplink de télémétrie (signé, attesté). Hot-reload des graphes de traitement du signal, des politiques de machine d'états d'autonomie, et des cartes de géofences. Mises à jour over-the-air (OTA) signées avec rollback automatique. Reboot à distance, re-flash à distance, diagnostic à distance — capacité native de l'OS, pas un add-on. Une immobilisation évitée rembourse l'appareil.
Métriques plateforme
Chiffres clés.
Architecture de référence
Une machine autonome sur MOS4.
Architecture de référence — fleet manager cloud connecté via uplink MQTT sécurisé à un ECU MOS4 embarqué. L'ECU exécute des nœuds ROS2 conteneurisés pour la perception, la planification et le contrôle. Multi Stacks gère J1939, ISOBUS, CANopen, Modbus sur le bus machine, alimentant un pipeline de fusion de signaux. La capture caméra alimente l'extraction de région d'intérêt, puis l'inférence NPU embarquée. La fusion de signaux, le NPU et ROS2 alimentent la machine d'états d'autonomie. La machine d'états commande le bus CAN actionneurs. L'ECU expose également une surface remote-care pour la remédiation signée.
flowchart LR Cloud[Cloud · fleet manager] --> Up[MD21 · MQTT secure uplink] Up --> ECU[MOS4 in-machine ECU] ECU --> MCM[MCM · containers] MCM --> ROS2[ROS2 nodes<br/>perception · planning · control] ECU --> MS[Multi Stacks<br/>J1939 · ISOBUS · CANopen · Modbus] MS --> MSP[MSP · signal fusion] ECU --> CAP[Camera capture<br/>MIPI · GMSL · UVC] CAP --> ROI[ROI shader<br/>GPU → NPU zero-copy] ROI --> NPU[mos-ai-runtime<br/>.tflite inference] NPU --> MEP[MEP · autonomy state-machine] MSP --> MEP ROS2 --> MEP MEP --> CMD[Command bus → actuator CAN] ECU --> RC[Remote care<br/>signed remediation]
Exemple traité
Un tug aéroportuaire autonome.
Un fabricant de véhicules d'opérations au sol aéroportuaires livre un tug à bagages autonome. La pile d'autonomie est la sienne — perception, planification, contrôle, le tout écrit en ROS2 par une petite équipe. Le châssis et l'interface drive-by-wire sont les siens. Le runtime, l'abstraction silicium, le bus machine, la capture multi-caméra, le calcul IA, l'uplink de télémétrie et la surface remote-care viennent de MOS4.
ROS2 préservé
Les nœuds ROS2 existants se déploient sans changement dans des conteneurs isolés. Le micro service de pont ROS2 traduit les messages ROS2 vers et depuis le bus d'événements MOS4 de manière bidirectionnelle.
Télémétrie dès le premier jour
L'uplink MD21 est livré avec l'OS. Les opérateurs flotte voient en direct la position, la santé, le mode et l'état des défauts sans écrire de couche de télémétrie.
Reboot à distance éprouvé
Un tug bloqué à la porte 14 au milieu d'un retournement n'exige pas qu'un technicien conduise jusqu'à l'aire de trafic. Une action signée à distance redémarre le processus concerné ; si le SoC est figé, un reboot signé à distance ramène l'unité à un état connu-bon.
Preuve anonyme
Fabricant de véhicules d'opérations au sol aéroportuaires · déploiement mondial.
Un fabricant leader de véhicules d'opérations au sol aéroportuaires déploie MOS4 dans sa flotte. Le logiciel d'autonomie et le châssis sont les siens ; le runtime, la télémétrie et la surface remote-care sont MOS4. Référence sous NDA — appel de référence médiatisé par les ventes disponible sur demande.
Référence sous NDA · demander un appel de référence médiatisé par les ventes
FAQ
Questions fréquentes
-
MOS4 livre-t-il une pile autonomie pour route ouverte ?
Non. MOS4 est conçu pour l'opération sur site privé — ferme, terrain d'aviation, mine, carrière, terminal portuaire, golf, dépôt. Le L4 sur route ouverte est hors périmètre par conception. Les acheteurs qui construisent des systèmes route ouverte ont besoin d'une autre chaîne d'outils.
-
Qui détient la décision d'autonomie ?
Vous. MOS4 héberge vos modèles de perception, planification et contrôle. Nous ne certifions pas les décisions d'autonomie, nous ne remplaçons pas vos nœuds perception/planification/contrôle, et nous ne fournissons pas de cartes HD. Nous fournissons la plateforme — runtime, bus machine, calcul IA, uplink, remote care, audit.
-
Cela fonctionne-t-il avec des nœuds ROS2 existants ?
Oui. Le micro service de pont ROS2 traduit les messages ROS2 (DDS) vers et depuis le bus d'événements MOS4 de manière bidirectionnelle. Les nœuds ROS2 existants tournent dans des conteneurs isolés sans modification de code. Voir la passerelle sidecar ROS2 sur la page SDK.
-
Quelle classe matériel est requise pour la perception IA ?
Silicium classe IA pour l'inférence embarquée de réseau de neurones. Les services d'extraction de région d'intérêt et de runtime IA nécessitent un NPU ; aucun fallback CPU en production. Le bus machine, la télémétrie et les surfaces remote care tournent sur classe compute. Voir la page matériel pour l'échelle des classes silicium.
-
Comment la flotte survit-elle à une panne sur le terrain ?
Remote Care est la réponse. Diagnostic à distance signé, hot-reload des graphes de traitement du signal et des politiques de machine d'états d'autonomie, mises à jour over-the-air (OTA) signées avec rollback automatique, reboot à distance au niveau processus et SoC. L'OS ne court-circuite pas les verrous de sûreté ; les remédiations sont médiatisées par opérateur et journalisées en audit.
-
Y a-t-il un support de conformité CRA ?
Oui. Un pipeline cycle de vie de développement logiciel avec software bill of materials (SBOM, format CycloneDX), audit des dépendances, analyse statique, mises à jour signées et journaux d'audit par action sont livrés dès le premier jour. Voir la page conformité pour le mapping article par article complet.
-
Puis-je nommer MOS4 dans mon dossier de sûreté ?
MOS4 livre les artefacts de conformité, les software bills of materials (SBOM) et les preuves du pipeline de sécurité. La certification de sûreté fonctionnelle (ISO 26262 / ISO 25119) de la machine intégrée est de la responsabilité de l'OEM — nous fournissons les preuves sous-jacentes, vous construisez l'argumentaire de sûreté.
Apportez votre machine autonome.
Classe de véhicule, mix capteurs, empreinte ROS2, protocoles de bus, topologie flotte — apportez les contraintes. L'ingénierie esquissera l'adéquation MOS4 pendant l'appel.