Cross-platform software development method and related equipment

Abstract

The invention relates to a cross-platform software development method and related equipment. The method is applied to the electronic equipment providing a low-code tool chain, and the low-code tool chain comprises a low-code development platform and a compiler. Based on the configuration of the meta model of the vehicle-mounted resource, the low-code development platform generates an automobile domain specific language VDSL file for describing the vehicle-mounted software function; the compiler obtains the VDSL file, compiles the VDSL file into running program codes running in different controllers and sends the running program codes to a cloud server, and the cloud server is used for sending the running program codes to the different controllers. According to the method and the device, the running program codes corresponding to different controllers are generated through the unified VDSL, so that cross-platform running software programs can be conveniently developed in the same platform, the software development efficiency is improved, and the development cost is reduced.

Description

Technical Field

[0001] This application relates to the field of code development technology, and in particular to a cross-platform software development method and related equipment. Background Technology

[0002] Currently, there is a need for cross-platform and cross-controller software development in the development of automotive software. However, different platforms have different development toolchains and programming languages. For example, some platform toolchains use Android Studio and Android programming languages ​​such as Java / Kotlin, while others use V++ and C / C++. Consequently, extensive communication and coordination between different systems are required during software development, resulting in low development efficiency and high development costs. Summary of the Invention

[0003] This application provides a cross-platform software development method and related equipment, aiming to improve software development efficiency and reduce development costs.

[0004] Firstly, this application provides a cross-platform software development method. The method is applied to electronic devices that provide a low-code toolchain, which includes a low-code development platform and a compiler. The method includes: based on the configuration of a meta-model of in-vehicle resources, the low-code development platform generates an automotive-specific language (VDSL) file describing the functions of the in-vehicle software; the compiler obtains the VDSL file and compiles it into runtime code that runs on different controllers; and the compiler sends the runtime code to a cloud server, whereby the cloud server distributes the runtime code to the different controllers. This application generates runtime code corresponding to different controllers using a unified VDSL language, facilitating the development of cross-platform software programs on the same platform, improving software development efficiency, and reducing development costs.

[0005] In some embodiments of this application, the generation of an automotive domain-specific language (VDSL) file describing the functions of the in-vehicle software by the low-code development platform based on the configuration of the metamodel of the in-vehicle resources includes: responding to the operation of dragging and dropping the metamodel of the in-vehicle resources from the metamodel library and the configuration operation of the metamodel of the in-vehicle resources; the designer of the low-code development platform creating objects and object data of the objects; and generating the VDSL file graphically using low-code development tools based on the object data of the objects. In this application embodiment, by visually dragging and dropping the metamodel and graphically generating the VDSL file using low-code development tools, the need for manual coding is reduced, and the development cycle of the in-vehicle system is shortened.

[0006] In some embodiments of this application, the operation of dragging and dropping the metamodel of the vehicle resource from the metamodel library and the configuration operation of the metamodel of the vehicle resource, the low-code development platform's designer creates objects and object data of the objects, including: displaying a code development interface, which includes a material area and a rendering interface; displaying the metamodel of the vehicle resource in the metamodel library through the material area; responding to the metamodel of the vehicle resource selected from the material area, displaying the selected metamodel of the vehicle resource in the object interface of the rendering interface, and creating the object according to the metamodel of the vehicle resource; and configuring the attributes of the metamodel of the vehicle resource to obtain the object data of the object. This application embodiment automatically creates corresponding objects by dragging and dropping metamodels from the material area to the rendering interface, simplifying the development process and reducing coding workload. Thus, code development is achieved through a visual interactive interface, significantly improving the usability, reliability, and efficiency of vehicle system development.

[0007] In some embodiments of this application, compiling the VDSL file into runtime code that runs on different controllers includes: compiling the VDSL file into VDSL sub-files that run on different controllers according to the operating environment of the in-vehicle software function; and compiling each VDSL sub-file into runtime code that runs on the corresponding controller. Embodiments of this application automatically generate differentiated VDSL sub-files based on the in-vehicle function's operating environment, ensuring compatibility with different hardware architectures and operating systems.

[0008] Secondly, this application also provides a cross-platform software development method applied to a cloud server. The method includes: generating a deployment program based on runtime code sent by a low-code development platform, wherein the deployment program includes a dependency table, and the dependency table includes a software version number; and sending the deployment program to different controllers on the vehicle side according to a preset deployment mechanism and the software version number. This application embodiment sends runtime code generated using a unified VDSL language to different controllers, facilitating the development of cross-platform software programs on the same platform, improving software development efficiency and reducing development costs. Simultaneously, before deploying the runtime code, the version number verifies whether the controller environment meets the operating conditions, preventing incompatible deployments.

[0009] In some embodiments of this application, the step of sending the distribution program to different controllers on the vehicle side according to a preset deployment mechanism and the software version number includes: if the distribution program is vehicle software deployed to the vehicle side for the first time, the cloud server determines that the controller where the main module is located is the first controller and determines that the controller where the sub-module is located is the second controller; the first program of the distribution program and the dependency table are sent to the first controller, and the second program of the distribution program and the dependency table are sent to the second controller, wherein the first controller verifies the software version number sent by the sub-module through the main module; and receives the verification success information sent by the first controller. In the embodiments of this application, the first controller (main controller) prioritizes the deployment and activation of the verification function of the distribution program to ensure that the distribution program of the sub-module is deployed in a trusted environment, and at the same time maintains version consistency by synchronizing between the main and sub-modules through the dependency table.

