[go: up one dir, main page]

WO2011063869A1 - Verfahren zum ermöglichen einer sequentiellen, nicht blockierenden abarbeitung von anweisungen in nebenläufigen tasks in einer steuereinrichtung - Google Patents

Verfahren zum ermöglichen einer sequentiellen, nicht blockierenden abarbeitung von anweisungen in nebenläufigen tasks in einer steuereinrichtung Download PDF

Info

Publication number
WO2011063869A1
WO2011063869A1 PCT/EP2010/005527 EP2010005527W WO2011063869A1 WO 2011063869 A1 WO2011063869 A1 WO 2011063869A1 EP 2010005527 W EP2010005527 W EP 2010005527W WO 2011063869 A1 WO2011063869 A1 WO 2011063869A1
Authority
WO
WIPO (PCT)
Prior art keywords
operating system
task
instruction
tasks
programmable logic
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/EP2010/005527
Other languages
English (en)
French (fr)
Inventor
Edgar Holembowski
Helene Schloter
Florian Zang
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Robert Bosch GmbH
Original Assignee
Robert Bosch GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Robert Bosch GmbH filed Critical Robert Bosch GmbH
Priority to US13/511,979 priority Critical patent/US9152454B2/en
Publication of WO2011063869A1 publication Critical patent/WO2011063869A1/de
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4812—Task transfer initiation or dispatching by interrupt, e.g. masked
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/05—Programmable logic controllers, e.g. simulating logic interconnections of signals according to ladder diagrams or function charts
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/10—Plc systems
    • G05B2219/11—Plc I-O input output
    • G05B2219/1162—Forcing I-O
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/10—Plc systems
    • G05B2219/13—Plc programming
    • G05B2219/13068—Program divided in operation blocks, groups, tasks each executed
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/10—Plc systems
    • G05B2219/13—Plc programming
    • G05B2219/13117—Two languages, ladder diagram and machine code for processor
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/10—Plc systems
    • G05B2219/15—Plc structure of the system
    • G05B2219/15079—Multitasking, real time multitasking

