Un article discutant des cinq éléments clés pour la mise en œuvre de voitures définies par logiciel

1 Mise à niveau de l'architecture

1.1 Architecture logicielle : découplage en couches, servitisation, standardisation de l'interface API

À mesure que les entreprises se transforment en méthodes de développement automobile définies par logiciel, l'architecture logicielle doit également être mise à niveau simultanément. -Méthodologie d'architecture orientée (SOA). La SOA automobile organise les capacités sous-jacentes de l’intelligence des véhicules. Les capacités matérielles et diverses fonctions de la voiture sont transformées en services. Ces services sont conçus avec des interfaces basées sur les normes SOA et communiquent sur la base des protocoles standards SOA. De cette manière, chaque composant de service peut accéder les uns aux autres, élargissant ainsi la forme de combinaison de services.

Figure 1 Schéma de principe de l'architecture orientée services SOA

L'introduction de SOA a progressivement transformé le système logiciel traditionnel fermé et solidifié des automobiles en un écosystème logiciel ouvert et réutilisable. Dans la nouvelle série de mises à niveau de l'architecture logicielle, basée sur l'architecture orientée services SOA découplée en couches, l'abstraction des périphériques et les services atomiques sont utilisés pour réaliser une maintenance complète des capacités matérielles. Les objets spécifiques incluent les capteurs, les actionneurs et les communications de bus traditionnelles autour du contrôleur. , ainsi que les propres dispositifs de diagnostic et de stockage du contrôleur. Dans le même temps, sur la base de l'idée de conception de « conversion sémantique logique », la normalisation de l'interface est achevée et les objectifs de réutilisabilité de l'interface pour différentes plates-formes et différents modèles sont atteints.

Figure 2 Exemples de services de base sous architecture SOA

Avec les changements dans l'infrastructure et les méthodes de développement, les « voitures définies par logiciel » bouleverseront l'ensemble du processus de développement automobile, et les solutions d'architecture logicielle basées sur SOA Fournit des abstractions de services importantes pour les systèmes de voiture intelligente. L'encapsulation rigoureuse et la structure en couches prennent en charge l'utilisation de méthodes de développement agiles et de tests d'interface, et réduisent la complexité du système, ce qui simplifiera considérablement la réutilisation des composants logiciels lors de la mise à jour des véhicules.

Figure 3 Diagramme schématique de l'architecture en couches logicielles

Standardisation de l'architecture :

L'architecture en couches introduit la couche de service atomique et la couche d'abstraction de périphérique dans l'architecture d'origine du véhicule.

• La couche d'abstraction du périphérique est chargée d'encapsuler les différences matérielles sous-jacentes et de fournir des interfaces avec les caractéristiques de la couche matérielle sous la forme de services que la couche de service atomique doit appeler. Les ajustements du matériel ne doivent pas entraîner de modifications dans le matériel. interfaces fournies par le logiciel système. La logique applicative est libérée des contraintes de la plate-forme matérielle sous-jacente ; la couche de service atomique sert de couche intermédiaire et est découplée de la plate-forme. Elle se charge de l'invocation des services applicatifs du côté supérieur et des accès. l'abstraction de l'appareil sur le côté inférieur, reflétant les différences entre les modèles de véhicules et l'adaptation de la configuration, permettant la réutilisation des applications de couche supérieure sur tous les modèles de véhicules ;
• Le service de couche application/composition est principalement responsable de la réalisation de la logique de la demande des utilisateurs ; , et combine des applications basées sur des scénarios en constante évolution en appelant l'interface fournie par la couche de service atomique.
• Standardisation de l'interface :

À travers les modèles et les fournisseurs de composants, maximisez la réutilisation et réduisez la complexité du développement de logiciels et de matériels automobiles définis par logiciel.

Sur la base de la standardisation architecturale, comment le logiciel peut-il être utilisé par les constructeurs automobiles ? Il est nécessaire de standardiser les interfaces entre les couches. Différents OEM, Tier1 et fournisseurs de plates-formes définissent le même ensemble d'interfaces de service, de sorte que les logiciels entre différents OEM et Tier1 puissent s'appeler, augmentant considérablement le nombre de logiciels. La réutilisabilité raccourcit le véhicule. cycle de développement.

En termes de promotion de la normalisation des interfaces, l'Association chinoise des constructeurs automobiles a publié la troisième édition de la « Spécification de référence de l'interface API de service atomique automobile définie par logiciel et de la spécification de référence de l'interface API d'abstraction de périphérique », qui contient plus de 700 API, couvrant contrôle de la carrosserie, gestion thermique, il existe plusieurs domaines fonctionnels tels que la gestion de l'énergie, le contrôle de mouvement, le domaine de conduite intelligente, le domaine de puissance, le domaine de châssis, etc. Les membres participant à la définition de normalisation des interfaces comprennent plus de 100 entreprises, dont des OEM, des composants, des composants de base. les fournisseurs de plateformes et les fournisseurs de logiciels.

1.2 Architecture de communication : application technologique basée sur l'Ethernet embarqué

Avec l'augmentation continue des fonctions des véhicules, notamment le développement continu de la conduite autonome et des cockpits intelligents, les signaux à transmettre ont explosé, et Fonctions du véhicule Avec des mises à niveau et des mises à jour continues, les utilisateurs ont mis en avant des exigences plus élevées pour l'expérience de mise à niveau OTA. La méthode de communication par bus CAN traditionnelle ne peut plus répondre au taux de croissance des fonctions du véhicule. L'utilisation de méthodes de communication basées sur les services Ethernet peut permettre une réorganisation flexible des fonctions du véhicule. fonctions et résout efficacement les problèmes traditionnels dans l'architecture de communication orientée signal, l'ajout, la suppression/la modification de signaux individuels entraînent des changements dans tous les systèmes fonctionnellement liés.

Vehicle Ethernet et l'architecture de protocole de couche supérieure qu'il prend en charge sont présentés dans la figure ci-dessous. Vehicle Ethernet implique principalement les technologies OSI de couche 1 et 2. Vehicle Ethernet prend également en charge AVB, TCP/IP, DoIP, SOME/IP et. DDS et autres protocoles ou formulaires de demande.

