KNX ohne Hardware simulieren - wie bei SPS

[Tessi]

Da es einem aber nur einen wirklichen Nutzen bringt, wenn man das komplette System simulieren kann, bestünde diese "Firma" Simulation aus allen KNX-Komponenten-Liferanten zusammen. Alle Gerätehersteller müssten ein Simulationsmodell genauso liefern, wie das für die ETS-Konfigurationsdatei der Fall ist. Dafür gibt es derzeit aber einfach keinen Anreiz.
Falls es je mal einen KNX-Nachfolger geben wird, mag bei diesem eine Simulation von vornherein vorgesehen und ggf. für die Hersteller verbindlich vorgegeben sein. Bei KNx ist das alles nie vorgesehen gewesen, deshalb glaube ich nicht, das es je kommen wird.

[lo4dro]

Ich habe das so vorstellt.

Es gibt die "Firma" Simulation, die auch unterschiedliche Aktoren hat, eben jene welche die simuliert werden.

Auf einem PC läuft diese Simulation und hat einen Buskoppler.
Auch in der Simulation muss man die Aktoren anmelden wie an echten Aktoren.
Anschließen werden die GAs übertragen und an der Simulation kann getestet werden.
Das es das nicht geben wird, ist mir schon klar, da sich nimand bereit erklärt die Kosten zu übernehmen und frei Programmierer werden wohl keine Changse haben, da es seitens der ETS diese Firma nie geben wird.
Alle wollen wie immer nur Dollars blinken sehen. Das sieht man schon an der extrem hohen Kosten für eine Software die jeder zwingen benötigt.
Es ist halt Profimaterial für den Gewerblichen Einsatz und kein "Baumarkt" Material für den Heimwerker.

[Tessi]

Die ETS programmiert die Geräte nun einmal nicht. Sie kann zwar neue Software in die Geräte flashen, kennt aber deren Funktion nicht. Was mit der ETS gemacht wird, ist die Zusammenstellung der Konfigurationsdaten. Nur kennt die ETS nicht die Bedeutung der Parameter die sie dann an die Geräte überträgt. Sie "versteht" also nicht, was dahinter steckt, wenn verschiedene Kommunikationsobjekte per GA verbunden werden. Daher sind diese Inforationen für eine Simulation nicht austeichend.
Vereinfacht gesagt, die ETS weis gar nicht, was ein Taster oder Aktor ist. Die Funktion der Parameter muss der Anwender kennen, die ETS verwaltet sie nur.
Ein Emulator braucht also weit mehr Informationen als die ETS ihm liefern kann. Woher sollen die aber kommen? Der "normale" Anwender dürfte damit überfordert sein, die Hersteller würden das nur liefern, wenn es auch bezahlt wird. Da es bislang keiner liefert, ist es auch kein Kaufargument, denn für den Anwender nützt es ja nur etwas, wenn fast alle und nicht nur ein paar Exoten dabei mitmachen. Der Anreiz für einen Hersteller, als erster das anzubieten geht also gegen Null. Das ist einer der wenigen Nachteile, wenn ein System nicht von einem einzigen Anbieter kommt und daher jeder lieber anderen das Risiko des ersten Schrittes überlassen will.

[lo4dro]

Ich verfolge den Beitrag schon eine Weile.
Sicherlich wäre es wünschenswert das auf Hardwareebene simuliert würde.
Da werden aber die wenigsten Hersteller ihre Daten preisgeben oder selber etwas entwickeln.

Aber würde es nicht reichen, wenn die Simulation auf Funktionsebene stattfinden würde? (die ETS Programiert dabei die Emulation)
Ich drück den simulierten Schalter und die Simulierte Lampe geht an.
So macht das ja jeder Aktor und Sensor erst einmal. Wenn man die Basis Programiert ist, kann man sicherlich die viele Zusatzfunktionen dazu Programmieren.
Der Vorteil den ich hier sehe, ist das man die GAs wie man sie in der ETS4 Programmiert testen kann. Und wenn man es schaft, das die Ethernetschnittstelle auch technisch funktioniert. Kann man die Visu und externe Logik testen.

[Tessi]

Man muss doch nicht gleich den Subprozessor simulieren. Es reicht, die KNX Baugruppe als Blockbox zu sehen mit Input und Output-Kanälen, das ganze in einer Automatensprache spezifiziert und in den Simulator eingefügt. Das Automatenmodell muss vom Hersteller kommen und dem tatsächlichen entsprechen. Dann würde auch endlich die leidvolle Versuch- und Irrtumperiode beim Bearbeiten eines neuen Produktes verringert werden, bis man verstanden hat, was die Dokumentation meint.

