Die Erfindung betrifft ein Verfahren zum Programmieren und Betreiben einer Steuerung einer industriellen Automatisierungsanlage, bei dem ein Programm für die Steuerung mit einem Entwicklungswerkzeug erstellt wird.

Die Erfindung betrifft weiterhin eine zur Durchführung des Verfahrens geeignete Steuerung.

Industrielle Automatisierungsanlagen dienen der Ablaufsteuerung und Überwachung von automatisierten Industrieanlagen. Sie weisen üblicherweise eine industrielle Automatisierungssteuerung auf, die auch als speicherprogrammierbare Steuerung (SPS) bezeichnet wird und die nachfolgend abgekürzt Steuerung genannt wird. Die Steuerung ist über einen Feldbus unmittelbar oder über einen Feldbuskoppler, auch Feldbus-Gateway genannt, mit Feldgeräten gekoppelt. Feldgeräte sind beispielsweise Ein- und/oder Ausgabemodule, abgekürzt auch als E/A-Module bezeichnet, die analoge und/oder digitale Ein- und/oder Ausgabekanäle bereitstellen, über die Anlagenkomponenten gesteuert werden können und Messwerte, beispielsweise von Sensoren, eingelesen werden können.

Zur Programmierung der Steuerung wird üblicherweise eine externe Entwicklungsumgebung (engineering tool) eingesetzt. Gemäß der Norm IEC 61 131 kann das zugrunde liegende Programm in verschiedenen Formen eingegeben werden. Eine häufig verwendete Form ist eine Darstellung mittels Funktionsbausteinen, die Logikbausteinen ähneln. Diese Funktionsbausteine können in einer grafischen Bedienoberfläche positioniert und miteinander verknüpft werden. Alternativ sind auch textbasierte Programmierungen möglich.

Das vom Anwender erstellte Programm wird in der Entwicklungsumgebung durch einen Übersetzer in einen ausführbaren Programmcode gewandelt, der auf die Steuerung übertragen und dort ausgeführt wird. Zudem stellt die Entwicklungsumgebung üblicherweise einen Mechanismus zur Versionskontrolle bereit, d.h., dass ältere Programmversionen in einer Datenbank, auch„reposi- tory" genannt, abgelegt werden, so dass gegebenenfalls auf sie zugegriffen werden kann. Eine derartige Entwicklungsumgebung ist insofern nachteilig, als dass zur Programmierung der Steuerung ein mit dieser Entwicklungsumgebung ausgestatteter Rechner, z.B. ein PC, vorhanden sein muss, der mit der Steuerung gekoppelt ist. Greifen mehrere Entwickler von unterschiedlichen PCs mit einer derartigen Entwicklungsumgebung auf die Steuerung zu, ist zudem eine konsistente Versionshistorie nicht gewährleistet.

Der Erfindung liegt die Aufgabe zugrunde, ein Verfahren zu beschreiben, mit dem eine Programmierung einer Steuerung unabhängig von externen Rech- nern, die mit einer Entwicklungsumgebung ausgestattet sind, erfolgen kann. Es ist eine weitere Aufgabe, eine zur Durchführung des Verfahrens geeignete Steuerung anzugeben.

Diese Aufgabe wird durch ein Verfahren bzw. eine industrielle Automatisie- rungssteuerung mit den Merkmalen des jeweiligen unabhängigen Anspruchs gelöst. Vorteilhafte Ausgestaltungen und Weiterbildungen sind in den abhängigen Ansprüchen angegeben.

Ein erfindungsgemäßes Verfahren zeichnet sich dadurch aus, dass die Steue- rung mithilfe eines integrierten Webservers eine webbasierte Entwicklungsumgebung an einem über ein Netzwerk mit der Steuerung verbundenen Rechner überträgt. Ein vom Benutzer erstelltes und/oder bearbeitetes Programm wird mittels eines in der ausgelieferten Webseite enthaltenen Übersetzungsmoduls in ein Hochsprachenprogramm übersetzt, das über das Netzwerk an die Steue- rung übertragen wird. In der Steuerung wird das empfangene Hochsprachenprogramm in ein zur Ausführung auf der Steuerung geeignetes Binärprogramm übersetzt und dieses durch die Steuerung ausgeführt.

