Zukunft Gebäudesteuerung

[christiantf]

Hi zusammen,

wenn auch ein wenig OT, aber die Sicht eines Privathausbauers:

KNX ist leider viel zu undurchschaubar, als dass es sich als Mainstream-Standard auch im Privathaushalt etablieren könnte. Alle anderen Steuer-Hersteller schaffen es, für vernünftiges Geld Hardware und Software auf den Markt zu bringen, die für den Bauherren auch bedienbar ist (sie es nun Wired oder Funk).

Offenbar sind die KNX-Lizenzbedingungen und sonstigen Restriktionen so hart, dass deswegen alles entweder sauteuer wird, oder die Hersteller gar kein Interesse haben.

Und irgendwie wirkt KNX auch ein bisschen protektionistisch für das Elektrikergewerbe. Praktisch will man die Einrichtung und Programmierung der Steuerung nicht in die Hände des Bauherrn geben.

Solange das so ist, spielt es gar keine Rolle, ob nun KNX-Funk oder KNX-Wired, weil die Leute sowieso andere Lösungen (wenn auch proprietär) einsetzen.

Erst wenn KNX den Mainstream erreicht/erreichen will (z.B. auch durch Kommunikation über IP und/oder Ethernet) und sich auch Mainstream-Produkte integrieren können (TV, Handy, Waschmaschine), wird es KNX als Quasi-Standard geben.

(Leider) derzeit meine Sicht der Dinge.

[kape147]

@makki

Hab gerade deine Ausführung vom 9.11. gelesen -

Chapeau!!!

besser kann man's nicht (be)schreiben!

[EPIX]

und endlich ist es wieder still
denn Friede kehrt nach Canterville...



Freut mich dass es auch andere Techniker gibt, die emotionell ihre Meinung vertreten!

Aber es führt eh zu nichts, wir reden völlig aneinander vorbei, solange ständig Medien, Protokolle und Anwendungen wahllos vermischt werden..

Genau...

Für meinen Teil, spar Dir die Mühe....

LG

[makki]

Meinen zweiseitgen Aufsatz hats mir gerade zerissen, müssen wir verschieben..
Aber es führt eh zu nichts, wir reden völlig aneinander vorbei, solange ständig Medien, Protokolle und Anwendungen wahllos vermischt werden..

@Mike: wenn Du Dein letztes Posting genau liest, findest Du darin sogar einen Beweis dafür, dass Security by obscurity nicht funktioniert.

Ich sprach von IP damit meinte ich IP, das auf dem L3, sonst garnichts, Du sprichst ständig von Ethernet und LAN.

Ich sprach von Security Definition Sicherheit siehe hier, ich wähle dieses Wort nicht zufällig, Du sprichst von Sicherheit.
Bitte Mike, Suche nach "IP, z.B. über" und Deiner Antwort dazu..

Den Rest ein andermal, einen Link noch..

Makki

@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

[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...

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

[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

[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ß

[Topper]

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

[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

[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

[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: 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