Vehicle-mounted software function implementation method, vehicle-mounted container engine, medium and equipment

Abstract

The invention relates to a vehicle-mounted software function implementation method, a vehicle-mounted container engine, a medium and equipment, and the method comprises the steps: generating a product script file for each vehicle-mounted software function based on a V-DSL language, and loading and operating the product script files through the vehicle-mounted container engine, the product script file comprises a plurality of node objects including a plurality of decision scene node objects and a plurality of service set node objects; the decision-making scene node object comprises decision-making scene description information written based on a vehicle domain specific language; the service set node object comprises SOA service description information written based on a vehicle domain specific language; the node object link relationship comprises a link relationship among the plurality of node objects written based on a specific language in the vehicle field; by running the product script file, the corresponding SOA service can be called in a specific scene. According to the invention, the development efficiency of the vehicle-mounted software function can be improved, and the development cost can be reduced.

Description

Technical Field

[0001] This application relates to the technical field of software development, and particularly to a method for implementing in-vehicle software functions, an in-vehicle container engine, a medium, and a device. Background Art

[0002] Currently, the development of in-vehicle software functions is mainly based on the MCU software development of AUTOSAR CP and the MPU software development of AUTOSAR AP. In-vehicle software developers perform specific coding of the specific software function business logic based on the existing platform through hard coding in programming languages (C / C++). The quality of in-vehicle software functions is greatly affected by the different capabilities of software developers, with a long development time and high development difficulty. Moreover, when an in-vehicle software function needs to be adapted to different vehicle models, even if the product function business logic is exactly the same, the original code cannot be directly reused. Generally, developers need to make adaptive modifications after fully understanding the product requirement documents, so the additional maintenance, development costs, and time costs are all very high. Summary of the Invention

[0003] The purpose of this application is to propose a method for implementing in-vehicle software functions, a container engine, a computer-readable storage medium, and an electronic device to improve the development efficiency of in-vehicle software functions and reduce the development costs.

[0004] To achieve the above purpose, an embodiment of this application provides a method for implementing in-vehicle software functions, and the method includes:

[0005] Load a product script file and run the product script file to implement the corresponding in-vehicle software function; one product script file corresponds to one in-vehicle software function;

[0006] Among them, running the product script file specifically includes:

[0007] Parse the product script file to obtain a plurality of node objects and the link relationships between the node objects; among them, the plurality of node objects include several decision scenario node objects and several service set node objects; the decision scenario node objects include decision scenario description information written in a vehicle domain-specific language; the service set node objects include SOA service description information written in a vehicle domain-specific language; the link relationships between the node objects include the link relationships between the plurality of node objects written in a vehicle domain-specific language;

[0008] Obtain vehicle perception signals, and determine whether the current vehicle scenario matches any of the decision scenarios described by the scenario node objects according to the vehicle perception signals. If there is a match, determine the service set node objects linked to the decision scenario node object according to the node object link relationship, and call the SOA services corresponding to the service set node objects. In the existing vehicle software function development mode, it is necessary to write C / C++ code for functions, and the development threshold is relatively high, and the development cycle is long. In view of this, the method of the embodiment of the present application summarizes and generalizes vehicle software functions according to the dimensional structure of "perception → decision → execution", so as to extract the key decision scenario node objects, service set node objects for describing the business and the node object link relationships between them. And the decision scenario node objects, service set node objects and the node object link relationships between them are written in a vehicle domain-specific language (V-DSL). V-DSL is a domain-specific language dedicated to the vehicle domain. Based on V-DSL, the implementation details of vehicle software can be abstracted, and the function definition and logic implementation of vehicle software are described in a highly structured manner. Compared with writing C / C++ language, the difficulty of writing the product script file of V-DSL is greatly reduced, and it models the product structure and business logic in a highly structured manner. Therefore, the product script file of V-DSL is easier to generate automatically. Therefore, the development threshold is reduced and the development efficiency is improved.

[0009] The embodiment of the present application also provides a method for implementing vehicle software functions, and the method includes:

[0010] Load the product script file and run the product script file to implement the corresponding vehicle software function; one product script file corresponds to implementing one vehicle software function;

[0011] Among them, the running of the product script file specifically includes:

[0012] Parse the product script file to obtain multiple node objects and node object link relationships; among them, the multiple node objects include several decision scenario node objects, several interaction node objects and several service set node objects; the decision scenario node objects include scenario description information written in a vehicle domain-specific language; the interaction node objects include description information for asking the user whether to call a service written in a vehicle domain-specific language; the service set node objects include SOA service description information written in a vehicle domain-specific language; the node object link relationships include the link relationships between the multiple node objects written in a vehicle domain-specific language;

[0013] Obtain vehicle perception signals, and determine whether the current vehicle scenario matches the scenario described by any decision scenario node object according to the vehicle perception signals. If it matches, determine the interaction node object linked to the any decision scenario node object according to the node object link relationship, interact with the user based on the interaction node object to solicit whether the user calls a service. If so, determine the service set node object linked to the interaction node object according to the node object link relationship, and call the SOA service corresponding to the service set node object.

