Automotive embedded software(personal human views)

Based on the McKinsey study of 2026 technology trends and their level of maturity making an attempt to see what will change in embedded systems, this forecast is agnostic to industry and is a guess-ti-mate as it is very tough to be accurate, that said, at attempt is being made here.

The main trends and their impact to embedded is as follows with 1-4-9- scale, 1 being the lowest impact and 9 being the highest.

Technology Trend	Adoption Score	Adoption Status
AI infrastructure and model architectures	4	Scaling in progress
Application-specific semiconductors	4	Scaling in progress
Cybersecurity and trustworthy systems	4	Scaling in progress
Advanced connectivity	4	Scaling in progress
Future of life sciences and bioengineering	4	Scaling in progress
Future of energy and sustainability technologies	4	Scaling in progress
Agentic software development	3	Piloting
Agentic AI	3	Piloting
Future of mobility	3	Piloting
AI for scientific discovery and engineering	2	Experimentation
Immersive-reality technologies	2	Experimentation
Future of robotics	2	Experimentation
Future of space technologies	2	Experimentation
Quantum technologies	1	Frontier innovation

Where the adoption score is 4 with scaling in progress it is implicit that this is a brown field and many players are already there which is why the Adoption Score of 4 impacts embedded systems.

Top three impacts are:

As AI infrastructure is growing rapidly, the memory costs both NAND flash and DRAM are increasing, this will force ODM (Original Device Manufacturers ) and OEM (Original Equipment Manufacturers) to demand more for less, meaning more features in the mid variant as against the premium variant. This will need embedded software to be more cognizant of the compute and memory usage.
With new ASIC development, there opportunities for VLSI design and verification skills to be in high demand.
As AI is reducing the time from detection of Zero day vulnerability to exploitation embedded systems need to be constantly monitored for attacks and alert the SOC (Security Operations Center) with a well tested fix available for OTA (Over the Air) as soon as possible.

2026 Technology trends and its probable impact on embedded systems

–––––––

Oct 27

Imagine you are the VP of projects looking at the health of projects, what could be the some of the possible scenarios you may face and next steps.

Radio Silence from project manager

This is the most dangerous sign , the project is lost in the Bermuda triangle, with no hope of recovery. The only way is to meet the paying client and see what can be done now.

Green status for weeks on end

This could be a water-melon color, green on the outside and red in the inside. In this case probe with others in the project to get a sense to see if green is real green.

Quality gone red

Well if Quality gone red in the early days of the project, it can be salvaged by having one or more of the following:
1. Adding strong technical folks with systematic on-boarding
2. Automated testing
3. Second opinion on the software architecture
Cost over-run

Well now it depends on how much percentage cost is over-run and relatively how much project is accepted by client. If there is no runway left, better to mutually close the project. At the end of the day projects are executed to make profits.

Schedule over-run

This the best case and most common scenario, assuming cost and quality are in good shape, you may reach out to the client or go for soft launch if feasible.

This brings to question what can be done to forecast these well in advance. Some of the following high level metrics might help.
1. Code review defect injection rate per pull-request
2. Regression failures per engineering builds
3. Rate of cash burn
4. Percentage of acceptance of project milestones by client.
PS : The angle here is assuming that the project is an external project.
MAYDAY MAYDAY in a fixed price project from a client

–––––––

Sep 24
I chanced up on the “The Software Architect Elevator” book by Gregor Hohpe and read the same cover to cover.

The book gives accurate definition of who is a software architect, what are their main functions. It draws up interesting analogy of an architect being able to transition from engine room to ivory tower using an elevator of sorts, meaning connecting the details of execution to the business.

The author would like architects to focus on rate of change rather than change which allows the organizations to be able to catch up with the super fast rate of change we are all being bombarded with, some we are able to comprehend, some we don’t even realize that the change itself has changed again and we missed to notice the first change.

The book focuses on enterprise IT architect, but the principles are applicable to all type of software architects like product/platform architects as well.

Then last few chapters of the book help and guide architects on how they can be change agents , the need for change, the steps for change and how to overcome resistance for change.

Last but not the least it is filled with “The Matrix movie” anecdotes and is very humorous to read from start to finish. You may want to pick up a copy of the same and read the same from the Modern Architect .

The Software Architect Elevator – Gregor Hohpe

–––––––

Sep 23
As seen in many organizations there are varied roles and responsibilities, the most interesting one i often encounter is that of technical manager. I will explain.

So a Technical Manager is she/he more technical or more managerial, so is this person leaning left (more Technical) or leaning right(more Managerial).

