Projekt Metalldetektor. Die meisten von uns kennen Metalldetektoren vielleicht von Sicherheitskontrollen zum Beispiel auf einem Flughafen. Metall und die Annäherung von Metall zu detektieren ist jedoch in vielen technischen Anwendungsbereichen eine wichtige zu lösende Aufgabe.

In diesem kleinen Projekt werden ausgewählte Elemente aus diesem Tutorial in einer Anwendung zusammenwirken. Dabei soll eine konkrete (physikalische) Aufgabe (Metall detektieren) mit den Mitteln der digitalen Signalverarbeitung gelöst werden. Würde man die erzielte Lösung miniaturisieren käme dann ein intelligenter Sensor dabei heraus. Rechts neben unserer Experimentierhardware ist zum Vergleich ein industrieller induktiver Näherungssensor zu sehen.

Es ist ein Metalldetektor mit Mikrocontrollersteuerung zu entwickeln. Die zu verwendende Hardware ist ein mySTM32 Board light und ein myFinder Metalldetektor-Add-On.

Die Erarbeitung der Lösung der gestellten Aufgabe setzt ein gewisses Grundverständnis der physikalischen Vorgänge am verwendeten Metalldetektor voraus.

Bei dem myFinder Metalldetektor-Add-On handelt es sich um einen Pulsinduktionsmetalldetektor. Das Pulsinduktionsverfahren zeichnet sich durch einfachen und robusten Aufbau, störungssichere Funktion sowie hohe Leistungsfähigkeit (Suchtiefe) aus.

Pulsinduktionsmetalldetektoren besteht aus folgenden Komponenten.

1. Energieversorgung
2. Impulsgenerator
3. Endstufe
4. Suchspule
5. Verstärkerstufe
6. Auswertungslogik
7. Schnittstelle zum Anwender (HMI, Benutzer-Ein- und Ausgaben)

Dabei sollen bestimmte Teile des Systems mit einem Mikrocontroller also als digitale Lösung gestaltet werden.

Pulsinduktions-Arbeitsprinzip

Das Grundprinzip des PI-Metalldetektors basiert auf der elektromagnetischen Induktion. Dazu wird ein starker elektromagnetischer Impuls ausgesendet. Dieser induziert Wirbelströme in Metallgegenständen die sich in der Reichweite des Impulses befinden. Die Wirbelströme in den Metallgegenständen erzeugen wiederum elektromagnetische Felder die als „Echo“ auf den Impuls empfangen und ausgewertet werden können.

Zum senden des elektromagnetischen Impulses wird eine Spule genutzt. Diese Spule kann aber auch zum Empfangen des Echosignals genutzt werden. Das empfangene Echo muss erheblich verstärkt werden damit wir es auswerten können. Den typischen Signalverlauf eines PI-Metalldetektors zeigt das folgende Bild.

Das gelbe Signal zeigt den ausgesendeten Impuls. Wir nennen dies das Primärsignal der Spule. Das rote Signal ist das Ergebnis nach der Verstärkung des Ausgangsignals nach der Spule. Aus diesem Signal müssen wir das sogenannte Sekundärsignal (das Echo) herauslesen. Es ist zu erkennen, dass zwischen den Impulsen eine längere Pause liegt. Diese dient zum Aufladen des Kondensators der Leistungsstufe. Der hohe Strombedarf des elektromagnetischen Impuls sollte nicht direkt aus der primären Energieversorgung gezogen werden sondern aus einem entsprechend dimensionierten Pufferkondensator. Der braucht natürlich Zeit sich wieder aufzuladen. Dafür wird bei der vorliegenden Schaltung etwa 1 Millisekunde benötigt. Das ist die lange Pause zwischen den Impulsen. Die hier verwendete Suchspule benötigt zum vollständigen Aufbau des elektromagnetischen Feldes um sich herum etwa 70 bis 100 Mikrosekunden. Das ist die optimale Dauer des Primärsignals (Impulses). Ist der Impuls kürzer sinkt damit die Energie des Magnetfeldes also wird die Suchleistung geringer. Ist der Impuls länger fließt der Strom nicht mehr in den Aufbau des elektrischen Feldes sondern wird nutzlos in Wärme umgewandelt. In den folgenden Bilder und dem Video wird der Signalverlauf bei Annäherung von Metall an die Spule gezeigt.

