Internship · Automotive R&D

Kenotom — Automotive ECU Software

Developing and debugging automotive ECU software on an AUTOSAR Classic stack, and learning to trace problems down through its layers.

Role
Automotive R&D Engineering Intern
Timeline
Jun – Aug 2026 · Thessaloniki, Greece
Stack
C, AUTOSAR Classic, ETAS RTA-CAR, RTA-OS, AURIX TC387

Overview

Over summer 2026 I worked as an automotive R&D engineering intern at Kenotom in Thessaloniki, Greece, through Princeton's international internship program. I worked on embedded ECU software in C on an AUTOSAR Classic stack, targeting Infineon AURIX TC3x7 hardware.

This page covers the stack and what I learned working in it. It doesn't cover anything proprietary about the work itself.

My role

  • Wrote ECU software in C.
  • Configured and generated AUTOSAR components (BSW, RTE, OS, and MCAL) with ETAS RTA-CAR and RTA-OS.
  • Worked on communication stack configuration, including CAN interfaces and BMS-related communication.
  • Resolved integration and build issues across the stack, using serial/printf debugging on the target.
  • Worked with a Greece-based, multilingual engineering team.

System

AUTOSAR Classic splits ECU software into layers. Application software components sit at the top and talk only to the RTE, a generated layer that connects them to each other and to the basic software: the communication stack, services, and the OS. Underneath is the MCAL, the drivers for the specific microcontroller, which here was an Infineon AURIX TC387 on a TC3x7 Application Kit.

AUTOSAR Classic layers, top to bottom: application software components, the RTE, basic software (communication stack and services alongside the OS), MCAL, and the Infineon AURIX TC387 microcontroller. An arrow traces a signal down through each layer.Application SWCsC · the logic you actually writeRTEgenerated interfaces between componentsBSWCOM stack · CAN · servicesRTA-OStasks · schedulingMCALmicrocontroller driversInfineon AURIX TC387the hardwaretrace thesignal downConfigured and generated with ETAS RTA-CAR
The AUTOSAR Classic layers I worked across. Debugging meant following a signal down through every one of them.

Much of this is generated from configuration, so a working system depends on the configuration being right in every layer as much as on the C code.

Challenges

When I first opened the stack, it was unfamiliar and very layered. My instinct was to treat problems like a normal C program: find the line that looked wrong and try a quick fix.

That didn't work. A symptom in application code could come from an RTE mapping, a COM stack setting, OS configuration, or an MCAL setting several layers down. Patching the symptom at the top usually just moved the problem.

How I changed my approach

So I stopped patching and started tracing:

  1. Follow the signal from the application code through the RTE.
  2. Look at how the basic software and COM stack handle it.
  3. Understand what the OS is doing: which task runs when.
  4. Follow the interface down toward the MCAL and the hardware.
  5. Read the documentation for each layer carefully, and write down my assumptions so I can check them.
  6. Ask engineers specific questions about a particular layer or interface instead of vague ones.

When a system is complex and unfamiliar, understanding its architecture and interfaces matters more than patching the symptom quickly.

What I learned

  • How a production-style automotive ECU stack is structured, and how different it is from classroom code.
  • How to debug through layers of abstraction, many of them generated.
  • How to get productive with unfamiliar professional tooling.
  • How to ask better technical questions.
  • What it's like to work on an engineering team in another country.

I'm not an AUTOSAR expert after one summer. I did come away knowing how to find my way around a stack like this, and how to approach the next large system I don't understand yet.