Code file generation method and device, equipment, vehicle, medium and product

Abstract

The present disclosure relates to the technical field of vehicles, and particularly relates to a code file generation method and device, equipment, vehicle, medium and product. The method comprises: obtaining parameter type information and first data of a to-be-converted vehicle parameter; wherein the first data is a parameter value of the to-be-converted vehicle parameter in a first code file, and the type of the first code file is a service-oriented architecture side code file or a model design development platform side code file; converting the first data into second data based on the parameter type information and a second code file; wherein the type of the second code file is a model design development platform side code file or a service-oriented architecture side code file, and the type of the second code file is different from that of the first code file; and storing the second data into the second code file to generate a target code file. The present application can solve the problems of low conversion efficiency between model design development platform side code and service-oriented architecture side code and low integration efficiency between models and service frameworks.

Description

Technical Field

[0001] This disclosure relates to the field of vehicle technology, and more particularly to a method, apparatus, device, vehicle, medium, and product for generating code files. Background Technology

[0002] In the field of automotive electronic control development, Matlab / Simulink is a model-based design and development platform (MBD) that uses graphical modeling to design vehicle control algorithms. It can automatically generate C++ engineering code from models, making it a standard solution for in-vehicle algorithm development. Currently, automotive electronic architecture is fully shifting towards software-defined vehicles, with Service-Oriented Architecture (SOA) becoming the mainstream solution for in-vehicle software development. SOA relies on Scalable Service-Oriented Middleware over IP (SOME / IP) communication protocols to break down the hardware functions of the Electronic Control Unit (ECU) into standardized service interfaces, weakening hardware-software binding and improving the iteration and expansion capabilities of the entire vehicle software. However, SOA interface definitions include complex data types such as fixed-length arrays, variable-length arrays, and strings. Simulink's native service interface modules cannot directly support these three types, creating a data type mapping barrier between MBD code and SOA code, hindering the one-click conversion of models into integrable in-vehicle service code.

[0003] In related technologies, SOA service interfaces are typically defined using only the basic data types natively supported by Simulink, avoiding complex types such as arrays and strings. This approach significantly limits the freedom of SOA interface design, requiring manual decomposition of complex data and manual writing of bidirectional conversion code. This results in a large workload for development, low efficiency in the conversion between MBD code and SOA code, and low integration efficiency between the model and service framework, making it difficult to adapt to the current rapid development needs of large-scale SOA software for the entire vehicle. Summary of the Invention

[0004] To address the aforementioned technical problems, this disclosure provides a method, apparatus, device, vehicle, medium, and product for generating code files, thereby resolving the issue of low conversion efficiency between MBD code and SOA code.

[0005] In a first aspect, this disclosure provides a method for generating a code file, the method comprising: obtaining parameter type information of the vehicle parameters to be converted and first data; wherein, the first data is the parameter value of the vehicle parameters to be converted in a first code file, and the type of the first code file is a service-oriented architecture side code file or a model design and development platform side code file; converting the first data into second data based on the parameter type information and a second code file; wherein, the type of the second code file is a model design and development platform side code file or a service-oriented architecture side code file, and the type of the second code file is different from that of the first code file; storing the second data in the second code file to generate a target code file.

[0006] In one optional implementation, the parameter type information includes the parameter name of the vehicle parameter to be converted; obtaining the first data includes: querying the first code segment corresponding to the parameter name in the first code file based on the parameter name; querying the data corresponding to the first preset field in the first code segment to obtain the first data.

[0007] In one optional implementation, the parameter type information further includes the parameter type and parameter length of the vehicle parameter to be converted; based on the parameter type information and the second code file, converting the first data into the second data includes: when the parameter type of the vehicle parameter to be converted is a fixed-length array type, querying the second code segment corresponding to the parameter name in the second code file based on the parameter name; querying the data corresponding to the second preset field in the second code segment to obtain the reserved storage space corresponding to the vehicle parameter to be converted, the reserved storage space being used to indicate the storage space pre-allocated in the second code file for the vehicle parameter to be converted; if the parameter length matches the reserved storage space, then the first data is determined as the second data.

[0008] In one optional implementation, based on parameter type information and a second code file, the first data is converted into the second data, including: when the type of the first code file is a service-oriented architecture side code file and the parameter type is a preset type, obtaining the array member dimension of the vehicle parameters to be converted on the model design and development platform side, the preset type being a variable-length array type or a string type; if the parameter length is greater than the array member dimension, then a first number of data elements are determined as the second data; wherein, the first number of data elements is the first number of data extracted from the first data starting from the starting position, and the first number is consistent with the array member dimension; if the parameter length is less than or equal to the array member dimension, then the first data is determined as the second data.

