Automotive and Mobility is a notoriously treacherous field when it comes to software development, both in the technical and managerial sense. Many automotive players are aware of the advantages that come with strong software development and are now taking drastic steps to improve performance. But this comes with big risks and challenges. Still, the leading concerns in automotive software development are quality, security, and safety.
Since automotive software development speeds up, with China leading the charge and Western companies racing to keep up, we met with the top experts from Bamboo Apps to discuss the state of the industry and the best strategies for navigating its many challenges.
Here is our interview with Alexander Antonuk, Head of Strategic Delivery & Operations at Bamboo Apps, and Maxim Leykin, Chief Technology Officer, PhD. During their years in the industry, they have worked with world-famous brands such as Jaguar Land Rover, Mitsubishi Electric, and Škoda. Following their recent interview at Automotive Testing Technology International, we are sharing some of their insights on the challenges of software development in the automotive industry.
There is this popular opinion that most automotive manufacturers are still behind when it comes to their software development practices. Would you say it is true?
Alexander: For many large automakers, the statement is still true.
Innovating in automotive means navigating plenty of requirements that add complexity and extend development and testing cycles.
“First off, I would emphasise the importance of functional safety and cybersecurity — the two critical aspects that can significantly impact the development cycle.”
Automotive software must be designed and tested to ensure that it operates correctly and safely in all possible scenarios. Hence the role of functional safety. For example, software in a braking system must be designed to respond appropriately to sudden stops or emergency situations, such as when a pedestrian steps into the vehicle’s path. To achieve this, engineers carry out rigorous testing and validation.
Additionally, functional safety standards such as ISO 26262 require extensive documentation and traceability throughout the development process, further adding to the development timeline. To mitigate cybersecurity risks, automotive software developers adhere to strict security standards and best practices, including secure coding practices, secure communication protocols, and regular vulnerability assessments.
Thus, we still witness software development processes similar to the development of car spares and components — they use the same approaches with rigorous, time-consuming validation, which is fully justified. Luckily, sometimes, these processes can be optimised to keep up with the speed of the modern IT industry — especially when working on automotive products that are less demanding on security practices: vehicle tracking applications, fuel efficiency apps, maintenance apps, etc.
Is there anything Automotive can learn from other industries?
Alexander: The first and perhaps the most important thing is flexibility. This is what will enable you to recognise mistakes in time, change your approach, and start doing things differently. You have to think like a startup. Minimum viable product (MVP) is a term that comes from the startup world. It means to make a quick release of a product with just enough features to be usable by early customers, who can then provide feedback for future product development. This approach can be successfully applied in the automotive industry as well.
For example, when Ford first launched its Sync infotainment system, it was a minimum viable product with limited features. The system was designed to be simple and easy to use, with voice-activated controls for music and phone calls. This allowed Ford to get the system into the hands of early adopters, identify areas of improvement, and implement them over time.
The second thing is to be open to feedback from customers, instead of being isolated from them. You can create an environment where you get feedback from customers through different channels: social media, feedback on Google Play & App Store, email, or customer interviews. And it is important not only to collect their opinions, but also to improve the product based on it, in order of priority.
Maxim:
“It would be great to promote openness, transparency, and unification.”
Now, the majority of operating systems, frameworks, and technologies used in Automotive are proprietary, they are licensed only to OEMs and are closed for the wider development community. It increases the entry barrier, complicates testing, leads to incompatibility issues and market fragmentation. As an example, the implementation of CAN bus and OBD still differs among cars from different OEMs. Also, emulators are available for a very limited number of car models.
Let’s say an automotive company wants to rethink its entire approach to software development, including the underlying operational model. How should it go about it?
Alexander: They need to start looking at the product not in terms of a set of functionalities, but in terms of the value that this product brings to the end user and the problem that is solved by your product. The product roadmap and the teams that will be responsible for different feature sets will be formed from this. This way, the complex system can be broken down into smaller parts that benefit the user.
Of course, this approach to development requires a significant change in the mindsets of decision-makers. And it would be necessary to agree on the new rules of the game inside the company. Managers at the top should promote such practices, not discourage them. Thus, it will put everybody on the same wavelength and the process of development will become more effective with new methodologies.
Besides, in my latest book, I explore strategies for enhancing the effectiveness of automotive software engineering teams. Get your copy today to dive into the insights.
Which architectures are the best for Automotive, in your opinion?
Maxim: There is no universally best architecture. Architecture is chosen on the initial stage of the project depending on many factors, including but not limited to:
- size and complexity of the project;
- tech stack: frameworks and languages;
- supported devices and OS versions;
- scalability and security requirements.
Among the most commonly used architectural patterns, there are the Clean Architecture on Android, layered MVC, or Viper on iOS. For automotive applications, we typically use the AUTOSAR Layered Architecture which consists of the following layers:
- Microcontroller Abstraction Layer (MCAL) — a software module that directly accesses the on-chip microcontroller (MCU) peripheral modules and external devices that are mapped to the memory. Makes the upper software layer independent of the microcontroller (MCU).
- Complex Drivers — this layer is used for complex functions not found on other layers. This layer accesses the microcontroller (MCU) directly. Fulfils the special functions and timing requirements needed to operate complex sensors and actuators.
- ECU Abstraction Layer — an interface with the MCAL (including the external device driver); provides access to peripherals and devices irrespective of whether they are inside or outside the microcontroller (MCU), as well as an API for interfacing with the microcontroller (MCU) (port pins, interface type).
- Runtime Environment (RTE) – this makes AUTOSAR software components (SWC) independent of their mapping to a specific ECU.
- Services Layer — provides basic services and basic software modules for applications.
What software development toolchain do you use?
Maxim: Creating next-level software experiences involves many moving parts and requires many different tools. A software development toolchain enables development teams to perform complex tasks. The tools comprising a toolchain usually run consecutively, with each tool’s output serving as the input for the next tool. However, some DevOps tools are used in parallel to the flow of the DevOps pipeline.
Being a service company, we are flexible enough to use the toolchains required or recommended by our clients. If we are free to choose, we typically use Android Studio/xCode for mobile development, Atlassian JIRA for project tracking, Gitlab for a source code repository and CI/CD, MS AppCenter for internal build distribution, and Figma for UI/UX design. Other tools (like Jenkins, Appium, Cucumber, etc.) can be added on demand.
What best practices do you follow when working on automotive solutions?
Alexander: If we are talking about the process part, at the beginning of the project, we offer clients a design thinking session to better understand their product. Together with the client, we go through the product definition and ideation phases and prototype a future solution based on that.
If the project has many unknowns and some technologies need to be researched, we conduct a discovery phase. That is when we do the research on the selected technologies and create a proof of concept. If we and the client are satisfied with the results, we move on and start the development of a complete product based on them.
Also, we always advocate the implementation of CI/CD in the technical process, which will allow us to constantly deliver and test new builds.
“We always encourage the use of Agile approaches and are ready to help the client understand them. At the same time, we realise that using an Agile framework in its pure form may not suit all companies. Therefore, we offer to combine and take the best of both worlds by using elements of both Agile and Waterfall methods in development.”
Maxim: Continuous integration is important and often underrated. Establishing a proper CI/CD process from the very beginning of the project significantly improves quality and maintainability, increases release rate, and simplifies fault isolation.
E.g. if there are many commits to the integration branch and as a result of all these commits and merges the build gets broken (a fairly common situation), properly configured CI will provide exhaustive information about the issue immediately and automatically, whereas investigating the issue without CI can take several hours of work.
Automated tests, in turn, are an important part of the CI chain. They are developed once they are executed after each commit. Such frequency just can’t be achieved with manual testing. And again, this aligns well with iterative processes and Agile practices.
From the technical side, we establish a code review process and introduce quality gates, such as static code analysis, post-deployment checks, etc. We also try to provide sufficient unit and automation test coverage.
How can companies decouple hardware and software development? How easy is this to do?
Maxim: I would say decoupling is a very powerful principle in general, because it allows modern hardware and software to remain maintainable despite high complexity. It is not always easy, but it is really worth doing. The key idea behind decoupling is to follow the single responsibility principle as much as possible and to have well defined interfaces between the interacting components.
Specifically decoupling between hardware and software is typically achieved through 2 mechanisms:
- mapping of function blocks to different devices;
- association of symbolic links to the device’s I/O.
A system architect starts by defining application(s) logic without caring much about the way it will be distributed/executed on the different devices. Then it is necessary to select the devices and map the execution logic (function blocks) to them. The program is calculating automatically the information that needs to be exchanged between the devices. Finally, we need to associate the symbolic links from the logic to the I/Os. In case you want to change the hardware device, you simply have to repeat this process again on the new hardware.
How important is it to combine overarching systems engineering with software development?
Maxim: Systems engineering and software engineering have evolved as distinct disciplines with different terminologies, focuses, and concerns. As software becomes an increasingly important element in all systems, there is a growing need for these disciplines to develop effective ways of collaborating.
“I would say that every hour spent on system engineering activities can potentially save much more hours on software development and bugfixing.”
There are many examples when insufficient or superficial system engineering leads to critical performance, stability, or scalability issues being revealed on a post-development stage, which then require significant effort to eliminate (up to a full redevelopment).
How can one discover software problems during the development process without sacrificing too much time, cost, and quality?
Maxim: First, it is crucial to have a proper QA process established, including performance, security, and regression testing. This allows engineers to identify potential issues at an early stage and take action to prevent or eliminate them for a reasonable cost and with minimal negative impact.
Then, software must be properly architectured and documented. All engineers should understand the existing architectural concept in order to follow it when adding new features or modifying the code. One more rule is to make software as simple as possible and avoid overcomplications which lead to the waste of time and money.
Alexander: We suggest that the client think in terms of MVP, where they select the most important functionality from the full set of features. And then expand the functionality of the solution iteration after iteration. The smaller the scope, the less risk and the more predictability you are working with.
This will allow the team to focus on higher-priority tasks and release a basic version of the product in a short period of time. The client will be able to start early user testing and get feedback fast. This way, you will avoid the additional cost of redesigning the product from scratch and instead create what users really need.
About Bamboo Apps
Bamboo Apps is an automotive software development company based in Tallinn, Estonia. With over 20 years of experience in Automotive, the team has earned the trust of the likes of Jaguar Land Rover, Mitsubishi Electric, Škoda, and Rinspeed. Bamboo Apps’ expertise encompasses car connectivity, HMI design, shared mobility, and fleet management.
The team follows specialised safety guidelines and standards for human-machine interfaces, ensuring compliance with series production requirements. Their knowledge of not only standards, but also automotive operating systems, protocols, and frameworks makes the team a reliable partner for leading OEMs worldwide.
