Conception d'architecture logicielle et méthodologie de découplage logiciel et matériel dans SOA

​Pour la prochaine génération d'architecture électronique et électrique centralisée, l'utilisation d'une unité informatique centrale centrale + zonale et d'une disposition de contrôleur régional est devenue une option incontournable pour divers OEM ou acteurs de niveau 1. En ce qui concerne l'architecture de l'unité centrale de calcul, il y a. Il existe trois manières : SOC séparé, isolation matérielle, virtualisation logicielle. L'unité informatique centrale centralisée intégrera les fonctions commerciales de base des trois principaux domaines de la conduite autonome, du cockpit intelligent et du contrôle des véhicules. Le contrôleur régional standardisé a trois responsabilités principales : la distribution d'énergie, les services de données et la passerelle régionale. L’unité centrale de calcul intégrera donc un commutateur Ethernet haut débit.

À mesure que le degré d'intégration de l'ensemble du véhicule devient de plus en plus élevé, de plus en plus de fonctions ECU seront lentement absorbées par le contrôleur régional. Le contrôleur régional basé sur la plate-forme utilise la même conception matérielle et la même interface IO, qui peuvent mieux répondre aux exigences d'évolutivité des différents modèles. Par conséquent, le contrôle régional assume également la fonction importante d’abstraction du matériel automobile. Les deux utiliseront Ethernet haut débit au lieu de la communication Can d'origine pour se connecter l'un à l'autre. En résumé, l'architecture électronique évolutive vise à protéger les différences matérielles entre les modèles. Quel que soit le nombre de contrôleurs régionaux utilisés dans le réseau de communication, leurs modes de communication mutuelle suivent les mêmes règles. Dans le même temps, le contrôleur régional assume également la responsabilité d'extraire les fonctions de l'ECU au sein de son réseau local.

L'architecture centralisée ci-dessus avec la plate-forme informatique centrale comme noyau a mis en place un capteur unifié et une interface périphérique, qui peut prendre en charge les mises à niveau des puces. Son objectif ultime est de réaliser des mises à niveau matérielles au cours du cycle de vie du véhicule, prolongeant ainsi la durée de vie du véhicule. Le cycle de vie intelligent des automobiles. Chaque contrôleur régional dispose de son propre middleware de système d'exploitation SOA Core Middleware, qui peut fournir un cadre de calcul et de communication distribué, protéger les différences entre les noyaux des différents systèmes d'exploitation et fournir un cadre de développement de services unifié pour le côté supérieur. Les fonctions impliquées incluent la gestion des services, la gestion du réseau, la gestion des communications, les mises à niveau, le diagnostic, les journaux, l'état, etc.

Cet article se concentrera sur l'orientation du découplage logiciel et matériel pour expliquer comment déployer des logiciels et du matériel pour SOA.

01 Principe de conception de l'architecture logicielle SOA

La figure suivante montre le principe typique de conception de l'architecture logicielle SOA. Cette architecture de développement orientée services est en fait une solution de modèle d'architecture SOA pour le développement orienté services, permettant aux chefs de produit de se concentrer sur la conception des services, tandis que les logiciels système approfondissent le processus de développement de produits. C'est également une solution à la crise des logiciels automobiles. Une avancée majeure. L'ensemble de l'architecture SOA peut être résumé comme un système découplé logiciel-matériel construit par une architecture logique et une abstraction et une adaptation des services complétées par une architecture de services, établissant finalement un système de services standardisé.

Le processus global de conception d'architecture logique peut être résumé comme suit :

Architecture électronique et électrique : La conception d'une architecture évolutive (également appelée architecture informatique et de communication) doit répondre aux exigences de conception en couches, de tests en couches et vérification en couches , pour éviter la réaction en chaîne des modifications logicielles pendant la phase de développement et l'apparition concentrée de problèmes lors des tests d'intégration, afin que les problèmes puissent être découverts plus rapidement et que les versions logicielles puissent être modifiées plus rapidement.

Plate-forme informatique matérielle : La plate-forme matérielle évolutive comprend la gestion des services de base SOA et la gestion du contrôle des E/S matérielles SOA, est compatible avec plusieurs capteurs et périphériques externes du système de conduite autonome, et prend en charge les puces et les mises à niveau matérielles multi-hétérogènes.