Figure 4 Ethernet du véhicule et son architecture de protocole de couche supérieure prise en charge

SOME/IP signifie : Scalable Service-Oriented Middleware over IP, un middleware évolutif orienté services basé sur IP. Le logiciel a a été intégré à la spécification AUTOSAR 4.1 en 2013.

Figure 5 Prise en charge du middleware SOME/IP orienté service

Changements apportés après la mise à niveau de l'architecture de communication :

• Mécanisme de communication plus flexible : le bus CAN est une communication diffusée, le multi -Le mode maître fonctionne de manière à ce que les informations envoyées par chaque nœud puissent occuper tous les supports de communication, mais le nœud récepteur peut choisir de recevoir ou non les informations. Ethernet communique de deux manières : un à un ou un à plusieurs, le message du nœud émetteur couvre son adresse et celle d'un nœud de réception. le message du nœud d'envoi couvre ses adresses et celles d'un nœud de réception. Les adresses de lui-même et de plusieurs nœuds de réception. Ni l’un ni l’autre n’affecte la communication des autres nœuds.
• Bande passante plus élevée, latence plus faible : la quantité totale de transmission de données embarquée et les exigences en matière de vitesse de transmission continuent d'augmenter, et, motivées par la demande de protocoles standard intersectoriels, il prend en charge davantage de scénarios d'application et des vitesses plus élevées. Il est devenu inévitable qu'Ethernet remplace les réseaux de communication automobiles traditionnels tels que CAN/LIN.
• Plus de scénarios d'application, interconnexion facile et extension facile : Ethernet embarqué et réseau hors véhicule sont basés sur le même protocole lors de la communication avec le réseau hors véhicule, la transition d'interface est plus fluide. Les réseaux de communication traditionnels embarqués sont basés sur des protocoles réseau uniques et ont une mauvaise standardisation des interfaces ; lors de l'interaction avec les réseaux hors véhicule, les protocoles de différents systèmes doivent être convertis. Sous la tendance des réseaux, le coût de conversion de protocole de l'Ethernet automobile est encore plus réduit.
• Vitesse de mise à niveau OTA plus rapide, expérience plus facile à utiliser : en utilisant Ethernet pour la mise à niveau OTA, la vitesse de communication est plus de 10 fois supérieure à la mise à niveau CAN traditionnelle, réduisant considérablement le temps d'attente de l'utilisateur. L'utilisation de la communication basée sur les services SOME/IP peut réaliser une réorganisation flexible des fonctions, résoudre efficacement le problème de l'augmentation ou de la diminution/du changement des fonctions individuelles dans l'architecture traditionnelle avec les exigences fonctionnelles comme noyau, ce qui entraîne la nécessité de changer de fonction. systèmes associés et réduisent le besoin de mises à niveau du système OTA.

1.3 Architecture matérielle : accès régional + centralisation de la puissance de calcul

L'ensemble de l'architecture électronique et électrique du véhicule est la pierre angulaire de la réalisation de voitures définies par logiciel La plupart des voitures traditionnelles actuellement vendues sur le marché sont distribuées. électronique et électrique L'architecture est présentée dans la figure ci-dessous.

Figure 6 Schéma schématique de l'architecture électronique et électrique distribuée traditionnelle

Dans l'architecture électronique et électrique distribuée, les fonctions du véhicule sont d'abord divisées en différents modules, tels que le contrôle de puissance, le contrôle du châssis, sécurité active, sécurité passive, conduite intelligente, infodivertissement et carrosserie, etc. Ensuite, les fonctions de chaque module sont subdivisées. Par exemple, les fonctions de carrosserie sont subdivisées en fonctions telles que la commande d'éclairage, la commande de porte et la commande de siège. Différentes fonctions de contrôle électronique sont mises en œuvre à l'aide d'unités de commande électroniques (ECU) indépendantes, et différents ECU communiquent via CAN/CAN FD.

Étant donné que chaque ECU est développé par un fournisseur différent et possède un logiciel intégré et un code sous-jacent différents, l'architecture électronique et électrique distribuée entraîne beaucoup de redondance et de coûts de nomenclature au niveau du véhicule. De plus, étant donné que le logiciel embarqué dans le véhicule est distribué sur différents calculateurs et que les calculateurs sont complétés indépendamment par chaque fournisseur, leurs logiciels et leur matériel sont étroitement couplés et le constructeur OEM n'a pas l'autorité nécessaire pour maintenir et mettre à jour le logiciel sur l'ECU. .

Répondre rapidement aux besoins des utilisateurs est la clé pour que les OEM puissent conquérir des parts de marché, et l'architecture électronique et électrique distribuée restreint considérablement la vitesse à laquelle les OEM peuvent répondre à la demande du marché. Supposons qu'une fois la conception d'un certain modèle de voiture terminée, l'utilisateur propose d'ajouter une fonction de mémoire de position du conducteur, c'est-à-dire qu'une fois que le conducteur a réglé les sièges, le volant, les rétroviseurs extérieurs et d'autres systèmes associés du véhicule dans une position confortable, il peut les définir comme positions de mémoire. Pratique pour des ajustements rapides ultérieurs. Les modifications logicielles doivent être apportées à plusieurs composants tels que les contrôleurs de porte, les contrôleurs de siège, les contrôleurs de volant et les passerelles. Ce n'est qu'une fois que chaque fournisseur de composants a terminé les modifications et que le fabricant d'équipement d'origine a terminé les tests d'intégration et les tests du véhicule que les nouvelles fonctionnalités peuvent être modifiées. mis sur le marché, ce qui entraînera des problèmes tels que des cycles de développement et de changement longs et des coûts élevés.

À cette fin, divers constructeurs automobiles ont déjà commencé à réserver de nouvelles solutions d'architecture électronique et électrique pour favoriser la mise en œuvre rapide de voitures définies par logiciel. Les particularités de la nouvelle architecture électronique et électrique sont la centralisation des fonctions (logiciels) et la standardisation du matériel. La gestion unifiée des fonctions de contrôle via une plate-forme informatique centrale/un contrôleur de domaine réduit la redondance matérielle et les coûts de nomenclature, réduisant ainsi la dépendance de l'OEM à l'égard de nombreux fournisseurs. Selon le degré de concentration fonctionnelle, les nouvelles architectures électroniques et électriques sont principalement divisées en trois types.

