Sequence control of program modules

Abstract

A method for sequence control of program modules, includes providing a control means and a description file having a configuration for controlling a program sequence. The method further includes providing a plurality of program modules which can be executed by a real-time operating system, the program modules being created using one or different programming languages. The method furthermore includes initiating selected program modules by executing specifications in the description file using the control means.

Claims

1. A method for sequence control of program modules, wherein the program modules are executed by a control device as part of a control application run by the control device for controlling an automation system, said method comprising: providing a control means as a part of a firmware of the control device; providing a description file comprising a configuration for controlling a program sequence, the configuration comprising, for each of the program modules selected for execution, an identifier and associated information for executing the program module; providing a plurality of program modules which can be executed by a real-time operating system, wherein the program modules are created using one or different programming languages; evaluating the information contained in the description file by the control means; and initiating selected program modules by the control means on the basis of the configuration information specified in the description file.

2. The method according to claim 1, further comprising repeated initiation of at least one of the program modules by the control means.

3. The method according to claim 1, wherein the control means is designed to initiate at least some of the program modules such that said modules can be executed in different processes managed by the real-time operating system.

4. The method according to claim 3, wherein the real-time operating system is designed to execute the processes and/or process modules on the basis of pre-determined priorities.

5. The method according to claim 4, further comprising recording and evaluating the sequence control using the real-time operating system.

6. The method according to claim 1, further comprising changing the sequence control by adding or removing program modules, without a reboot of a control system being performed.

7. The method according to claim 1, further comprising dividing the sequence control over different processes.

8. The method according to claim 1, further comprising generating a statistical evaluation using profiling information.

9. The method according to claim 1, further comprising inserting at least one recording marking into a program module for providing an application diagnosis.

10. The method according to claim 1, further comprising using the control means as a master and providing at least one further control means as a slave which is subordinate to the control means as the master.

11. The method according to claim 1, further comprising assigning, by the control means, of individual tasks described in the description file to program modules.

12. A real-time operating system for sequence control of program modules, wherein the program modules are executed by a control device as part of a control application run by the control device for controlling an automation system, said real-time operating system comprising: a control means provided as a part of a firmware of the control device; a description file that is stored in a memory and comprises a configuration for controlling a program sequence, said configuration comprising, for each of the program modules selected for execution, an identifier and associated information for executing the program module; a plurality of program modules that can be executed by the real-time operating system and are created using one or different programming languages; wherein the control means is designed to evaluate the information contained in the description file and to initiate the program modules on the basis of the configuration information specified in the description file.

13. A control means for sequence control of program modules of one or different programming languages in a real-time operating system designed for performing the method according to claim 1, wherein the program modules are executable by a control device as part of a control application run by the control device for controlling an automation system, and wherein the control means is provided as part of a firmware of the control device.

14. A control device for controlling an automation system, said control device being adapted for sequence control of program modules of one or different programming languages in a real-time operating system, comprising: a control means according to claim 13; a processor; a memory; and at least one interface to a sensor or to an actuator of the automation system.

15. A computer program product comprising program code for performing the method according to claim 1, wherein the computer program product is executed on a computer system, in a real-time operating system.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) Some embodiments of the invention are shown purely schematically in the drawings, and will be described in greater detail in the following. In the drawings:

(2) FIG. 1 illustrates an embodiment for controlling an overall application in an automation system according to the present invention;

(3) FIG. 2 illustrates an embodiment, according to the present invention, of a schematic structure comprising the control means as the master and two further control means as slaves;

(4) FIG. 3 illustrates an embodiment, according to the present invention, of controlling a program sequence using a control means;

(5) FIG. 4 illustrates an embodiment, according to the present invention, of a schematic structure comprising a control means.

DETAILED DESCRIPTION

(6) FIG. 1 illustrates an embodiment for controlling an overall application 10 in an automation system according to the present invention.

(7) In this connection, an overall application is understood to mean all programs or program modules, tasks and configuration settings which are required for execution on a control device. In this case, it is irrelevant whether the control device or the controller is the only one or is one of a plurality of devices.

(8) Cyclical processing of programs or program modules is typical of automation. Feedback to the user is typically not provided within the context of these cycles.

