阅读说明：本技术 用于处理软件项目的方法 (Method for processing software items ) 是由 德克·詹森 雷蒙·巴特 托马斯·罗伯特·齐格勒 迈克尔·约瑟夫·施洛特博姆 于 2019-05-17 设计创作，主要内容包括：本发明涉及一种用于通过第一用户在第一处理站(211)上处理由原代码(310)和机器代码(320)组成的软件项目的方法(100),具有以下方法步骤：-将所述原代码(310)的第一副本从第一存储器(201)下载(101)到所述第一处理站(211)；-更改(102)所述原代码(310)的第一副本；-产生(103)所述机器代码(320)的第一程序版本,其中所述机器代码(320)的第一程序版本是从所述原代码(310)的第一副本中产生的；-将所述机器代码(320)的第一程序版本上传(104)到第二存储器(202)中；以及-通过将所述机器代码(320)的第一程序版本上传到第二存储器(202)中触发地,将所述原代码(310)的经过更改的副本自动上传(105)到所述第一存储器(201)中。(The invention relates to a method (100) for processing a software item consisting of original code (310) and machine code (320) by a first user on a first processing station (211), comprising the following method steps: -downloading (101) a first copy of the primary code (310) from a first memory (201) to the first processing station (211); -altering (102) a first copy of the original code (310); -generating (103) a first program version of the machine code (320), wherein the first program version of the machine code (320) is generated from a first copy of the original code (310); -uploading (104) a first program version of the machine code (320) into a second memory (202); -automatically uploading (105) the altered copy of the original code (310) into the first memory (201) triggered by uploading the first program version of the machine code (320) into the second memory (202).)

1. Method (100) for processing a software item (300) consisting of original code (310) and machine code (320) by a first user on a first processing station (211), having the following method steps, wherein the method steps are performed in the order specified:

-downloading (101) a first copy of the primary code (310) from a first memory (201) to the first processing station (211);

-altering (102) the first copy of the original code (310);

-generating (103) a first program version of the machine code (320), wherein the first program version of the machine code (320) is generated from a first copy of the original code (310);

-uploading (104) a first program version of the machine code (320) into a second memory (202); and the number of the first and second groups,

-automatically uploading (105) the altered copy of the original code (310) into the first memory (201) triggered by uploading the first program version of the machine code (320) into the second memory (202).

2. The method (100) according to claim 1, having the additional method step of:

-checking (111): whether a second program version of the machine code (320) generated from a second copy of the original code (310) has been uploaded into the second memory (202) between downloading (101) the first copy of the original code (310) and uploading (104) the first program version of the machine code (320) to the second memory (202);

-downloading (112) a modified second copy of the original code (310) from the first memory (201) if it is determined at the time of the checking (111) that a second program version of the machine code (320) has been uploaded into the second memory (202);

-outputting (113) to a first user a requirement to merge the first copy of the original code (310) and the second copy of the original code (310) into a third copy of the original code (310);

-generating (114) a third program version of the machine code (320) from a third copy of the original code;

-uploading (115) a third program version of the machine code (320) into the second memory,

wherein automatically uploading (105) the altered copy of the original code (310) into the first memory (201) is designed to upload a third copy of the original code (310) into the first memory (201).

3. The method (100) of claim 2, wherein the uploading (104) of the first program version of the machine code (320) is interrupted prior to outputting the requirement to the first user.

4. The method (100) according to claim 2 or 3, wherein additionally the altered first copy of the original code (310) is uploaded into the first memory (201).

5. The method (100) according to claim 1, having the additional method step of:

-checking (111): whether a second program version of the machine code (320) generated from a second copy of the original code (310) has been uploaded into the second memory (202) between downloading (101) the first copy of the original code (310) and uploading (104) the first program version of the machine code (320) to the second memory (202);

-downloading (112) a modified second copy of the original code (310) from the first memory (201) if it is determined at the time of the checking (111) that a second program version of the machine code (320) has been uploaded into the second memory (202);

-outputting (113) to the first user a requirement to merge the first copy of the original code (310) and the second copy of the original code (310) into a third copy of the original code (310);

-overwriting (134) a second program version of the machine code (320) with a first program version of the machine code (320) triggered by a reaction of the first user to a requirement (113) for output;

wherein the automatic uploading of the altered copy of the original code (310) into the first memory (201) is designed to upload the altered first copy of the original code (310) into the first memory (201).

