Electronic Concepts for safety -relevant Systems

1. Electronic Conceptsforsafety-relevant Systems Pitfallsof Electronics

2. Preface • Electronic controltechnology in connectionwithsystemsbecomesmoreandmoreimportantforworkmachinesandisthedrivingforceformanyinnovations. • More andmoresubsystemshavetobenetworked. • Forthisreason also theworkmachinesthemselvesbecomemorecomplex. • “Time tomarket“ isgettingshorter. • Neverthelesshighestsafetystandardsarerequired. • The society‘sdemands on safetyrisesimultaneouslytothetechnicalprogress. • The costpressurerises.

3. Measures – Controllabilityofcomplexity • Wiki: Complexsystemsaresystems, thatrefusesimplificationandstaycomplex. • Functionalsafetyrequires: The systemarchtitecturehastopreventcomplexity. • This is not only due forthesystemstructure but also fortherespectivedevelopmentprocesses. • A deterministicsystemis an indispensibleprecondition. • This leadstotheconclusion: Nosystemswith adaptive orartificialintelligencecanbebuiltintosafetyfunctions. E. Goldratt: The more complex a problem, the more simple the solution has to be.

4. Examples – Controllabilityofcomplexity • OSI – Reference modelforcommunication • AUTOSAR • Upgrade from C to C++ • The programminglanguageofthecontroltechnologyCodesys ISO 62262

5. ImprovingSafetywithElectronics – Moose Test On 21 October, 1997 the moose testbecamewidelyknown. ESP (Electronic StabilityProgram) hasbeenfittedasstandard. Originally, ESP hadbeenintendedforthepreventionofskiddingby well-directedbrakingintervention. Referringelectronicstherearesimilarexamplesforworkingplatforms: basketweighing (MRW), electronic slopemonitoringofbasketanduppercarriage.

6. The Standards • Since 29-12-2009 themachinedirective must beapplied. The machinedirectiveis a lawthathastobefulfilledwithharmonizedstandards. • The IEC 61508 “FunctionalSafetyof electronic Systems” is an international standardforthedevelopmentof electronic systems. • Fromthe EN 954 thestandard EN ISO 13849 derived. • The EN ISO13849 ismainlybased on theknown hardware-orientedstructuresofthe EN 954. • However, the EN ISO13849 includestheprobabilityoffailureandcanbeappliedforelectric/electronic systems. • Further relatedstandards: ISO 26262 (vehicles), IEC 62061 (morecomplexsystems), ISO 25119 (agricultural machines)

7. Definitionen und Begriffe

8. Risikograph nach EN954

9. Risk graph according EN 13849 • Classification: • Injuring • Exposition • Prevention Parameters: MTTF, DC, CCF

10. ComparisonPL and SIL

11. Security level, MTTF und architecture Security level PL MTTFd: • low • middle • high

12. ArchitectureCategory B,1 L O I im im imconnection line I Input /Sensor L Logic O Output unit (power switch, contactor) • The structuralcharacteristics: • Useofestablishedsafetyprinciples • One-channelsetting • Nomonitoringofthesensor • Nomonitoringoftheoutputunit In category 1 establishedcomponentshavetobeused.

13. Architecture Category 2 L I O im im m im TE OTE imconnection line m Monitoring I Input /Sensor L Logic O Output unit (power switch, contactor) TE Test equipment OTE Output of test equipment • The structuralcharcateristics: • Requirementsofcategory B • One-channelstructure • Nodirectmonitoringofthesensor • Monitoring ofthereleasecircuit • Possible redundant structureattheactuatorside In category 2 an errorbetweenthetestscanleadtothelossofthesafetyfunctions.

14. Architecture Category 3 L I O im im m c L I O im im m imconneciton line c Cross monitoring m Monitoring I Input /Sensor L Logic O Output unit (power unit, contactor) • The structuralcharacteristics: • Requirementsofcategory B • Redundant structure • Monitoring thesensor • Monitoring thereleasecircuit • Possible redundant structureattheactuatorside In category3 in caseof an errorthesafetyfunctionisalwayscarried out. Severalerrorsareidentified, but not all.

15. Architecture Category 4 L I O im im m Comparison 3 and 4: DC is higher MTTF only “high” c L I O im im m imconnection line c Cross monitoring m Monitoring I Input /Sensor L Logic O Output unit (power switch, contactor) • The structuralcharacteristics: • Requirementofthecategory B • Redundant structure • Monitoring ofthesensor (Discrepancymonitoring) • Monitoring ofthereleasecircuit • Possible redundant structureattheactuatorside In category 4 in caseof an errorthesafetyfunctionisalwayscarriedout. The individual errorhastobeidentifiedimmediatelywhenswitching on thesystemoratthe end of a machinecycle.

16. Summary: Stepwise to the Performance Level • Identify safety functions • Risk evaluation corresponding with ISO 14121 • Definerequired Performance Levels PL • Choosesystemstructure • ChoosereliablecomponentswithMTTF • Evaluatethemonitoringofthecomponents (DC) • Evaluatethecontrol‘srobustness (CCF) • Verifyandvalidate PL

17. CANopen Safety CIA Draft Standard 304 CANopen – Protocols for safety-relevant products Non-safety-relevant products can be included Safety functions are processed via special communication objects SRDO (safety-relevant data objects)

