GAMP Toegepast op de DeskTopXorter Besturing DeskTopXorter

GAMP – Toegepast op de DeskTopXorter

Besturing DeskTopXorter

2

Opdrachtgever :

Ing. P. van den Berg

Opdrachtnemers :

Michel van Reenen Thijs Mommen

GAMP-methode “Besturing DeskTopXorter” Michel van Reenen en Thijs Mommen

GAMP – Toegepast op de DeskTopXorter

Besturing DeskTopXorter

2

Opdrachtgever :

Ing. P van den Berg

Opdrachtnemers:

Michel van Reenen Thijs Mommen

Michel van Reenen

Thijs Mommen

Starren B.V. Postbus 248 5460 AE VEGHEL

Dhr R. Luttmer

Dhr P van den Berg Handtekeningen voor akkoord

GAMP-methode / 2

GAMP-methode “Besturing DeskTopXorter” Michel van Reenen en Thijs Mommen 1

Versieoverzicht Datum: Versie: 04-03-‘04 1.0 11-03-‘04 1.1 16-03-‘04 1.2

Opmerking: Eerste opzet GAMP-methodiek Opmerkingen P van den Berg opgenomen Change Management opgenomen


GAMP-methode / 3

GAMP-methode “Besturing DeskTopXorter” Michel van Reenen en Thijs Mommen 2

Inhoudsopgave

1 Versieoverzicht ....................................................................................................................... 3 2 Inhoudsopgave ....................................................................................................................... 4 GAMP – DeskTopXorter................................................................................................................. 5 GAMP – DeskTopXorter................................................................................................................. 5 2.1 Wat is GAMP?..................................................................................................................5 2.2 Waarom GAMP? ..............................................................................................................5 2.3 GAMP projectfasen...........................................................................................................6 2.3.1 User Requirements Specification (URS)..............................................................................................6 2.3.2 Functional specification..............................................................................................................................7 2.3.3 Design specification.....................................................................................................................................7 2.3.4 Building System ............................................................................................................................................8 2.3.5 Installation Qualification .............................................................................................................................8 2.3.6 Operational Qualification............................................................................................................................8 2.3.7 Performance Qualification .........................................................................................................................8 2.3.8 Change Management..................................................................................................................................8 2.4 GAMP toegepast op de DeskTopXorter..............................................................................9 2.4.1 User Requirements Specification (URS)..............................................................................................9 2.4.2 Functional Specification .............................................................................................................................9 2.4.3 Design specification.....................................................................................................................................9 2.4.4 Building System ............................................................................................................................................9 2.4.5 Installation Qualification ...........................................................................................................................10 2.4.6 Operational Qualification..........................................................................................................................10 2.4.7 Performance Qualification .......................................................................................................................10 2.4.8 Change Request.........................................................................................................................................10

Figuren Figuur 3.1: GAMP V-model: Project fasering ................................................................................................................5 Figuur 3.2: Risicoanalyse.....................................................................................................................................................7


GAMP-methode / 4

GAMP-methode “Besturing DeskTopXorter” Michel van Reenen en Thijs Mommen GAMP – DeskTopXorter

2.1 Wat is GAMP? GAMP is een afkorting van Good Automated Manufacturing Practice en beschrijft een methode voor de projectdoorloop van automatiseringsprojecten, die gevalideerd moeten worden volgens richtlijnen in de farmaceutische industrie. De GAMP richtlijn is in 1994 opgesteld door het "GAMP Forum", een Europese industriegroep. In 2000 is GAMP onderdeel geworden van het internationale ISPE. Bovendien geeft de GAMP methodiek richtlijnen voor ontwerpen, testen en onderhouden van automatiseringssystemen.

2.2 Waarom GAMP? De GAMP richtlijn geeft zowel voor klanten als System Integrators zoals Starren een duidelijke omschrijving van de verschillende fasen die in een automatiseringsproject voorkomen. Tevens wordt in de GAMP richtlijn voor iedere fase aangegeven wat er vastgelegd dient te worden middels ontwerpdocumenten of testprotocollen. De klant kan met de projectverantwoordelijke duidelijke afspraken maken wie in iedere fase verantwoordelijk is voor het maken van een zulke documenten. GAMP verschaft als zodanig een handvat voor het duidelijk vastleggen van de leveringsomvang en verantwoordelijkheden in een project.

Figuur 3.1: GAMP V-model: Project fasering


GAMP-methode / 5


