Carenze di Ricorso nel Supporto di Sviluppo Trattato

da Dott. Dirk Ortloff

Dirk Ortloff, Jens Popp, Andreas Wagener
1Relazioni Trattate Gmbh
Autore Corrispondente: dirk.ortloff@process-relations.com

Argomenti Coperti

Estratto
Introduzione
Carenze
     Pressioni del Mercato
     Uso delle Pre-Valutazioni Virtuali
     Gestione di Informazioni Interna Insufficiente
     Supporto di Conformità e della Documentazione
Requisiti
Soluzioni
Conclusioni
Riferimenti

Estratto

Oggi vari incertezze e sviluppi di nuovo prodotto di sfida delle transenne o potenziamenti di prodotto. Ciò è particolarmente vera quando mette a punto i sistemi microelectromechanical (MEMS), sistemi nanoelectromechanical (NEMS) o unità nane della pellicola sottile del disgaggio ed i loro processi di fabbricazione specificamente richiesti. La diversità delle opzioni della tecnologia ed i loro vincoli come pure le geometrie restringenti ed altre forze interne e di esterno sopraffanno gli ingegneri e mettono le tecnologie al loro limite. Questo documento studia sistematicamente le aree differenti dei fattori esterni ed interni e delle loro influenze sugli sviluppi trattati di NEMS e di MEMS.

Per fare fronte alle sfide di difficoltà crescente nello sviluppo trattato di montaggio di MEMS/NEMS un nuovo approccio per automazione di progettazione trattata adeguata è necessario. Le necessità di approccio di riguardare la progettazione delle sequenze di nuovo processo dalla primissima idea alla consegna definitiva a fabbricazione in serie. Deve anche fornire i mezzi per il trasferimento elettronico dei dati e della conoscenza trattati nei partner della tecnologia.

Avanzi giù questo documento raccoglie i requisiti delle funzionalità affinchè i vestiti del software supportino questo approccio. Evidenzia, quello che le domande dei mercati a termine crescenti possono essere compiute soltanto con uso intensivo di tali software tool che funzionano congiuntamente con le metodologie di assistenza tecnica di prodotto. Strumenti di questo entrare gentile nella categoria di Sistemi di Esecuzione di Sviluppo Trattato (PDES) che migliorano e che automatizzano molte delle mansioni eseguite manualmente oggi. Questi oggetti sono stati indirizzati in PASSEGGIATA di progetto di ricerca di UE (IST 507965) e sue pubblicazioni2-4. Uno strumento di quella categoria che compie molti di questi bisogni è XperiDesk® che la commercializzazione della PASSEGGIATA risulta.

Introduzione

I Progetti di sviluppo per le nuove ricette di fabbricazione delle unità di NEMS e di MEMS sono sfidati da vari esterno differente e requisiti interni. Nella sezione successiva le carenze che derivano dalle pratiche correnti dello sviluppo sono evidenziate. Per motiviamo quelli, danno un'occhiata alle pratiche correnti dello sviluppo. Questo profilo di un progetto di sviluppo trattato precedentemente è stato pubblicato1 in modo analogo.

Ogni nuovo prodotto o potenziamento di prodotto si avvia con una nuova idea. Nell'area di progettazione dell'unità e di trattamento per MEMS e NEMS, le esperienze personali acquisite con gli sviluppi precedenti forniscono un contributo importante alle novità.

Altre sorgenti per informazione ed inspirazione includono i colleghi, gli articoli scientifici ed i vecchi libri del laboratorio. Tuttavia, questo è dove i problemi sorgono. I Colleghi non sono sempre disponibili e non è sempre chiaro se un determinato esperimento già è stato eseguito. I libri del Laboratorio sono una grande risorsa per i dati storici, ma nella maggior parte dei casi, sono soltanto utili alla gente che le ha scritte, come sanno dove guardare e leggerle. Anche se i file sono disponibili, spesso si distribuiscono su parecchi file server o sono nascosti in un certo posto e sono ordinati soltanto da un criterio unidimensionale. Cercando da un'altra prospettiva è quasi impossibile.