[0014] In the existing vehicle software function development mode, it is necessary to write C / C++ code for functions, and the development threshold is relatively high and the development cycle is long. In view of this, the method of the embodiment of the present application summarizes and generalizes vehicle software functions according to the dimensional structure of "perception → decision → execution", so as to extract key decision scenario node objects, interaction node objects, service set node objects for describing services and the node object link relationships between them. And the decision scenario node objects, interaction node objects, service set node objects and the node object link relationships between them are written in a vehicle domain specific language (V-DSL). V-DSL is a domain specific language dedicated to the vehicle domain. Based on V-DSL, the implementation details of vehicle software can be abstracted, and the function definition and logic implementation of vehicle software are described in a highly structured manner. Compared with writing C / C++ language, the difficulty of writing the product script file of V-DSL is greatly reduced, and it models the product structure and business logic in a highly structured manner. Therefore, the product script file of V-DSL is easier to generate automatically. Therefore, the development threshold is reduced and the development efficiency is improved.

[0015] The embodiment of the present application further provides a vehicle container engine, including a module for executing the vehicle software function implementation method as described above.

[0016] For example, when multiple in-vehicle software functions need to be implemented on vehicle model A, a product script file can be written for each in-vehicle software function based on V-DSL, and the product script file can be loaded and run through an in-vehicle container engine. The product script file includes multiple node objects and node object link relationships. By running the product script file, the corresponding SOA service can be called in a specific scenario to implement the corresponding in-vehicle function; the in-vehicle container engine, as the container for running the product script file, isolates the vehicle's underlying layer. Therefore, when the same in-vehicle software functions need to be implemented on vehicle model B, only the in-vehicle container engine needs to be adapted on vehicle model B. After the in-vehicle container engine is transplanted once, the in-vehicle container engine can provide a unified operating environment and interface, and all in-vehicle software functions can automatically complete adaptation. The in-vehicle container engine on vehicle model B can still run the above-mentioned product script file written based on V-DSL, thus realizing the transformation from the previous transplantation at the single product function level to the transplantation of the in-vehicle container engine, greatly improving the development efficiency of in-vehicle software functions and reducing the development cost.

[0017] The embodiment of the present application also provides a computer-readable storage medium storing a computer program, which when executed by a processor, implements the method for implementing in-vehicle software functions as described above.

[0018] The embodiment of the present application also provides an electronic device, including a processor, a memory, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, it implements the method for implementing in-vehicle software functions as described above.

[0019] Other features and advantages of the embodiments of the present application will be described in the subsequent specification. Description of the Drawings

[0020] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required in the description of the embodiments or the prior art. Obviously, the following drawings are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0021] Figure 1 It is a flowchart of running a product script file in an embodiment of the present application.

[0022] Figure 2 It is a flowchart of running a product script file in another embodiment of the present application.

[0023] Figure 3 It is a flowchart for extracting in-vehicle software function business entities in an embodiment of the present application.

[0024] Figure 4 This is a schematic structural diagram of a product script file in an embodiment of the present application.

[0025] Figure 5 This is a schematic diagram of the file organization method of a vehicle-mounted container engine in an embodiment of the present application.

[0026] Figure 6 This is a flowchart of a vehicle-mounted container engine executing a product script file in an embodiment of the present application. Detailed description of the specific implementation

[0027] The detailed description of the accompanying drawings is intended to be an illustration of the currently preferred embodiment of the present application, rather than representing the only form in which the present application can be implemented. It should be understood that the same or equivalent functions can be completed by different embodiments intended to be included within the spirit and scope of the present application.

[0028] Embodiment 1 of the present application provides a method for implementing vehicle-mounted software functions. The method includes: loading a product script file and running the product script file to implement the corresponding vehicle-mounted software function; one product script file corresponds to implementing one vehicle-mounted software function.

[0029] Among them, in Embodiment 1, running the product script file specifically includes the following steps:

[0030] Step S11, parsing the product script file to obtain a plurality of node objects and node object link relationships; among them, the plurality of node objects include a plurality of decision scenario node objects and a plurality of service set node objects; the decision scenario node objects include decision scenario description information written based on a vehicle domain-specific language; the service set node objects include SOA service description information written based on a vehicle domain-specific language; the node object link relationships include the link relationships between the plurality of node objects written based on a vehicle domain-specific language.

[0031] Specifically, in this embodiment, the vehicle-mounted software functions are summarized and inducted according to the dimensional structure of "perception → decision → execution", so as to extract key multiple node objects and node object link relationships for describing the business. For example, for a simple intelligent scenario service product "rainstorm mode", "rainstorm mode" means automatically turning on the windshield wipers and warning lights when it is raining heavily. In this embodiment, "rainstorm mode" can be disassembled into a decision scenario node object of "judging whether it is raining heavily during driving", and a service set node object including multiple service actions such as "turning on the windshield wipers" and "turning on the warning lights".

