[OS-HB] (XML-) Objektbeschreibung

[Ithamar G. (antimon)]

Info: Dieser Thread gehört zum Wiki-Artikel Hausbus Diskussion

Fortsetzung vom Thread "[OS-HB] PC-Steuersoftware"

Von Reinhard kam folgender Vorschlag bezüglich einer Knotenbeschreibung
in XML, welche folgende Struktur haben könnte:

---

<?xml version="1.0" encoding="iso-8859-1"?>
<HPCS Name="Local">
<Connections>
<HPC ID="23" Name="xyz" ConnTyp="SER" Localisation="Heizung"
NetPath="1.2.4.5">
    <Var Name="s0" Value="0" Typ="Bool" />
    <Var Name="s1" Value="-1" Typ="Bool" />
    <Var Name="s2" Value="-1" Typ="Bool" />
    <Var Name="temp1" Value="23" Typ="int" />
    <Var Name="LCDOut" Value="Hallo Welt" Typ="String" />
    <Var Name="s5" Value="-1" Typ="Bool" />
  </HPC>
  <HPC ID="13" Name="otto" Localisation="Kueche"
NetPath="1.1.7">
    <Var Name="s0" Value="0" Typ="Bool" />
    <Var Name="s1" Value="-1" Typ="Bool" />
    <Var Name="s2" Value="-1" Typ="Bool" />
    <Var Name="temp1" Value="23" Typ="int" />
    <Var Name="LCDOut" Value="Hallo Welt" Typ="String" />
    <Var Name="s5" Value="-1" Typ="Bool" />
   </HPC>
</Connections>
</HPCS>

---

Den prinzipiellen Aufbau finde ich okay, für XML wäre ich auch, da
einfach zu erweitern, gut zu bearbeiten etc.
Über Aufbau und Inhalt müsste man noch ein wenig diskutieren, denke
ich.

Prinzipiell bin ich der Meinung, dass es eine XML-Objektdatenbank geben
sollte, bei der jeder Objekttyp durch eine eigene Datei dargestellt
werden sollte, z.B. "schaltknoten.xml", "temperatursensor.xml"
etc.

Neben den oben schon vorgeschlagenen Elementen fände ich eine
Beschreibung des Knotens im Klartext praktisch.
Beim Netpath (soll vermutlich die Adresse darstellen) sehe ich noch
Diskussionsbedarf, der aber nicht hier in diesen Thread passt - das ist
eher Sache des Übertragungsprotokoll. Hier fände ich eine nachrichten-
und adressorientierte Verbindung praktisch, aber mehr dazu im
Protokoll-Thread. Das Ergebnis könnte man dann hier einfliessen
lassen.

Vielleicht könnten wir hier erst mal ein Brainstorming machen, welche
Informationen ins XML einfliessen sollen, wenn wir das dann haben,
besprechen wir wie wir das in XML strukturieren, was meint Ihr dazu?

[and_ref (Gast)]

@reinhard:
Kannst du mal mit ein paar Worten erklären, 1.) was man allgemein aus
dem XML-Dokument entnehmen können soll und dann 2.) was dein Beispiel
konrekt beschreibt?