Intergiciel noyau/service du système d'exploitation : En tant que cœur de la planification et de la conduite des fichiers, le système d'exploitation peut atteindre les meilleures capacités de contrôle en prenant en charge le découplage logiciel et matériel et le déploiement de logiciels sur le matériel.

Architecture de communication : L'évolutivité de l'architecture de communication peut bien garantir une adaptation rapide dans le développement de modèles basés sur une plate-forme. Les différences entre les modèles peuvent être réduites au minimum. effectué afin d'apprendre de la génération actuelle de produits , il n'est pas nécessaire d'effectuer de nombreux travaux de développement supplémentaires, ce qui peut réduire considérablement la pression de la maintenance ultérieure de la gamme de produits.

Afin de répondre aux exigences en temps réel du contrôle des véhicules, le réseau central adoptera des technologies de communication fiables telles que TSN. Dans le LAN relevant du contrôleur régional, les méthodes de communication traditionnelles telles que CAN et Lin continueront d'exister. La communication au sein d'un réseau local peut être effectuée sous la forme de signaux traditionnels. Dans le réseau fédérateur Ethernet central, les données interagiront sous la forme de services, ce qui nécessite un middleware de communication tel que DDS.

Couche de service/couche d'application : La couche de service standardisée et la couche d'application orchestrable comprennent plusieurs parties importantes de la gestion des fonctions du système SOA, de la gestion des fonctions du domaine unitaire, de la gestion du contrôle des fonctions des véhicules et de la gestion des services cloud.

02 Technologie d'abstraction de périphérique dans SOA

Avant d'analyser en détail la technologie de base du déploiement de l'architecture logicielle avec le contrôle de domaine central comme noyau, plusieurs concepts importants connexes doivent être expliqués en détail. Le modèle de conception capteur/actionneur dans Autosar décrit comment l'ECU gère les capteurs/actionneurs dans la boucle dans le contexte de l'architecture globale.

L'abstraction du périphérique BEG est située sur RTE (qui est un environnement de test). Il s'agit d'un ensemble de composants logiciels extraits de capteurs et d'actionneurs connectés à un calculateur spécifique. Il utilise des composants logiciels de capteurs ou d'actionneurs et se trouve au-dessus de RTE. seul composant autorisé à accéder à l’interface abstraite de l’ECU. L'abstraction de périphérique extrait les signaux bruts des capteurs et des actionneurs, tels que les pixels, les nuages ​​de points, les tensions, les signaux PWM, les signaux/messages numériques, les fréquences, et fournit des interfaces physiques (telles que les pixels, les nuages ​​de points, la pression, la masse, la température, etc. ). En fait, l'abstraction de l'appareil complète la conversion des valeurs physiques telles que les valeurs de tension, les signaux numériques, les nuages ​​de points, etc.

L'abstraction des appareils reflète l'interchangeabilité des logiciels de couche d'application entre différentes variantes matérielles via le logiciel de plate-forme et le logiciel pilote sous-jacent.

Tableau 1 Relation abstraite entre le logiciel de la plate-forme et l'appareil (capteur)

Superposition abstraite

Fonction

Principe de fonctionnement

Détails du travail

Logiciel de plate-forme

Entrez la valeur d'acquisition originale, la valeur de tension de sortie

Découplage du logiciel et de la connexion matérielle

Fournir les caractéristiques physiques de l'interface d'origine

Caractéristiques mécaniques, caractéristiques électriques, caractéristiques fonctionnelles et caractéristiques procédurales.

Pilote d'équipement électrique

Valeur de tension d'entrée, valeur de tension filtrée en sortie

Assurer la disponibilité des valeurs de mesure du capteur

Exécuter le logiciel de pilote d'équipement électrique pour le diagnostic électrique (tel que la détection masse, batterie) Court-circuit, circuit ouvert, etc.)

Filtre antibruit

Compensation de tension lorsque le capteur est alimenté en externe

Pilote de périphérique de capteur

Valeur de tension d'entrée, valeur de capteur de sortie telle que pixel, nuage de points, valeur de température

Découpler différents éléments de différence de capteur

Exécuter le pilote de périphérique de capteur

Contrôler le capteur Le comportement physique de la

