A cabin driving fusion software collaborative delivery and safe operation management and control system and method

Abstract

The application discloses a cabin-driving integrated software collaborative delivery and safe operation management and control system and method, and belongs to the technical field of vehicle-mounted software. The method comprises the following steps: collecting and inputting version information of cabin domain and intelligent driving domain software; performing automatic checking on full-dimension compatibility based on a bidirectional compatibility matrix; if the checking fails, triggering a release lock; if the checking passes, entering a gray release queue; filtering terminals according to multiple scenes; performing pushing by the OTA cloud according to a hierarchical proportion; if an exception occurs, suspending the pushing; collecting states in real time and determining fault levels; performing cross-domain linkage self-healing operation according to the fault levels; returning monitoring data, self-healing results and user feedback to a general control management module, generating a delivery report and completing an iterative closed loop. The application can realize collaborative and reliable delivery of cabin domain and intelligent driving domain software, rapid self-healing of operation exceptions, and improvement of cabin-driving integrated software delivery efficiency, vehicle-mounted end operation safety and stability.

Description

Technical Field

[0001] This application relates to the field of vehicle software technology, and in particular to a cabin-driver integration software collaborative delivery and safe operation control system, a cabin-driver integration software collaborative delivery and safe operation control method, electronic equipment and storage medium. Background Technology

[0002] The current automotive software technology field is developing towards the deep integration of intelligent cockpits and intelligent driving. Level 2 to Level 4 intelligent connected vehicles place higher demands on the delivery efficiency, operational safety, and stability of cockpit-driver integration software. In existing technologies, cockpit domain and intelligent driving domain software mostly adopt independent development, release, and operation and maintenance systems. OTA releases and fault handling technologies also focus on single-domain optimization. At the same time, there is a lack of a full-process digital control mechanism for cockpit-driver integration software at the project management level. Related publicly available technical solutions and patents also mostly focus on single dimensions such as intelligent driving single-domain algorithms, OTA transmission technology, and cockpit HMI interaction design.

[0003] The closest existing technology to this patent is related to cross-domain interaction of in-vehicle software and OTA gray-scale release solutions. Although such solutions have achieved basic information interaction between the cockpit and intelligent driving, as well as basic gray-scale push of in-vehicle software, they still have many unresolved technical defects, as follows:

[0004] The software version management of the cockpit domain and the intelligent driving domain is independent, the version dependency relationship is not transparent, and there is no pre-release automatic compatibility verification mechanism. This can easily lead to cross-domain interface incompatibility and functional conflicts, resulting in a fragmented user experience. It also causes frequent offline failures and a high rate of delivery rework.

[0005] The OTA (Over-The-Air) rollout of in-vehicle software adopts a fixed-ratio push mode, which lacks a graded screening strategy that takes into account the actual use scenarios of vehicles. Before the full rollout, potential problems cannot be accurately identified, resulting in high release risk. Furthermore, the rollback process after a failure is cumbersome and slow to respond, which can easily lead to a large number of user complaints.

[0006] The software project management of the cabin-driver integration lacks a full-process digital closed-loop system for requirements, versioning, gray-scale testing, monitoring, and self-healing. The connection between each link relies heavily on manual operation and maintenance, resulting in low project delivery efficiency, difficulty in effectively controlling online failure rate, and a significant limitation on the work efficiency of software project managers.

[0007] Existing technologies and patents do not cover the overall collaborative delivery and safe operation system of cabin-driver integration software projects. They only optimize single technical points, resulting in significant technological gaps and failing to meet the full lifecycle management requirements of in-vehicle software under deep cabin-driver integration.

[0008] The core reason for the above problems is that existing technologies have not established an integrated management and control mechanism for the cross-domain characteristics of cockpit-driver integration, which separates the delivery and operation of the cockpit and intelligent driving software. At the same time, the entire workflow of software project managers has not been transformed into standardized technical solutions, resulting in poor cross-domain collaboration, weak risk control capabilities, high manual operation and maintenance costs, and the lack of a systematic solution for related technology research and development. Summary of the Invention

[0009] In view of this, the purpose of this invention is to provide a cabin-pilot integrated software collaborative delivery and safe operation management system, a cabin-pilot integrated software collaborative delivery and safe operation management method, electronic equipment and storage medium, aiming to solve one of the technical problems in the prior art, namely poor cross-domain collaboration, weak risk prevention and control capabilities, high manual operation and maintenance costs, and the lack of a systematic development of related technologies.

[0010] This invention provides the following solution:

[0011] According to one aspect of the present invention, a cabin-pilot fusion software collaborative delivery and safe operation control system is provided, comprising:

[0012] The system includes a central control management module, a version compatibility verification module, a scenario-based push filtering module, a cross-domain status monitoring module, a fault self-healing control module, a cabin domain software operation module, a cross-domain communication module, an OTA push execution module, and a user feedback collection module.

