SDV Continuous Delivery Framework

Software-defined vehicle or SDV is a term that is frequently found in the automotive industry these days. SDVs are platforms for mobility and user experience that are capable of being updated and upgraded over time, as well as providing feedback and data about usage. They also integrate well with the environment for a complete user experience.

Yet, many cars available on the market today are not providing this very SDV experience. While we are seeing more complex and capable infotainment and navigation systems, and some integration with the ecosystem, most carmakers are not providing continuous feature delivery through over-the-air update capabilities.

In order to achieve this capability and use it for a better customer experience over time, iProcess designed an SDV continuous delivery framework to support improvements in processes, methods, tools, organization, etc.

First of all, it is essential for this framework to understand that every feature request is treated as a change. It does not matter if a feature is modified or if a new feature is introduced - even a newly introduced feature is treated as a change. Changes are all funneled through a clear change request process documented and traced by tickets.

There is a variety of sources that can actually trigger a change:

• Product Engineering is the group that looks into product improvements for the future. This team usually looks into the glass ball to find out what customers of tomorrow want.
• Service Engineering is the group that deals with the problems that customers have today. They can request improvements to serviceability as well as the user experience.
• The Factory is working on the production of the cars and is consistently gaining importance around software and feature development in order to improve the production process.
• Marketing is the department that uses a variety of channels to increase interest in the product. Therefore, they utilize feature requests combined with marketing campaigns.
• Regulatory Changes are not as frequent as other change requests, but over the lifetime of a car, they can appear - especially when the product is approaching a new market.
• The Research and Development Engineering Department has a very strong understanding of the product and its behavior in the real world and provides firsthand feedback and change requests to its performance and user experience.
• Advanced Development is working on next-generation technologies and will provide those when they are ready to become part of the current product, in order to increase efficiency or performance, or decrease cost.
• The Customer is the main user of the product and gathers the most experience as well as corner cases. By integrating customer feedback directly into the change management process, this vast amount of information is directly utilized within the framework.
• The Management of a car company is ultimately responsible for the direction and success of the company and therefore has a direct impact through change requests. Some companies have more involved upper management in this process than others.

Each of those sources gets documented into a ticket that will be reviewed by a leadership board. This leadership board shall contain members of all involved parties in the development and testing of the product. The decision options of the leadership board are: do it now, do it later, or don’t do it.

When a change request is approved for implementation, it is handed over to a feature development team. This team is a matrix-organized, cross-functional team led by the system integration engineer in charge of the feature. This engineer assembles the feature team according to the complexity and size of the feature by bringing together developers and test engineers from the involved parties and components across hardware, software, and mechanical design domains.

It is essential that the validation teams (both component and system) are already involved in the early stages of the feature development process, in order to be prepared and up-to-date on upcoming changes, as well as to provide input into the development process.

A program manager is engaged with the feature development team to synchronize progress with the rest of the feature development.

The feature development team works in iterations, depending on the discipline. Software iterations can be two-week sprints, while hardware iterations may span three-month sprints. Continuous synchronization between software and hardware development is the responsibility of the integration engineer.

This development cycle can vary greatly in duration - it can range from a few days up to many months. The new feature is continuously tested against its integration in the complete product to avoid regressions created during the process. When the feature team decides that the new development is completed and has passed all relevant targeted testing as well as system regression testing, it presents the feature back to the leadership board.

The leadership board reviews the change and the supporting evidence and will either send it to the next release sprint or back for rework.

Out of all the features approved for a release, the release management team assembles the release train. Over the course of two weeks, this release train is fully validated on performance, regression, integrity, and packaging.

When the sprint ends, the release train will “leave the station” with all the features that have successfully passed testing. Some features might be sent back for rework, while the others proceed into the release.

The company-wide database is filled with release trains whenever they leave the station. This database contains all software versions with their history, maturity, and approval status. It also contains information about all vehicles in the fleet, including their real-time configuration and software status.

A program manager assembles a release team together with a release manager and support from service engineering. When motivation arises for a new software update - whether by regulatory requirement, technical issue, recall, or improvement - this team creates a target selection for rollout based on criteria such as location, configuration, or vehicle age.

The update is continuously monitored for update performance, feature performance, and regressions across the entire fleet. If an issue is observed, it will trigger the change process through the service engineering channel of this framework.

This iProcess SDV Continuous Delivery Framework generates the powerful ability to utilize software-defined vehicles to the maximum by providing continuous improvement and enhancement of the user experience, as well as enabling feature development in a high-paced, iterative environment.