Gruß Micha

Leider gibt es mittlerweile Geräte, deren Plugin Teile des Applikations-Codes gemäss der jeweiligen Konfiguration neu erstellen, kompilieren, linken und laden. Da müsste dann auch das Automatenmodell gleich mit neu erzeugt werden. Das ist den Herstellern aber zu aufwendig. Könnte man den Original-Code nutzen, sähe das anders aus, setzt aber eben Simulatoren auf Binärcodeebene voraus.
Ausserdem müsste man bei extra Automatenmodellen bei jeder Änderung prüfen, ob Model und Gerät sich tatsächlich genau gleich verhalten, simuliere ich die Hardware, mus ich das nur bei deren Änderung tun, und das kommt seltener vor.
Ausserdem ist es bei einem rein logischem Modell ungleich schwieriger, das Timngverhalten genau abzubilden, oft ist das gar nicht so genau bestimmt worden. Ein Emulator weicht da i.d.R. nicht vom Original ab.
Gleiches gilt auch für Bugs...

[Gaston]

Alles richtig
Aber ich finde das nicht "leider" sondern einen Fortschritt das ich mich nicht mehr zwangsweise mit den BCU1/2 aus den 1980gern rumschlagen muss

Das "Leider" bezog sich ja auch auf die erhöhte Schwierigkeit sprich "Aufwand", die dies bei der Simulation bringt.

Allerdings muss man sich ja heute eh nicht mehr zwingend mit der BCU1/2 rumschlagen.

Gruss,
Gaston

[Micha]

Man muss doch nicht gleich den Subprozessor simulieren. Es reicht, die KNX Baugruppe als Blockbox zu sehen mit Input und Output-Kanälen, das ganze in einer Automatensprache spezifiziert und in den Simulator eingefügt. Das Automatenmodell muss vom Hersteller kommen und dem tatsächlichen entsprechen. Dann würde auch endlich die leidvolle Versuch- und Irrtumperiode beim Bearbeiten eines neuen Produktes verringert werden, bis man verstanden hat, was die Dokumentation meint.

Gruß Micha

[Tessi]

Aber leider verhindert das eben eine generische Simulation zu entwickeln, zu verschieden sind die Geräte dadurch geworden, und letztlich auch zu leistungsfähig, um ein ganzes System auf einem PC zu simulieren.
Ohne generische Module ist die Entwicklung von gerätespezifischen Simulationsmodulen schlicht zu aufwendig und teuer, das kann kein Eli/Bauherr und will kein Hersteller leisten.

Ich kann vielleicht einen C64-Emulator entwickeln und Dutzende Instanzen davon mit verschiedenen Programmen parallel auf einen entsprechend leistungsfähigen Rechner laufen lassen, aber ich kann nicht Dutzende verschiedener Emulatoren entwickeln, um damit einen heterogenen Rechnerverbund zu simulieren, das ist einfach zu viel Aufwand.

[makki]

Leider haben viele Geräte aber noch einen 2. Prozessor ..

Alles richtig
Aber ich finde das nicht "leider" sondern einen Fortschritt das ich mich nicht mehr zwangsweise mit den BCU1/2 aus den 1980gern rumschlagen muss

Makki

[Gaston]

Ein Simulationsprogramm macht einfach keinen Sinn, da die ETS keine "Programmierung" macht, sondern nur eine reine Verbindung von Sensoren und Aktoren ist.

Das ist so nicht ganz richtig. Das wäre so als würde man sagen es macht keinen Sinn einen C64 Emulator auf dem PC zu entwickeln da der PC keine Spiele Programiert.

Auch die ETS lädt die Applikation in das Gerät. Würde es nur BCU 1&2 Geräte geben die den PEI benutzen so könnte man durchaus einen Emulator schreiben der diese Geräte simulieren könnte.

Leider haben viele Geräte aber noch einen 2. Prozessor der die eigentlichen Aufgaben übernimmt der entweder fest "verdrahtet" ist oder per Plugin mit einer Firmware geladen wird. Hier ginge es dann nicht ohne Unterstützung vom Hersteller. Allse in allem ist das Ratio Nutzen/Aufwand m.E. viel zu Gross.

Kleine Annekdote am Rande: Ich habe vor ca. 14 Jahren mit dem Gedanken gespielt ein grosses GNU Projekt rund ums Thema CPU/Assembler/Emulation und HW zu starten hab letzlich aber den Aufwand aus Zeitmangel gecheut. Dieses Projekt hätte die Entwickelung eines KNX Simulators drastisch vereinfacht.

