Intelligent cabin acceptance method and system based on continuous integration and continuous delivery technology

Abstract

The invention belongs to the related technical field of intelligent cabin acceptance, and provides an intelligent cabin acceptance method and system based on a continuous integration and continuous delivery technology, which systematically introduces the continuous integration and continuous delivery technology into an intelligent cabin system acceptance process to realize an integrated closed loop of development, construction, test, acceptance and deployment. According to the method, the whole process of the intelligent cabin software from code submission to real vehicle deployment does not need a large amount of manual intervention, a standardized CICD acceptance system adaptive to the vehicle-mounted system is formed, the problems that in the prior art, feedback of the acceptance process is lagged, and the online period is long are solved, and the high-frequency and agile iterative development requirements of the intelligent cabin software can be better met.

Description

Technical Field

[0001] This invention belongs to the technical field of intelligent cockpit acceptance, and particularly relates to intelligent cockpit acceptance methods and systems based on continuous integration and continuous delivery technologies. Background Technology

[0002] The statements in this section are merely background information related to the present invention and do not necessarily constitute prior art.

[0003] With the rapid iteration of intelligent and connected technologies in the automotive industry, the intelligent cockpit, as the core carrier of in-vehicle human-machine interaction, is experiencing an exponential increase in the integration complexity and functional richness of its software and hardware systems, which places stringent demands on the iteration efficiency and delivery quality of software development.

[0004] In the traditional development model of intelligent cockpit software, the testing and acceptance processes generally adopt manual or semi-automatic methods, which suffer from industry pain points such as low process efficiency, errors easily introduced by manual operation, and lag in the problem feedback chain. Specifically, the testing and acceptance of existing embedded vehicle systems mostly rely on fixed version batch delivery, manual comparison of test results, and static document archiving management. The process flexibility and response speed of this model can no longer meet the core requirements of high-frequency requirement changes and agile iterative development of intelligent cockpit software.

[0005] To address these issues, some automakers have begun to introduce general-purpose automated build and testing tools such as Jenkins, GitLab CI, and Travis CI, hoping to improve testing and acceptance efficiency through tool-based approaches. However, in actual implementation, these general-purpose tools have not yet formed a standardized application process in the smart cockpit field, revealing several compatibility deficiencies: First, the tools have poor compatibility with automotive embedded hardware, making it difficult to be compatible with heterogeneous automotive hardware environments; second, the test coverage dimensions are limited, failing to achieve full-link test coverage of multiple cockpit modules; and third, the lack of a version dependency management mechanism easily leads to version conflicts during multi-module integration.

[0006] In summary, there is an urgent need to propose an intelligent cockpit acceptance scheme to address the significant technical bottlenecks of existing technologies in scenarios involving high-frequency iteration and rapid acceptance and delivery of intelligent cockpit software. Summary of the Invention

[0007] To overcome the shortcomings of the prior art, this invention provides an intelligent cockpit acceptance method and system based on continuous integration and continuous delivery technology, realizing an integrated closed loop of development, construction, testing, acceptance, and deployment, and possessing good reusability and scalability.

[0008] To achieve the above objectives, the present invention adopts the following technical solution: In a first aspect, the present invention provides an intelligent cockpit acceptance method based on continuous integration and continuous delivery technology, including: Integrate the code of multiple modules of the smart cockpit and set up an integration branch trigger mechanism; The server automatically triggers the compilation process to generate a multi-module binary image of an intelligent cockpit system that meets automotive-grade requirements. Execute test cases on the intelligent cockpit system, record test results in real time, and generate test reports; Based on preset acceptance conditions and test report results, the acceptance script automatically determines whether the smart cockpit software version corresponding to the multi-module binary image has passed acceptance.

[0009] Secondly, the present invention provides an intelligent cockpit acceptance system based on continuous integration and continuous delivery technologies, including: The code management module is configured to integrate the code of multiple modules in the smart cockpit and set up an integration branch trigger mechanism; The build module is configured to automatically trigger the compilation process by the build server to generate a multi-module binary image of an intelligent cockpit system that meets automotive-grade requirements. The testing module is configured to execute test cases on the intelligent cockpit system, record test results in real time, and generate test reports. The acceptance module is configured to automatically determine, based on preset acceptance conditions and test report results, whether the smart cockpit software version corresponding to the multi-module binary image has passed acceptance through an acceptance script. The deployment module is configured to deploy the smart cockpit software version corresponding to the accepted multi-module binary image to an embedded test environment or a real vehicle environment.

[0010] Thirdly, the present invention provides an electronic device including a memory and a processor, and computer instructions stored in the memory and running on the processor, wherein the computer instructions, when executed by the processor, perform the method described in the first aspect.

