SDD specifications

Die SDD besteht aus einer Konfigurationsdatei (.conf im JSON-Format) und Zusatzdateien wie Bildern, Dokumenten etc.

Namensschema der Konfigurationsdatei:

Format:

<VendorName>-<ProductName>-<Datum>-SDD<SDDrevision>.conf

Beispiel:

Schmalz-SCPSt-20200416-SDD1.1.conf

Feld	Datentyp	Bemerkung
VendorName	String	Der VendorName des Herstellers (wird nicht überprüft)
ProductName	String	Der ProductName, wie vom Hersteller vergeben (wird nicht überprüft)
Datum	JJJJMMTT	Erstellungsdatum der Datei (wird von Sicon überprüft)
SDDrevision	major.minor, jeweils dezimal	Aktuell 1.1 (wird von Sicon überprüft)

Die dazugehörigen Bilder (Icon, und Picture) sollten im PNG oder JPEG Format sein. Alle anderen Dokumente sollten im PDF-Format oder TXT-Format sein.

Benennung der Zusatzdateien:

Picture (großes Produktbild): <VendorName>-<ProductName>-pic.png

Icon (kleines Produktbild): <VendorName>-<ProductName>-icon.png

Bedienungsanleitung (lang): BAL_<Schmalz Art.Nr.>_<language>_<index>.pdf

Bedienungsanleitung (kurz): BAK_<Schmalz Art.Nr.>_<language>_<index>.pdf

Wobei <language> aus { en-EN, de-DE, es-ES, it-IT, fr-FR } gewählt wird.

Der Index ist eine Dateirevision und muss bei Erstellung der SDD bekannt sein.

Beispiel: BAL_10.06.02.00570_en-EN_00.pdf

Die SDD, sowie die Zusatzdateien werden als ZIP gepackt (flach - keine Unterverzeichnisse), nach folgendem Namensschema:

<VendorName>-<ProductName>-<Datum>-SDD<SDDrevision>.zip

Bei IOL-Zusatz-SDDs folgt das Namensschema der Konfigurationsdatei folgendem Format:

<VendorName>-<ProductName>-<Datum>-IOLSDD<SDDrevision>.conf

1. Hauptstruktur des Konfigurationsfiles

Die Hauptstruktur der SDD ist wie folgt:

JSON

{
  "Document": { required },
  "Source": { required },
  "Vendor": { required },
  "BasicInformation": { required },
  "DeviceControl": { optional },

  "Identification": { required },
  "Parameter": { required },
  "Observation": { required },
  "Diagnosis": { required
    "Device status": { optional },
    "Condition monitoring": { optional },
    "Counters": { optional },
    "Timing": { optional },
    "Energy monitoring": { optional },
    "Predictive maintenance": { optional }
  },

  "Events": { optional },

  "XConfig": { optional },
  "Replay": { optional },
  "Reporting": { optional },
  "Updater": { optional },

  "OPCUA": { only for OPCUA - TO BE DEFINED
    "Subdevices": { optional },
    "Events": { optional },
    "Replay": { optional },
    "Reporting": { optional }
  },

  "CyclicData": { optional
    "ProcessDataIn": { optional },
    "ProcessDataOut": { optional },
  }
}

2. Hauptstruktur des Konfigurationsfiles - Detail

JSON

{
  "Document": {
    "SDDRevision": "1.1"
  },
  "Source": {
    "SoftwareAdapter": required
    "RootPath": required/optional (only if Schmalz/Generic OPC UA)
  },
  "Vendor": {
    "Name": required
    "Text": required
    "URL": optional
    "Logo": optional
  },
  "BasicInformation": {
    "VendorID": required
    "DeviceID": required
    "ProductName": required
    "ArticleNumber": optional (only if Generic OPC UA)
    "SerialNumber": optional (only if Generic OPC UA)
    "UID": optional (only if Generic OPC UA)
    "LocationTag": optional
    "LocationPos": optional
    "AssetID": optional
    "PictureFileName": optional
    "IconFileName": optional
    "DocumentationNames": optional
    "Description": optional
    "FirmwareUpdatePossible": optional
  },
  "DeviceControl": {
    "Commands": {
      "SystemCommand": {
        "Size": required
        "ParameterDescriptor": required
        "Value": required/optional (required if Schmalz/Generic OPC UA, otherwise optional),
        "Remark": optional
        "Range": required
      }
    }
  },
  "Identification": {
    "Gruppierung1": {
      "Parameter": {
        "Index": required
        "DataType": required
        "BitLength": required/optional (required for DataType = "UIntegerT", "IntegerT")
        "Access": required
        "Label": required
        "ParameterDescriptor": optional 
        "Range": optional 
        "Gradient": optional 
        "Resolution": optional 
        "Offset": optional 
        "Unit": optional
        "Remark": optional
        "Value": optional (only if Schmalz/Generic OPC UA)
        "DefaultValue": optional
      }
    }
  },
  "Parameter": {
    "Gruppierung1": {
      "Gruppierung2": {
        "Gruppierung3": {
          "Gruppierung4": {
            ...
          }
        }
      }
    }
  },
  "Diagnosis": {
    "Device status": { optional },
    "Condition monitoring": { optional },
    "Counters": { optional },
    "Timing": { optional },
    "Energy monitoring": { optional },
    "Predictive maintenance": { optional },
  },
  "Observation": {
  },
  "Events": {
    "EventNumber": {
      "Name": required
      "Remark": required
      "Type": required
      "Description": optional
      "Cause": optional
      "Impact": optional
      "Solution": optional
    }
  },
  "XConfig": {
    "XIndices": required
    "AutomaticReadForEvents": required
    "AutomaticReadForReporting": required
  },
  "Replay": {
    "YIndices": required
    "Triggers": required
  },
  "Reporting": {
    "Trigger": {
      "type": required
      "Code": required/optional (required if type "event", otherwise optional)
      "mode": required/optional (required if type "event", otherwise optional)
    },
    "YIndices": required
  },
  "Updater": {
    "Interval": required
    "Indices": required
  },
    "OPCUA": { only for OPCUA - TO BE DEFINED
      "Subdevices": {
        "p1": {
          "VendorID": required
          "DeviceID": required
          "SerialNumber": required
          "DeviceType": required
          "RootPath": required
          "Parent": required
          "ParentInfo": required
          "LocationTag": optional
          "LocationPos": optional
          "AssetID": required
        },
        "p2": {
        .
        .
        }
      },
    "Events": { optional },
    "Replay": { optional },
    "Reporting": { optional }
  },
  "CyclicData": {
    "ProcessDataIn": {
      "ProcessDataParameter": {
        "Index": required
        "DataType": required
        "Access": required
        "Size": required/optional (required for DataType = "UIntegerT", "IntegerT")
        "Label": required
        "ParameterDescriptor": optional 
        "Range": optional 
        "Gradient": optional 
        "Resolution": optional 
        "Offset": optional 
        "Unit": optional
        "Remark": optional
        "Value": optional
        "DefaultValue": optional
      }
    }
  }
}