[0010] In some embodiments of this application, the method further includes: if the distributed program is in-vehicle software that is not being deployed to the vehicle for the first time, sending the first program to the first controller, and sending the second program and the dependency table to the second controller; receiving the software version number sent by the first controller; verifying the software version number sent by the first controller according to the software version number in the dependency table; if it is determined that the software version number sent by the first controller is correct, returning the verification success information to the first controller. Embodiments of this application can establish a software update trust foundation based on in-vehicle software being deployed to the vehicle for the first time, and quickly verify the distributed program through the software version number.

[0011] Thirdly, this application also provides a cross-platform software development method applied to a vehicle. The method includes: if the program sent by a cloud server is in-vehicle software deployed to the vehicle for the first time, a first controller on the vehicle receives a first program and a dependency table from the cloud server, and a second controller on the vehicle receives a second program and the dependency table from the cloud server. The first controller includes a main module, and the second controller includes a sub-module. The second controller sends the software version number in the dependency table to the first controller through the sub-module. The first controller verifies the software version number sent by the sub-module through the main module. If the software version number is correct, a verification success message is sent to the cloud server. This application embodiment sends runtime code generated using a unified VDSL language to different controllers, facilitating the development of cross-platform software programs on the same platform, improving software development efficiency and reducing development costs. Furthermore, by deploying different software programs on different controllers, flexible deployment of cross-controller software is facilitated.

[0012] In some embodiments of this application, the method further includes: if the program sent by the cloud server is in-vehicle software that is not being deployed to the vehicle for the first time, the second controller receives the second program sent by the cloud server and sends the software version number stored in the second controller to the first controller through the sub-module; the first controller receives the first program of the program sent by the cloud server and sends the received software version number to the cloud server through the main module to verify the software version number; and receives the verification success information or verification failure information sent by the cloud server. Embodiments of this application can establish a software update trust foundation based on in-vehicle software being deployed to the vehicle for the first time, and quickly verify the program through the software version number.

[0013] Fourthly, this application provides an electronic device, the electronic device including a memory and a processor: the memory is used to store program instructions; the processor is used to read and execute the program instructions stored in the memory, and when the program instructions are executed by the processor, the electronic device performs the above-described cross-platform software development method.

[0014] Fifthly, this application provides a computer storage medium storing program instructions that, when executed on an electronic device, cause the electronic device to perform the aforementioned cross-platform software development method.

[0015] Furthermore, the technical effects brought about by the second to fifth aspects can be found in the descriptions of the methods in the above-mentioned method section, and will not be repeated here. Attached Figure Description

[0016] Figure 1 This is an application environment framework diagram for a cross-platform software development method provided in some embodiments of this application.

[0017] Figure 2 This is a schematic diagram illustrating the generation of VDSL files in some embodiments of this application.

[0018] Figure 3 This is a schematic diagram of the code development interface provided for some embodiments of this application.

[0019] Figure 4 This is a schematic diagram of a dependency table provided for some embodiments of this application.

[0020] Figure 5 This is a schematic diagram illustrating the compilation of VDSL files into VDSL files that run on different controllers in some embodiments of this application.

[0021] Figure 6 This is a schematic diagram illustrating the sending of a distribution program to different controllers, provided for some embodiments of this application.

[0022] Figure 7 This is a schematic diagram illustrating the sending of a distribution program to different controllers, provided for other embodiments of this application.

[0023] Figure 8 This is a schematic diagram illustrating the cloud service delivery procedure provided in some embodiments of this application.

[0024] Figure 9 A flowchart illustrating a cross-platform software development method provided for some embodiments of this application.

[0025] Figure 10 A flowchart illustrating a cross-platform software development method provided for other embodiments of this application.

[0026] Figure 11 A flowchart illustrating a cross-platform software development method provided for other embodiments of this application.

[0027] Figure 12 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0028] To make the technical problems, technical solutions, and beneficial effects solved by this application clearer, the following detailed description is provided in conjunction with embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0029] Currently, there is a need for cross-platform and cross-controller software development in the development of automotive software. However, different platforms have different development toolchains and programming languages. For example, some platform toolchains use Android Studio and Android programming languages ​​such as Java / Kotlin, while others use V++ and C / C++. Consequently, extensive communication and coordination between different systems are required during software development, resulting in low development efficiency and high development costs.

[0030] To address the aforementioned technical problems, this application provides a cross-platform software development method. The method is based on a Vehicle Domain-Specific Language (VDSL) and generates programs that run on different controllers across the vehicle based on in-vehicle resources. It generates a VDSL file describing the program, compiles the VDSL file into runtime code for different controllers on the vehicle, and sends the runtime code to a cloud service. The cloud service then sends the runtime code to the corresponding controller for execution. Thus, this application generates runtime code for different controllers using a unified VDSL language, facilitating the development of cross-platform software programs on the same platform, improving software development efficiency, and reducing development costs.

