MP-SS15-02

Aus Verteilte Systeme - Wiki
Wechseln zu: Navigation, Suche

Einführung

In diesem Projekt mit der Eckelmann AG wird ein System entworfen und implementiert, das Maschinendaten am Beispiel einer CNC-Steuerung mit einem für Industrie 4.0 vorgeschlagenen Standard (UPC UA) exportiert und auf einer Benutzeroberfläche für Clients aufbereitet. Die Motivation ergibt sich aufgrund der Evaluierung des Standards OPC UA und der Informationen der Feldebene, die überall und jederzeit verfügbar sein sollen. Außerdem sollen mit Hilfe dieser Informationen Wartung und Ressourceneffizienz verbessert werden. Zusätzlich möchte die Eckelmann AG das Projekt als Messedemonstrator nutzen.

Industrie 4.0

Die vierte industrielle Revolution soll die Informatisierung der Fertigungstechnik vorantreiben. Es existiert keine einheitliche, klare Definition für "Industrie 4.0", da der Begriff viele unterschiedliche Sichtweisen und Bereiche der Industrie umfasst und auch als Schlagwort für Marketing-Zwecke missbraucht wird. Dennoch kann er als eine Zukunftsvision aufgefasst werden, die moderne Internet-Technologien in den Fertigungsprozess integriert und durch den Einsatz von Standards eine herstellerübergreifende Interoperabilität erreichen soll. Durch die Vernetzung aller im Wertschöpfungsprozess beteiligten Instanzen, die idealerweise fähig zur Selbstauskunft sind, entsteht eine flexible Automatisierung, die Produktionsstrategien bis hin zur Losgröße 1 - auch in Massenproduktion - ermöglichen soll.

OPC UA

OPC UA ist ein platformunabhängiger Standard, mit dem Komponenten bzw. Client und Server eines Systems Nachrichten austauschen können und ermöglicht eine robuste Kommunikation, die Identitäten von Clients und Servern sicherstellen und Integrität bzw. Vertraulichkeit gewährleisten kann. Informationen werden von Anwendern über OPC UA-definierte, oder herstellerspezifische Typen spezifiziert und als Objektmodelle in Servern für Clients bereitgestellt. Das standardisierte OPC UA Informationsmodell erlaubt durch Meta-Daten ein dynamisches "Discovery" von Objekten und Methoden eines Servers, sodass Clients nicht zur Übersetzungszeit angepasst werden müssen.

Nachrichten des OPC UA-Protokolls werden auf zwei alternative Arten kodiert:

  • XML/text
  • UA Binary

Es lassen sich drei Transportprotokolle verwenden:

  • OPC UA TCP
  • SOAP/HTTP
  • HTTPS

Address Space Model

OPC UA bietet ein Konzept um Objekte für Clients bereitzustellen, den sog. Address Space. Clients können diesen Address Space durchstöbern und Objekte des Servers abfragen. Die Struktur des Address Space im Server ist ein Graph, dessen Knoten (Nodes) miteinander in Verbindung stehen (References).

Node im Address Space


Folgende acht Node-Klassen werden von OPC UA definiert:

  • Object: (eine Instanz von einem Objekt-Typ)
  • Variable: (eine Instanz von einem Variablen-Typ)
  • Method (eine Methode, die von Clients aufgerufen werden kann)
  • View (eine Untermenge von Nodes, die Client-spezifischen View ermöglicht)
  • ObjectType
  • VariableType
  • ReferenceType
  • DataType


Jedes Objekt im Address Space muss eine Ausprägung einer der o.g. Node-Klassen sein. Clients und Servern ist es also nicht erlaubt, die Node-Klassen zu verändern oder weitere Node-Klassen zu definieren. Für die Erstellung eines anwendungsspezifischen Informationsmodells ist es aber möglich und notwendig, von den bestehenden Typen (ObjectType, VariableType, ...) und den Standard-OPCUA-Typen neue Typen abzuleiten.