Le premier type : architecture électronique et électrique centralisée par domaine

Dans le domaine architecture électronique et électrique centralisée, les fonctions de commande électronique et électrique du véhicule sont divisées en N domaines fonctionnels, et un domaine est conçu pour chacun domaine fonctionnel Les autres contrôleurs sont des contrôleurs intra-domaines, et les contrôleurs de chaque domaine sont généralement des capteurs intelligents, des actionneurs et des contrôleurs traditionnels.

Le schéma de principe de l'architecture électronique et électrique centralisée par domaine est présenté dans la figure ci-dessous. Dans l'exemple, les fonctions de contrôle électronique et électrique du véhicule sont divisées en cinq domaines fonctionnels : domaine de puissance, domaine de sécurité du châssis, conduite intelligente. domaine, domaine d'infodivertissement et domaine de confort corporel.

Figure 7 Schéma schématique de l'architecture électronique et électrique centralisée par domaine

Deuxième type : architecture électronique et électrique centralisée inter-domaines

Dans l'architecture électronique et électrique centralisée par domaine, domaine contrôle Le contrôleur est uniquement responsable du contrôle centralisé des fonctions dans un domaine ; dans l'architecture électronique et électrique centralisée inter-domaines, certains contrôleurs de domaine sont responsables du contrôle centralisé des fonctions dans deux domaines ou plus, améliorant encore l'intégration fonctionnelle de le système. L'architecture électronique et électrique centralisée inter-domaines la plus courante est l'architecture à trois domaines. Le schéma de principe de l'architecture électronique et électrique centralisée inter-domaines est présenté dans la figure ci-dessous.

Figure 8 Schéma schématique de l'architecture électronique et électrique centralisée inter-domaines

L'architecture à trois domaines est respectivement le domaine de contrôle du véhicule, le domaine de conduite intelligente et le domaine de cockpit intelligent. Elle combine l'original. domaine de puissance, domaine de sécurité du châssis et domaine de confort de la carrosserie est intégré au domaine de contrôle du véhicule, et le domaine de conduite intelligente et le domaine du cockpit intelligent se concentrent sur la réalisation de l'intelligence et de la connectivité du véhicule.

L'architecture à trois domaines dispose de 3 contrôleurs de domaine :

Le contrôleur de domaine du véhicule est responsable du contrôle du véhicule et a des exigences élevées en matière de temps réel et de sécurité ;

Le contrôleur de domaine de conduite intelligente est responsable de ;

Le contrôleur de domaine du cockpit intelligent est responsable de l'interaction HMI et de la mise en œuvre des fonctions liées au cockpit.

Le troisième type : accès régional + architecture électronique et électrique centralisée

L'architecture électronique et électrique centralisée ne déploie plus les systèmes électroniques et électriques du véhicule en fonction de la fonction, mais concentre la logique de contrôle de toutes les zones fonctionnelles du véhicule sur la plate-forme informatique centrale, améliorant encore l'intégration fonctionnelle du système. Les fonctions de contrôle/calcul des calculateurs dans les architectures originales distribuées et centralisées par domaine sont absorbées par la plate-forme informatique centrale et transformées en capteurs ou actionneurs plus simples.

Afin de réduire la longueur du faisceau de câbles, de simplifier la communication, de fournir un accès et une alimentation électrique à proximité, dans le cadre de l'architecture centralisée, les zones peuvent être divisées en fonction des emplacements physiques et des contrôleurs régionaux peuvent être déployés dans la zone pour former un plate-forme informatique centrale et plusieurs contrôleurs régionaux. Architecture, le schéma de principe de l'architecture électronique et électrique centralisée est présenté dans la figure ci-dessous.

Figure 9 Schéma schématique de l'architecture électronique et électrique centralisée

La mise à niveau de l'architecture matérielle doit également prendre en compte l'intégration de fonctions inter-domaines, la superposition de fonctions logicielles sous l'architecture SOA et le post-service contrôle Conception de sécurité fonctionnelle en temps réel, conception et intégration de matériel complexe, et bien plus encore.

2 Mise à niveau de la sécurité : construire un système de défense multicouche en profondeur du véhicule

2.1 Sécurité fonctionnelle

Avec la mise à niveau continue de la technologie de l'architecture électronique et électrique, de plus en plus de systèmes et de composants du véhicule sont inclus. Elle a un impact sur la sécurité fonctionnelle. C'est pourquoi la sécurité fonctionnelle s'est également étendue du développement de certains systèmes clés au développement global de tous les systèmes dans l'ensemble du véhicule.

Dans le même temps, l'émergence de nouvelles technologies d'architecture telles que les contrôleurs de domaine et les plates-formes informatiques centrales a posé de nouveaux défis techniques en matière de sécurité fonctionnelle. La sécurité fonctionnelle doit établir des méthodes de développement et d'évaluation pour ces systèmes et logiciels complexes.

La technologie de sécurité fonctionnelle affecte également le développement de la technologie de l'architecture électronique et électrique, évoluant de la sécurité intégrée traditionnelle (Fail-Safe) à la sécurité opérationnelle (Fail-Operational), et davantage de redondance est introduite dans la conception des systèmes électroniques et architecture électrique (comme la redondance des communications, les contrôleurs redondants, etc.) et les mesures de sécurité.

À l'avenir, la formation d'un écosystème de véhicules intelligents promouvra la technologie de sécurité fonctionnelle pour aller au-delà des vélos et s'étendre à l'ensemble du lien, assurant ainsi la sécurité globale de l'ensemble de l'écosystème intelligent.

2.2 Sécurité fonctionnelle anticipée

La sécurité fonctionnelle anticipée liée à l'architecture électronique et électrique fait référence à la prévention des risques personnels causés par des fonctions insuffisantes ou une mauvaise utilisation humaine raisonnablement prévisible. La technologie de sécurité fonctionnelle devrait faire partie de la technologie automobile et la norme correspondante est la norme ISO 21448. Sur la base de la fonction de conduite autonome et de son domaine de conception opérationnelle, analyser le schéma de configuration du système qui répond aux exigences de sécurité fonctionnelle attendues, et déterminer ou sélectionner le schéma d'architecture électronique et électrique approprié en fonction du schéma de configuration du système. Points techniques clés de la sécurité fonctionnelle attendue :

