Skip to content

Automotive embedded software (personal views)

  • 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
  • Electric Vehicle (EV) produces zero emissions, and also zero noise, the zero road noise seems like a cool factor. But in reality this “Silence of the EVs” make it impossible for other road users to know that there is a vehicle at a distance, this is unlike ICE (Internal Combustion Engines) vehicle which make a pass-by noise.

    This pass-by noise is especially important for Vulnerable road users (VRUs) like pedestrians, parents with strollers, teens with headphones for their safety.

    The technical solution is to have an external speaker which connects to the infotainment ECU and plays an speed dependent humming noise which alerts VRUs. This is regulated in the EU and mandatory from 2019 , the link to the same can be found at https://single-market-economy.ec.europa.eu/news/electric-and-hybrid-cars-new-rules-noise-emitting-protect-vulnerable-road-users-2019-07-03_en

    I would like to urge the major Indian OEMs like https://www.instagram.com/mahindraelectricsuvs/ and https://www.instagram.com/tata.evofficial/ to explore this possibility to improve VRU safety. In addition I would like to request https://www.instagram.com/arai_india/ to add it to the mandate of homologation if feasible.

    Silence of the Electric Vehicles in dense urban network in India

    –––––––

    Apr 27
  • Well here I have only one experiment to share unlike Mahatma Gandhi’s “My experiments with Truth” which is worth a read if not already.

    I am building a small FreeRTOS based application, as a rite of passage, got to write the “Hello World” which is a big confidence booster and a dopamine hit. As you can imagine the “Hello World” task was not not willing to say “Hello World”. I tried few more things with no luck of seeing the elusive.

    Then i recalled a friends’ conversation that he has completely stopped changed development style with LLM, I thought I will give it a stab. I purchased a 20 $ github co-pilot , installed as a plugin into VSCode.

    I selected the part of the code which was not working as for review comments, the LLM generated token, all looks good. Then I requested LLM to check why either task creation or task failure was not printing out anything. It started analysis all the files in the workspace, asked me for permission to fix the code, removed all the experimental code I had inserted while debugging, ran the build each time and lo behold the “Hello World”.

    Really mind-boggling, but then when I look the code again, formatting has changed, style has changed and I can barely recognize this as my style of code. So I am wondering what is the impact on maintainability and understandably of code in the long run or we doomed to rely on LLMs for the same, much like we don’t remember anyone phone numbers now ! So development will be abstracted away like a name on the phone under which lies the real phone number.

    #Handwritten #NoAI

    My Experiment with Git hub co-pilot for development

    –––––––

    Apr 20
  • What is Yocto

    It is an package system

    Provide configuration management of different open source and closed source packages

    Helps to build complete product software

    Lastly it is a swiss army knife for software development

    Has a steep learning curve

    What Yocto is not

    It is not a distribution of linux

    If you are developing a embedded linux product and would like to the entire product code to be built from scratch then Yocto is the answer. It comes with a concept of recipes which are abstraction on top older build systems like make or cmake. Using yocto different product variants can be configured and built. Yocto also generates BOM (Bill of Materials) including spdx if provided at each package level. Yocto fetches diferent packages from many open source , builds them from sources, installs them into the root-fs. Yocto can also build the linux kernel.

    So in summary it is a powerful tool for product development with a steep learning curve, once mastered you will love its power.

    May the force be with you !

    #NoAI has been used to write this note.

    Gentle introduction to Yocto

    –––––––

    Apr 14
  • Well if you are developing an micro controller based product, there are couple of ways to proceed, one is to develop the entire application in one single infinite loop and manage the timing yourself by fine tuning.

    Another approach is to use an RTOS (Real Time Operating System) and let it handle the timing constraints for the application, so as a developer you can focus on the application logic.

    One of the popular choices is FreeRTOS which is more or less available for all combination of compiler and MCU variants even including RISC V. Now with this approach, there are a few choices to be made.

    Use FreeRTOS without paying any royalty and go into production, it comes with MIT license which is permissive.

    If your company has a blanket agreement to not use any kind of open source, then you can for the OpenRTOS which is fully compatible with FreeRTOS, it is the exact same kernel under a commercial license.

    If the product in question is Safety product , then the choice is to use SafeRTOS so the safety certification of the kernel is taken care by https://www.highintegritysystems.com/.

    Happy development !

    FreeRTOS vs. SafeRTOS vs. OpenRTOS

    –––––––

    Apr 5
Next Page

Blog at WordPress.com.

Loading Comments...
  • Subscribe Subscribed
    • Automotive embedded software (personal views)
    • Already have a WordPress.com account? Log in now.
    • Automotive embedded software (personal views)
    • Subscribe Subscribed
    • Sign up
    • Log in
    • Report this content
    • View site in Reader
    • Manage subscriptions
    • Collapse this bar