Ancora, ogni ingegnere ha suo proprio modo di memorizzare le informazioni, in modo da significa che il vario software del freeware e dell'ufficio è usato per creare la documentazione. Già in questa prima fase di unità e di sviluppo trattato molte buone idee sono rottamate semplicemente perché non c' è abbastanza tempo di effettuare la ricerca necessaria e di esplorare lo spazio di soluzione sufficientemente.

Una Volta Che queste transenne iniziali sono sormontate, l'ingegnere poi comincia progettare un flusso di nuovo processo puntato su producendo l'unità in mente. Ciò è fatta su documento o sul per mezzo degli strumenti dell'ufficio quali un trattamento testi o i fogli elettronici. I formati di dati e del File variano solitamente dall'ingegnere all'ingegnere. Un problema critico con questo approccio è che nella maggior parte dei casi soltanto “le buoni„ ricette e risultati sono tenuti. Gli esperimenti Infruttuosi ed i loro dati risultanti sono eliminati spesso, archivato e spesso periodi dimenticato non correttamente.

Per esempio, un collega potrebbe cambiare la configurazione di un commputer (senza documentarlo), o un commputer utilizzato negli esperimenti precedenti non potrebbe essere disponibile più, rendendolo difficile usare e riprodurre i risultati degli esperimenti precedenti. Come conseguenza di questa pratica, di soltanto un ingegnere o di piccolo gruppo di conoscenza di guadagni degli ingegneri dagli esperimenti guastati. Ciò piombo ad una ripetizione degli errori, che è costosa in termini di tempo, risorse e moneta. Così non archivare il contesto completo di un esperimento limita la riproducibilità e spreca le risorse apprezzate.

Il punto seguente nella progettazione di nuovo processo di produzione è di verificare il flusso trattato montato. È tutta la pulizia necessaria punti là? Il bilancio della temperatura è incontrato? Questa sequenza dei punti contaminerà i commputer? Tuttavia, queste domande si applicano soltanto all'aspetto di manufacturability del flusso trattato, non l'aspetto funzionale. È evidente che molti vincoli devono essere incontrati e molti ostacoli devono essere sormontati per progettare “un buon„ flusso trattato.

dovuto le restrizioni di tempo inflitte dai più brevi cicli di sviluppo, queste valutazioni non sono a volte abbastanza accurate. Al massimo, altri ingegneri con esperienza valutano il flusso trattato e lo valutano dal loro punto di vista facendo uso delle loro proprie esperienze. Il problema con questo approccio è che gli ingegneri con esperienza non sono sempre disponibili facilmente in seno ad una società. Anche se c'è un trattamento accurato di esame, nessuno è perfetto e la tecnologia della trasformazione diventa sempre più complessa ogni giorno.

Gli errori Semplici, come avere il materiale sbagliato nel commputer sbagliato, possono avere un grande impatto sul progetto, sulla strumentazione utilizzata e sulla società. Questi errori provocano i risultati in ritardo e commputer nocivi, che interrompe la linea di produzione. Per Concludere, il primo turno del flusso trattato è eseguito ed i risultati sono valutati.

Nella maggior parte dei casi, il primo turno è un successo parziale o nessun successo affatto. Tuttavia, l'esperienza apprezzata è acquisita. Tuttavia, i vari dati e maschere (facendo uso dei microscopi elettronici di scansione (SEMs), dei microscopi atomici della forza (AFMs), Ecc.) sono generati durante la valutazione. Questi file sono memorizzati su file server e spesso soltanto sono esaminati dalle persone direttamente interessate perché conoscono la loro posizione e che esperimento appartengono. Per rendere gli argomenti peggiori, la discussione circa questi dati ha luogo via il email. Come conseguenza di questa pratica, la conoscenza informale circa il trattamento è memorizzata soltanto sul mail server ed accedere a questa conoscenza a tempo scaduto è passato ancora è difficile.