[0011] Fourthly, the present invention provides a computer-readable storage medium for storing computer instructions, which, when executed by a processor, perform the method described in the first aspect.

[0012] The above one or more technical solutions have the following beneficial effects: This invention systematically introduces continuous integration and continuous delivery technologies into the acceptance process of intelligent cockpit systems, realizing an integrated closed loop of development, construction, testing, acceptance, and deployment. This eliminates the need for extensive manual intervention in the entire process of intelligent cockpit software from code submission to real vehicle deployment, forming a standardized CICD acceptance system adapted to in-vehicle systems. This solves the pain points of delayed feedback and long launch cycles in existing technologies, and can better adapt to the high-frequency and agile iterative development needs of intelligent cockpit software.

[0013] This invention employs a universal modular structure and script templates. Core modules such as code management, build engine, and test management can be flexibly adapted to different hardware platforms and project architectures, eliminating the need to rebuild the entire process system for a single vehicle model or hardware. This design ensures the solution has excellent reusability while reserving functional expansion interfaces, allowing for rapid iteration based on subsequent smart cockpit technology upgrades (such as adding in-vehicle Ethernet testing, multimodal interaction testing, etc.), and adapting to the acceptance requirements of different automakers and vehicle models.

[0014] Advantages of additional aspects of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0015] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.

[0016] Figure 1 This is a block diagram for the acceptance of a smart cockpit based on continuous integration and continuous delivery technology in an embodiment of the present invention. Detailed Implementation

[0017] It should be noted that the following detailed descriptions are exemplary and intended to provide further illustration of the invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0018] It should be noted that the terminology used herein is for the purpose of describing particular implementations only and is not intended to limit the exemplary implementations of the present invention.

[0019] Where there is no conflict, the embodiments and features in the embodiments of the present invention can be combined with each other.

[0020] Example 1 This embodiment discloses an intelligent cockpit acceptance method based on continuous integration and continuous delivery technologies, including: Integrate the code of multiple modules of the smart cockpit and set up an integration branch trigger mechanism; The server automatically triggers the compilation process to generate a multi-module binary image of an intelligent cockpit system that meets automotive-grade requirements. Execute test cases on the intelligent cockpit system, record test results in real time, and generate test reports; Based on preset acceptance conditions and test report results, the acceptance script automatically determines whether the smart cockpit software version corresponding to the multi-module binary image has passed the acceptance test. Deploy the smart cockpit software version corresponding to the accepted multi-module binary image to an embedded testing environment or a real vehicle environment.

[0021] like Figure 1 As shown, this embodiment adopts a modular CICD architecture, including a code management module, a build engine module, a test management module, an acceptance control module, a deployment execution module, and a monitoring and feedback module.

[0022] As a specific implementation method, the code management module uses GitLab version management, multi-branch strategy, and Merge Request triggering mechanism to achieve orderly integration and automated flow of code from multiple modules, providing a compliant code foundation for subsequent build and testing phases.

[0023] Unlike traditional single-branch or simple dual-branch (development / main branch) modes, this system sets up three-level branches—Development Branch (Dev), Test Branch (Test), and Integration Branch (Integration)—to address the characteristics of multi-module collaboration (HMI / MCU / multimedia, etc.) and high-frequency iteration in intelligent cockpits.

[0024] Development branches: These are branches for individual module developers to submit code for development and self-testing within their modules, and do not directly participate in integration. Test branch: Merge the self-tested module code from the development branch for inter-module integration testing and pre-testing, and filter out basic functional defects; Integration branch: Only accepts merge requests initiated from the test branch, serving as the "sole trigger source" of the CICD pipeline to ensure that the code entering the build phase has passed initial verification.

[0025] Compliance verification logic triggered by Merge Request (MR): An improved version of existing GitLab MR functionality with a built-in multi-dimensional admission verification mechanism. Code review and verification: At least two module owners must pass the code review (including syntax standardization and module dependency conflict detection) to prevent non-compliant code from being mixed in; Commit information verification: Force verification of commit information format (such as module name-feature point-modification type) to ensure version traceability and auditability; Branch permission verification: Restricts MR to only test branches to integration branches, prohibits direct merging from development branches, and avoids the risk of integrating untested code.

[0026] After the Merge Request passes all validations and completes the merge, it automatically sends a trigger signal (including branch name, code version number, and target hardware platform parameters) to the Jenkins build engine, eliminating the need for manual triggering of the build and achieving a seamless connection between "code integration and automatic build".

[0027] As one specific implementation method, the engine module is built based on Jenkins multi-level pipeline + Docker containerized isolation to generate multi-module binary images that meet automotive-grade requirements (such as functional safety ISO 26262 and compatibility).

