The " Formel Q Ca Capability pability Software" contains contractu con tractually ally agreed agreed requirements from t he V Volks olks wagen G Grou roup p for t he purpose purpos e of ensuring th e quality quality o f pr ocesses ocesses and hence components in the procur eme ement nt and su pply c hain.
December 2014 nd
2 Fully Revised Edition Edition
© Volkswagen AG - Version 2 05.12.2014
2
st
-
September 2007
nd
-
December 2014
1 Edition 2 Fully Revised Edition
This brochure is available to the suppliers only electronically on the Volkswagen Group B2B platform www.vwgroupsupply.com in in the version valid at the time. under www.vwgroupsupply.com
Currently valid and binding documents are generally available on the aforementioned B2B platform. The German edition of the Formel Q Capability Software is binding. Property of Volkswagen Volkswagen AG Any reproduction, use or distribution is only permitted for the supplier within the supply chain of the companies in the Volkswagen Group. Copyright protected. All rights reserved by the Volkswagen AG. Issued by:
Volkswagen AG Group Supplier Quality Assurance Electric/Electronic Software Quality Assurance Letterbox 1477/0 38436 Wolfsburg Germany
© Volkswagen AG - Version 2 05.12.2014
3
Foreword The increasing digitization of vehicle functions requires robust processes for the development of software-based vehicle components.
Stable and mature development processes are the fundamental requirement in order for each software intensive component and thus the entire vehicle to meet the Volkswagen Group quality standards before production start-up. Here our suppliers for software-based vehicle components and their supply chain of crucial significance. Volkswagen can only achieve the zero defect target together with its suppliers. The commitment to customer satisfaction is in particular focus here. In order to eliminate difficulties at the start-up of new models, the process capability level throughout the entire supply is of particularly high importance. The 2nd edition of this brochure takes into consideration the quality strategy for functional safety and software as agreed in the Manufacturer Software Initiative (HIS) and the VDA and adds to specific requirements of the Volkswagen Group. The "Formel Q Capability Software" is binding for development suppliers, direct suppliers (1st tier) and their sub-suppliers for software-based vehicle components. It applies across all brands of the Volkswagen Group as well as worldwide subsidiaries. To improve communication, information in multiple languages and Volkswagen Group documents can be found on the Volkswagen Group B2B Platform at www.vwgroupsupply.com. The supplier is obligated to comply with the valid Volkswagen Group requirements and must also ensure the implementation in its supply chain. This applies in particular to the quality requirements for software. The present edition is binding by contract from the date of publication. Wolfsburg, December 2014
Dr. F.J. García Sanz
F. Tuch
Management Board, Group Purchasing
Head of Group Quality Assurance
Volkswagen AG
Volkswagen AG
© Volkswagen AG - Version 2 05.12.2014
4
Tabl ble e of Con ontents tents 1 2 2.1 3 3.1 3.2 3.3 3.4 3.5 3.6 4 4.1 4.2 5 5.1 5.2 5.3 5.4 6 6.1 6.2 6.3 6.4 6.5 6.6 6.7 7 7.1 7.2 7.3 8 8.1 8.2 8.3 8.4
Quality Management Agreements Purchased Parts ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 5 General Regulations ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 6 Further Applicable Applicable Documents ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐6 Introduction ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 7 Purpose ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐7 Objectives ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐7 Activities for for the Evaluation of the Software Quality Capability ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 7 Significance and Validity of the Rating Results ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐8 Activities in the Product Life Cycle ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐9 Contact ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐9 Supplier Self ‐Disclosure ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 10 Introduction ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 10 Procedure ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 10 Software Potential Analysis ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 11 Introduction ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 11 Implementation ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 11 Evaluation and Supplier Rating ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 12 Pending Status ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 13 Software Assessment ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 15 Introduction ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 15 Scope of Assessment ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 15 Quality Capability ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 16 Supplier Rating ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 17 Implementation ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 18 Assessment Report and Self Qualification of the Supplier ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 19 Adoption and Exchange of Assessment Assessment Results ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 20 Software Technical Revision ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 21 Introduction ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 21 Implementation ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 21 Evaluation ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 22 Sub‐Supplier Management ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 23 Introduction ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 23 Stipulations ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 23 Procurement Phase ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 23 Product Development Phase ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 23
8.5 Changes in the Supply Chain ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 24 9 Project‐Accompanying Quality Assurance ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 25 9.1 Introduction ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 25 9.2 Implementation and Actions Actions ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 25 9.3 Quality Status Report ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 26 10 Escalation ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 27 11 Reimbursement ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 29 11.1 Introduction ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 29 11.2 Technical Factor ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 29 11.3 Additional Agreement Agreement ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 30 12 Documentation of Supplier Visits ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 31 13 List of Abbreviations ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 32 14 List of Tables ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 33
© Volkswagen AG - Version 2 05.12.2014
5
1Q Quali uality ty Ma Management nagement Agr Agre eements ment s Pur urch cha ased Pa Part rts s The Customer-specific quality requirements of the Volkswagen Group are specified in several Formel Q volumes. The following figure shows the structure of the quality assurance agreement for purchased parts (Formel Q) with its different volumes.
© Volkswagen AG - Version 2 05.12.2014
6
2 General General Re Regu gulati lation ons s For simplification, the responsible department (i.e. Software Quality Assurance) of the Volkswagen Group companies is referred to as the Customer.
2.1 2.1
Further Appli cable Documents
Volkswagen Group quality documents (www.vwgroupsupply.com) in their current version:
current information on requirements of field defective parts for the Volkswagen Group,
Formel Q Konkret,
Formel Q Capability,
Formel Q New Parts Integral,
„KAP_5_Critical Project and Series Supplier Escalation“,
Functional Safety Development Guideline (EFS, LAH.000.9000),
Group Basic Requirements for Software (KGAS, LAH.893.909),
Supplier Self Report (LiSA “Lieferantenselbstauskunft“) of the Manufacturer Software Initiative
(HIS “Hersteller Initiative Software”) (www.automotive-his.de (www.automotive-his.de)) and
This
HIS Exchange Formats for Software Assessments (www.automotive-his.de). information
and
forms
can
be
found
in
electronic
format
on
the
B2B
platform
www.vwgroupsupply.com and www.vwgroupsupply.com and refer themselves further to additional standards. VDA Volumes and Automotive Standards ((www.vda-qmc.de www.vda-qmc.de): ):
Automotive SPiCE® Process Assessment Model
In addition, the technical delivery specification and standards of the Volkswagen Group applicable to the particular product, such as minimum shelf life of components as well as legal requirements, provisions, etc. for example, also applies. In general it is mandatory to develop according to the state-of-the-art.
© Volkswagen AG - Version 2 05.12.2014
7
3 Intro Introducti duction on 3.1
Purpose
The regulations in the "Formel Q Konkret" and "Formel Q capability" documents apply to series and development of software-based vehicle components for supplier evaluation. The "Formel Q Capability Software" governs the evaluation of the quality capability and quality performance of suppliers and development suppliers for software-based purchased parts and software components.
3.2
Objectives
Upon successful award of contract to a supplier for the development of software-based vehicle component or software components within a vehicle project, the supplier commits itself to perform the software development process for the development project according to the quality requirements in the “Group Basic Requirements for Software”. The requirements in the “Functional Safety Development Guideline” apply additionally to the suppliers of safety-relevant purchased parts. This document is a Volkswagen-specific embodiment of the ISO 26262 standard. In order to evaluate and ensure the quality capability and quality performance, the Customer conducts various QA activities for software development. These are primarily based on the Automotive SPiCE ® Assessment Model or refer to this standard. The leading of the activities is assumed by specifically trained members of staff from the Customer (hereafter referred to as “Assessors”) in order to fulfil the requirements in the ISO 15504-2. There are always at least two Assessors involved in the activities at the suppliers. Quality improvement measures are derived from the performed QA activities where necessary with the principle objective of product and cost optimization though improved processes and quality. Furthermore, the evaluation outcome from the performed QA activities as a whole has a direct consequence on the procurement process (Corporate Sourcing Committee - CSC) of the Customer. The result forms one part of the supplier rating.
3.3 3.3
Activ ities for the Evaluation Evaluation of the Software Quality Capability Capability
Various activities are performed leading either directly or indirectly to supplier rating. As for direct supplier ratings, the outcome is driven by the following activities:
1. 2.
the preparation of a Supplier Self-Disclosure Self-Disclosure (LiSA) (see Chapter 4), a Potential Analysis of the software development processes (PN) (see Chapter 5) or
© Volkswagen AG - Version 2 05.12.2014
8
3.
an Assessment of the software development processes (SWA) (see Chapter 6).
For that matter the first point is an activity performed by the supplier itself or by third parties. The other two activities are performed by the Assessors. The following activities result in a supplier rating indirectly through the escalation process (see Chapter 10): 1.
a Technical Revision of the software development processes (TR) (see Chapter 7) or
2.
an outcome from a Project-accompanying Quality Assurance (PQS) (see Chapter Fehler! Ve Verweisquelle rweisquelle konnte nicht gefunde gefunden n werden. werden.). ).
If serious deficiencies are determined during any of these two activities, it can be followed by an escalation process (see Chapter 10), which can eventually lead to a supplier rating. If unscheduled measures (see Chapter 11, Paragraph 3) must be performed due to poor quality performance and/or capacity of the supplier, the expense could be reimbursed.
3.4 3.4
Significance and Validit Validit y of the Rating Rating Results Results
Before the award of contract for the new developments, a change or further development of a software- specific vehicle component or a pure software component, a rating of the software quality capability of the supplier must be present. According to the Formel Q Capability, there are the "A", "B" or "C" ratings. This rating is valid for the entire Volkswagen Group. A supplier with the "C" rating is not quality-capable and will not be considered in an upcoming award of contract in the CSC process. Suppliers with a "B" rating will only be awarded the contract with terms of improvement (see the following chapter). The goal is to qualify as an "A" supplier. Suppliers with the "A" rating can be awarded the contract without restrictions. As a rule, an "A" rating is valid for four years, a "B" rating two years. A new evaluation will be performed at the discretion of the Customer. A rating corresponds to the software development for a controller category (product group) at a development location. The following are the existing categories:
Powertrain,
Chassis,
Restraint Systems,
Instrument Cluster,
Body / Infotainment,
Driver Assistance Systems,
© Volkswagen AG - Version 2 05.12.2014
9
General,
Software Projects.
If changes occur to the controller category or the development location, a re-evaluation is to be made. Existing ratings can be adopted for new developments in the same controller category at the same location. After a re-evaluation, only the most recent result is applicable to new contract award. This result is therefore also applicable to new contracts for existing projects that are being developed at a location within a controller category, even if they have already been evaluation once.
3.5 3.5
Activ ities in the Product Life Cycle
The activities described in this document for the evaluation of the software quality capability are associated with the phases of the product life cycle, as shown in the following diagram. Aw ard of Contract
SOP
Supplier Selection/
Product / Process
Pre-development
Development
Series Production
Af ter Sales
PN LiSA SWA A SW TR PQS Escalation Escala tion Process If a supplier needs to be qualified due to poor quality, Project-accompanying Quality Assurance or Technical Revision will take place during the course of the project. All QA activities can be used throughout the product life cycle to for suppler evaluation.
3.6
Contact
Whenever documents are to be sent to the Customer as required by this document, unless otherwise agreed, the following central e-mail address is to be used:
[email protected]
© Volkswagen AG - Version 2 05.12.2014
10
4 Sup Suppl plier ier Se Selflf -Dis iscl clos osur ure e 4.1
Introduction
The Supplier Self-Disclosure (LiSA) is a standard specified by the HIS. The supplier must conduct an evaluation of its development processes according to the Automotive SPiCE ® Standard (HIS Scope). Evaluations must be submitted for projects already in series production (development in past) and projects currently in development. In addition, a forecast from the supplier on how it will advance itself further in the future is also needed.
4.2
Procedure
There are generally two points in time within the product development process, at which a LiSA must be provided to the Customer. The first point is before the award of contract as part of the inquiry process, the second upon the delivery of the first B-sample. Moreover a LiSA can be requested by the Customer at any given occasions (e.g. critical projection situation or conclusion of a improvement program) at any time. Software Assessments carried out in the respective project according to Automotive SPiCE ® can serve as a basis for the LiSA. Alternatively, the project quality assurance can create estimation from the continual process control in progress. If required, the supplier must make use of external assistance. If the self-Assessment corresponds to a "C" rating (see Ch. 6.4), the supplier may be directly rated with "C" without any activity performed by the Assessors from the Customer. In the case of a development project, the supplier must consult the Assessors about an improvement program.
© Volkswagen AG - Version 2 05.12.2014
11
5 Sof Softw twa are Pot ote ent ntial ial Analysis Analysi s 5.1
Introduction
In preparation for the award of contract to series and development suppliers, for which no valid quality rating is available at the Customer regarding the software development process, a Potential Analysis of the software development process (PN) is to be performed. This potential analysis serves as the evaluation of the quality capability of the supplier with respect to the components, systems or software components inquired by the procurement or the technical development from the Customer for potential award of contract. The experience of the suppliers from similar products or projects and the potential in the core processes of the product and software development are evaluated. These core processes are
project management
quality assurance
configuration management
software development (from system requirement management to coding) and
testing (from unit to system test).
If the inquired (software) component is safety-relevant in terms of functional safety, these will be classified as additional requirement and evaluated as such.
5.2
Implementation
The software potential analysis is conducted by Assessors at the development site of the supplier. The duration of a potential analysis spans one to two days. The supplier and the Assessors must coordinate a common date for the Potential Analysis according to the procurement request. To avoid delaying the contract award process, the Potential Analysis must take place within the following two weeks. The potential analysis follows a standard agenda, containing the following points:
introduction,
analysis of the project management process,
analysis of the quality assurance process,
analysis of the configuration management process,
analysis of the software development processes,
analysis of the testing processes,
preparation and presentation of the report by the Assessors and
© Volkswagen AG - Version 2 05.12.2014
12
acknowledgement of the results (including rating)
Implementation evidences from development projects are used for the evaluation of the processes. If these (also as plans) are not yet available for the Customer project, evidence from similar projects may also be consulted. In addition, evidences from process specifications (e.g. process descriptions, documented procedures, plans, checklists, templates) valid corporate-wide at the supplier or from similar development projects are evaluated. A Potential Analysis of the software development processes results in a rating of the supplier in the "B" or "C" categories. A possible "A" rating can only be given with a software Assessment later in the project. Besides the rating, the final report contains also a list of found weaknesses to be resolved in case of a contract award. Prior to the award, the supplier must initiate an improvement program.
5.3
Evaluation and Suppli er Rating
Each of the analysed processes is evaluated separately. The requirements on the processes are derived from the Automotive SPiCE® standard and "Best Practices". The result is a degree of fulfilment for each process, divided into 3 levels. The subdivision and the meaning of the levels are shown in the following tables. Table 1: Rating of the evaluation blocks Levell Fulfiment Leve (per process)
Meaning Me aning of the rating of an evaluation evaluation bloc k The process fulfils fulfils its its objective. Both process specifications and application
Fulfilled
Partly fulfilled
Not fulfilled
n/a
examples were evident.
achieved . The weaknesses found The objective of the process is only partly achieved. pose a risk to the attainment of the process and hence the product quality.
fulfiled . There were serious weaknesses The objective of the process is not fulfiled. found in the process specifications and their execution. The process is not applicable to the project.
The overall result is generated from the average of fulfilment levels of the individual processes.
© Volkswagen AG - Version 2 05.12.2014
13
The overall result is mapped to the capability levels "B", "C" or a pending status. The classification and the significance behind are described in the following table: Table 2: Criteria for the ratings in Potential Analysis
Rating Rating
Definiti De finiti on for contract awa award rd decisions The supplier can be used. used .
B
Fulfiled
The rating in the "B" category is the premise for the award of the contract without any additional agreements. The supplier can be used conditionally. conditionally . Weaknesses concerning the development processes were detected at the supplier. The weaknesses pose a risk to the attainment of product quality.
~
Partly
To eliminate the risk, the supplier must agree to a target
fulfiled
agreement as contractual basis, in which the quality objectives and consequences of failure to achieve the quality targets are defined in consultation with the supplier. No rating will be in effect until the agreement is made. The supplier remains in the pending status. The supplier cannot be used. used .
C
Not fulfiled
The expert opinion of the Assessors reveals that elementary development processes at the supplier are inadequate or not recognisable.
Besides averaging, a downgrade to "C" is also possible if at least one process is classified as "not fulfilled". In this case, requirements for this process are not met, with a significant impact on product quality leading to an unacceptable risk for this process. The decisions shall be based on the analysis.
5.4
Pending Status
As described, a supplier in pending status must acknowledge a target agreement, in order to be considered for a contract award. In that respect, the supplier commits itself to create and implement a qualification program in order to resolve the found weaknesses. The qualification program must be coordinated with the Assessors. If the acknowledgement of the target agreement and the coordination of the qualification program is not sumbmited before the contract award decision or latest four weeks after the announcement of the result, the supplier will be downgraded to “C". This results in no award of contract.
© Volkswagen AG - Version 2 05.12.2014
14
If the acknowledged target agreement has been submited at the time of the award of contract decision, the supplier will be rated "B" and a nomination could be made. In this case, the Assessors would define the dates for follow-up activities. This includes among others the verification of the qualification program (see Chapter 9) and the Software Assessment after the delivery of the first Bsample. The rating and the evaluation by the Software Potential Analysis is not inevitably the same as that of the subsequent Software Assessments (see Chapter 6). The analysis of Software Assessments based on Automotive SPiCE® is significantly more detailed and based on evidence from the development project for the Customer.
© Volkswagen AG - Version 2 05.12.2014
15
6 Sof Softw twa are As Assessm sessme ent 6.1
Introduction
Based on the requirements from the Customer (see KGAS), an Assessment of the software development process (SWA) is conducted for software-based vehicle components and externally supplied software modules. The Assessment is used to assess the software quality capability and performance of the supplier in the implementation of the product and process requirements contractually defined. Process Assessment according to ISO 15504-2 with the Process Assessment Model (PAM) Automotive SPiCE® is used for systematic and reproducible analysis, As part of the Automotive SPiCE® Assessments the software development process of the project will be analysed and verified by means of examples. Verified sample deficiencies are interpreted as deficit in quality performance and systematic failures as deficits in quality capability.
6.2 6.2
Scope of Assessment
The following processes are considered in the Assessment as recommended by HIS:
Project Management (MAN.3),
Quality Assurance (SUP.1),
Configuration Management (SUP.8),
Problem Resolution Management (SUP.9),
Change Request Management (SUP.10),
System Requirements Analysis (ENG.2),
System Architectural Design (ENG.3),
Software Requirements Analysis (ENG.4),
Software Design (ENG.5),
Software Construction (ENG.6), Software Integration (ENG.7),
Software Testing (ENG.8),
System Integration (ENG.9),
System Testing (ENG.10) and
If applicable, Supplier Monitoring (ACQ.4).
Depending on the project, the scope can also vary, e.g. the system processes may not be assessed in pure software projects. If the supplier outsources any development activities (e.g. the development of software modules or the implementation of testing activities), the process Supplier Monitoring (ACQ.4) is also assessed in addition.
© Volkswagen AG - Version 2 05.12.2014
16
If the concerned (software) component is safety-relevant in terms of functional safety, these will be classified as additional requirement and evaluated as such. This means that, for example, the correct application of required normative methods in software development and testing can be used as a criterion for quality capability and performance.
6.3
Quality Capabil Capabil ity
The processes defined in Chapter 6.2 are each verified against the process attributes of Level 1 and 2 in Automotive SPiCE®. They are evaluated in the following four levels: Table 3: Rating of process attributes
Process Attribute Ratings (PA)
Fulfiment Leve Levell
Evaluation Eva luation of the fulfil ment of requireme requirements nts
F
86% - 100%
Requirements fully fully achieved achieved
L
51% - 85%
Requirements largely largely achieved achieved
P
16% - 50%
Requirements partly partly achieved achieved
N
0% - 15%
Requirements not achieved
From the rating of process attributes (PA), the process capability of assessed processes is calculated as shown in the following table Table 4: Process capability levels
Process
Process
Capability
At tr ib ut ute e
Level 0
PA 1.1
Evaluation N P
Not (N) or partly (P) achieved
L F
Largely (L) or fully (F) achieved
Level 1
PA 1.1
F
PA 1.1
Fully (F) achieved
Level 2
PA 2.1
L F
Largely (L) or fully (F) achieved
L F
Largely (L) or fully (F) achieved
PA 2.2
© Volkswagen AG - Version 2 05.12.2014
17
6.4
Suppli er Rating
From the evaluation of the individual processes, a correlation to the contract award relevant rating of "A", "B" or "C" -supplier is derived, as shown in the following table. Table 5: Project rating based on process capability levels Requirements on Rating
process capability capability
Conclusion / Actions
level
A
All processes reach
The supplier is quality c apable apable
Process
The evaluation identifies no major weakness at the supplier
Capability Level 2
regarding the software development process.
The supplier is conditi onally quality capable The evaluation identifies weaknesses in product quality and/or in process quality in one or more processes. The identified process weaknesses present a potential risk to All processes reach
B
at least Process Capability Level 1
the achievement of product quality, which must be mitigated with additional supplementary actions. An improvement program is to be implemented by the supplier in order to achieve the required process capability as soon as possible and to develop itself into an A-supplier. Due to the low quality performance, an escalation to Level 0 is started additionally in accordance with “Critical Project and Series Supplier” (see Chapter 10).
The supplier is not q uality capable Major weaknesses in both product quality as well as At least one
C
process has Process Capability Level 0
process quality are identified in one or more processes. An immediate improvement program is to be started and implemented in order to resolve the weaknesses in the upcoming deliveries. Due to the low quality performance, an escalation to Level 2 is started additionally in accordance with “Critical Project and Series Supplier” (see Chapter 10).
A rating r ating will take effect at the moment when the Assessment rresult esult is a announced. nnounced. This rating is also relevant for the award of contract.
© Volkswagen AG - Version 2 05.12.2014
18
6.5
Implementation
To be able to evaluate the process capability and the quality performance for the Software Assessment, software development processes are expected to be established in the project. There are three paths which lead to a supplier rating:
the Supplier Self-Disclosure,
a single Assessment or
a split Assessment
As basis for a single Assessment, Assessment , a completed development cycle with a released sample status as a result is used as a general rule. Such a sample status is submitted latest before the first B-sample. Depending on complexity, language and country, a coherent Assessment lasts 4 – 7 days. Assessments , it is assumed that causal and thus temporal dependencies exist between the In split Assessments, processes in a development process. For example, a software test will only be performed when the software requirements have also been compiled. For split Assessments, more part Assessments are arranged, where a reduced process selection is assessed. A possibility is, for example, the arrangement in three phases with the following process selection: Planning phase: phase: At the start of the B-sample phase, processes such as project management, configuration management and quality assurance are assessed. These processes form the basis for a successful project execution and must be established already at project start. Specific Spe cific ation phase: phase: Upon completion of the specification phase, which depending on the project lies in the middle of the B-sample development cycle, the processes from system requriements analysis to software architectural design are assessed. This is the basis for the subsequent testing phase. Testing phase: phase: Prior to delivery of the B-samples, the test processes from unit testing to system testing are assessed. At this time, the problem resolution management and change request management processes are also assessed becase, from experience, sufficient supporting evidence for the process execution exist at the end of the testing phase. When assessing the specification and testing phases, it is required that the supporting processes from the planning phase remain in focus and be continuously evaluated to be able to determine the final evaluation. In addition, the processes which are evaluated with Level 0 in previous part Assessments must be re-evaluated. If no improvement in the re-evaluated processes can be seen, the expenses of the part Assessment will be reimbursed.
© Volkswagen AG - Version 2 05.12.2014
19
The practical execution of a split Assessment and single Assessments is scheduled according to the project needs and, as a general rule, announced with at least four weeks' notice. The supplier should take the Assessments into consideration during the planning of the project. The final and therefore contract award relevant result of the split Assessment will be given after the last part of the Assessment. If a supplier is rated "C", a follow-up Assessment must be conducted in the later course of the project to monitor and confirm the successful implementation of the improvement measures. If the required improvement is evident, the supplier shall be rated "B". Basically, the interview for each process takes place initially up to Process Capability Level 1. If the supplier has the potential to be an “A“-supplier or is involved in safety-relevant projects, Process Capability Level 2 will be assessed in a second Assessment.
6.6 6.6
Assessment Report Report and Self Self Qualification Qualification of the Supplier
The result of the Software Assessment with the rating and the substantial deficits is documented on the first two pages of the Assessment Report. The Assessment results will be announced directly at the end of the Assessment. At the conclusion of the Assessment, the report will be signed by the Assessors and the person in charge from the supplier in duplicate as acknowledgement. Within the following approximately four weeks, the Assessors will prepare a detailed Assessment Report, which describes the deviations in each process in detail. In addition, on enquiry, the supplier will receive the anonymous report, containing the rating of the processes and base practices without the project details (see HIS-exchange format). If deviations are identified in the report from the Assessors, the supplier must use them as a basis for the development and implementation of the improvement measures.
In addition, the supplier must conduct a comprehensive analysis of deviations found to identify any systematic problems. The supplier shall create subsequently an improvement program, in which the implementation of the actions is planned with deadlines and responsibilities. The improvement program must be submitted to the responsible Assessors for review and agreed upon. The supplier could be demanded to report regularly on the progress of implementation for each improvement program. The format and frequency of the status report is determined by the responsible Assessors (see Chapter 8). The supplier is responsible for the improvements in the project (process and product). If the necessary knowledge is not available within the company, the supplier must employee external aid (eg. consultants).
© Volkswagen AG - Version 2 05.12.2014
20
In the case of a "C" rating, a follow-up Assessment is needed in the current project. In this Assessment, at least those processes previously assessed with Level 0 must be re-assessed. In addition to check whether the weaknesses have been corrected that have not performed on Level 0 to process depreciation, the termination of which nevertheless was necessary but.
6.7 6.7
Adopt ion and Exchange of Assessment Result Result s
Before an Assessment is conducted, it is checked whether an Assessment has already been performed by the Customer at the respective supplier. As described, the results have a validity period. However, if the general conditions, such as development location, ECU category or similar, have changed, a re-Assessment is necessary. The decision to adopt an Assessment result that was not generated by the Customer Assessors is made by the responsible Assessors in individual cases. While there is in principle the possibility for the exchange of results in the HIS Exchange Format, this does not infer an obligation for the Customer to adopt results from Assessments. The responsible Assessors prove in each case whether a previous Assessment is adequate and applicable to the current project prior to the Assessment implementation.
© Volkswagen AG - Version 2 05.12.2014
21
7 Software Soft ware Tech chni nical cal Re Revisi vi sion on 7.1
Introduction
The Software Technical Revision (TR) is another quality assurance method in the framework of Volkswagen Group's quality strategy. While a Potential Analysis and the Assessment usually take place at defined milestones in the development project, the TR can be performed at any time during the development and in running series. The TR is also conducted by the Customer Assessors. The Technical Revision general has an urgent cause. Triggers for a TR are, e.g.:
Non-compliance with the obligation to inform the Customer in discovering deviations from specification (run-time behavior, resource consumption, software errors).
Relocation of development activities to other locations was not reported.
Product features deemed insufficient in the context of the system test.
Poor quality performance due to unstable internal / external processes.
Unstable process in the subordinate production process chain.
Specified requirements were demonstrably not implemented.
To monitor the compliance to an Additional Agreement.
Preventive measures without direct trigger or cause.
During the TR, it will be examined specifically, why problems could occur, how the supplier analyses the problems and which corrective actions the supplier has taken to solve the problem. A TR may also be carried out as preventive measure without measure without any direct trigger or cause. One reason may be the confirmation of previous Assessment ratings without performing a full Assessment.
7.2
Implementation
The Development Process Technical Revision can be announced to the management, quality management or project management of the respective supplier at short notice on the day before visit. The duration is usually one to two days. An agenda shall be sent by the Assessors with the notification. During a TR, special emphasis is placed on the analysis of the "Problem Resolution Management" process. This other supporting processes and some of the development processes will also be considered. Additionally targeted code analysis or code reviews may also be performed. Following the TR the resulting report will be presented on site. It contains where necessary the found weaknesses, an evaluation of the risk and the further course of action.
© Volkswagen AG - Version 2 05.12.2014
22
An improvement program will be agreed by the management of the supplier to eliminate the deficits. In doing so, the management of the supplier assure face to face with the Assessors the implementation deadlines for the improvement measures bindingly in writing.
7.3
Evaluation
The result of the TR is an evaluation of the quality performance. In doing so, conclusions on the process capability and product quality in the present project are also inferred. At the end of the Development Process Technical Revision, the overall result will be presented in the form of a traffic light system, as described in the following table. Table 6: Meaning of a traffic light in a Software Technical Revision
Evaluation
Meaning Mea ning / Act ions
No risks were risks were identified risks – There are no further actions are required.
Risks were identified – series production or development is not urgently Risks affected, but the problems must be resolved for upcoming (software) deliveries. Actions to eliminate the process weaknesses and product defects must be defined in order to achieve the necessary software and product quality.
Ac ute ut e ri sk s to series production or in the development phase were identified. An immediate improvement program based on the weaknesses found is to be started. In addition, the program "Critical Project and Series Supplier" will also be initiated (see Ch. 10).
If it emerges, that the supplier is responsible for the problem, the TR activities of the Customer Assessors will be regressed (see Ch. 11).
© Volkswagen AG - Version 2 05.12.2014
23
8 Sub-Sup Sub-Suppl plier ier Ma Management 8.1
Introduction
The Sub-Supplier Management from the Customer serves to identify possible risks in the supplier chain during the contract awarding process. In the product development phase and in series production, the supply chains must be monitored and assured. The Sub-Supplier management encompasses all parts of the supply and processing chain, and all planned and implemented development activities and services, which can have an impact on the required product quality, such as:
outsourced process steps, remote development sites, development partners, commissioned third parties in the development site,
testing service provider, calibration laboratories, testing laboratories and
other service providers who may have an impact on the product quality or the development
process.
8.2
Stipulations
Direct suppliers (1st tier) are 100% responsible for the overall project management and the deliveries from the sub-suppliers with whom they engage. The supplier must ensure that all risks within its supply and process chain are identified, evaluated and resolved through appropriate measures on one’s own responsibility. With reference to software development, the supplier must ensure that especially the requirements from the documents KGAS and the Formel Q Capability Software are also fulfilled at sub-suppliers.
8.3
Procu rement Phase
The Sub-Supplier Management is integrated into the procurement process. When submitting a quotation, the direct suppliers are requested to disclose the (software) supply and process chain. The direct supplier is also obligated to evaluate of its suppliers independently before awarding the contract. It must ensure already at the beginning of the development, that the sub-suppliers possess quality capability comforming to requirements as specified by the Customer. The Customer can demand supporting evidence, such as Supplier Self-Disclosure.
8.4
Produ ct Develop Develop ment Phase
The supplier must monitor and ensure the product and process quality at its sub-suppliers. This also applies to processes outsourced to sub-suppliers, such as test process. The Customer reserves the right to inspect the control documentation and to verify the supplier ratings, e.g. with joint on-site evaluation with the direct suppliers at sub-suppliers.
© Volkswagen AG - Version 2 05.12.2014
24
Such on-site evaluation is performed with the QA methods described in this document. A poor evaluation of the sub-supplier directly influences the rating of direct supplier as it is responsible for the entire project and thus for its sub-suppliers.
8.5
Changes in the Supply Chain
Changes in the supply chain or the outsourcing of processes must be disclosed to the Customer in writing in advance and may lead to a re-evaluation of the (sub-) suppliers. The Customer reserves the right to verify the modified sub-supplier structure (see also VW 01155 "Vehicle Parts; Approval of First Supply and Changes").
© Volkswagen AG - Version 2 05.12.2014
25
9P Proj roje ect-Accompanying ct-Acco mpanying Qualit Quality y As A s s u r anc an c e 9.1
Introduction
In projects where the "A" status is not achieved, regular monitoring of the quality performance of the supplier development is required by the Quality Assurance of the Customer. The core idea of the Project-accompanying Quality Assurance (PQS) is the inclusion of the Customer QA in the quality assurance activities at the supplier. This includes at least the regular provision of project and QS status information to the Customer QA and also possibly joint quality assurance activities such as reviews. In order to better support the supplier, the Customer can name specially trained external personnel during the transitional phase, who takes over the collection and reporting of project and QS status information from the supplier. The supplier bears the costs incurred. This continues until the supplier has established its own qualified personnel.
9.2 9.2
Implementation Implementation and Actio ns
The general conditions for the Project-accompanying Quality Assurance are defined with the supplier in a joint kick-off meeting. Besides the Customer Software QS, the component responsible personnel (“Bauteilverantwortlichen”) from the Development and Quality Assurance may also be involved in the kick-off meeting. Within this kick-off meeting, the joint quality assurance activities are defined, depending on the strategic importance of the project. These include:
definition of the quality objectives to be overseen,
Software Assessments,
Potential Analysis,
Technische Revisions,
code analysis,
reviews of work products in the development project,
reviews of the improvement program and its implementation,
reporting and
escalation paths.
The activities required are documented with due dates and responsibilities in a quality management plan. Based on the commitments in the QM plan, the supplier is obligated to establish a regular quality status report.
© Volkswagen AG - Version 2 05.12.2014
26
9.3
Quality Status Repor Repor t
After the start of the Project-accompanying Quality Assurance, it is defined jointly with the suppliers, which metrics must be regularly forwarded to the Customer to determine the project status. The due dates are agreed upon together with the supplier. The supplier commits to send the agreed metrics before the agreed due dates to the Customer Quality Assurance. A planning (due dates and target value) must be agreed agree d with the Customer for each metric. The right is reserved to review the metrics on site at the supplier. Non-compliance in the reported metrics against proven metric on site or non-delivered status reports can result in an escalation of the suppliers in the “Critical Project and Series Supplier” program.
© Volkswagen AG - Version 2 05.12.2014
27
10 Escalation If necessary actions and improvement programs required by the Customer are not timely and sustainably implemented or if repetitive errors are detected, an escalation in accordance with the “Critical Project and Serires Supplier” program will be initiated on the Customer’s side. The "Critical project and series supplier" program is started in the first instance when deficient quality performance is observed in a Technical Revision or Project-accompanying Quality Assurance. It can also be started, if:
a supplier has received an appointment with additional agreement, but yet does not achieve the agreed quality objectives,
an Assessment concludes with a “C” rating,
it is identified during a TR, that the supplier is is responsible for the problems in development
and series production,
the due dates confirmed by the suppliers for the implementation of the quality assurance activities are not met or
quality objectives agreed in the c context ontext of Project-accompanying Quality Assurance Assurance are not achieved.
The escalation is divided into four stages. Table 7: Escalation in the "Critical Project / Series Supplier" program
Stage
0 1
Responsible
Conclusion / Actions
(Customer) QA Staff/ Assessor QA Sub-Department Manager
There were serious weaknesses identified. The supplier must initiate and implement an improvement program. The supplier does not succeed in implementing the improvement actions in due time and with the necessary quality. The supplier is not capable alone to implement the
2
QA Department
improvement actions in due time and with the necessary
Manager
quality. The assistance from external resources with the necessary knowledge is mandatory.
3
QA Division Manager / Top Q
The supplier is unsuccessful in implementing the measures or finding remedies to the problems. The supplier could be rated "C" provisionally, meaning no award of new contracts.
© Volkswagen AG - Version 2 05.12.2014
28
The de-escalation in stages 0 - 2 can be performed by the Assessors, when the necessary improvement measures have been successfully implemented and problems rectified. The deescalation from the 3rd stage can only take place officially over the Top Q panel at the Customer.
© Volkswagen AG - Version 2 05.12.2014
29
11 Reimbursement 11.1 Introduction With Reimbursement, the incurred travel expenses and subsistence expenses for the Customer Assessors are charged to the supplier. The Reimbursement is performance-based, depending on needed effort (working days of the Assessors at the supplier), hotel and travel expenses as a lump sum for domestic and abroad. A Reimbursement is raised whenever the supplier generates additional expense for the Customer in the form of Re-assessments, Technical Revisions or Project-accompanying Quality Assurance. Additional expenses in this regard re gard are all activities that do not take place due to an initial inspection by the Customer. A Reimbursement is raised when
a Re-assessment is necessary because weaknesses were detected in the first Assessment;
existing development activities or those already awarded to a supplier are outsourced to
development locations different from that named in the contract („Nomination Letter“) and thus a re-evaluation of the new development site is required;
a new evaluation of the process capability is required because important processes are modified, the supply chains are changed or process steps are outsourced;
a Technical Revision is conducted due to problems emerge at the suppliers;
a Project-accompanying Quality Assurance is necessary.
Preventive measures conducted by the Customer are not reimbursed. The same applies to any actions that might arise from the Customer’s own interest to fulfil its obligations to ensure quality and were not induced by the supplier.
11.2 11. 2 Technic al Factor
The Technical Factor expresses in general the proportion, in which the supplier is responsible for defects in its series parts, TF = (claims accepted by the supplier) / (examined claims) Software quality deficiencies are a potential source of error and can therefore be used to form the
Technical Factor. If a "C"-supplier does not execute the improvement measures consistently and is still rated with “C” towards the start of series production, the Technical Factor in the case of a softwarebased error is set to "1". Hence the supplier is 100% responsible for the subsequent claims. The supplier is free to prove that the process defects do not led to errors.
© Volkswagen AG - Version 2 05.12.2014
30
11 11.3 .3 Addit ional Agreement Agreement Further Reimbursement can be raised due to non-performance of Additional Agreements, which were necessary as a prerequisite for the nomination of a supplier. This approach serves to secure the implementation of the improvement program, which is necessary on the basis of the weaknesses found. In the Additional Agreement, the improvement measures are scheduled and recorded with a consequence for the supplier (e.g, as contractually agreed cash payment), if the due dates are missed. Consequences and due dates are defined individually for each project.
© Volkswagen AG - Version 2 05.12.2014
31
12 Docu ocumenta mentati tion on of Supp upplier lier V Visi isits ts Upon the conclusion of a Software Potential Analysis, a Software Assessments or a Technical Revision, a report including the rating will be generated on site. These ratings, if applicable, with the weaknesses found and the specified immediate actions are summarized in a two-page report. This report is signed by the Assessors and the persons in charge of the project at the supplier in duplicate as acknowledgement. One copy remains with the supplier, one with the Assessors. With a Software Assessment and if applicable also other measures, a detailed report or a detailed minutes will be compiled afterwards. These detailed reports and the two-page reports already provided during the visit serve as a basis for the supplier in the preparation of the improvement program.
© Volkswagen AG - Version 2 05.12.2014
32
13 Lis Listt of Abb Abbrevia reviatio tions ns ACQ
Process group “Aquisition“ according to Automotive SPiCE®
B2B
Business 2 Business
CSC
Corporate Sourcing Committee
EFS
Functional Safety Development Guideline (“Entwicklungsrichtlinie Funktionale Sicherheit”)
ENG
Process group “Engineering“ according to Automotive SPiCE®
HIS
Manufacturer Software Initiative (“Hersteller Initiative Software”)
KGAS
Group Software Basic Requirements (“Konzern Grundanforderungen Software”)
LAH
Requirement Specification (“Lastenheft”)
LiSA
Supplier Self-Disclosure (“Lieferanten Selbstauskunft”)
MAN
Process group “Management“ according to Automotive SPiCE®
PA
Process Attribute a Automotive SPiCE®
PN
Software Potential Analysis (“Software Potentialanalyse”)
PQS
Project-accompanying Quality Assurance (“Projektbegleitende Qualitätssicherung”)
SUP
Process group “Support“ according to Automotive SPiCE®
QA
Quality Assurance
SWA
Software Assessment
TF
Technical Factor
TR
Software Technical Revision
© Volkswagen AG - Version 2 05.12.2014
33
14 L Lis istt of Tabl Table es Table 1: Rating of the evaluation blocks ............................................................................................... ............................................................................................... 12 Table 2: Criteria for the ratings in Potential Analysis ............................................................................ 13 Table 3: Rating of process attribu attributes tes..................................................................................................... ..................................................................................................... 16 Table 4: Process capability levels ......................................................................................................... ......................................................................................................... 16 Table 5: Project rating r ating based on process capability levels ................................................................... 17 Table 6: Meaning of o f a traffic light in a Software Technical Revision ..................................................... 22 Table 7: Escalation in the "Critical Project / Series Supplier" program ................................................. 27
© Volkswagen AG - Version 2 05.12.2014