Gruss,
Gaston

[makki]

Nun so ein Simulator (nennen wir es mal "test") hätte schon was - für Entwickler (wer unter der EITT leidet würde dafür seine Seele verkaufen )

Für normale Anwender aber völlig sinnlos..

Makki

[anlo007]

Hallo Fritzkarte,

Ein Simulationsprogramm macht einfach keinen Sinn, da die ETS keine "Programmierung" macht, sondern nur eine reine Verbindung von Sensoren und Aktoren ist.

Wenn du dir den Bergiff "Guppenadresse 1/2/3" jeweils übersetzt in "Schaltbefehl 1/2/3" dann ist das ganze einfacher zu verstehen.

Der Lichtschalter "Türe links (=1.1.3)" soll das Licht ein und ausschalten;
also sendet er für "EIN" - Schaltbefehl 1/2/3 ; EIN- und für "AUS" - Schaltbefehl 1/2/3 ;AUS- das ist alles und so einfach ist alles. Wenn es 2 Schalter für dasselbe Licht gibt, senden halt beide ihre Information. Welcher Schaltbefehl als letzter gesendet wurde, dessen Zustand gilt bis zum nächsten Schaltbefehl.

Mit der ETS legt man eigendlich nur fest, welche "Schaltbefehle" vom Lichtschalter; Sensor; etc. gesendet werden und auf welche "Schaltbefehle" die Relaisausgänge, Aktoren Rolloschalter etc. hören und reagieren sollen.

Ein bischen mehr oder weniger Logik ist in den Sensoren und Aktoren verbaut, manchen können Treppenlichtfunktionen, oder , und evtl auch Zeitfunktionen oder Strommessung, das liegt aber am Hersteller der Komponenten und dafür muß man sich deren "Applikationsprogramm" für das spezielle Gerät ansehen, das könnte eine Simulationssoftware nicht wissen, da dies von Hersteller zu Hersteller und Modell zu Modell variiert.

[Tessi]

Lies den Thread bitte noch einmal genau durch, so lang ist er ja noch nicht.
Es ging ursprünglich darum, mit den Daten, die man in die ETS eingeben muß, um eine reale Anlage zu konfigurieren, zuvor einen Simulator zu füttern, und mit diesem dann - im Heimbereich wohl hauptsächlich interaktiv - zu testen, ob die reale Anlage später dann genau so reagieren würde, wie man das beabsichtigt hat. Und das es Anwender, also Laien sind, die das tun würden, und nicht die Geräteentwickler, denn die bauen keine Anlagen damit auf.

So eine Simulation muss also so leicht zu bedienen sein, wie die ETS selbst. Also ohne Programmierkenntnisse und ohne das man selbst Modelle für die zu simulierenden Geräte erstellen muss. Für die ETS bekommt man die notwendigen Daten ja als Datei vom Gerätehersteller. Da es aber für die Simulation nichts mit der ETS vergleichbares gibt, gibt es auch keine Hersteller-Modelle. Und da bislang schon alle Versuche gescheitert sind, eine Alternative zur ETS zu entwickeln, sehe ich für ein von fleißigen Hobbyprogrammierern entwickeltes Simulationssysten ziemlich schwarz, denn das ist noch weit schwieriger zu realisieren als ein ETS-Klone.

Aber ich werde der Letzte sein, der versuchen wird, Dich davon abzuhalten, es dennoch zu versuchen...

Vielleicht steckt in Dir ja ein zweiter Linus Torvalds...
Oder wenigstens ein zweiter Bill Gates...

[TheCore]

Simulator für KNX ist sehr wohl möglich

Ein Simulator muß ja nur EIB/KNX sprechen. Die Maschine dahinter soll ja nur bestimmte Situationen abdecken und entsprechend reagieren - Eine solche State-Machine mit eigener Intelligenz muss natürlich vom Tester mit Daten gefüttert werden. Habe schon früher Simulatoren geschrieben. Daher weiß ich, dass das es nicht so schwer ist wenn mann Entwickler ist. TCL hat sich als sehr hilfreich in solchen Situationen erwiesen. Letzten Endes ist es egal was als Datengenerator dahinter steckt - kann auch Excel sein - wichtig ist nur das der Output stimmt.
Also nur mut - ich warte auch schon länger dass endlich mal einer die Zeit findet den zu schreiben.

[enertegus]

Ich bräuchte einen Simulator, um es vorher zu testen ... der EibPC ist, so wie ich es verstehe, etwas für den Nachgang.

Sorry, dann habe ich nicht verstanden, was genau Du willst.