Projektplanung einer Leitstelle –Eure Meinung!

[akkonsaarland]

ihr denkt alle zu kompliziert
ich würd mich als erstes mit meinem kollegen eine woche lang einsperren für ein brainstorming
danach ein pflichtenheft erstellen

ist dieses pflichtenheft erstellt angebote einholen
die einzelnen hersteller werden euch schon in die referenzleitstellen einladen

und vergesst die werbegeschenke net

[Fabpicard]

Mach dich mal bei der Feuerwehr Trier schlau

die haben vor Jahr und Tag eine ILS gebaut

Und haben sich en neuen ELW 2 gekauft, der nur eine Aufgabe hat:

"Nicht zu funktionieren" *g*

Die bekommen den zu 85% nie syncronisiert mit der ILS :D

So, dass musste mal gesagt werden :)

MfG Fabsi

[hannibal]

Und haben sich en neuen ELW 2 gekauft, der nur eine Aufgabe hat:

"Nicht zu funktionieren" *g*

Die bekommen den zu 85% nie syncronisiert mit der ILS :D

So, dass musste mal gesagt werden :)

MfG Fabsi

OK.. hast du Bilder ?

das wäre das erste zu beachten

schnittstellen mit einem ELW um bei AUsfall über den ELW fahren zu können

[fussel]

schnittstellen mit einem ELW um bei AUsfall über den ELW fahren zu können

Das ist übrigens ein Thema, welches IMHO noch sehr viel Entwicklungsarbeit benötigt: Anbindung einer Örtlichen Einsatzleitung an den Einsatzleitrechner einer ILS und Übernahme ihrer Tätigkeit, wenn die ILS ausfällt.

Auf der Interschutz 2005 war ich mit etwa 10 Herstellern von Leitstellensystemen im Gespräch und stellte genau die obige Frage. Knapp die Häfte der Hersteller sagten: "Diese Frage wurde uns noch nie gestellt." Unterschiedliche Hersteller bieten inzwischen Lösungen an, von denen ich hier drei nennen will:

* Verschiedene Hersteller bieten die Möglichkeit, per Web-Schnittstelle über einen Browser zumindest auf einen Teil der Daten im Einsatzleitrechner zuzugreifen (Beispiel: Secur.CAD / Swissphone Systems und Lebig in Niederösterreich)

* Swissphone bietet darüberhinaus einen Datenlink über eine Satelliten-Verbindung an, die es auch ermöglicht, mit einem abgestetzten Arbeitsplatz auf einen Secur.CAD-Server zuzugreifen

* ISE ermöglicht aufgrund der Server-basierten Architektur von Cobra das Einwählen per UMTS-Verbindung, VPN und (bei Windows) per Remote-Desktop-Verbindung auf den Cobra-Server. Damit laufen auch die Prozesse des Disponenten-Arbeitsplatzes auf der Server-Hardware, den man dann auf dem Remote-Desktop aufrufen kann. So muss auf einem UMTS-fähigen Rechner (Notebook) nur die VPN-Software installiert werden und nicht die Disponenten-Oberfläche des Einsatzleitsystems.

Alle diese Systeme sind aber Client-Server-Systeme. Die genannten Varianten sind lediglich örtlich abgesetzte Arbeitsplätze und damit Clients, sie setzen alle einen laufenden Server in der ILS vorraus. Eine Rückfallebene zu einer ausgefallenen ILS sind sie nicht! Dazu muss ein weiterer, vollständiger Server des jeweiligen Einsatzleitsystems mit dem gleichen Datenstand wie in der ILS vorhanden sein. Es stellt sich die Frage, ob man soetwas in einem ELW einrichten muss oder nicht vielleicht doch besser an einer anderen Örtlichkeit eine Notleitstelle einrichtet, die deutlich besser gewartet werden kann (vorhandene IT-Infrasktrur).

Den meisten ist inzwischen sicher auch bewusst, dass die derzeit genormten ELW1 und ELW2 an und für sich nicht als "kleine Leitstelle" ausgelegt sind, sondern eher als Meldekopf und Besprechungsraum für Stäbe bzw. entsprechend reduzierte Örtliche Einsatzleitungen. Aus dieser Not heraus richten viele ihre ELWs inzwischen deutlich über und von der Norm abweichend aus. Aber das ist sicher ein anderes Thema...