Ich bin auch gerade dabei meinen Bus in eine virtuelle und auf den PC
abbildbare Struktur zu fassen (C#/.net). Mit XML (bzw. dessen Vorzüge)
kenne ich mich leider (noch) nicht aus. Vielleicht kannst du anhand des
angehängten Screenshots kurz erläutern, ob meine Busstruktur/Parameter
usw. durch deinen XML-Ansatz prinzipiell beschrieben werden können,
oder ob es da zu große Abweichungen gibt. Ich kann deinen Ausführungen
leider noch nicht ganz folgen - wäre aber an einem universellen Ansatz
interessiert.

[Ithamar G. (antimon)]

Ich habe mir mal ein paar Gedanken gemacht, wie man die XML-Dateien
gestalten könnte:

Einerseits sollte eine globale Objekt-Datenbank vorhanden sein, die
alle möglichen Knotentypen beschreibt. Die liegt für alle verfügbar auf
einem Server und ist an die Hardware, also die Platine, sowie an die
Firmware des Knotens gebunden. Wenn wir also zusammen einen
Schaltknoten entwickeln, sollte es dafür eine XML-Beschreibung geben,
was der Knoten leisten kann, welche Daten er bereitstellt, etc.
Wird eine neue Firmware entwickelt, gibt es auch eine neue
XML-Beschreibung dazu. Welche Datei zu welchem Knoten gehört, könnte
man in die Firmware einbauen.

Dann wäre folgendes Szenario denkbar: Man baut sich einen Knoten anhand
der Schaltpläne im Internet auf und spielt die Firmware drauf. Die
Software scannt den Bus, findet eine neue Hardware und lädt sich anhand
der ID in der Firmware die passende Knotenbeschreibung vom Server
(sofern diese nicht schon vorhanden ist) und stellt den neuen Knoten
auf der Oberfläche da, der nun konfiguriert werden kann.

Natürlich soll man die Firmware auch selbst bearbeiten können, da
müsste man halt ein Flag einführen, dass nun die Beschreibung nicht vom
Server geladen wird, sondern lokal bereitgestellt wird.

Wenn man nun den Knoten konfiguriert, müssen die Einstellungen ja auch
abgespeichert werden, damit die Konfigurationsoberfläche die
Einstellungen kennt. Natürlich könnte sie sie auch immer beim Start aus
dem Bus auslesen, aber das denke ich ist unnötiger Overhead und sollte
nur ab und zu bzw. auf Anfrage geschehen.

Diese XML-Config (quasi eine Instanz von der Knotenbeschreibung)
braucht natürlich noch zusätzliche Eigenschaften, die vielleicht
getrennt im XML-File beschrieben werden können und jedem Knoten im Bus
zugeteilt werden. Also wenn ich beispielsweise 3x einen Schaltknoten
habe, existiert für jeden Knoten eine eigene Datei, da jeder Schalter
eine eigene Adresse hat, evtl. einen Namen, also Informationen die nur
im lokalen Netz wichtig sind.

Mein Vorschlag für die globalen Knotenbeschreibungen wäre:

- Name
- Beschreibung
- XML-Dateiversion
- ID (zum Verlinken von XML-Datei und Firmware)
- Fähigkeiten des Knotens (müssen noch aufgeschlüsselt werden)
- Informationen, die der Knoten preisgeben kann (auch Aufschlüsselung
nötig)
- etc.

Daten für die Instanzen (also die lokalen evtl. mehrfach vorhandenen
Knoten):

- Name
- Ort
- Adresse bzw. ID
- Firmware-Version
- Beschreibung
- feste Einstellungen (z.B. Schwellwerte für Temperaturschalter, etc.)
- etc.

Diese Daten können für jeden Knoten abgeändert werden, sind also
beschreibbar, die Fähigkeiten des Knotens sind ja für alle Knoten
dieser Art gleich und können deshalb aus der oberen Datei ausgelesen
werden.

Was haltet Ihr von den Ideen? Es sind nur grobe Vorschläge, die noch
sehr verfeinert werden müssen, können aber zumindest schon mal einen
Überblick verschaffen, wie das Ganze aussehen könnte...

[reloni (Gast)]

@andref

>1.) was man allgemein aus
>dem XML-Dokument entnehmen können soll
Mein Beispiel war eigentlich nur als kurzes Beispiel gedacht
xmlunkundigen einen Eindruck einer xmlStruktur zu geben.
dementsprechend habe ich es in 2min hingeschrieben ohne großen Anspruch
auf Projektrelevanz oder gar Vollständigkeit.
Die eigentlichen Prozessrelevanten Inhalte/Elemente zu ermitteln sind
das Ziel dieses threads.
++++++++++++++++++++++++++++++++++++++++++++++++++++
2.)
nochmal die kurze Beispiel erklärung aus dem Original Thread


DokumentElement <HPCS>:
HomeProzessControllerServer, repräsentiert die Abbildung des Netzes,
ist sozusagen das BasisObjekt Steuersoftware ,
Name =lokal auf rechner, denkbar das noch andere Remoteserver
vorhanden
sind wie Name="RemoteServer1" oder "134.456.235.768"

ChildElement <Connctions>
Auflistung mehrerer Childelemente vom Typ HPC-
HomeProzessController(Anm. in abgrenzung zur PLC/SPS für
Industriesteuerungen)

ChildElement <HPC>
Repräsentiert eine einzelne HPC
Als Attribute werden die spezifizierten unbedingt erforderlichen
Eigenschaften wie ID und ConnTyp übergeben.
ConnTyp "SER" könnte hier für ser COM verbindungstehen weiterhin
wäre
sinnvoll noch CAN und "W"LAN weiterhin ist zu überlegen ob hier auch
die Vebindungsparameter wie portnr baudrate settings stehen sollten
oder ob auf ein extra objekt referenziert wird.
!!Gleichzeitig könnte dieses HPC element so auch als Format für den
Nachrichtenaustausch verwendet werden!!!! evtl als attribut noch
Empfängeradresse einfügen



cHILDeLEMENT <Var>:
repräsentiert optionale Umgebungsvariablen der einzelnen Controller
es können beliebig viele eingefügt werden.


++++++++++++++++++++++++++++++++++++++++++++++
>Vielleicht kannst du anhand des
>angehängten Screenshots kurz erläutern, ob meine
>Busstruktur/Parameter
>usw. durch deinen XML-Ansatz prinzipiell beschrieben werden können,

