Nissan Harnesses Aras Innovator to Manage In-Vehicle Software Complexity

The rise of electrification, automation and software-enabled vehicle features has resulted in a notable surge in software complexity and code within cars.

In fact, it is estimated that the average vehicle now contains approximately 200 million lines of code. Consequently, effectively managing in-vehicle software variants, versions and configurations has become a significant challenge for OEMs.

In addition, as the transition to the software-defined vehicle progresses, OEMs must ensure that the software they deploy in their fleets remains up to date. However, achieving this requires the ability to identify the specific software functions and electronics capabilities present in each vehicle within their fleet.

Furthermore, OEMs also are expected to enhance features throughout a vehicle’s lifespan, necessitating a deep understanding of the relationship between functions and mission-critical elements. This ensures that updates do not compromise the functional safety of vehicles and that they comply with regional regulations.

Contrary to what one might assume, not all OEMs currently have the necessary mechanisms in place to effectively manage software variants across their model lineups. According to Paweł Z. Chądzyński, senior director of product management at Aras, one reason for this is the separation between software development and product implementation, with limited interaction between the involved parties. This division can be attributed to the historical emphasis on vehicle mechanical elements over software.

“The questions being asked now are, ‘How do I know what software functions are in this car versus that car? How do I know what electronic capabilities are in this model as opposed to that model? How do I know what functions have a direct relationship to critical safety aspects? What’s the impact of introducing or removing a function on functional safety and the whole vehicle system?’ says Chądzyński.

“The truth is that many OEMs continue to struggle in answering these questions. Even though they likely would never admit it, some kept track of in-vehicle software in spreadsheets, and that was a big problem during the chip supply chain crisis, for example, when OEMs had to remove functions from their vehicles due to the lack of chips,” Chądzyński says.

Nissan Introduces a Software Variant Configurator

As Nissan expands its electric-vehicle production, it has recognized the need for a unified tool that can offer engineers across different teams and domains clear visibility and traceability of its fleet-wide in-vehicle software. The objective is to streamline software design, evaluation and lifecycle management.

The automaker took an interesting approach to developing its platform. Instead of focusing on the overall code and holistic vehicle software functionalities, Nissan broke down each functionality into its individual atomic functions. This allowed it to create a comprehensive library of core software-based functions, encompassing those currently in use and the ones available for activation in vehicle software variants. The platform also tracks the criticality of functions and their interrelationships.

Nevertheless, Nissan soon realized that confining the platform within its own boundaries was insufficient. This conclusion was prompted by the fact that a significant portion of critical software was not developed in-house but by external partners that operate independently with separate development teams and objectives. This situation further complicates the traceability process.

As a solution, Nissan expanded the library to encompass all software functions developed by its partners and ensured visibility of its platform within the partner ecosystem. Importantly, this was achieved without compromising Nissan or its collaborators’ intellectual property, as the library solely focuses on tracking software functions rather than the underlying code.

In addition to registering software functions, the system requires internal teams at Nissan and its partners to notify others when they begin working on a new software function. This ensures that everyone in the ecosystem has visibility into ongoing developments and prevents teams from developing software that is already offered either internally or via a partner. Once a function is developed, the teams must provide information about software testing, supported configurations and the software platforms compatible with the new software.

Moreover, each function in the library is linked to a fully developed MATLAB Simulink model. This model, designed to facilitate system-level design, simulation, automatic code generation and continuous testing and verification of embedded systems, ensures that the function behaves as intended. Test results are recorded in the library database and made available to users.

Ultimately, the software variant configurator encourages collaboration and facilitates the collective determination of new vehicle functions that need to be developed. This demonstrates Nissan’s understanding of the vital role partnerships play in the future of SDVs, recognizing that sharing information and fostering collaboration are keys to success. This notable step shows a departure from the traditional protectionist attitude of OEMs.

Benefits

