A method and system for generating vehicle software and a storage medium

Abstract

The application discloses a kind of generation methods of vehicle software, it includes: step S10, call preset scene library, and select at least one scene template as trigger scene in it;Step S11, call preset interaction library, and select at least one interaction set in it and add to the output of trigger scene;Step S12, call preset service library, and select at least one service set in it, add to the output of trigger scene or interaction set;Step S13, form vehicle software for cockpit intelligent scene.The application also discloses corresponding system and storage medium.Embodiment of the application can quickly, flexibly generate obtain vehicle software product, can greatly reduce development cost and improve product development efficiency.

Description

Technical Field

[0001] This invention relates to the field of intelligent connected vehicle technology, and in particular to a method, system, and storage medium for generating in-vehicle software. Background Technology

[0002] Software-defined vehicle (SDV) has become a new direction in the development of intelligent vehicles. In the SDV model, in-vehicle software is managed by the OEM as an independent software, making its design a crucial issue and primary task for OEMs. Traditional automotive software product development is function-oriented, requiring collaboration from multiple ECUs and involving multiple suppliers, resulting in long development cycles and high costs. Furthermore, current technologies mostly employ a one-time development approach; developing new scenarios and services requires rewriting code, leading to low efficiency and high costs. Additionally, the developed products or services lack comprehensive vehicle-level testing, posing certain safety risks and user experience defects.

[0003] Therefore, the software-defined vehicle trend necessitates the separation of hardware and software development, and the separation of software release and vehicle model release has become a trend. However, the industry currently lacks corresponding methods and development tools for developing in-vehicle software products. Summary of the Invention

[0004] The technical problem to be solved by this invention is to provide a method, system, and storage medium for generating in-vehicle software. This allows for the separation of in-vehicle software product development and vehicle deployment, enabling rapid and efficient development of in-vehicle software products.

[0005] To address the aforementioned technical problems, as one aspect of the present invention, a method for generating in-vehicle software is provided, comprising the following steps:

[0006] Step S10: Call the preset scene library and select the desired scene template related to the vehicle software as the trigger scene; each scene template consists of at least one meta scene, which is an external state, vehicle state or vehicle user state signal.

[0007] Step S11: Call the preset interaction library and select at least one interaction set related to the desired in-vehicle software to add to the output port of the trigger scene;

[0008] Step S12: Call the preset service library and select at least one service set related to the desired vehicle software, and add it to the output port of the trigger scene or interaction set; the service set is configured with the execution sequence relationship of at least one service and / or the duration of service execution;

[0009] Step S13: After combining the scenarios, selected services, and interaction methods, in-vehicle software for intelligent cockpit scenarios is formed.

[0010] This further includes:

[0011] Pre-generate scene libraries, interaction libraries, service libraries, and visualization software generation devices suitable for various vehicle models; among which:

[0012] A scene built in the scene library consists of at least one scene template. Each scene template is composed of one or more meta-scenes. The meta-scenes within a scene template are combined using at least one of the logical relationships of AND, OR, or NOT, and the timing relationship can be configured.

[0013] The interaction library contains multiple interaction sets, each including at least one interaction cycle. Each interaction cycle contains an input unit and an output unit, where the input unit includes a function initiation input unit and a preference input unit; the output unit includes a preference output unit and a service content output unit; the interaction cycles within the same interaction set support configurable timing relationships.

[0014] Services built in the service library exist in the form of service sets. A service set consists of one or more meta services or atomic services. Services within a service set support configuring the service execution sequence and the duration of service execution. Atomic services correspond to the in-vehicle function services that the vehicle itself can provide, while meta services correspond to third-party ecosystem services obtained through the Internet of Vehicles.

[0015] The visualization software generation device is used to call the scene library, interaction library, and service library, and perform visualization combination processing, while also providing a simulation startup function.

[0016] In the interaction set, the function initiation input unit is represented by the following formula:

[0017] {Target Function: <Input Method>, <Input Point>}

[0018] In the formula, the target function refers to the function of the in-vehicle software that needs to be guided to be realized in the interaction; the input methods include three types: physical button input, voice input, and body posture input; the input point is the button, voice command, or gesture action that carries a clear input purpose in the specific input method.

[0019] The input cell for the preferred option is represented by the following formula:

[0020]

[0021] In the formula, the service willingness is indicated by "yes" or "no", and the service options refer to the service options provided by the vehicle software. The input method is the same as the input method of the function initiation input unit.

[0022] The intention option output unit is represented by the following formula:

[0023]

[0024] In this formula, service willingness is indicated by "yes" or "no"; output method is divided into three types: visual output, auditory output, and haptic output; input method prompts indicate which method to use for selection; service options refer to the service options provided by the in-vehicle software.

[0025] The service content output unit is represented by the following formula:

[0026] {Service content: <Output method 1, component, parameter>; <Output method 2, component, parameter>...; Input method prompt}.

[0027] In step S13, before forming the initial in-vehicle software for the intelligent cockpit scenario, a further step is included to perform a detection step of preset product design rules, object connection rules, and object triggering rules.

[0028] Step S13 further includes:

[0029] The in-vehicle software is subjected to simulation testing, and the in-vehicle software to be released is formed after the simulation test is passed.

