“Software-defined Vehicle” is a concept where an Automobile Manufacturer only has to make a singular model of a vehicle and all or most of the features can be rolled out through software changes at the vehicle assembly end or even through a software update at the consumer end.

Our Implementation of a Software-defined Vehicle

We, at Mazout Electric, are able to achieve the capabilities of a SDV for our two-wheeler EV. The EV supported a Variety of Hardware changes, be it changes or even replacement to the Battery Pack, dynamically altering the performance of the Motor through changes in the Motor Driver Software, adding features like accident detection through external sensor integration like an IMU sensor and all of this was possible in just a singular Model of the EV. The ability to control the software stack made this possible and thus makes the EV software-defined.

How did we achieve SDV capabilities?

In our journey to achieve SDV capabilities, we found the Android platform to have the perfect mixture of an open-source architecture, providing an user friendly frontend to the consumer, having a robust and proven environment for an experienced software developer to develop applications for the automobile world and also the ability to control added hardware on top of it through software modification at the kernel level.

My step into the Android ecosystem

I remember how I first used an HTC G1, if anyone remembers, it’s the first Android smartphone to ever hit the consumer shelves. Compared to today it was a very alien Phone, HTC didn’t quite know which design philosophy to hold on to so it went with it all. It had a Touch Screen, Qwerty Keyboard and also a track-ball, which some of you reading might not even know that used to exist on a Phone, compared to today when I use the Galaxy Flip Z4, we’ve come a long way. While we can sit all day and discuss Phone ergonomics, but this article is more about the Android Operating System integrated into an Automobile.

The Android Operating System has also come a long way since its inception in the mid 2000’s. As they say, “It’s a very mature Operating System”, so you would rarely see any ground shattering UI revamped update hit the Android market anytime soon.

Now let’s talk about what it was before it reached this mature stage, back in the day when rooting, unlocking the bootloader and gaining root level access, an Android phone meant unlocking its true potential and unleashing the full power of the hardware which the manufacturer didn’t intend the common user to utilize. These features are available today to the end consumer in the form of “Gaming Mode” or “Power Saving Mode”. I remember rooting my Samsung Galaxy S4 to flash a custom kernel tweak and change all the Characters in the OS to display “Hodor”, referring to the character Hodor in the Game of Thrones TV show. Although this resulted in me not being able to make any sense of what is happening on my phone, it laid foundation to my understanding of the “open-source” aspect of the Android ecosystem, meaning that anything is truly possible.

Linux Kernel — what controls Android?

A Kernel can be thought of as the heart of an Operating System. Every Operating System has one, be it Windows devices, Apple devices and ofcource any Android device as well. The Android uses the Linux Kernel which is an open-source Kernel, meaning that its internal code is available publicly to use and add upon as required.

The Kernel is responsible for managing and handling all the system resources, manipulating and assigning the memory, running user space and system essential services, handling file operations, etc. Now, you may have heard that Android is based on the Linux kernel, but what does that really mean? Is it yet another Linux distribution like Ubuntu, a very popular Linux based Operating System, or is it something else altogether. Well, the answer would be different depending on who you ask. Generally, any Linux distro (distribution) uses the GNU ‘C’ libraries, but Android uses the Bionic ‘C’ libraries. Branching out from the vanilla pool of the distros and creating its own implementation of the Linux kernel.

On average, the Linux kernel contains about 15 million lines of code, but almost 70% of it is dedicated device drivers used for compatibility and communication with different hardware. So, think of the kernel as the layer of software which comes on top of the Hardware drivers, be it your Screen, GPS sensor, Camera and even the Storage peripherals. It’s responsible for executing the User application services, like an Alarm App, as well as running the system level services like, maintaining the System Clock. As seen in Figure 1, Android is really whatever comes next after the Linux Kernel, namely, Application framework, Java Native Interface and other Native interfaces, Operations Managers and the User Applications themselves.

Adding any hardware to the Android OS

