Zukunft Gebäudesteuerung

[meudenbach]

Man hat das mit der Coax-Strippe und 10Base2

Im übrigen der zZ einzige Ansatz einer Topologie für die Feldebene. Das ganze dann noch über 2-Draht Technik und ich bin dabei... (Denke ja auch immer an die Nachrüstbarkeit)

Da ich mir zu 100% sicher bin, das es so kommen wird, sind unsere Gebäude gut gerüstet. Wir verkabeln seit Jahren nicht in Baum Topologie sondern Punkt zu Punkt...

Na ja, einen Schrank voller Switches haben wir in dem Bürogebäude ohnehin auf jedem Stockwerk.

Na Prima, was glaubst denn wohl, was da noch alles hinzukommen würde. Das ist schnell mal Faktor 20... Ethernet in Sterntopologie bzw. Sterntopologie generell ist völlig unbrauchbar für die Feldebene der Gebäudeautomation. Der Aufwand ist nicht gerechtfertigt !!! Wenn ich allein das Problem der Brandlasten hinzurechne... oha

Es wird in der modernen Gebäudeautomation immer mehrere Schichten geben. Anhand der Automationspyramide sollte das eigentlich schnell klar sein. Alles auf's Ethernet zu würgen bzw auf eine gemeinsame Ebene zu heben ist sicherlich nicht zielführend....

Es wird und bleibt ein Mix verschiedenster Technologien, wie auch des öfteren schon erwähnt wurde.

9K6 Debatte... Wetten ich schalte eine Steckdose an einem KNX Aktor schneller als eine Ethernet Steckdose wie zB von DLink ....

LG

Mögliche Bandbreiten auszunutzen ist ebenfalls völlig daneben.

[makki]

Worums im Kern meiner letzten (missverständlichen) Aussage geht ist nicht die Topologie oder das konkrete Medium sondern dass IP, z.B. über Ethernet halt ein offener Standard ist, den jedermann auf der IETF-Webseite nachlesen kann.
KNX ist eben KNX, propretär, geschlossen, Kartell.
Die Tatsache dass ich mich Stand heute trotzdem dafür entschlossen habe, dürfte Bände sprechen.

Dahin, IP, wird die Reise der Heimautomatisierung IMHO gehen (bzw. tut sie das schon, UPnP/DLNA-Geräte werden vermutlich in 100fachen Stückzahlen wie KNX verkauft, auch wenn davon sicherlich meist nur 1% genutzt wird - aber auch das gehört zur HA substantiell dazu). Der KNX ist da nur ein Sub-Bus für Aktorik und einfache Sensorik, kommen ja noch Mediensteuerung, Visu (stand natürlich: HTML/IP) etc.pp. obendrauf.

Worum gehts: es fehlt auf der IP-Seite an einem geeigneten Protokoll. also sowas wie KNXnet/IP nur das auf halt z.B. bei der IETF und nicht nur in der lokalen Unibibliothek nachzulesen ist. Es wäre auch hilfreich wenn jemand ein bisschen an Security denken würde..
Dazu aber evtl. ein ander mal meine wirren Gedanken..


Nun mal weg vom Ethernet-to-the-Lichtschalter (was so natürlich Käse ist) zurück zur Ausgangsfrage


Ich beschäftige mich gerade wieder etwas intensiver mit Funk und so.
Man kann ja gegen Funk sein, ich würde es auch keineswegs als Strategie fürn Neubau empfehlen aber das Problem ist, egal was man sich so alles dolles neues und vorhandenens ausdenkt:
der überwiegende Anteil der Gebäude ist Bestand und hat zumeist keine Verkabelung, weder für EIB, Ethernet noch für sonstwas..
Powerline, ganz kurz, kann man glaube ich schnell abhaken, ich würde auch gern an dS glauben, der Beweis liegt aber nicht aufm Tisch..
Der geneigte Leser kann erahnen warum ich mich mit Sensornetzwerken beschäftige, 1-Wire ist auch nur ein Sub-Bus und dann auch schnell ausgelutscht

Vorab, eine Info zu 868MHz die man IMHO wissen sollte:
1% duty-cycle (jeder Sender darf vereinfacht ausgedrückt nur max. 1% der Airtime belegen) ist halt verdammt wenig,
(in etwa, kommt drauf an was, 20kBit/s, also rund das doppelte von KNX-TP)
Das sind brutto ca. 90kByte pro Stunde. Oder ganze 25 Byte/s; da gehen noch Header usw. weg, für nen Tempfühler reicht das sicher, für Mediensteuerung wirds evtl. schon knapp.
Eine moderne HA wird sich IMHO nicht an zu langsamen Übertragungs-Standards orientieren sondern eher daran dass der Player in unter 100ms den aktuellen Titel ans Display bringt und man trotzdem gleichzeitig weiterschalten kann..
Bei 2.4 GHz & 802.15.4, wo es diese bei ISM ja durchaus gewollte und vielleicht sogar sinnvolle 1% Limitierung nicht gibt (eine handvoll FB funktionieren so wenigstens halbwegs zuverlässig ohne höherliegende Schichten), liegen wir da beim Faktor 12 in der Datenrate. Das reicht. Die Intelligenz, damit alle mit der Bandbreite klarkommen, muss in dem Fall aber in die oberen OSI-Schichten..


Also Funk, was haben wir da an (IMHO) relevantem:
- KNX-RF: hmm, irgendwie nicht so wirklich mit Geräten durchsetzt, Security ist nur in dillentantischen Ansätzen vorhanden, darauf geh ich jetzt mal nicht weiter ein, es ist aber IMHO nunmal besonders bei Funk in der HA schon ein bisschen "alltagsrelevant".
868MHz-1%-Problem.
Hauptproblem: goto Unibibliothek, Subbus, Schwamm drüber.
- FS20: rel. verbreitet, günstig, 868MHz-1%-Problem, völlig sicherheitsfrei. Fürn Christbaum und die WS300 ok, ansonsten grossen Schwamm drüber.
- EnOcean: geniale Idee, leider proprietär, bestenfalls Sub-bus
(Homematic und die anderen 511 proprietären Sonderlocken überspringe ich jetzt mal)

