Immer mehr Einfluss auf die Architektur serieller Bussysteme im Kfz übt die von der AUTOSAR-Partnerschaft (Automotive Open System Architecture) entwickelte offene Software-Architektur für elektronische Steuergeräte im Kfz aus (siehe Grafik AUTOSAR-Architektur). Der Grund liegt darin, dass die AUTOSAR-Architektur u. a. auch den Datenaustausch mittels CAN, LIN und FlexRay aufgreift und vereinheitlicht.

Charakteristisch für einen Busknoten ist die Wahrnehmung kommunikationsspezifischer Funktionen wie beispielsweise das Senden und Empfangen von Daten. Zu Beginn der Steuergerätevernetzung genügten dafür eine physikalische Busankopplung und ein einfacher Software-Treiber, der eine einfache, hardwareunabhängige Schnittstelle für die Applikation bereitstellte. Jedoch kam man mit steigenden Anforderungen an ein Automobil immer weniger ohne weitere kommunikationsspezifische Funktionen wie z.B. Netzwerkmanagement und Diagnose aus.

Wurden diese Funktionen anfangs noch als Teil der Anwendungssoftware implementiert, so gingen OEM (Original Equipment Manufacturer) bald dazu über, sämtliche Kommunikationsfunktionen auf separate standardisierte und wieder verwendbare Softwaremodule auszulagern, um die Integration der Busknoten auf Systemebene zu erleichtern und so die Entwicklungszeit zu reduzieren. Viele OEM orientierten sich dabei an ISO- (International Organization for Standardization) und OSEK- (Offene Systeme und deren Schnittstellen für die Elektronik in Kraftfahrzeugen) Standards (siehe Grafik ISO/OSEK-Architektur).

Die rasche Zunahme elektronischer Fahrzeugfunktionen ebnete den Weg für die herstellerübergreifende AUTOSAR-Architektur für elektronische Steuergeräte im Kfz. Sie standardisiert nicht nur die Basisfunktionalitäten, sondern auch die Schnittstellen sämtlicher Anwendungssoftwarekomponenten. Die Inanspruchnahme der Dienste der Basis-Software durch die Anwendungssoftwarekomponenten ausschließlich über die AUTOSAR-RTE (Run Time Environment) führt zur kompletten Abstrahierung der Anwendung von der gesamten Busknoteninfrastruktur und ermöglicht so die Wiederverwendbarkeit bzw. Portierbarkeit sämtlicher Anwendungssoftwarekomponenten.

Der Übergang zur AUTOSAR-Architektur beeinflusst die Architektur serieller Bussysteme im Kfz in besonderem Maße, da sie sämtliche für den Datenaustausch nötigen Funktionen vereinheitlicht. Die zweite Grafik zur AUTOSAR-Architektur zeigt den für den Datenaustausch relevanten Teil der AUTOSAR-Architektur. Kern dieses Teils stellen die drei identisch aufgebauten sog. „Kommunikationsstacks“ CAN, LIN und FlexRay dar.

Der Zugriff auf diese Kommunikationsstacks erfolgt mittels der übergeordneten Komponente COM (Communication). Die Komponente COM passt die von der Anwendung empfangenen Daten auf den jeweiligen Kommunikationsstack an, so dass die Anwendungsentwicklung vollkommen unabhängig von der jeweiligen seriellen Kommunikationstechnologie erfolgen kann.

Jeder Kommunikationsstack umfasst die Komponenten „TP (Transport)“, „SM (State Management)“ und „IF (Interface)“. Die Komponente „NM (Netzmanagement)“ kommt nur in den Kommunikationsstacks CAN und FlexRay zum Einsatz. Die Komponente TP dient zur Übertragung größerer Datenblöcke und sorgt für die entsprechende Segmentierung, Sequenzierung und Assemblierung. Die Komponente NM dient dazu, ein Netzwerk schlafenzulegen bzw. aufzuwecken. Im Kommunikationsstack LIN fehlt diese Komponente. Übernommen wird das Schlafenlegen und Wecken vom LIN Interface.

Die Aufgaben des State Managements hängen von den jeweiligen Kommunikationsstacks ab. Der CAN State Manager nimmt u. a. die busspezifische Fehlerbehandlung wahr. Der FlexRay State Manager steuert und überwacht die Synchronisation des Busknotens. Der LIN State Manager schaltet u. a. die Schedule um. Die jeweiligen Interface-Komponenten stellen eine Reihe hardwareunabhängiger Zugriffsfunktionen bereit. Am unteren Ende der Kommunikationsstacks sind die Software-Treiber DRV (Driver) angesiedelt. Sie übernehmen die Hardwareinitialisierung, das Senden und Empfangen.