Interface file generation method and device, equipment and medium

Abstract

The invention discloses an interface file generation method and device, equipment and a medium. The method comprises the steps that communication demand information of vehicle-mounted software is acquired; determining a component type of the vehicle-mounted software according to the communication demand information; determining an interface file format according to the component type; and inputting the communication demand information and the interface file format into a target large model, and outputting an interface file matched with the interface file format through the target large model. The generation efficiency of the interface file can be improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of vehicles, and in particular to an interface file generation method and device, equipment and a medium. BACKGROUND

[0002] With the rapid development of intelligent and networked vehicles, the functions of vehicle software are increasingly complex, and the communication needs between different functional modules, hardware devices and software systems are diversified and personalized. As the core carrier of vehicle software communication, the format specification and content accuracy of the interface file directly affect the communication stability, compatibility and development efficiency of the vehicle system.

[0003] In related technologies, the generation of interface files is mostly dependent on manual writing by developers according to communication needs or simple modification through fixed templates. However, vehicle software components are of various types, such as sensor components, control unit components, and interactive components, and the interface file formats corresponding to different components differ significantly, and manual generation methods have the problem of low efficiency. SUMMARY

[0004] The following is a summary of the subject matter described in detail herein. This summary is not intended to limit the scope of the claims.

[0005] The main purpose of the embodiments of the present disclosure is to provide an interface file generation method, device, equipment and medium, which can improve the generation efficiency of interface files.

[0006] The first aspect of the embodiments of the present application provides an interface file generation method, which comprises: obtaining communication requirement information of vehicle software; determining the component type of the vehicle software according to the communication requirement information; determining the interface file format according to the component type; inputting the communication requirement information and the interface file format into a target large model, and outputting an interface file matched with the interface file format through the target large model.

[0007] The first aspect of the embodiments of the present application provides an interface file generation method, which accurately matches the component type through the communication requirement information of vehicle software, and then determines the corresponding interface file format according to the component type, ensures that the interface file format is highly adapted to the actual application scenario of vehicle software, and reduces the risk of communication failure caused by format mismatch; subsequently, with the intelligent processing capability of the target large model, the communication requirement information is quickly and accurately converted into the content of the interface file, thereby improving the generation efficiency of the interface file.

[0008] In some embodiments of this application, determining the component type of the in-vehicle software based on the communication requirement information includes: The communication requirement information is parsed to obtain the functional characteristics of the vehicle software; the functional characteristics are used to indicate the communication behavior characteristics of the vehicle software. Based on the aforementioned functional characteristics, the correlation between the in-vehicle software and vehicle control functions is analyzed, and the analysis results are obtained. Based on the analysis results, the component types of the in-vehicle software are determined.

[0009] In some embodiments of this application, the functional features include signal update frequency, number of signal transmitting nodes, and signal timeout tolerance time; The process involves analyzing the correlation between the in-vehicle software and vehicle control functions based on the aforementioned functional characteristics, yielding analysis results including: If the signal update frequency is higher than the first threshold and the signal timeout tolerance time is lower than the second threshold, then it is determined that there is a correlation between the vehicle software and the vehicle control function. If the signal update frequency is lower than or equal to the first threshold and the number of signal sending nodes is a single node, then it is determined that there is no correlation between the vehicle software and the vehicle control function.

[0010] In some embodiments of this application, determining the component type of the in-vehicle software based on the analysis results includes: If the analysis results indicate a correlation between the in-vehicle software and vehicle control functions, the in-vehicle software component is identified as a first type; If the analysis results indicate that there is no correlation between the in-vehicle software and the vehicle control functions, the in-vehicle software component is determined to be of the second type.

[0011] In some embodiments of this application, determining the interface file format based on the component type includes: When the component type is the first type, the architecture description file format is determined to be the interface file format; When the component type is the second type, the source code file format is determined to be the interface file format.