(9) FIG. 1 shows a schematic structure of three tasks 20, 30, 40, which overall synchronously execute four programs or program modules 21, 31, 32, 41 from the domains of IEC 61131-3, C++, and Matlab/Simulink. The program module 21 is a CPP filter and is programmed in the programming language C++. The program module 31 is an IEC prepare program and is programmed in one of the programming languages according to the IEC standardization. The program module 32 is a SIM-CTRL program, i.e. a control program, and is programmed in the programing language Matlab/Simulink. The program module 41 is an IEC-Sync program, i.e. a synchronization program, and is programmed in one of the programming languages according to the IEC standardization. In this context, the terms “program” and “program module” are used interchangeable.

(10) After the procedure end or the process end of the program module 30, the program module 41 initiates the start of the task 40, via an interface 33, by way of a communications link 34.

(11) The tasks 20, 30, 40 of FIG. 1 have different priorities for the execution of the overall application 10, the task 20, as the main task, having the lowest priority, the task 30, as the control task or Ctrl-Task, having a medium priority, and the task 40, as the event task having synchronization tasks, having the highest priority. The task 20 furthermore has a cycle time of 5 ms (ms=milliseconds), and the task 30 has a cycle time of 30 ms. The task 40 is executed once, and ends when the program module 41 or the program in the program module has bene processed (event: proc_end).

(12) FIG. 2 illustrates an embodiment, according to the present invention, of a schematic structure comprising a control means 50 as the master, a control means 60 subordinate to the master as the first slave, and a further control means 70 subordinate to the master as the second slave. In this case, the master components and slave components 50, 60, 70 are used in order to coordinate program modules, from different program domains, in different processes. FIG. 2 furthermore shows different operating system processes or OS processes 11, 12, 13 which each comprise OS threads 14, 15, 16, 17, 18.

(13) The procedure according to the invention makes it possible to compose heterogeneous task contents. In this case, the processing sequence within a task can be selected freely and is not specified in a manner dependent on the system, and consistent data exchange between program instances is possible.

(14) The configuration of the master 50 and the tasks 20, 30, 40 thereof is achieved by one or more description files, in this case in the form of one or more XML files, which allow for configuration instead of programming. As a result, the function of a system can be changed at the runtime, without the individual application portions having to be translated again. The description file or the XML-based configuration also allows the user to make adjustments directly on the controller, or to use independent external tools and tool chains.

(15) The structure of the description file, in particular in the form of an XML file, can in this case be specified by clearly defined schema files, allowing for quick checking of the configuration. The specification of tasks and the associated program instances in a plurality of description files or XML configuration files makes it possible to split the overall application 10 into functional modules which can be created by different developer groups or suppliers. This facilitates not only the development of a complex sequence control system, but also the step-wise expansion of a running system. As a result, it is not necessary for the overall application 10 to be available from the beginning, but said application can instead be composed of partial modules.

(16) In addition, the definition of parameters in the description file or XML file allows for each task 20, 30, 40 to be assigned to a processor core, a group, or to all processor cores of the controller.

(17) A flexible system consisting of master and slave components 50, 60, 70 furthermore allows the user to execute programs over process boundaries. This is an advantageous prerequisite for separating programs of different users, which programs are thus executed in encapsulated memory regions. The memory protect mechanisms of the underlying real-time operating system can be used as the basis for this. For security reasons, it is therefore possible to restrict the access of programs or program modules in accordance with the user rights.

(18) In FIG. 2, the master 50 in each case configures one program module 21, 41 of a slave 60, 70 via operative connections 51, 52. In this case, “configuration” relates to the provision of priority information by the master 50. Furthermore, communications links 53, 54, 57, 58 are present in FIG. 2 in order to exchange commands and information or feedback among the individual program modules 21, 31, 32, 41 and a task 20, 30, 40. In this case, the information is sent back and forth and/or received in each case between master and slave instances. Commands are for example initiation commands (“initiates”) of the task 20, 40 to the program module 21, 41. Feedback is sent for example from the program modules 21, 41 to the tasks 20, 40 (“reports”). Furthermore, initiation commands (“initiates”) are also in each case sent from the task 30 to the program modules 31, 32 via the communications links 55, 56, the communication taking place within an OS thread.

(19) The proposed procedure makes it possible to transfer the known tasks from the IEC standardization into the field of high-level languages. As a result, the control means supports current cyclical tasks, idle tasks and event-based tasks which are represented on the priority-controlled processes and threads of the real-time operating system. In addition to said priority-controlled execution, the control means also makes it possible to execute tasks in response to the occurrence of a special event. This freely configurable system therefore makes it possible to mix program instances of different program domains within one task, and to execute said instances together. As a result, the sequence models known from IEC 61131-3 are also opened up for other domains.