[0030] The product design rules include the following:

[0031] Rule 1: Each scenario, service, and interaction involved in an in-vehicle software product is considered as one object;

[0032] Rule 2: Every in-vehicle software product must have a start and an end object;

[0033] Rule 3: The number of layers in each in-vehicle software product cannot exceed 5. The number of layers is calculated based on the input point of the longest chain in the product.

[0034] Rule 4: Each in-vehicle software product must have at least one service target;

[0035] Rule 5: There cannot be isolated objects in in-vehicle software products; that is, the input points of all objects cannot be empty.

[0036] The object triggering rules include the following rules:

[0037] Rule 1: Each object has an input port, which executes its internal logic after receiving a message from the previous node; each object also has an output port, which sends a message to the next connected object if the output is triggered.

[0038] Rule 2: Each scene object has only one output port. When the scene engine detects that the scene state signal condition is met, it sends a message to the next node.

[0039] Rule 3: Each interactive object has a default output port, which means that if the user does not respond within a specified time, the output port will be automatically triggered to send a message to the next node;

[0040] Rule 4: For each additional option added to an interactive object, an output port is added, indicating that the user's selection of that option triggers the sending of a message to the next node;

[0041] Rule 5: Each service set object has only one output port. When the last service in the service set is executed successfully, a message is sent to the next node.

[0042] The object connection rules include the following rules:

[0043] Rule 1: Connections between objects have a timing property;

[0044] Rule 2: An output port pointing to at least one input port indicates that an upstream node sends a message to at least one downstream node;

[0045] Rule 3: Connect any type of object after each object;

[0046] Rule 4: An input port receives messages from at least one output port, meaning that the object is triggered whenever a node sends a message.

[0047] Rule 5: If an object's output port is not connected to any other object, it defaults to the end state. The output port of a scene object cannot be connected to the end state.

[0048] Accordingly, another aspect of the present invention also provides a vehicle software generation system, which includes a scene library, an interaction library, a service library suitable for various vehicle models, and a visual software generation device; wherein, the visual software generation device further includes:

[0049] The scene generation unit is used to call a preset scene library and select the desired scene template related to the vehicle software as the trigger scene; each scene template consists of at least one meta-scene, which is an external state, vehicle state or vehicle user state signal.

[0050] The interaction generation unit is used to call a preset interaction library and select at least one set of interactions related to the desired in-vehicle software to add to the output port of the triggering scenario.

[0051] A service generation unit is used to call a preset service library and select at least one service set related to the desired in-vehicle software from it, and add it to the output port of the trigger scenario or interaction set; the service set is configured with the execution sequence relationship of at least one service and / or the duration of service execution;

[0052] The vehicle software acquisition unit is used to combine information based on scenarios, selected services, and interaction methods to form vehicle software for intelligent cockpit scenarios.

[0053] The scenarios built in the scenario library consist of at least one scenario template. Each scenario template is composed of one or more meta-scenarios. The meta-scenarios within a scenario template are combined using at least one of the logical relationships of AND, OR, or NOT, and the timing relationship can be configured.

[0054] The interaction library contains multiple interaction sets, each including at least one interaction cycle. Each interaction cycle contains an input unit and an output unit, where the input unit includes a function initiation input unit and a preference input unit; the output unit includes a preference output unit and a service content output unit; the interaction cycles within the same interaction set support configurable timing relationships.

[0055] Services built in the service library exist in the form of service sets. A service set consists of one or more meta services or atomic services. Services within a service set support configuring the service execution sequence and the duration of service execution. Atomic services correspond to the in-vehicle function services that the vehicle itself can provide, while meta services correspond to third-party ecosystem services obtained through the Internet of Vehicles.

[0056] In the interaction set:

[0057] The function initiation input unit is represented by the following formula:

[0058] {Target Function: <Input Method>, <Input Point>}

[0059] In the formula, the target function refers to the function of the in-vehicle software that needs to be guided to be realized in the interaction; the input methods include three types: physical button input, voice input, and body posture input; the input point is the button, voice command, or gesture action that carries a clear input purpose in the specific input method.

[0060] The input cell for the preferred option is represented by the following formula:

[0061]

[0062] In the formula, the service willingness is indicated by "yes" or "no", and the service options refer to the service options provided by the vehicle software. The input method is the same as the input method of the function initiation input unit.

[0063] The intention option output unit is represented by the following formula:

[0064]

[0065] In this formula, service willingness is indicated by "yes" or "no"; output method is divided into three types: visual output, auditory output, and haptic output; input method prompts indicate which method to use for selection; service options refer to the service options provided by the in-vehicle software.

[0066] The service content output unit is represented by the following formula:

[0067] {Service content: <Output method 1, component, parameter>; <Output method 2, component, parameter>...; Input method prompts}.

[0068] The visualization software generation device further includes:

[0069] The rule detection unit is used to perform a detection process of preset product design rules, object connection rules, and object triggering rules before the initial vehicle software for intelligent cockpit scenarios is formed.

[0070] This further includes:

[0071] The simulation testing unit is used to perform simulation testing on the vehicle software obtained by the vehicle software acquisition unit, and to form the vehicle software to be released after the simulation test is passed.

