Comprendre l'autosar et son architecture

AUTOSAR (Automotive Open System Architecture) peut être défini comme une plate-forme commune pour l'ensemble de l'industrie automobile, conçue pour améliorer le champ d'application des fonctionnalités du véhicule sans affecter le modèle d'exploitation actuel. AUTOSAR est essentiellement une architecture logicielle ouverte et standard qui a été développée conjointement par des constructeurs automobiles, des fournisseurs et des développeurs d'outils. Dans cet article, nous allons apprendre ce qu'est AUTOSAR et les différentes couches de son architecture.

La devise principale d'AUTOSAR est «Coopérer sur les normes, rivaliser sur la mise en œuvre». Cette architecture unique a été développée afin d'établir et de maintenir une norme commune parmi les fabricants, les fournisseurs de logiciels et les développeurs d'outils afin que le résultat du processus puisse être livré sans aucune modification.

AUTOSAR - Comment tout a commencé?

En 2003, le partenariat AUTOSAR a été formé comme une alliance de fabricants OEM (Original Equipment Manufacturer), de fournisseurs automobiles Tyre 1, de fabricants de semi-conducteurs, de fournisseurs de logiciels, de fournisseurs d'outils et autres. Ils ont établi AUTOSAR en tant que norme industrielle ouverte pour l'architecture logicielle automobile en tenant compte des différentes architectures E / E automobiles présentes et qui se lient et se formeraient à l'avenir.

Les 10 principaux partenaires d'AUTOSAR sont BMW Group, Bosch, Continental, DaimlerChrysler, Ford Motor Company, General Motors, PSA Peugeot Citroen, SiemensVDO, Toyota Motor Corporation et Volkswagen.

Importance d'AUTOSAR

L'infrastructure d'AUTOSAR n'est pas simple, mais pourquoi est-il nécessaire d'introduire une infrastructure aussi complexe dans l'industrie automobile? Premièrement Pourquoi avons-nous besoin d'AUTOSAR?

À mesure que la demande de véhicules intelligents, plus sûrs et plus intelligents augmentera, la concurrence dans l'industrie automobile augmentera également. Toutes ces fonctionnalités de renseignement et de véhicule ne peuvent pas être mises en œuvre par une seule autorité.

Par exemple, une voiture a des airbags, un système GPS, une intégration intelligente, etc. Toutes ces fonctionnalités sont implémentées sur les différents ECU (unités de contrôle électronique) par différentes industries automobiles, de sorte que toutes les différentes unités automobiles devraient pouvoir travailler main dans la main pour obtenez la sortie souhaitée.

Cela aide également dans le processus de développement logiciel, car jusqu'à une époque récente, le logiciel développé pour les industries automobiles était uniquement axé sur la fourniture des fonctionnalités du système et ils ne se souciaient jamais des effets qu'il peut fournir au système. Cela s'est compliqué en raison de nombreuses fonctionnalités sur divers calculateurs sur différents réseaux de véhicules. C'est devenu un problème plus critique avec l'augmentation des procédures de développement non standard. Par conséquent, ils ont développé l'AUTOSAR.

Différentes couches d'architecture AUTOSAR

Si vous regardez dans l'image ci-dessus, vous pouvez identifier que l'architecture de l'AUTOSAR est composée de trois couches principales qui sont

• Couche d'application
• Environnement d'exécution (RTE)
• Logiciel de base (BSW)

Chacune de ces couches a son propre objectif et a une opération spécifique à effectuer

Couche d'application

La couche d'application AUTOSAR se compose de diverses applications et de composants logiciels spécifiques conçus pour effectuer une tâche spécifique conformément aux instructions données. La couche application est la couche la plus élevée de l'architecture logicielle d'AUTOSAR, c'est pourquoi elle est essentielle pour toutes les applications du véhicule. La couche d'application comprend trois des composants les plus importants qui doivent être pris en considération. Ce sont des composants logiciels d'application, des ports de ces composants et des interfaces de port.

