Funktionsumfang einer KNX-Applikation?!

[evolution]

Ein Tool für ein FW-Update hat ebenfalls enertex für einige Gerätschaften. Dass dies grundsätzlich (wenn vorgesehen) über das KNX-TP möglich ist, ist auch unstrittig. Aber es handelt sich um ein separates Tool oder ein Plugin in der ETS, auch wenn es wie bei Jung im Hintergrund läuft...

[maeckes]

Naja wie und wo das läuft ist ja egal.
Fakt ist, dass diese Art des Updates deutlich entspannter ist.

Auch wenn es 30 Minuten dauert... Ausbauen, wegschicken, ärgern weil weg, warten, einbauen ist definitiv nervender

[evolution]

Mag sein, nur muss man dann eben auch bereit sein, für diese Möglichkeit -sagen wir einmal 30 €- mehr ausgeben zu wollen. Und bei einigen hier sind ja bereits € 100,-- für einen Präsenzmelder zu viel...

Auch sind FW-Änderungen meist (die Ausnahme bestätigt die Regel) mit geringfügigen HW-Änderungen verbunden. Und dann nutzt ein reines FW-Update halt auch nichts mehr.

[MannFred]

Interessantes Thema, nicht wahr!
Und es ist nicht einfach nur schwarz oder weiß!

Es ist durchaus möglich, mit der ETS deutlich mehr als nur Parameter, Adresstabelle, Verbindungstabelle und Kommunikationsobjekte zu laden.
Heutzutage werden bei ca. 95% der KNX-Geräte am Markt jedoch nur einfache Konfigurationen mit der ETS in Geräte programmiert. Also tatsächlich nur Parameter und Kleinkram, was sonst noch dazu gehört. Das macht u,. a. den Download erträglich kurz, denn man muss bedenken, dass die Zeit der schlanken Applikationsprogramme (250 Byte OP-Code) längst vorbei ist! Programme von 100kByte und mehr sind keine Seltenheit. Hört sich jetzt erst mal wenig an, aber programmiert die mal über TP mit 9.600 Bd und mit dem vorgesehenen Protokoll in ein Gerät ein. Da sind 30 Minuten und mehr locker drin. Und das will man nicht wirklich.

Das Applikationsprogramm, also der Programmcode im Gerät, der die Parameter auswertet und die Objekte bedient, befindet sich heutzutage in der Regel im Gerät, wenn es ausgeliefert wird. Der Hersteller hat diesen Teil der Software bereits im Herstellungsprozess einprogrammiert (steht oftmals im Flash).
Dann gibt es noch die "echte" Firmware. Das ist in der Regel die Systemsoftware, die in der BCU läuft und für die Kommunikation zuständig ist. Ich schreibe bewusst "in der Regel", denn das muss nicht immer so sein.
Da heutzutage "Applikation" von "Systemsoftware" kaum noch zu trennen ist, weil sowieso alles nur noch in einem Controller läuft, nennt man das Ganze der Einfachheit halber nur noch "Firmware".

Die ETS differenziert jedoch immer noch das Applikationsprogramm als autarke Einheit. Wie geschrieben enthält die Applikation aus Sicht der ETS heutzutage meist nur noch Parameter und Objekte, das eigentliche Applikationsprogramm, also der OP-Code ist dann in der Produktdatenbank quasi leer. Könnte man aber füllen und nutzen, wenn der Hersteller das so möchte und der verwendete Stack (abhängig von der Maskenversion der Geräte) das überhaupt unterstützt.

Es gab Zeiten, da hat die ETS neben den Paramertern & Co. auch ausführbaren OP-Code (nennen wir das einfach mal Applikationsprogramm) geladen. Das ist noch gar nicht sooo lange her. Einfache Geräte, die auch heute noch mit BCU1/2 & Co. ausgerüstet sind, werden i. d. R. immer noch so programmiert. Muss aber nicht, wenn sich der Hersteller andere Lösungen ausgedacht hat (z. B. econ Plug-In mit FW-Download).
Man kann das also nicht über einen Kamm scheren (was MDT macht, kann Siemens oder Gira schon wieder ganz anders machen). Alle kochen aber nur mit Wasser!

Seit Kurzem geht der Trend aber wieder etwas in die andere Richtung. Das hat zum einen damit zu tun, dass man nicht nur noch TP als Medium hat. Bei IP z. B. geht ein FW-Download deutlich schneller, besonders wenn man das IP Device Management (IP-Direktverbindung der ETS) nutzt. Da dauert ein vollständiger FW-Download "nur" noch wenige Minuten, wenn überhaupt. Es gibt ja schon erste Geräte, bei denen das so möglich ist.
Auch neue TP- oder RF-Geräte können mit Hilfe der ETS "geupdatet" werden. Entweder, weil ein Applikationsprogramm nachgeladen werden kann, oder weil sogar auch die Systemsoftware ausgetauscht oder repariert werden kann. Kein Problem mit der ETS.
Es kann dazu separate Update-Applikationen geben, mit deren Hilfe die ETS einfach OP-Code in die Geräte programmiert. Moderne Kommunikationsstacks nehmen diesen Code entgegen und kopieren ihn intern so um, dass die Applikation oder die gesamte Firmware dauerhaft im Gerät persistiert wird. Hierzu sind Bootloader oder Update-Viren erforderlich, die das handeln.

Alles möglich. Die vielen Hersteller machen das aber immer noch recht unterschiedlich. Das hat auch was damit zu tun, dass nicht alle Hersteller einen eigenen Kommunikationsstack besitzen (der auch zertifiziert ist). Viele kaufen den Stack einfach hinzu und arbeiten so damit, wie es der Quellhersteller vorgesehen hat.

