2.0: Automotive ECU Development
Key Terms
Key terms specific to this case study (see Appendix G and Appendix H for the complete glossary):
- ECU: Electronic Control Unit — the embedded computer that this case study develops
- ACC: Adaptive Cruise Control — the application domain for this ECU
- ASIL: Automotive Safety Integrity Level (A through D, where D is highest) — determines the rigor of development and verification activities
- AUTOSAR: AUTomotive Open System ARchitecture — the standardized BSW and RTE framework used in this project
- BSW/RTE/MCAL: Basic Software / Runtime Environment / Microcontroller Abstraction Layer — the three AUTOSAR layers below the application
- HARA: Hazard Analysis and Risk Assessment — the ISO 26262 process that assigns ASILs to safety goals
- MISRA C: Motor Industry Software Reliability Association coding standard for safety-critical C code
- HIL: Hardware-in-the-Loop — testing with real ECU hardware and simulated vehicle environment
- UDS/DTC: Unified Diagnostic Services / Diagnostic Trouble Code — automotive diagnostic protocols
- SOP: Start of Production — the milestone when the ECU enters mass manufacturing
- CL2: ASPICE Capability Level 2 — the target assessment level for this project, requiring managed processes
Introduction
This chapter presents a complete case study: developing an Adaptive Cruise Control (ACC) ECU from concept to production, following ASPICE CL2 and ISO 26262 ASIL-B requirements, with AI-assisted development. This real-world example demonstrates every concept from Parts I–IV applied to actual automotive embedded software.
Project Overview
System Context
Product: Adaptive Cruise Control (ACC) Electronic Control Unit OEM Customer: Tier-1 automotive supplier (anonymized as "AutoTech GmbH") Target Vehicle: Mid-size sedan (production: 2027) Safety Classification: ASIL-B (ISO 26262) ASPICE Target: CL2 (contractual requirement)
Note: This case study applies concepts from Part II (ASPICE Processes), Part III (AI Toolchain), and Part IV (Practical Implementation). Cross-references are provided throughout to help readers connect theory with practice.
Key Requirements
## ACC System Requirements (High-Level)
### Functional Requirements
1. **[SYS-001] Maintain Set Speed**
- System shall maintain driver-selected cruise speed (30-180 km/h)
- Tolerance: ± 2 km/h
2. **[SYS-002] Maintain Safe Following Distance**
- System shall maintain minimum 2-second time gap from lead vehicle
- Detection range: 5-150 meters
- Adjustable: 1.5s / 2.0s / 2.5s (driver selectable)
3. **[SYS-003] Automatic Speed Adjustment**
- System shall decelerate when lead vehicle slows (max: -3 m/s²)
- System shall accelerate when lead vehicle speeds up (max: +2 m/s²)
- Smooth acceleration/deceleration (jerk < 1.5 m/s³)
4. **[SYS-004] Driver Override**
- Driver brake pedal disengages ACC immediately
- Driver accelerator temporarily overrides ACC
- Driver can adjust set speed via steering wheel controls
### Safety Requirements (ISO 26262 ASIL-B)
5. **[SYS-100] Safe State Transition**
- System shall enter safe state within 500ms upon critical failure detection
- Safe state: ACC disabled, driver alerted, vehicle maintains current speed via engine ECU
6. **[SYS-101] Sensor Redundancy**
- System shall fuse data from radar + camera (redundant sensing)
- Single sensor failure shall not cause unsafe behavior
7. **[SYS-102] Plausibility Checks**
- System shall perform range plausibility checks on sensor inputs
- Out-of-range values trigger fault, ACC disabled
### Non-Functional Requirements
8. **[SYS-200] Real-Time Performance**
- Control loop: 50ms cycle time (20 Hz)
- Sensor fusion latency: < 100ms
9. **[SYS-201] Resource Constraints**
- Target ECU: Infineon AURIX TC397 (TriCore 300 MHz, 4 MB Flash, 768 KB RAM)
- Flash budget: 2 MB for ACC software
- RAM budget: 256 KB
10. **[SYS-202] AUTOSAR Compliance**
- Software shall conform to AUTOSAR Classic Platform 4.4.0
Project Timeline
The following diagram provides a high-level timeline for the ACC ECU development project, showing the major phases, milestones, and deliverables from project kickoff through SOP (Start of Production).
Team Structure
| Role | Count | Responsibilities |
|---|---|---|
| Project Manager | 1 | MAN.3 (Schedule, budget, stakeholder mgmt) |
| System Architect | 1 | SYS.3 (System architecture, AUTOSAR config) |
| Software Architects | 2 | SWE.2 (Application architecture, ADRs) |
| Embedded Developers | 5 | SWE.3-4 (C coding, unit testing) |
| Integration Engineers | 2 | SWE.5 (ECU integration, HIL testing) |
| QA Engineers | 2 | SWE.6, SUP.1 (Qualification testing, audits) |
| Safety Engineer | 1 | ISO 26262 (FMEA, FTA, safety case) |
| ASPICE Coordinator | 0.5 FTE | Process compliance, evidence collection |
Total: 14.5 FTE (Full-Time Equivalent)
Team Composition Note: The 14.5 FTE team represents a typical mid-sized automotive software project. For larger ASIL-D projects, expect 20-30 FTE; for smaller ASIL-A projects, 8-10 FTE may suffice. The 0.5 FTE ASPICE Coordinator is a common pattern where process expertise is shared across multiple projects.
Technology Stack
Hardware Platform
Target ECU: Infineon AURIX TC397
├── CPU: TriCore 1.6E (3 cores, 300 MHz each)
├── Flash: 4 MB (program + calibration data)
├── RAM: 768 KB (SRAM + DRAM)
├── Peripherals:
│ ├── CAN-FD (2 channels for vehicle network)
│ ├── FlexRay (backup, not used in ACC)
│ ├── Automotive Ethernet (100BASE-T1 for radar)
│ └── ADC (analog sensors: throttle position, brake pressure)
└── Debugger: JTAG/TRACE32 (Lauterbach)
Software Stack (AUTOSAR Classic 4.4.0)
Software Architecture (AUTOSAR Layered)
├── Application Layer
│ ├── ACC_Control (speed regulation algorithm)
│ ├── SensorFusion (radar + camera data fusion)
│ ├── SafetyMonitor (ASIL-B watchdog)
│ └── HMI_Interface (driver interaction)
│
├── Runtime Environment (RTE)
│ └── AUTOSAR RTE (generated by Vector DaVinci Configurator)
│
├── Basic Software (BSW)
│ ├── Communication: CAN Stack (Vector CANbedded)
│ ├── Memory: NVM Manager, Flash driver
│ ├── Diagnostics: UDS (ISO 14229), DTC management
│ └── OS: AUTOSAR OS (OSEK-compliant, real-time scheduler)
│
└── MCAL (Microcontroller Abstraction Layer)
└── Infineon iLLD (Infineon Low-Level Drivers)
Development Tools
| Category | Tool | Purpose |
|---|---|---|
| IDE | Vector PREEvision | AUTOSAR system design |
| Code Editor | VS Code + GitHub Copilot | C coding with AI assistance |
| Compiler | Tasking TriCore Compiler v6.3 | MISRA-compliant code generation |
| Static Analysis | LDRA TBvision | MISRA C:2012, ISO 26262 compliance |
| Unit Testing | Vector VectorCAST | Automated unit test execution |
| HIL Testing | dSPACE SCALEXIO | Hardware-in-the-Loop simulation |
| Debugger | Lauterbach TRACE32 | On-target debugging |
| Version Control | Git + GitHub | Source code management (SUP.8) |
| CI/CD | GitHub Actions | Automated build + test |
| Requirement Mgmt | IBM DOORS Next | Requirements traceability (SWE.1) |
AI Integration Points
Where AI Assists in This Project
| Phase | AI Tool | Use Case | Time Savings |
|---|---|---|---|
| Requirements | ChatGPT-4 | Draft initial requirements from OEM spec | 30% |
| Architecture | Claude Sonnet | Generate ADRs, review architecture diagrams | 25% |
| Coding | GitHub Copilot | Auto-complete C functions, boilerplate code | 40% |
| Unit Tests | Copilot + VectorCAST | Generate test cases from requirements | 50% |
| Code Review | SonarQube AI | Detect code smells, suggest refactoring | 20% |
| Documentation | Claude | Generate Doxygen comments from code | 60% |
Overall Productivity Gain: Estimated 35-40% reduction in development time (18 months instead of 28 months without AI).
Cross-Reference: For detailed AI tool integration patterns, see Part III (Chapters 13-18). The AI Integration Points table above summarizes the practical application of those concepts in this project.
ASPICE Process Mapping
How ASPICE Processes Apply to ACC Project
| ASPICE Process | ACC Project Activity | Key Work Products |
|---|---|---|
| SYS.2 System Req | Analyze OEM spec, derive system requirements | System Requirements Spec (150 reqs) |
| SWE.1 SW Req | Decompose system reqs into software requirements | Software Requirements Spec (300 reqs) |
| SWE.2 SW Arch | Design AUTOSAR architecture, define runnables | Architecture Decision Records (5 ADRs) |
| SWE.3 SW Design | Implement C code (25,000 SLOC) | Source code in Git |
| SWE.4 Unit Verify | Test functions in isolation | Unit test report (85% coverage) |
| SWE.5 Integration | Integrate on ECU, test component interactions | HIL test report (500 scenarios) |
| SWE.6 Qualification | System-level validation against SYS.2 | Qualification test report |
| SUP.1 QA | Code reviews, MISRA checks, safety audits | Audit reports, PR reviews |
| SUP.8 Config Mgmt | Git branching, semantic versioning, baselines | Git tags, release notes |
| MAN.3 Project Mgmt | Sprint planning, burndown tracking | Jira burndown charts |
Success Metrics
Project KPIs (Actual Results)
| Metric | Target | Achieved | Status |
|---|---|---|---|
| Schedule | 18 months | 17.5 months | PASS - On time |
| Budget | €2.5M | €2.4M | PASS - Under budget |
| Defect Density | ≤2.0 defects/KLOC | 1.6 defects/KLOC | PASS - Exceeds target |
| Code Coverage | ≥85% (ASIL-B) | 89% | PASS - Exceeds target |
| MISRA Compliance | 0 mandatory violations | 0 violations | PASS |
| ASPICE Rating | CL2 (≥85% BP achievement) | CL2 (92% BP) | PASS - Exceeds target |
| ISO 26262 Cert | ASIL-B certification | ASIL-B certified | PASS |
Conclusion: Project delivered on time, under budget, exceeding quality targets.
Chapter Structure
This chapter deep-dives into the ACC ECU development process:
- 25.01 Project Context and Requirements - OEM specification analysis, requirement derivation
- 25.02 Architecture and Design - AUTOSAR architecture, ADRs, design patterns
- 25.03 Implementation with AI - C coding with Copilot, MISRA compliance, code generation
- 25.04 Verification and Validation - Unit/HIL/system testing, ISO 26262 compliance
- 25.05 Lessons Learned - What worked, what didn't, recommendations for future projects
Next: Detailed requirements analysis (25.01).