Kernel Modules & Vendor Library Modules, these are blocks of code programmed in C/C++ which have been compiled into binary files from their respective object file. These modules can be used to add functionality to a system through Kernel/Vendor Image integration. These can be added at runtime in the form of Loadable Kernel Modules or added at system build process, which is recommended. Through communication protocols such i2c, UART or CAN we can virtually achieve any configuration of Hardware combinations.

Android Independent hardware

A Kernel Module (.ko) can be used to implement device driver functionality and communicate with the HAL (hardware abstraction layer) of the Kernel system. Before adding any hardware into the kernel the defconfig file of the Kernel needs to be set up according to the appropriate communication protocol to be used, if added kernel features need to be enabled or if any Makefile changes need to be made to compile the module.

The actual device driver is then set up to establish initialization, command execution, system file operation execution, cyclic value pull and push and then deinitialization. For example we built a motor driver Kernel Module which is independent of any Android subsystem provision and executed it to run as a kernel module at run time. This kernel module is then integrated in the “/lib/hardware/..” directory and its subsequent path is added in the “etc/modules”.

Android Dependent hardware

Just like with Android independent hardware, we first have to add the provisions in the kernel defconfig file for any additional communication protocol or hardware dependency. Then we’ll either have to integrate the Vendor Library Module (.so) in vendor partition, which would be containing all the appropriate Android framework dependencies and any device driver dependencies, or we can integrate all the files independently, module in the modules partition, android framework files in the sensor, and sensorbase files.

This integration is important for us to utilize any hardware provision in the Android OS, be it in the userspace or for api development. The (.so) file needs to be integrated in the “/sys/vendor/lib64/hardware/..” & “/sys/lib/hardware/..” path with its appropriate provisions in the init.rc file for any boot time configuration. The init.rc file needs to be configured in the “device/vendor/product/..” & “/sys/vendor/bin/hardware/..” path.

For android specific applications the hardware also needs to be board configured, and this is done in the form of device tree overlays, to be integrated in the /boot/..” partition. An example of this would be how I implemented an IMU sensor (MPU6050) to send its accelerometer data to the sensor manager android framework and then built a basic Android Application to view the data in real time in the user space. This is complete integration all the way from kernel driver to sensor manager integration.

iCommuteX’s — Our Implementation of software-defined vehicle with Android at its heart

With iCommuteX, our goal is to make EVs software-defined, revolutionizing the EV ecosystem. Targeting all two-wheeler form factors, iCommuteX integrates the drivetrain electronics with a common software stack through a secure operating system that allows applications to be built on top of it, as seen in Figure 2.

There is an open-source version of the Android Operating System available for anyone to use called the Android Open-Source Project (AOSP). Although it lacks a lot of vendor defined services and features, it enables us to implement our own version of the Android OS and integrate our own vendor specific files to provide a complete Android experience to the consumer. There is also an alternate to the AOSP, Android Automotive Operating System, but due to less Application development support and Kernel driver development support development, the OS is not suitable for faster development time and swift time to market.

Our version of the AOSP on iCommuteX would allow any Android developer to develop applications for the Automobile sector with the knowledge they possess for Smartphone Android Application development. The time has come for the automobile industry to also host a whole plethora of applications, ranging from safety provisions in the form of some ADAS software or some elaborate battery SoC calculation application for the end consumer. With the capabilities of SDV and functionality of Android we can add any hardware to our automobile be it a Camera, a GPS sensor or better yet, a BLDC Motor or a Battery Pack!

The “open-source” aspect of the Linux kernel and therein the Android OS is also what we’re implementing with our product to achieve an open-source software-defined vehicle like never before seen.

About me —

Pirdain Bhalla is a 3+ year embedded systems expert, fueled by a profound love for automobiles. Having crafted electric vehicles from scratch, he now pioneers an Android-infused automobile, merging his passions into a futuristic driving experience. If you like this article and have any feedback then feel free to reach out to me.