La Normativa Interforze sull Integrated Logistic Support NIILS SGD-G -018 I case studies

Transcript

1 Centro per la Formazione Logistica Interforze La Normativa Interforze sull Integrated Logistic Support NIILS SGD-G -018 I case studies Roma - CASD 8 maggio Mauro PERGOLESI

2 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

3 I CASE STUDY DELLA NIILS Le aree di analisi e verifica Gestione parti di ricambio Gestione Riparabili Gestione magazzini e depositi Trasporti/Imballi Gestione SUPPLY CHAIN Gestione Configurazione ENGINEERING SUPPORT FRACAS Manutenzione SW Analisi Disponibilità e Manutenibilità Feedback Sistema Principale Feedback sul Sistema di Supporto Pubblicazioni per manutenzione Addestramento Verifiche disponibilità On the Job Training Analisi dati dal campo Analisi livello p.r. Gestione Obsolescenze Analisi Supportabilità Radiazione Verifiche ambientali FIELD ENGINEERING Manutenzione preventiva Manutenzione correttiva Gestione cicli manutentivi 3/40

4 I CASE STUDY DELLA NIILS Visione d assieme -> avvio: marzo > presentazioni: apr > conclusione: 13 nov VERIFICARE L APPLICABILITA PRATICA DELLA NIILS IN CASI CONCRETI 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 VERIFICA UTILIZZO NIILS 4

5 I CASE STUDY DELLA NIILS CASE STUDY 5/40 EI MM AM COMPONENTE A.D. SME COMLOG EI TERRARM SGD - DPFNEC SMM NAVISPELOG NAVARM SMA COMLOG AM ARMAEREO COMPONENT E INDUSTRIA SELEX ELSAG SELEX GALILEO SELEX SISTEMI INTEGRATI SELEX SISTEMI INTEGRATI ALENIA AERMACCHI VITROCISET SISTEMA OPERATIVO SISTEMA SOLDATO FUTURO SISTEMA DI COMBATTIMENTO UNITÀ NAVALE AVANZATA EUROFIGHTER (EFA) TEMATICHE DI TEST FORMALIZZAZIONE DEI REQUISITI SCENARI OPERATIVI E LA LORO ALLOCAZIONE AI PARAMETRI PRESTAZIONALI. GESTIONE CONFIGURAZIONEONE. VISTE DI SISTEMA. ANALISI R&M. UID IL PROCESSO INTEGRATO DI SYSTEM ENGINEERING E ILS ENGINEERING. ALLOCAZIONE DEI REQUISITI OPERATIVI ALLA ARCHITETTURA DI SISTEMA ED AI PARAMETRI PRESTAZIONALI, CON GARANZIA DI TRACCIABILITÀ GESTIONE DELLA CONFIGURAZIONE CONFRONTO METODOLOGIA BY- BASELINE E BY ASD 2000M DATI DI RITORNO DAL CAMPO

6 CASE STUDY E.I. SISTEMA DI RIFERIMENTO PROGRAM MANAGEMENT ENTI A.D. PARTECIPANTI NIILS PROGRAM MANAGEMENT PROJECT MANAGEMENT DITTE PARTECIPANTI NIILS PROJECT MANAGEMENT SOLDATO FUTURO (FORZA NEC) SGD DIREZIONE DI PROGRAMMA FORZA NEC SME, COMOG EI, DZP FORZA NEC, DGAT SGD/DNA - VI REPARTO SELEX COMMS SELEX COMMS SELEX SISTEMI INTEGRATI SELEX GALILEO CAPO PROGETTO CONSORZIO CALS 6/40

7 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

8 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

9 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

10 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 ILS (Integrated Logistic Support), il Product Common Source Data Base (PCSDB). 10/40

11 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

12 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

13 I CASE STUDY DELLA NIILS CASE STUDY A.M. Scheda Progetto SISTEMA DI RIFERIMENTO PROGRAM MANAGEMENT ENTI A.D. PARTECIPANTI NIILS PROGRAM MANAGEMENT PROJECT MANAGEMENT: Sistema EFA ARMAEREO/COMLOG AM SMA, COMLOG AM, ARMAEREO SGD/DNA VI Reparto ALENIA Aeronautica DITTE PARTECIPANTI: ALENIA Team integrato con rappresentanze di Ingegneria ed ICT VITROCISET Team Sistemi Informativi Gestionali e Logistici NIILS PROJECT MANAGEMENT Capo Progetto Consorzio CALS 13/40

14 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

15 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 15/40 gestione integrata delle strutture di prodotto d interesse.

16 CASE STUDY E.I. CASE STUDY EI Il Soldato Futuro (SF) 16/40

17 CASE STUDY E.I. Fucile Arx 160 Individual Combat Weapon Sight Headset / Softwar Microphone e Defined Radio (+ GPS) VISORE NOTTURNO (NIMOS) Power Unit + Batteria Ricaricabile MASCHERA NBC Fire Control System Lanciagranate DDA Display Wearable Personal Computer GIUBBETTO AP ELMETTO INDUMENTO NBC UAB 17/40 Display Power Unit + Rechargeable Battery NATO NAAG AC/225 LCG/1 Working Group.

