Local Operating Network - Versionsgeschichte

Rmcharb: tk

2023-08-13T18:23:05Z

← Nächstältere Version		Version vom 13. August 2023, 20:23 Uhr
Zeile 51:		Zeile 51:

	Softwareseitig werden ''Knoten'' mit Applikationen für Standardaufgaben oder frei programmierbare Systeme eingesetzt.		Softwareseitig werden ''Knoten'' mit Applikationen für Standardaufgaben oder frei programmierbare Systeme eingesetzt.
	Für die Applikationen mit Standardaufgaben werden die Netzwerkschnittstelle und – soweit notwendig – auch die Aufgaben in [[LonMark]] standardisiert bzw. empfohlen. Die Aufgaben werden in LonMark Objekten – auch als Funktionsprofile ('''functional profiles''') bezeichnet – gegliedert. Beispiele sind das [[Lamp Actuator]], das Switch und das [[Constant Light Controller]] Objekt.		Für die Applikationen mit Standardaufgaben werden die Netzwerkschnittstelle und – soweit notwendig – auch die Aufgaben in [[LonMark]] standardisiert bzw. empfohlen. Die Aufgaben werden in LonMark Objekten – auch als Funktionsprofile (''functional profiles'') bezeichnet – gegliedert. Beispiele sind das [[Lamp Actuator]], das Switch und das [[Constant Light Controller]] Objekt.
	Freie Programmierung erfolgt z. T. über Neuron C (z. B. mit dem NodeBuilder der Firma Echelon), einer ANSI C Erweiterung oder über grafische Programmierung (z. B. mit dem Programmiersystem IPOCS der Firma SysMik).		Freie Programmierung erfolgt z. T. über Neuron C (z. B. mit dem NodeBuilder der Firma Echelon), einer ANSI C Erweiterung oder über grafische Programmierung (z. B. mit dem Programmiersystem IPOCS der Firma SysMik).

	Für die Festlegung der Kommunikation zwischen den Geräten (das „Binding“), die Inbetriebnahme und die Verwaltung in '''LON''' Netzen werden Netzwerkmanagementtools eingesetzt. Für den physischen Zugriff auf die LON-Netze werden Netzwerkschnittstellen verschiedener Arten eingesetzt, u. a. PC Einsteckkarten.		Für die Festlegung der Kommunikation zwischen den Geräten (das „Binding“), die Inbetriebnahme und die Verwaltung in ''LON''-Netzen werden Netzwerkmanagementtools eingesetzt. Für den physischen Zugriff auf die LON-Netze werden Netzwerkschnittstellen verschiedener Arten eingesetzt, u. a. PC Einsteckkarten.

	Für die softwaretechnische Verwaltung der Informationen hat sich [[LonWorks Network Services]] (LNS) durchgesetzt, eine Client/Server-Architektur mit integrierter Datenbank. Für die Anbindung an die [[Gebäudeleittechnik]] (GLT) – oder in der allgemeinen Sprechweise der Automatisierer an [[SCADA]] Systeme ([[Supervisory Control and Data Acquisition]]) – existieren Schnittstellen, wie sie dem Stand der Technik entsprechen, z. B. über [[OLE for Process Control]] (OPC).		Für die softwaretechnische Verwaltung der Informationen hat sich [[LonWorks Network Services]] (LNS) durchgesetzt, eine Client/Server-Architektur mit integrierter Datenbank. Für die Anbindung an die [[Gebäudeleittechnik]] (GLT) – oder in der allgemeinen Sprechweise der Automatisierer an [[SCADA]] Systeme ([[Supervisory Control and Data Acquisition]]) – existieren Schnittstellen, wie sie dem Stand der Technik entsprechen, z. B. über [[OLE for Process Control]] (OPC).
Zeile 64:		Zeile 64:
	== Frameworks ==		== Frameworks ==

	* [[OSGi]] - Middleware-Standard (Java-Framework) für die Einbindung von LON in Service-Gateways		* [[OSGi]]: Middleware-Standard (Java-Framework) für die Einbindung von LON in Service-Gateways

	== Organisationen ==		== Organisationen ==
