Hallo zusammen,
im Rahmen eines prototypen Projektes muss ich etwa 15 digitale und 5
analoge Signale erfassen und per Ethernet (vermutlich UDP) an einen Host
PC zur Verarbeitung schicken. Zusätzlich sollen gleich viele digitale
Signale, die auch über Ethernet kommen als Ausgänge geschrieben werden.
Auf der gesuchten Hardware soll neben der reinen IO-Ethernet Umsetzung
auch ein wenig sicherheitskritische Software laufen:
- Fällt die Ethernetverbindung aus, soll das Ausgangssignal den
Eingangsignale entsprechen
- Ein speizieller DI Wert soll kontinuierlich im Betrieb untersucht
werden, weicht dieser von Wert xy ab so sollen ebenfalls die
Eingangssignale an die Ausgangsisgnale gesendet werden.
Also im Prinzip wird hier eine bestehende Signalleitung aufgetrennt mit
der Möglichkeit auf diese zurückzufallen sollte ein manueller Override
oder Netzwerkausfall auftreten - wie gesagt alles im Rahmen eines
Prototypens. Daher muss auch ich (und nicht ein Experte), mit meinen
Grundkenntnisse, das ganze im Rahmen einer Machbarkeitsstudie
untersuchen. Finanzielle Mittel sind wie immer knapp (akademisches
Projekt).
Im Brainstorming hab ich mir folgenden Möglichkeiten überlegt:
FPGA (mit µC):
-Kann nicht "hängen bleiben"
-Nutzung meiner Erfahrung in LabVIEW
-Vergleichsweise sehr teuer
-Nutzenes des FPGAs für die Programme aber auch in LabVIEW aufwendiger
Mikrokontroller
-Vergleichsweise preiswert
-Wie stellt man sicher, dass er nicht "hängen bleibt"?
-Kann man sowas mit eigenem Scheduler und Interrupts lösen oder lieber
gleich ein RTOS!?
Ich würde gerne eure Meinung und Rat hören. Beides hat seine Vor- und
Nachteile. Vielleicht hat jemand sogar einen Rat zu einem geeigenet
Evaluation Board (~ 30DIOs und Ethernet Port).
Vielen Dank schonmal!
Subcentos schrieb:> FPGA (mit µC):> -Kann nicht "hängen bleiben"
Interessante These. Was macht den µC hier besser als einen, der ohne
FPGA genutzt wird?
Zunächst sollte man die kritikalität des Ausfalls bewerten. Erst dann
kann man die zu realisierende Struktur festlegen.
Für Safety gibts z.b. die ISO26262
FPGA oder Mikroprotz bleiben in den seltensten Fällen hängen, weil die
Hardware streikt. Ursache ist fast immer das Programm. Und da kann man
sowohl in einem uC als auc hin einem FPGA hinreichend Unsinn machen.
Womit hast du die meiste Erfahrung? RTOS klingt toll. Aber wenn du damit
dein erstes Projekt machst, kalkuliere xx Wochen Einarbeitung ein. KISS
ist angesagt.
Vielen Dank schonmal für die vielen Antworten!
Rufus Τ. F. schrieb:> Interessante These. Was macht den µC hier besser als einen, der ohne> FPGA genutzt wird?
Der µC kann immernoch hängen bleiben ganz klar. Der FPGA kann dann aber
(so wie ich das bisher verstanden habe) für den sicherheitskritschen
Programmteil verantwortlich sich. Den µC brauch ich bei einem FPGA nur
für Ethernet (mit UDP oder TCP Support) oder sehe ich das falsch?
Flo schrieb:> ISO26262
Die Serienanwendung dürfte sicherlich ASIL C oder D sein ohne das ganze
mit FTA oder sonstiges geprüft zu haben. Der Prototyp mit eingewiesenem
Personal im gesonderten Testbetrieb sicherlich darunter.
C. A. Rotwang schrieb:> WDT
Richtig, aber kann ich damit auch die Ausführung der
sicherheitskritischen Abfragen genauso gut "garantieren" wie bei einem
FPGA. Beim Watchdog fängt das Programm effektiv immer wieder von vorne
an oder? Beim FPGA kann ich Sicherheitsabfragen parallel machen. Gerne
lasse ich mir aufklären (um dann mit dem µC Geld zu spaaren ;) )
Georg G. schrieb:> Womit hast du die meiste Erfahrung?
Mit µCs einige Bastelein (Inverse Pendel etc.) mit dem Arduino, mit
FPGAs mit dem myRIO von NI ebenfalls viele Bastelein.
Subcentos schrieb:>> WDT> Richtig, aber kann ich damit auch die Ausführung der> sicherheitskritischen Abfragen genauso gut "garantieren" wie bei einem> FPGA. Beim Watchdog fängt das Programm effektiv immer wieder von vorne> an oder?
Ja, oder gilt. manche µC können erkennen warum sie grad neustarten
(PowerUp oder WDT_reset) und dementsprechend unterschiedlich aufstarten.
>Beim FPGA kann ich Sicherheitsabfragen parallel machen.
Nimmste halt mehrere µC, dann geht da auch Parallel mit den Abfragen.
Wobei?, meinst du parallel oder redundant? Es gibt auch µC mit
eingebauter redundanz, check mal Infineon Aurix.
Subcentos schrieb:> Im Brainstorming hab ich mir folgenden Möglichkeiten überlegt:
[...]
Das Wichtigste in diesem Zusammenhang, womit jeder wissenschaftlich auch
nur halbwegs Gebildete mit seinen Überlegungen anfangen würde, das hast
du dir nicht überlegt: die Anforderungen bezüglich Durchsatz und
Latenzen.
Sprich: Es hat damit anzufangen, die zu erwartende Datenmenge und die
nötigen Antwortzeiten zu spezifizieren.
Weil: wenn da schon rauskommt, dass das ein generischer µC nicht oder
nur mit sehr großer Mühe schaffen kann, wird die Wahl schon von ganz
alleine ziemlich eng und du brauchst kein weiteres Hirnschmalz in diese
Entscheidung investieren, die Fakten haben sie für dich gefällt.
Alles andere ist schwachsinniges Gelaber ohne faktische Grundlagen.
Sollte eines Wissenschaftlers/Technikers unwürdig sein, selbst eines
(hoffentlich) noch Werdenden...
FPGA und Mikrocontroller sind beides komplexe Bauteile im Sinne 61508.
Du kannst keine Fehler ausschliesen. Punkt. Baue redundant, wenn es geht
diversitär.
Wenn du es in µC lösen kannst, ist das das Mittel der Wahl. FPGA ist
immer aufwändiger, und hat keinen Sicherheitsvorteil. Es ist aber
aufwändiger bei der Abnahme. Mit Labview braucht ihr dem TÜV vermutlich
nicht anzurücken.
Was µC angeht:
Im Normalfall baut man das System zweikanalig auf, z.B. mit µC die beide
die Funktion warhnehmen und sich gegenseitig prüfen. Absichern muss man
das gegen Fehler mit gemeinsamer Ursache - z.B. eine Überspannung, die
beide µC tötet oder so.
Hängt aber von den konkreten Anforderungen ab, wie Norm, SIL oder
Performance- Level und so weiter.
Was das Aufhängen angeht : Das hat man damit zuverlässig abgefangen. Die
µC prüfen sich gegenseitig, per zyklischer Kommunikation. Ist die
inkonsistent, lösen sie beide unabhängig voneinander den sicheren
Zustand aus.
Wir haben mit derartigen Systemen SIL2 erreicht.
Achja:
Bitte beachten, dass man bei einem Safety Projekt nicht "frei von der
Leber weg" loslegen darsf. Da gibt es Prozesse einzuhalten und das auch
nachzuweisen.
Ich rate hier zu einer frühzeitigen Beratung (aus eigener, bitterer
Erfahrung).
Eine Konzeptprüfung ist auch sinnvoll, das kann sehr viel Geld sparen.
Safety macht keinen Spass, soviel steht fest ;-)
Subcentos schrieb:> FPGA (mit µC):> -Kann nicht "hängen bleiben"
Klar kann der hängen bleiben. Wenn Du z.B. eine State Machine falsch
implementierst, kann er in einem undefinierten Zustand hängen bleiben.
Es können auch Glitches oder Timing Violations auftreten.
> -Nutzung meiner Erfahrung in LabVIEW
Also hast Du überhaupt keine Erfahrung in der richtigen Programmierung
mit VHDL oder Verilog. Das ist schon mal ganz schlecht.
> -Vergleichsweise sehr teuer
Das kommt darauf an, was Du darin implementieren willst. Kleine FPGAs
gibts ab 2.50€. Nach oben sind die Grenzen natürlich offen.
> -Wie stellt man sicher, dass er nicht "hängen bleibt"?
Watchdog.
> -Kann man sowas mit eigenem Scheduler und Interrupts lösen oder lieber> gleich ein RTOS!?
Wenn Du genug Know-How hast, kannst Du das alles selber machen. Wenn
nicht, überlasse das den Profis.
> > Womit hast du die meiste Erfahrung?> Mit µCs einige Bastelein (Inverse Pendel etc.) mit dem Arduino, mit> FPGAs mit dem myRIO von NI ebenfalls viele Bastelein.
Also immer nur "betreutes Programmieren" und keinerlei richtige
Erfahrung aus der Realität.
> Ich würde gerne eure Meinung und Rat hören. Beides hat seine Vor- und> Nachteile. Vielleicht hat jemand sogar einen Rat zu einem geeigenet> Evaluation Board (~ 30DIOs und Ethernet Port).http://www.ti.com/tool/msp-exp432e401y
Kostet bei TI 20$. Prozessor ist ein 120 MHz ARM M4F mit integriertem
MAC und PHY, 1M Flash, 256k RAM. IDE, Compiler, RTOS, Netzwerkstack und
Driverlib gibts von TI. Debugger ist auf dem Board mit drauf.
> - Fällt die Ethernetverbindung aus, soll das Ausgangssignal den> Eingangsignale entsprechen> - Ein speizieller DI Wert soll kontinuierlich im Betrieb untersucht> werden, weicht dieser von Wert xy ab so sollen ebenfalls die> Eingangssignale an die Ausgangsisgnale gesendet werden.
Diese beiden Funktionalitäten kannst Du sicher in einem kleinen 3€-FPGA
ohne Labview nur zu Fuß einfach implementieren. Das wäre ein n-fach
Multiplexer, der entweder die Signale vom Prozessor ausgibt oder auf
Bypass schaltet, und ein digitaler Komparator. Beides sind
Anfängeraufgaben.
Als Umschaltkriterium kannst Du z.B. die Ethernet Link LEDs auf Port F
auswerten und ggf. irgend einen Prozessorpin, der in der
Interruptroutine des Ethernet MAC gepulst wird. Der Puls setzt einen
Abwärtszähler auf einen Startwert zurück, und wenn der lange genug
ausgeblieben ist, dann läuft der Zähler im FPGA ab und setzt dann ein
Flag (==0), was dann auch zum Schalten auf Bypass führt. Auch das ist
relativ einfach in VHDL zu implementieren.
Als drittes kannst Du einen bestimmten Prozessorpin definieren, mit dem
der Prozessor sich in die Verbindung einklinkt.
Diese Dinge kannst Du natürlich auch in diskreter Logik implementieren,
aber ein kleines FPGA ist hier oft die bessere Lösung.
In vielen Fällen heißt es nicht "entweder oder", sondern "sowohl als
auch".
fchk
Subcentos schrieb:> - Fällt die Ethernetverbindung aus, soll das Ausgangssignal den> Eingangsignale entsprechen
Woran erkennst Du einen Ausfall der Ethernetverbindung?
Wie unterscheidest Du bösartig gefälschte Antwortpakete von korrekten?
Moin,
für solche Anwendungen habe ich mir letztes Jahr mal ne Plattform
herangezüchtet, weil solche Anforderungen auch bei den 'Kleinen' (also
nicht grade die mit Avionik-Geldbörse) immer mehr zum Thema werden.
Nennt sich 'netpp node' und ist als Eval-Kit bei mir auf Lager, bei
Interesse gerne anpingen.
Die Frage ist immer, welche Art von Sicherheit du anpeilst.
Siehe auch Beitrag "Microcontroller-Sicherheit in MIL-Systemen durch FPGAs erhöhen"Subcentos schrieb:> FPGA (mit µC):> -Kann nicht "hängen bleiben"
Kann es schon, wenn irgendwo ein fieser EMV-Spratz die Logik stört.
> -Nutzung meiner Erfahrung in LabVIEW> -Vergleichsweise sehr teuer> -Nutzenes des FPGAs für die Programme aber auch in LabVIEW aufwendiger
Das Problem (weswegen ich auch von LV strikt absehe): Die Geschichte ist
nicht vernünftig verifizierbar, abgesehen von der Wartbarkeit. Ich weiss
auch nicht, wie das ist, wenn man die von LV generierte (abgegriffene)
HDL einem Dritten zur Verifikation schickt...so rein rechtlich gesehen.
>> Mikrokontroller> -Vergleichsweise preiswert> -Wie stellt man sicher, dass er nicht "hängen bleibt"?
Das Thema Watchdog wird hier immer wieder durchgekaut, und man trifft
auf eine Menge an Murks. Habe des öfteren sicherheitsrelevante SW unter
der Lupe, wo sich bei den 'OS' der üblichen Verdächtigen eine nur noch
die Haare sträuben. Das Problem ist immer dann, wenn Watchdogs auslösen,
wenn sie eigentlich gar nicht sollten und bei gewissen Szenarien munter
Endlos-Rebootschleifen auftreten.
> -Kann man sowas mit eigenem Scheduler und Interrupts lösen oder lieber> gleich ein RTOS!?
Damit mal zum eigentlichen Thema: Die ganzen Richtlinien sind schön und
gut, aber oft eine Farce, wenn der Code-Ersteller nicht beweisen kann,
dass sein Programm korrekt abläuft.
Du kannst natürlich allen möglichen highlevel Tools (Rational, lint,
usw) und Richtlinien wie MISRA vertrauen.
Meine Meinung: Wenn ich persönlich für was haften muss, reicht das nicht
aus, und MISRA ist eigentlich Augenwischerei. Deswegen vertraue ich
eigentlich nur noch dem HDL-Simulator.
Und wenn du dann das ganze RTOS mit-verifizieren musst, wird das richtig
aufwendig.
Deswegen bin ich eher für den dualen Weg: die Sicherheitsschaltungen
sind simpel und in primiver Logik realisiert, somit sind die
Fehlerszenarien einfacher durchzusimulieren. Alles was irgendwie hart
'realtime' ist kommt in autonome Logik.
Für den Rest packt man sich einen gut verifizierbaren uC ins FPGA und
kann die main loop simpel halten. Der Gag an der ganzen Hybridlösung
ist, dass das komplette System inkl. Software in die Simulation gesteckt
werden kann. Ein uninitialisiertes HW-Register (was MISRA logischerweise
durch die Lappen geht) springt da z.B. sofort ins Auge.
Weitergehende Doku dazu findest du auch unter
https://section5.ch/index.php/dokumentation/masocist-soc/, da liegt auch
n Link aufn Docker-Container, den du für die "akademischen Zwecke" frei
missbrauchen kannst.
>>Auf der gesuchten Hardware soll neben der reinen IO-Ethernet Umsetzung auch ein
wenig sicherheitskritische Software laufen:
Ich würde empfehlen den sicherheitskritischen Teil nicht mit normaler
Funktionalität
zu vermischen. Willst du später Funktionalität erweitern wollen, musst
du nicht
nochmal zum TÜV.
C. A. Rotwang schrieb:> meinst du parallel oder redundant?
Nein, ich meinte wirklich paralell. Wenn beispiielsweise die Routine zum
Lesen/Senden der Ethernet Pakete (immer wieder) hängen bleibt, dann soll
dennoch die Durschleifung der originales Signale gewähleistet sein. Der
Watchdog setzt dann den µC zurück, dann müsste "nur" zu Beginn der Main
Loop die Sicherheitsabfrage kommen.
c-hater schrieb:> du dir nicht überlegt: die Anforderungen bezüglich Durchsatz und> Latenzen.
Doch hab ich, aber ich hab vergessen sie hier zu Posten. Nach einer
ersten Überlegung sollte der Sicherheitskritische Teil (also ob die
Signale durchgeschliffen oder die vom Netzwerk an den DOs gesendet
werden) auf jeden Fall < 50 ms garantiert sein! Für die Umsetzung der
eigentlich Signale, egal ob die aus dem DI oder die über Ethernet gilt
ähnliches, wobei hier wie immer schneller besser ist! Durchsatz kann ich
derzeit leider wirklich nur Abschätzen. Da warte ich selbst noch auf
neue Informationen. Wobei ich bei den DIs von etwa 100 Hz ausegehe. ABER
wie gesagt das sind erste Abschätzungen, die genauen Werte stehe noch
aus. Ich bin wie gesagt ganz am Anfang des Projektes und wollte mir im
Vorfeld die richtigen Gedanken machen!
Hmm schrieb:> Was das Aufhängen angeht : Das hat man damit zuverlässig abgefangen. Die> µC prüfen sich gegenseitig, per zyklischer Kommunikation. Ist die> inkonsistent, lösen sie beide unabhängig voneinander den sicheren> Zustand aus.
Sehr intressante Idee, über die ich noch gar nicht nachgedacht habe.
Danke für den Anreiz.
Martin S. schrieb:> Das Problem ist immer dann, wenn Watchdogs auslösen,> wenn sie eigentlich gar nicht sollten und bei gewissen Szenarien munter> Endlos-Rebootschleifen auftreten.
Genau dabei hab ich ebenfalls die größten Bedenken. Wenn ich einfach gar
nicht mehr zur Sicherheitsabfrage komme wäre schlecht. Jedoch wäre mein
Code eventuell ganz einfach und man könnte das dann ausschließen.
Martin S. schrieb:> Deswegen bin ich eher für den dualen Weg: die Sicherheitsschaltungen> sind simpel und in primiver Logik realisiert, somit sind die> Fehlerszenarien einfacher durchzusimulieren. Alles was irgendwie hart> 'realtime' ist kommt in autonome Logik.
So ähnlich hatte ich mir das mit dem FPGA von Anfang an gedacht - nur
dann eben mit LV, aber deine Begründung gegen LV kann ich gut
nachvollziehen. Wird sehr schwer wenn man das extern prüfen lassen
müsste (Ich weiß noch nicht ob das erforderlich ist, kläre ich derzeit).
Martin S. schrieb:> Für den Rest packt man sich einen gut verifizierbaren uC ins FPGA und
Das wäre bei mir ja nur die Verteilung von und nach Ethernet UDP, selbst
wenn die mal abstürzt/hängen bleibt wäre es dann nicht schlimm. Da die
Sicherheitsabfrage ausgelagert auf dem FPGA läuft.
Martin S. schrieb:> Weitergehende Doku dazu findest du auch unter> https://section5.ch/index.php/dokumentation/masocist-soc/, da liegt auch> n Link aufn Docker-Container, den du für die "akademischen Zwecke" frei> missbrauchen kannst.
Eure ganze Webseite ist viel Lesestoff, ich werd mich mal durcharbeiten
und kann mir gut vorstellen, dich nochmals direkt anzuschreiben. Vielen
Dank schonmal.