Dopo Che l'esperimento è completo, i risultati e le conclusioni tratti sono usati per regolare il flusso trattato o la progettazione dell'unità e una nuova ripetizione della ricetta e della progettazione comincia. Tuttavia, lo spazio di parametro è diventato troppo grande per gli esseri umani. Parecchi esperimenti inutili sono fatti su un percorso “di zigzag„ alla versione di trattamento di finale o al licenziamento di un'idea.

Lo Studio della pratica sopra descritta fornisce le comprensioni nelle emissioni durante lo sviluppo trattato ed evidenzia il potenziale per i miglioramenti necessari. Il resto del documento guarda più dettagliatamente sopra nella descritta in come pure ulteriori transenne e sfide.

Carenze

Come motivato negli strumenti di sviluppo e nelle pratiche di trattamento della corrente dell'introduzione soffra da parecchie sfide riguardo a supporto adeguato. Queste carenze possono essere raggruppate in quattro aree importanti:

  1. Il servizio fa pressione su e tendenze che devono essere affrontate dalle società con gli strumenti insufficienti per gli esperimenti, la collaborazione e la normalizzazione.
  2. L'uso limitato delle possibilità virtuali di pre-valutazione (come le valutazioni di manufacturability) e delle simulazioni dovuto varie ragioni.
  3. Informazioni e gestione delle conoscenze interne Insufficienti.
  4. Supporto Insufficiente di conformità e della documentazione.

Pressioni del Mercato

La concorrenza Mondiale e le domande del mercato risultano dentro requisiti più veloci e più veloci di time to market. Ciò richiede gli approcci più efficienti dello sviluppo. Vari itinerari possono essere catturati per compire questo scopo.

Un modo avvicinarsi all'emissione di time to market è di usare il modello virtuale e le pre-valutazioni virtuali. Il modello Virtuale può accelerare significativamente lo sviluppo nei primi risultati d'offerta più velocemente. Egualmente permette la verifica delle varianti più potenzialmente utili nello stesso tempo. L'Individuazione dei difetti nelle ricette sviluppate e nelle alternative possibili più presto nel processo di sviluppo può tagliare significativamente il tempo e le spese. Purtroppo il software appropriato per queste mansioni è spesso insufficiente nel migliore dei casi.

Un Altro approccio per accelerare lo sviluppo sta riutilizzando il più possibile dagli sviluppi precedenti. Per le ricette quello ed i risultati centralmente gestiti e riproducibili dello sviluppo è un presupposto. A causa dei formati non uniformi della documentazione, i dati sparsi di risultato ed il recupero insufficiente significano che questo presupposto non è compiuto spesso.

La Collaborazione fra la gente ed i gruppi differenti dentro la società è di importanza fondamentale per gli sviluppi alta tecnologia. Ciò può comprendere la collaborazione fra i gruppi differenti intorno al globo. Il Servizio tende ed i costi di realizzazione anche determinano l'esigenza delle attività di collaborazione dello sviluppo fra gli enti giuridici differenti. La Collaborazione può migliorare il time to market.

Comunque una piattaforma centrale adeguata dello sviluppo, compreso la comunicazione e le funzionalità elettroniche di trasferimento di conoscenza, è necessaria agire in tal modo efficientemente. Ciò è particolarmente vera, se la conoscenza trattata deve essere trasferita ad un nuovo sito. L'Installazione del trattamento al sito di ricezione posa spesso le deviazioni dai risultati previsti di riferimento. Queste deviazioni devono Spesso essere ricercate ancora perché non c'è nessuna base adeguata di riferimento presente. Ciò piombo alla comprensione che l'odierna pratica comune della tecnologia di trasferimento via i lunghi libri blu trattati ed i trasferimenti dell'ingegnere non soddisfarà le richieste delle risorse e di in tempo degli sviluppi futuri.

Uso delle Pre-Valutazioni Virtuali

