Issue management method applied to the automotive vehicle infotainment unit

Description

ISSUE MANAGEMENT METHOD APPLIED TO THE AUTOMOTIVE VEHICLE INFOTAINMENT UNITField of invention

[0001] The present invention relates to the technical field of the automotive industry, focusing more specifically on the development of an innovative methodology for managing issues in automotive vehicle infotainment units, in order to obtain a robust and error-free application in its programming, ensuring its improved use for the user and its reliable production.Background of the invention

[0002] An infotainment unit is a system that combines information and entertainment functionalities. Also known as a multimedia center, usually located on the dashboard, its purpose is to improve the driver and passenger experience, providing convenience, communication, and fun while using the vehicle. The concept of an in-car infotainment system dates back to the 1980s, with the first simpler electronic systems, such as digital radios and basic interfaces for audio devices like CD players and AM / FM radios. However, it was from the 1990s onwards that what would become a multimedia center began to take shape, with the integration of additional functions such as navigation and phone connectivity. In the 2000s, the first multimedia systems with touchscreens and the ability to integrate, in addition to audio control, GPS navigation functions and vehicle configuration emerged. This period marked an important transition: instead of simply providing vehicle information or basic entertainment, it began to offer deeper integration with the use of digital technologies. Throughout this decade, connectivity with external devices, such as MP3 players and, later, smartphones, became an increasing requirement. In the 2010s, the concept of the multimedia center expanded considerably, and more sophisticated interfaces emerged, with higher-definition screens, voice recognition systems, and integration with communication platforms, allowing drivers to connect their smartphones directly to the vehicle's multimedia center, offering access to a range of functionalities, such as maps, music, calls, and messages, in a more fluid and secure way. In recent years, multimedia centers have incorporated more advanced technologies, such as virtual assistants, artificial intelligence to enhance navigation, entertainmentpersonalization, and even automation of vehicle settings. Furthermore, digital platforms have become increasingly integrated into the car, providing a real-time connected experience with the internet and remote vehicle control via smartphone. The screens became more integrated into the dashboard, with sophisticated graphical interfaces and multi-layered gesture and touch control functionalities, creating a more immersive experience for the driver and passengers.

[0003] With all the observed advancements and increased sophistication of multimedia systems, there has also been an increase in software issues between these systems and their electronic control units (or ECUs). Manufacturer validation departments typically began employing various conventional tools to report these software issues to infotainment teams. Since the other electronic control units did not present as many issues, no workflow was developed for the issue management process. These conventional tools and the absence of an issue management methodology made it difficult for the technical team to triage all issues, identify redundancies in different documents generated by the various tools, report issues to the equipment supplier, and monitor the progress of solutions.

[0004] Thus, the current methodology of employing various tools for reporting software issues in infotainment units prevents adequate monitoring and practical and functional resolution of these issues, resulting in wasted time and the possibility of programming errors even after using the usual tools, increasing the cost of the product and reducing the supplier's rejection rate.

[0005] Searching the state of the art patent literature, the following documents were found:

[0006] Document CN118351734 describes a configuration-based training and fault processing system for managing software issues by simulating faults in a physical subsystem and correcting them using specific instructions.

[0007] Document EP3926505 describes a method for managing software query information related to legal approval of software for a vehicle by acquiring traceability information from a device. This information, managed by the vendor, includes software verification reports.

[0008] Thus, considering the state-of-the-art solutions, it is evident that none of them has been able to solve the technical issue associated with the use of various tools to report software issues and the absence of an information management methodology for the adequate collection of all issues identified in various validation domains, subsequent classification and merging of redundant issue areas, avoiding opening the same issue more than once, and allowing it to be reported to the supplier. Furthermore, in the solution proposed in this invention, a standardized report, including tables and graphs, is used to track the progress of software issues.