Hierboven is het V-model van GAMP afgebeeld. Hierin zien we dat het automatiseringsproject is opgedeeld in een aantal fasen. Omdat een automatiseringsproject een complex geheel is is het belangrijk om de verschillende fasen te volgen. Deze fasen worden in principe één voor één uitgevoerd zoals aangegeven in figuur 3.1. Het is wel mogelijk dat bepaalde fasen gelijktijdig kunnen worden uitgevoerd. Hieronder worden de verschillende fasen verder uitgewerkt.

2.3

GAMP projectfase n

2.3.1 User Requirements Specification (URS) Hierin dienen de eisen van de klant, in dit geval Starren, worden opgenomen. Een URS heeft de volgende kenmerken: • Beschrijft het systeem vanuit het oogpunt van de gebruiker • Dient als leidraad voor de hierop volgende ontwerpdocumenten • Operationele eisen (operationele modi, systeemgedrag, systeemprestaties) • Beperkingen • Ontwikkel levenscyclus Om de duidelijkheid en de overzichtelijkheid te kunnen waarborgen zijn er een aantal richtlijnen opgesteld voor het schrijven van een URS: • Elke requirement is uniek genummerd en bevat niet meer dan 250 woorden • Requirements mogen elkaar niet tegenspreken of dubbel voorkomen • Er mogen geen oplossingen in zijn opgenomen • Een requirement moet een prioriteit meekrijgen • Iedere requirement moet testbaar zijn In de Performance Qualification wordt de User Requirements Specification gebruikt als valificatie document. Onder de fase Requirements horen verder de volgende documenten: • Validatie master plan (VMP) • Validatie project plan (VPP) • Criticality analyse • Risico analyse Validatie plan Een validatie plan behoort de volgende inhoud te hebben: • Beschrijving projectteam (organisatiestructuur) en taken verantwoordelijkheden per projectlid • Systeemgrenzen en interfaces (contextdiagram) • Aanpak van de criticaly en risico analyse • Beschrijving van de validatiestrategie • Opsomming van documenten en verantwoordelijkheden • Opsomming van de van toepassing zijnde procedures • Geeft aan hoe de documenten worden gearchiveerd Criticality analyse


GAMP-methode / 6

GAMP-methode “Besturing DeskTopXorter” Michel van Reenen en Thijs Mommen In een criticality analyse wordt bepaald of een systeem (of een onderdeel daarvan) onder de GxPregulering valt. Dit is een wettelijke eis op hoog niveau en kan worden uitgevoerd door de vragenlijst uit bijlage A door te nemen. Een systeem kan als GxP kritisch beschouwd worden als er één of meerdere vragen met ‘ja’ beantwoord moeten worden.

Risico analyse Een risico analyse is nodig om zeker te zijn dat het systeem veilig functioneert. Het is de bedoeling dat voor ieder GxP risico de prioriteit wordt bepaald. Dit kan worden gedaan door onderstaande tabellen in te vullen. Waarschijnlijkheid L Impact

M

H

1 2 3

Als eerste dient de risico-klasse bepaald te worden. Kies voor het risico de waarschijnlijkheid van optreden. Vervolgens dient de impact gekozen te worden wanneer het risico optreedt. Aan de hand van de gemaakte keuzes wordt er een klasse verkregen.

Klasse 1 Klasse 2 Klasse 3 Detectie kans L Klasse

M

H

1 2 3 Prioriteit HIGH

Nu kan de prioriteit worden bepaald door te beoordelen of de kans van het risico gedetecteerd wordt. Maatregelen nemen: Prioriteit high: verplicht maatregelen nemen Prioriteit medium en low: optioneel maatregelen nemen

Prioriteit MEDIUM Prioriteit LOW Figuur 3.2: Risicoanalyse

2.3.2 Functional specification Hierin dienen de specificaties van het systeem te worden beschreven, dit is in feite de vertaling van eisen uit de User Requirements Specification naar: • Functionaliteit • Systeembeschrijving • Beschrijving van systeem interfaces Het functioneel ontwerp geeft dus detaillistische informatie over hoe het systeem werkt, welke onderdelen zijn opgenomen en hoe de interface verloopt tussen de verschillende onderdelen.


GAMP-methode / 7


In de Operational Qualification wordt het Functioneel ontwerp gebruikt als verificatie document.