[0031] refer to Figure 1 The diagram illustrates the application environment framework of a cross-platform software development method provided in some embodiments of this application. The method is applied in a low-code toolchain 1, a cloud server 2, and a vehicle-side component 3. In some embodiments of this application, the low-code toolchain 1 includes a low-code development platform and a compiler. The cloud server includes cloud services. The vehicle-side component 3 includes multiple controllers. These controllers include one or more of the following: an Intelligent Driving Computer (IDC), a Central Computing Unit (CCU), a Microcontroller Unit (MCU), and a Zone Control Unit (ZCU). In some embodiments of this application, the Intelligent Driving Computer is an onboard high-performance computing unit (such as an autonomous driving domain controller) used to process sensor data (image data, radar data, etc.) and control the vehicle to execute preset algorithms (such as perception, decision-making, and planning algorithms). The Central Computing Unit is an onboard high-performance computing platform used to integrate multiple domain controllers (such as autonomous driving, intelligent cockpit, and body control) to centralize the vehicle's electronic and electrical architecture. The Microcontroller Unit is an embedded chip integrating a CPU, memory, and peripheral interfaces, used for real-time control of the vehicle's electronic systems.

[0032] In some embodiments of this application, the meta-model of in-vehicle resources in vehicle terminal 3 is imported into a low-code development platform. The low-code development platform generates programs that run on different controllers across the vehicle terminal based on the meta-model of in-vehicle resources, and generates a VDSL file describing the programs. In some embodiments of this application, the meta-model of in-vehicle resources is an intermediate transformation description obtained by describing the data of in-vehicle resources using the VDSL language. The meta-model of in-vehicle resources in this application includes in-vehicle resources in different controllers or platforms of vehicle terminal 3. Obtaining the meta-model of in-vehicle resources by describing them using a unified VDSL language facilitates the development of cross-platform in-vehicle software programs on the same platform (such as a low-code development platform).

[0033] refer to Figure 2 The diagram illustrates the generation of VDSL files in some embodiments of this application. In some embodiments of this application, the meta-model of in-vehicle resources in vehicle terminal 3 is imported into a low-code development platform. The low-code development platform generates programs that run across different controllers on the vehicle terminal based on the meta-model of in-vehicle resources, and generates VDSL files describing the programs. In some embodiments of this application, the meta-model of in-vehicle resources is an intermediate transformation description obtained by describing the data of in-vehicle resources using the VDSL language. The low-code development platform generates VDSL files describing the functions of in-vehicle software in response to drag-and-drop operations and configuration operations of the meta-model of in-vehicle resources by developers.

[0034] In some embodiments of this application, a JSON-based structured VDSL is used to describe the operating environment, operating parameters, invocation methods, and initialization methods of in-vehicle resources. In embodiments of this application, when dragging and dropping or configuring the metamodel of in-vehicle resources, the resources can be combined and assembled into a VDSL file describing a specific function.

[0035] In some embodiments of this application, in-vehicle resources include, but are not limited to, in-vehicle signals, services, algorithms, network topology, UI controls, and events. In-vehicle signals include, but are not limited to, vehicle speed, accelerator pedal position, window lifting status, and interior temperature. Services include, but are not limited to, diagnostic services, power management services, navigation services, and voice interaction services. Algorithms include, but are not limited to, object detection algorithms, lane detection algorithms, and path planning algorithms. Network topology includes, but is not limited to, distributed architecture and domain-centralized architecture. UI controls include, but are not limited to, buttons, sliders, and icons. Events include, but are not limited to, user-triggered events, system events, and network events. For example, user-triggered events may include electrical center screen events and voice command events. System events may include airbag trigger signals and battery level below 10% warning signals. Network events may include Bluetooth device disconnection events.

[0036] In some embodiments of this application, the metamodel of the vehicle resources is stored in the metamodel library of the low-code development platform. In response to user operations such as dragging and dropping metamodels of vehicle resources from the metamodel library and configuring the metamodels of vehicle resources, the low-code development platform uses a designer to create objects and object data of those objects; based on the object data, it uses low-code development tools to graphically generate VDSL files.

[0037] In some embodiments of this application, the designer of the low-code development platform creates objects and object data based on the metamodel of in-vehicle resources. The designer can configure the object data through the code development interface. In some embodiments of this application, configuring object data includes attribute configuration, data binding, data source management, and event binding.

[0038] refer to Figure 3 As shown in (a), the designer displays a code development interface 40, which includes a material area 41 and a rendering interface 42. The material area 41 is used to display the metamodels of in-vehicle resources in the metamodel library. The rendering interface 42 is used to display the object interface 421 of user-created objects. In some embodiments of this application, the object can be in-vehicle software (e.g., a music application) or an in-vehicle functional module (e.g., a voice control module).

[0039] In some embodiments of this application, the designer responds to a user's selection of a metamodel (such as a UI control) of an in-vehicle resource from the material area 41, displaying the metamodel of the selected in-vehicle resource in the object interface 421. In some embodiments of this application, the user can select the metamodel of the in-vehicle resource from the material area 41 via drag-and-drop operations. For example, refer to... Figure 3 (b) The user drags the metamodel of the vehicle resource from the material area 41 to the object interface 421. The designer can display the metamodel of the vehicle resource on the object interface 421 and create the object based on the metamodel of the vehicle resource.

