Method for dynamically issuing locomotive by using lua script generated by workflow

Abstract

The invention discloses a method for generating a Lua script dynamic departure engine through a workflow, and relates to the technical field of Internet of Vehicles and vehicle-mounted software, and the method comprises the steps: firstly constructing a basic operator through a cloud platform, responding to a user arrangement, generating a process definition file, converting the process definition file into a Lua script code, and packaging and uploading the Lua script code after digital signature; and the vehicle terminal monitors a system state, downloads an update file when a trigger condition is satisfied, and performs integrity verification and signature verification. And after the verification is passed, the calculation center module starts a Lua interpreter to run a script, and calls a local Java operator to execute service logic through a reflection mechanism. According to the method, decoupling of service logic and underlying capability is realized through cloud arrangement and an end-side sandbox execution mechanism, dynamic hot update of the vehicle machine function is completed under the condition that firmware OTA flash is not carried out, and meanwhile, the security of script operation is ensured by utilizing encryption verification and permission isolation.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of Internet of Vehicles and vehicle-mounted software, and particularly relates to a method for dynamically delivering a vehicle machine by a work flow generation Lua script. BACKGROUND

[0002] With the popularization of Internet of Vehicles technology, the functions carried by the vehicle-mounted information entertainment system are increasingly rich, and users have higher requirements for the function iteration speed of vehicle machine applications. At present, the function update of the vehicle machine system mainly depends on remote upgrade technology, which usually includes firmware upgrade and software upgrade. This traditional update method often needs to replace the entire system image or application installation package in full, even if it is only necessary to adjust a subtle business logic, the user needs to download a large volume of data package and go through a long flashing and system restart process, resulting in large resource consumption, low update efficiency, and easy interruption of normal use of the user.

[0003] In the existing vehicle machine software development architecture, the upper-layer business logic is usually tightly coupled with the lower-layer function implementation, and the business rules are hard-coded in the compiled program file. When the business requirements change, the developer must modify the source code and re-complete the compilation, packaging, testing and release process. This high-coupling mode makes the development cycle longer and makes it difficult to respond to flexible market demands, increasing the maintenance cost of the software.

[0004] In addition, although there are some dynamic loading technologies in the mobile Internet field, in the vehicle-mounted environment with extremely high requirements for safety and stability, directly issuing and executing external code faces serious challenges. If there is a lack of effective identity authentication, integrity verification and runtime isolation mechanism, the dynamic script issued is easy to be attacked by network attacks or malicious tampering, and major logic errors can cause the vehicle machine system to crash or run out of resources, thereby affecting the driving safety of the vehicle. Therefore, how to realize the decoupling and lightweight hot update of the vehicle machine business logic under the premise of ensuring system safety and stability is a problem to be solved in the current technical field. SUMMARY

[0005] The purpose of the present application is to provide a method for dynamically delivering a vehicle machine by a work flow generation Lua script, which at least solves the problems of low efficiency caused by the dependence of the function update of the existing vehicle machine system on the overall upgrade of the firmware, high development and maintenance cost caused by the tight coupling of business logic and underlying code, and the lack of effective security protection and runtime isolation mechanism for dynamic code issuance and execution.

[0006] The present application provides a method for dynamically delivering a vehicle machine by a work flow generation Lua script, which comprises the following steps:

[0007] S1, build a basic capability operator through an operator development service module of a cloud service platform, generate a release package containing an operator library file and a metadata file, and register operator interface information to an operator service capability management module;

[0008] S2, respond to user operations through an operation background front-end module, compile a business logic flow based on the registered operator interface information, and generate a corresponding flow definition file;

[0009] S3, receive the flow definition file through an operator script development platform module, convert the flow definition file into Lua script code using conversion rules, perform digital signature processing on the Lua script code, and encapsulate the Lua script code into a script file, upload the script file and the operator library file to a release platform module;

[0010] S4, monitor system status through a computing center module of a vehicle terminal, and initiate a query request to the release platform module when a preset triggering condition is met, download updated script files and operator library files;

[0011] S5, perform integrity checking and signature verification on the downloaded files through the computing center module, and load class objects in the operator library file using a class loader after the integrity checking and signature verification are passed;

[0012] S6, receive execution instructions from a business application module through the computing center module, start a Lua interpreter to run corresponding script files, and execute business logic by calling methods in the operator library file through a reflection mechanism.

[0013] In the above method, the operator construction process of the cloud service platform adopts an annotation-driven approach. The operator development service module receives Java source code containing specific business logic classes, which are marked by preset annotations. During compilation, the annotation processor scans the annotations in the source code, extracts the class fully qualified name, method signature, and parameter description information, and generates a metadata file describing the characteristics of the operator interface. The compiled operator library file and the metadata file are packaged as commodity units, and the operator library file is digitally signed using an asymmetric encryption algorithm to ensure the reliability of the operator source.

