Software-Defined Vehicle & AUTOSAR

Software-defined vehicle and AUTOSAR — the Classic and Adaptive platforms, methodology, and integration practice, taught from ETS core material.

Private cohorts & on-site
Format: 2-day (8:30 a.m.–4:30 p.m.)
Level: Intermediate
Location: Scheduled on demand · on-site at your facility or a regional venue
Date(s): Not yet scheduled for open enrollment. Get notified when it is, or book it privately for your team.
Includes: Certificate of Completion · printed slide binder · take-home reference text

Get notified when this course is scheduled

One email when dates are set. Or skip the wait: run it as a private cohort, on-site at your plant.

Talk to us about a private cohort
  • One email, no sequence
  • Never shared
  • Reply within one business day

Faculty

Faculty details for this seminar will be announced with the full schedule.

Fees

Early: $1,895 (payment 4+ weeks ahead)
Standard: $2,095 (check/ACH) · $2,165 (card)

Group discount: $200 off per attendee for 3+ from the same organization.

Also Available

  • Corporate on-site delivery at your facility
  • Private cohort sessions
  • Digital curriculum licensing

Seminar Overview

This seminar is taught from the AUTOSAR specifications themselves — the corpus holds the actual AUTOSAR Adaptive Platform specification, AUTOSAR Classic Platform specification, and AUTOSAR Foundation specification documents (terms-of-use-prefaced PDFs), and the course works from their real structure: the platform's layered architecture, its module specifications, its methodology and templates. Most SDV training is built from consultant summaries of these documents. This course opens the documents.

The software-defined vehicle transition is the largest architecture shift in the industry since the move to CAN — and its cost is paid by organizations that adopt AUTOSAR vocabulary without understanding the platform's actual structure. Teams confuse Classic and Adaptive platform responsibilities, choose communication stacks (SOME/IP vs. DDS) without understanding the service-oriented model underneath, bolt OTA concepts onto diagnostics architectures that were never designed for them, and discover late that the AUTOSAR Methodology's artifact flow does not match their tooling. These are spec-reading failures, and they are fixed by spec-reading discipline.

After two days you will be able to navigate the Classic and Adaptive specifications efficiently, map a real E/E architecture onto the layered AUTOSAR model, choose between Classic and Adaptive (or a hybrid) with defensible criteria, design a service-oriented communication architecture using SOME/IP and DDS as specified, position UDS diagnostics and OTA update mechanisms correctly within the architecture, apply the AUTOSAR Methodology to your tool chain, and connect the architecture to ISO 26262 functional-safety obligations — citing the specification sections behind each decision.

Ideal Learner

  • Embedded software and systems architects at automotive OEMs and Tier 1 suppliers
  • Software engineers migrating from Classic ECU development to service-oriented architectures
  • Functional safety engineers who need AUTOSAR fluency for ISO 26262 work products
  • E/E architecture and systems engineers defining next-generation vehicle platforms
  • Technical leads and managers evaluating SDV platform and tooling decisions

Learning Objectives

  • Navigate the AUTOSAR Classic, Adaptive, and Foundation specification families and locate governing sections efficiently
  • Map an E/E architecture onto the AUTOSAR layered model (application, RTE/runtime, services, MCAL/OS abstraction)
  • Decide between Classic Platform, Adaptive Platform, and hybrid deployment with documented criteria
  • Design service-oriented communication using SOME/IP and DDS per the specification's service model
  • Position UDS diagnostics and OTA update mechanisms correctly within a vehicle API and update architecture
  • Apply the AUTOSAR Methodology to a tool chain and connect architecture artifacts to ISO 26262 safety work products

Consulting Sessions

Seminar attendees can sign up for individual consulting sessions with the instructor. Sessions are free for registered attendees, first-come first-served — sign up when registering by calling 248-539-0473 or during the seminar.

Seminar Outline

  • From federated ECUs to zonal/central compute: what changes for software organization
  • Hardware-software decoupling, vehicle APIs, and the app-store economics driving OEM decisions
  • The SDV feature lifecycle: feature flags, deployment units, and post-SOP updates
  • **Case History: a program that adopted SDV vocabulary without the architecture — and paid in integration**
  • The three specification families: Foundation, Classic Platform, Adaptive Platform — and how they interlock
  • Classic Platform layers: Application Layer, RTE, Services Layer (with functional clusters), ECU Abstraction, MCAL
  • The Virtual Functional Bus concept and what port/interface abstraction actually buys
  • Configuration and code generation: how ECU software becomes configured from templates
  • **Exercise 1: map a real ECU's software onto the Classic layered model, cluster by cluster**
  • Adaptive Platform architecture: the ara:: runtime, Functional Clusters, and Execution Management
  • Dynamic service deployment, application manifests, and the POSIX-based operating environment
  • Decision criteria: deterministic hard-RT control vs. high-compute service hosting; safety and security profiles
  • Hybrid architectures: which software lives where, and the bridging patterns between platforms
  • **Exercise 2: partition a vehicle function set across Classic, Adaptive, and non-AUTOSAR domains with a written rationale**
  • The service-oriented communication model in the specifications: services, methods, events, fields
  • SOME/IP: message structure, service discovery (SOME/IP-SD), serialization, and its Classic/Adaptive bridging role
  • DDS in the Adaptive context: QoS policies, publish-subscribe semantics, and where the spec positions it
  • Signal-based (CAN/LIN/FlexRay) communication vs. service-based: coexistence and gateway translation
  • **Worked example: specify a service interface (methods/events/fields) and its deployment on SOME/IP**
  • Unified Diagnostic Services (UDS/ISO 14229) fundamentals: sessions, services, DIDs, routines
  • Diagnostic architecture in AUTOSAR: the Diagnostic stack (Classic) and diagnostics as services (Adaptive)
  • Security access, authentication, and the diagnostics-attack-surface question in connected vehicles
  • Fault memory (DTC) management and its relationship to service-based logging
  • **Exercise 3: design the diagnostic service surface for a remotely updatable ECU**
  • OTA update pipelines: campaigns, delta updates, A/B partitions, rollback, and safety interlocks
  • The update architecture per platform: Classic flashing concepts vs. Adaptive deployment/installation model
  • Vehicle APIs: what gets exposed, to whom, and the abstraction layers protecting internal interfaces
  • Regulatory context for updates (software update management expectations) and its architectural consequences
  • **Case Study: an OTA campaign that bricked a domain controller — the rollback design that was missing**
  • The AUTOSAR Methodology: activities, work products, and artifact flow from system description to ECU binaries
  • Tool-chain mapping: authoring, configuration, code generation, and the artifacts each step consumes/produces
  • ISO 26262 connection: item definition → safety goals → technical safety concept mapped onto AUTOSAR elements; safety mechanisms the platform provides (E2E protection, memory partitioning, watchdog)
  • Freedom from interference and mixed-criticality deployment on both platforms
  • **Exercise 4 (capstone): end-to-end architecture review — layering, platform split, communication, diagnostics, update, and safety rationale for a defined vehicle function**

More in Track E — EV, ADAS & Software-Defined Vehicle

Full Course Catalog