[0009] In one optional implementation, based on parameter type information and a second code file, the first data is converted into the second data, including: when the first code file is a code file on the model design and development platform side and the parameter type is a preset type, obtaining the array member dimension and effective length variable value of the vehicle parameter to be converted on the model design and development platform side, the preset type is a variable-length array type or a string type, and the effective length variable value is used to indicate the number of bytes occupied by the actual effective data of the vehicle parameter to be converted on the model design and development platform side; if the effective length variable value is greater than the array member dimension, then the first data is determined as the second data; if the effective length variable value is less than or equal to the array member dimension, then a third number of data elements are determined as the second data, the third number of data elements is the third number of data extracted from the first data starting from the starting position, and the third number is consistent with the effective length variable value.

[0010] In one optional implementation, the method further includes: obtaining a service interface configuration file, which describes the metadata information of the vehicle parameters corresponding to each of the multiple vehicle service interfaces; generating a model design and development platform-side structure corresponding to each vehicle parameter based on the service interface configuration file; and generating model design and development platform-side code files corresponding to the multiple vehicle service interfaces based on the model design and development platform-side structure.

[0011] In one optional implementation, the metadata information includes parameter data, parameter type, basic data type, and preset length information for each vehicle parameter. Based on the service interface configuration file, a model design and development platform-side structure corresponding to each vehicle parameter is generated, including: when the parameter type of the first vehicle parameter is a fixed-length array type, and the preset length information is a preset array member dimension, a first structure is constructed according to the parameter data of the first vehicle parameter. The first structure includes a first array member variable, which is used to store parameter data. The array member dimension of the first array member variable is consistent with the preset array member dimension, and the data type of the first array member variable matches the basic data type. The first vehicle parameter is any one of multiple vehicle parameters. When the parameter type of the first vehicle parameter is a variable-length array type, and the preset length information is... When the maximum storage length is preset in the service interface configuration file, a second structure is constructed based on the parameter data of the first vehicle parameter. The second structure includes a second array member variable and a first effective length variable. The array member dimension of the second array member variable is the maximum storage length, and the first effective length variable is used to represent the effective length of the array member variable. When the parameter type of the first vehicle parameter is string, and the preset length information is the maximum string length preset in the service interface configuration file, a third structure is constructed based on the parameter data of the first vehicle parameter. The third structure includes a third array member variable and a second effective length variable. The array member dimension of the third array member variable is the maximum string length, the data type of the third array member variable is character, and the second effective length variable is used to record the actual effective character length of the string.

[0012] Secondly, the present invention provides a code file generation apparatus, comprising: an acquisition module for acquiring parameter type information of vehicle parameters to be converted and first data; wherein the first data is the parameter value of the vehicle parameters to be converted in a first code file, and the type of the first code file is a service-oriented architecture side code file or a model design and development platform side code file; a conversion module for converting the first data into second data based on the parameter type information and the second code file; wherein the type of the second code file is a model design and development platform side code file or a service-oriented architecture side code file, and the type of the second code file is different from that of the first code file; and a generation module for storing the second data in the second code file to generate a target code file.

[0013] Thirdly, the present invention provides an electronic device, comprising: a memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to perform the code file generation method described in the first aspect or any corresponding embodiment thereof.

[0014] Fourthly, the present invention provides a vehicle including the aforementioned electronic device for executing the method for generating code files of the first aspect or any corresponding embodiment thereof.

[0015] Fifthly, the present invention provides a computer-readable storage medium storing computer instructions for causing a computer to execute the code file generation method described in the first aspect or any corresponding embodiment thereof.

[0016] In a sixth aspect, the present invention provides a computer program product, including computer instructions for causing a computer to execute the method for generating a code file of the first aspect or any corresponding embodiment described above.

[0017] The technical solution provided in this disclosure has the following advantages compared with the prior art: The code file generation method provided in this embodiment can obtain parameter type information and first data of the vehicle parameters to be converted; based on the parameter type information and the second code file, the first data is converted into second data; the second data is stored in the second code file to generate the target code file. That is, by using the parameter type information of the vehicle parameters to be converted as the conversion basis, bidirectional automated adaptation and conversion of vehicle parameter data between MBD model code and vehicle SOA service code is achieved. It relies on parameter type information to distinguish between different parameter forms such as fixed-length arrays, variable-length arrays, strings, and scalars, executing differentiated conversion logic. This solves the problem of incompatibility and inability to directly interoperate between the native data containers of the two architectures. It eliminates the need for manual modification and conversion of various vehicle parameter data, avoiding compilation and runtime failures caused by manual operation, such as type mismatch, array length exceeding limits, and missing effective length identifiers. This significantly reduces the manual debugging workload of cross-architecture integration of vehicle software, improves the efficiency of vehicle code conversion, the accuracy of data transmission, and the automation level of vehicle software development. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0019] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating a method for generating a code file according to an embodiment of this application; Figure 2This is a flowchart illustrating another method for generating a code file according to an embodiment of this application; Figure 3 This is a flowchart illustrating another method for generating a code file according to an embodiment of this application; Figure 4 This is a structural block diagram of the code file generation apparatus provided in the embodiments of this application; Figure 5 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0021] To better understand the above-mentioned objectives, features, and advantages of this disclosure, the solutions disclosed herein will be further described below. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0022] Numerous specific details are set forth in the following description in order to provide a full understanding of this disclosure, but this disclosure may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only some, and not all, of the embodiments of this disclosure.