Zur Sache
Wer sich jetzt nicht grade 48h Datenblätter reingefressen hat, dem will will ich vorab mitgeben:
IEEE 802.15.4: Das ist quasi der Funk-Übertragungungsstandard, Layer1+2, vglb.: Ethernet. Mehrere Frequenzbereiche, für uns relevant 868MHz und 2.4 GHz.
6LoWPAN und ZigBee setzen darauf auf, für mehr Details den Wikipeter fragen.

- ZigBee: Sieht gut aus, viele Vorteile: an Mesh, Zoning, Security usw. wurde gedacht, keine limitierung aufs 868MHZ-Band, breite Unterstützung in der dafür relevanten Industrie.
Nachteil, grosser Nachteil: das ist wieder fast dieselbe proprietäre Suppe. Der Zugang für Hersteller ist verglichen mit einem KNX aber relativ schmerzfrei.
Und die Medienindustrie ist, zumindest mit der dicken Lippe, schon im Boot (Stichwort RF4CE). Das reicht IMHO aber auch nur für nen Sub-Bus.. Die Realität der mind. nächsten 50J ist nunmal IP, egal wieviele Herstellerkonsortien noch was ganz-dolles-eigenens ausdenken

- 6loWPAN: IPv6 over Low power Wireless Personal Area Networks (ausschreiben=Lernzielkontrolle).
Langsam wirds interessant denkt der Netzwerkmensch, IPv6 zuckt zwar noch etwas aber offene Standards, IP, alles perfekt.
Die Ernüchterung wenn man auf grosse ganze der HA blickt (darum solls ja hier gehen) folgt aber ebenso schnell. Da gibts konkret leider (noch?) nicht so viel. Jetzt kommen wir wieder zu einem bereits genannten Punkt: einheitliches, offenes (natürlich IP-basiertes) Protokoll.. Das fehlt irgendwie..
Die Teile zum spielen mit 802.15 sind jedenfalls bestellt..


Soviel von mir für heute zum Thema "Zukunft Gebäudesteuerung". Die ist im Kern IP-basiert, das ist IMHO sicher. Die Frage ist nur wieviele proprietäre Subsysteme sich da wie lange da mit "durchschleichen" können.
Da erlaube ich mir jetzt noch den Hinweis: das hängt auch vom Markt ab, wenn der Kunde nicht den Marketing-Lemming gibt sondern auf offenen Standards pocht haben die Hersteller, die hinter solchen stehen auch eine Chance..

Makki

[MarkusS]

Z-Wave würde ich mal im Auge behalten, IMO am Markt (auch und gerade in den USA!) deutlich "vitaler" als ZigBee.

[meudenbach]

IP, z.B. über Ethernet halt ein offener Standard ist, den jedermann auf der IETF-Webseite nachlesen kann.

Das sehe ich mal völlig anders. Ethernet ist ein Übertragungsmedium und definiert lediglich, wie Daten von A nach B zu übertragen sind bzw transportiert werden. Auch hier kann neben standartisierten Protokollen natürlich "properitäre Grütze" übertragen werden siehe zB SONOS. Ergo, nicht alles was ein Ethernetschnittstelle hat unterliegt einem offenen Standard.

also sowas wie KNXnet/IP nur das auf halt z.B. bei der IETF und nicht nur in der lokalen Unibibliothek nachzulesen ist. Es wäre auch hilfreich wenn jemand ein bisschen an Security denken würde..

Definiere doch bitte mal Sicherheit... IMHO 2 wichtige Klassifizierungen:

• Übertragung
• Transparenz der Daten

Ich deken in Punkto Übertragungsichert müssen wir nicht lang diskutieren, das ist Gesetz

Was ich aber unter dem Begriff "Security" verstehe ist, neben anderen wichtigen Faktoren, dass eben nicht sämtliche Daten für "Jedermann" zugänglich sind. Das mag im Bereich Multimedia sportlicher gesehen werden, aber in der Gebäudeautomation sollte man sich damit schon etwas tiefgründiger auseinandersetzen. Ist natürlich super, wenn das Protokoll meiner EMA für jedermann transparent nachlesbar ist... das ganze dann noch auf "Ethernet Schicht" gehoben und die kleinste Sicherheitslücke im Router öffnet sprichwörtlich "Türen"....

Danke für Deinen informellen Ausblick in die Funktechnologieen. hierbei kommen wir doch zusammengefasst zu folgender Erkenntnis:

Jede Technologie hat ihre eigenen Anforderungen. Hierzu werden eben entsprechend bedarfsgerechte Protokolle verwendet, weil je komplexer die Protokolle umso höher der Aufwand in Hardware und dadurch bedingt auch im Stromverbrauch. Möchte man alles zusammengefasst, wie es heute ja durch WLAN möglich ist, haben wir größte Probleme in Punkto Stromverbrauch und die Batterieen in der FB halten nicht mehr 1 Jahr lang sondern nur noch wenige Stunden... (banales aber greifbares Beispiel).

Neue Technologieen, wie eben Enocean sind nur auf "dummes" Schalten ausgelegt, daher funktioniert es ja eben auch so gut und ZigBee mag ein Ansatz sein, wie es eben bei BT auch schon funktioniert, nur mit entsprechend höheren Reichweiten. Reichweiten im Übrigen auch immer ein Thema funkbasierter Lösungen.

Fazit: Es kann und wird also nie ein einheitliches "Verfahren" geben, da die Unterschiede im Bedarf doch arg groß sind und jede Technolgiee für sich hinsichtlich der Ergonomie eben das Optimum beansprucht.

Die Zukunft der Gebäudeautomation ist IMHO längst bestimmt und wir befinden uns in der Optimierungsphase. Es wird sich ein System im Feld, also Sensorik/Aktorik durchsetzen. Es wir "etwas" für Multimedia geben DLNA ist ja zumindest schon ein Ansatz und oben drüber eben Ethernet mit einem zentralen Knoten, der alle Subsysteme eben auf ein transparente Schicht hebt... und schon sind wir wieder bei der Automationspyramide.... Da ist so wenig dran zu drehen, wie an den Grundbedürfnissen nach der Maslow'schen Bedürfnispyramide.

