Method and device for realizing intelligent cockpit scene driving development and test based on unified scene description language, processor and storage medium

Abstract

The present application relates to a kind of based on unified scene description language implementation intelligent cockpit scene driven development and test method, comprising the following steps: establishing USDL specification, unified scene description language specification definition scene atom;Product requirement is decomposed into user journey, and is decomposed into multiple independently triggered and indivisible scene atom, according to the structured description file of each scene atom of USDL specification writing;Converter set is built, and scene atom in scene atom library is converted into target platform file;When scene atom changes, CI / CD pipeline automatically triggers converter set, and no manual maintenance is generated. Experience-driven closed-loop optimization is realized, through USDL embedding NPS weight and time constraint, test result is associated with online NPS data, and scene priority and performance baseline are continuously calibrated;Non-invasive integration, converter adapts existing platform interface, can be non-invasively integrated into current conventional "function" mainly development process, so that verification is closer to real user operation.

Description

Technical Field

[0001] This invention relates to the field of automotive intelligence, and more particularly to the field of cockpit system development. Specifically, it relates to a method, apparatus, processor, and computer-readable storage medium for intelligent cockpit scene-driven development and testing based on a unified scene description language. Background Technology

[0002] With the development of automotive intelligence, intelligent cockpits have become a core area for automakers to differentiate their products and enhance user experience. Currently, the development and testing of intelligent cockpit systems face two major challenges: 1) Long development and debugging cycle for scenarios: Intelligent cockpits involve multiple domains such as cockpit domain (IVI), body domain (BCM), advanced driver assistance system (ADAS), and cloud domain (TSP). Scenarios have distributed, nonlinear, and multi-causal characteristics, while traditional development tools are based on the assumption of single domain, linearity, and single causality. This leads to cross-domain collaborative debugging requiring repeated communication, waiting for hardware to be ready, and difficulty in locating problems, with an average cycle of more than 2 weeks.

[0003] 2) Low coverage of system test scenarios: The combination space of user scenarios is exploding (factors such as vehicle speed, battery level, network, temperature, etc.). Traditional manual test cases can only cover the "happy path", and a large number of boundary, exception and concurrent scenarios are missed, resulting in poor user NPS (Net Promoter Score).

[0004] Currently, there is a lack of a standardized language that can uniformly describe scenarios and simultaneously drive development (generating interface contracts) and testing (generating automated test cases). Different domain teams use natural language or their own formatted functional requirements documents, leading to a lack of focus on scenario understanding among product, development, and testing teams. Instead, they focus solely on the functions they need to implement, resulting in low scenario design and test coverage. User feedback leads to repeated feature splitting and rework based on user scenarios, resulting in long development and improvement cycles and poor user NPS. Summary of the Invention

[0005] The purpose of this invention is to overcome the shortcomings of the prior art and provide a method, apparatus, processor and computer-readable storage medium for intelligent cockpit scene-driven development and testing based on a unified scene description language, which has the advantages of short debugging cycle, high scene coverage and wide applicability.

[0006] To achieve the above objectives, the present invention provides a method, apparatus, processor, and computer-readable storage medium for intelligent cockpit scene-driven development and testing based on a unified scene description language, as follows: The method for scenario-driven development and testing of intelligent cockpits based on a unified scenario description language is characterized by the following steps: (1) Establish a unified scenario description language (USDL) specification, wherein the USDL specification defines scenario atoms, and the scenario atoms include basic meta-information, triggers, preconditions, action sequences, expected results and time constraints; (2) Decompose product requirements into user journeys and into multiple independently triggerable and indivisible scenario atoms. Write a structured description file for each scenario atom according to the Unified Scenario Description Language (USDL) specification. The scenario atom carries the influence weight of user recommendation intention. (3) Construct a converter set to convert the scene atoms in the scene atom library into target platform files. The target platform files include contract files, automated test scripts, integrated environment configuration files, combined test model files, and objective indicator configuration files. (4) When scene atoms change, the CI / CD pipeline automatically triggers the converter set, generates and executes test scripts, and collects test results; generates a net recommender value change prediction report based on test results and actual indicator data, controls the deployment process based on the net recommender value change prediction report, and corrects scene atoms based on online net recommender value data.

[0007] Preferably, the basic metadata includes scene identifier and user recommendation intention influence weight, the trigger defines the scene start conditions, the preconditions describe the state that the system must meet before the scene is executed and organize signal constraints according to domain, the action sequence lists cross-domain call operations in sequence, the expected result defines the phenomena that should be observed after the scene is successful and their time limits, and the time constraint specifies the maximum allowable delay between key events.

