- Innovation créatrice de nouvelles compétences
- Non
- Innovation génératrice de nouvelles activités
- Non
- Phase de développement de l'innovation
- Commercialisé depuis plusieurs années
- Date de création
- Date de mise à jour
En bref
Ces dix dernières années, l'informatique embarquée n'a cessé de se développer dans l'industrie automobile. Des programmes-cartographies-logiciels commandent un grand nombre de fonctions faisant appel à des réseaux multiplexés liés.
L'interaction de ces fonctions engendre une complexité croissante et requiert un environnement logiciel contrôlé et standardisé. La rapidité de développement d'applications automobiles et l'intégration grandissante de fonctions et d'unités de contrôle constituent un nouvel enjeu pour les constructeurs automobiles et les équipementiers.
La standardisation des logiciels de base des ECU et des interfaces fonctionnelles est devenue incontournable afin de gérer au mieux la complexité grandissante au niveau système, de maîtriser les coûts et de garantir l'évolutivité des architectures logicielles.
- Innovation créatrice de nouvelles compétences
- Non
- Innovation génératrice de nouvelles activités
- Non
- Phase de développement de l'innovation
- Commercialisé depuis plusieurs années
- Date de création
- Date de mise à jour
Description détaillée
AUTOSAR (AUTomotive Open System Architecture) est une association internationale de développement regroupant des constructeurs automobiles, des équipementiers et des sociétés spécialisées dans l'électronique et l'informatique, créée en 2003 dans le but de développer et d'établir une architecture logicielle standardisée et ouverte pour les véhicules.
Ce groupe permet de simplifier les échanges et la mise à jour des logiciels et matériels. L'objectif d'AUTOSAR est de garantir une maîtrise de la complexité croissante des systèmes électriques et électroniques des véhicules et de gagner en rentabilité sans compromis sur la qualité. Il s'agit donc de définir une architecture logicielle ouverte normalisée destinée aux unités de contrôle électronique (ECU) dans l'automobile. La devise d'AUTOSAR est « coopération sur les standards, concurrence sur la mise en œuvre ».
L'architecture logicielle en couches d'AUTOSAR facilite l'utilisation de composants logiciels indépendants. Ces derniers peuvent être mis en œuvre dans les véhicules de différents constructeurs et dans les composants électroniques de divers équipementiers, et recouvrir plusieurs générations de produits.
Les partenaires centraux d'AUTOSAR sont le groupe BMW, Bosch, Continental, Daimler AG, Ford, General Motors, PSA Peugeot Citroën, Toyota et le groupe Volkswagen. À ces entreprises s'ajoutent plus de 170 membres qui participent activement à ce partenariat. Toute entreprise rejoignant le consortium peut utiliser gracieusement les spécifications AUTOSAR.
Le consortium collabore aussi avec d'autres organismes de normalisation comme GENIVI, Car-to-X et Ethernet afin de fournir un socle qui prenne en charge de nombreux standards.
L'historique simplifié :
En mai 2006, à l'issue de la phase I, AUTOSAR a publié le premier volet des spécifications de la version 2.0. Il intégrait 42 des 46 composants logiciels de base achevés. Cette version comporte plus de 90 documents.
À partir de la version 2.1, courant 2006, et des versions 3.0/3.1, la majorité des partenaires ont pu commencer à déployer AUTOSAR.
Les versions principales :
3.0 : entre le 21.12.2007 et 30 sept 2010 version finale (1.6.0)
3.1 : entre le 13.08.2008 et 30 sept 2010 version finale (1.4.0)
3.2 : entre 13.05.2011 et 28.02.2014 version finale (1.2.0)
4.1 : entre 18.02.2009 et 19.01.2012 version finale (1.2.1)
4.2 : version initiale : 4.2.1 le 31.10.2014
4.3 : version 4.3.0 en octobre 2016
Mise en œuvre concrète :
De nombreux véhicules intégrant des ECU conformes à AUTOSAR sont déjà en circulation, étant donné la disponibilité d'un nombre grandissant de produits AUTOSAR depuis 2006-2007.
Tout cet ensemble d'avancées dans le partenariat de développement lors de la phase II en 2009 a permis d'asseoir le développement initial du standard.
Mais c'est au cours de la phase III (2010-2012) qu'AUTOSAR s'était fixé une double tâche : d'une part, l'amélioration sélective des versions 3.x et 4.0 afin de garantir une architecture et une méthodologie fiables et évolutives ; de l'autre, la maintenance des versions en cours utilisées pour les projets en développement ou en production série : ceci permettait d'asseoir le rôle important de la mise en œuvre du standard.
C'est donc au cours de cette phase III qu'AUTOSAR a réalisé sa percée et rencontré un succès croissant. À partir de ce moment, le terme de « phase » a disparu : ce sont désormais les « versions » qui évoluent selon les avancées et les besoins.
À titre d'information, la version avancée 4.0.3 comporte 176 documents contre les 90 de la version 2.0 !
Les versions évoluées sont également rétrocompatibles avec certaines versions antérieures.
Depuis décembre 2016, il y a 191 partenaires impliqués à différents stades.
Pour exemple, parmi les fonctionnalités de la version AUTOSAR 4.2.1 figurent :
· La sérialisation entre émetteur et récepteur. Cette nouvelle fonction permet la transformation automatisée de structures de données volumineuses complexes dans un flux d'octets côté émetteur et la transformation inverse correspondante côté récepteur. Ce mécanisme fonctionne avec la communication sender/receiver ou client/serveur et est applicable à la fois entre des calculateurs ou entre des microcontrôleurs au sein d'un même calculateur. Cette nouvelle fonctionnalité limite l'effort de configuration tout en optimisant les performances et en permettant si nécessaire la sécurisation des transferts de données à l'aide d'une somme de contrôle (checksum).
· La synchronisation d'horloges pour les dispositifs de commande du réseau multiplexé, qui permet l'authentification d'une communication et l'extension des interfaces CAN existantes pour la prise en charge des communications à débit variable (CAN FD).
· La sûreté de fonctionnement fait l'objet d'une extension de la protection de bout en bout, ainsi que sa prise en charge dans la méthodologie et les formats d'échange.
· L'intégration de systèmes GENIVI via le protocole SOME/IP et la conversion des descriptions de composants AUTOSAR vers le langage Franca-IDL de GENIVI.
En résumé : la modularité, le dimensionnement, et la ré-utilisation comme structure de base pour le développement d'applications logicielles embarquées.
Le concept peut être schématisé grâce aux visuels suivants :
Méthodologie générique :
source : autosar
Approche basique :
source: autosar
Composants:
source: autosar
· RTE : RunTime Environnement, c'est l'environnement logiciel qui va implémenter les fonctions du VFB pour un ECU spécifique. Mais cette tâche peut être autant que possible déléguée au logiciel de base (BSW).
· VFB : Virtual Fonctional Bus, c'est l'ensemble des mécanismes de communication et des interfaces essentielles, indépendamment de la technologie utilisée. Cela permet de réaliser les intégrations virtuelles lors des développements des produits.
· BSW : Basic SoftWare, c'est un logiciel de base qui réalise une fonctionnalité de l'ECU.
· SW-C : AUTOSAR SoftWare Component. Il encapsule une application qui fonctionne sur l'infrastructure informatique AUTOSAR. Les composants logiciels AUTOSAR ont des interfaces aux contours précis et un format d'échange défini également par AUTOSAR.
| Diffusion sur le marché | Depuis 2006, les équipementiers, constructeurs, peuvent s'appuyer sur cette standardisation dans le développement des calculateurs. |
|---|---|
| Constructeurs concernés | Les partenaires "coeur" sont BMW, Bosch, VAG, Toyota, PSA, GM, Ford, Daimler, Continental. On a ensuite des partenaires "premium", Nissan, Renault, Autoliv, Honda, Tata, Valeo, Volvo, Hyundai, Hella, Fiat, Chrysler, Delphi, Denso, etc. |
| Innovation engendrant des entretiens | Non |
| Innovation engendrant des réparations | Non |
| Dispositif législatif en rapport avec l'innovation | Activité qui n'est pas encadrée par un dispositif législatif. |
| Contrôle technique | L'architecture logicielle AUTOSAR, n'entre pas dans le champ d'application du contrôle technique VL. |
| Mots-clés | standard, protocole, ingénierie, fabrication, conception |
Méthodes et pratiques
-
| Métiers concernés | Mécanicien technicien VI-VU, Mécanicien-Technicien Auto |
|---|
Impact sur les compétences en atelier
-
À lire aussi dans la même section
Le Protocole SENT
C’est un protocole de communication unifilaire utilisé pour transmettre des informations de capteur(s) vers un calculateur de gestion.
Utilisé principalement sur les systèmes d’injection et de...
Capteur de roue bidirectionnel ou "signé"
De nombreux capteurs permettent d'assurer la gestion de l'électronique de sécurité active pour réaliser des fonctions comme l'ESP, l'antipatinage, l'aide au démarrage en côte, etc.
Un de ces capteurs...
Near Field Communication (NFC)
Le Near Field Communication ou NFC pour "communication à champ proche" permet la mise en relation sans fil d'équipements électroniques.
La communication est sécurisée et ne peut se réaliser que sur...
Les batteries GEL, AGM et EFB
Dans les offres commerciales, les véhicules équipés de "stop and start" sont souvent appelés "micro-hybride" afin de se raccrocher à une image de développement durable.
Ce segment est le plus actif...