Correct uit is het nieuwe in (5)

In dit vijfde artikel wordt aandacht besteed aan de specificatie en de documentatie van de veiligheidsgerelateerde software van de remotelototo-unit waarbij de norm IEC/CD1 620611 wordt gevolgd. Tevens wordt in dit artikel een aanzet gegeven voor de opbouw van de oorzaak-gevolgrelaties van deze remotelototo-unit vanuit de I/O list.

In de voorgaande artikelen is het IFA-rapport2 en de relatie met de IEC 620161 vermeld. In dat rapport van de IFA is aangegeven wat er moet worden vastgelegd voor de verificatie/validatie van de veiligheidsgerelateerde software. In tabel 1 is een overzicht met toelichting gegeven van de vereiste documenten voor deze verificatie/validatie.  

Document

Toelichting

A1

Specificatie van de veiligheidsfuncties:

Een lijst met een overzicht van de veiligheidsfuncties met belangrijke eigenschappen zoals. vereiste prestatieniveau, responstijden, modes, prioriteit, etc..

A2.1

Overzichtsschets:

Globaal overzicht van het systeem en kan ook  ontwerpgegevens bevatten.

A2.2

Schakelschema:

Elektrische bedrading en schema’s in het bijzonder van de veiligheidsgerelateerde onderdelen.

A2.3

Systeem ontwerp:

Overzicht van de veiligheidscomponenten en hun verbinding (topologie netwerk).

A2.4

I/O-list:

Een lijst van alle veiligheidsgerelateerde en indien nodig andere relevante in- en uitgangen met adressen en/of namen van de variabelen. Deze lijst bevat eveneens controlepunten (C1 en D1).

A3

Overzicht van foutvermijdende maatregelen en instrumenten:

Programmeringsregels voor het vermijden van fouten.

A4

Eisen:

In EN ISO 13849-1, paragraaf 4.6.3. worden eisen gegeven ten aanzien van de scheiding tussen veiligheidsgerelateerde en niet-veiligheidsgerelateerde software en de weerslag op de betrouwbarheid van de veiligheidsfuncties.

B1

Architecture veiligheidssoftware:

Overzicht over de opbouw van de veiligheidssoftware  (de hiërarchie en wanneer de ‘bouwstenen / modules worden aangeroepen).

B2

Architecture standaardsoftware:

Overzicht over  de structuur van de standaard software (de hiërarchie en wanneer de ‘bouwstenen / modules worden aangeroepen)

B3

Module architectuur:

Overzicht van de gebruikte modules (Functie blokken) met de onderling verbonden inputs en outputs en de logische signalen van de besturingslogica.

B4

Veiligheidsgerelateerde software-eisen en validatie plan:

Specificatie van software en test plan voor de verificatie en validatie van software op basis van een matrix (cause and effect).

B5

Programma-overzicht:

Weergave van de onderdelen van het programma, bijvoorbeeld in een functieblokdiagram.

Kan worden afgeleid van het later gerealiseerde programma (bijvoorbeeld met behulp van screenshots ed.).

P1

Berekening van de veiligheidsfuncties

Berekening van de SIL PL waarden aan de hand van de opbouw van de componenten (bijvoorbeeld met Sistema).

R1

Verslag van de veiligheidsfunctie

Verslag waarin de hardware is gecontroleerd en de werking van de software is aangetoond.

V1

Verslag van de verificatie van de software:

Geen apart document of verslag, maar controle van de velden in de documenten B3 en B4, aangezien deze tegen de specificatie van de veiligheidsfuncties (A1) moeten worden gelegd.

V2

Verslag van de verificatie van de hardware:

Geen apart document of verslag, maar controle of de hardware conform de specificatie van de veiligheidsfuncties (A1) voldoet.

C1

Verslag Code Review:

De code of programma dat moet worden beoordeeld en/of worden onderzocht op fouten. In het verslag van de Code Review staan de verificatiestappen in een tabel opgesomd met daarachter de ontdekte fouten.

D1

Verslag Software Validatie:

Protocol voor de validatie van de software met de gevolgde stappen en een controle daarop.

Q1

Eindverslag

Verslag op basis van bovenvermelde documenten waarin hardware en software bij eindmontage wordt getest.