Ach... und den "zentralen Knoten" gibbet auch schon ...

Marketing-Lemming gibt sondern auf offenen Standards pocht haben die Hersteller...

Ne... das glaube ich nicht !!! "offener Standard" ist en sehr dehnbarer Begriff und wie erwähnt, ich möchte dies im Sinne der "Security" NICHT !!! Und wie bereits erwähnt, IP heißt noch lang nicht "offen".

Der Zugang für Hersteller ist verglichen mit einem KNX aber relativ schmerzfrei

Völliger Quatsch diese Aussage... KNX Member zu werden und damit Zugang auf die gesamte Bibliothek zu erhalten, hat mich einen Anruf und eine Unterschrift gekostet... Der Spass fängt bei 1000,- €/anno an. Allein schon für das Marketing, von dem ich als Mitglied natürlich partizipiere, rechnet sich das... Ähnlich ist das auch bei der LNO und anderen Organisationen.

Und Gebäudeautomation ist IMHO keine Spielwiese. Im EFH mag ich das nocht entspannt sehen, aber im Objektgeschäft geht es auch um Leib und Leben.... ich weiss nicht, ob Du mal erlebt hast, wie ca. 60 Raffstoren aus ca. 60m nach einer mächtigen Windböe das Glasdach einer Einkaufspassage durchschschlagen haben... glücklicherweise war es Sonntags.... ähnlich im KFZ Bereich... man stelle sich vor, man könnte die BT Schnittselle anzapfen und eine "open sauce" Software in die Motorsteuerung schieben... da würde ich doch gleich, bei jedem der es wagt mich zu überholen, den BAS aktivieren

Man muss einfach mal die Kuh im Zaun lassen und für und wieder betrachten. Vieles "Geschlossene" beruht auch darauf, dass "User" eben keine Dummheiten machen kann. Denn 99% der User sind idR DAU's oder auch super DAU's und auch die möchten "bedient" werden. Die Hersteller müssen sich entsprechend absichern, dass eben der BAS nicht unmotiviert auslöst und somit Schaden verursacht, sowie eben jeder Mensch mit einer elektronischen Schließanlage ruhig schlafen können möchte.

Und vor Allem: Möchte jeder, der evtl. in einigen Jahren ein gebrauchtes "Smarthaus" kauft sich sicher sein, dass ihm geholfen werden kann, wenn mal etwas nicht mehr funktioniert

LG

[IBFS]

Man muss einfach mal die Kuh im Zaun lassen und für und wieder betrachten. Vieles "Geschlossene" beruht auch darauf, dass "User" eben keine Dummheiten machen kann. Denn 99% der User sind idR DAU's oder auch super DAU's und auch die möchten "bedient" werden. Die Hersteller müssen sich entsprechend absichern, dass eben der BAS nicht unmotiviert auslöst und somit Schaden verursacht, sowie eben jeder Mensch mit einer elektronischen Schließanlage ruhig schlafen können möchte.

Und vor Allem: Möchte jeder, der evtl. in einigen Jahren ein gebrauchtes "Smarthaus" kauft sich sicher sein, dass ihm geholfen werden kann, wenn mal etwas nicht mehr funktioniert

LG

Was soll man dazu noch sagen als 100% ACK


Im übrigen bin ich Fan von schönen großen Schaltschränken
mit ordentlich platzierten und verdrahteten REG-Komponenten.
Innen hängt der USB-Stick mit dem KNX-Projekt - Schrank ZU!


Gruß

[makki]

@Markus: Danke für den Hinweis! Z-Wave wurde gedanklich irgendwann auch wegsortiert.. 868 MHz, proprietär und wenn ein DevKit 3000$ kostet bzw. das SDK 1.5k dann ist bei mir schnell Ende Aber richtig, es spielt mit..

Das sehe ich mal völlig anders. Ethernet ist ein Übertragungsmedium und definiert lediglich, wie Daten von A nach B zu übertragen sind bzw transportiert werden.

Mike, ich denke wir müssen keine Grundsatzdiskussion über OSI-Layer führen oder Haare zerpflücken. Ich glaube wir kennen beide hinreichend den Unterschied zwischen Eth, IP, TCP, UDP
Ich schrieb z.B. Ethernet..
Jetzt lassen wir das Kabel einfach mal bitte weg, es ging, nochmal: um IP und andere offene Standards.

[/B]

Auch hier kann neben standartisierten Protokollen natürlich "properitäre Grütze" übertragen werden siehe zB SONOS. Ergo, nicht alles was ein Ethernetschnittstelle hat unterliegt einem offenen Standard.

Das hab ich auch nicht behauptet.. Noch damit gemeint, Sonos gehört dann eben zur Kategorie "proprietäre Subsysteme die sich da mit durchschleichen".
Also weil Sonos proprietäre Grütze verschickt, ist die Verwendung offener Standards oder von IP nachteilig oder was willst Du uns damit sagen ? Das das von Sonos Grütze ist ? einverstanden.

Definiere doch bitte mal Sicherheit...

Bei (Netzwerk)sicherheit geht es im wesentlichen um folgendes:
Authentisierung, Integrität und Vertraulichkeit.

- Authentisierung, d.h. ich muss zwischen zwei oder mehreren Kommunikationspartnern sicherstellen, dass es auch jew. derjenige ist, der er vorgibt zu sein.
- Integrität, d.h. es muss sichergestellt sein, dass die Daten nicht verändert oder z.B. wiederholt wurden.
- Vertraulichkeit, d.h. verschlüsselt (soweit überhaupt notwenig, die ersten beiden sind in der Praxis meist erheblich wichtiger)

Nun braucht man diese Sicherheit natürlich nicht immer und überall.
Ich behaupte aber felsenfest, zumindest bei Funk, dass jeglicher Standard, der nicht nach heutigem Stand der Technik absolut wasserdichte Verfahren zur Authentisierung Integrität und Verschlüsselung vorsieht, langfristig keine Chance haben wird.