[0014] In the above method, the script generation process is implemented through graph structure analysis and code mapping. The operator script development platform module analyzes the graph structure in the flow definition file, which describes the node set and the edge set between the nodes. For action execution nodes in the node set, the conversion engine maps them to Java reflection call statements in the Lua environment. This mapping process converts the operator class, method, and parameter set referenced by the action node into call instructions for a predefined reflection call encapsulation function, which is used to trigger the specific behavior of the Java operator in the Lua runtime environment.

[0015] For conditional branch nodes in the node set, the conversion engine converts them into conditional control statements. The conversion process builds control logic according to the Boolean expression contained in the conditional node, so that the script can select the branch path that meets the condition or does not meet the condition according to the calculation result of the expression when running. In addition, the operator script development platform module executes a dependency analysis program to scan all operator class identifiers referenced by action execution nodes in the flow definition file, and generates a dependency declaration code in the head of the script, which contains import instructions for loading corresponding operator classes.

[0016] In the above method, the release and distribution of resources adopt a tagging strategy. The release platform module configures a visibility tag for each resource version, which includes at least one of a vehicle identification code list, a geographical area where the vehicle is located, a vehicle configuration code, and a user group identifier. When the release platform module receives a query request from the computing center module, it retrieves all resources that the vehicle has access to according to the vehicle identification code carried in the request, and compares the latest version number on the cloud with the local version number carried in the request. Only when there is a resource on the cloud with a higher version number and meeting the visibility tag strategy, a response message containing the resource download address is generated.

[0017] In the above method, the car machine terminal ensures timely update of resources through a triggering mechanism. The computing center module configures a resource update listening service to maintain real-time monitoring of the car machine operating system state. When a system cold start scenario is detected, i.e., the vehicle ignition power-on causes the car machine operating system to complete the boot-up process, a query request is initiated; or when a system from suspend state recovery scenario is detected, i.e., the car machine operating system receives a user presentation broadcast signal indicating that the system wakes up from the STR hibernation state, a query request is initiated.

[0018] In the above method, the car machine terminal performs strict security verification on the downloaded resources. The computing center module calculates the hash digest of the downloaded file and compares it with the hash value in the metadata issued by the cloud. If the calculated digest does not match the hash value in the metadata, the integrity verification fails, and the file is deleted and the update is terminated. After the integrity verification is passed, the computing center module reads the RSA public key pre-stored in the security storage area when the car machine is shipped and the digital signature value attached to the downloaded file, and calls the asymmetric encryption algorithm library to perform the signature verification operation. Only when the signature verification returns true value, it is confirmed that the resource comes from a legal release platform module.

[0019] Further, after the security check passes, the computing center module performs a dependency check. The computing center module decompresses the script file and reads the description file therein to extract a list of operators on which the script runs depend. Meanwhile, the computing center module scans the locally installed and security-checked operator set. The computing center module determines whether the list of operators on which the script depends belongs to a subset of the locally installed operator set. If a missing operator is detected, the computing center module automatically triggers a download request or a rollback update operation for the missing operator to prevent runtime errors.

[0020] In the above method, the execution of the script relies on a hybrid running environment. The computing center module constructs an environment based on the cooperation of the Java virtual machine and the Lua interpreter. When the Lua interpreter is started, a sandbox isolation strategy is configured, and application program interfaces in the Lua standard library related to system file operations, operating system process control, and debugging functions are removed. A preset proxy function is injected into the Lua global environment as a channel for the Lua script to call the Java operator. When the Lua interpreter executes a function call instruction, the proxy function is triggered, and the proxy function is used to find the corresponding Java class instance in the memory mapping table of the operator identifier and the Java class instance method.

[0021] In the above method, the business application module and the computing center module interact through inter-process communication or an AIDL interface. The business application module sends an execution instruction containing a unique identifier of a target script and a business scenario context parameter. The computing center module converts the business scenario context parameter into a Lua table structure and pushes it into the Lua virtual machine stack. After the script file is executed, the computing center module captures the final output data of the script and encapsulates it as a response object to return to the business application module.

[0022] Through the above scheme, the following beneficial technical effects are obtained:

[0023] The present application realizes lightweight hot updating of car machine business logic. By converting a business process arranged in the cloud into a Lua script file for independent distribution, the car machine terminal can directly load and run new business logic using the built-in Lua interpreter. Compared with the traditional whole vehicle OTA upgrade which requires downloading a full firmware package and restarting the system for flashing, this method only needs to transmit a small script file, and the function iteration can be completed without interrupting the vehicle operation, significantly improving the update efficiency and response speed of the car machine function.

