La Normativa Interforze sull’Integrated Logistic Support ......6/40 sistema di riferimento soldato futuro (forza nec) project management selex comms program management sgd – direzione

Mauro PERGOLESI

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 -

2/40

Agenda

• Aree di analisi e verifica

• I “case study” della NIILS

• Case Study E.I.

• Case Study M.M.

• Case Study A.M.

Mauro Pergolesi 2014

3/40

FIELD ENGINEERING

Gestione SUPPLY CHAIN

GestioneConfigurazione

ENGINEERING SUPPORT

Verifiche disponibilità On the Job TrainingAnalisi dati dal campoAnalisi livello p.r.Gestione ObsolescenzeAnalisi SupportabilitàRadiazioneVerifiche ambientali

Gestione parti di ricambio Gestione RiparabiliGestione magazzini edepositiTrasporti/Imballi

Manutenzione preventivaManutenzione correttivaGestione cicli manutentivi

FRACASManutenzione SWAnalisi Disponibilità e ManutenibilitàFeedback Sistema Principale Feedback sul Sistema di SupportoPubblicazioni per manutenzioneAddestramento

Le aree di analisi e verifica

I CASE STUDY DELLA NIILS


VERIFICA UTILIZZONIILS

Case Study

AM

Case Study

MM

Case Study

EI

VERIFICARE L’APPLICABILITA’ PRATICA DELLA NIILS IN CASI CONCRETI

PROMOSSO DA SGD/DNA SU RICHIESTA GRUPPO CALS

PROTOCOLLO INTESA TRA DIFESA (SGD) E INDUSTRIA (CALS ITALIA)

GESTIONE SGD CON TEAM TECNICI F.A. E D.G.

-> avvio: marzo 2011

-> presentazioni: apr. 2012

-> conclusione: 13 nov. 2012


Visione d’assieme


44/40

CASE STUDY

COMPONENTE A.D.

COMPONENTE INDUSTRIA

SISTEMA OPERATIVO TEMATICHE DI TEST

EI SME

COMLOG EITERRARM

SGD - DPFNEC

SELEX ELSAG

SELEX GALILEO

SELEX SISTEMI INTEGRATI

SISTEMA SOLDATO FUTURO

FORMALIZZAZIONE DEI REQUISITI SCENARI OPERATIVI E LA LORO

ALLOCAZIONE AI PARAMETRI PRESTAZIONALI. GESTIONE

CONFIGURAZIONEONE . VISTE DI SISTEMA. ANALISI R&M. UID

MM SMM

NAVISPELOGNAVARM

SELEX SISTEMI INTEGRATI

SISTEMA DICOMBATTIMENTO

UNITÀ NAVALE AVANZATA

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À

AM SMA

COMLOG AMARMAEREO

ALENIA AERMACCHI

VITROCISET

EUROFIGHTER (EFA)

GESTIONE DELLA CONFIGURAZIONE CONFRONTO METODOLOGIA BY-

BASELINE E BY ASD 2000M

DATI DI RITORNO DAL CAMPO


Mauro Pergolesi 20145/40

6/40

SISTEMA DI RIFERIMENTO SOLDATO FUTURO (FORZA NEC)

PROJECT MANAGEMENT SELEX COMMS

PROGRAM MANAGEMENT SGD – DIREZIONE DI PROGRAMMA “FORZA NEC”

ENTI A.D. PARTECIPANTI SME, COMOG EI, DZP “FORZA NEC”, DGAT

DITTE PARTECIPANTI SELEX COMMS – SELEX SISTEMI INTEGRATI SELEX GALILEO

NIILS PROJECT MANAGEMENT CAPO PROGETTO CONSORZIO CALS

NIILS PROGRAM MANAGEMENT SGD/DNA - VI REPARTO

CASE STUDY E.I.


7/40

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

Obiettivi

CASE STUDY E.I.


La documentazione del processo acquisitivo ad oggidisponibile del Soldato Futuro, non contiene tutti glielementi d’informazione caratterizzanti l’approccio adampio spettro lungo l’intero ciclo di vita del sistema, acui la NIILS, invece induce a pensare.