Dadurch, dass die Entwicklungsumgebung von dem Webserver, der in der Steuerung enthalten ist, an einen angeschlossenen Rechner übertragen wird, ist es nicht erforderlich, Rechner mit spezieller Entwicklungsumgebung zur Programmierung einzusetzen. Stattdessen kann jeder Rechner (PC, Tablet usw.), der über einen Webbrowser verfügt, zur Programmierung eingesetzt werden. Diese Universalität wird zusätzlich dadurch unterstützt, dass im

Webbrowser nicht ein unmittelbar von der Steuerung ausführbares Binärprogramm erstellt wird, sondern ein Hochsprachenprogramm, beispielsweise in C oder C++, das in dem Sinne universell ist, als dass es keine hardwarespezifischen Elemente der Steuerung enthält. Derartige hardwarespezifische Elemen- te können in einem nachfolgenden Übersetzungsprozess des Hochsprachenprogramms in die ausführbare Sprache hinzugefügt werden.

In einer bevorzugten Ausgestaltung des Verfahrens wird das Programm in einer grafischen Programmiersprache erstellt bzw. überarbeitet. Die grafische Programmiersprache kann beispielsweise Funktionsblöcke enthalten, mit der eine Programmierung der Steuerung auf intuitive Weise erfolgen kann. Alternativ können andere geeignete Programmiersprachen zur Erstellung des Programms genutzt werden.

In einer vorteilhaften Weiterbildung wird neben dem Hochsprachenprogramm auch das vom Benutzer erstellte oder überarbeitete Programm selbst von dem Rechner oder Webbrowser an die Steuerung übertragen. Bevorzugt ist dann vorgesehen, innerhalb der Steuerung das Programm und/oder das Hochsprachen- programm und/oder das Binärprogramm gemeinsam in einem Versionsspeicher abzulegen. Zumindest das Programm und das daraus erstellte Binärprogramm sollten dabei einander zugeordnet abgelegt werden. Durch den Versionsspeicher, der beispielsweise in Form einer Datenbank ausgebildet sein kann, ist nicht nur die aktuell ausgeführte Programmversion verfügbar, sondern auch zurückliegen- de Entwicklungsstände abspeicherbar. Jeder auf dem Webserver der Steuerung zugreifende Rechner kann somit auf das aktuell ausgeführte Programm und auch bei Bedarf auf zurückliegende Programmversionen zurückgreifen.

Die jederzeit nachvollziehbare Zuordnung von Binärprogramm und Programm verhindert eine ungewollte Aufsplittung eines Programms in verschiedene Entwicklungszweige dadurch, dass beispielsweise ungewollt ältere Entwicklungsstände des Programms weiter gebildet werden, obwohl bereits neuere Entwicklungsstände existieren. Unabhängig von dem zugreifenden Rechner steht bei der genannten Weiterbildung die vollständige Versionsgeschichte jedem Webbrowser zur Verfügung.

In einer weiteren vorteilhaften Weiterbildung des Verfahrens ist vorgesehen, in einer Anordnung mit mindestens zwei Steuerungen von einem Rechner bzw. einem Webbrowser aus Programme für beide Steuerungen in einem übergeordneten Projekt zu bearbeiten. Auf diese Weise kann flexibel mit sogenannten verteilten Projekten gearbeitet werden, bei denen einzelne Steuerungen unterschiedliche Teilprojekte in einem gemeinsamen, übergeordneten Projekt wahrnehmen. Dadurch, dass Entwicklungsstände im genannten Versionsspeicher einer jeden Steuerungen abgespeichert werden, ist auch bei einem derartigen verteilten Arbeiten jederzeit eine Datenkonsistenz für die Programme gegeben. Dieses gilt sogar für eine flexible Mischnutzung, bei der Teilprojekte an einzelnen Steuerun- gen separat und ggf. im Rahmen eines übergeordneten Projekts geändert werden.

Um das übergeordnete Projekt auch bearbeiten zu können, wenn eine der Steuerungen für den Webbrowser des übergeordneten Bearbeiters nicht erreichbar ist, kann vorgesehen sein, im Rechner des übergeordneten Bearbeiters eine Spiegelung des Versionsspeichers der Einzelsteuerung abzulegen. Nach Wiederverbindung mit der Steuerung werden die Versionsspeicher der Steuerung und des Rechners und des übergeordneten Bearbeiters bevorzugt automatisiert synchronisiert.