[0072] Accordingly, another aspect of the present invention provides a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the aforementioned method.

[0073] Implementing the embodiments of the present invention has the following beneficial effects:

[0074] This invention provides a method, system, and storage medium for generating in-vehicle software. By employing a system including a scene library, a service library, an interaction library, and a visual software generation device, software products for intelligent cockpit scene services can be set up through a scene-interaction-service ternary structure. It adopts a visual generation method, featuring low-code characteristics, and can quickly and flexibly realize the entire design process of software products, thereby effectively solving the problems of long development cycles and high costs associated with existing in-vehicle software development.

[0075] By implementing this invention, low-code product development can be achieved through scene service generation, which can significantly reduce development costs; product design can be carried out very conveniently, which can greatly improve product development efficiency; and the scope of scenes and services can be greatly expanded to achieve a very rich range of scenes and services. Attached Figure Description

[0076] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, obtaining other drawings based on these drawings without creative effort still falls within the scope of the present invention.

[0077] Figure 1 This is a schematic diagram of the ternary structure of the software involved in the present invention;

[0078] Figure 2 This is a schematic diagram of the main flow of an embodiment of a method for generating vehicle software provided by the present invention;

[0079] Figure 3 This is a schematic diagram of the scene state phase space involved in the present invention;

[0080] Figure 4 This is a schematic diagram of the scene structure in the scene library involved in the present invention;

[0081] Figure 5 This is a schematic diagram of the interaction structure in the software involved in the present invention;

[0082] Figure 6 This is a schematic diagram of the interaction structure in the interaction library involved in the present invention;

[0083] Figure 7 This is a schematic diagram of the service structure in the service library involved in the present invention;

[0084] Figure 8 This is an example schematic diagram of the software product portfolio involved in the present invention;

[0085] Figure 9 This is a schematic diagram of the interface of the visualization software generation device involved in the present invention;

[0086] Figure 10 A schematic diagram of the structure of an embodiment of an in-vehicle software generation system provided by the present invention;

[0087] Figure 11 for Figure 10 A schematic diagram of the structure of the visualization software generation device. Detailed Implementation

[0088] To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings.

[0089] First, some terms involved in this invention are explained as follows:

[0090] User Experience Software Product (UESP): This refers to automotive functionalities installed in a vehicle that can be perceived by the user and require software to implement their functions; examples include smart keys and intelligent welcome systems. A UESP software product consists of a "scenario-interaction-service" three-element structure. This structure can be used to analyze the existing features within the cockpit. In other words, the applicant believes that all configurable software products within the intelligent cockpit are built upon this three-element structure. For details, please refer to... Figure 1 As shown.

[0091] A scenario refers to a combination of various state signals of a vehicle, its users, or external conditions, as well as a set of rules formed by logical relationships between these state signals. For example, when the vehicle speed is greater than 100 km / h, the state of the vehicle at that time is considered a scenario.

[0092] Interaction: refers to the way information is transmitted and responded to by vehicles and people, consisting of interaction cycles and interaction levels, including interaction logic, interaction specifications, and interaction methods, such as TTS broadcasts, text messages, H5 pop-ups, etc.

[0093] Services: This refers to two main categories: in-vehicle function services and third-party ecosystem services. In-vehicle function services specifically refer to services that can be controlled and executed by various in-vehicle controllers (ECUs). These can be categorized by domain controller type, such as cockpit domain, intelligent driving domain, body domain, chassis domain, and powertrain domain services. This invention primarily targets cockpit domain and some body domain vehicle control services, including window control, seat control, air conditioning, and vehicle infotainment system operation. Third-party ecosystem services refer to services provided by third-party ecosystem service providers in the categories of "oil and electricity maintenance, and daily necessities," including music services, navigation services, and refueling / charging services.

[0094] like Figure 2 The diagram shown illustrates the main flow of an embodiment of a method for generating in-vehicle software provided by the present invention. (See also...) Figures 2 to 9 As shown, in this embodiment, the method for generating the in-vehicle software includes the following steps:

[0095] Step S10: Invoke a preset scene library and select a desired scene template related to the in-vehicle software as the trigger scene; each scene template consists of at least one meta-scene, which is an external state, vehicle state, or vehicle user state signal. In embodiments of the present invention, the in-vehicle software may be, for example, in-vehicle UESP software.

[0096] Understandably, the scene library is pre-generated and suitable for various vehicle models. A scene built in the scene library consists of at least one scene template, and each scene template is composed of one or more meta-scenes. Meta-scenes within a scene template are combined using at least one of the logical relationships of AND, OR, or NOT, and timing relationships can be configured. Meta-scenes are composed of signals.

[0097] More specifically, in one example, it is necessary to design software trigger scenarios based on the designer's ideas or external requirements; that is, when the X signal state condition is met, the scenario reaches the trigger state. This invention uses a scenario state phase space composed of external state, vehicle state, and vehicle user state to represent the specific state of the scenario. For example... Figure 3 As shown, scene design involves finding a subset of the scene state phase space and establishing a correspondence between this subset and the specific requirements that need to be met. The smallest granularity scene is called the meta-scene, which can be described by the following formula:

[0098] {Scene object: <set of state values>}

[0099] In the formula, the scene object refers to the external environment, vehicle or vehicle user, and its state value can be mostly detected by vehicle sensors. It is both a continuous value and a discrete value.

[0100] In simple terms, the control condition for scene triggering is that the scene is automatically triggered when the scene signal reaches the conditions set during the design phase; the control parameter for scene triggering is the scene signal state value.

[0101] like Figure 4 As shown, a scenario built in the scenario library consists of one or more scenario templates (cases). Scenario templates are related by OR. Each scenario template consists of one or more signals, and the signals within a scenario template can be configured with timing relationships.

[0102] Meanwhile, the anti-shake condition must be met when the scene is triggered. The anti-shake condition refers to the condition that the vehicle enters the scene state when the vehicle meets a certain preset state information value. For example, when the vehicle speed is greater than 100km / h and the duration is greater than 10 seconds, the vehicle is determined to be in a high-speed driving scene.

[0103] Step S11: Call the preset interaction library and select at least one interaction set related to the desired in-vehicle software to add to the output port of the trigger scene;

[0104] Understandably, the interaction library is pre-generated and suitable for various vehicle models. Multiple interaction sets are built within the library, each containing at least one interaction cycle. Each interaction cycle includes an input unit and an output unit. The input unit includes a function initiation input unit and a desired option input unit; the output unit includes a desired option output unit and a service content output unit. Interaction cycles within the same interaction set support configurable timing relationships; see reference for details. Figure 5 and Figure 6 As shown.

[0105] In the interaction set:

[0106] The function initiation input unit is represented by the following formula:

[0107] {Target Function: <Input Method>, <Input Point>}

[0108] In the formula, the target function refers to the function of the in-vehicle software that needs to be guided to be realized in the interaction; the input methods include three types: physical button input, voice input, and body posture input; the input point is the button, voice command, or gesture action that carries a clear input purpose in the specific input method.

[0109] The input cell for the preferred option is represented by the following formula:

[0110]

[0111] In the formula, the service willingness is indicated by "yes" or "no", and the service options refer to the service options provided by the vehicle software. The input method is the same as the input method of the function initiation input unit.

[0112] The intention option output unit is represented by the following formula:

[0113]

[0114] In this formula, service willingness is indicated by "yes" or "no"; output method is divided into three types: visual output, auditory output, and haptic output; input method prompts indicate which method to use for selection; service options refer to the service options provided by the in-vehicle software.

[0115] The service content output unit is represented by the following formula:

[0116] {Service content: <Output method 1, component, parameter>; <Output method 2, component, parameter>...; Input method prompt}.

[0117] In simple terms, when a scene is triggered, the scene signal state value is output as an input message to the input port of the interactive object, and the control condition for the interaction execution is the scene signal state value when the scene is triggered; each different interaction option provides input messages for the next node service or the next layer of interaction.

[0118] For example, in one scenario, we could first provide the meta-interaction of "voice broadcast," and after obtaining user feedback, use the meta-interaction of "page pop-up" to obtain a second level of user feedback.

[0119] Step S12: Call the preset service library and select at least one service set related to the desired vehicle software, and add it to the output port of the trigger scene or interaction set; the service set is configured with the execution sequence relationship of at least one service and / or the duration of service execution;

[0120] Understandably, the service library is pre-generated and suitable for various vehicle models. Services built in the service library exist in the form of service sets, which consist of one or more meta-services or atomic services. Services within a service set support configuring the service execution sequence and the duration of service execution. Atomic services correspond to the in-vehicle function services that the vehicle itself can provide, while meta-services correspond to third-party ecosystem services obtained through the Internet of Vehicles.

[0121] More specifically, after the scenario of the software product is determined, the services of the in-vehicle software are designed according to the specific scenario and user information. The services mainly include two categories.

[0122] Firstly, vehicle control services

[0123] Vehicle control services refer to the in-vehicle functional services that the vehicle itself can provide, including control functions in the body domain, some control functions in the cockpit domain, and some control function services in the powertrain, chassis, and intelligent driving domains that may be involved in the future. This invention refers to the smallest granularity vehicle control functional service as an atomic service, described by the following formula:

[0124] {Atomic Service: <Service Source>, <Physical Quantity Type>, <Set of State Values>}

[0125] In the formula, the service source refers to the controlled object of the atomic service, such as car windows, car doors, windshield wipers, etc., the physical quantity type refers to the physical quantity representing the atomic service, such as air conditioning temperature expressed in degrees Celsius, and the state value is both a continuous value and a discrete value.

[0126] Secondly, third-party ecosystem services

[0127] Third-party services refer to the capabilities that vehicles acquire through the Internet of Vehicles (IoV). These capabilities are primarily information services, including traditional provider / supplier (CP / SP) services, as well as information services provided by traffic infrastructure and other traffic participants in the V2X era. These information services mainly consist of text, images, audio, and video.

[0128] This invention refers to the smallest granularity of third-party ecosystem services as meta-services, which are described by the following formula:

[0129] {Metaservice: <Service Source>, <Service Type>, <Service Format>, <Service Content>}