[0028] The layered build logic of Jenkins' multi-level pipeline is as follows: Considering the characteristics of smart cockpits with multiple modules (HMI / MCU / multimedia) and multiple hardware platforms (cockpit chips for different vehicle models), a three-level pipeline is designed: "module compilation → module integration → whole vehicle image packaging". Level 1 (Module Compilation): Compile the code of each functional module in parallel to generate independent module middleware (such as the UI rendering component of the HMI module and the control logic component of the MCU module). Level 2 (Module Integration): Based on the vehicle configuration (such as high-end / low-end cabin hardware), the corresponding module middleware is integrated to solve the interface compatibility issues between modules; Level 3 (Vehicle Image Packaging): Add automotive-grade security checks (such as image signature and integrity checks) to generate deployable binary images (such as images adapted to Qualcomm 8295 / NVIDIA Orin chips).

[0029] Docker containerization build environment isolation technology: Unlike the traditional unified physical machine build environment, it creates independent Docker containers for different hardware platforms (e.g., vehicle A uses Qualcomm chips, vehicle B uses Renesas chips). Each container has a built-in dedicated build toolchain (e.g., ARM GCC cross compiler) and dependency libraries (e.g., CAN bus communication library). Environment isolation: Avoid dependency conflicts between different hardware platforms (such as conflicts between the graphics library of Qualcomm chips and the control library of Renesas chips). Environment reuse: Container images can be reused in different projects. When building a new model, only minor configuration adjustments are needed, shortening the environment setup time (from the traditional 2 days to 30 minutes). Traceability: Each container image records the version of the build tools and the versions of the dependent libraries to ensure that the build environment is reproducible and meets automotive-grade "auditability" requirements.

[0030] Quality control mechanism for automotive-grade images: "Automotive-grade verification nodes" are embedded during the build process, including: Code security verification: Scan the image for unauthorized code (such as open source library license compliance); Functional safety verification: Ensure that the image meets ISO 26262 ASIL-B requirements (e.g., disabling debug interfaces, redundancy design of critical functions); Size and performance verification: control the image size (avoid occupying too much vehicle storage) and the execution efficiency of the compiled code (e.g., MCU module response latency ≤ 100ms).

[0031] In this embodiment, through "multi-level pipeline + containerized isolation + automotive-grade verification", a stable, efficient and compliant construction of multiple hardware platforms for intelligent cockpits is achieved for the first time.

[0032] As a specific implementation method, the core of the test management module is to integrate multiple test frameworks (pytest / RobotFramework / Vector CANoe) + simulator / real vehicle dual environment to realize full-dimensional automated testing of intelligent cockpit functions, interfaces, security and UI.

[0033] Collaborative testing logic across multiple testing frameworks: For smart cockpits with multiple test types (unit testing / integration testing / CAN bus testing), different testing frameworks are integrated and collaboratively implemented. Unit testing: Use the pytest framework to test the core functions of a single module (such as the shift control logic of an MCU module) to ensure the correctness of the module's functions; Integration testing: Use Robot Framework to test the interaction between modules (such as the interface compatibility of the HMI module sending the "play music" command to the multimedia module). Bus test: Use Vector CANoe to simulate the vehicle's CAN / LIN bus signal to test the correctness of communication between the cockpit and other vehicle systems (such as engine and chassis) (e.g., whether the vehicle speed displayed by the HMI is consistent with the vehicle speed transmitted by the CAN bus). UI Testing: Combine image recognition technology (such as OpenCV) to test the HMI interface (such as button response latency, interface layout consistency), and support multi-resolution (such as 12.3-inch / 15.6-inch cockpit screen) adaptation.

[0034] Simulator and real vehicle dual-environment linkage testing mechanism: Unlike traditional "simulator-only testing" or "real vehicle-only testing", a dual-environment process of "simulator pre-testing → real vehicle final testing" is designed: Simulator environment (such as Prescan / Simulink): Simulates cockpit hardware environment and virtual road conditions (such as congested roads and nighttime scenarios), and performs high-frequency regression tests (such as after each code commit) to avoid frequently occupying real vehicle resources; Real vehicle environment: Only for versions that have passed simulator testing, “software and hardware integration testing” is performed in real vehicle hardware (such as the test vehicle cabin) to verify scenarios that cannot be covered by the simulator (such as the stability of CAN bus communication under extreme temperatures and the impact of real vehicle vibration on UI display). Data synchronization: Simulator and real vehicle test data (such as test case execution results and defect logs) are uniformly uploaded to the test management platform (such as TestRail) to enable test results to be compared and defects to be traced.

