WO2020015837A1

WO2020015837A1 - Verfahren und anordnung zur bereitstellung, überprüfung und optimierung eines automatisierungsprogramms

Info

Publication number: WO2020015837A1
Application number: PCT/EP2018/069805
Authority: WO
Inventors: Thomas Trenner; Jan Götz; Andrés Botero Halblaub
Original assignee: Siemens Aktiengesellschaft
Priority date: 2018-07-20
Filing date: 2018-07-20
Publication date: 2020-01-23

Abstract

Die Erfindung betrifft ein Verfahren und eine Automatisierungsanordnung zur Erstellung und Überprüfung und Optimierung eines Automatisierungsprogramms einer industriellen Fertigungseinrichtung, mit zumindest einer Beschreibungskomponente (A, B, C) zur Beschreibung von Anforderungen, mit zumindest einer Engineering-Komponente (D, E) zur Projektierung zumindest einer Automatisierungskomponente (F) hinsichtlich ihrer Hardware und zur Erstellung zumindest eines Automatisierungsprogramms der Automatisierungskomponente (F). Dabei ist eine Generatorkomponente (G) zur Erzeugung einer ersten Spezifikation für eine Hardware-Konfiguration und für das Automatisierungsprogramm, und zur Erstellung einer zweiten Spezifikation für Tests der programmierten Automatisierungskomponente (F) aus den Anforderungen eingerichtet, und weiter ist eine Solverkomponente (H) vorgesehen, wobei diese zur Überprüfung des Automatisierungsprogramms und/oder der sich im Betrieb befindlichen Automatisierungskomponente (F) anhand der zweiten Spezifikationen eingerichtet ist. Durch eine solche Anordnung und ein solches Verfahren wird eine Konsistenz zwisehen den Anforderungen und der projektierten bzw. programmierten Automatisierungskomponente sichergestellt. Vorhandene Teile der Spezifikation müssen nicht erneut händisch eingegeben und überprüft werden, sondern können von einem erfindungsgemäß ausgestalteten System aus Artefakten vorheriger Entwicklungsphasen wiederverwendet werden. Dabei ist von Vorteil, dass die Spezifikation insbesondere für den Test nicht erst zum Zeitpunkt des Projektierens bzw. Programmierens der Hardware und der Software erstellt wird, sondern bereits in vorhergehenden Phasen mit den spezifischen Möglichkeiten der jeweils verwendeten Planungs-Tools erfolgt.

Description

Beschreibung

Verfahren und Anordnung zur Bereitstellung, Überprüfung und Optimierung eines Automatisierungsprogramms

Die Erfindung betrifft ein Verfahren zur Erstellung, Überprü fung und Optimierung eines Automatisierungsprogramms einer industriellen Fertigungseinrichtung gemäß dem Oberbegriff des Patentanspruchs 1, und eine Anordnung zur Erstellung, Über prüfung und Optimierung eines Automatisierungsprogramms einer industriellen Fertigungseinrichtung gemäß dem Oberbegriff des Patentanspruchs 9.

Zur Erstellung eines Automatisierungsprogramms einer indust riellen Fertigungsanlage (das kann auch eine prozesstechni- sche Anlage sein) sind zunächst Tätigkeiten aus dem Bereich des Requirements-Engineerings (Anforderungen an das zu ferti gende Produkt) , des System-Engineerings (Anforderungen an den Fertigungsprozess) und der Anforderungen an das Engineering (Anforderungen an die Automatisierung) der Fertigungsanlage zu berücksichtigen. Ein Automatisierungsfachmann („Automation Engineer") verwendet dabei zur Beschreibung der Produktanfor derungen, des Fertigungsprozesses und der Fertigungs- und Automatisierungsanlage üblicherweise computergestützte Hilfs mittel („Tools"), beispielsweise für das „Requirements- Engineering" das Programm „IBM Rational Doors", für die Be schreibung des Fertigungsprozesses das Produkt „Tecnomatix Process Simulate /Plant Simulation", und für die Beschreibung der Fertigungsanlage das Tool „Siemens Automation Designer".

Die durch die vorgenannten Hilfsmittel erstellten Arbeitser gebnisse, nachfolgend auch „Artefakte" genannt, werden ver wendet, um zum einen die Hardware einer Automatisierungsein richtung zu projektieren, und zum anderen die Software, also die Automatisierungsprogramme, zu erstellen. Für die Hard ware-Projektierung wird beispielsweise das Produkt „Siemens TIA-Portal" und/oder das bereits erwähnte Programm „Siemens Automation Designer" eingesetzt, und für die Erstellung der Software ebenfalls das „Siemens TIA-Portal", die Software „Simulink" von The Mathworks oder andere Tools. Dabei ist der Informationsfluss von den drei erstgenannten Hilfsmitteln, die sich mit den Anforderungen an das Produkt, den Ferti gungsprozess und die Fertigungsanlage befassen, zu den nach folgenden Hilfsmitteln, die sich mit der Erstellung der Hard ware und der Software zur Steuerung der Automatisierung be fassen, heutzutage nur rudimentär und unvollständig automati siert. Das bedeutet, dass mittels einer durchgängigen Daten haltung es nur rudimentär möglich ist, die definierten Anfor derungen direkt in die nachfolgende Verarbeitungsstufe zu übernehmen. So müssen für diesen Datenimport die Daten der einzelnen Vorläuferstufen, also der Beschreibung des Produk tes, des Fertigungsprozesses und der Fertigungsanlage, ge trennt in die Projektierungs-Hilfsmittel der Hardware bzw. der Software geladen werden und getrennt beim Prozess der Hardware-Projektierung bzw. Software-Projektierung berück sichtigt werden. Dieser Prozess geschieht heutzutage nicht in optimaler Weise und ist oft fehlerbehaftet, insbesondere auf grund einer heterogenen „Tool-Landschaft" mit einer Zusammen arbeit verschiedener Programme von verschiedenen Herstellern sowie durch Hürden der jeweiligen Anwendungsdomänen (Hardware - Software - Produkt - Fertigungsanlage - Fertigungsprozess) . Dies führt oft zu erheblichem Informationsverlust, beispiels weise wenn es dazu kommt, die Anforderungen an die zu ferti genden Produkte auf den Fertigungsprozess, auf die Ferti gungsmittel und letztlich auf das Automatisierungssystem (be stehend aus Automatisierungs-Hardware und Automatisierungs- Software) abzubilden.