Definitions

  • the present invention relates to a method for enabling a sequential, non-blocking processing of instructions in concurrent tasks in a control device having a multitasking operating system, in particular a programmable logic controller (PLC), as well as a control device and a computer program.
  • PLC programmable logic controller
  • Programmable logic controllers are known in different variants. These are devices that are used to control or regulate a machine or system and are programmed on a digital basis. Programmable logic controllers have replaced the hard-wired (connection-programmed) controllers used in the past and, like them, are primarily state-oriented.
  • the European standard EN 61131 which corresponds to the international standard IEC 61131, deals with the basics of programmable logic controllers and, in Part 3 (IEC / EN 61 131-3), contains definitions concerning programming languages used in programmable logic controllers.
  • the programming languages and / or regulations “Instruction List” (Instruction List, IL, AWL), “Ladder Diagram” (LD, KOP), “Function Block Diagram” (FBD), FBS), “Sequential Function Chart” (SFC, AS) and “Structured Text” (ST).
  • the pro- The programming language ST is based on well-known programming languages and is also known as Structured Control Language.
  • the languages IL and ST are text-based, the other languages (LD, FBD, SFC) are graphical forms. Functions and function blocks which are previously defined in another language and / or provided by the manufacturer of a corresponding programmable logic controller in the form of software libraries (in binary form even without source code) can be used in all of the languages mentioned.
  • the control program defined by the user is stored in a special electronically readable memory.
  • the program processing in a programmable logic controller is performed by the central processing unit (CPU), which usually involves a cyclic processing of instructions.
  • the programmable logic controller initially assumes the signal states of the inputs, whereby the process image of the inputs is renewed.
  • a user program is processed, statement by instruction.
  • the previously generated process image is accessed.
  • the process image of the outputs is transmitted in the form of the current status, the cycle is thus ended.
  • the order shown is typically executed within a task.
  • the programmable logic controller then begins executing the next prioritized task.
  • the mentioned cyclic program processing can take the form of synchronous (fixed, ie isochronous) or asynchronous cycles.
  • Programmable logic controllers can also be event-driven, state-controlled or freewheeling.
  • processing takes place in a "round robin" method at a low priority level.
  • the processing sequence corresponds to the above-mentioned cyclic processing, but no cycle time is defined. Therefore, compared to cyclic tasks, very long processing times can occur, which may cause the problem that the input images "out of date" and the output images are not updated in time. Therefore, as explained further below, in particular the renewal of the input process image explained above as well as the transmission of the output process image independently thereof (for example, in a concurrent task) take place.
  • Multitasking refers to the concurrent execution of multiple tasks or tasks by an operating system.
  • different processes are activated in a predetermined sequence or priority, cyclically repeating or freewheeling, so that the impression of simultaneous processing arises.
  • a sequential programming essentially within the specifications of the standard EN / IEC 6113-3 by means of the programming language "Structured Text" and using a cooperative multitasking model can be realized.
  • This programming can be used to process so-called free-running tasks.
  • the execution of instructions of a flow control can be improved.
  • a flow control is much more compact to program.
  • the program code quantity to be generated by the programmer is considerably reduced.
  • the processor time is better distributed to the individual tasks.
  • a conventional sequential execution of instructions in free-running tasks in a PLC is blocking.
  • sequential processing which corresponds to a machine sequence or a machine sequence
  • the system waits at the points or at program steps at which actions (eg motion or movement commands) are initiated until the execution of the action is acknowledged.
  • actions eg motion or movement commands
  • the basis for implementing the present invention may be, for example, a conventional type programmable logic controller having an operating system that is capable of multitasking, that is, has operating system calls that cause the operating system to suspend the respective currently executing task in favor of another. if the task or a higher-level unit (watchdog) signals this.
  • Such switching tasks can for example be done when in a task a wait state arises (waiting for an event) and, for example, therefore, an operating system function wait () is called.
  • free-running tasks are to be used which are suitable for optimally utilizing the residual computing time of a programmable logic controller or of a processor in such a controller.
  • the switching logic corresponds advantageously to the known "cooperative multitasking".
  • Cooperative multitasking refers to a multitasking process in which each process "voluntarily” returns control to the kernel when this process no longer requires any computational time. It is up to each process to decide when to return control to the core.
  • Cooperative multitasking can be easily realized if the respective processes reliably return the control to the core. However, as soon as a single process or task terminates its cooperation (for example due to a malfunction), which does not return the control to the operating system, this can result in a shutdown of all involved, free-running tasks. According to a preferred embodiment, it is therefore proposed to provide a watchdog function in order to enable a forced interruption of one task in favor of another.
  • switching between tasks can advantageously always be carried out at positions or at program steps at which a respective process or task waits for an event, ie, for example, the execution of a task and / or a command. This measure advantageously results in an optimal allocation of the processor time.
  • standard commands are advantageously encapsulated in a respective new function, wherein one or more operating system calls are allocated within the encapsulated function.
  • the library function operating system function
  • the library function is then called to release the processor time.
  • Such a function for releasing the processor time is also available, for example, for control structures such as WHILE loops in order to enable the user or programmer, in particular when programming an endless loop without termination conditions, to release the processor time.
  • a control device likewise provided according to the invention, in particular a programmable logic controller, has all the means for carrying out a method according to the invention as explained above.
  • the computer program provided according to the invention comprises program code means, in particular at least one instruction and operating system calls encapsulating structure, which are provided by a method according to the invention.
  • Suitable data carriers for such a computer program are, in particular, floppy disks, hard disks, flash memory, EEPROM, CD-ROM, DVDs, etc.
  • a download of such a program via a computer network Internet, intranet, system network, etc. is also possible.
  • Figure 1 shows a periodic and a cyclic execution of instructions in a programmable logic controller according to the prior art in a schematic representation.
  • Figure 2 shows a processing of a free-running task in a motion control according to the prior art in a schematic representation.
  • Figure 3 shows a sequential, non-blocking processing of instructions in concurrent tasks in control device according to a particularly preferred embodiment of the invention in a schematic representation.
  • Figure 4 shows a sequential, non-blocking processing of instructions in concurrent tasks in control device according to a further particularly preferred embodiment of the invention in a schematic representation.
  • FIG. 1 the usual, known from the prior art processing of instructions in programmable logic controllers is shown.
  • scheme 100 a cyclic processing of instructions or commands is depicted in scheme 110, wherein in the case of periodic execution 100 a cycle time t is specified as synchronous.
  • the cycle time t 1 f t 2 , t 3 varies according to the duration of the respective processing of a command V.
  • a stored program controller reads an input image E at the beginning of each cycle and writes at the end of a cycle, labeled A, an output image. Between the reading of the input image and the writing of the output image, the processing of a user program or the execution of commands V takes place.
  • FIG. 2 corresponding to the representation of FIG. 1, a processing of instructions 200 is shown, as conventionally implemented in a motion control device (motion control).
  • the processing takes place in the form of a free-running task V, which is processed cycle-independently and triggered again after execution.
  • an updating of the input and output image via a concurrent task is carried out continuously in the form of a periodic, concurrent task or in the form of an interval control.
  • the instruction flow in a motion control device is usually sequential blocking.
  • the measures according to the invention include, inter alia, a sequential blocking processing of instructions, as they are principally composed of a motion controller. is known to transfer to a programmable logic controller. In programmable logic controllers, due to the limited possibilities of conventional programming languages available there, such a sequential blocking execution of instructions is not possible.
  • the present invention provides a capsule structure in which a command to be executed is encapsulated and which has one or more operating system calls in addition to the command to be executed, on the one hand for reading an output image and writing an input image on the other hand, and can cause switching between concurrent tasks.
  • FIG. 3 shows a processing of concurrent tasks, which according to a particularly preferred embodiment takes place in a sequential blocking manner.
  • the cycle sequence is specified in a programmable logic controller, with 2 the actual processing of the respective tasks is specified.
  • T1 designates a first task
  • T2 a second task
  • T3 a third task, wherein the tasks T1, T2 and T3 are executed concurrently (in parallel) and because of the multitasking capability of the operating system gives the impression of simultaneous processing.
  • T1 designates a first task
  • T2 a second task
  • T3 a third task, wherein the tasks T1, T2 and T3 are executed concurrently (in parallel) and because of the multitasking capability of the operating system gives the impression of simultaneous processing.
  • T1 designates a first task
  • T2 a second task
  • T3 a third task
  • the tasks T1, T2 and T3 are executed concurrently (in parallel) and because of the multitasking capability of the operating system gives the impression of simultaneous processing.
  • 320
  • Switching between the respective tasks T1, T2 and T3 takes place in each case at times or transfer points 310.
  • the transfer 310 of a check from one task to another task is carried out by the operating system and based on an operating system call, for example a function wait ().
  • the inventive measures are advantageously realized in the form of a capsule function 320 or capsule structure 320, which will be explained in more detail below.
  • the capsule structure represents an encapsulating command that includes the actual command to be executed.
  • the programmer uses this encapsulated command (eg "sMoveAbsolutQ") instead of the original command (eg "MoveAbsolutQ").
  • the programmer need not include the operating system call itself in his program, which facilitates realization even without knowledge of the program internals.
  • the task T1 usually begins with the reading of an input image. Subsequently, the instructions of the tasks T1 are run through until an encapsulated command is encountered. This is represented by block 320.
  • the convention of the conventionally blocking instruction begins.
  • an instruction is issued to a motion controller (eg, a motion handler). This is expediently carried out in the form of a call of a motion function to an interpolator.
  • a first operating system call is made, denoted by *, in this case the writing of an output image.
  • the system waits for execution of the command.
  • a capsule structure 320 includes a check function consisting of a query command 305 and a wait step 306, in which it is queried in step 305 whether the transferring command has been completely executed. If so, the execution of the commands continues as shown below. If this is not yet the case, execution of the program continues with step 306, in which another cycle t is awaited.
  • an operating system call is made which causes an operating system to interrupt the respective task in favor of another, i. allocate the computation time to another task. This transfer is symbolized by arrow 310.
  • routine 307 the program returns to query 305.
  • the check thus includes a cycle that runs as long as a processing of the command given in step 302 has not yet taken place.
  • step 308 Upon receipt of the computation time and execution of the instruction 302, the program proceeds to step 308 where, also in the form of an operating system call, an input image is read and the encapsulated instruction is terminated with step 309. Subsequently, the commands of the current task are processed further until, for example, a further encapsulated command is issued.
  • FIG. 3 shows a structure in which it is ascertained in the form of a query function whether a command 302 issued has been completely executed.
  • FIG. 4 An alternative embodiment for this purpose is shown in FIG. 4 and indicated as a whole by 400.
  • a semaphore function 416 is used here.
  • a capsule function 420 is also used here.
  • the command begins with step 401.
  • step 402 analogous to step 302 of FIG. 3, a command is passed to a motion handler.
  • step 410 an operating system call is made, which relinquishes control to another process.
  • a semaphore function 416 is also triggered, which suspends the task to be executed and thus puts it into a passive waiting function or waiting situation.
  • step 402 Until the time at which the semaphore function signals that the instruction triggered in step 402 has been executed, the instruction remains in the suspended state and is reactivated or activated only after the semaphore instruction. The instruction then arrives at step 409 The End.
  • FIG. 4 shows a processing of tasks, analogous to FIG. Due to the suspension S of the task T1, however, this is not executed in the cycles t2 and t3, but is only processed again in the cycle t4 after reactivation R.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Programmable Controllers (AREA)

