Die folgenden Typen werden hier besprochen: OpcClient.
Der Zustand der Verbindung zwischen Client und Server ist ausschlaggebend für die Kommunikation zwischen den beiden Teilnehmern. Die Überwachung des Zustands der aktuellen Sitzung/Verbindung kann darüber Auskunft geben, ob eine Anfrage erfolgreich abgesetzt werden kann. Die folgenden Ereignisse ermöglichen hierbei die Überwachung des Clients:
OpcClient.Connected und OpcClient.Connecting
Die genannten Ereignisse werden nur durch den manuellen Aufruf von OpcClient.Connect() ausgelöst und nicht nach einen Verbindungsabbruch, wenn die Verbindung zum Server automatisch wieder hergestellt wurde.
OpcClient.Disconnected und OpcClient.Disconnecting
Die folgenden Typen werden hier besprochen: OpcClient.
Die Konfiguration der OpcClient-Klasse entscheidet über die Aktionen die eintreten, sobald die Verbindung zum Server verloren gegangen ist. Unabhängig von der Ursache des Verbindungsverlusts sind die folgenden Ereignisse ausschlaggebend:
OpcClient.StateChanged
OpcClient.BreakDetected
OpcClient.Reconnecting und OpcClient.Reconnected
Die beschriebenen Ereignisse werden auf der Basis einer KeepAlive-Logik ausgelöst. Ein im verwendeten Stack der OPC Foundation vorhandener Watchdog prüft zyklisch (alle 5 Sekunden) den Status des Servers und stellt dabei den Verlust einer Verbindung spätestens nach 5 Sekunden fest. Wird der Verlust einer Verbindung festgestellt, treten die beschriebenen Ereignisse in Abhängigkeit der Konfiguration des OpcClients in Aktion. Das verwendete KeepAlive-Interval kann über die KeepAlive-Eigenschaft der OpcClient-Klasse geändert werden.
Die folgenden Typen werden hier besprochen: OpcClient, OpcSubscription, OpcMonitoredItem und OpcNotification.
Benachrichtigungen (engl. Notifications) werden vom Client immer in Folge einer aktiven Subscription empfangen. Die Verarbeitungskette einer Notification beginnt beim Handler des zugehörigen MonitoredItem's. Von dort aus wird die Notification an die verantwortliche Subscription und schließlich zum Client der Subscription weitergereicht. Die hierbei behandelbaren Notifications liefern die vom Server erhaltenen Informationen über eine Datenänderung oder eines am Server aufgetretenen Alarm's beziehungsweise Event's.
OpcClient.NotificationReceived
Die folgenden Typen werden hier besprochen: OpcClient, OpcSimpleAttributeOperand, OpcFilter, OpcFilterOperand und OpcAlarmCondition.
Das folgende Beispiel abonniert alle Ereignisse, welche aktuell aktiv, jedoch noch nicht bestätigt worden sind:
var isActive = new OpcSimpleAttributeOperand( OpcEventTypes.AlarmCondition, "ActiveState", "Id"); var isAcked = new OpcSimpleAttributeOperand( OpcEventTypes.AcknowledgeableCondition, "AckedState", "Id"); var filter = OpcFilter.Using(client) .FromEvents(OpcEventTypes.AlarmCondition) .Where(OpcFilterOperand.OfType(OpcEventTypes.AlarmCondition) & isAcked == false & isActive == true) .Select(); var subscription = client.SubscribeEvent("ns=2;s=Machine", filter, (sender, e) => { if (e.Event is OpcAlarmCondition alarm) { Console.WriteLine( "{0}: {1}, IsActive = {2}, IsAcked = {3} ({4})", alarm.GetType().Name, alarm.Message, alarm.IsActive, alarm.IsAcked, alarm.Severity); } });
Unter UWP (Universal Windows Platform) werden Anwendungen wie bei der Entwicklung einer Mobil-Anwendung streng reglementiert. Damit die UWP-App über OPC UA als Client-Anwendung agieren kann, müssen die folgenden „Capabilities“ im Projekt eingestellt werden:
Das zudem benötigte Anwendungszertifikat kann unter UWP nicht automatisch vom OPC UA .NET SDK erstellt werden. Weshalb manuell außerhalb der UWP-Anwendung ein Anwendungszertifikat erstellt werden muss. Dieses Zertifikat kann dann als Teil der Assets
der Anwendung mit ausgeliefert und aus diesen geladen werden. Ein Beispiel, wie ein UWP-Projekt aufgebaut sein könnte ist hier zu finden: OPC UA .NET Samples - UWP Client
Die folgenden Typen werden hier besprochen: OpcServer und OpcNodeManager.
Standardmässig befinden sich alle Nodes, im benutzerdefinierten Namespace mit der Nummer (= NamespaceIndex) zwei. Der Namespace mit der Nummer eins wird vom zugrundeliegenden Stack der OPC Foundation als „Core Namespace“ und als „Application Namespace“ beschrieben. Damit Nodes innerhalb des Namespaces mit dem Index eins verwaltet werden können, muss der benutzerdefinierte OpcNodeManager den Wert der OpcServer.ApplicationUri-Eigenschaft als NamespaceUri verwenden.
Die folgenden Typen werden hier besprochen: OpcServer, OpcAccessControlEntry und OpcSession.
Damit je verwalteten Access-Control-Entry (ACE), also je definierten Benutzer im OPC UA Server, sich ein Nutzer nur einmalig verbinden kann und erst wenn eine aktive Verbindung getrennt wurde wieder eine neue Verbindung hergestellt werden kann, müssen die verfügbaren Endpunkte für den Benutzer blockiert werden solange eine Sitzung des Nutzers aktiv ist. Wie das funktionieren kann ist hier zu sehen:
server.SessionActivated += (sender, e) => { var identityEntry = GetUserEntry(server.Security, e.Session); if (identityEntry != null) identityEntry.Disable(OpcEndpointIdentity.GetCurrent()); }; server.SessionClosing += (sender, e) => { var identityEntry = GetUserEntry(server.Security, e.Session); if (identityEntry != null) identityEntry.Enable(OpcEndpointIdentity.GetCurrent()); }; private static OpcAccessControlEntry GetUserEntry( OpcServerSecurity security, OpcSession session) { var identity = session.UsedIdentity; // In case of anonymous. if (identity == null) return null; return (from userEntry in security.UserNameAcl.Entries let userPrincipal = userEntry.Principal let userIdentity = (OpcUserIdentity)userPrincipal.Identity where userIdentity.DisplayName == identity.DisplayName select userEntry).FirstOrDefault(); }