[0023] The embodiments of this application are applied to the scenario of converting MBD code to vehicle SOA code.

[0024] In the automotive electronics and control field, Matlab / Simulink, as a core tool of MBD (Motion-Based Design), is widely used in vehicle control algorithm development for building dynamic system models graphically. Its S-Function extension mechanism supports writing custom modules in C to implement complex algorithms and customized functions; the Target Language Compiler (TLC) controls the code generation process, efficiently converting models into C++ engineering code. As automotive electronic and electrical architecture evolves towards "software-defined vehicles," SOA (Service-Oriented Architecture) has become an important paradigm for next-generation automotive software development. SOA decouples traditionally distributed ECU functions into standardized, reusable software services, and implements standardized interface calls between services based on communication protocols such as SOME / IP, thereby breaking the tight coupling between hardware and software and improving system flexibility and scalability. However, the basic data types, enumerations, structures, fixed-length arrays, variable-length arrays, and string types widely used in SOA service interfaces have compatibility limitations with the original service-oriented interface modules of MBD—especially fixed-length arrays, variable-length arrays, and string types, which cannot be directly supported.

[0025] In related technologies, the conversion between MBD code and SOA code typically requires manual transformation. This method involves a large development workload, resulting in low conversion efficiency and data type compatibility issues between the model and service-oriented code, affecting system integration efficiency and code generation quality. For example, when implementing service-oriented communication (such as the SOME / IP protocol), complex data types cannot be directly mapped, hindering the seamless conversion and deployment of models to services in the context of "software-defined vehicles".

[0026] To address the aforementioned technical issues, this application provides a method for generating code files. This method leverages the array member characteristics of structures to achieve mapping and conversion between fixed-length arrays, variable-length arrays, and strings between MBD code and SOA code, thereby broadening the applicability of MBD in service-oriented architectures.

[0027] This embodiment provides a method for generating code files, which can be executed by a code file generation device. The code file generation device can be any device with both communication and computing capabilities. For example, the code file generation device can be a server or a cloud server.

[0028] Figure 1 This is a flowchart illustrating a method for generating a code file according to an embodiment of this application; as shown below. Figure 1 As shown, the process includes the following steps: S101, Obtain the parameter type information and first data of the vehicle parameters to be converted.

[0029] The vehicle parameters to be converted can be various vehicle service parameters transmitted in the vehicle service interface. For example, signals, messages, and character information required for vehicle control.

[0030] In this embodiment, the parameter type information may include the parameter name, parameter type, and parameter length of the vehicle parameter to be converted. The parameter type may be a fixed-length array, a variable-length array, or a string.

[0031] In this embodiment of the application, the first data is the parameter value of the vehicle parameter to be converted in the first code file. For example, if the vehicle parameter to be converted is the vehicle speed, the first data is 50 km / h.

[0032] In this embodiment, the first code file is either a service-oriented architecture (SOA) side code file or a model design and development platform (MBD) side code file. The SOA side code file is also called an SOA code file; the MBD side code file is also called an MBD code file. An MBD code file is a C++ code file derived from multiple MBD structures.

[0033] In this embodiment, the target code file can be used for parameter communication between the model design and development platform and the service-oriented architecture, as well as for ECU firmware compilation, SOME / IP message parsing, vehicle bus simulation, and automated software integration testing.

[0034] Specifically, to obtain the first data, follow these steps; see [link / reference] for details. Figure 2 As shown, it includes: S1011, based on the parameter name, query the first code segment corresponding to the parameter name in the first code file.

[0035] The first preset field can be set according to actual needs and is not restricted. For example, for SOA side code, the array member storing element content can be set as the first preset field; for MBD model-generated structure code, the array variable storing data inside the structure can be set as the first preset field.

[0036] S1012, query the data corresponding to the first preset field in the first code segment to obtain the first data.

[0037] As is understandable, the code file consists of multiple code segments; each vehicle parameter corresponds to a code segment in the first code file; when the vehicle parameter to be converted is obtained, the corresponding first code segment can be found in the first code file, which records the parameter value of the vehicle parameter to be converted. By obtaining the first data through matching the parameter name with the corresponding code segment and extracting preset field data, the vehicle parameter to be converted can be retrieved in a targeted manner without traversing the entire code file, greatly improving data reading efficiency.

[0038] S102, based on parameter type information and the second code file, converts the first data into the second data.