[0040] In some embodiments of this application, after the metamodel is displayed on the object interface 421, the designer can also configure the attributes of the metamodel to obtain the object data of the object. (See reference...) Figure 3 (c) If the user performs an editing operation on the metamodel on the object interface 421, for example, after the user clicks on the metamodel on the object interface 421, the designer displays the settings interface 43 on the object interface 421. The user can set the properties of the metamodel through the settings interface 43, and the designer generates the object data of the object based on the properties configured by the user for the metamodel.

[0041] In some embodiments of this application, the low-code development tool of the low-code development platform maps the object data of an object to a VDSL file of the low-code platform. In some embodiments of this application, the VDSL file is used to describe the business logic, data model, and interaction rules of the object. In some embodiments of this application, the low-code development tool is a VDSL parser.

[0042] In some embodiments of this application, the compiler obtains the VDSL file from the low-code development platform, compiles the VDSL file into runtime code that runs on different controllers, and sends the runtime code to the cloud service in cloud server 2. In some embodiments of this application, the controller's runtime code includes functional logic code, communication information, and a dependency table. The functional logic code is the runtime functional logic of the corresponding controller; for example, the functional logic code can be a script or program running in the corresponding controller. The communication information is used to represent the communication code between the corresponding controller and other controllers or platforms. The dependency table is used to record the software version dependencies of the controller with other controllers or platforms. When the software version of other controllers or platforms does not meet the requirements, the dependent software version needs to be updated. In some embodiments of this application, the controller's main module is used to store the dependency table. (See reference...) Figure 4 The diagram shown illustrates a dependency table provided in some embodiments of this application. The dependency table includes a target dependency controller, dependent modules, version information, and verification information. The target dependency controller represents the controller to which the dependency table belongs; for example, the target dependency controller can be an IDC, CCU, or MCU. The dependent module represents the module that the controller depends on. The version information represents the software version number of the module that the controller depends on.

[0043] refer to Figure 5 The diagram illustrates how a VDSL file is compiled into VDSL files that run on different controllers in some embodiments of this application. In some embodiments of this application, the compiler compiles the VDSL file into VDSL sub-files that run on different controllers based on the operating environment of the in-vehicle software functions; and compiles each VDSL sub-file into runtime code that runs on the corresponding controller. For example, VDSL files running on different controllers include, but are not limited to, VDSL files running on the IDC and VDSL files running on the CCU.

[0044] In some embodiments of this application, the compiler uses the compiler's lexical / syntactic analyzer to generate an abstract syntax tree (AST) from the VDSL source code in the VDSL file running on different controllers, uses a semantic analyzer to generate an intermediate representation (IR) from the AST, and uses a target platform code generator to generate runtime code running on different controllers from the intermediate representation based on platform adaptation information.

[0045] In some embodiments of this application, the compiler sends the generated runtime code running on different controllers to the cloud service. The cloud service then sends the runtime code for different controllers to the corresponding controllers, or waits for the vehicle to request the runtime code.

[0046] In some embodiments of this application, the cloud service generates a deployment program based on the runtime code of different controllers, wherein the deployment program includes a dependency table; and sends the deployment program to different controllers according to a preset deployment mechanism and the dependency table. (See reference) Figure 6 As shown, if the deployed program is the first time the vehicle software is deployed to the vehicle, the controller where the main module is located is determined to be the first controller and the controller where the sub-module is located is determined to be the second controller. The first program and dependency table of the deployed program are sent to the first controller on the vehicle, and the second program and dependency table of the deployed program are sent to the second controller on the vehicle. The sub-module in the second controller sends the software version number in the dependency table to the first controller. The main module of the first controller verifies the software version number sent by the sub-module according to the software version number in the dependency table. If it is determined that the software version number sent by the sub-module is correct, it returns a verification success message to the cloud server.

[0047] refer to Figure 7 As shown, if the deployed program is in-vehicle software that is not being deployed to the vehicle for the first time and the deployed program is an update to some software functions of the in-vehicle software, or if the deployed program is in-vehicle software that is not being deployed to the vehicle for the first time, the second program of the deployed program is sent to the controller where the sub-module is located on the vehicle (i.e., the second controller), and the first program of the deployed program is sent to the controller where the main module is located on the vehicle (i.e., the first controller); the sub-module in the second controller sends the software version number stored in the dependency table in the second controller to the first controller; the first controller sends the received software version number to the cloud server to verify the software version number; the cloud server verifies the software version number sent by the main module according to the software version number in the dependency table stored in the cloud server; if it is determined that the software version number sent by the main module is correct, it returns a verification success message to the first controller.

[0048] In some embodiments of this application, the first program includes a dynamic library, and the second program includes a script. A dynamic library represents a pre-compiled executable code module that supports runtime loading and is used to extend vehicle-side functionality, such as algorithmic functions and driving functions. The cloud service sends the dynamic library and script to the low-code engines of different controllers for execution. A low-code engine represents a runtime environment that supports rapid application development through configuration or simple scripts.