(1) Technologie de formulation de critères de sécurité de conduite autonome : Développer des critères quantitatifs objectifs pour les performances de sécurité de la conduite autonome dans des scénarios connus et inconnus afin de déterminer scientifiquement le niveau de sécurité de la conduite autonome

 ;

(2) Technologie d'analyse de sécurité : grâce à des méthodes d'analyse de sécurité telles que STPA, identifiez les limitations de performances insuffisantes et les conditions de déclenchement de dangers des fonctions liées à la sécurité de la conduite autonome, formulez des mesures ciblées et effectuez des mises à jour des fonctions

(3 ; ) Approche multipilier Technologie de test : Système de test de sécurité fonctionnelle attendu pour la conduite autonome comprenant des tests de simulation, des tests de scénarios définis et des tests sur route réelle

(4) Technologie de démonstration de sécurité : Basée sur les résultats du développement, de l'analyse et des tests de sécurité ; , etc., développer les dossiers de sécurité fonctionnelle attendus Stratégie, via GSN et d'autres méthodes de démonstration, évaluer les risques de sécurité de la conduite autonome et compléter la version de sécurité fonctionnelle attendue

(5) Technologie de surveillance de la sécurité : surveiller les performances de sécurité pendant la ; fonctionnement de la conduite autonome et identifier les risques pour la sécurité par des moyens embarqués et à distance et mettre en œuvre les mesures de contrôle des risques nécessaires pour garantir le fonctionnement sûr de la conduite autonome.

2.3 Sécurité du réseau

Les terminaux de voiture intelligents, les pipelines de communication, les plateformes cloud et les applications mobiles sont tous confrontés à une série de menaces pour la sécurité des informations. En partant de la dimension de l'espace du réseau automobile, grâce à de multiples collaborations techniques, différents moyens se complètent et au déploiement à plusieurs niveaux de lignes de défense de sécurité de l'extérieur vers l'intérieur, les exigences de profondeur, d'équilibre et d'intégrité de la protection de la sécurité des informations du véhicule peut être rencontré. Il est nécessaire de mettre en œuvre et de déployer des mesures de protection correspondantes basées sur l'architecture électronique et électrique des véhicules de nouvelle génération du point de vue de la sécurité des réseaux, de la sécurité intranet et de la sécurité des calculateurs.

Figure 10 Défense complète de sécurité du réseau pour les voitures intelligentes

Sécurité du réseau

La couche d'accès au réseau résiste principalement au DOS, au type PING et aux messages mal formés ciblant Ethernet, le scan dynamitage, tromperie, chevaux de Troie et autres attaques de réseau. Il est nécessaire de disposer de la capacité de protection de sécurité active du mécanisme de liaison voiture-cloud, et la stratégie de protection peut être configurée en temps réel via le système cloud, qui comprend principalement un mécanisme d'authentification d'accès, un mécanisme de protection des communications, un mécanisme de pare-feu Ethernet et une détection d'intrusion. et de prévention (IDPS).

Sécurité du réseau embarqué

La sécurité du réseau embarqué résiste principalement aux attaques sur le CAN/CAN FD du véhicule et l'Ethernet du véhicule, y compris les attaques telles que la surveillance des messages, l'injection d'erreurs et la relecture des messages. Les stratégies de protection comprennent : un mécanisme de détection d'intrusion sur le bus, un mécanisme de pare-feu intranet, un mécanisme d'isolation de domaine fonctionnel, un mécanisme de protection des communications sur le bus et un mécanisme de protection de sécurité de diagnostic.

Sécurité de l'ECU clé

Afin de garantir que le système du véhicule ou les données clés ne sont pas détruits, le niveau de l'ECU clé du véhicule doit avoir des capacités de sécurité pour un démarrage en toute sécurité, un stockage sûr des données clés et fonctionnement sûr du système et peut être utilisé pour les applications Run pour fournir des capacités de gestion des autorisations.

Service Security

Le cadre de sécurité SOA doit suivre cinq principes de base : confidentialité, intégrité, authenticité, autorisation et disponibilité, via le cryptage des informations, les signatures numériques, l'authentification par mot de passe et la conception de listes de contrôle d'accès. Diverses solutions et des produits tels que la surveillance des attaques ACL et DOS assurent la sécurité du réseau tout en garantissant que ces informations réseau peuvent être découvertes, consultées, communiquées et surveillées.

Figure 11 Principes de sécurité du réseau du service SOA du véhicule

• Dans la découverte du service, définissez le mécanisme d'isolement du groupe de sécurité des informations afin que les messages de diffusion du service ne soient envoyés qu'aux utilisateurs du service qui en ont besoin ; En termes d'accès aux services, mettre en place des mécanismes de contrôle d'accès à la sécurité de l'information pour les fournisseurs de services, authentifier et autoriser les demandes de service initiées par les utilisateurs du service.
• En termes de communication des services, déterminer la SOA en fonction des scénarios d'application métier réels des services SOA ; Le mécanisme de transmission de sécurité des informations que les messages doivent utiliser ;
• En termes de surveillance des services, mettre en place un mécanisme de surveillance de la sécurité des services pour découvrir les événements anormaux liés aux services SOA et un mécanisme de traitement des réponses de sécurité.
3 Changement de processus : développement agile, publication itérative

Les fonctions de la voiture changent chaque jour qui passe et la quantité de code logiciel augmente de jour en jour. Le développement en cascade sous le modèle V traditionnel. a été débordé. Afin de livrer rapidement aux clients, c'est la fonction dont le besoin est le plus urgent, la transformation du processus de développement logiciel est cruciale. Actuellement, de plus en plus de fournisseurs de pièces automobiles se tournent vers le développement agile. Sur la base de l'architecture système permettant de réaliser un découplage logiciel et matériel et d'une architecture hiérarchique de logiciels système, de middleware et de logiciels d'application, une itération et une publication rapides des fonctions logicielles peuvent être obtenues, permettant aux OEM d'occuper rapidement le marché.