[0039] The second code file is either a model design and development platform-side code file or a service-oriented architecture-side code file, and its type differs from the first code file. Specifically, when the first code file is a model design and development platform-side code file, the second code file is a service-oriented architecture-side code file; or, when the first code file is a service-oriented architecture-side code file, the second code file is a model design and development platform-side code file.

[0040] In this embodiment, different parameter type information corresponds to different conversion methods.

[0041] In this embodiment of the application, the data type of the second data matches the file type of the second code file.

[0042] The following describes the specific conversion methods for "converting first data into second data based on parameter type information and second code file" for three different parameter types.

[0043] In some optional implementations, when the parameter type of the vehicle parameter to be converted is a fixed-length array type, the second code segment corresponding to the parameter name is queried in the second code file based on the parameter name; the data corresponding to the second preset field is queried in the second code segment to obtain the reserved storage space corresponding to the vehicle parameter to be converted; if the parameter length matches the reserved storage space, the first data is determined as the second data.

[0044] The reserved storage space is used to indicate the storage space pre-allocated in the second code file for the vehicle parameters to be converted.

[0045] In this embodiment of the application, when the parameter type of the vehicle parameters to be converted is a fixed-length array type, the C++ code data type on the SOA side uses std::array, and the length of std::array is fixed.

[0046] In this embodiment, the second preset field can be set according to actual needs and is not limited. For example, when the second code file is an SOA-side code file, the member field of std::array that stores array elements is used as the second preset field to obtain the fixed memory space allocated to the array; when the second code file is an MBD model-side code file, the array member dimension that carries the fixed-length array inside the structure is used as the second preset field to read the array storage space pre-allocated by the structure.

[0047] Optionally, if the parameter length does not match the reserved storage space, it is determined that the first data cannot be converted into data that conforms to the file format of the second code file.

[0048] Understandably, for fixed-length array-type vehicle parameters, the second code segment is located by parameter name and the reserved storage space is obtained by reading the second preset field. The parameter length and storage space size are checked first before the data conversion is completed. This can intercept problems such as copy out of bounds, data loss, and compilation exceptions caused by inconsistent array lengths at both ends in advance. The storage space size is accurately obtained by relying on standardized field reading logic. It is suitable for bidirectional conversion scenarios of fixed-length arrays of std::array and MBD structure on SOA side, effectively improving the security and accuracy of fixed-length array data conversion and reducing the workload of model and service framework integration and debugging.

[0049] In some optional implementations, when the type of the first code file is a service-oriented architecture side code file and the parameter type is a preset type, the array member dimension of the vehicle parameters to be converted on the model design and development platform side is obtained; if the parameter length is greater than the array member dimension, the first number of data elements are determined as the second data; if the parameter length is less than or equal to the array member dimension, the first data is determined as the second data.

[0050] The default type is either a variable-length array or a string.

[0051] In this embodiment of the application, the first number of data elements is the first number of data elements extracted from the first data starting from the starting position; the first number is consistent with the dimension of the array members.

[0052] In this embodiment of the application, when the parameter type of the vehicle parameters to be converted is a variable-length array type, the C++ code on the SOA side uses std::vector as the corresponding data carrier type; std::vector supports dynamic adjustment of storage length at runtime, with no fixed upper limit on length, which can adapt to dynamic data transmission scenarios with variable quantities in vehicle services.

[0053] In this embodiment of the application, when the parameter type of the vehicle parameter to be converted is a string, the C++ code data type on the SOA side uses std::string as the string carrying type. std::string can dynamically increase or decrease the character length during program execution, and there is no fixed capacity limit. It can flexibly carry various vehicle text information with variable lengths.

[0054] Optionally, when the file type of the first code file is a service-oriented architecture side code file type and the parameter type is a preset type, if the parameter length is greater than the array member dimension, the effective length member variable of the vehicle parameter to be converted on the model design and development platform side is set to the array member dimension; if the parameter length is less than or equal to the array member dimension, the effective length member variable is set to the parameter length.

[0055] Understandably, when converting dynamic type parameters such as variable-length arrays and strings on the SOA side, which have no fixed length limit, to structures on the MBD model side with a storage limit, the maximum dimension of the array on the model side (i.e., the dimension of the array members) is first obtained as a capacity constraint. When the length of the original data exceeds the storage limit, the front-end data with the same dimension is automatically truncated as the conversion result, and the effective length variable of the structure is simultaneously assigned to the array dimension. If the limit is not exceeded, the original data is completely retained and the effective length is set to the actual parameter length. On the one hand, this can strictly limit the total amount of data written to the structure on the model side, completely avoiding risks such as memory overflow, data spill, and program runtime abnormalities, and ensuring the stable operation of the MBD model generation code. On the other hand, through unified truncation rules and effective length assignment logic, automated adaptation is achieved, eliminating the need for manual data trimming and manual filling of effective length identifiers, greatly reducing the workload of in-vehicle code integration and debugging, and effectively improving the reliability of data conversion in the integrated development of MBD and SOA architectures.