Les composants logiciels assurent la fonctionnalité du sous-système, ce qui implique les opérations et les éléments de données dont le logiciel a besoin et les ressources nécessaires aux composants. Et la source de l'application est indépendante de l'emplacement des composants interactifs, du type d'ECU sur lesquels le composant est mappé et du nombre de fois où le composant est instancié dans un système.

Couche d'environnement d'exécution (RTE)

La couche d'environnement d'exécution crée un environnement approprié pour le fonctionnement des composants logiciels (SWC). Le SWC dépend toujours de l'interface fournie par le RTE.

Il peut être considéré comme le centre de communication entre les calculateurs qui se trouvent dans le réseau. Il aide les composants logiciels à fonctionner indépendamment des mécanismes et des canaux de communication. Le RTE rend cela possible en mappant les relations de communication entre les composants qui sont implémentés dans les différents modèles, à un mécanisme de communication Intra spécifique comme l'appel ou à un mécanisme de communication inter ECU comme un message COM.

RTE a la responsabilité de gérer le cycle de vie du SWC, il doit démarrer et arrêter les fonctions en fonction des besoins. Il agit également comme une couche de séparation entre le logiciel d'application (ASW) et le logiciel de base (BSW) où le logiciel de base avait la permission d'appeler directement n'importe quelle fonction API ou d'autres modules, mais le logiciel d'application ne peut communiquer que via les ports.

Le RTE est généré en deux phases

• Phase de contrat: Cette phase est indépendante de l'ECU et fournit le contrat entre le logiciel d'application et le RTE, c'est-à-dire que l'API des composants ASW peut être codée.

Cela a abouti à un en-tête spécifié par le composant ASW que nous pouvons inclure dans le code source. Le fichier d'en-tête comprend toutes les fonctions de l'API RTE qui peuvent être utilisées dans l'ASW et les types de données et structures nécessaires aux composants ASW sont également déclarés dans le fichier d'en-tête.

• Phase de génération: Cette phase se concentrera sur la génération du code concret pour un ECU donné. Avec les composants ASW et les fichiers d'en-tête créés dans la phase de contrat et tout le code BSW nécessaire, le code généré peut être compilé dans un fichier exécutable pour l'ECU.

Logiciel de base (BSW)

La couche de logiciel de base peut être définie comme le logiciel standardisé qui peut fournir des services aux composants logiciels AUTOSAR et elle est également utilisée pour exécuter la partie fonctionnelle du logiciel. Le logiciel de base comprend les composants normalisés et spécifiés par l'ECU.

La couche de logiciel de base est divisée en 4 parties principales à savoir la couche de services, la couche d'abstraction d'ECU, la couche d'abstraction de microcontrôleur et les pilotes complexes.

I. Couche de service

C'est la couche la plus élevée de la couche logicielle de base, elle fournit les modules logiciels de base au logiciel d'application et elle est indépendante du microcontrôleur et du matériel de l' ECU.

La couche de service fournit des fonctions telles que