So ist es heute oft nicht möglich, die Konsistenz der Automa tisierungssoftware mit den Anforderungen an die Fertigung au tomatisiert zu prüfen, wobei es das Ziel ist, dann automati siert Inkonsistenzen oder Fehler und deren Ursachen zu detek- tieren und schließlich abzustellen.

Die Figur 1 zeigt schematisch eine Konstellation der ver schiedenen Hilfsmittel aus dem Stand der Technik, wobei in der ersten Stufe (oben in der Abbildung) die Tools für das Requirement-Engineering A (Anforderung an das Produkt und die Produktionsanlage) , das Systems-Engineering B (Anforderungen an den Fertigungsprozess) und ein Tool für das Engineering der Fertigungsanlage C angeordnet sind. In der nächsten (da runter in dem Bild angeordneten) Ebene sind die Tools für das Engineering der Automatisierungshardware D und zum Enginee ring bzw. Programmieren der Automatisierungssoftware E ange ordnet. Aus den in Bezug auf die Hardware und auf die Soft ware erstellten Projektierungsdaten wird das „Target", also die fertig programmierte Automatisierungskomponente F (bei spielsweise eine speicherprogrammierbare Steuerung SPS) auf gebaut und programmiert. Während der Informationsfluss aus der Projektierung der Hardware und der Software hin zum fer tigen Automatisierungsprodukt anhand der Pfeile in der Figur 1 dargestellt ist und auch heutzutage schon reibungslos, d.h. wenig fehleranfällig, weitgehend automatisch und mit wenigen manuellen Benutzeraktionen funktioniert, sind zwischen den Blöcken A, B und C und den nachfolgenden Einheiten D, E keine Pfeile eingezeichnet, um zu visualisieren, dass dort der In formationsfluss mit den heutigen Mitteln nur unzureichend funktioniert .