2.3.3 Design specification Hierin wordt de Hardware Design Specification en de Software Design Specification onderscheiden. De Design Specification is te beschouwen als een visualisatie van het functioneel ontwerp, en is een belangrijk onderdeel om in relatief korte tijd de opbouw van de hardware en de software te begrijpen. In de Hardware Design Specification dienen tekeningen te worden ontworpen welke het gehele hardware gedeelte van het systeem weergeven. Documentatie in de vorm van een beschreven systeem configuratie behoort tevens tot de Hardware Design Specification. In de Software Design Specification dienen tekeningen te worden ontworpen welke het gehele software gedeelte van het systeem weergeven. Hiervoor zijn technieken ontwikkeld, zoals SD (State Diagram) en SFC (Sequential Function Chart). Vervolgens dienen de software modules tot in detail beschreven te worden.

2.3.4 Building System Hier wordt het systeem gerealiseerd. De hardware wordt geassembleerd en de software wordt ontwikkeld. Het systeem dient gerealiseerd te worden volgens de eerder doorlopen fasen. Na de realisatie van het systeem hoort ook het testen bij Building System. Een eis hierbij is dat de constructeur zijn eigen werk niet mag testen. Het systeem moet voldoen aan alle van tevoren beschreven eisen.

2.3.5 Installation Qualification Het doel van de Installation Qualification is het aantonen dat het systeem gebouwd is zoals gespecificeerd in de Design Specification. Het resultaat is een IQ testplan en een IQ testrapport. Hierin wordt o.a. geverifieerd dat: • Alle software correct geïnstalleerd is • Gespecificeerde hardware geassembleerd en correct geïnstalleerd • Alle data- en veldverbindingen juist zijn aangesloten • Instrumentatie geïnstalleerd en gekalibreerd is

2.3.6 Operational Qualification Het doel van de Operational Qualification is het aantonen dat het systeem gebouwd is zoals gespecificeerd in de functional Specification. Het resultaat is een OQ testplan en een OQ testrapport. Hierin wordt geverifieerd of alle hard- en software componenten zodanig functioneren dat het systeem correct functioneert.

2.3.7 Performance Qualification Het doel van de Performance Qualification is het aantonen dat het systeem functioneert zoals gespecificeerd in de User Requirements Specification. Het resultaat is een PQ testplan en een PQ testrapport. Hierin wordt geverifieerd dat de werking van het systeem in zijn definitieve omgeving is getest. Een testplan beschrijft wat en op welke manier er getest gaat worden. Een testplan is geldig wanneer deze is ondertekend door de tester. Het detailniveau dient zodanig te zijn, dat testen op een later tijdstip kan worden herhaald.

2.3.8 Change Management Wanneer er tussentijds een wijziging optreedt in de hard- of software van het systeem dient dit op een gestructureerde wijze te gebeuren. Tevens dient iedere wijziging gevalideerd en gedocumenteerd te


GAMP-methode / 8

GAMP-methode “Besturing DeskTopXorter” Michel van Reenen en Thijs Mommen worden met behulp van een Change Request. Voordat een wijziging kan worden doorgevoerd moet het plan worden geaccepteerd door minimaal twee personen. Wanneer een plan om te wijzigen is geaccepteerd dient het Change Request (bijlage B) volledig worden ingevuld. Tevens dient ieder plan uniek genummerd te worden.

2.4 GAMP toegepast op de DeskTopXorter Omdat het project gestructureerd dient te verlopen en er dat er goede documentatie wordt opgeleverd zullen we het project doorlopen volgens de GAMP-methode. 2.4.1 User Requirements Specification (URS) Het is belangrijk om de eisen van de klant (Starren) vast te leggen. Op deze manier kan achteraf worden bekeken of het systeem voldoet aan de eisen die de klant gesteld heeft. We zullen User Requirements Specification opstellen. Dit document is vergelijkbaar met het Pakket van Eisen en hierin staat beschreven dat we een werkende DeskTopXorter zullen afleveren. Er wordt dieper ingegaan op welke softwarepakketten gebruikt worden en de documentatie dat het project op zal leveren. De overige documenten die volgens de GAMP specificatie horen bij de fase Requirements zullen we niet behandelen. 2.4.2 Functional Specification De Functional Specification is de uitwerking van de User Requirements Specification, oftewel de eisen van de klant omgezet in een methode om deze eisen te realiseren. We zullen de functionele specificaties opstellen welke voldoen aan de eisen van de Functional Specification van GAMP. Hierin is een systeembeschrijving verwerkt, welke uitgewerkt is volgens de S88 methodiek. Ook wordt beschreven hoe het SCADA-scherm opgebouwd gaat worden. 2.4.3 Design specification De Design Specification is de uitwerking van de Functional Specification, oftewel het ontwerp van de hard- en software. We gebruiken zoveel mogelijk afbeeldingen omdat met behulp van tekeningen en schema’s gemakkelijker inzicht te krijgen is in het systeem. Voor de hardware van het model zelf maken we geen schema, omdat de DeskTopXorter compleet geassembleerd wordt aangeleverd. We hoeven dus geen ontwerp te maken voor de opbouw van het systeem. De verschillende hardware onderdelen waar het model uit bestaat worden wel uitvoerig beschreven in de functionele specificaties. Ook dient er een tekeningenpakket te komen waarin duidelijk wordt gemaakt hoe de interface verloopt tussen de PLC en de DeskTopXorter. Er zal namelijk een besturingskast worden gemaakt voor de I/O modules. Hiervoor dient er een tekeningenpakket te komen, opgesteld volgens de normen van Starren. De schema’s van de software worden gemaakt volgens de S88-methodiek. Ook maken we een SFC (Sequential Function Chart). Dit is een techniek om overzichtelijk een PLC-programma weer te geven. Ook zal er een standaard SCADA-scherm worden ontworpen welke toepasbaar is op een willekeurig SCADA-pakket. Dit is te realiseren door een scherm op te slaan in een formaat welke door een willekeurig SCADA-pakket kan worden geopend. Het voordeel hiervan is dat de SCADA -applicatie op