Es ist deutlich zu sehen wie das Sekundärsignal sich bei Annährung des Metallgegenstandes verändert. Unmittelbar nach Ende des Impulses ist das Echo offensichtlich nicht besonders gut auszuwerten. Aber etwa ab 10 bis 20 Mikrosekunden nach dem Impuls kann man deutlich einen gut auswertbaren Signalverlauf erkennen.

Es lässt sich zum Funktionsprinzip des PI-Metalldetektors folgendes zusammenfassen:

1. ein bis zwei Millisekunden Aufladen der Leistungsstufe (charging break)
2. 70 bis 100 Mikrosekunden Senden des Impulses (pulse)
3. mindestens 10 bis 20 Mikrosekunden Wartezeit vor dem Austasten des Sekundärsignals (sample delay)
4. Erfassen des Analogsignals und Auswertung (sampling)
5. Auswertung des erfassten Signals (processing)
6. Anzeigen des Ergebnisses (displaying)
7. weiter mit 1. also den Vorgang wiederholen (repeat)

Für das im hier beschriebene Projekt werden folgende Komponenten verwendet.

• mySTM32 Board light für Ein- und Ausgaben, Steuerung und Auswertung sowie Energieversorgung über USB
• Metalldetektor Add-On myFinder für die zusätzlich benötigten Bausteine: Endstufe, Suchspule und Verstärkerstufe
• Kabelsatz zum Herstellen der benötigten Verbindungen

Es ist natürlich auch möglich eine eigene Schaltung für das Projekt zu entwerfen und herzustellen. Dabei können sich einzelne der hier genannten Parameter ändern. Das Grundprinzip beleibt das Selbe. Ein Oszilloskope kann eine sinnvolle Ergänzung der Ausrüstung sein ist aber nicht zwingend erforderlich.

Das Projekt kann in folgende Arbeitspakte unterteilt werden:

1. Analyse der Aufgabenstellung und des Funktionsprinzips
2. Entwurf eines Lösungskonzepts
3. Realisierung der Lösung
4. Test und
5. Dokumentation der Lösung
6. Übergabe

Die konkrete Arbeitsorganisation und ggf. Aufgabenverteilung hängt vom jeweiligen Kontext ab und kann natürlich variieren.

Die Anforderungen an ein zu entwickelndes System können grob in folgende Kategorien unterteilet werden:

• Hauptanforderungen (general requirements, top level requirements)
• funktionale Anforderungen, in der regel Konkretisierung der Hauptanforderungen (functional requirements)
• nicht funktionale Anforderungen, in der Regel Qualitätsanforderungen (nonfunctional requirements)
• sonstige Anforderungen zum Beispiel an die Projektorganisation (e.g. process requirements)

Moderne Anforderungsdefinitionen erfolgen aus der Benutzerperspektive. Dafür bietet die UML und die SysML eine spezielle Darstellungsformen an: Das Anwendungsfalldiagramm. Im Anwendungsfalldiagramm wird herausgearbeitet WAS das System für WEN leisten soll. Die folgende Darstellung zeigt die Benutzerperspektive des Metalldetektors als Anwendungsfalldiagramm.

Die Grundlagen für das Erstellen von Anwendungsfalldiagrammen sind recht einfach zu erlernen.

Für funktionalen Anforderungen also WIE soll das System die gewünschte Leistung erbringen bietet sich zum Beispiel das UML Aktivitätsdiagramm als mögliche Darstellungsform an.

Die Verfeinerung der Anwendungsfälle mit den erwarteten Abläufen nennt man Szenarien oder auch User-Storys. Die folgenden Abbildungen zeigen mögliche Szenarien der oben dargestellten Anwendungsfälle des Systems.

Das Erstellen von Aktivitätsdiagrammen ist nicht ganz trivial aber einfache Flussdiagramme zu modellieren ist recht schnell zu erlernen.

Zusammenfassend lässt sagen, dass sich mit den Modellierungsmöglichkeiten der UML und SysML folgende Aussagen zum zu entwickelnden System präzise herausarbeiten lassen:

• WAS soll das System leisten = Anwendungsfälle
• WER soll das System benutzen = Akteure
• WIE soll das System benutzt werden = Szenarien

Auch wenn die in diesem Kurs beschriebene Vorgehensweise modellgetrieben ist so stellt sich in der Praxis trotzdem die Aufgabe projektbezogene Dokumente vorzulegen. Dokumente und Anforderungsspezifikationen die von Mitarbeitern manuell in Textverarbeitungssystemen oder auch in Datenbank-basierenden Managementwerkzeugen erfasst werden neigen dazu, nach mehr oder weniger kurzer Zeit sich von der Systemrealität zu entfernen.

