Centro per la Formazione Logistica Interforze La Normativa Interforze sull’Integrated Logistic Support NIILS – SGD-G -018 I case studies Roma - CASD – 8 maggio 2014 Mauro PERGOLESI Agenda • Aree di analisi e verifica • I “case study” della NIILS • Case Study E.I. • Case Study M.M. • Case Study A.M. 2/40 Mauro Pergolesi 2014 I CASE STUDY DELLA NIILS Le aree di analisi e verifica Gestione parti di ricambio Gestione Riparabili Gestione magazzini e depositi Trasporti/Imballi Verifiche disponibilità On the Job Training Analisi dati dal campo Analisi livello p.r. Gestione Obsolescenze Analisi Supportabilità Radiazione Verifiche ambientali 3/40 Mauro Pergolesi 2014 Gestione SUPPLY CHAIN ENGINEERING SUPPORT FRACAS Manutenzione SW Analisi Disponibilità e Manutenibilità Feedback Sistema Principale Feedback sul Sistema di Supporto Pubblicazioni per manutenzione Addestramento Gestione Configurazione FIELD ENGINEERING Manutenzione preventiva Manutenzione correttiva Gestione cicli manutentivi I CASE STUDY DELLA NIILS Visione d’assieme -> avvio: marzo 2011 -> presentazioni: apr. 2012 VERIFICARE L’APPLICABILITA’ PRATICA DELLA NIILS IN CASI CONCRETI -> conclusione: 13 nov. 2012 PROMOSSO DA SGD/DNA SU RICHIESTA GRUPPO CALS Case Study MM Case Study EI Case Study AM PROTOCOLLO INTESA TRA DIFESA (SGD) E INDUSTRIA (CALS ITALIA) GESTIONE SGD CON TEAM TECNICI F.A. E D.G. 4/40 Mauro Pergolesi 2014 VERIFICA UTILIZZO NIILS 4 I CASE STUDY DELLA NIILS CASE STUDY COMPONENTE A.D. COMPONENT E INDUSTRIA SISTEMA OPERATIVO TEMATICHE DI TEST SISTEMA SOLDATO FUTURO FORMALIZZAZIONE DEI REQUISITI SCENARI OPERATIVI E LA LORO ALLOCAZIONE AI PARAMETRI PRESTAZIONALI. GESTIONE CONFIGURAZIONEONE . VISTE DI SISTEMA. ANALISI R&M. UID SELEX ELSAG EI MM AM SME COMLOG EI TERRARM SGD - DPFNEC SMM NAVISPELOG NAVARM SMA COMLOG AM ARMAEREO 5/40 Mauro Pergolesi 2014 SELEX GALILEO SELEX SISTEMI INTEGRATI IL PROCESSO INTEGRATO DI SYSTEM ENGINEERING E ILS SISTEMA DI ENGINEERING. ALLOCAZIONE DEI SELEX SISTEMI COMBATTIMENTO REQUISITI OPERATIVI ALLA INTEGRATI UNITÀ NAVALE ARCHITETTURA DI SISTEMA ED AI AVANZATA PARAMETRI PRESTAZIONALI, CON GARANZIA DI TRACCIABILITÀ ALENIA AERMACCHI VITROCISET EUROFIGHTER (EFA) GESTIONE DELLA CONFIGURAZIONE CONFRONTO METODOLOGIA BYBASELINE E BY ASD 2000M DATI DI RITORNO DAL CAMPO CASE STUDY E.I. SISTEMA DI RIFERIMENTO SOLDATO FUTURO (FORZA NEC) PROGRAM MANAGEMENT SGD – DIREZIONE DI PROGRAMMA “FORZA NEC” ENTI A.D. PARTECIPANTI SME, COMOG EI, DZP “FORZA NEC”, DGAT NIILS PROGRAM MANAGEMENT SGD/DNA - VI REPARTO PROJECT MANAGEMENT SELEX COMMS DITTE PARTECIPANTI SELEX COMMS – SELEX SISTEMI INTEGRATI SELEX GALILEO NIILS PROJECT MANAGEMENT CAPO PROGETTO CONSORZIO CALS 6/40 Mauro Pergolesi 2014 CASE STUDY E.I. Obiettivi NELL’AMBITO DELL’OBIETTIVO DEL PROGETTO, IL CASE STUDY Soldato Futuro SI CONCENTRA SU: – REQUISITI RELATIVI A SCENARI OPERATIVI, SISTEMA D’ARMA, SUPPORTO LOGISTICO – GESTIONE DELLA CONFIGURAZIONE – VISTE DI SISTEMA – ANALISI R&M – UID 7/40 Mauro Pergolesi 2014 CASE STUDY E.I. La documentazione del processo acquisitivo ad oggi disponibile del Soldato Futuro, non contiene tutti gli elementi d’informazione caratterizzanti l’approccio ad ampio spettro lungo l’intero ciclo di vita del sistema, a cui la NIILS, invece induce a pensare. Occorre, quindi, pensare come il sistema in acquisizione verrà impiegato, mantenuto e posto fuori servizio/alienato nel corso della sua vita utile, già in fase concettuale, cioè quando l’esigenza operativa (EO) derivante dalla Pianificazione Generale della Difesa, individua il tipo di prodotto che può soddisfarla, in modo da poter, già nel corso della progettazione scegliere soluzioni orientate a garantire non solo le prestazioni di efficacia ma anche quelle di affidabilità e manutenibilità che possano rendere il sistema realmente “disponibile” 8/40 Mauro Pergolesi 2014 CASE STUDY M.M. Scheda Progetto SISTEMA DI RIFERIMENTO: Sistema di Combattimento di Unità Navale PROGRAM MANAGEMENT: NAVARM ENTI AD PARTECIPANTI: SMM; NAVISPELOG; NAVARM NIILS PROGRAM MANAGEMENT: SGD/DNA VI Reparto PROJECT MANAGEMENT: SELEX Sistemi Integrati EEOO SELEX-SI COINVOLTI: BUSD; CS; BD; AQ; ICT NIILS PROJECT MANAGEMENT: Consorzio CALS 9/40 Mauro Pergolesi 2014 CASE STUDY M.M. Obiettivi Case Study Marina Militare ha per obiettivo la verifica del livello di applicazione della normativa NIILS relativamente al processo di acquisizione di un generico Sistema di Combattimento (SdC) per una Unità Navale. Il dominio di valutazione copre tutti gli elementi fondamentali sui quali si basa la normativa NIILS: • il Program Management Office (PMO), • il Processo Support), • il Product (PCSDB). 10/40 Mauro Pergolesi 2014 ILS Common (Integrated Source Logistic Data Base CASE STUDY M.M. Obiettivi specifici a.Caratterizzazione architetturale del Sistema di Combattimento nell’ambito del sistema “Unità Navale” a partire dai Requisiti Operativi b.Estrarre la vista prestazionale derivante dalla documentazione di progetto funzionale ed architetturale c.Identificare linguaggi formali e standard, idonei alla integrazione delle attività di System Engineering e di Logistics Engineering, per la definizione, allocazione e tracciamento dei requisiti e la progettazione funzionale d.Individuare possibili modalità per legare la modellazione di sistema alla modellazione della disponibilità operativa per attuare il TLM (Through Life Management) e.Sperimentare l’integrazione sistemistica ed informatica delle viste di prodotto definite dalla NIILS 11/40 Mauro Pergolesi 2014 CASE STUDY M.M. Conclusioni • L’approccio Model Driven al Processo Integrato ILS-System Enginnering si è dimostrato efficace ed efficiente per l’Individuazione delle relazioni tra le varie fasi del processo e la conseguente realizzazione di un unico modello dati di Viste NIILS Integrate • E’ stata sperimentata la validità del System Modelling all’interno del Case Study in accordo ai requisiti NIILS • Il PCSDB è realizzabile con soluzioni coerenti con i processi e gli strumenti già in essere nelle industrie e nella Difesa (vedasi Sistemi Informativi per la gestione in esercizio del EI, della MM e della AM). Individuata una potenziale soluzione del PCSDB del tipo Product Lifecycle Management (PLM) light • La “System effectivness” del Sistema Operativo può essere Valutata tramite strumenti di elaborazione di dati e relazioni presenti all’interno del modello Integrato di sistema (FMECA Funzionale) 12/40 Mauro Pergolesi 2014 I CASE STUDY DELLA NIILS CASE STUDY A.M. Scheda Progetto SISTEMA DI RIFERIMENTO Sistema EFA PROGRAM MANAGEMENT ARMAEREO/COMLOG AM ENTI A.D. PARTECIPANTI SMA, COMLOG AM, ARMAEREO NIILS PROGRAM MANAGEMENT SGD/DNA VI Reparto PROJECT MANAGEMENT: ALENIA Aeronautica DITTE PARTECIPANTI: ALENIA Team integrato con rappresentanze di Ingegneria ed ICT VITROCISET Team Sistemi Informativi Gestionali e Logistici NIILS PROJECT MANAGEMENT 13/40 Mauro Pergolesi 2014 Capo Progetto Consorzio CALS CASE STUDY A.M. Obiettivi • Verificare l’attuale modalità di scambio dati tra Utilizzatore e Ditta Fornitrice secondo quanto previsto dalla NIILS • Verificare la metodologia applicata attraverso l’analisi dati “In Servizio” su casi reali e tracciabili • Verificare la rispondenza del Sistema Informativo della F.A. sia in riferimento alla NIILS, sia in riferimento alla specifiche ASD 14/40 Mauro Pergolesi 2014 CASE STUDY A.M. Conclusioni Il Caso di Studio ha prodotto i seguenti risultati classificabili in: - Dati: le due strutture Dati di Prodotto sono relazionabili, a meno di prevedere la gestione dei dati aggregati di configurazione alla base della navigazione “Configurata” tra le strutture prodotte. - Processi: le impostazioni dei sottoprocessi dell’Acquisizione Logistica, così come enunciate nella NIILS, si confermano valide ed integrabili in un unico processo di Gestione Integrata della Configurazione di Prodotto. - Contesto Normativo: pur rimanendo valide le diversificate esigenze di strutturazione dati per i singoli sottoprocessi del’Acquisizione Logistica, si avverte la necessità di una continuità di gestione del dato di configurazione lungo tutto il ciclo di vita. Necessità che andrebbe espressa all’interno di una Normativa di Configurazione Through Life Cycle sotto forma di requisito improntato alla gestione integrata delle strutture di prodotto d’interesse. 15/40 Mauro Pergolesi 2014 CASE STUDY E.I. CASE STUDY EI Il Soldato Futuro (SF) 16/40 Mauro Pergolesi 2014 CASE STUDY E.I. •Fucile Arx 160 •Power Unit + Batteria •Ricaricabile •Headset / •Softwar•Microphone e Defined Radio •(+ GPS) •Individual Combat Weapon Sight •VISORE NOTTURNO (NIMOS) •MASCHERA NBC •Fire Control •System •DDA •Display •Wearable •Personal • Computer •Lanciagranate •UAB •Display 17/40 Mauro Pergolesi 2014 •NATO •Power Unit + Rechargeable •Battery NAAG AC/225 LCG/1 Working Group. •GIUBBETTO AP •INDUMENTO NBC •ELMETTO CASE STUDY E.I. •Tra le varie possibili configurazioni si è deciso di far riferimento alla squadra di fanteria media così composta: • • • • • n. 1 C.te di squadra n. 1 Vice C.te di Squadra n. 4 fucilieri n. 2 granatieri n. 3 equipaggio VBM “Freccia” (non considerati ai fini dell’esercizio) 18/40 Mauro Pergolesi 2014 CASE STUDY E.I. •Work Breakdown Structure •Organizational •Breakdown •Structure •WBE 1.1.2.1 •PMO •(Program Management Office) •ILS •IPT •A.D. •System 19/40 Mauro Pergolesi 2014 • Risorsa a •DISCI•PLINA X •DISCI•PLINA Y •Soldato •Futuro •WBE •1 •WBE 2 •WBE 1.1 •WBE 1.2 •WBE 1.1.1 •WBE 1.1.2 •WBE 1.1.3 •WBE 1.1.2.2 •WBE 1.1.2.3 •WBE 1.3 IPT (Integrated Project Team) •Risorsa b AMBIENTE DI LAVORO WEB BASED •Risorsa c CASE STUDY E.I. Nome Work Package Definizione degli Scenari Operativo WP1 e Logistico Identificazione del Sistema WP2 Operativo e delle sue Configurazioni Realizzazione delle Viste WP3 Funzionale, Prestazionale e FisicoFunzionale Rapporto di Valutazione RAMS e WP4 definizione della Ao (disponibilità operativa) Deliverable Scenario operativo Vista gestione configurazione Viste funzionali prestazionali e fisico-funzionale Valutazione RAMS WP5 Realizzazione Vista IEPT-IPL-IPC e DMRL Vista IPL-IPC Vista IETP DMRL WP6 Reporting Sintesi del case study Workshop conclusivo 20/40 Mauro Pergolesi 2014 CASE STUDY M.M. CASE STUDY MM Sistema di Combattimento di Unità Navale 21/40 Mauro Pergolesi 2014 CASE STUDY M.M. I WP del Case Study • Work Package 1 e Work Package 2 definizione e analisi del Requisito Operativo di un “Sistema di Combattimento di Unità Navale” Work Package 3 e Work Package 4 • presentazione del processo integrato di System EngineeringeIntegrated Logistic Support(ILS) Engineering, che fornisce all‟Industria e all‟Amministrazione Difesa le metodologie e i modelli per coprire l’intero Ciclo di Vita di un Sistema Operativo, definendo relazioni tra il progetto di un Sistema(in termini di design architetturale,analisi funzionale, etc.) e informazioni e dati attinenti il Supporto Logistico Work • Package 5 relazione tra i task manutentivi, necessari a ripristinare la corretta funzionalità del Sistema Operativo, con le procedure diagnostiche e manutentive delle pubblicazioni tecniche Work Package 6 • • analisi FMECA e correlazione tra i dati FMECA e la vista prestazionale Work Package7 processo generale del Configuration e Data Management e iniziative di miglioramento in base alle opportunità tecnologiche ed alle esigenze operative (supporto ai processo aziendali) standard internazionali integrazione di sistemi (SOA) 22/40 Mauro Pergolesi 2014 CASE STUDY M.M. WP 7 – Layout Logico 23/40 Mauro Pergolesi 2014 CASE STUDY M.M. WP 7 – Layout Logico 24/40 Mauro Pergolesi 2014 CASE STUDY M.M. Principali risultati ottenuti nell’ambito del Case Study Processo e Linguaggi di riferimento: Individuato il processo integrato ILSSE; definite le regole di modellizzazione per la Vista Logistica per la realizzazione delle viste NIILS Integrate per la sperimentazione del modello PCSDB Viste NIILS integrate: Realizzato il modello di viste di sistema integrate Relazionati i task manutentivi con gli IETP: definito e descritto approccio e metodologia Valutazione Efficacia di Sistema: Individuate le regole di modellizzazione per l’analisi FMECA a livello C/S e di S/S e l’allocazione alla Vista Funzionale. Definito l’approccio FMECA al livello di S/S per la determinazione della efficacia di sistema. 25/40 PCSDB: Individuata una possibile proposta operativa per la realizzazione del PCSDB. Individuato il processo di condivisione dati e la relativa tool chain integrata. Definito un esempio di struttura dei file di interscambio per la condivisione dei dati. Definito l’approccio al PCSDB Mauro Pergolesi 2014 CASE STUDY A.M. CASE STUDY AM Velivolo Typhoon 26/40 Mauro Pergolesi 2014 CASE STUDY A.M. Casi di Studio L’attività è stata svolta prendendo a riferimento il Sistema Operativo Eurofighter analizzando le seguenti tematiche: Gestione della Configurazione: la relazione fra struttura di prodotto per baseline e la struttura ASD S2000M Ritorni dal campo: metodologia e dati per la valutazione delle prestazioni In-Service di un Sistema Operativo oggetto di Acquisizione Logistica 27/40 Mauro Pergolesi 2014 CASE STUDY A.M. Il Supporto Logistico • GSS : è il sistema informativo dedicato Ground Support System per l’Eurofighter , in grado di soddisfare i requisiti espressi dal Cliente (NETMA). Esso è costituito da tre sottosistemi: – Mission Support System (MSS), – Engineering Support System (ESS) – Ground Loading Unit (GLU) • SiLEF : è il sistema informativo dell’Aeronautica Militare Italiana per il supporto logistico dell’A.M. 28/40 Mauro Pergolesi 2014 CASE STUDY A.M. Ground Support System Il Velivolo EF ha la capacità di interfacciarsi con la parte operativa e con la parte manutentiva mediante i tre sottosistemi di cui è dotato: Parte operativa: MSS: peculiare del pilota. In esso lo stesso pianifica, fa il briefing e il debriefing della missione GLU: è l’interfaccia con il velivolo per caricare il SW e i dati di missione. Parte manutentiva: ESS: è stato progettato per avere le seguenti capacità: 29/40 Mauro Pergolesi 2014 PMDS – Portable Maintenance Data Store » RIU – Re-Configurable Interface Unit » ASH - Aircraft System Health » EHM – Engine Health Monitoring » SHM – Structural Health Monitoring » SPS -Secondary Power System Health Monitoring » EFLogSW – Eurofighter Logistics Software Packages » IETP – Browser » XCS – Experience Capturing System CASE STUDY A.M. •SiLEF : è il sistema informativo •dell’Aeronautica Militare Italiana per il supporto logistico dell’A.M. • Utilizzo di tecnologia allo stato dell’arte • Alta disponibilità ed affidabilità • Alto grado di integrazione funzionale • Facilità di interfacciamento con altri sistemi I.T. • Compatibilità Standard ASD 30/40 Mauro Pergolesi 2014 CASE STUDY A.M. SiLEF – Configuration Management • Consente il controllo dell’evoluzione del sistema d’arma gestendo la configurazione dell’intera flotta anche tramite l’interfacciamento con i sottosistemi informativi internazionali (per l’EFA) già esistenti e/o in corso di sviluppo/rilascio (IWSSS, ISSS, GSS/ESS) o con i sistemi informativi (per il Tornado) di Alenia (CRM-ILS) e Avio (ISIS) • Consente il tracciamento delle modifiche tecniche apportate • Consente la gestione delle strutture master velivolo e dei principali componenti strutturati (configurazioni ammissibili) • Consente la Gestione delle configurazioni delle singole Matricole Militari velivolo e dei S/N dei principali componenti strutturati (Serializzazione) • Consente la Gestione delle modifiche tecniche 31/40 Mauro Pergolesi 2014 CASE STUDY A.M. SiLEF – Configuration Management •Master Configuration •Codice MOI - MOV •Sistema d’Arma •AGE •Velivolo •Role equipment •SBC – Part Number - Descrizione •Nodo funzionale •Nodo Funzionale •SBC – Descrizione •Nodo fisico •SBC - Descrizione •Nodo fisico •Nodo fisico •Nodo fisico •SBC – Part Number - Descrizione •Nodo fisico 32/40 Mauro Pergolesi 2014 •Nodo fisico •SBC – Part Number - Descrizione CASE STUDY A.M. SiLEF – Configuration Management •Inserimento Serializzazione •MOI - MOV •Sistema d’Arma •SBC – Part Number - Descrizione •+ S/N •Velivolo •SBC – Part Number - Descrizione •Nodo fisico •Da tracciare •SBC – Part Number - Descrizione •+ S/N •Nodo Fisico •+ S/N •Da tracciare •SBC – Part Number - Descrizione •+ S/N •Nodo fisico •Nodo fisico •Nodo fisico •Nodo fisico •Da tracciare •SBC – Part Number - Descrizione •Nodo fisico 33/40 Mauro Pergolesi 2014 •Nodo fisico CASE STUDY A.M. Struttura Baseline – approccio Top Down Configuration Baseline è una configurazione di riferimento prefissata ottenuta definendo e registrando la documentazione di configurazione approvata per un sistema o per un articolo di configurazione in un momento definito o contestualmente ad un evento significativo e rappresenta l’immagine istantanea che cattura la configurazione o la configurazione parziale di un CI in un momento specifica Punti di verifica di commessa che rappresentano l’approvazione di un CI in un particolare momento definito durante la fase di sviluppo Punti di controllo che hanno lo scopo di focalizzare l’attenzione del management 34/40 Mauro Pergolesi 2014 (MIL-HDBL-61) CASE STUDY A.M. Baselines durante il Ciclo di Vita DEF STAN 05-57/4 Il processo di Gestione della Configurazione comporta la definizione di una serie di baseline in linea con la Configurazione di Riferimento di Prodotto (PBL) La Requirements baseline (RBL) nella fase concettuale del sistema viene poi seguita dalla Functional Baseline (FBL) durante la definizione ed il rilascio della Design (Development or Allocated) Baseline (DBL) durante la fase di dimostrazione Requirements Baseline Functional Baseline CONCEPT ASSESSMENT Design Baseline Product Baseline •DEMONSTRATIO N As Planned Baseline •MANUFACTURE As to be Maintained Baseline 35/40 Mauro Pergolesi 2014 As Built Baseline As Delivered Baseline •INSERVICE As Maintained Baseline DISPOSAL CASE STUDY A.M. Baselines durante il ciclo di vita Direzione degli Armamenti Aeronautici •Comando Logistico Conf.Base Design •Mondo in cui vengono •ACQUISITI •i sistemi In-Service •Mondo in cui vengono •GESTITI •i sistemi • As to Be Maintained Baseline • Design Baseline • Product Baseline 36/40 Mauro Pergolesi 2014 • ASD CASE STUDY A.M. Struttura ASD – approccio Bottom Up ASD S2000M L’ottica è focalizzata sulle “parti” attraverso la definizione di una IPL – Initial Provisioning List che viene compilata secondo una logica del breakdown ingegneristico del prodotto in una sequenza di disassemblaggio o scomposizione, che identifica tutti gli assiemi ed i loro componenti, unitamente a tutte le altre parti che non possono essere associate ad assiemi. La sequenza con la quale gli articoli vengono individuati viene contraddistinta da Catalogue Sequence Number (CSN). I dati di Initial Provisioning che hanno rilevanza ai fini della Gestione di configurazione sono rappresentati da : Model Version (MOV) Pre/Post Mod indicator (CAN) Range di Effectivity (EFY) Interchangeability Code (ICY) Usable Code (UOCA/UOCE) 37/40 Mauro Pergolesi 2014 CASE STUDY A.M. I Dati di Prodotto presenti nei due documenti corrispondono a meno dei PNR non applicabili al livello manutentivo. SERVICE DESIGN IPL •MOD Request for Alteration RFA Bill off Material BOM Non c’è perfetta corrispondenza tra i dati IPL/IPC e quelli di design, perché L’IPL contiene dati relativamente ai soli item di interesse logistico, non a tutti gli item che compongono il prodotto. 38/40 Mauro Pergolesi 2014 CASE STUDY A.M. Confronto BOM con Struttura ASD S2000M BOM vs IPL/IPC Informazioni contenute •BOM Ultima “istantanea” delle modifiche applicate “Evoluzione” di tutte le modifiche applicate NO EVOLUZIONE SI EVOLUZIONE Non c’è visibilità dell’evoluzione del sistema / prodotto in funzione delle modifiche, ma l’ultima configurazione applicabile C’è visibilità dell’evoluzione del sistema / prodotto in funzione delle modifiche applicabili 39/40 Mauro Pergolesi 2014 CASE STUDY A.M. Confronto BOM con Struttura ASD S2000M Nelle BOM ci sono informazioni post modifica allineate rispetto all’ordine delle modifiche introdotte, mentre nella IPL/IPC sono riportati tutte le evoluzioni a partire dalla Configuration Base É Possibile confrontare, quindi, una BOM con la IPL/IPC filtrata con i soli riferimenti post-modifica relativi. In questo caso i dati di prodotto corrispondono a meno dei PNR non applicabili al livello manutentivo. Viceversa per confrontare l’IPL/IPC completa dovrei sommare le informazioni contenute nelle BOM non riportando le duplicazioni. I dati necessari da gestire per permettere tale confronto sono l’insieme di dati di Design gestiti nelle Modifiche, nelle RFA e nelle BOM 40/40 Mauro Pergolesi 2014 Centro per la Formazione Logistica Interforze Domande? 41/49
© Copyright 2024 Paperzz
