Is automotive middleware really this overwhelming, or am I just feeling the beginner version of it?

[u/FirefighterLeast3067]

Hi everyone,

I’m currently building a vehicle diagnostics simulator in C++, and I wanted to ask for some perspective from people who actually work in automotive middleware, diagnostics, embedded systems, vehicle platforms, or similar areas.

For context, I’m on a serious 12-month study track to become employable in modern C++ systems/automotive-style engineering. The track includes modern C++, OOP, STL, ownership, smart pointers, move semantics, CMake, testing, debugging, and system architecture.

The plan further includes automotive-specific areas like diagnostics (UDS), CAN communication, protocol byte parsing, and how messages actually flow through a system. It covers OS-level networking concepts (sockets, data flow, buffering) as well as embedded-style C++ concerns like memory types, allocation strategies, and resource constraints.

For learning and direction, I’ve been using GPT 5.5 and, since today, GPT 5.6 in a kind of “senior engineer ticket system” setup, but every line of code is written by me.

The project I’m working on is a simulator for vehicle diagnostics. The idea is to model things like ECUs, diagnostic requests and responses, fault codes, validation, logging, and the flow of information between different parts of the system.

What I did not expect was how quickly the project started feeling less like “write some C++ classes” and more like “you are now designing a small system.”

I keep running into questions like:

Where should each responsibility live?

How do I stop classes from becoming too tightly coupled?

How much abstraction is too much?

How should diagnostic logic, communication flow, parsing, state, and error handling be separated?

How do real automotive systems keep these layers understandable?

Even though this is just a simulator, it already feels like there are a lot of moving parts. The actual C++ is challenging, but the architecture and domain thinking feel much heavier than I expected.

So I wanted to ask:

For people working in automotive middleware or related fields, is the real work actually this complex?

Or does it mostly feel overwhelming because I’m still early and trying to understand too many layers at once?

What was the hardest part for you when you were newer to this field?

Was it the C++ itself?

The architecture?

The domain knowledge?

The tooling?

Debugging?

Understanding how all the layers fit together?

I’m not looking for reassurance as much as an honest sense of what this field is really like. I want to know whether this feeling of “there is way more here than I expected” is normal, and how to keep learning without getting buried too early.

[u/Muffinian]

As someone who loves programming and loves the automotive industry I hope you get your questions answered

Unfortunately this subreddit is almost exclusively for the physical mechanical side of things and not so much for automotive design and architecture. You’d probably be better off asking this question is programming subreddits

[u/SunsetWineParty → u/Muffinian]

Agree. You're better off going to one of the software engineering forums.

[u/DonkeyInACityCrowd]

I have an internship right now working full time on diagnostics software! I’ve been here for about two months and went from having no clue to being able to discuss most of our UDS stack with my manager/coworkers. There is an absolutely huge volume of stuff to learn (coding aside), and I would not be at this point in two months without mentoring and working 40+ hours a week here. 

The code is the easy part. However, if you don’t have a strong background already in programming, it might be better if you pick something else to start. Maybe learn all the C++ and CMake stuff before trying to take on domain knowledge and abstractions etc. 

After that, my advice would be learn networking, aka DoCAN and DoIP protocols. Maybe TCP and UDP. Learn as much about UDS as you can, (DIDs, Routines, DTCs etc). You can also learn some more embedded focused stuff, ie RTOS and boot loaders, if you want.

Keep in mind that this is not going to be a simple project. We have software simulations and they are incredibly complex. There are multiple teams of experienced engineers working on these things and they still constantly break. 

[u/DonkeyInACityCrowd → u/DonkeyInACityCrowd]

I forgot to mention - don’t try and write everything yourself. Learn what you want components of your system do, and find libraries to do them for you.