Die vorherige AUTOSAR-Architektur (Bild 3) war hauptsichtlich eine geschichtete Architektur für tief eingebettete Systeme, also für Systeme mit begrenzten Hardware-Ressourcen. Dort werden Programme ausschließlich aus dem eigenen Speicher unter statischer Konfiguration ausgeführt, die Kommunikation nutzt etablierte Fahrzeug-Bussysteme wie CAN, LIN, FlexRay und neuerdings auch das Ethernet. Es wurde im Grunde nicht für Steuergeräte ausgelegt, die nach der SOP-Phase eine regelmäßige Aktualisierung benötigen - etwa wegen kritischer Sicherheits-Patches oder um Fahrzeugfunktionen ergonomischer zu gestalten.
Die Auslegung erfüllte auch einen ökonomischen Zweck. Mit der Entkopplung von Softwarekomponenten, die ausschließlich Fahrzeugfunktionen handhaben, konnten Automobilerhersteller Anwendungen effizient zwischen den ECUs portieren. Die Festlegung von Standardschnittstellen zwischen der Funktionssoftware und der low-level Software sparte Aufwand und Kosten in der Neukonfiguration und dem Test.
Die Designprinzipien adressierten jedoch Konzepte und Funktionen des Fahrzeugbaus aus den 90er Jahren bis hin zur Jahrtausendwende. Für den akuten Wandel unter den sozioökonomischen Triebkräften sind diese Konzepte jedoch nur bedingt geeignet.
Ein Kernthema ist etwa das hochautonome Fahren, in dem das Fahrzeugsystem, energieeffizient und dauerhaft mit der Straßeninfrastruktur oder einer Cloud kommunizieren soll. Auch soll die Softwareentwicklung einen Mehrwert im Fahrzeugbau schaffen und den Fahrzeugwert über den Produktionstag hinweg steigern.
Klassisches AUTOSAR, das hauptsächlich von einigen Softwarelieferanten der Steuergeräte konzipiert wurde (OEMs und die Tier2-Lieferanten), war dafür ungeeinigt. Da es keine standardisierte Middleware-Schnittstelle hat, auf die Entwickler für High-Level- oder FrondEnd-Anwendungen zugreifen können, erzeugt die bloße Softwareentwicklung darauf, keinen wirtschaftlichen Mehrwert nach dem Produktionstag (SOP). Es geht eben um diese Middelware, die als Software-as-a-Service-Bereitstellungsmodell (SaaS) betrachtet werden kann.
Diese angestrebten neuen Funktionen erfordern eine hohe Rechenleistung, intensives Off- und On-Board-Datenstreaming und eine Fahrzeugarchitektur, die OTA-Updates (Over-the-Air) unterstützt. Der Einsatz von Ethernet als interner Kommunikationsbus und die Verfügbarkeit von Vielkern-Prozessoren zu wettbewerbsfähigen Preisen in der Automobilindustrie, bilden die technologische Basis zur Umsetzung solcher Geschäftsfälle. Adaptive AUTOSAR soll alle jene Funktionen unterstützen, welche die weltweite Automobilindustrie grundlegend wandeln. Die jeweiligen technischen Ziele sind sowohl im klassischen als auch im adaptiven Fall am besten an den Hauptanforderungen der Fundamentalspezifikation abzulesen (AUTORSAR_RS_Main).
Die adaptive Plattform (AP) befasst sich mit der Unterstützung von hoch-performanten Recheneinheiten, einer modularen Bereitstellung und Neuzuweisung von Software, der Unterstützung für eine serviceorientierte standortunabhängige Kommunikation, Kompatibilität für unterschiedliche Programmiersprachen und der Möglichkeit, Kommunikationswege und Anwendungssoftware zur Laufzeit zu ändern. Darüber hinaus soll die Interoperabilität mit dem klassischen AUTOSAR erhalten bleiben.