GAMP 4 Guide Quick Reference

Transcript

1 GAMP 4 Guide Quick Reference Good Automated Manufacturing Practice (GAMP) è una normativa di validazione messa a punto dal GAMP Forum, un sottocomitato tecnico di ISPE (International Society of Pharmaceutical Engineering). E' 4 perché è la quarta versione (emessa nel 2001) di un documento il cui primo draft fu emesso nel 1994 per la industria UK. Tiene conto di raccomandazioni europee e nord-americane. E' conforme a GxP: GMP (Good Manufacturing Practice), GCP (Good Clinical Practice), GLP (Good Laboratory Practice), GDP (Good Distribution Practice). Non è una normativa adatta per la validazione retrospettiva di sistemi esistenti. E' applicabile ad un ampio spettro di sistemi (PCS (Process Control Systems) e IT Systems). E' parte della GAMP Guidance, che include la GAMP Guide, Good Practice Guides (da emettere) e Training Materials (materiale formativo della ISPE). Si compone di un corpo centrale (concettuale) e di Appendici su temi specifici: Gestionali Di sviluppo Operative. Nel 2000 è stato costituito un GAMP America, che compendia il Forum europeo. La validazione di una nuova struttura deve seguire una struttura sequenziale: 1. Edifici e servizi principali 2. Apparati e sistemi automatizzati 3. Processi e normative igeniche. La validazione può essere vista come ripartita in 3 aree fondamentali: IQ installation qualification: corretta installazione dei sistemi, OQ operational qualification: corretta (vs. specifiche) funzionalità, PQ performance qualification: corrette (vs. specifiche) prestazioni, DQ design qualification: rispondenza del progetto (documentazione) agli obiettivi. Schema delle attività di validazione: Attività di validazione Planning Specification Test planning (IQ,OQ,PQ) Testing (IQ,OQ,PQ) Review e Report Prepara un piano di validazione scritto Specifica i design review di progetto e di realizzazione del sistema Preparazione della documentazione che descrive i test Esegue i test e raccoglie i risultati Revisione della documentazione per mostrare che il sistema è conforme alle specifiche E' essenziale per implementare le attività di validazione mantenere documenti di Specifica ben aggiornati (questo è un requisito GxP). Lo schema di corrispondenza fra specificazione e qualificazione è quello classico a V:

2 Specifica Realizzazione Validazione URS User Requirements Spec. PQ verifica URS FS Functional Spec. OQ verifica FS e DS DS Design Spec: IQ verifica DS Sviluppo del sistema Più specificamente si ha la seguente corrispondenza: Attività di sviluppo Fase Attività di validazione URS FS (incluse le specifiche meccaniche ed elettriche per i sistemi embedded) Planning & Specification Validation Plan, Supplier Assesments, Design Reviews Hw DS, Sw DS, Sw module DS, Mechanical and electrical Specs, Network DS, Package Design Design Reviews Configuration Specs Realizzazione e assemblaggio Hw, Codifica Sw, Realizzazione e assemblaggio apparati (sistemi embedded), Realizzazione e assemblaggio della rete Hw test, Sw module test, Sw integration test, Equipment tes (sistemi embedded), Package configuration test Hw inst., Sw inst., inst. apparati (sistemi embedded), inst. rete Hw acceptance testing Network acceptance testing Construction Testing Installation Construction Reviews//Code Reviews Monitor supplier (NB) Installation qualification System Acceptance testing Acceptance testing Operational Qual., Performance Qual., Validation Report Maintenance Change Control Operation Validation Report, Manutenzione dello stato di validazione NB: test eseguiti presso il fornitore, se adeguatamente controllati e documentati, possono essere parte integrante di OQ e PQ, allo scopo di semplificarne la complessità. Vanno considerate le cose seguenti: IT Systems Il PQ va eseguito con dati realistici (rispondenti all'uso quotidiano). Dovrà esistere un piano di qualità per qualificare la infrastruttura informatica che ospita l'applicazione validata. Process Control Systems E' importante che aspetti meccanici, elettrici e sw vengano qualificati insieme (in assetto integrato) durante la OQ. Per mantenere lo stato di validazione del sistema sono essenziali: Piani operativi e procedure Addestramento Gestione e risoluzione problemi

