Maschinenmodularisierung
Artikel#: 00070
Datum: 2021-10-08
Autor: Radim
Wie unterteilen wir das gesamte Maschinenprogramm richtig in Module?
Wir müssen uns die Maschine ansehen, ihren Aufbau, aus welchen Maschinenteilen sie besteht, wie sie mit Sensoren und Aktoren ausgestattet ist und wie der Ablauf und die Funktionalitäten der Maschine aussehen.
Ein Modul führt eine Funktion der Maschine oder eines Maschinenteils aus und kapselt alles, was für die Funktion benötigt wird.
Es hat normalerweise einige Eingänge, Ausgänge, interne Funktionen und kann andere untergeordnete Module enthalten.
Das Modul ist ein Werkzeug, mit dem wir einen Teil der Maschine steuern.
Das Modul sammelt Informationen von Peripheriegeräten oder untergeordneten Modulen, verarbeitet sie und gibt Befehle an diese Peripheriegeräte oder untergeordneten Module aus.
Es liefert auch Informationen über seinen Status für Elternmodule und für die Visualisierung und führt Befehle aus, die von den Elternmodulen und der Visualisierung kommen.
Die Module sind wie Schachteln, die wir ineinander stecken.
Elternmodul enthält ein oder mehrere untergeordnete Module.
Mit dieser Modularisierung schaffen wir eine hierarchische Struktur des Maschinenprogramms.
Die Anzahl der Ebenen in der Struktur ist nicht begrenzt.
Im Allgemeinen sind wir auf höheren Ebenen abstrakter und losgelöst von den realen physischen Geräten, aber wenn wir es brauchen, können wir Peripheriegeräte auf jeder Ebene anschliessen (Siehe "Button Z" in der Abbildung unten.).
Beginnen wir die Modularisierung mit der untersten Ebene der Maschine - mit Sensoren und Aktoren. (Siehe "Module A" und "Module B" in der Abbildung unten.)
Dann müssen wir eine sinnvolle Gruppierung von Modulen der niedrigsten Ebene finden.
Wir gruppieren einige Module zusammen, wenn wir sehen, dass sie eine Teilfunktion der Maschine ausführen können.
Dadurch werden die Module der zweiten Ebene erstellt. (Siehe "Module C" in der Abbildung unten.)
Die richtige Gruppierung der Module erkennt man daran, dass das Elternmodul alles (alle notwendigen untergeordneten Module) zur Verfügung hat, was es für seine Funktion benötigt.
Dies ist die richtige Kapselung und Abstraktion, die das Programm richtig strukturiert macht.
Wir legen kleine Schachteln in eine grössere Schachtel.
Dann packen wir grössere Schachteln in eine noch grössere Schachtel und so weiter.
Und schliesslich enthält die grösste Schachtel genau alles, was wir brauchen und repräsentiert somit unsere Maschine / Anlage oder das ganze System.
Abbildung: Verschachtelung der Module; Modulschnittstellen
Erklärung der Abbildung:
Die Abbildung ist ein Beispiel für die Verschachtelung von Modulen der untersten Hierarchieebene (Modul A und Modul B) im Elternmodul (Modul C).
Die Abbildung zeigt auch 3 verschiedene Typen von Modulschnittstellen: Schnittstelle zu Peripheriegeräten, Schnittstelle zum Elternmodul und Schnittstelle zur Visualisierung (Human Machine Interface).
Die Ellipse repräsentiert die programmierte Funktion des Moduls.
Die in das Modul zeigenden Pfeile repräsentieren die definierten Eingänge des Moduls.
Die aus dem Modul herauszeigenden Pfeile repräsentieren die definierten Ausgänge des Moduls.
Modul A ist ein Modul auf der untersten Ebene der hierarchischen Struktur.
Dieses Modul verfügt über definierte Eingänge für einen Sensoranschluss. (Dieser Anschluss kann z. B. ein 4-20mA Analogsignal sein.)
Das Modul verfügt ausserdem über eine definierte Schnittstelle (Ein- und Ausgänge) zur Kommunikation mit dem Elternmodul und Ausgänge zur Bereitstellung von Informationen an die Visualisierung (Human Machine Interface).
Modul B ist auch ein Modul auf der untersten Ebene der hierarchischen Struktur.
Dieses Modul verfügt über definierte Ein- und Ausgänge für einen Aktoranschluss. (Diese Verbindung kann z. B. ein Profibus-Signal sein.)
Weiterhin verfügt das Modul über eine definierte Schnittstelle (Ein- und Ausgänge) zur Kommunikation mit dem Elternmodul und Ausgänge zur Bereitstellung von Informationen an die Visualisierung (Human Machine Interface).
Modul C ist ein Elternmodul für die Module A und B.
Modul C hat einen digitalen Eingang zum Anschluss eines Tasters (Button Z).
Modul C verfügt zusätzlich über eine definierte Schnittstelle (Ein- und Ausgänge) zur Kommunikation mit einem Elternmodul.
Modul C hat Eingänge zum Abrufen von Befehlen von der Visualisierung und Ausgänge zum Bereitstellen von Informationen an die Visualisierung (Human Machine Interface).
© Radim-Automation, 2020–2025. Alle Rechte vorbehalten.
Die Verbreitung dieses Artikels ist mit Angabe der Quelle (Link zur Originalseite) ausdrücklich gestattet.
Verwandte vorherige Artikel:
- Modulare Softwarearchitektur
- Hardwarekonzept
- Ein gutes Konzept = Kompletter Satz geeigneter Lösungen
- Entwerft Maschinen mit Fokus auf die Fähigkeiten und Bedürfnisse des Benutzers
- Warum scheitern Automatisierungsprojekte?
- Sammelt alle Anforderungen und sortiert sie!
- Wer wird operieren?
- Funktionelles und intuitives HMI
- Verwende einen nützlichen Styleguide!
- Schreibe und akzeptiere nur lesbaren Code!
- Ernenne einen Vertreter!
- HMI- und SPS-Anwendungen sollen zusammenwachsen
- Willst du damit wirklich beginnen?
- Ich sehe was, was du nicht siehst
- Mehr als nur starten und stoppen
- Sicherheit zuerst!
- Mach die richtigen Dinge und mach sie richtig!
- Definiere kontinuierlich Testszenarien und Testfälle!
- Mach es nicht schlimmer!
- Behaltet die Antworten auf die Frage "Warum"
- Alles ist schwierig, bis es einfach wird
- Komm und bleibe im "Flow"!
- Bleibe wachsam!
- Was braucht der Kunde?
- Enttäuscht euren Kunden nicht!
- Stelle Fragen!
- Entwickle Verantwortungsbewusstsein!
- Erledige die Dinge mit einem kleinen, motivierten Team!
- Konzentriere dich auf das Ziel!
- Überlege auf dem Papier!
- 9 Frauen können ein Baby nicht in einem Monat zur Welt bringen
- Schärfe deine Axt, bevor du beginnst zu fällen!
- Überprüfe das Ergebnis!
- Halte es einfach!
- Verlass kein Arbeitspaket halbfertig!
- Erfolg ist kein Zufall
- Entwicklung ist Evolution
- Folge der Vision!
- Vernachlässige und überspringe keinen Schritt!
- Transparenz und Zuverlässigkeit
- Von einer Idee zu einem konsistenten System
Verwandte nächste Artikel:
- Erkenntnisse aus einem abgeschlossenen Projekt sind unbezahlbar
- Variablennamen
- Wahl der Programmiersprache
- Visuelle Modellierung
- Dokumentationsprobleme
- Sicherheitsrelais versus Sicherheits-SPS
- Designüberlegungen für effektive HMIS
- Klare Signale
- Ohne Sensoren geht es nicht
- Ereignislogger als allererste im Programm implementierte Funktion
- Mein Chef war ein Held
- Versionskontrollsystem
- SPS-Netzwerkdiagramm
- Pflege Ordnung im Programmkode
- Traum von einem plattformunabhängigen SPS-Programm
- Halte alles, was du brauchst, zusammen
- High Performance HMI
- Die falsche Illusion des schnellen Fortschritts
Kommentar#: 00001
Datum: 2021-10-13
Benutzer: Radim
Wenn du der Meinung bist, dass ein untergeordnetes Modul zwei Elternmodule hat, die beide das eine untergeordnete Modul steuern müssen, dann sollte das untergeordnete Modul nicht in einem der Elternmodule platziert werden, sondern direkt neben ihnen auf derselben Ebene wie die Elternmodule. Das Modul, das sich in der hierarchischen Struktur über den beiden Elternmodulen befindet und diese steuert, soll auch das gemeinsame Modul entsprechend den Zuständen der beiden Elternmodule steuern.
Kommentar#: 00002
Datum: 2021-10-13
Benutzer: Radim
Bleibe flexibel in der Programmstruktur! Auch wenn ihr alle Anforderungen gesammelt habt und die Prozessexperten behaupten, "so ist es endgültig", gibt es Fälle, in denen es bei der Inbetriebnahme und ersten Tests notwendig ist, diese "endgültigen" Dinge wieder zu ändern.
Kommentar#: 00003
Datum: 2021-10-17
Benutzer: Radim
Die Problemanalyse ist mit einer geeigneten modularen Architektur einfach. Da immer ein übergeordnetes Modul die Eingänge steuert und die Ausgänge seiner untergeordneten Module verarbeitet, lässt sich leicht feststellen, an welcher Schnittstelle die Informationen nicht übertragen werden.
Kommentar#: 00004
Datum: 2021-10-19
Benutzer: Radim
Um alle Dinge, die das Modul für seine Funktionalität benötigt (aber sonst nichts) richtig zu kapseln, ist es gut sich vorzustellen, dass wir das Modul möglichst einfach aus dem Programm/Projekt entfernen und in einem anderen Programm/Projekt verwenden müssen.
Stelle dir vor, ein Modul möchte von einem Kollegen in seinem Programm verwendet werden ... Ist das Modul entsprechend gekapselt, kann das Modul möglichst einfach übernommen werden?
Kommentar#: 00005
Datum: 2021-10-19
Benutzer: Radim
Die Inbetriebnahme der Maschine geht deutlich schneller, wenn das Programm richtig in Module strukturiert ist. So ist beispielsweise kein ausführlicher I/O-Test notwendig, es reicht aber aus, die Funktion jedes Moduls im Handbetrieb mit der Maschine zu testen. Nur wenn die Maschine die vorgesehene Funktion nicht erfüllt, müssen wir nach einem Problem in der Zuordnung der Variablen, Verdrahtung und Pneumatik suchen.
Kommentar#: 00006
Datum: 2021-10-20
Benutzer: Radim
Die Entwicklung jedes Moduls ist ein separates Teilprojekt innerhalb des Hauptprojekts und sollte alle Phasen des Entwicklungszyklus umfassen, d. h. Analyse, Programmierung, Test usw.
Kommentar#: 00007
Datum: 2021-10-20
Benutzer: Radim
Antworten auf diese Fragen können bei der Modularisierung helfen:
1. Welche Elemente gibt es?
2. Wie ist die Beziehung zwischen den Elementen?
3. Wie sind die Elemente mit der SPS verbunden?
4. Welche Informationen liefern die Elemente?
5. Für wen sind diese Informationen interessant?
6. In welchen Zuständen können die Elemente geschaltet werden?
7. Wer steuert die Elemente?
8. Unter welchen Bedingungen wollen wir die Elemente in ihre möglichen Zustände schalten?
9. Unter welchen Bedingungen dürfen die Elemente nicht in bestimmte Zustände geschaltet werden?