Method, system and program product for collaborative development of Simulink model

Abstract

The present application relates to the field of model-based development, and more particularly, to a method, system and program product for collaborative development of Simulink models. The method comprises the steps of triggering execution of a callback function in response to operation of a user on a locally stored Simulink model; comparing the version of the locally stored Simulink model with the version of the Simulink model stored on the server through the callback function; and responding to the situation that the version of the locally stored Simulink model is lower than the version of the Simulink model stored on the server, and sending a version updating instruction.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of Model-Based Development (MBD), and more particularly, to a method, system and program product for Simulink model collaborative development. BACKGROUND

[0002] With the increasing application of Model-Based Development, version management of model files is a problem that most enterprises pay more attention to. Generally, a developer modifies an old version of a model file locally, and then uploads the modified new version of the model file to a server. However, there can be multiple developers working on the same model file, and they can not communicate with each other in time about the modifications they make to the model file, resulting in conflicts when uploading the model file to the version management tool. This can reduce development efficiency and generate additional costs.

[0003] It is to be noted that the information disclosed in the above BACKGROUND section is only for the purpose of strengthening the understanding of the background of the present application, and therefore can include information that does not constitute prior art known to those of ordinary skill in the art. SUMMARY

[0004] To solve or at least alleviate one or more of the above problems, the following technical solutions are provided. The present application provides a method for Simulink model collaborative development, which can make full use of existing resources to actively identify the version difference between a local model file and a model file on a server, and timely remind the current developer to avoid the consumption of additional development resources.

[0005] According to a first aspect of the present application, a method for Simulink model collaborative development is provided, the method comprising: in response to a user's operation on a locally stored Simulink model, triggering the execution of a callback function; comparing the version of the locally stored Simulink model with the version of a Simulink model stored on a server through the callback function; and in response to the version of the locally stored Simulink model being lower than the version of the Simulink model stored on the server, issuing an indication of version update.

[0006] As an alternative or supplement to the above solution, in a method according to an embodiment of this application, the method further includes: obtaining log information of the Simulink model on the server through the callback function; determining whether the log information includes the identity of the most recent modifier; and in response to the log information not including the identity of the most recent modifier, including the user's identity as the identity of the most recent modifier in the log information to update the log information.

[0007] As an alternative or supplement to the above solution, in a method according to an embodiment of this application, the method further includes: in response to the log information including the identity of the most recent modifier, determining whether the identity of the most recent modifier is consistent with the identity of the user; and in response to the identity of the most recent modifier being inconsistent with the identity of the user, issuing an indication to the user that the locally stored Simulink model is being modified by someone else.

[0008] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, the callback function to be triggered among a plurality of callback functions is determined based on the type of the operation.

[0009] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, the operation includes opening and saving; and wherein, when the type of the operation is opening, the callback functions to be triggered include the pre-loading callback function PreLoadFcn and / or the post-loading callback function PostLoadFcn, and when the type of the operation is saving, the callback functions to be triggered include the pre-saving callback function PreSaveFcn and / or the post-saving callback function PostSaveFcn.

[0010] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, the callback function includes command-line operation instructions for obtaining the version of the Simulink model stored on the server through a version management tool.

[0011] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, the method further includes: based on user input confirming a version update, updating the locally stored Simulink model to the Simulink model stored on the server using a version management tool.

[0012] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, the version management tools include Git and SVN.

[0013] According to a second aspect of this application, a system for collaborative development of Simulink models is provided, the system comprising: a memory; a processor; and a computer program stored in the memory and executable by the processor, the execution of the computer program causing any one of the methods according to the first aspect of this application to be performed. According to a third aspect of this application, a computer program product is provided, characterized in that the computer program product includes instructions that, when executed, perform any one of the methods according to the first aspect of this application.

[0014] The method for collaborative development of Simulink models according to one or more embodiments of this application can accurately and promptly remind developers of potential version updates, content conflicts, or duplication of work by utilizing software or model callback functions and existing version management tools, thereby avoiding a decrease in collaborative development efficiency. Furthermore, the method requires no additional learning costs or effort from developers, nor does it demand excessive transmission and computing resources. Attached Figure Description

[0015] The above and / or other aspects and advantages of this application will become clearer and more readily understood from the following description taken in conjunction with the accompanying drawings, in which the same or similar elements are denoted by the same reference numerals. In the drawings: Figure 1 This is a flowchart of a method 100 for collaborative development of Simulink models according to an embodiment of this application; Figure 2 This is a flowchart of a method 200 for collaborative development of Simulink models according to another embodiment of this application; Figure 3 This is a flowchart of a method 300 for collaborative development of Simulink models according to another embodiment of this application; and Figure 4 This is a block diagram of a system 40 for collaborative development of Simulink models according to an embodiment of this application. Detailed Implementation

