Verification method, electronic device, readable medium and program product

Abstract

The invention relates to the technical field of software, and discloses a verification method, electronic equipment, a readable medium and a program product. The verification method is applied to the electronic equipment, the electronic equipment can convert a to-be-verified program file (such as an ARXML file) into a visual graphic file (such as a UML graph), logic information such as the dependency relationship between configuration items in the to-be-verified ARXML file is displayed through the UML graph, and a user can conveniently verify the consistency of the program file and a designed software architecture. In this way, the verification efficiency of the ARXML file can be improved, and the verification difficulty of the ARXML file is reduced.

Description

Technical Field

[0001] The present invention relates to the field of software technology, and in particular to a verification method, electronic equipment, readable medium and program product. Background Art

[0002] In the automotive open system architecture (AUTOSAR) standard, ARXML files are a file format based on extensible markup language (XML) that is used to describe the configuration information of automotive electronic systems in detail. In the design process of automotive electronic software architecture, ARXML files can present the design information of the software architecture in a standardized format as the basis for subsequent software development and integration.

[0003] To ensure that the ARXML file complies with the design specifications and is consistent with the design requirements of the software architecture, the ARXML file needs to be verified. Currently, the most common verification method is for technicians to check the configuration information in the ARXML file. However, the ARXML file is large in size and not very readable, which makes verification difficult and inefficient. Summary of the invention

[0004] In view of this, embodiments of the present application provide a verification method, an electronic device, a readable medium, and a program product.

[0005] In a first aspect, an embodiment of the present application provides a verification method, which is applied to an electronic device, and the method includes: obtaining a program file to be verified, the program file to be verified including multiple configuration items, and the multiple configuration items correspond to different functional modules; screening multiple target configuration items corresponding to the target functional module from the multiple configuration items, and intercepting a program fragment to be verified from the program file to be verified according to the multiple target configuration items; generating a first graphic file corresponding to the program fragment to be verified, the first graphic file being able to describe the association relationship between the multiple target configuration items in the form of a graphic; and displaying the first graphic file for a user to verify the configuration information of the multiple target configuration items, the configuration information at least including the association relationship between the multiple target configuration items.

[0006] Based on the above solution, the electronic device can convert the program file to be verified (such as ARXML file) into a visual graphic file (such as UML diagram), and display the logical information such as the dependency relationship between the configuration items in the ARXML file to be verified through the UML diagram, so as to facilitate the user to verify the consistency between the program file and the designed software architecture. This is conducive to improving the verification efficiency of ARXML files and reducing the difficulty of ARXML file verification.

[0007] In a possible implementation of the first aspect above, generating a first graphic file corresponding to the program fragment to be verified includes: converting the program fragment to be verified into an architecture description file to be verified based on a unified modeling language through a large language model; and generating a graphic file corresponding to the architecture description file to be verified by using a drawing tool based on the unified modeling language, wherein the graphic file corresponding to the architecture description file to be verified is the first graphic file.

[0008] In a possible implementation of the first aspect above, the program file to be verified is generated based on a source architecture description file of the corresponding software, and the source architecture description file adopts a unified modeling language; before obtaining the program file to be verified, the method also includes: obtaining the source architecture description file; using a drawing tool based on the unified modeling language to generate a second graphic file corresponding to the source architecture description file, the second graphic file can describe the architecture information of the corresponding software in the form of a graphic, and the architecture information includes multiple configuration items involved in the software, and the association relationship between the multiple configuration items; obtaining the program file to be verified includes: generating the program file to be verified based on the second graphic file or the source architecture description file.

[0009] In a possible implementation of the first aspect above, before generating the first graphic file corresponding to the program fragment to be verified, the method further includes: determining the type of the graphic file to be drawn based on the source architecture description file, the type of the graphic file to be drawn being the type of the second graphic file.

[0010] In a possible implementation of the first aspect above, a program fragment to be verified is converted into an architecture description file to be verified based on a unified modeling language through a large language model, including: inputting the type of the program fragment to be verified and the type of the graphic file to be drawn into the large language model, and converting the program fragment to be verified into the architecture description file to be verified through the large language model, and the architecture description file to be verified can be used to generate a graphic file of the type of the graphic file to be drawn.

[0011] In a possible implementation manner of the first aspect above, the method further includes: verifying the standardization of the program fragment to be verified by using a large language model, and outputting a verification result.

[0012] In a possible implementation of the first aspect above, the standardization of the program fragment to be verified is verified through a large language model, and the verification result is output, including: obtaining a design specification file, the design specification file including configuration rules related to configuration items; inputting the design specification file and the program fragment to be verified into the large language model, and verifying the configuration information of each target configuration item in the program fragment to be verified with the configuration rules through the large language model to obtain a verification result of whether each target configuration item satisfies the configuration rules.