[0012] In some embodiments of this application, the target large model is trained through the following steps: Obtain historical interface development data, which includes communication requirement sample information, interface file samples, and corresponding component type tags; The initial large model is trained based on the historical interface development data to obtain the target large model.

[0013] In some embodiments of this application, determining the component type of the in-vehicle software based on the communication requirement information further includes: The communication requirement information is standardized to obtain standardized communication requirement information. The standardized communication requirement information is converted to a new format to obtain the converted communication requirement information. Based on the communication requirement information after format conversion, the component type of the vehicle software is determined.

[0014] To achieve the above objectives, a second aspect of the present invention provides an interface file generation apparatus, the apparatus comprising: The information acquisition module is used to acquire communication requirement information of the vehicle software; A type determination module is used to determine the component type of the vehicle software based on the communication requirement information; The format determination module is used to determine the interface file format based on the component type. The file generation module is used to input the communication requirement information and the interface file format into the target large model, and output an interface file that matches the interface file format through the target large model.

[0015] To achieve the above objectives, a third aspect of the present invention provides an electronic device, comprising: at least one control processor and a memory for communicatively connecting to the at least one control processor; the memory stores instructions executable by the at least one control processor, the instructions being executed by the at least one control processor to enable the at least one control processor to perform the above-described interface file generation method.

[0016] To achieve the above objectives, a fourth aspect of the present invention provides a computer-readable storage medium storing computer-executable instructions for causing a computer to execute the above-described interface file generation method.

[0017] It is understood that the beneficial effects of the second to fourth aspects compared with the related technologies are the same as the beneficial effects of the first aspect compared with the related technologies. Please refer to the relevant description in the first aspect above, which will not be repeated here. Attached Figure Description

[0018] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which: Figure 1 This is a flowchart illustrating an interface file generation method provided in this application; Figure 2 This is a comparison diagram of the implementation process of the interface file generation method provided in this application and the implementation process of the traditional method; Figure 3 This is another comparison diagram of the implementation process of the interface file generation method provided in this application and the implementation process of the traditional method; Figure 4 This is a schematic diagram of the structure of an interface file generation device provided in this application; Figure 5 This is a schematic diagram of the structure of an embodiment of the electronic device provided in this application. Detailed Implementation

[0019] The embodiments of this application are described in detail below. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain this application, and should not be construed as limiting this application.

[0020] In the description of this application, the use of terms such as "first," "second," etc., is for the purpose of distinguishing technical features only and should not be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated or the order of the technical features indicated.

[0021] In the description of this application, it should be understood that the orientation descriptions, such as up, down, etc., are based on the orientation or positional relationship shown in the accompanying drawings, and are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application.

[0022] In the description of this application, it should be noted that, unless otherwise explicitly defined, terms such as "setup," "installation," and "connection" should be interpreted broadly, and those skilled in the art can reasonably determine the specific meaning of the above terms in this application in conjunction with the specific content of the technical solution.

[0023] With the rapid development of intelligent and connected vehicles, the functions of in-vehicle software are becoming increasingly complex, and the communication needs between different functional modules, hardware devices, and software systems are showing diversified and personalized characteristics. As the core carrier of in-vehicle software communication, the format standardization and content accuracy of interface files directly affect the communication stability, compatibility, and development efficiency of the in-vehicle system.

[0024] In related technologies, the generation of interface files often relies on developers manually writing them according to communication requirements, or making simple modifications to fixed templates. However, automotive software has a wide variety of components, such as sensor components, control unit components, and interaction components, and the interface file formats corresponding to different components vary significantly, making manual generation inefficient.

[0025] Based on this, embodiments of this application provide an interface file generation method, apparatus, device, and medium, which aims to accurately match component types with the communication requirements information of vehicle software, and then determine the corresponding interface file format according to the component types, ensuring that the interface file format is highly compatible with the actual application scenarios of vehicle software, reducing the risk of communication failures caused by format mismatch; subsequently, with the help of the intelligent processing capabilities of the target large model, the communication requirements information is quickly and accurately converted into interface file content, thereby improving the efficiency of interface file generation.

