3 mei. 2017
16 minuten
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.
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.
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. |
|
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
|
|
|
|
D1 |
C1 |
|
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)
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.
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.
Anderen lazen ook