[0013] In a second aspect, an embodiment of the present application provides an electronic device, comprising: one or more memories; one or more memories storing one or more programs, when one or more programs are executed by one or more processors, the above-mentioned electronic device executes the verification method provided in the above-mentioned first aspect and various possible implementations of the first aspect.

[0014] In a third aspect, an embodiment of the present application provides a computer-readable medium having instructions stored thereon. When the instructions are executed on an electronic device, the electronic device executes the verification method provided in the first aspect and various possible implementations of the first aspect.

[0015] In a fourth aspect, an embodiment of the present application provides a computer program product, which includes computer instructions. When executed by an electronic device, the electronic device executes the verification method provided in the first aspect and various possible implementations of the first aspect.

[0016] The beneficial effects of the second to fourth aspects mentioned above can be referred to the relevant description of the first aspect mentioned above, and will not be elaborated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 According to some embodiments of the present application, a schematic diagram of a software architecture design and verification process is shown;

[0018] Figure 2 According to some embodiments of the present application, an overall logical architecture diagram of a verification method is shown;

[0019] Figure 3 According to some embodiments of the present application, a logical architecture diagram of a visual audit is shown;

[0020] Figure 4 According to some embodiments of the present application, a logical architecture diagram of automated auditing is shown;

[0021] Figure 5 According to some embodiments of the present application, a flow chart of a verification method is shown;

[0022] Figure 6 According to some embodiments of the present application, a schematic structural diagram of an electronic device 10 is shown. DETAILED DESCRIPTION

[0023] In order to make the purpose, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described in detail below in conjunction with the accompanying drawings and specific implementation methods.

[0024] As you can understand, the unified modeling language (UML) is a modeling language widely used in software engineering fields such as software architecture design. UML helps technicians display the design information of software architecture in a visual way through a series of standardized graphic symbols and representation methods.

[0025] During the design phase of the software architecture, technicians can use different types of UML diagrams (such as class diagrams, component diagrams, sequence diagrams, etc.) to describe the design information of the software architecture in detail. For example, in an automotive electronic system, a component diagram can be used to intuitively display modules / components / units such as the engine control module (ECM), transmission control module (TCM), and body control module (BCM), as well as the dependencies and communication interfaces between modules / components / units.

[0026] It can be understood that the process of verifying the ARXML file is the process of checking whether the automotive electronic system architecture elements, interfaces, parameters and relationships defined in the ARXML file comply with the AUTOSAR standard specifications. Furthermore, the process of verifying the ARXML file is the process of verifying the designed software architecture.

[0027] Figure 1 According to an embodiment of the present application, a schematic diagram of the design and verification process of a software architecture is shown.

[0028] It can be understood that technicians, as the main body of designing and verifying the software architecture, need to use electronic devices to assist in completing the design and verification process of the software architecture. The following describes the design and verification process of the software architecture from the perspective of technicians using electronic devices.

[0029] refer to Figure 1 As shown, the technician can use the UML design tool deployed or run on the electronic device, such as the open source tool PlantUML, to obtain the corresponding UML diagram by writing PlantUML code to achieve visual design of the software architecture. In some embodiments, the technician can also use other UML design tools to obtain the corresponding UML diagram by drawing graphics or writing codes to achieve visual design of the software architecture, which is not limited here.

[0030] Furthermore, the electronic device can obtain the corresponding ARXML file based on the PlantUML code or UML diagram and a dedicated configuration tool (such as AUTOSAR Builder). The ARXML file can provide detailed configuration information and support automatic code generation, thereby ensuring information consistency and interoperability between different development environments and development tools, thereby guiding the subsequent code generation and system integration process.

[0031] It can be understood that in the actual scenario of software architecture design and verification, only one function or a few related functions are usually targeted during a design and verification process. However, in view of the complexity of automotive electronic systems, even if only one function is designed and verified, due to the existence of a large number of complex cross-module and cross-level configurations, the contents of other modules and other levels in the ARXML file may also need to be updated accordingly. For example, when designing the audio playback function of the in-vehicle entertainment system, it may be necessary to adjust the configuration of the underlying hardware driver module related to the audio processing chip, and it may also involve the display logic adjustment of the upper-level user interaction interface module. These modules are at different levels. Furthermore, the obtained ARXML file does not only contain the part corresponding to the current design function, but includes all ARXML files related to the system where the function is implemented after the current function is updated, that is, the obtained ARXML file is relatively large in size.