[0026] The interface file generation method, apparatus, device, and medium provided in this application are specifically described through the following embodiments. First, the interface file generation method in this application is described.

[0027] Therefore, referring to Figure 1 This application provides an interface file generation method, which is applied to vehicles and includes the following steps S100 to S400.

[0028] Step S100: Obtain the communication requirement information of the vehicle software; Step S200: Determine the component type of the vehicle software based on the communication requirement information; Step S300: Determine the interface file format according to the component type; Step S400: Input the communication requirement information and the interface file format into the target large model, and output an interface file that matches the interface file format through the target large model.

[0029] In this embodiment, in-vehicle software can refer to application software installed in a vehicle, such as in-vehicle navigation, in-vehicle music, etc., without being specifically limited here.

[0030] In this embodiment, communication requirements information may include, but is not limited to, information such as the communication object, data transmission rate requirements, data format requirements, communication protocol type, and interface interaction logic. For example, the communication requirements information of a certain vehicle navigation software are: the communication object is the vehicle sensor, the data transmission rate requirement is not less than 10Mbps, the data format requirement is JSON, the communication protocol type is TCP / IP, and the interface interaction logic is "sensor data upload - navigation software data reception - data verification - feedback confirmation". Furthermore, the communication requirements of the in-vehicle software can be obtained by receiving the requirements information input by developers through the input interface, extracting requirements information from the development requirements document of the in-vehicle software, or by interacting with the development system of the in-vehicle software. No specific limitations are made here.

[0031] In this embodiment, the component types may include sensor components, control unit components, human-computer interaction components, data storage components, communication transmission components, etc.

[0032] Furthermore, a pre-defined rule can be set to correspond between communication requirement information and component type. Based on this pre-defined rule, the acquired communication requirement information can be matched and analyzed to determine the corresponding vehicle software component type.

[0033] For example, the predefined correspondence rules between communication requirement information and component type can be as follows: if the communication requirement information includes descriptions related to data acquisition and physical quantity detection, and the data transmission rate requirement is between 1-100Mbps and the data format is binary, then the component type is determined to be a sensor component; if the communication requirement information includes descriptions related to command issuance and device control, and the communication protocol type is CAN bus protocol, then the component type is determined to be a control unit component; if the communication requirement information includes descriptions related to user input and information display, and the interface interaction logic includes processes such as user operation and response feedback, then the component type is determined to be a human-computer interaction component.

[0034] In this embodiment, interface file format templates corresponding to different component types can be preset. The interface file format may include information such as file structure, field definition, parameter configuration rules, and syntax specifications.

[0035] For example, the interface file format template corresponding to the sensor component contains a file structure of "sensor identification field - data acquisition time field - data type field - data value field - check code field". The field definition clearly specifies the data length and data type of each field. The parameter configuration rules include the configuration requirements of data transmission rate parameters and sampling frequency parameters. The syntax specification follows the ISO15765 standard.

[0036] Based on the determined component type, the corresponding interface file format template is called as the interface file format for this generation of interface files.

[0037] In this embodiment, the target large model is an artificial intelligence model trained with data generated from interface files. Its training data may include communication requirement sample information of historical vehicle software, interface file samples, and corresponding component type labels.

[0038] Furthermore, the acquired communication requirement information is used as the content input, and the determined interface file format is used as the format constraint condition. Both are input into the target large model. The target large model adjusts the output form according to the format constraint condition, fills the interface file content according to the communication requirement information, and automatically completes operations such as field assignment, parameter configuration, and syntax verification. Finally, it outputs an interface file that meets the interface file format requirements and contains complete communication requirement information.

[0039] Unlike existing technologies, this application's embodiments accurately match component types based on the communication requirements of the vehicle software, and then determine the corresponding interface file format according to the component type. This ensures that the interface file format is highly compatible with the actual application scenarios of the vehicle software, reducing the risk of communication failures caused by format mismatch. Subsequently, by leveraging the intelligent processing capabilities of the target large model, the communication requirements information is quickly and accurately converted into interface file content, thereby improving the efficiency of interface file generation.