[0024] This application reduces the development and maintenance costs of in-vehicle infotainment software. The invention adopts an architecture that separates the underlying operators from the upper-level logic. Hardware control capabilities are encapsulated into stable Java operators, while the variable business logic is decoupled into Lua scripts. The two interact through reflection. When business requirements change, developers only need to adjust the process orchestration and regenerate the scripts in the cloud, without modifying or recompiling the underlying Java code. This achieves decoupling between the business layer and the implementation layer, improving code reusability.

[0025] This application ensures the secure execution of dynamic scripts in the in-vehicle infotainment system environment. During the distribution phase, the invention utilizes digital signatures and hash verification technologies to ensure that the distributed script files are tamper-proof and of legitimate origin. During the runtime phase, a sandbox environment that removes system-level operation interfaces is constructed, restricting scripts to calling specific operators only through pre-defined channels. This multi-layered protection mechanism effectively prevents malicious code injection or unauthorized operations, ensuring that the in-vehicle operating system maintains system stability while allowing script execution capabilities. Attached Figure Description

[0026] Figure 1 This is a schematic diagram of the overall system architecture of the present invention.

[0027] Figure 2 This is a flowchart of the overall system operation and interaction of the present invention. Detailed Implementation

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

[0029] See attached document Figure 1 This invention provides an intelligent connected vehicle control system, which mainly includes a cloud service platform 100 and a vehicle terminal 200. The cloud service platform 100 and the vehicle terminal 200 are connected via a wireless communication network for data transmission and command interaction.

[0030] The cloud service platform 100 is used to manage basic operator capabilities, orchestrate business logic, and generate and publish executable scripts. The cloud service platform 100 includes an operator development service module 101, an operator service capability management module 102, an operations backend frontend module 103, an operator script development platform module 104, and a publishing platform module 105.

[0031] The operator development service module 101 is used to develop and manage basic capability operators. Operators are encapsulations of the vehicle-mounted system's underlying service interfaces, existing as Java class libraries or JAR files. The operator development service module 101 is responsible for compiling these operators and generating corresponding metadata files.

[0032] The operator service capability management module 102 is used to register and store operator information output by the operator development service module 101. This module maintains the operator's interface definition, parameter list, and version information, providing indexable basic capability units for upper-level visual orchestration.

[0033] The operations backend frontend module 103 provides a visual human-computer interaction interface. It reads operator data from the operator service capability management module 102, allowing operators to define business logic processes through node drag-and-drop and parameter configuration in a graphical interface. The operations backend frontend module 103 then exports the orchestrated business logic as a standard format process definition file.

[0034] The operator script development platform module 104 receives process definition files and converts them into executable code. Module 104 has a built-in conversion rule engine that parses and maps JSON-formatted process definition files into Lua script code. Furthermore, module 104 is also responsible for calling a signature service to digitally sign the generated scripts.

[0035] The publishing platform module 105 is used to store and distribute operator JAR packages and Lua script files. The publishing platform module 105 receives operator packages from the operator development service module 101 and script files from the operator script development platform module 104, and maintains the version numbers, dependencies, and canary release strategies of the resources.

[0036] The vehicle-mounted terminal 200 is the execution environment for logic scripts. The vehicle-mounted terminal 200 includes a computing center module 201 and a business application module 202.

[0037] The Computing Center Module 201 is a core component deployed in the vehicle's operating system, responsible for resource lifecycle management and logic execution. The Computing Center Module 201 includes a resource management unit, a security verification unit, a class loading unit, and a script execution unit. The resource management unit monitors update signals and retrieves the latest operator and script files from the release platform module 105. The security verification unit verifies the integrity and signature validity of downloaded files. The class loading unit loads operator JAR packages into memory. The script execution unit has a built-in Lua interpreter for parsing and running Lua scripts, and invokes methods in the operator JAR packages via reflection.

[0038] The business application module 202 is the upper-layer application of the vehicle-mounted system, such as a recommendation application, scene engine, or HMI interface program. The business application module 202 does not contain specific business control logic, but instead sends script execution requests to the computing center module 201 through API interfaces and receives the execution results.

[0039] See attached document Figure 2 This invention provides a method for generating scripts based on a visual workflow engine and dynamically sending them to the vehicle's infotainment system for execution. The method includes the following steps:

[0040] S1. Build basic capability operators through the operator development service module, generate a release package containing operator library files and metadata files, and register the operator interface information to the operator service capability management module;

[0041] S2. The front-end module of the operation backend responds to user operations, orchestrates business logic processes based on the registered operator interface information, and generates corresponding process definition files.

[0042] S3, the operator script development platform module receives the process definition file, converts it into Lua script code using conversion rules, performs digital signature processing on the script code, and uploads the signed script file and operator library file to the publishing platform module;

[0043] S4. The computing center module of the vehicle terminal monitors the system status and sends a query request to the publishing platform module when the preset trigger conditions are met, and downloads the updated script files and operator library files.

[0044] S5. The computing center module performs integrity verification and signature verification on the downloaded file. After the verification is successful, it uses the class loader to load the class object in the operator library file.

