Code development synchronization method and device, equipment and storage medium
By updating the model in the development of autonomous driving system to match the target code, the problem of inconsistency with the model after the code is modified is solved, and development efficiency is improved.
Patent Information
- Application Number
- CN202411560337.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-04
- Publication Date
- 2025-02-11
AI Technical Summary
During the development of autonomous driving systems, the inconsistency between code modification and model has seriously reduced the development efficiency, and programmers need to negotiate with demand personnel and model designers to complete information synchronization.
By obtaining the target code, updating the first model based on the code, generating the second model, and pushing it to the user terminal, synchronizing the code and the model.
It solves the problem of inconsistent with the model after code modification, shortens the development iteration process, and improves the efficiency of code development.
Smart Images
Figure CN119415133A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of autonomous driving, and in particular to a code development synchronization method, device, equipment and storage medium. Background Art
[0002] Model-driven development is a model-based software engineering method that aims to reduce the coding time and effort required to automatically generate source code from models. Models are converted into real systems through model transformation, and compilable running code is generated. In the field of traditional automotive software development, model-driven development methods are widely used.
[0003] In the actual application process, in order to speed up the iteration speed, the code may be temporarily modified, resulting in inconsistency between the code form and the model information. Information synchronization can only be completed after consultation between programmers, requirements personnel and model designers. This process seriously reduces development efficiency.
[0004] Therefore, how to improve the efficiency of code development is an urgent problem to be solved. Summary of the invention
[0005] The present application provides a code development synchronization method, apparatus, device and storage medium to improve the code development efficiency of an autonomous driving system.
[0006] In a first aspect, an embodiment of the present application provides a code development synchronization method, including:
[0007] Obtaining a target code, wherein the target code is obtained by modifying a service framework code generated based on a first model, wherein the first model is used to represent an interaction mode between components in a vehicle open architecture;
[0008] According to the target code, the first model is updated to obtain a second model;
[0009] The second model is pushed to a preset user terminal.
[0010] In a possible implementation, the method further includes:
[0011] Acquire a third model obtained by modifying the first model;
[0012] Correspondingly, the updating of the first model according to the target code to obtain the second model includes:
[0013] The first model is updated according to the target code and the third model to obtain the second model.
[0014] In a possible implementation manner, updating the first model according to the target code and the third model to obtain the second model includes:
[0015] Parsing the target code into a first script in a natural language;
[0016] generating a second script in natural language according to the third model;
[0017] Merge the second script and the first script and perform deduplication processing to obtain a third script;
[0018] The second model is determined according to the third script.
[0019] In a possible implementation manner, determining the second model according to the third script includes:
[0020] Determine a graph structure of the third script according to the associated service types between the components in the third script and the node type of each component in the associated service type, wherein the graph structure is used to represent the associated relationship between the components in a plan view;
[0021] The graph structure is rendered into the second model using a preset modeling tool.
[0022] In a possible implementation, the method further includes:
[0023] Parsing the service framework code of the first model into a fourth script in a natural language;
[0024] generating a fifth script in natural language according to the first model;
[0025] A consistency comparison is performed based on the fourth script and the fifth script to determine whether the service framework code is correct.
[0026] In a possible implementation, the performing consistency comparison according to the fourth script and the fifth script to determine whether the service framework code is correct includes:
[0027] Processing the fourth script by using a preset natural language processing model to obtain a text vector of the fourth script;
[0028] Processing the fifth script by the natural language processing model to obtain a text vector of the fifth script;
[0029] determining semantic similarity between the text vector of the fourth script and the text vector of the fifth script;
[0030] If the semantic similarity is greater than a preset similarity, it is determined that the service framework code is correct.
[0031] In one possible implementation, the content of any script includes: an associated service type between two components, and a node type of each component in the associated service type; wherein the associated service type includes a subscription publishing service and a request response service, and the node type includes: a subscription node, a publishing node, a request node, and a response node.
[0032] In a second aspect, the present application provides a code development synchronization device, the device comprising:
[0033] An acquisition module, used for acquiring a target code, wherein the target code is obtained by modifying a service framework code generated based on a first model, wherein the first model is used for representing an interaction mode between components in a vehicle open architecture;
[0034] A synchronization module, used for updating the first model according to the target code to obtain a second model;
[0035] A sending module is used to push the second model to a preset user terminal.
[0036] In a third aspect, the present application further provides an electronic device, comprising: a memory, a processor;
[0037] The memory stores computer-executable instructions;
[0038] The processor executes the computer-executable instructions stored in the memory, so that the processor executes the above first aspect and / or various possible implementations of the first aspect.
[0039] In a fourth aspect, the present application also provides a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, they are used to implement the above first aspect and / or various possible implementations of the first aspect.
[0040] In a fifth aspect, the present application also provides a computer program product, including a computer program, which, when executed by a processor, implements the above first aspect and / or various possible implementations of the first aspect.
[0041] The present application provides a code development synchronization method, device, equipment and storage medium, the method comprising: obtaining a target code, the target code is obtained by modifying a service framework code generated based on a first model, the first model is used to represent the interaction mode between components in a vehicle open architecture; according to the target code, the first model is updated to obtain a second model; the second model is pushed to a preset user terminal. In this way, a model synchronization method is introduced into the development process of a model-driven autonomous driving system, and the upstream model information and downstream information are updated in time after the service framework code is modified to complete the synchronization, solve the problem of inconsistency between the code and the model after the code is modified, shorten the development iteration process and improve the efficiency of code development. BRIEF DESCRIPTION OF THE DRAWINGS
[0042] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.
[0043] Figure 1 Develop a process diagram for a model-driven automated driving system;
[0044] Figure 2 A schematic diagram of the development process for modifying code during the development of a model-driven autonomous driving system;
[0045] Figure 3 Schematic diagram of the code development synchronization method provided for this application Figure 1 ;
[0046] Figure 4 Schematic diagram of the code development synchronization method provided for this application Figure 2 ;
[0047] Figure 5 A schematic diagram of the development process of an autonomous driving system optimized by combining the model synchronization method with agile development thinking provided in this application;
[0048] Figure 6 A schematic diagram of the structure of a code development synchronization device provided by this application;
[0049] Figure 7 A schematic diagram of the structure of the electronic device provided in this application.
[0050] The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION
[0051] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.
[0052] Model-driven development is a model-based software engineering approach that aims to reduce the coding time and effort required to automatically generate source code from models. Model-driven development is a development process based on model-driven architecture, which is a software architecture that uses model simulation as its main specification representation. It converts models into real systems through model transformation and generates compilable and runnable source code. In the field of traditional automotive software development, model-driven development methods are widely used, such as body control systems based on Autosar CP, chassis control systems, and autonomous driving systems based on Autosar AP.
[0053] Component-based architecture is a method of creating systems using blocks, each with a well-defined function that interacts with other blocks through interfaces so that each block can contribute to the whole. Each component can be independently developed, tested, and maintained, but together they form a complete system.
[0054] In an autonomous driving system based on model-driven development, the model is mainly the construction of a service-oriented architecture, which mainly involves the design and implementation of services, customers, and the connections between them.
[0055] Figure 1 This is a schematic diagram of the development process of a model-driven autonomous driving system. During the development process of a model-driven autonomous driving system, the processes must be executed sequentially, and the development efficiency is relatively low.
[0056] In the process of developing an autonomous driving system based on a model-driven architecture, certain operations are performed in a jumpy manner, such as temporarily modifying the code to speed up iteration, which will cause the code format to be inconsistent with the model information. Figure 2 The following is a schematic diagram of the development process for modifying code during the development of a model-driven autonomous driving system. Figure 2 As shown in the figure, after the service framework code is modified, the code change causes inconsistency with the model information. At this time, programmers need to negotiate with demand personnel and model designers to complete information synchronization. This process seriously reduces development efficiency.
[0057] In view of this, the present application provides a code development synchronization method, in which the user makes modifications based on the service framework code generated by the model, parses and reversely renders the modified code into a model, and performs reverse synchronization and downstream synchronization. In this way, the service framework code developers, the model developers before the service framework code, and the functional code developers after the service framework code complete the synchronization, thereby improving development efficiency.
[0058] The execution entity of this application can be a cloud server or a terminal device on the user side, such as a computer.
[0059] The following takes the execution subject as a cloud server as an example, and describes in detail the technical solution of the present application and how the technical solution of the present application solves the above technical problems with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.
[0060] Figure 3 Schematic diagram of the code development synchronization method provided for this application Figure 1 ,like Figure 3 As shown, the method includes:
[0061] S101. Obtain a target code, where the target code is obtained by modifying a service framework code generated based on a first model, and the first model is used to represent the interaction mode between components in a vehicle open architecture.
[0062] In the code development of autonomous driving, after the system collects and analyzes the requirements, it can use visual methods to edit and design models, input the determined model into the code generator to generate service framework code, and the service framework code can generate the corresponding simple service language representation through the parser. The construction of the model can be visual. The user drags certain component blocks on the visual interface to generate the model and establish the interaction between component blocks. Each component block has a clearly defined function and interacts with other blocks through the interface.
[0063] In this step, the developer modifies the service framework code generated in the code generator (i.e., the source code before the target code is modified) to obtain the modified target code. The developer inputs the target code into the cloud server.
[0064] S102: Update the first model according to the target code to obtain a second model.
[0065] In one implementation, the first model is updated only according to the target code. Specifically, the target code is first parsed into a natural language script, and the second model is generated by rendering according to the parsed natural language script. The core functions and logic are extracted from the target code, such as the relationship between functions, classes and modules. Based on the extracted functions, a natural language description is generated to clearly explain the role of each component and their relationship with each other. Developers can use visualization tools to render the second model. The format structure of the second model is similar to that of the first model, and both show the function of each component and the interaction between components to ensure that the input and output of each module are correctly connected.
[0066] In one implementation, when generating the second model, not only the update of the target code should be considered, but also the possibility of updating the first model should be considered. The second model is generated by combining the first model and the target code. The specific combination will be introduced in subsequent embodiments.
[0067] S103: Push the second model to a preset user terminal.
[0068] In this step, the second model generated is the updated model, which is issued in the system and pushed to the relevant user terminal. The service framework code is generated in the system through the code generator and pushed to the relevant user terminal. Subsequent developers can develop, test and modify the functional application code on the updated service framework code.
[0069] This embodiment provides a code development synchronization method, which includes: obtaining a target code, which is obtained by modifying a service framework code generated based on a first model, and the first model is used to represent the interaction mode between components in a vehicle open architecture; updating the first model according to the target code to obtain a second model; and pushing the second model to a preset user terminal. In this way, a model synchronization method is introduced into the model-driven autonomous driving system development process, and the upstream model information and downstream information are updated in time after the service framework code is modified to complete the synchronization, solve the inconsistency problem between the code and the model after the code is modified, shorten the iteration process and improve the code development efficiency.
[0070] The following is a detailed introduction with several examples.
[0071] Figure 4 Schematic diagram of the code development synchronization method provided for this application Figure 2 ,like Figure 4 As shown:
[0072] Step 1: During the autonomous driving code development process, model 1 is used to generate code 1 through a code generator.
[0073] Step 2: Parse code 1 to generate a script in simple service language 1# (ie, the fourth script).
[0074] Among them, the simple service language can be a natural language, and the content of the generated script includes: the associated service type between two components, and the node type of each component in the associated service type; among them, the associated service type includes subscription and publishing services and request and response services, and the node types include: subscription nodes, publishing nodes, request nodes and response nodes.
[0075] The specific process of generating a script according to code 1 is as follows:
[0076] a. Service Definition
[0077] Based on the traffic behavior of the service, two common services used in autonomous driving systems are defined, namely publish-subscribe and request-response, where the publish / respond end is considered the server and the subscribe / request end is considered the client. The publish-subscribe service is a one-way communication from the server to the client, while the request-response service is a two-way communication between the server and the client.
[0078] This statement creates a service named @service-name, where the service content indicates that one or more services can be defined. For publish-subscribe services, users need to define the publishing method and publishing parameters. The publishing strategy can be event publishing or cyclic publishing. For event publishing strategy, users need to define the event trigger mechanism, and for cyclic publishing strategy, users need to define the cyclic publishing cycle.
[0079] For request-subscribe services, users need to define the request method and request parameters.
[0080] In the design of autonomous driving systems, publish-subscribe services are more commonly used.
[0081] b. Create a node
[0082] create @node-name node; This statement creates a node, which can be a service node or a client node, depending on the out-degree and in-degree of the node. If the node has only in-degree, then the node is a client node. If the node has only out-degree, then the node is a service node. If the node has both out-degree and in-degree, then the node is both a service node and a client node.
[0083] c. Establish directed links
[0084] create @link-name link @node-name and @another-node-name
[0085] This statement creates a link named @link-name, where @node-name is the server node and @another-node-name is the client node.
[0086] d. Related Services
[0087] attach @link-name to @service-name
[0088] This statement associates the @service-name service to the @link-name link. If the associated service is a subscription-publish service, then @node-name is the publishing node and @another-node-name is the subscription node; if the associated service is a request-response service, then @node-name is the response node and @another-node-name is the request node.
[0089] e. Remove associated services
[0090] detache @service-name from @link-name
[0091] This statement removes the associated @service-name service from the @link-name link.
[0092] Step 3: Represent model 1 using a script of simple service language 1 (i.e., the fifth script).
[0093] Identify each component in the model and its function. For each component, its input and output interfaces need to be clearly defined. Convert each component and its interface into a script described in natural language.
[0094] Step 4: Perform equivalence verification on the fourth script and the fifth script to determine whether the generated code 1 is correct.
[0095] In this step, the fourth script is processed by a preset natural language processing model (such as pre-trained models such as Word2Vec and GloVe), each word is converted into a vector, and then the vector of the entire sentence is obtained by summing or averaging, and finally the text vector of the fourth script is obtained; similarly, the fifth script is processed to obtain the text vector of the fifth script; the semantic similarity between the text vector of the fourth script and the text vector of the fifth script is determined, and the cosine similarity can be used; if the semantic similarity is greater than the preset similarity, it is determined that the service framework code is correct.
[0096] Step 6: Get the code 2 modified by the user.
[0097] Obtain code 2 after the user modifies code 1. The user may modify the association method of the components or the interface parameters, and there is no restriction on how to modify code 2.
[0098] Step 7: Parse code 2 into a script in simple service language 2#.
[0099] This step is similar to the way code 1 is parsed into simple service language 1# script, so it will not be repeated here.
[0100] Step 8: Generate model 2 according to the script of simple service language 2#.
[0101] In one implementation, based on the associated service types between the various components in the script of the simple service language 2# and the node type of each component in the associated service type, a graph structure corresponding to the script is determined, and the graph structure is used to represent the association relationship between the various components in the plan view; the graph structure is rendered as model 2 using a preset modeling tool.
[0102] The basic idea of the graph structure is to treat each component in the system as a node and the relationships between components (such as data transmission, calls, etc.) as edges. The graph structure clearly shows the interdependencies, data flows, and service types between components, making the system structure more intuitive and easy to understand. Users can also check and modify the graph structure.
[0103] Specifically, a graph node is created according to each component in the script, edges are added between nodes to represent the flow of data and the interdependence between components, and the corresponding service type (for example: reading, processing, execution) and node function are added to each node.
[0104] The graph structure is rendered using an open source modeling tool to generate model 2.
[0105] Through this process, certain operations can be performed in a jumpy manner during the development of an autonomous driving system based on a model-driven architecture, without having to start from the initial modification of the model. The development efficiency can be improved by reversely synchronizing the model after the user modifies the code.
[0106] In the actual development process, you may encounter a situation where the code developer modifies the code, while the model developer modifies the model. Therefore, it is necessary to comprehensively consider the modified target code and the modified model. The following is an example to introduce.
[0107] Figure 4 Schematic diagram of the code development synchronization method provided for this application Figure 2 ,like Figure 4 As shown:
[0108] Step 1: Get code 2 which is modified based on code 1.
[0109] Step 2: Obtain model 2 modified based on model 1.
[0110] The user modifies the connection mode or interface parameters of the components in model 1 through visual writing to obtain the model.
[0111] Step 3: Parse code 2 into a script in simple service language 2#.
[0112] Step 4: Represent model 2 as a script of simple service language 2.
[0113] Step 5: Merge the script of simple service language 2# and the script of simple service language 2 to obtain a merged script of simple service language 3.
[0114] In this step, the contents of the two scripts are identified, the repeated descriptions are determined, and duplicate removal is performed. The determination of the repeated contents can be performed through semantic recognition, and the association between the two components is determined. The two paragraphs do not need to be exactly the same.
[0115] For different contents, it is necessary to determine which one shall prevail. In one method, the user marks the modified content when modifying code 2, for example, the modified content is represented by a font of a preset modification color. The corresponding content is also represented in different colors when generating the script. For different contents (indicating that the association method or parameters between two components are different), when the script of Simple Service Language 2# is the preset modification color, it is determined that it is obtained by the user modifying the code, then the content corresponding to the script shall prevail, and the content corresponding to Model 2 shall be deleted. When the script of Simple Service Language 2# is the normal color, it means that the code has not modified this part, and it is obtained by modifying the model, and the content corresponding to Code 2 shall be deleted.
[0116] Thus, the merged simple service language 3 script can be obtained.
[0117] Step 6: Render as model 3 according to the script of simple service language 3.
[0118] In this step, the manner of rendering the script of the simple service language 3 into the model 3 is similar to that in the aforementioned embodiment, and will not be described in detail here.
[0119] Step 7: Generate code 3 based on model 3.
[0120] Finally, model 3 is used to generate code 3 through a code generator.
[0121] In one embodiment, the generated code 3 is pushed to a related user terminal for display, and the model 3 is pushed to a related user terminal for display.
[0122] In one embodiment, the generated code 3 and model 3 are displayed on the system interface for the user to download.
[0123] This example provides a composite model synchronization method, which can also achieve the synchronization of model and code when the model and code are modified at the same time. In the development activities of model-driven autonomous driving systems, changes in requirements and code modifications usually occur at the same time. For traditional development methods, the changes in the model caused by code changes cannot be passed back. At this time, programmers need to negotiate with the requirements personnel and model designers to complete information synchronization, which seriously reduces the development efficiency. The previous example has proposed a model synchronization method, which solves the problem of automatically passing the model changes back after the code changes, reduces communication costs, and improves development efficiency. The composite model synchronization method proposed in this example is based on the model synchronization method to solve the problem of bidirectional model synchronization caused by changes in requirements and changes in code. After model 1 generates code 1, the programmer modifies it to code 2 during the development and testing process. At the same time, the model designer modifies the model to model 2 through visual operations according to the changes in requirements. At this time, the information represented by model 2 and code 2 is inconsistent. Simple service language 2 is exported through model 2, and then simple service language 2# is parsed through code 2. Then simple service language 2 and simple service language 2# are merged into simple service language 3, and then simple service language 3 is rendered into model 3. Model 3 generates code 3, and finally the synchronization of model and code is completed. This method further simplifies communication costs and further promotes rapid iteration of code and model.
[0124] Agile software development is a development process about feedback and change, emphasizing that software development is an empirical or nonlinear process, in which short feedback loops are required to achieve ideal and predictable results. "Agile" means that in the software development process, we should respond to the changing environment and user needs as quickly as possible, and iterate quickly to solve problems.
[0125] The traditional model-driven autonomous driving system development process is a completely sequential execution process, which means that each time a new function is added, it needs to be redesigned from the demand, which makes the development efficiency very low. Through the model synchronization method, agile development thinking can be introduced into the traditional development process, so that development and testing problems can be quickly fed back, thereby improving the speed of development iteration, as follows Figure 5 shown.
[0126] Figure 5 A schematic diagram of optimizing the development process of an autonomous driving system by combining the model synchronization method with agile development thinking is provided for this application.
[0127] a. Demand
[0128] Here, demand collection and analysis can be carried out simultaneously with the subsequent processes.
[0129] b. Model design
[0130] Here, model design can also be carried out simultaneously with the subsequent processes. Model changes are mainly based on changes in requirements. At the same time, changes in code feedback can also be accepted to synchronize the model. If changes in requirements and code occur at the same time, composite model synchronization can be used.
[0131] c. Service framework code
[0132] The service skeleton code is generated from the model and can be parsed into a simple service language script.
[0133] d. Function / application code
[0134] Function / application code is the code for designing the upper-layer functions and application layer of autonomous driving, and cannot be parsed as a simple service language script. Users can design and modify function / application code.
[0135] e. Compile
[0136] This process compiles the service framework code and function / application code into a program file that can be executed on the target ECU.
[0137] f.ECU or virtual ECU
[0138] The domain controller where the autonomous driving program software runs or the domain controller simulated by the software. The domain controller simulated by the software is generally used in the testing process.
[0139] g. Testing
[0140] Conduct autonomous driving system software unit and system testing.
[0141] h. Feedback
[0142] Based on the feedback from the test results, users or automated programs can modify the code and perform rapid iterations to complete software functions or resolve bugs. Here, you can modify the service framework code or function / application code based on the feedback results.
[0143] Introducing agile development thinking into the model-driven autonomous driving system development process optimizes the development process from the process structure, speeds up iterations, and improves overall development efficiency.
[0144] By introducing agile development thinking and model synchronization methods into the model-driven autonomous driving system development process, the following beneficial effects can be achieved:
[0145] Compared with the development of autonomous driving systems based on model-driven architecture alone, the development efficiency is higher; visual development generates framework code, allowing users to focus on functional and application layer development, lowering the development threshold. Through the development model synchronization method, agile development thinking can be introduced into the model-driven development process.
[0146] Figure 6 A schematic diagram of the structure of a code development synchronization device provided in this application, such as Figure 6 As shown, the code development synchronization device 600 provided in this embodiment includes:
[0147] An acquisition module 601 is used to acquire a target code, where the target code is obtained by modifying a service framework code generated based on a first model, where the first model is used to represent the interaction mode between components in a vehicle open architecture;
[0148] A synchronization module 602, configured to update the first model according to the target code to obtain a second model;
[0149] The sending module 603 is used to push the second model to a preset user terminal.
[0150] Optionally, the acquisition module 601 is further used to acquire a third model obtained by modifying the first model;
[0151] Accordingly, the synchronization module 602 is specifically used for:
[0152] The first model is updated according to the target code and the third model to obtain the second model.
[0153] Optionally, the synchronization module 602 is further used for:
[0154] Parsing the target code into a first script in a natural language;
[0155] generating a second script in natural language according to the third model;
[0156] Merge the second script and the first script and perform deduplication processing to obtain a third script;
[0157] The second model is determined according to the third script.
[0158] Optionally, the synchronization module 602 is further used for:
[0159] Determine a graph structure of the third script according to the associated service types between the components in the third script and the node type of each component in the associated service type, wherein the graph structure is used to represent the associated relationship between the components in a plan view;
[0160] The graph structure is rendered into the second model using a preset modeling tool.
[0161] Optionally, the device further includes an equivalence comparison module 604, which is specifically configured to:
[0162] Parsing the service framework code of the first model into a fourth script in a natural language;
[0163] generating a fifth script in natural language according to the first model;
[0164] A consistency comparison is performed based on the fourth script and the fifth script to determine whether the service framework code is correct.
[0165] Optionally, the equivalent comparison module 604 is further used for:
[0166] Processing the fourth script by using a preset natural language processing model to obtain a text vector of the fourth script;
[0167] Processing the fifth script by the natural language processing model to obtain a text vector of the fifth script;
[0168] determining semantic similarity between the text vector of the fourth script and the text vector of the fifth script;
[0169] If the semantic similarity is greater than a preset similarity, it is determined that the service framework code is correct.
[0170] Optionally, the content of any script includes: the associated service type between two components, and the node type of each component in the associated service type; wherein the associated service type includes subscription and publication service and request and response service, and the node type includes: subscription node, publication node, request node and response node.
[0171] The code development synchronization device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and this embodiment will not be described in detail here.
[0172] Figure 7 This is a schematic diagram of the structure of an electronic device provided in this application. The electronic device may be a server or a terminal computer, such as Figure 7 As shown, the electronic device 50 provided in this embodiment includes: at least one processor 501 and a memory 502. Optionally, the device 50 also includes a communication component 503. The processor 501, the memory 502 and the communication component 503 are connected via a bus 504.
[0173] In a specific implementation process, at least one processor 501 executes the computer-executable instructions stored in the memory 502, so that at least one processor 501 executes the above method.
[0174] The specific implementation process of the processor 501 can be found in the above method embodiment, and its implementation principle and technical effect are similar, so this embodiment will not be repeated here.
[0175] In the above embodiments, it should be understood that the processor can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), etc. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the invention can be directly implemented as a hardware processor, or can be implemented by a combination of hardware and software modules in the processor.
[0176] The memory may include a high-speed memory (Random Access Memory, RAM), and may also include a non-volatile memory (NVM), such as at least one disk storage.
[0177] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, the bus in the drawings of this application is not limited to only one bus or one type of bus.
[0178] The present application also provides a computer program product, including a computer program, which implements the above method when executed by a processor.
[0179] The present application also provides a computer-readable storage medium, in which computer-executable instructions are stored. When a processor executes the computer-executable instructions, the above method is implemented.
[0180] The above-mentioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk. The readable storage medium can be any available medium that can be accessed by a general or special-purpose computer.
[0181] An exemplary readable storage medium is coupled to a processor so that the processor can read information from the readable storage medium and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can be located in an application specific integrated circuit (Application Specific Integrated Circuits, referred to as: ASIC). Of course, the processor and the readable storage medium can also exist in the device as discrete components.
[0182] The division of units is only a logical function division, and there may be other divisions in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interface, device or unit, which can be electrical, mechanical or other forms.
[0183] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
[0184] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
[0185] If the function is implemented in the form of 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 the present invention, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods of each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc. Various media that can store program codes.
[0186] Those skilled in the art can understand that all or part of the steps of implementing the above-mentioned method embodiments can be completed by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, the steps of the above-mentioned method embodiments are executed; and the aforementioned storage medium includes: ROM, RAM, disk or optical disk and other media that can store program codes.
[0187] Finally, it should be noted that those skilled in the art will readily conceive of other embodiments of the present invention after considering the specification and practicing the invention disclosed herein. The present invention is intended to cover any variations, uses or adaptations of the present invention, which follow the general principles of the present invention and include common knowledge or customary technical means in the art not disclosed by the present invention, are not limited to the precise structure described above and shown in the drawings, and may be modified and changed in various ways without departing from the scope thereof. The scope of the present invention is limited only by the appended claims.
Claims
1. A code development synchronization method, characterized in that: include: Obtaining a target code, wherein the target code is obtained by modifying a service framework code generated based on a first model, wherein the first model is used to represent an interaction mode between components in a vehicle open architecture; According to the target code, the first model is updated to obtain a second model; The second model is pushed to a preset user terminal.
2. The method according to claim 1, characterized in that The method further comprises: Acquire a third model obtained by modifying the first model; Correspondingly, the updating of the first model according to the target code to obtain the second model includes: The first model is updated according to the target code and the third model to obtain the second model.
3. The method according to claim 2, characterized in that The updating of the first model according to the target code and the third model to obtain the second model includes: Parsing the target code into a first script in a natural language; generating a second script in natural language according to the third model; Merge the second script and the first script and perform deduplication processing to obtain a third script; The second model is determined according to the third script.
4. The method according to claim 3, characterized in that The determining the second model according to the third script includes: Determine a graph structure of the third script according to the associated service types between the components in the third script and the node type of each component in the associated service type, wherein the graph structure is used to represent the associated relationship between the components in a plan view; The graph structure is rendered into the second model using a preset modeling tool.
5. The method according to any one of claims 1 to 4, characterized in that: The method further comprises: Parsing the service framework code of the first model into a fourth script in a natural language; generating a fifth script in natural language according to the first model; A consistency comparison is performed based on the fourth script and the fifth script to determine whether the service framework code is correct.
6. The method according to claim 5, characterized in that The performing consistency comparison according to the fourth script and the fifth script to determine whether the service framework code is correct includes: Processing the fourth script by using a preset natural language processing model to obtain a text vector of the fourth script; Processing the fifth script by the natural language processing model to obtain a text vector of the fifth script; determining semantic similarity between the text vector of the fourth script and the text vector of the fifth script; If the semantic similarity is greater than a preset similarity, it is determined that the service framework code is correct.
7. The method according to any one of claims 1 to 3, characterized in that: The content of any script includes: the associated service type between two components, and the node type of each component in the associated service type; wherein the associated service type includes subscription publishing service and request response service, and the node type includes: subscription node, publishing node, request node and response node.
8. A code development synchronization device, characterized in that: The device comprises: An acquisition module, used for acquiring a target code, wherein the target code is obtained by modifying a service framework code generated based on a first model, wherein the first model is used for representing an interaction mode between components in a vehicle open architecture; A synchronization module, used for updating the first model according to the target code to obtain a second model; A sending module is used to push the second model to a preset user terminal.
9. An electronic device, characterized in that: include: Memory, processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory, so that the processor performs the method according to any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to any one of claims 1 to 7 when executed by a processor.