[0013] The overall control management module is used to complete the closed-loop management of cockpit and intelligent driving software version dependency verification, gray-scale strategy orchestration, cross-domain operation monitoring and fault self-healing, as well as data integration to generate delivery reports;

[0014] The version compatibility verification module is used to store the two-way compatibility matrix of the software and perform compatibility verification and release locking.

[0015] The scenario-based push filtering module is used to generate OTA tiered push lists based on multi-level scenario conditions;

[0016] The cross-domain status monitoring module is used to connect with the cabin driving domain software operation module through the cross-domain communication module to collect the operation status in real time and determine the fault level;

[0017] The fault self-healing control module is connected to the cross-domain status monitoring module and the cross-domain communication module, and is used to perform cross-domain linkage self-healing control according to the fault level.

[0018] The cockpit domain software operation module achieves secure data interaction and executes self-healing commands through the cross-domain communication module;

[0019] The OTA push execution module is used to execute tiered software pushes after verification and filtering.

[0020] The user feedback collection module is used to collect user data and send it back to the central control management module, forming a closed-loop digital process.

[0021] Furthermore, compatibility checks include: interface parameter checks, timing matching checks, and system resource usage checks.

[0022] Furthermore, the OTA push execution device uses a gradient-increasing ratio to perform tiered pushes and immediately suspends pushes when an anomaly is detected.

[0023] Furthermore, an OTA tiered push list is generated based on multi-level scenario conditions, including: vehicle model, mileage, environmental conditions, intelligent driving level, and user credit tag, and only terminals that meet all the conditions are included in the push queue.

[0024] Furthermore, the cross-domain status monitoring device classifies anomalies into three levels: minor, medium, and severe.

[0025] Furthermore, the implementation of cross-domain collaborative self-healing control is as follows:

[0026] Minor failure: Perform a single-domain or cross-domain service restart;

[0027] Moderate failure: The cockpit domain service self-heals, while the intelligent driving domain execution interface or function is downgraded;

[0028] Severe failure: Execute version rollback and coordinate with the intelligent driving domain to perform a safe sidewalk operation.

[0029] Furthermore, the central control management module unifies and collects version verification data, gray-scale push data, fault monitoring data, self-healing result data, and user feedback data, and automatically generates standardized delivery reports for version decision-making and iterative optimization.

[0030] Furthermore, it also includes the vehicle-mounted gateway, which serves as a cross-domain communication hub, responsible for forwarding operational status, fault information, and self-healing instructions to ensure the safety of cross-domain communication between the cabin and the driver.

[0031] According to a second aspect of the present invention, a method for collaborative delivery and safe operation management of cabin-pilot fusion software is provided, comprising the following steps:

[0032] Collect and input the version information of the cockpit domain and intelligent driving domain software;

[0033] Automatic compatibility verification is performed across all dimensions based on a two-way compatibility matrix. If the verification fails, a release lock is triggered; if it passes, the product is placed in the canary release queue.

[0034] Terminals are selected according to multi-level scenarios, and OTA cloud pushes are executed according to the hierarchical ratio. If there is an abnormality, the push is suspended.

[0035] Real-time status monitoring and fault level determination;

[0036] Perform cross-domain collaborative self-healing operations based on the fault level;

[0037] The monitoring data, self-healing results, and user feedback are fed back to the central control management module to generate a delivery report and complete the iteration loop.

[0038] According to three aspects of the present invention, an electronic device is provided, comprising: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0039] The memory stores a computer program, which, when executed by a processor, causes the processor to perform steps of a cabin-pilot fusion software collaborative delivery and safe operation control method.

[0040] According to four aspects of the present invention, a computer-readable storage medium is provided that stores a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of a cabin-rider fusion software collaborative delivery and safe operation control method.

[0041] Compared with the prior art, the present invention has the following advantages:

[0042] This invention reduces online failure rates, shortens failure detection time, and reduces offline cross-domain failures by implementing pre-emptive automatic verification through version collaborative locking and multi-layered scenario-based canary release risk control, thereby preventing the occurrence of batch complaints from the source.

[0043] This invention significantly shortens the average delivery cycle, reduces the delivery rework rate, and reduces the workload of manual intervention for software project managers by realizing full-process digital closed-loop management of cabin-driver integration software projects, thereby greatly improving the overall efficiency of project management.

[0044] This invention establishes a cross-domain fault classification self-healing mechanism, which enables rapid self-healing of moderate faults without affecting user operation or requiring vehicle shutdown and rollback. For severe faults, it can link version rollback and intelligent driving safety sideline operations to achieve rapid fault handling, prevent single-domain faults from spreading into cross-domain safety issues, and effectively protect vehicle driving safety.

[0045] This invention achieves monitorable, traceable, and self-healing operation status of the cabin-driver integration software through cross-domain real-time monitoring and fault linkage degradation, significantly improving the overall stability and reliability of the vehicle software operation.