[0045] S6. The computing center module receives execution instructions from the business application module, starts the Lua interpreter to run the corresponding script file, and calls the methods in the operator library file through reflection to execute business logic.

[0046] The technical details of operator construction, script conversion, resource distribution, and terminal execution in each of the above steps will be described in detail below.

[0047] The basic capability operator construction method provided by this invention relies on the operator development service module 101 and the operator service capability management module 102. The specific implementation details are as follows:

[0048] An operator is the smallest functional unit in a vehicle-mounted terminal that executes business logic; essentially, it is a Java class library that encapsulates the underlying service interfaces of the vehicle-mounted terminal. The operator development service module 101 is responsible for managing the operator's lifecycle, including code writing, compilation, and metadata generation. The operator distribution package consists of operator library files (JARs) and metadata files.

[0049] During the build phase, the operator development service module 101 receives Java source code written by developers. The source code contains specific business logic classes, which are marked with predefined annotations. These annotations identify the methods allowed to be called by external scripts, the types of input parameters, and the return value types within the class.

[0050] During the compilation process, the operator development service module 101 initiates the annotation processor. The annotation processor scans the annotation tags in the source code, extracts the fully qualified class name, method signature, and parameter description information, and generates the corresponding metadata file. The metadata file uses a structured data format (such as JSON or XML) to accurately describe the functional interface characteristics of the operator, ensuring that the script generation service can correctly index the operator capabilities.

[0051] The operator library files encapsulate the logic for calling common capabilities at the vehicle's underlying system level. Specifically, operator classes control vehicle hardware status or acquire sensor data by referencing system service interfaces (such as HQCarService) or data synchronization service interfaces (such as DataSyncService) provided by the vehicle's operating system. For example, an operator that controls the windows contains code instructions that call relevant APIs of the Body Domain Controller (BCM).

[0052] The operator development service module 101 packages the compiled operator library files and metadata files into an independent product unit. Each product unit is assigned a unique product code and version identifier. The version identifier is used to distinguish operator functions in different iteration cycles, supporting incremental updates or version rollbacks by the vehicle terminal.

[0053] Before release, the operator development service module 101 digitally signs the operator library file using an asymmetric encryption algorithm. This process calculates the hash digest of the operator library file and encrypts the digest using a preset private key to generate a signature value. The signature value is stored together with the operator release package to ensure the integrity of the operator file and the authenticity of its origin during transmission.

[0054] The completed operator information is registered to the operator service capability management module 102. The operator service capability management module 102 parses the metadata file and establishes a mapping relationship library between operator identifiers and functional interfaces. This mapping relationship library provides data support for the operation backend front-end module 103, enabling the front-end designer to display operator capabilities in the form of visual nodes, which users can directly reference when orchestrating processes.

[0055] The business logic orchestration and script generation method provided by this invention mainly relies on the collaboration between the operation backend front-end module 103 and the operator script development platform module 104. The specific implementation method is as follows:

[0056] The operations backend frontend module 103 provides a graphical editing interface based on a directed graph model. Responding to external input commands, the operations backend frontend module 103 constructs a business process topology structure containing multiple logical nodes. The logical node types include at least start nodes, end nodes, conditional branch nodes, action execution nodes, and delay / wait nodes. Action execution nodes are bound to operator interfaces registered in the operator service capability management module 102 for configuring specific operator methods and input parameters.

[0057] The operations backend frontend module 103 serializes the completed business process topology into a standard format process definition file. This process definition file typically uses JSON format, and its internal data structure describes a set of nodes. and the set of edges between nodes To form a graph structure For sets For each node in the process, the process definition file records the node type, configuration parameters, and subsequent node index.

[0058] Operator script development platform module 104 receives the process definition file and executes the code generation program through the built-in transformation engine. (Transformation engine parsing graph structure) It uses depth-first traversal or breadth-first traversal algorithms to map logical nodes to the syntax structure of the Lua scripting language.

[0059] For the action execution node, operator script development platform module 104 converts it into a Java reflection invocation statement in the Lua environment. Let the action node be... The operator class referenced by this node is The method is The parameter set is The generated script code snippet The following mapping relationship is satisfied:

[0060] ;

[0061] in, This provides a predefined function wrapper for reflection calls, used to trigger specific behaviors of Java operators within the Lua runtime environment.

[0062] For conditional branch nodes, operator script development platform module 104 converts them into conditional control statements. Let the conditional node be... Its contained Boolean expression is The branch paths that meet the conditions are The branch path that does not meet the conditions is The generated script code structure Represented as:

[0063] ;

[0064] in, This indicates the output of the code transformation function recursively executed on subsequent path nodes.

[0065] Before generating the main logic code, the operator script development platform module 104 executes a dependency analysis program. This program scans all operator class identifiers referenced by action nodes in the flow definition file and generates dependency declaration code in the script header. Let the set of operator classes referenced by the script be... The generated header code as follows:

[0066] ;

[0067] in, This is an instruction used to load operator classes, ensuring that the relevant operators are ready in memory when the script is executed.

[0068] Operator script development platform module 104 will include header code Combined with the main logic code, a complete Lua script file is generated. Subsequently, the operator script development platform module 104 calls the key management service, uses the RSA private key to calculate the content of the script file, generates a digital signature, and appends the script version number, effective time, and digital signature to the metadata area of ​​the script file, completing the script generation process.

[0069] The resource publishing and distribution method provided by this invention mainly relies on the publishing platform module 105 for execution, and the method includes the following:

[0070] The publishing platform module 105 establishes a resource management architecture based on the product model. This architecture collectively refers to operator library files and Lua script files as product resources. The publishing platform module 105 organizes resources through a four-level hierarchical structure: business users, product categories, product entities, and product versions.

[0071] During the resource release phase, the release platform module 105 executes a strict sequential operation process. First, in response to administrator instructions, the release platform module 105 creates a product category for the specific business scenario. Second, it creates a unique product identifier (Code or ID) based on this product category. Third, it creates a specific product version number for this product identifier; the version number is used to identify the resource's iteration order. Finally, it associates the compiled Lua script file or operator library file with this product version and submits the release command.

[0072] Upon receiving a publishing instruction, the publishing platform module 105 performs a digital signature operation on the resource file. The publishing platform module 105 uses a pre-set private key to encrypt and compute the binary stream of the script file or operator library file, generating a digital signature string. This digital signature is stored along with the resource file in the object storage system, and a corresponding network download address (URL) is generated.

[0073] The publishing platform module 105 uses a tagging system to control the distribution scope of resources, implementing a canary release strategy. The publishing platform module 105 allows configuring visibility tags for each product version. These tags include, but are not limited to, a list of Vehicle Identification Numbers (VINs), the geographical region where the vehicle is located, the vehicle model configuration code, and user group identifiers. The publishing platform module 105 only distributes the corresponding resource version to terminals that match specific tag rules.

[0074] The publishing platform module 105 provides a resource query interface based on the HTTP protocol. When the computing center module 201 of the vehicle terminal initiates a query request, the publishing platform module 105 receives the vehicle identification code and the list of currently installed resource versions carried in the request.

[0075] The publishing platform module 105 retrieves all product resources that the vehicle is authorized to access from the database based on the vehicle identification number. The publishing platform module 105 compares the latest version number in the cloud with the local version number carried in the request. When a resource with a higher version number and conforming to the tagging policy exists in the cloud, the publishing platform module 105 packages the resource's download address, version information, file hash value, and digital signature into a response message and returns it to the computing center module 201.

[0076] The publishing platform module 105 supports the verification and distribution of resource dependencies. When publishing Lua script products, the publishing platform module 105 parses the list of operator dependencies declared in the script metadata. When issuing resource response messages, the publishing platform module 105 checks whether the target vehicle has the operator versions required for script execution. If dependencies are missing, the publishing platform module 105 will also include download information for the required operator library files in the response message to ensure that the terminal can obtain a complete execution environment.

[0077] The vehicle-mounted terminal resource management and update method provided by this invention mainly relies on the computing center module 201 deployed in the vehicle-mounted terminal 200 for execution. The method includes the following:

[0078] The computing center module 201 is configured with a resource update monitoring service, which maintains real-time monitoring of the vehicle's operating system status to determine when to trigger an update. The triggering timing is primarily set for two scenarios: the first is a system cold start scenario, i.e., when the vehicle is started and powered on, causing the vehicle's operating system to complete the boot process; the second is a system recovery scenario, i.e., when the vehicle's operating system receives a user-presented broadcast signal (such as the ACTION_USER_PRESENT signal in Android), indicating that the system has woken up from its STR sleep state.

[0079] After detecting the aforementioned trigger signal, the computing center module 201 initiates a resource query request to the cloud-based publishing platform module 105. This request message is transmitted via an HTTPS encrypted channel and contains the vehicle's unique identification number (VIN) as well as a list of operator library versions and script versions stored in the computing center module 201's local database.

[0080] The computing center module 201 receives the response message returned by the publishing platform module 105. The response message contains a list of the latest resources available within the current vehicle's permission scope. The computing center module 201 executes version comparison logic, iterating through each resource item in the response list. Let the resource version number returned by the cloud be... The corresponding resource version number for local storage is (If the resource does not exist locally) (For example, 0). The computation center module 201 is valid if and only if it satisfies... When the conditions are met, the resource is marked as pending update, and the resource download address (URL), file hash value, and digital signature data provided in the response message are parsed.