Das Thema fehlt in den KNX(-RF) Specs aber nahezu vollständig..

Was ich aber unter dem Begriff "Security" verstehe ist, neben anderen wichtigen Faktoren, dass eben nicht sämtliche Daten für "Jedermann"..

Da sind wir sicherlich einer Meinung. Wo hab ich denn geschrieben dass der Anwender alles im klartext lesen können muss ? IP und die umgebenden Standards ermöglichen ja gerade das, s.u.. In richtig!

Ganz kurz: Wenn ich ein IP-Paket z.B. mit IPSec verschlüssele, dann ist das alles sichergestellt (bzw. weiss man genau wo die Grenzen von SHA1 oder AES liegen) - und basiert auf offenen Standards.
Security: Haken dran, fertig.
Brauchts ned: abschalten, Haken dran.

Ist natürlich super, wenn das Protokoll meiner EMA für jedermann transparent nachlesbar ist... das ganze dann noch auf "Ethernet Schicht" gehoben und die kleinste Sicherheitslücke im Router öffnet sprichwörtlich "Türen"....

1. Wenn das "Protokoll" Deiner EMA (was auch immer das jetzt ist) derzeit nicht für "jedermann transparent nachlesbar" ist, gibt es dafür nur folgende Erklärungen:
- Es ist mit anerkannten, offenen Verschlüsselungsverfahren geschützt
- Es hat sich noch niemand die Mühe gemacht, es zu knacken
- Es ist physikalisch nicht zugänglich, das geht Medien- und Protokollunabhängig durch ziehen des Steckers.
2. Was ist denn bitte die Ethernet-Schicht ? Meinst Du IP, wovon ich gesprochen habe ? Wo gings überhaupt um Alarmanlagen, das ist ein ganz anderes Thema..

Vielleicht drücke ich mich auch undeutlich aus aber jetzt kommen wir langsam zum Kern der Diskussion und warum wir hier immer aneinander vorbeireden werden:

Ich glaube fast Du verwechselst ganz fundamental "proprietär" mit "gewonnener Sicherheit"!

Nur weil etwas nicht offengelegt ist, heisst das noch lange nicht, dass es sicherer ist!
Das Gegenteil ist der Fall, genau darum geht es doch!

Immer wenn sich irgendwelche Schlaumeier was ganz tolles neues ausgedacht haben und der Meinung waren, es würde besonders sicher wenn mans nur so geheim wie möglich hält, ging das in jedem Einzelfall früher oder später in die Hose!

CSS, Keeloq, DECT, Funktastaturen, ..... die Liste lässt sich endlos fortsetzen..

Es ist eine seit vielen Jahrzehnten gefestigte Meinung unter Sicherheitsexperten - nicht nur meine - dass (Netzwerk)-Sicherheit langfrisitg nur mit offenen Standards auch wirklich sicher zu machen ist.
Warum empfiehlt das US DoD, ein BSI & Co die Verwendung offengelegter Verfahren und Standards für Verschlusssachen ? (bzw. wird die Verwendung proprietärer Protokolle und Alg. sogar explizit verboten)
Warum setzt die Bundeswehr z.B. massiv auf IP(v6) und lässt sich nicht ne eigene Suppe schreiben ?


Lieber Mike, Du verstehst sicherlich äonen mehr von GA als ich, aber da biste gedanklich IMHO ganz gewaltig aufm Holzweg..

Und mit dir erhebliche Teile der Elektrobranche, das ist das Problem:
Die ebenso verbreitete wie fundamental falsche Ansicht, dass ein proprietäres Verfahren oder Protokoll per se die Sicherheit erhöhen würde.

Ich will jetzt nicht mit Kerckhoffs anfangen, empfehle aber als Lektüre von Bruce Schneier z.B. das mal zu lesen.

Das alles hat - nur so präventiv nachdem ich offenbar gern missverstanden werde - übrigens rein garnichts mit der offenlegung von Software zu tun. Ich spreche über die Verwendung offener Standard und in diesem speziellen Fall Sicherheitsverfahren und Protokoll

Es müssen doch hier in der GA wirklich nicht dieselben Fehler wiederholt werden, die man anderswo schon vor 20 oder mehr Jahren gemacht und eingesehen hat..

Die Verfahren in Form offener Standards dafür sind vorhanden, ausgereift, tausendfach geprüft.. (X.509,IPSec,SSL,AES,SHA um nur einige zu nennen)
Und um gleich mal vorab ein Argument zu entkräften, das kann auch in dem kleinsten Atmel-Hühnerfutter locker implementiert werden.. Bzw. gibts das sogar schon, kleines Beispiel.

Fazit: Es kann und wird also nie ein einheitliches "Verfahren" geben, da die Unterschiede im Bedarf doch arg groß sind und jede Technolgiee für sich hinsichtlich der Ergonomie eben das Optimum beansprucht.

Jein. Die Phantasie ist durchaus da.. 802.15.4 hat das Zeug dazu (das ist übrigens technisch und in der Entstehungsgeschichte garnicht so weit von BT entfernt)
Wir sprechen ja über die Zukunft, ich sehe da durchaus eine 802.15.4 Funk-FB von Hersteller X die ohne grosses Fummeln, Autoconfig, nach dem einlegen der Batterien und der Eingabe eines Codes einen TV vom Hersteller y der am MEDIUM XY steckt im PAN sieht und diesem einfach Befehle schickt. Nebenbei noch die Stehlampe mit der Steckdose im Eck auf die Taste unten links gelegt..

Ganz genauso wie es heute selbstverständlich ist, vom Mac auf eine Datei des XP-Rechnern im gleichen LAN zuzugreifen oder sich (SW und HW-unabhängig) einfach mal ein eMail zu schicken.
Ohne tagelanges konfigurieren, parametriesieren oder programmieren.

