Hallo Zusammen, scheint so, als beginne man Stellwerke in FPGAs zu implementieren: http://www.deutschebahn.com/de/presse/presseinformationen/pi_it/3265064/ubd20130306.html Warum erst jetzt? Ich behaupte mal, dass es einfacher ist die Korrektheit von Hardware-beschreibungen als jene von Programmen zu verifizieren. Auch hat man bei FPGAs deutlich weniger Abstraktion (kein Betriebssystem, etc.) Was sagt ihr dazu?
Stellwerke arbeiten seit jeher - also auch schon vor der Relais-Technik - digital, nicht analog. Insofern ist diese Presseinformation eine reine Anhäufung von Schlagwörtern - Tenor: Schaut mal, wie modern wir sind! Im übrigen möchte ich einmal das FPGA sehen, welches 1. ohne zwischengeschaltetes Leistungsglied eine Weiche betätigt 2. Rückmeldesignale von der Strecke ohne externe Eingangsbeschaltung verkraftet. Bernhard
Bernhard R. schrieb: > Im übrigen möchte ich einmal das FPGA sehen, welches > 1. ohne zwischengeschaltetes Leistungsglied eine Weiche betätigt > 2. Rückmeldesignale von der Strecke ohne externe Eingangsbeschaltung > verkraftet. Dafür muss man doch nur den IOSTANDARD auf HPDS (High Power Differential Signaling) setzen und die IO-Bank entsprechend versorgen :)
Und sicherlich werkelt darin eine NIOS, MICROPLACE, ... mit Ethernet darin.
So nen Artikel kann nur ein BWLer geschrieben haben, der FPGA als Stichwort im Zusammenhang mit "modern" aufgeschnappt hat. Lukas K. schrieb: > Ich behaupte mal, dass es einfacher ist die > Korrektheit von Hardware-beschreibungen als jene von Programmen zu > verifizieren. Damit ist es leider nichtmal ansatzweise getan, um einen für ein Stellwerk notwendigen SIL zu erreichen. Logikwurstler schrieb: > Und sicherlich werkelt darin eine NIOS, MICROPLACE, ... mit Ethernet > darin. Unter Garantie nicht nur einer ;-)
Hut ab von den jungs, die die FPGA fehlerfrei 'programmieren' müssen. Ich dachte bei mir schon oft 'hier kann doch kein Fehler sein', und siehe da, bei 1000 Platinen ohne Probleme und bei der 1001ten tat sich ein Timing Problem auf. Hier zu sagen sowas ist einfacher wie bei einer Softwarelösung, der hat noch nie ein großes FPGA Design gemacht - das kann der Horror sein ...
Sicherheitskritische Anwendungen wie ein Stellwerk müssen fail-safe sein. D.h. im Fehlerfall, durch Software- oder Hardwarefehler muss das System immer zur sicheren Seite zurückfallen. Ein gutes Beispiel sind die alten mechanischen Signale. Reisst der Betätigungsdraht ab, fällt der Zeiger durch sein Eigengewicht nach unten. Die Strecke ist gesperrt. Bei elektronischen Systemen werden Halbleiter generell als nicht sicher angenommen. Eine Fuse kann ausfallen, durch Migration in einem Chip können neue ungewollte Verbindungen auftauchen. Redundanz alleine reicht nicht aus. Daher wird viel Aufwand betrieben um die Sicherheit zu gewährleisten. Ob ein System durch Controller, FPGAs oder anderes realisiert wird ist dabei sekundär.
Nucor schrieb: > Sicherheitskritische Anwendungen wie ein Stellwerk müssen fail-safe > sein..... Absolut richtig, was du schreibst.. Und wenn man sich den aus deiner Beschreibung resultierenden Testaufwand vor Augen führt, dann wird schnell klar, dass sowas komplett in einem FPGA zu realisieren unglaublich viel schwieriger ist, als per Software. Daher gehe ich davon aus, dass in diesem "ehrgeizigen" Projekt der FPGA nur eine untergeordnete Rolle spielt und mit der Safety recht wenig zu tun hat.
FPGA schrieb im Beitrag #3086359: > Dafür muss man doch nur den IOSTANDARD auf HPDS (High Power Differential > > Signaling) setzen und die IO-Bank entsprechend versorgen :) Eine "rail to rail" Versorgung sozusagen :-) Ich sehe sie schon, die extended Kintex, mit anschflaschbarem Leistungstreiber zum anschrauben. Ich persönlich sehe bei den Weichen keinen Bedarf für FPGAs. Die fressen zuviel Strom, haben einen engeren Temperaturbereich = Reserve bei Betrieb, als Prozessoren, und die Bandbreite braucht kein Mensch.
Harkan schrieb: > Ich persönlich sehe bei den Weichen keinen Bedarf für FPGAs. Die fressen > zuviel Strom, haben einen engeren Temperaturbereich = Reserve bei > Betrieb, als Prozessoren, und die Bandbreite braucht kein Mensch. So sieht´s aus.. Aber interessant wäre es schon, welche Funktionen die da mit dem FPGA erschlagen.
> Aber interessant wäre es schon, welche Funktionen die da mit dem FPGA > erschlagen. Naja, bei den mechanischen und elektromechanischen Stellwerken läuft ja relativ viel über Verriegelung, gegenseitiges Blocken, etc. Was aber wen blockiert, hängt vom konkreten Aufbau des Bahnhofs ab (Weichen, Fahrstrassen, ...). Bei den alten Methoden war das quasi immer ein Custom-Build und bei Änderungen (neue/keine Weiche) wirds mühsam. Hab auch schon gelesen, dass bei Rückbau im Stellwerkskeller dann eine Schrankenmechanik oder nur ein Weichenmotor rumliegt (und auch rummört...), was die weggefallene externe Komponente betrieblich ersetzt, damit keine Änderungen der Stellwerkslogik nötig sind... Ich könnte mir vorstellen, das Stellwerksabläufe in einem FPGA relativ generisch synthetisierbar und auch testbar sind. Man kann eine ganze Menge interne Redundanz (Majority Voting) und parallel+unabhängig laufende Sanitychecks einbauen, was auf dem niedrigen Level mit normalen CPUs nicht geht.
oder man macht redundante Funktionen mit unterschiedlicher Technik: eine state machine im Prozessor mit Software und eine im FPGA, die sich gegenseitig überwachen.
Schlumpf schrieb: > Und wenn man sich den aus deiner Beschreibung resultierenden Testaufwand > vor Augen führt, dann wird schnell klar, dass sowas komplett in einem > FPGA zu realisieren unglaublich viel schwieriger ist, als per Software. > > Daher gehe ich davon aus, dass in diesem "ehrgeizigen" Projekt der FPGA > nur eine untergeordnete Rolle spielt und mit der Safety recht wenig zu > tun hat. Und weshalb bietet Altera dann Tools und Devices an, mit denen eine Zertifizierung bis SIL3 möglich ist? http://www.altera.com/end-markets/industrial/functional-safety/ind-functional-safety.html
Georg A. schrieb: > Ich könnte mir vorstellen, das Stellwerksabläufe in einem FPGA relativ > generisch synthetisierbar und auch testbar sind.[...] Ich stelle mir genau das unglaublich schwierig vor, da man bei einer integrierten Lösung in einem FPGA Fehler annehmen muss, die man bei einer diskreten Lösung ausschließen kann. Theoretisch kann in einem FPGA nicht ausgeschlossen werden, dass quasi jedes interne Signal mit jedem kurzgeschlossen sein kann. Bei einem diskreten Aufbau kann dies bei genügend Abständen hingegen ausgeschlossen werden. (nur mal als Beispiel) Auch bei der Bahn wird die EN61508 zugrunde liegen und da wird mit Sicherheit SIL3 oder sogar SIL4 für Stellwerke gefordert sein. Wie so ein hoher SIL mit einem FPGA erreicht werden kann, ist mir ein Rätsel. Wenn, dann kann ich mir nur vorstellen, dass das über mehrere "kooperierende" FPGAs funktionieren kann, die sich gegenseitig "überwachen". Eine Single-Chip-FPGA Lösung halte ich für ein Stellwerk nicht für ausreichend. Rein funktional natürlich schon, aber nicht, was die funktionale Sicherheit angeht.
Zufällig habe ich mir heute Mittag dieses Video angesehen: http://www.youtube.com/watch?v=xwaKYZfgY8k
Michael Fuhrmann schrieb: > Und weshalb bietet Altera dann Tools und Devices an, mit denen eine > Zertifizierung bis SIL3 möglich ist? Dazu schreibt Altera: Figure 1 shows a typical dual-channel SIL3 industrial "safe" system implemented with two FPGAs Betonung liegt auf "two".. genau, wie ich es in meinem Post von vorhin vermutet habe, dass man dann mindestens 2 FPGAs benötigt. Und was wird der IP-Core machen? Er wird zwei Statemachines in 2 FPGAs laufen lassen, die sich synchronisieren und gegenseitig auf Plausibilität prüfen. Also nichts, was man nicht in einem uC auch machen kann. Es wird also nicht funktionieren, dass man einfach ein paar "Stellwerksverknüpfungen" in VHDL beschreibt und diese durch die Synthese schiebt. Die Saftey kommt durch garantiert durch gewisse Abläufe im FPGA, die nicht auf Gatterebene zu bechreiben sind, sondern durch einen übergeordneten Flow. Und dann ist man von der Abstraktion auch wieder bei einer Art "Software", die auf dem Safety-Controller des FPGA läuft.
Wie man im Vortrag bei 0:33:28 erkennen kann, ist eine PFH von 10E-9 bis 10E-8 gefordert. Das entspricht SIL4. Und um SIL4 zu erreichen, reicht selbst die zertifizierte Altera-Lösung nicht aus..
> Eine Single-Chip-FPGA Lösung halte ich für ein Stellwerk nicht für > ausreichend. Davon hat auch keiner was gesagt ;) Wenn das Ding für einen grösseren Bahnhof in ein paar 19"-Einschübe passt, ist das ja schon ausreichend. Laut Text geht es ja im wesentlichen um Modernisierung von alten Stellwerken. > Die Saftey kommt durch garantiert durch gewisse Abläufe im FPGA, die > nicht auf Gatterebene zu bechreiben sind, sondern durch einen > übergeordneten Flow. Da wird sicher mehr ineinandergreifen. Aber ich glaube,dass man schon ganz unten gerade im FPGA Vorteile hat, weil man massiv parallel und verteilt Checks machen kann. Das ist schon was anderes als in SW, wo alles durch dieselben CPU-Pfade muss. FPGA-übergreifend kann man über die vielen IOs den Zustand auch redundant vergleichen bzw. verteilen. Hier gibts ein Patent, evtl. gehört das dazu: http://www.google.com/patents/EP2445771A1?cl=de Aber sonst ist die Informationslage schon etwas dünn...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.