Nissan’s software variant configurator runs on Aras Innovator, a low-code platform designed for comprehensive product lifecycle management (PLM). According to Aras, this configurator has enabled Nissan to streamline the development of new applications by effectively modeling business issues and making modifications to software with minimal coding requirements. The benefits of the platform include:

• Resource optimization and accelerated software development, resulting in improved speed and quality.

• Enhanced traceability and control over functional safety, software testing and compliance with regional requirements.

• Reduced likelihood of human error compared to manual input methods such as spreadsheets.

• Decreased complexity and duplication, eliminating unnecessary redundancies.

Why Aras Innovator?

Traditionally, PLM platforms were used to manage the lifecycle of products beginning from the implementation phase, specifically from the point the bill of materials is defined.  However, in today's digital era and with the growing prominence of software-defined products, there is an increasing need to initiate PLM more upstream, at the product-planning stage. This is exemplified by Nissan’s requirement to trace software-related information even before development and implementation in its vehicles.

The challenge is that most PLM platforms were not designed to effectively trace the type of data generated during the product-definition or design-intent phase, such as a list of requirements.

This is where Aras distinguishes itself, as its platform does not have predefined assumptions about data format. Due to the understanding that certain services must always be available regardless of the data and processes being managed, Aras developed abstraction layers that make its platform highly adaptable while providing a user-friendly low-code implementation of PLM.

Lastly, Aras's focus on open APIs, connectivity and low-code approach allows for platform updates without disrupting the code customizations developed by its customers, such as Nissan’s software-variant configurator.

“No PLM deployments are the same. Some vendors say they have everything out-of-the-box, but a few years later, you have to change what you got because it doesn’t quite fit your business model anymore or the changes in technology,” Chadzynski says. “The resiliency of the Arras (Innovator) is that it can be configured and applied to existing and evolving business and technology data models. It can easily incorporate new representations of design data and abstraction levels.”

After conceptualizing the software-variant configurator, Nissan conducted an evaluation of the platforms currently utilized in other areas of the company. During this assessment, Aras Innovator emerged as the most suitable and flexible environment for implementing its solution.

“Ten years ago, this idea (software-variant configurator) was so grand and difficult that I couldn’t find any capable solutions. Today, Aras Innovator allows step-by-step realization of these goals via its ‘easy to build,’ ‘easy to align’ and ‘easy to connect’ characteristics,” says Hiroaki Nemoto of Nissan.

Regarding the partnership with Nissan, Chądzyński adds: “Aras has several engagements with automotive OEMs that use Aras’s platform for all kinds of aspects of the automotive design and manufacturing processes, but I believe that what Nissan did is unique in terms of what needs to be done moving forward with electric vehicles and the software-defined vehicle. They focused entirely on the software content of the vehicle as opposed to the mechanical aspects.”

Nissan’s Approach to SDVs

When devising strategies for the transition to SDVs, OEMs typically prioritize the updating of vehicle architectures, often driven by the introduction of new EV platforms. However, Nissan has taken a different approach.

Rather than solely focusing on the vehicle aspects, Nissan acknowledges the equal significance of the organizational aspect. In fact, having the necessary hardware in vehicles holds limited value if OEMs lack the means to effectively manage software versions, develop new software and deploy over-the-air updates. Surprisingly, only a few OEMs seem to prioritize the management of vehicle software variants.

In many SDV projects, the emphasis is placed on a single platform version, with the management of different versions considered a secondary step. Consequently, the new software features developed by OEMs are unlikely to be implemented in vehicles already on the road due to either a lack of backward compatibility or the overwhelming challenge automakers face in updating their entire vehicle fleets.

“There are several aspects of the change that OEMs are undergoing, and Nissan’s management focused on people and their feedback first, allowing them to start developing new processes, pick the right tool and build data modeling,” Chadzynski says. “And this is something that other companies are struggling to do. There are organizational and cultural shift problems in most of the traditional OEMs today.”