[0040] In some embodiments, step S200 may include, but is not limited to, steps S210 to S230: Step S210: Parse the communication requirement information to obtain the functional characteristics of the vehicle software; the functional characteristics are used to indicate the communication behavior characteristics of the vehicle software. Step S220: Based on the functional characteristics, analyze the correlation between the vehicle software and the vehicle control function to obtain the analysis results; Step S230: Based on the analysis results, determine the component type of the vehicle software.

[0041] In this embodiment, the functional features can be used to indicate the communication behavior characteristics of the vehicle software, and may include signal update frequency, number of signal sending nodes, signal timeout tolerance time, and may also include information such as data flow characteristics, interaction purpose characteristics, operation object characteristics, and protocol adaptation characteristics.

[0042] Furthermore, parameter-type information in the communication requirements information can be directly extracted. For example, signal update frequency, number of signal transmitting nodes, and signal timeout tolerance time are directly quantified parameters that can be directly extracted and assigned values ​​to obtain the functional characteristics of the vehicle software.

[0043] In other implementations, the functional characteristics of the vehicle software are obtained by performing operations such as keyword extraction from the text descriptions in the communication requirements information, classification and labeling of parameter information, and process decomposition of the interaction logic.

[0044] For example, given the communication requirements information, the communication object is an on-board sensor, the data transmission rate requirement is 20Mbps, the interface interaction logic is data acquisition-upload-verification-feedback, the signal update frequency is 30Hz, the number of signal sending nodes is 1, and the signal timeout tolerance time is 5ms, the functional feature parameters are directly extracted: signal update frequency = 30Hz, number of signal sending nodes = 1, signal timeout tolerance time = 5ms; at the same time, the keywords sensor, data acquisition, and upload are extracted, and the interaction process is decomposed into acquisition → upload → verification → feedback, and the data flow characteristics are supplemented to show that it is a one-way upload (sensor → software system), and the interaction purpose characteristics are data acquisition and verification.

[0045] In this embodiment, a vehicle control function association feature library can be pre-set. Vehicle control functions may include core control functions such as power control, chassis control, body control, comfort system control, and safety system control. The association feature library stores the associated keywords, data flow rules, and operation object types corresponding to each control function. Based on these functional characteristics, the correlation between the in-vehicle software and the vehicle control functions can be analyzed to obtain the analysis results.

[0046] In other implementations, parameter information in the functional features can be compared with thresholds to determine the correlation between the in-vehicle software and the vehicle control functions.

[0047] Furthermore, the functional features include signal update frequency, number of signal transmitting nodes, and signal timeout tolerance time. Step S220 may include, but is not limited to, steps S221 to S222.

[0048] If the signal update frequency is higher than the first threshold and the signal timeout tolerance time is lower than the second threshold, then it is determined that there is a correlation between the vehicle software and the vehicle control function.

[0049] If the signal update frequency is lower than or equal to the first threshold and the number of signal sending nodes is a single node, then it is determined that there is no correlation between the vehicle software and the vehicle control function.

[0050] In this embodiment, the signal update frequency can refer to the reciprocal of the update cycle of the data signal between the vehicle software and the communication object (i.e., the number of signal updates per unit time), which is used to characterize the real-time requirements of communication.

[0051] The number of signal transmitting nodes can refer to the total number of hardware or software nodes that initiate signal transmission, and is used to characterize the degree of distribution of communication.

[0052] Signal timeout tolerance time refers to the maximum allowable delay time during signal transmission. If this time is exceeded, it is considered a communication anomaly and is used to characterize the timeliness requirements of communication.

[0053] Furthermore, a first threshold and a second threshold are preset. The first threshold is a critical value for the signal update frequency, and its value range can be set to 10Hz-100Hz. The second threshold is a critical value for the signal timeout tolerance time, and its value range can be 5ms-50ms.