Zu den im OPC UA-Standard vordefinierten Typen gehören Server-bezogene Typen (ObjectTypes) mit z.B. Informationen über Diagnose, Konfiguration, oder Capabilities (ServerDiagnosticsType, ServerConfigurationType, ServerCapabilitiesType). Verpflichtend ist die Existenz eines Objekts vom Typ ServerType, das allgemeine Informationen über z.B. Namespaces oder den Status des Servers, sowie Diagnose und Capabilities kapselt. Weiterhin sind primitive Datentypen (DataTypes) wie z.B. String, Boolean, Number (Double, Float, Integer) und abstrakte Objekttypen (ObjectTypes) für die anwendungsbezogene Modellierung definiert.

Beispielsweise existiert ein AnalogItemType, der laut Standard einen analogen Wert darstellt (z.B. eine Spannung, Frequenz oder Geschwindigkeit). Dieser Typ beinhaltet neben dem eigentlichen Wert eine Referenz auf eine Variable vom Typ EUInformation, die semantische Informationen über die physikalische Einheit des Werts bereitstellt. Ein Client, der den Address Space eines Servers durchstöbert und auf ein Objekt vom Typ AnalogItemType trifft, kann so u.a. die physikalische Einheit des entsprechenden Werts in Erfahrung bringen.


Analyse

Anforderungen

Die Anforderungen an das zu entwickelnde System unterteilen sich in funktionale bzw. nicht funktionale und wurden nach Projektbeginn grob festgelegt, mit Freiheitsgraden bei der Auswahl von Standards und Werkzeugen.

  1. Funktional
    1. Benutzeroberfläche soll Informationen einer CNC-Steuerung aufbereiten
      1. Bereich mit Tortendiagrammen
      2. Bereich mit Liniendiagrammen
      3. Aktuelle Prozessdaten als Liste
    2. Informationen der CNC-Steuerung
      1. Wegdaten
      2. Werkzeugeingriff
      3. An/Aus
      4. Energieverbrauch
    3. Informationen der CNC-Steuerung sollen im Intervalltakt aktualisiert werden (5 Sek.)
    4. Informationen der CNC-Steuerung sollen zur eventuellen weiteren Verarbeitung (Archivierung) aggregiert (zwischengespeichert) werden
    5. Informationen der CNC-Steuerung sollen über einen OPC UA-Server abgefragt werden
  2. Nicht funktional
    1. Benutzeroberfläche soll für Desktop-PCs und mobile Endgeräte geeignet sein (responsive)
    2. Ansehnliches Design der Benutzeroberfläche für die Nutzung als Messedemonstrator
    3. Geeignete Frameworks sollen die Aufbereitung der Benutzeroberfläche unterstützen
    4. Unkomplizierte Nutzung: Ein Endgerät soll keine Installationen vornehmen müssen
    5. System muss über viele Geräte zugreifbar sein

Auswahl geeigneter OPC UA-Implementierung

Der OPC UA-Standard ist von der OPC Foundation erstellt worden. Die Ziele der Organisation sind die Standardisierung der industriellen Automation, Zusammenarbeit und Übereinkunft mit führenden anderen Organisationen und Standards der Industrie und Zertifizierung von Implementierungen durch das "Certification and Compliance program".

Es existieren viele OPC UA-Implementierungen, von denen einige kostenfrei sind. Leider besteht ein Großteil der Lösungen nur aus Client und Server oder sie sind nicht von der OPC Foundation zertifiziert. Ebenso stößt man oft auf unzureichende Dokumentationen. Um die Anforderungen des Projekts umzusetzen, ist ein komplettes SDK mit folgenden Features wünschenswert:

  • Client/Server/UA-Stack Implementierung (mit Beispielen)
  • Zertifiziert von der OPC Foundation
  • Platformunabhängig
  • Ausreichende Dokumentation mit Tutorials
  • Client-Browser
  • Modellierungs-Tool für den Server

3S CODESYS Umgebung

Die CODESYS Umgebung von 3S bietet ein Programmiersystem für speicherprogrammierbare Steuerungen (SPS) nach dem IEC 61131-3 Standard, der die Grundlagen von SPSen definiert. Mit der Entwicklungsumgebung können SPS-Programme erstellt und auf beliebige Controller übertragen werden, vorausgesetzt die CODESYS Laufzeitumgebung "CODESYS Control" läuft auf dem Zielsystem.

