NlfKonfig

Remarks in german

Konfigurationsmanagement Dokument von 2001

DEPRECATED Achtung teilweise durch ISOagriNET überholt. Beinhaltet aber Infos, die noch abgearbeitet werden sollten:

1 Einleitung

Dieses Papier dient der Vorstellung eines Vorschlags zur Kommunikation im Bussystem Innennwirtschaft.

Teil 1

Location-Description

Um im Bus die gegenseitige Nutzung von Sensoren, Steuerungs-, und Regelungseinheiten zu realisieren, muß die Umgebung der Units beschrieben werden. Hierzu sollte die Location-Description dienen. Sie sollte 4 - 5 Items umfassen, die den genauen Ort zwei- bzw. dreidimensional festlegen. Im Schweinestall könnte die Ausprägung des Location-Description wie folgt aussehen: ||ITEM || Bezeichnung im Schweinestall ||Bemerkung ||

3 Geräte ID

Jedes Gerät ist werksseitig mit einer Serien ID eingestellt. Dies ist eine eindeutige ID, mit der die Basiskonfiguation beginnen kann. Ist die Serien ID vorhanden, kann das Gerät z.B. seine TCP/IP Adresse über eine voreingestellte MULTICAST Adresse erhalten. Ebenfalls kann dann die Device ID und die Location Description mit dieser Entität festgelegt werden.

Ist diese erste Konfiguration erfolgt, kann jede weitere Konfiguration alternativ über die TCP IP Adresse oder über die Multicast Adresse erfolgen. So können z.B gerätespezifische Parameter über eine Meta Konfig Entität eingeben werden

4 Funktionsbeschreibung

Wir sollten uns genau fragen, was das Gerät wissen muss, um z.B. über Multicast mit den umgebenen Sensoren etc. kommunizieren zu können. Dabei ist zwischen der Frage, wie empfangene Daten interpretiert werden sollten und welche Daten gesendet werden sollen, zu unterscheiden.

4.1 Empfangen

Die Konfiguration des Umgangs und der Verwendung von empfangenen ADIS Daten könnte in folgenden Schritten erfolgen:

4.1.1 Data Dictionary enrichten

Das Anlegen eines kleinen Data Dictionaries könnte z.B. über einen Query beim ADIS Provider erfolgen. Alternativ lassen sich die Daten mit der Device ID an das Gerät schicken (s.a. www.edi agrar.org oder www.lkv wl.de).

DH990001000000000800090000208000900003080009000040600090000624000900009080

VH990001DD 1997 20000418093453LKV Westfalen Lippe e.V lkv

QN19000100888889150DDictionaryN 00190001080ADR2003

ZN Natürlich kann das Data Dictionary oder ein Subset auch schon vorab beim Hersteller eingespielt werden.

4.1.2 Definitionsbeschreibung

Im nächsten Schritt sollten dann die verwendeten Definitionszeilen übertragen werden, die für die Kommunikation benutzt werden, so daß sie nur einmal zur Konfigurationzeit übertragen werden müssen. Diese Konfiguration gilt dann für alle Beteiligten an der Multcast Session. Eine weitere Abstimmung ist dann anschließend nicht mehr erforderlich. Während einer TCP/IP Session können natürlich weiter alle Möglichkeiten von ADIS/ADED genutzt werden.

4.1.3 Anforderungsbeschreibung

Welche Daten wie gefiltert und benutzt werden sollten, kann über eine Filterentität beschrieben werden:

Hiermit wird beschrieben, welche Entitäten von welchem Sender verarbeitet werden sollen. Wann bei ausbleibendem Empfang ein Alarm ausgelöst wird, kann hier auch bereits festgelegt werden. Alternativ kann der Sender über die Sender Device ID oder über die Location Description eingegrenzt werden. Die Angabe der Location Description erlaubt die Definition von Unit Gruppen. Entspricht der Wert des Items "Sender Bucht" einem Stern, so werden alle Zeilen der definierten Entität, die von Units innerhalb der Bucht abgeschickt werden, ausgewertet. Entsprechend wird mit den anderen Kategorien (Betrieb, Stall, Abteil) der Location Description verfahren. Mit diesem Verfahren läßt sich die Übernahme aktueller Daten ausführlich beschreiben. Geht es darum, die Datenverarbeitung aus komplexeren TCP/IP Sessions, wie sie z.B. Queries in Datenbanken darstellen, bietet sich z.B. der Einsatz von Entscheidungstabellen zur herstellerunabhängigen Konfiguration der Geräte an.

$BD01:HMZ1~MUTTER=sW ? :JJJJJNN\

$BD02:HMZ2~MUTTER=sW ? :JJJJNJN

$BD03:HMZ1~ALPHAMUTTER=sW ? :JJNN---

$BD04:HMZ2~ALPHAMUTTER=sW ? :JNJN---

$AK01:HMZ1~MUTTER=0 :XXXX-

$AK02:HMZ2~MUTTER=0 :XXX-X

$AK04:$ET;VVVOMAX.ET; :XXXXX

$AK05:$ET;VVVOGEBX.ET; :XXXXX

In einer weiteren Entität kann die Verarbeitung der übermittelten Items entsprechend beschrieben werden.

Wie diese Entität eingesetzt wird, kann gerätespezifisch definiert werden.

In einer weiteren Entität können dann gerätespezische Aktionen definiert werden

Im Zusammenspiel mit einer Event Entität könnte diese Aktionsentität auch benutzt werden, um nach einem im Netz erfolgten Event über TCP/IP eine komplexere Query/Request Anfrage bei dem Aktionsempfänger/ Partner durchzuführen.