Le cœur du processus de développement agile est de cultiver la conscience de la collaboration, la conscience des responsabilités, la conscience de la qualité, la conscience de l'apprentissage et la conscience de l'innovation du personnel de R&D, améliorant ainsi les capacités de R&D de l'ensemble de l'équipe de R&D de logiciels et développant efficacement des logiciels de haute qualité. produits. Le développement des fonctionnalités adopte un modèle de développement itératif avec un cycle de développement mensuel, qui est ensuite divisé en conception et révision détaillées, développement de fonctionnalités et lecture de code, inspection et évaluation de la qualité du code, conception et rédaction de scénarios de test, débogage conjoint des fonctions de fonctionnalités, examen de l'intégration des fonctionnalités, etc. sous-processus. Chaque sous-processus a des résultats spécifiques (documents de conception, code source, rapports de révision, cas de test, rapports de test, etc.) et un système d'évaluation quantitative (exhaustivité des chapitres du document de conception, rapport de mesure incrémentielle du code, densité d'opinion de révision, couverture des cas de test , densité de défauts, etc.), s'assurer que chaque sous-processus est réalisé conformément aux exigences de qualité du développement logiciel et archiver tous les documents pour prendre en charge la traçabilité de la qualité des logiciels.

La version adopte le modèle d'itération rapide de la version du logiciel avec un cycle de publication hebdomadaire. Les versions sont publiées chaque semaine à partir de la branche stable, les fonctions de base et les nouvelles fonctionnalités du logiciel sont entièrement vérifiées et les tests de régression des solutions sont effectués. des problèmes sont effectués, qui passent tous. Libérez la version plus tard. La valeur commerciale du développement agile :

• L'expérience utilisateur peut être publiée sur une base mensuelle.
• Les vulnérabilités et les correctifs sont publiés rapidement sur une base hebdomadaire.
• La version du logiciel est itérée sur une base horaire, et les composants et le véhicule sont intégrés de manière synchrone et vérifiés automatiquement (7*24h sans surveillance).

4 Mise à niveau de la chaîne d'outils : développement de services de véhicules basés sur SOA

L'idée générale de SOA est de concevoir un modèle de service, d'extraire différents services de base, de définir des interfaces API appropriées via un découplage hiérarchique et d'appliquer l'appel l'interface API de service pour implémenter la logique métier. La définition de l'interface API est indépendante de la plate-forme matérielle, du système d'exploitation et du langage de programmation qui implémente le service, garantissant ainsi que les services construits dans différents systèmes peuvent interagir de manière unifiée et universelle.

Pour l'industrie automobile, la SOA est une technologie nouvellement introduite qui nécessite un ensemble efficace de processus, de méthodes et de chaînes d'outils. Actuellement, l'industrie ne dispose pas d'une méthodologie et d'une chaîne d'outils très matures. Les OEM et Tier1/Tier2 sont en phase exploratoire. La figure ci-dessous montre une méthode de processus de développement de fonctions basée sur les services.

Figure 12 Méthode de processus de développement de fonctions basées sur les services

Effectuer d'abord une analyse de la demande sur la fonction, générer la définition du scénario et la conception des fonctionnalités, ainsi que la topologie physique correspondante et la définition de la fonction du module , puis poursuivre la conception du système, y compris la conception de l'architecture des services, la conception des services et la conception des communications. La définition du service doit être basée sur la spécification de référence de l'interface API publiée par le groupe de travail sur les automobiles définies par logiciel de l'Association chinoise des constructeurs automobiles.

5 Amélioration de la division industrielle du travail : division raisonnable du travail, collaboration ouverte

Face à l'ère future des voitures intelligentes, alors que la chaîne de valeur industrielle d'origine commence à se briser, les constructeurs automobiles traditionnels se transforment les uns après les autres , de nouvelles forces ont du mal à émerger, et le progrès technologique évolue chaque jour, tous les acteurs transfrontaliers sont entrés dans le jeu, et les éléments et les formes de la concurrence industrielle évoluent tranquillement. d’un nouveau modèle industriel et, d’autre part, elle donne lieu également à l’émergence d’une nouvelle écologie industrielle. L'industrie automobile intelligente se développe dans une direction plus diversifiée et plus complexe, avec de nombreux nouveaux domaines technologiques qui n'ont jamais été impliqués auparavant. Seule une coopération ouverte peut obtenir des résultats gagnant-gagnant, et des avantages complémentaires peuvent former une synergie.

5.1 Recommandations générales

Comme mentionné précédemment, l'industrie automobile évolue vers l'électrification et l'intelligence, et la technologie, l'expérience utilisateur, etc. sont le moteur de la croissance rapide de l'industrie automobile. Avec l'avancement progressif des voitures intelligentes, la complexité des logiciels et du matériel des véhicules continue également d'augmenter. La transformation de l'industrie vers les voitures définies par logiciel est devenue un consensus dans l'industrie. Cependant, les voitures définies par logiciel en sont encore à leurs balbutiements. L'introduction à grande échelle de logiciels a mis l'industrie automobile au défi : la conception et le développement, l'intégration, les tests, la publication et la maintenance entraînent tous une série de défis. Ce n'est qu'en gérant correctement la complexité de la combinaison logicielle et matérielle que nous pourrons continuer à répondre aux besoins d'expérience des consommateurs et à devenir compétitifs sur le marché.

Le découplage en couches est un moyen clé pour améliorer la réutilisabilité des logiciels et réduire la complexité du développement logiciel et matériel. C'est également le seul moyen d'évoluer vers des voitures définies par logiciel. Grâce au découplage en couches, les logiciels et le matériel peuvent être séparés, et les applications peuvent être séparées de la plate-forme de base. Cependant, la manière de le mettre en œuvre est devenue un défi clé et affectera directement les objectifs stratégiques et la valeur des voitures définies par logiciel. D'un point de vue technique, comment superposer l'architecture et comment diviser les services pour maximiser la réutilisation, simplifier le développement, la maintenance et l'évolution à long terme sont des défis clés. Seule une division de services raisonnable, stable et unifiée peut garantir que la valeur des voitures définies par logiciel est maximisée. Du point de vue de la chaîne industrielle, la manière dont toutes les parties se positionnent, divisent le travail et collaborent pour garantir le maximum d'intérêts de toutes les parties est la principale difficulté. L'ouverture, la coopération et le gagnant-gagnant sont la base de la mise en œuvre rapide de solutions définies par logiciel. voitures.

Recommandations générales :

Renforcer la coopération et la collaboration entre les entreprises en amont et en aval de la chaîne de l'industrie automobile sous les aspects de l'uniformité des spécifications techniques et de la division industrielle raisonnable du travail, promouvoir conjointement la normalisation des interfaces logicielles et matérielles des voitures intelligentes , et créer des couches d'abstraction de services et de périphériques atomiques. Réaliser un découplage hiérarchique des applications, des plates-formes de base et du matériel ; établir une architecture de service SOA et une standardisation et unification des interfaces pour maximiser la réutilisation entre les modèles et les fournisseurs de pièces, réduire la personnalisation, accélérer l'innovation et améliorer l'efficacité de la collaboration. de l'industrie automobile intelligente. Dans le même temps, combinée aux exigences et aux avantages de toutes les parties de la chaîne industrielle, basée sur la structure hiérarchique, une division raisonnable du travail est formée pour parvenir à une coopération totale.

Suggestions spécifiques :

• Au niveau de la couche d'abstraction des appareils, réaliser le découplage des appareils et des ports, protéger les différences de fonction matérielle et les différences de fabricants, et cette couche est définie conjointement par l'industrie et standardisée
•  ; La couche de plate-forme de base réalise le découplage des logiciels et du matériel de base, masquant les différences entre les appareils et les pilotes.
• Dans la couche de service atomique, elle réalise le découplage des services et des plates-formes, améliorant la réutilisabilité des logiciels, et cette couche est définie conjointement ; et standardisé par l'industrie ;
• Dans la couche application/service combiné, réaliser le découplage des applications et des services, réutiliser les applications entre les modèles de véhicules et se concentrer sur l'expérience. Il est recommandé que cette couche soit dirigée par les OEM.

Figure 13 Recommandations globales pour la coopération dans l'industrie automobile définie par logiciel

Dans le même temps, la normalisation des API ne signifie pas l'homogénéisation de la concurrence industrielle, l'ouverture des normes et la concurrence des produits. Les équipementiers et les fournisseurs de pièces détachées peuvent hiérarchiquement renforcer leur compétitivité de base dans les technologies clés, développer des capacités de gestion en collaboration pour améliorer l'efficacité et l'échelle, et créer des mécanismes de protection dans les modèles commerciaux pour garantir des avantages exclusifs/premiers arrivés, face aux utilisateurs en fin de compte. produits à plus forte valeur ajoutée.

Dans le même temps, le matériel, les logiciels, les plates-formes, etc. des différents fabricants sont interopérables, c'est-à-dire que différents modèles et différents composants peuvent utiliser le même langage pour effectuer des appels inter-domaines, échanger et partager des informations, permettant tout le monde dans la chaîne industrielle et les entreprises en bénéficient tous.

Pour les OEM :

• Gestion plus facile : se transformant en un modèle de gestion logicielle orienté objet, le logiciel Onetrack facilite la gestion des systèmes logiciels et des fournisseurs de véhicules plus complexes, et peut se concentrer sur les capacités d'intégration pour renforcer la compétitivité.
• Délai de mise sur le marché plus rapide : un développement logiciel efficace basé sur SOA et une API de service peuvent être pré-intégrés pour accélérer la mise sur le marché des modèles.

Pour les fournisseurs de pièces :

• Réduire la personnalisation : réduire les travaux complexes sans valeur ajoutée et réduire les coûts de développement et de maintenance des différents modèles
• Accélérer l'innovation : libérer les talents pour se concentrer sur l'innovation et construire ; technologie et produits de différenciation.

Pour les entreprises/développeurs de développement de logiciels :

• Plus facile à démarrer : facile à comprendre, intégrer les ressources de développement, développement rapide
• Plus d'opportunités : des talents transfrontaliers et de nouvelles idées sont introduits ; l'industrie automobile, en continuant à exploiter la valeur post-commercialisation apporte plus de marge de réalisation.

5.2 OEM

Les OEM sont directement confrontés aux utilisateurs finaux, fournissent des produits automobiles qui répondent aux besoins des utilisateurs, intègrent des logiciels et du matériel, des fonctions d'application et des services écologiques pour compléter la fourniture d'une fabrication complète de véhicules aux services de voyage à long terme.

Les constructeurs automobiles ne sont pas seulement des fabricants de voitures, mais fournissent également des services mobiles liés aux voyages aux consommateurs et répondent aux divers besoins automobiles des utilisateurs grâce au développement, à la configuration et aux mises à niveau itératives de logiciels. Les utilisateurs peuvent définir différentes fonctions des produits automobiles via le logiciel, et peuvent même modifier des scènes de voyage ou télécharger des fonctions de scène spécifiques en fonction de leurs préférences personnelles. À cette fin, les constructeurs OEM doivent achever la construction et le développement des plates-formes suivantes :

1) Intégration de la plate-forme matérielle