Im Bereich der Programmierung hat man dieses Problem der sich von der Systemrealität entfernenden Dokumentation der Programmierschnittstelle (API) schon länger progressiv gelöst. Systemrealität, also der aktuelle Quellcode und Dokumentation sind nicht mehr getrennte Artefakte sondern eins. Benötigte Darlegungen in Form von Textdokumenten oder Hilfesystemen werden aus dem Quellcode automatisch generiert. Dazu müssen jedoch spezielle Statements in den Code als Kommentare eingepflegt werden. Diese speziellen Statements sind letztlich eine Generatorskript die den Dokumentationsgenerator anweisen wie die Dokumentation aussehen soll.

Dem gleichen Ansatz, dass Dokumentationen des Systems letztlich nur ein automatisch generierter Output aus der Systemrealität besser gesagt aus der Systemquelle sind soll hier gefolgt werden. Die Systemquelle ist das Modell. Die gewünschten Dokumentationen sollen aus dem Modell heraus automatisiert erstellt also generiert werden. Dazu nutzen wir den Dokumentationsgenerator in SiSy.

Dokumentationen die aus Modellen generiert werden orientieren sich zwar an klassisch erstellten Textdokumenten weisen jedoch einige Spezifika auf. Zur Vertiefung dieser Aspekte hier die Vertiefungen zu den in diesem Kurs angebotenem Dokumentationsumfang.

• Hinweis zur Nutzung des Dokumentationsgenerators
• Gliederungsvorschlag für eine modellbasierende System Requirements Specification, SRS
• Gliederungsvorschlag für modellbasierende Test Cases, TC
• Gliederungsvorschlag für eine modellbasierende Technische Systemdokumentation, TSD
• Gliederungsvorschlag für ein modellbasierendes User Manual , UM

In diesem Projekt werden wir die im Kurs erlernten Modellierungstechniken anwenden. Wir nutzen als das SysML Anwendungsfall- und das Aktivitätsdiagramm, das UML-Klassendiagramm und Klassenbibliotheken für den STM32. Dafür legen Sie ein neues SiSy-Projekt an. Führen die folgenden Arbeitsschritte durch:

1. SiSy starten,
2. Ein neues SiSy-Projekt anlegen und das Projektprofil Vorgehensmodellordner auswählen,
3. Aus dem LibStore eine Projektvorlage mit den „Referenzmodell Embedded Systems Engineering“ laden,

Führen Sie folgende Arbeitsschritte durch:

1. ergänzen Sie das Anwendungsfalldiagramm
2. vervollständigen Sie die Aktivitätsdiagramme mit den Anwenderszenarien
3. generieren Sie das Dokument System Requirements Specification SRS

Vergegenwärtigen wir uns anhand der SRS die Aufgabe nochmal. Diese besteht darin mit unserem Mikrocontroller:

• mit einer Suchspule ein Impulssignal zu erzeugen
• den Analogwert von einem Potentiometer mit dem Ausgangssignal des OPV zu vergleichen
• das Ergebnis über eine LED und einen Speaker zu signalisieren

Aus dieser Aufgabenstellung resultieren folgende Systembausteine für das Klassenmodell unserer Lösung

Die für die Lösung benötigten Bibliotheksbausteine sind bekannt. Wir können aus dieser Betrachtung einer ersten einfachen Lösung folgenden Grobentwurf ableiten:

Da es sich hier um ein etwas komplexeres Projekt handelt, sollte die Realisierung in mehreren Iterationen erfolgen. Jede Iteration ist die Ausgangsbasis für die nächste bis das beste Ergebnis im gegebenen Zeit-Budget erreicht ist.

• Realisierungschritt 1 Kalibrierungsfirmware
• Realisierungschritt 2 einfache Lösung mit ON/OFF LED
• Realisierungschritt 3 Lösung mit akustischem Näherungssignal
• Realisierungschritt 4 Lösung mit UART Testdaten
• Realisierungschritt 5 Lösung mit einstellbarem Arbeitspunkt
• Realisierungschritt 6 umfassende Lösung mit 1-5

• Testszenarien erstellen
• Test
• …

• TSD erstellen
• UM erstellen
• …

…

• den nächsten Abschnitt
• zurück zur Übersicht