[0032] In this embodiment, V-DSL describes nodes through objects. Objects can be nested, that is, an object can contain another object. V-DSL describes the specific content in an object through attributes. An object can have multiple attributes, and the business data of a specific node is stored in the value of the attribute. V-DSL can organize and save the values of a certain type of object or attribute through an array. Among them, V-DSL supports multiple basic data types, including but not limited to: String (string), Number (numeric value), Int (integer), Range (range), Boolean (boolean value), Array (array), Enum (enumeration), Object (object), etc.

[0033] Step S12: Obtain vehicle perception signals, and determine whether the current vehicle scenario matches any decision scenario described by a decision scenario node object according to the vehicle perception signals. If there is a match, determine the service set node object linked to the decision scenario node object according to the node object link relationship, and call the SOA service corresponding to the service set node object.

[0034] Specifically, continuing with the "heavy rain mode" as an example, a vehicle can be equipped with a rain sensor to sense the current rainfall situation. The rain sensor can measure the intensity and magnitude of the rainfall. Therefore, the vehicle perception signal in step S2 can be the rainfall signal detected by the rain sensor. In addition, it can also be the vehicle perception signal obtained by recognizing the image of the vehicle's surrounding environment captured by the on-vehicle camera. Further, it can also combine the meteorological data provided by a third-party platform to obtain the vehicle perception signal, so as to determine whether the current vehicle scenario is a decision scenario of heavy rain according to the vehicle perception signal. If it is a decision scenario of heavy rain, call the corresponding SOA service and execute multiple service actions such as "turn on the windshield wiper" and "turn on the warning light".

[0035] It should be noted that in the existing in-vehicle software function development mode, it is necessary to write C / C++ code for functions, with a relatively high development threshold and a long development cycle. In response to this, the method of this embodiment summarizes and classifies in-vehicle software functions according to the dimensional structure of "perception → decision-making → execution", so as to extract key decision scenario node objects, service set node objects for describing the business, and the node object link relationships between them. And the decision scenario node objects, service set node objects, and the node object link relationships between them are written in the vehicle domain specific language (V-DSL). V-DSL is a code structure for describing in-vehicle software functions; based on V-DSL, the implementation details of in-vehicle software can be abstracted, and the function definition and logical implementation of in-vehicle software are described in a highly structured manner; by using V-DSL, developers can write vehicle software code more quickly, reduce the generation of errors and redundant code, and improve the readability and maintainability of the code, because it uses terms and concepts related to the vehicle domain, making the code more in line with the design and requirements of the vehicle system. Therefore, compared with writing in C / C++ language, the difficulty of writing the product script file of V-DSL is greatly reduced, and since it models the product structure and business logic in a highly structured manner, the product script file of V-DSL is easier to generate automatically. Therefore, the development threshold is reduced and the development efficiency is improved.

[0036] Embodiment 2 of the present application provides another method for implementing in-vehicle software functions, including: loading a product script file and running the product script file to implement the corresponding in-vehicle software function; one product script file corresponds to implementing one in-vehicle software function;

[0037] Among them, as Figure 2 shown, the running of the product script file in Embodiment 2 specifically includes the following steps:

[0038] Step S21, parsing the product script file to obtain a plurality of node objects and node object link relationships; among them, the plurality of node objects include a number of decision scenario node objects, a number of interaction node objects, and a number of service set node objects; the decision scenario node objects include scenario description information written in the vehicle domain specific language; the interaction node objects include description information for asking the user whether to call a service written in the vehicle domain specific language; the service set node objects include SOA service description information written in the vehicle domain specific language; the node object link relationships include the link relationships between the plurality of node objects written in the vehicle domain specific language;

[0039] Step S22: Obtain vehicle perception signals, and determine whether the current vehicle scenario matches the scenario described by any decision scenario node object. If there is a match, determine the interaction node object linked to the decision scenario node object according to the node object link relationship, interact with the user based on the interaction node object to ask whether the user wants to invoke a service. If so, determine the service set node object linked to the interaction node object according to the node object link relationship, and invoke the SOA service corresponding to the service set node object.

[0040] Specifically, the difference between Embodiment 2 and Embodiment 1 is that Embodiment 2 adds an interaction node object between the decision scenario node object and the service set node object. In Embodiment 1, when the current vehicle scenario matches the scenario described by any decision scenario node object, at this time, the SOA service corresponding to the service set node object is directly invoked. While in Embodiment 2, when the current vehicle scenario matches the scenario described by any decision scenario node object, the interaction node object is processed first to solicit the user's opinion. Only when the user agrees to invoke the service will the SOA service corresponding to the service set node object be invoked. Therefore, Embodiment 1 and Embodiment 2 can be applied to different scenarios respectively to meet different requirements. The principles, advantages, and other technical contents of the rest of Embodiment 2 are the same as those of Embodiment 1 and can be obtained by referring to the description of Embodiment 1, so they will not be elaborated here.