3. Beschreibung des Konfigurationsfiles

3.1 Document

An dieser Stelle wird die SDD Version des Dokumentes eingetragen. Folgendes Format wird benutzt:

JSON

"Document": {
    "SDDRevision": "1.1"
  }

3.2 Source

Der Eintrag SoftwareAdapter ist erforderlich. Keys Host und DefaultPort sind optional. Key RootPath ist erforderlich, wenn es sich um einem OPC UA Device handelt.

JSON

"Source": {
    "SoftwareAdapter": required
    "RootPath": required/optional
  }

Bei Version 0.5 kann der Wert von SoftwareAdapter sein: „OPC_UA“ (SICON PLUG Control und Generic) oder „MAINDEV“ (bei Main-Devices).
Bei SDDs für SICON PLUG Adapter wird unter RootPath der Anfangspfad aller NodeIDs als String hinterlegt. Dieser NodeID ist für die SPS fest: ns=4;s=.p0

Alle weiteren NodeIDs können als Strings beschrieben werden mit folgendem Format:

Pfad mit RootPath → „§§.PfadZumNodeID“

Pfad ohne RootPath → „ns=<Zahl>;s=PfadZumNodeID“

Beispiel:

OPC UA (SICON PLUG Control [Schmalz] & Generic)

JSON

"Source": {
    "SoftwareAdapter": "OPC_UA",
    "RootPath": "ns=4;s=.SPZiFassgreifer"
  }

Beispiel:

MAINDEV (Schmalz-SCTSi)

JSON

  "Source": {
    "SoftwareAdapter": "MAINDEV"
  }

3.3 Vendor

Beinhaltet alle wichtigen Informationen über den Hersteller.

CODE

"Vendor": {
    "Name": required
    "Text": required
    "URL": required
    "Logo": required
  }

Alle Werte sind als Strings einzutragen.

Beispiel

CODE

"Vendor": {
    "Name": "J. Schmalz GmbH", 
    "Text": "www.schmalz.com",
    "URL": "www.schmalz.com",
    "Logo": "Schmalz-logo.png"
 }

3.4 BasicInformation

Keys VendorID, DeviceID und ProductName sind erforderlich. Alle anderen (SerialNumber, LocationTag, LocationPos, AssetID, PictureName, IconName, DocumentationNames und Description) sind optional.

JSON

"BasicInformation": {
    "VendorID": required
    "DeviceID": required
    "ProductName": required
    "SerialNumber": optional
    "LocationTag": optional
    "LocationPos": optional
    "AssetID": optional
    "PictureFileName": optional
    "IconFileName": optional
    "DocumentationNames": optional
    "Description": optional
    "FirmwareUpdatePossible": optional
  }

Alle Werte – bis auf "FirmwareUpdatePossible" - sind als Strings einzutragen. "FirmwareUpdatePossible" ist als true/false einzutragen.

Key VendorID → VendorID entsprechend dem Zahlenbereichssystem von GPS

Key DeviceID → DeviceID

Bei einer SDD für OPC UA Adapter (SICON PLUG Control und Generic) können alle weiteren Werte auch als NodeID-Pfade definiert werden.

Key SerialNumber → Serienummer des Gerätes

Key LocationTag → Anlage

Key LocationPos → Ort

Key AssetID → Betriebsmittelkennzeichnung. Bei einer SDD für SICON PLUG Control ist dieser Key erfordelich

Key ProductName → String für die Erkennung des Gerätes

Key PictureFileName → Name des angehängten Bildes

Key IconFileName → Name des angehängten Icons

Key DocumentationNames ist als JSON-String einzutragen in folgendem Format:

Key UsersGuide_[XX] → Bedienungsanleitung in [XX] Sprache

Key Datasheet_[XX] → Datenblatt in [XX] Sprache

Key InstallationGuide_[XX] → Installationsanleitung in [XX] Sprache

Es sollen alle Namen von den vorhandenen Dokumenten in der SDD .zip Datei beschrieben werden.

z.B.:

JSON

"DocumentationNames": "{\"UsersGuide_EN\":\"SDD-5000001-BA_EN.pdf\",\"UsersGuide_DE\":\"SDD-5000001-BA_DE.pdf\"}",

Key Description → Gerätebeschreibung im Klartext (ProductText in IOL)

Key FirmwareUpdatePossible → false oder true, beschreibt ob bei dem Device ein Firmware-Update von Sicon aus durchgeführt werden kann (default = false)

3.5 DeviceControl

Dieser Parent-Key soll bei Geräten, die Device-Kommandos unterstützen, definiert sein.

Hier sind die Keys Size, ParameterDescriptor, Range und Value zu definieren (Key Value nur im Fall einer SDD für OPC UA Adapter). Der Rest wird vom System automatisch eingetragen (Index = 2, Label = „Standard Command“, Remark = „Runs the different commands on this device“, DataType = „UIntegerT“, Access = „w“).

JSON

  "DeviceControl": {
    "Commands": {
      "SystemCommand": {
        "Size": required
        "ParameterDescriptor": required
        "Value": required/optional,
        "Range": required,
      }
    }
  }

Size beschreibt die Bit-Länge (als Integer).

Range beschreibt alle vorhandenen Kommandos. Diese sollten wie folgend formatiert sein:

„[Wert 1],[Wert 2],…,[Wert N]“

Oder bei Werte-Bereichen:

„[Wert min]-[Wert max]“

Oder eine Mischung aus beiden:

„[Wert 1],[Wert 2],…,[Wert N],[Wert min]-[Wert max]“

Beispiel Eintrag von Range:

NONE

"0,1,4-7"

ParameterDescriptor definiert zu allen vorhandenen Kommandos die passende Beschreibung (als String). Jedes Kommando hat einen bestimmten Wert und Bedeutung. Diese sollten wie folgend formatiert sein:

„[Wert 1]=[Bedeutung 1],[Wert 2]=[Bedeutung 2],…,[Wert N]=[Bedeutung N]“

Beispiel Eintrag von ParameterDescriptor:

NONE

"0=Reset erasable counters,1=Calibrate sensor"

Beispiel Eintrag von Value:

NONE

"§§.Parameter.DeviceSettings.Commands"

3.6 Identification, Parameter, Observation & Diagnosis

3.6.1 Verschachtelung für Gruppierungen der Variablen

Bei jedem der folgenden Parent-Keys (Identification, Parameter, Observation & Diagnosis) ist eine Verschachtelung bis zur vierten Ebene erlaubt. Dies erlaubt die Gruppierungen von verschiedenen Parametern bis zu vier Ebenen tief. Die erste Ebene beginnt direkt nach dem Parent-Key.

Z.B.: nach Key Parameter

JSON

  "Parameter": {
    "Gruppierung1": {
      "Gruppierung2": {
        "Gruppierung3": {
          "Gruppierung4": {
          
          }
        }
      } 
    }
  }

Nachdem die Gruppierungen definiert sind, können die Parameter eingetragen werden.

Es gibt vier Hauptbereiche in denen Variablen definiert werden:

Identification → Informationen für die Identifizierung des Gerätes

Parameter → Einstellungen des Geräts

Observation → Variablen, die für eine Überwachung des Gerätes gedacht sind. Die Variablen dieses Bereichs werden mit MQTT-Mechanismus „postObservation“ zyklisch eingelesen.

Diagnosis → Variablen, die für die Diagnose des Geräts gedacht sind

3.6.2 Parameter-Normierung

Keys Index, DataType, Access und Label sind erforderlich.

Keys Subindex, Size, ParameterDescriptor, Range, Gradient, Resolution und Offset, Unit, Remark, DefaultValue und Value sind optional.

JSON

    "Variable": {
      "Index": required
      "Subindex": optional
	"BitOffset": required if Subindex != 0
      "DataType": required
      "Access": required
      "Label": required
      "Size": required/optional (required for DataType = "UIntegerT", "IntegerT")
      "ParameterDescriptor": optional 
      "Range": optional 
      "Gradient": optional 
      "Resolution": optional 
      "Offset": optional 
      "Unit": optional
      "Remark": optional
      "Value": optional
      "DefaultValue": optional
    }

HauptKey Variable → Label (Name) der Variable im UpperCamelCase-Format. Z.B.: Label = „Energy consumption“ → HauptKey = „EnergyConsumption“. Erlaubte Zeichen sind: [a-z], [A-z], [0-9]

Key Index → Eine eindeutige Zahl, welche die Variable identifiziert. Der gleiche Index darf nicht mehrfach auftreten.

Key Subindex → Eine eindeutige Zahl, welche die Variable innerhalb des Subindex identifiziert. Der gleiche Subindex darf nicht mehrfach innerhalb eines Index auftreten.

Key BitOffset → Bei Verwendung von Subindizes, das Offset des niederwertigsten Bits des Datums innerhalb eines komplexen Parameters. Von rechts her gezählt (vgl. Darstellung von RecordT in der IODD)

Key DataType → Datentyp der Variable (als String). Folgende Werte sind erlaubt:

§ IntegerT

§ UIntegerT

§ BooleanT

§ StringT

§ Float32T

§ TimeT

§ TimespanT

§ HexStringT

§ OctetStringT

Key Access → Berechtigungen für die Variable (als String). Folgende Werte sind erlaubt:

§ „r“ → nur Lesen erlaubt

§ „rw“ → Lesen und Schreiben erlaubt

§ „w“ → nur Schreiben erlaubt

Key Label → Name der Variable

Key Size → beschreibt die Bit-Länge (als Integer). Erforderlich bei folgenden DataTypes: „UIntegerT“ und „IntegerT“

Key Unit → Einheit der Variable

Key Remark → Funktion/Beschreibung der Variable

Key ParameterDescriptor → Beschreibt die Bedeutungen aller möglichen Werte. Wie auch bei Parameter SystemCommand hat jeder Wert seine bestimmte Bedeutung. Dieser Wert soll wie folgend formatiert sein:

„[Wert 1]=[Bedeutung 1],[Wert 2]=[Bedeutung 2],…,[Wert N]=[Bedeutung N]“

Der Key sollte vorhanden sein, falls Key Range Werte mit bestimmter Bedeutung hat.

Beispiel:

NONE

"0=Reset erasable counters,1=Calibrate sensor"

Key Range → Alle möglichen Werte der Variable. Ähnlich wie bei ParameterDescriptor sollten alle erlaubte Werte in folgendem Format definiert werden:

„[Wert 1],[Wert 2],…,[Wert N]“

Oder bei Werte-Bereichen:

„[Wert min]-[Wert max]“

Oder eine Mischung aus beiden:

„[Wert 1],[Wert 2],…,[Wert N],[Wert min]-[Wert max]“

Beispiele:

CODE

"2,3,128,129"
"0-999"
"0,3,5,7,100-999"

Key Gradient → Multiplikationsfaktor für die korrekte Anzeige der Variable (als String)

Key Resolution → Display-Format. Darf folgende Werte haben:

Hex: Hexadecimal Notation mit postfix “h”
Dec: Dezimalzahl Notation ohne postfix
Dec.x: Dezimalzahl Notation mit vorhandene Präzision (x ist die Anzahl an Ziffern nach dem Komma)
Bin: Binär Notation mit postfix “b“

Beispiel:

CODE

"Bin"
"Hex"
"Dec"
"Dec.1"

Key Offset → Wertverschiebung (als String)

Beispiel:

CODE

"12.3"
"-5.1"

Die Keys Gradient, Resolution und Offset sollten, wenn vorhanden, immer als Gruppe vorhanden sein. Der Wert der Variable wird in diesem Fall wie folgend verändert:

a. Der Wert der Variable wird mit Gradient multipliziert und um dem Wert vom Key Offset verschoben (Addition)

Beispiel {“SensorValue”: “2222” & “Gradient”: “0.01” & “Offset”: “-0.2”}

Neuer Wert der Variable nachdem Gradient & Offset angewendet wurden:

“SensorValue”: “22.20”

b. Der Wert der Variable wird in das entsprechende Format für die Darstellung gebracht (durch Key Resolution definiert)

Beispiel {“ SensorValue”: “22.20” & “Resolution”: “Dec.1”}

Neuer Wert der Variable nachdem Resolution angewendet wurde:

“SensorValue”: “22.2”

Key DefaultValue → Standard-Wert der Variable (ohne Verwendung von Gradient, Offset und Resolution)