(20) However, the degrees of freedom offered by the task execution using the control means 50 also increase the complexity during configuration and analysis. The control means 50 therefore provides integrated mechanisms for detailed profiling based on available expansion of the real-time operating system. The user is thus provided with the possibility of observing, evaluating and recording different properties of the task execution and of the operating system. These properties include, inter alia, the execution times of the tasks and program instances, frequency of task replacements, latency and jitter, system utilization, or watchdog monitoring. This information can also be evaluated, using dynamic ring buffers, for post mortem analyses following an error.

(21) Furthermore, centrally storing the profiling information of the control means 50 allows for statistical evaluations to be performed without said data being available for further analyses by remote server systems.

(22) FIG. 3 illustrates an embodiment, according to the present invention, of controlling a program sequence using a control means 50. In order to perform an automation task, the control means 50 can also access all auxiliary instances, such as one slave or a plurality of slaves, as shown in FIG. 2.

(23) FIG. 3 illustrates, in a simplified manner, coordination or control of control tasks by a control means 50, as is shown for example in FIG. 2. In this case, the described tasks 20, 30, 40 of FIG. 1 are controlled by the control means 50. In the case of this control or the evaluation thereof, it is possible to clearly trace when the individual programs and tasks are replaced by higher-level processes. These higher-level processes are reserved for the operating system and are shown in FIG. 3 ad OS processes 19.

(24) FIG. 3 shows the time on the x-axis, and processes or priority of the process on the y-axis. Therefore, as already explained with reference to FIG. 1, the task 20 has the lowest priority and the task 40 has the highest priority. RTOS denotes a high-priority thread 90 of the real-time operating system (RTOS), which thread has the highest priority. The high-priority thread 90 or high-priority OS thread 90 is, accordingly, part of the real-time operating system.

(25) As a result, the first task 20 is executed first, in time, by the program module 21, but this is interrupted by a real-time process 19 of the operating system. Subsequently, task 30 is processed by program modules 31 and 32. Thereafter, task 40 is processed by the program module 41. Here, too, there are temporary interruptions of the program modules by real-time processes 19. After the higher priorities have been processed, task 20 begins again, and thereafter task 30 is executed, and therefore FIG. 3 indicates cyclical processing of the tasks.

(26) Overall, according to the invention, a functionality is made possible, as a component of a new firmware architecture, on the basis of which functionality new industrial controls are implemented. This architecture is initially implemented for use on a device or control device. The architecture is designed, however, such that expansion to a plurality of devices is possible. This is the case for example in a redundancy system, in which two controls are executed synchronously.

(27) The aim in this case is to support the supplementation of conventional programming of controllers by high-level languages. For this purpose, a smooth transition between the IEC 61131-3 and the field of high-level languages is sought. A prerequisite for this, in addition to the support of languages of this kind, is also the seamless integration of the different programming domains. These include, inter alia, Matlab/Simulink, C++, C #, JAVA, Python and the languages of IEC 61131-3. In order to achieve a seamless integration of this kind, the control system should be capable of transferring the sequence known from IEC 61131-3, comprising program instances and tasks, into the sequence of other programming domains. Despite these more complex requirements of the technical implementation, aspects of data security, usability, flexibility and above all performance, are in addition ensured.

(28) FIG. 4 illustrates an embodiment, according to the present invention, of a schematic structure comprising a control means 50. In this embodiment, an operating system process or OS process 11 is shown, which comprises OS threads 14, 15, 16.

(29) The procedure according to the invention makes it possible to compose heterogeneous task contents. In this case, the processing sequence within a task can be selected freely and is not specified in a manner dependent on the system, and consistent data exchange between program instances is possible.

(30) The configuration of the master 50 and the tasks 20, 30, 40 thereof is achieved by one or more description files, in this case in the form of one or more XML files, which allow for configuration instead of programming. As a result, the function of a system can be changed at the runtime, without the individual application portions having to be translated again. The description file or the XML-based configuration also allows the user to make adjustments directly on the controller, or to use independent external tools and tool chains.