18. SRDO Structure • A SRDO consistsof 2 CAN telegrams. Both CAN telegrams‘ datais redundant. However, thesecond CAN telegram‘sdataisinvertedbitwise. • The SRDO‘stwo CAN telegramshavetofollow a certainorder. First the real data, thentheinverteddataistransmitted. • The receiver (receiving terminal) checkstheSRDO‘svalidity. The temporal andlogicalsequenceof a SRDO‘s CAN telegramsiscomparedto an expectancyvalue. Afterwardstheuserdataisverified. In caseerrorsareidentifiedthesystemchangestothesafestateoftheallocatedactuators. In dependencyoftheapplicationthesafestatehastobedefinedbytheproductmanufacturerand/ortheuser.

19. CAN Identifier SRDO • A SRDO consistsoftwo CAN telegrams. The followingrulesapplyforthegenerationof a SRDO: • The CAN identifiersofthetwo CAN telegramsdiffer in at least twobitlocations. • This isachievedbyallocatingthefirstmessageto an even ID andthesecondmessageto an odd ID. Thereare 64 Safety-relateddataobjects (SRDO).

20. SCT and SRVT • A SRDO istransmittedperiodically; theintervalbetweentwo SRDOs isdeterminedbytheSCT (Safeguard Cycle Time). • The intervalbetween a SRDO‘s CAN telegrams must not exceedthe SRVT (Safety-relatedValidationTime).

21. Global FailsafeCommand - GFC Toincreasetheresponse time in safety-relatedsystemsthe “Global FailsafeCommand” (GFC) hasbeendefined. Itconsistsoftwo high-prority CAN telegrams (CAN Identifier 1 and2). Even withonlyoneofthetwo CAN telegramsreceivingtheGFC is operative. The GFC does not containanydataandthereforecanbe send byanyparticipant. The initiatingparticipant, however, laterhastodeliverthe “reason“ forinitiating via SRDO.

22. Example: CANopen with CANopen Safety

23. Summary CANopenSafety: • Always 2 messagesaresent. • The 2. messageincludestheinverteddataofthe 1. one. • Themessagesaresentcyclically. • Thereis a time SCT, takingcareforthepackageconsistingofmessage 1 and 2 toarrive in time. • The time SRVT controlsthe time delaybetweenmessage 1 and 2.

24. Process controller concept Single channel Two channels Prozessrechner 2 Prozessrechner 1 Funktions-controller 2 Funktions-controller 1 CAN Über-wachung 2 Über-wachung 1

25. System overview

26. Security control • Alle sicherheitsrelevanten Sensoren sind redundant. • Es gibt Neigungssensoren für den Korb und die Plattform. • Hydrauliksensor zur Lastbegrenzung (Überlastung). • Schalter für Sicherheitsabschaltung

27. Emergency concept Zwangsgeführte Kontakte Lastmindernd Lasterhöhend

28. FUNCTION_BLOCK MOSAFE_MobaSafety Zentrale Funktion die alles überwacht. VAR_INPUT I_DigitalOutputMain : ARRAY [1..14] OF DIGOUT_SAFETY; (* Array of Values forthe digital Outputs *) I_DigitalOutputSub : ARRAY [1..14] OF DIGOUT_SAFETY; (* Array of Values forthe digital Outputs *) I_PWMOutputMain : ARRAY [1..20] OF PWMOUT_SAFETY; I_PWMOutputSub : ARRAY [1..20] OF PWMOUT_SAFETY; I_CurrentControlMain : BOOL; (* TRUE: CurrentControl on / FALSE: CurrentControl off *) I_CurrentControlSub : BOOL; (* TRUE: CurrentControl on / FALSE: CurrentControl off *) I_udiTurnSensor : UDINT; (* Value ofthe Turn-Sensor *) I_xEmergencyStopCAN_HMI_Cage: BOOL; (* Emergency Button ofthe Cage Module *) I_xEmergencyStopCAN_HMI_Platform: BOOL; (* Emergency Button ofthePlatform Module *) I_byPlatformMode : BYTE; (* Platformmode (Bitcodiert) - 1: Standardbetrieb ; 2: Versetzfahrt ; 4: Tunnelfahrt ; 8: Rüstbetrieb ; 16: Notbetrieb *) I_xResetOperationTime: BOOL; (* ResettheinternalOperationtimecounter *) I_xSetTaraCageLoad: BOOL; (* Set Tara ofthecageload *) I_xResetErrorCode: BOOL; (* ResettheactualErrorCode *) I_xDeactivateSecureFunc: BOOL; END_VAR Der Funktionsblock MOSAFE_MobaSafety muss alle 100msec aufgerufen werden. Passiert dies nicht geht das System in den Sicherheitszustand.

29. FUNCTION_BLOCK MSC_Safety Main controller application I/O module CAN1 CAN2

30. Interne Funktionen I Teleskoparm eingefahren Induktiver Näherungsschalter

31. Interne Funktionen II Control Safety Support Abstützeinheit belastbar? TRUE or FALSE

32. Software developmentaccording EN ISO 13849 Validierte Software Spezifikation der Sicherheits-funktionen Sicherheits-bezogene Software-spezifikation Validierung validieren Integrations- tests System-entwurf Überprüfende Aktivitäten Konstruktive Aktivitäten Modul-entwurf Modul-test Ergebnis Codierung Verifikation

33. Change management

34. End of presentation