[0041] It should be noted that in the existing vehicle software function development mode, it is necessary to write C / C++ code for functions, with a relatively high development threshold and a long development cycle. In view of this, the method of the embodiment of the present application summarizes and induces vehicle software functions according to the dimensional structure of "perception → decision → execution", so as to extract key decision scenario node objects, interaction node objects, service set node objects for describing the business and the node object link relationships between them. And the decision scenario node objects, interaction node objects, service set node objects and the node object link relationships between them are written in the vehicle domain specific language (V-DSL). V-DSL is a domain specific language dedicated to the vehicle domain. Based on V-DSL, the implementation details of vehicle software can be abstracted, and the function definition and logic implementation of vehicle software are described in a highly structured manner. Compared with writing C / C++ language, the difficulty of writing the product script file of V-DSL is greatly reduced, and it models the product structure and business logic in a highly structured manner. Therefore, the product script file of V-DSL is easier to be automatically generated. Therefore, the development threshold is reduced and the development efficiency is improved.

[0042] Based on the above Embodiment 1 or 2, more specifically, the multiple node objects further include a perception scenario node object, and the perception scenario node object includes perception scenario description information written based on V-DSL.

[0043] Specifically, in this embodiment, according to different scenario functions to be realized, the scenario node object is designed to include a perception scenario node object and a decision scenario node object, which are respectively used to determine whether it is in the perception scenario and the decision scenario. The perception scenario mainly senses whether a signal exists or changes. If so, it is in the perception scenario; if not, it is not in the perception scenario. The decision scenario mainly senses whether the change of the signal reaches a certain condition. If so, it is in the decision scenario; if not, it is not in the decision scenario.

[0044] The step S2 obtains the vehicle perception signal and determines whether the current vehicle scenario matches the decision scenario described by any decision scenario node object according to the vehicle perception signal, specifically including:

[0045] Obtain the vehicle perception signal, and determine whether the current vehicle scenario matches the perception scenario described by the perception scenario node object according to the vehicle perception signal. If it matches, further determine several decision scenario node objects linked to the perception scenario node object according to the node object link relationship, and determine whether the current vehicle scenario matches the decision scenario described by any decision scenario node object according to the vehicle perception signal.

[0046] Specifically, taking the in-vehicle software function product for PM2.5 perception as an example, this product mainly realizes the following functions: when the value of PM2.5 is greater than 60, the air conditioner turns on the ion air purification; when the value of PM2.5 is less than 30, the air conditioner turns off the ion air purification.

[0047] In this product, there are a total of 5 node objects and no interaction nodes. These 5 node objects are respectively:

[0048] Node object 0, a perception scenario node object, with the function of perception, registering the SOA signal corresponding to PM2.5;

[0049] Node object 1, a decision scenario node object, with the function of decision-making, making a decision on PM2.5 being greater than 60;

[0050] Node object 2, a service node object, with the function of service call, calling the air conditioner to turn on the ion air purification function;

[0051] Node object 3, a decision scenario node object, with the function of decision-making, making a decision on PM2.5 being less than 30;

[0052] Node object 4, a service node object, with the function of service call, calling the air conditioner to turn off the ion air purification function.

[0053] In this product, there are a total of 4 link relationships, which are respectively:

[0054] Node object 0 links to node object 1;

[0055] Node object 1 links to node object 2;

[0056] Node object 0 links to node object 3;

[0057] Node object 3 links to node object 4;

[0058] Therefore, in this product, node object 0 will be processed first. If a PM2.5 sensing signal is received,

[0059] then the sensing is successful, and node object 1 and node object 3 are processed synchronously. When the value of PM2.5 is greater than 60, the decision scenario of node object 1 is satisfied, and node object 2 linked to node object 1 is found. According to node object 2, the air conditioner is called to turn on the ion air purification function; when the value of PM2.5 is less than 30, the decision scenario of node object 3 is satisfied, and node object 4 linked to node object 3 is found. According to node object 4, the air conditioner is called to turn off the ion air purification function.

[0060] Based on the above example, it can be seen that generally there is one sensing scenario node object, while there can be one or more decision scenario node objects. The service set node objects generally match the decision scenario node objects. One decision scenario node object corresponds to one service set node object, or one decision scenario node object corresponds to one interaction node object, and one interaction node object corresponds to one service set node object.

[0061] Based on the above-mentioned first or second embodiment, more specifically, both the decision scenario node object and the sensing scenario node object include several signal rules, and the signal rule is a judgment expression composed of a signal real-time value attribute, an operator attribute, and a signal target value attribute;

[0062] If the decision scenario node object or the sensing scenario node object includes one signal rule, then when the vehicle sensing signal satisfies this signal rule, the vehicle scenario matches the scenario described by the decision scenario node object or the sensing scenario node object;

[0063] If the decision scenario node object or the sensing scenario node object includes at least two signal rules, then through a logical relationship, the at least two signal rules form a signal rule set. When the vehicle sensing signal satisfies the signal rule set, the vehicle scenario matches the scenario described by the decision scenario node object or the sensing scenario node object.