Key Value → statischer Wert der Variable. Bei einer SDD für OPC UA Adapter kann hier die NodeID eingetragen werden.

Beispiele:

CODE

“§§.Observation.Monitoring.ProcessDataIn.RatioComponentGrippedDropped” “ns=4;s=.SPZi.Observation.Monitoring.ProcessDataIn.RatioComponent”
“ns=4;s=|var|CODESYS.Application.IoConfig_Globals_Mapping.Input_1”

Gesamtes Beispiel für ein/e Parameter/Variable

DataType StringT für OPC UA (SICON PLUG Control und Generic)

JSON

      "Geolocation": {
        "Index": 10,
        "DataType": "StringT",
        "Access": "rw"
        "Label": "Geolocation",
        "Value": "§§.Identification.Localization.Geolocation",
      }

DataType UIntegerT

JSON

      "EnergyConsumptionPerCycle": {
        "Index": 157,
        "DataType":"UIntegerT",
        "Access":"r",
        "Size": 16,
        "Label": "Energy consumption per cycle",
        "Unit": "Ws"
        "Remark": "Add some description to this variable. ToDo!",
        "ParameterDescriptor": "",
        "Range": "0-999",
        "Gradient": "1",
        "Resolution": "Dec",
        "Offset": "0"
      }

3.6.3 Vordefinierte Indizes

Folgende Variablen haben vordefinierte Indizes:

IOL-Standard-Parameter (IDs immer gleich)	Hex-Wert	Dez-Wert
V_SystemCommand	0x0002	2
V_DeviceAccessLocks	0x000C	12
V_VendorName	0x0010	16
V_VendorText	0x0011	17
V_ProductName	0x0012	18
V_ProductID	0x0013	19
V_ProductText	0x0014	20
V_SerialNumber	0x0015	21
V_HardwareRevision	0x0016	22
V_FirmwareRevision	0x0017	23
V_ApplicationSpecificTag	0x0018	24
V_ErrorCount	0x0020	32
V_DeviceStatus	0x0024	36
V_DetailedDeviceStatus	0x0025	37

Schmalz-Standard-Parameter - Identification (IDs nicht standardisiert)
Unique ID	0x00F0	240
Feature List	0x00F1	241
Equipment Identification	0x00F2	242
Anlagenkennzeichnung	0x00F5	243
Ortskennzeichen	0x00F6	244
Geolocation	0x00F6	246
Weblink to IODD	0x00F7	247
Weblink to NFC App	0x00F8	248
Storage Location	0x00F9	249
Article Number	0x00FA	250
Article Index	0x00FB	251
Production Date	0x00FC	252
Installation Date	0x00FD	253
Detailed Product Text	0x00FE	254

3.6.4 Vordefinierte Gruppierungen

Für den Parent-Key Diagnosis sind folgende Gruppierungen vordefiniert: „Device status“, „Energy monitoring“, „Predictive maintenance“ und „Condition monitoring“

JSON

  "Diagnosis": {
    "Device status": { },
    "Energy monitoring": { },
    "Predictive maintenance": { },
    "Condition monitoring": { }
  }

In Gruppierung “Device status” sollte/n die Variable/n für die Beschreibung des Geräte-Zustands definiert sein.

In Gruppierung “Energy monitoring” sollte/n die Variable/n für die Beschreibung des Energiegebrauchs vom Gerät definiert sein.

In Gruppierung “Predictive maintenance” sollte/n die Variable/n für die vorausschauende Instandhaltung definiert sein.

In Gruppierung “Condition monitoring” sollte/n die Variable/n für die Überwachung des Geräte-Zustands definiert sein.

3.6.5 Vordefinierte Variablen in Schnittstelle SICON PLUG Control - MAIN

Folgende Variablen sollen bei der MAIN SDD in der SICON PLUG Control Schnittstelle vorhanden sein:

JSON

"Identification": {
    "Information": {
      "VendorName": {
        "Index": 16,
        "DataType": "StringT",
        "Access": "r",
        "Label": "Vendor name",
        "Remark": "This is the vendor name of the Facility/PLC",
        "Value": "§§.VendorName"
      },
      "VendorText": {
        "Index": 17,
        "DataType": "StringT",
        "Access": "r",
        "Label": "Vendor text",
        "Remark": "This is the vendor text of the Facility/PLC",
        "Value": "§§.VendorText"
      },
      "ProductName": {
        "Index": 18,
        "DataType": "StringT",
        "Access": "r",
        "Label": "Product name",
        "Remark": "This is the product name of the Facility/PLC",
        "Value": "§§.ProductName"
      },
      "ProductText": {
        "Index":20,
        "DataType": "StringT",
        "Access": "r",
        "Label": "Product text",
        "Remark": "This is the product text of the Facility/PLC",
        "Value": "§§.ProductText"
      },
      "SerialNumber": {
        "Index": 21,
        "DataType": "StringT",
        "Access": "r",
        "Label": "Serial number",
        "Remark": "This is the serial number of the Facility/PLC",
        "Value": "§§.SerialNumber"
      },
      "HardwareVersion": {
        "Index": 22,
        "DataType": "StringT",
        "Access": "r",
        "Label": "Hardware version",
        "Remark": "This is the hardware version of the Facility/PLC",
        "Value": "§§.HardwareVersion"
      },
      "FirmwareVersion": {
        "Index": 23,
        "DataType": "StringT",
        "Access": "r",
        "Label": "Firmware version",
        "Remark": "This is the firmware version of the Facility/PLC",
        "Value": "§§.SoftwareVersion"
      },
      "ArticleNumber": {
        "Index": 250,
        "DataType": "StringT",
        "Access": "r",
        "Label": "Article number",
        "Remark": "This is the article number of the Facility/PLC",
        "Value": "§§.ArticleNumber"
      },
      "InstallationDate": {
        "Index": 253,
        "DataType": "StringT",
        "Access": "r",
        "Label": "Installation date",
        "Remark": "This is the installation date of the Facility/PLC",
        "Value": "§§.InstallationDate"
      },
      "ProductionCode": {
        "Index": 255,
        "DataType": "StringT",
        "Access": "r",
        "Label": "Production code",
        "Remark": "This is the production code of the Facility/PLC",
        "Value": "§§.ProductionCode"
      },
	"DeviceType": {
        "Index": 260,
        "DataType": "StringT",
        "Access": "r",
        "Label": "Device type",
        "Remark": "This is the Device type of the SIO device",
        "Value": "§§.DeviceType"
      }
    },
    "Localization": {
      "Geolocation": {
        "Index": 246,
        "DataType": "StringT",
        "Access": "rw",
        "Label": "Geolocation",
        "Remark": "This is the geolocation of the Facility/PLC",
        "Value": "§§.Geolocation"
      },
      "WebLink": {
        "Index": 248,
        "DataType": "StringT",
        "Access": "rw",
        "Label": "Web link",
        "Remark": "This is the web link of the Facility/PLC",
        "Value": "§§.WebLink"
      },
      "StorageLocation": {
        "Index": 249,
        "DataType": "StringT",
        "Access": "rw",
        "Label": "Storage location",
        "Remark": "This is the storage location of the Facility/PLC",
        "Value": "§§.StorageLocation"
      },
      "LinkToIoT": {
        "Index": 256,
        "DataType": "StringT",
        "Access": "rw",
        "Label": "Link to IoT",
        "Remark": "This is the link to IoT of the Facility/PLC",
        "Value": "§§.LinkToIoT"
      },
      "OwnerName": {
        "Index": 257,
        "DataType": "StringT",
        "Access": "rw",
        "Label": "Owner name",
        "Remark": "This is the owner name of the Facility/PLC",
        "Value": "§§.OwnerName"
      }
    }
  },
  "Observation": {
    "Counters": {
      "GlobalCycles": {
        "Index": 140,
        "DataType": "StringT",
        "Access": "r",
        "Label": "Global cycles",
        "Gradient": "1",
        "Resolution": "Dec",
        "Unit": "",
        "Remark": "This are the global cycles of the Facility/PLC",
        "Value": "§§.GlobalCycles"
      }
    }
  },
  "Diagnosis": {
    "Device status": {
      "DeviceStatus": {
        "Index": 36,
        "DataType": "IntegerT",
        "Access": "r",
        "Size": 32,
        "Label": "Device status",
        "Remark": "This is the device status of the Facility/PLC",
        "Value": "§§.DeviceStatus"
      }
    }
  }