Bleibt spannend, was demnächst noch so kommt!

[DerSeppel]

Manfred hat das Thema gut umrissen.
Es ist halt alles eine Frage des Aufwands und damit auch der Kosten.
Motivation/Verkaufsstrategien spielen sicher auch eine Rolle.

Zuerst mal muss ein geeigneter (Flash)Bootloader auf dem Gerät vorhanden sein. Da man in der Regel den Codeflash nicht zur Laufzeit ändern kann muss das Gerät in einen Zustand gebracht werden in dem der Codeflash des Controllers geschrieben werden kann.
Ich kenne das aus der Praxis so, dass über einen wie auch immer gearteten Stimulus beim Reset des Gerätes der FBL angesprungen wird. Dieser lädt dann eine Toolbox in den RAM des Controllers welche die Applikation zum Schreiben der Software in den Codeflash bereit stellt. Die Software kann vorher in einen gesonderten Speicherbereich kopiert worden sein. Zum Beispiel zur Laufzeit über die ETS. Oder aber von Außen "live" zugeführt werden. Das bedeutet aber dass die entsprechenden Kommunikationsmechanismen im FBL implementiert sein müssen.
Ein anderer Weg ist z.B. ein Boot-Swap. Je nach Controller kann eventuell auch zur Laufzeit eine zweite Sektion im Codeflash geschrieben werden. Danach wird dann im Loader der Booteintrag auf den zweiten Bereich gehängt und die neue Applikation nach Reset angesprungen.

Alle diese Mechanismen sind aufwendig. Da steht ein nicht unerheblicher Entwicklungsaufwand dahinter. Dazu kommen ggf. noch Hardware-Anforderungen an den Mikrocontroller, mehr Speicher, etc.
Nicht zu vergessen: Aufwände für die Absicherung des ganzen. Es soll ja beim Kundenupdate nichts schief gehen was das Gerät unbrauchbar macht. Außerdem soll ja nicht jede beliebige Software auf das Gerät geflasht werden können.

Im Großen und ganzen ist das aber machbar und mit HW und SW Plattformen für Gerätereihen auch ein Aufwand der sich schnell relativiert.

[Andreas1]

MannFred Gibt es von euch eigentlich inzwischen ein Update für das DALI Gateway Plus REG 218000? Bzgl. des Fehlers der Standby-Abschaltung der EVG i.V.m. Szenen meintest du damals, dass man für dieses Gerät ein Firmwareupdate durchführen könnte.

[enertegus]

Ein Tool für ein FW-Update hat ebenfalls enertex für einige Gerätschaften.

Für alle unsere KNX Geräte haben wir diese Möglichkeit geschaffen.

[tuxedo]

Für alle unsere KNX Geräte haben wir diese Möglichkeit geschaffen.

+1 Sehr lobenswert.

[evolution]

Für alle unsere KNX Geräte haben wir diese Möglichkeit geschaffen.

Auch für den ProxyTouch? (Von dem weis ich es nämlich nicht...)

[enertegus]

Auch für den ProxyTouch? (Von dem weis ich es nämlich nicht...)

Logisch. Wie gesagt für wirklich alle, auch für die in der Zukunft.

[trollvottel]

Logisch. Wie gesagt für wirklich alle, auch für die in der Zukunft.

Und war dies ein sehr teurer, aufwändiger und nicht lohnenswerter Aufwand? (Falls ein Verantwortlicher eines anderen Herstellers der dieses noch nicht anbietet liest)

[enertegus]

Und war dies ein sehr teurer, aufwändiger und nicht lohnenswerter Aufwand?

Ich glaube diese Diskussion hier führt in die falsche Richtung. Wir diskutieren ja auch nicht, warum der Schaltaktor nicht in 5er Kanälen gebündelt wird, oder warum die Hardware XY ausgerechnet den Prozessor WZ und nicht den aus der Usersicht den besten Prozessor.

[trollvottel]

Ich glaube diese Diskussion hier führt in die falsche Richtung. Wir diskutieren ja auch nicht, warum der Schaltaktor nicht in 5er Kanälen gebündelt wird, oder warum die Hardware XY ausgerechnet den Prozessor WZ und nicht den aus der Usersicht den besten Prozessor.

Sehe ich anders: Die Frage ist ja mehrfach gekommen, warum die Hersteller das Selberflashen großteils nicht anbieten, dabei wurde dagegengehalten, dass dies zu ermöglichen sehr aufwändig und teuer sei. Worauf dann die Frage an jemand, der dies alles umgesetzt hat doch berechtigt ist, ob das denn wirklich so ist und sich nicht rentiert. Ebenso wurde ja auch mehrfach der Wunsch danach geäußert, dass sowas mehr Verbreitung finden sollte.

[MatthiasS]

Ihr müsst bei der Diskussion vom Haupteinsatzweck ausgehen. Das sind nicht die 5 Aktoren zuhause im EFH eines Freaks. Das Flashen eines Aktors dauert gern mal 30 bis 45 Minuten, es würde schlichtweg nicht genutzt, in einem Gewerbeobjekt das anzuwenden. Da sind die Teile schneller ausgetauscht im Schaltschrank als neu geflasht.

[SeatSLF]

Da muss ich Matthias recht geben, so gern ich zuhause auch einfach gern auf Firmware upgraden würde,
ABER im gewerblichen Umfeld wird das effektiv kaum einer nutzen, geschweige den bezahlen.