Abstract

In einem Verfahren zum Ermöglichen einer sequentiellen, nicht blockierenden Abarbeitung von Anweisungen (302, 402) in nebenläufigen Tasks (T1, T2, T3) in einer Steuereinrichtung mit einem multitaskingfähigen Betriebssystem, insbesondere einer speicherprogrammierbaren Steuerung, wird wenigstens einer Anweisung (302, 402) wenigstens ein Betriebssystemaufruf (310, 410) zugeordnet, der das Betriebssystem dazu veranlasst, die jeweilige Task (T1, T2, T3) nach einer durch die Anweisung (302, 402) ausgegebenen Instruktion zugunsten einer anderen Task (T1, T2, T3) zu unterbrechen.

Description

Verfahren zum Ermöglichen einer sequentiellen, nicht blockierenden Abarbeitung Anweisungen in nebenläufigen Tasks in einer Steuereinrichtung
Beschreibung
Die vorliegende Erfindung betrifft ein Verfahren zum Ermöglichen einer sequentiellen, nicht blockierenden Abarbeitung von Anweisungen in nebenläufigen Tasks in einer Steuereinrichtung mit einem multitaskingfähigen Betriebssystem, insbesondere einer speicherprogram- mierbaren Steuerung (SPS), sowie eine Steuereinrichtung und ein Computerprogramm.
Stand der Technik
Speicherprogrammierbare Steuerungen sind in unterschiedlichen Varianten bekannt. Es handelt sich hierbei um Geräte, die zur Steuerung oder Regelung einer Maschine oder Anlage eingesetzt und auf digitaler Basis programmiert werden. Speicherprogrammierbare Steuerungen haben die in der Vergangenheit verwendeten, fest verdrahteten (verbindungspro- grammierten) Steuerungen abgelöst und arbeiten wie diese primär zustandsorientiert. Die europäische Norm EN 61131 , die der internationalen Norm IEC 61131 entspricht, behandelt Grundlagen von speicherprogrammierbaren Steuerungen und beinhaltet in Teil 3 (IEC/EN 61 131-3) Definitionen bezüglich in speicherprogrammierbaren Steuerungen verwendeter Programmiersprachen. In der EN/IEC 61 131-3 sind die Programmiersprachen bzw. -Vorschriften "Anweisungsliste" (Instruction List, IL, AWL), "Kontaktplan" (Letter Diagram, LD, KOP), "Funktionsbausteinsprache" (Function Block Diagram, FBD, FBS), "Ablaufsprache" (Sequential Function Chart, SFC, AS) und "Strukturierter Text" (Structured Text, ST) definiert. Insbesondere die Pro- grammiersprache ST lehnt sich an bekannte Programmierhochsprachen an und wird auch als Structured Control Language bezeichnet. Die Sprachen IL und ST sind textbasiert, bei den übrigen Sprachen (LD, FBD, SFC) handelt es sich um grafische Formen. In sämtlichen der genannten Sprachen können Funktionen und Funktionsblöcke verwendet werden, wel- che zuvor in einer anderen Sprache definiert und/oder vom Hersteller einer entsprechenden speicherprogrammierbaren Steuerung in Form von Softwarebibliotheken (in binärer Form auch ohne Quelltext) zur Verfügung gestellt werden.
Bei speicherprogrammierbaren Steuerungen ist das Steuerungsprogramm, das vom Benut- zer definiert wird, in einem speziellen elektronisch lesbaren Speicher abgelegt. Die Programmverarbeitung in einer speicherprogrammierbaren Steuerung erfolgt durch die zentrale Recheneinheit (CPU), wobei in der Regel eine zyklische Bearbeitung von Anweisungen erfolgt. Hierbei übernimmt die speicherprogrammierbare Steuerung zunächst die Signalzustände der Eingänge, wodurch das Prozessabbild der Eingänge erneuert wird. In einem nächsten Schritt wird ein Anwenderprogramm Anweisung für Anweisung abgearbeitet. Bei einer hierzu erforderlichen Abfrage der Signalzustände der Eingänge wird auf das zuvor erzeugte Prozessabbild zugegriffen. Nach schrittweiser Abarbeitung der Anweisungen wird das Prozessabbild der Ausgänge in Form des aktuellen Zustands übertragen, der Zyklus ist damit beendet. Die dargestellte Reihenfolge (Eingangsabbild, Verarbeitung, Ausgangsab- bild) wird typischerweise innerhalb einer Task ausgeführt. Die speicherprogrammierbare Steuerung beginnt anschließend mit der Ausführung der nächst priorisierten Task. Die genannte zyklische Programmbearbeitung kann in Form synchroner (fester, also isochroner) oder asynchroner Zyklen erfolgen. Speicherprogrammierbare Steuerungen können darüber hinaus ereignisgesteuert, statusgesteuert oder freilaufend arbeiten.
Bei freilaufenden Tasks innerhalb einer speicherprogrammierbaren Steuerung erfolgt die Abarbeitung im "Round Robin"-Verfahren auf niedrig priorisierter Ebene. Die Abarbeitungs- folge entspricht der oben genannten zyklischen Bearbeitung, es ist jedoch keine Zykluszeit definiert. Daher können im Vergleich zu zyklischen Tasks sehr lange Verarbeitungszeiten auftreten, wodurch das Problem entstehen kann, dass die Eingangsabbilder "veralten" und die Ausgangsabbilder nicht rechtzeitig erneuert werden. Daher muss, wie unten weiter ausgeführt, insbesondere die zuvor erläuterte Erneuerung des Eingangsprozessabbilds sowie die Übertragung des Ausgangsprozessabbilds unabhängig hiervon (beispielsweise in einer nebenläufigen Task) erfolgen.
Insbesondere bei der zyklischen Abarbeitung von Anweisungen in speicherprogrammierba- ren Steuerungen tritt das Problem auf, dass häufig die Arbeitszeit eines Prozessors der speicherprogrammierbaren Steuerung nicht optimal ausgenutzt wird, weil in der Taskver- wendung nicht zwischen Prozessdatenverarbeitung (zyklische, höher priorisierte Tasks) und Ablaufsteuerung (sequentielle, niederpriorisierte, freilaufende Tasks) unterschieden wird. Vielmehr wird die Ablaufsteuerung durch den Einsatz einer Schrittkettenverwaltung bzw. SFC (AS) innerhalb der zyklischen Tasks realisiert. Daher muss die Priorisierung (Zyklus- Zeit) der Tasks so ausgelegt werden, dass immer alle Tasks ihre maximale Rechenzeit (Watchdog-Zeit) einhalten können. Diese„Worst Case"- Betrachtung führt zur ineffektiven Nutzung der Rechenzeit, da im Normalzustand eine geringere Rechenzeit benötigt wird und die dann ungenutzte Rechenzeit nahezu verloren geht. Zudem ergibt sich bei der Program- mierung der Schrittkette bzw. in der Ablaufsprache ein erheblicher Mehraufwand gegenüber sequentiell arbeitenden Befehlen, da diese die Weiterschaltbedingungen implizit realisieren.
In Rechnersystemen sind zur Vergabe von Rechenzeit an Tasks sogenannte Multitasking- Funktionen verfügbar. Multitasking- bzw. Mehrprozessbetrieb bezeichnet die nebenläufige Ausführung mehrerer Aufgaben bzw. Tasks durch ein Betriebssystem. Hierzu werden unterschiedliche Prozesse in vorgegebener Reihenfolge bzw. Priorität, zyklisch wiederholend oder freilaufend aktiviert, so dass der Eindruck einer gleichzeitigen Abarbeitung entsteht.
Es ist wünschenswert, eine Abarbeitung von Anweisungen in nebenläufigen Tasks in einer Steuereinrichtung, insbesondere in einer speicherprogrammierbaren Steuerung, anzugeben, bei der unter Verwendung bekannter Programmiersprachen, insbesondere Structured Text, eine nicht blockierende Ausführung insbesondere freilaufender Tasks in Form eines Multitaskings ermöglicht wird. Offenbarung der Erfindung
Erfindungsgemäß wird ein Verfahren zum Ermöglichen einer sequentiellen, nicht blockierenden Abarbeitung von Anweisungen in nebenläufigen Tasks in einer Steuereinrichtung mit einem multitaskingfähigen Betriebssystem, insbesondere einer speicherprogrammierbaren Steuerung, sowie eine Steuereinrichtung und ein Computerprogramm mit den Merkmalen der unabhängigen Patentansprüche vorgeschlagen. Bevorzugte Ausgestaltungen sind in den jeweiligen abhängigen Ansprüchen angegeben. Vorteile der Erfindung
Durch die vorliegende Erfindung kann beispielsweise eine sequentielle Programmierung im Wesentlichen innerhalb der Vorgaben der Norm EN/IEC 6113-3 mittels der Programmiersprache "Structured Text" und unter Verwendung eines kooperativen Multitaskingmodells realisiert werden. Diese Programmierung kann zur Abarbeitung sogenannter freilaufender Tasks verwendet werden. Insbesondere kann die Abarbeitung von Anweisungen einer Ablaufsteuerung verbessert werden. Durch die Erfindung ist eine Ablaufsteuerung wesentlich kompakter zu programmieren. Die vom Programmierer zu erzeugende Programmcodemenge wird erheblich verringert. Die Prozessorzeit wird besser auf die einzelnen Tasks verteilt.
Eine herkömmliche sequentielle Abarbeitung von Anweisungen in freilaufenden Tasks in einer SPS erfolgt blockierend. Bei der sequentiellen Abarbeitung, welche einer Maschinensequenz bzw. einem Maschinenablauf entspricht, wird an den Stellen bzw. zu Programmschritten, an denen Aktionen (z.B. Bewegungs- oder Verfahrbefehle) eingeleitet werden, gewartet, bis die Ausführung der Aktion quittiert wird. An diesen Stellen entstehen Blockaden sowohl der jeweiligen Task als auch aller anderen nebenläufigen Tasks. Diese Blockade der anderen nebenläufigen Tasks kann durch die erfindungsgemäße Lösung vermieden werden. Die Grundlage für die Realisierung der vorliegenden Erfindung kann beispielsweise eine speicherprogrammierbare Steuerung herkömmlicher Bauart sein, die ein Betriebssystem aufweist, welches multitaskingfähig ist, d.h. das über Betriebssystemaufrufe verfügt, die das Betriebssystem dazu veranlassen, die jeweilige, momentan abgearbeitete Task zugunsten einer anderen zu unterbrechen, falls die Task oder eine übergeordnete Einheit (Watchdog) dies signalisiert. Ein derartiges Umschalten von Tasks (Task switching) kann beispielsweise dann erfolgen, wenn in einer Task ein Wartezustand entsteht (Warten auf ein Ereignis) und beispielsweise deshalb eine Betriebssystemfunktion wait() aufgerufen wird. Im Rahmen der vorliegenden Erfindung sollen beispielsweise freilaufende Tasks verwendet werden, die geeignet sind, die Restrechenzeit einer speicherprogrammierbaren Steuerung bzw. eines Prozessors in einer solchen Steuerung optimal auszulasten. Die Umschaltlogik, wie sie im Rahmen dieser Anmeldung beispielhaft vorgestellt wird, entspricht dabei vorteilhafterweise dem an sich bekannten "kooperativen Multitasking". Das kooperative Multitasking bezeichnet einen Multitaskingvorgang, bei dem jeder Prozess "freiwillig" die Kontrolle an den Betriebssystemkern zurückgibt, wenn dieser Prozess keine Rechenzeit mehr benötigt. Es ist also jedem Prozess selbst überlassen, wann er die Kontrolle an den Kern zurückgibt.
Kooperatives Multitasking kann einfach realisiert werden, wenn die jeweiligen Prozesse zuverlässig die Kontrolle an den Kern zurückgeben. Sobald ein einzelner Prozess bzw. eine Task jedoch seine Kooperation abbricht (beispielsweise aufgrund einer Fehlfunktion), die Kontrolle also nicht an das Betriebssystem zurückgibt, kann dies einen Stillstand aller beteiligten, freilaufenden Tasks zur Folge haben. Gemäß einer bevorzugten Ausgestaltung wird daher vorgeschlagen, eine Watchdogfunktion vorzusehen, um eine zwangsweise Unterbrechung einer Task zugunsten einer anderen zu ermöglichen. Im Rahmen der vorliegenden Erfindung kann eine Umschaltung zwischen Tasks vorteilhafterweise immer an Positionen bzw. zu Programmschritten erfolgen, an dem ein jeweiliger Prozess bzw. Task auf ein Ereignis, d.h. beispielsweise die Ausführung einer Aufgabe und/oder eines Befehls wartet. Durch diese Maßnahme ergibt sich vorteilhafterweise eine optimale Vergabe der Prozessorzeit. Für die Umsetzung der erfindungsgemäßen Maßnah- men werden vorteilhafterweise Standardbefehle (Standard-Motion-Befehle) in einer jeweils neuen Funktion gekapselt, wobei innerhalb der gekapselten Funktion ein oder mehrere Betriebssystemaufrufe zugeordnet bereitgestellt werden. An den Wartestellen wird dann die Bibliotheksfunktion (Betriebsystemfunktion) zum Freigeben der Prozessorzeit aufgerufen. Eine derartige Funktion zur Freigabe der Prozessorzeit, wie etwa waitTimeQ, steht beispielsweise auch für Kontrollstrukturen wie WHILE-Schleifen zur Verfügung, um dem Anwender bzw. Programmierer, insbesondere bei Programmierung einer Endlosschleife ohne Abbruchbedingungen, ein Freigeben der Prozessorzeit zu ermöglichen. Eine erfindungsgemäß ebenfalls vorgesehene Steuereinrichtung, insbesondere eine speicherprogrammierbare Steuerung, weist sämtliche Mittel zur Durchführung eines erfindungsgemäßen Verfahrens wie zuvor erläutert auf. Das erfindungsgemäß vorgesehene Computerprogramm umfasst Programmcodemittel, insbesondere wenigstens eine Anweisungen und Betriebssystemaufrufe einkapselnde Struktur, die anhand eines erfindungsgemäßen Verfahrens bereitgestellt sind. Geeignete Datenträger für ein solches Computerprogramm sind insbesondere Disketten, Festplatten, Flash- Speicher, EEPROM, CD-ROM, DVDs usw. Auch ein Download eines derartigen Programms über ein Computernetz (Internet, Intranet, Systemnetz usw.) ist möglich.
Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und der beiliegenden Zeichnung. Es versteht sich, dass die vorstehend genannten und die nachfolgend noch zu erläuternden Merkmale nicht nur in der jeweils angegebenen Kombination, sondern auch in anderen Kombinationen oder in Alleinstellung verwendbar sind, ohne den Rahmen der vorliegenden Erfindung zu verlassen. Die Erfindung ist anhand von Ausführungsbeispielen in der Zeichnung schematisch dargestellt und wird im Folgenden unter Bezugnahme auf die Zeichnung ausführlich beschrieben.
Figurenbeschreibung Figur 1 zeigt eine periodische und eine zyklische Abarbeitung von Anweisungen in einer speicherprogrammierbaren Steuerung gemäß dem Stand der Technik in schematischer Darstellung.
Figur 2 zeigt eine Abarbeitung einer freilaufenden Task in einer Bewegungssteuerung gemäß dem Stand der Technik in schematischer Darstellung.
Figur 3 zeigt eine sequentielle, nicht blockierende Abarbeitung von Anweisungen in nebenläufigen Tasks in Steuereinrichtung gemäß einer besonders bevorzugten Ausführungsform der Erfindung in schematischer Darstellung. Figur 4 zeigt eine sequentielle, nicht blockierende Abarbeitung von Anweisungen in nebenläufigen Tasks in Steuereinrichtung gemäß einer weiteren besonders bevorzugten Ausführungsform der Erfindung in schematischer Darstellung.
In Figur 1 ist die übliche, aus dem Stand der Technik bekannte Abarbeitung von Anweisungen in speicherprogrammierbaren Steuerungen dargestellt. In Schema 100 ist dabei eine periodische, im Schema 110 eine zyklische Abarbeitung von Anweisungen bzw. Befehlen abgebildet, wobei im Fall der periodischen Abarbeitung 100 eine Zykluszeit t als synchron angegeben ist. In der zyklischen Abarbeitung 110 variiert die Zykluszeit t1 f t2, t3 hingegen entsprechend der Dauer der jeweiligen Verarbeitung eines Befehls V. Wie allgemein bekannt und zuvor erläutert, liest eine speicherprogrammierte Steuerung zu Beginn eines jeden Zyklus ein Eingangsabbild E und schreibt am Ende eines Zyklus, mit A bezeichnet, ein Ausgangsabbild. Zwischen dem Lesen des Eingangsabbilds und dem Schreiben des Aus- gangsabbilds erfolgt die Verarbeitung eines Benutzerprogramms bzw. die Ausführung von Befehlen V.
Aus Sichtweise eines klassischen Programmierers einer speicherprogrammierbaren Steuerung wird das Programm mittels einer Schrittkette organisiert. Hierdurch werden die einzel- nen Befehle in eine bestimmte Ausführungsreihenfolge gebracht, da sie sich anderenfalls überlagern würden. Hierdurch erfolgt ein sequentieller, nicht blockierender Befehlsablauf, wobei das Eingangs- und das Ausgangsabbild zyklisch aktualisiert werden.
In Figur 2 ist, entsprechend zur Darstellung der Figur 1 , eine Abarbeitung von Anweisungen 200 dargestellt, wie sie herkömmlicherweise in einer Bewegungssteuerungseinrichtung (Motion-Steuerung) realisiert ist. Die Abarbeitung erfolgt in Form eines freilaufenden Tasks V, der zyklusunabhängig abgearbeitet und nach dem Abarbeiten erneut angestoßen wird.
Während der Bearbeitung V wird in Form einer periodischen, nebenläufigen Task ständig bzw. in Form einer Intervallsteuerung, eine Aktualisierung des Eingangs- und Ausgangsabbilds über eine nebenläufige Task ausgeführt. Der Befehlsablauf in einer Bewegungssteuerungseinrichtung ist in der Regel sequentiell blockierend. Es sei zu verstehen gegeben, dass die erfindungsgemäßen Maßnahmen unter anderem beinhalten, eine sequentiell blockierende Abarbeitung von Anweisungen, wie sie prinzipiell aus einer Bewegungssteuerung be- kannt ist, auf eine speicherprogrammierbare Steuerung zu übertragen. In speicherprogrammierbaren Steuerungen ist auf Grund der eingeschränkten Möglichkeiten üblicher dort vorhandener Programmiersprachen eine derartige sequentiell blockierende Abarbeitung von Befehlen nicht möglich.
Wie im Folgenden dargestellt, stellt die vorliegende Erfindung in diesem Zusammenhang mit besonderen Vorteil eine Kapselstruktur zur Verfügung, in die ein auszuführender Befehl eingekapselt wird und die neben dem auszuführenden Befehl ein oder mehrere Betriebssystemaufrufe aufweist, die einerseits zum Lesen eines Ausgangsabbilds und zum Schreiben eines Eingangsabbildes verwendet werden, und andererseits ein Umschalten zwischen nebenläufigen Tasks bewirken können.
Figur 3 zeigt eine Abarbeitung nebenläufiger Tasks, die gemäß einer besonders bevorzugten Ausführungsform in sequentiell blockierender Weise erfolgt. Mit 1 ist die Zyklusabfolge in einer speicherprogrammierbaren Steuerung angegeben, mit 2 ist die eigentliche Abarbeitung der jeweiligen Tasks angegeben. T1 bezeichnet eine erste Task, T2 eine zweite Task und T3 eine dritte Task, wobei die Tasks T1 , T2 und T3 nebenläufig (parallel) abgearbeitet werden und sich aufgrund der Multitaskingfähigkeit des Betriebssystem der Eindruck einer gleichzeitigen Bearbeitung ergibt. Mit 320 sind jeweils Programmkapselfunktionen bezeich- net, die, wie zuvor erläutert, gemäß einer besonders bevorzugten Ausführungsform der Erfindung neben dem eigentlichen ausführenden Befehl Betriebssystemaufrufe aufweisen.
Ein Umschalten zwischen den jeweiligen Tasks T1 , T2 und T3 erfolgt jeweils zu Zeitpunkten bzw. Übergabepunkten 310. Die Übergabe 310 einer Kontrolle von einem Task an einen anderen Task erfolgt durch das Betriebssystem und auf Grundlage eines Betriebssystemsaufrufs, beispielsweise einer Funktion wait().
Wie erwähnt, werden die erfindungsgemäßen Maßnahmen vorteilhafterweise in Form einer Kapselfunktion 320 bzw. Kapselstruktur 320 realisiert, die im Folgenden näher erläutert wird. Die Kapselstruktur stellt einen einkapselnden Befehl dar, der den eigentlichen auszuführenden Befehl aufweist bzw. beinhaltet. Der Programmierer verwendet diesen gekapselten Befehl (z.B. "sMoveAbsolutQ") anstelle des ursprünglichen Befehls (z.B. "MoveAbsolutQ"). Somit braucht der Programmierer die Betriebssystemaufrufeselbst nicht in sein Programm aufzunehmen, was eine Realisierung auch ohne Kenntnis der Programminterna erleichtert. Die Task T1 beginnt üblicherweise mit dem Lesen eines Eingangsabbilds. Anschließend werden die Befehle der Tasks T1 durchlaufen, bis dabei auf einen gekapselten Befehl gestoßen wird. Dieser wird durch Block 320 dargestellt. Bei Schritt 301 beginnt der Ablauf des herkömmlicherweise blockierenden Befehls. Bei Schritt 302 wird eine Anweisung an eine Bewegungssteuerung (beispielsweise an einen Motion Handler) ausgegeben. Dies erfolgt zweckmäßigerweise in Form eines Aufrufs einer Bewegungsfunktion an einen Interpolator.
In Schritt 303 erfolgt ein erster Betriebssystemaufruf, mit * bezeichnet, in diesem Fall das Schreiben eines Ausgangsabbilds. Nachdem also in Schritt 302 ein Befehl an einen Motion Handler übergeben wurde, wartet das System auf die Ausführung des Befehls. Wie im Rahmen der Figur 3 dargestellt, beinhaltet eine Kapselstruktur 320 eine Prüffunktion, bestehend aus einem Abfragebefehl 305 und einem Warteschritt 306, wobei im Schritt 305 abgefragt wird, ob der übergebende Befehl vollständig ausgeführt worden ist. Ist dies der Fall, wird die Abarbeitung der Befehle, wie unten dargestellt, fortgesetzt. Ist dies jedoch noch nicht der Fall, setzt sich die Abarbeitung des Programms mit Schritt 306 fort, in dem ein weiterer Zyklus t abgewartet wird. Gleichzeitig erfolgt ein Betriebssystemaufruf, der ein Betriebssystem dazu veranlasst, die jeweilige Task zugunsten einer anderen zu unterbrechen, d.h. die Rechenzeit einer anderen Task zuzuteilen. Diese Übergabe ist mit Pfeil 310 symbo- lisiert. Über Ablauf 307 kehrt das Programm zur Abfrage 305 zurück. Die Prüfung beinhaltet also einen Zyklus, der so lange abläuft, wie eine Abarbeitung des in Schritt 302 übergebe- nen Befehls noch nicht erfolgt ist.
Nach Rückerhalt der Rechenzeit und Abarbeiten des Befehls 302 wird das Programm mit Schritt 308 fortgesetzt, wobei, ebenfalls in Form eines Betriebssystemaufrufs, ein Eingangsabbild gelesen wird und der gekapselte Befehl mit Schritt 309 zum Ende gelangt. Anschließend werden die Befehle der aktuellen Task weiter abgearbeitet, bis bspw. zu einem weiteren gekapselten Befehl gelangt wird.
Es sei zu verstehen gegeben, dass im Fall einer Blockade in der Abarbeitung des Blocks 320, beispielsweise bei einer nicht erfolgreichen Übergabe eines Befehls in Schritt 302, die zur Folge hat, dass das Programm blockiert würde und niemals zu Schritt 306 gelangen kann, ebenfalls eine Schleifenabfrage mit einer Betriebssystemfunktion entsprechend 310 vorgesehen sein kann derart, dass zu einem nächsten Task gesprungen wird, solange der Befehl 302 noch nicht übergeben wurde. Alternativ kann eine zwangsweise Übergabe 310 der Kontrolle an einen anderen Prozess auch unter Verwendung eines Watchdogs erfolgen.
In Figur 3 ist also eine Struktur dargestellt, bei der in Form einer Abfragefunktion festgestellt wird, ob ein abgegebener Befehl 302 vollständig ausgeführt wurde.
Eine alternative Ausführungsform hierzu ist in Figur 4 dargestellt und insgesamt mit 400 bezeichnet. Anstelle der Prüffunktion der Figur 3 wird hier eine Semaphorfunktion 416 eingesetzt. Ähnlich wie in Figur 3 wird auch hier eine Kapselfunktion 420 verwendet. Innerhalb der Kapsel beginnt der Befehl mit Schritt 401. In Schritt 402 wird, analog zum Schritt 302 der Figur 3, ein Befehl an einen Motion Handler übergeben. In Schritt 410 erfolgt ein Betriebssystemaufruf, der die Kontrolle an einen anderen Prozess abgibt. Gleichzeitig wird jedoch auch eine Semaphorfunktion 416 angestoßen, die den auszuführenden Task suspendiert und damit in eine passive Wartefunktion bzw. Wartesituation versetzt. Bis zu dem Zeitpunkt, zu dem mittels der Semaphorfunktion signalisiert wird, dass der in Schritt 402 angestoßene Befehl abgearbeitet wurde, verbleibt der Befehl im suspendierten Zustand und wird erst nach dem Semaphorbefehl erneut aktiviert bzw. reaktiviert R. Der Befehl gelangt dann bei Schritt 409 zum Ende. Im linken Teil der Figur 4 ist mit 2 eine Abarbeitung von Tasks, analog zur Figur 1 dargestellt. Durch die Suspendierung S des Tasks T1 wird dieser jedoch in den Zyk- len t2 und t3 nicht ausgeführt, sondern erst wieder im Zyklus t4 nach Reaktivierung R abgearbeitet.