In einer bevorzugten Ausgestaltung des Verfahrens wird eine Datenbank genutzt, um die Versionsgeschichte der Programme abzuspeichern. Bevorzugt wird ein Datenbanktyp verwendet, für den geeignete Techniken zur Spiegelung und Konsistenzhaltung verfügbar sind, auf die zurückgegriffen werden kann. Eine erfindungsgemäße Steuerung weist einen Webserver auf, der dazu eingerichtet ist, eine Entwicklungsumgebung an einen angeschlossenen Rechner auszuliefern. Es ergeben sich die im Zusammenhang mit dem Verfahren genannten Vorteile. In einer vorteilhaften Weiterbildung der Steuerung weist diese ein Echtzeitsystem zum Ausführen eines Binärprogramms zum Durchführen von Steuerungsaufgaben und ein Nicht-Echtzeitsystem zur Bereitstellung des Webservers auf. Das technisch aufwändigere zu realisierende Echtzeitsystem ist so den Steuerungsaufgaben vorbehalten, wobei weitere Aufgaben der Steuerung, z. B. im Zusammenhang mit der Bereitstellung des Webservers, im weniger aufwändigen Nicht-Echtzeitsystem ausgeführt werden können.

Eine wirksame und sichere Trennung zwischen dem Echtzeitsystem und dem Nicht-Echtzeitsystem kann in einer Ausgestaltung der Steuerung dadurch erfol- gen, dass dem Echtzeitsystem und dem Nicht-Echtzeitsystem unterschiedliche Prozessoren zugeordnet sind. Eine im Hinblick auf die Kosten demgegenüber vorteilhafte Alternative besteht darin, einen Prozessor für die Steuerung vorzusehen, der mindestens zwei Kerne aufweist, wobei mindestens ein Kern dem Echtzeitsystem und mindestens ein Kern dem Nicht-Echtzeitsystem zugeordnet ist. Jeder Kern wiederum kann exklusiv über zumindest einen ersten und ggf. auch einen zweiten (schnellen) Zwischenspeicher, auch Level 1 bzw. Level 2 Cache genannt, verfügen. In einer weiteren vorteilhaften Ausgestaltung weist die Steuerung einen Arbeitsspeicher auf, von dem ein Teil dem Echtzeitsystem und ein zweiter Teil dem Nicht-Echtzeitsystem exklusiv zugeordnet ist, wohingegen auf einen dritten Teil des Arbeitsspeichers sowohl das Echtzeit als auch das Nicht- Echtzeitsystem zugreifen kann. Auf diese Weise besteht mit dem exklusiv zugeordneten ersten und zweiten Teil eine Trennung der beiden Systeme, wohingegen der dritte, gemeinsam genutzte Teil einen Datenaustausch zwischen den Systemen ermöglicht, beispielsweise um das Binärprogramm nach dem Erstellen im Nicht-Echtzeitsystem in das Echtzeitsystem zu übertragen.

In einer weiteren vorteilhaften Ausgestaltung der Steuerung sind auch Schnittstellen, insbesondere externe Schnittstellen und hierbei vor allem Netzwerkschnittstellen, für das Echtzeitsystem und das Nicht-Echtzeitsystem in Hinblick auf die verwendete Hardware getrennt voneinander ausgeführt.

Die Erfindung wird nachfolgend anhand eines Ausführungsbeispiels mithilfe von Figuren näher erläutert. Die Figuren zeigen:

Fig. 1 eine schematische Darstellung einer Steuerung einer industriellen Automatisierungsanlage mit einem gekoppelten Rechner, auf dem eine Entwicklungsumgebung zur Programmierung der Steuerung abläuft;

Fig. 2 eine schematische Darstellung eines erfindungsgemäßen Verfahrens;

Fig. 3 ein schematisches Blockdiagramm der Steuerung gemäß Fig. 1 ;

und

Fig. 4 ein schematisches Diagramm einer Anordnung mehrerer Steuerungen und eines damit gekoppelten Rechners zur Bearbeitung eines verteilten Projekts.

Fig. 1 zeigt in Form eines Blockdiagramms eine beispielhafte industrielle Automatisierungsanlage mit einer Steuerung 10. An die Steuerung 10 sind über ein Bussystem 20, das ein Feldbussystem oder ein proprietärer Bus sein kann, beispielhaft zwei E/A-Module 21 angebunden, die Eingänge 22 und Ausgänge 23 aufweisen, die mit Aktoren und/oder Sensoren der Industrieanlage gekoppelt sind. Die Steuerung 1 0 weist mindestens einen Netzwerkanschluss 1 1 auf, sowie weitere Anschlüsse, z.B. ein Feldbusanschluss 1 2, ein weiterer Feldbus- anschluss 1 3, und ein USB (Universal Serial Bus) -Anschluss 14, sowie Kontrollanzeigen 1 5.