[0130] In the formula, "service source" refers to the service provider of the meta-service; "service type" refers to the type of meta-service provided; "service format" refers to the format in which the meta-service is provided, such as text, H5, voice, etc.; and "service content" refers to the actual content of the meta-service.

[0131] It is understandable that, in this embodiment, the control conditions for the service object are mainly of two types:

[0132] (a) Products without interactive objects

[0133] The service is executed when the scene is triggered, the scene signal state value is directly output to the input port of the service object as an input message, and the control parameter is the scene signal state value.

[0134] (ii) Products with interactive objects

[0135] The condition for service execution is that the interaction option acts as the upstream node of the service object, and the interaction option outputs control parameters to the associated service object. The control condition is the interaction option parameter information.

[0136] like Figure 7 As shown, services built in the service library exist in the form of service sets. A service set consists of one or more meta-services or atomic services. Services within a service set support configuring the execution sequence and duration of service execution. For example, in one example, the meta-services "turn on the air conditioner" and "close the car window" are combined together. The meta-service "turn on the air conditioner" is implemented first, followed immediately by the meta-service "close the car window".

[0137] Step S13: After combining the scenario, selected services, and interaction methods, an in-vehicle software for the intelligent cockpit scenario is formed. The in-vehicle software is then subjected to simulation testing, and a test report is automatically generated to detect the feasibility of the product logic, scenario state signal links, and service links. After the simulation test is passed, the in-vehicle software to be released is formed.

[0138] The design of intelligent cockpit scenario service products can be tailored to different scenarios, selecting different services and interaction methods, resulting in various product forms. Starting with the initial object, following the design logic from steps S10 to S12 above, a controllable editing method is used. Clicking the button at the output port allows the system to automatically list objects that are allowed to be connected according to the rules. Based on design requirements, select and add connected objects; for example, after a scenario object, you can choose to add interaction or service objects. Figure 8 The diagram illustrates an example of a software product portfolio related to the present invention.

[0139] It is understandable that in step S13, before forming the initial in-vehicle software for the intelligent cockpit scenario, there is a further step of detecting preset product design rules, object connection rules and object triggering rules.

[0140] In a specific example, the product design rules include the following rules:

[0141] Rule 1: Each scenario, service, and interaction involved in an in-vehicle software product is considered as one object;

[0142] Rule 2: Every in-vehicle software product must have a start and an end object;

[0143] Rule 3: The number of layers in each in-vehicle software product cannot exceed the predetermined number of layers. The number of layers is calculated based on the input point of the longest chain in the product.

[0144] Rule 4: Each in-vehicle software product must have at least one service target;

[0145] Rule 5: There cannot be isolated objects in in-vehicle software products; that is, the input points of all objects cannot be empty.

[0146] The object triggering rules include the following rules:

[0147] Rule 1: Each object has an input port, which executes its internal logic after receiving a message from the previous node; each object also has an output port, which sends a message to the next connected object if the output is triggered.

[0148] Rule 2: Each scene object has only one output port. When the scene engine detects that the scene state signal condition is met, it sends a message to the next node.

[0149] Rule 3: Each interactive object has a default output port, which means that if the user does not respond within a specified time, the output port will be automatically triggered to send a message to the next node;

[0150] Rule 4: For each additional option added to an interactive object, an output port is added, indicating that the user's selection of that option triggers the sending of a message to the next node;

[0151] Rule 5: Each service set object has only one output port. When the last service in the service set is executed successfully, a message is sent to the next node.

[0152] The object connection rules include the following rules:

[0153] Rule 1: Connections between objects have a timing property;

[0154] Rule 2: An output port pointing to at least one input port indicates that an upstream node sends a message to at least one downstream node;

[0155] Rule 3: Connect any type of object after each object; for example: scene connects to scene, indicating a scene judgment with logic, suitable for branch judgment of scene; interaction connects to scene, indicating that after the interaction is executed and feedback is received, the monitoring process of entering the next scene is initiated; service connects to scene, indicating that after the service is executed, the monitoring process of entering the next scene is initiated.

[0156] Rule 4: An input port receives messages from at least one output port, meaning that the object is triggered whenever a node sends a message.

[0157] Rule 5: If an object's output port is not connected to any other object, it defaults to the end state. The output port of a scene object cannot be connected to the end state.

[0158] It is understandable that the above steps are all implemented within a pre-defined visualization software generation device. This device is used to call upon the scene library, interaction library, and service library, perform visualization combination processing, and provide simulation startup functionality. Figure 9 A schematic diagram of the interface of the visualization software generation device involved in this invention is shown. It can be seen that in a software product named "Car Owner Smoking Reminder to Open Window," the triggering scenario includes three conditions: the vehicle is in P gear, the DMS detects smoking, and the air quality inside the vehicle is poor. The interaction method uses a pop-up window, with corresponding buttons A and B, which respectively correspond to the text "Open Window" and "Turn on Air Conditioning Recirculation." The default behavior is to exit the program if the user does not operate within 10 seconds. The corresponding service combination A sets the driver's side window to open 50%, and service combination B sets the air conditioning to recirculation mode.