Claims

Ansprüche
1. Verfahren zum Ermöglichen einer sequentiellen, nicht blockierenden Abarbeitung von Anweisungen (302, 402) in nebenläufigen Tasks (T1 , T2, T3) in einer Steuereinrichtung mit einem multitaskingfähigen Betriebssystem, insbesondere einer speicherprogrammierbareri Steuerung, wobei wenigstens einer Anweisung (302, 402) wenigstens ein Betriebssystemaufruf (310, 410) zugeordnet wird, der das Betriebssystem dazu veranlasst, die jeweilige Task (T1 , T2, T3) nach einer durch die Anweisung (302, 402) ausgegebenen Instruktion zugunsten einer anderen Task (T1 , T2, T3) zu unterbrechen.
2. Verfahren nach Anspruch 1 , das bei einer Speicherprogrammierbaren Steuerung oder einer Bewegungssteuerung verwendet wird.
3. Verfahren nach Anspruch 1 oder 2, wobei die unterbrochene Task (T1 ) während ei- ner Abarbeitungszeit der Instruktion suspendiert (S) und nach dem Ende der Abarbeitungszeit reaktiviert (R) wird.
4. Verfahren nach Anspruch 3, wobei die Suspendierung (S) und/oder Reaktivierung (R) unter Verwendung eines Semaphors und/oder einer Prüffunktion (305) erfolgt.
5. Verfahren nach einem der vorstehenden Ansprüche, welches für eine Programmiersprache gemäß IEC/EN 61131-3, insbesondere für Structured Text, realisiert wird.
6. Verfahren nach einem der vorstehenden Ansprüche, bei dem der wenigstens einen Anweisung (302, 402) weitere Betriebssystemaufrufe (A, E) zugeordnet werden, die das
Betriebssystem dazu veranlassen, ein Ausgangsabbild zu schreiben (A) und/oder ein Eingangsabbild zu lesen (E).
7. Verfahren nach einem der vorstehenden Ansprüche, wobei die Zuordnung von Be- triebssystemaufrufen (310, 410, A, E) zu der wenigstens einen Anweisung (302, 402) in
Form einer Anweisungen (302, 402) und Betriebssystemaufrufe einkapselnden Struktur (320, 420) erfolgt.
8. Verfahren nach Anspruch 7, bei dem die einkapselnde Struktur (320, 420) ferner eine Prüf- (305) und/oder eine Semaphorfunktion (416) beinhaltet.
9. Verfahren nach einem der vorstehenden Ansprüche, das für freilaufende Tasks (T1 , 12, 13) als sequentiell abzuarbeitende Tasks (T1 , 12, 13) verwendet wird. 0. Verfahren nach einem der vorstehenden Ansprüche, bei dem eine Watchdogfunktion verwendet wird, um eine zwangsweise Unterbrechung einer Task zugunsten einer anderen zu ermöglichen.
11. Computerprogramm mit Programmcodemitteln, insbesondere wenigstens eine Anweisungen und Betriebssystemaufrufe einkapselnde Struktur (320, 420), die gemäß einem Verfahren nach einem der vorstehenden Ansprüche bereitgestellt ist, zur Ausführung auf einem Computer oder einer entsprechenden Recheneinheit, insbesondere einer Steuerein- richtung.
12. Steuereinrichtung, insbesondere Speicherprogrammierbare Steuerung, die zur Ausführung eines Computerprogramms nach Anspruch 11 eingerichtet ist.
PCT/EP2010/005527 2009-11-25 2010-09-08 Verfahren zum ermöglichen einer sequentiellen, nicht blockierenden abarbeitung von anweisungen in nebenläufigen tasks in einer steuereinrichtung Ceased WO2011063869A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US13/511,979 US9152454B2 (en) 2009-11-25 2010-09-08 Method for enabling sequential, non-blocking processing of statements in concurrent tasks in a control device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102009055752A DE102009055752A1 (de) 2009-11-25 2009-11-25 Verfahren zum Ermöglichen einer sequentiellen, nicht blockierenden Abarbeitung von Anweisungen in nebenläufigen Tasks in einer Steuereinrichtung
DE102009055752.0 2009-11-25

