Hallo Forum,
ich poste das einmal im Forum uC&Elektronik. Bei mir geht es zwar
konkret um eine Hausautomatisierung mit AVR (Atmega), ich denke jedoch,
dass ist ein generelles Thema in jedem Verbund von miteinander
kommunizierenden Modulen.
Die Fragestellung:
Wie eine möglichst sinnvollen Hardwareabstraktion (HAL) zu erreichen,
wenn mehrere Module (eigenständige uC's) miteinander kommunizieren, um
Sensoren mit Aktoren zu verbinden. Das übergeordnete Objekt ist in
meinem Fall ein Haus, welches über mehrere eigenständig agierende AVR
Module (Binäreingang, Binärausgang, Webserver, Temperaturregelung,
Jalosiensteuerung, Scenensteuerung usw.) verfügt - beisst Euch bitte
aber nicht daran fest - könnte auch eine komplexere Maschinensteuerung
sein).
Wie die Kommunikation stattfindet (I2C, RS485, etc.) und auch das
Protokoll auf dem lower level sollen nicht das Thema sein.
Anforderungen sind:
1) Speicherbarkeit des HAL in einer relationalen DB
Diese läuft auf einem PC und stellt das Objekt Haus in menschenlesbarer
(konfigurierbarer) Struktur dar. Z.B. hat das Objekt Haus Objekte vom
Typ Raum mit einem Objekt Taster mit einem Objekt "Eingang" eines
"Sensormoduls" verbunden, welches Signale generiet (z.B. Ein, Aus, Temp
25C). Das Sensormodul hat also Signale, ggfs. mit Parametern, die
wiederum mit dem "Aktormodul" und dessen "Zuständen" (z.B. Ein, Aus,
aber auch PID_Regler(Parameter..) verbunden sind, welche dann mit einem
weiteren Aktormodul (z.B. Relais) mit dem Objekt "Lampe", "Thermomodul",
etc. verbunden ist. Diese Objekte sind wiederum in Raum x des Objekt
Hauses, usw.
(an betrachte dies als optional - die Aufgabe kann auch auf Pos 2)
reduziert werden.
2) Tabelle zur Steuerung der AVR Module ins EEPROM (oder Header file)
Von obiger Information dient vieles nur der Visualisierung - für die uC
Module ist nur ein kleiner Teil (Object, Signal(Parameter...) bzw.
Object, Zustand(Parameter ...)) interessant. Man stelle sich einfach
vor, dass eine PC DB Anwendung die für die uC Module notwendigen
Strukturen über die wie-auch-immer geartete Kommunikation überspielt.
Und zwar nur diese, da die Module ja auch hinsichtlich Speicher
limitiert sind. Es soll aber nun nicht auf allerletzte Platzoptimierung
ankommen.
Man könnte sich auch alternativ vorstellen, dass ein Default-Header
generiert wird, der diese Struktur festschreibt - dann eben zur
Compilezeit und Einspielung über Bootloader.
3) Steurerung im AVR (oder ähnlich) Modul
Hier sollen nun je nach Aufgabenstellung die generierten
Steuerungstabellen abgearbeitet werden, sei's die in einem Header
vorliegenden oder die zur Laufzeit ins EEPROM programmierten Strukturen.
Natürlich geht es nicht ganz ohne Hardwarenahe Funktion - ein 1-wire
Temperatursensur oder ein PID-Regler ist natürlich nicht 100%
abstrahierbar.
Spätestens jetzt denken viele an EIB/KNX - ok, tatsächlich ist die dort
im Projektierungstool abgelegte Strukture eine Möglichkeit für Pos 2 u.
3.
Mich hat jedoch auch die objektorienterte Struktur in Qt mit "Slots" und
"Methoden" beeinflusst. Die Steuerung mit Tabellen wird zum Beispiel
auch in SAP angewendet, um ganze Unternehmensstrukturen abzubilden.
Nun die Frage, welche Erfahrungen und Meinungen hierzu in der Community
vorliegen - welche komplexeren HAL Lösungen mag es geben (Google spukt
wie immer eine Unzahl von nicht unbedingt passenden Themen raus), welche
Ansatzpunkte zur Abstraktion mag es geben, usw. Z.B. gibt es ein
universelles Metamodell, in dem man die konkrete Modellierung darstellen
kann, etc.? Wie gesagt, die Ansätze sollen nicht auf Hausautomatisierung
beschränkt sein, das ist hier nur ein Beispiel.
Lasst mal hören.
Gruss
Axel
HAL ist etwas fuer MHz prozende Stromfresser. Ja, man kann aus einem
UART ein file machen, und dann mit 9 Prozessen probieren ein Protokol
abzuspulen.
Alternativ denkt man sich besser ein flexibles Protokol aus, das
beliebige Komponenten einbinden kann und deren Anzeige, Menu und
Eingabeparameter enthaelt.
Hallo Hacky,
ich sehe da nicht unbedingt den Widerspruch. Klar würde man nicht auf
den uC's die komplexe Abbildung des 'Systems' aus Punkt 1) umsetzen,
sondern daraus ein auf das Minimum reduziertes Modell ableiten, was ja
in 2) angesprochen ist.
Es geht ja mehr um eine Strukturierung der Daten, die man eh braucht,
und zwar in einer Weise, die eben so weit wie sinnvoll generalisiert
ist.
Mag ja sein, dass ich das zu kompliziert beschreibe, und man sich da
jetzt was intergalaktisches vorstellt - eigentlich geht es mir aber
einfach darum, die Objekte der Realwelt wie Schalter, Thermometer,
Windmesser, Sonnenscheinintensität, Luftfeuchte auf der einen Seite und
die Objekte, die daraus was machen, also Ein-Aus-Aktor, Zeitsteuerung,
PID Regler, usw. möglichst universell in einer Struktur abzubilden, so
dass es nicht mehr wichtig ist, ob es sich bei dem Objekt um x oder y
handelt. Beispielhaft - Anstelle zu sagen es gibt einen Schalter, der
kann EIN oder AUS - dann zu sagen, es gibt ein "Objekt", mit "Signalen"
und "Attribut" (o.ä.). Z.B. ein Objekt kann dann Typ "Taster" mit Signal
"PIN1" und Attribut "Ein"/"Aus"/"LANG-Ein"/"LANG-AUS" oder eben auch ein
Typ "Thermometer" it Signal "Temp1" (z.B. im Wohnzimmer) und Attribut
"25C" sein. Wenn man das hat, mappt sich das auf Objekt "Binärausgang"
mit "Zustand" Ausgang1 (z.B. Lampe im Wohnzi) und Attribut
"EIN"/"Toggle" usw. sein. Diese (halbwegs" universelle Struktur suche
ich.
Gibt es in die Richtung keine Überlegungen?
Grüsse
Axel