3.6.6 Vordefinierte Variablen in Schnittstelle SICON PLUG Control – SIO Gerät

Folgende Variablen sollen bei der SIO-Gerät-SDD in der SICON PLUG Control Schnittstelle vorhanden sein:

JSON

"Identification": {
    "Information": {
      "SerialNumber": {
        "Index": 21,
        "DataType": "StringT",
        "Access": "r",
        "Label": "Serial number",
        "Remark": "This is the serial number of the SIO device",
        "Value": "§§.SerialNumber"
      },
	"DeviceType": {
        "Index": 260,
        "DataType": "StringT",
        "Access": "r",
        "Label": "Device type",
        "Remark": "This is the Device type of the SIO device",
        "Value": "§§.DeviceType"
      }
    }
  },
  "Diagnosis": {
    "Device status": {
      "DeviceStatus": {
        "Index": 36,
        "DataType": "IntegerT",
        "Access": "r",
        "Size": 32,
        "Label": "Device status",
        "Remark": "This is the device status of the SIO device",
        "Value": "§§.DeviceStatus"
      }
    }
  }

3.7 Events

Parent-Key Events beinhaltet alle Informationen bezüglich Ereignissen und hat folgende Struktur:

JSON

  "Events": {
    "EventCode": {
      "Type": required
      "LanguageCode": {
        "Name": required
        "Remark": required
        "Description": optional
        "Cause": optional
        "Impact": optional
        "Solution": optional
      },
      "LanguageCode": {
        "Name": required
        "Remark": required
        "Description": optional
        "Cause": optional
        "Impact": optional
        "Solution": optional
      }
    }
  }

Haupt-Key EventCode → Code für die Erkennung des Ereignisses

Key Type → Ereignistyp. Darf folgenden Wert haben:

„Error“
„Warning“
„Notification“

Unter-Ebenen für Mehrsprachigkeit: LanguageCode → Sprach-Code für die untergeordneten Texte. Verwendet werden 2-letter Codes nach ISO 639-1 wie "en", "de", etc. Es muss immer mindestens "en" vorhanden sein.

Für jede Sprache gibt es folgende Unter-Keys:

Key Name → Ereignis-Text

Key Remark → zusätzliche Information

Key Description → beschreibt das Ereignis.

Key Cause → beschreibt die Ursache des Ereignisses.

Key Impact → beschreibt die Auswirkung des Ereignisses.

Key Solution → beschreibt die Abhilfe des Ereignisses.

Beispiel:

JSON

"Events": {
    "20736": {
      "Type": "Error",
      "en": {
        "Name": "Undervoltage US",
        "Remark": "Check application",
        "Description": "Primary power supply US is too low",
        "Cause": "Use of insufficient power supply or voltage drop on cabli…",
        "Impact": "Proper operation of the device cannot be ensured…",
        "Solution": "Check specification of power supply unit…"
      },
      "de": {
        "Name": "Unterspannung US",
        "Remark": "Anwendung überprüfen",
        "Description": "Haupt-Versorgungsspannung US ist zu niedrig",
        "Cause": "Hoher Spannungsabfall in Zuleitung, Netzteil defekt",
        "Impact": "Ventilfunktion beeinträchtigt, Datenverlust",
        "Solution": "Zuleitung und Netzteil überprüfen"
      }
    }
  }

3.8 XConfig

Der Parent-Key muss definiert sein, wenn der Parent-Key Reporting definiert ist. Er eröffnet die Möglichkeit X-Werte für die Darstellung von Events & Reporting (Y-Werte) festzulegen.

Zum Beispiel: Zeit, Zyklen, ...

Key XIndices → Indices der Variablen, die bei Events und Reporting als XValues geliefert werden sollen (als Array, max. 4 Indices erlaubt). Die Elemente im Array sind als String zu schreiben („Index.Subindex“). Hinter den angegebenen Index.Subindex Kombinationen müssen sich numerische Datenobjekte befinden, es darf nicht per Subindex 0 auf einen zusammengesetzten Index zugegriffen werden.

Key AutomaticReadForEvents → legt fest, ob die XIndices beim Verarbeiten eines Events automatisch mit ausgelesen werden sollen (true/false)

Key AutomaticReadForReporting → legt fest, ob die XIndices beim Verarbeiten eines Report automatisch mit ausgelesen werden sollen (true/false)

Alle Keys sind erforderlich. Die Struktur und Information sieht wie folgend aus:

JSON

  "XConfig": {
    "XIndices": ["140.0","143.0"],
    "AutomaticReadForEvents": true,
    "AutomaticReadForReporting": true
  }