·Fonction de filtrage (y compris le sous-échantillonnage)

Pilote de périphérique virtuel

Entrez la valeur de signification du capteur et sortez la valeur complète complétée, telle que la valeur de luminosité

Fin de compensation du signal du capteur découplé

Le pilote de périphérique virtuel du capteur résume sa représentation physique avec un logiciel

·Évaluation de la qualité du signal

·Remplacement de la valeur d'origine du signal (si la qualité du signal du capteur est insuffisante)

·Valeur d'origine du signal compensation

·Vérification de la valeur d'origine du signal

·Interface de diagnostic de test fonctionnel

Tableau 2 Relation abstraite entre le logiciel de la plate-forme et l'appareil (exécuteur)

Superposition abstraite	Fonction	Principe de fonctionnement	Détails du travail
Logiciel de plate-forme	Entrée PWM, valeur PWM de sortie Découplage de la connexion logicielle et matérielle	Fournir l'interface originale des propriétés physiques	Propriétés mécaniques, propriétés électriques, propriétés fonctionnelles et propriétés procédurales.
Pilote de périphérique électronique	Valeur de tension d'entrée, valeur de tension filtrée en sortie Assurer la validité du processus d'exécution de l'actionneur	Exécuter le logiciel de pilote de périphérique électrique pour le diagnostic électrique (tel que la détection de court-circuit à la terre et à la batterie), circuit ouvert, etc.)	Filtre antibruit Compensation de tension lorsque l'actionneur est alimenté de manière externe
Pilote de dispositif d'actionneur	PWM d'entrée, protection de sortie et valeur PWM correspondante découplage Exécution de processus mécaniques Protection de la capacité de l'actionneur découplé	Le pilote du dispositif de capteur représente le comportement physique de l'actionneur	·Superimposez la valeur de sortie pour surmonter la friction du pilote ·Sortez la valeur du signal d'exécution et garantissez que l'exécution est valide ·Limitez la sortie valeur pour éviter des dommages excessifs · Valeur de réglage de contrôle (coopérant avec la boucle fermée des données de détection) ·Une interface qui fournit des informations sur les limites et les capacités
Pilote de périphérique virtuel	Entrez la valeur et la sortie de la demande de l'actionneur Valeur PWM, telle que l'ouverture de la vanne Solution Couplage de la gigue de l'exécuteur, non-linéarisation, dépassement de limite d'exécution et autres traitements	Le programme d'exécution du dispositif virtuel résume la représentation physique de l'exécuteur	·Terminal de contrôle conversion de valeur de demande physique ·Conversion de valeur non linéaire pour les valeurs linéaires · Interface de testeur de diagnostic pour les tests fonctionnels · Gestion des modes spéciaux · Démarrage du fonctionnement de l'actionneur · Élimine la gigue de phase de l'actionneur en remplaçant les points de consigne ou en filtrant · Actionneurs coordonnés Activation sécurisée

En résumé, le concept abstrait et la conception du dispositif BEG peuvent être résumés comme suit :

Le logiciel d'application est indépendant des capteurs et actionneurs spécifiques connectés à un calculateur spécifique

Le code peut être réutilisé entre différents capteurs et actionneurs ;

Différents modèles de coopération de partage de code (partage de logiciels), prenant ainsi en charge différents modèles commerciaux ;

Déployer ou redistribuer des fonctions sur différents calculateurs ; Les interfaces de fonction et de service sont connectées vers le bas au logiciel de la plate-forme. L'objectif est d'exposer les interfaces autant que possible, de réaliser le découplage du logiciel et du matériel et d'éviter les modifications logicielles causées par les modifications S&A.

03

Exemple d'abstraction de périphérique dans SOA

Nous donnons ici un exemple pour illustrer comment implémenter l'abstraction de périphérique dans l'architecture SOA. Cette méthode n'a besoin que de connaître la catégorie de capteur (tel que radar, caméra, etc.) pour définir les données brutes d'entrée Rawdata. Il n'est pas nécessaire de connaître la méthode de connexion spécifique de ces capteurs. Pour la couche d'application supérieure, seulement la finale. les données de détection doivent être appliquées.

Prenons l'exemple de l'abstraction du capteur par l'appareil, qui peut être exprimée comme suit :