[0046] This invention transforms the workflow of software project managers—requirements-development-testing-release-operation and feedback—into a standardized technical solution. The project collaborative management platform can automatically generate delivery reports, providing data support for version decisions and iteration planning, thereby achieving scientific and data-driven project management.

[0047] This invention does not require intrusion into the core algorithms of intelligent driving perception / decision / control and the specific interaction design of the cockpit HMI. It has strong compatibility and can be directly implemented in the daily management scenarios of cockpit / intelligent driving software project managers. It is widely applicable to L2 to L4 level intelligent connected vehicles. Attached Figure Description

[0048] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0049] Figure 1 This is a structural diagram of a cabin-pilot fusion software collaborative delivery and safe operation control system provided by one or more embodiments of the present invention.

[0050] Figure 2 This is a flowchart of a method for collaborative delivery and safe operation management of cabin-pilot fusion software provided by one or more embodiments of the present invention.

[0051] Figure 3 This is a system architecture diagram in a specific embodiment of the present invention.

[0052] Figure 4 This is a flowchart of the cabin-riding version of the collaborative locking process in a specific embodiment of the present invention.

[0053] Figure 5 This is a scenario-based grayscale release strategy diagram in a specific embodiment of the present invention.

[0054] Figure 6 This is a cross-domain fault classification self-healing logic diagram in a specific embodiment of the present invention.

[0055] Figure 7 This is an electronic device structural block diagram of a method for collaborative delivery and safe operation management of cabin-pilot fusion software provided by one or more embodiments of the present invention. Detailed Implementation

[0056] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0057] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to limit the application. The singular forms “a,” “said,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms, and “multiple” generally includes at least two unless the context clearly indicates otherwise.

[0058] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0059] It should be understood that although the terms first, second, third, etc., may be used in the embodiments of this application, these descriptions should not be limited to these terms. These terms are only used to distinguish the descriptions. For example, first may also be referred to as second without departing from the scope of the embodiments of this application, and similarly, second may also be referred to as first.

[0060] Depending on the context, the words "if" or "if" as used here can be interpreted as "when," "when," "in response to determination," or "in response to detection." Similarly, depending on the context, the phrases "if determination" or "if detection (of the stated condition or event)" can be interpreted as "when determination," "in response to determination," "when detection (of the stated condition or event)," or "in response to detection (of the stated condition or event)."

[0061] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that an article or device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such an article or device. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the article or device that includes said element.

[0062] Figure 1 This is a structural diagram of a cabin-pilot fusion software collaborative delivery and safe operation control system provided by one or more embodiments of the present invention.

[0063] like Figure 1 As shown, it includes:

[0064] The system includes a central control management module, a version compatibility verification module, a scenario-based push filtering module, a cross-domain status monitoring module, a fault self-healing control module, a cabin domain software operation module, a cross-domain communication module, an OTA push execution module, and a user feedback collection module.

[0065] The overall control management module is used to complete the closed-loop management of cockpit and intelligent driving software version dependency verification, gray-scale strategy orchestration, cross-domain operation monitoring and fault self-healing, as well as data integration to generate delivery reports;

[0066] The version compatibility verification module is used to store the two-way compatibility matrix of the software and perform compatibility verification and release locking.

[0067] The scenario-based push filtering module is used to generate OTA tiered push lists based on multi-level scenario conditions;

[0068] The cross-domain status monitoring module is used to connect with the cabin driving domain software operation module through the cross-domain communication module to collect the operation status in real time and determine the fault level;

[0069] The fault self-healing control module is connected to the cross-domain status monitoring module and the cross-domain communication module, and is used to perform cross-domain linkage self-healing control according to the fault level.

[0070] The cockpit domain software operation module achieves secure data interaction and executes self-healing commands through the cross-domain communication module;

[0071] The OTA push execution module is used to execute tiered software pushes after verification and filtering.

[0072] The user feedback collection module is used to collect user data and send it back to the central control management module, forming a closed-loop digital process.

[0073] Specifically, through the coordinated efforts of multiple modules such as overall control management, version compatibility verification, scenario-based push filtering, cross-domain status monitoring, and fault self-healing control, the system achieves version compatibility management, scenario-based hierarchical OTA push, real-time monitoring of cross-domain operation status, and fault linkage self-healing for the cabin-driver integration software. At the same time, it forms a full-process digital closed loop by combining user feedback feedback, effectively ensuring the security, stability, and reliability of cross-domain collaborative delivery of cabin-driver domain software, improving the accuracy of software push, reducing the risk of cross-domain operation failures, and achieving efficient management and control of the entire lifecycle of cabin-driver integration software delivery and operation.

[0074] It is worth noting that although only some basic functional modules are disclosed in this embodiment, it does not mean that the composition of this system is limited to the above-mentioned basic functional modules. On the contrary, what this embodiment intends to express is that, based on the above-mentioned basic functional modules, those skilled in the art can arbitrarily add one or more functional modules in combination with existing technology to form an infinite number of embodiments or technical solutions. That is to say, this system is open rather than closed. The fact that this embodiment only discloses a few basic functional modules does not mean that the scope of protection of the claims of this invention is limited to the disclosed basic functional modules. At the same time, for the convenience of description, the above device is described separately according to its functions as various units and modules. Of course, in implementing this invention, the functions of each unit and module can be implemented in one or more software and / or hardware.