CODESYS


Es besteht alternativ die Möglichkeit eine Soft-SPS zu verwenden. Hierbei ist nur ein Industrie-PC mit idealerweise Echtzeiterweiterung im Betriebssystem und EA-Bausteinen für die Feldbus-Kommunikation nötig, auf dem das SPS-Programm ausgeführt werden kann. IdR. läuft das Programmiersystem und das Laufzeitsystem der SPS auf dem gleichen System, so ist kein zweiter PC für die Programmierung nötig und es ergibt sich eine höhere Flexibilität.

Die verwendete Version von CODESYS zum Zeitpunkt des Projekts (V3.5 SP6 Patch 2) bietet Soft-SPS-Systeme für z.B. Raspberry Pi und andere Platformen. Für das Projekt wurde die Soft-SPS "CODESYS Control Win" unter Windows eingesetzt. In dem Freigabedokument von CODESYS ist als neues Feature (zum Zeitpunkt des Projekts) die OPC UA-Unterstützung mit sämtlichen Soft-SPS-Systemen angegeben.

Es sollte also möglich sein, den in das Laufzeitsystem integrierten OPC UA-Server der Soft-SPS für den Export der Informationen aus der CNC-Steuerung zu verwenden. Die Analyse ergibt, dass das der Fall ist, aber mit starken Einschränkungen.

Ist ein SPS-Programm in CODESYS erstellt, kann über die sog. Symbolkonfiguration festgelegt werden, welche Prozessvariablen des Programms über OPC bzw. OPC UA exportiert werden sollen. Das Programmiersystem integriert so automatisch einen OPC UA-Server in den Code der Steuerung. Die Symbolkonfiguration ist für Benutzer einfach zu bearbeiten und auf "Knopfdruck" sind Variablen des Steuerungsprogramms für OPC UA-Clients abrufbar. Diese einfache Bedienung ist effektiv, erweist sich aber als Nachteil, da keine Möglichkeit der detaillierten Konfiguration der Symbole besteht.

CODESYS Symbolkonfiguration


Mit dem OPC UA-Browser "UaExpert" von Unified Automation kann der Address Space des CODESYS OPC UA-Servers durchstöbert werden. Die Variablen sind zugreifbar und deren Werte werden korrekt angezeigt. Hier spiegelt sich die einfach zu bedienende Symbolkonfiguration wider, da das Informationsmodell von OPC UA nur teilweise genutzt wird: Primitive Datentypen (Integer, Float, Double, ...) sind für die Variablen hinterlegt, und auch im Modell des Servers enthalten, wobei komplexere Datentypen (z.B. Arten von ObjectTypes) - die im Standard vorgegeben sind - fehlen. ObjectTypes für Server-spezifische Strukturen und das obligatorische Server-Objekt vom Typ ServerType sind vorhanden. Der OPC UA-Server von Unified Automation hingegen implementiert das Informationsmodell vollständig.

CNC-Steuerung

Die CNC-Steuerung EXC 88 von Eckelmann ermöglicht die Echtzeit-Kommunikation mit Antrieben und I/O Peripherie in zahlreichen Anwendungen, wie z.B. Drehen, Fräsen, Bohren, Schneiden etc. Sie gehört zu den Steuerungen der High-End-Klasse mit innovativem CNC-Kern und unterstützt 32 CNC-Achsen mit umfangreichem Befehlsvorrat.

Technische Daten:

  • Zentraleinheit
    • CPU: 32-Bit-Microcontroller
    • Programmspeicher: bis zu 1 GB Flash
    • Arbeitsspeicher: 256 MB RAM.
  • Schnittstellen
    • CAN-Bus, CANopen Port
    • Standard-Ethernet
    • Echtzeit-Ethernet (EtherCAT)
    • USB
    • Slot für SD-Karte


Für den Zugriff auf CNC-bezogene Prozessvariablen und Funktionen der Steuerung ist eine von Eckelmann entwickelte Bibliothek (mmictrl.dll) verfügbar.