Come motivato sopra, il modello e le pre-valutazioni virtuali possono accelerare gli sviluppi e ridurre i costi. A Volte l'uso delle funzionalità virtuali di pre-valutazione come le simulazioni strutturali è limitato dalla larghezza di banda degli esperti in simulazione o dalla disponibilità delle risorse richieste di manutenzione e di simulazione. Ciò è spesso dovuto gli impianti di software locali e le richieste di manutenzione come pure dovuto la necessità per personale specialmente preparato di sviluppare per esempio le configurazioni di simulazione. Questa in gente esperta si trasforma in in un grave ostacolo per efficacemente facendo uso degli strumenti di simulazione o in altri mezzi virtuali di valutazione. Di Conseguenza “gli assegni di Idea„ sono eseguiti via gli esperimenti in tensione reali che causano un aumento a tempo e risorse spese come pure uno spazio di riduzione in soluzione esplorato. Ciò induce gli ingegneri ad abbandonare semplicemente le buone idee perché non c' è abbastanza tempo di realizzare la ricerca e la prospezione necessarie.

Ancora, al giorno d'oggi le ricette sono diventato immensamente complesse in modo che fosse duro anche affinchè gli ingegneri dei metodi di trasformazione con esperienza individuasse tutte le contrazioni potenziali dentro un flusso trattato. Di Conseguenza l'esame manuale dei runcards e pianificazione Fa è diventato un noioso, che richiede tempo ed a volte anche compito soggetto a errori. I punti decimali Scorrettamente collocati in runcards manualmente generati, gli aggiornamenti contradditori dei sottomoduli in un flusso, le contraddizioni materiali o le incompatibilità sono sempre più difficili da macchiare e possono indurre gli interi batch ad essere non utili o, nei casi estremi, potrebbero anche danneggiare o contaminare la produzione di attrezzature.

Gestione di Informazioni Interna Insufficiente

Un Altro gruppo di emissioni è le informazioni e la gestione delle conoscenze interne insufficienti con conseguente assistenza tecnica di ricorso “il déjà vu„. Le Esperienze acquisite dagli sviluppi precedenti, dagli articoli scientifici e dai vecchi laboratorio-libri forniscono il contributo principale alla realizzazione delle idee del nuovo prodotto. Avendo il nessun o soltanto struttura insufficiente in questi dati causa molto lavoro del doppio e di difficoltà. Esperti nel preventivo di sviluppo trattato a semiconduttore che 10-15% degli esperimenti guastati e doppi potrebbe essere evitato, se i risultati precedenti fossero accessibili in un modo più facile. Questo legami dentro con le emissioni in seguito alla fluttuazione dell'ingegnere fra i progetti differenti. Entrando l'esperto nel progetto in un progetto differente potrebbe compromettere il progetto precedente mentre gli ingegneri che entrano in un progetto corrente sono sommersi dai lotti di informazioni non strutturate.

I mezzi tradizionali di archiviazione di dati forniscono Ulteriormente soltanto un criterio di ricerca unidimensionale. L'archiviazione di dati Stipata Di di risultato ed i dati importanti sulle unità disco locali causano la raccolta di dati ed a volte anche la perdita manuali noiose e soggette a errori di dati. Ancora spesso soltanto i punti di informazioni o gli insiemi di dati puri di risultato sono memorizzati con di contesto nessun o limitate informazioni. Soltanto limitando il contesto pone i problemi quando prova a riprodurre gli effetti o il risultato precedentemente veduti nel ricavare le conclusioni sbagliate dall'analisi di causa-effetto. Queste circostanze producono “il déjà vu„ sotto forma di “Una Volta Che avessimo un risultato…„ quello può essere molto seccante ed a costo elevato.

Supporto di Conformità e della Documentazione

La Documentazione e riferire del progresso dello sviluppo possono essere noiose nel migliore dei casi. L'archiviazione Stipata Di di risultati mette lo sforzo manuale principale sugli ingegneri di sviluppo che richiedono loro per raccogliere manualmente i dati da diverso macchinario. Ulteriormente il montaggio dei dati raccolti di risultato nei rapporti e della valutazione può richiedere una maggior parte di tempo di intervento tecnico. Riferendo sullo stato dello sviluppo è spesso cronometra più un montaggio manuale dei rapporti che un trattamento automatizzato. I dati di input non sono spesso aggiornati in modo che lo stato (WIP) del Lavoro in Corso non sia necessariamente preciso. Gli impatti di questi effetti anche sono aggravati tramite assicurazione di qualità e la conformità richiede quale l'ISO 900X, CMMI, SOX Ecc. Poiché quelli si applicano sempre più in via di sviluppo come pure nella produzione, c'è una forte domanda per soddisfare le condizioni imposte della documentazione.