(31) The structure of the description file, in particular in the form of an XML file, can in this case be specified by clearly defined schema files, allowing for quick checking of the configuration. The specification of tasks and the associated program instances in a plurality of description files or XML configuration files makes it possible to split the overall application 10 into functional modules which can be created by different developer groups or suppliers. This facilitates not only the development of a complex sequence control system, but also the step-wise expansion of a running system. As a result, it is not necessary for the overall application 10 to be available from the beginning, but said application can instead be composed of partial modules.

(32) In addition, the definition of parameters in the description file or XML file allows for each task 20, 30, 40 to be assigned to a processor core, a group, or to all processor cores of the controller. The task 30 in each case sends initiation commands (“initiate”) to the program modules 31, 32 via the communications links 55, 56, the communication taking place within an OS thread.

(33) The embodiment shown in FIG. 4 advantageously allows for the execution of the program modules in one single common OC process, it being possible for the program modules to be created using different programming languages.

(34) The advantages and designs set out above, in connection with the embodiment shown in FIG. 2, apart from those relating to the master/slave aspects, also apply to the embodiment shown in FIG. 4.

(35) A possible content of a description file in XML format is set out below, by way of example:

(36) TABLE-US-00001 <?xml version=“1.0” encoding=“UTF-8”?> <EsmConfigurationDocument> <EsmComponentSettings> <SharedDataSettings Size=“1024” /> </EsmComponentSettings> <EsmList> <Esm Name=“ESM0” CpuAffinity=“0” TimerInterval=“500us” TaskScheduleMode=“IntervalCounting” /> <Esm Name=“ESMI” CpuAffinity=“I” TimerInterval=“100us” TaskSchedulerMode=“SystemClock”/> </EsmList> <Tasks> <Task Name=“TaskCount” CycleTime=“500us” TaskType-“Cyclic” TaskPriority=“4” /> <Task Name=“TaskConf” CycleTime=“250ms” TaskType-“Cyclic” TaskPriority=“5” /> <Task Name=“TaskMain” CycleTime=“10ms” TaskType-“Cyclic” TaskPriority=“7” /> </Tasks> <EsmTaskRelations> <EsmTaskRelation ESMName=“ESM0’ TaskName=“TaskCount” /> <EsmTaskRelation ESMName=“ESM0’ TaskName=“TaskConf” /> <EsmTaskRelation ESMName=“ESMI’ TaskName=“TaskMain”/> </EsmTaskRelations> <Programs> <Program Name=“CppCounter-1” ProgramType=“CppCounter” ComponentName=“Arp.Demonstrator.CppCounter-1” /> <Program Name=“CppConfig-1” ProgramType=“CppConfig” ComponentName=“Arp.Demonstrator.CppConfig-1” /> <Program Name=“PizController-I’ ProgramType=“PizController’ ComponentName=“Arp.Demonstrator.PizController-1” /> <Program Name=“SimHeli-I” ProgramType=“SimHeli” ComponentName=“Arp.Demonstrator.SimHeli-1” /> </Programs> <TaskProgramRelations> <TaskProgramRelation TaskName=“TaskCount” ProgramName=“Arp.Demonstrator.CppCounter-1/CppCounter-1” Order=“0” /> <TaskProgramRelation TaskName=“TaskConf” ProgramName=“Arp.Demonstrator.CppConfig-I/CppConfig-1” Order=“0” /> <TaskProgramRelation TaskName=“TaskMain” ProgramName=“Arp.Demonstrator.PizController-I/PizController-1” Order=“0” /> <TaskProgramRelation TaskName=“TaskMain” ProgramName=“Arp.Demonstrator.SimHeli-1.SimHeli-1” Order=“1” /> </TaskProgramRelations> </EsmConfigurationDocument>

LIST OF REFERENCE SIGNS

(37) 10 overall application

(38) 11 OS process

(39) 12 OS process

(40) 13 OS process

(41) 14 OS thread

(42) 15 OS thread

(43) 16 OS thread

(44) 17 OS thread

(45) 18 OS thread

(46) 19 OS process

(47) 20 task

(48) 21 program module

(49) 30 task

(50) 31 program module

(51) 32 program module

(52) 33 procedure end

(53) 34 communications interface

(54) 40 task

(55) 41 program module

(56) 50 control means or ESM

(57) 51 operative connection

(58) 52 operative connection

(59) 53 communications link

(60) 54 communications link

(61) 55 communications link

(62) 56 communications link

(63) 57 communications link

(64) 58 communications link

(65) 60 control means or ESM as first slave

(66) 70 control means or ESM as second slave

(67) 80 OS process

(68) 90 high-priority OS thread