[0035] Dynamic test case generation and prioritization technology: Test cases are automatically generated based on smart cockpit requirements documents (such as SRS) and prioritized according to "risk priority". Dynamic generation: When the requirements document is updated, the corresponding test cases are automatically updated (e.g., when a new "voice control sunroof" function is added, the "voice command recognition → sunroof response" test case is automatically generated). Prioritization: Set "safety-related test cases" (such as DMS fatigue monitoring function) as the highest priority to ensure that critical functions are verified first in each test, which meets the automotive-grade "safety first" requirement.

[0036] As a specific implementation method, the core of the acceptance control module is to automatically determine whether the version meets the acceptance criteria based on test data through Pass Gate logic and automated acceptance scripts, replacing traditional manual acceptance.

[0037] The automotive-grade Pass Gate's multi-dimensional evaluation system: Addressing the "high reliability and high safety" requirements of intelligent cockpits, it designs four categories of acceptance indicators: "functionality, safety, efficiency, and compatibility," and these indicators can be dynamically adjusted according to vehicle configuration (e.g., high-end models / economy models). Functional indicators: Unit test pass rate ≥ 95%, CAN communication accuracy ≥ 99%, number of functional defects = 0 (e.g., no abnormalities in the "voice-controlled air conditioner" function); Security metrics: 100% security check pass rate (e.g., no open debug ports or invalid authentication vulnerabilities); DMS fatigue monitoring response latency ≤ 500ms. Efficiency metrics: Build time ≤ 30 minutes, total testing time ≤ 2 hours (to avoid excessively long acceptance cycles); Compatibility metrics: The image compatibility score with the target hardware platform (such as the Qualcomm 8295 chip) is ≥98% (no driver conflicts).

[0038] The logical judgment mechanism of the automated acceptance script: The acceptance script reads the test report generated by the test management module and calculates the comprehensive score according to the indicator weights (e.g., functional indicators have a weight of 40%, and security indicators have a weight of 30%). A score of ≥90 points will automatically be labeled "Acceptance Passed" and an acceptance log (including indicator scores and test report links) will be recorded. Score 60-89: Mark "Needs optimization", output the indicators that need improvement (e.g., "CAN communication accuracy is 98%, bus protocol needs optimization"). Score < 60 points: Automatic rejection, triggering "code rollback" to the previous version to prevent unqualified versions from entering the deployment stage.

[0039] Traceability and auditing mechanism for acceptance results: An "Acceptance Audit Report" is generated during the acceptance process, which includes: Indicator details: Test data for each acceptance indicator (e.g., "Unit test pass rate 96%, failed test case is 'shift logic exception' in MCU module"). Decision basis: script judgment process (e.g., "This indicator passes because the CAN communication accuracy rate is 99.2% ≥ 99%"). Operation log: Acceptance executor (automatically executed by the system), acceptance time, version number, which meets the automotive-grade "traceability" requirements (such as the audit traceability of ISO 26262).

[0040] As a specific implementation method, the core of the deployment and execution module is based on Ansible / Fastlane tools and an automatic rollback mechanism to deploy the accepted version to embedded test equipment or real vehicles and ensure deployment reliability.

[0041] Multi-scenario adapted automated deployment logic: Differentiated deployment processes are designed for two deployment scenarios: "embedded testing equipment (laboratory environment)" and "real vehicles (real road conditions)". Embedded test device deployment (Ansible tool): Connect to the test device (such as a cockpit simulator) remotely via network and perform the three-step operation of "image transfer → flashing → self-test": Image transmission: Employs breakpoint resume technology to avoid transmission failures caused by network interruptions; Programming: Automatically identifies the device hardware model (such as Qualcomm / NVIDIA chips) and selects the matching programming tool (such as Fastboot). Self-test: After programming is complete, a basic function self-test is automatically performed (such as starting the HMI interface and detecting the CAN bus connection). Real-vehicle deployment (Fastlane tool): Combined with the on-board diagnostic interface (OBD), it enables "offline deployment" (avoiding scenarios where the vehicle has no network access). Pre-built deployment package: The image is packaged into an offline deployment package (including drivers and configuration files), which is then imported into the actual vehicle via USB flash drive / SD card; Step-by-step deployment: First deploy to the backup partition of the actual vehicle, and then switch to the main partition after successful verification to avoid the cockpit system from being paralyzed due to deployment failure; Real-vehicle condition adaptation: During deployment, monitor the real vehicle status (e.g., battery voltage ≥12V). If the voltage is too low, pause the deployment to avoid damaging the hardware.

