Basic Services

The basic services can be implemented on top of a variety of enabling technologies (OPC UA, HTTP+JSON, CoaP, …). The assumptions (e.g. stateless communication) may be overriden by implementations as long as the interaction mechanisms described here remain in place. Specialized services may require additional assumptions.

Assumptions

Packet based communication; Flexible packet size

An upper packet size may be negotiated / enforced by the underlying transport layer Client / Server

Clients initiate the connection; Servers provide access to services and hold an internal information model Asynchronous communication

Client requests can be answered in any order and with any time delay (if no QoS overrides the policy); Requests contain an identifier that is used to match the response No QoS assumed a priori

QoS guarantuees need to be negotiated / queried at runtime (e.g. during the startup phase of a connection) Stateless connection

The service signature does not rely on the connection being stateful. However, implementations may enforce stateful secure connections / sessions to “tunnel” the invocation of stateless basic services. Information Model

Information is organized in a hierarchy of objects; Objects have components (variables, methods, other objects); Object types may enforce the existence of specific components; Changes to the information model at runtime are not required. Objects and variables have a unique identifier (URL, integer, …) within the context of the server Datatypes

Minimally supported datatypes (for variables and method arguments)

• Integers and floating point values (one type with at least 32bit precision)
• Strings
• Structures (named type-tuples, may contain scalars of any datatype and arrays)
• Arrays of any datatypes (1-dimensional, array of array is possible)"

Services

Discover

Get a list of (local) service providers (optionally filtered for a particular type of service) Connect / Disconnect

Connect to the server (optionally via a secure connection) CRUD

Create/read/update/delete; Transports representations of (virtual or physical) resources Call

Invoke a method via a remote procedure call Introspection

The serverside information model can be fully introspected. This includes the description of variables, components ofobjects and object types, method signatures, custom datatypes and access rights of the current user.

Subscriptions

Subscriptions are negotiated push delivery of content by the server. This can be - data changes of a variable - events (eminating from a variable or an object) that may have complex datatypes attached

Assumptions

Stateful connection

Servers hold per-connection state in order to deliver content with push mechanisms. No transport QoS a priori

QoS guarantuees for subscriptions, such as

• at least one notification delivery
• at most one notification delivery
• exactly one notification delivery

as well as reaction times and throughput are not assumed and need to be negotiated

Services

Create / Delete subscription

Setting data acquisition terms of a subscription

• Samping Interval
• Preprocessing (e.g. averaging)
• Event filter"

Historical Data Access

Historical Data refers to old variable states

• data changes of a variable
• events (eminating from a variable or an object) that may have complex datatypes attached

Services

HistoryRead / HistoryUpdate

Interaktionsschemata zur Nutzung von Diensten

One-Way

• Dienstnutzer und Dienstleister besitzen unterschiedliche Kommunikationsfähigkeiten:
  • Der Dienstnutzer schickt Anfragen
  • Der Dienstleister empfängt und bearbeitet Anfragen

• Der Dienstaufruf ist unidirektional, d.h. der Dienst gibt keine Rückmeldung auf den Aufruf.

• Antwort auf unterlagerten Ebenen der Kommunikation ist möglich, welche aber allenfalls Aus-kunft über erfolgreiche Zustellung gibt

• Fehlerfälle können durch den Dienstnutzer mit diesem Interaktionsschema nicht erkannt wer-den.

Anwendungsfälle

• Anstoßen von Vorgängen und Prozeduren in der Prozessführung ggf. mit Rückmeldung über den physikalischen Prozess.

• Zyklisches Übertragen von Zustandsabbildern.

• Zyklische Aufträge mit kurzer Gültigkeitsdauer.

Two-Way

• Dienstaufruf mit einer erwarteten Antwort innerhalb desselben Anwendungskontexts.

• Die Dienstschnittstelle ermöglicht Kommunikation in beiden Richtungen.

• Dienstnutzer und Dienstleister besitzen unterschiedliche Kommunikationsfähigkeiten:
  • Der Dienstnutzer schickt Anfragen und kann Antworten auf seine Anfragen annehmen (synchron/asynchron). Er ist nicht zwingend in der Lage, andere Nachrichten als diese Antworten anzunehmen.
  • Der Dienstleister empfängt und bearbeitet Anfragen und antwortet dem Dienstnutzer mit genau einer Antwort auf jede einzelne Anfrage.

• Typischerweise erwartet der Dienstnutzer die Antwort zeitnah, dies muss jedoch nicht so sein.

• Die Dienstbeschreibung macht Angaben darüber, wie der Dienstleister damit umgeht, wenn die Antwort nicht erfolgreich zugestellt werden kann, z.B. Nichterreichbarkeit.

Anwendungsfälle

• Datenabfragen

• Ausführen von Berechnungen

• Aufträge mit Ergebnisrückmeldung

Response Subscription

• Es gibt genau eine Anfrage durch einen Dienstnutzer und mindestens zwei Antworten durch den Dienstleister an den Dienstnutzer.

• Bedingungen und Inhalte der Antworten werden durch die Dienstbeschreibung und den Dienst-nutzer festgelegt. Beispielsweise ob das Senden von Antworten in entweder in regelmäßigen Zeitintervallen oder durch spontane Ereignisse ausgelöst wird.

• Der Dienstleister überprüft das Zutreffen der Bedingungen und sendet proaktiv die Antworten.

• Antworten des Dienstleisters sind dem ursprünglichen Aufruf zuordenbar.

• Die Dienstbeschreibung gibt Auskunft darüber, wie der Dienstleister mit einer Nichterreichbar-keit des Dienstaufrufers umgeht.

• Die Bedingungen, unter denen der Dienstleister keine Antworten mehr an den Dienstnutzer sendet, werden ebenfalls in der Dienstbeschreibung festgelegt. Typischerweise muss der Dienstnutzer eine weitere Nachricht schicken, um den Dienst „abzubestellen“.

Anwendungsfälle

• Langlebige Aufgabe mit Zwischenmeldungen

• Messwertüberwachung

• Grenzwertüberwachung, durch Änderungen ausgelöst wird

Double One-Way

• Dienstnutzer und Dienstleister besitzen gleiche Kommunikationsfähigkeiten, d.h. beide Teil-nehmer können Anfragen senden und bearbeiten.

• Dieses Schema wird insbesondere bei Organisationsformen ohne a priori festgelegte Rollen als Klienten und Server verwendet.

• Der Dienstnutzer bleibt während der Interaktion gleich, die ausführende Einheit, die die Rolle des Dienstleisters einnimmt, kann im Verlauf der Interaktion wechseln. Beispiel: Einheit A nimmt zunächst den Auftrag eines Nutzers an und leitet ihn dann ohne Kenntnis des Nutzers an eine andere Einheit B weiter. Nach Fertigstellung des Auftrags erhält der Nutzer Rückmeldung von Einheit B.

• Dienstnutzer kann eine einzelne Antwort dem Dienstaufruf zuordnen.

Anwendungsfälle

• Suchanfrage an ein Netzwerk

• Peer to Peer Kommunikation

• Der Dienstleister ist während der Ausführung des Dienstes nicht erreichbar und sendet die Ant-wort in einem anderen, neuen Kommunikationskontext.

• Vereinbarungen über das Antwortverhalten des Dienstes liegen nur informell vor.