[0075] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0076] Figure 2 This is a flowchart of a method for collaborative delivery and safe operation management of hybrid cabin driving software provided in one or more embodiments of the present invention.

[0077] like Figure 2 As shown, it includes the following steps:

[0078] Step S1: Collect and input the version information of the cockpit domain and intelligent driving domain software;

[0079] Step S2: Perform full-dimensional compatibility automatic verification based on the bidirectional compatibility matrix. If the verification fails, a release lock is triggered; if it passes, the product enters the canary release queue.

[0080] Step S3: Select terminals according to multi-level scenarios, and OTA cloud will push according to the hierarchical ratio. If there is an abnormality, push will be suspended.

[0081] Step S4: Collect status data in real time and determine the fault level;

[0082] Step S5: Perform cross-domain collaborative self-healing operation according to the fault level;

[0083] Step S6: Feed the monitoring data, self-healing results, and user feedback back to the central control management module to generate a delivery report and complete the iterative loop.

[0084] Specifically, by inputting the software version information of the cabin-driving domain, conducting full-dimensional compatibility verification based on a two-way compatibility matrix and implementing release lock control, multi-level scenario-based hierarchical OTA push, real-time cross-domain status monitoring and fault level determination, hierarchical linkage self-healing, and then combining data and feedback feedback to generate delivery reports to complete the iteration loop, the system achieves full-process closed-loop management of the cabin-driving integrated software from version verification, accurate push, operation monitoring to fault self-healing and iterative optimization. This effectively avoids version compatibility risks, improves the accuracy and security of OTA push, ensures the stable operation of the cabin-driving software across domains, and helps the software to continuously iterate and optimize.

[0085] Figure 3 This is a system architecture diagram in a specific embodiment of the present invention.

[0086] like Figure 3 As shown, it includes: a project collaborative management platform, a cockpit / driving version dependency library, a scenario-based canary release module, a cross-domain operation monitoring unit, a hierarchical self-healing orchestration unit, a cockpit domain software execution environment, an intelligent driving domain software execution environment, an in-vehicle gateway, OTA cloud, and a user experience feedback unit. The composition, connection relationship, function, and purpose of each unit are clearly defined, as follows:

[0087] Project Collaborative Management Platform: The core control unit of the system, which establishes bidirectional data connections with the cockpit and autonomous driving version dependency library, the scenario-based canary release module, the cross-domain operation monitoring unit, the hierarchical self-healing orchestration unit, the OTA cloud, and the user experience feedback unit. Its purpose is to realize the closed-loop management of cockpit and autonomous driving software version dependency verification, canary release strategy orchestration, cross-domain operation monitoring, and fault self-healing. At the same time, it automatically integrates various data to generate delivery reports, providing software project managers with a basis for version decision-making and iteration planning.

[0088] Cockpit and Driving Version Dependency Library: Establishes a data connection with the project collaboration and management platform, receives verification instructions from the platform, and provides feedback on the verification results; its purpose is to store the bidirectional compatibility matrix between cockpit software and intelligent driving software, and to automatically verify the input version information in all dimensions, including interface, timing, and resource usage. If the verification fails, a release lock mechanism is triggered to prevent the version combination from entering the OTA push queue, thus intercepting incompatibility issues from the source.

[0089] Scenario-based gray-scale release module: Establishes data connection with the project collaborative management platform and OTA cloud, receives gray-scale policies from the platform, and pushes a filtered list of terminals to the OTA cloud; Its purpose is to set multi-level thresholds and whitelists based on vehicle type, mileage, environmental conditions, intelligent driving level, and user credit tags, to accurately filter OTA push terminals and achieve gray-scale release with minimal risk.

[0090] Cross-domain operation monitoring unit: It establishes data connections with the cockpit domain software execution environment and the intelligent driving domain software execution environment through the vehicle gateway, and at the same time establishes data connections with the hierarchical self-healing orchestration unit and the project collaborative management and control platform; its purpose is to collect the cross-domain operation status and abnormal indicators of the cockpit and driver in real time 24 / 7, automatically determine the fault level (minor / medium / severe), and synchronize the abnormal data and fault level to the hierarchical self-healing orchestration unit and the project collaborative management and control platform.

[0091] Hierarchical self-healing orchestration unit: Establishes data connection with cross-domain operation monitoring unit, vehicle gateway, and project collaborative management platform; Its purpose is to send linkage self-healing operation commands to cockpit domain and intelligent driving domain according to fault level, and at the same time, transmit the self-healing results back to project collaborative management platform to realize the automation and traceability of fault handling.

