Cum „perfecțiunea” software-ului blochează livrarea avioanelor
Impasul actual al programului IAR 99 SM nu este unul de natură mecanică (avioanele sunt construite și pot zbura), ci unul de natură contractuală și birocratică. Acesta s-a născut din refuzul de a accepta livrarea software-ului în trepte (Blocks), o practică standard în toată lumea.
În dezbaterile publice despre aviația militară apare frecvent ideea că un avion nu ar trebui introdus în serviciu până când software-ul său nu este complet finalizat.
Esența impasului: o barieră legislativă și contractuală care tratează un software de aviație complex ca pe un produs fizic finit (precum un lot de uniforme sau de muniție), unde recepția se face „totul sau nimic”.
Iată de ce această rigiditate legislativă blochează programul IAR-99 SM și cum afectează industria, spre deosebire de modelele internaționale:
Conflictul dintre Legislație și Realitatea Tehnică
Viziunea Legislativă: În România, normele de recepție tind să impună ca produsul să fie livrat cu toate funcționalitățile finale prevăzute în contract pentru a se putea face plata.
Realitatea Aeronautică: Software-ul de antrenament (radar virtual, rachete simulate) este prin definiție evolutiv și necesită ani pentru maturizare completă. Refuzul recepției pe „blocuri” (Blocks) înseamnă că avionul nu poate fi acceptat oficial nici dacă este gata 90%.
În realitate, această așteptare nu a existat niciodată în programele moderne de avioane de școală și antrenament.
Dimpotrivă, practica internațională arată exact opusul: avioanele intră în serviciu cu software parțial, care este apoi dezvoltat incremental.
Această abordare nu este un compromis de avarie, ci o strategie matură, utilizată de state cu industrii aeronautice avansate și validată operațional timp de decenii.
Insistența de a nu accepta un avion până când software-ul de training nu este „100% gata” creează un blocaj financiar periculos. Această abordare transformă un program de modernizare într-o spirală a penalităților care poate băga o fabrică în faliment.
1. Mecanismul Colapsului: De ce apar penalitățile?
Neînțelegerea procesului de dezvoltare software duce la contracte rigide care nu fac distincția între siguranța zborului și funcțiile de antrenament:
• Blocarea plăților: Dacă beneficiarul refuză recepția aeronavei pe motiv că radarul virtual (software-ul de training) nu are toate funcțiile finale, fabrica nu poate încasa restul de plată, deși avionul este fizic construit și capabil să zboare în siguranță.
• Acumularea penalităților: Deoarece dezvoltarea software-ului de training este un proces de lungă durată, o întârziere de „finalizare” de câțiva ani poate genera penalități care depășesc profitul sau chiar valoarea întregului contract.
• Lipsa fluxului de numerar (Cash Flow): Fabrica rămâne cu avioanele în hangar și cu resursele blocate, în timp ce trebuie să plătească în continuare salarii și furnizori pentru un software care, prin natura sa, necesită ani de rafinare.
2. Cum au rezolvat ceilalți: Modelul „Block Upgrade”
Marii producători (Leonardo, Lockheed Martin, BAE Systems) au rezolvat această problemă prin abandonarea ideii de „livrare finală unică” în favoarea strategiei mature de dezvoltare incrementală.
• Definirea etapelor de recepție (Blocks): Contractele sunt împărțite pe „blocuri” software. Avionul este acceptat și plătit la atingerea IOC (Initial Operational Capability), care reprezintă de obicei 50–70% din capabilitatea software finală.
• Acceptarea parțială: Beneficiarul acceptă avionul cu un set de funcții de bază. Acest lucru oprește „ceasul” penalităților și permite fabricii să încaseze banii pentru hardware-ul livrat.
• Contracte de mentenanță și upgrade: Restul de 30–50% din software se dezvoltă și se livrează prin pachete ulterioare de tip „Update”, adesea sub contracte separate de suport tehnic,
eliminând riscul de blocaj financiar al producției
3. Exemple concrete de succes
Toate marile programe au evitat colapsul acceptând software „incomplet” la intrarea în serviciu:
• M-346 (Italia): A intrat în serviciu în 2011, deși sistemul său ETTS era funcțional dar limitat. Dezvoltarea completă a durat 10–11 ani (2000–2011). Dacă forțele aeriene ar fi refuzat recepția până în 2011, programul ar fi fost un dezastru financiar.
• BAE Hawk T.2 (Marea Britanie): A devenit operațional în 2010 cu un nivel de bază al antrenamentului sintetic. Dezvoltarea software-ului a continuat încă 4–6 ani după ce avionul era deja în serviciu și plățile fuseseră efectuate.
• T-50 (Coreea de Sud): A urmat același model, cu o durată efectivă de dezvoltare de 10–11 ani, livrând avioanele pe măsura atingerii pragurilor operaționale utile.
• L 39 NG Cehia) Durata efectivă de dezvoltare: Procesul a durat între 8 și 10 ani.
Perioada de desfășurare: Dezvoltarea a început în jurul anului 2010 și a ajuns la maturitate operațională în jurul anului 2020.
Strategia utilizată: Programul a urmat modelul de maturizare în trepte, integrând funcționalitățile pe parcursul unui deceniu
4. Concluzie: Lecția pentru IAR-99 SM
Scandalul legat de faptul că software-ul nu este „gata” pune sub presiune financiară gabrica dintr-o neînțelegere tehnică.
Pentru a evita colapsul financiar, soluția adoptată la nivel internațional este clară:
1. Recunoașterea IOC ca fiind o etapă legitimă de recepție.
2. Acceptarea livrării incrementale (avionul zboară și face instruire de bază acum, în timp ce software-ul tactic se rafinează în următorii 2-3 ani).
3. Separarea plăților pe hardware (avionul fizic) de etapele de maturizare a software-ului de training.
Fără această abordare „matură”, validată de decenii de practică internațională, orice fabrică de avioane este condamnată la un eșec financiar dictat de imposibilitatea tehnică de a livra un software „perfect” și „complet”, ținând cont de întârzierile cauzate de livrarea unor echipamente.
Suntem foarte aproape să ne dam cu stângul în dreptul.