[0049] The following example illustrates the specific implementation details of the cloud service's delivery program, using the scenario where the IDC needs to update or add features (such as sensing algorithms and control strategies), and the CCU needs to adjust business logic (such as human-computer interaction and diagnostic rules). (Reference) Figure 8 The diagram illustrates a cloud service delivery procedure provided in some embodiments of this application. The cloud service delivers the compiled dynamic library to the vehicle-side data center (IDC) via over-the-air (OTA) download or a dedicated channel. The IDC's low-code engine loads the dynamic library. The cloud service then delivers the script to the vehicle control unit (CCU), where the CCU's low-code engine executes the script.

[0050] In some embodiments of this application, the low-code engine of the IDC loads dynamic libraries using a binary file execution method. The low-code engine of the CCU executes scripts using a script parsing method. In some embodiments of this application, the vehicle-side controller also includes a Service-Oriented Architecture Service (SOA service). For example, the SOA service of the IDC represents a service-oriented functional module (such as perception, planning, and control services) running on the intelligent driving controller, which is called by other controllers (such as the ZCU) through a service interface. The IDC's low-code engine dynamically loads dynamic libraries to implement the functionality of the IDC's SOA service. The CCU's low-code engine executes scripts to implement the CCU's SOA service functionality.

[0051] In this embodiment of the application, the cloud service enables dynamic updates or expansions of vehicle-side functions by sending dynamic libraries and scripts to the IDC and CCU.

[0052] The following is based on Figure 1 The application environment framework diagram shown illustrates the cross-platform software development method provided in the embodiments of this application. (Reference) Figure 9 The diagram shown is a flowchart of a cross-platform software development method provided in some embodiments of this application. The method is applied in electronic devices that provide low-code toolchains. Figure 9 The example method includes one or more steps, but does not constitute a limitation of this application. Furthermore, the order of the steps in the method is merely illustrative and may be changed. Additional steps may be added or steps may be removed without departing from the disclosure of this application. The method includes the following steps.

[0053] In step S901, based on the configuration of the meta-model of the vehicle resources, the low-code development platform generates a VDSL file describing the functions of the vehicle software.

[0054] In some embodiments of this application, the metamodel of in-vehicle resources is an intermediate transformation description obtained by describing the data of in-vehicle resources using the VDSL language. In some embodiments of this application, the intermediate transformation description is obtained by using VDSL in a JSON-based structured format to describe the operating environment, operating parameters, calling methods, and initialization methods of in-vehicle resources. In the embodiments of this application, when performing drag-and-drop operations and configuration operations on the metamodel of in-vehicle resources, the in-vehicle resources can be combined and assembled into a VDSL file describing a specific function.

[0055] In some embodiments of this application, the metamodel of in-vehicle resources is stored in the metamodel library of a low-code development platform. The generation of a VDSL file describing the functions of in-vehicle software by the low-code development platform based on the configuration of the metamodel of the in-vehicle resources includes: responding to operations such as dragging and dropping metamodels of in-vehicle resources from the metamodel library and configuring the metamodels of the in-vehicle resources; the designer of the low-code development platform creating objects and object data of the objects; and graphically generating a VDSL file using low-code development tools based on the object data of the objects.

[0056] refer to Figure 3 As shown in (a), the designer displays a code development interface 40, which includes a material area 41 and a rendering interface 42. The material area 41 is used to display the metamodels of in-vehicle resources in the metamodel library. The rendering interface 42 is used to display the object interface 421 of user-created objects. In some embodiments of this application, the object can be in-vehicle software (e.g., a music application) or an in-vehicle functional module (e.g., a voice control module).

[0057] In some embodiments of this application, the designer responds to a user's selection of a metamodel (such as a UI control) of an in-vehicle resource from the material area 41, displaying the metamodel of the selected in-vehicle resource in the object interface 421. In some embodiments of this application, the user can select the metamodel of the in-vehicle resource from the material area 41 via drag-and-drop operations. For example, refer to... Figure 3 (b) The user drags the metamodel of the vehicle resource from the material area 41 to the object interface 421. The designer can display the metamodel of the vehicle resource on the object interface 421 and create the object based on the metamodel of the vehicle resource.

[0058] In some embodiments of this application, after the metamodel is displayed on the object interface 421, the designer can also configure the attributes of the metamodel to obtain the object data of the object. (See reference...) Figure 3(c) If the user performs an editing operation on the metamodel on the object interface 421, for example, after the user clicks on the metamodel on the object interface 421, the designer displays the settings interface 43 on the object interface 421. The user can set the properties of the metamodel through the settings interface 43, and the designer generates the object data of the object based on the properties configured by the user for the metamodel.

[0059] In some embodiments of this application, the low-code development tools of the low-code development platform map the object data of an object to a VDSL file of the low-code platform.

[0060] In step S902, the compiler obtains the VDSL file, compiles the VDSL file into runtime code that runs on different controllers, and sends the runtime code to the cloud server.