[0092] Cockpit Domain Software Execution Environment / Intelligent Driving Domain Software Execution Environment: The core operating carrier of the cockpit-driving fusion software. The two establish a secure data connection through the vehicle gateway, and at the same time establish a data connection with the cross-domain operation monitoring unit and the hierarchical self-healing orchestration unit. Its purpose is to run the cockpit / intelligent driving domain software, execute the operation instructions of the hierarchical self-healing orchestration unit, and at the same time transmit its own real-time operating status back to the cross-domain operation monitoring unit.

[0093] Vehicle gateway: The core hub for cross-domain communication, connecting the hierarchical self-healing orchestration unit with the cockpit domain / intelligent driving domain software execution environment; its purpose is to realize secure data interaction between the cockpit domain and the intelligent driving domain, forward operating status, fault information and self-healing operation instructions, and ensure the security and stability of cross-domain communication.

[0094] OTA Cloud: Establishes data connection with the project collaboration and management platform and the scenario-based canary release module; its purpose is to receive software versions after version verification and canary release strategy orchestration, and to perform hierarchical OTA push operations to selected terminals.

[0095] User Experience Feedback Unit: Establishes a data connection with the project collaborative management platform; its purpose is to collect user feedback data on the cabin-driver integration software (such as functional experience, fault feedback, etc.) and send the data back to the project collaborative management platform as the basis for version iteration and gray-scale strategy optimization.

[0096] The connections between the units are as follows: the project collaborative management platform serves as the core, enabling overall control and data exchange with each functional unit; the cockpit domain and intelligent driving domain achieve cross-domain communication and data interaction through the vehicle gateway; the cross-domain operation monitoring unit and the hierarchical self-healing orchestration unit monitor the operating status of the cockpit-driving fusion software and handle faults automatically; the OTA cloud and scenario-based gray-scale release modules enable secure software push; and the user experience feedback unit enables reverse data flow, forming a complete system closed loop.

[0097] One embodiment provides a method for the collaborative delivery and safe operation of intelligent cockpit and intelligent driving integrated software. Based on the above system, each step forms a fully digital closed loop. The specific operation steps, process parameters, and influencing factors are as follows:

[0098] Step 1: Collect software version information for the cockpit domain and intelligent driving domain

[0099] Completely input the software version information of the cockpit domain and intelligent driving domain that have been developed and tested into the project collaborative management platform. The input information includes core data such as version number, interface parameters, timing requirements, and resource usage indicators. This provides the basis for subsequent version compatibility verification. This step is a prerequisite for all subsequent operations, and the completeness of the information input directly affects the accuracy of the verification results.

[0100] Step 2: Perform automatic verification and release locking based on the compatibility matrix, such as... Figure 4 As shown;

[0101] The project collaborative management platform sends a verification command to the cabin version dependency library, calls the bidirectional compatibility matrix in the library, and performs full-dimensional automatic verification of the entered version information in terms of interface, timing, and resource consumption. If the verification passes, the version combination automatically enters the scenario-based canary release queue. If the verification fails, the system automatically triggers the release locking mechanism, intercepts the version combination, and outputs a detailed conflict report. After the software project manager reviews the report, the version is iterated and optimized again. The core of this process is full-dimensional automatic verification + release locking, which realizes the pre-interception of incompatible versions.

[0102] Step 3: Perform canary releases according to a multi-level scenario strategy, such as... Figure 5 As shown;

[0103] The project collaborative management platform configures a multi-level scenario filtering strategy for the scenario-based canary release module. The filtering dimensions include vehicle model, mileage, environmental conditions, intelligent driving level, and user credit tag. Each dimension has a clear threshold and whitelist. The scenario-based canary release module filters terminals according to the strategy, generating a push list only for terminals that meet all multi-level conditions and synchronizing it to the OTA cloud. The OTA cloud performs tiered pushes at a rate of 5% → 15% → 50% → 100%. During the push process, the cross-domain operation monitoring unit collects terminal operation data in real time. If an anomaly is detected, the push is immediately suspended. The core condition for this step is that all scenario dimensions are met. If any condition is not met, the push operation for that terminal is suspended.

[0104] Step 4: Monitor cross-domain operation status in real time

[0105] The cross-domain operation monitoring unit collects real-time operational indicators of the cockpit domain / intelligent driving domain software execution environment through the vehicle gateway, including cross-domain interface interaction status, function execution status, system resource utilization, etc. Threshold ranges are set for the collected indicators. When an indicator exceeds the threshold, the system automatically determines the fault level (minor / moderate / major) based on the scope and severity of the fault impact, and synchronizes the abnormal indicators and fault level to the hierarchical self-healing orchestration unit and the project collaborative management platform. The process requirements for this step are 24 / 7 real-time data collection and millisecond-level fault determination.

[0106] Step 5: Perform graded self-healing according to the fault level, such as... Figure 6 As shown;