Mit anderen Worten: zwischen A/B/C und D bzw. E existiert heute eine informationstechnische Lücke, deren Füllung einem Automatisierungstechniker („Engineer") obliegt, was zu höhe ren Kosten führt, weiterhin zeitliche Verzögerungen in einem Entwicklungsprozess bedingt und nicht zuletzt fehleranfällig ist .

Es ist also eine Aufgabe der vorliegenden Erfindung, die Er stellung, Überprüfung und Optimierung insbesondere einer Pro gramm- und Hardware-Konfiguration zu vereinfachen und zu ver bessern .

Es ist eine Kernidee der erfindungsgemäßen Lösung dieser Auf gabe, das dem Anwender Hilfsmittel bereitgestellt werden, die automatisiert „im Hintergrund" den Informationsfluss verbes- sern und eine Fehlerfreiheit und Konsistenz der Konfiguration (Hardware, Software) sicherstellen und eine etwaige Fehlersu che erleichtern.

Dazu soll zum einen eine „Generator-Einheit" G zur automati schen Erstellung von Spezifikationen sowohl für die in den Tools A, B und C definierten Anforderungen (Requirements ) zur automatischen Verarbeitung in den Projektierungsmitteln D, E für die Hardware und die Software eingesetzt werden, und zum anderen soll diese „Generator-Komponente" Spezifikationen für die Überprüfung der erstellten Hardware-Konfiguration und insbesondere eines erstellten Automatisierungsprogramms be- reitstellen .

Weiter umfasst die erfindungsgemäße Lösung der Aufgabe eine sogenannte „Solver-Komponente" , die die Einhaltung der er zeugten Spezifikationen, die mittels der Generator-Komponente definiert wurden, nach Fertigstellung der Hardware- Projektierung und der Software-Programmierung entweder durch Einsatz von Model-Checking oder spätestens bei einer Inbe triebnahme (produktive Inbetriebnahme oder Inbetriebnahme in einem Test- oder Simulationsszenario) überwacht und bei etwa igen Abweichungen ein geeignetes, korrigierendes Feedback an die Hardware-Projektierung und/oder Software-Projektierung gibt .

Die Aufgabe wird insbesondere durch ein Verfahren gemäß dem Patentanspruch 1 und durch eine Anordnung gemäß dem Patentan spruch 9 gelöst. Dabei ist die Anordnung vorteilhaft so ein gerichtet, dass diese wesentliche Verfahrensschritte teil- oder vollautomatisiert ausführen kann.

Die Lösung der Aufgabe sieht ein Verfahren zur Erstellung, Überprüfung und Optimierung einer Hardware-Konfiguration und/oder eines Automatisierungsprogramms einer industriellen Fertigungseinrichtung vor, wobei während einer Projektie rungsphase aus Anforderungen eines zu fertigenden Produkts, aus Anforderungen an einen Fertigungsprozess und aus Anforde- rungen an eine Fertigungsanlage in einem ersten Schritt eine erste Spezifikation für eine Hardware-Konfiguration zumindest einer Automatisierungskomponente und für ein Automatisie rungsprogramm für die zumindest eine Automatisierungskompo nente und eine zweite Spezifikation für Tests der mit dem Automatisierungsprogramm programmierten zumindest einen Auto matisierungskomponente erstellt werden, in einem zweiten Schritt anhand der ersten Spezifikation die Automatisierungs komponente hinsichtlich ihrer Hardware-Aspekte projektiert und das Automatisierungsprogramm erstellt werden, in einem dritten Schritt anhand der zweiten Spezifikation die Funktio nalität der mit dem Automatisierungsprogramm programmierten Automatisierungskomponente oder zumindest des Automatisie rungsprogramms geprüft wird, und in einem vierten Schritt an hand der festgestellten Abweichungen von der ersten Spezifi kation eine Anpassung des zumindest einen Automatisierungs programms und/oder der Projektierung der Automatisierungskom ponente erfolgt. Durch dieses Verfahren wird eine Konsistenz zwischen den Anforderungen und der projektierten bzw. pro grammierten Automatisierungskomponente sichergestellt. Vor handene Teile der Spezifikation müssen nicht erneut hündisch eingegeben und überprüft werden, sondern können von einem er findungsgemäß ausgestalteten System aus Artefakten vorheriger Entwicklungsphasen wiederverwendet werden. Dabei ist von Vor teil, dass die Spezifikation insbesondere für nachfolgendes Model-Checking mittels eines „Solvers" und/oder Tests nicht erst zum Zeitpunkt des Proj ektierens bzw. Programmierens der Hardware und der Software erstellt wird, sondern bereits in vorhergehenden Phasen mit den spezifischen Möglichkeiten der jeweils verwendeten Planungs-Tools erfolgt.

Die Aufgabe wird außerdem durch eine Anordnung zur Erstel lung, Überprüfung und Optimierung einer Hardware- Konfigurierung und/oder eines Automatisierungsprogramms einer industriellen Fertigungseinrichtung gelöst, mit zumindest ei ner Beschreibungskomponente zur Beschreibung der Anforderun gen an ein zu fertigendes Produkt, zur Beschreibung eines Fertigungsprozesses und/oder zur Beschreibung der Fertigungs- anlage, mit zumindest einer Engineering-Komponente zur Pro jektierung zumindest einer Automatisierungskomponente hin sichtlich ihrer Hardware und zur Erstellung zumindest eines Automatisierungsprogramms zu Programmierung der Automatisie rungskomponente, und mit der zu projektierenden und zu pro grammierenden Automatisierungskomponente. Dabei ist eine Ge neratorkomponente zur Erzeugung einer ersten Spezifikation für eine Hardware-Konfiguration der zumindest einen Automati sierungskomponente und für das Automatisierungsprogramm und zur Erstellung einer zweiten Spezifikation für Tests der mit dem Automatisierungsprogramm programmierten Automatisierungs komponente aus den Anforderungen an das zu fertigende Pro dukt, der Beschreibung des Fertigungsprozesses und/oder der Beschreibung der Fertigungsanlage eingerichtet, und dabei ist eine Solverkomponente vorgesehen, wobei die Solverkomponente zur Überprüfung des Automatisierungsprogramms und/oder der mit dem Automatisierungsprogramm programmierten und sich im Betrieb befindlichen Automatisierungskomponente anhand der zweiten Spezifikationen eingerichtet ist. Mit dieser Anord nung können die bereits anhand des Verfahrens diskutierten Vorteile erzielt werden.

Vorteilhafte Ausgestaltungen der Erfindung sind in den abhän gigen Patentansprüchen angegeben. Die dabei hinsichtlich des Verfahrens beschriebenen Merkmale und deren Vorteile gelten sinngemäß auch für die erfindungsgemäße Anordnung, und umge kehrt. Vorteilhafte Ausgestaltungen können in sinnfälliger Weise miteinander kombiniert werden.

Es gibt verschiedene jeweils in sich vorteilhafte Varianten zur Überprüfung der projektierten Automatisierungslösung, insbesondere des Automatisierungsprogramms, ob das Ergebnis der Projektierung konsistent ist mit den Anforderungen. Eine der vorteilhaften Ausgestaltungen sieht vor, dass die projek tierte Automatisierungskomponente mit dem erstellten Automa tisierungsprogramm in Betrieb genommen wird und anhand von in den zweiten Spezifikationen festgelegten Testkriterien hin sichtlich des Laufzeitverhaltens überprüft wird. In einer ersten Variante kann die projektierte und programmierte Auto matisierungskomponente oder die komplette projektierte Auto matisierungslösung in einem realen Produktionsumfeld in Be trieb genommen werden, wobei also die Überprüfungen während eines produktiven oder zumindest realen Betriebs überprüft werden. In einer anderen Variante kann die reale Produktions umgebung oder Fertigungsanlage zumindest teilweise, aber auch vollständig durch ein Simulations-Szenario nachgebildet wer den, also im Sinne eines Hardware-in-the-loop-Tests (HIL) . Natürlich kann der Programmcode auch analytisch geprüft wer den, indem er beispielsweise „geparst" wird. Auch eine Aus führung auf einem Simulator, also ohne Einsatz der eigentli chen „Ziel-Hardware", ist zu Testzwecken möglich.

Vorteilhaft wird die erste Spezifikation zumindest in Bezug auf die Anforderungen an das Automatisierungsprogramm in Form von Kontrakten formuliert. Durch die Notation in Form von Kontrakten können dabei die Anforderungen in maschinenlesba rer Form definiert werden, so dass durch die nachfolgenden Tools in der Verarbeitungskette, insbesondere von den Tools zur Projektierung der Hardware und zur Erstellung der Soft ware, diese Kontrakte teil- oder sogar vollautomatisch ausge wertet und in eine Hardware-Konfiguration und in eine Soft ware-Konfiguration teil- oder vollautomatisch umgesetzt wer den können. Damit minimiert sich der manuelle Aufwand bei der Erstellung und Programmierung der Automatisierungslösung, wo durch sich zum einen zeit- und kostenökonomische Vorteile er geben, zum anderen aber auch die Fehleranfälligkeit sinkt, da mit der automatischen Auswertung der Kontrakte eine bessere Übereinstimmung der nachfolgend erstellten Automatisierungs lösung mit den verschiedenen Anforderungsprofilen aus dem Produkt, aus der Fertigungsanlage und schließlich der Automa tisierungslösung gewährleistet ist.

In einer vorteilhaften Variante wird insbesondere aus der zweiten Spezifikation zusätzlicher Programmcode erzeugt, der Bestandteil des Automatisierungsprogramms ist und der für die spätere Überprüfung und vorteilhaft auch für den späteren produktiven Betrieb die korrekte Funktionalität der Automati sierungslösung in Bezug auf die Anforderungsprofile über prüft, dokumentiert und sicherstellt. Vorzugsweise wird die ser Programmcode vollautomatisch erzeugt oder zumindest auto matisch an die Spezifikationen, insbesondere an die zweite Spezifikation, angepasst bzw. parametriert .

In einer vorteilhaften Variante der Erfindung wird für den Vergleich zwischen den Anforderungen gemäß der zweiten Spezi fikation und den Resultaten beim Betrieb der Automatisie rungskomponente oder bei einer Offline-Analyse des Automati sierungsprogramms eine Solver-Komponente verwendet. Als eine von der Automatisierungskomponente und von der Erstellung der Spezifikation unabhängige Komponente kann die Solver- Komponente zum einen Spezifikationen übernehmen und auswer ten, und zum anderen Laufzeitinformationen oder Programmspe zifikationen (erstere von der im Betrieb befindlichen Automa tisierungskomponente, letztere aus dem Programmierwerkzeug) übernehmen, wobei dann sowohl die Spezifikationen als auch die Laufzeit- bzw. Programminformationen durch die Solver- Komponente gegeneinander ausgewertet werden. Dabei können vorteilhaft in dem vierten Schritt, insbesondere durch die Solver-Komponente, die zur Verletzung der Spezifikationen beitragenden Variablen des Automatisierungsprogramms und de ren aktuelle Werte zum Zeitpunkt der Verletzung, also derje nigen Werte, die entweder nicht der Spezifikation entsprechen oder aber kausal zur Spezifikationsverletzung geführt haben, einem Benutzer für eine Fehlersuche oder ggf. für eine auto matische Auswertung bereitgestellt werden. Insbesondere eine Übertragung dieser Variablen und Werte an den Solver, an die Hardware-Projektierung und an die Software-Programmierung im Sinne einer „Rückabbildung der Variablenbelegung" (RAV) er leichtert die Fehlersuche und ermöglich ggf. sogar eine auto matische Korrektur der Projektierung bzw. Programmierung.

Ein Ausführungsbeispiel des erfindungsgemäßen Verfahrens wird nachfolgend anhand der Zeichnungen erläutert. Es dient gleichzeitig zur Erläuterung eines Ausführungsbeispiels für eine erfindungsgemäße Anordnung.

Dabei zeigen:

Figur 1 in schematischer Darstellung den Haupt-

Informationsfluss zwischen einem Requirement- Engineering, einem Engineering einer Fertigungsan lage und einem Target gemäß dem Stand der Technik, und

Figur 2 den Haupt-Informationsfluss in einer erfindungsge mäßen Anordnung.

In der Figur 1 ist, wie bereits zuvor kurz erläutert, der weitgehend automatisiert realisierbare Haupt- Informationsfluss bei der Erstellung einer Automatisierungs lösung gemäß dem Stand der Technik erläutert. Zur Erstellung eines Automatisierungsprogramms einer Fertigungsanlage sind dabei Tätigkeiten aus dem Bereich des Requirement- Engineerings A (Anforderungen, z.B. aus dem Produkt und Pro duktionsbedingungen) , des Systems-Engineerings B, C (Enginee ring des Fertigungsprozesses B, Engineering der Fertigungsan lage C) , und des Automatisierungs-Engineerings D, E (Hard ware, Software der Automatisierungskomponenten) durchzufüh ren. Dabei symbolisieren die Bezugszeichen A, B und C die für die Formulierung und Erstellung der Anforderungen gebräuchli chen Software-Werkzeuge von verschiedenen Herstellern, bei spielsweise für die Komponente A das Programm IBM Rational Doors, für die Komponente B das Programmpaket Tecnomatix Pro- cess Simulate /Plant Simulation, für die Komponente C das Tool Siemens Automation Designer. Natürlich können auch ande re Werkzeuge von anderen Herstellern eingesetzt werden.

Die in den Komponenten A, B und C formulierten Anforderungen und „Requirements" werden in den Komponenten des Automatisie rungsengineerings D, E verwendet, um die Hardware der Automa tisierungslösung zu projektieren und die Software der Automa- tisierungslösung, insbesondere einer speicherprogrammierbaren Steuerung F („Target") zu erstellen. Dadurch, dass die ver wendete „Tool-Landschaft" zum einen heterogen ist, was die Anzahl, die Hersteller, die „Sprache" oder Notation der Ar beitsergebnisse und die jeweilige Aufgabe der einzelnen Kom ponenten A, B und C betrifft, ist, sowie durch die Hürden, die dadurch entstehen, dass die erforderlichen Datenschnitt stellen die Grenzen der verschiedenen Anwendungsdomänen (Pro duktplanung, Produktionsplanung, Automatisierungsplanung, An lagenaufbau, Inbetriebnahme, Betrieb) passieren, ergibt sich ein erheblicher Informationsverlust, wenn es dazu kommt, die Anforderungen (die Komponenten A, B, C definieren diese) an die zu fertigenden Produkte auf den Fertigungsprozess, auf die Fertigungsmittel und letztlich auf das Automatisierungs system (bestehend aus Automatisierungshardware und -Software) abzubilden. So ist in der Figur 1 der automatische Haupt- Informationsfluss, der durch Pfeile symbolisiert ist, im We sentlichen nur zwischen den Komponenten D, E (Hardware- Projektierung, Software-Erstellung) und der Ziel-Hardware F (Target, SPS) gegeben. Insbesondere der Informationsfluss von den Komponenten A, B und C zu den Komponenten D, E ist nicht vollständig und in vielen Teilen überhaupt nicht automatisch möglich, sondern muss manuell durchgeführt werden, was die manuelle Arbeit und die Expertise eines Systems-Engineers er fordert .