[0064] Specifically, the V-DSL of this embodiment describes scenarios through scenario node objects. Specifically, it describes specific rules through signal objects. A specific rule is manifested as a judgment expression, which is composed of attributes such as signal real-time value attributes, operator attributes, and signal target value attributes. For example, the vehicle speed is greater than 50 km / h; it also describes the types of specific signals through signal group attributes, such as vehicle signals, ecological signals, etc.; it also describes the composition rules between a group of signals through signal objects and signal logic attributes, such as or, and. This scenario description method can more intuitively express vehicle scenarios and rules. Developers can describe the behaviors and characteristics of vehicle systems by defining scenario nodes and signal rules. By using different attributes and logical relationships, various scenarios and rules can be flexibly combined and defined.

[0065] Based on the above-mentioned first or second embodiment, more specifically, the service set node object includes several service objects and an interruption strategy attribute. The service object includes an execution parameter attribute and a delay time attribute. The several service objects determine the timing relationship between each other through the delay time attribute. The interruption strategy attribute includes the processing strategy during the execution process of the several service objects.

[0066] Specifically, the V-DSL of this embodiment describes the service set through service node objects, and describes a specific execution action through service objects. It is composed of attributes such as execution parameter attributes and delay time attributes. For example: execute to open the window to 50% of the position and delay by 1 second relative to the previous action; describe the types of specific execution actions through service group attributes, such as vehicle control services, ecological services, TSP services, etc.; describe the processing strategy during the execution process of the service set through the interruption strategy attribute, such as whether to exit or continue when an exception occurs; this description method can more intuitively express the service set and execution actions. Developers can describe the service set and specific execution actions of vehicle systems by defining service objects. By using different attributes and strategies, various service sets and execution actions can be flexibly combined and defined.

[0067] Based on the above-mentioned first or second embodiment, more specifically, the link relationship between any two node objects includes an input node index attribute, an output node index attribute, and a link type attribute. The input node index attribute refers to one of the two node objects, and the output node index attribute refers to the other of the two node objects. The link type attribute refers to that after the processing result of the input node index attribute meets the preset condition, it jumps to process the output node index attribute.

[0068] Specifically, each object node is connected through certain rule logics to form a complete product / function. By describing the connection relationships between the nodes, the product / function business can be completely described. The input and output nodes of the specific connection are described through the input node index attribute (sourceNodeIndex) and the output node index attribute (targetNodeIndex). The specific link rules are described through the link type attribute (connectType). Different types of output nodes have different link rules. For example, the scenario object supports link rules such as true and false; the service set object supports link rules such as success and fail.

[0069] Taking the in-vehicle software function product for PM2.5 perception as an example, in this product, there are a total of 4 node object link relationships, which are respectively:

[0070] Link 1, sourceNodeIndex = 0, targetNodeIndex = 1, connectType = success means entering node object 1 from node object 0, and the condition is successful perception;

[0071] Link 2, sourceNodeIndex = 0, targetNodeIndex = 3, connectType = success means entering node object 3 from node object 0, and the condition is successful perception;

[0072] Link 3, sourceNodeIndex = 1, targetNodeIndex = 2, connectType = True means entering node object 2 from node object 1, and the condition is that the decision is true, that is, it means that when PM2.5 is greater than 60, enter the air conditioner to turn on the ion air purification function;

[0073] Link 4, sourceNodeIndex = 3, targetNodeIndex = 4, connectType = True means entering node object 4 from node object 3, and the condition is that the decision is true, that is, it means that when PM2.5 is less than 30, enter the air conditioner to turn off the ion air purification function.

[0074] Specifically, if interaction with the user is required before turning on or turning off the ion air purification function, an interaction node object is added, and link 3 and link 4 can be modified according to the interaction node object. For example, link 3 is modified to link 31 and link 32;

[0075] Link 31, sourceNodeIndex = 1, targetNodeIndex = a, connectType = True means entering node object a (interaction node object) from node object 1, the condition is that the decision is true, that is, PM2.5 is greater than 60, and the user is asked whether to enter the air conditioner to turn on the ion air purification function;

[0076] Link 32, sourceNodeIndex=a, targetNodeIndex=2, connectType=True means entering node object 2 from node object a, the condition is that the decision is true, that is, the user confirms to enter the air conditioner to turn on the ion air purification function, and enters the air conditioner to turn on the ion air purification function;

[0077] After the modification, there are 6 node object link relationships in total.

[0078] Based on the above embodiment 1 or 2, more specifically, the method specifically includes:

[0079] When calling the SOA service corresponding to the service set node object, the SOA service corresponding to the service set node object is called according to the preset metamodel file; specifically, when running the product file, it is necessary to provide various information that the product file relies on during the operation process. This information needs to be saved in corresponding files, including the metamodel file. The metamodel file includes the registration information of the SOA service used by the product, such as input parameters, output parameters, return values, etc.

[0080] Based on the above embodiment 1 or 2, more specifically, the method specifically includes:

[0081] When calling the SOA service corresponding to the service set node object, the SOA service corresponding to the service set node object is called according to a preset personalized parameter setting file; the personalized parameter setting file includes the personalized parameters of the user.

[0082] Specifically, different users may have different setting requirements for function parameter values. For example, for the use of the air-conditioning function, some users set the optimal comfort temperature to 26°, while some users set the optimal comfort temperature to 24°. Therefore, different users can have independent personalized parameter setting files. If multiple accounts are logged in to the same car, there will be multiple personalized parameter setting files. When calling the corresponding SOA service, the corresponding personalized parameter setting file will be obtained according to the currently logged in user account.

[0083] Based on the above-mentioned embodiment 1 or 2, more specifically, as Figure 4 As shown, the product script file includes product definition information (profileDef) and product function expression information (metadata);

[0084] The product definition information includes a product unique identifier, meta-model information, initial product setting values (controlSetting), and signal names (signal) of the product. The product unique identifier includes a product ID, a product name (name), and a product version number (version). Based on the product ID, product name, and product version number, a latest version of the product can be determined for operation, and other old versions of the product are cleared to facilitate product updates. The meta-model information includes a meta-model version (metadata Modle Version) and a meta-model ID (metadata Modle Id). The meta-model version corresponds to the vehicle model, that is, different vehicle models will have different meta-model versions. The meta-model ID corresponds to all SOA service information required by the product, that is, all SOA service information stored at the corresponding address can be queried based on the meta-model ID. The initial product setting values are the default values of each parameter of the product. When each product is generated, there are default values, and these default values will be stored in the initial product setting values. The signal name is the name of the vehicle perception signal required for the execution of the product and corresponds to the signal in the meta-model file.

[0085] The product function expression information includes the multiple node objects (first Node Index and nodes) and the node object link relationships (connections).

[0086] Embodiment 3 of the present application provides an in-vehicle container engine, including a module for executing the in-vehicle software function implementation method described in the above Embodiment 1 or 2.

[0087] Specifically, the in-vehicle container engine of this embodiment is a container for product script files, in which a very large number of product script files can be stored. For the same in-vehicle software function, it can be distinguished by the version number. The user can set whether this function is enabled or disabled through the IDC or the mobile phone APP. For the same product, the user can set personalized parameters to meet their own needs. For the SOA service calls inside the product script file, complete information records must be provided for searching. Therefore, the in-vehicle container engine not only contains multiple product files, but also needs to provide various information dependencies during the operation of the product files, and these information need to be saved in the corresponding files. Therefore, referring to Figure 5 , when executing the in-vehicle software function implementation method described in the above embodiment, it is necessary to add the running file (i.e., the module for executing the in-vehicle software function implementation method described in the above embodiment), the product script file, the meta-model file, and the personalized parameter setting file to the in-vehicle container engine.

[0088] Referring to Figure 6, the vehicle-mounted container engine of this embodiment executes the product script file, which mainly includes five parts: script preprocessing, scenario node processing, interaction node processing, service node processing, and processing of the link relationship between nodes. The following is a detailed description of these five parts:

[0089] Script preprocessing mainly includes static conflict management and pre-parsing of the product script file. Static conflict management mainly prevents conflicts between different product script files, such as file name conflicts and repetitive processing of signals in different product script files. Pre-parsing is to parse the JSON format of the original product script file into the internal structure organization form of the vehicle-mounted product engine and save the intermediate format file (the product script file to be loaded) to the local hard disk of the vehicle. Each time the vehicle is powered on, the intermediate format file is reloaded from the hard disk (i.e., the product script file loaded in step S1 above), which can improve the startup speed of the vehicle-mounted product engine.

[0090] Scenario node processing mainly parses the signal definition of the vehicle-mounted software function and the logical processing between multiple signals, subscribes to the signals according to the scenario signals defined by V-DSL. The signal judgment rules can be abstracted as relational operations such as greater than, equal to, and less than. Whether the signal conditions are met is judged by the true or false of the operation result. At the same time, the logical operation rules of multiple signals need to be completed to process the trigger conditions of complex products. For the above example of the vehicle-mounted software function product for PM2.5 perception, node object 0, node object 1, and node object 3 are all completed in this part, and the specific completion order is determined by the link relationship of the node objects.

[0091] Interaction node processing mainly analyzes the interaction node objects in the V-DSL script. When the scenario node processing reaches the trigger condition for executing the product. If there are no interaction node objects in the product, the product can run directly. If there are interaction node objects defined in the product, the interaction node objects in the product script file are parsed to obtain the interaction type (such as voice interaction or interface click interaction) and the interaction object (in-vehicle computer / instrument, etc.), and the interaction information is sent to the interaction object. After the interaction is completed, the user feedback information is obtained.