[0159] Understandably, in more specific examples, the in-vehicle software to be released needs to be documented in a certain form. Generally, this can include the following: Protocol definition: The product solution includes associated interfaces, instructions, and processing logic. These interfaces, instructions, and logic need to be provided to the vehicle-side intelligent scenario in a recognizable form. Therefore, the product generation system and the vehicle-side intelligent scenario operation system need to agree on a protocol that allows for the recognition of product documents. Content mapping: The product solution needs to map the interfaces, instructions, and logic information in the product solution into scripts, configuration files, and parameters according to the protocol; the final document generation: the scripts, configuration files, and parameter content constitute the product document. After completing the protocol definition and content mapping, the product document can be generated.

[0160] The core of the simulation testing system consists of three parts: 1. Test case construction; 2. Single-product testing; 3. Multi-product regression testing. The testing system verifies product feasibility, design effectiveness, and safety. The specific implementation method is as follows:

[0161] S1: Simulated Operating Environment Construction. A simulated operating environment is constructed to simulate the product's operating conditions on the vehicle side, thereby completing product function testing while avoiding the need to install it on the actual vehicles used by users and affecting normal vehicle use.

[0162] S2: Test Case Library Construction. This involves creating and managing all test cases and scenarios required for the testing system.

[0163] S3: Test Task Construction. This step involves creating test tasks and defining their content and standards.

[0164] S4: Test Task Execution. First, define the test process, such as executing single-product testing first, and then executing multi-product regression testing after the single-product test passes. The specific implementation method is as follows:

[0165] S4.1: Single Product Testing. Only one product is released for testing, ensuring that only one product is running on both the vehicle and cloud platforms at the same time, in order to test whether the single product functions properly and whether its operation is hindered.

[0166] S4.2: Multi-product regression testing. Release multiple products and run them simultaneously within the same timeframe to simulate real-world application scenarios and test for potential conflicts between products.

[0167] S5: Test Feedback. After testing is complete, feedback is provided to the product development system. If the test fails, product design changes are required; if the test passes, the product can be released.

[0168] In a more detailed embodiment, the following may also be included: submitting products that pass simulation testing for review, including feasibility review, security review, quality stability review, product regression testing review, and operational environment compliance review; products that pass the review will enter the pre-release state.

[0169] like Figure 10 The diagram shown illustrates a structural schematic of an embodiment of an in-vehicle software generation system provided by the present invention. (In conjunction with...) Figure 11 As shown, in this embodiment, the system includes: a scenario library 2 suitable for various vehicle models, an interaction library 3, a service library 4, and a visual software generation device 1; wherein, the visual software generation device 1 is mainly used to provide a low-code, visual, and easy-to-use product development environment, supporting product designers to carry out agile and flexible product design work based on business needs.

[0170] The visualization software generation device 1 further includes:

[0171] The scene generation unit 10 is used to call a preset scene library and select a scene template related to the desired vehicle software as a trigger scene; each scene template consists of at least one meta scene, which is an external state, vehicle state or vehicle user state signal.

[0172] The interaction generation unit 11 is used to call a preset interaction library and select at least one interaction set related to the desired in-vehicle software to add to the output port of the triggering scenario.

[0173] The service generation unit 12 is used to call a preset service library and select at least one service set related to the desired vehicle software from it, and add it to the output port of the trigger scene or interaction set; the service set is configured with the execution sequence relationship of at least one service and / or the duration of service execution;

[0174] The vehicle software acquisition unit 13 is used to form vehicle software for intelligent cockpit scenarios after combining and processing based on scenarios, selected services and interaction methods.

[0175] The simulation test unit 14 performs simulation tests on the vehicle software obtained by the vehicle software acquisition unit 13, and forms the vehicle software to be released after the simulation test is passed.

[0176] The rule detection unit 15 is used to perform a detection process of preset product design rules, object connection rules and object triggering rules before forming in-vehicle software for intelligent cockpit scenarios.

[0177] In a specific example, a scene built in the scene library consists of at least one scene template. Each scene template is composed of one or more meta-scenes. The meta-scenes within a scene template are combined using at least one of the logical relationships of AND, OR, or NOT, and timing relationships can be configured. In short, the scene library is mainly used to combine scene signals and set logical rules to form scene templates, and to provide these templates for the product design management system to use.

[0178] The interaction library contains multiple interaction sets, each including at least one interaction cycle. Each interaction cycle contains an input unit and an output unit, where the input unit includes a function initiation input unit and a preference option input unit; the output unit includes a preference option output unit and a service content output unit; the interaction cycles within the same interaction set support configurable timing relationships; simply put, the interaction library is mainly used to implement the combination of interaction methods and the setting of logical rules to form interaction templates, and to provide interaction templates for the product design management system to call.

[0179] Services built in the service library exist in the form of service sets. A service set consists of one or more meta services or atomic services. Services within a service set support configuring the service execution sequence and the duration of service execution. Atomic services correspond to the in-vehicle function services that the vehicle itself can provide, while meta services correspond to third-party ecosystem services obtained through the Internet of Vehicles.

[0180] In a specific example, within the interaction set:

[0181] The function initiation input unit is represented by the following formula:

[0182] {Target Function: <Input Method>, <Input Point>}