[0056] In some optional implementations, when the first code file is a code file on the model design and development platform side and the parameter type is a preset type, the array member dimension and effective length variable values ​​of the vehicle parameters to be converted on the model design and development platform side are obtained; if the effective length variable value is greater than the array member dimension, the first data is determined as the second data; if the effective length variable value is less than or equal to the array member dimension, the third number of data elements is determined as the second data.

[0057] The effective length variable is used to indicate the number of bytes occupied by the actual effective data of the vehicle parameters to be converted on the model design and development platform.

[0058] In this embodiment of the application, the third number of data elements is the third number of data elements extracted from the first data starting from the starting position; the third number is consistent with the value of the effective length variable.

[0059] Optionally, when the first code file is a code file on the model design and development platform side, and the parameter type is a preset type, if the value of the effective length variable is greater than the array member dimension, then the value of the effective length variable is set to the array member dimension; if the value of the effective length variable is less than or equal to the array member dimension, then there is no need to change the value of the effective length variable.

[0060] Understandably, by converting variable-length arrays and strings from the MBD model side to dynamic container data on the SOA side, after reading the effective length variables of the array member dimensions and the actual data volume recorded on the model side, the matching relationship between the effective length and the array dimensions is verified. If the effective length is greater than the array storage limit, the effective length is first corrected to the array dimension, and then all array elements are read completely as the conversion data. If the effective length does not exceed the limit, only the elements of the corresponding effective length are truncated and output to the std::vector or std::string on the SOA side. This can filter out invalid and redundant padding data in the structure array, ensuring that the data transmitted to the SOA service framework only contains valid business content, avoiding invalid data from occupying communication bandwidth and interfering with upper-layer business logic. It can also correct abnormal effective length values ​​in advance, preventing problems such as data length label confusion and message parsing failure after conversion. There is no need for manual screening of valid data and correction of length labels, reducing the manual debugging cost of integrating model code with the SOA service framework, and improving the accuracy of cross-architecture data conversion and the stability of vehicle service communication.

[0061] S103, store the second data in the second code file and generate the target code file.

[0062] For example, when the conversion direction of the first data is from SOA to MBD, the second data is stored in the element corresponding to the MBD array member in the second code file; when the conversion direction of the first data is from MBD to SOA, if the parameter type is a fixed-length array, the second data is stored in std::array in the second code file; if the parameter type is a variable-length array or string, the second data is stored in std::vector in the second code file.

[0063] based on Figure 1 The method shown uses the parameter type information of the vehicle parameters to be converted as the basis for conversion, realizing bidirectional automated adaptation and conversion of vehicle parameter data between MBD model code and vehicle SOA service code. It relies on parameter type information to distinguish different parameter forms such as fixed-length arrays, variable-length arrays, strings, and scalars and executes differentiated conversion logic. This solves the problem of incompatibility and inability to directly communicate between the native data containers of the two architectures. It eliminates the need for manual modification and conversion of various vehicle parameter data, avoiding compilation and runtime failures caused by manual operation, such as type mismatch, array length exceeding limits, and missing effective length identifiers. It can significantly reduce the amount of manual debugging work for cross-architecture integration of vehicle software, improve the efficiency of vehicle code conversion, the accuracy of data transmission, and the level of automation in vehicle software development.

[0064] In an optional example, based on the aforementioned embodiments and as described above, the code files for the model design and development platform are constructed using the following methods and steps, detailed in [reference needed]. Figure 3 As shown, it includes: S301, Obtain the service interface configuration file.

[0065] The service interface configuration file can be an extensible markup language configuration file based on the Automotive Open System Architecture (AUTOSAR) standard. The service interface configuration file describes the metadata information of the vehicle parameters corresponding to each of the multiple vehicle service interfaces.

[0066] In this embodiment of the application, the metadata information includes the parameter data, parameter type, basic data type, and preset length information of each vehicle parameter.

[0067] The preset length information includes the preset array member dimension, the preset maximum storage length in the service interface configuration file, or the preset maximum string length in the service interface configuration file. The basic data type indicates the lowest-level native storage data type of the vehicle parameters.

[0068] S302 generates the model design and development platform side structure corresponding to each vehicle parameter based on the service interface configuration file.

[0069] In one example, when the parameter type of the first vehicle parameter is a fixed-length array and the preset length information is the preset array member dimension, the first structure is constructed based on the parameter data of the first vehicle parameter.

[0070] The first vehicle parameter is any one of the multiple vehicle parameters.

[0071] In this embodiment, the first structure includes array member variables. These array member variables are used to store parameter data, and the array member dimensions of the array member variables are consistent with the preset array member dimensions.

