Découvrez l'architecture logicielle du contrôleur de domaine de conduite intelligente dans un seul article

La conduite intelligente nécessite que des personnes de nombreuses disciplines différentes travaillent ensemble, et tout le monde n'a pas une formation en logiciel ou en logiciel automobile. Afin de permettre à des personnes d'horizons différents de comprendre dans une certaine mesure le contenu de l'article, cet article essaie d'utiliser un langage très populaire pour le décrire et de l'illustrer avec diverses images. Cet article évite l’utilisation d’une terminologie ambiguë et tous les termes reçoivent leur définition précise dès leur première apparition.

L'importance de l'architecture logicielle de conduite intelligente

Modèle conceptuel simplifié de la conduite intelligente

Le modèle conceptuel de la conduite intelligente consiste simplement à résoudre trois problèmes fondamentaux :

1.

2. Où vais-je ?

3. Comment y arriver ?

La première question « Où suis-je ? » Ce qu'il faut résoudre, c'est le problème de la « perception de l'environnement » et du « positionnement ». Ce qu'il faut comprendre, c'est la position de la voiture elle-même et l'environnement statique autour de la position. (routes, panneaux de signalisation, feux de circulation) etc.) et environnement dynamique (voitures, personnes, etc.). Cela a déclenché une série de solutions techniques de détection et de positionnement, notamment divers capteurs et systèmes algorithmiques.

La deuxième question « Où vais-je ? » Dans le domaine de la conduite autonome, il s'agit de « planifier la prise de décision ». De là découlent certains termes tels que « planification globale », « planification locale », « planification des tâches », « planification de parcours », « planification du comportement », « prise de décision comportementale », « planification des mouvements », etc. En raison de l'ambiguïté linguistique, certains de ces termes ont différentes manières de dire le même sens, dont certains ont souvent des significations similaires mais légèrement différentes selon les occasions.

Mis à part la terminologie spécifique, d'une manière générale, le problème de la « prise de décision en matière de planification » sera décomposé en trois parties :

1. Planification du chemin, planification des tâches)

2. Divisez les résultats de la première étape en plusieurs étapes (termes courants : planification comportementale, prise de décision comportementale)

3. Effectuez une planification plus approfondie pour chaque étape (couramment utilisée). Termes : planification locale, planification de mouvement)

Pour ces différentes planifications, de nombreux systèmes algorithmiques permettant de résoudre des problèmes sont dérivés.

La troisième question « Comment dois-je procéder ? » fait généralement référence au « contrôle de l'exécution », c'est-à-dire à la mise en œuvre effective du plus petit plan pour atteindre l'objectif du plan. En particulier dans le domaine automobile, cela se reflète souvent dans divers algorithmes de contrôle, et la théorie du contrôle résout ces problèmes.

Parce que les solutions à ces trois problèmes sont toutes des problèmes algorithmiques en dernière analyse, donc dans un sens, le cœur de la conduite autonome est l'algorithme. D’une certaine manière, l’architecture logicielle doit être capable de supporter ces algorithmes. Sans un bon système de transport, quelle que soit la qualité de l'algorithme, il sera inutile.

Caractéristiques fractales récursives du modèle conceptuel de base

Par souci de commodité, nous représentons les trois problèmes du modèle conceptuel de base comme E, P et ). Chaque ensemble d'E-P-X a son espace de problème descriptif.

Par exemple, si nous définissons l'espace problématique A comme « conduire de Pékin à Guangzhou », alors pour le problème E : son positionnement peut se concentrer sur le quartier actuel de Pékin, et il n'est pas nécessaire de l'affiner aux rues. Nous devons également nous soucier de la présence ou non d'orages et des informations sur la structure routière au-dessus des autoroutes provinciales. Pour la question P :

P-1 : La première étape consiste à concevoir un itinéraire global, quelle autoroute, autoroute nationale ou provinciale emprunter

P-2 : Planifier une série d'éléments comportementaux basés sur chemin global, à quelle intersection d'autoroute se rendre en premier, combien de kilomètres parcourir, se rendre à l'aire de service pour faire le plein, changer de route, etc.