3 Contratti di manutenzione e servizio System Management Back-up e Recovery Configuration Management Controllo dei cambiamenti operativi Gestione sicurezza Monitoring delle prestazioni Mantenimento, archiviazione e recupero delle registrazioni rilevanti per la qualità Piano di Business Continuity Review periodiche e valutazioni Sostituzione sistemi 1 Ciclo di vita della validazione E' essenziale la cooperazione utente-fornitore. E' essenziale che il fornitore usi un sistema di gestione formale per controllare e documentare il processo di sviluppo. La responsabilità della validazione è dell'utente, sebbene il fornitore sia ampiamente coinvolto nel processo. L'utente deve avere quindi una policy per coprire le seguenti problematiche che sono a suo carico: 1. Identificazione dei sistemi 2. Produzione del USR 3. Definizione della strategia di validazione con: Assessment dei rischi Assessment dei componenti del sistema (con loro categorizzazione) Assessment del fornitore (può portare all'audit del fornitore) 4. Produrre un Validation Plan 5. Revisionare e approvare le Specifiche, inclusa la System description 6. Fare il monitoring dello sviluppo del sistema 7. Review del codice sorgente (deve garantire che questa attività sia svolta) 8. Review e approvazione delle Test Specs 9. Eseguire il test (il coinvolgimento può essere come testimone del test o come auditor dei risultati) 10. Review ed approvazione dei risultati dei test 11. Produzione del Validation Report 12. Mantenimento del sistema con appropriate procedure operative e di gestione 13. Ritiro del sistema Per la identificazione dei sistemi dovrà come minimo essere gestita una lista di quelli rilevanti ai fini GxP. Gli URS debbono essere scritti dall'utente, che può delegare, ma deve mantenere almeno il reviewing e la approvazione (vedi Appendice D1). Per la determinazione della strategia di validazione, sono essenziali i seguenti passi: Risk Assessment: identificazione dei sistemi e dei processi critici per il prodotto e/o il paziente e/o il business; la validazione va indirizzata verso le aree critiche (vedi Appendice M3). Assessment of System Components: categorizzazione dei componenti per determinare il livello di validazione richiesto (vedi Appendice M4). Supplier Assessment: (vedi Appendice M2).

4 Devono esistere un Validation Plan, redatto dall'utente, e un Quality & Project Plan, concordato fra utente e fornitore, basato sul precedente. Il Validation Plan deve essere prodotto per tutti i sistemi regolati da GxP. Esso definisce: Ruoli e responsabilità Struttura organizzativa Assessment delle criticità GxP Strategia di validazione (tenendo conto del risk assessment) Deliverables della validazione Criteri di accettazione Controllo delle modifiche Procedure Operative Standard Gestione della documentazione Mantenimento dello stato di validazione (vedi Appendice M1). Alla fine della validazione l'utente deve produrre un Validation Report (vedi Appendice M7). Il Quality & Project Plan deve essere concordato col fornitore, deve soddisfare gli indirizzi del Validation Plan e deve deve definire in particolare il ruolo dell'utente nelle attività di quality assurance (vedi Appendice M6). Per le specifiche di sistema esistono le seguenti direttive: Functional Specs (vedi Appendice D2), Hardware Design Specs (vedi Appendice D3), Software Design e Software Module Design Specs (vedi Appendice D4). Secondo l'annex 11 del GMP deve esistere una system description che descrive per ogni sistema principi, obiettivi, misure di sicurezza, caratteristiche principali, interfacce verso altri sistemi e procedure: se queste informazioni sono incluse nelle Functional Specs, non è necessario produrre un documento separato. Lo sviluppo del software deve essere inquadrato dal fornitore in un quality management system atto a sviluppare e configurare il software in accordo ai requisiti. L'utente deve controllare il fornitore per quel che concerne: metodi e strumenti, politiche e procedure, regole di programmazione, metodi di review, testing e verifica, sicurezza e confidenzialità. L'utente deve anche verificare che il codice sorgente subisca reviewing formale (vedi Appendice D5). Le Test Specs devono essere prodotte per le seguenti attività: Software module test Software integration test Hardware acceptance test System acceptance test. Le direttive per test specs e documentazione dei risultati sono definite in Appendice D6. Per il mantenimento dello stato di validazione l'utente deve predisporre e mantenere procedure e piani per i seguenti aspetti. 1. Definizione di procedure operative per l'uso e la gestione del sistema. Esse debbono essere definite prima della messa in servizio. 2. Training per utenti e staff di supporto.

5 3. Politica per la gestione e risoluzione di problemi: come catturarli, valutarli, priorizzarli, controllarne l'evoluzione, scalarli e chiuderli. 4. Definizione dei contratti di assistenza e manutenzione (vedi Appendice O2). 5. Definizione di temi di system management come l'amministrazione, l'uso di tool, i test e le calibrazioni di routine, la gestione di parti di ricambio e materiale di consumo. 6. Debbono essere stabilite procedure di back-up e recovery (vedi Appendice O7). 7. Debbono essere stabilite procedure di gestione della configurazione (vedi Appendice M9). 8. Debbono essere stabilite procedure di gestione delle modifiche (vedi Appendice O4). 9. Debbono essere stabilite procedure di security management (vedi Appendice O3). 10. Esistono sistemi che potrebbero perdere la missione a fronte di degradi prestazionali, essi debbono essere posti sotto performance monitor periodico (vedi Appendice O5). 11. Debbono essere stabilite procedure per la gestione delle registrazioni relative alla qualità (vedi Appendice O6). 12. Debbono essere stabilite procedure per la continuità di esercizio: disaster recovery e rigenerazione del software e dei dati del sistema (vedi Appendice O8). 13. Debbono essere stabilite procedure per la revisione periodica del sistema e del mantenimento dello stato di validazione (vedi Appendice O1). 14. Debbono essere stabilite procedure per il decommissioning dei sistemi che tengano conto del fatto che essi gestiscono dati rilevanti per le GxP (per la gestione dati vedi Appendice O6). Schema riassuntivo della principale documentazione da produrre durante il progetto: Documento Responsabilità Appendice User Requirement Specification U (utente) D1 Validation Plan U M1 Quality & Project Plan E (entrambi) M6 Functional Specification F (fornitore) D2 Hw Design Specification F D3 Sw Design Specification F D4 Test Specification F D6 Validation Report U M7 2 Sistema di gestione per fornitori di IT Systems E' raccomandato che il fornitore segua un sistema formale di gestione, preferibilmente basato su ISO Questa parte si applica ai sistemi IT, i MES sono considerati tali, sebbene siano sull'area di confine con i sistemi di controllo processi. Oggi si impiegano sovente package commerciali per applicazioni IT; in questo caso la documentazione del prodotto deve essere usata intensamente per la validazione del sistema. Di seguito è riportato il ciclo di vita generico. Non tutti i sistemi richiedono tutta la documentazione elencata (il Quality and Project Plan deve identificare la documentazione richiesta). Il ciclo di vita deve evolvere in modo sequenziale (i deliverable debbono essere approvati in ordine logico). Ad esempio mentre il progetto può iniziare prima che URS e FS siano finite, il progetto completo non può ovviamente essere approvato prima di URS e FS. La tracciabilità deve essere mantenuta durante l'elaborazione dei documenti. Il planning può richiedere un risk assessment (vedi Appendice M3). Il prototyping è consentito come strumento per chiarire i requisiti di utente e per valutare le aree di rischio. Deve però essere eseguito un rigoroso controllo di versioni: prototipo e software finale debbono essere segregati.

6 Planning and Specification SAMP??? (1) Validation Plan (M1) User Requirement Specification (D1) Supplier Assessment (M2) Quality and project plan (M6 + M3/M4) Functional Specification (D2) System Acceptance test Specification (D6) Design and Construction Hardware Design Specification (D3) Hardware Acceptance Test Specification (D6) Software Design Specification (D4) Software Integration Test Specification (D6) Package Configuration Specification Software Module Design Specification (D4) Software Module Test Specification (D6) Hardware Production Software Production (D5) Configure Package Installation and Testing Hardware Acceptance Test results (M7) Package Configuration Test Specification (D6????) Software Module Testing and Verify Configuration (M7???) Results (M7) Software integration Testing and Results (M/7) (2) Acceptance testing System Acceptance Tesing and Results (M7) Operation (mantaining the validated state) Change Control (M8) Maintenance (O2) Note: (1) In verde le attività a completo carico dell'utente (2) In alcuni sistemi l'integration testing non è necessario L'adozione di software package standard può richiedere una significativa reingegnerizzazione dei processi, in questo caso i processi debbono essere rivalidati. Il Quality and Project Plan è un documento contrattuale e quindi deve essere approvato sia dall'utente, sia dal fornitore. Per i software package standard i requisiti possono essere soddisfatti da una combinazione di: funzioni standard settaggi di configurazione customizzazioni del prodotto base nuovo software custom, come le specifiche evolvono, il Quality and Project Plan deve essere aggiornato per definire quali di questi approcci deve essere usato e come esso va documentato. Le Specifiche non debbono essere vaghe o ambigue: l'obiettivo è quello di usarle successivamente per il test. Un piccolo sistema può essere completamente definito da una Specifica, sistemi più grandi possono invece richiedere un insieme di specifiche funzionali, di progetto e di configurazione di package. Il processo di tracciabilità requisiti - specdifiche - progetto - test richiede l'uso di matrici di tracciabilità (vedi Appendice M5). La Functional Specification è un documento contrattuale e quindi deve essere approvato sia dall'utente, sia dal fornitore. Per sistemi piccoli si può omettere la produzione di documentazione di

7 progetto e di package configuration, inserendo questi temi in appendice alla FS (questo deve però essere definito nel Quality and project plan). In compenso sistemi complessi possono essere necessarie più FS. Se si usano software package si deve dove possibile fare ricorso alla documentazione del fornitore. Le System Acceptance Test Specification è opportuno scriverle in parallelo alle FS. L'hardware va basato per quanto possibile su prodotti standard di fornitori qualificati. L' Hardware Design Specification e l'hardware Acceptance Test Specification è opportuno scriverle in parallelo. Il Package Configuration Specification include: settaggi di configurazione motivi del settaggio con riferimento ai requisiti strumenti o metodi da usare per impostare le opzioni richieste dipendenze e impatti su altri moduli e sistemi sicurezza dei settaggi. Per sistemi di piccole dimensioni è possibile mettere queste informazioni in appendice a FS (questo va precisato nel Quality & Project Plan). Le Software Design Specification sono la base per lo sviluppo. Se c'è un solo modulo da sviluppare non è necessario produrre la documentazione di design e test a livello di modulo e la Specifica di test di integrazione. Per sistemi di piccole dimensioni è possibile mettere queste informazioni in appendice a FS (questo va precisato nel Quality & Project Plan). Se si usa un approccio OOD/P il fornitore deve verificare che il metodo soddisfi le normative di settore e i requisiti di utente e documentare tale metodo nel Quality & Project Plan. Le design review dovranno tener conto di questo approccio e così il Configuration Management che dovrà fornire copertura anche per librerie e tool associati. Il Controllo di Configurazione deve essere regolato in conformità all'appendice M9. Le Software Module Design Specification devono normalmente essere aggiornate dopo lo sviluppo per includere dettagli essenziali per la successiva manutenzione. Le Network Design Specification si rendono necessarie per sistemi in cui la rete è rilevante, esse includono descrizioni su: componenti fisici, protocolli di trasporto, sistemi operativi di rete, cablaggi, bridge, server, socket, etc. Per sistemi di piccole dimensioni è possibile mettere queste informazioni in appendice a FS (questo va precisato nel Quality & Project Plan). Le reti debbono essere realizzate per quanto possibile con prodotti standard di fornitori qualificati. E' opportuno produrre in parallelo una Network Acceptance Test Specification. Il codice deve essere sviluppato con metodi, strumenti, regole di programmazione e convenzioni sui nomi di variabili che debbono essere documentati. I sorgenti debbono essere sottoposti a code review. Le modalità e frequenza delle review debbono essere specificate nel Quality & Project Plan. Se si usano componenti software esistenti (i.e. OOP) si deve valutare se essi debbono essere sottopostia review e testing. Il Quality & Project Plan deve definire se il fornitore consegna i sorgenti all'utente, se no l'utente può richiedere il deposito dei sorgenti presso una terza parte. Le linee guida per la produzione di codice sono descritte in Appendice D5. Per Specifica prodotta deve essere prodotta un corrispondente insieme di Specifiche di Test, con un metodo di registrazione della tracciabilità. I test sulla configurazione dei software package possono avvenire per ispezione o per prova. Per le reti è importante eseguire soprattutto i test di componenti che potrebbero divenire inaccessibili come conseguenza della costruzione del sistema. Le System Acceptance Test Specification sono un documento contrattuale e quindi vanno accettate sia

8 dall'utente, sia dal fornitore. Esse coprono varie aree: funzionalità, configurazione, performance, aspetti critici, procedure operative. I test debbono coprire le verifiche di allarmi, limiti, range di valori. Il testing è svolto a vari livelli di dettaglio, corrispondenti ai vari livelli di specificazione. Il fornitore è di solito coinvolto in tutti i livelli di test e le registrazioni di test del fornitore possono essere parte della documentazione di validazione, se è appropriatamente controllata. System Acceptance Testing Valida URS e FS (FAT+SAT) Hardware Acceptance Testing Valida HDS Software Integration Testing Valida SDS Software Module Testing Package Configuration Testing Valida SMDS e PCS Review & Test module Verifica la codifica La validazione è più pesante per sistemi custom, che per sistemi package based. L'utente ha un coinvolgimento primario sui livelli alti di testing. Nei sistemi gestionali spesso i test vengono svolti in tre aree: laboratorio software, laboratorio di test e ambiente target. Gli HAT e i SAT (a volte divisi in Factory Acceptance Test e Site Acceptance Test, nel qual caso l'utente deve essere presente in entrambi) devono essere prodotti in modo completamente documentato: moduli firmati. Deve esistere una procedura definita per eseguire i test e registrarne gli esiti. La fase di accettazione include la consegna della documentazione finale. Aspetti gestionali che coprono l'intero ciclo di sviluppo (conformi a ISO 9000) e che devono essere coperti durante il supplier assessment sono: 1. Review: La modalità deve essere definita nel Quality & Project Plan, le direttive sono in Appendice M5. 2. Configuration Management: Deve esistere un sistema per il CM e per la gestione delle change (cambiamenti a documentazione contrattuale o a deliverable approvati devono essere concordati con l'utente). La modalità deve essere definita nel Quality & Project Plan, le direttive sono in Appendici M8, M9, M Controllo sub-fornitori: Debbono essere approvati dall'utente che si può riservare il diritto di farne audit. Le forniture debbono essere regolamentate da ordini ben definiti. Il fornitore si deve rendere garante di queste sub-forniture. Per l'hardware possono essere inclusi certificati di test e calibrazione. 4. Training: Il fornitore deve erogare adeguata formazione al suo personale e documentare la formazione eseguita nella documentazione di progetto. Una volta completato lo sviluppo si devono eseguire le operazioni atte a mantenere lo stato di validazione del sistema. Il fornitore può essere coinvolto in questo mediante servizi di supporto. Per i sistemi IT particolare considerazione deve essere rivolta a: gestione delle modifiche configuration management gestione release software planning del business continuity (i.e, disaster recovery, procedure di rigenerazione).

9 3 Validazione di Process Control System (PCS) I precedenti due paragrafi si riferivano soprattutto ai sistemi IT. Qui vengono trattati invece i sistemi che gestiscono processi di produzione o di laboratorio. La loro validazione è più complessa perché l'attività è più multi-disciplinare. I PCS sono a volta integrati con sistemi gestionali per formare una infrastruttura CIM. Per eseguire la validazione si deve tener conto anche della ISPE Baseline: Guide on commissioning and qualification, che fornisce indicazioni per qualificazioni con attività di commissioning. Lo schema di verifica è fatto col solito approccio a V. Retirement Operation & maintenance Planning Performance Process Requirement Operational GxP and safety review Installation Equipment FS Control System FS Operational Check Mechanical and Electrical Design Operating Interface Design Design review and approval Control System Design I sistemi PCS possono appartenere a due categorie: Mechanical and Electrical Build Operating Interface Build Control System Programming (FAT&SAT) Installation Check (FAT&SAT) Module integration and development testing embedded in macchinari standalone connessi a impianti (PLC, SCADA, DCS, BMS (Building Management System)). Normalmente la generazione della documentazione di sistemi embedded è a carico del fornitore. Per lo sviluppo di sistemi standalone, il coinvolgimento dell'utente è maggiore. Il fornitore deve comunque applicare un ciclo di vita atto a produrre la documentazione necessaria al successivo supporto della fase di qualificazione, con tracciabilità dai requisiti fino al testing.

10 Di seguito si riporta il ciclo di vita e di documentazione per gli embedded system. Planning and Definition Location Responsability Validation Plan (M1) Vendor USR (D1) Critical Process Assessment Parameters C C Specification Approval Supplier Assessment (M2) S C(S) Design Specification, Development and Construction Mechanical FS Electrical & Software FS Instrument FS Mechanical E&I Diagrams, HDS SDS Drawings S S(C) Mechanical Construction Cabling Code (D5) Design Reviewing and Testing STS HATS Software testing Commissioning and Installation Operational Performance Electrical testing & Instrumentation Calibration and Results FATS Factory Acceptance Testing and Results GEP Installation Site Acceptance Test Commissioning and Results Software release and installation S C S (C) FAT: S (C) D. Rev.: C (S) Install: S(C) IQ: C(S) SAT: S(C) OQ: C(S) Comm.: S(C) PQ: C(S) Ongoing Operation (Maintaining the validation state) Change Control Maintenance Periodic Review C C (S) Decommissioning Retirement C C (S) Legenda: L'area in grigio è quella soggetta a design review; C è customer, S è supplier, () indica un possibile coinvolgimento

11 Di seguito si riporta il ciclo di vita e di documentazione per gli standalone system. Planning and Definition Location Responsability Validation Plan (M1) Specification Approval Vendor USR (D1) Critical Process Assessment Parameters C C Design Agreement Process Design Data Contracto rs Quality Plan Design and Development Phase Cabling & Instrumentation Application Data Sheet (5) C&I Application Engineering & Drawings Supplier Assessment (M2) S C(S) Functional Design Specs Computer HW Design Specs Development Testing & System Build C&I inspection and calibration (vs. 5) Hardware Test Specs (2) Computer HW Production Computer Hw Testing (vs. 2) Acceptance Test Specs (1) Software Design Specs Sw module Design Specs System suppliers Quality Plan Sw integrat. Specs (3) Sw module Test Specs (4) Sw module coding & configuration Sw module Tesing (vs. 4) Sw module integration testing (vs. 3) Supplier's system integration and testing (vs. 1, 2 e 3) S S S S (C) S (C) S (C) Design Review & Acceptance Testing Factory Acceptance Test (vs. 1) S FAT: S(C) Des. Re.: C (S) Commissioning and Installation Operational Performance GEP Installation Site Acceptance Test Commissioning C Install: S(C) IQ: C(S) SAT: S(C) OQ: C(S) Comm.: S(C) PQ: C(S) Ongoing Operation (Maintaining the validation state) Change Control Maintenance Periodic Review C C (S) Decommissioning Retirement C C (S) Legenda: L'area in grigio è quella soggetta a design review; C è customer, S è supplier, () indica un possibile coinvolgimento

12 Le norme concernenti i PCS mi sembrano meno dettagliate e coerenti di quelle relative agli IT system del paragrafo precedente (ndr). Durante la fase di planning l'utente esegue un assessment delle procedure di qualità del fornitore, per verificarne la congruità e valutare l'esigenza di azioni correttive. Il fornitore redige un Quality & Project Plan (vedi Appendice M6) e supporta l'utente nell'esecuzione del risk assessment (vedi Appendice M3). In questo caso l'attività riguarderà non solo hw e sw, ma anche strumentazione, aspetti elettrici e meccanici. Le USR (vedi Appendice D1) potranno essere più di una, in particolare ce ne potrà essere una focalizzata esclusivamente sulle funzionalità di controllo. Questo non è necessario in applicazioni di piccola dimensione ove i dati sul processo possono essere inclusi nella specifica della macchina o dell'apparato da controllare. Si deve porre particolare attenzione alla definizione dei parametri produttivi controllati e all'assessment della loro criticità. Per questo è importante gestire delle matrici di tracciabilità (vedi Appendice M5). La documentazione rilevante contrattualmente deve essere messa sotto change control una volta approvata. Le Functional Specs sono la base per l'oq. Per sistemi standalone devono coprire tutti i temi, mentre per gli embedded le problematiche di controllo possono essere trattate nella documentazione del macchinario. La struttura della documentazione deve comunque essere definità nel Quality & Project Plan. Se il software include funzionalità non usate nella specifica applicazione, esse debbono essere elencate. Per piccoli sistemi è possibile che FS includano in appendice anche le specifiche di progetto. Questo tipo di sistemi richiedono una documentazione che correli il sistema di controllo all'impianto controllato, essa consta di: layout degli impianti e degli apparati, diagrammi di flusso del processo e localizzazione della strumentazione (P&IDs), tabella degli anelli di regolazione e della strumentazione (con dati caratteristici dei segnali, soglie di allarme, etc.), sequenze, logiche e interblocchi di processo (normalmente diagrammi o matrici), schemi elettrici di cablaggio. L'HDS deve includere dati anche per la strumentazione e le interfacce. Per piccoli sistemi è possibile incorporare il tutto nelle FS. L'SDS definisce non solo la struttura del software, ma anche le norme di programmazione. Il software deve essere modulare, strutturato e commentato. Per piccoli sistemi è possibile incorporare il tutto nelle FS. L' Instrument Specification è derivata dai P&IDs e i parametri relativi sono ottenuti dalle URS. La specifica fornisce quindi i requisiti per ogni strumento necessario. La Realizzazione del sistema si compone di: sviluppo software costruzione sistema realizzazione di disegni ingegneristici.

13 Le Design Review permettono il tracciamento dei lavori dai requisiti (hw, sw, ambientali, performance, etc), fino alla fine dello sviluppo. Di nuovo è importante usare matrici di tracciabilità. Si noti che è ammesso che alcuni requisiti di sistema (layout di schermo, formato reports, etc.) non siano inizialmente ben definiti e vengano chiariti in corso d'opera: in questo caso si esegue una review 'ad interim'. Norme per le design review sono incluse anche in ISPE Baseline: Guide on Commissioning and. Lo Sviluppo software deve essere fatto con metodi, convenzioni e strumenti appropriati. Il codice sorgente deve essere commentato (vedi Appendice D5). La Costruzione del sistema può avvenire presso il fornitore (normale per gli embedded system) o presso il sito finale. Essa avviene in accordo ai disegni di assemblaggio dell'impianto e dell HDS. Le Software Review controllano il rispetto delle specifiche e delle metodologie di sviluppo. Esse debbono essere svolte da personale esperto e indipendente (vedi Appendice D5). Il Test di sviluppo è svolto dal fornitore e copre: Software development test (funzionale e strutturale), Hardware manufacturing test, Sw/Hw integration test, Instrumentation & electrical equipment manufacturing test. I Test di accettazione debbono essere formalmente documentati, rivisti e approvati. Essi debbono avere una severità basata su caratteristiche del sistema e criticità GxP. Normalmente sono divisi in FAT e SAT. Il FAT di standalone system può essere svolto con simulazione del processo. Il FAT è fonte preziosa di informazioni per la messa a punto finale del sistema. Il SAT controlla che il sistema non abbia subito danni nel trasporto e operi correttamente nel suo ambiente finale. Normalmente la procedura di accettazione SAT è identica a quella FAT, più alcuni test eseguibili solo nell'ambiente target. Se le modalità di test sono sufficientemente rigorose il SAT può fornire la base di IQ e OQ (vedi ISPE Baseline: Guide on Commissioning and ). La strumentazione di campo va calibrata prima e dopo la consegna del sistema. La Qualificazione verifica che il PCS può essere usato presso la struttura dell'utente. La IQ controlla: Il corretto caricamento del software Il corretto assemblaggio e installazione dell'hardware I cablaggi di alimentazione e di segnale Il controllo della calibrazione e della installazione della strumentazione Il corretto funzionamento di diagnostica di power-up e on-line. La OQ la PQ verificano che la funzionalità del sistema sia adeguata nelle condizioni operative reali, anche di stress e allarme. Alla fine della qualificazione viene redatto il Validation Report. Si consideri che normalmente la PQ va in parallelo al Process. Il Mantenimento dello stato di validazione implica la definizione di piani e procedure di assistenza e supporto, che possono coinvolgere il fornitore. In particolare deve essere definita la procedura per la ricalibrazione e il controllo periodici della strumentazione. I review periodici debbono essere focalizzati soprattutto alla verifica dei seguenti attributi di sistema: affidabilità, ripetibilità, prestazioni e diagnostica, salvaguarda di dati critici, etc. Tutte le modifiche debbono essere sottoposte a Change Control e Configuration Management.

14 Il Decommissioning come al solito deve verificare la possibilità di archiviare e ritrovare dati contenuti nel sistema e rilevanti ai fini del tracciamento di qualità o del rispetto di specifiche normative.