[0072] In this embodiment of the application, the data type of the array member variable matches the basic data type.

[0073] In another example, when the parameter type of the first vehicle parameter is a variable-length array and the preset length information is the maximum storage length preset in the service interface configuration file, the second structure is constructed based on the parameter data of the first vehicle parameter.

[0074] The second structure includes array member variables and a valid length variable.

[0075] In this embodiment, the array member dimension of the array member variable is the maximum storage length. The data type of the array member variable is the basic type of a variable-length array.

[0076] In this embodiment, the effective length variable is used to represent the effective length of the array member variable. The dimension of the effective length variable is equal to 1, the data type is an unsigned 16-bit integer (uint16), and the range is from 0 to the maximum array dimension.

[0077] In another example, when the parameter type of the first vehicle parameter is a string and the preset length information is the maximum string length preset in the service interface configuration file, a third structure is constructed based on the parameter data of the first vehicle parameter.

[0078] The third structure includes array member variables and a valid length variable. The array member variables have an array member dimension equal to the maximum string length. The data type of the array member variables is character. The valid length variable records the actual valid character length of the string. The valid length variable has a dimension of 1, a data type of unsigned 16-bit integer (uint16), and a range from 0 to the maximum array dimension.

[0079] Understandably, structures are constructed based on different types of vehicle parameters and the corresponding preset length information in the service configuration file. For fixed-length arrays, a first structure is generated containing only array member variables that match the basic data type and whose dimensions are consistent with the preset array member dimensions. For variable-length arrays and strings, a second structure and a third structure are generated, respectively, containing fixed-capacity array member variables and effective length variables. The string structure is also separately limited to character type for underlying storage. Through unified structured encapsulation, the dynamic containers on the SOA side are uniformly converted into a static structure format that can be recognized by the MBD model side. The preset length constrains the upper limit of array storage and the effective length variable marks the actual business data volume, avoiding compilation and runtime failures such as array storage out of bounds, data overflow, and type mismatch. There is no need to manually write structure definitions, reducing the cost of vehicle software integration and debugging.

[0080] S303 generates model design and development platform-side code files corresponding to multiple vehicle service interfaces based on the model design and development platform-side structure.

[0081] Understandably, the system directly reads the service interface configuration file to extract all vehicle parameter metadata information. Based on parameter types, basic data types, and preset length constraints, it batches and generates various structures adapted to the MBD model side. Then, it automatically outputs complete MBD side code files based on the generated structures. The entire process requires no manual definition of structures or writing of code, achieving a one-stop automatic conversion of vehicle service parameters from SOA configuration files to model-side code. This ensures that all vehicle parameter structure definitions uniformly follow the configuration file specifications, avoiding human errors such as type errors, array length mismatches, and missing variables with valid lengths caused by manual writing. It can also batch process massive vehicle service interface parameters, greatly reducing the workload of type adaptation and code writing during the joint development of MBD and SOA, and improving the development efficiency, code standardization, and data type matching accuracy of cross-architecture software integration.

[0082] This embodiment also provides a code file generation apparatus for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that performs a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0083] This embodiment provides a code file generation device, such as... Figure 4 As shown, Figure 4 This is a structural block diagram of a code file generation apparatus according to embodiments of this application; including: The acquisition module 401 is used to acquire the parameter type information and first data of the vehicle parameters to be converted; wherein, the first data is the parameter value of the vehicle parameters to be converted in the first code file, and the type of the first code file is a service-oriented architecture side code file or a model design and development platform side code file; The conversion module 402 is used to convert the first data into the second data based on the parameter type information and the second code file; wherein, the type of the second code file is either a model design and development platform side code file or a service-oriented architecture side code file, and the type of the second code file is different from that of the first code file; The generation module 403 is used to store the second data in the second code file and generate the target code file.

[0084] In some optional implementations, the parameter type information includes the parameter name of the vehicle parameter to be converted; the acquisition module 401 is specifically used to query the first code segment corresponding to the parameter name in the first code file based on the parameter name; and to query the data corresponding to the first preset field in the first code segment to obtain the first data.

[0085] In some optional implementations, the parameter type information also includes the parameter type and parameter length of the vehicle parameter to be converted; the conversion module 402 is specifically used to, when the parameter type of the vehicle parameter to be converted is a fixed-length array type, query the second code segment corresponding to the parameter name in the second code file based on the parameter name; query the data corresponding to the second preset field in the second code segment to obtain the reserved storage space corresponding to the vehicle parameter to be converted, the reserved storage space is used to indicate the storage space pre-allocated in the second code file for the vehicle parameter to be converted; if the parameter length matches the reserved storage space, then the first data is determined as the second data.