[0042] Automatic rollback mechanism for deployment failures: Unlike traditional "manual rollback," it designs a process of "snapshot backup → failure detection → one-click rollback." Snapshot backup: Before deployment, create a snapshot (including image, configuration file, and user data) of the current version (such as the stable running V1.0 version) and store it to the local backup partition of the actual vehicle; Fault Detection: After deployment, faults are detected through "hardware self-test (such as chip temperature, storage capacity) + functional self-test (such as voice control, navigation function)". Hardware failures: such as the chip failing to boot after programming or insufficient storage capacity; Functional failures: such as a black screen on the HMI interface or no response on the CAN bus; One-click rollback: After a fault is detected, the snapshot is automatically called to restore to the previous version. The rollback time is ≤5 minutes (traditional manual rollback takes more than 1 hour), and a fault alarm (including fault type and deployment log) is sent.

[0043] Multi-device parallel deployment technology: For scenarios involving "multiple test devices / multiple test vehicles", parallel deployment is supported (such as deploying 10 embedded test devices at the same time). The device list is managed through Ansible's "host group" function, and the deployment progress is synchronized to the monitoring screen in real time, avoiding the inefficiency of manual deployment one by one (deployment efficiency is improved by 80%).

[0044] As a specific implementation method, the core of the monitoring and feedback module is based on Prometheus metric collection, Grafana visualization, and multi-channel alerts to achieve controllability, auditability, and early warning throughout the entire process (code integration → build → test → acceptance → deployment).

[0045] A multi-dimensional, end-to-end metrics collection system: Three core metrics—efficiency, quality, and resources—are designed for each stage of CICD, and collected periodically via Prometheus (collection frequency is configurable). Efficiency metrics: code merging time (time from MR initiation to merging), build time, testing time, acceptance time, deployment time; Quality metrics: Code review pass rate (the percentage of MapReduce approvals), build success rate, test pass rate (unit tests / integration tests / CAN bus tests), acceptance pass rate, deployment success rate; Resource metrics: CPU / memory utilization of the build server, online rate of test equipment, and status of equipment deployed in the actual vehicle (such as battery voltage and network connectivity).

[0046] Grafana's hierarchical visualization logic: Designing differentiated visualization dashboards based on user roles (developers, testers, project managers): Developer dashboard: Displays "code merging time, module compilation success rate, and unit test pass rate" to facilitate the identification of module development issues (e.g., "MCU module compilation success rate is 80%, code errors need to be investigated"). Test personnel dashboard: Displays "test pass rate, defect distribution (by module / test type), and test equipment status" to facilitate tracking of test progress and defect fixing; Project manager dashboard: Displays "full process cycle (total time from code submission to deployment), success rate of each stage, and resource utilization rate", which facilitates control over the overall project progress (e.g., "current version acceptance cycle is 4 hours, which meets the target requirements").