[0016] The following detailed description of embodiments is merely exemplary in nature and is not intended to limit the disclosed technology or its application and use. Furthermore, the technical solutions protected in this application are not intended to be bound by any express or implied theories presented in the foregoing technical fields, background technology, or the following detailed description.

[0017] In the following detailed description of the embodiments, numerous specific details are set forth in order to provide a more thorough understanding of the disclosed technology. However, it will be apparent to those skilled in the art that the disclosed technology can be practiced without these specific details. In other instances, well-known features have not been described in detail to avoid unnecessarily complicating the description.

[0018] Terms such as "possessing" and "comprising" indicate that, in addition to the units (modules) and steps directly and explicitly stated in the specification and claims, the technical solution of this application does not exclude the presence of other units (modules) and steps not directly or explicitly stated. Terms such as "first" and "second" do not indicate the order of the units in terms of time, space, size, etc., but are merely used to distinguish the units. Furthermore, the steps in this document are not limited to being performed in the order they are written; a step written later may be performed simultaneously with or before a step written earlier.

[0019] Simulink, a powerful graphical modeling and simulation tool within MATLAB, is widely used for modeling and simulating various dynamic systems. Currently, many early-stage technology development projects rely on Simulink for rapid prototyping. To further improve development efficiency, collaborative development is frequently employed to develop and iterate on the same model, requiring a high degree of collaboration among multiple developers.

[0020] When a Simulink model file changes, version control tools can typically send update information automatically to relevant parties via email to ensure model information and version synchronization. However, if multiple model files involved in the same project undergo frequent changes, a large number of change notification emails can be generated, potentially causing significant information overload for recipients (leading to missed model changes). Furthermore, email notifications are not particularly timely, typically being checked a limited number of times per day or week. Therefore, even with email push notifications, it cannot be guaranteed that relevant parties will notice the changes promptly. Other dedicated synchronization or notification methods may require additional learning costs and hardware resources; therefore, the goal is to achieve more comprehensive version difference identification and conflict alerts with minimal modifications and resources.

[0021] One or more embodiments of this application will now be described with reference to the accompanying drawings. Figure 1This is a flowchart of a method 100 for collaborative development of a Simulink model according to an embodiment of this application. Method 100 begins at step 102, where a user (e.g., one of the developers participating in the collaborative development) performs operations on a locally stored Simulink model. In some embodiments, the operations include opening and saving. In other embodiments, the operations may also include editing, modifying, or adjusting the Simulink model.

[0022] Then, in step 104, a callback function is triggered in response to a user's operation on the locally stored Simulink model. In some embodiments, after step 104, method 100 further includes determining which of a plurality of callback functions to be triggered based on the type of the operation. Specifically, when a user opens a Simulink model or saves a modified Simulink model, the execution of the callback function corresponding to the open or save operation is automatically triggered. For example, when the operation type is open, MATLAB loads the locally stored Simulink model. Accordingly, the callback functions to be triggered at this time include the pre-load callback function PreLoadFcn and / or the post-load callback function PostLoadFcn. When the operation type is save, the callback functions to be triggered include the pre-save callback function PreSaveFcn and / or the post-save callback function PostSaveFcn. Furthermore, in some embodiments, the callback function may also be a built-in callback function in Simulink or another callback function written by the user.

[0023] Next, in step 106, a callback function is used to compare the version of the Simulink model stored locally with the version of the Simulink model stored on the server. Within the callback function, the version of the Simulink model stored on the server can be obtained by executing corresponding command-line instructions (e.g., via a version control tool), and then compared with the version of the Simulink model stored locally to determine any version differences. In some embodiments, distributed Git or centralized SVN can be used as the version control tool.

[0024] In step 108, based on the comparison results in step 106, it is determined whether the version of the locally stored Simulink model is lower than the version of the Simulink model stored on the server. If the version of the locally stored Simulink model is the same as or higher than the version of the Simulink model stored on the server, it means that the user has opened or saved the latest version of the Simulink model, and there is no version conflict issue. Proceed to step 112, and method 100 ends.

[0025] Conversely, if the version of the locally stored Simulink model is lower than the version of the Simulink model stored on the server, it indicates that the user has opened or saved an older version of the Simulink model, and any modifications made by the user may cause a version conflict. Therefore, proceed to step 110 to issue a version update instruction to the user. In some embodiments, the instruction can be issued to the user via a pop-up message, which may include information about the version difference between the locally stored Simulink model and the Simulink model stored on the server as determined in step 106.

