IO-Link Device Software
Um ein IO-Link Device zu implementieren bietet TMG den IO-Link Device Stack, die IO-Link Device Stack Extensions und IO-Link Device Firmware Update an. Der Device Stack realisiert die IO-Link Kommunikation bis zum Application Layer Interface. Die IO-Link Device Stack Extensions übernehmen die IO-Link Applikationsfunktionen wie den Gerätetausch ohne Tool. Das IO-Link Device Firmware Update wird dann benötigt, wenn die Firmware des IO-Link Devices mit einem standardisierten Mechanismus aktualisiert werden soll.
IO-Link Device Stack
Der IO-Link Device Stack der TMG TE wird von den führenden Geräteherstellern verwendet und von den führenden Halbleiterherstellern referenziert. Unsere Software zeichnet sich durch ihre leichte Portierbarkeit mit sehr kleinem Speicherbedarf aus. Die konsequente Trennung von Hardwareanpassung und Protokollstack erlaubt die Verwendung mit praktisch allen Mikrocontrollern und allen IO-Link Transceivern.
- Konform zur IO-Link Spezifikation V1.1.3
- Erstellt in ANSI-C 99
- Unterstützt alle IO-Link Funktionalitäten
- Rückwärtskompatibilität zum Betrieb an V1.0 Mastern
- Unterstützung aller Telegramm-Typen
- Device Kompatibilität (Unterstützung mehrerer Device IDs in einem Device)
- Konsequente Trennung von Protokoll Stack und Hardware-Anpassung
- Konsistenter Prozessdatenaustausch durch Wechselpuffer
- Synchronisation der Gerätesoftware auf den Prozessdaten- bzw. Kommunikationszyklus möglich
- Einfache Anpassung an die jeweils konkrete Anwendung durch eine Konfigurationsdatei
- Benötigt kein Betriebssystem
- Programmcode: ca. 3,5 kByte
- Je nach Mikrocontroller und Compiler
- RAM: ca. 0,5 kByte
- HW Timer: 1 x 8Bit, besser 16Bit Timer
- UART: Rx und Tx (mindestens Rx Interrupt, besser auch Tx Interrupt)
- Transmit Enable: GPIO
- Wakeup: 1x Interrupt Eingang
- Je nach Transceiver zusätzlich SPI oder I²C zur Konfiguration und Diagnose, oder alternativ zum UART SPI zur Kommunikation bei Transceivern mit Frame Handler
- Quellcode in ANSI C99
- PDF Dokumentation
- Beispiel-Hardwareanpassung
- Beispielanwendung
- Die Beispielanwendung zum IO-Link Device Stack zeigt die prinzipielle Verwendung des Stacks mit Prozessdaten, Read/Write-Requests und Events. Sie realisiert aber nicht die Anwendungsfunktionen oberhalb des Applilcation Layer Interfaces. Diese werden durch die IO-Link Device Stack Extensions komfortabel und einfach realisiert.
IO-Link Device Stack Extensions
Oberhalb des eigentlichen Kommunikations-Stacks (Application Layer Interface, Layer 7) spezifiziert IO-Link ab der Version 1.1 einige Funktionen, die die Anwendung der IO-Link Devices für den Anwender einfacher und wertiger machen. Diese Funktionen sind Teil der Anwendung und bis auf wenige Ausnahmen Pflicht. Diese Funktionen werden durch die IO-Link Device Stack Extensions realisiert.
Wir haben eine sehr große Anzahl an Integrationen mit den Stack Extensions durchgeführt und dabei eine "Best Practice" Lösung geschaffen, die praktisch alle Anforderungen von sehr einfachen bis hin zu sehr komplexen IO-Link Devices erfüllt.
Die IO-Link Software und die Umsetzung der in der IODD beschriebenen Funktionalität in die Device Firmware wird mit dem IO-Link Device Stack und den IO-Link Device Stack Extensions zum Kinderspiel. Hierbei wird mehr konfiguriert als programmiert. Das spart viel Zeit in der Entwicklung und reduziert das Entwicklungsrisiko.
Eine Beispielanwendung mit IODD und Simulation von Prozessdaten erleichtert den Einstieg und dient zur einfachen Inbetriebnahme der Hardware-Plattform mit IO-Link.
- Der Parameter Manager verwaltet alle implementierten Parameter und erzeugt Fehlercodes, wenn Zugriffsrechte fehlschlagen, die Länge von Parametern nicht stimmt und der Zugriff auf nicht implementierte Adressen (Index / Subindex) abgelehnt wird.
- Diese Funktionalität ist Pflicht (mandatory)
- Ermöglicht den Gerätetausch ohne Tool. Der IO-Link Master stellt Speicher zur Verfügung, um die Parameter des Geräts zu sichern. Eine Zustandsmaschine einschließlich Fehlerbehandlung muss implementiert werden. So muss zum Beispiel ein Rollback erfolgen, wenn die Übertragung nicht erfolgreich ist oder zu einem nicht konsistenten Zustand führt. Das ist auch der Grund für den doppelten RAM Bedarf bei den RW Variablen.
- Die Funktionalität ist Pflicht (mandatory), wenn mindestens ein Parameter beim Gerätetausch übertragen werden muss. Es ist zulässig, eine Ersatzlösung wie eine Speicherkarte zu implementieren. Die Ersatzlösung muss mit jedem normkonformen IO-Link Master funktionieren. Ausser in sehr speziellen Fällen wie einem Bilderkennungssystem mit mehr Speicherplatzbedarf, als die Master zur Verfügung stellen (2kByte), raten wir von einer derartigen Lösung ab, da sie sehr speziell ist und für den Anwender vom erwarteten und gewohnten Verhalten abweicht.
- Hinweis: Data Storage hat nichts mit dem Speichern der Parameter im nichtflüchtigen Speicher zu tun. Dies ist unabhängig davon immer zusätzlich notwendig.
- Speichert Parameter automatisch im nichtflüchtigen Speicher. Doppelspeicherung für Null-Spannungssicherheit und CRC Absicherung werden unterstützt.
- Die Übertragung von Parametern wird mit Kommandos gekapselt. Während der Übertragung des Parameterblocks werden die Abhängigkeiten der Variablen untereinander nicht überprüft. Nach der Blockübertragung prüft das Gerät die Konsistenz aller Parameter. Im Fehlerfall wird ein Rollback durchgeführt. Diese Funktionalität wird verwendet, um Deadlocks während der Parameterübertragung bei Abhängigkeiten zu verhindern.
- Die Funktionalität ist mit dem Common Profil mandatory. Dieses ist für alle IO-Link Geräte highly recommended, was soviel heißt wie verpflichtend, es sei denn, es gäbe zwingende Gründe es nicht zu implementieren. Es müsste dann aber in der Hersteller-Erklärung und der Anwender-Dokumentation beschrieben sein.
- Device Access Locks ist der Standardmechanismus mit dem der Benutzer die lokale Parametrisierung sperren und entsperren kann oder eine lokalen Bedienung (z.B. Display) ein- und ausschalten kann.
- Die Funktionalität ist Pflicht, wenn es lokale Bedienungsmöglichkeiten gibt.
- Standarddiagnose, bei der der Gerätestatus als komprimierter Status und als detaillierter Gerätestatus in Form einer Liste aller anstehenden Ereignisse angezeigt wird.
- Die Funktionalität ist mit dem Common Profil Pflicht (mandatory).
- Der IO-Link Device Stack ermöglicht zwar die Übertragung von Ereignissen, aber für die Anwendung gibt es Regeln, um eine Eventflut zu vermeiden und für das Verhalten, wenn mehrere Events gleichzeitig auftreten. Dies wird von dem Event-Dispatcher gelöst.
- Die Funktionalität ist mandatory.
- Auf Anforderungen großer Anwender wurde ein Profil definiert, das die Mindestanforderungen an IO-Link Devices für eine gute Systemdurchgängigkeit festlegt. Dieses Profil ist bei der Implementierung von Geräte-Profilen wie dem Smart-Sensor-Profile, Firmware Update und IO-Link Safety Pflicht, muss aber auch bei allen IO-Link Devices, die keinem speziellen Geräteprofil folgen, außer in Sonderfällen implementiert werden.
- Oft müssen Einstellungen am Ende des Produktionsprozesses vorgenommen werden und ins Gerät gespeichert werden, wie zum Beispiel: Serien Nummer, Kalibrierdaten, oder auch Geräte Identifikation, Voreinstellungen u.s.w., wenn z.B. die gleiche Leiterplatte für verschiedene Produkte verwendet wird.
- Diese Parameter sind für den Benutzer nicht sichtbar und durch ein Kennwort und einen Ausblendungsmechanismus geschützt. Der einfachste Weg zur Implementierung einer solchen Funktionalität ist die Verwendung des IO-Link-Mechanismus.
- Die Funktionalität ist zusätzlich zum IO-Link-Standard und wurde von TMG TE spezifiziert und implementiert. Die meisten unserer Kunden nutzen diese Funktionalität.
- Hinweis: Einige unserer Kunden verwenden den TMG USB-IO-Link Master V2, um den Produktionstest und die Produktionseinstellungen durchzuführen. Wir bieten Bibliotheken für Windows an, um den TMG USB-IO-Link Master in die Testumgebung zu integrieren.
- Erstellt in ANSI-C 99
- Leicht portierbar auf beliebige Plattformen
- Konsequente Trennung von logischen und hardwareabhängigen Anteilen
- Hardwareabstraktionsschnittstelle zur Ansprache des nicht-flüchtigen Speichers
- Benötigt kein Betriebssystem
- Programmcode: ca. 6,5 kByte
- Je nach Mikrocontroller und Compiler
- RAM
- je nach den zu implementierenden Variablen
- Länge der Read/Write Variablen x 2 + geringfügiger Overhead
- Nicht flüchtiger Speicher
- Hinweis: Programm Flash ist meist nicht nutzbar wegen Data Retention und Einfrieren der Programmausführung während des Löschens von Flash Segmenten.
- Für 0-Spannungs-sichere Implementierung Speicherbedarf so wie beim RAM
- Mögliche Lösungen:
- Vorzugslösungen: EEPROM, Data Flash oder FRAM
- Auch schon realisiert: Bei Mikrocontrollern mit großem Flash und RAM: SW komplett ins RAM geladen und dort ausgeführt. Durch Wechsel der Speicherplätze im Flash, die Schreibzyklen soweit reduziert, dass auch mit dem Programmflash genug Speicherzyklen zur Verfügung stehen.
- Quellcode in ANSI C99
- PDF Dokumentation
- Template für die Hardwareanpassung für den nicht-flüchtigen Speicher
- Beispielanwendung mit simulierten Prozessdaten
- IODD für die Beispielanwendung
IO-Link Device Firmware Update
Die Komplexität der Firmware in IO-Link Devices nimmt zu. Dementsprechend wird die Möglichkeit, Updates der Firmware wegen neuer Funktionen oder Fehlerbeseitigungen vorzunehmen, immer wichtiger. Die IO-Link Community hat deshalb eine standardisierte Lösung für diese Anforderung spezifiziert.
Die Lösung besteht aus einem Bootloader, einer IO-Link-Beispielanwendung mit dem IO-Link Firmware Update Profile samt IODD und dem TMG IO-Link Firmware Packager.
Die Lösung mit einem Bootloader sichert die 0-Spannungssicherheit. Geht beim Update etwas schief, so steht immer noch die Bootloader-Funktionalität zur Verfügung und der FW-Download kann erneut versucht werden. Der Bootloader benötigt den IO-Link Device Stack, da für die Übertragung das IO-Link Protokoll verwendet wird. Im Bootloader-Modus wird die neue Firmware mit Hilfe des Binary Large Object Profiles (BLOB) übertragen.
In der eigentlichen IO-Link Software (Produktiv-Firmware) werden einige für das FW Update Profile spezifischen Funktionalitäten wie die Hardware Identifikation und der Wechsel in den Bootmodus implementiert. Dies wird auch in der IODD entsprechend beschrieben.
Damit beliebige IO-Link konforme Tools die Firmware für das Update verarbeiten können, muss diese entsprechend bereitgestellt werden. Dazu wird die Firmware als Binary-File mit einer Beschreibungsdatei (Meta-File) und ggf. mit der für diese Firmware notwendigen neuen IODD in einem Firmware-Package verpackt. Dies übernimmt der im Lieferumfang enthaltene TMG IO-Link Device Firmware Packager. Zusätzlich zu den Pflichtfunktionen zum FW Update Profile ist auch die Verschlüsselung (Firmware -Packager) und Dekodierung (Bootloader) mit dem RC4 Algorithmus enthalten. Damit tragen wir dem Schutz Ihres Knowhows und unauthorisierter Manipulation Rechnung.
Die IO-Link Device Firmware Update Funktionalität wird von unserem IO-Link Device Tool V5.1 in der Standard und Professional Edition sowie von der für unseren TMG USB IO-Link Master V2 verfügbaren Windows DLL unterstützt. Damit bieten wir die vollständige Tool-Chain von der Entwicklung bis in die Anwendung an.
- Implementierung gemäß IO-Link Profile BLOB Transfer & Firmware Update V1.1 (09/2019)
- Erstellt in ANSI-C 99
- TMG IO-Link Firmware Update Packager Tool
- basierend auf IODD
- übernimmt automatisch die Konfiguration aus der IODD
- Erstellt den Meta Data File und berechnet den CRC
- Kann die Firmware mit RC4 verschlüsseln
- Kann die „neue“ IODD im Firmware Package verpacken
- Erstellt das Firmware-Paket * .iolfw
- Kommandozeilen Steuerung möglich
- Kann damit in den Firmware-Generierprozess eingebunden werden
- Unterstützt von IO-Link Device Tool V5.1 SE, PE und TS
- Import von Firmware-Update-Paketen
- in die interne Datenbank des IO-Link Device Tools V5.1
- Automatische Übernahme der neuen IODD
- Firmware-Updates für IO-Link Devices
- mit und ohne IODD möglich
- Für den Bootloader werden ca. 8 kByte Flash benötigt.
- Wir empfehlen die nächst größere Anzahl von Flash-Segmenten für den Bootloader zu reservieren.
- Bootloader:
- Quellcode in ANSI C99
- PDF Dokumentation
- Beispiel-Hardwareanpassung
- Produktiv-Software
- Beispielprojekt basierend auf unserem IO-Link Device Stack und den IO-Link Stack Extensions mit zugehöriger IODD
- IODD mit IO-Link Device Firmware Update Profile
- TMG IO-Link Device Firmware Packager