In der Figur 2 ist schematisch eine erfindungsgemäße Anord nung dargestellt, wobei die entsprechenden Bezugszeichen A,

..., F in der Figur 2 dieselbe Bedeutung haben, wie bereits an hand der Figur 1 erläutert. Das erfindungsgemäße System be steht dabei im Wesentlichen aus acht Elementen. Zunächst sind die Software-Werkzeuge für das Requirements-Engineering A, zur Beschreibung des Fertigungsprozesses B, zur Beschreibung der Fertigungsanlage C, zur Beschreibung und Projektierung der Automatisierungshardware D und zur Beschreibung bzw. Pro grammierung der Automatisierungssoftware E dieselben, wie an hand der Figur 1 beschrieben. Selbiges gilt für die speicher programmierbare Steuerung F, also das „Target". Selbstver- ständlich kann in einem konkreten Anwendungsfall die Konfigu ration auch abweichen, insbesondere können die Komponenten A, B und C auch anders zusammengefasst oder aufgeteilt sein auf verschiedene einzelne Hilfsmittel und Programmpakete. Ebenso wird in der Realität anstelle einer einzelnen speicherpro grammierbaren Steuerung F auch eine größere Anzahl program mierbarer Automatisierungskomponenten vorgesehen sein. Natür lich kann dann auch nicht nur ein einzelnes Automatisierungs programm erstellt werden, sondern es wird sich um eine ganze Familie von unterschiedlichen Automatisierungsprogrammen für die verschiedenen Verarbeitungsstufen einer Fertigungsanlage handeln .