Aggregation der Maschinendaten

Die Informationen der CNC-Steuerung sollen von dem OPC UA-Server geholt und zwischengespeichert werden, um eine Archivierung zu ermöglichen und zusätzlich eventuelle weitere Verwendungen der Daten außerhalb des Projektrahmens nicht auszuschließen. Gute Performance und Flexibilität sollen darüber hinaus erreicht werden. Wenn eine Anwendung mit Web-Interface für jeden Client-Request bis auf die Ebene der CNC-Steuerung zugreifen und evtl. durch I/O blockieren muss oder durch Fehler der Steuerung aufgehalten wird, ergibt sich kein lose gekoppeltes, stabiles System.

Die klassische Lösung über eine Zwischenspeicherung in einer konventionellen Datenbank scheint für den Anwendungsfall passend zu sein, noch besser eignet sich aber ein Message Queueing System (MQS), da nur bestimmte Mengen von Informationen (z.B. die letzten 300 Werte) für die Anwendung relevant sind. Außerdem kann das MQS die Daten bei Bedarf in einer Datenbank speichern und beliebige andere Anwendungen können über das MQS Informationen abfragen oder abonnieren. Ein In-Memory Key-Value-Store wie z.B. Redis mit einfacher Schnittstelle und besserer Performance als konventionelle DBMS stellt sich als optimale Technologie heraus.

Web-Frameworks

Um die Benutzeroberfläche ansehnlich zu gestalten und die Entwicklung zu erleichtern gilt die Vorgabe, etablierte Web-Frameworks zu verwenden. Für nahezu jede Skriptsprache gibt es eine Reihe von Web-Framworks. Für die Auswahl eines konkreten Produkts werden die Programmierfähigkeiten in der Skriptsprache, sowie die allgemeine Beliebtheit unter Entwicklern als Kriterien herangezogen. Das web2py-Framework eignet sich bestens für Erstellung der Webanwendung (Model-View-Control-Stil, schnelle Einarbeitung, Bossie Award 2011 für beste Open Source Development Software, Technology of the Year award - 2012 - von InfoWorld).

Für die Darstellung einer responsive-Weboberfläche wird das JavaScript-Framework jQuery Mobile verwendet, damit Clients - ob Smartphone, Tablet oder PC - ein ansprechendes, passendes Design erhalten.

Die Webseite beinhaltet Kuchen- bzw. Liniendiagramme, für deren Darstellung das Framework Chart.js verwendet wird. Es ist einer der wenigen JavaScript Frameworks, die kostenfrei nutzbar sind und ansprechend aussehen.


Design

Architektur

Gesamtarchitektur

Die Architektur des Systems ist im Schaubild dargestellt. Die orangefarbenen Pfeile stellen den Fluss der Maschinendaten dar und die Kästchen sind Systemkomponenten.

Die Steuerung EXC880 von Eckelmann (1) übernimmt die Bedienung der verbundenen Maschine, indem sie CNC- bzw. SPS-Programme abarbeitet und Antriebe steuert, die z.B. über CAN-Bus oder EtherCAT angeschlossen sind. Diese Programme laufen in der CODESYS Runtime (2).

Der Industrie-PC (9) führt einen OPC UA-Server (3) aus, der die CNC-Maschinendaten mit Hilfe einer Funktionsbibliothek für ein proprietäres Protokoll von der Steuerung abfragt und für Clients wie Komponente 4 bereitstellt.

Die Komponenten 4 und 5 setzen sich zu einer Instanz zusammen, die vom OPC UA-Server exportierte Variablen zyklisch abfragt und in den "In-Memory Key-Value-Store" Redis (6) abspeichert. Der OPC UA-Client (4) wird von einem Skript (5) verwendet, das diese Aufgabe übernimmt. Dieses Aggregation Script wird über die Komponente 8 konfiguriert. Es kann z.B. festgelegt werden, welche OPC UA-Variablen denn vom Server geholt werden sollen.

Der Web Server (7) bezieht die Maschinendaten von dem Redis Server (6). Er kennt die Konfigurationsparameter aus 8 des Aggregation Scripts (5) und weiß, welche Informationen vom Redis Server zu holen sind.