[0008] Preferably, step (2) specifically includes the following steps: (2.1) Input user surveys, after-sales data and vehicle logs, decompose the user journey, and output a list of touchpoints, actions and feedback; (2.2) Extract scene atoms and output candidate scene atoms; (2.3) Perform atomic particle size review and output the smallest atom that is confirmed to be indivisible; (2.4) Perform structured writing of a unified scenario description language and output a structured description file that conforms to JSON Schema; (2.5) Perform atomic verification and storage, output verification report and storage Git, and form the atomic library of the scenario.

[0009] Preferably, the determination rule for performing atomic granularity review in step (2.3) is as follows: the scene atom has a clear trigger; after execution, there is at least one expected result that supports automated detection; and the scene atom cannot be further divided.

[0010] Preferably, the converter set includes a USDL-to-PACT converter, a USDL-to-TestCase converter, a USDL-to-Simulation converter, a USDL-to-Factors converter, and a USDL-to-Metrics converter. The USDL-to-PACT converter is used to generate an interface contract file from the action sequence. The USDL-to-TestCase converter is used to generate an executable automated test script from the scene atoms. The USDL-to-Simulation converter is used to generate signal configuration and event scripts for a virtual integrated environment. The USDL-to-Factors converter is used to extract factors and values ​​from the parameters of the preconditions and action sequence to generate a combined test model file. The USDL-to-Metrics converter is used to extract the influence weights and time constraints of the user's recommendation intention to generate an objective metric configuration file.

[0011] Preferably, step (4) specifically includes the following steps: (4.1) Perform syntax validation and output a validation report; (4.2) Generate and verify the contract; (4.3) Perform factor extraction and combination generation, and output the combined use case set; (4.4) Generate the test script and output the pytest script; (4.5) Perform various types of tests and output the test results; (4.6) Perform net promoter value (NPV) prediction and output a NPV change prediction report; (4.7) Deploy and output OTA grayscale.

[0012] Preferably, step (4) of correcting the scenario atom based on online net promoter score data specifically includes the following steps: Feedback action is triggered when any of the following feedback trigger conditions are met: the complaint rate in the online Net Promoter Score survey is greater than 5%, the success rate shown in online tracking data is less than 95%, or the number of times the work order is marked is greater than 3. The feedback actions include: the system automatically creates candidate modification requests; after manual approval, they are merged, triggering a new round of the pipeline; if the modification is successful and the online net promoter score improves, it is solidified; otherwise, it is rolled back.

[0013] The device for scenario-driven development and testing of intelligent cockpits based on a unified scenario description language is characterized by the following: A processor is configured to execute computer-executable instructions; The memory stores one or more computer-executable instructions, which, when executed by the processor, implement the various steps of the method for scene-driven development and testing of intelligent cockpit based on a unified scene description language.

[0014] The processor for intelligent cockpit scene-driven development and testing based on a unified scene description language is characterized in that the processor is configured to execute computer-executable instructions, and when the computer-executable instructions are executed by the processor, the various steps of the above-mentioned method for intelligent cockpit scene-driven development and testing based on a unified scene description language are implemented.

[0015] The main feature of this computer-readable storage medium is that it stores a computer program thereon, which can be executed by a processor to implement the various steps of the above-described method for scene-driven development and testing of intelligent cockpit based on a unified scene description language.

[0016] This invention employs a method, apparatus, processor, and computer-readable storage medium based on a unified scenario description language (USDL) for scenario-driven development and testing of intelligent cockpits. This shortens the cross-domain collaborative debugging cycle by automatically generating contract files and test scripts using USDL atomically. Development and testing are based on the same file, eliminating the need to wait for real-vehicle integration testing. The cross-domain debugging cycle is expected to be reduced from an average of two weeks to two days, a reduction of over 85%. It also improves system test scenario coverage by automatically extracting and combining factors, increasing scenario combination space coverage from less than 30% to over 85%, automatically covering boundary, anomaly, and concurrent scenarios. Furthermore, it reduces labor costs by shortening test script writing time by over 80%, and automatically synchronizing tests when scenarios change, eliminating the need for manual maintenance. Finally, it achieves experience-driven closed-loop optimization by embedding NPS weights and time constraints within USDL, linking test results with online NPS data to continuously calibrate scenario priorities and performance baselines. Finally, it enables non-intrusive integration, with converters adapting to existing platform interfaces and allowing non-intrusive integration into current conventional "function-centric" development processes, making verification more closely resemble real user operations. Attached Figure Description