Im Unterschied zu einer Anordnung aus dem Stand der Technik gemäß der Figur 1 zeigt die erfindungsgemäße Anordnung gemäß der Figur 2 zusätzlich einen Generator zur automatisierten Erzeugung von Spezifikationen G und einen Solver H. Der Gene rator zur automatisierten Erzeugung von Spezifikationen G ist in der Figur 2 dabei doppelt dargestellt, weil diese Kompo nente an zwei verschiedenen Stellen des Informationsflusses eingebunden ist. Faktisch handelt es sich in der Regel nur um ein einzelnes Gerät oder eine einzelne Software-Instanz auf einer Recheneinheit (PC, Server, Cloud o.ä.), kann jedoch oh ne Abweichung von der Kernidee der hier skizzierten Lösung auch auf unterschiedliche Instanzen verteilt sein oder sogar in einer „Cloud" als ein Dienst angeboten werden. Selbiges gilt für den Solver H, dessen Funktionalität auch auf ver schiedene Instanzen aufgeteilt sein kann, oder dessen Funkti onalität auch als ein Dienst in einer "Cloud" oder in einer anderen verteilten Infrastruktur angeboten werden kann.

Die bereits beschriebene Informationslücke im automatisierten Datenfluss zwischen den Komponenten A, B, C einerseits und den Komponenten D und E andererseits wird in der erfindungs gemäßen Lösung durch die Komponente G, nämlich den Generator zur automatisierten Erzeugung von Spezifikationen geschlos sen. Diese Facette der Komponente G kann für einen Endanwen der „unsichtbar" im Hintergrund ihre Aufgabe erledigen, was bedeutet, dass Benutzereingaben und eine manuelle Kontrolle der Komponente im Regelfall nicht erforderlich sind. Selbiges gilt für das Wirken des Solvers H, dessen Funktionalität spä ter beschrieben wird und dessen Aufgabe auch im Hintergrund ablaufen kann, aber nicht muss.