[0032] Furthermore, the technicians may check the ARXML files to obtain checked ARXML files, so as to ensure that the checked ARXML files can meet the requirements for implementing the functions and comply with the design specifications, thereby serving as a basis for subsequent software development and integration.

[0033] For example, for the ARXML file generated by designing the automotive electronic software architecture (such as the powertrain system), the design requirements of the powertrain system are to realize the engine control function, the transmission control function, etc. To ensure that the ARXML file can meet the implementation requirements of the above functions and conform to the design specifications, the technicians need to check whether the corresponding ARXML file correctly configures the corresponding software components such as ECM and TCM, whether the interfaces between the software components are correctly configured, and other related contents.

[0034] Based on the above Figure 1 In the process shown, technicians use electronic devices to design and verify the software architecture.

[0035] It can be understood that when verifying an ARXML file, verifying logical information such as dependencies between configuration items in the ARXML file is crucial to ensuring the correctness, integrity and stability of the software architecture. The following is an exemplary description of the dependencies between configuration items in the ARXML file.

[0036] Specifically, Table 1 provides partial configuration information related to the vehicle speed interface in an ARXML file.

[0037]

[0038] In the configuration information shown in Table 1, two composite software components SpeedCalc and Odometer, as well as a send-receive interface VehicleSpeedInterface, are defined. Among them, SpeedCalc has a provided port named VehicleSpeed, which needs to reference an interface pointing to the send-receive interface VehicleSpeedInterface. Similarly, Odometer has a required port named VehicleSpeed. This port needs to reference an interface, also pointing to the send-receive interface VehicleSpeedInterface. By defining the data elements and data types of the send-receive interface VehicleSpeedInterface, the VehicleSpeed ​​port determines the rules and format of port data interaction by referencing the VehicleSpeedInterface interface. For example, the VehicleSpeed ​​provided port of the SpeedCalc component provides UInt type data according to the VehicleSpeedInterface interface definition, and the VehicleSpeed ​​required port of the Odometer component receives UInt type data according to the VehicleSpeedInterface interface definition.

[0039] It can be understood that the above configuration is usually used in electronic control units in vehicles, such as engine control module (ECM), transmission control module (TCM) and body control module (BCM), etc. By defining clear data interfaces and data types, it is ensured that data exchange between different modules is standardized and reliable.

[0040] In some embodiments, the VehicleSpeedInterface interface is used to transmit the current speed data of the vehicle. This interface can be used by multiple electronic control units, such as the dashboard to display the current speed, or the adaptive cruise control system to adjust the vehicle speed. Correspondingly, the above SpeedCalc component can be used to provide vehicle speed data, and the above Odometer component can be used to obtain vehicle speed data, which will not be described in detail here.

[0041] It can be understood that in some of the configuration information in the ARXML file shown in Table 1 above, the composite software component and the send-receive interface can be regarded as configuration items, and the detailed configuration content corresponding to the composite software component and the send-receive interface (such as the name and detailed information in Table 1 above) can be regarded as configuration parameters corresponding to the configuration items. Based on this, the dependency relationship between the configuration items is exemplarily described below:

[0042] Usage dependency: The Odometer component depends on the vehicle speed data provided by the SpeedCalc component. The functions of the Odometer component (such as calculating mileage, etc.) need to be based on accurate vehicle speed data, and obtain data from the VehicleSpeed ​​provided port of the SpeedCalc component through the VehicleSpeed ​​required port.

[0043] Implementation Dependencies: The above composite software components all depend on the definition of the VehicleSpeedInterface interface. If the definition of VehicleSpeedInterface changes, such as a data type change or an interface behavior adjustment, then both SpeedCalc and Odometer components need to be updated accordingly. For example, if the data type of VehicleSpeed ​​is changed from UInt16 to UInt32, then the content of the SpeedCalc component that provides data and the content of the Odometer component that receives and processes data need to be updated to adapt to the new data type.

[0044] As mentioned above, when verifying an ARXML file, verifying the logical information such as the dependency between configuration items in the ARXML file is crucial to ensuring the correctness, integrity, and stability of the software architecture. However, currently, the logical information such as the dependency between configuration items can only be verified by technical personnel, which takes a lot of time. In this way, it is difficult to further reduce the difficulty of verification and improve the efficiency of verification.

