[Webinar Recap] Making Sense of ASQMS: A New Standard for Automotive Software Quality
|
In this blog, we recap a preview of our recent webinar. Click HERE to watch it in its entirety.
Making Sense of ASQMS: A New Standard for Automotive Software Quality
The Next Automotive Software Standard Is Here. Are You Ready for ASQMS?
The shift toward software-defined, new energy, and intelligent vehicles is transforming the automotive industry. As vehicles become more reliant on complex software to power advanced features, autonomy, and connectivity, the need for robust quality management has never been greater. To meet this challenge, China’s CACPQSP introduced the Automotive Software Quality Management System (ASQMS).
In this blog, we recap a preview of our recent webinar in which hosts Sathihya Ramamoorthy (Jama Software) and Ronald Melster (Melster Consulting GmbH) discuss how ASQMS fits into the standards landscape and why it matters for your teams.
What You’ll Learn:
- An overview of ASQMS, who published it, and why it matters
- Key differences between ASQMS, ASPICE, and IATF, including new lifecycle requirements
- Why ASQMS complements, rather than replaces, ASPICE
- Practical tips for risk-based software classification and lifecycle coverage
- Actionable next steps to strengthen software quality and efficiency
The Above Video Is A Preview – Click HERE To Watch The Entire Webinar
VIDEO TRANSCRIPT PREVIEW
Ronald Melster: Thank you very much for the warm introduction and thank you very much also for inviting me to today’s webinar. I am excited to be here with all of you and to share with you the information about this new standard ASQMS. So let’s get started and explore what the standard means for the automotive world and how we can best adapt to it. For those of you who don’t know me yet, my name is Ronald Melster. In the automotive world, I’m simply known as Ron. As one of Europe’s most experienced Automotive SPICE principal assessors, I have spent nearly three decades helping organizations transform their development processes. Since 2005, I’ve been guiding teams not just to achieve higher capability levels, but to truly understand the why behind effective processes. My journey began in the 1990s when I studied computer science in Berlin and Edinburgh, but I quickly discovered my passion for software engineering and processes. What started as a love for coding evolved into a mission to help teams balance structure with pragmatism.
Over the years, I have had the privilege of working with industry leaders like Bosch, Audi, Porsche, and Here Technologies. One of my biggest achievements was leading a Bosch development division with 7,000 engineers worldwide to capability level 3, proving that even larger teams can embrace systematic improvements. But here’s what I’ve learned. Assessments are not just about ratings. They’re about empowering people, building confidence, and creating sustainable change. Whether it’s functional safety according to ISO 26262, cybersecurity, or process improvement initiatives, I’m here as your mentor, coach, and sparring partner. Maybe you have heard the rumors about this new China standard and you want to learn more about it. You have come to the right place. Let’s start with the name of ASQMS, Automotive Software Quality Management System. That’s the full name of the standard, and yes, it’s a Chinese standard.
We will take that apart piece by piece in this webinar. So the first question is which body exactly published this ASQMS standard? And the answer is the Chinese Association of Consumer Products Quality and Safety Promotion, short CACPQSP. Say this three times. This body is dedicated to consumer rights and their safety and regulates consumer products, including cars. To promote this, they created the ASQMS standard and demand that each OEM selling cars in China needs to be certified according to the standard. So naturally, it applies to Chinese OEMs selling in China, and it also applies to European OEMs wanting to sell cars in China as well. And there’s more. The OEMs are required to request the certificate from their suppliers as well, so it also applies to any supplier tier two or tier one if they want to be part of the supply chain for cars sold in China.
Let’s have a look at why they created the standard and why we need another standard if we have Automotive SPICE or ASPICE. The reason for that is the dependency on software in the car. The complexity is growing rapidly. The number of technical and organizational interfaces gets bigger every day, and the cars increasingly rely on data coming from the outside. Let me share an observation with companies trying to reach capability level 2, according to Automotive SPICE. At the beginning of the project, the capability level is at a stable level 0. Then it takes one, or two, or even three years to get to level 1 and then to level 2. Then the project delivers the result and is finished. And the next project start again at level 0. I call this cycle the chainsaw or zigzag, up and down and up and down. It’s a huge waste of time and effort, and might have led to the ASPICE frustration, which we observed in networks like LinkedIn.
RELATED: Buyer’s Guide: Selecting a Requirements Management and Traceability Solution for Automotive
Melster: Why is that? Because the knowledge is not captured after the project in the company, nor is it standardized or rolled out. Only few companies have managed to establish a stable level 3 with a standard process according to ASPICE. Why can a project not start in a systematic way, aka level 2 or level 3, from the start of the project? This will also reduce the technical debt, which is built up every time a project starts from level 0. There are some of the reasons why this new standard was developed. We need a strong focus on software development. We need to include the software outside the vehicle, and we need to focus on the organization to provide standard process which is applied in each and every project in a similar way. And I might add that we need to take care of the software long after the initial development phase. In a world with rising cybersecurity issues, the software must be maintained and updated if new threats become known. Therefore, ASQMS includes the entire life cycle, including the termination of the software with a systematic deletion of all personal data.
Let’s talk about what’s inside the standard ASQMS and how it’s structured. The standard contains three kinds of requirements, which must be implemented by a company which wants to be certified according to ASQMS. The first one are basic practices, not base practices, but basic practices. They’re mandatory for all automotive development. The second kind of practices are advanced practices. They must be implemented by products which are safety or cybersecurity relevant. And the third type of requirements are recommended practices. They should be implemented by all software projects. The ASQMS standard follows a risk-based approach, which means that not all requirements, which are defined by the standard need to be implemented in each development program. For that, a classification is introduced, the two classes or types of software.
Type II is a software that carries a risk related to safety or cybersecurity, and type I is the rest of the software, which is not related to safety or cybersecurity. For type II software, the cybersecurity or safety-related, the basic practices are mandatory, and the advanced practices are mandatory. The recommended practices are recommended. For type I software, which are not as critical, only the basic practices are mandatory, and advanced and recommended practices are optional. ASQMS clusters the processes into three groups: operational processes, supporting processes, and system management processes. The operational processes include project management and the entire V-model with requirements engineering, architectural design, detailed design and implementation, unit verification, integration, and verification testing.
Apart from these well-known engineering processes, the following processes are defined as part of the operational processes: supplier management, software release, software deployment, software maintenance, user information management, and software termination. So there’s some overlap and some new processes. The supporting processes include some which we already know from Automotive SPICE like configuration management, problem resolution management, change request management, and of course, quality assurance. They even have the same process names. The basic practices may differ in some aspects. And some new supporting processes are introduced like documentation management, equipment and facilities, knowledge management, revenue management, and externally supplied products and services, which includes the management of free and open-source software.
RELATED: Jama Connect® for Automotive
Melster: With the system management processes, something completely new is introduced. They’re not to be confused with the system development processes, which we know from ASPICE. System here refers to the quality management system in the name of ASQMS. So it’s similar to ISO 9001, or ITF 16949, or an information security management system, which gets certified by TSACS. These processes include the scope and the context of the organization, the quality management system fundamentals like quality policies and roles, personnel management, performance evaluation, and the continuous improvement process. In this next section, I will highlight some of the key changes when we compare Automotive SPICE with ASQMS. The first one is the software, which is in the scope of the standard ASQMS. The requirements are not only mandatory for in-vehicle software, which many of us have known for a long time, but also for software outside the vehicle is in scope.
This includes any software in the cloud providing data to the vehicle or to an entire fleet. It furthermore includes any system along the roads, so-called roadside systems. Again, exchanging information with the car or even controlling the behavior of the vehicle. And it applies to the software tool chains which are used for software development and maintenance. The next important change is the lifecycle. Automotive SPICE development projects typically stop with the release of the finished software, whatever this means. The maintenance phase is usually left out or ignored, and really no one thinks about the termination of the software in an ASPICE project. This will change with ASQMS. The entire lifecycle of the software must be covered. This only starts with the initial development phase and must be continued with the ongoing maintenance of the software until the termination of the software. You might want to know, what is the termination more than switching off the software? Well, many software instances store data, oftentimes personal data, and this information must be securely deleted as part of the termination.
Many companies claim that they are ASPICE level 2 certified. However, this is not true. There is no such certification. What they have reached in most cases is a level 2 in one project at a certain time. So this does not apply to any other project in the same company without performing additional assessments, nor is the claim true in the future or after the assessment for the same project. So here’s the last key change I will talk about. ASPICE assessments are statements about projects at a certain point in time. This statement cannot be carried over to any other project in the company, nor is it valid in the future. ASQMS, on the other hand, focuses on the organization. This means that the organization must establish processes to fulfill the requirements and maintain them in each and every development project. This also includes internal auditing activities to make sure that all projects follow the defined rules and methods. And as I’ve mentioned earlier, it also includes processes to provide competence staff to the project. Only then will the company get the ASQMS certificate, which is published by an external auditor.
So what have we learned today about how ASPICE and ASQMS can work together? First, ASPICE integration. ASQMS will not replace Automotive SPICE. Instead, ASPICE can be used to show the conformance with the overall standard processes. And if you are already using ASPICE at the project level, these methods can be scaled to the entire organization using the approach of ASQMS. Second, both standards have shared goals. They’re built on the same fundamental principles, traceability, clear structure, and well-defined roles. Whether you’re working on a senior development project or managing quality across multiple teams, these core elements remain the same. And finally, ASQMS is extending the scope. Here’s where ASQMS goes beyond traditional ASPICE scopes. It adds organizational elements like leadership development, culture building, and personnel focus. The reality, ASPICE and ASQMS work as a partner, not competitors. Automotive SPICE gives you project-level excellence while ASQMS builds the organizational capability to sustain that excellence across all your software activities. Together, they create a comprehensive quality approach that works at every level.
This Has Been A Preview of Our Webinar, To Watch the Full Webinar, Visit:
Making Sense of ASQMS: A New Standard for Automotive Software Quality
Director of Product and Solution Marketing at Jama Software
Experienced in all aspects of the software development lifecycle with a particular focus on requirements management. Currently managing a team of pre-sales solution architects. We are passionate about understanding our client's business challenges and what it takes to solve them. We are innovative, agile, and have the pleasure of working with the best in class solution.
Latest posts by Mario Maldari (see all)
- Mastering Variant Management for Product Line Success - September 26, 2025
- [Webinar Recap] Making Sense of ASQMS: A New Standard for Automotive Software Quality - September 24, 2025
- Jama Software Launches Jama Connect® Availability in AWS Marketplace - September 16, 2025