Das dargestellte System nutzt den Generator zur automatisier ten Erzeugung von Spezifikationen G zur Erzeugung einer for malen Spezifikation. Dabei ist die Komponente G derart ge staltet, dass Informationen aus einem vorhergehenden Entwick lungswerkzeug oder im Idealfall von mehreren vorhergehenden Engineering-Werkzeugen (insbesondere Komponenten A, B und C) derart genutzt werden, dass dabei erste Spezifikationen er zeugt werden, die zur Projektierung der Hardware und zur Er zeugung der Software benötigt werden und daher direkt von den Komponenten D, E verarbeitet werden können. Sie können auch dem Nutzer visuell aufbereitet werden, damit er das Programm oder die Hardware-Konfiguration passend erstellen kann. Es ist auch möglich, dass in den Komponenten D,E automatisch passende Einstellungen und Parameter gewählt werden (z.B. Wertebereich, Typen, etc.). Weiter werden zweite Spezifikati onen erzeugt, die in einem Ausführungsbeispiel direkt dem Solver H zugeführt werden können und die im Wesentlichen der Überprüfung der Projektierung von Hardware und Software die nen. Die Spezifikationen, die von der Komponente G erzeugt werden, sind in einem Beispiel also Spezifikationen, die dem Solver H als Informationsbasis bzw. als Test-Kriterien (Test- Spezifikation) zugeführt werden, als auch in einem anderen Beispiel sogenannte Test-Vektoren, die innerhalb eines Test- Frameworks (Simulationsumgebung) oder zur Laufzeit (Produk tivbetrieb) direkt auf der Steuerung F (Target) ausgewertet werden, oder aber auch generierte Laufzeit-Tests, die auf der Steuerung F überprüft werden können. Mischformen sind selbst verständlich möglich.

Um dies zu erreichen, werden von der Komponente G spezifische Schnittstellen („Tool-spezifische Schnittstellen") zu den Komponenten A, B und C einerseits und den Komponenten D, E andererseits verwendet. Wird beispielsweise für die Erzeugung und Spezifikation des Automatisierungsprogramms als Komponen te E das Programm „Simulink" verwendet, so weist die Kompo nente G (Generator zur automatisierten Erzeugung von Spezifi kationen) beispielsweise eine Schnittstelle auf, um die in dem Programm „Simulink" hinterlegten Minimal- und Maximal werte von Eingängen eines Reglers in der Hardware- Projektierung D und der Software-Erstellung E (beispielswiese TIA-Portal) derart zu übernehmen, dass sie von dem Solver H auswertbar sind. Dabei können diese Minimal- und Maximal werte oder andere Anforderungen („constraints") beispielswei se in eine prädikatenlogische Formel überführt werden, die von dem Solver H automatisch ausgewertet werden kann. Dadurch kann der in der Komponente E (Tool zur Erzeugung der Automa tisierungs-Software) manuell, halbautomatisch oder vollauto matisch erstellte Programmcode, speziell beispielsweise ein Steuerungscode zum Aufruf und zur Verschaltung eines Reglers, automatisch auf Einhaltung der Minimal- und Maximal-Werte mittels der Komponente H überprüft werden. Die Überprüfung kann teilweise auch in der Komponente E ohne Solver H erfol gen (z.B. an Hand von Typen, etc.) .

Natürlich sind auch andere Varianten der automatischen Über prüfung mittels des Solvers H möglich. Soll beispielsweise ein Requirement zeitliche Abfolgen spezifizieren, sind auch Darstellungen als LTL-Formeln (Linear Temporal Logic) über Variablen möglich, die wiederum von dem Solver H genutzt wer den. Der Steuerungscode, also das erstellte Automatisierungs programm, würde sodann daraufhin „offline" dahingehend veri fiziert werden, ob dieser die LTL-Formeln erfüllt.

Ein häufiges Problem besteht darin, dass eine Prüfung durch den Solver H ein sogenanntes NP-vollständiges Problem ist.

Das bedeutet, dass eine vollständige Überprüfung unter Abde ckung aller möglichen Parameter-Konstellationen in einer zur Verfügung stehenden Zeit nicht oder kaum möglich ist. Daher ist in einer Variante vorgesehen, dass der Generator G das erfindungsgemäße System derart parametriert, dass Test- Vektoren generiert werden, die den zu untersuchenden Pro grammcode überprüfen. Dabei erzeugt die Komponente G also zu sätzlichen Programmcode, der von dem „Target" F ausführbar ist, beispielsweise anstelle der zuvor beschriebenen prädika- tenlogischen Formeln.