P-3 : Planifier le chemin routier spécifique à chaque tronçon. Par exemple, que vous souhaitiez emprunter le troisième périphérique ou le quatrième périphérique jusqu'à une intersection d'autoroute, vers quelle route changer

X doit exécuter chaque étape prévue par P.

Si nous définissons l'espace problématique B comme « conduire en toute sécurité à une intersection », alors pour le problème E, nous devons prêter attention aux informations routières actuelles, aux informations sur les feux de circulation, aux conditions des véhicules sur la route, aux conditions des piétons, etc. Pour le problème P :

P-1 : La première étape consiste à planifier un chemin sûr à travers l'intersection, y compris quelle voie pour atteindre l'intersection actuelle et quelle voie pour entrer dans l'intersection cible selon les règles de circulation et les informations routières.

P-2 : La deuxième étape consiste à planifier une série de séquences d'action basées sur les résultats fondamentaux de la première étape, comme ralentir d'abord, changer de voie cible, s'arrêter et attendre le feu rouge, commencer à accélérer et passer l'intersection.

P-3 : La troisième étape consiste à concevoir une trajectoire spécifique pour chaque action de la deuxième étape. La trajectoire doit pouvoir éviter les obstacles tels que les piétons et les véhicules.

X est responsable de l'exécution de la sortie du problème P.

Cet espace problématique B est le plus proche du problème à résoudre par les algorithmes de planification habituels. La première étape de P-1 est souvent appelée « planification globale » ou « planification des tâches », P-2 est souvent appelée « planification comportementale » ou « prise de décision comportementale » et P-3 est appelée « planification locale » ou « planification comportementale". Plan de mouvement". Comme le montre la figure ci-dessous, E-P-X forme un modèle conceptuel de base abstrait, et les espaces de problèmes A et B sont ses implémentations spécifiques dans une certaine portée.

Figure 1 Deux espaces de problèmes EPX

A et B ont des structures E-P-X similaires, mais les étendues des problèmes qu'ils résolvent sont très différentes dans le temps et dans l'espace. Dans l'image ci-dessus, la tâche que A : Ainsi, comme le montre la figure ci-dessous, le modèle E-P-X est une structure fractale récursive.

Figure 2 Structure fractale récursive d'EPX

X dans le niveau supérieur peut toujours être décomposé en E-P-X à plus petit grain par le niveau suivant pour exécution.

« Fractale » est également appelée « fractale auto-similaire ». Sa compréhension populaire est que les parties des choses ont des structures similaires à l'ensemble, qui est une symétrie à différentes échelles, comme une branche d'arbre et le tout. arbre Ils ont une structure similaire et de plus, les nervures de la tige de chaque feuille ont également une structure similaire. La figure ci-dessous répertorie quelques structures fractales typiques.

Figure 3 Exemple fractal

Ces 6 graphiques ont une fonctionnalité, n'importe quelle partie de chaque graphique a la même structure que le graphique entier. Si vous zoomez davantage sur la zone locale, vous constaterez que la zone locale a la même structure. Par conséquent, lorsque nous disposons d’un ensemble de logiques de traitement métier qui peuvent être appliquées à l’ensemble, elles peuvent également être appliquées aux parties. Tout comme pour la culture de certains arbres, vous pouvez prendre une branche et la planter, et elle deviendra un nouvel arbre. L'expression mappée à un logiciel est « récursion ». Cela ne signifie pas utiliser des fonctions récursives, mais une récursivité au niveau architectural.

L'expression la plus académique de « fractale » est « l'utilisation de la perspective de dimension fractionnaire et de méthodes mathématiques pour décrire et étudier des choses objectives, en sautant hors des barrières traditionnelles des lignes unidimensionnelles, des surfaces bidimensionnelles, des surfaces tridimensionnelles ». des solides et même de l'espace-temps à quatre dimensions. Il est plus proche de la description des attributs réels et du statut de systèmes complexes, et plus cohérent avec la diversité et la complexité des choses objectives. Lorsque nous trouvons une expression mathématique appropriée pour la « réalité physique » et que nous la convertissons ensuite en « réalité du programme », nous pouvons trouver une architecture logicielle et une méthode de mise en œuvre plus concises, claires et précises.