[Michel]

Das war eine Menge Information - Danke!

Also Cobra, habe ich jetzt vermehrt entnommen, scheint ja doch gut verbreitet zu sein. Ich habe mir die Seite mal angesehen und das hört sich gut durchdacht an! Das werd ich mir in den nächsten Tagen mal in der Praxis ansehen.

Ferner ist die Datenanbindung des ELW II an den ELR ebenfalls ein Punkt, über den wir uns gerade noch gedanken gemacht haben.
Wir überlegen eine Standalone-Lösung, in der der ELW II, unabhängig von der LST als eigenständige Not-LST betrieben werden könnte.
Vom Gedankengang her schwebt uns folgendes vor:
-Ständige Datenanbindung des ELW II an den ELR über Kabel.
-Im Einsatzfall (bei noch vorhandener LST) über eine Datenverbindung
-Im Einsatzfall( bei Totalausfall der LST inkl. Server) sollte er eigenständig dann mit dem letzten Datenstand technisch arbeiten können. D. h. einen, von mir aus in Zarges-Kisten verpackter, ELR-Arbeitsplatz der bei Bedarf zügig im ELW aufgebaut werden kann. Von einem Fernmeldetechniker die 112 in den ELW legen lassen, sodass dann im Idealfall 1-3 Notrufleitungen besetzt werden können und wir einen abgespeckten Dispoplatz im ELW, ggf. unterstützt durch die 3 vorhanden Laptops, in betriebnehmen können. Unser ELW II wird noch unterstützt durch die Räumlichkeit eines AB TEL (Technische Einsatzleitung), also sollte zumindest genug Platz für eine Not.LST da sein. Nur müssen diese Überlegungen des Redundanzfalls meiner Meinung nach jetzt bereits mit eingeplant werden.

Ich werde in Kürze hier mal eine nummerierte List unserer Gedanken/Ideenansätze einstellen, um sie hier mal zu diskutieren oder ggf. ein paar Referenzstellen zu bekommen oder sogar noch Verfeinerungen, bzw. Erfahrungswerte einzuholen.

Vielen Dank bereits wieder im Vorfeld!

[fussel]

Von einem Fernmeldetechniker die 112 in den ELW legen lassen, sodass dann im Idealfall 1-3 Notrufleitungen besetzt werden können und wir einen abgespeckten Dispoplatz im ELW, ggf. unterstützt durch die 3 vorhanden Laptops, in betriebnehmen können.

Hierzu eine generelle Anmerkung (entschuldigt bitte die etwas spitzfindige Feder ;-) ), die ich weiter oben vergessen habe: Wenn man den Leitstellenbetrieb in einem ELW führen muss, weil die reguläre Leitstelle ausfällt, sollte man davon ausgehen, dass der gesamte Standort der regulären Leitstelle ausfällt (Beispielszenario: Hochwasser, alle Technikräume stehen unter Wasser). Sehr wesentlich ist für das drahtbezogene Redundanzkonzept (=Notrufleitung), wie man die Anbindung der Notrufleitungen löst, denn man kann nicht davon ausgehen, im Falle eines Leitstellen-Ausfalls den ELW bzw. die "Reserve-Leitstelle" auf dem Hof des Leitstellen-Gebäudes zu stellen und auf Teile der dort vorhandenen Technik zugreifen können. Die steht ja szenariobedingt unter Wasser ;-).

[Michel]

Richtig! Davon sind wir auch nicht ausgegangen! Wir werden an verschiednen städtischen Einrichtungen, die alle mit einer Amtsleitung verbunden sind an markanten Stellen einen Abgriffspunkt einrichten auf den die Telefongesellschaft die 112 routet. Das müßte gehen! Aber trotzdem guter ergänzender Hinweis an dieser Stelle. Danke.

[Fabpicard]

Wir werden an verschiednen städtischen Einrichtungen, die alle mit einer Amtsleitung verbunden sind an markanten Stellen einen Abgriffspunkt einrichten auf den die Telefongesellschaft die 112 routet.

Da würd ich mir aber lieber eine Sateliten-Datenlink holen auf den ich im Bedarfsfall die 112 routen lassen kann ^^

Nur mal so als Anmerkung ;)