[0081] Based on the resolved download address, the computing center module 201 downloads the corresponding operator JAR package or Lua script compressed package from the content delivery network (CDN). After the file is downloaded to the vehicle's local temporary storage area, the computing center module 201 immediately initiates a security verification procedure. The security verification procedure first performs an integrity check, calculating the SHA-256 hash digest of the downloaded file. and the hash value in the metadata distributed from the cloud. Perform a comparison. The verification logic satisfies:

[0082] ;

[0083] ;

[0084] If the integrity check fails, the computing center module 201 will directly delete the temporary file and terminate the update process of the resource.

[0085] After the integrity verification passes, the computing center module 201 executes the digital signature verification procedure. The computing center module 201 reads the RSA public key pre-installed in a secure storage area (such as a TEE environment) when the vehicle's infotainment system leaves the factory. and the digital signature value accompanying the download package. The computing center module 201 calls the asymmetric encryption algorithm library to perform signature verification. The verification process is defined as follows:

[0086] ;

[0087] Only when Only when the value "True" is returned can the computing center module 201 confirm that the resource originated from the legitimate publishing platform module 105 and has not been tampered with.

[0088] After completing the security verification of the Lua script file, the Computing Center Module 201 further executes a dependency check procedure. The Computing Center Module 201 decompresses the script archive, reads the included description file (such as description.json), and extracts the list of operators that the script must depend on to run. The computing center module 201 scans the locally installed and verified set of operators. The necessary conditions for the update operation to continue are:

[0089] ;

[0090] If the computing center module 201 detects a missing local dependency operator, it will automatically trigger a download request for the missing operator, or roll back the update operation of the script if the dependency cannot be obtained, in order to prevent runtime errors from occurring.

[0091] After all validation and dependency checks pass, the computing center module 201 moves temporary files to persistent storage and updates the version index information in the local resource database. For operator JAR packages, the computing center module 201 triggers the class loader for dynamic loading; for Lua scripts, the computing center module 201 updates the script index table so that subsequent business calls can point to the latest script file path, thereby completing the hot update process of resources.

[0092] The in-vehicle terminal script execution and runtime interaction method provided by this invention relies on the class loading unit and script execution unit within the computing center module 201. The specific implementation details are as follows:

[0093] The Computing Center Module 201 constructs a hybrid runtime environment based on the collaborative operation of the Java Virtual Machine and the Lua interpreter. During the initialization phase of the Computing Center Module 201, the class loading unit scans the operator library files in the local persistent storage area that have passed security checks. The class loading unit uses Java reflection to traverse the class definitions in the operator library files and identify the public methods marked with annotations. The Computing Center Module 201 establishes a memory mapping table between operator identifiers and Java class instance methods. This mapping table is used to quickly index the underlying Java objects during script runtime.

[0094] The Computing Center Module 201 initializes the Lua execution environment, namely the Lua Virtual Machine (Lua State). To ensure the stability and security of the vehicle's operating system, the Computing Center Module 201 configures a sandbox isolation policy when the Lua Virtual Machine starts. The Computing Center Module 201 removes dangerous application programming interfaces (APIs) from the Lua standard library that involve system file operations (such as the I / O library), operating system process control (such as os.execute), and debugging functions. The Computing Center Module 201 only injects pre-defined proxy functions into the global Lua environment, serving as the sole channel for Lua scripts to call Java operators.

[0095] The business application module 202, acting as the initiator of logic execution, sends execution requests to the computing center module 201 via inter-process communication (IPC) or the AIDL interface. The execution request includes a unique identifier for the target script and business scenario context parameters. The business application module 202 does not contain specific business judgment logic; it is only responsible for triggering actions and displaying the final results.

[0096] After receiving the execution request, the computing center module 201 retrieves the corresponding Lua script file from the local index based on the script identifier. The computing center module 201 converts the business scenario context parameters into a Lua table structure and pushes it onto the Lua virtual machine's stack. The computing center module 201 then calls the Lua interpreter to parse the script file and execute it.

[0097] During Lua script execution, when a function call instruction corresponding to an action node is encountered, the Lua interpreter triggers a pre-defined proxy function. The proxy function receives the operator class identifier, method name, and parameter list from the script. The computing center module 201 uses the proxy function to look up the corresponding Java class instance in the operator mapping table.

[0098] The computing center module 201 executes cross-language call logic. It maps parameter types from the Lua environment to Java primitive data types and uses reflection to call specific methods in the operator library file. These methods further call the underlying service interfaces of the vehicle's operating system (such as vehicle control services and multimedia services) to achieve control of vehicle hardware or data acquisition.

[0099] After the Java operator method completes execution, the return result is passed back to the computing center module 201. The computing center module 201 converts the Java return object into a Lua data type and returns control to the Lua script to continue executing subsequent logic. When the Lua script reaches the end node, the computing center module 201 captures the script's final output data (such as pop-up commands and navigation coordinates) and encapsulates it into a response object, which is then returned to the business application module 202.

