Skip to main content
Skip table of contents

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

 

 

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.

Contact Support Close