Hallo liebe Community,
wisst Ihr ob die Hersteller von Achterbahnen die Software für Ihre Bahnen selbst entwickeln oder gegebenenfalls ob ihr Hersteller von Software dieser Art kennt?
Des Weiteren sollten Achterbahnen ca. 30 Jahre laufen was mich dazu veranlasst, dass diese Software oder zumindest die Bibiliotheken der Software Open Source sind.
Ich möchte hier klar stellen, dass ich diese Informationen aus reinem Interesse an Achterbahnen und deren Technik habe.
Open Source? Ganz bestimmt nicht. Die Sicherheitsansprüche an derartige Software sind viel zu hoch, als dass man Code einsetzen könnte, für den letztendlich niemand verantwortlich zeichnet.
Quadratische Bilder aus Freizeitparks: instagram.com/multimueller
Diese Steuerungen werden entweder im eigenen Haus oder von einem Subunternehmer programmiert werden. Und ich kann mir beim besten Willen nicht vorstellen, dass eine solche Steuerung Open Source werden wird. Eine für Simulationszwecke ausreichende Steuerung sollte sich mit ein wenig Kenntnis der Materie auch problemlos von Hand programmieren lassen.
I''''m an orange... HEY APPLE!!! Aaahahahahahahahaha!! HEY! How do Rabbits like their beer brewed? With a lot of hops. Hahaha!!! Get it?! HOPS! Hahahaha! BLACK is beautiful...and Hardstyle is my style!
Diverse Verschlüsselungsalgorithmen sowie, Verschlüsselungstools sind ja auch Open Source.
Des Weiteren gibt es bei Achterbahen ja auch eine physische Sicherungen oder?
Meiner Meinung nach wäre doch das Risiko, dass ein Server + USV den Geist aufgibt viel zu hoch.
Die Unterschiede zwischen freier Software und zu lizenzierende Software liegen eher in den Möglichkeiten, die sie bieten und dem Programmierkomfort.
Ich denke, dass auch bei Achterbahnen zur Steuerung der Grundfunktionen eine SPS im Einsatz ist. (Siemens oder Phonix bieten hier z.B. kommerzielle Systeme)
Sicherheitsfunktionen werden in Hardware, also Ausfallsicher konzipiert, d.h. die Anlage wird überwacht und sobald ein Fehler auftritt wird die Anlage in einen definierten Zustand gebracht, unabhängig davon was die SPS ausgibt.
Seit ein paar Jahren bietet Siemens eine "Safety SPS", d.h. mit dieser SPS lassen sich auch Sicherheitsfunktionen realisieren. Ob und wie weit man diese Technik bei Achterbahnen einsetzen kann weis ich nicht, aber zumindest bei uns kommt zum Personenschutz in den Anlagen zum Einsatz.
Was lässt dich zu der annahme kommen, das gerade weil eine Achterbahn 30+Jahre laufen soll, die Software OpenSource sein soll?
Zumal in der Regel bei solchen Attraktionen wie von dir bereits erwähnt sogenannte Speicherprogrammierbare Steuerungen (SPS) eingesetzt werden (und nicht nur bei Achterbahnen, auch bei Fahrgeschäften sind diese schon lange im Einsatz!).
In einer SPS gibt es dann 2 Arten von "Software". Zum einen das Betriebssystem der SPS (Im PC würde man es BIOS nennen!), und die vom Anwender bzw. Programmierer vorher zu erstellende den entsprechenden Anforderungen entsprechende Software (Firmware). In letzterer werden dann sämtliche Informationen über Sensoren und bedienungselemente abgelegt, sowie entsprechend bestimmt, was die SPS beim drücken der "starttaste" darf und was nicht. Natürlich in abhängigkeit davon was die entsprechenden Sensoren der SPS melden.
Entsprechende Hardware sorgt dann dafür, das im Falle eines Fehlers, div. Sicherungsfunktionen aktiviert werden (Z.b. das abblasen von Druckluft, bei Stromausfall - damit die Bremsen mittels Federspeicher geschlossen werden können usw.).
Um eine SPS mittels PC zu programmieren, ist eine weitere Software erforderlich. Am bekanntestens ist hier wohl das von der Firma Siemens vertriebene Prodkut "Step 7" bzw. deren Vorgänger "Step 5".
Und gerade da ist nix mit "Open Source" schon gar nicht mit der vom Anwender erstellten "Software" für die SPS, das geht sogar soweit, das manche Hersteller diese "Firmware" überhaupt nicht mit ausliefern, wenn ihre Attraktionen ausgeliefert werden. Schließlich heißts in der Regel - einmal programmiert und gut ist.
Meine Annahme bezieht sich darauf, dass z.B. viele Käufer die Vorgabe geben in den Quellcode usw. eine Einsicht haben zu können. Die Wahrscheinlichkeit, dass ein Software Hersteller noch in 30 Jahren diese Software supportet düfte wohl relativ gering oder kostspielig sein.
Ich denke wir sollten hier auch den Unterschied zwischen Open Source und Closed Source betrachten. Ich habe nicht unbedingt gemeint, dass die Software Hersteller alle Bibliotheken zur verfügung stellt.
Hm... Eine Software die nie Fehler enthält? Ich glaube da sucht man lange.
Na ja. Das ist wohl mehr eine Demonstration des Selbstverständnisses eines gewissen Herrn Knuths (der Autor der Reihe "The Art of Computer Programming" ist), als ein Beweis dafür, dass TeX fehlerfrei sein soll. Viele Bugs in TeX werden vermutlich nie gefunden, weil im Gegensatz zu anderen Programmen die Benutzer bei Problemen zuerst an einen Bedienfehler denken, als an einen Software-Bug. Wäre das doch immer so...
Quadratische Bilder aus Freizeitparks: instagram.com/multimueller
Abgesehen davon, das die Haltbarkeit einer SPS meistens keine 30 Jahre beträgt, sondern zwischendurch oft getauscht wird, gegen neuere Versionen, und für diese neueren Versionen WIEDER neue Programmiersoftware zur verfügung steht ist das eigentlich auch kein Problem.
Ich sage es nochmal: In den QuellCode der Programmiersoftware wirst du, noch ein Käufer eine Einsicht haben. Ähnlich siehts mit dem "BIOS" der SPS aus.
Bei der "Firmware" mag es evtl. anders aussehen, da dieses Sache des Käufers bzw Herstellers des durch die SPS zu steuernden Gerätes aus. Hier könnte man den Quellcode dieser Firmware wenn man möchte offenlegen. Was aber in der Regel nicht gemacht wird. (Wie ja bereits erwähnt!)
Hm... Eine Software die nie Fehler enthält? Ich glaube da sucht man lange.[/quote]
Lach nicht, ich kenne da die Firmware eines Fahrgeschäftes, welches seit vielen Jahren betrieben wird, deren Firmwarestand immer noch 1.0 ist!
Du darfst so eine Software halt nicht mit einer Software für einen PC vergleichen. Beim PC muss man beim Programmieren verschiedene Hardwareplattformen berücksichtigen, sowie verschiedene Treiberversionen und evtl. unterschiede in Betriebssystemen. Bei einer SPS sieht das anders aus. Dort ist die Hardware bekannt, und immer gleich so das man keine kompromisse eingehen muss (Wenn PORT 1 = High dann PORT2 = Low und nicht Wenn PORT1 = HIGH dann PORT2 = LOW ABER WENN PORT1 NOT PORT1 SONDERN PORT3 *bla bla bla). Somit ist es hierbei schon möglich eine fehlerfrei arbeitende Software zu Programmieren, welche dann Jahrelang funktioniert. Und wie schon gesagt, es gibt sogar Hersteller welche diese Software noch nichtmal als "Backup" mitliefern zu ihren Geräten. Sollte es hier zu einem defekt kommen, muss halt der Hersteller die SPS neu programmieren.
Man sollte hier auch mal sagen das die SPS in den meisten Fällen das Sicherheitskritischste ist das an so manch einer Anlage verbaut ist. Hier laufen alle Sicherheitsrelevanten Daten auf wie z.B. Drehzahlen Min/Max, Laufzeiten Min/Max, Endschalter, Melder... woraus die Firmware das Blocksystem bildet.
Übrigens interessiert sich der TÜV auch sehr für die Steuerung und besonders für die SPS und genehmigt diese sollte sich auch nur eine Logische Verknüpfung ändern Erlischt die Betriebserlaubnis.
Also neue SPS Hardware Version = neue Firmware = neue Abnahme
Siemens Produziert und Repariert immer noch SPS Steuerungen für Kraftwerke im Original (ohne jegliche Änderung von Bauteilen) da sonst die Zulassung erlischt oder für neue Hardware eine neue Zulassung fällig ist.
Sicherheitsrelevante Sachen (wie Not-Aus, Türschalter, Endschalter, Stillstands-/Drehzahlüberwachung) laufen bei neueren Maschinen sehr oft über eine Sicherheits-SPS (z.B.: PNOZ-Multi von Pilz), diese werden sehr oft in FUP programmiert (Funktionsplan, einfache programmierung), hier wird ein Programmausdruck sehr oft dem Kunden zusammen mit dem Stromlaufplan mitgeliefert, die Parametriersoftware hat mehrere Benutzerlevel, der Kunde bekommt in der Regel höchstensn nur das Passwort zur einfachen Online-Diagnose, Änderungen an einem Sicherheits-SPS-Programm darf und kann nur der Hersteller der Maschine machen.
Früher mussten solche Sicherheitsrelevanten Sachen Hardwaremässig mit Sicherheitsrelais ohne SPS realisiert werden.
Andere Sachen wie z.B.: Bewegungsabläufe, Ansteuerungen von Magnetventilen werden sehr oft über die "normale" SPS gemacht, einfachere Anwendungen werden nach wie vor z.B. in FUP programmiert, aufwändigere und zeitkritische Anwendungen sehr oft in "C" geschrieben, hier wird sehr oft kein Programmausdruck mitgegeben. Damit sichergestellt ist daß beide SPS-Steuerungen sicher laufen muss die normale SPS ein getaktetes Signal über eine Leitung zur Sicherheits-SPS schicken, diese nimmt dann im Fehlerfall den Laststrom weg. Verschiedene Funktionen, vor allem wenn es um Bewegungen von Achsen geht welche die normale SPS bzw. der Servoverstärker (welcher am Feldbus an der SPS hängt) regelt und steuert wird zusätzlich von der Sicherheits-SPS überwacht.
Insgesamt lässt sich sagen das die Steuerung von Achterbahnen weder besonders kompliziert noch rechenintensiv ist. Wenn man die Motortreiber und Pneumatikanlagen mal außer acht lässt würde zur rein formalen Steuerung sicherlich ein 8-Bit Mikrocontroller reichen (fahren würde ich mit so einer Bahn allerdings nicht).
Schwierig wird es erst bei machanischen Sondereffekten oder bei Abschussmechanismen. Ich habe mal im Speedmonster Maschinenraum vor dem Rechner gestanden - wahnsinn was das Sicherheitssystem da alles überprüft und ermittelt. Wenn zwei reduntante Sensoren dann mal nicht genau das gleiche Ergebnis liefern gibt es einen Notstop. Seit dem wundert es mich nicht dass diese Anlagen zu Downtimes neigen, es wundert mich eher dass sie den ganzen Tag funktionieren!
Eine moderne Achterbahn braucht schon mehrere Steuerungen:
- Sicherheitssteuerung(en) (Bügel, Zaun, Hintertretschutz, Stillstands-/Drehzahlüberwachung für Antriebe,...)
- Standard-SPS (dürfte bei neueren Anlagen ein Industrie-PC mit Touchscreen-Panel, und Feldbus-Karte z.B. für Profibus DP, CAN-Open, Powerlink,... sein). Diese wird für die Steuerung der ganzen Betriebsarten wie Ablauf im Normalbetrieb, Zug einfädeln/ausfädeln,..., Überwachung der Kraft an den Stützen und Schienen (über Dehnungsaufnehmer, die an Analog-Eingangsmodulen angeschlossen sind), Runden-Wartungs-Zähler für jeden Zug, Anzeige und Visualisierung von Störungen. Bei so vielen Sensoren wird locker ein 32-Bit-Prozessor benötigt, damit das System echtzeitfähig bleibt.
- Für die ganzen Sound-, Multimedia- und Lichteffekte wird nochmals eine seperate Steuerung/PC benötigt
Die ganzen Steuerungen können über Ethernet, Feldbus, serielle COM-Schnittstellen, Hardwarebrücken (Ausgangsklemme von der einen Steuerung auf eine Eingangsklemme der andern Steuerung) miteinander verbunden sein.
Okay, da kommt doch mehr zusammen, aber wirklich viel berechnet werden muss da ja nicht.
An welcher Bahn wird denn die Statik überwacht und welche Sinn soll das ergeben?
Um alles Echtzeitfähig zu machen sollte die Programmzykluszeit sehr kurz sein z.B.: 1 ms oder besser noch kleiner. Wenn z.B.: zwei Endlagen zur Richtungserkennung des Zuges ca. 0,5m von einander entfernt montiert sind und der der Zug zuerst Sensor1 auslöst und 10ms später Sensor2 auslöst reicht eine zu lange Zykluszeit (z.B.: 10ms) nicht aus, die Steuerung kann nicht mehr eindeutig erkennen welcher Sensor vorher ausgelöst hatte und die Steuerung meint dann beide Sensoren wurden gleichzeitig ausgelöst.
Zur Statiküberwachung: Beim Silver Star wird die Statik überwacht, habe ich vor einigen Monaten gelesen. Da bei Personenbeförderungsmitteln die allerhöchste Sicherheitskategorie erforderlich ist macht das sehr viel Sinn. Weicht die Belastung zu stark vom Sollwertbereich ab, kann davon ausgegangen weden daß es in der Statik ein Problem gibt, dem nachgegangen werden muss.
Jedem, der sich mit dem Thema Automatisierung praktisch beschäftigen möchte, sei in diesem Zusammenhang das excellente LEGO Mindstorms NXT empfohlen. Hinter der Steuerungs-Software steckt übrigens das durchaus professionelle NI LabVIEW.
Quadratische Bilder aus Freizeitparks: instagram.com/multimueller
Vor 30 Jahren konntest du die Dinger wahrscheinlich noch verkabeln, wie ein Bloeder.
Da lief alles noch ueber Relais. Da hattes du ein Haufen Schaltschraenke.
Heute wird vorwiegend SPS (evtl. S7 von Simens oder PCWorx von Phoenix Contact) genutzt.
Dann hsst du nur noch einen Rechner, eine SPS und stoepselst den Rest per Bussystem (Bsp. Interbus, Profibus) dran.
gruss
First Place: MF Second Place: EGF Third Place: Sex :D ...und was soll das mit den verhaeltnismaessig zu vielen Grossbuchstaben?! :lol:
/var/www/onride/onride.de/includes/functions.php on line 635: in_array() expects parameter 2 to be array, null given /var/www/onride/onride.de/includes/functions.php on line 635: in_array() expects parameter 2 to be array, null given /var/www/onride/onride.de/includes/functions.php on line 635: in_array() expects parameter 2 to be array, null given /var/www/onride/onride.de/includes/functions.php on line 635: in_array() expects parameter 2 to be array, null given /var/www/onride/onride.de/includes/functions.php on line 635: in_array() expects parameter 2 to be array, null given /var/www/onride/onride.de/includes/functions.php on line 635: in_array() expects parameter 2 to be array, null given /var/www/onride/onride.de/includes/functions.php on line 635: in_array() expects parameter 2 to be array, null given /var/www/onride/onride.de/includes/functions.php on line 635: in_array() expects parameter 2 to be array, null given /var/www/onride/onride.de/includes/functions.php on line 635: in_array() expects parameter 2 to be array, null given /var/www/onride/onride.de/includes/functions.php on line 635: in_array() expects parameter 2 to be array, null given /var/www/onride/onride.de/includes/functions.php on line 635: in_array() expects parameter 2 to be array, null given /var/www/onride/onride.de/includes/functions.php on line 635: in_array() expects parameter 2 to be array, null given /var/www/onride/onride.de/includes/functions.php on line 635: in_array() expects parameter 2 to be array, null given /var/www/onride/onride.de/includes/functions.php on line 635: in_array() expects parameter 2 to be array, null given /var/www/onride/onride.de/includes/functions.php on line 635: in_array() expects parameter 2 to be array, null given /var/www/onride/onride.de/includes/functions.php on line 635: in_array() expects parameter 2 to be array, null given /var/www/onride/onride.de/includes/functions.php on line 635: in_array() expects parameter 2 to be array, null given /var/www/onride/onride.de/includes/functions.php on line 635: in_array() expects parameter 2 to be array, null given /var/www/onride/onride.de/includes/functions.php on line 635: in_array() expects parameter 2 to be array, null given /var/www/onride/onride.de/includes/functions.php on line 635: in_array() expects parameter 2 to be array, null given /var/www/onride/onride.de/includes/functions.php on line 635: in_array() expects parameter 2 to be array, null given /var/www/onride/onride.de/includes/functions.php on line 635: in_array() expects parameter 2 to be array, null given /var/www/onride/onride.de/includes/functions.php on line 635: in_array() expects parameter 2 to be array, null given /var/www/onride/onride.de/includes/functions.php on line 635: in_array() expects parameter 2 to be array, null given /var/www/onride/onride.de/includes/page_tail.php on line 105: Illegal offset type
multimueller
Ich glaube da sucht man lange. 
. Serverzeit 0.47s - Ladezeit wait - 105 Abfragen - Fläche ?
