AUTOSAR, ECU Development
& Automotive Embedded — FAQ
Answers to the most common questions about AUTOSAR architecture, ECU development, UDS, ISO 26262, and how to build a career in automotive embedded software engineering.
01What is AUTOSAR and how do I learn it?
AUTOSAR (AUTomotive Open System ARchitecture) is a standardized software architecture for automotive ECUs. It consists of three main layers: the Application Layer (SWC), the Runtime Environment (RTE), and the Basic Software (BSW). To learn it, start with the official AUTOSAR specification, then practice with tools like DaVinci Configurator or Tresos Studio. Working with a mentor who has real project experience can significantly accelerate your learning.
02How do I become an automotive embedded software engineer?
To become an automotive embedded software engineer: (1) Master embedded C and MISRA coding standards, (2) Learn AUTOSAR architecture — BSW, RTE, SWC, MCAL, (3) Understand automotive communication protocols: CAN, LIN, SOMEIP, Ethernet, (4) Get familiar with diagnostic standards: UDS (ISO 14229) and OBD-II, (5) Practice with industry tools: CANoe, Trace32, DaVinci Configurator, (6) Understand functional safety concepts from ISO 26262. Real project experience or structured mentoring is key to landing your first automotive role.
03What is the difference between Classic AUTOSAR and Adaptive AUTOSAR?
Classic AUTOSAR targets resource-constrained ECUs with hard real-time requirements — engine control units, braking systems, airbag controllers. It uses a static architecture fully configured at build time, runs on OSEK/AUTOSAR OS, and is programmed in C. Adaptive AUTOSAR targets high-performance ECUs running ADAS, infotainment and connected services. It uses a POSIX-based OS (Linux), supports dynamic service discovery via SOMEIP/DDS, and uses C++14. Most safety-critical ECUs in production today still run Classic AUTOSAR.
04What tools are used in AUTOSAR development?
The main AUTOSAR development tools are: Vector DaVinci Configurator & Developer (BSW and RTE configuration), Elektrobit Tresos Studio (BSW configuration), Artop/Eclipse (ARXML editing and tooling), CANoe (network simulation and testing), Trace32 by Lauterbach (low-level debugging), PCAN and CANalyzer (CAN analysis), and Jenkins/Git for CI/CD. For specific OEM projects, proprietary tools may also be used.
05What is UDS (Unified Diagnostic Services) in automotive?
UDS (Unified Diagnostic Services, ISO 14229) is the standard diagnostic protocol used in modern vehicles to communicate with ECUs via CAN, Ethernet or other buses. It defines key services: DiagnosticSessionControl (0x10) to switch between default and programming sessions, ECUReset (0x11), ReadDataByIdentifier (0x22), WriteDataByIdentifier (0x2E), and RoutineControl (0x31) for custom routines. UDS is used for end-of-line programming, fault code reading, and over-the-air software updates. In AUTOSAR, UDS is implemented through the DCM (Diagnostic Communication Manager) module.
06How long does it take to learn AUTOSAR?
With dedicated study and hands-on practice, you can grasp AUTOSAR fundamentals in 3 to 6 months. To be production-ready and contribute meaningfully to real automotive projects, expect 1 to 2 years of combined learning and professional experience. The learning curve is steep because AUTOSAR involves mastering the architecture, the toolchain, the communication stacks, and the safety constraints simultaneously. Working with an experienced mentor can cut this timeline significantly by focusing on what matters in real projects.
07Is ISO 26262 required for all automotive software?
ISO 26262 (Road Vehicles — Functional Safety) is required for safety-relevant ECUs where a failure could cause harm: braking systems, steering, airbags, and powertrain control typically require ASIL B to ASIL D certification. Comfort features like windows, seats, or infotainment typically fall under QM (Quality Management) without strict ISO 26262 requirements. The standard defines the entire development lifecycle: from hazard analysis to design, coding rules, testing, and documentation.
08What is SOMEIP and when is it used in automotive?
SOMEIP (Scalable service-Oriented MiddlewarE over IP) is a middleware protocol used in automotive Ethernet networks for service-oriented communication. It allows ECUs to discover services dynamically and exchange structured data. SOMEIP is the foundation of Adaptive AUTOSAR communication and is increasingly used in gateway ECUs, central computers, and domain controllers in modern vehicles. Unlike CAN which is message-oriented, SOMEIP is service-oriented — services are published and subscribed to dynamically.
09What microcontrollers are commonly used in AUTOSAR projects?
The most common microcontrollers in Classic AUTOSAR projects are: Infineon AURIX TC2xx and TC3xx (TriCore architecture, widely used in safety-critical ECUs), Renesas RH850 and RL78 (popular in Japanese OEM projects), NXP S32G and S32K families (gateway and domain controllers), and STMicroelectronics SPC5xx. AURIX TC3xx is currently dominant in new AUTOSAR Classic projects due to its lockstep cores for ASIL D compliance and multicore capabilities.
10What is the MCAL in AUTOSAR?
MCAL (Microcontroller Abstraction Layer) is the lowest software layer in Classic AUTOSAR, sitting directly above the hardware. It provides standardized APIs to access hardware peripherals: DIO (digital I/O), ADC (analog-to-digital converter), SPI, CAN, LIN, PWM, ICU, OCU, and more. The MCAL is microcontroller-specific and is usually provided by the MCU vendor or a BSW supplier like Vector or Elektrobit. Configuring the MCAL with tools like Tresos or DaVinci is one of the first practical skills needed in AUTOSAR development.
11What is a Software Component (SWC) in AUTOSAR?
A Software Component (SWC) is the application-level building block in Classic AUTOSAR. It encapsulates application logic and communicates with other SWCs or the BSW only through the RTE (Runtime Environment) via well-defined ports and interfaces. SWCs are defined in ARXML and are theoretically portable across different ECUs. Types include Application SWC, Sensor/Actuator SWC, and Complex Device Driver (CDD) for direct hardware access when BSW drivers are insufficient.
12What is CAN bus and why is it used in automotive?
CAN (Controller Area Network) is the dominant serial communication protocol in automotive ECUs, standardized by Bosch in the 1980s and now under ISO 11898. It allows multiple ECUs to communicate on a shared 2-wire bus at speeds up to 1 Mbit/s (CAN FD up to 8 Mbit/s). CAN is used because it is robust (differential signaling), supports multi-master architectures, has built-in error detection and prioritization, and is cost-effective. In AUTOSAR, CAN communication is handled by the ComStack: CanIf, PduR, Com, and CanSM modules.
13How is automotive embedded different from other embedded domains?
Automotive embedded development differs from general embedded in several key ways: (1) Strict functional safety requirements under ISO 26262, (2) Mandatory coding standards (MISRA C/C++), (3) Standardized architecture (AUTOSAR) that most projects follow, (4) Long product lifecycles — automotive software must be maintainable for 10-15 years, (5) Rigorous V-cycle development process with extensive documentation, (6) OEM-specific requirements and homologation processes. These constraints make automotive embedded more structured but also more demanding than IoT or industrial embedded.
14What career path exists in automotive embedded software?
A typical automotive embedded career progression: (1) Junior Embedded SW Engineer — writing and testing AUTOSAR SWC and BSW modules, (2) Embedded SW Engineer — owning features, leading technical discussions with customers, (3) Senior Embedded SW Engineer — architecture decisions, MCAL/BSW configuration ownership, (4) Technical Referent / Expert — cross-team technical authority, process improvement, (5) Software Architect — full system design across ECUs. Specializations include: BSW expert, MCAL expert, COM stack expert, diagnostics expert, and safety manager.
15Can I transition to automotive embedded from telecom or aerospace?
Yes — and many skills transfer directly. From telecom: protocol knowledge (CAN ≈ physical/data link layer thinking), embedded C, RTOS concepts, and communication stack understanding all map well to automotive. From aerospace: safety methodologies (DO-178C concepts align with ISO 26262), real-time constraints, and rigorous V&V processes are directly applicable. The main new concepts to learn are AUTOSAR-specific: the BSW architecture, ARXML tooling, and automotive-specific protocols (UDS, OBD-II, SOMEIP). A structured mentoring program can bridge this gap in a few months.
Still have questions?
Get personalised answers and a clear roadmap for your automotive embedded career through 1:1 mentoring sessions.