[0183] In the formula, the target function refers to the function of the in-vehicle software that needs to be guided to be realized in the interaction; the input methods include three types: physical button input, voice input, and body posture input; the input point is the button, voice command, or gesture action that carries a clear input purpose in the specific input method.

[0184] The input cell for the preferred option is represented by the following formula:

[0185]

[0186] In the formula, the service willingness is indicated by "yes" or "no", and the service options refer to the service options provided by the vehicle software. The input method is the same as the input method of the function initiation input unit.

[0187] The intention option output unit is represented by the following formula:

[0188]

[0189] In this formula, service willingness is indicated by "yes" or "no"; output method is divided into three types: visual output, auditory output, and haptic output; input method prompts indicate which method to use for selection; service options refer to the service options provided by the in-vehicle software.

[0190] The service content output unit is represented by the following formula:

[0191] {Service content: <Output method 1, component, parameter>; <Output method 2, component, parameter>...; Input method prompts}.

[0192] In simple terms, the service library is mainly used to combine in-vehicle function services and third-party services and set logical rules to form a service set, and to provide a single service and service set to be called by the product design and management system.

[0193] In a specific example, the product design rules include the following rules:

[0194] Rule 1: Each scenario, service, and interaction involved in an in-vehicle software product is considered as one object;

[0195] Rule 2: Every in-vehicle software product must have a start and an end object;

[0196] Rule 3: The number of layers in each in-vehicle software product cannot exceed the predetermined number of layers. The number of layers is calculated based on the input point of the longest chain in the product.

[0197] Rule 4: Each in-vehicle software product must have at least one service target;

[0198] Rule 5: There cannot be isolated objects in in-vehicle software products; that is, the input points of all objects cannot be empty.

[0199] The object triggering rules include the following rules:

[0200] Rule 1: Each object has an input port, which executes its internal logic after receiving a message from the previous node; each object also has an output port, which sends a message to the next connected object if the output is triggered.

[0201] Rule 2: Each scene object has only one output port. When the scene engine detects that the scene state signal condition is met, it sends a message to the next node.

[0202] Rule 3: Each interactive object has a default output port, which means that if the user does not respond within a specified time, the output port will be automatically triggered to send a message to the next node;

[0203] Rule 4: For each additional option added to an interactive object, an output port is added, indicating that the user's selection of that option triggers the sending of a message to the next node;

[0204] Rule 5: Each service set object has only one output port. When the last service in the service set is executed successfully, a message is sent to the next node.

[0205] The object connection rules include the following rules:

[0206] Rule 1: Connections between objects have a timing property;

[0207] Rule 2: An output port pointing to at least one input port indicates that an upstream node sends a message to at least one downstream node;

[0208] Rule 3: Connect any type of object after each object;

[0209] Rule 4: An input port receives messages from at least one output port, meaning that the object is triggered whenever a node sends a message.

[0210] Rule 5: If an object's output port is not connected to any other object, it defaults to the end state. The output port of a scene object cannot be connected to the end state.

[0211] For more details, please refer to the above. Figures 2 to 9 The description of the method for generating in-vehicle software will not be elaborated here.

[0212] This application provides a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the methods provided in this application.

[0213] Optionally, in some embodiments, the memory may include a program storage area and a data storage area, wherein the program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the terminal or server, etc. Furthermore, the memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the terminal or server via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0214] Implementing the embodiments of the present invention has the following beneficial effects:

[0215] This invention provides a method, system, and storage medium for generating in-vehicle software. By employing a system including a scene library, a service library, an interaction library, and a visual software generation device, software products for intelligent cockpit scene services can be set up through a scene-interaction-service ternary structure. It adopts a visual generation method, featuring low-code characteristics, and can quickly and flexibly realize the entire design process of software products, thereby effectively solving the problems of long development cycles and high costs associated with existing in-vehicle software development.

[0216] By implementing this invention, low-code product development can be achieved through scenario service combination processing, which can significantly reduce development costs; product design can be carried out very conveniently, which can greatly improve product development efficiency; and the scope of scenarios and services can be greatly expanded to achieve a very rich range of scenarios and services.

[0217] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0218] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0219] The above description is merely a preferred embodiment of the present invention and should not be construed as limiting the scope of the invention. Therefore, any equivalent variations made in accordance with the claims of the present invention are still within the scope of the present invention.

Claims

1. A method for generating in-vehicle software, characterized in that, Includes the following steps: Step S10: Call the preset scene library and select at least one scene template as the trigger scene; each scene template consists of at least one meta scene, which is an external state, vehicle state or vehicle user state signal; Step S11: Call the preset interaction library and select at least one interaction set from it to add to the output port of the trigger scene; Step S12: Call the preset service library and select at least one service set from it, and add it to the output port of the trigger scene or interaction set; the service set is configured with the execution sequence relationship of at least one service and / or the duration of service execution; Step S13: After combining the selected services and interaction methods according to the scenario, the in-vehicle software for the intelligent cockpit scenario is formed. The method further includes: Pre-generate scene libraries, interaction libraries, service libraries, and visualization software generation devices suitable for various vehicle models; among which: A scene built in the scene library consists of at least one scene template. Each scene template is composed of one or more meta-scenes. The meta-scenes within a scene template are combined using at least one of the logical relationships of AND, OR, or NOT, and the timing relationship can be configured. The interaction library contains multiple interaction sets, each including at least one interaction cycle. Each interaction cycle contains an input unit and an output unit, where the input unit includes a function initiation input unit and a preference input unit; the output unit includes a preference output unit and a service content output unit; the interaction cycles within the same interaction set support configurable timing relationships. Services built in the service library exist in the form of service sets. A service set consists of one or more meta services or atomic services. Services within a service set support configuring the service execution sequence and the duration of service execution. Atomic services correspond to the in-vehicle function services that the vehicle itself can provide, while meta services correspond to third-party ecosystem services obtained through the Internet of Vehicles. The visualization software generation device is used to call the scene library, interaction library, and service library, and perform visualization combination processing, while also providing a simulation startup function.

