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?
Subcentos schrieb: > Mikrokontroller > -Wie stellt man sicher, dass er nicht "hängen bleibt"? WDT > -Kann man sowas mit eigenem Scheduler und Interrupts lösen oder lieber Dazu gabst hier mal ne längere Verbalprügelei: Beitrag "Der Watchdog – oder wie strande ich nicht im Weltall?"
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.
Möglichkeit 3: Die Rückfallebene mit diskreter Logik aufbauen. Die Plausibilitätskontrolle ebenfalls.
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.
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.