Auch klar dass dazu noch ne Menge fehlt und es auf dem Weg dorthin ein paar Steine gibt aber technisch ist es machbar, wenn dann läuft das IMHO aber nur über offene Standards bei denen jeder mitspielen darf.
Ohne die konkrete Antwort dafür zu kennen übrigens..

Sowas wie 6loWPAN (+das drumherum, das würde jetzt aber den Rahmen sprengen) ist IMHO auf dem Weg dorthin, Zigbee ein bisschen, die meisten anderen bewegen sich eher davon weg..

Die Zukunft der Gebäudeautomation ist IMHO längst bestimmt und wir befinden uns in der Optimierungsphase.

Auch diese Ansicht teilen wir nicht. Ich sehe eher einen kleinen, sehr fragmentierten Markt mit kleinkarierter Industrie. Über Optimierungsphase können wir sprechen wenn der "Bus" (welcher auch immer) im Kinderzimmer so selbstverständlich wie der PC ist ;-)

Ach... und den "zentralen Knoten" gibbet auch schon ...

Nein Mike, mit Verlaub, es gibt leider nur, ich nenne es mal unterschiedlich komfortable Entwicklungsumgebungen, um all die unzulänglichenkeiten und proprietären Kistchen und Busse - mit hohem Know-How und Aufwand - halbwegs zueinander zu bringen.
Das sei nun ein HS, mmh, beide zusammen, Labview oder sonstwas und ist hier und heute natürlich das zielführendste.

Aber sieht so ne ne Zukunftvision aus ?

Immer wieder gerne das Beispiel: Heinz Mustermann bestellt DSL, geht in Geizmarkt, kauft sich ne Fritzbox, nen Wintel und nen Mac. Schafft er das mit Filesharing, Digicam, Internetzugriff ? Ich meine ja, obwohl es technisch ungleich komplexer als so ein bisschen Hausbus um ne Lampe zu schalten oder IR-Steuerung ist.. (Und nein, es geht nicht ums Strippenverlegen, das macht aus gutem Grund der Eli, es geht auch nicht um BCU's am Medium XY)
Aber ich weiss, das will die GA-Branche ja garnicht..

"offener Standard" ist en sehr dehnbarer Begriff

Ok, meine Definition von offener Standard ist eigentlich nicht sehr dehnbar: Für jedermann, der sich dafür interessiert frei zugänglich. Damit ist das Internet übrigens gross geworden.

ich weiss nicht, ob Du mal erlebt hast, wie ca. 60 Raffstoren aus ca. 60m nach einer mächtigen Windböe das Glasdach einer Einkaufspassage durchschschlagen haben...

Die propagierung offener Standards, IP oder Zukunft der Gebäudeautomation hat doch rein garnichts damit zu tun Und natürlich muss es auch weiterhin Fachleute geben, die Diskussion geht aber jetzt in eine ganz andere Richtung, sorry, das sind die üblichen Totschlagargumente..

Ich hab auch nichts gegen den KNX, der wird als einäugiger unter blinden und Marktführer seine Rolle sicherlich spielen.
Aber eine Vision, ausser für einen Sensorik/Aktorik Sub-bus mit relativ hohen Zugangsvoraussetzungen kann ich dabei leider insgesamt nicht erkennen..

Makki

[MarkusS]

@Markus: Danke für den Hinweis! Z-Wave wurde gedanklich irgendwann auch wegsortiert.. 868 MHz, proprietär und wenn ein DevKit 3000$ kostet bzw. das SDK 1.5k dann ist bei mir schnell Ende

??? Das ControlThink-SDK kostet unverschämte 79 US-Dollar, das SDK von Zensys kostet 1500 Dollar.

[makki]

@Markus: Ahhh, Ok.. Hatte ich nicht gesehen aber deshalb sprechen wir ja drüber..
Meine armen Nachbarn, ich hab schon wesentlich mehr Test-Funksticks als Geräte

Makki

[Micha]

Auch das Thema Beschreibungssprache fällt unter die Kategorie "Offener Standard". Wenn KNX als ein Subsystem in der GA gesehen wird, ist mir unklar, warum für die Parametrierung nicht ein vorhandenes, standardisiertes, weltweit eingeführtes und sicheres Beschreibungssystem benutzt wie z.B. die Beschreibungssprachen der IEC 61131 ( AWL, FUP, KOP, ST u.a. ). Millionen von Anwendern beherrschen diese Beschreibungssprachen, keine Automatisierungs- oder Regelungstechnik geht ohne IEC 61131, was ist nun so neu oder anders am KNX, was damit nicht gehen würde. Die Hersteller von KNX Komponenten müßten nur die entsprechenden Targetbibliothen liefern.

Ob die Umsetzungs von Steuerungsabläufen in einem zentralen Knoten oder denzentral in KNX-Komponenten erfolgt, kann bei der Kompiler-Übersetzung gesteuert werden, Gateway-Probleme gehören der Vergangenheit an. Offline-Simulation, Professionelles Debugging u.a wäre kein Problem.

Sicherlich sind dafür Rechenpower und moderne SW-Technologien erforderlich, die zum Beginn des EIB in den 90-Jahren nicht da waren. Aber wir schreiben das Jahr 2009, jeder Billig-PC kann ein Vielfaches der Apollo13 Technik, und die sind immerhin zum Mond geflogen. Möglich sollte es sein.

WAGO geht IMHO den richtigen Weg, steht aber auch noch am Anfang, denn noch wird die ETS benötigt.

Gruß Micha

[Topper]

Nicht ganz mein Thema, aber EMA steht für Einbruchmeldeanlage. ;-)

[IBFS]

Auch das Thema Beschreibungssprache fällt unter die Kategorie "Offener Standard". Wenn KNX als ein Subsystem in der GA gesehen wird, ist mir unklar, warum für die Parametrierung nicht ein vorhandenes, standardisiertes, weltweit eingeführtes und sicheres Beschreibungssystem benutzt wie z.B. die Beschreibungssprachen der IEC 61131 ( AWL, FUP, KOP, ST u.a. ).

Sorry, aber aus dem Text entnehme ich eine gewisse Unwissenheit über
den Unterschied zwischen Parametrierung und Programmierung.