[0045] In order to solve the above problems, an embodiment of the present application provides a verification method, which can convert the ARXML file to be verified into a visual graphic file, and display the logical information such as the dependency relationship between the configuration items in the ARXML file to be verified through the graphic file, so as to facilitate the user to verify the consistency between the ARXML file and the designed software architecture. Specifically, the method can obtain the ARXML file to be verified, and then extract the ARXML fragment to be verified in the ARXML file to be verified, further generate the PlantUML code corresponding to the ARXML fragment to be verified, and generate the corresponding UML diagram based on the PlantUML code. It can be understood that the UML diagram can intuitively display the logical information such as the dependency relationship between the configuration items, so it can improve the efficiency of verifying the ARXML fragment and reduce the difficulty of verifying the ARXML fragment, and then can significantly improve the verification efficiency of the designed software architecture and reduce the difficulty of verification.

[0046] Figure 2 A logical architecture diagram of the verification method according to an embodiment of the present application is shown.

[0047] like Figure 2 As shown, technicians can convert the PlantUML code file (source architecture description file) into the corresponding UML diagram, and then obtain the ARXML file to be verified based on the UML diagram. Figure 1 The relevant description is not repeated here. The following mainly introduces the verification process of ARXML files.

[0048] Continue reading Figure 2 In the embodiment of the present application, there is no need for technical personnel to verify the ARXML file. Instead, the ARXML file is input into the ARXML file visualization and automatic verification system, and the system is used to realize the automatic and visual review of the ARXML file.

[0049] It can be understood that in some embodiments, the ARXML file visualization and automated verification system may be used only to implement visual review of ARXML files, or may be used only to implement automated review of ARXML files, and this application does not limit this.

[0050] The ARXML file visualization and automated verification system can be used to implement visual review of ARXML files. Specifically, the ARXML file visualization and automated verification system can generate the PlantUML code (architecture description file to be verified) corresponding to the ARXML file. The PlantUML code can be used to generate UML diagrams. The UML diagrams can intuitively display logical information such as the dependencies between configuration items in the ARXML file. This makes it easier for technicians to quickly determine whether the ARXML file complies with the software architecture design, which can significantly improve verification efficiency.

[0051] The ARXML file visualization and automated verification system can be used to realize the automated review of ARXML files. Specifically, the ARXML file visualization and automated verification system can automatically identify non-compliance issues in ARXML files (such as whether special instructions are called according to the rules) based on the input design specifications, and output a verification report. In this way, part of the manual review work can be automated to improve the efficiency of code review.

[0052] In addition, technicians can also input files in the form of PlantUML code (source architecture description files) into the view style recognition module. The view style recognition module can determine what type of UML diagram is used in the software architecture design based on the PlantUML code, that is, the type of UML diagram directly converted based on the source architecture description file, as well as key information such as the functional modules included in the software architecture.

[0053] The ARXML file visualization and automated verification system can obtain the above key information (the type of UML diagram, the functional modules included in the software architecture). In this way, when generating the PlantUML code corresponding to the ARXML file, the form of the generated PlantUML code can be made to conform to the code form required to generate the corresponding UML diagram type, so as to ensure that the type of the generated UML diagram is close to the type of the UML diagram directly converted based on the source architecture description file, which is convenient for manual confirmation.

[0054] Combine the following Figure 3 The verification method of the embodiment of the present application is introduced to realize the visual review process of ARXML files. Figure 3 According to some embodiments of the present application, a logical architecture diagram of visual auditing is shown.

[0055] like Figure 3 As shown, the ARXML file visualization and automatic verification system may include a text preprocessing module and a large language model. The text preprocessing module is used to receive the ARXML file to be verified and output the ARXML fragment in the ARXML file to the large language model.

[0056] It is understandable that the ARXML files to be verified are generally large in number and have a large amount of code. If they are directly input into the large language model for processing, the context will be too large, thereby reducing the accuracy of the output results of the large language model. Therefore, the irrelevant content in the ARXML file is filtered out through the text preprocessing module to obtain ARXML fragments. The large language model does not need to process all ARXML files, but only needs to process ARXML fragments with smaller data volume, which can improve the accuracy of the output results.

[0057] Specifically, the text preprocessing module can obtain the filtering rules from the view style recognition module, and then process the ARXML file according to the filtering rules to obtain the ARXML fragment. The filtering rules may include the target functional module to be verified and the related target configuration items. In this way, the obtained ARXML fragment can be a code fragment related to the target configuration item of the target functional module. The algorithm for extracting the ARXML fragment can use traditional regular expression retrieval, which is not limited in this application.

[0058] The Large Language Model (LLM) can obtain the ARXML fragment from the text preprocessing module, and then generate the corresponding PlantUML code based on the ARXML fragment, and then further convert the PlantUML code into a picture format through the UML design tool to obtain a UML diagram (the first graphic file mentioned in this application). It is convenient for manual review. The large language model can also obtain the type of UML diagram from the view style recognition module to ensure that the generated PlantUML code can be converted into a UML diagram of this type.