[0017] Figure 1 This is a schematic diagram illustrating the descriptive composition of scene atoms in the method for scene-driven development and testing of intelligent cockpit based on a unified scene description language according to the present invention.

[0018] Figure 2 This is an integrated architecture diagram of USDL, which is based on the unified scene description language to realize scene-driven development and testing of intelligent cockpit according to the present invention.

[0019] Figure 3 This is an integration architecture diagram for routine functional testing.

[0020] Figure 4 This is a schematic diagram of the workflow for the method of intelligent cockpit scene-driven development and testing based on a unified scene description language according to the present invention.

[0021] Figure 5 This is a schematic diagram of the execution logic of various converters in the USDL (Unified Scene Description Language) method for scene-driven development and testing of intelligent cockpits, as described in this invention. Detailed Implementation

[0022] To more clearly describe the technical content of the present invention, the following description is provided in conjunction with specific embodiments.

[0023] The present invention discloses a method for scene-driven development and testing of intelligent cockpits based on a unified scene description language, comprising the following steps: (1) Establish a unified scenario description language (USDL) specification, wherein the USDL specification defines scenario atoms, and the scenario atoms include basic meta-information, triggers, preconditions, action sequences, expected results and time constraints; (2) Decompose product requirements into user journeys and into multiple independently triggerable and indivisible scenario atoms. Write a structured description file for each scenario atom according to the Unified Scenario Description Language (USDL) specification. The scenario atom carries the influence weight of user recommendation intention. (3) Construct a converter set to convert the scene atoms in the scene atom library into target platform files. The target platform files include contract files, automated test scripts, integrated environment configuration files, combined test model files, and objective indicator configuration files. (4) When scene atoms change, the CI / CD pipeline automatically triggers the converter set, generates and executes test scripts, and collects test results; generates a net recommender value change prediction report based on test results and actual indicator data, controls the deployment process based on the net recommender value change prediction report, and corrects scene atoms based on online net recommender value data.

[0024] In a preferred embodiment of the present invention, the basic metadata includes scene identifier and user recommendation intention influence weight, the trigger defines the scene start conditions, the preconditions describe the state that the system must meet before the scene is executed and organize signal constraints according to domains, the action sequence lists cross-domain call operations in sequence, the expected result defines the phenomena that should be observed after the scene is successful and their time limits, and the time constraint specifies the maximum allowable delay between key events.

[0025] In a preferred embodiment of the present invention, step (2) specifically includes the following steps: (2.1) Input user surveys, after-sales data and vehicle logs, decompose the user journey, and output a list of touchpoints, actions and feedback; (2.2) Extract scene atoms and output candidate scene atoms; (2.3) Perform atomic particle size review and output the smallest atom that is confirmed to be indivisible; (2.4) Perform structured writing of a unified scenario description language and output a structured description file that conforms to JSON Schema; (2.5) Perform atomic verification and storage, output verification report and storage Git, and form the atomic library of the scenario.

[0026] As a preferred embodiment of the present invention, the determination rule for performing atomic granularity review in step (2.3) is as follows: there is a clear trigger for the scene atom; there is at least one expected result that supports automated detection after execution; and the scene atom cannot be further divided.

[0027] In a preferred embodiment of the present invention, the converter set includes a USDL-to-PACT converter, a USDL-to-TestCase converter, a USDL-to-Simulation converter, a USDL-to-Factors converter, and a USDL-to-Metrics converter. The USDL-to-PACT converter is used to generate an interface contract file from the action sequence. The USDL-to-TestCase converter is used to generate an executable automated test script from the scene atoms. The USDL-to-Simulation converter is used to generate signal configuration and event scripts for a virtual integrated environment. The USDL-to-Factors converter is used to extract factors and values ​​from the parameters of the preconditions and action sequence to generate a combined test model file. The USDL-to-Metrics converter is used to extract the influence weights and time constraints of the user's recommendation intention to generate an objective metric configuration file.

[0028] In a preferred embodiment of the present invention, step (4) specifically includes the following steps: (4.1) Perform syntax validation and output a validation report; (4.2) Generate and verify the contract; (4.3) Perform factor extraction and combination generation, and output the combined use case set; (4.4) Generate the test script and output the pytest script; (4.5) Perform various types of tests and output the test results; (4.6) Perform net promoter value (NPV) prediction and output a NPV change prediction report; (4.7) Deploy and output OTA grayscale.