Tout d'abord, MCAL dans la couche physique sous-jacente collecte des données en accédant au port uC et fournit des données brutes, qui sont détectées à intervalles réguliers. Période (telle que 10 ms), il n'est pas nécessaire de comprendre la méthode de connexion des appareils électriques et la signification des données correspondantes. Par exemple, les données de pixels de l'image originale sont collectées à partir du capteur lidar sous-jacent et entrées dans le microcontrôleur MCU/SOC.

Deuxièmement, le MCU/SOC extrait la valeur du nuage de points correspondant de l'adresse physique correspondante selon une certaine période, la transmet au module d'abstraction matérielle d'E/S via le périphérique d'E/S et détecte le point de mesure des données mesurées. via le point abstrait du matériel d'E/S L'appareil électrique de premier niveau est connecté au routeur, et le capteur calcule la valeur de tension en fonction des informations de routage et des données brutes interprétées et effectue un traitement de filtrage. Ce processus ne nécessite pas de compréhension de la signification. des données mesurées.

Ensuite, la valeur de tension dans le module d'abstraction matérielle est traitée étape par étape selon le pilote 8 bits et est appelée par le pilote du périphérique électronique du capteur pour générer la valeur d'origine de base. Cette valeur pilote le dispositif virtuel Dri à travers le capteur du dispositif virtuel des piétons, des panneaux de signalisation, etc.

Enfin, le logiciel d'application d'AP Autosar lit les données au niveau cible du capteur en temps réel via l'environnement d'exécution en temps réel RTE, qui est utilisé pour le contrôle ultérieur de la planification et le contrôle décisionnel du logiciel d'application.

Comme le montre l'exemple ci-dessus, l'abstraction de l'appareil présente les avantages suivants. Les modifications apportées au capteur et à l'actionneur n'entraîneront pas de modifications associées au logiciel de plate-forme et au logiciel d'application. En résumé, les types de découplage logiciel et matériel suivants sont provoqués. par des transformations.

Pour remplacer différents modèles de capteurs de détection, la sélection de l'ECU n'est plus limitée au modèle de mode d'analyse du signal pris en charge par l'ECU. Par exemple, pour remplacer les modèles NTC et PTC, il vous suffit de modifier le module logiciel situé dans le pilote de périphérique.

Les modules de capteurs et d'actionneurs du même type peuvent partager certains des mêmes modules de traitement. Par exemple, pour le mode de traitement de la caméra à vue latérale, l'algorithme de traitement de l'une des caméras à vue latérale peut être directement appliqué à la caméra à vue latérale. trois autres, et il suffit de recalibrer les paramètres de caméra des trois caméras. Si certaines caméras doivent être mises à niveau vers des caméras de résolution plus élevée, il n'est pas nécessaire d'apporter des modifications majeures au logiciel pilote sous-jacent et au logiciel de plate-forme, au moins l'I/. O interface. Il n'est pas nécessaire de changer le formulaire ou le mode de saisie des données, mais le module d'algorithme de traitement des images doit être réajusté. Par exemple, l'algorithme de traitement basse résolution d'origine peut ne pas être en mesure de répondre au temps réel. Exigences du module de traitement haute résolution. Dans ce cas, il est nécessaire d'étudier la méthode d'optimisation du modèle d'accélération du réseau neuronal, mais le modèle global d'architecture de l'algorithme reste inchangé.

04 Résumé

Actuellement, la méthode de développement préconisée par de nombreux OEM est le développement de produits basé sur une plate-forme, et la plateforme met l'accent sur l'idée fondamentale du découplage logiciel et matériel. L'adoption du modèle d'architecture SOA facilite la formation de lignes de produits et de plates-formes. lignes. Dans la division du travail, la ligne de produits est responsable de projets de modèles de véhicules spécifiques et la ligne de plate-forme est responsable de la construction d'un centre technique. Dans le développement de nouvelles plates-formes, les liens techniques sont souvent très longs et complexes. La conception de l'architecture en couches et la méthode de découplage logiciel et matériel peuvent faciliter les tests et la vérification en couches, réduire la pression des tests d'intégration et découvrir plus complètement les problèmes. augmenter la vitesse de publication des versions.

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!