• Services de mémoire (gestion NVRAM)
• Services de diagnostic (y compris UDS communication et mémoire d'erreurs)
• Communications et gestion du réseau de véhicules
• Gestion de l'état de l'ECU
• Système d'exploitation (OS)

Le montage de cette couche est spécialisé pour le micro-contrôleur (MCU), les parties du matériel ECU et leurs applications.

II. Couche d'abstraction ECU

Cette couche agit comme une interface de la couche d'abstraction du microcontrôleur qui contient également certains pilotes de périphériques externes. Il a accès aux périphériques et aux appareils peu importe où ils se trouvent à l'intérieur ou à l'extérieur du microcontrôleur. Il offre également l'API pour s'interfacer avec le microcontrôleur.

III. Couche d'abstraction du microcontrôleur (MCAL)

La couche microcontrôleur est la voie d'accès pour communiquer avec le matériel. Cette couche a été encadrée afin d'éviter l'accès direct aux registres du microcontrôleur. Le microcontrôleur Abstraction Layer (MCAL) est une couche matérielle conçue pour assurer l'interface standard avec les composants du logiciel de base. Il fournit des valeurs indépendantes du micro-contrôleur pour les composants du logiciel de base et gère également les périphériques du micro-contrôleur.

Le MCAL est doté d'un mécanisme de notification afin qu'il puisse prendre en charge la distribution de commandes, de réponses et d'informations à différents processus. En dehors de cela, le MCAL peut inclure certaines des fonctions et des dispositifs tels que les E / S numériques (DIO), le convertisseur analogique / numérique (ADC), le modulateur de largeur d'impulsion (PWM, PWD), EEPROM (EEP), Flash (FLS), Capture Compare Uni (CCU), Watchdog Timer (WDT), Serial Peripheral Interface (SPI), Bus I2C.

IV. Pilote de périphérique complexe (CDD)

Cette couche a une synchronisation et des exigences fonctionnelles spéciales pour traiter des capteurs et des actionneurs complexes. Le CDD est utilisé pour gérer des fonctions complexes, il ne peut être trouvé dans aucune autre couche et il a la capacité d'accéder directement au microcontrôleur. Les fonctions complexes comprennent le contrôle d'injection, le contrôle des valeurs électriques, la détection d'augmentation de position, etc.

Objectifs d'AUTOSAR

AUTOSAR a été créé pour certaines raisons qui sont utiles pour le présent et qui seront également utiles à l'avenir, certains des objectifs sont énumérés ci-dessous.

• Implémentation et standardisation des fonctions de base en tant que solution «standard core» à l'échelle de l'industrie.
• Intégrations de modules fonctionnels de différents fournisseurs.
• Facile à entretenir le processus tout au long du cycle de vie.
• La possibilité de mettre à l'échelle différents véhicules indépendamment de la plate-forme.
• Activation de la redondance.
• Prise en compte des exigences de disponibilité et de sécurité.
• Transfert facile des fonctions d'un ECU à un autre ECU au sein du réseau.
• Utiliser davantage de matériel commercial standard (COTS).
• Mises à jour et mises à niveau logicielles régulières pendant toute la durée de vie du véhicule.

Avantages d'AUTOSAR

AUTOSAR sert différents avantages à différentes étapes du cycle de vie du véhicule

OEM: avec AUROSAR, vous pouvez utiliser le même code logiciel encore et encore pour différents OEM. Il est plus flexible pour s'adapter à différentes conceptions et réduit également le temps et le coût de production.

Fournisseurs: les fournisseurs peuvent accroître leur efficacité de développement fonctionnel et créer leur propre modèle d'entreprise qui leur convient.

Fournisseur d'outils: AUTOSAR a une interface commune qui aide le fournisseur d'outils à standardiser son processus de développement.

Nouvel entrant sur le marché: pour les nouveaux entrants, AUTOSAR agit comme une interface transparente et définie qui peut les aider à comprendre les normes de l'industrie et à créer leurs propres modèles commerciaux.

À quoi pouvez-vous vous attendre avec AUTOSAR?

AUTOSAR est conçu pour servir à diverses fins à divers départements de l'industrie automobile. Comme il est polyvalent et flexible, vous pouvez faire beaucoup de choses en dehors de cela, certains des résultats de base que l'AUTOSAR peut vous donner sont la possibilité de réutiliser le logiciel qu'il contient pour plusieurs unités et le logiciel utilisé peut être échangé à tout moment. nécessaire, AUTOSAR agit comme une plate-forme standard pour tous les logiciels du véhicule et n'a pas d'application propre.

Il dispose d'un OS avec des fonctions de base et des logiciels d'interface et le principal avantage est que la même interface peut être utilisée dans tous les logiciels de base. Les fonctionnalités d'AUTOSAR sont fournies sous forme de composants logiciels et tous les composants impliqués sont indépendants du matériel.