[0107] The hierarchical self-healing orchestration unit sends cross-domain linkage self-healing operation commands to the cockpit domain and intelligent driving domain through the vehicle gateway based on the fault level determined by the cross-domain operation monitoring unit. Different fault levels correspond to specific operation processes, namely:

[0108] Minor failure: Perform a single-domain or cross-domain service restart operation to quickly restore software operation without any functional impact; self-healing response time ≤1s.

[0109] Moderate fault: The cockpit domain performs a service self-healing operation, and the intelligent driving domain simultaneously performs an interface / function degradation operation (such as downgrading from the large screen display to the instrument display). The self-healing time is ≤2 seconds, the user is unaware of it, and it does not affect core driving safety.

[0110] Severe Fault: Immediately trigger a version rollback operation, while the intelligent driving domain executes a safe sidewalk command to ensure vehicle driving safety and prevent the fault from escalating. After the self-healing operation is completed, the hierarchical self-healing orchestration unit sends the self-healing results back to the project collaborative management platform, enabling traceability of fault handling.

[0111] Step 6: Data feedback forms a closed delivery loop

[0112] All fault data from the cross-domain operation monitoring unit, self-healing results from the hierarchical self-healing orchestration unit, and user feedback data from the user experience feedback unit are fed back to the project collaborative management platform. The platform automatically integrates various types of data and generates standardized delivery reports according to project management requirements. Based on the delivery reports, the software project manager makes version decisions, iterative planning, and gray-scale strategy optimizations, completing the collaborative delivery and safe operation closed loop of the entire cabin-pilot integration software. This step realizes the unified collection and analysis of all data, providing data support for subsequent version optimization.

[0113] Specifically, the version collaboration locking mechanism intercepts cross-domain version incompatibility issues from the source of software release through a two-way compatibility matrix, full-dimensional automatic verification, and release locking, directly reducing offline failures and delivery rework, and achieving the technical effect of further reducing the delivery rework rate.

[0114] Multi-layered scenario-based canary releases eliminate the drawbacks of traditional fixed-ratio pushes by using multi-dimensional scenario filtering, tiered pushes, and abnormal pauses. This allows OTA pushes to be precisely targeted to "highly compatible, low-risk" terminals, quickly identifying potential problems, avoiding batch failures, and achieving the technical effect of further reducing online failure rates.

[0115] Cross-domain fault classification self-healing achieves automated and rapid fault handling through real-time monitoring, millisecond-level fault determination, and linkage between fault level and self-healing operation. Moderate faults are imperceptible to users, while severe faults provide a safety net, significantly improving fault self-healing capabilities and driving safety.

[0116] The end-to-end digital closed loop replaces traditional manual operation and maintenance and process connection through the overall control of the project collaborative management platform, data interconnection of all stages, and automated report generation. It achieves standardization and automation of each process, greatly improves project delivery efficiency, shortens the delivery cycle, and reduces the manual intervention of project managers.

[0117] Cross-domain real-time monitoring and fault linkage degradation enable full-dimensional perception of the operating status of the cabin-driver integration software and precise handling of faults, preventing single-domain faults from spreading into cross-domain safety issues and significantly improving the stability and reliability of the vehicle software operation.

[0118] In one embodiment of the version of the cooperative locking implementation,

[0119] Versions to be released: Cockpit software V1.5.0, Intelligent driving software V3.2.1;

[0120] After the above version information is entered into the project collaborative management platform, the system calls the two-way compatibility matrix of the cockpit version dependency library for automatic verification. If the interface parameters of the two are found to be incompatible, the system automatically triggers release locking, intercepts the version combination, and outputs a report of 3 specific interface mismatch items. The software project manager optimizes the interface of the cockpit software V1.5.0 based on the report. After optimization, it passes the re-verification and enters the gray-scale queue. This implementation reduces offline cross-domain failures and reduces the delivery rework rate.

[0121] In one embodiment of a scenario-based canary release implementation, the canary release software version is: Cockpit-Drive Fusion Software V2.0; the canary release screening conditions are set as follows: highway conditions + vehicle mileage > 5000km + L2 intelligent driving level + user satisfaction rate > 95%;

[0122] The scenario-based gray-scale release module selects eligible terminals based on conditions, and the OTA cloud performs tiered push at a rate of 5%→15%→50%→100%. During the push process, the cross-domain operation monitoring unit collects data in real time. The actual anomaly rate of this implementation is 0.12%, which is far lower than the 1.8% of the traditional full release. The fault detection time is ≤30s, and no batch complaints have occurred.

[0123] In one embodiment of cross-domain fault self-healing, the fault scenario is as follows: during vehicle operation, the cockpit rendering freezes, causing the intelligent driving interface to lag; after the cross-domain operation monitoring unit collects abnormal indicators, it determines that the fault is a moderate fault; the hierarchical self-healing orchestration unit immediately sends an operation command, the cockpit domain executes the rendering service restart operation, and the intelligent driving domain simultaneously downgrades the interface to the instrument display; the self-healing time of this fault is ≤2s, the driver has no perception, there is no need to stop and roll back, and it does not affect normal driving.

