Liebe Hardware Entwickler, in letzten Meeting zwischen unserer HW- und SW-Abteilung wurden einige Aussagen getätigt, die für mich als SW-Entwickler schwer nachzuvollziehen sind. Ich würde mich freuen, wenn mir jemand vielleicht helfen könnte diese Nachzuvollziehen oder seine Sichtweise auf die Dinge erläutern könnte. Hier eine Kurzfassung. Im Projekte geht es um eine Entwicklung eines Schaltpaneels (ca. 10 Schalter, ca. 15 LEDs) und die Verbindung zum uC. Also eigentlich ein Standard Projekt. Folgende Aussagen wurden im Meeting getätigt: 1. Die 15 Schalter sollen direkte auf zu dem uC (GPIOs) geführt werden, ohne irgendwelche Zusatzbauteile. Ein vorgeschlagener IO-Expander auf der Schalter Baugruppe/PCB ist unsicherer (wobei Sicherheit nicht näher spezifiziert ist). Eine SPI Verbindung (20cm) würde nicht funktionieren. 2. „I2C ist eine unsichere Verbindung und wird bei uns nicht verwendet“. Hier wurde als Begründung der Tri-State der Pins genannt. Wobei Sicherheit sich hier auf funktionale Sicherheit bezieht. Der Tri-State bezieht sich auf den Transceiver und das Umschalten zwischen Empfangen und Senden. 3. Die LEDs sollen über eine Daisy Chain angeschlossen werden, dabei handelt es sich um ein China-Modul mit entsprechender eingeschränkter Dokumentation und Ansteuerung über Pulslänge im 100ns Bereich (Datenblatt habe ich leider grade nicht vorliegen). Meine Sicht wäre folgende: Zu 1) – Entfernung von SPI lässt sich einfach Googeln. – Zu einer direkten Verbindung zu den GPIOs, muss man, glaube ich auch nicht viel sagen. – Ein Wackelkontakt oder schlechte Verbindung wäre bei der Vielzahl an Kabel viel wahrscheinlicher als ein Ausfall des IO-Expanders. (Der IO-Expander sollte dabei direkt auf die PCB der Schalter). – Der Ausfall des IO-Expanders wäre einfach zu detektieren. – Verkabelungsaufwand und spätere Integration wäre deutlich geringer. – Die Schnittstelle zum uC müsste auch bei Veränderung des Paneels nicht mehr angefasst werden. – Die serielle, Daisy Chain Ansteuerung passt aus meiner Sicht nicht zu Punkt 3. Zu 2) – Demnach kann es keine ICs mit I2C und SIL3 Zertifizierung geben, gibt es aber. – CAN besitzt auch einen Transceiver, hier müsste das gleiche Problem vorliegen. (Ich bin dann sicherheitshalber mit dem Fahrrad von der Arbeit nach Hause gefahren:)) – Die funktionale Sicherheit auf serieller (Physical/Logical- Layer) zu betrachten ist nur die halbe Wahrheit. Falls es reicht einen Ausfall zu detektieren und man entsprechend reagieren kann ist aus meiner Sicht eine Übertragung über fast alle Kanäle möglich. Entsprechende Absicherung (z.b. ausreichende CRC/Sequencer, ...) vorausgesetzt – ist halt ein anderer Layer. Zu 3) – Im Vergleich zum IO-Expander ist es ein No-Name-Produkt, da stellt sich für mich die Frage über: QC, Verfügbarkeit, Shelf-Life, Regulierungen (darf es vertrieben werden), Software-Integration, ... – Wie unter 1) einmal seriell, aber die Schalter parallel von der Baugruppe/PCB. Aus meiner Sicht nicht konsistent. Ich hoffe, die Ausführung war nicht zu kurz, halbwegs verständlich und reicht für eine Einordnung. Vielen Dank für euer Hilfe. Beste Grüße M
Was für Personendarsteller haben die von Dir geschilderten Aussagen gemacht? Welche Qualifikation geben die vor zu haben?
Ich erinnere mich da an ein SIL3-PLe-Projekt, an dem ich mal die Hardware mitentwickelt habe... "Der TÜV sagt, wir dürfen keine ICs nehmen, weil die fehleranfälliger sind" vom Projektmanager - Ich frage mich bis heute, was fehleranfälliger gewesen wäre: Der Instrumentenverstärker aus 3 einzelnen Operationsverstärkern oder ein einzelner INA333. Das Digital-Poti mit I2C war spannenderweise kein Problem. Soll das Bedienpanel denn funktionale Sicherheit haben? Welches SIL? Welches Performance Level? Wenn ja, wäre es wohl das einfachste, eine entsprechende Safety-SPS von Pilz oä. zu nehmen, anstatt selber was zu entwerfen. Aber natürlich kann man auch IO-Expander und Bussysteme entsprechend sicher ausführen. Redundanz (zwei Controller machen das gleiche und müssen das gleiche Ergebnis liefern) ist die einfachste Stufe. Macht euch bewusst, welche Sicherheitsanforderungen benötigt werden und sprecht mit den entsprechenden Stellen, die die Zertifizierung vornehmen. Es gibt auch externe Unternehmen, die die Entwicklung begleiten können.
:
Bearbeitet durch User
Vielen Dank erstmal für die Antworten. Wir haben alle mehr als 10 Jahre Berufserfahrung. Im Projekt erfüllen wir die Sicherheitsanforderungen über den harten Ein/Aus-Schalter. Es geht aber einerseits um technische sinnvolle Lösung sowie ggf. spätere Erweiterungen. Zusätzliche rütteln die Aussagen an meinem Grundlegenden Verständnis und Best Practices die ich aus anderen Projekten kenne. Den einzigen Grund für den höheren Ausfall bei I2C würde ich im Bus-System sehen und zwar aufgrund der Vielzahl an Teilnehmern und dann sogar eher Aufgrund der Teilnehmer als dem Bus selbst. Im konkreten Fall handelt es sich aber um eine P2P Verbindung.
Mar schrieb: > Den einzigen Grund für den höheren Ausfall bei I2C würde ich im > Bus-System sehen und zwar aufgrund der Vielzahl an Teilnehmern und dann > sogar eher Aufgrund der Teilnehmer als dem Bus selbst. Im konkreten Fall > handelt es sich aber um eine P2P Verbindung. Um hier vielleicht noch einmal etwas zu konkretisieren, dass einzige was ich mir noch vorstellen könnte ist, dass durch die Verbindungsaufteilung auf MOSI und MISO, es für einen defekten Teilnehmer schwieriger (unwahrscheinlicher) wird, beide Richtungen gleichzeitig zu stören bzw. MOSI überhaupt zu stören. Ggf. ist auch ein CS im Teilnehmer IC einfacher und robuster zu integrieren als eine (konfigurierbare) Adresse.
Moin, Tastenmatrix 4x4 mit Pullups und WS28xx LEDs plus uC. Fertig:-) Aus schaltkontakt-technischen Gesichtspunkten empfehle ich die Pullups, um beim Betätigen der Taster ein paar mA durch die Schaltkontakte fließen zu lassen, damit die Taster langzeit-zuverläßig bleiben. Das säubert die Kontaktübergänge. Die paar uA von den uC Pullups reichen nicht aus und führen in den meisten Fällen ohne Goldkontakte zu häufigen Störungen. Weiters empfehle ich Serien Widerstände an den Eingängen, um der EMV willen. Nackte uC IO können auf extern induzierte Störfelder sehr empfindlich reagieren. Im Notfall helfen auch kleine Keramik-Cs an den Eingängen.
:
Bearbeitet durch User
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.