AUTOSAR, l’architecture

Suite de la visite d’AUTOSAR

Si vous n’avez pas lu le post précédent, je vous encourage à le faire ;)

Nous avons vu précédemment l’historique et le concept d’AUTOSAR. Aujourd’hui, creusons les détails de l’architecture proposée.

Selon cette norme, la structure du code est séparée en 5 catégories :

• Microcontroller Abstraction Layer fournit les interfaces bas niveau pour communiquer avec le microcontrôleur choisi (piloter une IO, lire un channel ADC, configurer un transceiver…)

• ECU Abstraction Layer fournit les configurations propres à l’ECU (Com stack, Mem stack…)

• Services Layer fournit des services génériques (Crypto, OS…)

• Runtime Environnment est l’endroit où la magie opère. Il met en relation les différentes applications logicielles et les abstractions précédentes.

• L’Application Layer est, comme son nom l’indique, l’endroit idéal pour le développement des applications haut-niveau. Elles s’appuient sur le Runtime Environment pour lire et écrire des données.

Une dernière catégorie, inclassable, car trop spécifique, permet le développement de composants non standardisés par AUTOSAR : Les Complex Drivers.

Certains sont liés au microcontrôleur utilisé (DMA, SpecialTimer…) d’autres sont liés à l’ECU (capteur de pression, driver de pont en H…)

Pour reprendre les points du dernier post,

• les fondeurs développent les outils de Microcontroller Abstraction Layer et certains complex drivers

• les équipementiers fournissent l’ECU Abstraction Layer, le Service Layer, le Runtime Environment et certaines Applications

• les constructeurs peuvent fournir des services spécifiques, mais aussi des applications à intégrer

Le tout, savamment orchestré grâce aux spécifications AUTOSAR 🙂

La prochaine fois, nous mettrons l’inter-opérabilité en pratique avec la virtualisation 😉