[0059] It can be understood that in the above-mentioned solution of finally presenting the ARXML file to be verified in the form of a UML diagram to achieve visual audit, since the UML diagram can intuitively display logical information such as the dependencies between configuration items, the technician can discover potential performance problems and architectural defects of the designed software architecture during the process of checking the generated UML diagram. For example, if the dependencies between components are too complex (for example, there are multiple layers of nested dependencies), it may lead to increased system response time or resource competition. For another example, if there are close dependencies between components (for example, one component frequently calls the interface of another component), it may make the system difficult to expand or optimize. For another example, if a component depends on the interface provided by another component, and the performance of the interface is low (for example, long response time or low data transmission efficiency), it may lead to a decrease in overall performance.

[0060] Combine the following Figure 4 The verification method of the embodiment of the present application is introduced to realize the automated review process of ARXML files. Figure 4 According to some embodiments of the present application, a logical architecture diagram of automated review is shown.

[0061] like Figure 4 As shown in the figure, the pre-process of automated review, that is, the process of processing ARXML files by the text preprocessing module in combination with filtering rules and outputting ARXML fragments to the large language model, can be referred to Figure 3 The relevant description will not be repeated here.

[0062] Automated review mainly checks the above ARXML fragments through the large language model. Specifically, the design specifications related to the software architecture are input into the large language model, and the large language model can automatically detect whether there is any content in the ARXML fragment that does not comply with the design specifications, and then output a verification report. For example, in the AUTOSAR architecture, RTE (Runtime Environment) is a bridge between the application layer (Application Layer) and the basic software layer (such as the complex driver layer CDD, etc.). The design specifications stipulate that the application layer function module must call the CDD module through RTE. If there is a software component (Software Component) in the application layer function module in the ARXML fragment that directly calls the CDD module without going through RTE, this situation can be detected by the large language model and reflected in the verification report.

[0063] In this way, the ARXML fragments are automatically checked through a large language model, which greatly saves the workload of technical personnel in traditional verification methods, and can significantly improve the verification efficiency of the designed software architecture and reduce the difficulty of verification.

[0064] The verification method of the embodiment of the present application can be applied to electronic devices. Figure 5 The following are steps of the verification method according to the embodiment of the present application, which may include:

[0065] S501: The electronic device obtains a program file to be verified, where the program file to be verified includes multiple configuration items, and the multiple configuration items correspond to different functional modules.

[0066] In an embodiment of the present application, the program file to be verified may be the ARXML file described above. The ARXML file contains multiple configuration items, and the multiple configuration items correspond to different functional modules. For example, in an ARXML file shown in Table 1 above, the composite software components SpeedCalc and Odometer, and the send-receive interface VehicleSpeedInterface are all configuration items, involving multiple functional modules such as the engine control module (ECM), the transmission control module (TCM), and the body control module (BCM). In another ARXML file, multiple configuration items different from the composite software components SpeedCalc and Odometer, and the send-receive interface VehicleSpeedInterface described above, but involving other functional modules such as the engine control module (ECM), the transmission control module (TCM), and the body control module (BCM) may also be included.

[0067] In some embodiments, the program file to be verified is generated based on a source architecture description file of the corresponding software, for example, an ARXML file is generated based on a file in the form of PlantUML code.

[0068] Therefore, before the above step S501, the method further includes the following steps: the electronic device obtains a source architecture description file (e.g., a file in the form of PlantUML code); using a drawing tool based on the unified modeling language (UML design tool), a UML diagram (the second graphic file mentioned in this application) corresponding to the source architecture description file is generated. It can be understood that the UML diagram can describe the software architecture information in the form of a graphic, including multiple configuration items involved in the software, and the association relationship between the multiple configuration items, that is, the dependency relationship between the configuration items and other logical information.

[0069] Accordingly, the above step S501 may include: the electronic device generates an intermediate format (eg XML) file corresponding to the UML diagram using a UML design tool, and then obtains an ARXML file corresponding to the XML file using a dedicated configuration tool (eg AUTOSAR Builder).

[0070] S502: The electronic device selects a plurality of target configuration items corresponding to the target functional module from the plurality of configuration items, and intercepts a program segment to be verified from the program file to be verified according to the plurality of target configuration items.

[0071] As mentioned above, the ARXML files to be verified are generally large in number and have large amounts of code. However, the actual content to be verified each time is not much, so multiple target configuration items corresponding to the target functional module can be screened out by the electronic device, and then the program fragment to be verified can be intercepted from the program file to be verified according to the multiple target configuration items.