Modellierung der CNC-Maschine

In dem OPC UA-Server soll ein Modell der CNC-Maschine vorhanden sein. Idealerweise sollen die Informationen aus Anforderung 2 aus dem Analyseteil verfügbar sein. Energieverbrauchswerte z.B. können über die Schnittstelle zwischen Industrie-PC und Steuerung nicht direkt abgefragt werden und die Funktionen sind stark CNC-Programm-orientiert. Daher beinhaltet das vereinfachte Modell der Maschine (CNCType) zunächst einen Event für den Werkzeugeingriff (ToolEngage), einen Zähler für die vergangenen Sekunden seit dem Start der Steuerung (Uptime) und für die X-, Y- und Z-Achse die jeweilige Position.

Mit dem Modellierungstool "UaModeler" von Unified Automation kann das Modell für den Server erstellt, bearbeitet und generiert werden.

Modell für CNC-Maschine

Implementierung

OPC UA-Server

In den folgenden Code-Beispielen sind wichtige Ausschnitte aus dem OPC UA Server zu sehen. Hier soll deutlich werden, wie der generierte Code des UaModeler im Server verwendet werden kann.

 1 CNCM::NodeManagerCNCModel *nm;
 2 
 3 static void createNodeManager(OpcServer* pServer) {
 4 	
 5   // create NodeManager
 6   nm = new CNCM::NodeManagerCNCModel(OpcUa_True);
 7 
 8   // add NodeManager
 9   pServer->addNodeManager(nm);
10 
11 }

Der Server braucht einen NodeManager (1), der die definierten Typen aus dem Modell verwalten kann. Die Funktion createNodeManager() erstellt den NodeManager (6) und fügt ihn dem Server hinzu (9).


 1 CNCM::CNCType* cncmachine;
 2 
 3 static void createInstances() {
 4 
 5   // create Instances
 6   cncmachine = new CNCM::CNCType(UaNodeId("CNCMachine", nm->getNameSpaceIndex()), // NodeId
 7                                  "CNCMachine", //Name
 8                                  nm->getNameSpaceIndex(), // Name space index
 9                                  nm
10   ); 
11 
12   nm->addNodeAndReference(OpcUaId_ObjectsFolder, cncmachine, OpcUaId_Organizes);
13 
14 }

Um Instanzen zu erstellen, ist nur der Konstruktor des Objekttypen nötig. Das Objekt wird erzeugt (6-10) und dem NodeManager nm hinzugefügt (12). Dabei wird über Parameter angegeben, unter welcher Node das Objekt eingehängt werden soll (in diesem Fall in den "Objects"-Ordner).


 1 // loop read until user shutdown
 2 while (ShutDownFlag() == 0) {
 3 
 4   // read axis information
 5   mmi->readParam(h, ADDRESS_AXIS_POSITION, nvalues, axis);		
 6 
 7   // read uptime 
 8   mmi->readParam(h, ADDRESS_UPTIME, nvalues, uptime);
 9   
10   // update OPC UA variables
11   cncmachine->setUptime((int) uptime[0]);
12   cncmachine->setXAxis(axis[0]);
13   cncmachine->setYAxis(axis[1]);
14   cncmachine->setZAxis(axis[2]);
15 
16   // sleep 500 ms
17   UaThread::msleep(500);
18 
19 }

In der Hauptschleife des Servers können die Objekte bearbeitet werden. Die Attribute werden zyklisch im Takt von 500 ms aktualisiert. Zuerst wird die Position der Achsen über die Methode readParam von der EXC880-Steuerung gelesen (5) (das mmi-Objekt kapselt die Schnittstelle zwischen Industrie-PC und Steuerung). Zusätzlich wird die Uptime von der Steuerung gelesen (8) und in den Zeilen 10-14 das Objekt mit den Prozessdaten aktualisiert.

OPC UA-Client