[0054] It should be noted that the first and second thresholds can be dynamically adjusted according to the safety level requirements of the vehicle control functions. For example, the first threshold for power control and safety system control can be set to 50Hz and the second threshold to 10ms; the first threshold for comfort system control can be set to 20Hz and the second threshold to 30ms.

[0055] If the signal update frequency in the functional characteristics is higher than the first threshold and the signal timeout tolerance time is lower than the second threshold, then it is determined that there is a correlation between the vehicle software and the vehicle control function. If the signal update frequency in the functional features is lower than or equal to the first threshold, and the number of signal sending nodes is a single node, then it is determined that there is no correlation between the vehicle software and the vehicle control function. In other implementations, such as when the signal update frequency is higher than the first threshold but the signal timeout tolerance time is higher than or equal to the second threshold, or when the signal update frequency is lower than or equal to the first threshold but the number of signal sending nodes is multiple, it can also be determined that there is a correlation between the vehicle software and the vehicle control function. However, the correlation in this case is lower than the correlation in the functional features where the signal update frequency is higher than the first threshold and the signal timeout tolerance time is lower than the second threshold.

[0056] Furthermore, when the signal update frequency is higher than the first threshold but the signal timeout tolerance time is higher than or equal to the second threshold, or when the signal update frequency is lower than or equal to the first threshold but the number of signal sending nodes is multiple, the vehicle control function associated feature library can be used for further verification. For example, the associated feature library stores the associated keywords and data flow rules corresponding to each control function. After supplementing the matching, the final correlation can be determined.

[0057] For example, if the functional characteristics are a signal update frequency of 40Hz (higher than the first threshold of 30Hz) and a signal timeout tolerance of 15ms (lower than the second threshold of 20ms), the analysis result is highly correlated with the vehicle control function; if the functional characteristics are a signal update frequency of 25Hz (lower than the first threshold of 30Hz) and a signal sending node count of 1 (single node), the analysis result is not correlated with the vehicle control function; if the functional characteristics are a signal update frequency of 40Hz (higher than the first threshold) and a signal timeout tolerance of 25ms (higher than the second threshold), it is first determined to be moderately correlated, and then verified by combining the associated feature library. If it contains power control-related keywords, it is updated to highly correlated; otherwise, it remains moderately correlated.

[0058] In this embodiment, by clearly defining the functional characteristics, including three core quantification parameters such as signal update frequency, number of signal sending nodes, and signal timeout tolerance time, and providing specific correlation determination rules (dual threshold determination + single node exclusion rule), the abstract correlation analysis is transformed into quantifiable and executable logic. This avoids the subjectivity and ambiguity of correlation determination in traditional methods and significantly improves the accuracy of component type determination. At the same time, the clear definition of quantification parameters makes the correlation analysis reproducible, and the determination results are consistent in different development scenarios, enhancing the universality and reliability of this embodiment.

[0059] Furthermore, step S230 may include, but is not limited to, the following: If the analysis results indicate a correlation between the in-vehicle software and vehicle control functions, the in-vehicle software component is identified as a first type; If the analysis results indicate that there is no correlation between the in-vehicle software and the vehicle control function, the in-vehicle software component is determined to be of the second type. When the component type is the first type, the architecture description file format is determined to be the interface file format; When the component type is the second type, the source code file format is determined to be the interface file format.

[0060] In this embodiment, if the analysis results indicate a correlation (including high correlation and medium correlation) between the in-vehicle software and the vehicle control function, the in-vehicle software component is determined to be of the first type.

[0061] In other implementations, the first type of components can be further subdivided according to functional characteristics: if the functional characteristics include data acquisition and physical quantity detection, the first type is specifically a sensor component; if the functional characteristics include command issuance and device control, the first type is specifically a control unit component; if the functional characteristics include data storage and historical data query, the first type is specifically a data storage component; if the functional characteristics include protocol conversion and cross-module data forwarding, the first type is specifically a communication transmission component.