[0072] For example, referring to the above Figure 2 or Figure 3 Related description, the electronic device can determine the filtering rules through the view style recognition module, and then filter the ARXML file through the text preprocessing module according to the filtering rules to obtain ARXML fragments, which are program fragments to be verified related to multiple target configuration items corresponding to the target functional module.

[0073] S503: The electronic device generates a first graphic file corresponding to the program fragment to be verified. The first graphic file can describe the association relationship between multiple target configuration items in the form of a graphic.

[0074] In the embodiment of the present application, the electronic device can convert the program fragment to be verified into a description file of the architecture to be verified based on the unified modeling language through the large language model; then, a drawing tool of the unified modeling language, such as a UML design tool, is used to generate a graphic file corresponding to the description file of the architecture to be verified. The graphic file corresponding to the description file of the architecture to be verified is the first graphic file.

[0075] For example, referring to the above Figure 3 Related description, the electronic device converts the ARXML fragment into the corresponding PlantUML code through the large language model, and then further converts the PlantUML code into a picture format through the UML design tool to obtain a UML diagram.

[0076] In some embodiments, the electronic device converts the program fragment to be verified into an architecture description file to be verified based on the unified modeling language through a large language model. Specifically, it may include: the electronic device inputs the type of the program fragment to be verified and the graphic file to be drawn into the large language model, and then converts the program fragment to be verified into the architecture description file to be verified through the large language model. The architecture description file to be verified can be used to generate a graphic file of the type of the graphic file to be drawn.

[0077] The type of the graphic file to be drawn can refer to the type of UML diagram mentioned above. Figure 2 Related description, the electronic device can identify the PlantUML code through the view style recognition module to determine the type of UML diagram used in the software architecture design, that is, the type of UML diagram (second graphic file) converted based on the source architecture description file.

[0078] In this way, when the large language model converts the ARXML fragment into the corresponding PlantUML code, according to the type of the UML diagram, the form of the generated PlantUML code can be made to conform to the code form required for generating the type of the UML diagram, so as to ensure that the type of the generated UML diagram (first graphic file) is close to the type of the second graphic file, which is convenient for manual comparison to confirm the similarities and differences between the first graphic file and the second graphic file.

[0079] It can be understood that, in some embodiments, the verification method further includes: the electronic device verifies the standardization of the program fragment to be verified through a large language model, and outputs a verification result.

[0080] For example, refer to Figure 4 Related description, the electronic device can input the design specifications related to the software architecture into the large language model, and then automatically detect the content in the ARXML fragment that does not meet the design specifications through the large language model, and then output a verification report.

[0081] Specifically, the electronic device obtains a design specification file of the software architecture, which includes configuration rules related to configuration items; then, the design specification file and the program fragment to be verified are input into the large language model, and the configuration information of each target configuration item in the program fragment to be verified is verified with the configuration rules through the large language model to obtain a verification result of whether each target configuration item satisfies the configuration rules.

[0082] For example, the configuration rules related to the configuration items include that the application layer function module must call the CDD module through RTE. If the large language model detects that a component in the configuration information of the target configuration item does not pass RTE, the CDD module is directly called, and the verification result that the target configuration item does not meet the configuration rules is output.

[0083] It should be noted that this application does not limit the configuration rules in the design specification file and can be set according to actual applications.

[0084] S504: The electronic device displays a first graphic file for the user to verify configuration information of the multiple target configuration items, where the configuration information at least includes associations between the multiple target configuration items.

[0085] In the embodiment of the present application, the first graphic file is a UML diagram. The electronic device finally presents the ARXML file to be verified as a UML diagram. The UML diagram intuitively displays the relationship between multiple target configuration items. In this way, technicians can quickly discover potential performance problems and architectural defects of the designed software architecture.

[0086] In summary, the verification method provided in the embodiment of the present application can finally present the ARXML file to be verified in a UML diagram through an electronic device, and can also automatically review non-compliance issues in the ARXML file, which can improve the efficiency of verifying ARXML fragments and reduce the difficulty of verifying ARXML fragments, thereby significantly improving the verification efficiency of the designed software architecture and reducing the difficulty of verification.

[0087] In addition, an embodiment of the present application also provides an electronic device, including: one or more memories; one or more memories storing one or more programs, when one or more programs are executed by one or more processors, the above-mentioned electronic device executes the verification method provided in the above-mentioned first aspect and various possible implementations of the first aspect.

[0088] In addition, an embodiment of the present application also provides a computer-readable medium, on which instructions are stored. When the instructions are executed on an electronic device, the electronic device executes the verification method provided in the first aspect and various possible implementations of the first aspect.