[0029] As a preferred embodiment of the present invention, step (4) of correcting the scenario atom based on online net promoter score data specifically includes the following steps: Feedback action is triggered when any of the following feedback trigger conditions are met: the complaint rate in the online Net Promoter Score survey is greater than 5%, the success rate shown in online tracking data is less than 95%, or the number of times the work order is marked is greater than 3. The feedback actions include: the system automatically creates candidate modification requests; after manual approval, they are merged, triggering a new round of the pipeline; if the modification is successful and the online net promoter score improves, it is solidified; otherwise, it is rolled back.

[0030] The present invention relates to an apparatus for intelligent cockpit scene-driven development and testing based on a unified scene description language, wherein the apparatus comprises: A processor is configured to execute computer-executable instructions; The memory stores one or more computer-executable instructions, which, when executed by the processor, implement the various steps of the method for scene-driven development and testing of intelligent cockpit based on a unified scene description language.

[0031] The present invention discloses a processor for intelligent cockpit scene-driven development and testing based on a unified scene description language. The processor is configured to execute computer-executable instructions, and when the computer-executable instructions are executed by the processor, the various steps of the above-described method for intelligent cockpit scene-driven development and testing based on a unified scene description language are implemented.

[0032] The computer-readable storage medium of the present invention stores a computer program thereon, which can be executed by a processor to implement the various steps of the above-described method for scene-driven development and testing of intelligent cockpit based on a unified scene description language.

[0033] This invention aims to provide a scenario-driven development and testing method for intelligent cockpits based on a unified scenario description language, in order to solve the problems of long cross-domain collaborative debugging cycles and low system test scenario coverage in existing technologies. It realizes the transformation of vague user scenarios into accurate and executable engineering data; one end generates interface contracts to drive development, and the other end generates automated test cases to drive verification; it significantly shortens the cross-domain joint debugging cycle, improves scenario coverage, and ultimately supports NPS improvement.

[0034] The present invention adopts the following technical solution: A scenario-driven development and testing method for intelligent cockpits based on the Unified Scenario Description Language (USDL) includes the following steps: Step S1: Establish the Unified Scenario Description Language (USDL) specification USDL uses the YAML format, and each scene atom consists of the following six modules: Basic metadata includes a unique identifier (id), a name, a semantic version (version), and an NPS impact coefficient (nps_weight) (1-5 points). Trigger: Defines the conditions for starting a scene, including trigger type (voice command, button press, gesture, vehicle status, timer), keyword list, and confidence threshold; Preconditions: Describe the states that the system must meet before the scenario is executed. Organize signal constraints by domain (vehicle, environment, cockpit, cloud) and include enumerated values ​​(in), continuous range (range), and exact equal to (eq). Actions: Lists cross-domain calls in sequence. Each action includes the execution order, target domain, operation name, and parameters or payload. Expectations: Define the phenomena that should be observed after the scenario is successful, including the check type (such as TTS broadcast, window position, UI update, CAN signal), parameters, and time limit (time_limit_ms). Time constraints (time_constraints): Specifies the maximum allowable delay between critical events, including the start event from, the end event to, and the maximum delay max_ms.

[0035] Step S2: Build the scene atomic library Product requirements are broken down into user journeys, and then further broken down into independently triggerable, observable, and indivisible scenario atoms. These are stored in a Git repository according to USDL specifications, forming a scenario atom library. Each atom carries an NPS weight derived from user surveys and after-sales data.

[0036] The process of constructing USDL scene atoms is as follows: (1) The inputs are user surveys, after-sales data and vehicle logs. The user journey is decomposed and the outputs are touchpoints, actions and feedback lists. (2) The input is a list of touch points, actions, and feedback, which is used to extract scene atoms and output candidate scene atoms; (3) The input is a list of candidate atoms, the atomic particle size is reviewed, and the output is the smallest atom that is confirmed to be indivisible. (4) The input is the confirmed atom, which is then written in USDL structure and output as a YAML file conforming to JSONSchema; (5) The input is a YAML file, which is then atomically checked and stored in the database. The output is a check report and stored in Git.

[0037] The USDL atomic granularity determination rule states that a scene atom must satisfy all of the following conditions: Independent triggering: There is a definite trigger, and it does not depend on the intermediate state of other atoms; Observable: After execution, at least one expected result can be automatically detected; Indivisible: If broken down into smaller steps, each step cannot form an independent closed loop of user value.