Die Semantik der ersten beiden XIndices ist vordefiniert als:

X1= GlobalCycles

X2= PartCycles

3.9 Replay

Mit der Replay werden die Indizes und Trigger-Bedingungen für das Replay Feature vorgegeben.

JSON

  "Replay": {
    "YIndices": ["64.1","65.1","66.2","148.0","149.0"],
    "Triggers": [
      {"Code":36002,"Mode":"SINGLESHOT"},
      {"Code":12345,"Mode":"DISAPPEARS"}
    ]
  }

Key Indices: Indices der Variablen, die im Replay enthalten sein sollen (als Array, max. 30 Indices erlaubt). Die Elemente im Array sind als Strings, mit der Möglichkeit, einen Subindex anzugeben. Hinter den angegebenen Index.Subindex Kombinationen müssen sich numerische Datenobjekte befinden, es darf nicht per Subindex 0 auf einen zusammengesetzten Index zugegriffen werden.

Key Triggers listet ein Array aus einzelnen Trigger-Bedingungen. Diese werden ODER-verknüpft. Jede Trigger-Bedingung ist ein Objekt aus folgenden Keys:

Code: Ereignis-Code, der für die Auslösung des Replay benutzt werden soll.
Mode: Ereignis-Mode, der für die Auslösung des Replay benutzt werden soll. Mögliche Werte:

o „APPEARS“

o „DISAPPEARS“

o „SINGLESHOT“

Das Event 36002, SINGLESHOT, muss immer mindestens vorhanden sein ("user trigger").

3.10 Reporting

Der Parent-Key Reporting darf nur definiert sein, wenn auch der Parent-Key Xconfig definiert ist. Er beinhaltet die Einstellungen für die zyklischen postReport Nachrichten und hat folgende Struktur:

JSON

"Reporting": {
    "Trigger": {
      "type": required
      "Code": required (only if type "event")
      "mode": required (only if type "event")
    },
    "YIndices": required
    "SummaryAccess": optional (only implemented for IO-Link devices so far)
    {
    	"Index": required
    	"Offsets": required
    }
    }

Key Trigger hat folgende Subkeys:

Type: beschreibt den Auslöser-Typ der Reporting Nachricht. Der Key darf folgende Werte haben:

o „time“

o „event“

o „self-triggered“

§ Code: Ereignis-Code, der für die Auslösung der postReport Nachricht benutzt werden soll. Der Key muss nur vorhanden sein, falls Key Type → „event“ ist.

§ Mode: Ereignis-Mode, der für die Auslösung der postReport Nachricht benutzt werden soll. Der Key muss nur vorhanden sein, falls Key Type → „event“ ist. Mögliche Werte:

o „APPEARS“

o „DISAPPEARS“

o „SINGLESHOT“

§ SamplingRate: Zeitinterval zwischen 2 Reporting Nachrichten, falls Key Type -> „time“ ist. (Intervall in ms)

Key YIndices: Indices der Variablen, die in der Reporting Nachricht geliefert werden sollten (als Array, max. 20 Indices erlaubt). Die Elemente im Array sind als Objekte zu schreiben. Die Möglichkeit Indices mit Subindices zu schreiben ist auch vorhanden. Hinter den angegebenen Index.Subindex Kombinationen müssen sich numerische Datenobjekte befinden, es darf nicht per Subindex 0 auf einen zusammengesetzten Index zugegriffen werden.

Die Indices sind die Keys eines Objekts und der Value ein String, der folgende Werte haben darf: „EM“, „CM“ und „PM“. Diese Werte definieren die Gruppierung für die Reporting Variablen, mit folgender Bedeutung:

EM → Energy Monitoring

PM → Predictive Maintenance

CM → Condition Monitoring

Beispiel:

CODE

[{"41.0": "EM"},
{"42.0": "PM"},
{"43.0": "PM"},
{"44.0": "CM"},
{"45.0": "CM"},
{"46.0": "CM"},
{"47.0": "CM"},
{"48.0": "CM"},
{"49.0": "CM"}]

Key SummaryAccess → Objekt mit Darstellung eines Reporting-Sammelindex

Index→ Index auf dem alle Reporting-Daten summarisch gelesen werden können
Offsets → Array Länge 1...20, Angabe des jeweiligen Byte-Index (startend bei 0, von links nach rechts) wo der Reporting-Wert im Sammelindex gefunden werden kann (Reihenfolge des Offset-Arrays entspricht der Reihenfolge im Indices-Array).

3.11 Updater

Der Parent-Key Updater ist optional und beinhaltet die Einstellungen für ein regelmäßiges Updaten statischer Variablen. Er hat folgende Struktur:

JSON

"Updater": {
  "Interval": required
  "Indices": required
}

Key Interval: Zeit-Interval für das Updaten der Variablen in ms.

Key Indices: Indices der Variablen, die aktualisiert werden sollten (als Array).

Beispiel:

3.12 OPCUA

! Dieser Bereich wird noch überarbeitet !

3.12.1 Subdevices

Dieser Parent-Key ist optional und kann für die Anmeldung von Unterelemente bzw. Untergeräte eines Schmalz Gerätes verwendet werden. Dieser Key darf nicht in einer SDD eines OPCUA- Untergerätes verwendet werden. Es besteht folgende Struktur:

JSON

  "Subdevices": {
    "p1": {
      "VendorID": required
      "DeviceID": required
      "SerialNumber": required
      "DeviceType": required
      "RootPath": required/optional (required if Schmalz OPC UA, otherwise optional)
      "Parent": required
      "ParentInfo": required
      "LocationTag": optional
      "LocationPos": optional
      "AssetID": required
    },
    "p2":
    .
    .
  }

Jedes Objekt beschreibt ein Untergerät und es besteht aus folgenden Keys:

Parent-Key p[x] → Muss fortlaufend nummeriert sein

Haupt-Key VendorID →

Haupt-Key DeviceID →

Haupt-Key SerialNumber → Seriennummer des Gerätes

Haupt-Key DeviceType → Geräte-Typ „sdd“ oder „iodd“

Haupt-Key RootPath → Anfangspfad des Untergeräts vom OPC UA Server

Haupt-Key Parent → Parent-Key des Vorgängers vom Untergerät (als String)

Haupt-Key ParentInfo → Extrainformationen vom Vorgänger des Untergerätes (z.B.: Anschluss-Port)

Haupt-Key LocationTag → Anlage des Untergeräts (als String)

Haupt-Key LocationPos → Ort des Untergeräts (als String)

