With the growing volumes of electric two-wheelers, there is an increasing need to standardise non-differentiating software across various ECUs to shorten development time.
26 Oct 2024 | 7151 Views | By Kollu Nandakumar & Nakul Dhanya BR, Elektrobit
As the adoption of electric two-wheelers increases, the need to standardize non-differentiating software across different electronic control units (ECUs) and vehicle platforms becomes more evident. This approach not only improves software quality but also shortens development timelines and reduces costs through increased software reuse.
Furthermore, it establishes a reliable ...
This is an Autocar Pro Plus article. Subscribe to continue reading.
As the adoption of electric two-wheelers increases, the need to standardize non-differentiating software across different electronic control units (ECUs) and vehicle platforms becomes more evident. This approach not only improves software quality but also shortens development timelines and reduces costs through increased software reuse.
Furthermore, it establishes a reliable partner ecosystem for consistent software maintenance throughout the vehicle's lifecycle. For electric two-wheeler OEMs, embracing this standardization strategy is essential for scaling up production and ensuring long-term value and efficiency in their software systems.
Currently, many OEMs source electronic control units (ECUs) such as motor controllers and battery management systems from suppliers who handle complete software responsibility. OEM-specific requirements, like communication, network management, boot loaders, and diagnostics…, are provided to suppliers as statements of requirements (SOR). Each time the supplier delivers software, OEMs perform acceptance tests to ensure quality.
When sourcing ECUs from multiple suppliers, the costs of implementation and validation increase due to varied supplier practices. Additionally, changes to requirements often lead to increased costs and extended delivery timelines due to high dependency on suppliers. Conversely, for ECUs like body control modules (BCMs) and instrument clusters (ICs), OEMs often plan to develop software in-house to enhance the user experience.
However, developing the complete software stack in-house, including both differentiating and non-differentiating software, can become a bottleneck for scaling up and maintaining the software over vehicle life cycle, leading to significant costs for OEMs.
Through customer interviews, we sought to understand the motives behind various software approaches in the electric two-wheeler (2W) market. Many new players, alongside established ones, aimed to gain an early mover advantage by quickly hitting the road. However, scaling up has posed significant challenges with these initial approaches. OEMs have realized that continuous software updates can enhance vehicle value, maintain their competitive edge, and enrich customer experiences.
Consequently, they are now seeking structured software development and maintenance practices. Inspired by technologies used in passenger cars, questions arise about the feasibility of applying standards like AUTOSAR to 2W controllers, concerns about performance with large software integrations, and the costs associated with standardization.
Together with a leading electric 2W OEM in India, we set out to address the challenges in scaling and maintaining software. Our first step was to thoroughly understand the current software architecture and components. We developed a new architecture that included AUTOSAR standard components and integrated legacy complex device drivers using a wrapper layer.
Kollu Nandakumar, Head of Product Development – Elektrobit India.
This approach allowed us to connect standard components and integrate non-AUTOSAR applications. The results were encouraging we successfully integrated and validated the application on the vehicle, surpassing performance targets (CAN throughput – increased by 13%) and achieving a comparable memory footprint (only 19KB bytes more in binary file). Additionally, onboarding customer teams for these integrations in a short time bolstered confidence in this direction.
Software suppliers possess the expertise to transition from multiple purpose-built ECUs to implementing common software across different ECUs and vehicle platforms. A common misconception is that migrating to AUTOSAR middleware necessitates migrating all application components to AUTOSAR. This assumption is incorrect. We enable the seamless integration of non-AUTOSAR application components with AUTOSAR middleware, ensuring a unified software environment.
Software suppliers can deliver platforms preconfigured and validated based on customer provisions, such as basic software configurations, boot loaders, diagnostics, and CAN network management. This approach helps avoid multiple implementations and validations across different ECUs and vehicle platforms. OEMs can provide these packages to electronics suppliers for integration, streamlining the process and reducing complexity.
The next step is transitioning to a 2Wheeler Operating System (2WOS) to harmonize system abstraction across the vehicle and multiple vehicle platforms. This approach decouples application development from 2WOS development, enabling continuous development across different hardware platforms. By adopting this strategy, we can enhance software quality, reduce development timelines, increase software reuse, lower costs, and create a reliable ecosystem for software maintenance throughout the vehicle lifecycle.
In addition, OEMs can completely rely on partners to develop and maintain the 2WOS (non-differentiating software) throughout the vehicle lifecycle. This allows OEMs to focus on applications and features (differentiating software) that will keep them ahead in the competition. By leveraging this approach, OEMs can ensure that their offerings remain cutting-edge and appealing to customers while benefiting from the stability and reliability provided by standardized, non-differentiating software.
Disclaimer: The views expressed in this article are purely those of the authors.