[0038] Step S3: Provide a converter set to interface with standard "feature" development processes and capabilities. Develop a set of converters to automatically convert USDL atoms into files usable on various platforms: usdl-to-pact: Generates Pact contract files from USDL action sequences and uploads them to the Pact Broker for providers (such as vehicle domains) to verify the contracts; usdl-to-testcase: Generates executable automated test scripts (pytest, Robot Framework, etc.) and integrates them into CI / CD pipelines; usdl-to-simulation: Generates signal configurations and event scripts for a virtual integrated environment, driving simulation / HIL / real vehicle execution; usdl-to-factors: Extracts factors and values ​​from preconditions and actions.params to generate combined test model files (such as PICT format), supporting orthogonal combination generation; usdl-to-metrics: Extracts nps_weight and time_constraints, generates an objective metric configuration file, and connects to the NPS prediction model.

[0039] USDL's various converters execute logic such as Figure 5 As shown.

[0040] The various converters are described below: Step S4: Integrate CI / CD pipeline to achieve automated closed loop When a USDL atom is committed or changed, the CI / CD pipeline automatically triggers all converters; The generated test scripts are executed in parallel, and the test results (pass / fail, actual latency, etc.) are collected. The actual indicators are compared with the baseline defined in USDL and pushed to the NPS prediction model to generate an NPS change prediction report. If a decrease in NPS is predicted, the pipeline will be blocked or a manual review will be triggered; if the access control is passed, deployment will proceed automatically (such as OTA canary release). Compare online NPS data with prediction results, and correct nps_weight or time constraints in USDL through a closed-loop process.

[0041] The CI / CD closed-loop management process is as follows: (1) The pipeline triggering conditions are as follows: 1) Trigger source: Push or merge request to the Git repository of the scenario atomic library (for USDL files); Scheduled trigger (daily); Upstream dependencies (such as vehicle body domain interface updates) trigger a rerun.

[0042] 2) Triggering rules: Only if the changed file path matches atoms / The scenario testing process is triggered when the .yaml file is accessed.

[0043] neglect Change the .md or README file.

[0044] (2) The stages and access control parameters of the production line are as follows: (3) Closed-loop feedback rule The feedback trigger conditions are as follows: In online NPS surveys, the complaint rate related to a certain scenario is greater than the threshold (e.g., 5%). Online tracking data shows a success rate of <95% in a certain scenario; This scenario was marked more than 3 times in the after-sales work orders.

[0045] The feedback action is as follows: 1) The system automatically creates candidate PRs for modification: adjust nps_weight (increase or decrease) or modify time_constraints.max_ms (relax or tighten).

[0046] 2) After manual approval, the merged data triggers a new round of CI / CD.

[0047] 3) If the modification is successful and the online NPS improves, then apply the changes; otherwise, roll back.

[0048] Core principle: USDL (Unified Scenario Description Language) uses a five-tuple structure (trigger + precondition + action + expectation + timing) to transform a user-perceptible behavior (such as voice-activated window control) into a precise, executable, composable, and measurable engineering description. It eliminates the ambiguity of natural language and connects the entire data chain from requirements, development, testing to experience measurement.

[0049] The composition of a scene atom is as follows Figure 1 As shown.

[0050] The description of the scene atoms is shown in the figure below.

[0051] The integration architecture diagram of USDL with the current conventional "functional testing" is as follows: Figure 2 and Figure 3 As shown.

[0052] Example: USDL description and automated verification of a voice-controlled driver's side window lowering scenario. Step 1: Write USDL atomic files (scenario engineering descriptions) Create the file S-VOICE-WIN-001.yaml.

[0053] Step 2: Commit to the Git repository and trigger CI / CD The scenario definer submits the above YAML file to the Git repository of the scenario atomic library. The CI / CD pipeline detects the change and automatically executes: Running usdl-to-pact generates a Pact file ivi_bcm_pact.json, containing the cockpit domain's expected requests and responses to the body domain's set_window interface. This is uploaded via the Pact Broker API, and the body domain CI automatically runs pact-verifier to verify interface consistency.

[0054] Run usdl-to-factors: Extract the factor model file factors.txt: text gear_position: P, N vehicle_speed: 0, 3, 5, 60 window_lock: true, false online_status: online, offline window_percent: 0, 30, 100 Use the PICT tool to generate 30 combined test cases.

[0055] Run usdl-to-testcase: Generates the corresponding pytest script for each combined test case.

[0056] Running usdl-to-simulation generates the virtual integrated environment configuration file sim_config.json and the event script events.py.