Haupt-Key AssetID → Betriebsmittelkennzeichnung (als String)

Beispiel für ein Schmalz OPC UA Gerät:

JSON

"Subdevices": {
    "p1": {
      "RootPath": "ns=4;s=.p1",
      "Parent": "p0",
      "ParentInfo": "I/O Klemme 1.0",
      "VendorID": "§§.BasicInformation.VendorID",
      "DeviceID": "§§.BasicInformation.DeviceID",
      "SerialNumber": "§§.BasicInformation.SerialNumber",
      "DeviceType": "sdd",
      "AssetID": "-B1"
    },
    "p3": {
      "RootPath": "ns=4;s=.p3",
      "Parent": "p0",
      "ParentInfo": "I/O Klemme 1.1",
      "VendorID": "§§.BasicInformation.VendorID",
      "DeviceID": "§§.BasicInformation.DeviceID",
      "SerialNumber": "§§.BasicInformation.SerialNumber",
      "DeviceType": "sdd",
      "AssetID": "-A1"
    },
    "p7": {
      "RootPath": "ns=4;s=.p7",
      "Parent": "p0",
      "ParentInfo": "I/O Klemme 2.0 - 2.3",
      "VendorID": "§§.BasicInformation.VendorID",
      "DeviceID": "§§.BasicInformation.DeviceID",
      "SerialNumber": "§§.BasicInformation.SerialNumber",
      "DeviceType": "sdd",
      "AssetID": "-A2"
    },
    "p12": {
      "RootPath": "ns=4;s=.p12",
      "Parent": "p0",
      "ParentInfo": "I/O Klemme 2.0 - 2.3",
      "VendorID": "234",
      "DeviceID": "987654321",
      "SerialNumber": "§§.SerialNumber",
      "DeviceType": "sdd",
      "LocationPos": "+Flach",
      "AssetID": "-F1"
    }
  }

3.12.2 Events (OPCUA)

Der Parent-Key muss bei SDDs für Schmalz OPC UA Geräte definiert sein und darf nicht für eine SDD eines OPCUA-Untergerätes verwendet werden.

Key DataPath → NodeID für den Event-String des OPC UA Servers

Key HandshakePath → NodeID für den Handshake des OPC UA Servers

Key Format → Format des Event-Strings im OPCUA-Server

Key Modes → Beschreibung aller Ereignis-Modi (als Array of String)

Key Types → Beschreibung aller Ereignis-Typen (als Array of String)

Alle Keys sind erforderlich. Die Struktur und Information sieht wie folgend aus:

JSON

"OPCUA": {
  "Events": {
    "DataPath": "§§.Events",
    "HandshakePath": "§§.EventsHandshake",
    "Format":"timestamp;GlobalCycles;PartNumber;PartText;PartCycles;mode;type;Subdevice;code",
    "Modes": ["UNKNOWN", "SINGLESHOT", "APPEARS", "DISAPPEARS"],
    "Types": ["UNKNOWN", "Notification", "Warning", "Error"]
  }
}

3.12.3 Replay (OPCUA)

To be defined..

3.12.4 Reporting (OPCUA)

Key DataPath → NodeID für die Reporting-Daten (als String) des OPC UA Servers

Key HandshakePath → NodeID für den Reporting-Handshake des OPC UA Servers

CODE

"DataPath": "§§.ReportingData",
"HandshakePath": "§§.ReportingHandshake",

Key Format muss bei Schmalz OPC UA Geräte definiert sein. Dieser beschreibt das Format der Variablen, die vom OPC UA Gerät im Reporting-String vor den eigentlichen Reporting-Daten geliefert wird.

Beispiel:

CODE

"Format": "timestamp;GlobalCycles;PartNumber;PartText;PartCycles;Subdevice",

Beispiel:

JSON

"OPCUA": {
  "Reporting": {
    "DataPath": "§§.Events",
    "HandshakePath": "§§.EventsHandshake",
    "Format":"timestamp;GlobalCycles;PartNumber;PartText;PartCycles;mode;type;Subdevice;code"
  }
}

3.13 CyclicData

Der Parent-Key “CyclicData” ist optional und erlaubt die Definition von zyklischen Prozessdaten für das Device. Diese werden dann mit dem MQTT-Mechanismus getDynData bzw. startCyclicData geholt.

JSON

"CyclicData": { optional
  "ProcessDataIn": { optional
    "ProcessDataInParameter1": {
      "Index": required
      "DataType": required
      "Access": required
      "Size": conditional (required for DataType = "UIntegerT", "IntegerT")
      "Label": required
      "ParameterDescriptor": optional 
      "Range": optional 
      "Gradient": optional 
      "Resolution": optional 
      "Offset": optional 
      "Unit": optional
      "Remark": optional
      "Value": optional
      "DefaultValue": optional
    },
    "ProcessDataInParameter2": {
        ...
    }
  },
  "ProcessDataOut": { optional
    "ProcessDataOutParameter1": {
        ...
    }
  }
}

Keys ProcessDataIn, ProcessDataOut: wenn CyclicData vorhanden ist, muss mindestens einer dieser Keys vorhanden sein. „In“ beschreibt die Daten, die das Device als Prozessdaten an eine Steuerung liefert, „Out“ entsprechend die Daten die von der Steuerung an das Device geschickt werden.

Keys ProcessDataInParameter1, ProcessDataInParameter2 etc.: geben Referenz-Namen für die einzelnen Elemente der CyclicData. Diese dienen später als Objektname beim Senden auf MQTT ??

Alle weiteren Keys sind äquivalent zu denen bei der Variablendefinition (Identification, Parameter, Observation etc.). Passt das ?

Zu klären:

Index/Subindex vorhanden, optional oder immer ? Was wird damit gemacht ?

Zumindest bei eMQTT-basierten Devices müsste immer eine Angabe von BitOffset und BitLength rein und somit womöglich auch ein Subindex immer dazu ?

Zum Vergleich, Beispiel aus alter Spec v0.3:

JSON

     "RatioComponentGrippedDropped": { 
        "Index": 157, 
        "DataType":"UIntegerT", 
        "Access":"r", 
        "Size": 16, 
        "Label": "Ratio - component gripped/dropped", 
        "Range": "0-100", 
        "Gradient": "1", 
        "Resolution": "Dec.1", 
        "Offset": "0" 
        "Value": "§§.Observation.Monitoring.….RatioComponentGrippedDropped", 
      }

3.14 MappedIndices

