"Dans le contexte de l'ère des voitures définies par logiciel, le statut du logiciel est de plus en plus élevé, et le développement de l'industrie automobile intelligente nécessite le découplage du logiciel et du matériel." 🎜#
Vous devez être familier avec des mots comme ceux ci-dessus Au cours des dernières années de développement des voitures intelligentes, la composition de la chaîne d'approvisionnement automobile a subi des changements bouleversants, et le découplage entre logiciel et matériel est devenu un problème important, tant pour les constructeurs OEM que pour les fournisseurs qui tentent toujours de résoudre le problème.
Toutefois, les standards sont encore difficiles à unifier, et les interfaces de chaque entreprise sont encore différentes. Même après toutes ces années, le découplage logiciel et matériel se heurte encore à de nombreuses difficultés.
L'évolution de l'architecture EE# 🎜🎜 #
(Les lecteurs qui connaissent cette partie du sujet peuvent la sauter et passer directement à la section suivante)# 🎜🎜##🎜 🎜#Il y a quelques années, il n'y avait qu'une douzaine à vingt ECU sur un véhicule. Cependant, à mesure que le consumérisme du divertissement électronique continue d'envahir tous les aspects de la vie des gens, les exigences fonctionnelles des gens en matière de voitures ont progressivement augmenté, et en le distribué Dans le contexte de l'architecture, chaque nouvelle fonction nécessite l'ajout continu du calculateur correspondant. Cela est particulièrement vrai pour les voitures autonomes. En conséquence, le nombre d’ECU sur une voiture autonome est passé à près de 1 ou 200 au maximum.
L'augmentation continue du nombre d'ECU a entraîné une augmentation continue de la longueur totale et du coût total des faisceaux de câbles utilisés pour la transmission de données (selon les calculs de Zos Automotive Research, si l'architecture distribuée actuelle, le coût du faisceau de câbles des véhicules autonomes ne sera pas inférieur à 1 000 $ US), et les difficultés de gestion des fournisseurs ont également augmenté.
De plus, dans l'architecture distribuée, les fonctions telles que ACC et AEB sont liées au capteur (MCU à l'intérieur) et sont séparées les unes des autres (cela ne signifie pas se conformer aux premiers principes (ce n'est pas le cas lorsque les gens conduisent), et l'exigence d'une conduite autonome de haut niveau est que chaque fonction est un organisme, elle doit donc être implémentée via le même SoC.
Dans ce contexte, comment améliorer l'utilisation de l'espace et maximiser les performances de l'ECU dans un espace limité est devenu la prochaine étape dans l'orientation du développement de l'industrie. En conséquence, l'architecture EE automobile a ouvert la porte à l'évolution d'une architecture distribuée vers une architecture centralisée. À cette fin, de nombreux contrôleurs de domaine ont commencé à être remplacés par des contrôleurs de domaine et la puce de contrôle principale a été mise à niveau. MCU précédent vers SoC.
Le nombre d'ECU continue de diminuer, et les ECU restants dans la voiture sont également passés de la nécessité initiale de supporter une partie des calculs à ceux qui n'ont besoin que de supportent la plupart des fonctions d'exécution et ont des capacités de traitement affaiblies « Vis » (le calculateur a toujours la capacité d'origine de traiter les calculs, mais il n'est plus fonctionnellement nécessaire pour traiter une partie des calculs).
L'évolution de l'architecture EE de distribuée à centralisée par domaine, le SoC remplaçant le MCU, offre une transition inter-domaines pour l'industrie automobile de l'ère du « le matériel est roi » à l'ère des « voitures définies par logiciel » Prérequis créés.
La puce SoC intègre plusieurs modules tels que DSP, GPU et NPU. Elle dispose non seulement d'une unité de contrôle mais intègre également un grand nombre d'unités de calcul. Cela permet aux puces SoC non seulement d'effectuer plusieurs tâches simultanément, mais également d'avoir la capacité de traiter de grandes quantités de données. Remplacer certains MCU par des puces SoC, c'est comme remplacer les dirigeants ordinaires de plusieurs départements d'une entreprise par un PDG super excellent qui peut égaler un à cent.
À une époque où le matériel est roi, en raison du haut degré de couplage entre logiciel et matériel, les constructeurs OEM trouveront d'abord des sociétés de conseil pour réaliser des rapports d'analyse des exigences fonctionnelles automobiles pour les 5 à 8 prochaines années, puis élaborer un plan d'intégration logicielle et matérielle sur 5 à 8 ans basé sur le rapport. Lorsque les logiciels et le matériel sont introduits dans la chaîne de production, jusqu'à ce que le constructeur du véhicule ait installé les différents composants et expédié le véhicule, il sera difficile pour le véhicule de changer de logiciel ou de matériel dans un délai de 5 à 8 ans.
À l'ère des voitures définies par logiciel, si nous suivons toujours le processus d'intégration de l'usine automobile d'origine et établissons immédiatement un plan de construction automobile sur 5 à 8 ans, alors dans la construction automobile Le problème ne sera pas trop important au cours des premières années, mais dans la seconde moitié de la période du plan, lorsqu'une voiture est livrée à l'utilisateur, le matériel et les logiciels de la voiture sont de loin obsolètes.
Par conséquent, lors de la phase de conception du produit, les problèmes d'itération ultérieurs doivent être pris en compte. Pour résoudre le problème d’itération, le logiciel et le matériel doivent être développés séparément.
Lorsque les configurations matérielles des différents constructeurs automobiles ont convergé, le matériel est devenu « enroulable ». Afin de se différencier, les constructeurs OEM doivent être capables de collecter les besoins changeants des utilisateurs avec des capacités de réponse très rapides et de procéder aux ajustements logiciels correspondants. itération. À l'heure actuelle, les OEM ont deux options : l'une consiste à développer eux-mêmes des logiciels et des algorithmes et à résoudre tous les problèmes par eux-mêmes, y compris le découplage logiciel et matériel ; l'autre consiste à trouver un fournisseur approprié pour répondre aux exigences d'itération après le découplage logiciel et matériel ;
Si vous voulez emprunter la première voie, l'OEM a besoin d'une très grande force, mais tous les OEM n'ont pas de telles capacités, donc la plupart des OEM préféreront emprunter la deuxième voie. En conséquence, le statut des sociétés d’algorithmes logiciels a commencé à s’améliorer et la relation dans la chaîne d’approvisionnement automobile est passée des niveaux clairs d’origine Tier1, Tier2 et Tier3 à une relation aux frontières floues.
Dans ce contexte, il existe également un besoin de découplage logiciel et matériel entre les différents fournisseurs de logiciels et de matériel pour une compétitivité plus forte, un meilleur développement indépendant et une meilleure écologie de coopération.
Cependant, bien que le slogan du découplage logiciel et matériel soit crié depuis plusieurs années, l'effet n'est pas idéal.
Il est difficile de découpler les capteurs, les puces et les algorithmes
Étant donné que les algorithmes et les capteurs sont fortement liés, dans les applications pratiques, une telle liaison cause beaucoup de problèmes aux ingénieurs en algorithmes. Par exemple, une fois que l’appareil photo précédemment utilisé dans une voiture est passé d’un appareil photo de 2 mégapixels à un appareil photo de 8 mégapixels, l’algorithme ne doit pas être réécrit.
De plus, un ingénieur en algorithmes de niveau 1 :
"Même si nous avons la possibilité de découpler l'algorithme de détection et le capteur, il est particulièrement difficile de calibrer le capteur après découplage." le soft Le couplage matériel est élevé et les données du capteur sont également fortement liées au capteur. Une fois le capteur remplacé, toutes les annotations de données auparavant coûteuses seront invalidées et un nouveau cycle de collecte devra être lancé. C'est très important pour les sociétés d'algorithmes. On dit que c'est une chose très gênante, mais il n'existe actuellement aucune bonne solution à ce problème.
De plus, la configuration du capteur, la position d'installation et l'angle d'installation sur chaque véhicule sont différents, donc les algorithmes sont également différents. Les algorithmes de détection sont différents et les algorithmes de contrôle sont différents.
Si le découplage des algorithmes et des capteurs est tout simplement gênant, alors le découplage des algorithmes et des puces est très difficile.
Par exemple, lorsque l'auteur a communiqué avec de nombreux ingénieurs en algorithmes au sujet de problèmes liés au découplage logiciel et matériel, j'ai découvert que l'un des problèmes communs qu'ils ont tous est que beaucoup de travail supplémentaire est nécessaire en raison de la difficulté de transplantation d'algorithmes.
Cela est dû au fait que la fréquence de migration des algorithmes est imprévisible. La concurrence et les itérations de produits des fabricants de puces affectent souvent les préférences du marché. Vous ne pouvez pas être sûr qu'il y aura de nouvelles et meilleures puces qui se vendront très bien dans la prochaine tendance.
Les changements dans les préférences du marché amèneront les OEM à spécifier des puces de remplacement. À l'heure actuelle, pour les ingénieurs en algorithmes, peut-être que votre algorithme basé sur cette puce vient d'être amélioré et qu'il y aura de nouvelles exigences de transplantation d'algorithmes.
La raison du phénomène ci-dessus est la forte relation de liaison entre l'algorithme et la puce. Différentes puces fournissent différents BSP, ce qui rend difficile la réutilisation du middleware utilisé pour découpler les puces et les algorithmes, et différentes adaptations personnalisées doivent être apportées pour différentes puces.
Le responsable du système de conduite intelligente d'un certain OEM a expliqué :
« L'adaptation du middleware à la couche inférieure BSP est un casse-tête. Par exemple, la puce du cockpit utilise le 8155 ou le 8295 de Qualcomm. et le pilotage automatique. La puce utilise le TDA4 de TI, donc comme les BSP fournis par leurs puces sont différents, une adaptation personnalisée du middleware est nécessaire lors de l'intégration. "
Non seulement les différences entre les plates-formes de puces empêchent la réutilisation du middleware. De plus, si deux contrôleurs de domaine basés sur la même plateforme de puces ont des architectures matérielles différentes (certains contrôleurs de domaine ont 2 voire 3 SoC), ils ont des exigences différentes en matière de middleware.
02 Dilemmes techniques liés au découplage logiciel et matériel
Le middleware actuel doit en fait être personnalisé en fonction de la fonction, de la plate-forme matérielle et du système d'exploitation. Même le middleware le plus standardisé nécessite que les sociétés d'algorithmes ou les OEM l'adaptent. un middleware qui peut tout couvrir. Parce que tous les middlewares auront certaines limitations ou restrictions, par exemple, certains ne peuvent pas définir rapidement les interfaces de communication, certains ne sont pas particulièrement conviviaux pour certaines prises en charge multiplateformes et certains ne s'adaptent pas bien à d'autres puces.
Quant au middleware, à partir de la transmission des données elle-même, il y aura des problèmes tels que la déviation des données, les erreurs de données et la défaillance d'un seul module affectant la transmission des données. Par exemple, si le volume de transmission de données est important, lorsque SOME/IP effectue une acquisition de données, de nombreux signaux de communication ne peuvent pas être collectés et la perte de paquets est facile à se produire.
De plus, les erreurs de retour de données peuvent facilement provoquer une série de réactions en chaîne, affectant finalement les niveaux de prise de décision et d'exécution, entraînant des conséquences néfastes. On peut dire que le partage de données présente des avantages et des inconvénients. En théorie, il peut améliorer l'efficacité, mais si la source est erronée, cela entraînera une série d'erreurs et il y aura également un manque de mécanismes efficaces de diagnostic et de correction.
De plus, l'heure et le lieu auront également un impact sur la transmission des données. Par exemple, à des vitesses élevées, Autosar AP aura des exigences plus élevées en matière de bande passante de transmission de données. À ce stade, le conflit entre le protocole de transmission de bande passante et la transmission de données en co-ligne sera particulièrement évident. Pendant les vacances, l'utilisation de la bande passante est concentrée et la charge est trop élevée, ce qui peut ne pas suffire à répondre aux besoins de transmission de données.
En plus des problèmes ci-dessus, le middleware actuel présente également des problèmes tels que le mécanisme de mise en cache n'est pas bien fait, le groupe de fonctions ne prend pas en charge l'imbrication et l'état la collaboration machine ne se fait pas bien, etc. Ces problèmes obligent les ingénieurs algorithmiques à apporter des modifications sur la base des middlewares existants, ce qui augmente considérablement la difficulté de découplage logiciel et matériel.
En plus des difficultés techniques ci-dessus, les logiciels Le découplage matériel se heurte également à une série de difficultés commerciales.
Fabricant de middleware professionnel
Avec Vector, RTI, EB Middleware Les fabricants représentés par Yitechi espèrent produire un ensemble de middleware standardisés pouvant être adaptés aux logiciels et au matériel de chaque entreprise et répondre en une seule étape aux demandes de chaque entreprise en matière de découplage logiciel et matériel.
Mais la réalité n'est pas aussi belle qu'on l'imagine. D'une part, à l'exception de quelques grandes sociétés de middleware, il est difficile pour les produits de la plupart des sociétés de middleware de gagner la véritable confiance des OEM ; d'autre part, la plupart des sociétés d'algorithmes ne sont pas aussi disposées à coopérer avec les fabricants de middleware. , car une fois que les interfaces et les systèmes de mise en œuvre seront unifiés par les fabricants de middleware, cela signifie que la substituabilité de leurs propres produits sera améliorée et la différenciation sera réduite, ce qui entraînera une augmentation soudaine de la pression concurrentielle de la part des sociétés d'algorithmes, elles sont donc très résistant.
De plus, alors que la voie de développement technologique des voitures intelligentes n'est pas encore claire, les équipementiers espèrent que la configuration de leurs propres voitures sera différente de celle des produits concurrents pour gagner en concurrence Les barrières (la différenciation de la couche application nécessite également la différenciation des middlewares pour la prise en charge) et les middlewares standardisés iraient à l'encontre de ce désir. Par conséquent, les OEM préfèrent développer leur propre middleware plutôt que d’utiliser un middleware standardisé développé par des sociétés de middleware.
Finalement, ces middlewares deviennent difficiles à vendre, et il devient insoutenable de ne proposer que des middlewares standardisés.
D'après ce que Jiuzhang Zhijia a appris, à l'exception de Huayutongsoft et d'autres, ils se concentrent sur des modules à hautes barrières techniques comme DDS, et ont réussi le test depuis longtemps À l'exception des entreprises qui ont acquis certains avantages concurrentiels grâce à l'accumulation, la plupart des entreprises qui se positionnaient à l'origine comme des « fournisseurs de middleware » ont essentiellement commencé à se transformer (à s'étendre dans d'autres domaines) au cours des deux dernières années.
Fournisseur
Les sociétés d'algorithmes et certains logiciels et matériels sont tous Les fabricants de niveau 1 et de puces ont commencé à créer des middlewares, mais dans la pratique, tout le monde a du mal à apprendre.
Algorithm Company
Pour les sociétés d'algorithmes, si elles Si le Le middleware standardisé acheté est trop générique, il y aura de nombreux problèmes d'adaptation qui ne pourront pas être résolus. Cependant, si vous obtenez un middleware universel livré dans une boîte noire, il ne correspondra pas suffisamment à l'algorithme et cela posera de grandes difficultés aux ingénieurs en algorithmes. Et si vous achetez un middleware personnalisé, la société d’algorithmes devra également passer beaucoup de temps à communiquer avec le fabricant du middleware, et le coût sera très élevé.
Directeur technique d'une société d'algorithmes :
« S'il y a un problème, en général, l'entreprise signalera le problème au fabricant du middleware, mais certains fabricants sont moins coopératifs et exigent que la société d'algorithmes fournisse des preuves concrètes à prouver qu'il s'agit d'un problème de middleware, sinon ce sera un gâchis, qui consommera plus de main d'œuvre et de temps et affectera le processus de développement.
"En particulier, les sociétés d'algorithmes qui viennent de commencer à s'impliquer dans le middleware ne sont pas particulièrement. professionnel dans sa compréhension du middleware.Trouver des comparaisons empiriques.C'est difficile et prendra plus de temps et si plusieurs parties coopèrent dans ce processus, l'OEM devra avoir des personnes à coordonner, ce qui prolongera encore les progrès de la résolution du problème. "
Ainsi, les sociétés d'algorithmes choisissent simplement de développer des middlewares auto-développés pour mieux correspondre à leurs propres algorithmes.
De plus, les middlewares fabriqués par les fabricants internationaux de middlewares sont chers, tandis que les middlewares fabriqués par les start-up nationales fabricants de middleware Le logiciel n'est peut-être pas plus adapté que le middleware développé par soi-même basé sur son propre algorithme, ce qui est aussi l'une des raisons pour lesquelles les sociétés d'algorithmes développent leur propre middleware
« Si je le développe moi-même, j'aurai un une meilleure compréhension des besoins de mon projet. Serait-ce mieux que de laisser les fournisseurs de middleware le développer ? " a déclaré un ingénieur en architecture système d'une société d'algorithmes.
En plus de ce qui précède, il existe une autre raison pour laquelle les sociétés d'algorithmes développent des middlewares auto-développés : les algorithmes de diverses sociétés d'algorithmes présentent de petites différences, et les middlewares auto-développés sont nécessaire pour former la différenciation des produits.
Un directeur principal d'une société d'algorithmes a déclaré :
"À l'heure actuelle, il est difficile de refléter les différences de chaque algorithme. Ils sont tous programmés en C et C++. Pour refléter les différences, les performances doivent être améliorées sur le middleware. Pour ce faire, nous devons améliorer la fiabilité, ce qui consiste à renforcer certains avantages de l'expérience fonctionnelle. «
Cependant, les sociétés d'algorithmes sont également confrontées à de nombreux défis lorsqu'elles développent des middlewares auto-développés. Tout d'abord, les middlewares développés par les OEM peuvent établir des normes pour les fournisseurs, mais si les sociétés d'algorithmes développent des middlewares auto-développés, ce sera le cas. difficile. Convaincre les OEM et autres fournisseurs de s'adapter à leurs propres normes
Comme l'a dit le directeur logiciel d'une entreprise L4 :
"Par exemple, Weilai et Xiaopeng fabriquent leur propre middleware car il s'agit du véhicule complet. A l'usine peut définir un ensemble de normes pour contraindre ses fournisseurs ; mais si une société d'algorithmes de conduite autonome crée un middleware de support, que ce soit pour convaincre l'OEM de croire que votre ensemble de choses peut être appliqué à d'autres domaines, il est difficile de convaincre d'autres fournisseurs. des OEM à intégrer selon leurs propres standards. ”
De plus, lorsqu'une société d'algorithmes développe son propre middleware, si quelque chose ne va pas, elle ne peut pas blâmer. Par conséquent, pour la société d'algorithmes, le middleware doit être mieux fait
Un moteur principal. fabricant L'ingénieur en chef d'Intelligent Network a déclaré :
« Nous signerons un accord de service garanti avec nos fournisseurs, ce qui signifie qu'une fois qu'un grave accident de qualité se produit, bien que le constructeur automobile soit la première personne responsable, nous serons naturellement le C'est la première fois qu'il faut demander des comptes à ces fournisseurs. Si une société d'algorithmes développe un middleware, alors une fois la responsabilité impliquée, elle peut difficilement s'en soustraire, et nous ne lui permettrons pas d'échapper à sa responsabilité
Fabricants de puces
Le but des fabricants de puces dans la création de middleware est de afficher les performances de la puce.
D'un point de vue technique, il est moins difficile pour les fabricants de puces de créer des middlewares que pour les éditeurs d'algorithmes. Étant donné que les sociétés d'algorithmes doivent s'adapter à différentes puces, la charge de travail est bien plus compliquée que celle des fabricants de puces créant des middlewares, et les middlewares créés par les fabricants de puces n'ont besoin que de pouvoir s'adapter à leurs propres puces.
Malgré cela, en pratique, très peu de gens utilisent les middleware développés par les fabricants de puces.
Actuellement, on sait que les principales entités fabriquant des middlewares sont les fabricants de middlewares, les sociétés d'algorithmes, les fabricants de puces et les OEM. La part de marché des middlewares est très finement divisée et la concurrence est féroce. Si vous souhaitez développer un middleware complet à ce stade, à qui devriez-vous vendre le middleware développé ? Le middleware peut-il vraiment être utilisé pour réaliser des profits ? Tous ces problèmes doivent être pris en compte avant de développer un middleware.
Un expert d'une société d'algorithmes a déclaré :
« Nous n'utilisons généralement pas de middleware provenant d'entreprises de puces, car ils fabriquent davantage de middleware pour des raisons écologiques. Leur middleware a peut-être plus de fonctions, mais les performances ne sont pas nécessairement optimales. y compris l'abstraction de l'IA, la lecture des enregistrements de données et le traitement des nuages de points, tout cela peut être fait, mais dans ce cas, il y aura un problème : l'algorithme est initialement censé faire des choses, mais le middleware les a toutes faites, et les performances ne sont pas bon. Entièrement garanti, et il doit prendre en compte les besoins de plusieurs sociétés d'algorithmes, et la flexibilité deviendra pire. "
On peut voir que même si certains fabricants de puces sont capables de créer des middlewares, compte tenu de la pression de. La concurrence sur le marché est grande, elle nécessite également d'investir beaucoup de main-d'œuvre et de ressources matérielles dans la recherche et le développement. La plupart des fabricants de puces compétents n'ont aucune motivation pour investir trop dans la création de middleware, mais préfèrent se concentrer sur la qualité de la puce elle-même.
Par conséquent, le middleware développé par la plupart des fabricants de puces est très léger et est essentiellement un middleware de démonstration qui peut s'exécuter sur la puce pour démontrer les performances de la puce aux clients. Un tel middleware de démonstration ne sera certainement pas d’une grande aide dans le découplage logiciel et matériel.
OEM d'origine
Pour les OEM, le besoin de personnalisation du middleware a toujours existé.
Le responsable du système de conduite intelligente d'un certain équipementier a donné un exemple :
"Par exemple, lors de l'écriture d'un algorithme de reconnaissance de feux tricolores ou d'un algorithme de vision binoculaire, si vous voulez être différent du traditionnel algorithmes ou algorithmes concurrents, vous avez besoin d'un ensemble de middleware personnalisé, qui implique l'abonnement aux données, le partage, l'enregistrement, la lecture, l'envoi, le stockage, le diagnostic et d'autres fonctions du middleware. Cependant, le fonctionnement parfait de ces fonctions ne peut pas être garanti. »
Cependant, certains OEM puissants préféreraient utiliser des middlewares provenant de sociétés de middleware tierces. sociétés d’algorithmes.
Tout d'abord, l'achat d'un middleware fermé tel que le DDS de RTI signifie souvent la personnalisation du middleware, ce qui nécessite non seulement des coûts plus élevés, mais aussi le cycle d'amarrage du projet sera très long en comparaison, signifie un middleware auto-développé ; que vous pouvez contrôler entièrement la direction de la personnalisation, obtenir vos propres données et rendre le produit sans restriction. De cette façon, vous pouvez mieux contrôler le processus de développement du produit et sa transformation ultérieure, et résoudre le problème qu'un certain fournisseur de middleware peut provoquer. le problème des retards de livraison de la production de masse.
Deuxièmement, les middlewares auto-développés peuvent également constituer certaines barrières techniques pour les OEM. Pour certains OEM puissants, certaines couches d'application de couche supérieure sont entièrement entre leurs mains. Ils peuvent créer leur propre middleware en fonction des besoins de leurs applications de couche supérieure et peuvent mieux personnaliser certaines applications de couche supérieure et peuvent également créer certaines fonctionnalités. .
En fait, alors que la technologie middleware n'est pas encore mature et que les tendances futures ne sont pas encore assez évidentes, la raison pour laquelle les acteurs en amont et en aval de l'industrie créent des middleware est de tester les limites de leurs propres capacités et d'explorer les limites. de l'ensemble de l'industrie.
Cependant, de nombreux ingénieurs de conduite autonome des constructeurs OEM estiment que « par rapport aux sociétés d’algorithmes, les middlewares développés par les constructeurs eux-mêmes ont peu d’avantages ».
Tout d’abord, la plupart des OEM n’ont pas beaucoup d’accumulation de capacités algorithmiques. Le coût de la mise en place d'une équipe spécifiquement chargée de fabriquer des middlewares est énorme, mais le résultat n'est peut-être pas aussi bon que celui d'un fournisseur spécialisé dans ce domaine. La douleur causée par une telle consommation a largement dépassé celle de la coordination de plusieurs fournisseurs. . C'est comme si la douleur causée par nos projets faibles serait plus douloureuse que les nouveaux défis de nos projets forts.
Deuxièmement, il est difficile pour le middleware auto-développé par l'OEM d'obtenir suffisamment de retours d'échantillons, ce qui n'est pas propice à l'itération du produit. Les algorithmes et les middlewares des fournisseurs sont de plus en plus utilisés par tout le monde, et à mesure que la base de clients augmente, le taux de commentaires des clients sur les bugs sera plus élevé, ce qui est cependant plus propice à la progression itérative des produits, si les équipementiers développent leurs propres produits et ne fournissent que les produits. produits pour eux-mêmes, ce sera facile. Il y a un manque de données d'échantillonnage suffisantes, donc l'itération est plus lente.
De plus, si l'OEM souhaite développer son propre middleware, il est voué à débaucher les talents techniques d'autres entreprises. Cependant, pour les talents travaillant dans un département d'une grande entreprise, ils n'ont peut-être pas un sens aussi fort de la mission. Après tout, il y aura toujours le sentiment que « le ciel nous tombe sur la tête, mais il y a encore des gens au-dessus pour le tenir. ", et au final, le résultat est que si les capacités des talents recrutés peuvent être utilisées à 80%, cela serait considéré comme idéal. Mais si le même talent technique travaille seul et que la recherche est liée à des intérêts personnels, il aura certainement plus de pression et de motivation pour bien le faire. Dans un tel environnement, il pourra souvent faire preuve de plus de talents.
Enfin, pour les OEM, les middlewares auto-développés nécessitent beaucoup de talent pour constituer une équipe de recherche une fois qu'il est constaté que cette route ne peut pas continuer, une si grande équipe. Un certain nombre de Tous les employés courront le risque d'être licenciés, et le licenciement d'un grand nombre d'employés augmentera le sentiment parmi les employés actuels que « l'entreprise est instable ».
De ce point de vue, le « middleware auto-développé » des OEM n'est peut-être le plus souvent qu'un slogan marketing, mais cela ne veut pas dire que tous les OEM développent eux-mêmes - middleware développé Aucun des logiciels ne réussira Si le fabricant du moteur principal est suffisamment fort et peut développer avec succès son propre algorithme, la probabilité de succès du middleware auto-développé est toujours élevée. Mais relativement parlant, pour les constructeurs OEM qui ne sont pas en mesure de développer eux-mêmes la plupart des algorithmes, les exigences en matière de découplage logiciel et matériel doivent encore être satisfaites par les fournisseurs.
La naissance du middleware était à l'origine pour résoudre le problème du logiciel et du matériel ne peut pas être développé séparément.Par conséquent, les gens espéraient initialement que le middleware pourrait devenir un logiciel bloquant qui pourrait rationaliser le processus et s'adapter à tous les logiciels et matériels, de sorte que les ingénieurs d'applications logicielles de niveau supérieur ne puissent pas prendre en compte le matériel. Problèmes d'adaptation, et faites du bon travail en algorithme en toute sérénité.
Cependant, la réalité est contraire au souhait initial.
D'une part, le middleware fait preuve d'une forte intensité de personnalisation.
L'architecte logiciel d'une société d'algorithmes a présenté :
« Chaque modèle de voiture ou chaque La plateforme de puces a une adaptabilité différente au middleware, et le logiciel sous-jacent fourni a une adaptabilité différente au middleware. Par exemple, certains véhicules utilisent le système d'exploitation QNX et certains utilisent le système d'exploitation Linux. Ces deux systèmes d'exploitation ont des exigences différentes. contenu.
« En plus du système d'exploitation sous-jacent, la couche d'application logicielle aura également des exigences différenciées pour le middleware, telles que, en fonction d'une certaine plate-forme, certaines exigences spéciales. Les méthodes de communication doivent être activées. Certaines données doivent être transmises non pas via une liaison commune telle qu'Ethernet traditionnel, mais via des liaisons spéciales telles que PCIe ou la mémoire. Cela nécessite que le middleware soit personnalisé afin qu'il puisse prendre en charge les exigences de communication des différents. links.
"Certains fabricants de logiciels de conduite autonome ou OEM ont leurs propres méthodes de journalisation, et d'autres non, un middleware est donc nécessaire pour fournir une capacité de journalisation. Par conséquent, le middleware être personnalisé en fonction des capacités des différents utilisateurs. »
La personnalisation signifie que s'il appartient aux fabricants de middleware de le faire séparément Pour répondre aux besoins au-delà de la standardisation, ou pour demander à la société d'algorithmes/au fabricant du moteur principal d'envoyer des ingénieurs d'algorithmes d'amarrage dédiés pour effectuer une adaptation et un ajustement personnalisés du middleware, des ressources humaines et matérielles supplémentaires seront nécessaires.
Et le middleware personnalisé crée de nouvelles difficultés pour l'algorithme d'analyser les données.
Un ingénieur d'un OEM a dit sans ambages :
"Si V2X doit être installé en masse- " #🎜 🎜#
D'autre part, « De plus en plus d'acteurs commencent à contourner la norme AUTOSAR et à créer le leur. Même si le middleware est également réalisé selon la norme AUTOSAR , le degré de personnalisation est également très élevé.", A déclaré un expert du système hôte Factory. De nos jours, chaque entreprise développe son propre middleware. La plupart des middlewares ne s'adaptent qu'à ses propres algorithmes, interfaces, etc., et le phénomène d'incohérence s'aggrave.
Qu'il s'agisse d'un OEM ou d'une société d'algorithmes, au lieu de se demander si le middleware est facile à utiliser et si les logiciels et le matériel sont découplés, ce qui est réellement pris en compte lors de la coopération sur un projet est de savoir si celui-ci peut résoudre les problèmes réels rencontrés. Si le middleware acheté ne parvient pas à résoudre le problème et n'obtient pas l'effet souhaité, les deux parties devront alors modifier et ajouter divers contenus basés sur le middleware d'origine, ce qui conduira à une situation de « couplage » continu. est devenu un phénomène inévitable.
Donc, en repensant à l'intention initiale du middleware de simplifier les processus et de réduire la charge de travail, je ne peux m'empêcher de soupirer.
Alors, si vous souhaitez réaliser un découplage logiciel et matériel, par quels angles pouvez-vous commencer ?
D'une part, la virtualisation matérielle peut être effectuée d'abord au niveau du système d'exploitation, et les interfaces, les protocoles de communication, etc. peuvent être standardisés, de sorte que les applications de couche supérieure n'aient pas besoin de prendre en compte différents problèmes du système sous-jacent. , mais cela nécessite que les fabricants de puces et les fabricants de systèmes d'exploitation puissent être menés conjointement, ou que les fabricants de puces développent leur propre système d'exploitation, il reste donc encore beaucoup de difficultés.
D'un autre côté, même si la future forme de middleware n'est pas encore claire, une chose est sûre. Le découplage logiciel et matériel doit encore être résolu sous la forme de middleware, mais le middleware peut être divisé de plusieurs manières :
.1. Les fournisseurs de middleware développent un middleware de type outil qui simplifie Autosar en se basant sur Autosar lui-même. Étant donné qu'Autosar lui-même est très complexe, il n'est pas facile à apprendre pour les ingénieurs. Si une version simplifiée de l'outil de développement peut être fournie, ce serait une bonne idée de fournir cet outil aux fabricants en amont et en aval qui ont besoin de développer eux-mêmes. middleware pour optimiser leur propre processus middleware auto-développé.
2. Les usines de middleware, les principaux fabricants de moteurs et fournisseurs forment une alliance de middleware, l'usine de puces ou l'usine de moteurs principale prenant la tête pour unifier les règles. En testant les limites du marché, un OEM ou une usine de puces très puissant prendra l'initiative de former une norme unifiée pour l'alliance industrielle et d'unifier le système d'exploitation, les interfaces, etc. pour former des normes industrielles.
3. Entièrement open source, avec un OS propriétaire créé par la société de puces, permettant aux entreprises en amont et en aval de se développer sur cette base. Les fabricants de puces créent des boîtes à outils open source comme CUDA de NVIDIA, qui non seulement développent leur propre système d'exploitation et middleware, mais sont également entièrement open source, aidant les clients en amont et en aval à utiliser ensemble les outils pour un meilleur développement d'adaptation et établir un bon écosystème.
4. En tant que service, nous fournissons des services middleware personnalisés et des travaux de maintenance aux fournisseurs. En raison du faible plafond du marché et de la difficulté d'unifier les middlewares, les middlewares pourraient ne pas devenir un produit indépendant, mais un service personnalisé. Étant donné que les fabricants de middleware disposent d’une meilleure expérience en matière de recherche sur les middlewares, ils sont mieux placés pour fournir de tels services personnalisés.
Dans le passé, diverses marques de téléphones mobiles étaient en pleine floraison. De 2005 à 2010, lorsque les « téléphones en brique » et les téléphones intelligents volaient côte à côte, il y avait jusqu'à plus de 200 interfaces de téléphonie mobile en circulation sur le marché. marché. Différentes marques de téléphones mobiles ont différentes interfaces de chargement, différentes interfaces de casque, diverses grandes et petites interfaces avec la même forme et des tailles différentes, et même les téléphones mobiles de la même marque ont des interfaces de chargement différentes.
Un expert du numérique à cette époque devait souvent emporter 5 ou 6 types de chargeurs et 5 ou 6 câbles différents lorsqu'il partait en voyage d'affaires. Même si nous disposons plus tard d'un chargeur universel, nous ne pouvons que retirer la batterie du téléphone tablette pour la charger. Le problème de l'incohérence entre le port de charge du smartphone et les prises casque de différentes tailles ne peut toujours pas être résolu.
Une période aussi chaotique et désordonnée est aussi le moment où le développement de la technologie de la téléphonie mobile est le plus brillant et le plus vigoureux après l'essor des téléphones mobiles, tout comme le développement actuel des voitures intelligentes. Aujourd'hui, nous constatons que les interfaces des téléphones mobiles ont été fondamentalement unifiées. Des centaines de fabricants de téléphones mobiles ont progressivement réduit leur nombre dans le cadre d'un processus d'auto-recherche et ont finalement élaboré des normes sous la décision finale du marché.
L'industrie automobile intelligente est profondément affectée par le marché de la consommation électronique, en particulier celui de la téléphonie mobile. Au cours des deux dernières années, tout le monde dans l'industrie a semblé très impétueux. Tout le monde est impatient de progresser rapidement vers un état final, en espérant. Sélectionner un maître dans un laps de temps très court. Cependant, l'industrie automobile est en réalité une industrie à croissance lente. De la production de véhicules à la production de masse, puis au marché de consommation, ce n'est qu'en recueillant les commentaires de dizaines de millions d'utilisateurs que nous pouvons nous optimiser en permanence et élaborer des normes. Et ce n’est peut-être qu’à ce moment-là que les middlewares pourront véritablement être unifiés pour former un standard.
Une fois la technologie mûrie dans le futur, le middleware pourra être utilisé comme logiciel de base solidifié sur la puce ASIC, et on ne sait pas s'il n'apparaîtra plus sous la forme d'un middleware seul.
Cependant, cela dit, à l'heure actuelle, alors que toutes les parties sont confrontées à des difficultés, qui est approprié pour le middleware ?
D'une manière générale, si nous visons à utiliser un middleware standard pour atteindre complètement l'objectif de découplage logiciel et matériel, le middleware le plus approprié est en fait le fabricant de puces.
Deux raisons : Premièrement, l'adaptation des algorithmes repose en fin de compte sur la plate-forme de la puce, et la puce est la pierre angulaire. Deuxièmement, il y a moins de sociétés de puces que de sociétés d’algorithmes, et il est relativement moins difficile de les unifier.
Mais actuellement, partant du principe que tout le monde attend de la personnalisation, les sociétés d'algorithmes sont les plus adaptées aux middlewares personnalisés.
"Les sociétés de puces accordent plus d'attention à l'application de la puce elle-même, par exemple s'il convient d'ajouter un mécanisme de vérification, comment planifier et accélérer le BSP, etc. Les sociétés de puces peuvent toutes mettre en œuvre ces exigences, mais les sociétés de puces ne peuvent pas les proposer. de meilleures exigences pour les logiciels d'application et les middlewares. Il est recommandé aux utilisateurs d'utiliser uniquement des solutions matures, mais cette solution peut ne pas être en mesure de répondre à tous les besoins du logiciel. On peut voir que les sociétés d'algorithmes reçoivent le plus de demandes de personnalisation dans la pratique commerciale et. sont les plus demandés Pour le rôle d'adaptation du middleware, il est plus pratique de créer directement un middleware personnalisé qui s'adapte à votre propre algorithme.
L'ingénieur en chef d'un certain équipementier a également le même point de vue :
"Pour l'instant, les services fonctionnels de niveau supérieur sont relativement concentrés. Les fournisseurs de solutions de conduite autonome ont une compréhension approfondie des applications fonctionnelles et s'éloignent des couche d'application. Le logiciel peut mieux correspondre aux fournisseurs de solutions matérielles de puces grand public sous-jacents, et la solution globale est plus raisonnable.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
Quelles compétences sont nécessaires pour travailler dans l'industrie PHP ?
Outils de test de logiciels
Comment enregistrer un nom de domaine permanent pour un site Web
erreur d'initialisation mom.exe
Configurer les variables d'environnement Java
Que signifient les faces C et B ?
Comment résoudre une syntaxe invalide en Python
Comment définir la couleur de la police en HTML
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