Requisiti

Per aggirare o limitare gli impatti dei software tool precedentemente descritti di sfide è necessaria. Avere una piattaforma centrale potere supportare la raccolta di dati di pianificazione, di verifica e di risultato di esperimento ha potuto migliorare tutti questi sforzi. Una tal piattaforma ha potuto raccogliere Ulteriormente i dati di riferimento per la pianificazione di progetto futura tenendo la cronologia della progressione. Un Tal software tool deve soddisfare le seguenti condizioni ad alto livello:

  • Supporti il ciclo di sviluppo completo come presentato nella Figura 1.
  • Permetta la collaborazione internamente ed esternamente ma fornisca alla gestione a grana fine di destre e della protezione
  • Permetta i meccanismi completi e selettivi dell'esportazione e dell'inclusione per i trasferimenti di tecnologia
  • Fornisca le possibilità virtuali di pre-valutazione per impedire gli esperimenti guastati il più possibile
  • Offra i meccanismi pre-per valutare recentemente il manufacturability di una ricetta di progettazione
  • Permetta che tutti gli ingegneri eseguano le valutazioni virtuali piuttosto che limitando per/via di uso gli esperti
  • Offra il bloccaggio completo ed accedi a ad informazioni storiche (strutturate come pure informali)
  • Fornisca la ricerca potente e dettagliata di informazioni storiche dalle diverse prospettive
  • Contenga i meccanismi per raccogliersi, categorizzi di risultato della gestione ed informazioni automaticamente
  • Soddisfaccia le esigenze della documentazione dei bisogni di conformità e di assicurazione di qualità
  • Fornisca l'estese segnalazione e capacità di progettazione
  • Permetta l'amministrazione centrale e distribuzione ed esecuzione su varie piattaforme
Figura 1. ciclo di Sviluppo da supportare da un PDES

Soluzioni

Le condizioni sopra quotate possono essere soddisfatte dai Sistemi di Esecuzione dello Sviluppo Trattato (PDES). Un PDES è simile ad un Sistema di Esecuzione di Fabbricazione (MES) in vari aspetti. Il fattore di distinzione centrale è che PDESs è adattato per la direzione lo sviluppo di un processo di fabbricazione mentre MES sono adattati per l'esecuzione della produzione in volume facendo uso del trattamento sviluppato. Di Conseguenza il fuoco e gli strumenti di un PDES è più su volume più basso ma su più alta libertà della sperimentazione e della flessibilità. Gli strumenti di un MES di più sono messi a fuoco su meno varianza, più alti volumi, controllo più stretto e logistica. Entrambi I tipi di software applicativi hanno in comune che aumentano la tracciabilità, la produttività e la qualità (per PDES la qualità del processo di fabbricazione sviluppato contrariamente alla qualità del manufatto per MES).

Un PDES offre un modo semplice di accedere a questi sviluppi precedenti in un modo strutturato. Le Informazioni possono essere più veloce recuperato ed i risultati precedenti possono essere considerati più efficientemente. Un PDES offre tipicamente i mezzi per video e cercare i dati di risultato dai punti di vista differenti e per categorizzare i dati che conciliano gli aspetti differenti. Queste funzionalità si applicano a tutti i dati di risultato come i materiali, i punti trattati, i commputer, gli esperimenti, i documenti, le maschere Ecc. Il PDES egualmente fornisce un modo collegare le entità che appartengono allo stesso o al simile contesto ed esplorare le informazioni risultanti.

Una serie di software che appartiene nella categoria di PDES è dall'aprile 2008 XperiDesk, di prodotto software disponibile nel commercio. Supporta gli ingegneri di sviluppo trattato nel loro compito di mantenere e sviluppare le ricette alta tecnologie di fabbricazione per esempio per la fabbricazione dell'unità a semiconduttore. I risultati di uso in una spinta significativa di produttività degli ingegneri dei metodi di trasformazione come pure di una qualità trattata migliore.

