Legosortiermaschine gesamte Anlage
Dies ist ein Unterartikel von der Legoteil Zählmaschine, wo Aufgaben bezogen auf die ganze Anlage beschrieben werden.
Anforderungen
Spezifikations-ID | Anforderungs-ID | Anforderungstitel | Beschreibung der Spezifikation | Arbeitsergebnis |
---|---|---|---|---|
010 | REQ10.2000 | Eigenständige Funktionsweise der Sortiermaschine | Funktionsfähig ohne Verbindung zu einem anderen System und ohne menschliche Eingriffe | Inbetriebnahmeprotokoll |
052 | REQ10.2040 | Sicherheit / Gefährdungsbeurteilung | Mechanische Sicherheit (Einklemmschutz) | Inbetriebnahmeprotokoll |
0053 | REQ10.2040 | Sicherheit/ Gefährdungsbeurteilung | Erstellen einer Gebrauchsanleitung im Wiki | Wiki-Artikel |
054 | REQ10.2040 | Sicherheit / Gefährdungsbeurteilung | Erstellen einer Schritt-für-Schritt Anleitung im Wiki | Wiki-Artikel |
410 | REQ10.3250 | Modellierung der System- und Softwarearchitektur | Geeignete Software für System- und Softwarearchitektur verwenden (zb. MS Visio) | Wiki Artikel |
510 | REQ10.3290 | Integrationstests | Für die entwickelte Software bzw. die Steuer- und Regelungsalgorithmen muss ein Integrationstest durchgeführt werden. | Integrations_Tests |
500 | REQ10.3280 | Komponententests | Für die entwickelte Software bzw. die Steuer- und Regelungsalgorithmen müssen geeignete Komponententests durchgeführt und geeignet dokumentiert werden | Unit_Tests |
0070.2 | REQ10.2060 | Verarbeitungszeit | > 80 Legoteile in 10min | |
0320 | REQ10.3220 | Ablagestruktur für Versionsverwaltung | Geeignete Struktur für SVN definieren und einrichten | |
0330 | REQ10.3231 | Dokumentation | Projektergebnisse nachvollziehbar und nachbaubar darstellen für fachversierte Nutzer | |
0432.1 | REQ10.3272 | Nachhaltigkeit | SVN-Nachhaltigkeit | |
0520.1 | REQ10.3300 | Coding Guidelines | Code Reviews | |
0520.3 | REQ10.3300 | Coding Guidelines | Leitfaden überarbeiten (Arduino-C, Matlab) | |
0521 | REQ10.3300 | Coding Guidelines | Untersuchung und Überarbeitung des bisherigen Codes bezüglich Einhaltung der Coding Guidelines |
Schnittstellen
Die Legosortiermaschiene ist in drei Arbeitsbereiche eingeteilt. Dies hat den Vorteil, dass aus dem gesamten Team kleine Gruppen gebildet werden können, welche für ihren Maschinenteil verantwortlich sind. Dadurch wird vermieden, dass Aufgaben doppelt oder gar nicht erledigt werden. Es bringt allerdings den Nachteil mit sich, dass es Schnittstellen zwischen den Gruppen gibt. Diese müssen genau definiert werden, damit eine reibungslose Zusammenarbeit gewährleistet ist.
Separierung - Bildverarbeitung
Die Separierung vereinzelt die Legoteile, damit die Bildverarbeitung diese verarbeiten kann. Dafür sind folgende Vereinbarungen getroffen worden:
Hardware
- Es darf immer nur ein Teil von der Separierung an die Bildverarbeitung übergeben werden
- Das Förderband und der Eingang der Bildverarbeitungsbox liegen auf einer Höhe, damit kein Teil vom Förderband fällt. Damit alle Teile in die Box fallen, ist diese schräg angebracht.
- Die Anlage wird über einen Schaltschrank gesteuert. Dort werden die Komponenten der Separierung und der Bildverarbeitung gesteuert.
Software
Beide Anlagenteile können nicht gleichzeitig durch zwei getrennt Programme gesteuert werden. Deshalb muss eine Hauptfunktion die Laufzeiten steuern. Nötige Vereinbarungen:
- Sobald ein Teil in der Bildbox erkannt wird, bleibt die Separierung stehen
- Kalibrierungen der Kameras wird in der Hauptfunktion durchgeführt
- Die Teilprogramme dürfen keine Dauerschleifen haben
- Die graphische Ausgabe für beide Funktionen ist in einer Figur
Bildverarbeitung - Sortierung
Das Teil aus der Bildverarbeitung muss in die Sortierung gelangen, damit es richtig einsortiert wird. Dafür sind folgende Vereinbarungen getroffen worden:
Hardware
- Die Bildverarbeitung hat den Ausgang zur Seite
- Das Teil wird mit einer Luftdüse herausgeschossen
- Die Anlage wird über einen Schaltschrank gesteuert.
Software
- Hat die Bildverarbeitung ein Teil erkannt, so steuert sie die Klappen der Sortierung. Dazu ist in der Bildverarbeitung hinterlegt, welche Klappen bei jedem Teil angesteuert werden müssen.
Richtlinien zur Codegestaltung
Die Softwarekomponenten der Legoteil-Zählmaschine wurden in MATLAB und Arduino C implementiert. Um den Entwicklungsprozess zu vereinfachen mussten zunächst formalen Guidelines überarbeitet werden. Diese legen die formelle und syntaktische Gestaltung des im Rahmen des Praktikums erzeugten Codes fest.
Insbesondere Liegt der Fokus hier auf:
- Gestaltung von Headern
- Benennung von Funktionen und Variablen
- Umfang von Kommentaren
Die Guidelines beziehen sich in erster Linie auf Code in C/C++ und Matlab, können jedoch auch leicht auf andere Sprachen übertragen werden. Sie wurden im Verlaufe des Semesters mehrfach überarbeitet und angepasst. Dies Erfolgte zuletzt in Zusammenarbeit mit Stephan Marks aus der Gruppe des Autonomen Fahrzeuges. Die entsprechenden Dokumente liegen im SVN oder sind hier im Wiki zu finden und werden auch im weiteren Praktikumsverlauf falls nötig noch erweitert und verbessert werden.
Konkret wurden hierbei folgende Änderungen vorgenommen:
- Die C Richtlinien wurden auf MATLAB erweitert
- Variablenbenennung soll auf Deutsch erfolgen
- Es wurden Anforderungen an Kommentare hinzugefügt, laut denen allein anhand dieser der Programmablauf klar werden muss
- Das Header Format wurde wie Folgt spezifiziert:
Sprache | Modul | Funktion |
---|---|---|
C/C++ | /************************************************************\
*
* Modul : ModulName.c
*
* Datum : 04. Oktober 2013
*
* Beschreibung : Zweck dieses Moduls
*
* Implementierung : Visual Studio 2012 Professional
*
* Autor : Mustermann, Max
*
* Bemerkung : Demo für den ersten Meilenstein
*
* Letzte Änderung : 04. Mai 2018
*
\************************************************************/
|
/***********************************************************\
*
* Funktion : MD_FunktionsName
*
* Datum : 04. Oktober 2013
*
* Beschreibung : Zweck dieser Funktion
*
* Implementierung : Visual Studio 2012 Professional
*
* Autor : Mustermann, Max
*
* Bemerkung : Code-Review noch ausstehend
*
* Letzte Änderung : 04. Mai 2018
*
* Übergebeparameter :
* Typ Name Beschreibung
* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* int n Anzahl Elemente des Arrays
* double[] a Array mit double-Werten
*
* Rückgabeparameter :
* Typ Beschreibung
* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* int Rückgabe eines Fehlercodes
*
\***********************************************************/
|
MATLAB | % ***********************************************************\
%
% Modul : ModulName.m
%
% Datum : 04. Oktober 2013
%
% Implementierung : MATLAB R2013a
%
% Toolbox : Example Toolbox
%
% Autor : Mustermann, Max
%
% Bemerkung : Code-Review noch ausstehend
%
% Letzte Änderung : 04. Mai 2018
%
%************************************************************/
|
%************************************************************\
%
% Funktion : Funktion.m
%
% Datum : 14. Mai 2018
%
% Implementierung : MATLAB R2017a
%
% Toolbox : -
%
% Autor : Marks, Stephan
%
% Bemerkung : Beispiel eines Funktions-Headers
%
% Letzte Änderung : 04. Mai 2018
%
% ***********************************************************/
|
- Im Falle des MATLAB Headers soll nach Möglichkeit zudem eine via
help Funktionsname
aufrufbare Hilfe eingebaut werden. Bei MATLAB wird hierfür stets der erste zusammenhängende Kommentar verwendet, daher sollte sich vor dem eigentlichen Header ein Block folgender Form befinden:
function result = Math_Add_A2B(a, b)
% MATH_ADD_A2B addiert zwei Zahlen
%
% Syntax:
% ergebnis = MATH_ADD_A2B(a, b)
%
% Beschreibung:
% Es werden die zwei Zahlen 'a' und 'b'
% beliebigen Datentyps addiert.
% result = a + b
%
% Eingangswerte:
% a: erster Summand
% b: zweiter Summand
%
% Rückgabewerte:
% result: Ergebnis der Addition von 'a' und 'b'
%
% Beispiel:
% ergebnis = MATH_ADD_A2B(7, 12.583)
Nach der ersten Überarbeitung der Guidelines wurde dann der gesamte bisherige Matlab Code bezüglich der Konformität überprüft und entsprechend überarbeitet. Dabei wurden die Benennungen und Formatierungen in Absprache mit Professor Göbel angepasst, um einen aufgeräumten und einheitlichen Ausgangszustand zu erzeugen, auf dem im Folgesemester weiter aufgebaut werden kann. Dazu wurde jede Datei des Programms analysiert und auf Header, Kommentare, Variablen und Funktionsbenennung untersucht und die Ergebnisse in einer Tabelle festgehalten. Zudem wurde überprüft, ob die einzelnen Funktionen im aktuellsten Programm überhaupt noch Verwendung fanden. Alle nicht verwendeten Programmteile wurden anschließend entfernt.
Ein Ausschnitt der erstellten Tabelle ist im Folgenden dargestellt:
Eine komplette Liste mit allen überarbeiteten und gelöschten Dateien sowie Informationen zu den Umbenennungen sind im SVN zu finden. Eine erneute Überarbeitung der Header aufgrund wiederholter Anpassungen steht noch aus. Auch Code Reviews wurden aufgrund des Arbeitsaufwandes durch die Überarbeitung und den geringen Programmierfortschritt der anderen Teilteams noch nicht durchgeführt.
SVN
Die Ordnerstruktur im SVN wurde größtenteils von den Vorsemestern übernommen. In dem Bereich Dokumentation wurden einige Teilbeeiche hinzugefügt um neu entstandene Dokumente sinnvoll abzuspeichern.
Die Nachhaltigkeit des SVN Ordners wurde durch verschiedene Maßnamen verbessert:
- Entfernen ungenutzter Dateien
- Im Ordner SRC wurden alte, ungenutzte Dateien entfernt
- Löschen temporärer Dateien wie Matlab .asv Dateien oder ~$ Dateien von Office Programmen
- Ignorierliste erweitert
- .asv Dateien
- Inventurliste.xls
- Umbenennungen
- FARBERKENNUNG_V2 --> Farberkennung
- createBinary_V3 --> createBinary
Test der Verarbeitungsrate
Um die Verarbeitungsrate der Maschine aus Spezifikation 0070 zu überprüfen, wird nach jeder Änderung und zu jedem Meilenstein eine Auswahl von Legoteilen in die Maschine eingeworfen und die Zeit bis zur vollständigen Abarbeitung genommen. Anschließend wird daraus die Verarbeitungsrate in Teile pro 10 Minuten ermittelt. Zusätzlich wird über die Differenz der zugeführten und erkannten Teile die Erkennungsrate in Prozent berechnet. Die folgende Tabelle zeigt die Tests der Verarbeitungsrate, die im SS18 durchgeführt wurden.
Datum | Anzahl Teile | erkannte Teile | Dauer | Verarbeitungsrate Teile/10min | Erkennungsrate in % | Modifikation |
---|---|---|---|---|---|---|
23.04.18 | 50 | 13 | 10 Minuten | 13,0 | 26 | Vorvereinzelung entfernt Steigförderband Muster 2 |
14.05.18 | 70 | 33 | 9,5 Minuten | 34,74 | 47,14 | Steigförderband Muster 4; Erhöhung der Bandge-schwindigkeit |
28.05.18 | 70 | 33 | 7 Minuten | 47,14 | 47,14 | Verbesserung der Farberkennung |
25.06.18 | 81 | 54 | 9,5 Minuten | 56,84 | 66,67 |
Wie der Tabelle zu entnehmen ist, konnte die Verarbeitungs- und Erkennungsrate innerhalb des SS18 durch provisorische Modifikation des Steigförderbands und Programmverbesserungen merklich gesteigert werden. Die Zielvorgabe mit mehr als 80 Teilen pro 10 Minuten konnte jedoch nicht erreicht werden. Die Umsetzung der geplanten Konzepte zur Verbesserung der Vereinzelung sowie Zentrierung im WS 18/19 verspricht weiterhin eine erhebliche Verbesserung der Verarbeitungsrate der Maschine.
[3]
[4]
Inbetriebnahmeprotokoll
In einem Inbetriebnahmeprotokoll wurde die Legosortiermaschine im Juni 2018 in Betrieb genommen. Folgende Requirements wurden in diesem Protokoll bearbeitet und als Ergebnis in SVN festgehalten:
Spezifikations-ID | Anforderungs-ID | Anforderungstitel | Beschreibung der Spezifikation |
---|---|---|---|
0020 | REQ10.2010 | Antriebe | Elektrischer Antrieb muss vorhanden sein |
0030 | REQ10.2020 | Energieversorgung | Per 230V AC Schukostecker |
0040 | REQ10.2030 | Abmessung | 2,5m x 1m x 1,5m Grundplattenmontage |
0056 | REQ10.2040 | Sicherheit/ Gefährdungsbeurteilung | Drucken und Anbringen von Warnhinweisen |
Das Inbetriebnahmeprotokoll ist unter folgendem Link zu finden: Inbetriebnahmeprotokoll
Der Systemtest der elektrischen Antriebe wurde zudem in einem Protokoll festgehalten und ist unter folgendem Link zu finden: Systemtest elektrische Antriebe
Gefährdungsbeurteilung
Eine Gefährdungsbeurteilung wurde im Juni 2018 erstellt.
Die Gefährdungsbeurteilung wurde in tabellarischer Form angelegt und listet mögliche Gefahren der Legosortiermaschine auf. Von der Grundausstattung über elektrische und mechanische Gefährdungen, wurden auch Gefahrstoffe und Brandgefährdungen kontrolliert.
Mögliche Gefahren wurden dabei in folgende Risikostufen eingeteilt:
- Kein Risiko
- Geringes Risiko
- Großes Risiko
Anhand der Risikostufe werden desweiteren Lösungsmaßnahmen sowie Termine zur Fehlerbehebung festgelegt.
Es wurden die folgenden drei Risiken erkannt:
1.) Eine Betriebsanweisung ist erstellt worden?
Das Risiko wurde als gering eingeschätzt und es wurde die Pflicht aufgenommen, eine Betriebsanweisung zum Meilenstein 4 zu erstellen.
2.) Bewegte Transportmittel, bewegte Arbeitsmittel
Für das Förderband gibt es momentan lediglich einen Warnhinweis und keinen materiellen Einklemmschutz. Dieses Risiko wurde als gering eingeschätzt und zum Meilenstein 3 wird ein Schutz angebracht werden.
3.) Unkontrollierte bewegte Teile
Nach der Bildverarbeitung werden die Legoteile "ausgeschossen". Dieses Risiko wurde ebenfalls als gering eingestuft. Als Maßnahme gilt der Zusammenbau der Sortiereinheit, welcher anschließend vor der Bildverarbeitung positioniert wird.
Die gesamte Gefährdungsbeurteilung wurde in SVN abgelegt und ist unter folgendem Link zu finden: Gefährdungsbeurteilung
Software Dokumentation
Spezifikations-ID | Anforderungs-ID | Anforderungstitel | Beschreibung der Spezifikation |
---|---|---|---|
410 | REQ10.2320 | Modellierung der System- und Softwarearchitektur | Geeignete Software für System- und Softwarearchitektur verwenden (zb. MS Visio) |
Eine Softwarearchitektur beschreibt die grundlegenden Komponenten und deren Zusammenspiel innerhalb eines Softwaresystems.
Eine Systemarchitektur wird nach dem V-Modell XT im Rahmen des Systementwurfs erstellt und umfasst die Dekomposition des Systems, die Schnittstellenübersicht und den übergreifenden Datenkatalog (Daten, die Systeme und Systemelemente austauschen).
Zu Beginn der Systemarchitekturarbeiten werden, durch Analyse der Gesamtsystemspezifikation und weiterer vorhandener Informationen, Architekturtreiber identifiziert und Bewertungskriterien festgelegt. Funktionale und nicht-funktionale Anforderungen beeinflussen den Entwurf der Systemarchitektur, die in Architektursichten dokumentiert wird.
Für die System- und Softwarearchitektur müssen Programme verwendet werden die kostenfrei sind oder durch die Hochschule zur Verfügung gestellt werden.
Beipielhaft können folgende Programme verwendet werden:
- PapDesigner
- MS Visio
- Clickcharts
- Dia
- XMind
- FreeeMind
Für den Ablauf der Legosortiermaschine wurde mit der Software PAP-Designer ein Ablaufplan erstellt. In der neben stehenden Abbildung 2 ist ein Auszug zu sehen.
Das Dokument ist unter folgendem Link abrufbar:
Dateien sollten nicht als PDF oder Bilder gespeichert werden um nachfolgenden Gruppen die Weiterbearbeitung und Ergänzung zu ermöglichen.
Dokumentation
Die Ergebnisse des Projektes wurden, wie in Spezifikation 0330 gefordert, nachvollziehbar und nachbaubar dokumentiert. Die gesamten Dateien und Unterlagen zur Dokumentation sind strukturiert in SVN gesichert und versioniert. Abbildung 3 zeigt eine Übersicht der Dokumentationen, die im SS18 anzufertigen waren. Mit Hilfe der dort dargestellten Tabelle wurde die Vollständigkeit sowie der Fortschritt der Dokumentation überprüft.
Zusammenfassung
Dieser Artikel beschreibt Punkte zur Hardware und Software, die auf die gesamte Anlage bezogen sind. Umgesetzte Punkte sind die folgenden:
- Coding Richtlinien
- SVN Organisation
- Test der Verarbeitungsrate
- Inbetriebnahmeprotokoll
- Gefährdungsbeurteilung
- Dokumentation
Liste offener Punkte (LOP)
Die Requirements des Sommersemesters 2018 wurden alle erfüllt. Für das Wintersemester 18/19 sind folgende Punkte in Bezug auf die gesamte Anlage zu erledigen:
- Erstellen einer Betriebsanweisung
- Erstellen einer Schritt-für-Schritt Anleitung
- Neu verdrahten des Schaltschrankes
- Erstellung eines Schaltplans
Autoren
Dies ist ein Unterartikel von der Legoteil_Zählmaschine, welcher die Zusammenführung der einzelnen Teile zu einer Einheit beschrieben.