Establishing a software factory to support developer-centric system design

In the era of electrification, it’s not just fuel that makes a car go. Software is essential to its operation, safety, and performance. Only 10 years ago, high-end vehicles contained an already significant 50-80 electronic control units (ECUs). Furthermore, today’s premium cars that feature advanced driver-assist systems (ADAS) can have as many as 150, executing millions of lines of code. According to McKinsey & Company, software developed for powering in-vehicle infotainment, vehicle safety, and connected services will reach $14 billion by 2025 and $18 billion by 2030.

However, as the software content in a vehicle increases, so does complexity of the development. Automakers presently must adhere to extremely stringent governmental regulations around safety and reliability, data privacy, and security. Combine these requirements with the imperative to deliver innovative features and functionality to market before your competitors, and it becomes clear that the traditional way in which OEMs have operated is unsustainable.

What Is the software factory?

It’s common for OEMs to employ specialists to work in silos with specialty tools. Undoubtedly, they use slow manual processes that inhibit the exchange of data between teams. This approach is no longer sufficient–a new approach that encourages collaboration, efficient data sharing, consistency and governance is essential.

Therefore, it is here we enter the concept of “software factory.” This is an organized and scalable approach to software development based on collaboration, efficient data-sharing, and standardized processes.

The aims of a software factory are to help to eliminate data silos that can result in miscommunication and errors. At the same time, the process works on accelerating development, improving product quality and reducing the cost of design and development. The way to do this is with a repeatable, well-defined process for delivering applications to production.

Here are some key components of a well-oiled software factory for automotive embedded software development:

• Standardized tools and methodologies. Using standardized, developer-focused tooling and methodologies lowers barriers to entrance for engineers. This in turn eliminates the need to employ only highly specialized experts. Not only does this help to break down data silos, it allows you to hire from a wider pool of developers. Since all of the software a development team uses will likely come from different vendors, open interfaces and support for a wide array of protocols and standards is key.
• Automated workflows. Developers need tools that provide consistent, automated workflows and remove time-consuming, error-prone manual tasks. Automation frees up developers’ time. By the same token, this enables them to focus on innovating new features. They can add value and deliver a shift left in delivery of released software.
• The ability to iterate and improve. Agile methodologies help to improve quality and address potential problems early in the development cycle. Similarly, adopting continuous integration and continuous deployment (CI/CD) practices enables incremental changes feedback is gathered and as requirements evolve.
• A model-based approach. Model-based practices and generative tools enable you to test, verify, and implement new functionality over the vehicle’s lifespan. Leveraging a digital twin is an essential component of model-based design and development, particularly by ensuring effective data-sharing and traceability throughout the development process.
• Service-oriented architectures. In service-oriented architectures, the goal is to be able to move functions around easily, combined with a centralized and/or zonal architecture enabling provision of headroom in a reduced number of powerful ECUs to accommodate new functionality, as needed without cost increases at every ECU. Over-the-air updates enable OEMs to extend functionality throughout the lifespan of a vehicle without requiring a complete redesign. In fact, service-oriented architectures provide the centralized, scalable compute power to support such updates.
• Bus-level separation. In a collaborative environment, it is important to realize that protecting software IP is top of mind. At the tool level, there must be plug-ins, APIs, and cloud-level services that provide sufficient separation and stable interfaces between tools.

These components are the foundation for a software factory that enables OEMs to bring software design in-house and reduce the reliance on highly specialized tools and experts.

Capital VSTAR: A cornerstone of the software factory

A complete AUTOSAR-compliant solution, Siemens Capital VSTAR enables developers to work in a virtual ECU environment where they can perform rapid and early debugging on a laptop using standardized developer-centric tools. Instead of using a physical chip, they can test out and verify functionality with a digital twin, iterate early and frequently, and leverage a digital thread to move seamlessly between the virtual and embedded environment. Developers benefit from:

• Increased performance with developer-centric tooling
• Automation and virtual validation for right-the-first-time design
• The ability to reuse design components to support future MCU and CPU development
• Extensive functional safety and cybersecurity capabilities
• Multi-core support

With these capabilities, Capital VSTAR supports overall efforts to bring embedded software design in-house. Obviously this is to establish a software factory to eliminate data silos, reduce errors, and streamline embedded software development.

Learn more about Siemens solutions for the Automotive industry here and download our white paper “Bring automotive embedded software development in-house with Siemens“. Also, check out the following webinars:

• On-demand Webinar: Bringing automotive embedded software in-house

• On-demand Webinar: Continuous Integration and Continuous Deployment (CI/CD) of ECU software