[0092] Service node processing is mainly responsible for the mechanism of calling vehicle services and cloud services after the product meets the conditions. For SOA services, when the vehicle-mounted container engine calls services, the vehicle-mounted container engine is the client of the service. In view of the complex environment of vehicle hardware, this module needs to be compatible with the situation where the service returns immediately and the situation where the service cannot give immediate feedback, and be compatible with the situation where the execution result is obtained through the return value and the situation where it is returned through the event mechanism, etc. For the above example of the vehicle-mounted software function product for PM2.5 perception, node object 2 and node object 4 are all completed in this part, and the specific completion order is determined by the link relationship of the node objects.

[0093] The processing of node link relationships is the execution logic for handling the entire functionality described by V-DSL. Analogous to the execution sequence in a program flow chart, the node link relationship processing module concatenates all the abstract node objects in V-DSL, and the engine executes step by step according to the expressed logic. When the next node object cannot be found, the product script file execution is completed. For the above example of the in-vehicle software function product for PM2.5 perception, Link 1 and Link 2 are completed synchronously, and Link 3 and Link 4 also wait synchronously for the conditions to be met. That is to say, after the perception of node object 0, the in-vehicle container engine will simultaneously enter the states of node object 1 and node object 3, and based on the decision-making situation, finally enter the state of node object 2 or node object 4.

[0094] It should be noted that the vehicle in this embodiment is a vehicle oriented to the SOA service software architecture, and all its relevant capabilities have been service-ified. When multiple in-vehicle software functions need to be implemented on vehicle model A, a product script file can be written for each in-vehicle software function based on V-DSL, and a vehicle container engine is used to load and run this product script file. The product script file includes multiple node objects and node object link relationships. By running the product script file, the corresponding SOA service can be called in a specific scenario to implement the corresponding in-vehicle function. The vehicle container engine, as the container for running the product script file, isolates the vehicle's underlying layer. Therefore, when the same in-vehicle software function needs to be implemented on vehicle model B, only the vehicle container engine needs to be adapted on vehicle model B. After the vehicle container engine is transplanted once, the vehicle container engine, as the running environment of the product script file, is deployed in the central controller (CCU). The vehicle container engine can provide a unified running environment and interface. The vehicle container engine has a certain cross-platform ability, which can ensure that after transplanting the in-vehicle product engine between different vehicle models, the original functions of other vehicle models can be transplanted to the new vehicle model, and all in-vehicle software functions can be automatically adapted. The vehicle container engine on vehicle model B can still run the above-mentioned product script file written based on V-DSL, thus realizing the transformation from the previous single product function-level transplantation to the transplantation of the vehicle container engine, greatly improving the development efficiency of in-vehicle software functions and reducing the development cost. If assisted by relevant visual development tools, product designers can complete the development of in-vehicle software functions in a visual and graphical way.

[0095] Embodiment 4 of this application also proposes a computer-readable storage medium. The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, it implements the in-vehicle software function implementation method as described in Embodiment 1 or 2 above.

[0096] Specifically, the computer-readable storage medium may include: any entity or recording medium capable of carrying the computer program instructions, such as a USB flash drive, a mobile hard disk, a magnetic disk, an optical disc, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium, etc.

[0097] Embodiment 5 of this application proposes an electronic device, including a processor, a memory, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, it implements the vehicle-mounted software function implementation method as described in Embodiment 1 or 2 above.

[0098] Among them, the electronic device may further include a bus connecting different components (including the memory and the processor). The memory may include a computer-readable medium in the form of volatile memory, such as a random access memory (RAM) and / or a cache memory. The memory may also include at least one program product, and this program product has a set of (for example, at least one) program modules, and these program modules are configured to execute the functions of the embodiments of this application. The electronic device may also communicate with one or more external devices (such as a keyboard, a pointing device, a display, etc.), and may also communicate with one or more devices that enable a user to interact with the electronic device, and / or communicate with any device that enables the electronic device to communicate with one or more other computing devices (such as a network card). Such communication may be carried out through an input / output (I / O) interface. Moreover, the electronic device may also communicate with one or more networks (such as a local area network (LAN), a wide area network (WAN), and / or a public network, such as the Internet) through a network adapter.

[0099] The embodiments of this application have been described above. The above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and variations are obvious to those of ordinary skill in the art in the technical field without departing from the scope and spirit of the described embodiments. The selection of the terms used herein is intended to best explain the principles of the embodiments, practical applications, or improvements to the technology in the market, or to enable other ordinary skill in the art in the technical field to understand the embodiments disclosed herein.

Claims

1. A method for implementing in-vehicle software functions, characterized in that, the method includes: loading a product script file and running the product script file to implement the corresponding in-vehicle software function; one product script file corresponds to one in-vehicle software function; wherein, running the product script file specifically includes: parsing the product script file to obtain a plurality of node objects and node object link relationships; wherein, the plurality of node objects include a plurality of decision scenario node objects and a plurality of service set node objects; the decision scenario node objects include decision scenario description information written in a vehicle domain-specific language; the service set node objects include SOA service description information written in a vehicle domain-specific language; the node object link relationships include link relationships between the plurality of node objects written in a vehicle domain-specific language; obtaining vehicle perception signals, and determining whether the current vehicle scenario matches any decision scenario described by a scenario node object according to the vehicle perception signals. If there is a match, determine the service set node object linked to the any decision scenario node object according to the node object link relationships, and call the SOA service corresponding to the service set node object.