La plate-forme matérielle est la base des voitures définies par logiciel. À ce stade, l'électronique. et architecture électrique prévue par chaque OEM. Il en existe trois grands types : domaine fonctionnel centralisé, intégration inter-domaines et domaine informatique central + accès régional. Afin de répondre aux besoins des voitures intelligentes et des voitures définies par logiciel, le domaine informatique central + l'accès régional constitueront l'architecture électronique et électrique dominante à l'avenir. Les OEM doivent attribuer raisonnablement les fonctions de chaque domaine et les interfaces du matériel d'accès régional en fonction de leurs propres conditions.

2) Intégration de logiciels

Les constructeurs de véhicules doivent disposer de capacités d'intégration de logiciels, créer un « centre logiciel » ou un « centre d'expérience utilisateur » et établir une structure organisationnelle correspondante pour améliorer les capacités de développement de logiciels de véhicules.

La première étape : se concentrer sur les logiciels de couche d'application de contrôle des véhicules et les logiciels fortement liés à l'expérience utilisateur pour former les caractéristiques de la marque et améliorer la fidélité de l'utilisateur. Créez un environnement de développement logiciel et suivez le processus de développement logiciel, tel que l'importation des spécifications AUTOSAR, etc., pour réaliser le découplage du logiciel de la couche application et du matériel du fournisseur au niveau du développement. Le logiciel de la couche application est encapsulé et remis au fournisseur pour intégration. et la configuration sans qu'il soit nécessaire de l'ouvrir pour la couche application, plusieurs fournisseurs de matériel peuvent être spécifiés. Dans le même temps, nous pouvons coopérer avec des prestataires de services écologiques pour intégrer des logiciels tiers dans la couche applicative. Une fois la couche application contrôlée indépendamment, elle peut être rapidement transplantée, améliorer l'efficacité du développement et fournir une base pour une itération continue des fonctions et des mises à jour fréquentes pour les utilisateurs. L'OTA est le canal principal, et la première phase de mise en œuvre est la première étape vers les voitures définies par logiciel.