[0026] As an example scenario, during collaborative development of a Simulink model, two developers, A and B, open the same Simulink model file (both version 1.0) stored locally. A then modifies and saves the Simulink model locally before uploading it to the server, creating a version 1.1 Simulink model. Using method 100, when B subsequently modifies and saves the model locally (which may trigger PreSaveFcn or PostSaveFcn, as these triggers only occur when the model is opened), a pop-up message can be sent to B to proactively remind them of the version difference, thus avoiding version conflicts during upload. In particular, method 100 also applies if A and B are on the same branch of the Simulink model.

[0027] Next reference Figure 2 , Figure 2 This is a flowchart of a method 200 for collaborative development of Simulink models according to another embodiment of this application. Figure 2 In method 200, steps 202-208 are respectively related to... Figure 1Steps 102-108 in method 100 are similar and will not be repeated here. The difference is that the version update instruction issued in step 210 also includes a confirmation button clicked by the user. Next, in step 212, it can be determined whether to confirm the update based on user input (e.g., whether the user clicked the confirmation button). If the Simulink model update is confirmed, proceed to step 214, where, based on the user input confirming the Simulink model update, the locally stored Simulink model is updated to the Simulink model stored on the server using a version management tool. In some embodiments, before step 214, the previously opened old Simulink model is closed, and after step 214, the updated Simulink model is opened without developer intervention. Finally, in step 216, method 200 ends.

[0028] As another example scenario, during collaborative development of a Simulink model, developers A and B both modify a Simulink model based on version 1.0. A may have already completed the modifications and uploaded the modified model to the server, creating a version 1.1 Simulink model. However, B may not be aware that the Simulink model on the server has been updated to version 1.1. In this case, using method 200, when B prepares to modify the Simulink model but does not retrieve the latest version 1.1 from the server and instead directly opens the version 1.0 Simulink model stored locally (potentially triggering PreLoadFcn or PostLoadFcn), a pop-up message can proactively remind B of the model version difference. Then, B only needs to confirm the update via a confirmation button to directly update their locally stored Simulink model to the latest version 1.1. This proactively avoids B modifying an older version of the model and potentially unnecessary work. In particular, method 200 also applies if A and B are on the same branch of the Simulink model.

[0029] Next reference Figure 3 , Figure 3 This is a flowchart of a method 300 for collaborative development of a Simulink model according to another embodiment of this application. Developers (e.g., developer A and developer B) collaborating through method 300 are on the same branch of the Simulink model. It should be understood that one or more steps in method 300 can be combined with... Figure 1 Method 100 and Figure 2One or more steps of method 200 are combined to adapt to various different scenarios. Steps 302 and 304 in method 300 are... Figure 1 Steps 102 and 104 in method 100 and Figure 2 Steps 202 and 204 in method 200 are the same and will not be repeated here. As an alternative or supplement to the subsequent steps of method 100 and method 200, in step 306, after the execution of the callback function is triggered by an operation performed by the developer, the log information of the Simulink model on the server can be obtained through this callback function. Then, in step 308, it is determined whether the log information includes the identity of the most recent modifier. If the log information does not include the identity of the most recent modifier (i.e., it means that no one has started modifying this version of the Simulink model), proceed to step 310, include the current user's identity as the identity of the most recent modifier in the log information, and update the log information about this Simulink model on the server by uploading the log.

[0030] On the other hand, if the log information contains the identity of the most recent modifier (i.e., indicating that someone has started modifying this version of the Simulink model), proceed to step 312 to determine if the identity of the most recent modifier included in the log information matches the identity of the user currently opening the Simulink model. If they match, it means that the user currently opening the Simulink model is the same user who last modified this Simulink model, and they may have the latest version of the Simulink model saved locally. Therefore, proceed to step 316, and method 300 ends. Otherwise, in response to the inconsistency between the identity of the most recent modifier and the current user's identity, proceed to step 314 to issue an indication to the current user that this Simulink model is being modified by someone else. In this way, the current user (e.g., the developer) can be aware of potential content conflict risks and then coordinate through offline communication or internal confirmation, thereby avoiding unnecessary duplication of work.

