Abstract:
A component of automation technology has a central unit, a boot memory, and a system memory. When a starting condition is invoked, the central unit implements a boot program stored in the boot memory. Because of the implementation of the boot program, the central unit is able to communicate with a server, accept a system program from the server and, optionally, store the accepted system program in the system memory by overwriting a system program already stored in the system memory. The central unit furthermore carries out the system program. Because of the implementation of the system program, the central unit communicates at least once with a peripheral unit which is connected to the central unit and is in operative connection with an industrial engineering progress. On the other hand, the boot program is configured such that a communication of the central unit with the peripheral unit is not possible.

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application is the US National Stage of International Application No. PCT/DE2007/000463 filed Mar. 14, 2007, claims the benefit thereof and is incorporated by reference herein in its entirety. 
     
    
     FIELD OF INVENTION 
       [0002]    The present invention relates to an operating method for an automation engineering component. The present invention also relates to such a component itself. 
       BACKGROUND OF INVENTION 
       [0003]    Drive engineering components are generally known. Examples of such components are the control devices of control systems, for example the central processors of programmable logic controllers (PLCs), the control devices of computer numerical controllers (CNCs) and of motion control units (MCUs), sensor modules, distribution nodes of modular control systems, etc. 
         [0004]    The example of a CPU of a PLC is used below to explain in more detail the typical design and typical mode of operation of a drive engineering component. It should be mentioned here for the sake of clarity that the abbreviation “CPU” is always used below for the central control device of a modular control system, i.e. for the physical component. The term “central processor” is always used for the element of the automation engineering component that executes the various programs required for the proper operation of the component. If the automation engineering component comprises both CPU functionality and input/output devices, it is referred to as a compact device. 
         [0005]    In the prior art, the CPU comprises a system memory. The system memory is designed as a non-volatile memory. A system program is stored in the system memory. As a result of executing the system program, the central processor communicates during operation of the CPU with (at least) one input/output device, which is connected to the central processor. 
         [0006]    The (at least one) input/output device is actively connected to a technical process. For example, the system program can cause the central processor to detect initially the control system configuration level i.e. how many input/output devices are connected to the central processor. As the next step, the central processor can detect, for example, what these input/output devices are. During continued operation of the component, the system program causes the central processor cyclically to receive from the at least one input/output device at least one status signal of the industrial technical process, and to transmit to the at least one input/output device at least one control signal intended for the industrial technical process. On the other hand, the system program (at least normally) brings about neither processing of the received status signal nor determination of the control signals to be transmitted. This processing and determination is normally performed in the prior art by the central processor executing a user program that defines the processing and determination. As the name already implies, the user program can be written by a user. It can be input to the CPU by the user. It can also be deleted or modified. The system program, on the other hand, cannot normally be changed by the user. 
         [0007]    There are CPUs for which the contents of the system memory, i.e. the system program, cannot be modified at all. If the system program is meant to be, or must be, changed for such a CPU, it is necessary to replace the system memory. CPUs are also already known, however, for which the contents of the system memory can be modified. To modify the contents of the system memory, however, it is necessary to follow a complicated procedure that can normally only be perforated by specially trained personnel. Irrespective of whether or not the system program can be modified, the system program must still provide complete system functionality. This means that it must be designed so that it provides all the functions that could possibly be needed according to the application and configuration, irrespective of whether all the functions are even needed in a specific application or in a specific configuration. 
         [0008]    The explanation above applies not only to CPUs of modular control systems. It is also the case for other automation engineering components that not only is it either impossible to modify the system program or only possible in an extremely involved manner, but the system program must always provide a complete set of functions. 
       SUMMARY OF INVENTION 
       [0009]    An object of the present invention is to create possible options by means of which the system program can be modified flexibly, in particular can be adapted easily to suit the application and/or configuration or other criteria. 
         [0010]    The object is achieved by an operating method and a component as claimed in the claims. 
         [0011]    According to the invention, on the occurrence of a start condition, a central processor of the component executes a boot program stored in a boot memory of the component. As a result of executing the boot program, the central processor is able to communicate with a server, to receive a system program from the server, and to save the received system program, if applicable overwriting a system program already stored in a system memory of the component, in the system memory. The central processor then executes the system program. As a result of executing the system program, the central processor communicates at least once with at least one input/output device connected to the central processor, this input/output device being actively connected to an industrial technical process. Hence the boot program is designed so that it is not possible for the central processor to communicate with the at least one input/output device as a result of executing solely the boot program. 
         [0012]    Various circumstances can be necessary or sufficient for the occurrence of the start condition. For example, the start condition can occur when a start command is specified for the central processor by the server or by a user via a man-machine interface of the component. Alternatively or additionally, the start condition can occur when the central processor has communicated with the at least one input/output device a preset number of times or during a preset time period. It is also possible that the central processor executes a user program quasi-simultaneously with the system program, and the start condition occurs when a new user program is input to the component. 
         [0013]    A common application of the present invention consists in the central processor, as a result of executing the system program, receiving from the at least one input/output device at least one status signal of the industrial technical process, and transmitting to the at least one input/output device at least one control signal intended for the industrial technical process. In this case, as a result of executing the user program, the central processor determines the at least one control signal from at least the at least one status signal. 
         [0014]    As already mentioned, the component can take the form of a central control device of a modular control system. In this case, the component comprises a control bus interface, via which the at least one input/output device can be connected to the central processor. 
         [0015]    In an alternative embodiment of the component, the component takes the form of a distribution node of a modular control system. In this case, the central processor, as a result of executing the system program, receives from the at least one input/output device at least one status signal of the industrial technical process, and transfers it to a higher-level control device. In addition in this embodiment, the central processor receives from the higher-level control device at least one control signal intended for the industrial technical process, and transfers it to the at least one input/output device. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0016]    Further advantages and details follow from the description below of exemplary embodiments with reference to the drawings, in which using schematic diagrams, 
           [0017]      FIG. 1  shows schematically an automation engineering system, a server and an industrial technical process, 
           [0018]      FIG. 2 to 4  show a flow diagram, 
           [0019]      FIG. 5  shows another automation engineering system, 
           [0020]      FIG. 6  shows a flow diagram, 
           [0021]      FIG. 7  shows another automation engineering system, and 
           [0022]      FIG. 8  shows a flow diagram. 
       
    
    
     DETAILED DESCRIPTION OF INVENTION 
       [0023]    As shown in  FIG. 1 , an automation engineering component  1  takes the form of a central control device (CPU) of a modular control system, for example a CPU of a PLC. The embodiment of component  1  as a central control device is purely by way of example, however. The automation engineering component  1  could alternatively take a different faun, for example the form of a distribution node of a modular control system (cf. the description below relating to  FIG. 5 ) or as a sensor device (cf. the description below relating to  FIG. 7 ). Other embodiments are also possible. 
         [0024]    As shown in  FIG. 1 , the automation engineering component  1  comprises a central processor  2 , a boot memory  3  and a system memory  4 . The central processor  2  can be a microprocessor, for example. A boot program  5  is stored in the boot memory  3 . A system program  6  can be stored in the system memory  4 . Alternatively, the system memory  4  can be empty or contain other information. In addition, the component  1  comprises (at least) one communications interface  7 , via which the central processor  2  can communicate with a server  8 . The description given above on the embodiment of the component  1  applies irrespective of whether or not the automation engineering component  1  takes the form of a central control device of a modular control system. 
         [0025]    In the specific embodiment of the component  1  as a central control device of a modular control system, there is also a user memory  9  present, in which a user program  10  can be stored. Alternatively, the user memory  9  can be empty or contain other information. 
         [0026]    Irrespective of the specific embodiment of the automation engineering component  1 , the component  1  performs an operating method, which is described in greater detail below with reference to  FIG. 2 . It should first be mentioned, however, that the terms “automation engineering component  1 ” and “central control device” are used in different senses below. Where information is given that pertains to the automation engineering component  1  it applies generally. Where information is given that pertains to the central control device, it relates specifically to the central control device. 
         [0027]    As shown in  FIG. 2 , the central processor  2  checks in a step S 1  whether a start condition is satisfied. Possible start conditions are discussed in greater detail later. 
         [0028]    In a step S 2 , the central processor  2  executes the boot program  5 . As a result of executing the boot program  5 , the central processor  2  in particular is able to communicate with the server  8 . Under what circumstances and in what form the central processor  2  communicates with the server  8  are discussed in greater detail below. 
         [0029]    When the central processor  2  is communicating with the server  8 , the central processor  2 , as a result of executing the boot program  5 , is also able to receive from the server numeral  8  a (new) system program  6 , and to store the newly received system program  6  in the system memory  4 . Where necessary, a system program  6  previously already stored in the system memory  4  can be overwritten in this process. Under what conditions the central processor  2  receives the system program  6  from the server  8  and stores it in the system memory  4  are also discussed further below. 
         [0030]    Then the central processor  2  in a step S 3  executes the system program  6 , which is stored in the system memory  4 . As a result of executing the system program  6 , the central processor  2  communicates at least once with at least one input/output device  11 , which is connected to the central processor  2 , in the case shown in  FIG. 1  via a control bus interface  12  of the central control device. The form of communication is also discussed in greater detail below. What is important is that communication between the central processor  2  and the input/output devices  11  takes place within the context of execution of the system program  6 . The boot program  5 , on the other hand, is designed so that, as a result of executing solely the boot program  5 , it is not possible for the central processor  2  to communicate with the input/output devices  11 . 
         [0031]    The input/output devices  11  are actively connected to an industrial technical process  13 . The input/output devices  11  are hence able to detect at least one status signal E of the industrial technical process  13  and transfer it to the automation engineering component  1 . Alternatively or additionally, the input/output devices  11  are able to output at least one control signal A to the industrial technical process  13  and thereby influence the industrial technical process  13 . 
         [0032]    The above operating method according to the invention, explained with reference to  FIG. 2 , is always performed, i.e. irrespective of the specific embodiment of the automation engineering component  1 . An embodiment of the operating method, which is practical when the central processor  2  also executes the user program  10 , is explained below with reference to  FIG. 3 . 
         [0033]    As shown in  FIG. 3 , the step S 3  is divided into three steps S 11 , S 12  and S 13 . In step S 11 , the central processor  2  executes a first part of the system program  6 . Within step S 11 , the central processor  2  receives from the input/output devices  11  the status signals E of the industrial technical process  13 . In step S 12 , the central processor  2  executes the user program  10 , which is stored in the user memory  9 . The user program  10  contains instructions that are used by the central processor  2  to evaluate the status signals E received in step S 11 . In addition, the central processor  2  uses the status signals E to determine the control signals A for the industrial technical process  13 , if applicable additionally using internal status signals of the component  1  (examples of such status signals include the values of timers, counters and flags). In step S 13 , the central processor  2  executes a second part of the system program  6 . Within step S 13 , the central processor  2  transmits to the input/output devices  11  the control signals A intended for the industrial technical process  13 . 
         [0034]    As shown in  FIG. 3 , the flow diagram in  FIG. 3  is executed cyclically. A cycle time (i.e. the time required to run through the flow diagram of  FIG. 3  once) usually lies in the region of a few milliseconds, in some cases even less than a millisecond, e.g. around 125 microseconds. The central processor  2  must hence switch continuously back and forth between executing the system program  6  (keyword “receiving the status signals E and transmitting the control signals A”) and executing the user program  10  (keyword “evaluating the status signals E and determining the control signals A”). The central processor  2  hence executes the system program  6  and the user program  10  quasi-simultaneously. 
         [0035]    The procedure of  FIG. 3  described so far is performed in particular when the automation engineering component  1  is controlling the industrial technical process  13 . As far as it relates to the procedure of  FIG. 3  described so far, the automation engineering component  1  can hence be one of the following units:
       a central control device of a modular control system (see  FIG. 1 ), for example a CPU of a PLC such as, purely by way of example, a CPU of the SIMATIC S7-300 series from Siemens AG, or   a control device, in which the input/output devices  11  are already integrated in the control device. An example of such a control device is a compact PLC of the earlier SIMATIC S5-90 or SIMATIC S5-95 series from Siemens AG.       
 
         [0038]    If the input/output units  11  are already integrated in the control device, it is even possible that additional input/output devices  11  are added to the respective compact device (see above for definition). For example, the SIMATIC S5-95 component from Siemens AG already has input/output devices  11  on board the compact device. In addition, however, input/output devices  11  of the modular control system SIMATIC S5-100 can also be connected to this compact device. 
         [0039]    If the central processor  2  executes the user program  10  quasi in parallel with the system program  6 , whether in the manner described so far with reference to  FIG. 3  or whether in another manner, the start condition can be realized in the way that is further described below with reference to  FIG. 3 . 
         [0040]    As shown in  FIG. 3 , the central processor  2  checks in a step S 14  whether it is being supplied with a new user program  10 . If the central processor  2  is not being supplied with a new user program  10 , a suitable response action is taken. What response action is suitable can depend on the circumstances of the individual case. For example, if the user program  10  executed by the central processor  2  is a user program of a programmable logic controller, the response action may be to return directly to step S 11 . On the other hand, if the user program  10  is a production instruction for a single workpiece (not several workpieces) to be manufactured, the response action may be to return to step S 14 . A procedure that can be applied in every case is described below with reference to  FIG. 3 . 
         [0041]    This is because according to  FIG. 3 , in the case that the component  1  is not supplied with a new user program  10 , the response action is to return to step S 1 . Step S 1  of  FIG. 3  is identical to step S 1  of  FIG. 2 , and therefore does not need to be explained again. 
         [0042]    On the other hand, if the component  1  is supplied with a new user program  10 , the central processor  2  executes steps S 15  and S 16 . In step S 15 , the central processor  2  accepts the new user program  10 . Step S 15  may involve, in particular, storing the new user program  10  in the user memory  9 . In step S 16 , the central processor  2  sets the start condition to “satisfied”. After executing step S 16 , the central processor  2  moves onto step S 1 . 
         [0043]    The contents of step S 2  of  FIG. 2  are also contained in  FIG. 3 . The step is split into steps S 17  to S 21 , however. In step S 17 , the control device  2  sets the start condition to “not satisfied”. Step S 17  is necessary to ensure that steps S 17  to S 21  are only run through once after a new user program  10  is supplied. 
         [0044]    In step S 18 , the central processor  2  checks whether the current system program  6  is optimum for the newly supplied user program  10 . If this is the case, execution moves directly to a step S 22 . Otherwise steps S 19  to S 21  are executed. Step S 18  is only optional. If it is not included, steps S 19  to S 21  are always executed. 
         [0045]    In step S 19 , the central processor  2  makes contact with the server  8 . In this process, it transmits to the server  8  at least one identifier indicating the type of the component  1 . It also transmits, at least usually, an item of information that the server  8  can use to determine the optimum system program  6 . For example, the central processor  2  can transmit to the server  8  the user program  10 , a type declaration of the user program  10 , or an identifier for the optimum system program  6  (“I need system program no.  7 ”). 
         [0046]    Within step S 19 , the central processor  2  can also transmit additional information to the server  8 . For example, it can also transmit an identifier by means of which the component  1  can be distinguished uniquely from other components, i.e. in particular also from components  1  of identical design. Other information can also be transmitted, for example an update status of the system program  6  currently stored in the system memory  6 . 
         [0047]    In step S 20 , the central processor  2  receives the new, optimum system program  6  from the server  8 . In step S 21 , the central processor  2  stores the received system program  6  in the system memory  4 . 
         [0048]    In step S 22 , the central processor  2  checks whether the user program  10  is to be executed. If the user program  10  is to be executed, the central processor  2  moves onto step S 11 . Otherwise, the central processor  2  moves onto step S 14 . Step S 22  is only optional. Step  22  can be used, however, to limit how often the user program  10  is executed. This is because, depending on the situation of the individual case, it can be practical to execute the user program alternatively once, multiple times or continuously (i.e. until an abort condition occurs e.g. a user  14  specifying a stop command). 
         [0049]    Further options that can be used to check whether the start condition is satisfied are explained below with reference to  FIG. 4 . The options can alternatively be given individually, in groups or all together. They can be in any order. The options of  FIG. 4  can also be combined with the condition “new user program  10  specified”. 
         [0050]    As shown in  FIG. 4 , the central processor  2  checks in a step S 31  whether the user  14  has specified a start command for it via a man-machine interface  15 . In addition, the central processor  2  checks in a step S 32  whether the server  8  has specified a start command for it (i.e. a communications request has been transmitted). In addition, the central processor  2  checks in a step S 33  whether it has executed the user program  10  sufficiently often, i.e. within step S 33  it compares with a preset number the number of times that it has executed the user program  10 . Owing to the cyclical execution of steps S 1  to S 3  (cf.  FIG. 2 ), this check corresponds to the number of times that the central processor  2  has communicated with the input/output devices  11 . Hence within step S 34 , it checks whether it has communicated with the input/output devices  11  for at least four hours or three days, for example, or whether a set time is reached, i.e. an absolutely defined time period has ended. 
         [0051]    If one of the checks of steps S 31  to S 34  is satisfied, the central processor  2  moves onto a step S 35 , in which it sets the start condition to “satisfied”. Step S 35  of  FIG. 4  corresponds to step S 16  of  FIG. 3 . Step S 1 , which has already been explained with reference to  FIG. 2 , comes after step S 35 . 
         [0052]    The present invention has been explained above with reference to a control device of a control system. The control system could be modular or non-modular in this case. The present invention is not limited to control devices, however. It can also be applied to other automation engineering components  1  for example, in particular where it relates to the embodiments shown in  FIG. 2 , in steps S 17  to S 21  of  FIG. 3  and in  FIG. 4 . An example of such a component is described in greater detail below with reference to  FIGS. 5 and 6 . 
         [0053]    As shown in  FIG. 5 , the component  1  is embodied as a distribution node of a modular control system. The distribution node  1  is connected to the input/output devices  11  via an input/output interface  16 . The input/output devices  11  can detect status signals E of the industrial technical process  13  and/or can output control signals A to the industrial technical process  13 . The distribution node  1  is also connected to a higher-level control device  18  via a control bus interface  17 . The control device  18  of  FIG. 5  can be the central control device of  FIG. 1  for example. Alternatively, however, it can also be a different control device. It is possible that the distribution node  1  executes a user program  10 . Alternatively, it is possible that the distribution node  10  does not execute a user program  10 . Communication with the server  8  may be made directly. Alternatively, communication can be made via the higher-level control device  18 . It is also possible that the higher-level control device  18  is identical to the server  8 . 
         [0054]    As shown in  FIG. 6 , the distribution node  1  of  FIG. 5  executes the operating method described above with reference to  FIG. 2 . Step S 3  is divided into steps S 41  to S 44  in the case of  FIG. 6 . 
         [0055]    In step S 41 , the central processor  2  receives from the input/output devices  11  status signals E of the industrial technical process  13 . In step S 42 , the central processor  2  transfers the status signals E to the higher-level control device  18 . In step S 43 , the central processor  2  receives from the higher-level control device  18  the control signals A for the industrial technical process  13 . In step S 44 , the central processor  2  transfers the control signals A to the input/output devices  11 . 
         [0056]    A further possible embodiment of the present invention is described below with reference to  FIGS. 7 and 8 . 
         [0057]    As shown in  FIG. 7 , the automation engineering component  1  takes the form of a sensor device. A plurality of sensors  19  are connected to the sensor device  1 . The sensors  19  may be part of the sensor device  1 . Alternatively they may be discrete components. The sensors  19  correspond to the input/output devices  11 . 
         [0058]    The sensor device  11  of  FIG. 7  is connected to an evaluation device  21  via a communications interface  20 . Communication with the server  8  is made either via the evaluation device  21  or directly with the server  8 . In addition, in a similar way to the embodiment of  FIG. 5 , the evaluation device  21  may be identical to the server  8 . 
         [0059]    As shown in  FIG. 8 , steps S 1  to S 3  of  FIG. 2  are implemented as follows: 
         [0060]    In a step S 51 , the central processor  2  checks whether the variable to be detected is to be changed. Changing the variable to be detected corresponds to the occurrence of the start condition. 
         [0061]    In a step S 52  (which corresponds to step S 1  of  FIG. 2 ), the central processor  2  checks whether the start condition is satisfied. 
         [0062]    If the start condition is satisfied, the central processor  2  establishes contact with the server  8  in a step S 53 . Within step S 53 , it transmits at least one type identifier. Usually it also transmits an identifier for the required system program  6  or for the variable to be detected. Step S 53  of  FIG. 8  corresponds essentially to step S 19  of  FIG. 3 . 
         [0063]    In a step S 54 , the central processor  2  receives from the server  8  the required system program  6 . In a step S 55 , the central processor  2  stores the received system program  6  in the system memory  4 . Steps S 54  and S 55  of  FIG. 5  correspond to steps S 20  and S 21  of  FIG. 3 . 
         [0064]    In a step S 56 , the central processor  2  detects the variable to be detected. If applicable, it performs further actions. Further actions may, for example, comprise saving or pre-evaluating the detected variable. Alternatively or additionally, it is possible that the detected variable, at least from time to time, is transmitted to the evaluation device  21 . Step S 56  corresponds to implementing step S 3  of  FIG. 2 . 
         [0065]    Numerous embodiments are possible based on the principles described above. 
         [0066]    For example, it is possible to retain information centrally in the server  8  that indicates when a certain system program  6  is intended for a particular component  1 . In this case it is not necessary that the respective component  1  notifies the server  8  which system program  6  it requires. Furthermore, in this case it is possible that the server  8  automatically addresses the respective component  1  and then transmits the system program  6 . 
         [0067]    It is also possible that the automation engineering component  1  interrogates the server periodically, e.g. once per day, once per week or once per month, as to whether an update of the system program  6  is available. 
         [0068]    It is also possible at start-up of the component  1  to execute initially a first, system program  6 , which is used to perform the checks and initialization procedures of the component  1 , and then to load subsequently a second system program  6  and, if applicable, also further system programs  6  that are required sequentially while the component  1  is running. 
         [0069]    It is also possible to optimize the system program  6  with regard to the requirements of the user program  10 . If, for example, the component  1  is a control unit of a CNC or an MCU, a user program  10  in which just two or three axes need to be actuated, can be executed more quickly than a user program  10  in which, for example, five or six or even more axes need to be actuated. 
         [0070]    Usually the system memory  4  is a non-volatile memory, i.e. the contents of the system memory  4  are retained even when the power supply of the system memory  4  is switched off. An example of such a non-volatile memory is a flash EPROM. Alternatively, however, it is also possible that the system memory  5  is a volatile memory e.g. a simple RAM. 
         [0071]    Usually the system memory  4  contains either no system program  6  or just one single system program  6 . Alternatively, however, it is also possible to scale and operate the system memory  4  such that two system programs  6  are stored simultaneously in the system memory  4 . In this case, it is possible, for example, while the component  1  is running (i.e. while one of the system programs  6  stored in the system memory  4  is being executed) to load gradually a new system program  6  additionally into the system memory  4 , and on completion of the loading process to switch over to the system program  6  just loaded. This procedure not only has the advantage that it can be executed even while the component  1  is running, but it also means that in the event that subsequent loading of the new system program  6  has failed (no matter for what reason), there is an executable system program  6  available in the system memory  4 . 
         [0072]    In addition, the system program  6  usually does not process any status signals E of the process  13  and nor does it determine any control signals A of the process  13 . This is possible in individual cases, however. 
         [0073]    The boot memory  3  is always a non-volatile memory. It may not be possible to modify the boot program  5  stored in the non-volatile memory  3 . Alternatively, it is possible that also the boot program  5  can be updated. Similar to the option of storing two system programs  6  simultaneously in the system memory  4 , where, however, just one of the system programs  6  is activated, such a procedure is also possible with regard to the boot memory  3  and the boot program  5 . 
         [0074]    Any manner of connection can theoretically be used between the component  1  and the server  8 . It can be direct or indirect. It can be a network connection or a point-to-point connection. Preferably communication between the component  1  and the server  8  is via the Internet. 
         [0075]    In particular, the system program  6  can be updated in a straightforward manner by means of the present invention. In addition, the system program  6  can be adapted easily to suit specific circumstances (e.g. to suit a user program  10  to be executed). No complicated interaction with the user  14  is needed. 
         [0076]    The description above serves solely to explain the present invention. The scope of protection of the present invention, however, shall be defined solely by the enclosed claims.