6. The method (100) of claims 2 to 5, wherein the checking is performed based on a timestamp of a program version of the machine code (320).

7. The method (100) of claims 2 to 5, wherein the checking is performed based on a hash value of a program version of the machine code (320).

8. The method (100) according to any of claims 1 to 7, wherein the program version of the machine code (320) is generated by compiling a copy of the original code (310).

9. The method (100) according to any of claims 1 to 8, wherein the item of software (300) comprises a configuration file (312), wherein the configuration file (312) is part of the original code (310), wherein the configuration file (312) is integrated in a program version of the machine code (320), wherein the change of the first copy of the original code (310) comprises a change of the configuration file (312), wherein the changed configuration file (312) is uploaded into the second memory (202).

10. The method (100) according to any one of claims 1 to 9, wherein a plurality of original code versions are stored in the first memory (201), and wherein a display (250) of the original code versions stored in the first memory (201) is invokable at the first processing station (211).

11. The method (100) according to any one of claims 1 to 10, wherein one or more primary code versions from the first memory (201) are synchronized with the third memory (203) according to a preset, in particular according to a user input or automatically.

12. The method (100) according to any one of claims 1 to 11, wherein the item of software (300) is an automation item, wherein the machine code (320) is for controlling an automation component (401), and wherein the second memory (202) is arranged in the automation component (401).

13. The method (100) according to claim 12, wherein the first memory (201) is arranged in the automation component (401).

14. Processing station (211) with a first data interface (231) and input options (240) of a user, wherein the processing station (211) is designed to perform the method (100) according to any one of claims 1 to 13.

15. Automation system (400) having a first memory (201), an automation component (401) with a second memory (202) and at least one processing station (211) according to claim 14, wherein a first communication connection (261) is established between the first memory (201) and the processing station (211) and a second communication connection (262) is established between the processing station (211) and the second memory (202).

Technical Field

The invention relates to a method for processing a software item on a first processing station, a processing station and an automation system having such a processing station.

The present application claims priority from german patent application DE 102018111930.5 filed on 2018, 5, 17, the contents of which are hereby incorporated by reference in their entirety.

Background

Software items, such as controls for automation systems, are becoming more and more complex. In many cases, the control software for automation systems is so complex that the creation and modification of the software project is performed by a large number of users. The same applies to software items in other fields, for example for computer games and office programs. Therefore, a way must be found so that multiple users can process a software project at the same time without losing the already processed state due to the overlay in the process. This can be done, for example, by providing a programming environment on the processing station, wherein the software items are composed of objects that can be downloaded onto the processing station and are assigned time stamps. Now if both processors process the same object at the same time and then upload the object into memory again, this can be recognized based on the time stamp. Then instead of uploading later, the user is asked to check the modified object and make other modifications if necessary before re-uploading. Such a process is disclosed in document EP 2811352 a 1.