Different organizations may have different understanding of orientations, maybe in some the Technical Managers are mostly leaning left. This causes an issues for potential job applicants and also for interview panels to decide on a candidate.

Assuming the candidate does pass this hurdle either by design or by fluke, then comes her/his daily interactions, how managerial this person must be or vice versa.

To add to this mix, there is also Technical Program Manager (TPM), now three domains are mixed together, technology, project management and management. The TPM has even more overlaps. Organizations may think they are reducing the cost of having a three in one, but in reality they may get none and the job satisfaction for the individual in such roles are even more questionable.

My proposed solution is to have Program Managers who take care of projects only, Manager Technical (more managerial) and Technical Manager (more technical) so it simplifies the titles and makes for easy transitions across organizations and better job satisfactions.

If this resonates or have a different view point , could you share in the comments below for the benefit of the community.

Technical manager or Manager technical

–––––––

Sep 21
LLMs will make humans extinct in the next decade is a speculation, but at the moment, it is making code reviewers task very complex.

The challenges forseen by code reviewers are:
1. Is there any copy righted code that is being generated by LLM
2. Is there a possibity of the GPL code getting into the code as snippets.
3. Speed and volume of code is massive, many pull requests getting pulled in very fast to mainline.
4. Perfectly working code for a given use case, but tough to understand the code base.
5. Review comments are fed into an LLM and reponse is an LLM response and does not address the real review comment
6. A sense within the team, as to why we need code reviews to be done manually.
7. Many vendors tool promising code review automated via an LLM.
With all these what can really code reviewers do to improve the code quality and maintainability.
1. Move to meeting based code reviews rather than offline to get a sense of how much of the code base control the developer in turn has
2. Putting together automated tests before merging to main
3. Code reviewer having a clear idea on her/his implementation, atleast a rough sketch.
4. Accept smaller chunks for code review.
If this resonates with you click “like” or share your “wow” (way-of-working) wrt to this.
Code reviews in the age of LLM

–––––––

Sep 16
A colleague of mine asked me if I am into SDV (Software Defined Vehicle). I started to wonder if I am in SDV and what really SDV is all about.

Well to define SDV, it depends whom you ask this question to. A consumer may say if I am able to connect to my vehicle via an mobile app, then she/he believes their vehicle is SDV. If the same question is asked to a Tier-1, the company will likely explain on zonal architecture or High Performance architecture. An OEM is likely to give more convoluted answer which is even harder to understand.

To futher this confusion there are many SDV consortiums some with commercial interests , with open source interests and a few with both. Here is a list of SDVs which I am aware of:
1. Eclipse SDV
2. SOAFEE
3. AOSP
4. .
5. .
I am sure there are many more which I am not even aware. So coming back to the question, am I into SDV?

If an individual is working on a software which is going to be deployed into the vehcile or connects to the vehicle then she/he is in SDV. Needless to say, indiviuals involved in all phases of the software development life cycle from requirements to validation are into SDV.
SDV (Software Defined Vehicle) for simpletons.

–––––––

Sep 16
On many occasions software architects get asked “are we there yet” from teams, managers and even executives.

The answer to this question is not so simple, when can we cut off architecture and hand over to the development team. The answer was quite simple during water fall software development lifecycle. The requirements would be frozen (at least theoretically), architecture team has a clear start and end points.

When it comes to Agile development, the product is split into multiple sprints, and ideally the architecture team is well ahead of the development team at least a few sprints ahead.

But still question is did the architecture team do enough before handing it to over development teams.

The answer is “it depends” on many factors:
1. Regulatory requirements for the product before Start of Production
2. Security requirements
3. Safety requirements
4. Organization structure
5. Teams’ domain and programming knowledge on an average
6. Distribution of the software teams across different time zones.
When you start seeing the pull request or discussions with the team aligned more and more to software architecture team, then the divide between architecture and development has been more or less closed.

If you still see that there is divergence , then best approach is to have architecture workshops to bring all the folks together. Also attention needs to be paid to new folks who are joining the team.

So software architecture is as much team sport along with technical skills , experience of past product launches and also past failures collectively across complete software team.
Is the software architecture done yet ?

–––––––

Sep 8
We all have studied about soil erosion in our high school and know how harmful it is from an agricultural point of view. Similarly there is a an phenomenon of erosion of value in the software.