L'architecture logicielle résout le mappage de la « réalité physique » à la « réalité du programme »

E-P-X est une structure abstraite basée sur la « réalité physique ». Et la plupart d’entre eux sont des travaux algorithmiques de différents types. La recherche et le développement des algorithmes individuels eux-mêmes peuvent être effectués indépendamment sur la base de conditions d'entrée et de sortie prédéfinies. Mais comment combiner les algorithmes, les déclencher correctement au bon moment et utiliser les résultats de manière raisonnable, pouvons-nous enfin former une fonction ayant une utilisation pratique. Le cœur de ce pont entre la « réalité physique » et la « réalité du programme » est l’architecture logicielle.

Le système de conduite autonome va du niveau 1 au niveau 5. Plus le modèle E-P-X mentionné ci-dessus est imbriqué profondément, plus il est élevé. L'architecture logicielle devient plus difficile. La plupart des fonctions simples de niveau 1 et de niveau 2 ne nécessitent qu'une seule couche du modèle E-P-X. Prenons l'exemple de l'AEB (freinage automatique d'urgence) :

Partie E (perception) : principalement reconnaissance statique et classification des cibles devant (voitures, personnes), suivi dynamique et détection de la distance et de la vitesse.

Partie P : étant donné que l'AEB effectue uniquement un contrôle longitudinal, tout peut être réalisé via le contrôle de la vitesse. Il suffit donc de planifier la vitesse sur une période de temps.

Partie X : Transmettez la planification de la vitesse à l'unité de commande du véhicule.

Cela ne veut pas dire qu'avec une seule couche d'EPX, la fonction AEB est simple. En fait, il est très difficile de mettre en œuvre des fonctions AEB qui peuvent être produites en série. Cependant, l'EPX de premier niveau n'a pas besoin d'être planifié en fonction de scénarios, il doit uniquement se concentrer sur la mise en œuvre d'EPX dans un seul scénario, et son architecture logicielle est relativement simple. Le chapitre 2 présentera l'architecture logicielle commune des fonctions L2.

Qu'est-ce que la planification basée sur les scènes ?

Même dans la boucle EPX au plus petit niveau de granularité, aucune implémentation d'EXP ne peut résoudre tous les problèmes à ce niveau.

Par exemple : pour un cas d'utilisation simple de conduite en ligne droite, nous pouvons implémenter l'unité de fin X en tant qu'algorithme de contrôle du véhicule, qui peut gérer tous les scénarios de routes plates, de montée et de descente. Vous pouvez également utiliser une unité de planification (S) pour identifier les routes plates, les pentes ascendantes et les pentes descendantes comme différents scénarios basés sur les informations de l'unité E, et passer à différents cycles EXP de niveau suivant. Chaque boucle EXP du niveau suivant implémente une seule scène. En fait, même si un algorithme de contrôle d'unité X est utilisé pour résoudre tous les scénarios de route plate, de montée et de descente, l'algorithme distinguera toujours ces scénarios en interne. En fait, il s'agit toujours d'une boucle EXP à petit grain.

Figure 4 Planification EPX

Comme le montre la figure 4, la planification de scène (S) peut être à tous les niveaux, ce qui signifie que la définition de « scénario » est également une division granulaire. Le modèle EPX doit donc être le modèle EPX-S. Il n’y a tout simplement pas de section S évidente en dessous de L2.

Comment l'architecture logicielle est compatible avec L1 à L3+

La fonction d'aide au stationnement automatique commence à nécessiter une planification de scènes, comme le stationnement vertical, le stationnement vertical, le stationnement horizontal, le stationnement horizontal, le stationnement en diagonale, etc. Ils sont tous différents scénarios, et leurs parties P et X doivent être implémentées séparément. Cependant, la planification des scènes peut être sélectionnée manuellement via l'interface HMI, qui est une unité S « humain dans la boucle ».

Niveau 3 Parmi les fonctions ci-dessus, aucune intervention manuelle n'est requise pendant une longue période de conduite continue. Cela impliquera inévitablement la planification automatique de plusieurs niveaux d’EXP différents. De cette manière, l'architecture logicielle est très différente des fonctions situées en dessous de L2. C’est l’une des raisons pour lesquelles de nombreuses entreprises divisent les L2 et L3+ en deux équipes différentes.

En fait, tant que l'architecture logicielle est consciemment conçue sur la base du modèle EXP-S à plusieurs niveaux, chaque unité EXP-S a sa propre incarnation appropriée. En fait, un ensemble d'architecture logicielle peut être réalisé pour. support de L1 à L3+ La conduite automatique ci-dessus est basique. C'est juste que l'unité S est plus faible pour les fonctions inférieures à L2, mais son statut architectural existe toujours.

Architecture logicielle des contrôleurs à fonction unique L2 et inférieurs

Jetons d'abord un coup d'œil à l'architecture logicielle commune de la fonction L2.

Utilisation de la solution AEB/ACC/LKA de Smart Sensor

Les trois fonctions AEB/ACC/LKA sont les fonctions d'aide à la conduite les plus classiques de L2. La partie perception de la solution système générale utilise principalement la cible de sortie de la caméra avant (véhicules, piétons) et les fusionner avec les données cibles fournies par le radar à ondes millimétriques avant pour obtenir une vitesse et une distance plus précises. La perception visuelle et la perception radar utilisent principalement des solutions de capteurs intelligents, de sorte que le niveau 1 peut choisir des produits auprès de fournisseurs matures de niveau 2. Les principaux travaux de développement du niveau 1 portent sur la mise en œuvre de la fusion des perceptions et de l'algorithme de contrôle des machines à états fonctionnels et des véhicules. Architecture matérielle couramment utilisée topologie

Option 2 : Un contrôleur L2 indépendant connecte les capteurs intelligents de vision et de radar. Le contrôleur L2 complète la fusion de perception et la machine d'état fonctionnelle L2

Figure 6 Topologie du schéma 2

. 2 Toutes les solutions sont souvent adoptées. La solution 1 utilise un contrôleur radar plus performant et alloue certaines unités de calcul pour mettre en œuvre l'algorithme de fusion et la machine à états fonctionnelle. De nombreux fabricants de puces prennent en compte cette partie de la puissance de calcul lors de la conception de puces de traitement radar. Par exemple, la série S32R de NXP est spécialement conçue pour les calculateurs radar. Ses multiples cœurs sont suffisants pour effectuer simultanément le traitement du signal radar et la mise en œuvre de la fonction L2. Après tout, l’algorithme visuel le plus gourmand en calculs est réalisé sur un autre appareil.

L'option 2 sépare L2 pour implémenter le contrôleur de fonction L2 et communique avec deux capteurs intelligents via un Can privé pour obtenir des données de détection. D'une manière générale, cette solution peut envisager d'ajouter davantage de fonctions L2 à l'avenir, et si nécessaire, vous pouvez connecter davantage de capteurs intelligents.

Architecture logicielle typiquePour l'architecture système utilisant Smart Sensor, la caméra intelligente orientée vers l'avant et le radar à ondes millimétriques orienté vers l'avant donnent respectivement la sémantique des objets cibles dans l'environnement observé. Ces deux parties de données sont directement transférées au module responsable de la fusion des perceptions et de la mise en œuvre de la fonction L2 via le bus Can ou le mécanisme interne IPC (communication inter-processus du système d'exploitation de l'ordinateur).

Qu'il s'agisse de la solution matérielle un ou de la solution deux, l'architecture logicielle la plus couramment utilisée dans l'industrie est développée sur la base de Classic AutoSar. Classic AutoSar fournit des fonctions communes pour les calculateurs de véhicules et fournit un environnement d'exécution et des canaux d'entrée et de sortie de données pour les logiciels de référence. Le module de fusion de perception et d'autres fonctions ACC/AEB/LKA peuvent être implémentés sous la forme d'un ou plusieurs SWC AutoSar (composants logiciels). Chaque développeur a sa propre logique raisonnable quant à savoir si et comment diviser ces composants SWC. Mais l’architecture de base est sensiblement la même.

Bien sûr, vous ne pouvez pas utiliser Classic AutoSar et utiliser d'autres RTOS appropriés comme système sous-jacent. Cela sera peut-être plus difficile pour les calculateurs de véhicules qui nécessitent un développement de fonctions générales et répondent aux normes de sécurité fonctionnelle, mais en termes d'architecture du système. du développement de fonctions d'application, ce sera plus difficile. Il n'y a pas beaucoup de différence dans la solution utilisant Classic AutoSar. Figure 7 Architecture logicielle typique des algorithmes d'exécution de contrôle ACC/AEB/LKA et machines à états fonctionnels ACC/AEB/LKA. Utilisez ensuite des outils pour générer du code C et intégrez-le manuellement dans la plateforme cible. L'un des avantages de la méthode de développement MDB est que vous pouvez d'abord utiliser des outils et des équipements de modèle tels que CanOE pour développer et déboguer directement sur le véhicule, ou vous connecter à la plateforme de simulation pour le développement et le débogage. De cette façon, l'équipe de développement peut être divisée en deux parties, une partie utilise des outils modèles pour développer des fonctions d'application, et l'autre partie développe une série de tâches fastidieuses requises par tous les calculateurs de véhicules, puis les intègre ensemble.

Solutions de produits plus intégrées

Généralement, les produits de stationnement entièrement automatiques adopteront une solution plus intégrée, intégrant des algorithmes visuels (reconnaissance d'obstacles statiques, reconnaissance d'obstacles dynamiques, reconnaissance des piétons, reconnaissance de ligne d'espace de stationnement) algorithme de radar à ultrasons (détection de distance, détection d'obstacles), la planification de la trajectoire et l'exécution du contrôle du processus de stationnement sont toutes réalisées dans un seul contrôleur. Un niveau d'intégration plus élevé prendra également en charge la fonction de vue surround à 360 degrés dans le contrôleur de stationnement automatique, qui doit également prendre en charge la correction de l'image surround de la caméra et l'épissage du rendu graphique 2D/3D, la sortie vidéo, la génération HMI et d'autres fonctions.
La topologie matérielle schématique est la suivante.

Illustration de la topologie matérielle

Figure 8 Solution de topologie matérielle du système de stationnement

Chaque module de la figure a différents modes de distribution dans différentes solutions de sélection matérielle. Généralement, les MCU utilisés pour le traitement en temps réel utilisent une puce distincte. Différents fabricants de puces disposent de leurs propres solutions d’unités d’IA. Certains utilisent un DSP haute performance, d'autres des unités de calcul matricielles propriétaires, d'autres encore un FPGA, etc.

Architecture logicielle typique

L'image ci-dessous est une architecture logicielle typique du système de stationnement automatique (il ne s'agit que d'une illustration simplifiée, le système de production de masse réel sera plus complexe) :

Par rapport à 2.1.1 Le changement le plus significatif ici est la distinction entre les systèmes « domaine temps réel » et « domaine performance ». De manière générale, nous appelons les systèmes logiciels et matériels sur MCU ou autres cœurs temps réel (Cortex-R, Cortex-M ou autre série équivalente) le « domaine temps réel ». Le grand cœur du SOC (Cortex-A ou série équivalente) et Linux/QNX qui s'y exécute sont collectivement appelés le domaine de performance, qui comprend généralement également des systèmes logiciels et matériels prenant en charge l'accélération visuelle des algorithmes.

Bien qu'en termes de difficulté d'ingénierie pour la production de masse, le système de stationnement entièrement automatique est beaucoup plus petit que les fonctions de sécurité active de niveau 2 telles que ACC/AEB/LKA. Mais en termes d’architecture logicielle, le système de stationnement est bien plus compliqué. Cela se reflète principalement dans les aspects suivants :

Figure 9 Architecture logicielle du système de stationnement

La division du domaine temps réel et du domaine de performance apporte une complexité systémique, qui doit être basée sur des données réelles. exigences de temps et ressources informatiques Exigences, choisissez différentes plates-formes matérielles pour différents calculs

• OS dans le domaine des performances Après l'adoption de Linux, l'environnement d'exécution au niveau du système d'exploitation est beaucoup plus compliqué que RTOS
• Une série de frameworks ou middleware sont nécessaires pour prendre en charge le développement des applications
• Complexité du chemin de données
• augmentation du chemin de traitement du flux vidéo
• augmentation des exigences de chemin de données entre le domaine temps réel et le domaine de performance
• Il y a données entre différents modules logiciels dans le domaine des performances Une fois les exigences de communication
• mises en œuvre dans la solution de plate-forme de puce spécifique, la conception architecturale doit être intégrée et coordonnée avec les différents SDK de la puce

De plus, à travers cette architecture logicielle, on peut constater que l'introduction de Linux (ou QNX /vxworks). Ces systèmes eux-mêmes sont des systèmes d'exploitation informatiques qui n'ont rien à voir avec des industries spécifiques. Lorsqu'ils sont utilisés dans les contrôleurs électroniques automobiles, ils comportent une série de fonctions générales qui n'ont rien à voir avec des fonctions spécifiques du produit mais doivent être implémentées en tant que calculateurs automobiles. Tels que les diagnostics, la synchronisation de l'horloge, les mises à niveau, etc. Cette partie représente une charge de travail très importante dans le développement global du contrôleur, dépassant 40 % dans de nombreux cas, et est très liée à la fiabilité du contrôleur.

Dans le domaine des équipements de communication en réseau, ceux-ci sont souvent appelés plans de gestion. Beaucoup sont également des fonctionnalités de base fournies par AutoSar AP. En fait, qu'il s'agisse de CP AutoSar ou d'AP AutoSar, à l'exception du module responsable de la communication, la plupart des autres sont des capacités du plan de gestion.

Coopération de plusieurs calculateurs monofonctions

Comment travailler ensemble s'il y a plusieurs fonctions L2 sur un véhicule. La figure ci-dessous est un exemple de topologie multi-contrôleur simplifiée.

Figure 10 Schéma de topologie de plusieurs contrôleurs de fonctions L2 plus des contrôleurs de domaine#🎜🎜 ##🎜 🎜#

Cette topologie intègre 6 contrôleurs, fournis par "système de stationnement entièrement automatique", "caméra intelligente avancée" et "radar avant à ondes millimétriques". La fonctionnalité est telle que décrite précédemment. Les radars d'angle gauche et droit sont deux dispositifs en miroir, chacun fonctionnant indépendamment et pouvant réaliser des fonctions telles que « alarme d'approche de véhicule arrière » et « alarme d'ouverture de porte ». Le « système de surveillance du conducteur » détecte l'état du conducteur et peut déclencher une alarme lorsqu'il constate que le conducteur est fatigué pendant la conduite. Si le conducteur perd complètement la capacité de se déplacer, il informera les autres systèmes d'essayer de ralentir et de s'arrêter.

Les points clés de cette topologie sont les suivants : introduction d'un contrôleur de domaine pour connecter plusieurs contrôleurs de fonctions d'assistance à la conduite indépendants, et connexion du contrôleur de domaine au réseau fédérateur Can ; bus pour éviter une bande passante insuffisante du bus.

D'un point de vue architecture logicielle, chaque contrôleur d'aide à la conduite fonctionne de manière indépendante et décide indépendamment de démarrer et d'arrêter ses propres fonctions. Les signaux de contrôle pertinents sont envoyés au contrôleur de domaine, qui les transmet au domaine d'alimentation. Le contrôleur de domaine d'assistance à la conduite est chargé d'évaluer les sorties de commande des contrôleurs individuels. Du point de vue du rôle que les contrôleurs de domaine peuvent jouer ici, il existe différentes conceptions possibles, du plus léger au plus lourd. Dans la conception légère du contrôleur de domaine, le contrôleur de domaine effectue uniquement un simple transfert de données, filtrant les données sur le réseau fédérateur et les envoyant au contrôleur du domaine. Envoyez des signaux de contrôle des contrôleurs du domaine au réseau fédérateur. Cette méthode ne nécessite pas une puissance de calcul élevée du contrôleur de domaine.

Si le contrôleur de domaine assume plus de travail, il peut prendre en charge le travail de calcul de la partie de domaine en temps réel d'autres contrôleurs. Par exemple, les calculs de contrôle de planification de ACC/AEB/LKA sont tous effectués sur le contrôleur de domaine. Cela nécessite que d'autres contrôleurs envoient des données de détection au contrôleur de domaine, qui seront traitées uniformément par le contrôleur de domaine. Cela nécessite une puissance de calcul plus élevée. Dans le même temps, les besoins en bande passante des réseaux intra-domaines ont également augmenté.

Pour aller plus loin, car il peut obtenir toutes les données de détection, le contrôleur de domaine peut également développer certaines fonctions supplémentaires, comme s'appuyer sur les capteurs de l'image, c'est possible de Le contrôleur de domaine met en œuvre des fonctions d'assistance au changement de voie ou d'évitement d'obstacles d'urgence.

À mesure que les fonctions se concentrent progressivement sur les contrôleurs de domaine, les parties non conscientes des autres contrôleurs qui sont responsables de la partie consciente sont progressivement affaiblies.

Modèle conceptuel EPX-SA

Mécanisme d'arbitrage#🎜🎜 #Comme mentionné précédemment, la réalisation des fonctions ACC/AEB/LKA, la réalisation d'un stationnement entièrement automatique et d'autres fonctions en dessous d'un seul L2 peuvent être comprises comme une ou deux couches de fractales Modèle EPX-S récursif.

En fait, ces trois fonctions ACC/AEB/LKA peuvent être activées en même temps dans les produits de production de masse. Chacune est un cycle EPX-S distinct. . Cela signifie que plusieurs boucles EPX-S peuvent être exécutées simultanément et en parallèle. Si la sortie X est générée en même temps, elle doit être arbitrée par un mécanisme d'arbitrage (Arbitrage).

Lorsque plusieurs contrôleurs s'exécutent en même temps, le contrôleur de domaine arbitre à un niveau supérieur.

Le modèle EPX-S devrait donc être étendu au modèle EPX-SA. Comme le montre la figure ci-dessous, le scénario 1 et le scénario 2 sont deux boucles EPX-S fonctionnant en parallèle, et le X qu'elles génèrent est sorti après arbitrage.

Figure 11 Modèle conceptuel EPX-SA #

#🎜 🎜#Proposition du concept de modèle environnemental

Chaque contrôleur qui implémente une seule fonction L2 possède certains aspects de capacités de perception. Ils décrivent tous un certain aspect des attributs de l'environnement interne et externe du véhicule, qui peuvent être divisés à partir des angles spatiaux et des distances, ou à partir d'attributs physiques, tels que la lumière visible, les ondes ultrasonores, les ondes millimétriques et les lasers. Si un système de modèle 3D idéal et totalement précis est établi pour l'ensemble de l'environnement, chaque capteur équivaut à un filtre pour ce modèle. Comme « l'aveugle touchant l'éléphant », chaque capteur exprime un certain aspect des attributs du modèle idéal.

La partie perception de la conduite intelligente consiste en fait à utiliser autant de capteurs et d'algorithmes que possible pour obtenir une approximation du modèle idéal. Plus il y aura de capteurs disponibles, plus l’algorithme sera précis et moins il s’écartera du modèle idéal.

Dans le contrôleur de domaine de L2, si nécessaire, les données de détection de tous les contrôleurs subordonnés peuvent être obtenues. Ensuite, à ce niveau, un modèle réaliste du modèle d'environnement idéal peut être élaboré sur la base de tous les résultats de détection. Il existe encore un grand écart entre le modèle idéal, mais il s'agit déjà d'un modèle environnemental au sens holistique.

Les informations fournies par le modèle d'environnement sont utilisées non seulement dans les modules de planification (P) à tous les niveaux, mais également dans les étapes de planification (S) et d'arbitrage (A).

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!