La documentazione del processo acquisitivo ad oggidisponibile del Soldato Futuro, non contiene tutti glielementi d’informazione caratterizzanti l’approccio adampio spettro lungo l’intero ciclo di vita del sistema, acui la NIILS, invece induce a pensare.

Occorre, quindi, pensare come il sistema in acquisizione verràimpiegato, mantenuto e posto fuori servizio/alienato nel corsodella sua vita utile, già in fase concettuale, cioè quando l’esigenzaoperativa (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 agarantire non solo le prestazioni di efficacia ma anche quelle diaffidabilità e manutenibilità che possano rendere il sistemarealmente “disponibile”

Occorre, quindi, pensare come il sistema in acquisizione verràimpiegato, mantenuto e posto fuori servizio/alienato nel corsodella sua vita utile, già in fase concettuale, cioè quando l’esigenzaoperativa (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 agarantire non solo le prestazioni di efficacia ma anche quelle diaffidabilità e manutenibilità che possano rendere il sistemarealmente “disponibile”

CASE STUDY E.I.

8/40Mauro Pergolesi 2014

SISTEMA DI RIFERIMENTO: Sistema di Combattimento di Unità Navale

PROGRAM MANAGEMENT: NAVARM

ENTI AD PARTECIPANTI: SMM; NAVISPELOG; NAVARM

EEOO SELEX-SI COINVOLTI: BUSD; CS; BD; AQ; ICT

NIILS PROGRAM MANAGEMENT: SGD/DNA VI Reparto

PROJECT MANAGEMENT: SELEX Sistemi Integrati

NIILS PROJECT MANAGEMENT: Consorzio CALS

Scheda Progetto

CASE STUDY M.M.


10/40

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 elementifondamentali sui quali si basa la normativa NIILS:

• il Program Management Office (PMO),

• il Processo ILS (Integrated LogisticSupport),

• il Product Common Source Data Base(PCSDB).

Obiettivi

CASE STUDY M.M.


Obiettivi specificia.Caratterizzazione architetturale del Sistema di

Combattimento nell’ambito del sistema “Unità Navale” a partiredai Requisiti Operativi

b.Estrarre la vista prestazionale derivante dalladocumentazione di progetto funzionale ed architetturale

c.Identificare linguaggi formali e standard, idonei allaintegrazione delle attività di System Engineering e di LogisticsEngineering, per la definizione, allocazione e tracciamento deirequisiti e la progettazione funzionale

d.Individuare possibili modalità per legare la modellazione disistema alla modellazione della disponibilità operativa perattuare il TLM (Through Life Management)

e.Sperimentare l’integrazione sistemistica ed informatica delleviste di prodotto definite dalla NIILS

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)

CASE STUDY M.M.


13/40

SISTEMA DI RIFERIMENTO Sistema EFA

PROJECT MANAGEMENT: ALENIA Aeronautica

PROGRAM MANAGEMENT ARMAEREO/COMLOG AM

ENTI A.D. PARTECIPANTI SMA, COMLOG AM, ARMAEREO

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

NIILS PROGRAM MANAGEMENT SGD/DNA VI Reparto

I CASE STUDY DELLA NIILSCASE STUDY A.M.Scheda Progetto


• 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

Obiettivi

CASE STUDY A.M.


Il Caso di Studio ha prodotto i seguenti risultati classificabili in:

- Dati: le due strutture Dati di Prodotto sono relazionabili, a meno di prevedere lagestione dei dati aggregati di configurazione alla base della navigazione“Configurata” tra le strutture prodotte.

- Processi: le impostazioni dei sottoprocessi dell’Acquisizione Logistica, così comeenunciate nella NIILS, si confermano valide ed integrabili in un unico processo diGestione Integrata della Configurazione di Prodotto.

- Contesto Normativo: pur rimanendo valide le diversificate esigenze distrutturazione dati per i singoli sottoprocessi del’Acquisizione Logistica, si avvertela necessità di una continuità di gestione del dato di configurazione lungo tutto ilciclo di vita. Necessità che andrebbe espressa all’interno di una Normativa diConfigurazione Through Life Cycle sotto forma di requisito improntato allagestione integrata delle strutture di prodotto d’interesse.

Conclusioni

CASE STUDY A.M.


CASE STUDY EIIl Soldato Futuro (SF)

CASE STUDY E.I.


•Power Unit + Batteria•Ricaricabile

•Display

•Individual Combat Weapon Sight

•Wearable•Personal• Computer

•Software Defined Radio•(+ GPS)

•Display

•Headset /•Microphone

•Power Unit + Rechargeable•Battery

•DDA

•GIUBBETTO AP•INDUMENTO NBC

•MASCHERA NBC

•VISORE NOTTURNO (NIMOS)

•ELMETTO

•Fucile Arx 160

•UAB

•Lanciagranate

•Fire Control •System

•NATO NAAG AC/225 LCG/1 Working Group.

CASE STUDY E.I.


•Tra le varie possibili configurazioni si è deciso di far riferimento alla squadradi 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)