La deuxième étape : Réaliser progressivement l'intégration de la couche application et de la couche inférieure en achetant des outils de configuration. Le fournisseur de matériel fournit une « boîte blanche » pour l'intégration et le flashage chez l'OEM. Réalisez un véritable découplage entre les logiciels et le matériel, élargissez la portée de l'approvisionnement en matériel et réduisez les coûts d'approvisionnement. Cependant, les fonctions de configuration sous-jacentes nécessitent beaucoup d'investissements de la part des OEM, et ces derniers détermineront s'ils doivent entrer dans le jeu en fonction de leurs propres capacités.

La troisième étape : Entrer progressivement dans le développement indépendant du matériel et des couches sous-jacentes. Réduisez les coûts des véhicules grâce au matériel, sélectionnez indépendamment les puces principales, brisez les limites des plates-formes matérielles et effectuez une transplantation modulaire logicielle basée sur la configuration du véhicule et les exigences fonctionnelles basées sur le coût et l'expérience client.

3) Construction d'une plate-forme ouverte

Le développement automobile traditionnel repose entièrement sur la philosophie des ingénieurs de l'usine automobile et constitue un modèle de développement qui place les clients au-dessus des clients. Basée sur le nouveau modèle gagnant-gagnant, de symbiose et de co-création, la plateforme ouverte peut résoudre la relation entre les fournisseurs, les véhicules et les utilisateurs dans la nouvelle situation.

La plate-forme ouverte peut fournir aux ingénieurs de développement de véhicules, aux tiers et aux utilisateurs des capacités complètes du véhicule. Ces capacités incluent certaines capacités matérielles sous-jacentes, des capacités logicielles, des données et des informations. Sur la base de ces capacités combinées à des scénarios d'utilisation, des solutions diversifiées peuvent être créées. être développé. Le logiciel fournit aux utilisateurs des services personnalisés et par abonnement, créant de la valeur pour les utilisateurs et les OEM et bénéficiant également de ses propres avantages. Permettez aux utilisateurs de participer au développement de logiciels de véhicules et de véritablement réaliser des voitures définies par logiciel.

Grâce à la plate-forme ouverte, des centaines de milliers de modules matériels dans la voiture peuvent être utilisés, ce qui peut fournir des capacités de perception plus fortes, plus de scénarios d'application, une plus grande couverture et des cycles de vie plus longs que les téléphones mobiles, de sorte que l'écosystème automobile est plus large que l’écosystème de la téléphonie mobile, plus ouvert que les téléphones mobiles et plus proche des utilisateurs.

5.3 Fournisseur de pièces

Pour les fournisseurs de pièces traditionnels, dans le cadre de la tendance au développement des automobiles définies par logiciel, les OEM ont de plus en plus leur mot à dire dans le développement des fonctions du système. Avec l'aide du découplage logiciel et matériel et de la mise en œuvre de l'architecture SOA, les OEM seront également progressivement responsables. le développement des fonctions applicatives de certains fournisseurs de pièces détachées, de niveau 1, qui est traditionnellement basé sur le matériel, doit de toute urgence se transformer et trouver de nouvelles voies de sortie.

À l'heure actuelle, la création de capacités logicielles et matérielles complètes est la clé pour conquérir les prochains sommets de part de marché. De nombreux niveaux 1 dotés de capacités très complètes construisent « du matériel + des logiciels sous-jacents + des middlewares + des algorithmes de logiciels d'application ». + intégration du système" "Les capacités techniques full-stack peuvent fournir aux clients à la fois du matériel et des logiciels, ainsi que des solutions logicielles et matérielles intégrées. Cependant, une telle configuration nécessite que le niveau 1 investisse beaucoup de main-d'œuvre et de capitaux, ce que tous les niveaux 1 ne peuvent pas se permettre.

À cet égard, les fournisseurs de pièces détachées devraient ouvrir davantage les ports matériels et les capacités matérielles abstraites. Afin de réduire le coût de personnalisation pour les différents constructeurs OEM et d'améliorer l'efficacité de la livraison, les interfaces doivent être ouvertes selon des normes unifiées. Réduisez la complexité de la mise en correspondance, réduisez le couplage logiciel et matériel et améliorez la flexibilité et la réutilisation. Il s'associe également de manière proactive avec les OEM, les fournisseurs de logiciels et d'autres parties pour construire conjointement un écosystème de pièces afin d'attirer et de créer des scénarios de profit plus diversifiés et plus riches. Dans le cadre d'interfaces standard, les différences de performances entraîneront en même temps une concurrence pour les fournisseurs de pièces. , cela encouragera également les fournisseurs de pièces détachées à innover et à progresser. Les fournisseurs de pièces détachées doivent se concentrer sur les algorithmes de base internes et parvenir à une différenciation et à une évolution continue des performances et de l'expérience grâce à l'optimisation et à la mise à niveau des algorithmes et des codes internes. Et en coopérant avec des sociétés informatiques dans les domaines des constructeurs automobiles, de l'intelligence artificielle, des logiciels et d'autres domaines, nous pouvons comprendre les derniers besoins et orientations de développement, ajuster notre propre direction et nos capacités de R&D, nous baser sur le matériel et utiliser les connaissances accumulées par l'industrie. -Les avantages de développer des capacités logicielles de fonctions d'application, qui génèrent des retours et stimulent des ventes de matériel différenciées, sont le choix de nombreux fournisseurs de pièces détachées.

