Hardwareabstraktion in komplexeren Systemen (AVR et al.)

[Axel R. (axelroro)]

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

[Purzel H. (hacky)]

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.

[Axel R. (axelroro)]

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