[0031] Method 300 can be very effective in certain scenarios, such as the collaborative development of a Simulink model by developers A and B, as mentioned above, where A and B are on the same branch. A modifies and saves a new Simulink model based on version 1.0 locally, but hasn't uploaded it to the server yet (therefore, version 1.1 hasn't been generated). In this case, neither Method 100 nor Method 200 mentioned above can provide this information to developer B. Therefore, with Method 300, after A completes the modifications and saves, the Simulink model's log information (e.g., information about the most recent modifier) ​​is synchronized to the model log on the server, instead of automatically synchronizing the entire model. Then, when developer B performs an operation on their locally stored original version 1.0 Simulink model (e.g., opens or saves), they can be notified that A is the most recent modifier for that version of the Simulink model. This allows developer B to realize that their local Simulink model might not be up-to-date and might have some duplicate work or content conflicts with developer A, thus enabling timely offline communication or internal confirmation.

[0032] Methods 100, 200, and 300 described above fully utilize the built-in callback functions of the software and models, as well as existing version management tools, to cover various development scenarios that may lead to repetitive work and version conflicts. Developers do not need to spend additional time and effort learning new processes, software, or operations. These methods, or combinations thereof, can proactively identify version and content differences between local model files and model files on the server, and provide accurate and rapid alerts to developers regarding potential content conflicts or repetitive work.

[0033] Figure 4 This is a block diagram of a system 40 for collaborative development of Simulink models according to an embodiment of this application. The device 40 includes a memory 410, a processor 420, and a computer program 430 stored in the memory 410 and executable on the processor 420. The execution of the computer program 430 causes... Figure 1 Method 100 shown, such as Figure 2 Method 200 shown, such as Figure 3 The method 300 shown, or any combination thereof, is executed. Furthermore, the instructions in computer program 430 can also be directly embedded into native software used for Simulink model development.

[0034] The software (such as program code and / or data) according to this application can be stored on one or more computer storage media. It is also contemplated that the software identified herein can be implemented using one or more networked and / or otherwise general-purpose or special-purpose computers and / or computer systems. Where applicable, the order of the various steps described herein can be changed, combined into compound steps, and / or divided into sub-steps to provide the features described herein.

[0035] The embodiments and examples presented herein are provided to best illustrate embodiments of this application and its particular applications, thereby enabling those skilled in the art to implement and use this application. However, those skilled in the art will understand that the above description and examples are provided for ease of illustration and example only. The descriptions presented are not intended to cover all aspects of this application or to limit this application to the precise forms disclosed.

Claims

1. A method for Simulink model co-development, characterized in that, The method comprises: triggering execution of a callback function in response to a user operation on a locally stored Simulink model; comparing, by the callback function, a version of the locally stored Simulink model with a version of a Simulink model stored on a server; and issuing an indication of a version update in response to the version of the locally stored Simulink model being lower than the version of the Simulink model stored on the server.

2. The method of claim 1, wherein, The method further comprises: obtaining, by the callback function, log information of the Simulink model on the server; determining whether the log information includes an identity of a most recent modifier; and including, in response to the log information not including the identity of the most recent modifier, the identity of the user as the identity of the most recent modifier in the log information to update the log information.

3. The method of claim 2, wherein, The method further comprises: determining, in response to the log information including the identity of the most recent modifier, whether the identity of the most recent modifier is consistent with the identity of the user; and issuing, in response to the identity of the most recent modifier being inconsistent with the identity of the user, an indication to the user that the locally stored Simulink model is being modified by another person.

4. The method of claim 1, wherein, The method further comprises determining a callback function to be triggered among a plurality of callback functions based on a type of the operation.

5. The method of claim 4, wherein, The operation comprises opening and saving; and wherein when the type of the operation is opening, the callback function to be triggered comprises a PreLoadFcn callback function before loading and / or a PostLoadFcn callback function after loading, and when the type of the operation is saving, the callback function to be triggered comprises a PreSaveFcn callback function before saving and / or a PostSaveFcn callback function after saving.

6. The method of claim 1, wherein, The callback function comprises command line operation instructions for obtaining the version of the Simulink model stored on the server by a version management tool.

7. The method of claim 1, wherein, The method further comprises updating, based on a user input confirming the version update, the locally stored Simulink model to the Simulink model stored on the server by the version management tool.

8. The method of claim 6 or 7, wherein, The version management tool comprises Git and SVN.

9. A system for Simulink model co-development, characterized in that, The system comprises a memory; a processor; and a computer program stored on the memory and executable by the processor, execution of the computer program causing the method of any one of claims 1-8 to be performed.

10. A computer program product, characterised in that, The computer program product comprises instructions which, when executed, perform the method of any one of claims 1-8.

Images