so zBsp könnte dein Ansatz via xml formal beschrieben werden. (Ohne
Anspruch auf inhaltliche Richtigkeit)
<?xml version="1.0" encoding="iso-8859-1"?>
<HPCS Name="Local">
<Connections>
   <Knoten ID="122" Name="Knoten122" ConnTyp="SLK"
Localisation="Wohnzimmer Beschreibung="Wohnzimmerlampen">

      <Vars>
         <Var Name="AnzahlResets" Value="651" Typ="int"
Access="RW" Unit="h"  />
         <Var Name="Uptime" Value="2345126" Typ="long"
Access="RW" Unit="s" />

    </Vars>
    <Ports>
  <Port Portname="Dimmer0" ID="L104" PTyp="DA" GTyp="Taster">
              <Port Portname="Taster0"   ID="T102" PTyp="IO"
GTyp="Dimmer">

   </Ports>
</Knoten>
<Knoten ID="123" Name="Knoten123" ConnTyp="SLK"
Localisation="Terasse" Beschreibung="Wohnzimmerlampen ...">

      <Vars>
         <Var Name="AnzahlResets" Value="651" Typ="int"
Acces="RW" Unit="h" ... />
         <Var Name="Uptime" Value="2345126" Typ="long"
Acces="RW" Unit="s" .../>
..
..
            </Vars>
    <Ports>
  <Port Portname="Dimmer0" ID="L104" PTyp="DA" GTyp="Taster">
              <Port Portname="Taster0"   ID="T102" PTyp="IO"
GTyp="Dimmer">
..
..
   </Ports>
</Knoten>
<Knoten.........
</Knoten>
</Connections>
</HPCS>

[reloni (Gast)]

@ithamar
>Über Aufbau und Inhalt müsste man noch ein wenig diskutieren, denke
>ich.
ein wenig ist milde ausgedrückt...


>Prinzipiell bin ich der Meinung, dass es eine XML-Objektdatenbank
>geben sollte, bei der jeder Objekttyp durch eine eigene Datei
>dargestellt werden >sollte , .B. "schaltknoten.xml",
"temperatursensor.xml" etc.

wie meinst du dies:  Jedes Objekt eine eigene Datei??
Ein Sinn der Xml Darstellung liegt in der Strukturierungsmöglichkeit
durch Verschachtelung - wie willst du eine Baumstruktur mit einer
anzahl gleichberechtigter xml-Dateien darstellen??

oder meinst du zu jeden Typ (zusätzlich zur xml-Baumstruktur)nochmal
eine zusätzliche xml-Beschreibung??

>Neben den oben schon vorgeschlagenen Elementen fände ich eine
>Beschreibung des Knotens im Klartext praktisch.

ja unbedingt. Allerdings würde ich diese nicht als xml-attribut
 einfügen (....beschreibung="bla bla"/>) sondern als innertext
element
( <HPC id=..... > Bla Bla </HPC>) also zwischen Haupt Tag und einen
zusätzlichen Terminierungs Tag einfügen. Dies hätte den Vorteil das
auch längere Beschreibungen problemlos (bezüglich "" )und leserlich
eingefügt werden können.
Dies gilt übrigends für alle Elemente , also auch für Variablen und
andere noch zu kreierenden Inhalte.

Reinhard

[Ithamar G. (antimon)]

Äh Baumstruktur? Ich meine eigentlich nur ein Element, eine Hardware.

Also quasi die Beschreibung eines Busknotens in seinen Fähigkeiten. Was
kann das Teil und wie kann ich es ansteuern.

Bei der Beschreibung des Netzes oder so bin ich noch gar nicht, mir
gehts jetzt erst mal um die (noch nicht verdrahteten) Elemente.

[reloni (Gast)]

>Äh Baumstruktur? Ich meine eigentlich nur ein Element, eine >Hardware.
>Also quasi die Beschreibung eines Busknotens in seinen Fähigkeiten.
>Was
>kann das Teil und wie kann ich es ansteuern.

>Bei der Beschreibung des Netzes oder so bin ich noch gar nicht, mir
>gehts jetzt erst mal um die (noch nicht verdrahteten) Elemente.

Äh - unter "Baumstruktur" meinte ich jetzt folgendes

HPCS
|
|---Connections
    |-----HPC1
    |     |
    |     |-----oblVar1
    |     |
    |     |-----oblVar2
    |     |-----optVar3
    |     |-----udefVar4
    |
    |
    |-----HPC2
    |     |
          |-----Var1
    |     |
    |     |-----Var2
    |     |-----Var3
     |
     |-----HPC3
     |
     |-----HPC4

und das ganze sollte meiner Meinung nach in einer xmlDatei abgebildet
werden. (Dabei verstehe ich unter HPC(HomeProzessController) wohl das
was du als BusKnoten bezeichnest. Ich differenziere hier noch zu
anderen Knotentypen wie Repeater, Switche,Koppler usw. welche anders
behandelt werden sollten.)

Wie stellst du dir die Aufteilung in mehrere Dateien vor?