Aufgrund der immanenten Eigenschaft der Unvollständigkeit der Tests kann in einer dritten Variante die Generator-Komponente G auch so eingestellt werden, dass separat oder zusätzlich Programmcode erzeugt wird, der eine Überprüfung der Einhal tung der Minimal- und Maximal-Werte zur Laufzeit auf der „Target-Komponente" F ermöglicht. Dieser zusätzlich erzeugte Programmcode kann in einer ersten Variante für einen Anwender sichtbar sein und somit auch verändert werden, oder in einer anderen Variante „unsichtbar" sein, also in seiner Ansicht oder zumindest in der Editier-Möglichkeit für einen Benutzer gesperrt sein.

In jeder der beschriebenen Varianten wird im Falle der Ver letzung der Spezifikationen eine Variablenbelegung im Anwen derprogramm gezeigt, wobei im Idealfall nur oder vorrangig die zur Verletzung führenden Variablen und deren Belegung (Werte) angezeigt werden. Anhand dieser Informationen kann ein Nutzer die Fehlerursache identifizieren, beispielsweise für ein sogenanntes „debugging" . In der Figur 2 ist mit den Pfeilen mit dem Bezugszeichen RAV diese Rückabbildung der Va riablenbelegung im Falle einer Verletzung der Spezifikation gezeigt .

Allgemein kann für die Komponente G gesagt werden, dass vor gesehen ist, sogenannte „Kontrakte" von Software-Bausteinen zu erstellen, wobei die Software-Bausteine vorzugsweise auf einer IEC61131-3-kompatiblen Programmiersprache aufbauen kön nen, was den Vorteil hat, dass der hier typische Anwender diese Sprachen meist gut beherrscht und daher die in einer solchen Programmiersprache formulierten Kontrakte von diesem Anwender leicht nachvollzogen und überprüft werden können. Einerseits werden die erzeugten Kontrakte direkt in den Korn- ponenten D und E zur Projektierung bzw. Programmierung der Hardware und der Software des „Target" F verwendet. Die For mulierung der Kontrakte kann beispielsweise als prädikatenlo- gische Formeln, also über Variablen, erfolgen. In einer vor teilhaften Ausgestaltung werden bereits in vorhergehenden Tools der Verarbeitungskette solche prädikatenlogischen For meln verwendet. So ist es in einigen Tools und Software- Werkzeugen zur Beschreibung der Fertigungsanlage C, bei spielsweise dem Programm „Automation Designer" der Siemens AG, bereits möglich, Software-Module mit bestimmten Schnitt stellen zu definieren. Neben der Möglichkeit datentechnischer Schnittstellen mit einem Software-Werkzeug zur Beschreibung des Fertigungsprozesses B, beispielsweise „Process Simulate", hat das erfindungsgemäße System auch die Möglichkeit, seman tische Schnittstellen der Software-Module zu definieren, bei spielsweise in Varianten, aber auch zeitliche Abhängigkeiten, die auf LTL-Formeln abgebildet werden. Diese werden mittels der Generator-Komponente G bereits in den Komponenten D und E hinterlegt und, wie bereits beschrieben, für die Programmie rung des Targets F und als Informationsgrundlage für die Ar beit des Solvers H verwendet.

Durch die Lösung wird die Konsistenz zwischen den Systemen A/B/C und D/E/F hergestellt und eine automatische Überprüfung der Einhaltung der Spezifikation ermöglicht. Vorhandene Teile der Spezifikation müssen nicht erneut hündisch eingegeben und überprüft werden, sondern können mit dem System aus Artefak ten vorheriger Entwicklungsphasen wiederverwendet werden.

Dies erhöht die Code-Qualität, detektiert frühzeitig Fehler, verkürzt dadurch Entwicklungszeiten und verringert die Zeit für die Inbetriebnahme.

Als Voraussetzung zur Lösung ist der Einsatz der Komponenten G und H zu sehen, die eine Verbindung zwischen A/B/C zu D/E und wiederum zu F/H ermöglichen.

Der Vorteil von G ist, dass die Spezifikation nicht erst zum Zeitpunkt des Programmierens des Automatisierungscodes mit E bzw. der Zusammenstellung der Automatisierungshardware mit D erstellt wird, sondern bereits in vorhergehenden Phasen mit den jeweiligen Tool-spezifischen Möglichkeiten erfolgt. Die Komponente G sorgt sodann für die reibungslose Übernahme der Informationen in eine automatisiert nutzbare Form in D und E (bzgl. E durch Abbildung bspw. auf zusätzlichen IEC61131-3- Code für das Target F oder für Runtime-Tests ) oder aber auch auf prädikatenlogische „Assertions " , die durch H ausgewertet werden können.

Claims

Patentansprüche

1. Verfahren zur Erstellung, Überprüfung und Optimierung eines Automatisierungsprogramms einer industriellen Ferti gungseinrichtung,