[0009] In view of the points presented, the importance and urgency for a technical solution capable of overcoming the currently existing gap in this technical field is clear. Taking these points into account, the present invention aims to offer a favorable solution to the issues previously presented.Objectives of the invention

[0010] The present invention, in a first objective, aims to provide an issue management methodology for the proper collection of all issues identified in various validation domains, subsequent classification and merging of redundant issue areas, avoiding opening the same issue more than once, and allowing it to be reported to the supplier.

[0011] Another objective of the invention is to create a clear workflow for the validation areas, engineering team, and supplier for the creation, triage, and resolution of issues.

[0012] Another objective of the present invention is the creation of an online spreadsheet adding tabs for each validation area containing all the relevant information necessary to understand and open an issue for the supplier, enabling all areas to raise issues together and the engineering team to triage all issues using only one file, making triage faster and more objective, avoiding opening issues for the supplier without information.

[0013] Another objective of the present invention is to provide an issue management methodology that establishes a clear workflow from the release of a software to the resolution of issues and a new release of the software.Summary of the invention

[0014] In this way, the present invention solves such issues of the prior art through a management method applied to the automotive vehicle infotainment unit comprising thefollowing steps:a) software version, where the supplier releases new software with the new implementation and the previously corrected open issues, this step being the supplier's responsibility. The data input for this step is represented by manufacturer specifications and open issues, and the data output for this step is represented by the new software version;b) software validation, with the validation of the new software version and verification of the corrected points, this step being the responsibility of the electro-electronic engineering validation team / quality team. The data input for this step is represented by the new software version, and the data output for this step is represented by the issues;c) main issue list, defined by the online spreadsheet created by adding tabs for each validation area containing all the relevant information necessary to understand and triage the issue for the supplier. The validation area will add issues to the main issue list file with videos, records, and all the necessary details to triage the issue. This step is the responsibility of the quality team. The data input for this step is the issues found during the previous step, and the data output for this step is represented by the issues to be triaged;d) triage, where the engineering team triages the received issues and ensures that the issues are relevant with all the necessary information to pass on to the supplier, under the responsibility of the engineering team's issue manager. The data input for this step is represented by the main issue list defined in the previous step, and the data output is represented by issues opened by the supplier;e) new issues opened by the supplier, where the engineering team will open new issues found and reopen issues that should be corrected, under the responsibility of the engineering team's issue manager / electronic engineering validation team. The data input for this step is represented by the issues identified during the previous step, and the data output for this step is represented by issues opened by the supplier;f) Vehicle issue tracking meeting, represented by a weekly / daily meeting, on demand, to discuss open issues of severity A, B, P, and S, where: severity "A" is any issue that causes high customer dissatisfaction, severity "B" is any issue that causes low customerdissatisfaction, severity "P" is any issue that causes a technically immobilizing failure, severity "S" is any issue with potential safety impact, and data resolution and status update, under the responsibility of the engineering team's issue manager. The data input for this step is represented by the open issues for the project, and the data output is represented by the updated status of all listed issues in a defined red state, i.e., the issue that does not have an identified root cause and is under analysis by the supplier; and g) issue reports, represented by standard reports with established graphs and tables to present the status of software issues throughout the project, under the responsibility of the engineering team's issue manager. The data input for this stage is represented by the status of open issues, and the data output for this stage is represented by graphs and tables.

[0015] All technical features of this patent application will be immediately recognized and appreciated by those skilled in the art. These features will be detailed further below.Brief description of the drawings

[0016] The present invention will be described in more detail after the presentation of the drawings, in which:- Figure 1 presents a flowchart of the proposed method.Detailed description of the invention

[0017] Before the invention is described in detail, it should be understood that it is not limited to the specific steps of the described method, as these may vary. It should also be understood that the terminology used herein is only for the purpose of describing particular embodiments and is not intended to be limiting. It should be noted that, as used in the descriptive report, claims and abstract presented, the singular forms "a", "an", "the" and "the" include singular and / or plural referents, unless the context clearly indicates otherwise. Furthermore, it should be understood that, in the case of parameter ranges delimited by numerical values being provided, the ranges are considered to include these limiting values.