Die Steuerung 10 ist zu ihrer Programmierung über den Netzwerkanschluss 1 1 und ein Netzwerk 30 mit einem Rechner 40 verbunden. Der Rechner 40 wird nur zur Programmierung der Steuerung 1 0 eingesetzt; für den Steuerungsbetrieb ist die Steuerung 1 0 unabhängig vom Rechner 40 und kann autark ohne diesen betrieben werden.

Beispielhaft sind zwei Verbindungen zwischen der Steuerung 10 und dem Rechner 40 über das Netzwerk 30 dargestellt, einmal eine direkte Verbindung über ein Netzwerkkabel 31 und eine Verbindung über ein Internet 32. Zur Verbindung über das Internet 32 können bekannte Verbindungsarten verwendet werden, über die internetspezifische Protokolle ausgetauscht werden können. Im Rechner 40 wird ein Webbrowser 41 ausgeführt, der eine von der Steuerung 1 0 bereitgestellte Webseite ausführt, die eine Entwicklungsumgebung umfasst. Symbolisiert ist die Entwicklungsumgebung im Webbrowser 41 durch ein Programm 41 0 in Form eines Funktionsblockdiagramms, das eine nach der Norm I EC 61 1 31 gültige grafische Programmiermethode für die Steuerung 1 0 dar- stellt.

Fig. 2 zeigt das Zusammenspiel von Steuerung 1 0 und Rechner 40 zur Programmierung der Steuerung 1 0 detaillierter in einem Blockdiagramm. Aus Gründen der Übersichtlichkeit ist das an die Steuerung 1 0 angebundene Bus- System 20 in der Fig. 2 nicht wiedergegeben.

Die Steuerung 10 ist in zwei Abschnitte unterteilt, von denen ein erster ein Nicht-Echtzeitsystem 100 darstellt und ein zweiter ein Echtzeitsystem 1 1 0. Im Echtzeitsystem 1 1 0 werden die Steuerungsaufgaben durchgeführt. Das Echt- zeitsystem 1 1 0 umfasst einen Speicherbereich, in dem ein auszuführendes Binärprogramm 1 1 1 abgelegt ist sowie die gesamte Ablaufsteuerung 1 1 2. Diese Funktionalität ist grundsätzlich bekannt und soll hier nicht näher erläutert werden. Im Nicht-Echtzeitsystem 1 00 ist ein Webserver 1 01 angeordnet, der Daten über das Netzwerk 30 ausgibt und entgegennimmt.

Der Rechner 40 umfasst wie bereits im Zusammenhang mit Fig. 1 erläutert, ei- nen Webbrowser 41 , der mit dem Webserver 1 01 der Steuerung 1 0 kommuniziert. Bei Verbindung des Rechners 40 mit der Steuerung 1 0 und beim Aufruf des Webbrowsers 41 werden Webseiten von dem Webserver 1 01 an den Webbrowser 41 übertragen, die im Webbrowser 41 ein Entwicklungssystem bereitstellen.