[0061] In some embodiments of this application, the runtime code of the vehicle-side controller includes functional logic code, communication information, and a dependency table. The functional logic code represents the runtime logic of the corresponding controller; for example, it can be a script or program running within the corresponding controller. The communication information indicates the communication code between the corresponding controller and other controllers or platforms. The dependency table records the software version dependencies between the controller and other controllers or platforms. In some embodiments of this application, the controller's main module stores the dependency table.

[0062] In some embodiments of this application, compiling a VDSL file into runtime code that runs on different controllers includes: the compiler compiling the VDSL file into VDSL sub-files that run on different controllers according to the operating environment of the vehicle software functions; and compiling each VDSL sub-file into runtime code that runs on the corresponding controller.

[0063] Specifically, the compiler uses the compiler's lexical / syntactic analyzer to generate an abstract syntax tree (AST) from the VDSL source code in the VDSL files running on different controllers. It then uses a semantic analyzer to generate an intermediate representation (IR) from the AST. Finally, it uses a target platform code generator to generate runtime code for different controllers from the intermediate representation based on platform adaptation information.

[0064] In some embodiments of this application, the compiler sends the generated runtime code running on different controllers to the cloud service. The cloud service then sends the runtime code for different controllers to the corresponding controllers, or waits for the vehicle to request the runtime code.

[0065] In some embodiments of this application, the method further includes: importing the metamodel of in-vehicle resources in the vehicle into a low-code development platform.

[0066] refer to Figure 10 The diagram shown is a flowchart of a cross-platform software development method provided in some embodiments of this application. The method is applied in a cloud server. Figure 10 The example method includes one or more steps, but does not constitute a limitation of this application. Furthermore, the order of the steps in the method is merely illustrative and may be changed. Additional steps may be added or steps may be removed without departing from the disclosure of this application. The method includes the following steps.

[0067] Step S1001: Generate a distribution program based on the runtime program code sent by the low-code development platform, wherein the distribution program includes a dependency table, and the dependency table includes a software version number.

[0068] Step S1002: The distribution program is sent to different controllers on the vehicle according to the preset deployment mechanism and the software version number.

[0069] The cloud service in the cloud server determines that the controller where the main module is located is the first controller and the controller where the sub-module is located is the second controller; if the program being deployed is in-vehicle software being deployed to the vehicle for the first time, the first program and dependency table of the program being deployed are sent to the first controller, and the second program and dependency table of the program being deployed are sent to the second controller, and the verification success information sent by the first controller is received.

[0070] In some embodiments of this application, the sub-module in the second controller sends the software version number in the stored dependency table to the first controller. The main module of the first controller verifies the software version number sent by the sub-module according to the software version number in the dependency table. If it is determined that the software version number sent by the sub-module is correct, it returns a verification success message to the cloud server.

[0071] If the downloaded program is in-vehicle software that has not been deployed to the vehicle for the first time and the downloaded program updates some of the software functions of the in-vehicle software, or if the downloaded program is in-vehicle software that has not been deployed to the vehicle for the first time, the cloud service will send the second program of the downloaded program to the second controller and the first program of the downloaded program to the first controller; receive the software version number sent by the first controller; verify the software version number sent by the main module according to the software version number in the dependency table stored in the cloud server; if it is determined that the software version number sent by the main module is correct, return a verification success message to the first controller.

[0072] In some embodiments of this application, the sub-module in the second controller sends the software version number in the distribution program to the controller where the main module is located (i.e., the first controller); the first controller sends the software version number to the cloud service of the cloud server to realize the verification of the software version number by the cloud service.

[0073] refer to Figure 11The diagram shown is a flowchart of a cross-platform software development method provided in some embodiments of this application. The method is applied in a vehicle. Figure 11 The example method includes one or more steps, but does not constitute a limitation of this application. Furthermore, the order of the steps in the method is merely illustrative and may be changed. Additional steps may be added or steps may be removed without departing from the disclosure of this application. The method includes the following steps.

[0074] Step S1101: Determine whether the program sent by the cloud server is the first time the vehicle software is deployed to the vehicle. If the program is the first time the vehicle software is deployed to the vehicle, proceed to step S1102; if the program is not the first time the vehicle software is deployed to the vehicle, proceed to step S1107.

[0075] In step S1102, the first controller on the vehicle receives the first program and dependency table of the downloaded program sent by the cloud server, and the second controller on the vehicle receives the second program and dependency table of the downloaded program sent by the cloud server. The first controller includes a main module, and the second controller includes a sub-module.

[0076] In step S1103, the sub-module in the second controller sends the software version number in the dependency table to the first controller.

[0077] In step S1104, the main module of the first controller determines whether the software version number sent by the sub-module is correct. If the software version number sent by the sub-module is correct, proceed to step S1105; if the software version number sent by the sub-module is incorrect, proceed to step S1106.

[0078] In some embodiments of this application, the main module of the first controller verifies the software version number sent by the sub-module based on the software version number in the dependency table. If the software version number sent by the sub-module is consistent with the software version number stored in the main module, the software version number sent by the sub-module is determined to be correct; if the software version number sent by the sub-module is inconsistent with the software version number stored in the main module, the software version number sent by the sub-module is determined to be incorrect.

[0079] Step S1105: Return verification success information to the cloud server.

[0080] Step S1106: Return verification failure information to the cloud server.