[0086] In some optional implementations, the conversion module 402 is specifically used to obtain the array member dimension of the vehicle parameters to be converted on the model design and development platform side when the first code file is a service-oriented architecture side code file and the parameter type is a preset type, the preset type is a variable-length array type or a string type; if the parameter length is greater than the array member dimension, then the first number of data elements is determined as the second data; wherein, the first number of data elements is the first number of data extracted from the first data starting from the starting position, and the first number is consistent with the array member dimension; if the parameter length is less than or equal to the array member dimension, then the first data is determined as the second data.

[0087] In some optional implementations, the conversion module 402 is specifically used to, when the first code file is a code file on the model design and development platform side and the parameter type is a preset type, obtain the array member dimension and effective length variable value of the vehicle parameters to be converted on the model design and development platform side. The preset type is a variable-length array type or a string type. The effective length variable value is used to indicate the number of bytes occupied by the actual effective data of the vehicle parameters to be converted on the model design and development platform side. If the effective length variable value is greater than the array member dimension, the first data is determined as the second data. If the effective length variable value is less than or equal to the array member dimension, the third number of data elements is determined as the second data. The third number of data elements is the third number of data elements extracted from the first data starting from the starting position. The third number is consistent with the effective length variable value.

[0088] In some optional implementations, the acquisition module 401 is further configured to acquire a service interface configuration file, which describes the metadata information of the vehicle parameters corresponding to each of the multiple vehicle service interfaces; the generation module 403 is further configured to generate a model design and development platform-side structure corresponding to each vehicle parameter based on the service interface configuration file; and generate model design and development platform-side code files corresponding to the multiple vehicle service interfaces based on the model design and development platform-side structure.

[0089] In some optional implementations, the metadata information includes parameter data, parameter type, basic data type, and preset length information for each vehicle parameter; the generation module 403 is specifically used to construct a first structure based on the parameter data of the first vehicle parameter when the parameter type of the first vehicle parameter is a fixed-length array type and the preset length information is a preset array member dimension. The first structure includes a first array member variable, which is used to store parameter data. The array member dimension of the first array member variable is consistent with the preset array member dimension, and the data type of the first array member variable matches the basic data type. The first vehicle parameter is any one of multiple vehicle parameters. When the parameter type of the first vehicle parameter is a variable-length array type and the preset length information is a preset length in the service interface configuration file... When the maximum storage length is reached, a second structure is constructed based on the parameter data of the first vehicle parameter. The second structure includes a second array member variable and a first effective length variable. The array member dimension of the second array member variable is the maximum storage length, and the first effective length variable is used to represent the effective length of the array member variable. When the parameter type of the first vehicle parameter is string, and the preset length information is the maximum string length preset in the service interface configuration file, a third structure is constructed based on the parameter data of the first vehicle parameter. The third structure includes a third array member variable and a second effective length variable. The array member dimension of the third array member variable is the maximum string length, the data type of the third array member variable is character, and the second effective length variable is used to record the actual effective character length of the string.

[0090] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0091] In this embodiment, the code file generation device is presented in the form of a functional unit. Here, a unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0092] This invention also provides an electronic device having the above-described features. Figure 4 The device for generating the code file shown.

[0093] Please see Figure 5 , Figure 5 This is a schematic diagram of the hardware structure of the electronic device according to an embodiment of this application, such as... Figure 5As shown, the electronic device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise as required. The processors can process instructions executed within the electronic device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple electronic devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). Figure 5 Take a processor 10 as an example.

[0094] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0095] The memory 20 stores instructions executable by at least one processor 10 to cause the at least one processor 10 to perform the method shown in the above embodiments.

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

[0097] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0098] The electronic device also includes a communication interface 30 for communicating with other devices or communication networks.

[0099] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0100] This invention provides a computer program product, which includes computer instructions for causing a computer to execute the method of any embodiment of this invention.

[0101] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0102] The above description is merely a specific embodiment of this disclosure, enabling those skilled in the art to understand or implement it. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this disclosure. Therefore, this disclosure is not to be limited to the embodiments described herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for generating code files, characterized in that, The method includes: Obtain the parameter type information and first data of the vehicle parameters to be converted; wherein, the first data is the parameter value of the vehicle parameters to be converted in the first code file, and the type of the first code file is a service-oriented architecture side code file or a model design and development platform side code file; Based on the parameter type information and the second code file, the first data is converted into the second data; wherein, the type of the second code file is the code file on the model design and development platform side or the code file on the service-oriented architecture side, and the type of the second code file is different from that of the first code file; The second data is stored in the second code file to generate the target code file.

2. The method according to claim 1, characterized in that, The parameter type information includes the parameter name of the vehicle parameter to be converted; Obtaining the first data includes: Based on the parameter name, query the first code segment corresponding to the parameter name in the first code file; In the first code segment, query the data corresponding to the first preset field to obtain the first data.