[0100] The computing center module 201 has the ability to capture and handle exceptions during execution. When a runtime error or timeout occurs during the execution of a Lua script, the computing center module 201 immediately terminates the Lua virtual machine and executes the preset default logical path. At the same time, it records the exception log and reports it to the cloud service platform 100, ensuring that the main functions of the business application module 202 are not affected by script failures.

[0101] This invention provides a method for dynamically updating vehicle infotainment system functions based on scripts. The implementation process of this method in a specific application scenario is as follows:

[0102] The operator development service module 101 pre-builds and compiles operator library files containing vehicle control capabilities. In this embodiment, the operator library files encapsulate at least air conditioning control operators, window control operators, and door lock control operators. The interface definitions and parameter specifications of the above operators are registered and stored in the operator service capability management module 102 as basic elements for subsequent logic orchestration.

[0103] In its initial state, the camping mode script running within the vehicle terminal 200 only contains air conditioning control logic. When it is necessary to upgrade the camping mode functionality to add window closing and vehicle locking logic, the operations personnel operate the operations backend front-end module 103. The operations backend front-end module 103 loads the list of available operators from the operator service capability management module 102 and reads the original camping mode flowchart in the visualization canvas.

[0104] The operations backend frontend module 103 responds to the user's editing commands, adding window closing and door locking action nodes sequentially via drag-and-drop, following the existing air conditioning on node. The operations backend frontend module 103 configures the operator method for the window closing action node as the fully closed interface of the window control operator, and configures the operator method for the door locking action node as the locking interface of the door lock control operator. The operations backend frontend module 103 then generates an updated process definition file from the modified business logic.

[0105] The operator script development platform module 104 receives the process definition file and converts it into Lua script code. The converted script code contains reflection call statements for the air conditioning control operator, window control operator, and door lock control operator. The operator script development platform module 104 digitally signs the new script and uploads it to the publishing platform module 105, marking it as an updated version.

[0106] The vehicle terminal 200 is in sleep or powered off state. When the vehicle terminal 200 detects an ignition signal or receives a user wake-up signal, the computing center module 201 initiates the initialization process. The computing center module 201 sends a version query message to the publishing platform module 105. The publishing platform module 105 compares the data and finds an updated version of the camping mode script in the cloud, and returns a download instruction to the computing center module 201.

[0107] The computing center module 201 downloads the updated script file and performs integrity verification and digital signature verification. After successful verification, the computing center module 201 replaces the old file in the local storage area with the new script file, completing the hot update of the logic. The entire update process does not involve reflashing or restarting the vehicle's firmware.

[0108] The user clicks the "Activate Camping Mode" button in the business application module 202 (e.g., the scene application app on the central control screen). The business application module 202 sends an execution command containing the "Camping Mode" script identifier to the computing center module 201.

[0109] The computing center module 201 loads and executes the updated Lua script. The Lua interpreter first executes the air conditioning activation logic, and then executes the newly added script logic sequentially. The Lua interpreter calls the locally loaded window control operator Java instance through a proxy function to send a window closing command to the vehicle body controller; then it calls the door lock control operator Java instance to send a lock command to the vehicle door lock controller.

[0110] Through the above process, the vehicle achieved a change from a single air conditioning control function to a composite control function that includes closing windows and locking doors, without undergoing a full-vehicle OTA upgrade, verifying the effectiveness of the dynamic distribution and execution of the logic script.

[0111] For ease of description, the above system is described by dividing it into various units and modules based on their functions. Of course, in implementing this application, the functions of each unit and module can be implemented in one or more software and / or hardware.

[0112] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the meaning consistent with their meaning in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined.

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

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

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

Claims

1. A method for dynamically issuing a vehicle machine by a workflow generation lua script, characterized in that, The method comprises the following steps: S1, constructing a basic capability operator through an operator development service module of a cloud service platform, generating a release package containing an operator library file and a metadata file, and registering operator interface information to an operator service capability management module; S2, responding to user operations through an operation background front-end module, compiling a business logic flow based on the registered operator interface information, and generating a corresponding flow definition file; S3, receiving the flow definition file through an operator script development platform module, converting the flow definition file into Lua script code using a conversion rule, performing digital signature processing on the Lua script code, and encapsulating the Lua script code into a script file, uploading the script file and the operator library file to a release platform module; S4, monitoring system status through a computing center module of a vehicle terminal, and initiating a query request to the release platform module when a preset triggering condition is met, downloading updated script files and operator library files; S5, performing integrity checking and signature verification on the downloaded files through the computing center module, and loading class objects in the operator library file using a class loader after the integrity checking and the signature verification are passed; S6, receiving an execution instruction from a business application module through the computing center module, starting a Lua interpreter to run the corresponding script file, and calling methods in the operator library file through a reflection mechanism to execute business logic.