Tabel 1 : Documentatie van de software veiligheidsfunctie(s)

In dat zelfde IFA rapport is eveneens de relatie aangegeven tussen de hard- en softwareplannen3 en de vereiste documenten (afbeelding 1).  Hierbij zijn de documenten die voornamelijk hardware georiënteerd zijn rood gekleurd. De hoeveelheid aan documentatie kan bij complexe systemen – en gelet op de gegevens in tabel 1 – nogal omvangrijk worden. Echter als de veiligheidsfuncties gebaseerd zijn op bestaande componenten zoals in dit geval de PNOZmulti, is de documentatie een stuk minder omvangrijk.

 afb 1

Afbeelding 1 Tabel 4 (vertaald) uit het IFA rapport

De IEC 62061 commissie heeft deze werkwijze van dit IFA-rapport overgenomen. Bij een ontwerp van een veiligheidsfunctie met behulp van standaard hard- en software kan de verkorte versie van het zogenoemde V-model worden gevolgd (afbeelding 2). Dit V-model begint met de specificatie van veiligheidsfunctie (en de verdieping daarvan) inclusief de testspecificaties van de testen die tijdens de verificatie/validatie fase moeten worden gerealiseerd.

afb 2

Afbeelding 2 Het verkorte V-model (figuur 10 van IEC/CD1 62061)

Specificeren van de veiligheidsfunctie en testfunctie

In de praktijk blijkt dat het lastig is om de software-specificatie concreet te maken. Vaak wordt volstaan met een checklist gebaseerd op onder andere hoofdstuk 4 van de EN 62061. Nadeel van een dergelijke checklist is dat deze niet voldoende eenduidig is en vaak niet de vereiste diepgang oplevert. Met behulp van de hierna vermelde stappen kan op eenvoudige wijze een completere specificatie worden gerealiseerd.

Stap 1.  Beschrijf de functie die moet worden vervuld

Als de remote werkschakelaar (WSR) wordt uitgeschakeld moet de motorbediende vermogensautomaat (MSVA) in de basisunit worden uitgeschakeld en daarna moet na de afschakeling van MSVA de spanning via de nulspanningsdetectie (ZVD) worden gecontroleerd. Als deze spanning op de afgaande velden kleiner of gelijk is dan 10 V moet vervolgens de motorbediende vermogensautomaat (SMVS) worden ingeschakeld voor de kortsluiting en aarding. Als de SMVS is ingeschakeld moet daarna op de remote unit de groene lamp (LEDG) oplichten

Stap 2.  Maak van deze beschrijving van stap 1 een ‘namaak-programma’

Een voorbeeld van deze uitwerking is te zien in tabel 2.

 

Nummer

Actie

Opmerking

1

ALS Automatische controle bij opstart = OK DAN

Unit staat in ‘stand by’ mode.

2

ALS WSR gaat naar off toestand DAN

Interne remotelototo functie van de remote unit en de basis unit

3

ALS AMVS gaat naar off toestand DAN

Interne remotelototo functie van de basis unit

4

ALS ZVD detecteert spanning < 10 V DAN

Interne remotelototo functie van de basis unit

5

ALS SMVS gaat naar de in toestand DAN

Interne remotelototo functie van de basis unit

6

ALS SMVS is ingeschakeld DAN LEDG = Aan

