-
Notifications
You must be signed in to change notification settings - Fork 1
Softwarekonzept
- Stromsparende Mikrokontroller
- Wenig Speicher und Rechenleistung für die Software
- Individuelle Hardware und Nutzeranforderungen
- muss mit wenig Resourcen zurecht kommen
- muss für individuelle Nutzeranforderungen geeignet sein
- einfache Konfigurierbarkeit
- Testbar
- Simulierbar
- einfache Fehlerdiagnose
Die besondere Herausforderung in diesem Projekt entsteht insbesondere durch die individuellen Nutzeranfoderungen. Dadurch, dass jedes System anderen Komponenten und Informationen verarbeiten muss, und die Resourcen beschränkt sind, ist für jedes System eine eigene Software nötig. Diese Software muss sich aus den Anforderungen des Systems ableiten.
Die Zielsetzung muss daher sein, eine Softwarearchitektur zu entwickeln, die es ermöglicht, dass der Anwender durch eine Konfiguration, eine auf Ihn zugeschnittene Software für sein System erhält. In der Praxis ist diese Lösung mit einer SPS (System Programmierbare Steuerung) zu vergleichen. Es liegt also nahe, auch Open Sourcs SPS Lösungen, im Vergleich zu dem hier vorgestellten Konzept, zu untersuchen.
Das Konzept basiert auf einer sehr einfach Herangehensweise. Es gibt nur zwei Dinge, die es zu beachten gibt:
- Signale : welche Informationen sollen im System existieren
- Units : welche Einheiten gibt es, die diese Signale verarbeiten
Aus diesen zwei Anforderungen an das System wurde der Name des Konzepts "SigUni" abgeleitet.
Wie sieht das nun in der Praxis aus? Der folgende Graph zeigt die Zusammenhänge:
Signale ---> Units -|--> Codegenerator -|--> Software für das System
Es gibt also einen einfachen Zusammenhang. Der Anwender des Systems (hier WomoLIN) muss die Signale definieren, die für Ihn als Anwender wichtig sind. Dann verknüpft er diese Signale mit Einheiten, die vom System zur Verfügung gestellt werden. Ein Tool erzeugt dann aus diesen Informationen die Software für das System.
Sämtliche Beschreibungen und Definitionen erfolgen in XML. Dieses wiederum wird über ein XML Schema validiert, damit der Anwender immer sicher sein kann, eine gültige XML Datei zu erfassen. Im späteren Entwicklungsstand, kann auch eine eigenen Andwendung für das Verfassen der XML Dateien programmiert werden. Die Verwendung von XML stellt eine moderne und flexible Lösung dar, die rein textbasiert ist.
Im folgenden ist jeweils ein Beispiel für ein Signal und für eine Unit dargestellt:
<signal>
<type>onoff</type>
<name>light_onoff</name>
<description>Licht ein- und ausschalten</description>
</signal>
<unit>
<name>relay_k1</name>
<open>
<signal>light_onoff</signal>
<value>on</value>
</open>
<close>
<signal>light_onoff</signal>
<value>off</value>
</close>
</units>
Es gibt vordefinierte Signatypen im Sytem. Einer davon ist der Signaltyp "onoff". Wie der Name schon sagt, kann dieses Signal den Wert "on" oder "off" annehmen. Jedes Signal im System bekommt einen Namen vom Anwender, hier "light_onoff". Über eine Beschreibung kann der Nutzer später seine Signale genau identifizieren.
Jedes Signal macht nur sinn, wenn es mit einer unit verbunden ist. Hier in diesem Beispiel gibt es eine Unit "relay_k1". Dieser Unit ist in der Lage Signale vom Typ "onoff" zu verarbeiten. Weiterhin verfügt die Unit über zwei Eigenschaften, hier "open" und "close" Diese Eigenschaften müssen über den Anwender mit den Signalen verbunden werden. In unserem Beispiel, öffnet das Relay, wenn es das Signal "light_onoff" mit dem Wert "on" empfängt. Es schliesst, wenn es das Signal "light_onoff" mit dem Wert "off" empfängt.
In dieser Art und Weise, wird das gesamte System, durch den Anwender definiert.
Nachdem das System über die Signale und Units definiert ist, werden die XML Dateien über einen Codegenerator interpretiert und in C++ Code gewandelt. Der C++ Code wird dann zu der finalen Soft- und Firmware kompiliert. Durch dieses vorgehen, erhält das System einen individuelle und performante Software. Der Codegenerator wird über die Programmiersprache Python realisiert.
Die Main Unit ist das Herzstück des Systems. In der Main Unit laufen alle Informationen zusammen, da die Main Unit die physikalischen Schnittstellen für, z.B. das Wohnmobil, hat. Die Main Unit kommuniziert über eine serielle Schnittstelle. Über diese Schnittstelle werden die Signale von und zu der Main Unit gesendet. Es ist möglich, dass mehere Teilnehmer z.B. mehrere Displays an diese Schnittstelle angeschlossen werden.
Das System hat keine besonderen Anforderungen an die Benutzeroberflächen, egal ob Web oder Embedded Display. Alles ist individuell umsetzbar. Einzig die Signale müssen von den Benutzerinterfaces empfangen und gesendet werden können. Daher ist es sinnvoll, wenn auch die Bedieneinheiten von den XML Dateien ableiten. Sowohl Design, als auch Verhaltensweisen der Bedienheiten können individuell durch den Anwender vorgegeben werden.
Die komplette Entwicklung erfolgt nach modernen Vorgehensweisen, wie Docker, Versionskontrolle, Unit Tests usw. Das Basissystem ist Linux. Aber auch Windows und Mac sollte möglich sein.
Die Umgebung lässt es zu, dass viele Entwickler gleichzeitig entwickeln können. Über das offene Softwaredesign ist es auch möglich, dass jede neue Hardware eingebunden werden kann.