In der ETS wird NICHT Programmiert sondern Parametriert.
Du glaubst aber garnicht wie unterschiedlich die Parametrierung
in der IEC-Welt gelöst ist.

WAGO IOPro <> BECKHOFF <> SIEMENS <> MITSHUBISHI <> ALLEN BRADLEY <> alles ungleich IEC hin oder her


Nur die Automatikfunktionen programmiert man dann im Sytem und das ist
dann verschieden: Homeserver, WAGO, KNX2S7(STEP7), EIBpc usw.

Auch für WAGO KNX braucht man übrigens die ETS. Denn man macht
ja nicht alles in der WAGO, sonst bräuchte man ja kein KNX mehr.
Werden alle Taster und Aktoren im WAGO-Kopf realisiert kann
man das grüne Kabel ja gleich weglassen. Aber dann ist es auch kein
KNX mehr.


Ich bin eigentlich ganz froh, dass - ausser der Gruppenaddressenhierarchie - alle in ein Korsett gezwungen werden. Sonst müßte man - wie bei der
Programmierung - erstmal den Programmierstil des Programmierers verstehen bevor man was findet und ändern kann.


Gruß

[Micha]

Hallo Frank,

Sorry, aber aus dem Text entnehme ich eine gewisse Unwissenheit über den Unterschied zwischen Parametrierung und Programmierung.

Ich kenne den Unterschied aus eigener Tätigkeit schon gut, ich habe in Bezug auf den KNX auch von Parametrierung gesprochen.

In der ETS wird NICHT Programmiert sondern Parametriert.
Du glaubst aber garnicht wie unterschiedlich die Parametrierung
in der IEC-Welt gelöst ist.

WAGO IOPro <> BECKHOFF <> SIEMENS <> MITSHUBISHI <> ALLEN BRADLEY <> alles ungleich IEC hin oder her

Ich meine nicht das Handlung der "Entwicklungsumgebung" sondern den Standard IEC.., Wer im Namen IEC.. führt sollte schon Quelltextkompatibel sein, falls das nicht so ist (kannst Du villeicht besser beurteilen) ist es zumindest anzustreben.

Auch für WAGO KNX braucht man übrigens die ETS. Denn man macht
ja nicht alles in der WAGO, sonst bräuchte man ja kein KNX mehr.
Werden alle Taster und Aktoren im WAGO-Kopf realisiert kann
man das grüne Kabel ja gleich weglassen. Aber dann ist es auch kein
KNX mehr.

Genau das sehe ich anders: KNX ist für mich das Übertragungsmedium mit entsprecheden Protokollen und die Verfügbarbarkeit von KNX-Geräten mit in hardware gegossener fester Programmierung (PDB), die durch Parametrierung an meine Erfordernisse angepasst wird.

Der KNX-Bus mit seiner Topologie ist ein super Feldmedium für Gebäude, sehr robust, flexibel, Elektrikerfreundlich u.a.

KNX-Geräte sind hervorragend an die flexiblen Anforderungen der Gebäude-technik angepasst und lassen sich schnell und kostengünstig parametrieren.

Nun stell Dir vor, Du würdest vom KNX Gerätehersteller eine IEC.. Bibliothek bekommen, die z.B. genau die Funktionalität des KNX Jalousieaktor abbildet, den Du im KNX Feldbus verwendest. Jetzt kannst Du in einer einheitlichen Entwicklungsumgebung zentrale und dezentrale Funktionen einheitlich darstellen, testen, dokumentieren und auch in die KNX Feldgeräte laden.

Insofern würde nur die ETS-Funktionalität in die IEC Entwicklungsumgebung einfliessen, der KNX-Feldbus bleibt wie er ist.

Auch in der KNX ETS kann bei Fremdprojekten durchaus Parametrierstile erkennen und eine Einarbeitung fällt nicht immer leicht.

Mir geht es praktischerweise eigentlich darum, nicht bei jedem neuen Gerät (komplexe Aktoren, Sensorik) Zentralgeräte wie HS, eibPC, WAGO, u.a neue Softwareumgebungen mit langen Einarbeitungszeiten zu haben.

Gruß Micha

[meudenbach]

Hallo Makki,

wenn wir über

IP und andere offene Standards

sprechen, dann sollten wir evtl. definieren, wann ein Standard "offen" ist und wann eben nicht. Ich zb sehe KNX eben auch als offenen Standard. Natürlich nicht hinsichtlich der Verbreitung mit Ethernet zu vergleichen, aber eben offen.

Bei diesen Gedankengängen müssen wir auch immer unterscheiden, wo wir uns grad bewegen, also Topologie Ebene (Art des Mediums zur Übertragung von "irgendwas", oder eben dem Protokoll (zB IP/UDP), welches ich über das Medium (zB Ethernet) würge).
*Dies ist so nun sicherlich sehr pauschal ausgedrückt, aber OSI wollen wir mal bei Seite lassen.*

Wenn nun die KNX BCU einen LAN Anschluss hätte und eben dann auf eine Ethernet Topologie aufsetzen würde und halt dann direkt KNXnet/IP sprechen würde, wären wir dann hinsichtlich Deiner Definition "IP und andere offene Standards" auf dem selben Nenner ??? Theoretisch wäre dies sogar durchaus möglich. Meine Anmerkung in Richtung KONNEX wäre eben die Punkt zu Punkt Verkabelung zu favorisieren und von der Baum Topoplogie Abstand zu nehmen, dies würde vorhandenen Technologien (zb Line2Wire) ermöglichen in Zukunft die gute alte Busleitung auch auf's Ethernet zu "heben".

Kern der Gesamtproblematik bzw. möglicher zukünftigen Ausrichtungen ist eben die solide Infrastruktur. Hier muß vorerst ein gemeinsamer Nenner gefunden werden, bevor man dann in Richtung Kommunikation denkt....