Der Parent-Key MappedIndices ist optional und beinhaltet die Einstellungen für Indices, welche sowohl beim Lesen als auch Schreiben mit SICON.OS-internen Werten synchronisiert werden. Aktuell existiert nur der Wert „Geolocation“. MappedIndices hat folgende Struktur:

JSON

"MappedIndices": {
	"Geolocation": {
	  "Format": required
	  "Index": required
	}
}

Key Format: Format-String, welcher die Formatierung des Indices abbildet.

Key Index: Index der Variable, welche die synchronisiert werden soll (als String).

Beispiel:

JSON

"MappedIndices": {
	"Geolocation": {
	  "Format": "%LAT_10_DC_POINT;%LONG_10_DC_POINT",
	  "Index": "246.0"
	}
}

3.15 EventGroups

Der Parent-Key EventGroups ist optional und beinhaltet Event-Gruppen (Array) mit Einstellungen (Object) für Events, welche sinnvollerweise zusammen gehören (weil Sie zum Beispiel einen Status abbilden) und daraus abzuleitenden/berechenbaren Werten/Aggregaten. EventGroups hat folgende Struktur:

JSON

"EventGroups": [
	{
		"GroupName": required
		"EventCodes": required
		"Computed": [
		 	{
				"Name": required
				"Equation": required
			}
		]
	}
]

Key GroupName: Name (unique) der Gruppe, welcher im Frontend angezeigt werden

Key EventCode: Array von Objekten mit Code und Label, welche Teil der Gruppe sind

Key Computed: Array von Objekten von abzuleitenden/berechenbaren Werten/Aggregaten, mit folgenden Subkeys:

Key Name: Name (unique) des Wertes, welcher im Frontend angezeigt werden

Key Equation: math. Formel zur Berechnung dieses Wertes, mit möglichen Variablen:

timeSumEEVENTCODE: summierte Zeit, für die dieser EventCode aktiv war

Beispiel:

JSON

"EventGroups": [
	{
		"GroupName": "Vacuum Generator Status",
		"EventCodes": [
{
"Code": 1000,
"Label": "pump off"
},
{
"Code": 1001,
"Label": "pump on"
}
],
		"Computed": [
		 	{
				"Name": "Pump Off Time",
				"Equation": "timeSumE1000"
			},
		 	{
				"Name": "Pump On Time",
				"Equation": "timeSumE1001"
			},
		 	{
				"Name": "working Time",
				"Equation": "timeSumE1000 + timeSumE1001"
			},
		 	{
				"Name": "Score",
				"Equation": "timeSumE1001 / (timeSumE1000 + timeSumE1001) * 100"
			}
		]
	}
]

5. SDD für IO-Link Geräte

Für IO-Link Geräte gibt es die Möglichkeit, weitere Informationen (welche nicht in der IODD abgebildet werden) durch die hier spezifizierte SDD zu beschreiben.

Folgende Bereiche können durch eine SDD erweitert werden:

Information über Dokumentationen (Key DocumentationNames in BasicInformation)
Parent-Key „XConfig“
Parent-Key „Reporting“
Parent-Key „Updater“
Parent-Key „MappedIndices“
Parent-Key „EventGroups“
Parent-Key "Events"
- zum Erweitern eines Events aus der IODD sollten nur die Text Cause, Impact, Solution und Remark angegeben werden.
- Ein Event kann auch neu definiert werden, dass gar nicht in der IODD vorhanden ist. Dann muss auch noch mindestens der Type und der Name hier definiert werden.

Dafür soll folgende Struktur benutzt werden:

JSON

{
  "Document": {
    "SDDRevision": erforderlich
  },
  "BasicInformation": {
    "VendorID": required
    "DeviceID": required
    "DocumentationNames": optional
  },
  "XConfig": { optional },
  "Reporting": { optional },
  "XConfig": { optional },
  "Updater": { optional },
  "Events": { optional }
}

Beispiel SDD für IO-Link Gerät VSi

JSON

{
  "Document": {
    "SDDRevision": "1.1"
  },
  "BasicInformation": {
    "VendorID": 234,
    "DeviceID": 100213
    "DocumentationNames": "{\"UsersGuide_EN\":\"VSi-100610-BA-EN.pdf\"}"
  },
  "XConfig": {
    "XIndices": ["140.0","143.0"],
    "AutomaticReadForEvents": true,
    "AutomaticReadForReporting": true
  },
  "Reporting": {
    "Trigger": {
      "type": "event",
      "code": 35872,
      "mode": "APPEARS"
    },
    "YIndices": [{"160.0": "CM"}, {"66.2": "CM"}]
  },
  "Updater": {
    "Interval": 10000,
    "Indices": ["36.0"]
  },
  "Events": {
    "20736": {
      "en": {
        "Cause": "Use of insufficient power supply or voltage drop on cabli…",
        "Impact": "Proper operation of the device cannot be ensured…",
        "Solution": "Check specification of power supply unit…"
      },
      "de": {
        "Cause": "Hoher Spannungsabfall in Zuleitung, Netzteil defekt",
        "Impact": "Ventilfunktion beeinträchtigt, Datenverlust",
        "Solution": "Zuleitung und Netzteil überprüfen"
      }
    }
  }
}

Diese speziellen SDDs für IO-Link-Geräte werden nach folgendem Schema benannt:

<VendorName>-<ProductName>-<Datum>-IOLSDD<SDDrevision>.conf

4. Document revision

21.08.2019	Aktualisierung auf SDD0.3 (neues Namensschema)
04.02.2020	v0.4.0 – Umbenennungen, Umstrukturierung Observation und X/Y-Indices
05.05.2020	v0.4.1 – Attribute FirmwareUpdatePossible hinzugefügt unter BasicInformation
11.05.2020	v0.5.0 – Anpassung / Überarbeitung an implementierte Version
27.05.2020	v0.5.3 – Durchsicht/Korrekturen, Definition Replay.
10.06.2020	v1.0.0 – Korrekturen Benennungen von Replay, Reporting, Updater. Neugliederung OPCUA. Freigabe der Spec als v1.0.0
18.08.2020	v1.1.0 – Erweiterung der Events um Mehrsprachigkeit. Erweiterung IOLSDD um Events
14.01.2021	v1.2.0 – Neuer Abschnitt „MappedIndices“ hinzugefügt
20.01.2021	v1.2.1 – CyclicData wurde wieder aktiviert, nicht mehr deprecated
10.02.2021 10.03.2021	v1.3.0 – Neuer Abschnitt „EventGroups“ hinzugefügt v1.3.1 – EventGroups: EventCodes sind jetzt Objekte mit Code und Label