Publications (1)

Publication Number Publication Date
WO2011063869A1 true WO2011063869A1 (de) 2011-06-03

Family

ID=43027892

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2010/005527 Ceased WO2011063869A1 (de) 2009-11-25 2010-09-08 Verfahren zum ermöglichen einer sequentiellen, nicht blockierenden abarbeitung von anweisungen in nebenläufigen tasks in einer steuereinrichtung

Country Status (3)

Country Link
US (1) US9152454B2 (de)
DE (1) DE102009055752A1 (de)
WO (1) WO2011063869A1 (de)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9305082B2 (en) * 2011-09-30 2016-04-05 Thomson Reuters Global Resources Systems, methods, and interfaces for analyzing conceptually-related portions of text
US9710315B2 (en) * 2014-09-12 2017-07-18 Qualcomm Incorporated Notification of blocking tasks
KR102079499B1 (ko) * 2015-10-20 2020-02-21 엘에스산전 주식회사 Plc 위치 결정 시스템의 축별 제어주기 독립 할당 방법
DE102016107527A1 (de) 2016-04-22 2017-10-26 Beckhoff Automation Gmbh Echtzeitumgebung und speicherprogrammierbare Steuerung
JP6776987B2 (ja) * 2017-04-06 2020-10-28 株式会社島津製作所 タスク実行制御装置及び該装置用プログラム
US11513491B2 (en) 2017-05-29 2022-11-29 Tetra Laval Holdings & Finance S.A. Process control for production of liquid food
DE102017222761A1 (de) 2017-12-14 2019-06-19 Robert Bosch Gmbh Hydraulische Versorgungseinrichtung
DE102018133058A1 (de) 2018-12-20 2020-06-25 Beckhoff Automation Gmbh Verfahren zum steuern eines automatisierungsprozesses in echtzeit

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4302820A (en) * 1979-08-20 1981-11-24 Allen-Bradley Company Dual language programmable controller
US6009454A (en) * 1994-09-30 1999-12-28 Allen-Bradley Company, Llc Multi-tasking operation system for industrial controller
US20060212874A1 (en) * 2003-12-12 2006-09-21 Johnson Erik J Inserting instructions

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7334229B1 (en) * 1999-01-28 2008-02-19 Cisco Technology, Inc. Mutual exclusion at the record level with priority inheritance for embedded systems using one semaphore
EP1247195A4 (de) * 1999-12-22 2005-01-05 Ubicom Inc System und verfahren zur auf befehlsebene arbeitenden multithreading in einem eingebetteten prozessor mit nullzeitkontextumschaltung
US7234139B1 (en) * 2000-11-24 2007-06-19 Catharon Productions, Inc. Computer multi-tasking via virtual threading using an interpreter
US7089557B2 (en) * 2001-04-10 2006-08-08 Rusty Shawn Lee Data processing system and method for high-efficiency multitasking
WO2003104914A2 (en) * 2002-06-05 2003-12-18 Axs Technologies Apparatus and method for sharing digital content of an image across a communication network
TW201009713A (en) * 2008-08-21 2010-03-01 Ind Tech Res Inst Multitasking processor and task switch method thereof
JP2010160600A (ja) * 2009-01-07 2010-07-22 Yamatake Corp 情報処理装置、スケジューラ、及びスケジューリング方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4302820A (en) * 1979-08-20 1981-11-24 Allen-Bradley Company Dual language programmable controller
US6009454A (en) * 1994-09-30 1999-12-28 Allen-Bradley Company, Llc Multi-tasking operation system for industrial controller
US20060212874A1 (en) * 2003-12-12 2006-09-21 Johnson Erik J Inserting instructions