Zum Thema SONOS:
Ich kann bei Dir "Grütze" und "nicht Grütze leider nicht unterscheiden. In jedem Fall kategorierst Du oft alles, aus Deiner Sicht properitäre, in Richtung Grütze. Ergo, sind aus Deiner Sicht "proprietäre Subsysteme" doch auch Grütze... (mag nun nicht suchen, aber Grütze ist bei Dir eigentlich alles, was Dir nicht gefällt). Mir fehlt da ein wenig die Objektivität in Deinen Aussagen, denn nach dieser, Deiner!, Kategoriesierung müßte ein "1Eier" System doch eigentlich Obergrütze sein ???

Und da wird es eben wirr, ob gedanklich oder kommunikativ... weil mir fehlt immer so der Ansatz, wo eben mal ein gangbare Weg aufgezeigt wird. Das ist sicherlich zielführender, als über Grütze zu diskutieren.

nicht alles was ein Ethernetschnittstelle hat unterliegt einem offenen Standard.

Natürlich hast Du dies nicht behauptet, aber eine Aussage wie

über Ethernet halt ein offener Standard ist, den jedermann auf der IETF-Webseite nachlesen kann

suggeriert doch, evtl. missverständlich, dass Ethernet "offen" bedeutet.
Daher mein entsprechender Einwand am Beispiel SONOS, was sicherlich KEINE Grütze ist.

Zum Thema Sicherheit:

Wenn ich ein IP-Paket z.B. mit IPSec verschlüssele, dann ist das alles sichergestellt

Klar, ist es... aber weil eben, am Beispiel SONOS, nur der Hersteller die Key's etc. kennt, macht es dieses System doch properitär, obwohl es einen "offenen Standard" verwendet.

Zu Deinen Erklärungen, die mich etwas verwirren bzw. noch mehr verwirren und lassen mich darüber hinaus vermuten, dass Du eben meine Gedankengänge nicht nachvolziehen kannst, welche eben auch ein wenig erklären sollen, warum manche Dinge eben so sind, wie sie sind.

Beispiel EMA (Einbruchmeldeanlage)...
Nun muss ich wieder Deine Aussage hinzunehemen, dass alles was nicht "öffentlich" einlesbar eben "Grütze", "Properitär", "Kartell" ist. Wie eben auch Systeme, deren Dokumentation allein auf Grundlage der Sicherheitsrelevanz der Öffentlichkeit verwehrt werden. Deine Erklärungen sind somit eher Vermutungen und daher schlichtweg falsch.

2. Was ist denn bitte die Ethernet-Schicht ? Meinst Du IP, wovon ich gesprochen habe ?

Wenn ich zb dieses properitäre System auf unseren, wie ich denke, gemeinsamen Nenner (Ethernet) hebe, was ich ja tun muss um eine durchgängige Kommunikationsstruktur zu erhalten.

Dies ist doch unsere Anstrebung, oder sehe ich was falsch ???

Wo gings überhaupt um Alarmanlagen, das ist ein ganz anderes Thema..

Wie anderes Thema ???, reden wir hier über Themen und Standards der Zukunft? bzw. über Möglichkeiten diese Techniken durch Vereinheitlichung der Protokollebenen hinsichlich der Automation zu vereinfachen oder gar selbstlernend auszurichten?? Was klammert Du denn noch aus ??

Vielleicht drücke ich mich auch undeutlich aus aber jetzt kommen wir langsam zum Kern der Diskussion

Welchen Kern muss ich nun fragen ?

Ich glaube fast Du verwechselst ganz fundamental "proprietär" mit "gewonnener Sicherheit"!

Ganz bestimmt nicht !!! Daher ja meine Eingangsfrage:

Definiere doch bitte mal Sicherheit... IMHO 2 wichtige Klassifizierungen:

Was Du beschreibst, ist die Sicherheitsschicht aus der Sichtweise eines IT Profis, sicherlich nicht falsch aber in der Gebäudeautomation so nicht anwendbar. Sicherlich denkbar um das spätere Gesamtkonstrukt nach aussen zu kapseln, aber soweit sind noch lang nicht... Aber wenn dann natürlich so, wie von Dir beschrieben...

Und ja, ich gebe Dir recht, wenn wir aneinander vorbei reden... weil Du überwiegend über eben Sicherheit in der Protokollschicht redest, was aber überhaupt nicht Kern und Ansatz meiner Ausführung war...

garnichts mit der offenlegung von Software

Nö, richtig... war da irgendwo eine Anmerkung ?

technisch ist es machbar, wenn dann läuft das IMHO aber nur über offene Standards bei denen jeder mitspielen darf.

Dem mag auch ich gar nicht wiederprechen, ist aber IMHO für eine solch weit ausgerichtete und individuell einsetzbare Technolgie nicht umsetzbar ohne eben einer "Schicht" dazwischen...

Ich sehe eher einen kleinen, sehr fragmentierten Markt

Das kommt auf die Sichtweise an... ich sehe ja nicht nur KNX sondern eben Automation als Gesamtheit und das ist ein Millarden Markt...

Ich meine ja, obwohl es technisch ungleich komplexer als so ein bisschen Hausbus um ne Lampe zu schalten

Siehst und da gehen unsere Meinungen erheblich auseinander. Heinz Mustermann beruft sich auf Standards, die Ihm aufgezwungen werden und eben kein "links" und "rechts" zulassen. Nimmst Timac bzw. X10 kannst das auch haben. Je eingeschränkter die Flexibilität und eben Anwendungsumgebungen diktiert werden, desto einfacher können solche Fallbeispiele auch umgesetzt werden. Das ist doch auch heute, kein Problem... es wird aber nicht akzeptiert. Die Bandbreite in der modernen Gebäudeautomation unter einem Nenner zu bringen ist sicherlich mit erheblich größerer Aufwand verbunden, als nen "dummen" PC mit dem Internet zu verbinden, obwohl die eigentliche Technik drumherum ungemein "kleiner" erscheint.

Ok, meine Definition von offener Standard ist eigentlich nicht sehr dehnbar: Für jedermann, der sich dafür interessiert frei zugänglich. Damit ist das Internet übrigens gross geworden.