Causes for this software erosion are:
1. Lack of coding guidelines
2. Poor quality of code review
3. Developers not trained in a proper fashion with a new code base
4. Chaotic project schedules without well defined scope for each Engineering Release
5. Mismanaged changes to requirements
6. Divergence from software architecture and design
7. Reckless usage of LLMs meaning copying the whole file as is without a full understanding of the newly generated code.
8. Improper roles and responsibility definition between engineering manager, software architect and program manager
The above are only a partial list and all of them contribute to exponential build up technical debt which after a point can’t be debited or paid off. The debt is so high that the entropy of the software code base is way too high. This leads to a brittle software which shows symptoms of developer burn-out, many regression issue and overall a run way project.

One way to avoid this is to have a proper software architecture, now what is proper, my definition is to have the documentation using a tool like Enterprise Architect or Visual Paradigm with all views congruent. The class diagram and sequence diagram must all from a common dictionary. Next important step is to generate the header and stubs from the architecture diagram itself. When the code comes in for review if header files are changed with additional public methods added, the reviewer knows something is fishy and architecture is being broken down.

If above is not possible, possibly that boat has sailed, there is an option to reverse engineering the software architecture from code and compare manually and address the major inconsistency step by step with good regression tests to ensure the refactoring does not introduce even more defects.

Do please share your ideas in the comments, thank you.
Software Value Erosion

–––––––

Sep 1
I had the privilege to attend the Meet Qt event recently. Qt is known for their highly successful cross platform development environment which is similar to Java (write once and run everywhere and anywhere). Qt applications once written can be run from an low CPU MCU (Micro Controller Unit) to high end tablets and mobile devices as well. It has to recompiled for each of the target devices which is expected.

Qt also has other interesting tools for by name COCO which helps to compute the code complexity and measures run of the code lines after being tested. COCO can give a graphical view of which lines of code are tested as a part of the test run.

Yet another super interesting tool is SQUISH which automates execution of Qt/QML application via scripts, the SQUISH tool can be integrated with multiple other tools to provide an end to end test environment. For e.g. SQUISH can be main tool which can also run Vector’s CANOe based CAPL scripts, stimulate the UI and collect the results.

Axivion is an architectural analysis tool, it can take software architecture and code base in C/C++ as input and identify where the implementation has deviated from the architecture. This is especially useful for very large application when code drift or architectural erosion may not be visible in code reviews or design workshops. The architecture to code drifts slowly and steadily and over a period of time, we start to wonder what happened and how to refactor back to original architecture.

All in all well spent 4h to learn latest about Qt company in such a short span of time. Thank you to Qt team for making the event happen successfully.

Meet Qt event in BLR

–––––––

Aug 25
Well we all have been there at one time or the other, LLMs seem to have all the answers, have you wondered how is it possible? I have and have tried to understand LLM better, after all they are our (s/w teams) fre-enemy (friend or enemy based on situation)

For starters LLMs are mere token generators which are trained by companies like Meta/Anthropic/Open AI with all the internet data available so far and continue to train them. So the LLMs have ingested all this and created associations between the different tokens and chunks of tokens, those who worked with NLP (Natural Language Processing) will know about words, embedding and vectors, the LLM is an extension to this but at a massive scale.

If LLMs were to be provided to us as is, we will not be so impressed, it hallucinates at times, gives wrong information etc. What companies have done is to append these LLMs with additional tools, for e.g. when you use github co-pilot and provide it a piece of log to analyze, it analyses the same by running different commands (with users permissions) , this LLM + additional tools make them agents, more useful to solve the problem at hand.

IMHO LLMs or agents in themselves are not intelligent. I would like to quote an example from work, an yocto build was failing, the github co-pilot identified the reason for the failure, only on a human nudge it wrote a script to download the failing packages, github co-pilot could not think of this, it was the human in the loop who had to give this idea, but once the idea is given, within next 10 mins it generated a shell script to download the failing package. So human in the loop is very much essential, someone who has her/his own ideas to try, the laborious work of writing code to try ideas, this is solved by the agents.

I have also witnessed agents taking over the developer’s mind and time, it sends the developer into a rabbit hole if used without stepping back every now and then, the end result is a massive token usage payment.

So agents must be used like one, the human must know if the output seems right or not, if the human is clueless of expected end result how it looks, then agent and human together are burning tokens and time.

Most important is excessive reliance on agents, leads to cognitive dis-ability , loss of self confidence to solve the problem at hand.

Analogously if a carpenter does not know his trade well enough, on how to use which tool and when, then giving him an agent will never make him a better carpenter.

So we all need to continue to learn and then rely on agents to do heavy lifting, the agent must in our control and not the other way around.

Happy llm’ing

Why was I so impressed with LLM (Large Language Models)

–––––––

May 3