[0089] In addition, an embodiment of the present application also provides a computer program product, which includes computer instructions. When executed by an electronic device, the electronic device executes the verification method provided in the first aspect and various possible implementations of the first aspect.

[0090] Figure 6 According to an embodiment of the present application, a structural schematic diagram of an electronic device 10 is provided.

[0091] like Figure 6 As shown, in some embodiments, the electronic device 10 may include one or more processors 1004, a system control logic 1008 connected to at least one of the processors 1004, a system memory 1012 connected to the system control logic 1008, a non-volatile memory (NVM) 1016 connected to the system control logic 1008, and a network interface 1020 connected to the system control logic 1008.

[0092] In some embodiments, processor 1004 may include one or more single-core or multi-core processors. In some embodiments, processor 1004 may include any combination of general-purpose processors and special-purpose processors (eg, graphics processors, application processors, baseband processors, etc.).

[0093] In some embodiments, system control logic 1008 may include any suitable interface controller to provide any suitable interface to at least one of processors 1004 and / or any suitable device or component in communication with system control logic 1008 .

[0094] In some embodiments, the system control logic 1008 may include one or more memory controllers to provide an interface to the system memory 1012. The system memory 1012 may be used to load and store data and / or instructions. In some embodiments, the memory 1012 of the electronic device 10 may include any suitable volatile memory, such as a suitable dynamic random access memory (DRAM).

[0095] The non-volatile memory 1016 may include one or more tangible, non-transitory readable storage media for storing data and / or instructions. In some embodiments, the non-volatile memory 1016 may include any suitable non-volatile memory such as flash memory and / or any suitable non-volatile storage device, such as at least one of a hard disk drive (HDD), a compact disc (CD) drive, and a digital versatile disc (DVD) drive.

[0096] The non-volatile memory 1016 may include a portion of storage resources on the device on which the electronic device 10 is installed, or it may be accessible by the device but is not necessarily a portion of the device. For example, the non-volatile memory 1016 may be accessed via the network interface 1020 over a network.

[0097] In particular, the system memory 1012 and the non-volatile memory 1016 may include: a temporary copy and a permanent copy of the instruction 1024. The instruction 1024 may include: when executed by at least one of the processors 1004, causing the electronic device 10 to implement the above-mentioned Figure 5 In some embodiments, instructions 1024, hardware, firmware, and / or software components thereof may additionally / alternatively be placed in system control logic 1008, network interface 1020, and / or processor 1004.

[0098] The network interface 1020 may include a transceiver for providing a radio interface for the electronic device 10 to communicate with any other suitable device (such as a front-end module, an antenna, etc.) through one or more networks. In some embodiments, the network interface 1020 may be integrated with other components of the electronic device 10.

[0099] The network interface 1020 may further include any suitable hardware and / or firmware to provide a multiple-input multiple-output radio interface. For example, the network interface 1020 may be a network adapter, a wireless network adapter, a telephone modem and / or a wireless modem.

[0100] In one embodiment, at least one of the processors 1004 may be packaged with logic for one or more controllers of the system control logic 1008 to form a system in package (session initiation protocol, SiP). In one embodiment, at least one of the processors 1004 may be integrated on the same die with logic for one or more controllers of the system control logic 1008 to form a system on chip (SoC).

[0101] The electronic device 10 may further include an input / output (I / O) device 1032. The I / O device 1032 may include a user interface to enable a user to interact with the electronic device 10; the design of a peripheral component interface enables peripheral components to also interact with the electronic device 10. In some embodiments, the electronic device 10 further includes a sensor for determining at least one of an environmental condition and location information related to the electronic device 10.