[0057] Step 3: Test Execution and Result Collection The CI / CD pipeline launches 30 simulation containers in parallel (each containing a cockpit simulator and a signal simulator), running the pytest script. Each script executes the following sequentially: Set the initial signal according to the preconditions (vehicle speed 3km / h, P gear, window lock closed, etc.); Inject the voice command "Open the driver's side window"; Poll and check TTS broadcast, window position, UI status, and record actual latency; Assert that all expectations are satisfied within time_limit_ms.

[0058] The execution results (pass / fail, actual latency) are summarized in JUnit format.

[0059] Step 4: NPS Prediction and Loop Closure Run usdl-to-metrics to extract baselines: NPS weight of 4.2 for scenario IDS-VOICE-WIN-001, baseline latency of 800ms and 1200ms. Push the average latency obtained from actual testing (e.g., 890ms) to the NPS prediction model service. The model predicts that the NPS of this version may decrease by 1.5%, triggering manual review in the pipeline.

[0060] After review and approval, the version will be released via OTA (Over-The-Air) canary release. Real user NPS data will be collected online. If an increase in the complaint rate related to this scenario is detected, the updated NPS weights or time constraints will be written back to the USDL atomic file through a closed-loop process to achieve continuous evolution.

[0061] Step 5: Verification of Technical Effectiveness After adopting the solution in this embodiment, the cross-domain integration testing time for this scenario was shortened from 14 days to 1.5 days, the scenario combination coverage increased from 10 manually generated test cases to 30 automatically generated test cases (covering all paired combinations), and the test script writing time was reduced from 4 hours to 10 minutes. Online NPS monitoring showed that the user complaint rate related to window control decreased by 45%.

[0062] Workflow such as Figure 4 As shown.

[0063] This application focuses on scenario testing, embedding standard functional and performance requirements into scenario testing. Furthermore, scenario testing integrates market user NPS values, linking R&D testing with market feedback to create a closed-loop management system throughout the product lifecycle for both R&D and users.

[0064] In specific embodiments of this invention, the concept of cockpit domain control in this field is in its initial stage. Current industry practices typically involve first converting requirements into functional and performance specifications, then using natural language to describe these specifications, followed by development and testing. Unit testing, integration testing, and system testing are then conducted by reading and understanding the natural language requirements, followed by the writing of test cases and scripts. The conversion of requirements to test parameters (unit, integration, system) is achieved through human-written test cases and scripts based on an understanding of the natural language requirements during test case / script writing. It is not performed using an executable converter.

[0065] NPS (Network Performance Scale) evaluation has multiple dimensions, with cabin scenario experience being a crucial factor. Currently, industry scenario evaluations are often subjective and involve specific user groups, leaving little time or resources for targeted testing with specific user groups. Instead, they rely more on AI to collect actual user behavior and feedback for comprehensive analysis before adjusting features. This closed-loop mechanism involves adjusting features based on AI analysis, rather than directly evaluating and responding to individual customer feedback scenarios.

[0066] Natural language description and USDL language corresponding YAML file description: Scene Atomic Identifier: S-VOICE-WIN-001 Scenario Name: Voice-controlled lowering of driver's window NPS impact weight: 4.2 (out of 5, indicating that this scenario has a high impact on users' willingness to make recommendations).

[0067] Triggering conditions: Users initiate operations via voice commands, including "open the driver's side window," "open window," or "open driver's side window." A voice recognition confidence score of 0.8 or higher is required for a valid trigger.

[0068] Prerequisites: Before executing this scenario, the system must meet the following conditions: Vehicle status: Gear is in P or N; vehicle speed is between 0 and 5 km / h; windows are closed (i.e., not locked).

[0069] Environment settings: System language is set to Chinese (Simplified); network status can be online or offline.

[0070] Action sequence (executed in order): 1. The cockpit domain (IVI) performs voice recognition (ASR) with a timeout of 2000 milliseconds.

[0071] 2. The gateway routes the command to the Body Control Module (BCM), carrying the following parameters: service is window control, target location is the driver's side, and the percentage of descent is 30%.

[0072] 3. Body Module (BCM) performs window setting operations: driver's side window lowers by 30%, maximum execution time is 3000 milliseconds.

[0073] Expected results (to be met within the specified timeframe): In-Cockpit Domain (IVI): Within 800 milliseconds, the system should deliver a response containing keywords such as "OK" or "Opening" via text-to-speech (TTS).

[0074] Vehicle status: The driver's side window should be 30% open within 1200 milliseconds, with an allowable error of ±2% (i.e., 28%~32%).