Für TCP/IP Sessions sollte die Anfrage in Datenbanken konfiguriert werden können. Auch hierzu kann die Konfiguration durch eine Entität benutzt werden.

4.1.4 Processing Instruction

M.E. sollte es über eine Processing Instruction möglich sein, jederzeit von jedem Gerät über die MULTICAST Adresse die wichtigsten Konfigurationsparameter wie TCP/IP Adresse, Locations Description etc. anzufordern. Eine andere Processing Instruction könnte genutzt werden, um die Leistungsbeschreibung einer Unit anzufordern. Eine Leistungsbeschreibung könnte beinhalten:

1. welche Aufgaben (Meßaufgaben, Aktionen,

Steuerungsaufgaben) ein Gerät erfüllen kann

2. welche Protokolle (Multicast, TCP/IP) es

implementiert hat

3. ob es Datenbankfunktionen erfüllt

4. ob es Search/Requests oder Queries ... versteht

5. ADIS Protokoll Level

PI`s können auch für andere Steuerungsaufgaben eingesetzt werden (s.a. Proposal N204).

4.2 Senden

In ähnlicher Weise könnte über eine Entität definiert werden, welche Daten in welchem Abstand an die MultiCast Adresse geschickt werden muß.

Eine Sendeaufforderung Entität könnte in ähnlicher Form für das automatische Versenden in einer TCP/IP Session genutzt werden. Hiermit sollten dann benannte Queries oder Search Requests im Abo Verfahren gebucht werden können.

5 Zusammenfassung

Ziel dieser Beschreibung ist es, ein einfach zu konfigurierendes und robust funktionierendes Protokoll für Multicast Kommunikation im Bussystem aufzubauen. Ob eine allgemeingültige Festlegung von Entitäten reicht, kann diskutiert werden. Um hier mehrere, nebeneinander benutzbare Entitäten zu erlauben, gäbe es drei Möglichkeiten:

1. für abweichende Entitätsdefinitionen abweichende

Multicast Adressen verwenden

2. In den Valuezeilen eine führende Spalte zur

Differenzierung einführen

3. Valuezeile mit jeweils vorhergehender

Definitionszeile verschicken.

Über eine TCP/IP Adissession kann natürlich jederzeit mit unterschiedlichenen Definitionen etc. gearbeitet werden, so daß die angeführten Alternativen für die einfache Kommunikation von Meßwerten etc. eigentlich kaum benötigt werden. Den Geräten ist eine möglichst generische Behandlung der Definitions und Valuezeilen zu empfehlen.

In einer weiteren Entität kann die Verarbeitung der übermittelten Items entsprechend beschrieben werden.

Wie diese Entität eingesetzt wird, kann gerätespezifisch definiert werden.

In einer weiteren Entität können dann gerätespezische Aktionen definiert werden

Im Zusammenspiel mit einer Event Entität könnte diese Aktionsentität auch benutzt werden, um nach einem im Netz erfolgten Event über TCP/IP eine komplexere Query/Request Anfrage bei dem Aktionsempfänger/ Partner durchzuführen.

Für TCP/IP Sessions sollte die Anfrage in Datenbanken konfiguriert werden können. Auch hierzu kann die Konfiguration durch eine Entität benutzt werden.

0.0.1 Processing Instruction

M.E. sollte es über eine Processing Instruction möglich sein, jederzeit von jedem Gerät über die MULTICAST Adresse die wichtigsten Konfigurationsparameter wie TCP/IP Adresse, Locations Description etc. anzufordern. Eine andere Processing Instruction könnte genutzt werden, um die Leistungsbeschreibung einer Unit anzufordern. Eine Leistungsbeschreibung könnte beinhalten:

1. welche Aufgaben (Meßaufgaben, Aktionen,

Steuerungsaufgaben) ein Gerät erfüllen kann

2. welche Protokolle (Multicast, TCP/IP) es

implementiert hat

3. ob es Datenbankfunktionen erfüllt

4. ob es Search/Requests oder Queries ... versteht

5. ADIS Protokoll Level

PI`s können auch für andere Steuerungsaufgaben eingesetzt werden (s.a. Proposal N204).

0.1 Senden

In ähnlicher Weise könnte über eine Entität definiert werden, welche Daten in welchem Abstand an die MultiCast Adresse geschickt werden muß.

Eine Sendeaufforderung Entität könnte in ähnlicher Form für das automatische Versenden in einer TCP/IP Session genutzt werden. Hiermit sollten dann benannte Queries oder Search Requests im Abo Verfahren gebucht werden können.

1 Zusammenfassung

Ziel dieser Beschreibung ist es, ein einfach zu konfigurierendes und robust funktionierendes Protokoll für Multicast Kommunikation im Bussystem aufzubauen. Ob eine allgemeingültige Festlegung von Entitäten reicht, kann diskutiert werden. Um hier mehrere, nebeneinander benutzbare Entitäten zu erlauben, gäbe es drei Möglichkeiten:

1. für abweichende Entitätsdefinitionen abweichende Multicast-Adressen verwenden

2. In den Valuezeilen eine führende Spalte zur

Differenzierung einführen

3. Valuezeile mit jeweils vorhergehender Definitionszeile verschicken.

Über eine TCP/IP-Adissession kann natürlich jederzeit mit unterschiedlichenen Definitionen etc. gearbeitet werden, so daß die angeführten Alternativen für die einfache Kommunikation von Meßwerten etc. eigentlich kaum benötigt werden. Den Geräten ist eine möglichst generische Behandlung der Definitions- und Valuezeilen zu empfehlen.

MoinMoin Powered

Immutable page (last edited 2009-01-31 12:25:42 by CPaulsen)

Or try one of these actions: AttachFile, LikePages, LocalSiteMap, SpellCheck