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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.