[0081] In step S1107, the second controller receives the second program of the downloaded program sent by the cloud server, and sends the software version number stored in the second controller to the first controller through the sub-module.

[0082] In step S1108, the first controller receives the first program of the download program sent by the cloud server and the software version number sent by the second controller, and sends the received software version number to the cloud server through the main module to verify the software version number.

[0083] Step S1109: Receive verification success information or verification failure information sent by the cloud server.

[0084] In some embodiments of this application, the cloud service in the cloud server verifies the software version number sent by the main module based on the software version number in the dependency table stored in the cloud server; if it is determined that the software version number sent by the main module is correct, it returns a verification success message to the first controller; if it is determined that the software version number sent by the main module is incorrect, it returns a verification failure message to the first controller.

[0085] In some embodiments of this application, the method further includes: the low-code engine of the first controller executing a first program, and the low-code engine of the second controller executing a second program.

[0086] In some embodiments of this application, the first program of the delivery program may include a dynamic library, and the second program includes a script. In some embodiments of this application, the first controller downloads the dynamic library via OTA or a dedicated channel, and the IDC's low-code engine dynamically loads the dynamic library to implement the IDC's SOA service functionality. The second controller downloads the script via OTA or a dedicated channel, and the CCU's low-code engine executes the script to implement the CCU's SOA service functionality.

[0087] In some embodiments of this application, the method further includes providing onboard resources to a low-code toolchain.

[0088] This application generates programs that run on different controllers across the vehicle based on in-vehicle resources; generates a VDSL file describing the program, compiles the VDSL file into runtime code for different controllers running on the vehicle, and sends the runtime code to a cloud service; the cloud service sends the runtime code to the corresponding controller for execution. Thus, this application generates runtime code for different controllers using a unified VDSL language, which facilitates the development of cross-platform software programs on the same platform, improving software development efficiency and reducing development costs.

[0089] refer to Figure 12 The diagram shown is a structural schematic of an electronic device provided in some embodiments of this application.

[0090] In one embodiment of this application, the electronic device 200 includes, but is not limited to, a storage device 21, a processing device 22, and a computer program, such as a cross-platform software development program, stored in the storage device 21 and executable on the processing device 22.

[0091] In one embodiment of this application, the electronic device 200 is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored computer-readable instructions. Its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.

[0092] The electronic device 200 can be an electronic device that carries a low-code development toolchain, such as a personal computer, desktop computer, smartphone, or cloud development terminal, or it can be a server, vehicle-mounted device, etc.

[0093] The electronic device 200 may include network devices and / or user devices. The network devices include, but are not limited to, a single network electronic device, a group of multiple network electronic devices, or a cloud based on cloud computing consisting of a large number of hosts or network electronic devices. This application does not limit the scope of the electronic devices.

[0094] The network in which the electronic device 200 is located includes, but is not limited to: the Internet, wide area network, metropolitan area network, local area network, virtual private network (VPN), etc.

[0095] Those skilled in the art will understand that the schematic diagram is merely an example of the electronic device 200 and does not constitute a limitation on the electronic device 200. It may include more or fewer components than shown, or combine certain components, or different components. For example, the electronic device 200 may also include input / output devices, network access devices, buses, etc.

[0096] The processing device 22 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor. The processing device 22 is the computing core and control center of the electronic device 200, connecting various parts of the electronic device 200 through various interfaces and lines, and obtaining the operating system of the electronic device 200 and various installed applications and program code.

[0097] The processing device 22 acquires the operating system and various installed applications of the electronic device 200. The processing device 22 acquires these applications to implement the steps in the above-described cross-platform software development method embodiment, for example... Figure 9-11 .

[0098] For example, the computer program may be divided into one or more modules / units, which are stored in the storage device 21 and retrieved by the processing device 22 to complete this application. The one or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the process of retrieving the computer program from the electronic device 200.

[0099] The storage device 21 can be used to store the computer programs and / or modules. The processing device 22 implements various functions of the electronic device 200 by running or retrieving the computer programs and / or modules stored in the storage device 21 and by calling the data stored in the storage device 21. The storage device 21 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the electronic device 200, etc. In addition, the storage device 21 may include non-volatile memory, such as hard disk, memory, plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, at least one disk storage device, flash memory device, or other non-volatile solid-state storage device.

[0100] The storage device 21 may be an external memory and / or an internal memory of the electronic device 200. Further, the storage device 21 may be a physical memory, such as a memory module, a TF card (Trans-flash Card), etc.

[0101] If the modules / units integrated in the electronic device 200 are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when the computer program is acquired by a processor, it can implement the steps of the various method embodiments described above.

[0102] The computer program includes computer program code, which may be in the form of source code, object code, accessible file, or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, and read-only memory (ROM).

[0103] Specifically, the specific implementation method of the above instructions by the processing device 22 can be referred to Figure 2 The descriptions of the relevant steps in the corresponding embodiments are not repeated here.

[0104] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and other division methods may be used in actual implementation.

[0105] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0106] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in the form of hardware plus software functional modules.

[0107] Therefore, the embodiments should be considered exemplary and non-limiting in all respects, and the scope of this application is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be embraced within this application. No appended diagram markings in the claims should be construed as limiting the scope of the claims.