Als de groene lamp continue brandt kan de vergrendeling lockout door de bediener plaatsvinden (een actie van de basis unit naar de remote unit.

Tabel 2 Een ‘namaak-programma’

Stap 3.  Ontleed de acties met de zogenoemde WAT-ALS methode

Dus wát gebeurt er áls het gegeven in het zinsdeel tussen de vetgedrukte ‘ALS-DAN’ niet correct functioneert of faalt. Houdt hierbij in gedachte dat de actie van het uitschakelen niet automatisch hoeft te resulteren in de uitgeschakelde toestand (de status).

Mogelijke fouten en/of storingen die er voor zorgen dat bijvoorbeeld de vereiste (veiligheids-) functie  – (ALS WSR gaat naar off toestand DAN) niet kan worden vervuld, zijn onder andere dat:

  • de correcte stuurspanning van de WSR (op de remote-unit) niet aanwezig is door bijvoorbeeld draadbreuk of kortsluiting in de aders van de basisunit naar de remote-unit.
  • de stuurspanningspuls die de schakelaar (AMVS) moet activeren niet aanwezig is door bijvoorbeeld een draadbreuk of kortsluiting of een defecte uitgang van de PNOZmulti.
  • uitgerekend op het moment van schakelen van de WSR de (stuur)spanning wegvalt van de WSR naar de basisunit.
  • uitgerekend op het moment van schakelen van de AMVS de (stuur)spanning wegvalt van de PNOZmulti naar de AMVS.
  • de veer van de vermogensschakelaar die voor de uitschakeling en scheiding moet zorgen, niet is gespannen of gebroken.
  •  enz.

Door deze fouten en oorzaken te ordenen (tabel 3) en te voorzien van mogelijke testen om de fout aan te tonen wordt de oorspronkelijk globale specificatie gedetailleerder en zal tevens de specificatie voor de verificatie/validatietesten ontstaan. Deze testen zijn in afbeelding 2 weergegeven met de pijl ‘TEST’.

Door dergelijke beschouwingen verder uit te werken in een overzicht, kan hieruit de complete specificatie van de veiligheidsfunctie worden afgeleid. In het IFA report wordt een matrix of tabel voorgesteld zoals tabel 4. In deze tabel 4 is te zien dat een deel van de ‘Code Review’ (C1) is opgenomen onder aan die tabel. Door nu stelselmatig de documenten en/of tabellen te voorzien van dergelijke rijen en/of kolommen wordt de verificatie en validatie overzichtelijker. In het eindverslag (document Q1) worden de onderdelen van C1 en D1 verzameld en afgetekend.

 

nummer

ALS WSR gaat naar off toestand DAN

Actie / detectie

Globale testspecificatie

2.1

Stuurspanning remote- basisunit onderbroken.

Spanning wordt gecontroleerd door voortdurende pulstrein over de aders.

Onderbreken van de multicore kabel naar de remote unit, waardoor de AMVS afvalt en de unit in storing staat (LEDG is uit).

2.2

Stuurspanning remote- basisunit kortsluiting.

Spanning wordt gecontroleerd door voortdurende pulstreinen over de meervoudig uitgevoerde aders.

Aders in  Multicore kabel (een voor een) kortsluiten met aarde.

2.3

Stuurspanning PNOZ- AMVS onderbroken.

Ruststroom principe. Indien stuurspanning zonder reden niet hoog is wordt AMVS uitgeschakeld en storing gemeld.

Ader/aders onderbreken in de diverse modes en dan moet de foutreactie leiden tot een storingsmelding en het initiëren van de SF1/SF2 functie.

2.4

Stuurspanning PNOZ- AMVS kortsluiting.

Uitgang van PNOZmulti is of hoog door kortsluiting naar de 24V of laag door een kortsluiting naar de nul/ aarde.

Simulatie van een kortsluiting naar hoog tijdens bedrijf. N.B. bij kortsluiting naar aarde of nul wordt deze  uitgeschakeld (2.3).

2.5

Stuurspanning (24 V) valt weg tijdens bediening WSR.

Ruststroom principe.

AMVS schakelt uit.

Zie 2.1 van tabel 5

2.6

Stuurspanning (24V) valt weg tijdens bediening AMVS.

Ruststroom principe.

AMVS schakelt uit.

Zie 2.3 van tabel 5

2.7

Veer niet gespannen.

AMVS kan niet uitschakelen.

Test of  de veer wordt gespannen wanneer bij de opstartcyclus de automatische controle correct wordt doorlopen.

2.8

Veer (tijdens automatische controle van remotelototo-unit ondertussen gebroken).

AMVS kan niet uitschakelen.

Na overschrijding van het tijdsverloop van het opwinden van de veer wordt SMVS ingeschakeld en storing gemeld.

Tabel 3 Uitwerking van item 2 uit tabel 2

 

SF1

Uitschakelen (AMVS) hoofdschakelaar in basis unit

1

Beschrijving

Wanneer de werkschakelaar is uitgeschakeld is het afgaande veld spanningsloos

2

Activerende gebeurtenis

Verdraaien van de remote werkschakelaar naar de Off positie

3

Veiligheidsreactie

Uitschakelen door (AMVS) van de spanning van het afgaande veld

4

Gevaarlijke delen

Spanning op afgaande veld

5

Reactie SF op storing

Uitschakelen (AMVS) en actief SF2 aansturen

6

PL /SIL

PL e / SIL 3

7

Bedrijfsmode

Alle modes

8

Parameters / Fouten

8.1 Veer opspanning brengen ca. 3 sec

8.2 Uitschakelen ca. 100 msec.

8.3 Spanning meten (PU3Z) na 0,5 sec interval

8.4 ..

9

Vertragingstijd

Tijd om test te maken via software loop ca. 170 ms

10

Gedrag SF1 bij storing

Uitschakelen van AMVS en inschakelen van de SF2.

11

Start voorwaarde

11.1 24 V d.c. functioneert

11.2 PNOZMulti is OK (interne controlelus na 15 msec)

11.3 Geen fouten / storingen opgetreden (separate controle lus PNOZ via programma)

11.4 Deur van basisunit is vergrendeld

11.5 De veer van AMVS is gespannen

11.6 ..

12

Prioriteit

Hoogste (1)

C1

Gecontroleerd (OK/NOK)

NOK (er ontbreekt nog een aantal fouten bij punt  8 en 11 (wel meegenomen in programma) De vertragingstijd (9) nameten.

Datum

27 maart 2017

Naam

P. Hoogerkamp

Tabel 4 De veiligheidsfunctie samengevat

Documentatie

Na het voorbeeld van een deel van de specificatie en de documentatie in deze en voorgaande artikelen kan een tussenbalans worden opgemaakt. Hierbij is gebruik gemaakt van tabel 1 van dit artikel. De documenten A1 t/m D1 maken deel uit van het technisch constructiedossier en zijn in een overzicht (tabel 5) samengevat. Uiteraard kunnen deze documenten in een configuratiemanagement worden opgenomen, maar wordt in deze artikelenreeks buiten beschouwing gelaten.

 

Item

Opmerkingen

A1

Bepalen van de (veiligheids)functies van de remotelototo (o.a. tabel 4, 5 en 6 van dit artikel). Dit document A1 is compleet als alle functies zijn benoemd (in dit artikel niet nader uitgewerkt, vanwege op de omvang en details).

A2.1.

Documentatie in de vorm van schema’s is meestal voorhanden (zie o.a. schema’s in derde artikel tabel 1).

A2.2

Documentatie in de vorm van het complete elektrisch schema.

A2.3

Document waarin de samenhang tussen de componenten vastgelegd, maar gelet op de complexiteit en omvang van de unit wordt worden volstaan met het overzicht uit het E-schema en de opstellingstekening of foto (zie afbeelding 1 in het derde artikel).

A2.4

Zie dit artikel onder de kop I/O list.

A3

De tabel met de foutvermijdende maatregelen (zie tabel 9 van dit artikel) is een vast gegeven dat vergelijkbaar is met de tabellen in EN-ISO 13849-2 bijlagen A t/m D.

A4

Dit document grijpt terug op de gegevens van EN-ISO 13849-1 paragraaf 4.6.3 waarin de eisen worden vastgesteld voor de veiligheidsgerelateerde en niet-veiligheidsgerelateerde toepassingsprogrammatuur. Door het toepassen van de PNOZmulti binnen zijn specificaties wordt het document A4 in feite een verwijzing naar de documentatie van de toeleverancier.
Daarnaast rekening te worden gehouden dat bij bepaalde kritische testen de uiterste waarden worden vastgelegd en geverifieerd.

B1

Niet van toepassing doordat gebruik is gemaakt van PNOZmulti, waardoor de software architectuur vastligt.

B2

Niet van toepassing doordat gebruik is gemaakt van PNOZmulti, waardoor de software architectuur vastligt.

B3

Niet van toepassing, want er is geen separate module gemaakt.

B4

De software specificatie is samen te stellen door de documentatie van A1 en de uitwerking van de I/O list te combineren.

B5

De PNOZmulti configurator (listing) toont deze schema’s in de samenhang tussen de bouwstenen.

P1

Het bepalen van de veiligheidsfunctie conform EN-ISO 12100 en het brugdocument ISO/TR 22100-2. Vastgesteld is dat deze remoteloto moet voldoen aan de hoogste eisen Ple / SIL 3 en is berekend met behulp van Sistema.

R1

Het document waarin duidelijk wordt dat de hardware is gecontroleerd en de werking van de software is aangetoond. In feite komt dit neer op het controleren van de hardware met behulp van het elektrisch schema en tevens verifiëren of het geheel functioneert conform de eisen.

V1

Deze voorbeelden worden in het nog te publiceren artikel (6) gegeven.

V2

De testen vinden plaats tijdens het controleren van het elektrisch schema en het controleren van de hardware verbindingen.

C1

Verslag van de diverse reviews van de documenten (in dit artikel aangegeven met de grijsgekleurde kolommen in de tabellen).

D1

Verslag van de diverse reviews van de documenten (in dit artikel aangegeven met de grijsgekleurde kolommen in de tabellen).

Q1

De uiteindelijke validatie vindt plaats voor de eerste ingebruikname en valt samen met D1. Dit document is in feite een verzamellijst.

  

Tabel 5 De vereiste documentatie volgens het IFA-rapport (IEC/CD1 62061)

In deze artikelenreeks is een aantal delen van de documentatie nog niet verder uitgewerkt, zoals de foutvermijdende maatregelen (A3), de I/O list (A2.4) en de uiteindelijk validatie (Q1). Hiervan zijn voor de remotelototo de I/O-lijst en de oorzaak- gevolgmatrix de belangrijkste. In de PNOZmulti zijn bijna alle foutvermijdende maatregelen door de fabrikant in deze unit ‘verwerkt’. Voor de opbouw met behulp van de ‘PNOZ’- bouwstenen is onder andere R25 in tabel 6 van belang. Hierin wordt het password- en file-beheer vastgelegd.

Foutvermijdende maatregelen

Om de programmatuur leesbaar te houden worden vaak tussen de coderegels commentaren geplaatst en betekenisvolle namen aan variabelen te geven. Zo wordt bijvoorbeeld een ingangsvariabele van een veiligheidsfunctie van het type boolean aangeduid met IS_b. Door dergelijke regels (tabel 6) consequent te hanteren tijdens het programmeren worden fouten in de software vermeden en is bovendien de lijstuitdraai (listing) van het programma makkelijker te volgen bij controle door een derde.

In tabel 6 zijn kolommen/rijen (grijs gekleurd) toegevoegd die bedoeld zijn om een verificatie en/of validatie uit te voeren. Ieder maatregel heeft een R-code met nummer die alleen wordt gebruikt als referentie bij de overige documentatie. De kolom ‘opmerkingen’ is bedoeld om eventuele afwijkingen in het onderhanden project aan te geven en tevens aan te geven of er gebruik gemaakt is van de genoemde foutvermijdende maatregel.

 

C1

A. Variables

referentie

OK/NOK

Prefixes of temporary variables: "#", boolean variables: "b".

R0

Prefixes of binary inputs:

"I_b" (non-safety-related input),

"IS_b" (safety-related input).

R1

Prefixes of binary outputs:

"Q_b" (non-safety-related output) or

"QS_b" (safety-related input).

R2

Prefixes of instances:

Timers: "T_",

Positive edge detections: "R_",

Flip-Flops: "FF_",

SF_GUARD: GUARD_<guard name>,

SF_ESTOP: ESTOP_<number>,

SF_FDBACK: CONTACTORS_<contactors>

R3

Prefixes of global variables:

"G_" (non-safety-related),

"GS_" (safety).

R4

Variable names: The variable name after the prefix should be self-explanatory, e. g. should contain the device name under consideration. For example..GD1.. for guard door 1

R5

Variable declaration: Initialize with the safest condition. Include a comment in each declaration

R6

B. Signal processing

Software architecture: Partition the software data flow in a pre-processing layer (inputs), a switch off logic (logic) and a post-processing layer (outputs).

Realize the pre-processing layer in consecutive networks. The output of each network should somehow contribute to the switch off logic. For each binary output: Realize the corresponding switch off logic and the post-processing layer in one network (if possible).

R8

Allocation: Allocate outputs and variables in only one program statement.

R9

Comments: Each network has a comment.

R7

Cyclic processing: Run each part of the safety-related software unconditionally as part of each cycle.

R10

Monitoring of two channel inputs: Monitor on two channel inputs (e. g. push buttons) by the input cards with a discrepancy time of 100 ms.

R11

Monitoring of contactors: Monitor of the mirror contacts of contactors with a feedback time of 1 s.

R12

Monitoring of guard door: Monitor of the interlocking devices with a discrepancy time of 100-500 ms.

R13

Automatic restart: Is only allowed for guard doors where the operator can stay in the hazard zone.

R14

Errors in peripheral devices: Manual reset is necessary.

R15

Triggering of safety functions: Trigger by FALSE.

R15

Concept of acknowledge of detected failures: Selectivity of "reset/acknowledge" depending on the availability concept; human actions requirements

R16

Reaction time (typical): Calculate or test and document the reaction time of the safety-related program.

R17

C. Library function blocks / functions (FBs/FCs)

Usage: Wherever applicable use pre-assessed library FBs/FCs.

R18

Guard door: SF_GUARD.

R19

Emergency stop device: SF_ESTOP.

R20

Contactor: SF_FDBACK.

R21

Enabling device: SF_EV2DI

R22

Automatic Reset: Depending on the library functions (to be cited here)

R23

Activation: Depending on the library functions (to be cited here)

R24

Self-developed FBs/FCs: If applicable capsule logical signal combinations which have multiple assignments within the project in a FB/FC . The life cycle complies with the V-model. These FBs/FCs shall be password protected. A library management is necessary.

R25

Datum:

Naam:

       

Tabel 6 Overzicht van de foutvermijdende maatregelen

 


Beschrijving (functie, signaal)


Variabele


Adres

D1
HW bedrading correct (OK/NOK)

C1
SW verbinding correct (OK/NOK)

Ingangen

PU3Z Y44

(25A3 L1-N) a1.IM0

Sheet 2

PU3Z Y45

(25A3 L2-N) a1.IM1

PU3Z Y46

(25A3 L3-N) a1.IM2

PU3Z Fault

(25A3 FAULT) a1.IM3

..

Uitgangen

Spanningsbewaking NOK

IM19

Spanningsbewaking OK

..

..

Datum:

Naam (hardware check):

Naam (software check):

Tabel 7 I/O lijst (niet compleet)

afb 3

  

Afbeelding 3 Deel uit het elektrisch schema

   

I/O-lijst

Het opstellen van de I/O-lijst (benodigd voor het document A2.4) kan worden gerealiseerd met behulp van het elektrisch schema waarin de verbindingen en nummeringen worden vermeld (tabel 7). D e variabele (25A3 L1-N) a1.IM0 is voor de remotelototo opgebouwd uit een deel gerelateerd aan de bladzijde van het E-plan en de locatie (25A3 L1-N) vervolgens de ingang van de PNOZmulti (a1 met het klemnummer uit het E-schema van de PNOZmulti (IM0) (zie afbeelding 3 de rode rechthoeken).

Paul Hoogerkamp, Pouw Jongbloed en Aart van Ginkel

NB: Op het Safety Event – 9 mei in Eindhoven (Evoluon) – worden diverse alternatieven voor de remotelototo getoond. Eind mei zal ook het zesde en laatste artikel verschijnen.

http://www.remotelototo.nl/   

www.engineersonline.nl/safetyevent

Voetenoten

1Door de samenwerking tussen de werkgroepen van ISO en IEC ten aanzien van de veiligheidsgerelateerde besturing zal onder andere het validatiegedeelte gemeenschappelijk worden opgesteld.

2IFA report 2/2016 ‘Sicherheitsbezogene Anwendungssoftware von Maschinen – Die matrixmethode des IFA’.

3NB: Plan (Engels) wordt vaak vertaald met planning en niet met ‘het plan’. Met het plan wordt bedoeld een aantal activiteiten (of achterliggende gedachten) om een bepaald resultaat te behalen. Dit is wat anders dan de tijdsplanning.