2. The method as described in claim 1, characterized in that, In the interaction set: The function initiation input unit is represented by the following formula: In the formula, the target function refers to the function of the in-vehicle software that needs to be guided to be realized in the interaction; the input methods include three types: physical button input, voice input, and body posture input; the input point is the button, voice command, or gesture action that carries a clear input purpose in the specific input method. The input cell for the preferred option is represented by the following formula: In the formula, the service willingness is indicated by "yes" or "no", and the service options refer to the service options provided by the vehicle software. The input method is the same as the input method of the function initiation input unit. The intention option output unit is represented by the following formula: In this formula, service willingness is indicated by "yes" or "no"; output method is divided into three types: visual output, auditory output, and haptic output; input method prompts indicate which method to use for selection; service options refer to the service options provided by the in-vehicle software. The service content output unit is represented by the following formula: 。 3. The method according to any one of claims 1 to 2, characterized in that, In step S13, before forming the initial in-vehicle software for the intelligent cockpit scenario, a further step is included to perform a detection step of preset product design rules, object connection rules and object triggering rules.

4. The method as described in claim 3, characterized in that, Step S13 further includes: The in-vehicle software is subjected to simulation testing, and the in-vehicle software to be released is formed after the simulation test is passed.

5. A system for generating in-vehicle software, characterized in that, include: A scene library, interaction library, and service library suitable for various vehicle models, as well as a visualization software generation device; wherein, the visualization software generation device further includes: The scene generation unit is used to call a preset scene library and select at least one scene template as the trigger scene; each scene template consists of at least one meta-scene, which is an external state, vehicle state or vehicle user state signal. The interaction generation unit is used to call a preset interaction library and select at least one interaction set from it to add to the output port of the trigger scene; A service generation unit is used to call a preset service library and select at least one service set from it, adding it to the output port of a trigger scenario or interaction set; the service set is configured with the execution sequence relationship of at least one service and / or the duration of service execution; The vehicle software acquisition unit is used to combine information based on scenarios, selected services, and interaction methods to form vehicle software for intelligent cockpit scenarios. The scenarios built in the scenario library consist of at least one scenario template. Each scenario template is composed of one or more meta-scenarios. The meta-scenarios within a scenario template are combined using at least one of the logical relationships of AND, OR, or NOT, and the timing relationship can be configured. The interaction library contains multiple interaction sets, each including at least one interaction cycle. Each interaction cycle contains an input unit and an output unit, where the input unit includes a function initiation input unit and a preference input unit; the output unit includes a preference output unit and a service content output unit; the interaction cycles within the same interaction set support configurable timing relationships. Services built in the service library exist in the form of service sets. A service set consists of one or more meta services or atomic services. Services within a service set support configuring the service execution sequence and the duration of service execution. Atomic services correspond to the in-vehicle function services that the vehicle itself can provide, while meta services correspond to third-party ecosystem services obtained through the Internet of Vehicles.

6. The system as described in claim 5, characterized in that, In the interaction set: The function initiation input unit is represented by the following formula: In the formula, the target function refers to the function of the in-vehicle software that needs to be guided to be realized in the interaction; the input methods include three types: physical button input, voice input, and body posture input; the input point is the button, voice command, or gesture action that carries a clear input purpose in the specific input method. The input cell for the preferred option is represented by the following formula: In the formula, the service willingness is indicated by "yes" or "no", and the service options refer to the service options provided by the vehicle software. The input method is the same as the input method of the function initiation input unit. The intention option output unit is represented by the following formula: In this formula, service willingness is indicated by "yes" or "no"; output method is divided into three types: visual output, auditory output, and haptic output; input method prompts indicate which method to use for selection; service options refer to the service options provided by the in-vehicle software. The service content output unit is represented by the following formula: 。 7. The system according to any one of claims 5 to 6, characterized in that, The visualization software generation device further includes: The rule detection unit is used to perform a detection process of preset product design rules, object connection rules, and object triggering rules before the initial vehicle software for intelligent cockpit scenarios is formed.

8. The system as described in claim 7, characterized in that, Further includes: The simulation testing unit is used to perform simulation testing on the vehicle software obtained by the vehicle software acquisition unit, and to form the vehicle software to be released after the simulation test is passed.

9. A computer-readable storage medium storing computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the method as described in any one of claims 1 to 4.

Images