Der OPC UA-Client wird von dem Aggregation Script verwendet und soll als Modul zur Verfügung stehen. Damit das Modul im Script verwendet werden kann, muss zunächst die Schnittstelle (opcclient.h) für ein Programmierwerkzeug beschrieben werden, das den "glue code" zwischen Script- und C++-Code erstellt. SWIG (Simplified Wrapper and Interface Generator) ist ein solches Tool, das C/C++ Module für andere Sprachen verfügbar macht. SWIG benötigt die Schnittstellenbeschreibung "opcclient.i" als Eingabe.

 1 %module opcclient
 2 %{
 3   #include "opcclient.h"
 4 %}
 5 
 6 class OpcClient : public UaSessionCallback {
 7 
 8 public:
 9   OpcClient();
10   virtual ~OpcClient();
11 
12   // OPC UA service calls
13   int connect(char *);
14   int disconnect();
15   UaVariant *readNode(char*, int);
16   UaString *getEUInformation(char*, int);
17 };
18 
19 class UaString {
20 public:	
21   const char *toUtf8();
22 };
23 
24 class UaVariant {
25 public:	
26   int toDouble(double& OUTPUT);
27 };

Die Datei "opcclient.i" für SWIG beinhaltet die Beschreibung der OpcClient-Schnittstelle (8-17). Sie ist in diesem Teil identisch mit der Header-Datei "opcclient.h". Für den Verbindungsauf- bzw. abbau gibt es die Methoden connect() und disconnect(). readNode() liest einen Knoten aus dem Address Space des Servers und getEUInformation() holt einen String, der die physikalische Einheit einer Variable beschreibt. UaString-Objekte sind Strings aus der OPC UA-Bibliothek und müssen ebenfalls (minimal) beschrieben werden (19-22), damit das aufrufende Skript sie zumindest als einen Null-terminierten String interpretieren kann (mit der Methode toUtf8()). UaVariant-Objekte aus der OPC UA-Bibliothek sind generische Objekte und haben Methoden zum Konvertieren in bestimmte Datentypen (z.B. toInt32(), toBool(), toDouble(), ...), da beim lesen mit readNode() viele verschiedene Typen zurückgegeben werden können. Für das Projekt ist zunächst nur die Konvertierung in den Typ Double nötig. Um mehr Methoden von UaVariant zu nutzen, muss nur die Signatur - wie für toDouble() - entsprechend beschrieben werden.


swig -Wall -c++ -python opcclient.i

SWIG generiert den Wrapper-Code (opcclient_wrap.cxx), der anschließend mit dem opcclient.o zu einer dynamischen Bibliothek ("_opcclient.so") gelinkt wird.


In einem Python-Script kann die Bibliothek dann importiert und verwendet werden:

 1 # import opcclient python module
 2 import opcclient as opc
 3 
 4 # create OpcClient Instance
 5 client = opc.OpcClient()
 6 
 7 # connect to test server
 8 client.connect("opc.tcp://192.168.56.1:48010")
 9 
10 # read EngineeringUnit information from specific Node
11 euinf = client.getEUInformation("CNCMachine.XAxis.EngineeringUnits", 2)
12 
13 # close connection
14 client.disconnect()
15 
16 # print result
17 print '\nDescription of CNCMachine.XAxis.EngineeringUnits: ' + euinf.toUtf8()

Die Ausgabe sieht wie folgt aus:

Connecting to opc.tcp://192.168.56.1:48010
Connection status changed to Connected
Connect succeeded
Read ...
Disconnecting ...
Connection status changed to Disconnected
Disconnect succeeded

Description of CNCMachine.XAxis.EngineeringUnits: millimetre

Aggregation Script Konfiguration

 1 {
 2 
 3   "uaserver": "opc.tcp://192.168.56.1:48010", 
 4 
 5   "sets": [
 6     {
 7       "name": "testset",
 8       "items": ["x", "y", "z"],
 9       "interval": 1,
10       "avg": 5,
11       "n": 30
12     }
13   ],	
14 
15   "vars": [
16     {
17       "name": "x",			
18       "id": "CNCMachine.XAxis",
19       "ns": 2,
20       "n": 10
21     },
22 
23     {
24       "name": "y",
25       "id": "CNCMachine.YAxis",
26       "ns": 2,
27       "n": 10
28     },
29 		
30     {
31       "name": "z",
32       "id": "CNCMachine.ZAxis",
33       "ns": 2,
34       "n": 10
35     },
36 
37     {
38       "name": "up",
39       "id": "CNCMachine.Uptime",
40       "ns": 2,
41       "n": 10
42     }
43   ]
44 
45 }