Furthermore, software for distributed version management of files is also known. Here, a central server may be used to store the version of the item of software, or the version of the item of software may be stored by distributed distribution of the version status of the item of software, such as is implemented in Git (https:// de. wikipedia. org/wiki/Git).

Disclosure of Invention

It is an object of the invention to provide an improved method for processing a software project. It is a further object of the invention to provide a processing station on which the method can be carried out, and an automation system in which such a processing station is integrated.

These objects are solved by the methods and devices of the independent claims. Further developments are specified in the dependent claims.

In a method for processing a software item consisting of primary code (Primaercode) and machine code by a first user, the following method steps are carried out in the stated order, wherein the processing takes place on a first processing station. First, a first copy of the original code is downloaded from a first memory to the first processing station. Here, the source code includes all files that can be directly processed by the first user. The first copy of the original code is then altered by the first user. To this end, the first user may use the resources provided to the first user by the first processing station. A first program version of the machine code is then generated from the altered first copy of the original code. The machine code includes all files used by the computer in executing the item of software. Thus, the machine code is a runnable version of the item of software and the original code is a programmable form of the item of software. After generating the first program version of the machine code, uploading the first program version of the machine code to a second memory. Here, the second memory may be associated with a computer on which the item of software should be executed. Here, the uploading of the first program version of the machine code may be triggered by an input of the first user if the first user considers the respective runnable program version of the machine code available. Automatically uploading the altered copy of the original code into the first memory triggered by uploading the first program version of the machine code to the second memory.

Thus, the first user does not have to remember himself to upload the copy of the original code (which may be, for example, the altered first copy of the original code) into the first memory after the processing. It is hereby achieved that the original code files belonging to the executable machine code stored in said second memory are provided in the first memory for other users. Other users can now download the modified original code to their processing stations, where other modifications are made. Even if the user uploads other executable program versions of the machine code into the second memory, the altered original code is automatically stored in the first memory. Version management during programming or during revision of the software project is thereby significantly simplified, as the user (e.g., programmer) need only worry about uploading a runnable program version of the machine code to the second memory. The original code file changed by the user is automatically uploaded to the first memory.

In one embodiment of the method, it is additionally checked that: whether a second program version of the machine code generated from a second copy of the original code has been uploaded to the second memory between downloading the first copy of the original code and uploading the first program version of the machine code to the second memory. This may be the case, for example, if a second user uploads a program version of the machine code to the second memory based on the same or an earlier version of the original code, simultaneously with the first user. If it is determined in the case of the check that a second program version of the machine code has been uploaded to the second memory, then a modified second copy of the original code is downloaded from the first memory to the first processing station, and a requirement is output to the first user to merge the first copy of the original code and the second copy of the original code into a third copy of the original code. A third program version of the machine code may then be generated from a third copy of the original code. A third program version of the machine code may then be uploaded to the second memory. Here, the automatic uploading of the altered copy of the original code into the first memory is designed to upload a third copy of the original code into the first memory. Thus, it is possible to check whether the modified program version of the machine code has been uploaded before the modified copy of the original code is automatically uploaded, since in this case it is not absolutely necessary to upload the first copy of the original code modified by the first user.

However, it may alternatively be provided that, when the first program version of the machine code is uploaded, the modified first copy of the original code is automatically uploaded, and that subsequently, after the checking, a third copy of the original code is also automatically uploaded into the first memory, triggered by the uploading of a third program version of the machine code.

In one embodiment of the method, the uploading of the first program version of the machine code is interrupted prior to outputting the requirement to the first user. Transmission bandwidth between the first processing station and the second memory can thereby be saved. Alternatively or additionally, provision may be made for the modified first copy of the original code to be uploaded into the first memory in each case automatically, and for the uploading of the modified first copy of the original code into the first memory to likewise be interrupted if it is determined that the second program version of the machine code has been uploaded.

In one embodiment of the method, it is likewise checked whether a second program version of the machine code, which is generated from a second copy of the original code, has already been uploaded into the second memory between the downloading of the first copy of the original code and the uploading of the first program version of the machine code into the second memory. The modified second copy of the original code is then also downloaded, and a requirement is output to the first user to merge the first copy of the original code and the second copy of the original code into a third copy of the original code. In this embodiment, however, the second program version is overwritten with the first program version triggered by the reaction of the first user to the output request. The automatic uploading of the modified copy of the original code into the first memory is here designed to upload the modified first copy of the original code into the first memory. In this embodiment, it can be provided, for example, that the first processing station outputs a warning indication to the first user. The alert indication is used to signal the first user that uploading the first program version will result in the state of the software project created by the second user being overridden. However, after verifying the first and second copies of the original code, the first user may dismiss the warning indication by user input.

In one embodiment, the checking is performed based on a timestamp of a program version of the machine code. This time stamp may be integrated into the machine code, for example, at the time the program version of the machine code is generated, and may be related to the time at which the copy of the original code was downloaded.

In one embodiment, the checking is based on a hash value of the program version of the machine code. In this case, the hash value of the program version located in the second memory is generated during the downloading of the first copy of the original code and is then compared with the hash value of the program version of the machine code during the uploading of the first program version of the machine code to the second memory. If during this time the other user has uploaded the second program version of the machine code into the second memory, the hash values are no longer consistent, and it can be determined that the second program version of the machine code has been uploaded into the second memory.

In one embodiment, the program version of the machine code is generated by compiling a copy of the original code. This is a common method of generating a machine code (machine-readable code) from the original code.

In one embodiment, the software project includes a configuration file. The configuration file is part of the original code. The configuration file is also integrated into the program version of the machine code. Altering the first copy of the original code includes altering the configuration file. The modified configuration file is also uploaded to the second memory. The configuration file may be integrated into the machine code, for example, by calling the configuration file by the machine code. This is advantageous, for example, if the software project is designed such that, although individual parameters have to be modifiable, this does not have a significant effect on the software architecture of the machine code. The parameters can then be provided in the configuration file, which can be modified as part of the original code on the one hand, and read from the machine code on the other hand, so that the parameters can be taken into account accordingly when executing the machine code.

In one embodiment of the method, a plurality of original code versions are stored in the first memory. The display of the original code version stored in the first memory may be invoked at the first processing station. Whereby the first user has access to a previous state of the original code during processing of the item of software. This allows for more flexible programming and may additionally represent a first level of data security.

In one embodiment of the method, one or more original code versions from the first memory are synchronized with a third memory according to a preset. The preset can in particular be a user input or an automatic preset. So that, for example, the original code version may be automatically saved in the third memory every week for a safe backup of data. At the same time, the first user may trigger synchronization of the original code versions of the first and third memories by user input if the first user believes that he or she has reached a milestone during programming of the software project.

In one embodiment of the method, the item of software is an automation item, wherein the machine code is for controlling an automation component. The second memory is disposed in the automation component. This means that a second memory for the machine code is arranged in a memory in the automation component for storing a program version of the machine code for controlling the automation component. A simple system architecture is thereby achieved. In this case, the first memory can be arranged outside the automation component, for example on a central file server.

In one embodiment of the method, the first memory is disposed in the automation component. The original code from the first memory can then be provided via the automation component, and on the other hand the readable machine code can be uploaded into the second memory of the automation component. In this case, the first memory and the second memory may be configured as physical storage media within the automation component, such as a hard disk or flash memory.

The processing station has a data interface and user input options. The processing station is designed to perform one of the methods described above. This means in particular that a computer program can be run on the processing station, which computer program interacts with the first user such that the processing steps performed by the first processing station can be performed. During execution of the method, the first user may make changes, for example changes to the original code, which are not performed by the processing station. The machine code is then generated from the altered original code and automated version management may be performed by uploading the altered original code to the first memory.

The processing station may have a display with which information is displayed to the first user. Alternatively or additionally, the processing station may be designed as a server which enables access to other computers from outside the processing station. This access to the server then represents the first user's input options.

The automation system comprises a first storage, an automation component with a second storage and at least one such processing station. The automation system may include a sensor reading option and provide control signals for the actuators. The machine code is used to control the automation component, wherein the control may be based on the read sensor and may result in a signal being output to the actuator. A first communication connection is established between the first memory and the processing station. A second communication connection is established between the processing station and the second memory. Whereby the original code may be downloaded from the first memory to the processing station and uploaded from the processing station to the second memory after the original code has been altered. The machine code located in the second memory may then be subsequently executed by the automation component.

Drawings

The invention is explained in more detail below on the basis of embodiments and with reference to the drawings. Here, the first and second electrodes are, respectively in a schematic view,

fig. 1 shows a flow chart of a first embodiment of the method;

FIG. 2 shows a timing diagram of a first embodiment of the method;

FIG. 3 shows a flow chart of a second embodiment of the method;

FIG. 4 shows a timing diagram of a second embodiment of the method;

FIG. 5 illustrates a flow chart of integrating the method into a method for updating stored original code;

FIG. 6 shows a flow chart in which method steps are likewise integrated in the method for updating the memory of the original code;

FIG. 7 illustrates an item of software composed of original code and machine code, including a configuration file;

FIG. 8 shows a timing diagram of another embodiment of the method with an additional synchronization step;

FIG. 9 shows a processing station;

FIG. 10 illustrates an automation system having automation components and a processing station; and

fig. 11 shows a further exemplary embodiment of such an automation system.

Detailed Description

Fig. 1 shows a flow chart 100 of a method for processing a software item consisting of original code and machine code on a first processing station by a first user. In a first method step 101, a first copy of the original code is downloaded from a first memory to the first processing station. In a second method step 102, the first copy of the original code is altered. In a third method step 103, a first program version of the machine code is generated from the first copy of the original code. In a fourth method step 104, the first program version of the machine code is uploaded into a second memory. In a fifth method step 105, the modified copy of the original code is automatically uploaded into the first memory triggered by the uploading of the first program version of the machine code into the second memory. The modified copy of the original code uploaded in the fifth method step 105 can be the modified first copy of the original code. The processing station on which the method is performed can be programmed such that a first copy of the original code is downloaded in a first method step 101, a first program version of the machine code is generated in a third method step 103, and the first program version of the machine code is uploaded into a second memory triggered by a user input of the first user in a fourth method step 104, and the first copy of the original code is modified by the first user in a second method step 102. Here, the processing station provides the first user with a means to change the original code, for example via an input mask and/or a programmer interface. As soon as the fourth method step 104 triggered by the first user, i.e. the uploading of the first program version of the machine code, is completed, in a fifth method step 105, the modified copy of the original code is additionally automatically uploaded into the first memory, so that the first user does not have to care about this method step himself, but rather the fifth method step 105 is automatically executed by the first processing station.

Fig. 2 shows a timing diagram 150 of method steps 101 to 105 of the method of fig. 1 and the interaction of the first processing station 211 with the first memory 201 and the second memory 202. The sequence of method steps 101 to 105 proceeds from top to bottom. In a first method step 101, a first copy of the original code is downloaded from a first memory 201 to a first processing station 211. In a second method step 102, the first copy of the original code is modified at the first processing station 211. In a third method step 103, a first program version of the machine code is generated from the modified first copy of the original code. This first program version is then uploaded to the second memory 202 in a fourth method step 104. Triggered by the uploading of the first program version of the machine code into the second memory 202 in the fourth method step 104, the modified copy of the original code is automatically uploaded into the first memory 201 in the fifth method step 105.

Here, the first memory 201 and the second memory 202 may be located at different physical locations, e.g. on different servers, or may be located at the same physical location, e.g. on the same server or even on the same hard disk or the same flash memory. Here, the machine code stored in the second memory 202 comprises an executable program version of said item of software, while the original code version stored in the first memory 201 comprises the source file of said item of software.

Fig. 3 shows a flow chart 100 of a second configuration of the method. The first four method steps 101 to 104 correspond to the method steps of the exemplary embodiment in fig. 1. After the first program version of the machine code has been uploaded in the fourth method step 104, it is checked in a first checking step 111: whether a second program version of the machine code, which is generated from a second copy of the original code, has been uploaded into the second memory between the downloading of the first copy of the original code in the first method step 101 and the uploading of the first program version of the machine code in the fourth method step 104. If this is not the case, then the fifth method step 105 of the embodiment of fig. 1 is automatically executed, i.e. the altered copy of the original code is automatically uploaded into the first memory. If, however, the check in the first checking step 111 indicates that a second program version of the machine code has been uploaded into the second memory, then a modified second copy of the original code is subsequently downloaded from the first memory in a sixth method step 112. In a seventh method step 113, a requirement to combine the first copy of the original code and the second copy of the original code into a third copy of the original code is output to the first user. Then, in an eighth method step 114, a third program version of the machine code is generated from the third copy of the original code. This may be done by the first user following the requirements from the seventh method step 113. Then in a ninth method step 115, a third program version of the machine code is uploaded into the second memory. A fifth method step 105 is then performed in which the automatic uploading of the altered copy of the original code to the first memory is designed to upload a third copy of the original code to the first memory.

It may additionally be provided that the modified first copy of the original code is additionally uploaded to the first memory before or after the first checking step 111. It can also be provided that the uploading of the first program version in the fourth method step 104 is interrupted if the check in the first checking step 111 indicates that a second program version of the machine code has been uploaded to the second memory.

Fig. 4 illustrates a timing sequence 150 for the method of fig. 3. Here, the first memory 201, the second memory 202 and the first processing station 211 correspond to the respective devices of fig. 2. The method steps 101 to 104 are carried out analogously to the sequence of fig. 2, the sequence of these method steps again proceeding from top to bottom. Between the downloading of the first copy of the original code in the first method step 101 and the uploading of the first program version in the fourth method step 104, the second program version has been uploaded from the second processing station 212 to the second memory 202 in a further fourth method step 124. In a further fifth method step 125, a second copy of the original code is uploaded to the first memory 201. Now in a first checking step 111 it is checked whether a second program version of the machine code has been uploaded to the second memory 202. Due to this, a second copy of the original code is now downloaded to the first processing station 211 in the sixth method step 112. Then in a seventh method step 113, a requirement is output to the user to merge the first copy of the original code, which was changed by the user in the second method step 102, with the second copy of the original code downloaded in the sixth method step 112. Then, in an eighth method step 114, a third program version of the machine code is generated from the third copy of the original code. The third program version of the machine code is then uploaded to the second memory 202 in a ninth method step 115. Triggered automatically by the ninth method step 115, the fifth method step 105 is executed, in which a third copy of the original code is uploaded as a modified copy of the original code into the first memory 201.

In fig. 4, a further upload step 106 is additionally shown in dashed lines, in which the modified first copy of the original code is uploaded into the first memory 201 independently of the first check step 111. This method step is optional and may be used to provide all modified versions of the original code in the first memory 201.

Fig. 5 shows a flow chart 100 which contains a plurality of method steps of the flow chart of fig. 3 and in which further method steps are carried out. After the third method step 103, i.e. after the first program version of the machine code has been generated from the first copy of the original code, it is checked in a second checking step 131 whether the generation was successful. If this is not the case, the method is interrupted. The end of the method is represented as a circle in the flowchart 100 of fig. 5. If the generation is successful, a fourth method step 104 is then performed, i.e. the first program version of the machine code is uploaded into the second memory. A first checking step 111 is then performed. If it is indicated in the first checking step 111 that the second program version of the machine code has not yet been uploaded, a fifth method step 105 is carried out analogously to the procedure described in fig. 3. If it is determined in the checking step 111 that a second program version of the machine code has been uploaded into the second memory, instead of outputting a request to the first user and downloading a modified second copy of the original code, a first decision step 132 is performed in the flowchart 100 of fig. 5, in which the first user can decide whether he wants to overwrite the second program version with the first program version. If this is not the case, the method is interrupted. If this is the case, an override step 134 is performed in which the first program version is uploaded to the second memory and the second program version is deleted from the second memory. It is then checked in a third checking step 133 whether the overwriting of the second program version was successful. If this is not the case, the method is interrupted. If the second program version of the machine code is successfully overwritten, a fifth method step 105 is automatically executed, i.e. a modified first copy of the original code is uploaded into the first memory.

Fig. 6 shows a further flowchart 100, which contains a plurality of method steps of the flowchart of fig. 3 and in which further method steps are carried out. After the fourth method step 104, a first checking step 111 is first carried out. In this case, it can be concluded on the first path 141 that the first program version already corresponds to the program version stored in the second memory, so that the method can be interrupted. The end of the method is represented as a circle in the flowchart 100 of fig. 6. Furthermore, a second path 142 can be derived in the first checking step 111, which corresponds to a situation in which the second program version was not uploaded to the second memory and therefore the first program version was successfully uploaded in the fourth method step 104. A fifth method step 105 is then executed, namely the modified copy of the original code is uploaded into the first memory. If it is concluded in the first checking step 111 that the second program version has been uploaded to the second memory, the method proceeds via a third path 143 to a second decision step 135. Now let the first user choose whether he wants to reject his change in the fourth path 144. The method is then interrupted and its original code copy is not uploaded into the first memory. Furthermore, the following method steps can be provided in the fourth path 144, wherein the first program version from the fourth method step 104 is also rejected. Furthermore, the first user is provided with a possibility to reject the second program version of the second user via a fifth path 145. A fifth method step 105 is then executed and the modified first copy of the original code is uploaded into the first memory. Via a sixth path 146, the first user enters a third alternative, namely merging the two program versions already described for fig. 3 in method steps 112 to 115 and subsequently method step 105.

In one embodiment, checking whether the program versions of the machine code located in the second memory are different is performed via a timestamp of the program versions of the machine code. Here, a timestamp for uploading the original code and the machine code is transmitted together when the first copy of the original code is downloaded. If the machine code already in the second memory at the time of uploading the machine code also has the timestamp, the machine code is not altered during this time, so that the uploading of the altered copy of the original code can continue.

In one embodiment, the checking is performed based on a hash value of the program version of the machine code. If the hash value of the program version of the machine code already located in the second memory at the time of uploading the generated program version of the machine code corresponds to the hash value of the machine code at the time of downloading the first copy of the original code, no new program version of the machine code is uploaded into the second memory during this time.

In one embodiment, these program versions, for example the first program version and/or the second program version and/or the third program version, are generated in the fourth method step 104 or in the eighth method step 114 by compiling a copy of the original code.

Fig. 7 shows an item of software 300 consisting of original code 310 and machine code 320. Here, the source code 310 includes one or more source files 311 and configuration files 312. If the machine code 320 should now be generated in the fourth or eighth method step, the source file 311 is compiled by the compiler 330 into a machine-readable file 321. The configuration file 312 is not run through the compiler 330 here and is also available in the machine code 320 unaltered. The configuration file 312 located in the machine code 320 is integrated into the machine-readable file 321 by, for example, setting a command in the machine-readable file 321 to "load specific lines or values from the configuration file 312 and thereby execute these specific lines or values". Here, the configuration file 312 may contain information about the peripheral device and thus, for example, about the driver selection for the external device.

Fig. 8 shows a further time sequence 150 of the method, wherein the method steps are taken from fig. 2 and 4 and correspond to the method steps of fig. 2 and 4 if no differentiation is described below. As illustrated in fig. 2, method steps 101 to 105 are first performed. In a first checking step 111 following the fourth method step 104, it is determined that no further program versions of the machine code have been uploaded during this time. The fifth method step 105 is therefore executed. The original code copy now located in the first memory 201 is then downloaded in a further first method step 121 to the second processing station 212. In a further second method step 122, a further third method step 123 and a further fourth method step 124, the second user modifies the original code copy on the second processing station 212 and then uploads the machine code thus generated into the second memory 202. At the same time, the first user executes the additional second method step 152 and the additional third method step 153 on the first processing station 211 and thus further modifies the first program version of the machine code. The uploading of the additional first program version of the machine code by the first user, i.e. the additional fourth method step 154, is performed before the further fourth method step 124 of the second user. In addition, a first copy of the further modification of the original code is uploaded in an additional fifth method step 155 into the first memory 201. In this case, after the additional first program version of the machine code has been uploaded in the additional fourth method step 154, it is determined in an additional first checking step 156 that the "modified program version of the machine code has not been uploaded during this time", and then an additional fifth method step 155 is automatically carried out. After uploading the program version of the machine code changed by the second user, which is done in a further fourth method step 124, it is now checked and determined in a further first checking step 126: between the downloading of the original code in a further first method step 121 and the uploading of the program version of the machine code in a further fourth method step 124, the machine code has been modified by an additional fourth method step 154. Thus, in the sixth method step 112, the modified version of the original code uploaded in the first memory 201 in the additional fifth method step 155 is downloaded to the second processing station 212, and the method steps 113 to 115 are then carried out as described for fig. 4, but this time on the second processing station 212. Now in a ninth method step 115, the merged program version is uploaded into the second memory 202, and simultaneously a further fifth method step 125 is automatically executed by this upload, and in the process a merged copy of the original code is uploaded into the first memory 201. Now in a synchronization step 127 the content of the first memory 201 is synchronized with the third memory 203. This can be triggered, for example, by: the second user on the second processing station 212 believes that the milestone of the software project has now been reached, so that further secure backups of data appear to be meaningful to the second user. However, the synchronization step 127 may also be performed automatically, for example at the end of each weekday or in the evening between two weekdays.

Fig. 9 shows a first processing station 211 with a central computer 230, a first data interface 231, a second data interface 232 and input options 240 for the user. Furthermore, the first processing station 211 has an optional display 250. As an alternative to this configuration, the first processing station 211 can also consist of only the central processing unit 230 with the first data interface 231. The central computing unit 230 and thus the first processing station 211 can then be accessed remotely via a computer (not shown) connected to the second data interface 232 via the second data interface 232. The connection may be made, for example, via a network or the internet. The first processing station 211 is connected to a first (not shown) memory and a second (not shown) memory at a first data interface 231. This may also be done via a network interface or via the internet. If a plurality of processing stations are provided as shown in fig. 4 and 8, these processing stations may be constructed similarly to the processing stations of fig. 9. However, it can also be provided that the central computing unit 230 functions as a server as described above and that the central computing unit 230 can be accessed from two different external computers via the second data interface 232. In the sense of the present patent application, such use of the central computing unit 230 represents the use of two processing stations.

As long as provision is made for a plurality of original code versions to be stored in said first memory, the version of the original code stored in said first memory may be displayed via the display 250 or via a display of a computing unit connected to the second data interface 232. A user who wants to change the item of software may then select which original code version he wants to change from the versions displayed on display 250. This may be used, for example, to reject previous changes that have, for example, proven invalid, and to start in an earlier state when the item of software is processed.

The first memory and the second memory may be designed as a central file server or as a so-called Git repository. Here, the first and second memories may be physically disposed on the same storage medium, for example, a hard disk of the server.

The described processing station and the described method for changing and modifying the software project can be used particularly advantageously in automation technology.

Fig. 10 shows an automation system 400 with an automation component 401 and a first processing station 211, as well as a first memory 201. The second memory 202 is associated with an automation component 401. The memories 201, 202 and the first processing station 211 function here as described above. The automation component 401 has a control computer 410, a sensor input 420 and an actuator output 430. A control program running on the control computer 410 can read in sensor data detected via at least one of the sensor inputs 420 and control the actuator via at least one of the actuator outputs 430 on the basis of the sensor data. Such automation components 401 may be part of a larger system control, for example under the framework of a building automation or in the field of industrial control of production plants. The second memory 202 is associated with and connected to the control computer 410. The control software of the control computer 410, which contains, for example, a control program running on said control computer, is stored in the second memory 202. The control software represents the software items of the method described so far. In particular in automation technology, it is important to modify the control software in such a way that the downtime of the automation component 401 is as short as possible. The method described in this way is particularly important in that it is checked whether the second user has already uploaded a further program version of the machine code of the control software into the second memory 202 during the processing of the control software by the first user. The automation system 400 of fig. 10 additionally has a second processing station 212. The first processing station 211 is connected to the first memory 201 by means of a first communication connection 261 and to the second memory 202 by means of a second communication connection 262, so that on the one hand the original code of the item of software can be downloaded from the first memory 201 and on the other hand the machine code of the item of software can be uploaded into the second memory 202. Similar to fig. 9, the first processing station 211 can have a central processing unit with a first data interface, wherein the communication connection can be connected to the first data interface 231 of the central processing unit. The second processing station 212 is connected to the first memory 201 via a third communication connection 263. The second processing station 212 is connected to the second memory 202 via a fourth communication connection 264. The first memory 201 is connected to the third memory 203 via an optional fifth communication connection 265. This can be used to perform the synchronization step described in fig. 8. The third memory 203 and the fifth communication connection 265 may be omitted if no additional storage in the third memory 203 is required. The third and fourth communication connections 263, 264 can likewise be omitted if the second processing station 212 is omitted. In such an automation system 400, the described method can be carried out, whereby the downtime of the automation component 401 can be reduced and at the same time it is achieved that a plurality of processing stations 211, 212 can process the control software or the software items for controlling the computer 410.

Fig. 11 shows a further exemplary embodiment of an automation system 400, which corresponds to the automation system of fig. 10, as long as no differences are described below. In this configuration of the automation system 400, the first memory 201 is also associated with the automation component 401. Here, the first memory 201 and the second memory 202 can be arranged on the same hard disk or on different hard disks or on the same or different memory options in the first automation component 401.

The first memory 201, the second memory 202 and the third memory 203 may be designed as Git repositories, but also as other possibilities for decentralized version management.

List of reference numerals

100 flow chart

101 first method step

102 second method step

103 third method step

104 fourth method step

105 fifth method step

106 Another uploading step

111 first checking step

112 sixth method step

113 seventh method step

114 eighth method step

115 ninth method step

121 further first method step

122 another second method step

123 further third method step

124 another fourth method step

125 another fifth method step

126 another checking step

127 synchronization step

131 second checking step

132 first decision step

133 third checking step

134 step of covering

135 second decision step

141 first path

142 second path

143 third route

144 fourth path

145 fifth path

146 sixth Path

150 timing diagram

152 additional second method step

153 additional third method step

154 additional fourth method step

155 additional fifth method step

156 additional first checking step

201 first memory

202 second memory

203 third memory

211 first treatment station

212 second processing station

230 central computing unit

231 first data interface

232 second data interface

240 input options

250 optional display

261 first communication connection

262 second communication connection

263 third communication connection

264 fourth communication connection

265 fifth communication connection

300 item of software

310 original code

311 source file

312 configuration files

320 machine code

321 machine-readable file

330 compiler

400 automation system

401 automation component

410 control computer

420 sensor input

430 actuator output