18 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

19 CASE STUDY E.I. Organizational Breakdown Structure PMO (Program Management Office) ILS Work Breakdown Structure Risorsa a WBE WBE WBE WBE 1.1 WBE WBE WBE 1 Soldato Futuro WBE 1.2 WBE WBE 2 WBE 1.3 IPT (Integrated Project Team) IPT 19/40 A.D. System DISCI- PLINA X DISCI- PLINA Y Risorsa b Risorsa c AMBIENTE DI LAVORO WEB BASED

20 CASE STUDY E.I. Nome Work Package WP1 WP2 WP3 WP4 WP5 WP6 20/40 Definizione degli Scenari Operativo e Logistico Identificazione del Sistema Operativo e delle sue Configurazioni Realizzazione delle Viste Funzionale, Prestazionale e Fisico- Funzionale Rapporto di Valutazione RAMS e definizione della Ao (disponibilità operativa) Realizzazione Vista IEPT-IPL-IPC e DMRL Reporting Deliverable Scenario operativo Vista gestione configurazione Viste funzionali prestazionali e fisico-funzionale Valutazione RAMS Vista IPL-IPC Vista IETP DMRL Sintesi del case study Workshop conclusivo

21 CASE STUDY M.M. CASE STUDY MM Sistema di Combattimento di Unità Navale 21/40

22 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

23 CASE STUDY M.M. WP 7 Layout Logico 23/40

24 CASE STUDY M.M. WP 7 Layout Logico 24/40

25 CASE STUDY M.M. Principali risultati ottenuti nell ambito del Case Study 25/40 Processo e Linguaggi di riferimento: Individuato il processo integrato ILS- SE; 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. 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

26 CASE STUDY A.M. CASE STUDY AM Velivolo Typhoon 26/40

27 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: larelazionefrastruttura 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

28 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

29 CASE STUDY A.M. Il Velivolo EF ha la capacità di interfacciarsi con la parte operativa e con la parte manutentiva mediante i tre sottosistemi di cui è dotato: Ground Support System 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à: 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 29/40» XCS Experience Capturing System

30 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

31 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

32 CASE STUDY A.M. Master Configuration SiLEF Configuration Management Sistema d Arma Codice MOI - MOV AGE Velivolo SBC Part Number - Descrizione Role equipment Nodo funzionale SBC Descrizione Nodo Funzionale SBC - Descrizione Nodo fisico Nodo fisico Nodo fisico Nodo fisico SBC Part Number - Descrizione Nodo fisico Nodo fisico SBC Part Number - Descrizione 32/40

33 CASE STUDY A.M. SiLEF Configuration Management Inserimento Serializzazione Sistema d Arma Velivolo MOI - MOV SBC Part Number - Descrizione + S/N Da tracciare SBC Part Number - Descrizione Nodo fisico Nodo fisico Nodo fisico + S/N Nodo fisico Nodo Fisico SBC Part Number - Descrizione Nodo fisico Da tracciare SBC Part Number - Descrizione Da tracciare + S/N + S/N SBC Part Number - Descrizione Nodo fisico Nodo fisico 33/40

34 CASE STUDY A.M. Struttura Baseline approccio Top Down (MIL-HDBL-61) 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

35 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 Design Baseline Product Baseline As Planned Baseline As Built Baseline As Delivered Baseline As Maintained Baseline CONCEPT ASSESSMENT DEMONSTRATIO N MANUFACTURE IN- SERVICE DISPOSAL As to be Maintained Baseline 35/40

36 CASE STUDY A.M. Baselines durante il ciclo di vita Design Direzione degli Armamenti Aeronautici Conf.Base In-Service Comando Logistico Mondo in cui vengono ACQUISITI i sistemi Mondo in cui vengono GESTITI i sistemi Design Baseline Product Baseline As to Be Maintained Baseline ASD 36/40

37 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

38 CASE STUDY A.M. I Dati di Prodotto presenti nei due documenti corrispondono a meno dei PNR non applicabili al livello manutentivo. DESIGN SERVICE IPL MOD Request for Alteration RFA Bill of 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

39 CASE STUDY A.M. BOM vs IPL/IPC Informazioni contenute Confronto BOM con Struttura ASD S2000M BOM Ultima istantanea delle modifiche applicate Evoluzione di tutte le modifiche applicate NO EVOLUZIONE Non c è visibilità dell evoluzione del sistema / prodotto in funzione delle modifiche, ma l ultima configurazione applicabile SI EVOLUZIONE C è visibilità dell evoluzione del sistema / prodotto in funzione delle modifiche applicabili 39/40

40 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

41 Centro per la Formazione Logistica Interforze Domande? 41/49