[0018] It should also be understood that the embodiments disclosed herein should not be understood as individual embodiments that would not relate to each other. The characteristics discussed with one embodiment should also be disclosed in connection withother embodiments shown herein. If, in one case, a specific characteristic is not disclosed with one modality but with another, a person skilled in the art would understand that this does not necessarily mean that the characteristic is not intended to be disclosed with the other modality. A person skilled in the art would understand that the essence of this request is to disclose the characteristic also for the other modality, but that, for the sake of clarity and to keep this descriptive report within a manageable volume, this has not been done. Furthermore, all the concepts and elements presented here are easily understood by people skilled in the art, not limited only to the nomenclature defined here.

[0019] The present invention comprises a management method applied to an automotive vehicle infotainment unit comprising the following steps:a) software version, where the supplier releases new software with the new implementation and the previously corrected open issues, this step being the supplier's responsibility. The data input for this step is represented by manufacturer specifications and open issues, and the data output for this step is represented by the new software version;b) software validation, with the validation of the new software version and verification of the corrected points, this step being the responsibility of the electro-electronic engineering validation team / quality team. The data input for this step is represented by the new software version, and the data output for this step is represented by the issues;c) main issue list, defined by the online spreadsheet created by adding tabs for each validation area containing all the relevant information necessary to understand and triage the issue for the supplier. The validation area will add issues to the main issue list file with videos, records, and all the necessary details to triage the issue. This step is the responsibility of the quality team. The data input for this step is the issues found during the previous step, and the data output for this step is represented by the issues to be triaged;d) triage, where the engineering team triages the received issues and ensures that the issues are relevant with all the necessary information to pass on to the supplier, under the responsibility of the engineering team's issue manager. The data input for this step is represented by the main issue list defined in the previous step, and the data output isrepresented by issues opened by the supplier;e) new issues opened by the supplier, where the engineering team will open new issues found and reopen issues that should be corrected, under the responsibility of the engineering team's issue manager / electronic engineering validation team. The data input for this step is represented by the issues identified during the previous step, and the data output for this step is represented by issues opened by the supplier;f) Vehicle issue tracking meeting, represented by a weekly / daily meeting, on demand, to discuss open issues of severity A, B, P, and S, where: severity "A" is any issue that causes high customer dissatisfaction, severity "B" is any issue that causes low customer dissatisfaction, severity "P" is any issue that causes a technically immobilizing failure, severity "S" is any issue with potential safety impact, and data resolution and status update, under the responsibility of the engineering team's issue manager. The data input for this step is represented by the open issues for the project, and the data output is represented by the updated status of all issues listed in the so-called red state, i.e., those that do not have an identified root cause and are under analysis by the supplier; and g) Issue reports, represented by standard reports with established graphs and tables to present the status of software issues throughout the project, under the responsibility of the engineering team's issue manager. The data input for this stage is represented by the status of open issues, and the data output for this stage is represented by graphs and tables.

[0020] The present invention differs from the prior art in that it streamlines the analysis of the large volume of software issues received by the engineering team in the validation areas and merges duplicate issues from different areas, avoiding opening the same issue more than once for the supplier, which would cause them to waste time analyzing all the issues. In addition, the proposed method establishes a clear workflow between the validation areas, engineering team, and supplier for the creation, triage, and resolution of issues. There is faster resolution on the supplier's side, as they will receive all relevant information for each issue, and daily follow-up with the supplier will take place to ensure the robustness of the correction. Finally, standardized reports are produced for all projects, making the project status clear to management.

[0021] From the main embodiment disclosed and described in detail herein, and from the non-exhaustive examples of alternative embodiments described, various alterations, additions, and even additional forms of alternative embodiments may be made without departing from the scope or the totality of the subject matter disclosed in the present invention.