Im Entwicklungssystem ist eine grafische Eingabemöglichkeit („editor") für ein Programm 41 0, z.B. in Form eines Funktionsblockdiagramms, enthalten. Der Benutzer des Webbrowsers 41 kann durch Zusammenstellen und Verbinden von Funktionsblöcken das Programm, das auf der Steuerung 1 0 ausgeführt werden soll, zusammenstellen.

Dieses Programm 41 0 wird durch einen ebenfalls in der Entwicklungsumgebung enthaltenen Hochsprachenübersetzer 41 2 in ein Hochsprachenprogramm 41 3 übersetzt. Dieses Hochsprachenprogramm 41 3 wird in einem Speicherbe- reich des Rechners 40, auf den der Webbrowser 41 zugreifen kann, abgelegt.

Bevorzugt ist das Hochsprachenprogramm 41 3 ein C-Programm, oder ein C++- Programm, es können jedoch auch andere bekannte Programmiersprachen eingesetzt werden. Der Vorteil der Umsetzung in ein Hochsprachenprogramm 41 3 liegt in der Hardwareunabhängigkeit von der Steuerung 1 0.

Zusätzlich ist in der Entwicklungsumgebung eine Versionsverwaltung 41 1 umgesetzt, die bestimmte Versionsstände des Programms 41 0, die in das Hochsprachenprogramm 41 3 übersetzt werden, erfasst und an die Steuerung 1 0 weiterleitet. Eine Abspeicherung der Versionsstände erfolgt in einem Versions- Speicher 1 06, der in der Steuerung 1 0 im Nicht-Echtzeitsystem 1 00 vorgesehen ist. Auf diese Weise kann unabhängig vom verwendeten Rechner 40 auf verschiedene Versionsstände des Programms 41 0 zurückgegriffen werden.

Das Hochsprachenprogramm 41 3 wird dann vom Rechner 40 über das Netz- werk 30 zu dem Webserver 1 01 der Steuerung 1 0 übertragen. Bevorzugt werden bekannte webbasierte Synchronisationsmechanismen für Datenbanken für diesen Zweck eingesetzt. In der Steuerung 1 0 wird das Hochsprachenprogramm 41 3 an einen Hochsprachenübersetzer („Compiler") 1 02 weitergeleitet, der das Hochsprachenprogramm 41 3 in ein ausführbares Programm übersetzt. Diesem Programm werden in einem nachfolgenden Link-Prozess durch einen Linker 1 04 hardware- spezifische Bibliotheken 1 03 hinzugefügt. Das entstandene Programm wird in dem Schritt einer Installation 1 05 als Binärprogramm 1 1 1 an das Echtzeitsystem 1 1 0 ausgeliefert („deployment"), und steht damit zur Ausführung auf der Steuerung 1 0 durch die Ablaufsteuerung 1 12 zur Verfügung. Soll dieses Programm weiterentwickelt werden, kann das unabhängig von dem Rechner 40, mit dem es ursprünglich erstellt wurde, abgeändert oder weiterentwickelt werden. Dazu ist jeder beliebige Rechner 40, der lokal oder weltweit über das Netzwerk 30 mit der Steuerung 1 0 gekoppelt wird, in der Lage, über seinen Webbrowser 41 die Entwicklungsumgebung von der Steuerung 1 0 zu beziehen und auch das aktuelle oder eine ältere Version des Programms 41 0 einzuladen, um es weiterzuentwickeln. Nach Änderung des Programms 41 0 wird dieses dann von dem dann benutzten Rechner 40 in der zuvor beschriebenen Weise an die Steuerung 1 0 übertragen, dort in ein Binärprogramm 1 1 1 übersetzt und zur Ausführung gebracht.

Dabei sind bevorzugt Sicherheitsmechanismen vorgesehen, die einen unbefugten Zugriff auf die Steuerung 1 0 unterbinden. Neben Zugriffsbeschränkungen, die das Netzwerk 30 betreffen, stellt der Übergang vom Nicht-Echtzeitsystem 1 00 zum Echtzeitsystem 1 1 0 eine kontrollierbare Grenze dar, die verwendet werden kann, um einen unerlaubten Zugriff auf die Ablaufsteuerung 1 1 2 zu unterbinden.

Fig. 3 zeigt die Steuerung 1 0 im Hinblick auf ihren hardwaremäßigen Aufbau in einer schematischen Darstellung. Die Fig. 3 dient insbesondere dazu, die Auf- teilung der Hardware im Hinblick auf das Nicht-Echtzeitsystem 1 00 und das Echtzeitsystem 1 1 0 zu verdeutlichen.

Die beispielhaft dargestellte Steuerung 1 0 zeichnet sich dadurch aus, dass ein gemeinsam vom Nicht-Echtzeitsystem 100 und vom Echtzeitsystem 1 1 0 ge- nutzter Prozessor 1 20 vorgesehen ist. Es wird angemerkt, dass auch eine Ausgestaltung der Steuerung 1 0, bei der für das Nicht-Echtzeitsystem 1 00 und für das Echtzeitsystem 1 10 jeweils ein eigener Prozessor vorhanden ist, möglich ist. Das dargestellte Ausführungsbeispiel ist jedoch im Hinblick auf eine Kos- tenoptimierung vorteilhafter und bietet dennoch eine sichere Trennung zwischen dem Nicht-Echtzeitsystem 1 00 und dem Echtzeitsystem 1 1 0.

Der Prozessor 1 20 weist im dargestellten Ausführungsbeispiel zwei Kerne 1 21 auf, die unabhängig voneinander arbeitende Rechenwerke darstellen. In alternativen Ausgestaltungen ist auch die Verwendung von Prozessoren mit mehr als zwei Kernen möglich, wobei zumindest jeweils einer der Kerne dem Nicht- Echtzeitsystem 1 00 und einer der Kerne dem Echtzeitsystem 1 1 0 zugeordnet ist.

Jeder Kern 121 weist einen separaten, nur von diesem Kern 1 21 nutzbaren ersten Zwischenspeicher 1 22, auch„Level 1 Cache" genannt, auf. Ein zweiter Zwischenspeicher 1 23, auch„Level 2 Cache" genannt, ist von beiden Kernen 1 21 nutzbar. Auch hier sind alternative Ausgestaltungen möglich, die separate zweite Zwischenspeicher nutzen.

Weiter weist die Steuerung 1 0 einen Arbeitsspeicher 1 24 auf, der ebenfalls von beiden Kernen 1 21 genutzt werden kann und von daher sowohl dem Nicht- Echtzeitsystem 1 00, als auch dem Echtzeitsystem 1 1 0 zur Verfügung steht. Ein hier nicht dargestellter Speicherverwaltungsbaustein regelt den Zugriff des Prozessors 1 20 auf den Arbeitsspeicher 1 24. Dabei ist vorgesehen, den beiden Kernen 1 21 verschiedene Arbeitsspeicherbereiche 1 25 zuzuweisen, die sich innerhalb des Arbeitsspeichers 1 24 teilweise überlappen. Auf diese Weise steht ein erster Teil des Arbeitsspeichers 1 24 nur dem Kern 1 21 des Nicht- Echtzeitsystem 1 00 zur Verfügung und ein zweiter Teil des Arbeitsspeichers

1 24 steht nur dem Kern 1 21 des Echtzeitsystems 1 1 0 zur Verfügung. Ein dritter Teil des Arbeitsspeichers 1 24 kann von beiden Kernen 1 21 genutzt werden und steht somit sowohl dem Nicht-Echtzeitsystem 1 00 als auch dem Echtzeitsystem 1 1 0 zur Verfügung. Dieser dritte Teil des Arbeitsspeichers 1 24 kann genutzt werden, um Daten zwischen dem Nicht-Echtzeitsystem 100 und dem Echtzeitsystem 1 1 0 auszutauschen. Eine vergleichbare Aufteilung kann auch für den zweiten Zwischenspeicher 1 23 vorgesehen sein.

Durch die Trennung des Prozessors 1 20 und des Arbeitsspeichers 1 24 in sepa- rate Kerne 1 21 bzw. Teile des Arbeitsspeichers 1 24 die nur dem Nicht- Echtzeitsystem 1 00 bzw. dem Echtzeitsystem 1 1 0 zugeordnet sind, wird eine sichere Umgebung für das Echtzeitsystem 1 10 geschaffen, um dieses vor unzulässigen Zugriffen durch das Nicht-Echtzeitsystem 100 zu schützen. Die Produktionsumgebung, die von der Steuerung 10 kontrolliert wird, ist somit gegen- über unberechtigten Zugriffen, beispielsweise aus dem Internet und darüber verbreitete Schadsoftware gesichert.

Entsprechend kann auch eine Softwareaktualisierung („Update") getrennt für das Echtzeitsystem 1 10 und das Nicht-Echtzeitsystem 100 vorgenommen werden. Letzteres erfordert in der Regel häufiger eine Aktualisierung, um bekannt gewordene Sicherheitslücken schließen zu können. Bei dem Echtzeitsystem 1 1 0 werden Aktualisierungen eher vermieden, um ein laufendes System nicht unterbrechen zu müssen und eine Gefahr von nicht absehbaren Folgen der Ak- tualisierung zu minimieren. Die strenge Abschottung des Echtzeitsystems 1 10 kommt dem zugute, da abgeschottete Systeme seltener ausnutzbare Sicherheitslücken aufweisen.

Die Trennung und Absicherung spiegelt sich auch in den Verbindungen der Steuerung 1 0 zu externen Geräten wider. Insbesondere sind Netzwerkverbindungen für das Nicht-Echtzeitsystem 1 00 und das Echtzeitsystem 1 10 möglichst voneinander getrennt. Die Steuerung 10 weist daher Schnittstellen 1 1 3 im Echtzeitsystem 1 1 0 auf, beispielsweise eine Ethernet-Schnittstelle, die den (hier beispielhaft Ethernet-basierten) Feldbusanschluss 1 2 bedient, eine Rück- wandbus-Schnittstelle, die das Bussystem 20 für die E/A-Module 21 bedient, und hier beispielhaft eine weitere Feldbusschnittstelle 1 3, z.B. für einen CAN (Controller Area Network)-Bus. Zusätzlich kann für das Echtzeitsystem 1 1 0 ein nicht flüchtiger Speicher 1 14, zum Beispiel ein Flash-Speicher, vorhanden sein. Auch das Nicht-Echtzeitsystem 1 00 weist Schnittstellen 1 07 auf, beispielsweise eine Ethernet-Schnittstelle für den Netzwerkanschluss 1 1 zur Verbindung mit einem innerbetrieblichen Ethernet. Eine weitere der Schnittstellen 107 ist beispielsweise eine USB-Schnittstelle, die den USB-Anschluss 14 bedient. Darüber hinaus kann eine Schnittstelle für einen Kartenslot 1 08 vorgesehen sein, in die z.B. eine SD-Karte eingesteckt werden kann. Ähnlich wie beim Echtzeitsystem 1 1 0 kann auch ein fest eingebauter nicht-flüchtiger Speicher 1 09 vorgesehen sein, beispielsweise in Form einer eMMC-Karte (embedded Multimedia Card). Das anmeldungsgemäße Verfahren zum Erstellen von Binärprogrammen 1 1 1 für die eigentliche Ablaufsteuerung 1 1 2 der Steuerung 1 0 über einen

Webbrowser 41 , der in einem (externen) Rechner 40 betrieben wird, ist im Zusammenhang mit Fig. 2 für die Kombination einer Steuerung 1 0 und eines Rechners 40 beschrieben worden. Nachfolgend wird mit Bezug auf Fig. 4 eine Anordnung beschrieben, bei der mehrere Steuerung 1 0', 1 0" und 1 0"' in einem sogenannten verteilten Projekt vorhanden sind, die von einem Rechner 40 aus verwaltet und programmiert werden können. Die Anzahl der hier gezeigten drei Steuerungen ist dabei rein beispielhaft. Die Anzahl kann auch zwei betragen oder größer als drei sein.

Jede der genannten Steuerungen 1 0', 10" und 1 0"' ist beispielsweise so aufgebaut, wie im Zusammenhang mit den vorherigen Figuren beschrieben ist. Insbesondere weist jede der Steuerungen 1 0', 1 0" und 10"' einen eigenen

Webserver auf, der über ein Netzwerk 30 zugänglich ist. Weiter ist in jeder der Steuerungen 1 0', 1 0" und 1 0"' ein Versionsspeicher 1 06 vorgesehen, in dem ein oder mehrere Steuerungsprogramme sowohl in einer binären Version (vgl. Binärprogramm 1 1 1 in Fig. 2) als auch in Form von Quellcodes (vgl. z.B. als Funktionsblockdiagramm 41 1 gemäß Fig. 1 ), gegebenenfalls in verschiedenen Entwicklungsständen, abgelegt ist.

Zum Bearbeiten oder Erstellen der Programme im Versionsspeicher 1 06 der Steuerungen 1 0', 1 0" und 1 0"' kann vom Rechner 40 aus, wie zuvor beschrie- ben, über einen Webbrowser 41 auf jede der Steuerungen 1 0', 1 0" und 1 0"' zugegriffen werden und das entsprechende Programm zur Bearbeitung eingeladen werden, gegebenenfalls erstellt oder geändert werden. Auf diese Weise können mehrere Steuerungen 1 0 zentral von einem Rechner 40 aus betreut werden.

In einer vorteilhaften Ausgestaltung ist dabei vorgesehen, vom Rechner 40 aus ein übergeordnetes Projekt zu definieren, mit dem die involvierten Steuerungen 1 0', 10", 1 0'" verwaltet werden. Innerhalb der Versionsverwaltung 41 1 des übergeordneten Projekts wird bevorzugt für jede der involvierten Steuerungen 1 0', 10" und 10"' eine Spiegelung der Versionsspeicher 1 06 angelegt. Diese Spiegelungen sind innerhalb der Versionsverwaltung 41 1 als Versionsspeicherspiegelungen 414', 414" und 414"' in der Fig. 4 dargestellt. Bevorzugt wird zu dem Zweck in dem Rechner 40 selbst oder auf einem weiteren Rechner (Server) ein Webserver betrieben, der Vergleichbar mit dem Webserver 1 01 der Steuerungen 1 0', 1 0", 1 0'" die verwendete Entwicklungsumgebung in Form von Webseiten bereitstellt.

Die Versionsspeicherspiegelungen 414', 414" und 414"' bieten den Vorteil, dass gegebenenfalls auch dann an Programmen für die Steuerungen 1 0', 10", 10'" am zentralen Rechner 40 gearbeitet werden kann, wenn die betreffende Steuerung 10', 10", 10'" aktuell nicht verfügbar ist. Ist die Steuerung 10', 10", 10'" wieder verfügbar, beispielsweise weil der Rechner 40 wieder im gleichen Netzwerk betrieben wird wie die entsprechende Steuerung 10', 10", 10'", wird bevorzugt automatisch ein Abgleich zwischen den Versionsspeicher 106 in der entsprechenden Steuerung 10 und dem Versionsspeicher Spiegel 414 in der Versionsverwaltung 41 1 auf dem Rechner 40 vorgenommen.

Auch wenn eine der Steuerungen 10', 10" und 10"' über einen anderen Rech- ner bearbeitet wird, bleiben auf diese Weise im Rechner 40, der das übergeordnete Projekt bearbeitet, die Teilprojekte der einzelnen Steuerungen 10', 10", 10'" konsistent.

Auf diese Weise ist ein flexibles Arbeiten mit verteilten Projekten möglich. Auf die Teilprojekte der einzelnen Steuerungen 10', 10", 10'" kann unter Nutzung der entsprechenden Netzwerkadresse unmittelbar zugegriffen werden und die Teilprojekte können unabhängig vom übergeordneten Projekt bearbeitet und verändert werden. Steuerungsübergreifend kann das Projekt dann auf dem in diesem Sinne übergeordneten Rechner 40 bearbeitet werden.

Vorteilhaft können Projekte so zunächst in kleinem Rahmen unter Einsatz einer Steuerung 10', 10", 10'" begonnen werden und später in einen größeren Kontext, beispielsweise in eine größere Anlage, die von mehreren Steuerungen 10 kontrolliert wird, übernommen werden. Die Projekte skalieren entsprechend je nach Größe der gewählten Automatisierungslösung. Es lassen sich gut Varianten einer Automatisierungslösung erzeugen oder verwalten, wobei der Anwender sich nicht um die konsistente Zusammenführung der Teilprojekte kümmern muss, da dieses durch die Spiegelung der Versionsspeicher 106 automatisch vorgenommen wird. Wartung und Pflege eines verteilten Projekts wird so ver- einfacht, da gezielt an einzelnen der Steuerungen 1 0 Anpassung vorgenommen werden können, ohne immer das gesamte Projekt übergeordnet bearbeiten zu müssen. Bezuqszeichenliste

10 Steuerung

10' - 10'" Steuerung

1 1 Netzwerkanschluss

12 Feldbusanschluss

13 weiterer Feldbusanschluss

14 USB-Anschluss

15 Kontrollanzeigen

100 Nicht-Echtzeitsystem

101 Webserver

102 Hochsprachencompiler

103 Bibliothek

104 Linker

105 Installation

106 Versionsspeicher

107 Schnittstelle

108 Kartenslot

109 nicht flüchtiger Speicher

1 10 Echtzeitsystem

1 1 1 Binärprogramm

1 12 Ablaufsteuerung

1 13 Schnittstelle

1 14 nicht flüchtiger Speicher

120 Prozessor

121 Kern

122 erster Zwischenspeicher

123 zweiter Zwischenspeicher

124 Arbeitsspeicher

125 Arbeitsspeicherbereich 20 Bussystem

21 E/A-Modul

22 Eingang

23 Ausgang

24 weiteres Bussystem Netzwerk

Netzwerkkabel

Internet

Rechner

Webbrowser

Programm (Funktionsblockdiagramm) Versionsverwaltung

Hochsprachenübersetzer Hochsprachenprogramm ' - 414"' gespiegelter Versionsspeicher