Falls die Russen kommen und schon alle Schulen, Rathäuser usw besetzt halten :D

MfG Fabsi

[Michel]

Tipp: Sucht euch einen Generalunternehmer, der euch das gesamte System zum Festpreis liefert und integriert. Angefangen von der Hardware - Server, idealerweise als hochverfügbarer Cluster ausgelegt,....

Was ist ein "hochverfügbarer Cluster"?

[Fabpicard]

Was ist ein "hochverfügbarer Cluster"?

Siehe dazu:

http://de.wikipedia.org/wiki/Computercluster

Und dann unter " Hochverfügbarkeitscluster" ;)

MfG Fabsi

[Michel]

Danke! Demnach wäre eine stretched Cluster-Lösung doch prima mit LST und ELW 2 zu verbinden. Natürlich wäre die Baugröße des ELW2-Clusters nicht gerade überragend und es bleibt fraglich ob es überhaupt technisch möglich ist, aber aufjedenfall interessant!

[fussel]

Was ist ein "hochverfügbarer Cluster"?

Ich bin zufällig zertifizierter Systems Engineer für Clustersysteme eines bekannten Deutschen IT-Lieferanten ;-), daher erlaube ich mir hier noch ein paar Worte zum Prinzip von Hochverfügbarkeit und solchen Clustern:

Cluster sind wie schon aus dem Wikipedia-Artikel bekannt Rechnerverbünde, die aus verschiedenen Knoten (Einzelrechner) bestehen und der Aussenwelt vorgaukeln, sie seien ein einziger Rechner. Die Knoten sind über einen sog. Cluster-Interconnect (prinzipiell eine besondere Netzwerkleitung) miteinander verbunden und senden sich darüber Heartbeats, also Lebenstakte zu. Darüber wissen alle Knoten eines Clusters immer, ob die anderen Knoten noch leben. Über den Cluster Interconnect laufen nur die Heartbeats und keine anderen Dinge. Üblicherweise haben die Knoten einen redundanten Cluster-Interconnect (also zwei oder mehr) und darüberhinaus weitere Netze, mit denen sie untereinander und mit der Aussenwelt verbunden sind. Die Daten eines Clusters liegen typischerweise nicht auf den Knoten selbst, sondern auf einem nachgeschalteten Storage-System, welches meist als RAID 5 oder gar als RAID 50 bzw. als Storage Area Network (SAN) ausgelegt ist.

Hochverfügbarkeit (HV) bedeutet nun, dass eine beliebige Applikation - z.B. ein Serverprozess des Einsatzleitrechners - auf einem (und nur auf einem!) dieser Knoten läuft. Gibt es ein Problem mit diesem Knoten oder der darauf laufenden Applikation, so wird dieser Knoten von den anderen als fehlerhaft erkannt und kontrolliert "getötet". Wenn der getötete Knoten meldet, dass er definitiv heruntergefahren/getötet ist (der geneigte Leser wird sich jetzt fragen, wie ein getöteter Rechner noch etwas melden kann, aber dies ist unter anderem ein Grund, warum die Cluster-Hersteller sich gut bezahlen lassen ;-) ), wird auf einem zweiten Knoten die Applikation automatisch neu angefahren. Für den Benutzer der Applikation steht diese nach einem Zeitdelta, welches für die Umschaltung gebraucht wird (Applikation auf einem Knoten töten und auf dem anderen wieder anfahren), wieder in der gleichen Weise zur Verfügung wie vor der Umschaltung.

Wichtig ist, dass eine Applikation immer nur auf einem einzigen Knoten läuft. Wenn die gleiche Applikation auf zwei Knoten gleichzeit läuft, könnte sie die gemeinsame Datenbasis zerstören.

Im Unterschied hierzu ist ein Parallelrechner zu sehen, der wirklich "heiss" mitläuft und in Bruchteilen von Sekunden - also ohne das Zeitdelta für die Umschaltung - die Applikation auf einem anderen Knoten zur Verfügung stellt. Das kostet allerdings noch viel mehr als ein HV-Cluster und ist recht selten...