[0022] All the technical characteristics of the different embodiments disclosed in the present patent application will be immediately recognized and appreciated by those skilled in the art.

[0023] It is expressly provided that all combinations of elements that perform the same function substantially in the same way to achieve the same results as the elements now claimed are within the scope of the present invention. Finally, it should be noted that the scope of protection of the present invention covers other possible variations, not being limited solely by the content of the claims alone, including possible equivalents.

[0024] It should be noted that the presented drawing is not necessarily to scale, having a merely conceptual nature. Nevertheless, it is expressly provided that all combinations of elements that perform the same function essentially in the same way to achieve the same results as the elements now claimed are within the scope of the present invention. Finally, it should be noted that the scope of protection of the present invention covers other possible variations, not being limited solely by the content of the claims alone, including possible equivalents.

Claims

CLAIMS1. Issue management method, wherein comprises the following steps:a) Software version;b) Software validation;c) Main issue list;d) Triage;e) Open items for supplier;f) Vehicle issue tracking meeting; andg) Issue reports.

2. Issue management method according to claim 1, wherein the step where the supplier releases new software with the new implementation and the previously corrected open issues, this step being the responsibility of the supplier.

3. Issue management method according to claim 2, wherein the data input of step (a) comprising the manufacturer specifications and the open issues and the data output of step (a) comprising the software version.

4. Issue management method according to claim 1, wherein the step (b) comprising the validation of the new software version and verification of the corrected points, this step being the responsibility of the electrical engineering validation team / quality team.

5. Issue management method according to claim 4, wherein the data input of step (b) comprises understanding the new software version and the data output of step (b) comprises understanding the issues.

6. Issue management method according to claim 1, wherein the step (c) comprises an online spreadsheet created by adding tabs for each validation area containing all relevant information necessary to understand and triage the issue for the supplier, wherein the validation area will add issues to the main issue list file with videos, records and all details necessary to triage the issue, this step being the responsibility of the quality team.

7. Issue management method according to claim 6, wherein the data input of step (c) comprises understanding the issues encountered during step (b) and the data output of step (c) comprises understanding the issues to be triaged.

8. Issue management method according to claim 1 wherein the step (d) comprises the screening of issues received by the engineering team, ensuring that the issues are relevant with all the necessary information to pass on to the supplier, under the responsibility of the issue manager of the engineering team.

9. Issue management method according to claim 8, wherein the data input of step (d) comprises the main list of issues defined in step (c) and the data output comprises the issues opened by the supplier.

10. Issue management method according to claim 1, wherein the step (e) comprises the opening of new issues found by the engineering team and the reopening of issues that should be corrected, under the responsibility of the issue manager of the engineering team / electrical engineering validation team.

11. Issue management method according to claim 10, wherein the data input of step (e) comprises the issues identified during step (d) and the data output of step (e) is represented by the issues opened by the supplier.

12. Issue management method according to claim 1, wherein the step (f) comprises weekly / daily meetings, on demand, to discuss open points of severity A, B, P and S, wherein: severity "A" is any issue that causes high customer dissatisfaction, severity "B" is any issue that causes low customer dissatisfaction, severity "P" is any issue that causes a technically immobilizing failure, severity "S" is any issue with potential safety impact, and data resolution and status update, under the responsibility of the issue manager of the engineering team.

13. Issue management method according to claim 12, wherein the data input of step (f) comprises the open issues for the project and the data output of step (f) comprises the updated state of all issues listed in a thus defined red state, signifying those that do not have an identified root cause and are under analysis by the supplier.

14. Issue management method according to claim 1, wherein the step (g) comprises standard reports with established graphs and tables to present the status of software issues throughout the project, under the responsibility of the issue manager of the engineering team.

15. Issue management method according to claim 14, wherein the data input of step (g) comprises the status of open issues and the data output of step (g) comprises graphs and tables.

Images