[0062] If the analysis results indicate that there is no correlation between the in-vehicle software and the vehicle control functions, then the in-vehicle software component is determined to be of the second type.

[0063] In other implementations, the second type of specific components can be further subdivided according to functional characteristics: if the functional characteristics include user input, information display, etc., then the second type is a human-computer interaction component.

[0064] In this embodiment, the architecture description file format can be a file format used to describe the architecture design, interface definition, module interaction relationship, and parameter constraint rules of the vehicle software components. It has the characteristics of being structured, standardized, and highly parseable, so as to adapt to the interface development requirements of vehicle control-related components.

[0065] The source code file format can be an executable code file format used to implement user interaction logic and data processing flow. It has the characteristics of compilability and strong interactivity to adapt to the interface development needs of non-vehicle control interactive components.

[0066] Furthermore, if the component type is the first type (related to vehicle control functions), then the architecture description file format is determined to be the interface file format; the specific types of the architecture description file format include, but are not limited to, AUTOSARARXML format, Protobuf format, and XML Schema format.

[0067] In some implementations, different first-type specific components correspond to different preset architecture description file formats. For example, sensor components and control unit components correspond to the AUTOSAR ARXML format, conforming to the AUTOSAR AdaptivePlatform standard, to support real-time parameter configuration and control logic description. Data storage components correspond to the XML Schema format to support data structure definition and storage rule constraints. Communication transmission components correspond to the Protobuf format to support cross-module data serialization and protocol conversion description.

[0068] Furthermore, if the component type is the second type (unrelated to vehicle control functions), then the source code file format will be determined as the interface file format. Specific types of source code file formats include, but are not limited to, JavaScript, Python, and C# formats, to adapt to the interaction logic implementation requirements of the human-computer interaction component. In some implementations, if the functional features include web-based interaction or visual display, the corresponding format is JavaScript. If the functional features include backend data processing and interactive responses, the corresponding format is Python; if the functional features include a desktop-level interactive interface, the corresponding format is C#.

[0069] In some embodiments, the target large model can be trained through the following steps: Obtain historical interface development data, which includes communication requirement sample information, interface file samples, and corresponding component type tags; The initial large model is trained based on the historical interface development data to obtain the target large model.

[0070] In this embodiment, historical interface development data includes communication requirement sample information, interface file samples, and corresponding component type tags. Historical interface development data can be obtained from historical development projects in the automotive software industry, publicly available automotive interface standard documents, and internal interface development knowledge bases of automakers; no specific limitations are imposed here.

[0071] The initial large model can be selected to adapt to the basic model of text generation and structured data processing, and initialized according to the vehicle interface generation scenario, such as setting the maximum sequence length to 2048 to adapt to long text requirements and interface files.

[0072] During training, supervised learning can be employed, using preprocessed communication requirement sample information and component type labels as input features, and corresponding interface file samples as output labels to construct the training dataset. The training objective function can utilize the cross-entropy loss function. This yields the target large-scale model.

[0073] In some embodiments, step S200 may also include, but is not limited to, steps S240 to S260: Step S240: Standardize the communication requirement information to obtain standardized communication requirement information; Step S250: Convert the standardized communication requirement information to obtain the format-converted communication requirement information; Step S260: Determine the component type of the vehicle software based on the communication requirement information after format conversion.

[0074] In this embodiment, standardization processing can be used to process the parameter names, units, and expression formats of communication requirement information to eliminate format differences between information from different sources and ensure data consistency and parsability.

[0075] For example, standardization can be achieved by standardizing parameter names and pre-setting a dictionary of core parameters for vehicle communication requirements, uniformly mapping parameter names with different expressions to standard names. For instance, data transmission speed and bandwidth can be uniformly mapped to transmission rate, and signal refresh frequency and data update frequency can be uniformly mapped to signal update frequency.

[0076] The purpose of format conversion is to convert standardized unstructured / semi-structured information (such as text descriptions and key-value pairs) into a structured data format that can be directly parsed by machines, facilitating subsequent feature extraction and correlation analysis.

