Forum: Mikrocontroller und Digitale Elektronik X-CUBE-STL Erfahrungen?


von Bert S. (kautschuck)


Lesenswert?

Hi,

Ich möchte gerne für ein Projekt die X-CUBE-STL 
(https://www.st.com/en/embedded-software/x-cube-stl.html) verwenden um 
die ganze Safety Geschichte zu vereinfachen.

In UM1840 
(https://www.st.com/resource/en/user_manual/um1840-stm32f4-series-safety-manual-stmicroelectronics.pdf) 
(Beispiel für F4) steht auf Seite 78 folgendes:

Implementation of non-safety-related functions is in principle forbidden 
by the assumed safety requirement
ASR6 (see Section 3.3.1 Safety requirement assumptions), hence under End 
user's entire responsibility. As
any other derogation from safety requirements included in this manual, 
it is End user's responsibility to provide
consistent rationales and evidences that the function does not bring 
additional risks, by following the procedure
described in this section. Therefore, it is strongly recommended to 
reserve such derogation to very simple
functions (as the one provided in the example).

Mir ist noch nicht ganz klar, wo da die Grenze ist. Der Safety 
Controller soll soweit einmal 2 Taster einlesen und wenn einer auf LOW 
geht einen STO triggern mit PLd, soweit sollte das kein Problem sein, da 
der Motor Controller einen PLd STO Eingang hat.

Nun soll die ganze Kommunikation aber über CAN laufen, heisst der 
Applikationsprozessor gibt Referenzwerte vor und der Motorcontroller 
führt diese aus. Der Safety Controller kann direkt den STO triggern wenn 
einer der Taster auf LOW geht, unabhängig von der CAN Kommunikation. Ich 
möchte aber z.B noch eine SafeLimitedSpeed hinzufügen (PLc) und da fängt 
es jetzt erst richtig an. Das System hat 2 Encoder, die ich einlesen 
könnte auf dem Safety Controller und so die Geschwindigkeit ermitteln 
(z.B #ticks zwischen 2 Interrupts). Ist das nun so noch IEC 61508 
konform oder geht das schon zu weit? Ich könnte aber z.B auch über CAN 
die PDOs auslesen und so die Geschwindigkeit ermitteln und bei 
Übergeschwindigkeit oder keine Keep Alives mehr einen STO auslösen. Ich 
denke aber, da CAN nicht Safety zertifiziert ist, kann man das so nicht 
machen, oder liege ich da falsch?

: Bearbeitet durch User
von Andras H. (kyrk)


Lesenswert?

Bei CAN wird ja E2E verwendete. Da CAN prinzipiell QM ist und durch E2E 
abgesichert wird.

So richtig verstanden habe ich nicht was du machen möchtest. Versuche 
mal dein Problem besser darzustellen. Oder halt auf kleinere Stücke 
aufzuspalten.

Sonst braucht man noch auch weitere Dokus bezüglich dein Safetykonzept 
und eigentlich Schaltplan, Systembeschreibung, Requirements. Aber ich 
bezweifele dass jemand solche Dokus auf öffentliche Forums hochladen 
würde.

von Bert S. (kautschuck)


Lesenswert?

Andras H. schrieb:
> So richtig verstanden habe ich nicht was du machen möchtest. Versuche
> mal dein Problem besser darzustellen. Oder halt auf kleinere Stücke
> aufzuspalten.

Im Prinzip wird ein Motor aktiviert (Referenzwert aus 
Trajektoriengenerator des Application Controllers) welcher seine Rampe 
abfährt. Dazu muss ein Benutzer 2-Taster (mit je einer Hand) bedienen, 
ein Loslassen eines Tasters führt einen STO aus.

Nun möchte ich aber auch noch SLS (Safe Limited Speed) PLc hinzufügen 
und hier kann man nicht mehr einfach logische Signale durchschleifen 
(mit GPIOs), sondern man muss einen Encoder einlesen, auswerten und dann 
entscheiden, ob man einen STO triggert oder nicht. Der Motorcontroller 
gibt aber auch über CAN als PDO (CANOpen) die Geschwindigkeit in Hz 
direkt aus. Ich könnte also entweder direkt den Encoder im Safety 
Controller einlesen (das scheint die sicherere Variante zu sein und 
wahrscheinlich auch einfacher zum zertifizieren) oder aber die PDOs des 
CAN nehmen und dann bei Übergeschwindigkeit einen STO auslösen.

: Bearbeitet durch User
Bitte 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
Noch kein Account? Hier anmelden.