wobei während einer Projektierungsphase aus Anforderungen ei nes zu fertigenden Produkts, aus Anforderungen an einen Fer tigungsprozess und aus Anforderungen an eine Fertigungsanlage in einem ersten Schritt eine erste Spezifikation für eine Hardware-Konfiguration zumindest einer Automatisierungskompo nente (F) und für ein Automatisierungsprogramm für die zumin dest eine Automatisierungskomponente (F) und eine zweite Spe zifikation für Tests der mit dem Automatisierungsprogramm programmierten zumindest einen Automatisierungskomponente (F) erstellt werden, in einem zweiten Schritt anhand der ersten Spezifikation die Automatisierungskomponente (F) hinsichtlich ihrer Hardware- Aspekte projektiert und das Automatisierungsprogramm erstellt werden, in einem dritten Schritt anhand der zweiten Spezifikation die Funktionalität der mit dem Automatisierungsprogramm program mierten Automatisierungskomponente (F) oder zumindest des Automatisierungsprogramms geprüft wird, und in einem vierten Schritt anhand der festgestellten Abweichun gen von der ersten Spezifikation eine Anpassung des zumindest einen Automatisierungsprogramms und/oder der Projektierung der Automatisierungskomponente (F) erfolgt.

2. Verfahren nach Patentanspruch 1,

dadurch gekennzeichnet,

dass für den dritten Schritt die projektierte Automatisie rungskomponente (F) mit dem erstellten Automatisierungspro gramm in Betrieb genommen wird und anhand von in der zweiten Spezifikation festgelegten Testkriterien das Laufzeitverhal ten überprüft wird.

3. Verfahren nach Patentanspruch 2,

dadurch gekennzeichnet,

dass die programmierte Automatisierungskomponente (F) für de ren Überprüfung in einer Simulationsumgebung betrieben wird, wobei mit der Simulationsumgebung einige oder alle anderen Bestandteile der industriellen Fertigungseinrichtung simu liert werden.

4. Verfahren nach einem der Patentansprüche 1 oder 2, dadurch gekennzeichnet,

dass in dem dritten Schritt für die Überprüfung der Funktio nalität der programmierten Automatisierungskomponente (F) diese in einer realen industriellen Fertigungseinrichtung be trieben wird.

5. Verfahren nach einem der vorhergehenden Patentansprüche, dadurch gekennzeichnet,

dass in dem ersten Schritt die erste Spezifikation zumindest in Bezug auf die Anforderungen an das Automatisierungspro gramm in Form von Kontrakten formuliert wird.

6. Verfahren nach einem der vorhergehenden Patentansprüche, dadurch gekennzeichnet,

dass in dem zweiten und im dritten Schritt zusätzlicher Pro grammcode zur Überprüfung des Laufzeitverhaltens generiert und in das Automatisierungsprogramm eingefügt wird,

wobei dieser zusätzliche Programmcode zur zumindest teilwei sen Überprüfung des Laufzeitverhaltens in Bezug auf die erste Spezifikation dient und/oder der zusätzliche Programmcode zur Generierung weiterer Daten eingesetzt wird,

wobei diese weiteren Daten zur Überprüfung mittels der zwei ten Spezifikation verwendet werden.

7. Verfahren nach einem der vorhergehenden Patentansprüche, dadurch gekennzeichnet,

dass in dem dritten Schritt für den Vergleich zwischen den Anforderungen gemäß der zweiten Spezifikation und den Resul taten beim Betrieb der Automatisierungskomponente (F) oder bei der Analyse des Automatisierungsprogramms eine

Solverkomponente (H) verwendet wird.

8. Verfahren nach einem der vorhergehenden Patentansprüche, dadurch gekennzeichnet,

dass in dem vierten Schritt die zur Verletzung der zweiten Spezifikation beitragenden Variablen des Automatisierungspro gramms und deren Werte zum Zeitpunkt der Verletzung gespei chert und für eine Fehlersuche einem Benutzer bereitgestellt werden .

9. Anordnung zur Erstellung, Überprüfung und Optimierung eines Automatisierungsprogramms einer industriellen Ferti gungseinrichtung,

mit zumindest einer Beschreibungskomponente zur Beschreibung der Anforderungen an ein zu fertigendes Produkt (A) , zur Be schreibung eines Fertigungsprozesses (B) und/oder zur Be schreibung der Fertigungsanlage (C) ,

mit zumindest einer Engineering-Komponente (D, E) zur Projek tierung zumindest einer Automatisierungskomponente (F) hin sichtlich ihrer Hardware und zur Erstellung zumindest eines Automatisierungsprogramms zu Programmierung der Automatisie rungskomponente (F) , und

mit der zu projektierenden und zu programmierenden Automati sierungskomponente (F) ,

dadurch gekennzeichnet,

dass eine Generatorkomponente (G) zur Erzeugung einer ersten Spezifikation für eine Hardware-Konfiguration der zumindest einen Automatisierungskomponente (F) und für das Automatisie rungsprogramm und zur Erstellung einer zweiten Spezifikation für Tests der mit dem Automatisierungsprogramm programmierten Automatisierungskomponente (F) aus den Anforderungen an das zu fertigende Produkt, der Beschreibung des Fertigungsprozes ses (B) und/oder der Beschreibung der Fertigungsanlage (C) eingerichtet ist, und

mit einer Solverkomponente (H) , wobei die Solverkomponente (H) zur Überprüfung des Automatisierungsprogramms und/oder der mit dem Automatisierungsprogramm programmierten und sich im Betrieb befindlichen Automatisierungskomponente (F) anhand der zweiten Spezifikationen und zur Meldung von zumindest ei ner an einer Verletzung von Spezifikationen beteiligten Vari ablen und deren Wert eingerichtet ist.