[0077] The following describes the implementation process of the interface file generation method provided in the embodiments of this application: like Figure 2 As shown, Figure 2The diagram shows a comparison between the implementation process of this application and the traditional method. For application-level SWC components with changing requirements (i.e., components related to control functions), the interface description file Arxml can be quickly generated according to the requirements (i.e., communication requirement information). The traditional method requires multiple steps such as importing SystemExtra files, creating runnable entities, creating events, creating interfaces, and connecting before generating the Arxml file, which can easily lead to omissions of requirements.

[0078] Among them, the AI ​​large model can use previous engineering code (labeled data) to train multiple personalized models, or it can directly use existing large model tools and switch flexibly according to needs.

[0079] like Figure 3 As shown, Figure 3 This is another comparison diagram of the implementation process of this application and the traditional method. For the middleware communication agent software component (SWC) (i.e., the component that is not related to the control function), when the network professional releases the communication matrix (i.e., communication demand information), this embodiment can directly input the AI ​​large model to bypass the basic software (BSW) development and directly generate the communication callback interface. The traditional method requires multiple steps such as the creation of CAN database file (DBC) and LIN description file (LDF), and the configuration of BSW protocol stack.

[0080] like Figure 4 As shown in some embodiments of this application, an interface file generation apparatus is provided. The apparatus includes an information acquisition module 10, a type determination module 20, a format determination module 30, and a file generation module 40. Specifically: Information acquisition module 10 is used to acquire communication requirement information of vehicle software; The type determination module 20 is used to determine the component type of the vehicle software based on the communication requirement information; The format determination module 30 is used to determine the interface file format according to the component type; The file generation module 40 is used to input the communication requirement information and the interface file format into the target large model, and output an interface file that matches the interface file format through the target large model.

[0081] It should be noted that the interface file generation device provided in this embodiment and the interface file generation method described above are based on the same inventive concept. Therefore, the relevant content of the interface file generation method described above also applies to the content of the interface file generation device, and therefore will not be repeated here.

[0082] To this end, the device accurately matches component types with the communication requirements information of the vehicle software, and then determines the corresponding interface file format based on the component type. This ensures that the interface file format is highly compatible with the actual application scenario of the vehicle software, reducing the risk of communication failures caused by format mismatch. Subsequently, with the help of the intelligent processing capabilities of the target large model, the communication requirements information is quickly and accurately converted into interface file content, thereby improving the efficiency of interface file generation.

[0083] like Figure 5 As shown in the illustration, this application also provides an electronic device, which includes: At least one memory; At least one processor; At least one program; The program is stored in memory, and the processor executes at least one program to implement the interface file generation method described above in this disclosure.

[0084] This electronic device can be any smart terminal, including mobile phones, tablets, personal digital assistants (PDAs), and in-vehicle computers.

[0085] The electronic devices according to embodiments of this application will now be described in detail.

[0086] The processor 1600 can be implemented using a general-purpose central processing unit (CPU), microprocessor, application specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of the present invention. The memory 1700 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 1700 can store operating devices and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the program code is stored in the memory 1700 and is called and executed by the processor 1600 to execute an interface file generation method according to an embodiment of the present invention.

[0087] The input / output interface 1800 is used to implement information input and output. The communication interface 1900 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 2000 transmits information between various components of the device (e.g., processor 1600, memory 1700, input / output interface 1800, and communication interface 1900); The processor 1600, memory 1700, input / output interface 1800 and communication interface 1900 are connected to each other within the device via bus 2000.

[0088] This invention also provides a storage medium, which is a computer-readable storage medium storing computer-executable instructions for causing a computer to execute the above-described interface file generation method.

[0089] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor 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.

[0090] The embodiments described in this invention are intended to more clearly illustrate the technical solutions of the embodiments of this invention, and do not constitute a limitation on the technical solutions provided by the embodiments of this invention. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this invention are also applicable to similar technical problems.

[0091] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of the present invention, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0092] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; 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.