[0075] In-Vehicle Context (IVI): Within 500 milliseconds, the window status controls on the UI should be updated to "opening".

[0076] Time constraints (maximum delay between critical events): The time from the start of speech recognition (ASR_start) to the completion of TTS playback (TTS_play) must not exceed 800 milliseconds.

[0077] The time from the start of voice recognition (ASR_start) to the start of window movement (window_move_start) must not exceed 1200 milliseconds.

[0078] The core problem addressed by the technical solution of this invention is the long cross-domain collaborative debugging cycle (average 2 weeks) and low system test scenario coverage (less than 30%), leading to poor user experience (NPS). Furthermore, the difficulty in cross-domain (IVI / BCM / ADAS / TSP) distributed, nonlinear, and multi-causal collaborative debugging makes it difficult to quantify the user's subjective experience. The technical path is: USDL atom + five types of converters → contract / test / simulation / combination factor / NPS index → ​​CI / CD access control → online NPS closed-loop correction.

[0079] The technical solution of this invention proposes features such as NPS weighting, contract generation, NPS prediction access control, and online experience closed loop. The combination of user experience measurement (NPS) with scene description language, CI / CD access control, and online feedback closed loop is unprecedented in existing technologies. This invention belongs to the field of intelligent cockpit R&D, focusing on cross-domain collaboration efficiency and user experience quantification closed loop. Specific implementation schemes of this embodiment can be found in the relevant descriptions in the above embodiments, and will not be repeated here.

[0080] It is understood that the same or similar parts in the above embodiments can be referred to each other, and the contents not described in detail in some embodiments can be referred to the same or similar contents in other embodiments.

[0081] It should be noted that in the description of this invention, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. Furthermore, in the description of this invention, unless otherwise stated, "a plurality of" means at least two.

[0082] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of the invention includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as will be understood by those skilled in the art to which embodiments of the invention pertain.

[0083] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution device. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0084] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The corresponding program can be stored in a computer-readable storage medium. When the program is executed, it includes one or a combination of the steps of the method embodiments.

[0085] Furthermore, the functional units in the various embodiments of the present invention can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0086] The storage media mentioned above can be read-only memory, disk, or optical disk, etc.

[0087] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0088] This invention employs a method, apparatus, processor, and computer-readable storage medium based on a unified scenario description language (USDL) for scenario-driven development and testing of intelligent cockpits. This shortens the cross-domain collaborative debugging cycle by automatically generating contract files and test scripts using USDL atomically. Development and testing are based on the same file, eliminating the need to wait for real-vehicle integration testing. The cross-domain debugging cycle is expected to be reduced from an average of two weeks to two days, a reduction of over 85%. It also improves system test scenario coverage by automatically extracting and combining factors, increasing scenario combination space coverage from less than 30% to over 85%, automatically covering boundary, anomaly, and concurrent scenarios. Furthermore, it reduces labor costs by shortening test script writing time by over 80%, and automatically synchronizing tests when scenarios change, eliminating the need for manual maintenance. Finally, it achieves experience-driven closed-loop optimization by embedding NPS weights and time constraints within USDL, linking test results with online NPS data to continuously calibrate scenario priorities and performance baselines. Finally, it enables non-intrusive integration, with converters adapting to existing platform interfaces and allowing non-intrusive integration into current conventional "function-centric" development processes, making verification more closely resemble real user operations.

[0089] In this specification, the invention has been described with reference to specific embodiments thereof. However, it will be apparent that various modifications and variations can be made without departing from the spirit and scope of the invention. Therefore, the specification and drawings should be considered illustrative rather than restrictive.

Claims

1. A method for scenario-driven development and testing of intelligent cockpits based on a unified scenario description language, characterized in that, The method includes the following steps: (1) Establish a unified scenario description language (USDL) specification, wherein the USDL specification defines scenario atoms, and the scenario atoms include basic meta-information, triggers, preconditions, action sequences, expected results and time constraints; (2) Decompose product requirements into user journeys and into multiple independently triggerable and indivisible scenario atoms. Write a structured description file for each scenario atom according to the Unified Scenario Description Language (USDL) specification. The scenario atom carries the influence weight of user recommendation intention. (3) Construct a converter set to convert the scene atoms in the scene atom library into target platform files. The target platform files include contract files, automated test scripts, integrated environment configuration files, combined test model files, and objective indicator configuration files. (4) When scene atoms change, the CI / CD pipeline automatically triggers the converter set, generates and executes test scripts, and collects test results; generates a net recommender value change prediction report based on test results and actual indicator data, controls the deployment process based on the net recommender value change prediction report, and corrects scene atoms based on online net recommender value data.