Zeile 80:		Zeile 80:

	* {{Literatur		* {{Literatur
	\|Titel=DIN EN 14908-1:2007-11 – Firmenneutrale Datenkommunikation für die Gebäudeautomation und Gebäudemanagement - Gebäudedatennetzprotokoll - Teil 1: Datenprotokollschichtenmodell; Englische Fassung EN 14908-1:2005		\|Titel=DIN EN 14908-1:2007-11 – Firmenneutrale Datenkommunikation für die Gebäudeautomation und Gebäudemanagement – Gebäudedatennetzprotokoll – Teil 1: Datenprotokollschichtenmodell; Englische Fassung EN 14908-1:2005
	\|Verlag=Beuth		\|Verlag=Beuth
	\|Ort=Berlin		\|Ort=Berlin
	\|Datum=2007}}		\|Datum=2007}}
	* {{Literatur		* {{Literatur
	\|Titel=DIN EN 14908-2:2006-01 – Firmenneutrale Datenkommunikation für die Gebäudeautomation und Gebäudemanagement - Gebäudedatennetzprotokoll - Teil 2: Kommunikation über paarig verdrillte Leitungen; Englische Fassung EN 14908-2:2005		\|Titel=DIN EN 14908-2:2006-01 – Firmenneutrale Datenkommunikation für die Gebäudeautomation und Gebäudemanagement – Gebäudedatennetzprotokoll – Teil 2: Kommunikation über paarig verdrillte Leitungen; Englische Fassung EN 14908-2:2005
	\|Verlag=Beuth		\|Verlag=Beuth
	\|Ort=Berlin		\|Ort=Berlin
	\|Datum=2006}}		\|Datum=2006}}
	* {{Literatur		* {{Literatur
	\|Titel=DIN EN 14908-3:2007-02 – Firmenneutrale Datenkommunikation für die Gebäudeautomation und Gebäudemanagement - Gebäude Netzwerk Protokoll - Teil 3: Kommunikation über die Stromversorgungsleitungen; Englische Fassung EN 14908-3:2006		\|Titel=DIN EN 14908-3:2007-02 – Firmenneutrale Datenkommunikation für die Gebäudeautomation und Gebäudemanagement – Gebäude Netzwerk Protokoll – Teil 3: Kommunikation über die Stromversorgungsleitungen; Englische Fassung EN 14908-3:2006
	\|Verlag=Beuth		\|Verlag=Beuth
	\|Ort=Berlin		\|Ort=Berlin
	\|Datum=2007}}		\|Datum=2007}}
	* {{Literatur		* {{Literatur
	\|Titel=DIN EN 14908-4:2007-02 – Firmenneutrale Datenkommunikation für die Gebäudeautomation und Gebäudemanagement - Gebäude Netzwerk Protokoll - Teil 4: Kommunikation mittels Internet Protokoll (IP); Englische Fassung EN 14908-4:2006		\|Titel=DIN EN 14908-4:2007-02 – Firmenneutrale Datenkommunikation für die Gebäudeautomation und Gebäudemanagement – Gebäude Netzwerk Protokoll – Teil 4: Kommunikation mittels Internet Protokoll (IP); Englische Fassung EN 14908-4:2006
	\|Verlag=Beuth		\|Verlag=Beuth
	\|Ort=Berlin		\|Ort=Berlin

InternetArchiveBot: InternetArchiveBot hat 1 Archivlink(s) ergänzt und 0 Link(s) als defekt/tot markiert.) #IABot (v2.0.8.6

2022-03-20T11:19:47Z

InternetArchiveBot hat 1 Archivlink(s) ergänzt und 0 Link(s) als defekt/tot markiert.) #IABot (v2.0.8.6

← Nächstältere Version		Version vom 20. März 2022, 13:19 Uhr
Zeile 6:		Zeile 6:
	\| accessdate = 2009-06-16		\| accessdate = 2009-06-16
	\| publisher = LonMark International		\| publisher = LonMark International
			\| archivebot = 2022-03-20 11:19:46 InternetArchiveBot
			\| archiveurl = https://web.archive.org/web/20140228054605/http://www.lonmark.org/news_events/press/2008/1208_iso_standard
			\| archivedate = 2014-02-28
			\| offline = yes
	}}</ref>		}}</ref>
	Zu diesem Zeitpunkt waren mehr als 100 Millionen Geräte mit dieser Technologie installiert.<ref name="LonMark" /> LON wird beispielsweise im [[Willis Tower]], am [[Flughafen Frankfurt Main]], [[Post Tower]] Bonn, [[Business Tower Nürnberg]], zur Steuerung der [[Oslo]]er Straßenbeleuchtung und im [[Reichstagsgebäude]] eingesetzt.<ref>{{cite web		Zu diesem Zeitpunkt waren mehr als 100 Millionen Geräte mit dieser Technologie installiert.<ref name="LonMark" /> LON wird beispielsweise im [[Willis Tower]], am [[Flughafen Frankfurt Main]], [[Post Tower]] Bonn, [[Business Tower Nürnberg]], zur Steuerung der [[Oslo]]er Straßenbeleuchtung und im [[Reichstagsgebäude]] eingesetzt.<ref>{{cite web

Uli Elch: lf

2021-12-15T10:37:54Z

← Nächstältere Version		Version vom 15. Dezember 2021, 12:37 Uhr
Zeile 7:		Zeile 7:
	\| publisher = LonMark International		\| publisher = LonMark International
	}}</ref>		}}</ref>
	Zu diesem Zeitpunkt waren mehr als 100 Millionen Geräte mit dieser Technologie installiert.<ref name="LonMark" /> LON wird beispielsweise im [[Willis Tower]], am [[Flughafen Frankfurt am Main]], [[Post Tower]] Bonn, [[Business Tower Nürnberg]], zur Steuerung der [[Oslo]]er Straßenbeleuchtung und im [[Reichstagsgebäude]] eingesetzt.<ref>{{cite web		Zu diesem Zeitpunkt waren mehr als 100 Millionen Geräte mit dieser Technologie installiert.<ref name="LonMark" /> LON wird beispielsweise im [[Willis Tower]], am [[Flughafen Frankfurt Main]], [[Post Tower]] Bonn, [[Business Tower Nürnberg]], zur Steuerung der [[Oslo]]er Straßenbeleuchtung und im [[Reichstagsgebäude]] eingesetzt.<ref>{{cite web
	\| url = http://www.echelon.com/solutions/building/LonWorksTechinBuildings.pdf		\| url = http://www.echelon.com/solutions/building/LonWorksTechinBuildings.pdf
	\| title = LonWorks at Work in Buildings Around the World		\| title = LonWorks at Work in Buildings Around the World

HerrMay am 13. Januar 2021 um 01:56 Uhr

2021-01-13T01:56:03Z

← Nächstältere Version		Version vom 13. Januar 2021, 03:56 Uhr
Zeile 7:		Zeile 7:
	\| publisher = LonMark International		\| publisher = LonMark International
	}}</ref>		}}</ref>
	Zu diesem Zeitpunkt waren mehr als 100 Millionen Geräte mit dieser Technologie installiert.<ref name="LonMark" /> LON wird beispielsweise im [[Willis Tower]], am [[Flughafen Frankfurt am Main]], [[Post Tower]] Bonn, zur Steuerung der [[Oslo]]er Straßenbeleuchtung und im [[Reichstagsgebäude]] eingesetzt.<ref>{{cite web		Zu diesem Zeitpunkt waren mehr als 100 Millionen Geräte mit dieser Technologie installiert.<ref name="LonMark" /> LON wird beispielsweise im [[Willis Tower]], am [[Flughafen Frankfurt am Main]], [[Post Tower]] Bonn, [[Business Tower Nürnberg]], zur Steuerung der [[Oslo]]er Straßenbeleuchtung und im [[Reichstagsgebäude]] eingesetzt.<ref>{{cite web
	\| url = http://www.echelon.com/solutions/building/LonWorksTechinBuildings.pdf		\| url = http://www.echelon.com/solutions/building/LonWorksTechinBuildings.pdf
	\| title = LonWorks at Work in Buildings Around the World		\| title = LonWorks at Work in Buildings Around the World

DiplPaul am 31. Dezember 2019 um 12:47 Uhr

2019-12-31T12:47:01Z

← Nächstältere Version		Version vom 31. Dezember 2019, 14:47 Uhr
Zeile 7:		Zeile 7:
	\| publisher = LonMark International		\| publisher = LonMark International
	}}</ref>		}}</ref>
	Zu diesem Zeitpunkt waren mehr als 100 Millionen Geräte mit dieser Technologie installiert.<ref name="LonMark" /> LON wird beispielsweise im [[Willis Tower]], am [[Flughafen Frankfurt am Main]], zur Steuerung der [[Oslo]]er Straßenbeleuchtung und im [[Reichstagsgebäude]] eingesetzt.<ref>{{cite web		Zu diesem Zeitpunkt waren mehr als 100 Millionen Geräte mit dieser Technologie installiert.<ref name="LonMark" /> LON wird beispielsweise im [[Willis Tower]], am [[Flughafen Frankfurt am Main]], [[Post Tower]] Bonn, zur Steuerung der [[Oslo]]er Straßenbeleuchtung und im [[Reichstagsgebäude]] eingesetzt.<ref>{{cite web
	\| url = http://www.echelon.com/solutions/building/LonWorksTechinBuildings.pdf		\| url = http://www.echelon.com/solutions/building/LonWorksTechinBuildings.pdf
	\| title = LonWorks at Work in Buildings Around the World		\| title = LonWorks at Work in Buildings Around the World

PerfektesChaos: tk k

2019-06-13T19:21:26Z

tk k

Änderungen zeigen

InternetArchiveBot: InternetArchiveBot hat 1 Archivlink(s) ergänzt und 0 Link(s) als defekt/tot markiert. #IABot (v2.0beta14)

2019-04-28T04:14:58Z

InternetArchiveBot hat 1 Archivlink(s) ergänzt und 0 Link(s) als defekt/tot markiert. #IABot (v2.0beta14)

← Nächstältere Version		Version vom 28. April 2019, 06:14 Uhr
Zeile 7:		Zeile 7:
	\| publisher = LonMark International		\| publisher = LonMark International
	}}</ref>		}}</ref>
	Zu diesem Zeitpunkt waren mehr als 100 Millionen Geräte mit dieser Technologie installiert.<ref name="LonMark" /> LON wird beispielsweise im [[Willis Tower]], am [[Flughafen Frankfurt am Main]], zur Steuerung der [[Oslo]]er Straßenbeleuchtung und im [[Reichstagsgebäude]] eingesetzt.<ref>{{cite web		Zu diesem Zeitpunkt waren mehr als 100 Millionen Geräte mit dieser Technologie installiert.<ref name="LonMark" /> LON wird beispielsweise im [[Willis Tower]], am [[Flughafen Frankfurt am Main]], zur Steuerung der [[Oslo]]er Straßenbeleuchtung und im [[Reichstagsgebäude]] eingesetzt.<ref>
			{{cite web
	\| url = http://www.echelon.com/solutions/building/LonWorksTechinBuildings.pdf		\| url = http://www.echelon.com/solutions/building/LonWorksTechinBuildings.pdf
	\| title = LonWorks at Work in Buildings Around the World		\| title = LonWorks at Work in Buildings Around the World
Zeile 13:		Zeile 14:
	\| format = PDF		\| format = PDF
	\| publisher = Echelon Corporation		\| publisher = Echelon Corporation
			\| archiveurl = https://web.archive.org/web/20090530082320/http://www.echelon.com/solutions/building/LonWorksTechinBuildings.pdf
⚫	}}</ref><ref>{{cite web
			\| archivedate = 2009-05-30
			\| offline = yes
			\| archivebot = 2019-04-28 04:14:58 InternetArchiveBot
			}}
		⚫	</ref><ref>{{cite web
	\| url = http://www.echelon.com/applications/pl-rf-outdoor-lighting		\| url = http://www.echelon.com/applications/pl-rf-outdoor-lighting
	\| title = Oslo Street Lighting System Slashes Energy Use with LonWorks® Technology		\| title = Oslo Street Lighting System Slashes Energy Use with LonWorks® Technology

Invisigoth67: form

2018-11-04T11:51:17Z

form

Seewolf: Änderungen von Experiment31 (Diskussion) auf die letzte Version von InkoBot zurückgesetzt

2018-01-29T11:29:07Z

Änderungen von Experiment31 (Diskussion) auf die letzte Version von InkoBot zurückgesetzt

← Nächstältere Version		Version vom 29. Januar 2018, 13:29 Uhr
Zeile 24:		Zeile 24:
	== Konzept ==		== Konzept ==

	Der ursprüngliche Kerngedanke des LON-Feldbussystems war die dezentrale Automatisierung in flachen, d. h. nicht oder nur wenig vertikal unterteilten Systemen. Im LON kommunizieren Geräte (in der [[Terminologie]] ''Knoten'' bzw. engl. ''Nodes'' genannt) über einen Bus miteinander. Der gedankliche Ansatz der dezentralen Automatisierung mit LON sieht eine Unterteilung der ''Nodes'' in [[Sensor]]en, [[Aktor]]en und [[Controller (Hardware)\|Controller]] vor. Nur lokal benötigte Informationen sollen dabei möglichst an „Ort und Stelle“ verarbeitet werden. Dieses Konzept steht im Gegensatz zu hierarchisch orientierten Systemen, in welchen ein übergeordneter Rechner (in der Regel eine [[Speicherprogrammierbare Steuerung]] – [[Direct Digital Control (Regelungstechnisches Verfahren)\|Direct Digital Control]] – Station) alle Daten einsammelt.		Der ursprüngliche Kerngedanke des LON-Feldbussystems war die dezentrale Automatisierung in flachen, d. h. nicht oder nur wenig vertikal unterteilten Systemen. Im LON kommunizieren Geräte (in der [[Terminologie]] ''Knoten'' bzw. engl. ''Nodes'' genannt) über einen Bus miteinander. Der gedankliche Ansatz der dezentralen Automatisierung mit LON sieht eine Unterteilung der ''Nodes'' in [[Sensor]]en, [[Aktor]]en und [[Controller (Hardware)\|Controller]] vor. Nur lokal benötigte Informationen sollen dabei möglichst an „Ort und Stelle“ verarbeitet werden. Dieses Konzept steht im Gegensatz zu hierarchisch orientierten Systemen, in welchen ein übergeordneter Rechner (in der Regel eine [[Speicherprogrammierbare Steuerung]] - [[Direct Digital Control (Regelungstechnisches Verfahren)\|Direct Digital Control]] - Station) alle Daten einsammelt.

	== Hardware ==		== Hardware ==
Zeile 44:		Zeile 44:

	Softwareseitig werden ''Knoten'' mit Applikationen für Standardaufgaben oder frei programmierbare Systeme eingesetzt.		Softwareseitig werden ''Knoten'' mit Applikationen für Standardaufgaben oder frei programmierbare Systeme eingesetzt.
	Für die Applikationen mit Standardaufgaben werden die Netzwerkschnittstelle und – soweit notwendig – auch die Aufgaben in [[LonMark]] standardisiert bzw. empfohlen. Die Aufgaben werden in LonMark Objekten – auch als Funktionsprofile ('''functional profiles''') bezeichnet – gegliedert. Beispiele sind das [[Lamp Actuator]], das Switch und das [[Constant Light Controller]] Objekt.		Für die Applikationen mit Standardaufgaben werden die Netzwerkschnittstelle und - soweit notwendig - auch die Aufgaben in [[LonMark]] standardisiert bzw. empfohlen. Die Aufgaben werden in LonMark Objekten - auch als Funktionsprofile ('''functional profiles''') bezeichnet - gegliedert. Beispiele sind das [[Lamp Actuator]], das Switch und das [[Constant Light Controller]] Objekt.
	Freie Programmierung erfolgt z. T. über Neuron C (z. B. mit dem NodeBuilder der Firma Echelon), einer ANSI C Erweiterung oder über grafische Programmierung (z. B. mit dem Programmiersystem IPOCS der Firma SysMik).		Freie Programmierung erfolgt z. T. über Neuron C (z. B. mit dem NodeBuilder der Firma Echelon), einer ANSI C Erweiterung oder über grafische Programmierung (z. B. mit dem Programmiersystem IPOCS der Firma SysMik).

	Für die Festlegung der Kommunikation zwischen den Geräten (das „Binding“), die Inbetriebnahme und die Verwaltung in '''LON''' Netzen werden Netzwerkmanagementtools eingesetzt. Für den physischen Zugriff auf die LON-Netze werden Netzwerkschnittstellen verschiedener Arten eingesetzt, u. a. PC Einsteckkarten.		Für die Festlegung der Kommunikation zwischen den Geräten (das „Binding“), die Inbetriebnahme und die Verwaltung in '''LON''' Netzen werden Netzwerkmanagementtools eingesetzt. Für den physischen Zugriff auf die LON-Netze werden Netzwerkschnittstellen verschiedener Arten eingesetzt, u. a. PC Einsteckkarten.

	Für die softwaretechnische Verwaltung der Informationen hat sich [[LonWorks Network Services]] (LNS) durchgesetzt, eine Client/Server-Architektur mit integrierter Datenbank. Für die Anbindung an die [[Gebäudeleittechnik]] (GLT) – oder in der allgemeinen Sprechweise der Automatisierer an [[SCADA]] Systeme ([[Supervisory Control and Data Acquisition]]) – existieren Schnittstellen, wie sie dem Stand der Technik entsprechen, z. B. über [[OLE for Process Control]] (OPC).		Für die softwaretechnische Verwaltung der Informationen hat sich [[LonWorks Network Services]] (LNS) durchgesetzt, eine Client/Server-Architektur mit integrierter Datenbank. Für die Anbindung an die [[Gebäudeleittechnik]] (GLT) - oder in der allgemeinen Sprechweise der Automatisierer an [[SCADA]] Systeme ([[Supervisory Control and Data Acquisition]]) - existieren Schnittstellen, wie sie dem Stand der Technik entsprechen, z. B. über [[OLE for Process Control]] (OPC).

	Wie auch bei einigen anderen Bussystemen gestattet es die LON-Topologie, Controller (Produkte) unterschiedlicher Hersteller miteinander zu kombinieren. Zur Parametrierung der Geräte und zur Erstellung der Bindings stehen diverse LNS-Netzwerkmanagementools von verschiedenen Herstellern (z. B. LonMaker von Echelon, NL220 von Newron System, ALEX von spega oder CARE von Honeywell) zur Verfügung. Sie unterscheiden sich sowohl durch die Art der grafischen Darstellung des LON-Netzes als auch durch den Umfang der angebotenen Management Services.		Wie auch bei einigen anderen Bussystemen gestattet es die LON-Topologie, Controller (Produkte) unterschiedlicher Hersteller miteinander zu kombinieren. Zur Parametrierung der Geräte und zur Erstellung der Bindings stehen diverse LNS-Netzwerkmanagementools von verschiedenen Herstellern (z. B. LonMaker von Echelon, NL220 von Newron System, ALEX von spega oder CARE von Honeywell) zur Verfügung. Sie unterscheiden sich sowohl durch die Art der grafischen Darstellung des LON-Netzes als auch durch den Umfang der angebotenen Management Services.
Zeile 57:		Zeile 57:
	== Frameworks ==		== Frameworks ==

	* [[OSGi]] – Middleware-Standard (Java-Framework) für die Einbindung von LON in Service-Gateways		* [[OSGi]] - Middleware-Standard (Java-Framework) für die Einbindung von LON in Service-Gateways

	== Organisationen ==		== Organisationen ==
Zeile 74:		Zeile 74:
	* {{Literatur		* {{Literatur
	\| Titel = DIN EN 14908-1:2007-11		\| Titel = DIN EN 14908-1:2007-11
	\| TitelErg= Firmenneutrale Datenkommunikation für die Gebäudeautomation und Gebäudemanagement – Gebäudedatennetzprotokoll – Teil 1: Datenprotokollschichtenmodell; Englische Fassung EN 14908-1:2005		\| TitelErg= Firmenneutrale Datenkommunikation für die Gebäudeautomation und Gebäudemanagement - Gebäudedatennetzprotokoll - Teil 1: Datenprotokollschichtenmodell; Englische Fassung EN 14908-1:2005
	\| Verlag = Beuth		\| Verlag = Beuth
	\| Ort = Berlin		\| Ort = Berlin
Zeile 81:		Zeile 81:
	* {{Literatur		* {{Literatur
	\| Titel = DIN EN 14908-2:2006-01		\| Titel = DIN EN 14908-2:2006-01
	\| TitelErg = Firmenneutrale Datenkommunikation für die Gebäudeautomation und Gebäudemanagement – Gebäudedatennetzprotokoll – Teil 2: Kommunikation über paarig verdrillte Leitungen; Englische Fassung EN 14908-2:2005		\| TitelErg = Firmenneutrale Datenkommunikation für die Gebäudeautomation und Gebäudemanagement - Gebäudedatennetzprotokoll - Teil 2: Kommunikation über paarig verdrillte Leitungen; Englische Fassung EN 14908-2:2005
	\| Verlag = Beuth		\| Verlag = Beuth
	\| Ort = Berlin		\| Ort = Berlin
Zeile 88:		Zeile 88:
	* {{Literatur		* {{Literatur
	\| Titel = DIN EN 14908-3:2007-02		\| Titel = DIN EN 14908-3:2007-02
	\| TitelErg = Firmenneutrale Datenkommunikation für die Gebäudeautomation und Gebäudemanagement – Gebäude Netzwerk Protokoll – Teil 3: Kommunikation über die Stromversorgungsleitungen; Englische Fassung EN 14908-3:2006		\| TitelErg = Firmenneutrale Datenkommunikation für die Gebäudeautomation und Gebäudemanagement - Gebäude Netzwerk Protokoll - Teil 3: Kommunikation über die Stromversorgungsleitungen; Englische Fassung EN 14908-3:2006
	\| Verlag = Beuth		\| Verlag = Beuth
	\| Ort = Berlin		\| Ort = Berlin
Zeile 95:		Zeile 95:
	* {{Literatur		* {{Literatur
	\| Titel = DIN EN 14908-4:2007-02		\| Titel = DIN EN 14908-4:2007-02
	\| TitelErg = Firmenneutrale Datenkommunikation für die Gebäudeautomation und Gebäudemanagement – Gebäude Netzwerk Protokoll – Teil 4: Kommunikation mittels Internet Protokoll (IP); Englische Fassung EN 14908-4:2006		\| TitelErg = Firmenneutrale Datenkommunikation für die Gebäudeautomation und Gebäudemanagement - Gebäude Netzwerk Protokoll - Teil 4: Kommunikation mittels Internet Protokoll (IP); Englische Fassung EN 14908-4:2006
	\| Verlag = Beuth		\| Verlag = Beuth
	\| Ort = Berlin		\| Ort = Berlin

Experiment31: Typographisch falschen Bindestrich durch Halbgeviertstrich ersetzt

2018-01-29T11:15:35Z

Typographisch falschen Bindestrich durch Halbgeviertstrich ersetzt

← Nächstältere Version		Version vom 29. Januar 2018, 13:15 Uhr
Zeile 24:		Zeile 24:
	== Konzept ==		== Konzept ==

	Der ursprüngliche Kerngedanke des LON-Feldbussystems war die dezentrale Automatisierung in flachen, d. h. nicht oder nur wenig vertikal unterteilten Systemen. Im LON kommunizieren Geräte (in der [[Terminologie]] ''Knoten'' bzw. engl. ''Nodes'' genannt) über einen Bus miteinander. Der gedankliche Ansatz der dezentralen Automatisierung mit LON sieht eine Unterteilung der ''Nodes'' in [[Sensor]]en, [[Aktor]]en und [[Controller (Hardware)\|Controller]] vor. Nur lokal benötigte Informationen sollen dabei möglichst an „Ort und Stelle“ verarbeitet werden. Dieses Konzept steht im Gegensatz zu hierarchisch orientierten Systemen, in welchen ein übergeordneter Rechner (in der Regel eine [[Speicherprogrammierbare Steuerung]] - [[Direct Digital Control (Regelungstechnisches Verfahren)\|Direct Digital Control]] - Station) alle Daten einsammelt.		Der ursprüngliche Kerngedanke des LON-Feldbussystems war die dezentrale Automatisierung in flachen, d. h. nicht oder nur wenig vertikal unterteilten Systemen. Im LON kommunizieren Geräte (in der [[Terminologie]] ''Knoten'' bzw. engl. ''Nodes'' genannt) über einen Bus miteinander. Der gedankliche Ansatz der dezentralen Automatisierung mit LON sieht eine Unterteilung der ''Nodes'' in [[Sensor]]en, [[Aktor]]en und [[Controller (Hardware)\|Controller]] vor. Nur lokal benötigte Informationen sollen dabei möglichst an „Ort und Stelle“ verarbeitet werden. Dieses Konzept steht im Gegensatz zu hierarchisch orientierten Systemen, in welchen ein übergeordneter Rechner (in der Regel eine [[Speicherprogrammierbare Steuerung]] – [[Direct Digital Control (Regelungstechnisches Verfahren)\|Direct Digital Control]] – Station) alle Daten einsammelt.

	== Hardware ==		== Hardware ==
Zeile 44:		Zeile 44:

	Softwareseitig werden ''Knoten'' mit Applikationen für Standardaufgaben oder frei programmierbare Systeme eingesetzt.		Softwareseitig werden ''Knoten'' mit Applikationen für Standardaufgaben oder frei programmierbare Systeme eingesetzt.
	Für die Applikationen mit Standardaufgaben werden die Netzwerkschnittstelle und - soweit notwendig - auch die Aufgaben in [[LonMark]] standardisiert bzw. empfohlen. Die Aufgaben werden in LonMark Objekten - auch als Funktionsprofile ('''functional profiles''') bezeichnet - gegliedert. Beispiele sind das [[Lamp Actuator]], das Switch und das [[Constant Light Controller]] Objekt.		Für die Applikationen mit Standardaufgaben werden die Netzwerkschnittstelle und – soweit notwendig – auch die Aufgaben in [[LonMark]] standardisiert bzw. empfohlen. Die Aufgaben werden in LonMark Objekten – auch als Funktionsprofile ('''functional profiles''') bezeichnet – gegliedert. Beispiele sind das [[Lamp Actuator]], das Switch und das [[Constant Light Controller]] Objekt.
	Freie Programmierung erfolgt z. T. über Neuron C (z. B. mit dem NodeBuilder der Firma Echelon), einer ANSI C Erweiterung oder über grafische Programmierung (z. B. mit dem Programmiersystem IPOCS der Firma SysMik).		Freie Programmierung erfolgt z. T. über Neuron C (z. B. mit dem NodeBuilder der Firma Echelon), einer ANSI C Erweiterung oder über grafische Programmierung (z. B. mit dem Programmiersystem IPOCS der Firma SysMik).

	Für die Festlegung der Kommunikation zwischen den Geräten (das „Binding“), die Inbetriebnahme und die Verwaltung in '''LON''' Netzen werden Netzwerkmanagementtools eingesetzt. Für den physischen Zugriff auf die LON-Netze werden Netzwerkschnittstellen verschiedener Arten eingesetzt, u. a. PC Einsteckkarten.		Für die Festlegung der Kommunikation zwischen den Geräten (das „Binding“), die Inbetriebnahme und die Verwaltung in '''LON''' Netzen werden Netzwerkmanagementtools eingesetzt. Für den physischen Zugriff auf die LON-Netze werden Netzwerkschnittstellen verschiedener Arten eingesetzt, u. a. PC Einsteckkarten.

	Für die softwaretechnische Verwaltung der Informationen hat sich [[LonWorks Network Services]] (LNS) durchgesetzt, eine Client/Server-Architektur mit integrierter Datenbank. Für die Anbindung an die [[Gebäudeleittechnik]] (GLT) - oder in der allgemeinen Sprechweise der Automatisierer an [[SCADA]] Systeme ([[Supervisory Control and Data Acquisition]]) - existieren Schnittstellen, wie sie dem Stand der Technik entsprechen, z. B. über [[OLE for Process Control]] (OPC).		Für die softwaretechnische Verwaltung der Informationen hat sich [[LonWorks Network Services]] (LNS) durchgesetzt, eine Client/Server-Architektur mit integrierter Datenbank. Für die Anbindung an die [[Gebäudeleittechnik]] (GLT) – oder in der allgemeinen Sprechweise der Automatisierer an [[SCADA]] Systeme ([[Supervisory Control and Data Acquisition]]) – existieren Schnittstellen, wie sie dem Stand der Technik entsprechen, z. B. über [[OLE for Process Control]] (OPC).

	Wie auch bei einigen anderen Bussystemen gestattet es die LON-Topologie, Controller (Produkte) unterschiedlicher Hersteller miteinander zu kombinieren. Zur Parametrierung der Geräte und zur Erstellung der Bindings stehen diverse LNS-Netzwerkmanagementools von verschiedenen Herstellern (z. B. LonMaker von Echelon, NL220 von Newron System, ALEX von spega oder CARE von Honeywell) zur Verfügung. Sie unterscheiden sich sowohl durch die Art der grafischen Darstellung des LON-Netzes als auch durch den Umfang der angebotenen Management Services.		Wie auch bei einigen anderen Bussystemen gestattet es die LON-Topologie, Controller (Produkte) unterschiedlicher Hersteller miteinander zu kombinieren. Zur Parametrierung der Geräte und zur Erstellung der Bindings stehen diverse LNS-Netzwerkmanagementools von verschiedenen Herstellern (z. B. LonMaker von Echelon, NL220 von Newron System, ALEX von spega oder CARE von Honeywell) zur Verfügung. Sie unterscheiden sich sowohl durch die Art der grafischen Darstellung des LON-Netzes als auch durch den Umfang der angebotenen Management Services.
Zeile 57:		Zeile 57:
	== Frameworks ==		== Frameworks ==

	* [[OSGi]] - Middleware-Standard (Java-Framework) für die Einbindung von LON in Service-Gateways		* [[OSGi]] – Middleware-Standard (Java-Framework) für die Einbindung von LON in Service-Gateways

	== Organisationen ==		== Organisationen ==
Zeile 74:		Zeile 74:
	* {{Literatur		* {{Literatur
	\| Titel = DIN EN 14908-1:2007-11		\| Titel = DIN EN 14908-1:2007-11
	\| TitelErg= Firmenneutrale Datenkommunikation für die Gebäudeautomation und Gebäudemanagement - Gebäudedatennetzprotokoll - Teil 1: Datenprotokollschichtenmodell; Englische Fassung EN 14908-1:2005		\| TitelErg= Firmenneutrale Datenkommunikation für die Gebäudeautomation und Gebäudemanagement – Gebäudedatennetzprotokoll – Teil 1: Datenprotokollschichtenmodell; Englische Fassung EN 14908-1:2005
	\| Verlag = Beuth		\| Verlag = Beuth
	\| Ort = Berlin		\| Ort = Berlin
Zeile 81:		Zeile 81:
	* {{Literatur		* {{Literatur
	\| Titel = DIN EN 14908-2:2006-01		\| Titel = DIN EN 14908-2:2006-01
	\| TitelErg = Firmenneutrale Datenkommunikation für die Gebäudeautomation und Gebäudemanagement - Gebäudedatennetzprotokoll - Teil 2: Kommunikation über paarig verdrillte Leitungen; Englische Fassung EN 14908-2:2005		\| TitelErg = Firmenneutrale Datenkommunikation für die Gebäudeautomation und Gebäudemanagement – Gebäudedatennetzprotokoll – Teil 2: Kommunikation über paarig verdrillte Leitungen; Englische Fassung EN 14908-2:2005
	\| Verlag = Beuth		\| Verlag = Beuth
	\| Ort = Berlin		\| Ort = Berlin
Zeile 88:		Zeile 88:
	* {{Literatur		* {{Literatur
	\| Titel = DIN EN 14908-3:2007-02		\| Titel = DIN EN 14908-3:2007-02
	\| TitelErg = Firmenneutrale Datenkommunikation für die Gebäudeautomation und Gebäudemanagement - Gebäude Netzwerk Protokoll - Teil 3: Kommunikation über die Stromversorgungsleitungen; Englische Fassung EN 14908-3:2006		\| TitelErg = Firmenneutrale Datenkommunikation für die Gebäudeautomation und Gebäudemanagement – Gebäude Netzwerk Protokoll – Teil 3: Kommunikation über die Stromversorgungsleitungen; Englische Fassung EN 14908-3:2006
	\| Verlag = Beuth		\| Verlag = Beuth
	\| Ort = Berlin		\| Ort = Berlin
Zeile 95:		Zeile 95:
	* {{Literatur		* {{Literatur
	\| Titel = DIN EN 14908-4:2007-02		\| Titel = DIN EN 14908-4:2007-02
	\| TitelErg = Firmenneutrale Datenkommunikation für die Gebäudeautomation und Gebäudemanagement - Gebäude Netzwerk Protokoll - Teil 4: Kommunikation mittels Internet Protokoll (IP); Englische Fassung EN 14908-4:2006		\| TitelErg = Firmenneutrale Datenkommunikation für die Gebäudeautomation und Gebäudemanagement – Gebäude Netzwerk Protokoll – Teil 4: Kommunikation mittels Internet Protokoll (IP); Englische Fassung EN 14908-4:2006
	\| Verlag = Beuth		\| Verlag = Beuth
	\| Ort = Berlin		\| Ort = Berlin

← Nächstältere Version		Version vom 4. November 2018, 13:51 Uhr
Zeile 13:		Zeile 13:
	\| format = PDF		\| format = PDF
	\| publisher = Echelon Corporation		\| publisher = Echelon Corporation
	}}</ref>		}}</ref><ref>{{cite web
	<ref>{{cite web
	\| url = http://www.echelon.com/applications/pl-rf-outdoor-lighting		\| url = http://www.echelon.com/applications/pl-rf-outdoor-lighting
	\| title = Oslo Street Lighting System Slashes Energy Use with LonWorks® Technology		\| title = Oslo Street Lighting System Slashes Energy Use with LonWorks® Technology
Zeile 44:		Zeile 43:

	Softwareseitig werden ''Knoten'' mit Applikationen für Standardaufgaben oder frei programmierbare Systeme eingesetzt.		Softwareseitig werden ''Knoten'' mit Applikationen für Standardaufgaben oder frei programmierbare Systeme eingesetzt.
	Für die Applikationen mit Standardaufgaben werden die Netzwerkschnittstelle und - soweit notwendig - auch die Aufgaben in [[LonMark]] standardisiert bzw. empfohlen. Die Aufgaben werden in LonMark Objekten - auch als Funktionsprofile ('''functional profiles''') bezeichnet - gegliedert. Beispiele sind das [[Lamp Actuator]], das Switch und das [[Constant Light Controller]] Objekt.		Für die Applikationen mit Standardaufgaben werden die Netzwerkschnittstelle und – soweit notwendig – auch die Aufgaben in [[LonMark]] standardisiert bzw. empfohlen. Die Aufgaben werden in LonMark Objekten – auch als Funktionsprofile ('''functional profiles''') bezeichnet – gegliedert. Beispiele sind das [[Lamp Actuator]], das Switch und das [[Constant Light Controller]] Objekt.
	Freie Programmierung erfolgt z. T. über Neuron C (z. B. mit dem NodeBuilder der Firma Echelon), einer ANSI C Erweiterung oder über grafische Programmierung (z. B. mit dem Programmiersystem IPOCS der Firma SysMik).		Freie Programmierung erfolgt z. T. über Neuron C (z. B. mit dem NodeBuilder der Firma Echelon), einer ANSI C Erweiterung oder über grafische Programmierung (z. B. mit dem Programmiersystem IPOCS der Firma SysMik).

	Für die Festlegung der Kommunikation zwischen den Geräten (das „Binding“), die Inbetriebnahme und die Verwaltung in '''LON''' Netzen werden Netzwerkmanagementtools eingesetzt. Für den physischen Zugriff auf die LON-Netze werden Netzwerkschnittstellen verschiedener Arten eingesetzt, u. a. PC Einsteckkarten.		Für die Festlegung der Kommunikation zwischen den Geräten (das „Binding“), die Inbetriebnahme und die Verwaltung in '''LON''' Netzen werden Netzwerkmanagementtools eingesetzt. Für den physischen Zugriff auf die LON-Netze werden Netzwerkschnittstellen verschiedener Arten eingesetzt, u. a. PC Einsteckkarten.

	Für die softwaretechnische Verwaltung der Informationen hat sich [[LonWorks Network Services]] (LNS) durchgesetzt, eine Client/Server-Architektur mit integrierter Datenbank. Für die Anbindung an die [[Gebäudeleittechnik]] (GLT) - oder in der allgemeinen Sprechweise der Automatisierer an [[SCADA]] Systeme ([[Supervisory Control and Data Acquisition]]) - existieren Schnittstellen, wie sie dem Stand der Technik entsprechen, z. B. über [[OLE for Process Control]] (OPC).		Für die softwaretechnische Verwaltung der Informationen hat sich [[LonWorks Network Services]] (LNS) durchgesetzt, eine Client/Server-Architektur mit integrierter Datenbank. Für die Anbindung an die [[Gebäudeleittechnik]] (GLT) – oder in der allgemeinen Sprechweise der Automatisierer an [[SCADA]] Systeme ([[Supervisory Control and Data Acquisition]]) – existieren Schnittstellen, wie sie dem Stand der Technik entsprechen, z. B. über [[OLE for Process Control]] (OPC).

	Wie auch bei einigen anderen Bussystemen gestattet es die LON-Topologie, Controller (Produkte) unterschiedlicher Hersteller miteinander zu kombinieren. Zur Parametrierung der Geräte und zur Erstellung der Bindings stehen diverse LNS-Netzwerkmanagementools von verschiedenen Herstellern (z. B. LonMaker von Echelon, NL220 von Newron System, ALEX von spega oder CARE von Honeywell) zur Verfügung. Sie unterscheiden sich sowohl durch die Art der grafischen Darstellung des LON-Netzes als auch durch den Umfang der angebotenen Management Services.		Wie auch bei einigen anderen Bussystemen gestattet es die LON-Topologie, Controller (Produkte) unterschiedlicher Hersteller miteinander zu kombinieren. Zur Parametrierung der Geräte und zur Erstellung der Bindings stehen diverse LNS-Netzwerkmanagementools von verschiedenen Herstellern (z. B. LonMaker von Echelon, NL220 von Newron System, ALEX von spega oder CARE von Honeywell) zur Verfügung. Sie unterscheiden sich sowohl durch die Art der grafischen Darstellung des LON-Netzes als auch durch den Umfang der angebotenen Management Services.