[0124] In one embodiment of the project delivery closed-loop implementation, the development project of the cabin-driver fusion software V2.0 for a certain L2-level intelligent connected vehicle was used as the implementation object. The entire process was executed according to the method of this invention: requirements analysis → software development → testing and verification → version collaborative locking → scenario-based canary release → cross-domain real-time monitoring → graded fault self-healing → user feedback feedback. Before this implementation, the average delivery cycle of this type of project was 21 days, which was shortened to 14 days after implementation, a reduction of 33% in the delivery cycle; the online failure rate decreased from 2.5% to 0.7%, a decrease of 72%; and the manual intervention work of the software project manager in version verification, canary push, and fault handling was reduced by 85%.

[0125] This invention is not limited to the specific embodiments described above. Various modifications, alterations, and substitutions can be made without departing from the core technical concept of this invention, and all such modifications, alterations, and substitutions fall within the protection scope of this invention. The following provides a detailed description of several typical alternative embodiments:

[0126] In an alternative embodiment of the present invention, the filtering dimensions for scenario-based grayscale release can be expanded beyond the original five dimensions: vehicle model, mileage, environmental conditions, intelligent driving level, and user credit tag. Specifically, one or more dimensions such as vehicle age, in-vehicle hardware and software configuration, and regional road conditions can be added as supplementary filtering conditions.

[0127] This alternative implementation still adopts the core logic of "push only when all multi-layered conditions are met," meaning that an OTA upgrade version will only be pushed to a target vehicle when it simultaneously meets all the set filtering conditions. By adding more dimensions of filtering conditions, more accurate user group segmentation can be achieved without affecting the original risk control effect, effectively avoiding pushing upgrade versions to unsuitable vehicles.

[0128] In an alternative embodiment of the present invention, the fault level classification method can be adjusted. Specifically, the original three-level fault classification of the present invention (minor / medium / severe) can be further subdivided into five-level fault classification (micro / minor / medium / severe / critical).

[0129] Different handling strategies are implemented for different levels of faults: for minor faults, only indicator warning operations are performed, without triggering any self-healing operations; for light and medium faults, self-healing operations corresponding to the original plan are performed; for major faults, emergency handling operations in the original plan are performed; for newly added critical faults, a combination of "emergency parking + version rollback" is performed.

[0130] The core of this alternative implementation method remains the linkage mechanism between fault level and self-healing operation. Through more refined fault level classification, more refined cross-domain fault handling can be achieved, further improving the safety and reliability of the vehicle during the OTA upgrade process.

[0131] In an alternative embodiment of the present invention, the dimensions of version compatibility verification can be expanded. Specifically, one or more dimensions such as software running frame rate verification, cross-domain data transmission latency verification, and system response speed verification can be added to the existing dimensions of interface compatibility verification, timing compatibility verification, and resource usage verification.

[0132] This alternative implementation still relies on a bidirectional compatibility matrix to perform automatic verification and release blocking mechanisms. That is, if any verification dimension fails to meet compatibility requirements, the release process for that version is automatically blocked. By adding more dimensions of compatibility verification, the compatibility between versions can be more comprehensively evaluated, further improving the operational stability and user experience of the software after OTA upgrades.

[0133] In an alternative embodiment of the present invention, the hierarchical ratio of grayscale push can be flexibly adjusted according to actual needs. For example, the original hierarchical push ratio of 5%→15%→50%→100% can be adjusted to 3%→10%→40%→100%, or to 10%→20%→60%→100%.

[0134] This alternative implementation still adopts the core logic of "tiered gradual rollout + abnormal pause," that is, gradually expanding the rollout scope according to a set ratio, and immediately pausing the rollout of that version when an abnormality is detected in a certain rollout stage. By flexibly adjusting the gray-scale rollout ratio, it can adapt to the project schedule requirements and risk tolerance of different car companies.

[0135] In an alternative embodiment of the invention, the sources of data feedback can be expanded. Specifically, in addition to the existing vehicle operation data, self-healing result data, and user feedback data, one or more sources such as offline test data, dealer maintenance data, and 4S store fault feedback data can be added.

[0136] This alternative implementation still integrates and processes all backflow data through a project collaborative management platform and generates a unified project delivery report. By adding more dimensions of data backflow sources, more comprehensive and accurate feedback on version operation can be obtained, thereby further optimizing the scientific nature of subsequent version iterations and project decisions.

[0137] It should be noted that the above-described alternative implementation methods can be implemented individually or in any combination. For example, alternative implementation methods that simultaneously expand the gray-scale release dimensions and adjust the gray-scale push ratio can be used, or alternative implementation methods that simultaneously refine the fault level classification and expand the data return sources can be used. These combined implementation methods also fall within the protection scope of this invention.