[0047] Multi-channel intelligent alerting mechanism: Based on Prometheus alerting rules (with customizable thresholds, such as "trigger alert after ≥2 build failures"), trigger alerts from multiple channels. Real-time alerts: Push "emergency faults" (such as build failures or deployment failures) via DingTalk / WeChat Work, including the faulty part, the cause of the fault (such as "Jenkins build failed because Docker container dependencies are missing"), and handling suggestions (such as "re-pull the container image"). Email alerts: Send "non-urgent alerts" (such as "test pass rate drops to 90%, below the threshold of 95%), along with a detailed metric report (such as a list of failed test cases). Log linkage: Alarm information is associated with logs of the corresponding stage (e.g., build failure alarms are associated with Jenkins build logs, deployment failure alarms are associated with real vehicle deployment logs), which facilitates quick problem location.

[0048] In this embodiment, after the developers complete the code development and local self-testing of a certain functional module of the smart cockpit (such as the HMI human-machine interaction module or the MCU control module), they submit the code to the corresponding development branch and initiate a code merge request to the preset develop branch or release branch. After the merge request is approved by the code review, the build process of this stage is automatically triggered without manual intervention to start the compilation.

[0049] Execution content: Source code retrieval: After receiving the trigger command, the build server (Jenkins) automatically retrieves the complete source code of the branch to be merged from the GitLab code repository, while verifying the code version number and the integrity of the commit record to ensure that the source code is not missing or tampered with. Compiler script reading: The build server retrieves the multi-platform cross-compilation build script pre-stored in the code repository. This script has built-in compilation instructions adapted to different automotive hardware platforms (such as Qualcomm 8295 chip and Renesas MCU chip), and can automatically match compilation parameters according to the hardware configuration of the target vehicle model. Multi-module image construction: Based on the compilation rules of the Build script, the various functional modules of the smart cockpit are compiled in parallel to generate independent module binary images that comply with the ISO 26262 automotive-grade functional safety standard, including but not limited to the HMI module image (responsible for rendering the cockpit interaction interface), the MCU control module image (responsible for executing vehicle equipment instructions), and the multimedia playback module image (responsible for audio and video content output), and each module image has a built-in integrity check code; Artifact repository storage: Upload the compiled multi-module binary images and image verification files to the enterprise-level artifact repository (such as Nexus), and give each image a unique version tag (including branch name, compilation time, and hardware compatibility model) to achieve version control and traceable retrieval of images.

[0050] The automated build phase solves the problem of low efficiency in traditional single-module serial compilation by cross-compiling across multiple platforms and parallel building. At the same time, the embedding of automotive-grade image standards ensures that the build products meet the safety operation requirements of the vehicle system. The image upload to the artifact repository enables unified storage and management of versions.

[0051] The automated testing phase solves the problem of low efficiency in traditional single-module serial compilation by cross-compiling across multiple platforms and parallel building. At the same time, the embedding of automotive-grade image standards ensures that the build products meet the safety operation requirements of the vehicle system. Uploading the image to the artifact repository enables unified storage and management of versions.

[0052] After the build phase is completed, the system automatically starts a Docker test container. This container has pre-integrated the runtime environment of test frameworks such as pytest, Robot Framework, and Vector CANoe, and establishes a communication link with the intelligent cockpit simulator and the real vehicle test platform, supporting seamless switching between the two environments.

[0053] The test container automatically retrieves a pre-defined test case set from the test case management library. This test case set is automatically generated and updated in real time based on the intelligent cockpit product requirements document, covering the following four core test dimensions: Functional testing: Verify the completeness and correctness of the core functions of each module, such as the voice command recognition function of the HMI module and the air conditioning control command execution function of the MCU module; Multi-protocol interface testing: For the HTTP interface (communication between the cockpit and cloud services), CAN bus interface (communication between the cockpit and the body control system), and LIN bus interface (communication between the cockpit and the vehicle low-voltage equipment), the stability and accuracy of interface data transmission were tested. The CAN bus communication test was completed by simulating real vehicle bus signals using Vector CANoe. Automotive-grade security check: Scanning the binary image and operating environment for security vulnerabilities such as open debug ports, invalid authentication, and unauthorized code calls to ensure compliance with vehicle system information security requirements; UI regression testing: Using image recognition algorithms (such as OpenCV) or control ID comparison technology, verify the layout consistency, control responsiveness, and multi-resolution adaptability of the HMI interface (such as 12.3-inch / 15.6-inch cockpit screen).

[0054] The test container automatically determines the pass status of a single test based on the preset test case pass threshold, and generates a standardized test report. The report includes core data such as the test pass rate of each module, defect type and location, and interface communication latency, and is associated with the execution log of the corresponding test case to achieve traceability of test results.

[0055] The automated testing phase solves the problems of incomplete coverage and difficulty in software and hardware integration in traditional testing by using multi-framework collaborative testing and dual-environment verification. The automated result judgment eliminates the subjective error of manual testing and provides accurate quality data support for the subsequent acceptance process.

[0056] To ensure that the intelligent cockpit software version meets automotive-grade delivery standards, the following quantitative acceptance indicators (i.e., Pass rules) are preset during the automatic acceptance phase. The indicator thresholds are set based on the functional safety and operational efficiency requirements of the in-vehicle system: Unit test pass rate ≥ 95%, ensuring that there are no logical defects in the core functions within the module; CAN bus communication accuracy is ≥99%, ensuring the communication stability between the cockpit and the body system; The number of functional defects is 0, meaning there are no fatal or serious defects that affect the operation of the core cockpit functions; The overall build time is ≤30 minutes to ensure timely version delivery.

[0057] The acceptance control module automatically retrieves the standardized test report generated during the automated testing phase and compares the data in the report with the preset pass rules one by one using the acceptance script: If all indicators meet the Pass rule, the system will automatically sign an acceptance pass electronic tag for this version and write the acceptance results, indicator details, test report link and other information into the acceptance audit log and synchronize it to the monitoring and feedback module. If any metric fails to meet the Pass rule, the system will automatically determine that the acceptance test has failed and output the specific unmet metric (e.g., "CAN bus communication accuracy is 98.5%, which does not meet the 99% threshold"). At the same time, the code rollback mechanism will be triggered to prevent this version from entering the subsequent deployment stage.

[0058] The automated acceptance phase replaces the traditional manual acceptance mode with quantified automotive-grade acceptance indicators and automated acceptance scripts, eliminating subjective judgment errors. The acceptance audit log enables the acceptance process to be auditable, meeting the full lifecycle traceability requirements of automotive-grade software.

[0059] The automated deployment phase includes: Pre-deployment verification: The deployment execution module first identifies the hardware status of the target test device (embedded test simulator or real vehicle cockpit terminal) through communication protocols (such as TCP / IP), including the device online status, remaining storage capacity, battery voltage (real vehicle scenario), etc. The subsequent deployment process is started only when the device status meets the deployment conditions (such as storage capacity ≥ 1.2 times the image size, real vehicle battery voltage ≥ 12V).

[0060] Image Push and Burning: Based on Ansible (simulator scenario) or Fastlane (real vehicle scenario) tools, the accepted multi-module binary image is pushed from the product warehouse to the target device, and the device-compatible burning tool (such as Fastboot) is automatically called to complete the image burning. The burning progress and integrity are monitored in real time during the burning process. Post-deployment self-test: After the image is burned, the target device automatically starts the cockpit system self-test process. The self-test includes module startup sequence, core function availability, bus communication connectivity, etc., and the self-test data is sent back to the deployment execution module in real time. Automatic Fault Rollback: If the self-test result shows deployment failure (such as module startup failure or communication interruption), the deployment execution module immediately calls the previous version image snapshot stored locally on the device to perform a one-click rollback operation. After the rollback is completed, the self-test is restarted to ensure that the device is restored to a stable operating state. At the same time, the fault information is pushed to the monitoring and feedback module for alarm.

[0061] The automated deployment phase solves the problems of error-prone traditional manual deployment and slow fault recovery by pre-deployment verification and automatic fault rollback. The dual tools adapt to different deployment scenarios, which improves the versatility of the solution and ensures the reliability and security of the smart cockpit version deployment.

[0062] This embodiment features a dedicated build engine module, built on Jenkins with a multi-level pipeline and a Docker containerized build environment. This isolates the compilation dependencies of different hardware targets and adapts to multi-platform cross-compilation requirements. In the automated build phase, it reads predefined multi-platform cross-compilation build scripts and can simultaneously generate images for multiple modules such as HMI, MCU control, and multimedia playback, meeting the requirements for parallel compilation and deployment of multiple versions. The build process incorporates automotive-grade security checks, ensuring that the generated binary images comply with automotive-grade security standards. Furthermore, the automated testing phase includes automotive-grade security checks (such as opening debug ports and invalid authentication checks) to adapt to the security restrictions of in-vehicle systems and meet the integration requirements of complex cockpit projects.

[0063] This embodiment establishes an end-to-end automated process of code integration → automatic build → automatic testing → automatic acceptance → automatic deployment. After code submission, the build is automatically triggered through the Merge Request mechanism. After acceptance, it is automatically deployed to the target device without manual initiation of each step. The code management module uses GitLab to achieve unified version control, setting standardized branch strategies for development, testing, and integration branches to avoid version confusion. The containerized environment in the build stage ensures consistency of environment across different projects and versions. If the deployment stage fails, it can automatically roll back to the previous successful version, avoiding errors introduced by manual operation and ensuring consistency between versions.

[0064] Example 2 The purpose of this embodiment is to provide an intelligent cockpit acceptance system based on continuous integration and continuous delivery technologies, including: The code management module is configured to integrate the code of multiple modules in the smart cockpit and set up an integration branch trigger mechanism; The build module is configured to automatically trigger the compilation process by the build server to generate a multi-module binary image of an intelligent cockpit system that meets automotive-grade requirements. The testing module is configured to execute test cases on the intelligent cockpit system, record test results in real time, and generate test reports. The acceptance module is configured to automatically determine, based on preset acceptance conditions and test report results, whether the smart cockpit software version corresponding to the multi-module binary image has passed acceptance through an acceptance script. The deployment module is configured to deploy the smart cockpit software version corresponding to the accepted multi-module binary image to an embedded test environment or a real vehicle environment.

[0065] In further embodiments, the following is also provided: An electronic device includes a memory and a processor, as well as computer instructions stored in the memory and running on the processor. When executed by the processor, the computer instructions perform the method described in Embodiment 1. For brevity, further details are omitted here.

[0066] It should be understood that in this embodiment, the processor can be a central processing unit (CPU), or it can be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0067] Memory may include read-only memory and random access memory, and provides instructions and data to the processor. A portion of memory may also include non-volatile random access memory. For example, memory may also store information about the device type.