CASE STUDY E.I.


•WBE 1.1

•Soldato•Futuro

•WBE 2

•WBE•1

•WBE 1.3

•WBE 1.2

•WBE 1.1.2

•WBE 1.1.1

•WBE 1.1.2.3

•WBE 1.1.2.2

•WBE 1.1.2.1

• Risorsa a

•Risorsa b

•Risorsa c

•ILS

•IPT

•DISCI-•PLINA Y

•Organizational•Breakdown•Structure

•A.D.

•System

•DISCI-•PLINA X

•WBE 1.1.3

•Work Breakdown Structure

IPT (IntegratedProject Team)

AMBIENTE DI LAVORO WEB BASED

•PMO•(Program Management Office)

CASE STUDY E.I.


Nome Work Package Deliverable

WP1 Definizione degli Scenari Operativo e Logistico Scenario operativo

WP2 Identificazione del Sistema Operativo e delle sue Configurazioni

Vista gestione configurazione

WP3 Realizzazione delle Viste Funzionale, Prestazionale e Fisico-Funzionale

Viste funzionali prestazionali e fisico-funzionale

WP4 Rapporto di Valutazione RAMS e definizione della Ao (disponibilità operativa)

Valutazione RAMS

WP5 Realizzazione Vista IEPT-IPL-IPC e DMRL

Vista IPL-IPCVista IETPDMRL

WP6 Reporting Sintesi del case studyWorkshop conclusivo

CASE STUDY E.I.


21/40

CASE STUDY M.M.

CASE STUDY MMSistema di Combattimento di

Unità Navale


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 prestazionaleWork 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)

CASE STUDY M.M.


WP 7 – Layout Logico

CASE STUDY M.M.


WP 7 – Layout Logico

CASE STUDY M.M.


Principali risultati ottenuti nell’ambito del Case Study

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

CASE STUDY M.M.


26/40

CASE STUDY AMVelivolo Typhoon

CASE STUDY A.M.


Casi di StudioL’attività è stata svolta prendendo a riferimento ilSistema Operativo Eurofighter analizzando le seguentitematiche:

Gestione della Configurazione: la relazione fra strutturadi prodotto per baseline e la struttura ASD S2000M

Ritorni dal campo: metodologia e dati per la valutazionedelle prestazioni In-Service di un Sistema Operativooggetto di Acquisizione Logistica

CASE STUDY A.M.


• GSS : è il sistema informativo dedicato Ground SupportSystem 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.

Il Supporto Logistico

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:

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 idati 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

» XCS – Experience Capturing System

Ground Support System

CASE STUDY 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

•SiLEF : è il sistema informativo •dell’Aeronautica Militare Italiana per il supporto logistico dell’A.M.

CASE STUDY A.M.


• Consente il controllo dell’evoluzione del sistema d’arma gestendola configurazione dell’intera flotta anche tramitel’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 ilTornado) 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

SiLEF – Configuration Management

CASE STUDY A.M.


•Master Configuration•Sistema d’Arma •Codice MOI - MOV

•Nodo funzionale

•Velivolo

•Nodo Funzionale

•SBC – Part Number - Descrizione

•Nodo fisico

•Nodo fisico

•Nodo fisico

•Nodo fisico

•SBC - Descrizione•SBC – Descrizione

•Nodo fisico

•Nodo fisico



•Role equipment•AGE


CASE STUDY A.M.



•Inserimento Serializzazione•Sistema d’Arma

•MOI - MOV

•Nodo fisico

•Velivolo

•Nodo Fisico


•Nodo fisico