GAMP-methode / 9

GAMP-methode “Besturing DeskTopXorter” Michel van Reenen en Thijs Mommen ieder SCADA -pakket hetzelfde er uit ziet, en dat er niet iedere keer een SCADA -scherm hoeft te worden ontworpen. 2.4.4 Building System Hieronder wordt de realisatie van het systeem verstaan. Het resultaat is een goed werkende DeskTopXorter, die klaar is om te worden getest. De besturing bestaat uit het PLC-programma en de SCADA-applicatie. Omdat de DeskTopXorter pas halverwege het afstuderen in bezit is van Starren, kunnen we het PLCgrogramma niet testen op het model. Daarom gebruiken we een simulatie-PLC (Winmod) en een software simulatie pakket (PLC-Sim) om het programma tussentijds te testen. Op deze manier kunnen we voor een belangrijk gedeelte bepalen of het programma functioneert, voordat de DeskTopXorter beschikbaar is. De hardware hoeft niet geassembleerd te worden omdat de DeskTopXorter een model is van een sorteerinstallatie die volledig geassembleerd wordt geleverd. De besturingskast dient wel te worden geassembleerd, Starren heeft hiervoor een eigen paneelbouw afdeling beschikbaar.

2.4.5 Installation Qualification Er dient een testplan te komen waarin wordt geverifieerd dat het ontworpen PLC programma en SCADA-applicatie gerealiseerd is zoals het ontwerp uit de Design Specification. Ook zal er een I/O test in worden opgenomen, zodat er een verificatie is dat de communicatie goed werkt. Het testplan is de basis voor het testrapport. In het testrapport wordt bevestigd dat aan de eisen van de Design Specification is voldaan. Het testrapport dient te worden ondertekend door degene die getest heeft.

2.4.6 Operational Qualification Er dient een testplan te komen waarin wordt geverifieerd dat het systeem gebouwd is zoals gespecificeerd in de functionele specificaties. In ons geval zal dat vooral gericht zijn op de functionele beschrijving. Hierin staat namelijk beschreven hoe de DeskTopXorter zal moeten gaan werken, dus hoe de ingevoerde producten worden gesorteerd. De DeskTopXorter wordt volledig functionerend geleverd. We zullen de hardware controleren op functionaliteit door alle aansluitingen te testen (lucht en electriciteit), en de sensoren en actuatoren. Het testrapport is het ingevulde testplan, en dient tevens te worden ondertekend door de tester.

2.4.7 Performance Qualification In het testplan van de Performance Qualification wordt getest of het systeem functioneert zoals beschreven staat in het pakket van eisen. Als dit is goedgekeurd (ondertekende testrapport) voldoet het systeem aan de eisen van de klant en kan het systeem worden opgeleverd.

2.4.8 Change Request Wanneer we tijdens dit project een wijziging moeten aanbrengen aan het systeem (hardware of software) zullen we een Change Request invullen zoals afgebeeld in bijlage A.

Wanneer alle stappen zijn doorlopen voldoet het systeem aan de GAMP eisen en is de klant en de opdrachtnemer verzekerd van een juist werkend systeem, inclusief de daarbij horende documentatie.


GAMP-methode / 10

GAMP Toegepast op de DeskTopXorter Besturing DeskTopXorter

Recommend Documents