2. The method of Claim 1, wherein, The operator development service module of the cloud service platform specifically comprises: receiving Java source code containing specific business logic classes, the business logic classes being marked by a preset annotation; starting an annotation processor during the compilation process, scanning the annotations in the source code, extracting class fully qualified names, method signatures, and parameter description information, and generating the metadata file; packaging the operator library file generated by the compilation and the metadata file into a commodity unit, and performing digital signature on the operator library file using an asymmetric encryption algorithm.

3. The method of claim 1, wherein the method further comprises: The operator script development platform module receiving the flow definition file and converting the flow definition file into Lua script code specifically comprises: parsing a graph structure in the flow definition file, the graph structure describing a node set and an edge set between nodes; for an action execution node in the node set, converting the action execution node into a Java reflection call statement in a Lua environment; the Java reflection call statement calls a predefined reflection call encapsulation function, the reflection call encapsulation function being used to trigger specific behaviors of a Java operator in a Lua runtime environment, and parameters of the reflection call encapsulation function including an operator class identifier, a method name, and a parameter set.

4. The method of Claim 3, wherein, The conversion rule used to convert the flow definition file into Lua script code further comprises: for a conditional branch node in the node set, converting the conditional branch node into a conditional control statement, the conditional control statement selecting a branch path meeting a condition or a branch path not meeting the condition according to a result of a Boolean expression; The dependency analysis program is executed to scan an operator class identifier referenced by all action execution nodes in the flow definition file; The dependency declaration code of the script header is generated, and the dependency declaration code includes an import instruction for loading an operator class.

5. The method of claim 1, wherein the method further comprises: After the signed script file and the operator library file are uploaded to the publishing platform module, the method further includes: Each resource version is configured with a visibility label by the publishing platform module, and the visibility label includes at least one of a vehicle identification code list, a geographical area where the vehicle is located, a vehicle model configuration code, and a user group identifier; When the publishing platform module receives a query request from the computing center module, all resources accessible by the vehicle are retrieved according to a vehicle identification code carried in the query request; The latest version number in the cloud is compared with the local version number carried in the query request, and only when there is a resource with a higher version number in the cloud and meeting the visibility label strategy, a response message containing a resource download address is generated.

6. The method of claim 1, wherein the method further comprises: The computing center module of the vehicle machine terminal monitors the system state, and initiates a query request to the publishing platform module when a preset trigger condition is met, and the method specifically includes: A resource update listening service is configured to maintain real-time monitoring of the vehicle machine operating system state; When a system cold start scenario is detected, that is, the vehicle ignition causes the vehicle machine operating system to complete the booting process, the query request is initiated; Or, when a system recovery from a suspended state scenario is detected, that is, the vehicle machine operating system receives a user-presented broadcast signal indicating that the system is awakened from the STR hibernation state, the query request is initiated.

7. The method of claim 1, wherein the method further comprises: The computing center module specifically includes the following steps: Calculate the SHA-256 hash digest of the downloaded file and compare it with the hash value in the metadata issued by the cloud, and if they are inconsistent, delete the file and terminate the update; After the integrity check passes, read the RSA public key pre-stored in the secure storage area when the vehicle machine is shipped and the digital signature value attached to the downloaded file; Call the asymmetric encryption algorithm library to perform the signature verification operation, and only when the signature verification returns true, confirm that the resource comes from the legitimate publishing platform module.

8. The method of Claim 7, wherein, After the computing center module performs integrity check and signature verification on the downloaded file, the method further includes: A dependency checking program is executed to decompress the script file and read the description file therein, and an operator list on which the script file depends is extracted; Scan the locally installed and verified operator set; Determine whether the operator list belongs to a subset of the locally installed and verified operator set; If a locally missing dependent operator is detected, automatically trigger a download request or a rollback update operation for the missing operator.

9. The method for dynamically issuing vehicle-to-everything (V2X) scripts using a workflow according to claim 1, characterized in that, The method specifically includes the following steps: A hybrid running environment based on the cooperation of the Java virtual machine and the Lua interpreter is constructed; When the Lua interpreter is started, a sandbox isolation strategy is configured to remove application programming interfaces in the Lua standard library related to system file operations, operating system process control, and debugging functions; Injecting a preset proxy function into a Lua global environment as a channel for calling Java operators by a Lua script; When the Lua interpreter executes a function call instruction, triggering the proxy function to find a corresponding Java class instance in a memory mapping table of an operator identifier and a Java class instance method by using the proxy function.

10. The method of claim 1, wherein the method further comprises: The execution instruction received from the business application module by the computing center module includes: The execution instruction is received by inter-process communication or an AIDL interface, and the execution instruction contains a unique identifier of a target script and a business scenario context parameter; The business scenario context parameter is converted into a Lua table structure and pushed into a stack of a Lua virtual machine; After the script file is executed, final output data of the script is captured, and the final output data is encapsulated as a response object and returned to the business application module.

Images