3. The method according to claim 2, characterized in that, The parameter type information also includes the parameter type and parameter length of the vehicle parameter to be converted; The step of converting the first data into second data based on the parameter type information and the second code file includes: When the parameter type of the vehicle parameter to be converted is a fixed-length array, the second code segment corresponding to the parameter name is queried in the second code file based on the parameter name; In the second code segment, query the data corresponding to the second preset field to obtain the reserved storage space corresponding to the vehicle parameter to be converted. The reserved storage space is used to indicate the storage space pre-allocated in the second code file for the vehicle parameter to be converted. If the parameter length matches the reserved storage space, then the first data is determined as the second data.

4. The method according to claim 3, characterized in that, The step of converting the first data into second data based on the parameter type information and the second code file includes: When the type of the first code file is the service-oriented architecture side code file and the parameter type is a preset type, obtain the array member dimension of the vehicle parameter to be converted on the model design and development platform side, where the preset type is a variable-length array type or a string type; If the parameter length is greater than the array member dimension, then the first number of data elements is determined as the second data; wherein, the first number of data elements is the first number of data elements extracted from the first data starting from the starting position, and the first number is consistent with the array member dimension; If the length of the parameter is less than or equal to the dimension of the array member, then the first data is determined as the second data.

5. The method according to claim 3, characterized in that, The step of converting the first data into second data based on the parameter type information and the second code file includes: When the first code file is the code file on the model design and development platform side, and the parameter type is a preset type, the array member dimension and effective length variable values ​​of the vehicle parameter to be converted on the model design and development platform side are obtained. The preset type is a variable length array type or a string type. The effective length variable value is used to indicate the number of bytes occupied by the actual effective data of the vehicle parameter to be converted on the model design and development platform side. If the value of the effective length variable is greater than the dimension of the array member, then the first data is determined as the second data; If the value of the effective length variable is less than or equal to the array member dimension, then the third number of data elements is determined as the second data. The third number of data elements is the third number of data elements extracted from the first data starting from the starting position, and the third number is consistent with the value of the effective length variable.

6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: Obtain the service interface configuration file, which is used to describe the metadata information of the vehicle parameters corresponding to each of the multiple vehicle service interfaces; Based on the service interface configuration file, a model design and development platform-side structure corresponding to each of the vehicle parameters is generated. Based on the model design and development platform side structure, multiple model design and development platform side code files corresponding to the vehicle service interfaces are generated.

7. The method according to claim 6, characterized in that, The metadata information includes the parameter data, parameter type, basic data type, and preset length information for each of the vehicle parameters; The step of generating the model design and development platform-side structure corresponding to each of the vehicle parameters based on the service interface configuration file includes: When the parameter type of the first vehicle parameter is a fixed-length array type and the preset length information is the preset array member dimension, a first structure is constructed based on the parameter data of the first vehicle parameter. The first structure includes a first array member variable, which is used to store the parameter data. The array member dimension of the first array member variable is consistent with the preset array member dimension, and the data type of the first array member variable matches the basic data type. The first vehicle parameter is any one of the multiple vehicle parameters. When the parameter type of the first vehicle parameter is a variable-length array and the preset length information is the maximum storage length preset in the service interface configuration file, a second structure is constructed based on the parameter data of the first vehicle parameter. The second structure includes a second array member variable and a first effective length variable. The array member dimension of the second array member variable is the maximum storage length, and the first effective length variable is used to represent the effective length of the array member variable. When the parameter type of the first vehicle parameter is a string, and the preset length information is the maximum string length preset in the service interface configuration file, a third structure is constructed based on the parameter data of the first vehicle parameter. The third structure includes a third array member variable and a second effective length variable. The array member dimension of the third array member variable is the maximum string length, the data type of the third array member variable is character, and the second effective length variable is used to record the actual effective character length of the string.

8. A code file generation apparatus, characterized in that, The device includes: The acquisition module is used to acquire parameter type information and first data of the vehicle parameters to be converted; wherein, the first data is the parameter value of the vehicle parameters to be converted in a first code file, and the type of the first code file is a service-oriented architecture side code file or a model design and development platform side code file; The conversion module is used to convert the first data into second data based on the parameter type information and the second code file; wherein the type of the second code file is the code file on the model design and development platform side or the code file on the service-oriented architecture side, and the type of the second code file is different from that of the first code file; The generation module is used to store the second data into the second code file and generate the target code file.

9. An electronic device, characterized in that, include: A memory and a processor are communicatively connected, the memory stores computer instructions, and the processor executes the computer instructions to perform the method for generating a code file according to any one of claims 1 to 7.

10. A vehicle, characterized in that, Including the electronic device as described in claim 9.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing a computer to execute the method for generating a code file according to any one of claims 1 to 7.

12. A computer program product, characterized in that, It includes computer instructions for causing a computer to execute the method for generating a code file according to any one of claims 1 to 7.

Images