Unser WLAN Funkmodul für Messuhren und andere Handmessmittel wie Bügelmessschraube oder Messschieber kann mit dem Funkmodul M8 für Verbindungen über WebSockets verwendet werden. Meist werden unsere Datenübertragungsmodule im MQTT Modus eingesetzt. Es gibt jedoch Anwendungsfälle, in denen eine Verbindung über Websockets zweckmäßiger ist. Z.B. wenn aus einer Web-Anwendung oder einem Web-Browser heraus direkt auf ein einzelnes Messgerät zugegriffen werden soll.

Dieses Praxisbeispiel soll zeigen, wie eine WebSocket-Verbindung zum Messgerät hergestellt werden kann.

Das Beispiel besteht aus einer einfachen Webseite / Webanwendung in HTML und Javascript. Über diese einfachen Techniken ist es möglich, direkt auf das Funkmodul zuzugreifen und den aktuellen Messwert sowie Statusinformationen aus der Funk-Messuhr auszulesen. Dies ist im Vergleich zu MQTT ohne zusätzliche Infrastruktur eines Brokers möglich und somit vor allem für kleine, lokale Anwendungen eventuell einfacher umzusetzen als eine MQTT Abfrage.

Web-Oberfläche der Beispielanwendung

Der Quelltext der einfachen Anwendung:

<!DOCTYPE HTML>
<html>
<head>
  <meta name="websocket_test">
  <meta charset="UTF-8"/>
  <style>button{width:140px;height:50px}body{background: #f48f0d;}</style>
  <style>table, th, td { border-collapse: collapse;}</style>
<title>websocket to iot test</title>
</head>
<body style="font-family: arial, sans-serif;">
    <div style="width:500px;border:1px solid black;align:left">
        <form onsubmit="return false">
            Client name (informal): <input type="text" id="txtName" value="Client_1"><br>
            Server: <input type="text" id="txtServer" value="192.168.1.119">
        </form>
        <form onsubmit="return false">
            <button type="submit" id="btnConnect">Connect to IoT device</button>
            <input type="checkbox" id="cbxSsl" name="ssl" checked>
            <label for="cbxSsl">SSL</label>
            <input type="checkbox" id="cbxRaw" name="raw" checked>
            <label for="cbxRaw">Raw</label>
        </form>
        <form onsubmit="return false">
            <button type="submit" id="btnConfigSet" disabled>Set configuration</button>
        </form>
        <form onsubmit="return false">
        <table>
        <tr><td>
            <button type="submit" id="btnRequestMeas" disabled>Request measurements</button>
            </td><td>
            Repeat count:<input style="width:80px;" size="3" type="number" id="txtRepCnt" value="3"><br>
            Interval:<input style="width:80px;" size="6" type="number" id="txtRepMs" value="200">
            </td>
        </tr></table>
        </form>
        <form onsubmit="return false">
            <button type="submit" id="btnRequestMeta" disabled>Request device info</button>
        </form>
        <!-- output form -->
        <form onsubmit="return false">
            <div style="overflow:scroll;height:400px;word-break:break-all" id="divOut">Not connected...</div>
        </form>
        <!-- clear -->
        <form onsubmit="return false">
            <button type="submit" id="btnClear">Clear</button>
        </form>
    </div>
    <script type="text/javascript">
        const elem = id => document.getElementById(id);
        const txtName = elem("txtName");
        const txtServer = elem("txtServer");
        const txtRepCnt = elem("txtRepCnt");
        const txtRepMs = elem("txtRepMs");
        const btnConnect = elem("btnConnect");
        const cbxSsl = elem("cbxSsl");
        const cbxRaw = elem("cbxRaw");
        const btnConfigSet = elem("btnConfigSet");
        const btnRequestMeas = elem("btnRequestMeas");
        const btnRequestMeta = elem("btnRequestMeta");
        const btnClear = elem("btnClear");
        const divOut = elem("divOut");

        class Mdevice {
            constructor() {
                this.connecting = false;
                this.connected = false;
                this.name = "";
                this.ws = null;
            }
            connect() {
                if (this.ws === null) {
                    this.connecting = true;
                    txtName.disabled = true;
                    this.name = txtName.value;
                    btnConnect.innerHTML = "Connecting...<br>"+txtServer.value+"<br>ssl "+
                      cbxSsl.value+": "+(cbxSsl.checked?"on":"off");
                    this.ws = new WebSocket("ws"+(cbxSsl.checked?"s":"")+"://"+txtServer.value+"/"+(cbxRaw.checked?"raw1":"dev1"));
//                    this.ws = new WebSocket("wss://192.168.1.119/dev1");
                    this.ws.onopen = e => {
                        this.connecting = false;
                        this.connected = true;
                        divOut.innerHTML += "<br><p>Connected.</p>";
                        btnConnect.innerHTML = "Disconnect";
                        btnConfigSet.disabled=false;
                        btnRequestMeas.disabled=false;
                        btnRequestMeta.disabled=false;
                        // optional: send something through the websocket 
                        // this.ws.send(this.name + " connected!");
                    };
                    this.ws.onmessage = e => {
                        divOut.innerHTML+="<p>"+e.data+"</p>";
                        divOut.scrollTo(0,divOut.scrollHeight);
                    }
                    this.ws.onclose = e => {
                        this.disconnect();
                    }
                }
            }
            disconnect() {
                if (this.ws !== null) {
                    // optional: send something through the websocket 
                    // this.ws.send(this.name + " disconnect!");
                    this.ws.close();
                    this.ws = null;
                }
                if (this.connected) {
                    this.connected = false;
                    btnConfigSet.disabled=true;
                    btnRequestMeas.disabled=true;
                    btnRequestMeta.disabled=true;
                    txtName.disabled = false;
                    divOut.innerHTML+="<p>Disconnected.</p>";
                    btnConnect.innerHTML = "Connect";
                }
            }
            sendMessage(msg) {
                if (this.ws !== null) {
                    this.ws.send(msg);
                }
            }
        };
        let mdevice = new Mdevice();
        btnClear.onclick = () => {
            divOut.innerHTML ="";
        }
        btnConnect.onclick = () => {
            if (mdevice.connected) {
                mdevice.disconnect();
            } else if (!mdevice.connected && !mdevice.connecting) {
                mdevice.connect();
            }
        }
        btnConfigSet.onclick = () => {
            mdevice.sendMessage("{\"cmd\":\"config\",\"sleep_sec\":13698,\"display_text\":\"MESSAGE\"}");
            divOut.focus();
        }
        btnRequestMeas.onclick = () => {
            if (cbxRaw.checked) {
               mdevice.sendMessage("meas"); // -- opt: csv instead json
            } else {
              mdevice.sendMessage("{\"client\":\""+this.name+"\",\"cmd\":\"meas\",\"rep_cnt\":"+
                txtRepCnt.value+",\"rep_ms\":"+txtRepMs.value+"}");
            }
            divOut.focus();
        }
        btnRequestMeta.onclick = () => {
            // mdevice.sendMessage("1|info|*");
            mdevice.sendMessage("{\"client\":\""+this.name+"\",\"cmd\":\"info\"}");
            divOut.focus();
        }
    </script>
</body>
</html>

Der Quellcode dieses Programmbeispiels kann hier heruntergeladen werden. Dieser Quelltext kann gerne frei verwendet werden (Freeware, OpenSource, Public domain) – allerdings übernehmen wir keine Haftung für die Fehlerfreiheit des Quellcodes oder der Software.

Wir mussten schon erfahren, dass unsere IoT Funkmodule von Interessenten begeistert begutachtet werden – dann aber im Unternehmen nicht eingesetzt werden dürfen, da die lokale IT nur (noch) WLAN mit 5GHz (IEEE 802.11ac) zulässt.

Dies ist ein K.O. Kriterium nicht nur für unsere Module, sondern für die gesamte Digitalisierung im Unternehmen. Entsprechend ist es eine falsche Entscheidung.
Denn: Entweder es wird ein WLAN im 2.4 GHz Bereich betrieben oder es wird nichts mit Industrie 4.0 und IIoT.

Warum diese drastische Einschätzung?

Ganz einfach: Es gibt aktuell noch keine integrierte MCU / SoC mit WLAN auf dem Markt welche 5GHz bedienen kann (Stand August 2021).

Es gibt einige reine Funkmodule mit 5GHz, diese benötigen jedoch eine externe CPU um angesteuert zu werden.
Diese Module sind als Funkmodule in Notebooks und Smartphones vorgesehen, nicht jedoch für den Einbau in kleinste Sensoren für die Messtechnik.
Für einen Betrieb als per Akku betriebene IoT Device sind diese Module nicht nur nicht geeignet sondern praktisch einfach nicht möglich.

Nun könnte man sagen, dass die Hersteller von Modulen vielleicht ja die nächsten Jahre ein 5GHz IoT Modul auf den Markt bringen.
Dies könnte sein. Eventuell werden in einem Zeitraum von 2-5 Jahren sogar mehrere solcher Module erscheinen.
Dies eröffnet das nächste Problem: Soll man gleich auf das erste Modul setzen? Oder kommt in einem halben Jahr vielleicht ein viel besseres?
Und wenn ein besseres kommt: Wie schnell wird das Alte abgekündigt?
Und kommen dann vielleicht die ersten OFDM 5G Module?
Wir haben nun ein „Frosch im heissen Wasser“ Problem.
Es wird nicht möglich sein, den richtigen Moment zum Springen zu finden.
Selbst wenn dann das nächste „perfekte“ Funk-Modul auf den Markt kommt wird es einige Jahre dauern bis die wichtigsten Softwarebibliotheken auf dieses Modul portiert sind und stabil funktionieren. Das Warten auf die 5GHz Technik im IoT Bereich bedeutet also auf jeden Fall ein langes Warten. Dieses Warten ist dabei noch von vielen Unsicherheitsfaktoren umgeben. Es geht bei der Digitalisierung in der Fertigung nicht darum zu warten bis das perfekte System zu 100% verfügbar ist. Es geht viel mehr darum, zu beginnen. Diese Dinge zu digitalisieren die den größten Nutzen in Bezug auf Qualität und Effizienz bieten. In diesem Prozess ist der einzige richtige Moment „jetzt“. Mit den maximalen Möglichkeiten die der Markt zum Zeitpunkt „jetzt“ bietet. In der Form, dass der Prozess gestartet und stetig optimiert und fortgeführt wird.

Ein weiterer Aspekt ist die Sicherheit der Module.
Die kleinen IoT Devices unterstützen „nur“ WPA2/PSK als Basis-Authentifizierung.
Ein aktives Zertifikatshandling kann keines der bekannten MCU Devices.
Auch auf diesem Gebiet muss die Unternehmens-IT also umdenken:
Für die IoT Devices muss eine geeignete Infrastruktur bereitgestellt werden, wenn der Weg in die Digitalisierung in den nächsten Jahren gemeistert werden soll.

Zusammenfassend kann man also sagen:

  • Entweder Papier und ablesen (Stand 19. Jahrhundert),
  • Kabel- oder Bluetooth-Lösung (Stand 20. Jahrhundert und nicht besonders praktikabel),
  • oder eben WLAN mit 2.4GHz Funktechnik (Stand heute).

Die 2.4 GHz Technik ist etabliert, jeder vernünftige Router kann neben 5 GHz auch noch 2.4 GHz.
Hier ein eigenes IoT-WLAN mit einem entsprechenden Gateway zu betreiben kann kein wirkliches Problem darstellen. Im Gegenteil: Ein reines 2.4 GHz WLAN für Messtechnik und Prozesstechnik und ein separates WLAN für Office, ERP und MES sollte in Bezug auf Eigenständigkeit und Übersichtlichkeit eher ein Vorteil darstellen.

Die 2.4GHz Funktechnik wird noch viele Jahre bestehen und ermöglicht Industrie 4.0 jetzt.
Die Alternative bedeutet bestimmt 5-10 Jahre warten – und sich nicht sicher sein, was dann eben kommt.
Diese Zeit hat kein Unternehmen.

Eine geeignetes Sicherheitskonzept für das Netzwerkes mit seinen Teilnehmern bereitzustellen ist eine Herausforderung. Diese Herausforderung kann aber geleistet werden und ist unabhängig von der verwendeten Sendefrequenz der Module.

Aktuell ist es schlicht die Aufgabe der Unternehmens-IT für IIoT mindestens ein 2.4 GHz WLAN Netzwerk mit einfacher WPA2/PSK bereitzustellen.

Sobald ein Bauteil verfügbar ist welches die geforderte Leistung bei 5 GHz bereitstellt werden wir unsere Module natürlich auch gerne auf dieser Technik anpassen und liefern.

Anhang:

Marktübersicht vorhandener WIFI Module:

  • texas instruments (ti) mit CC3200
  • microchip mit SAMW25
  • espressiv mit ESP32/ESP8266

Alle diese Module arbeiten ausschließlich mit 2.4GHz. Viel mehr gibt es leider nicht.
Auch OEM Module wie z.B. das „Würth Calypso WIFI module“ haben einen der oben genannten Chips verbaut.

Mitutoyo Messschieber und Bügelmessschrauben besitzen mit der Digimatic-Schnittstelle eine einfache Möglichkeit die gemessenen Daten digital weiter zu verarbeiten. An das Digimatic-Interface lassen sich über ein Kabel die Daten auslesen und z.B. an einen PC oder Prozessrechner übertragen. Auch unsere WLAN-Funkmodule für Mitutoyo Messgeräte werden über die Digimatic-Steckbuchse an den Messschieber oder die Messuhr angeschlossen. In diesem Artikel soll es um die neuen und besonderen Digimatic-Buchsen der Handmessmittel gehen welche eine höhere Schutzart (IP67) besitzen und hierbei einen besonderen Anschluss für das Digimatic-Kabel besitzen.

Die normale, klassische Digimatic-Schnittstelle besteht meist einfach aus 5 Kontaktflächen auf der Elektronik-Platine des Messmittels. Der Stecker mit seinen Goldkontaktflächen stellt dann die elektrische Verbindung zur Schnittstelle her.

caliper-digimatic-view
Blick auf die klassische Digimatic-Schnittstelle an einem Mitutoyo Messschieber

Etwas anders sieht es beim Digimatic-Anschluss für Handmessmittel mit IP67 Schutzart aus. Auf den ersten Blick sieht es ganz so aus, als ob es schlicht überhaupt keine Kontaktflächen oder nur eine einzige Kontaktfläche gibt. Der Stecker – welcher sich auch vom normalen Digimatic-Stecker unterscheidet – weist dagegen auch 5 Kontaktflächen an der Stirnseite auf.

Blick auf die Digimatic Schnittstelle mit Schutzart IP67
Blick auf die Digimatic Schnittstelle mit Schutzart IP67
Digimatic Schnittstelle in Schutzart IP67 an einer Mitutoyo Bügelmessschraube
Digimatic Schnittstelle in Schutzart IP67 an einer Mitutoyo Bügelmessschraube

Aufschluss über die Funktionsweise der Steckverbindung gibt die Analyse der Kontaktfläche unter einem Mikroskop: Die vermeintlich durchgängige Kontaktfläche besteht aus sehr vielen sehr dünnen Drahtbahnen.
Die einzelnen Drähte haben hierbei eine Stärke von ca. 0,05 mm.

Digimatic Kontaktfläche in großer Vergrößerung
Digimatic Kontaktfläche in großer Vergrößerung

Diese dünnen Drahtbahnen stellen die Verbindung zu dem Digimatic-Stecker her. Hierbeit wird keine 1:1 Verbindung hergestellt sondern der Stecker trifft auf einige Gegenkontakte. Diese geben das elektrische Signal dann an die Mitutoyo Platine weiter.

Die Digimatic-Stecker im Vergleich. Links der Standardstecker. Rechts der Stecker für Digimatic-IP67

Auch die Stecker für die IP67 Schutzart-Variante unterscheiden sich. Der Standardstecker hat seine Kontaktfläche oben. Die IP67 Variante hat eine durchgängige Kontaktfläche. Verwendet zur Kontaktherstellung wird jedoch nur die Vorderseite/Stirnseite des Steckers. Diese Fläche liegt auf dem Kontaktpad auf. Zusätzlich wird der Stecker mit hoher Schutzart verschraubt. Dies ist auch notwendig damit der Stecker fest auf die Dichtung drückt. Die Buchse selbst besitzt keine hohe Schutzart.

mitutoyo-buegelmessschraube-offen
Geöffnete Mitutoyo Bügelmessschraube

Ein vollständiges Bild der Situation vermittelt eine Messuhr mit geöffnetem Deckel. Das Goldkontakt-Element wird einfach in die Aussparung der Kunststoffbuchse geschoben und stellt dann eine Brücke zwischen dem Digimatic-Stecker auf der einen und der Platine auf der anderen Seite her. Beim Einstecken wird das Kontaktpad etwas zusammengedrückt – so dass es hoffentlich einen guten Kontakt zwischen Stecker auf der einen Seite und der Platine auf der anderen Seite herstellt.

Mitutoyo wird sich bei dieser Konstruktion etwas gedacht haben. Nur: Wir wissen nicht was. Die Schutzklasse wird lediglich durch die Gummidichtung ganz außen hergestellt (auf dem Bild ganz oben gut zu sehen, auf dem Bild mit der geöffneten Messschraube entfernt). Anstatt einem Kontaktübergang haben wir es nun mit 2 Kontaktübergängen zu tun. Weiter sind die Abstände zwischen den Kontaktbahnen sehr klein (ca. 50μm): Kleinste Fremdkörper wie metallische Späne oder auch Flüssigkeiten würden die Kontaktfähigkeit mit hoher Wahrscheinlichkeit beeinträchtigen oder eine Brücke zwischen 2 Signalleitungen herstellen. Insgesamt halten wir diese Konstruktion also – milde gesagt – für sehr gewagt. Vielleicht ist sie einfach nur einfach, schnell und preisgünstig umzusetzen.

Als Alternative bieten wir daher an die Datenkabel unsere Funkmodule fest mit der Bügelmessschraube zu verbinden: Das Kontaktpad kann einfach entnommen werden, dafür wird das Kabel direkt vom WLAN-Funkmodul durch die Kunststoffdurchführung gelegt und fest mit der Platine der Bügelmessschraube verlötet. Eine Verbindung die zuverlässig über Jahre hält und dauerhaft stabile Messergebnisse liefert.

Aufgabenstellung

Eine klassische Messvorrichtung soll die gemessenen Daten per Funk an ein verarbeitendes System übertragen. Die Vorrichtung wurde durch den Vorrichtungsbau bereits erstellt und ist bereits mit präzisen Mitutoyo Messuhren ausgestattet. Die Prüfvorrichtung soll Mobil eingesetzt werden. Es ist daher eine kabellose Lösung mit unabhängiger Stromversorgung erforderlich.

Durch die automatische Übertragung per Funk sollen Ablesefehler vermieden werden. Eine Übertragung mit Bluetooth oder anderen gängigen Funkprotokollen von Funkmessuhren ist nicht sinnvoll da die Vorrichtung an unterschiedlichen Stellen im Betrieb eingesetzt werden soll. Eine Kopplung der Funkmodule mit einem Rechner vor jeder Messung ist zudem zu aufwändig und generell problematisch.

Die Messungen sollen Ferngesteuert aus der Ferne ausgelöst werden.

Die Messung mit den Messuhren soll praktisch zeitsynchron in einem sehr engen Zeitfenster (wenige Millisekunden) durchgeführt werden.

Lösung der Aufgabe

Die vorhandenen Messuhren werden mit rAAAreware Funkmodulen M4 ausgestattet. Die Module können einfach auf der Rückseite der Messuhren montiert werden. Auf die Module wird ein leistungsstarker Lithium-Ionen Akku aufgeschoben. Dieser ermöglicht einen langen unabhängigen und kabellosen Betrieb der Funkmodule auf der Vorrichtung. Ein notwendiger baldiger Akkuwechsel wird rechtzeitig sowohl vom Modul als auch über MQTT angezeigt.

Messvorrichtung mit 6 Messuhren welche mit WLAN-Funkmodulen ausgestattet sind.
Ansicht der Messvorrichtung mit 6 Messuhren und den WLAN-Funkmodulen
(Modell M4 mit Akku)

Die WLAN Messuhr-Module werden über das offene und frei verfügbare MQTT Protokoll angesteuert. Somit kann über einen Leitrechner oder einen anderen MQTT Client eine Messung ferngesteuert getriggert werden. Die Ergebnisse werden dann direkt vom MQTT Broker übernommen und können direkt weiterverarbeitet werden. Als Bedienung an der Messvorrichtung ist nur das Einschalten der Messuhren und das Einschalten der Funkmodule über einen Schiebeschalter erforderlich.

Durch die gleichzeitige Messung und Übertragung der Messergebnisse wird ein Qualitätsgewinn und eine Zeitersparnis bei der Durchführung der Messaufgabe erreicht. Die Gesamtmessung ist in sehr kurzer Zeit bei minimaler Fehlermöglichkeit durchführbar.

Alternative Lösungsansätze

Ein alternativer Lösungsansatz ist über eine zentrale Stromversorgung der Funkmodule realisierbar. Wenn z.B. der Platz hinter den Messuhren nicht für das Funkmodul ausreicht können diese an anderer Stelle der Messvorrichtung angebracht werden. Die Verbindung zur Messuhr erfolgt dann nur über das Digimatic Kabel. Die extern auf der Vorrichtung angebrachten Module können dann über einen zentralen Ein-/Ausschalter mit einer zentralen Stromversorgung verbunden werden. Diese zentrale Energieversorgung kann dann ein industrielles Akku-Pack sein oder auch eine gewöhnliche 5V Powerbank. Durch die zentrale Spannungsversorgung der Module wird die Bedienung weiter vereinfacht, da alle Messuhren gleichzeitig und zentral ein- und ausgeschaltet werden können.

Dieser Ansatz wurde bereits bei anderen Prüfvorrichtungen erfolgreich umgesetzt. Auch andere Messuhren oder auch andere Messgeräte sind so über ein serielles Kabel an ein extern montiertes Funkmodul anbindbar.

Kontaktieren Sie uns wenn Sie weitere Informationen zu dieser Aufgabenstellung aus dem Bereich der Längenmesstechnik wünschen.

Wir stellen hier eine Übersicht der aktuell verfügbaren und uns bekannten Funk-Messschieber dar.

Funk Messchieber

Hersteller / VertriebProduktbezeichnungModul oder IntegriertFunktechnologieStromversorgungEmpfängerMessbereich, Messgenauigkeit (Ziffernschritt)InfosPreis
rAAArewareM5ModulWLAN
(WiFi, MQTT)
LiIon / LiPo Akkukein spezieller Empfänger notwendig0 - 600 mm; 0,01mm - abhängig vom MessschieberGeeignet für die meisten Mitutoyo Messschieber und Tiefenmesser.
Auch Modelle für Mahr oder RS232 verfügbar.
240 Euro
Hoffmann-GruppeDigitaler Messschieber HCT IP67 mit Bluetooth, GARANT Art.-Nr.: 412780IntegriertBluetooth 4.2Batterie CR2032kein spezieller Empfänger notwendig0 - 150 mm; 0,01 mm224 Euro
MahrMahr 16 EWRi-VIntegriertAnt+ / ProprietärBatterie CR2032enthalten0 - 200 mm; 0,01 mmauch Ausführungen mit deutlich höherem Messbereich verfügbar.220 Euro
Helios-PreisserDIGI-MET® Taschenmessschieber IP67 mit integriertem FunkIntegriertBatterie CR2032enthalten220 Euro
IBRISM-mit1ModulZigbee? / ProprietärBatterieseparat erhältlichfür Mitutoyo (Digimatic)auch Modelle für Mahr oder RS232 verfügbar80 Euro
MitutoyoU-WAVEModulAnt+? / 2,4 GHz / ProprietärBatterie CR2032separat erhältlichbenötigt eigenen Empfänger140 Euro
TESATesa TLCModulAnt+? / ProprietärBatterie CR2032separat erhältlichpassend für TESA TWIN Messschieber165 Euro
SylvacS_Cal EVO SMART - 8101516IntegriertBluetoothBatterie CR2032kein spezieller Empfänger notwendig0 - 150 mm220 Euro
MIB Messzeuge

(Importeur)
Digital-Messschieber inklusive Bluetooth induktives MesssystemIntegriertBluetooth 4Batterie 3Vkein spezieller Empfänger notwendig0 - 150 mm220 Euro
MIB Messzeuge

(Importeur)
MIB Bluetooth DatensenderModulBluetoothBatterie 3Vkein spezieller Empfänger notwendig120 Euro
Messschieber mit Funk-Funktion (Bluetooth, WLAN, Zigbee, Ant+) oder Funk-Module für Messschieber

Auch wenn wir (noch) ein kleiner Hersteller sind brauchen wir uns nicht verstecken und lassen uns gerne mit den „Großen“ der Messtechnik-Branche in dieser Marktübersicht vergleichen. Der Produktvergleich der Messschieber zeigt: Die einzigen die echtes IIoT, MQTT und WLAN beherrschen sind wir. Die anderen können immerhin Bluetooth für kurze Distanzen oder etwas längere Distanzen mit proprietären Protokollen und separat erhältlichen Empfängern.

Ein weiteres Alleinstellungsmerkmal unserer Module ist, dass wir keine Einwegbatterien verwenden sondern Lithium-Ionen oder Lithium-Polymer-Akkus verwenden. Mit der mitgelieferten Ladeschale kann der Messschieber kontinuierlich geladen werden und ist immer Einsatzbereit. Leere Batterien gibt es hier nicht.

Dieser Artikel wurde im Dezember 2020 erstellt nachdem im „Industrial Outlook“ der Vogel-Mediengruppe ein Bluetooth Messschieber der Fa. Garant vorgestellt wurde. Es verwunderte uns, dass dies als eine Neuheit vorgestellt wurde – wo wir doch seit über 2 Jahren „echte“ WLAN Messmodule fertigen. Und überhaupt: Bluetooth ist nun wirklich nichts Neues mehr.

Wir haben diese Tabelle und den Vergleich nach bestem Wissen und Gewissen erstellt. Trotzdem gilt: Alle Angaben sind ohne Gewähr. Informieren Sie sich bei Fragen bei uns oder bei den anderen Herstellern der Messmittel. Einige genannte Marken oder Bezeichnungen sind vermutlich eingetragene Marken der Hersteller. Wir besitzen hier keine Markenrechte und verwenden die Namen unter Respektierung der Markenrechte der Eigentümer.

Einleitung und Übersicht

Eine MQTT Infrastruktur für industrielle Anwendungen zu betreiben ist genauso wie MQTT an und für sich: Einfach und flexibel. Trotzdem ist es wie für alle Vorhaben empfehlenswert einige Vorüberlegungen anzustellen und zu entsprechend zu planen. Dies verhindert, dass die erstellte Infrastruktur direkt nach der Fertigstellung angepasst werden muss. Weiter ist es notwendig, angrenzende Bereiche vor allem aus dem Bereich der Netzwerkinfrastruktur in die Überlegungen und Entscheidungen mit einfließen zu lassen.

Grundsätzlich lässt eine MQTT Infrastruktur in 3 Teile unterteilen: Die Sensoren oder Aktoren (IoT Devices) als primäre Datenlieferanten, den MQTT Broker als Vermittler der Daten und das Backend als primärer Abonnent der Daten. Dies ist eine logische Aufteilung. MQTT-Technisch gibt es Publisher (= Datenlieferanten) und Subscriber (=Datenabonnenten) – doch jeder Publisher kann auch selbst Daten beziehen und jeder Subscriber kann auch Daten senden (und macht dies normalerweise auch). Trotzdem ist es eher so, dass im Datenbackend eher mehr Subscriber von Nutzdaten sitzen und die Devices als Sensoren und Aktoren die primären Datenlieferanten des Systems sind.

Das Bindeglied zwischen den 3 Komponenten des Systems ist das Netzwerk. Bei einer MQTT Infrastruktur geht es also um klassische TCP/IP Netzwerktechnik.

Eine MQTT Device ist normalerweise über WLAN an das Netzwerk angebunden. Wir haben in unserer Netzwerkinfrastruktur also ein WLAN Netzwerk integriert.

Lokale Infrastruktur

In dieser einfachen Infrastruktur befindet sich alles in einem einzigen Netzwerk (LAN, Local area network). Es kommt keine spezielle industrielle Hardware zum Einsatz. Vielmehr dient ein einfacher Accesspoint als Zugangspunkt zum Netzwerk mit MQTT Broker und Backend.

Einfache MQTT Client / MQTT Broker Infrastruktur

Der MQTT Broker kann hierbei auf irgendeinem Rechner des Netzwerks laufen. Möglich ist es sogar, sowohl Broker als auch Accesspoint auf einem einzigen Android Endgerät zu betreiben. Somit besteht die gesamte Infrastruktur z.B. nur aus der IoT Device und einem Tablet. Dieser Spezialfall einer minimalen MQTT Architektur ist in unserem Artikel MQTT Broker auf Android beschrieben.

Gateway als MQTT Broker

Eine fast genauso einfache Infrastruktur setzt einen MQTT Broker als Gateway zwischen 2 LAN Netzwerken ein. Dieser Broker kann als proprietäres System oder als Linux System umgesetzt sein.

MQTT Infrastuktur mit Gateway zwischen Produktionsnetzwerk und Firmennetzwerk.

Firmen wie die Wiesemann & Theis GmbH (www.wut.de) bieten einen einfachen MQTT Broker als fertige Komponente an. Alternativ kann ein kleiner Linux Rechner wie z.B. ein Raspberry Pi Rechner als MQTT Broker eingesetzt werden. Die erste Option bietet eventuell einen etwas leichteren Einstieg in die Konfiguration, da diese komplett über eine WEB Oberfläche vorgenommen werden kann.
Der Raspberry Computer bietet dagegen eine maximale Flexibilität durch ein komplett offenes und frei konfigurierbares System welches mit Sicherheit über viele Jahre gepflegt und weiterentwickelt wird.
Mit dem von uns entwickelten und angeboten Raspberry Industrierechner können wir ein System liefern welches eine sehr einfache Konfiguration ermöglicht und trotzdem die maximale Flexibilität eines quelloffenen und freien Linux Systems bietet.

MQTT Broker im WAN Netzwerk

Eine für nicht-industrielle Anwendungen häufig umgesetzte Konfiguration ist die Verwendung des MQTT Brokers als Service in einer Cloud, also auf einem entfernten Rechner in einem WAN (wide area network; Internet).
Dies vereinfacht die Gesamtkonfiguration und den Betrieb etwas, da ein MQTT Broker eben überhaupt gar nicht erst installiert und konfiguriert werden muss. Dies ist natürlich auch für Industrielle Anwendungen denkbar.

MQTT Infrastruktur mit einem MQTT Broker in der Cloud

Meist kommt diese Konfiguration aus mindestens 2 Gründen nicht zum Einsatz:

Erstens ist die Grundanforderung der Unabhängigkeit einer Industrieanlage nicht gewährleistet. Sollte der externe Dienst des MQTT Brokers aus irgendeinem Grund nicht mehr erreichbar sein ist eine Produktion im schlimmsten Fall nicht mehr oder nur noch deutlich eingeschränkt möglich.

Ein zweiter Grund ist, dass Daten der Anlage außerhalb des lokalen Netzwerkes oder Firmennetzwerkes gespeichert werden. Zwar können die Datenverbindungen und Übertragungen unter MQTT z.B. Passwort oder über eine TLS/SSL Verschlüsselung geschützt werden, ein Risiko zur Einsicht oder Manipulation der Daten auf dem Server selbst bleibt jedoch bestehen.

Wenn man bedenkt, wie einfach ein MQTT Server installiert, administriert und betrieben werden kann ist es empfehlenswert den MQTT Server in einem lokalen Firmen-LAN zu betreiben.

Ergänzung

Ergänzung: Gleichzeitiges Messen mehrerer Messuhren

Bei verschiedenen Szenarien ist es oft eine Anforderung, mehrere Messungen gleichzeitig zu erfassen.

Wirklich Gleichzeitig in einem einzelnen WLAN Netzwerk zu messen ist nicht möglich, da die Datenpakete hintereinander über das Netzwerk übertragen werden. Die Übertragungszeiten sind jedoch kurz. Aus der Praxis können wir diese Werte angeben:

Der Datendurchlauf des Anfordern und Empfangen eines Messwertes dauert ca. 50 ms. Dies bedeutet, dass der PC einen Messwert über den Broker anfordert, der Broker die Anforderung an die Messuhr weitergibt, die Messuhr die Messung durchführt und die Messdaten an den Broker überträgt. Diese gibt die Daten dann an den PC weiter.

Funkstandards bei IoT / IIoT Technologien für Industrie 4.0

Bei der Anbindung von Messmitteln an eine IIoT Industrie 4.0 Infrastruktur stellt sich immer wieder die Frage, auf welchen Funkstandard oder Funktechnologie man setzen kann, soll, muss oder darf. Inzwischen bewerben sich viele verschiedene Protokolle und/oder Standards wie WLAN / Wi-FI, Bluetooth, Ant+ oder ZigBee um den Einsatz in der Fabrikhalle oder Fertigung. Hersteller entscheiden sich für einen dieser Standards oder verwenden einen ganz eigenen – wie das U-Wave von Mitutoyo – obwohl auch diese Ansätze dann wieder auf Standards wie IEEE 802.15.4 aufsetzen.

Wenn ein Unternehmen IIoT in der Produktion umsetzen will kommt es nicht umher sich mit diesen Funkstandards auseinander zu setzen. Wer dies nicht tut endet in einem Chaos von Systemen und eventuell instabilen oder sich gegenseitig beeinflussenden Funksystemen. Gleichzeitig hilf es nicht weiter überhaupt nichts zu tun oder sich einfach stoisch für ein System zu entscheiden. Im 2. Fall wird man festzustellen, dass viele gewünschte Dinge dann einfach nicht umsetzbar sind. Es gilt die beste Lösung zu finden und auch Kompromisse zu machen um die Herausforderungen der IoT in der Automatisierungstechnik erfolgreich umzusetzen.

Mit einem Vergleich und einer Gegenüberstellung der verschiedenen Funksysteme mit industrieller Eignung versuchen wir etwas Licht in dieses Thema zu bringen.

Wir sind ein Hersteller von WLAN-Modulen für die Messtechnik und sicherlich keine wissenschaftlichen Nachrichtentechniker. Aber gerade dies ermöglicht uns einen praxisorientierten Blick auf die Thematik welchen wir durch unsere langjährige Erfahrung in der Zusammenarbeit mit unseren Industriekunden verfestigen konnten.

Sie können unseren Artikel zu Funkstandards bei IoT / IIoT Technologien für Industrie 4.0 hier lesen oder downloaden.

Marktübersicht verfügbare Funk-Messmittel

In unserer Marktübersicht zu Messschiebern mit Funkmodulen bekommen Sie einen Überblick was andere Hersteller zum Thema Funktechnik für Handmessmittel zu bieten haben.

Rechtliches

Einige Namen in diesem Text können Urheberrechtlich geschützt sein.
Bluetooth ist eine eingetragene Marke der Bluetooth SIG, Inc.
ANT+ ist ein eingetragene Marke der ANT Alliance bzw. Garmin.
Zigbee ist eine eingetragene Marke der Zigbee Alliance, USA.
Wi-Fi ist eine eingetragene Marke der Wi-Fi Alliance.
Wir weisen darauf hin, dass wir keine Rechte an diesen Namen haben oder beanspruchen, diese Namen nur redaktionell zur Erklärung verwenden und keine Verbindung zu den Firmen mit den Namensrechten haben.

Installation und Betrieb eines MQTT Brokers (MQTT Server) auf dem Android Betriebssystem

Einleitung

Die Kommunikation bei MQTT wir über einen zentralen Server abgewickelt.
Dieser Server steht normalerweise im „Backend“: Über eine Adresse ist er bekannt – alles weitere interessiert den MQTT Anwender dann nicht mehr. In der Praxis läuft dieser Server (MQTT Broker genannt) dann entweder in der Cloud – also einem entfernten Dienst eines Dienstleisters oder auf einem eigenen Server. Der eigene Server kann dann etwas Großes oder Kleines sein. Etwas großes wäre der dicke Server im Keller. Etwas kleines wäre z.B. ein Raspberry Pi welcher mit Open-Software ausgestattet z.B. lokal in einer Fertigungsanlage oder in der Linie positioniert ist.

Eine Übersicht über solche klassische MQTT Infrastruktur-Szenarien haben wir Im Artikel „Möglichkeiten einer IoT MQTT Infrastruktur zusammengestellt.

Es ist jeweils für den aktuellen Anwendungsfall zu entscheiden was das zweckmäßigste ist.
Normal ist jedoch, dass viele MQTT Devices über diesen Server kommunizieren und ihre Daten bereitstellen, abrufen und austauschen.

Nun kommen wir zum nicht normalen Fall: Es gibt Anwendungsfälle, in welchen schlicht kein klassischer Server gewünscht ist. Zum Beispiel soll eine lokale IoT Device Messwerte an ein Smartphone oder Tablet liefern die dort dann angezeigt und gespeichert werden. Dies ist die für MQTT einfachste Konfiguration. In der vor Industrie 4.0 Zeit hätte hier dann vielleicht auch anstatt einem IoT Device auch nur ein Gerät mit Bluetooth oder Zigbee Verwendung gefunden.

Der Einsatz von MQTT bietet jedoch auch in diesem einfachen Anwendungsfall einige Vorteile:

  • deutlich stabilere Funkverbindung und höhere Reichweite (100-300m statt 3-10m!).
  • keine umständliche Kopplung bei Gerätewechel notwendig.
  • einheitliche Weiterverarbeitung der Daten über den offenen MQTT Standard.

Für uns als MQTT Messgerätehersteller (WLAN Handmessmittel) stellte sich für dieses Szenario die Aufgabe einen MQTT Broker auf einem Android Betriebssystem zu betreiben. Dieser Fachartikel beschreibt die Analyse der Möglichkeiten und zeigt eine einfache Lösung des Problems. Die Lösung besteht darin, einen quelloffenen und verbreiteten Linux MQTT Broker auf einem Android Device zu betreiben. Dieser Broker kann dann direkt auf dem Smartphone oder Tablet von einer lokalen Anwendung angesprochen werden um die Messwerte zu verarbeiten.

Vorhandene MQTT Broker

Eine Liste der wesentlichen MQTT Broker-Implementationen ist auf Github zu finden.

Es ist nicht weiter verwunderlich, dass hier kein Broker für Android zu finden ist, da Android ein Client-Betriebssystem ist – und ein MQTT Broker eben eine Server Anwendung.

Eine Suche im Google Playstore listet zwar einige MQTT Broker auf – diese haben jedoch keine allzu guten Reputationen. Unsere Versuche mit diesen Brokern blieben Versuche: Von einem ernsten industriellen Einsatz raten wir ab. Zu unstabil, mit Werbung versehen und fragwürdige Herkunft bei geschlossenen Quellen sind keine Basis für einen industriellen Einsatz.

Der wahrscheinlich am häufigsten verwendete MQTT Broker ist der Mosquitto Broker der Eclypse Foundation. Dieser Broker läuft auf einigen Betriebssystemen – ab liebsten und häufigsten sicherlich auf Linux.

Android ist wie gesagt ein Client-Betriebssystem und der Betrieb eines Servers ist dort nicht unbedingt vorgesehen. Da Android jedoch nicht mehr als ein modifiziertes Linux ist kann der Weg zu einem Linux Server nicht all zu weit sein.

Die Lösung sieht also folgendermaßen aus und ist entsprechend einfach:
Wir installieren eine Linux-Terminal Emulation auf Android. In dieser Emulation können wir dann den Linux MQTT Broker installieren und betreiben.

Mosquitto MQTT Broker Installation auf Android

Hier also die Schritt-für-Schritt Anleitung zur Installation.

Alle eingesetzten Produkte sind OpenSource Programme und kostenlos verfügbar. Die Quellen aller Programme sind frei verfügbar. Alle Programme sind keine Exoten sondern von einer großen Gemeinschaft professionell entwickelte Produkte.

Installation von Termux

Das Programm Termux wird installiert.
Empfohlen über F-Droid oder Google Playstore.

Wenn F-Droid für die Installation gewählt wurde müssen auch die unten aufgeführten Zusatzmodule unter F-Droid installiert werden. Gleiches gilt für den Google Playstore. Die Termix-Installationen müssen also alle aus dem gleichen Store kommen – ansonsten werden Sie in verschiedenen Bereichen installiert und finden sich nicht gegenseitig.


Abhängig von der geplanten Betriebsweise werden zudem Zusatzmodule von Termux benötigt: Soll der Broker über ein Symbol auf dem Startbildschirm (Application Launcher) gestartet werden wird das Zusatzmodul Termux:Widget benötigt. Soll der Broker bei jedem Start des Gerätes automatisch gestartet werden benötigen wir das Modul Termux:Boot. Die Links zu den Modulen in den Android-Anwendungsstores:
Widget: Termux:Widget in F-Droid und Termux:Widget im Playstore.
Boot: Termux:Boot in F-Droid und Termux:Boot im Playstore.

Installation von Mosquitto

Nach der Installation von Termux wird Termux geöffnet / ausgeführt.

Es erscheint eine Eingabeaufforderung. Hier können nun die weiteren Befehle eingegeben werden. Zur Installation von Mosquitto reicht eine Zeile (Return nach der Eingabe):

pkg install mosquitto

Eventuelle Nachfragen alle einfach mit „Return“ bestätigen: Wir benötigen keine besonderen Einstellungen.

Weiter benötigen wir später noch einen Text-Editor, also installieren wir diesen:

pkg install nano

Optional kann natürlich auch ein anderer Editor installiert werden oder mit den entsprechenden Kenntnissen ein Android-Editor verwendet werden.

Ausführen des MQTT Brokers

Damit der Broker einfach ausgeführt werden kann, legen wir entweder eine Verknüpfung auf dem Startbildschirm an oder veranlassen Termux das Laden des Dienstes direkt beim Systemstart.

MQTT Broker über Startsymbol starten

Im Termux Terminal geben wir ein:

mkdir -p $HOME/.shortcuts
nano $HOME/.shortcuts/mosquitto.sh

Im Nano Texteditor dann

mosquitto

Abgeschlossen mit einem „Return“. Den Editor dann mit Strg-X und „Y“ beenden und speichern.

Abschliessend

chmod +x $HOME/.shortcuts/mosquitto.sh

eingeben, damit das Script die Berechtigungen zum Ausführen erhält.

Nun sollte im Android Launcher ein Widget mit dem Namen „Termux“ vorhanden sein. Dieses kann nun auf den Startbildschirm positioniert werden. Nach Auswahl des Widgets kann das angelegte Script „mosquitto.sh“ ausgewählt werden. Dieses Script ist nun dem Widget zugeordnet. Bei jedem Start über das Symbol wird also das Script ausgeführt, welches wiederum den Mosquitto Server ausführt.
Detailinfos zum Widget auf der Termux:Widget Wiki Seite.

Wenn Android Widgets völlig fremd sind hilft eine Suche zu allgemeinen Widget Themen.

MQTT Broker beim Android Systemstart starten

Die oben schon installierte Termux:Boot Anwendung muss nach der Installation einmalig gestartet werden damit die Anwendung sich als Boot-Dienst registriert.

Anschliessend legen wir analog zum Widget-Start ein Mosquitto Start Script im dafür vorgesehenen Verzeichnis ab. Im hier gezeigten Beispiel fügen wir noch die Zeile „termux-wake-look“ ein: Diese verhindert, dass Android in den Standby-Modus wechselt, so dass unser Broker durchgehend läuft.

Im Termux Terminal geben wir ein:

mkdir ~/.termux/boot
nano ~/.termux/boot/mosquitto.sh

Im Nano Texteditor dann

#!/data/data/com.termux/files/usr/bin/sh
termux-wake-lock
mosquitto

Abgeschlossen mit einem „Return“. Den Editor dann mit Strg-X und „Y“ beenden und speichern.

Diese Datei wird nun über Termux:Boot beim Systemstart geladen und ausgeführt und sollte den Mosquitto Broker starten.

Über die rAAAreware GmbH

Die rAAAreware GmbH ist ein Dienstleister für IT und Elektronik und ein Hersteller für IoT Devices. Neben Erfahrungen mit vielen Industrie- und Automotive-Protokollen wie CAN, CCP und OPC haben wir uns in den letzten Jahren bei M2M Protokollen immer mehr auf MQTT spezialisiert. Neben der Entwicklung und dem Vertrieb unserer eigenen Produkte unterstützen wir Firmen beim Aufbau und Betrieb einer MQTT Infrastruktur und bieten Entwicklungsarbeiten für IIoT Devices.

Rechtliches

Bluetooth ist eine eingetragene Marke der Bluetooth SIG, Inc.
Wi-Fi ist eine eingetragene Marke der Wi-Fi Alliance.

Vielleicht konnten Sie auch schon Produktflyer oder Anzeigen zur neuen Mitutoyo Smart Factory sehen:
Unser erster Gedanke war: Prima, auch Mitutoyo macht nun auf IIoT/IoT.
Im Prinzip ist es so, doch ist es viel eher eine Anwendung für unsere Messuhrmodule als ein Ersatz. Nach wie vor finden wir keine IoT Funkmodule für Mitutoyo Messuhren.

Die von Mitutoyo beworbene Software zielt eher auf das Messtechnik-Backend als auf die Handmesstechnik und deren Verbindung zum Prozess.
Die Messwerte können in der Software zentral verwaltet werden. Die erfassten Messungen werden mit ihren Werten gespeichert und die Verläufe können eingesehen werden.

An die Software können Mitutoyo Messgeräte (Handmessmittel / Small Tool Instruments) wie Messuhren oder Bügelmessschrauben einfach angebunden werden. Allerdings gibt es von Mitutoyo weiterhin keine direkt WLAN fähigen Messgeräte.
Zumindest liefert die Suche auf der Mitutoyo Seite (Stand 09/2020) weder zu WLAN noch zu MQTT etwas.
Es ist davon auszugehen, dass wenn ein Messgerät direkt als IoT Device an eine Cloud, einen Prozess oder ganz allgemein eine Software angebunden werden soll weiterhin kein Weg an unseren Produkten vorbei führt.
Das freut uns.
Weiter ist es dann egal, ob diese verarbeitende Software von Mitutoyo, von einem anderen Anbieter, von Ihrer IT selbst oder von uns stammt.

Ob Mitutoyo mit dieser Software erfolg haben wird ist aus unserer Sicht fraglich. Die abgedeckten Funktionen der Datenverarbeitung von Messwerten ist ein Punkt, welcher in vielen Unternehmen sehr individuell behandelt wird. Ob diese Aufgabe mit den vorhandenen Funktionen dieser Standardsoftware abgedeckt werden kann ist fraglich. Standards wie MQTT als Datenbroker vermissen wir in der Software. Wenn schon Standardsoftware, dann sollte diese offene und transparente Schnittstellen haben – um z.B. die Daten einfach an andere Systeme wie z.B. SAP oder Q-DAS / qs-STAT weitergeben zu können.

Rechtliches

Mitutoyo, Digimatic und MeasurLink sind vermutlich eingetragene Warenzeichen von Mitutoyo. Wir verwenden diese Bezeichnungen hier zur Erklärung des IoT Moduls (der Hardware und Software). Wir stehen in keiner Verbindung zu Mitutoyo – setzen aber sehr gerne und wo immer möglich deren gute und zuverlässigen Messuhren ein.
Die Angaben über Mitutoyo Produkte sind ohne Gewähr. Im Zweifel bitte direkt bei Mitotoyo nachfragen und um eine Beratung bitten.

Agile Entwicklung und Fertigung für die Industrie

Wir betreiben Produktentwicklung und Fertigung als kleines Unternehmen. Dies ist in der heutigen Zeit vielleicht exotisch, denn klassische Produktentwicklung bedeutet einen großen Zeitaufwand und hohe Entwicklungskosten für die erforderlichen Prozesse und Komponenten.

Keine Zeit und kein Geld ist auf der anderen Seite die Situation, in welcher sich gerade Startups zu Beginn ihrer Laufbahn befinden.

Wir sind zwar durch unsere langjährige Erfahrung und unseren Erfolg in der industriellen Softwareentwicklung finanziell und personell gut ausgestattet – trotzdem gelten die oben genannten Punkte auch für uns.

Kurzum: Wir haben aus der Not eine Tugend gemacht und sind nun mit unseren Produkten und unserem Vorgehen zufrieden. Was noch wichtiger ist: Unsere Kunden sind es auch.

Doch betrachten wir unser Vorgehen etwas näher und im Detail:
Für unsere industriellen IoT Produkte im Bereich der Messtechnik mit IIoT-Sensoren und IIoT-Aktoren benötigen wir die Komponenten [Gehäuse], die [Elektronik] und die [Software].
Alle diese Grundkomponenten zu Entwickeln ist entweder nur bei sehr großen Stückzahlen oder bei einem sehr hohen Produktpreis wirtschaftlich.
Deshalb versucht eine Produktionsfirma für industrielle Komponenten diese 2 Parameter zu optimieren:

  • Fertigung möglichst hoher Stückzahlen eines einzelnen Produktes
  • Möglichst lange Produktzyklen

Genau dies machen wir anders. Deshalb sehen unsere Produkte im direkten Vergleich vielleicht etwas anders aus als die unserer Mitbewerber. Hier erklären wir warum wir einiges anders machen:

Messuhr Konstruktionszeichnung in 3d-Ansicht

Agile Produktentwicklung

Wir kommen aus der Softwareentwicklung.
Hier war es vor langer Zeit auch so, dass die Produktzyklen sehr lange sind.
Eine Software war eine sehr langfristige Investition.
Entsprechend war ein ähnliches klassisches Vorgehen angebracht.
Bei der Entwicklung von Software hat hier in den letzten Jahren ein Umdenken stattgefunden.
Das klassische Wasserfallmodell findet nicht mehr überall Anwendung.
In vielen Bereichen wird Software als ein dynamischer und flexibler Prozess verstanden.
Die agile Softwareentwicklung hat sich hier zumindest für einige Bereiche durchgesetzt – sicherlich auch mit dem einen oder anderen Nachteil.
Unter Betrachtung der sich daraus jedoch auch ergebenden Vorteile haben wir unsere Produktentwicklung auf eine agile Entwicklung abgestimmt.

Zeigt den Kreislauf einer agilen Entwicklung mit den einzelnen Entwicklungsschritten

Prinzip einer agilen Vorgehensweise

Dies bedeutet im auf ein Produkt übertragenen konkreten Fall:

  • Alle Gehäuse werden auf 3D Druckern gedruckt.
    Der Preis für ein Gehäuse vervielfacht sich dadurch zwar vom Cent-Bereich auf vielleicht einen Euro.
    Es liefert jedoch dafür den Vorteil, jederzeit Verbesserungen und Weiterentwicklungen am Gehäuse und Aufbau vornehmen zu können.
    Weiter können spezifische Kundenwünsche unkompliziert und schnell umgesetzt werden.
  • Als Elektronik-Bauteile werden nur Standard-Komponenten eingesetzt.
    Dies stellt auch bei kleinen Losgrößen und dynamischer Entwicklung sicher, dass eine lange und sichere Ersatzteilversorgung gewährleistet ist.

  • Die Software der Komponenten wird konsequent agil umgesetzt.
    Es werden wo möglich Standards mit Standard-Bibliotheken eingesetzt.
    Die Build-Prozesse sind automatisiert und Toolchains erstellen einfach und schnell neue Versionsstände.
    Neue Versionen können auf Wunsch und bei Bedarf einfach direkt aus der Ferne installiert werden.

Über alle Bereiche hinweg wird eine Dokumentation und Versionierung in hoher Präzision umgesetzt.
Dadurch ist es auch bei vielen Produktvarianten sicher möglich, jeden einzelnen Versionsstand zu reproduzieren und nachvollziehen zu können.

Dies alles vereint bedeutet ein leistungsfähiges Produkt in kleinen Stückzahlen zu vermarkten und mit kurzen Produktzyklen Innovationen sehr schnell in die Produktion einfliesen zu lassen.

Weiter lassen sich individuelle Kundenwünsche sehr einfach und zielgerichtet realisieren.
Dies beginnt bei Farbe und Material für das Produktgehäuse und endet bei eigenen Funktionen oder Schnittstellen in der Software.

Unsere Grundsätze

Unsere Produktentwicklung folgt weiteren wichtigen Grundsätzen um ein zuverlässiges und langlebiges Produkt für die Messtechnik zu erstellen.

Einfachheit

So einfach wie möglich. So komplex wie nötig.
Wir erleben es häufig in Projekten, dass Dinge unnötig kompliziert gemacht werden.
Dies versuchen wir mit unseren Entwicklungen zu vermeiden.

Modularität

Eine Veringerung der Komplexität führt unweigerlich zu einer Modularisierung.
Komplexe Themen werden so lange in kleinere Module geteilt, bis jedes für sich einfach zu lösen ist.
Dies führt zu einer einfachere Realisierung und dadurch zu geringeren Kosten.
So einfach ist es.
Durch die Modularität wird das gesamte Implementationsrisiko auf eigene Unterbereiche aufgeteilt.

Eigenständigkeit / Autark

Durch die Eigenständigkeit, also die Vermeidung von unnötigen Abhängigkeiten, wird das gesamte Ausfallrisiko verringert.
Vor allem negative (Seiten-)effekte durch abhängige Module dürfen das eigentliche Modul nicht beeinträchtigen.

Wiederverwendbarkeit / Reusability

Unabhängige und eigenständige Module ermöglichen eine hohe Wiederverwendung einzelner Elemente.
Auch dies spart Kosten und ermöglicht eine preisgünstige Produktentwicklung.

Testbarkeit / Validierbarkeit

Eine dokumentierte Test- und Validierbarkeit eines Systems ist inzwischen Standard und ermöglicht eine kontinuierliche und hohe Gesamtqualität des Produkts.
Modularität ermöglicht deutlich einfachere Modultests.
Gerade bei schnellen Produktzyklen sind automatisierte Tests sinnvoll und notwendig.

Simulationfähigkeit

Eine gute Simulationsfähigkeit der Produktumgebung ist zwingend für Leistungstests, Skalierungstests und Langzeittests.
Deshalb wird die Simulation von Anwendungsfällen von Anfang an mit eingeplant und umgesetzt. Bei Dienstleistungen für die Industrie ist es selten möglich eine reale Produktionsanlage in einem Entwicklungsbereich umzusetzen. Um trotzdem jede Komponente einer Anlage testen zu können ist es unabdingbar, die anderen Komponenten der Anlage soweit möglich zu simulieren.

Offenheit

Die Mindestanforderung einer Produktentwicklung sind offene Schnittstellen.
Diese Offenheit bietet Flexibilität in der Anwendung unserer Produkte und bietet unseren Kunden eine hohe Investitionssicherheit. Wir sind Freunde von Open-Source und bevorzugen Tools und Systeme, welche dem Open-Source Grundsatz folgen. Wir vermeiden die Abhängigkeit von bestimmten Herstellern oder IT-Systemen um jederzeit flexibel auf industrielle Anforderungen reagieren zu können.