5.4 Fournisseur de plate-forme de base

Face à l'ère des voitures définies par logiciel, l'objectif des fabricants de plates-formes de base est d'utiliser leur propre accumulation de technologies TIC et leurs avantages pour aider les équipementiers à créer des solutions différenciées adaptées à leur propre planification de l'ensemble du véhicule L'architecture électronique et électrique de nouvelle génération réduit la complexité de la recherche et du développement des voitures intelligentes, améliore l'efficacité et accélère le développement des voitures intelligentes.

Mais le modèle actuel de la chaîne d'approvisionnement, des équipementiers aux fournisseurs de premier rang, en passant par les fournisseurs de deuxième rang et les fournisseurs de troisième rang, devient de plus en plus flou, et les constructeurs automobiles espèrent de plus en plus dominer davantage de contenu. briser les frontières avec une attitude plus ouverte, se concentrer sur leurs propres produits avantageux, fournir des interfaces API ouvertes pour le matériel supérieur et inférieur et les logiciels d'application, et fournir un environnement d'exploitation sûr et digne de confiance ainsi qu'un développement et une vérification de services faciles à utiliser pour les logiciels fonctionnels . Chaîne d'outils.

Il est recommandé aux fournisseurs de plates-formes de base de fournir aux OEM une architecture pour l'évolution durable des voitures intelligentes. Le concept de conception doit être axé sur les personnes et continuer à innover autour de l'expérience utilisateur et de la réussite commerciale des OEM.

5.5 Fournisseur de logiciels/développeur de logiciels

Avec le renforcement continu de l'autonomie des OEM et des capacités d'auto-recherche des logiciels, les OEM ont commencé à rechercher une coopération directe avec les fournisseurs de logiciels, tels que les constructeurs de véhicules complets chercheront d'abord à reprendre les fonctions du système interactif HMI du cockpit. Les logiciels d'application tels que les outils de conception UI/UX, les modules de reconnaissance vocale, les modules d'effets sonores et les modules de reconnaissance faciale achèteront directement des licences logicielles auprès des fournisseurs de logiciels, contournant ainsi le niveau 1 traditionnel et atteignant l'autonomie. . développement.

Avec l'avancement de la révolution automobile définie par logiciel, les systèmes matériels automobiles se standardisent progressivement, et le logiciel est la partie itérative la plus rapide, la plus facile à personnaliser et à différencier de la voiture. Dans le même temps, le logiciel pilotera également le matériel. innovation 2. Les uns se complètent. Pour les fournisseurs de logiciels, plus ils peuvent proposer de portefeuilles de produits logiciels IP, plus ils ont de chances d'obtenir une valeur de véhicule plus élevée.

Dans le même temps, les éditeurs de logiciels cherchent également à pénétrer dans les maillons de conception et de fabrication de matériel contrôlés par le Tier1 traditionnel, tels que les contrôleurs de domaine, T-BOX, etc., pour proposer des solutions diversifiées. Pour le développement d'applications d'applications de voiture intelligente, le développement de logiciels d'application basés sur l'API standard de service atomique deviendra très pratique et facile à utiliser. Pour les applications, il n'est pas nécessaire de prêter trop d'attention à l'implémentation sous-jacente et de réduire les dépendances des différents niveaux et modules, à l'instar du modèle de développement basé sur Android. Pour différents groupes de personnes, différentes voitures et différents scénarios de vie, différents développeurs d'applications créeront des applications avec différentes fonctions, différents graphiques et différentes expériences.

Le seuil de développement d'applications est devenu plus bas et davantage de fournisseurs/développeurs de logiciels peuvent participer au développement d'applications automobiles. En conséquence, la concurrence dans le développement de logiciels est devenue plus grande. Les fournisseurs de logiciels devraient analyser les préférences de différents groupes de personnes sur la base de certaines données d'enquête et développer des applications différenciées adaptées au public pour différents modèles de voitures. Les utilisateurs peuvent installer de manière sélective certaines fonctions et applications de fonctionnalités en fonction de leurs conditions réelles. Grâce à différentes applications et services, ils peuvent définir certaines caractéristiques de leurs propres véhicules pour réaliser des mises à niveau fonctionnelles ou une personnalisation personnalisée via un logiciel.

Dans le processus de concurrence, non seulement des logiciels d'application très populaires émergeront, mais ils augmenteront également l'initiative et la précision des fournisseurs de logiciels d'application pour améliorer les services et améliorer leur capacité à innover des produits, faisant ainsi prospérer l'écosystème d'applications pour voitures intelligentes. .

5.6 Organisations industrielles

Le gouvernement devrait aider l'ensemble de l'industrie automobile à établir un système de gestion raisonnable et efficace du point de vue des réglementations, politiques, normes, etc., superviser le fonctionnement ordonné et fluide de l'ensemble l'industrie, et continuer à grandir et à se renforcer, et à assurer une concurrence équitable dans l'ensemble de l'industrie.

Encouragez les entreprises à développer de nouvelles technologies d'un point de vue politique. Par exemple, vous pouvez récompenser les unités commerciales qui ont contribué à l'industrie automobile ou qui ont réalisé des percées dans certaines technologies, partager et afficher les résultats de l'innovation et parvenir à une intégration profonde de la science. et les politiques technologiques et l'innovation technologique. Nous continuerons d'améliorer les politiques, d'améliorer le système de rétroaction, de faire jouer pleinement la force motrice des politiques visant à développer de nouvelles technologies, de créer un bon écosystème de logiciels automobiles et d'utiliser des véhicules connectés intelligents pour piloter la construction et l'innovation technologique. développement des transports intelligents et des villes intelligentes.

Établir des interfaces communes et d'autres spécifications pour résoudre des problèmes courants sur la base de normes, réaliser l'interconnexion des logiciels et des produits matériels automobiles, éviter que chaque entreprise ne se batte au niveau des interfaces standardisées communes et encourager chaque entreprise à faire du bon travail en développant leurs propres produits sous une interface unifiée Innovation et R&D, éviter la duplication et les investissements fragmentés, améliorer l'efficacité de la R&D et promouvoir le développement de véhicules connectés intelligents dans notre pays.

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!