2. A method for implementing in-vehicle software functions, characterized in that, the method includes: loading a product script file and running the product script file to implement the corresponding in-vehicle software function; one product script file corresponds to one in-vehicle software function; wherein, running the product script file specifically includes: parsing the product script file to obtain a plurality of node objects and node object link relationships; wherein, the plurality of node objects include a plurality of decision scenario node objects, a plurality of interaction node objects and a plurality of service set node objects; the decision scenario node objects include scenario description information written in a vehicle domain-specific language; the interaction node objects include description information written in a vehicle domain-specific language for asking the user whether to call a service; the service set node objects include SOA service description information written in a vehicle domain-specific language; the node object link relationships include link relationships between the plurality of node objects written in a vehicle domain-specific language; obtaining vehicle perception signals, and determining whether the current vehicle scenario matches any scenario described by a decision scenario node object according to the vehicle perception signals. If there is a match, determine the interaction node object linked to the any decision scenario node object according to the node object link relationships, interact with the user according to the interaction node object to ask the user whether to call a service. If so, determine the service set node object linked to the interaction node object according to the node object link relationships, and call the SOA service corresponding to the service set node object.

3. The method according to claim 2, characterized in that, the interaction node object includes an interaction method attribute, a waiting response time attribute and an interaction content attribute.

4. The method according to claim 1 or 2, characterized in that, The multiple scenario node objects further include a perception scenario node object, and the perception scenario node object includes perception scenario description information written based on a vehicle domain-specific language; The obtaining of the vehicle perception signal and determining whether the current vehicle scenario matches the decision scenario described in any decision scenario node object according to the vehicle perception signal specifically includes: Obtaining the vehicle perception signal, and determining whether the current vehicle scenario matches the perception scenario described in the perception scenario node object according to the vehicle perception signal. If it matches, further determining several decision scenario node objects linked to the perception scenario node object according to the node object link relationship, and determining whether the current vehicle scenario matches the decision scenario described in any decision scenario node object according to the vehicle perception signal.

5. The method according to claim 4, wherein, Both the decision scenario node object and the perception scenario node object include several signal rules, and the signal rule is a judgment expression composed of a signal real-time value attribute, an operator attribute, and a signal target value attribute; If the decision scenario node object or the perception scenario node object includes one signal rule, when the vehicle perception signal satisfies this signal rule, the vehicle scenario matches the scenario described in the decision scenario node object or the perception scenario node object; If the decision scenario node object or the perception scenario node object includes at least two signal rules, forming a signal rule set by logically relating the at least two signal rules, and when the vehicle perception signal satisfies the signal rule set, the vehicle scenario matches the scenario described in the decision scenario node object or the perception scenario node object.

6. The method according to claim 1 or 2, wherein, The service set node object includes several service objects and an interruption strategy attribute. The service object includes an execution parameter attribute and a delay time attribute. The several service objects determine the timing relationship between each other through the delay time attribute, and the interruption strategy attribute includes the processing strategy during the execution of the several service objects.

7. The method according to claim 1 or 2, wherein, The link relationship between any two node objects includes an input node index attribute, an output node index attribute, and a link type attribute. The input node index attribute refers to one of the two node objects, the output node index attribute refers to the other of the two node objects, and the link type attribute refers to that after the processing result of the input node index attribute meets a preset condition, jumping to process the output node index attribute.

8. The method according to claim 1 or 2, wherein, The method specifically includes: When calling the SOA service corresponding to the service set node object, specifically calling the SOA service corresponding to the service set node object according to a preset meta-model file; the meta-model file includes the registration information of the SOA services used by the product.

9. The method according to claim 1 or 2, wherein, The method specifically includes: When invoking the SOA service corresponding to the service set node object, specifically, the SOA service corresponding to the service set node object is invoked according to a preset personalized parameter setting file; the personalized parameter setting file includes the personalized parameters of the user.

10. The method according to claim 1 or 2, wherein, the product script file includes product definition information and product function expression information; the product definition information includes a product unique identifier, meta-model information, initial product setting values, and the signal name of the product. The product unique identifier includes a product id and a product version number. The meta-model information includes a meta-model version and a meta-model id. The meta-model version corresponds to the vehicle model. The meta-model id corresponds to all the SOA service information required by the product. The initial product setting values are the default values of each parameter of the product. The signal name is the name of the vehicle perception signal required by the product; the product function expression information includes the multiple node objects and the node object link relationship.

11. An in-vehicle container engine, wherein, it includes a module for executing the in-vehicle software function implementation method according to any one of claims 1 to 10.

12. A computer-readable storage medium, wherein, the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, it implements the in-vehicle software function implementation method according to any one of claims 1 to 10.

13. An electronic device, wherein, it includes a processor, a memory, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, it implements the in-vehicle software function implementation method according to any one of claims 1 to 10.

Images