[0102] In some cases, the disclosed embodiments may be implemented in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried or stored on one or more temporary or non-temporary machine-readable (e.g., computer-readable) storage media, which may be read and executed by one or more processors. For example, instructions may be distributed over a network or through other readable media. Therefore, a machine-readable medium may include any mechanism for storing or transmitting information in a machine (e.g., computer) readable form, including, but not limited to, a floppy disk, an optical disk, an optical disk, a magneto-optical disk, a read-only memory (ROM), a random access memory (RAM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic card or an optical card, a flash memory, or a tangible machine-readable memory for transmitting information (e.g., a carrier wave, an infrared signal, a digital signal, etc.) using the Internet in an electrical, optical, acoustic, or other form of propagation signal. Accordingly, machine-readable media include any type of machine-readable media suitable for storing or transmitting electronic instructions or information in a form readable by a machine (eg, a computer).

[0103] References to "one embodiment" or "an embodiment" in the specification mean that the specific features, structures, or characteristics described in conjunction with the embodiment are included in at least one exemplary implementation or technology disclosed according to the embodiment of the present application. The appearance of the phrase "in one embodiment" in various places in the specification does not necessarily all refer to the same embodiment.

[0104] The disclosure of the embodiment of the present application also relates to an operating device for executing the text. The device can be specially constructed for the required purpose or it can include a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program can be stored in a computer-readable medium, such as, but not limited to any type of disk, including a floppy disk, an optical disk, a CD-ROM, a magneto-optical disk, a read-only memory (ROM), a random access memory (RAM), an EPROM, an EEPROM, a magnetic or optical card, an application-specific integrated circuit (ASIC) or any type of medium suitable for storing electronic instructions, and each can be coupled to a computer system bus. In addition, the computer mentioned in the specification may include a single processor or may be an architecture involving multiple processors for increased computing power.

[0105] In addition, the language used in this specification has been primarily selected for readability and instructional purposes and may not be selected to describe or limit the disclosed subject matter. Therefore, the present application embodiment disclosure is intended to illustrate rather than limit the scope of the concepts discussed herein.

Claims

1. A verification method, applied to an electronic device, characterized in that: The method comprises: Obtaining a program file to be verified, wherein the program file to be verified includes multiple configuration items, and the multiple configuration items correspond to different functional modules; Screening a plurality of target configuration items corresponding to the target functional module from the plurality of configuration items, and intercepting a program fragment to be verified from the program file to be verified according to the plurality of target configuration items; Generate a first graphic file corresponding to the program fragment to be verified, wherein the first graphic file can describe the association relationship between the multiple target configuration items in the form of a graphic; The first graphic file is displayed for a user to verify configuration information of the plurality of target configuration items, wherein the configuration information at least includes association relationships between the plurality of target configuration items.

2. The verification method according to claim 1, characterized in that: The step of generating a first graphic file corresponding to the program fragment to be verified includes: Converting the program fragment to be verified into a description file of the architecture to be verified based on the unified modeling language through a large language model; A drawing tool based on the unified modeling language is used to generate a graphic file corresponding to the architecture description file to be verified, where the graphic file corresponding to the architecture description file to be verified is the first graphic file.

3. The method according to claim 2, characterized in that The program file to be verified is generated based on a source architecture description file of the corresponding software, and the source architecture description file adopts the unified modeling language; Before obtaining the program file to be verified, the method further includes: Obtaining the source architecture description file; Generate a second graphic file corresponding to the source architecture description file by using a drawing tool based on the unified modeling language, wherein the second graphic file can describe the architecture information of the corresponding software in the form of a graphic, wherein the architecture information includes the multiple configuration items involved in the software and the association relationship between the multiple configuration items; The step of obtaining the program file to be verified includes: The program file to be verified is generated based on the second graphic file or the source architecture description file.

4. The method according to claim 3, characterized in that Before generating the first graphic file corresponding to the program fragment to be verified, the method further includes: Based on the source architecture description file, a type of the graphics file to be drawn is determined, and the type of the graphics file to be drawn is the type of the second graphics file.

5. The method according to claim 4, characterized in that The method of converting the program fragment to be verified into a description file of the architecture to be verified based on the unified modeling language by using the large language model includes: Inputting the types of the program fragment to be verified and the graphic file to be drawn into the large language model, The program fragment to be verified is converted into the architecture description file to be verified through the large language model, and the architecture description file to be verified can be used to generate a graphic file of the type of the graphic file to be drawn.

6. The method according to claim 2, characterized in that The method further comprises: The large language model is used to verify the standardization of the program fragment to be verified, and a verification result is output.

7. The method according to claim 6, characterized in that The method of verifying the standardization of the program fragment to be verified by using the large language model and outputting the verification result includes: Obtaining a design specification file, wherein the design specification file includes configuration rules related to the configuration item; Inputting the design specification file and the program fragment to be verified into the large language model, The configuration information of each of the target configuration items in the program fragment to be verified is verified with the configuration rules through the large language model to obtain a verification result of whether each of the target configuration items satisfies the configuration rules.

8. An electronic device, characterized in that: The device comprises one or more processors; one or more memories; the one or more memories store one or more programs, and when the one or more programs are executed by the one or more processors, the device executes the verification method described in any one of claims 1 to 7.

9. A computer-readable medium, characterized in that The readable medium stores instructions, which, when executed on an electronic device, enable the electronic device to execute the verification method according to any one of claims 1 to 7.

10. A computer program product, characterized in that The program product comprises computer instructions, and when executed by an electronic device, the electronic device performs the verification method according to any one of claims 1 to 7.

Images