Ein streched Cluster ist prinzipiell für den genannten Fall geeignet, aber man sollte generell in der Leitstelle einen aus mindestens zwei Knoten bestehenden Cluster vorsehen. Fallen beide aus, könnte der Knoten im ELW übernehmen. Cluster nehmen nicht viel Platz weg. Unserer (alerdings recht kleiner) ist nur wenige Höheneinheiten hoch (die zugehörige USV ist mit 10 HE größer als Cluster und Storage-System).

Habe ich für genug Verwirrung gesorgt ;-)?

[Michel]

Habe ich für genug Verwirrung gesorgt ;-)?

Das war genial erklärt! Also wäre es sinnvoll 2 Knoten in der LST zu haben und einem im ELW. Ergo drei insgesamt. Ich könnte mir auch vorstellen im technikraum der Wache 2 so einen 2. bzw. 3. Knoten aufzustellen, aber das wird wohl irgendwann den Finanzrahmen sprengen!

Ist es somit richtig, das ein sicheres LST-System in dr Regel aus HV Clustern besteht oder gibt es alternative Sicherheitssysteme?

Wie sieht also insgesamt mit dr Redundanz in euren LST aus?

[fussel]

In der ILS sollte man einen HV-Cluster haben mit mindestens zwei Knoten. Leider kann man bei einem HV-Cluster die einzelnen Knoten nicht "einfach so" beliebig weit auseinander stellen (also z.B. in unterschiedliche Wache). Die Länge des Cluster-Interconnects ist bei den meisten Herstellern begrenzt, damit sich keine Fehlerquellen einschleichen. So wäre es z.B. nicht besonders sinnvoll, wenn man einen Cluster-Interconnect über mehrere aktive Netzwerkomponenten (Switches/Router/Bridges/etc) führt, weil dort ein Defekt in der Netzwerkkomponente zu einem Umschalten des Clusters führen könnte, was nicht gewollt ist, da es dem Cluster an und für sich ja gut geht. Ein HV-Cluster ist somit meistens örtlich begrenzt. Anders ist es bei einem Storage Area Network, das kann (und sollte!) man über entsprechend schnelle IP-Strecken (z.B. über Lichtwellenleiter) verbinden und an unterschiedlichen Orten aufstellen.

Inwieweit sich ein Streched-Cluster praktischt realisieren lassen würde, muss man jedenfalls detailliert mit den beteiligten Zulieferern abstimmen (sowohl Cluster-System wie auch Einsatzleitrechner). Solche Ausfallszenarien sind derzeit wie schonmal angedeutet noch etwas stiefmütterlich behandelt worden. Erst in den letzten Jahren geht man da ran.

Ein sicheres EDV-System sollte so aussehen:

* Plattenkapazität: über ein Storage Area Network (SAN) oder ein RAID5 / RAID50-Storage-System, welches die Daten sicher speichert. Das Storage-System sichert gegen Hardware-Ausfall der Festplatten und der RAID-Kontroller und stellt die Erweiterungsfähigkeit des Systems sicher (einfach im laufenden Betrieb weitere Platten reinstecken und Volumes vergrößern). Festplatten können im Fehlerfall im laufenden Betrieb und ohne Datenverlust ausgetauscht werden. Das Storage System wird an die Server bzw. den Cluster mittels Gigabit-Leitungen angeschaltet (oft über fiberoptische Leitungen mit 2 oder 4 Gigabit Durchsatz).

* Backup-Lösung zum Archivieren der Daten

* HV-Cluster für die dauerhafte Verfügbarkeit der Applikationen (wie oben beschrieben). Auf dem Cluster laufen alle Dienste wie RDBMS-System (SQL-Datenbanken wie Oracle oder MySQL), zentrale Einsatzleitrechner-Prozesse und dergleichen mehr. Der Cluster stellt die hohe Verfügbarkeit der Applikationen bei Hardware-Ausfall eines Knoten sicher.

* Doppelte Datennetze

* Autarke, mehrfach redundate Stromversorgung über USVn und Dieselgenerator für mehrstündigen autonomen Betrieb der Leitstelle

die Ausfallsicherheit der Kommunikationssysteme (Funk, Notrufleitungen etc.) lasse ich hier mal aussen vor.

Du kannst dich auch jederzeit per Mail bei mir melden, wenn Du weitere Infos haben möchtest.

[Michel]

Wieder sehr ausführlich und vieln Dank für das Angebot. Ich werd drauf zurückkommen! Danke!!! ;-)