XperiDesk fornisce una piattaforma affinchè gli ingegneri dei metodi di trasformazione lavori insieme e per dividere i loro risultati globalmente e permette al seguente approccio di verifica in tre tappe:

  • Verifica Convenzionale del manufacturability facendo uso di conoscenza di trattamento dell'estratto catturata nelle norme
  • Verifica da simulazione e da visualizzazione e
  • Tenendo La Carreggiata della verifica sperimentale per il bloccaggio ed il recupero dettagliati e completi di conoscenza.

La serie di XperiDesk indirizza la maggior parte dei requisiti sopra quotati e riguarda il ciclo di sviluppo completo per i processi di fabbricazione alta tecnologia come rappresentato in Figura 2.

Figura 2. ciclo di Sviluppo con gli screenshot di XperiDesk

Conclusioni

Un esame delle pratiche correnti dello sviluppo trattato è stato dato e le carenze che derivano da quelle pratiche sono state evidenziate. Le emissioni sono state raggruppate nelle categorie differenti e gli approcci della soluzione potenziale sono stati descritti. Da quello i requisiti degli strumenti di supporto del software sono stati derivati. Queste condizioni possono essere soddisfatte per una nuova categoria del software chiamata Sistema di Esecuzione dello Sviluppo Trattato (PDES).

Un PDES supporta l'intero flusso dello sviluppo - dalla prima idea dell'unità al trasferimento della ricetta risultante in produzione o ad una collaborazione partner. Di Conseguenza, chiude il ciclo dello sviluppo ed inserisce gli odierni risultati del mondo reale nelle idee di domani. Può non sostituire mai la creatività degli ingegneri, ma può aiutare gli ingegneri a mettere a fuoco sulle buone idee ed a liberarsi di cattive idee nella fase iniziale. Ulteriormente, un PDES può rimuovere la documentazione ed i carichi della raccolta di dati fornendo i mezzi automatizzati per questi scopi.

Egualmente fornisce un campo da giuoco affinchè gli ingegneri verifichi le loro idee in un ambiente virtuale di montaggio, fornente i modi esplorare più idee che precedentemente possibili. Un PDES dà ad una società un vantaggio competitivo trovando le migliori soluzioni e fornendo il più breve time to market. I concetti per PDES sono stati ricercati nella PASSEGGIATA di progetto di ricerca di UE (IST 507965) e sono diventato disponibili nel commercio come la serie di software di XperiDesk.


Riferimenti

1. J. Popp, D. Ortloff, A. Wagener. Contributo di Sviluppo a Progettazione di Processo di Fabbricazione. Nel Forum di GSA, Volume 15, Nessun 1, Marzo 2008.
2. A. Wagener, J. Popp K. Hahn, R. Brück; Ortloff, D.: Contributo Tenere La Carreggiata e di Progettazione Trattata a MEMS. In: Atti di SPIE: Tecnologia Della Trasformazione X, San José BD di Microfabbricazione e di Micromachining. 6109, 2006. - Fotonica 2006 Ad Ovest
3. D. Ortloff, F. Cooijmans.; B. Veenstra: Un Approccio Sistematico Verso Riproducibilità e Tenere La Carreggiata dello Sviluppo Trattato di MEMS. In: Atti della decima Conferenza Internazionale sulla Commercializzazione di Micro e Sistemi Nani, Baden-Baden, 2005. - COMS 2005
4. B. Veenstra, D. Ortloff, S. Langenhuisen: Un approccio per scambiare e generare conoscenza di Sviluppo Trattato di MEMS. In: Atti dell'undicesima Conferenza Internazionale sulla Commercializzazione di Micro e Sistemi Nani, San Pietroburgo, 2006. - COMS 2006

Copyright AZoNano.com, MANCEF.org

Date Added: Jul 12, 2010 | Updated: Jun 11, 2013

Last Update: 14. June 2013 01:28

Tell Us What You Think

Do you have a review, update or anything you would like to add to this article?

Leave your feedback
Submit