[0093] Those skilled in the art will understand that all or some of the steps, apparatuses, or functional modules / units in the methods disclosed above can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0094] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, apparatus, product, or device that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0095] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0096] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0097] The units described as separate components may or may not be physically separate. The components shown as units 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 units can be selected to achieve the purpose of this embodiment according to actual needs.

[0098] Furthermore, the functional units 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 as a software functional unit.

[0099] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause an electronic device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0100] The above is a detailed description of the preferred embodiments of this application. However, the embodiments of this application are not limited to the above-described implementation methods. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the embodiments of this application. All such equivalent modifications or substitutions are included within the scope defined by the claims of the embodiments of this application.

Claims

1. A method for generating interface files, characterized in that, include: Obtain communication requirement information from the vehicle software; Based on the communication requirement information, determine the component type of the vehicle software; Determine the interface file format based on the component type; The communication requirements information and the interface file format are input into the target large model, and the target large model outputs an interface file that matches the interface file format.

2. The interface file generation method according to claim 1, characterized in that, Determining the component type of the in-vehicle software based on the communication requirement information includes: The communication requirement information is parsed to obtain the functional characteristics of the vehicle software; the functional characteristics are used to indicate the communication behavior characteristics of the vehicle software. Based on the aforementioned functional characteristics, the correlation between the in-vehicle software and vehicle control functions is analyzed, and the analysis results are obtained. Based on the analysis results, the component types of the in-vehicle software are determined.

3. The interface file generation method according to claim 2, characterized in that, The functional features include signal update frequency, number of signal transmitting nodes, and signal timeout tolerance time; The process involves analyzing the correlation between the in-vehicle software and vehicle control functions based on the aforementioned functional characteristics, yielding analysis results including: If the signal update frequency is higher than the first threshold and the signal timeout tolerance time is lower than the second threshold, then it is determined that there is a correlation between the vehicle software and the vehicle control function. If the signal update frequency is lower than or equal to the first threshold and the number of signal sending nodes is a single node, then it is determined that there is no correlation between the vehicle software and the vehicle control function.

4. The interface file generation method according to claim 2, characterized in that, The step of determining the component type of the in-vehicle software based on the analysis results includes: If the analysis results indicate a correlation between the in-vehicle software and vehicle control functions, the in-vehicle software component is identified as a first type; If the analysis results indicate that there is no correlation between the in-vehicle software and the vehicle control functions, the in-vehicle software component is determined to be of the second type.

5. The interface file generation method according to claim 4, characterized in that, Determining the interface file format based on the component type includes: When the component type is the first type, the architecture description file format is determined to be the interface file format; When the component type is the second type, the source code file format is determined to be the interface file format.

6. The interface file generation method according to claim 1, characterized in that, The target large model is trained through the following steps: Obtain historical interface development data, which includes communication requirement sample information, interface file samples, and corresponding component type tags; The initial large model is trained based on the historical interface development data to obtain the target large model.

7. The interface file generation method according to claim 1, characterized in that, The step of determining the component type of the vehicle software based on the communication requirement information further includes: The communication requirement information is standardized to obtain standardized communication requirement information. The standardized communication requirement information is converted to a new format to obtain the converted communication requirement information. Based on the communication requirement information after format conversion, the component type of the vehicle software is determined.

8. An interface file generation device, characterized in that, The device includes: The information acquisition module is used to acquire communication requirement information of the vehicle software; A type determination module is used to determine the component type of the vehicle software based on the communication requirement information; The format determination module is used to determine the interface file format based on the component type. The file generation module is used to input the communication requirement information and the interface file format into the target large model, and output an interface file that matches the interface file format through the target large model.

9. An electronic device, characterized in that: It includes at least one control processor and a memory for communicatively connecting to the at least one control processor; the memory stores instructions executable by the at least one control processor, which, when executed by the at least one control processor, enable the at least one control processor to perform the interface file generation method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions for causing a computer to perform the interface file generation method according to any one of claims 1-7.

Images