[0068] A computer-readable storage medium for storing computer instructions, which, when executed by a processor, perform the method described in Embodiment 1.

[0069] The method in Embodiment 1 can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor. The software modules can reside in readily available storage media in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory; the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, a detailed description is not provided here.

[0070] A computer program product includes a computer program that, when executed by a processor, implements the method described in Embodiment 1.

[0071] The present invention also provides at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. The computer program product includes computer-executable instructions, such as instructions included in program modules, which execute in a device on a target real or virtual processor to perform the processes / methods described above. Typically, program modules include routines, programs, libraries, objects, classes, components, data structures, etc., that perform specific tasks or implement specific abstract data types. In various embodiments, the functionality of program modules can be combined or divided among program modules as needed. The machine-executable instructions for the program modules can execute within a local or distributed device. In a distributed device, the program modules can reside in both local and remote storage media.

[0072] The computer program code used to implement the methods of the present invention may be written in one or more programming languages. This computer program code may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the computer or other programmable data processing device, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a computer, partially on a computer, as a stand-alone software package, partially on a computer and partially on a remote computer, or entirely on a remote computer or server.

[0073] In the context of this invention, computer program code or related data may be carried by any suitable carrier to enable a device, apparatus, or processor to perform the various processes and operations described above. Examples of carriers include signals, computer-readable media, and the like. Examples of signals may include electrical, optical, radio, sound, or other forms of propagation signals, such as carrier waves, infrared signals, etc.