[0108] Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices described in this application may also be implemented by a single unit or device through software or hardware. The terms "first," "second," etc., are used to indicate names and do not indicate any specific order.

[0109] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application and are not intended to limit it. Although this application has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of this application without departing from the spirit and scope of the technical solutions of this application.

Claims

1. A cross-platform software development method, characterized in that, The method is applied to electronic devices that provide low-code toolchains, the low-code toolchains including low-code development platforms and compilers, and the method includes: Based on the configuration of the meta-model of in-vehicle resources, the low-code development platform generates automotive domain-specific language VDSL files that describe the functions of in-vehicle software. The compiler obtains the VDSL file, compiles the VDSL file into runtime code that runs on different controllers, and sends the runtime code to the cloud server, which is used to send the runtime code to the different controllers.

2. The cross-platform software development method as described in claim 1, characterized in that, Based on the configuration of the meta-model of in-vehicle resources, the low-code development platform generates automotive-specific language (VDSL) files describing the functions of in-vehicle software, including: In response to operations such as dragging and dropping metamodels of the vehicle resources from the metamodel library and configuring the metamodels of the vehicle resources, the designer of the low-code development platform creates objects and object data of the objects. Based on the object data of the object, the VDSL file is graphically generated using low-code development tools.

3. The cross-platform software development method as described in claim 2, characterized in that, The response includes operations such as dragging and dropping the metamodel of the vehicle resource from the metamodel library and configuring the metamodel of the vehicle resource. The low-code development platform's designer creates objects and the object data of those objects. The code development interface is displayed, which includes a material area and a rendering interface. The material area displays the meta-models of the vehicle resources in the meta-model library; In response to the metamodel of the vehicle resource selected from the material area, the metamodel of the selected vehicle resource is displayed in the object interface of the rendering interface, and the object is created based on the metamodel of the vehicle resource. The object data of the object is obtained by configuring the attributes of the metamodel of the vehicle resources.

4. The cross-platform software development method as described in claim 1, characterized in that, The process of compiling the VDSL file into runtime code that runs on different controllers includes: Based on the operating environment of the vehicle software functions, the VDSL file is compiled into VDSL sub-files that run on different controllers; and Each VDSL subfile is compiled into runtime code that runs on the corresponding controller.

5. A cross-platform software development method, characterized in that, The method is applied to a cloud server, and the method includes: A distribution program is generated based on the runtime program code sent by the low-code development platform, wherein the distribution program includes a dependency table, and the dependency table includes a software version number; The program is sent to different controllers on the vehicle according to the preset deployment mechanism and the software version number.

6. The cross-platform software development method as described in claim 5, characterized in that, The step of sending the distribution program to different controllers on the vehicle according to the preset deployment mechanism and the software version number includes: If the program being distributed is in-vehicle software being deployed to the vehicle for the first time, the cloud server determines that the controller where the main module is located is the first controller and determines that the controller where the sub-module is located is the second controller; The first program of the distribution program and the dependency table are sent to the first controller, and the second program of the distribution program and the dependency table are sent to the second controller, wherein the first controller verifies the software version number sent by the sub-module through the main module; Receive the verification success message sent by the first controller.

7. The cross-platform software development method as described in claim 6, characterized in that, The method further includes: If the program being distributed is in-vehicle software that is not being deployed to the vehicle for the first time, the first program is sent to the first controller, and the second program and the dependency table are sent to the second controller. Receive the software version number sent by the first controller; The software version number sent by the first controller is verified based on the software version number in the dependency table; If it is determined that the software version number sent by the first controller is correct, then the verification success information is returned to the first controller.

8. A cross-platform software development method, characterized in that, The method is applied to the vehicle end, and the method includes: If the program sent by the cloud server is the vehicle software deployed to the vehicle for the first time, the first controller of the vehicle receives the first program and dependency table of the program sent by the cloud server, and the second controller of the vehicle receives the second program and dependency table of the program sent by the cloud server, wherein the first controller includes a main module and the second controller includes a sub-module. The second controller sends the software version number in the dependency table to the first controller through the sub-module; The first controller verifies the software version number sent by the sub-module through the main module; If the software version number is confirmed to be correct, a verification success message is sent to the cloud server.

9. The cross-platform software development method as described in claim 8, characterized in that, The method further includes: If the program sent by the cloud server is not the first time the vehicle software has been deployed to the vehicle, the second controller receives the second program sent by the cloud server and sends the software version number stored in the second controller to the first controller through the sub-module; The first controller receives the first program of the downloaded program sent by the cloud server, and sends the received software version number to the cloud server through the main module to verify the software version number; Receive the verification success message or verification failure message sent by the cloud server.

10. An electronic device, characterized in that, The electronic device includes a memory and a processor: The memory is used to store program instructions; The processor is configured to read and execute the program instructions stored in the memory, and when the program instructions are executed by the processor, cause the electronic device to perform the cross-platform software development method as described in any one of claims 1 to 9.

11. A computer storage medium, characterized in that, The computer storage medium stores program instructions that, when executed on an electronic device, cause the electronic device to perform the cross-platform software development method as described in any one of claims 1 to 9.

Images