•Nodo fisico

•Nodo fisico

•Nodo fisico

•SBC – Part Number - Descrizione•SBC – Part Number - Descrizione

•Nodo fisico

•Nodo fisico



•Da tracciare

•+ S/N

•+ S/N

•Da tracciare

•+ S/N

•Da tracciare

•+ S/N

CASE STUDY A.M.


33/40

Configuration Baseline

è una configurazione di riferimento prefissata ottenuta definendoe registrando la documentazione di configurazione approvata perun sistema o per un articolo di configurazione in un momentodefinito o contestualmente ad un evento significativo erappresenta l’immagine istantanea che cattura la configurazione o laconfigurazione parziale di un CI in un momento specifica

Punti di verifica di commessa che rappresentano l’approvazione di un CI inun particolare momento definito durante la fase di sviluppo

Punti di controllo che hanno lo scopo di focalizzare l’attenzione delmanagement

Struttura Baseline – approccio Top Down (MIL-HDBL-61)

CASE STUDY A.M.


DEF STAN 05-57/4Baselines durante il Ciclo di VitaIl 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

CONCEPT ASSESSMENT•DEMONSTRATIO

N•MANUFACTURE

•IN-

SERVICEDISPOSAL

Functional Baseline

DesignBaseline

ProductBaseline

As Planned Baseline

As Built Baseline

As Delivered Baseline

As Maintained Baseline

As to be Maintained Baseline

CASE STUDY A.M.


Baselines durante il ciclo di vita

•Mondo in cui vengono •ACQUISITI •i sistemi

Direzione degli Armamenti Aeronautici

•Comando Logistico

In-Service

•Mondo in cui vengono •GESTITI •i sistemi

• Design Baseline

• Product Baseline

• As to Be Maintained Baseline

• ASD

DesignConf.Base

CASE STUDY A.M.


ASD S2000ML’ottica è focalizzata sulle “parti” attraverso la definizione di unaIPL – Initial Provisioning List che viene compilata secondo una logicadel breakdown ingegneristico del prodotto in una sequenza didisassemblaggio o scomposizione, che identifica tutti gli assiemi ed iloro componenti, unitamente a tutte le altre parti che non possonoessere associate ad assiemi.La sequenza con la quale gli articoli vengono individuati vienecontraddistinta 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)

Struttura ASD – approccio Bottom Up

CASE STUDY A.M.


I Dati di Prodotto presenti nei due documenti corrispondono a meno dei

PNR non applicabili al livello manutentivo.

Bill fBill of MaterialBOM

DESIGN SERVICE

•MODRequest for AlterationRFA

IPL

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.

CASE STUDY A.M.


•BOM

Ultima “istantanea” delle

modifiche applicate“Evoluzione” di tutte le modifiche

applicate

NO EVOLUZIONENon c’è visibilità dell’evoluzione del sistema / prodotto in funzione delle modifiche, ma l’ultima configurazione applicabile

SI EVOLUZIONEC’è visibilità dell’evoluzione del sistema / prodotto in funzione delle modifiche applicabili

BOM vs IPL/IPCInformazioni contenute

Confronto BOM con Struttura ASD S2000M

CASE STUDY A.M.


Nelle BOM ci sono informazioni post modifica allineate rispettoall’ordine delle modifiche introdotte, mentre nella IPL/IPC sonoriportati tutte le evoluzioni a partire dalla Configuration Base

É Possibile confrontare, quindi, una BOM con la IPL/IPC filtrata coni soli riferimenti post-modifica relativi. In questo caso i dati diprodotto corrispondono a meno dei PNR non applicabili al livellomanutentivo.

Viceversa per confrontare l’IPL/IPC completa dovrei sommare leinformazioni contenute nelle BOM non riportando le duplicazioni.

I dati necessari da gestire per permettere tale confronto sonol’insieme di dati di Design gestiti nelle Modifiche, nelle RFA e nelleBOM

Confronto BOM con Struttura ASD S2000M

CASE STUDY A.M.


Centro per la Formazione Logistica Interforze

Domande?

41/49

Documents

La Normativa Interforze sull’Integrated Logistic Support ......6/40 sistema di riferimento soldato futuro (forza nec) project management selex comms program management sgd – direzione