[0074] Those skilled in the art will recognize that the units and algorithm steps described in conjunction with the embodiments herein can be implemented in electronic hardware or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0075] While the specific embodiments of the present invention have been described above in conjunction with the accompanying drawings, this is not intended to limit the scope of protection of the present invention. Those skilled in the art should understand that various modifications or variations that can be made by those skilled in the art without creative effort based on the technical solutions of the present invention are still within the scope of protection of the present invention.

Claims

1. A smart cockpit acceptance method based on continuous integration and continuous delivery technologies, characterized in that, include: Integrate the code of multiple modules of the smart cockpit and set up an integration branch trigger mechanism; The server automatically triggers the compilation process to generate a multi-module binary image of an intelligent cockpit system that meets automotive-grade requirements. Execute test cases on the intelligent cockpit system, record test results in real time, and generate test reports; Based on preset acceptance conditions and test report results, the acceptance script automatically determines whether the smart cockpit software version corresponding to the multi-module binary image has passed the acceptance test. Deploy the smart cockpit software version corresponding to the accepted multi-module binary image to an embedded testing environment or a real vehicle environment.

2. The intelligent cockpit acceptance method based on continuous integration and continuous delivery technology as described in claim 1, characterized in that, The binary image includes one or more module images selected from the HMI module, MCU control module, and multimedia playback module.

3. The intelligent cockpit acceptance method based on continuous integration and continuous delivery technology as described in claim 1, characterized in that, Integrate the multi-module code of the smart cockpit through version control tools such as Git or GitLab; trigger the build process through the Merge Request mechanism to set up development branches, test branches and integration branches.

4. The intelligent cockpit acceptance method based on continuous integration and continuous delivery technology as described in claim 1, characterized in that, The system builds a multi-level pipeline based on Jenkins and uses Docker containerization to run the build environment, isolating the compilation dependencies of different hardware targets.

5. The intelligent cockpit acceptance method based on continuous integration and continuous delivery technology as described in claim 1, characterized in that, The automated testing process integrates one or more testing frameworks, including pytest, Robot Framework, and Vector CANoe, and the testing content also includes at least one of interface testing and security checks.

6. The intelligent cockpit acceptance method based on continuous integration and continuous delivery technology as described in claim 1, characterized in that, The version push and flashing are completed using Ansible or Fastlane tools. After deployment, the device self-test is started. If the self-test fails, the rollback process is used to revert to the previous successful version.

7. The intelligent cockpit acceptance method based on continuous integration and continuous delivery technology as described in claim 1, characterized in that, The test objects are multi-module binary images and corresponding software and hardware interaction logic.

8. An intelligent cockpit acceptance system based on continuous integration and continuous delivery technologies, characterized in that, include: The code management module is configured to integrate the code of multiple modules in the smart cockpit and set up an integration branch trigger mechanism; The build module is configured to automatically trigger the compilation process by the build server to generate a multi-module binary image of an intelligent cockpit system that meets automotive-grade requirements. The testing module is configured to execute test cases on the intelligent cockpit system, record test results in real time, and generate test reports. The acceptance module is configured to automatically determine, based on preset acceptance conditions and test report results, whether the smart cockpit software version corresponding to the multi-module binary image has passed acceptance through an acceptance script. The deployment module is configured to deploy the smart cockpit software version corresponding to the accepted multi-module binary image to an embedded test environment or a real vehicle environment.

9. An electronic device, characterized in that, It includes a memory and a processor, as well as computer instructions stored in the memory and running on the processor, which, when executed by the processor, perform the method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, Used to store computer instructions, which, when executed by a processor, perform the method described in any one of claims 1-7.

Images