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