2. The method for scene-driven development and testing of intelligent cockpit based on a unified scene description language according to claim 1, characterized in that, The basic metadata includes scene identifiers and user recommendation intention influence weights. The trigger defines the scene's start conditions. The preconditions describe the state that the system must meet before the scene is executed and organize signal constraints according to domains. The action sequence lists cross-domain call operations in sequence. The expected result defines the phenomena that should be observed after the scene is successful and their time limits. The time constraint specifies the maximum allowable delay between key events.

3. The method for scene-driven development and testing of intelligent cockpit based on a unified scene description language according to claim 1, characterized in that, Step (2) specifically includes the following steps: (2.1) Input user surveys, after-sales data and vehicle logs, decompose the user journey, and output a list of touchpoints, actions and feedback; (2.2) Extract scene atoms and output candidate scene atoms; (2.3) Perform atomic particle size review and output the smallest atom that is confirmed to be indivisible; (2.4) Perform structured writing of a unified scenario description language and output a structured description file that conforms to JSON Schema; (2.5) Perform atomic verification and storage, output verification report and storage Git, and form the atomic library of the scenario.

4. The method for scene-driven development and testing of intelligent cockpit based on a unified scene description language according to claim 3, characterized in that, The criteria for determining the atomic granularity of step (2.3) are as follows: there are explicit triggers in the scene atoms; and there is at least one expected result that supports automated detection after execution. Furthermore, the scene atoms cannot be further divided.

5. The method for scene-driven development and testing of intelligent cockpit based on a unified scene description language according to claim 1, characterized in that, The converter set includes a USDL-to-PACT converter, a USDL-to-TestCase converter, a USDL-to-Simulation converter, a USDL-to-Factors converter, and a USDL-to-Metrics converter. The USDL-to-PACT converter is used to generate an interface contract file from the action sequence. The USDL-to-TestCase converter is used to generate an executable automated test script from the scene atoms. The USDL-to-Simulation converter is used to generate signal configuration and event scripts for a virtual integrated environment. The USDL-to-Factors converter is used to extract factors and values ​​from the parameters of the preconditions and action sequence to generate a combined test model file. The USDL-to-Metrics converter is used to extract the influence weights and time constraints of the user's recommendation intention to generate an objective metric configuration file.

6. The method for scene-driven development and testing of intelligent cockpit based on a unified scene description language according to claim 1, characterized in that, Step (4) specifically includes the following steps: (4.1) Perform syntax validation and output a validation report; (4.2) Generate and verify the contract; (4.3) Perform factor extraction and combination generation, and output the combined use case set; (4.4) Generate the test script and output the pytest script; (4.5) Perform various types of tests and output the test results; (4.6) Perform net promoter value (NPV) prediction and output a NPV change prediction report; (4.7) Deploy and output OTA grayscale.

7. The method for scene-driven development and testing of intelligent cockpit based on a unified scene description language according to claim 1, characterized in that, Step (4) of the above-mentioned process of correcting the scenario atom based on online net promoter score data specifically includes the following steps: Feedback action is triggered when any of the following feedback trigger conditions are met: the complaint rate in the online Net Promoter Score survey is greater than 5%, the success rate shown in online tracking data is less than 95%, or the number of times the work order is marked is greater than 3. The feedback actions include: the system automatically creates candidate modification requests; after manual approval, they are merged, triggering a new round of the pipeline; if the modification is successful and the online net promoter score improves, it is solidified; otherwise, it is rolled back.

8. A device for scenario-driven development and testing of intelligent cockpits based on a unified scenario description language, characterized in that, The device includes: A processor is configured to execute computer-executable instructions; The memory stores one or more computer-executable instructions, which, when executed by the processor, implement the steps of the method for scene-driven development and testing of intelligent cockpit based on a unified scene description language as described in any one of claims 1 to 7.

9. A processor for scene-driven development and testing of intelligent cockpits based on a unified scene description language, characterized in that, The processor is configured to execute computer-executable instructions, which, when executed by the processor, implement the steps of the method for scene-driven development and testing of intelligent cockpit based on a unified scene description language as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, It stores a computer program that can be executed by a processor to implement the various steps of the method for scene-driven development and testing of intelligent cockpit based on a unified scene description language, as described in any one of claims 1 to 7.

Images