Für das Aggregation Script wird festgelegt, welche Variablen von welchem Server abgefragt werden sollen. Die Konfiguration in JSON-Syntax besteht aus drei Teilen:

uaserver (3)
Die Endpunkt-Adresse des OPC UA-Servers
sets (5-13)
"sets" sind Mengen von Variablen, die in "items" (8) angegeben sind. Die Variablen von einem set werden alle zyklisch zum gleichen Zeitpunkt aktualisiert, wobei das Interval in Sekunden in "interval" (9) festgelegt ist. Wenn das Element "avg" (10) > 1 ist, werden avg gelesene Werte aufsummiert und zu einem Wert gemittelt. "n" (11) ist die Länge der Queue, die die Werte aggregiert.
vars (15-43)
vars sind OPC UA-Variablen, die im 2-Sekunden-Takt gelesen werden. Die OPC UA Node ID wird in "id" (18) angegeben, der OPC UA Namespace mit "ns" (19) und die Länge der Queue mit "n" (20).

JSON Chart Beschreibung

 1 {
 2   "pies": [
 3     {
 4       "name": "Test",
 5       "pieData": [
 6         {
 7           "color": "#CFA",
 8           "label": "Test",
 9           "value": "x"
10         },
11         {
12           "color": "#ABC",
13           "label": "Test",
14           "value": "y"
15         }
16       ]
17     }
18   ],
19 
20 
21   "graphs": [
22     {
23       "name": "Test",
24       "set": "testset",
25       "datasets": [
26         {
27           "pointHighlightStroke": "rgba(220,220,100,1)",
28           "label": "x",
29           "pointHighlightFill": "#fff",
30           "fillColor": "rgba(200,250,220,0.1)",
31           "pointColor": "rgba(220,220,100,1)",
32           "strokeColor": "rgba(220,220,100,1)",
33           "pointStrokeColor": "#fff",
34 					"data": ""
35         },
36         {
37           "pointHighlightStroke": "rgba(220,20,100,1)",
38           "label": "y",
39           "pointHighlightFill": "#ff5",
40           "fillColor": "rgba(200,250,20,0.1)",
41           "pointColor": "rgba(220,20,100,1)",
42           "strokeColor": "rgba(220,20,100,1)",
43           "pointStrokeColor": "#ff5",
44 					"data": ""
45         },
46         {
47           "pointHighlightStroke": "rgba(220,220,220,1)",
48           "label": "z",
49           "pointHighlightFill": "#f11",
50           "fillColor": "rgba(100,0,20,0.1)",
51           "pointColor": "rgba(220,220,220,1)",
52           "strokeColor": "rgba(220,220,220,1)",
53           "pointStrokeColor": "#f11",
54 					"data": ""				
55         }
56       ]
57     }
58   ],
59   
60   "info": [
61 		{
62 			"name": "x",
63 			"value": "x"
64 		},
65 		{
66 			"name": "y",
67 			"value": "y"
68 		}, 
69 		{
70 			"name": "z",
71 			"value": "z"
72 		},
73 		{
74 			"name": "Uptime in Sek",
75 			"value": "up"
76 		}
77 	]
78 
79 }

Die Konfiguration für die Weboberfläche, also welche Diagrammtypen mit welchen Variablen dargestellt werden sollen ist wie die Aggregation Script Konfiguration im JSON-Format und unterteilt sich ebenfalls in drei Teile. Für nähere Informationen zu den einzelnen Elementen siehe Dokumentation von Chart.js.

pies (2-18)
Definition der Kuchendiagramme
graphs (21-58)
Definition der Liniendiagramme
info (15-43)
Definition von Name-Wert-Paaren, die als Liste angezeigt werden sollen

Screenshots

Sektion Kuchendiagramme


Sektion Liniendiagramme


Sektion Info