Sicherlich, aber eben nicht vergleichbar.... und ach, über wieviel "Standards" im Zusammenhang mit "Internet" reden wir doch gleich ???

...

@Micha

Auch das Thema Beschreibungssprache fällt unter die Kategorie "Offener Standard".

IMHO die überhaupt erste Zielsetzung neben der Infrastruktur...

Sicherlich sind dafür Rechenpower und moderne SW-Technologien erforderlich

Das ist überhaupt das Problem, warum eben in mehreren "Schichten" gedacht werden muss. Eben auch die Ergonomie (Kosten). Es ist sicherlich nicht zielführend einen Superchip für einen einfachen Lichtschalter einzusetzen, nur dass dieser sich über ein einheitliches Protokoll mit der "Restwelt" unterhalten kann...

WAGO geht IMHO den richtigen Weg

Naja, ein Ansatz ... aber noch gaaaaaanz weit weg... "IBFS" hat es schon schön erklärt...

alle in ein Korsett gezwungen werden.

... und eben dieses "Korsett" darf nicht wegfallen. Sonst erreicht man eben nicht die Mehrheit der Masse (und somit auch nicht die Industrie) und genau das ist auch eines der größten Probleme....


... nun genug für heute.

LG

[Chris M.]

Beispiel EMA (Einbruchmeldeanlage)...
Nun muss ich wieder Deine Aussage hinzunehemen, dass alles was nicht "öffentlich" einlesbar eben "Grütze", "Properitär", "Kartell" ist. Wie eben auch Systeme, deren Dokumentation allein auf Grundlage der Sicherheitsrelevanz der Öffentlichkeit verwehrt werden. Deine Erklärungen sind somit eher Vermutungen und daher schlichtweg falsch.

Das sehe ich anders. Wenn ein System sicherheitsrelevant ist, dann ist es IMHO zwingend erforderlich, dass die verwendete Kommunikationstechnologie veröffentlicht wird. Nur so kann man überprüfen, ob das System einem sicher genug ist. Proprietäre Algorithmen haben hier in der Vergangenheit zu genüge gezeigt, dass sie notorisch unsicher sind. Hier darf man nur auf einen der Major Player setzen, an denen sich Kryptographen nachweislich die Zähne ausbeissen (das probieren so viele, dass man mit hinreichender Gewissheit davon ausgehen kann, dass niemand im stillen Kämmerchen sitzt und den Algorithmus doch genackt hat...)
Die Kommunikation selbst ist - geschützt durch solche Maßnahmen - natürlich nicht mehr öffentlich einsehbar. Die dafür verwendeten Schlüssel sind natürlich auf privat.

Beispiel wo das ständig eingesetzt wird: Homebanking.
Die Kommunikation lässt sich an genug Stellen anzapfen. Also muss diese geschützt werden - was über normale Zertifikate und Verschlüsselung passiert, alles in öffentlichen Standards definiert. Und ganze Scharen von Kryptographen versuchen sich ständig daran, genau die dort verwendeten Algorithmen zu knacken. Und trotzdem setzen die Banken - zu recht - auf diesen Standard und nicht eine "proprietäre Grütze" die per Java-Applet, Flash, what-ever eine "sichere" Kommunikation herstellen würde.

Mein Fazit: je sicherheitskritischer ein Kommunikationsvorgang um so relevanter ist eine öffentliche Dokumentation und evtl. sogar Implementierung! Es gab schon einige, die meinten ein sicheres Verfahren zu verwenden und hatten dann einen Fehler in der Implementierung...

[meudenbach]

@Chris,

ich sehe, da spricht wieder ein IT'ler... und Du hast auch völlig recht, nur reißt Du da etwas aus dem Zusammenhang.

Wir müssen nun ja unterscheiden, wo wir über "Sicherheit" sprechen... da muss ich nun wieder auf meine Klassifizierung verweisen:

Übertragung
Transparenz der Daten

Der "Einwand" von Dir und Makki bezieht sich ja wohl immer auf die Übertragung. Und da bin ja völlig auf eurer Seite.

Was ich mit "Transparenz der Daten" meine ist eben die Zugänglichkeit der Informationen auf ein Protokoll aufsetzen zu können. Am Beispiel der EMA zB das IGES Protokoll... da bin ich erstmal noch auf RS232 und muss mir, wie auch immer, einen Weg bauen die Kommunikation auf's Ethernet zu bringen. Das mache ich üblicherweise mit einem Moxa. Bis zu diesem Punkt denke ich noch gar nicht über AES, IPsec etc nach... Mit einem Moxa, wird's da auch schwierig ... Im eigentlichem Sinne kann man natürlich auch nicht von "Sicherheit" sprechen, nur weil Protokolldaten nicht zugänglich sind. Das trägt evtl. zur Verwirrung bei.

Der Gegensatz ist eben SONOS... komplett auf Standards im Sinne der IT ausgerüstet. Aber eben AES (Vermutung) verschlüsselt... No Chance um dazwischen zu kommen. (Seit der iPhone APP ist nun wohl eine Lücke gefunden worden). Also im Sinne gewünschter Standards nicht properitär aber durch die Verschlüssung, welche dem IT'ler wieder das grinsen aufkommen läßt, dann doch properitär ??? ... also Grütze ?!

.. ich versteh das nimmer !!

Es wird IMHO schlichtweg falsch behauptet, dass eben Systeme "properitäre Grütze" sind, nur weil die Zugänglichkeiten erschwert werden bzw. Geld dafür verlangt wird, wobei man dann offensichtlich nur eine Seite betrachtet und mal nicht hinterfragt wird, warum das so ist.
Das ist eben keine objektive Betrachtungsweise.... und ab diesen Punkt ist jedwede Diskussion eigentlich überflüssig.

Das ärgert mich einfach !!!

Denn, und das ist ganz wichtig, die "Sicherheit", also die Verschlüsselung müssen ja alle Teilnehmer im Netz unterstützen, im Sinne der Zukunft also auch die LAN BCU !!! Und da kommen doch schon wieder neue Probleme, die neue Denkansätze erfordern.

LG