[0138] Figure 7 This is an electronic device structural block diagram of a method for collaborative delivery and safe operation management of cabin-pilot fusion software provided by one or more embodiments of the present invention.

[0139] like Figure 7 As shown, this application provides an electronic device, including: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0140] The memory stores a computer program, which, when executed by the processor, causes the processor to perform the steps of a method for collaborative delivery and safe operation control of cabin-pilot fusion software.

[0141] This application also provides a computer-readable storage medium storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of a cabin-rider fusion software collaborative delivery and safe operation control method.

[0142] For the sake of simplicity, the method embodiments are described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0143] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0144] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A cabin-pilot integrated software collaborative delivery and safe operation control system, characterized in that, include: The system includes a central control management module, a version compatibility verification module, a scenario-based push filtering module, a cross-domain status monitoring module, a fault self-healing control module, a cabin domain software operation module, a cross-domain communication module, an OTA push execution module, and a user feedback collection module. The overall control management module is used to complete the closed-loop management of cockpit and intelligent driving software version dependency verification, gray-scale strategy orchestration, cross-domain operation monitoring and fault self-healing, as well as integrate data to generate delivery reports; The version compatibility verification module is used to store the two-way compatibility matrix of the cockpit software and perform compatibility verification and release locking. The scenario-based push filtering module is used to generate an OTA tiered push list based on multi-level scenario conditions. The cross-domain status monitoring module is used to connect with the cabin driving domain software operation module through the cross-domain communication module, and is used to collect the operation status and determine the fault level in real time. The fault self-healing control module is connected to the cross-domain status monitoring module and the cross-domain communication module, and is used to perform cross-domain linkage self-healing control according to the fault level. The cockpit domain software operation module achieves secure data interaction and executes self-healing commands through the cross-domain communication module; The OTA push execution module is used to execute the tiered push of software after verification and filtering; The user feedback collection module is used to collect user data and send it back to the central control management module, forming a closed-loop digital process.

2. The cabin-pilot integrated software collaborative delivery and safe operation control system according to claim 1, characterized in that, The compatibility check includes: Interface parameter validation, timing matching validation, and system resource usage validation.

3. The cabin-pilot integrated software collaborative delivery and safe operation control system according to claim 1, characterized in that, include: The OTA push execution module uses a gradient-increasing ratio to perform tiered pushes and immediately pauses pushes when an anomaly is detected.

4. The cabin-pilot integrated software collaborative delivery and safe operation control system according to claim 1, characterized in that, The process of generating an OTA tiered push list based on multi-level scenario conditions includes: The system selects terminals that meet all of the following criteria: vehicle model, mileage, environmental conditions, intelligent driving level, and user credit tag. Only terminals that meet all of these criteria are included in the push queue.

5. The cabin-pilot integrated software collaborative delivery and safe operation control system according to claim 1, characterized in that, include: The cross-domain status monitoring module classifies anomalies into multiple anomaly levels.

6. The cabin-pilot integrated software collaborative delivery and safe operation control system according to claim 5, characterized in that, include: The execution of cross-domain linkage self-healing control is as follows: Minor failure: Perform a single-domain or cross-domain service restart; Moderate failure: The cockpit domain service self-heals, while the intelligent driving domain execution interface or function is downgraded; Severe failure: Execute version rollback and coordinate with the intelligent driving domain to perform a safe sidewalk operation.

7. The cabin-pilot integrated software collaborative delivery and safe operation control system according to claim 1, characterized in that, include: The overall control management module unifies and collects version verification data, gray-scale push data, fault monitoring data, self-healing result data, and user feedback data, automatically generates standardized delivery reports, and is also used for version decision-making and iterative optimization.

8. A method for collaborative delivery and safe operation control of cabin-pilot integrated software, characterized in that, Includes the following steps: Collect and input the version information of the cockpit domain and intelligent driving domain software; Automatic compatibility verification is performed across all dimensions based on a two-way compatibility matrix. If the verification fails, a release lock is triggered; if it passes, the product is placed in the canary release queue. Terminals are selected according to multi-level scenarios, and OTA cloud pushes are executed according to the hierarchical ratio. If there is an abnormality, the push is suspended. Real-time status monitoring and fault level determination; Perform cross-domain collaborative self-healing operations based on the fault level; The monitoring data, self-healing results, and user feedback are fed back to the central control management module to generate a delivery report and complete the iteration loop.

9. An electronic device, characterized in that, include: The processor, communication interface, memory, and communication bus are connected, with the processor, communication interface, and memory communicating with each other via the communication bus. The memory stores a computer program, which, when executed by the processor, causes the processor to perform the steps of the cabin-pilot fusion software collaborative delivery and safe operation control method as described in claim 8.

10. A computer-readable storage medium, characterized in that, It stores a computer program that can be executed by an electronic device. When the computer program runs on the electronic device, it causes the electronic device to perform the steps of the cabin-rider fusion software collaborative delivery and safe operation control method as described in claim 8.

Images