Also Published As

Publication number Publication date
US9152454B2 (en) 2015-10-06
DE102009055752A1 (de) 2011-05-26
US20130081054A1 (en) 2013-03-28

Similar Documents

Publication Publication Date Title
WO2011063869A1 (de) Verfahren zum ermöglichen einer sequentiellen, nicht blockierenden abarbeitung von anweisungen in nebenläufigen tasks in einer steuereinrichtung
EP2325708B1 (de) Echtzeit-Laufzeitsystem und Funktionsmodul für ein solches Laufzeitsystem
EP2506098B1 (de) Anordnung und Verfahren für den Betrieb einer industriellen Automatisierungsanordnung mit einer Mehrzahl programmierbarer Automatisierungskomponenten und einer Mehrzahl Automatisierungsprogramme
EP3538960B1 (de) Ablaufsteuerung von programmmodulen
EP3542232B1 (de) Steuerung für eine industrielle automatisierungsanlage und verfahren zum programmieren und betreiben einer derartigen steuerung
EP3417373B1 (de) Verfahren und vorrichtung zum betreiben eines steuergeräts
EP2504738A1 (de) Parallelisierte programmsteuerung
DE102014103139B4 (de) Parallelisierte Ausführung von Single-Core Steuerungssoftware auf Multi-Core Fahrzeugsteuergeräten
EP1238318B1 (de) Automatisierungsgerät und aufdat-verfahren
DE102009025572A1 (de) Eine Methode zur Entwicklung von garantiert korrekten Echtzeitsystemen
EP2732347B1 (de) Verfahren und system zur dynamischen verteilung von programmfunktionen in verteilten steuerungssystemen
EP1221641B1 (de) Industrielle Steuerung mit taktsynchronem Ablaufebenenmodell
EP2187281B1 (de) Automatisierungsgerät und Verfahren zu dessen Betrieb
DE102017130552B3 (de) Verfahren zur Datenverarbeitung und speicherprogrammierbare Steuerung
EP2561415B1 (de) Datenverwaltungsverfahren und speicherprogrammierbare steuerung
EP2574997A1 (de) Verfahren zur Einstellung eines Betriebszustandes
EP3977301A1 (de) Laufzeitserver zum gleichzeitigen ausführen mehrerer laufzeitsysteme einer automatisierungsanlage
EP1221639B1 (de) Programmierung von zyklischen Maschinen
EP1220065B1 (de) Verfahren zum Betrieb einer industriellen Steuerung mit Run-Time-System
EP2365438A1 (de) Verfahren zum Betrieb eines Automatisierungssystems
DE102016121542A1 (de) Ablaufsteuerung von Programmmodulen
DE102005039771B3 (de) Einheit zur Verwaltung von Echtzeitprozessen ohne asynchrone Unterbrechungen
WO2008148838A1 (de) Prozessor und verfahren zu seiner ansteuerung
DE102010001962A1 (de) Verfahren zum Betreiben eines Steuergeräts
DE4209541A1 (de) Verfahren zum Betreiben von Mikroprozessoren und Mikrocontrollern für Steuerungen und Regelungen

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10752323

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 94322010

Country of ref document: AT

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 13511979

Country of ref document: US

122 Ep: pct application non-entry in european phase

Ref document number: 10752323

Country of ref document: EP

Kind code of ref document: A1