JF-17 - Updates, News & Discussion

Off-topic but if this is going to materialize then that means India is ditching the Tejas for now and will gain all the expertise from developing Rafale. Although we don't know how much production % will fall in the hands of India. Basically India is taking the approach of what Pakistan did jointly with China for JF-17 (and Indians were mocking Pakistan for it). Still, a great deal for India and Pakistan needs to be prepared.

"France and India are entering a new era of defence cooperation with plans to jointly produce Rafale fighter jets as well as helicopters, French President Emmanuel Macron said on Thursday, adding France also hopes to sell more submarines to India." Source: Dawn India to make Rafale jets with France
 
I think focus is on SHORADS acquisition in current budget.
sir, is there any planned integration of GBAD and PIADS into one echo system under PAF?

also what i understand that PAF is working to develop antidote for SSCM in large scale employment?
 
sir, is there any planned integration of GBAD and PIADS into one echo system under PAF?

also what i understand that PAF is working to develop antidote for SSCM in large scale employment?
I don't know about any such plans but there is a focus now on enhancing jointness between all services, a JADC2 kind of approach to bring all sensors-shooters in same network.
SHORADS induction is primarily due to SSCM threat, also an increased EW and GBJ capability for soft kills.
 
Okay. I agree to end this discussion.

I'll use the limited time available to submit our entire conversation to AI for analysis, attempting to pinpoint the root cause of the problem. Below is the feedback from the AI tool after analyzing our conversation. I'll use this to conclude this discussion.

==========================

Below is a fully objective, technical, and neutral analysis in English, focused on where the discussion actually broke down rather than who is “right”.


Executive Summary​

The core problem is not technical ignorance on either side, but a fundamental mismatch in conceptual framing, terminology, and evidentiary standards.

Michael and Oscar were not arguing about the same thing, yet they used overlapping vocabulary (“integration,” “Level 4,” “source code”), which created the illusion of direct disagreement while masking a deeper misalignment.

As a result, the discussion devolved into repetition, frustration, and mutual disbelief—despite both sides making internally coherent arguments.


1. The Primary Failure: Different Questions, Same Words​

Michael’s actual question:​


This is a system-of-systems optimization question, concerned with:

  • Native cooperative engagement modes
  • Deep sensor–shooter coupling
  • Algorithmic co-design assumptions
  • Upper performance ceilings in edge cases (e.g. cooperative BVR engagement)

Oscar’s actual question:​


This is an engineering integration feasibility question, focused on:

  • ICDs, data buses, SMS/WMMC, SDFs
  • MIL-STD-1760 / 1553B architectures
  • Real-world mixed-origin integration examples
  • Practical constraints vs myths
📌 Key point:
Michael was discussing optimal system behavior at the design ceiling.
Oscar was discussing what is technically achievable and widely proven in practice.

These are not mutually exclusive, but they are not the same question.


2. The L1–L4 Issue: The Fatal Anchor​

The discussion irreversibly derailed around the “L1–L4 integration levels” concept.

Why this became the breaking point​

  • Michael treated L1–L4 as a real, commonly understood industry model.
  • Oscar correctly demanded:
    • A recognized standard
    • A military program reference
    • An OEM or government definition
None were provided.

From an English-language technical forum perspective:

  • An undefined taxonomy = non-falsifiable
  • “AI tools say so” = not evidence
  • Repetition without citation = credibility erosion
📌 Even if Michael’s intuition reflects real internal industry thinking, without formal grounding it cannot function as a shared analytical framework in that environment.


3. “Source Code” Was the Wrong Hill to Die On​

This is the single most important semantic failure in the entire discussion.

What Michael​

Not:

  • Git repositories
  • Full software transparency
But rather:

  • Control over algorithmic behavior
  • Ability to reshape sensor–weapon interaction logic
  • Freedom to modify assumptions embedded during co-design
  • Authority to restructure how data is fused, prioritized, and exploited
In other words: system behavior plasticity, not literal code access.

What Oscar​

  • OEM handing over proprietary software
  • Direct access to radar or mission computer internals
  • A claim that modern integration cannot work without this
Under that interpretation, Oscar’s rebuttal is technically correct.

📌 They were arguing past each other due to a collapsed abstraction layer.


4. Functional Integration vs System-Native Optimization​

This is the conceptual gap that never got bridged.

Oscar’s position (correct in engineering terms):

  • Modern architectures intentionally decouple systems
  • High-end capabilities can be achieved via:
    • ICDs
    • Data links
    • Middleware
    • Certification and testing
  • Mixed-origin integrations work extremely well in reality
Michael’s position (valid but poorly framed):

  • Some weapons are designed assuming:
    • Native radar waveform cooperation
    • Tight timing guarantees
    • Specific data fusion philosophies
  • When removed from that native ecosystem:
    • The weapon still works
    • But certain edge-case or advanced modes may be unavailable or degraded
  • This is not about “can fire” but about design-intended maxima
📌 These positions are not contradictory, but Michael never clearly separated:


Oscar understandably rejected the latter.


5. Cultural and Methodological Mismatch​

This amplified everything.

Michael’s implicit norms (common in Chinese technical discourse):​

  • Internal models are acceptable even if unpublished
  • “Industry logic” can substitute for citations
  • System-level intuition is valued
  • Terminology is flexible if intent is understood

Oscar’s explicit norms (Western engineering forums):​

  • Claims must be externally verifiable
  • Standards > intuition
  • Terminology must map to real documents
  • Reproducibility matters more than plausibility
📌 Neither is “wrong”, but they are incompatible without adaptation.


6. Why the Discussion Became Irreparable​

Three things happened simultaneously:

  1. Michael repeated an undefended classification system
  2. Oscar escalated evidentiary pressure
  3. Michael doubled down instead of reframing
At that point:

  • Oscar concluded the argument was unfalsifiable
  • Michael concluded Oscar was ignoring system-level realities
  • Trust collapsed

7. One-Sentence Root Cause​



8. What Would Have Worked Instead​

Had Michael reframed his argument as:

  • “Certain design-assumed cooperative engagement modes may not be economically or contractually available in cross-ecosystem integrations”
  • “This is about optimization ceilings, not basic functionality”
  • “No source code transfer is required, but some behaviors are not exposed through interfaces”
…the discussion likely would have converged rather than collapsed.


Final Note​

Importantly:
Neither side demonstrated ignorance.
The failure was one of abstraction management, terminology discipline, and audience calibration—not technology.
To cut the long story short. Pratically, CEC capability can be achieved without having source code. How? Let's unpack that. The core consideration is what type of CEC is achievable without source code. Now we are not choosing between Source code OR CEC rather we are choosing between Sensor-level CEC or Network-level CEC (also called Overlay CEC). It can be achieved with ICD access (as @Oscar suggested), Mission computer control, Standardized national track format adapted by a modular datalink. No radar source required.
But there are certain performance ceiling parameters which can be enhanced in sensor-level CEC with having radar source code.

You only need radar source access if you want to achieve following in CEC kill chain.
  • Custom radar modes for specific missile support
  • Advanced cooperative waveform scheduling
  • Ultra-low latency missile–radar closed-loop logic
  • Deep radar–missile energy management optimization.
That’s top-tier ecosystem integration like you see in platforms such as the F-35 Lightning II.
But even USAF doesn't operate F-35 only. There are thousands of 4.5 gen fighters (Even newer are being made) because in futuristic JADC2 (Joint All Domain Command & Control) architecture fighters will only act as missile carrier. Netowrk and Advanced Battle Management System (ABMS) will ensure Multi-node guidance, Third-party targeting, and Shooter survivability. On May 7th, we saw glimpses of some of these capabilities by PAF as well.

In summary, during a network-centric warfare, instead of modifying sensors (radar with source code) you build a network overlay layer above them where Sensors produce data, Network distributes data, Missile consumes data. No radar source code needed. Only disciplined architecture.
@AeronautIR has shared that now PAF is also pursuing a system similar to JADC2, it makes perfect sense if we consider the tactics of PAF during 2025 conflict with India and all recent press releases.

Now as for weapon integration, here is how PAF will integrate its own weaposn without have source code. Weapons Pakistan will develop would be sensor-agnostic in design and this approach usher a fundamental change in design philosophy. Underlying principle here is that a missile does not care which sensor produced the target data. So for weapon designer the consideration changes from
“Radar X must guide Missile Y”

to
“Any validated target track can guide Missile Y.”

That’s a massive doctrinal shift.
 
  • On the specific JF-17 point, every source, academic, marketing, interviews all describe a MIL-STD-1760-based stores interface and list multiple integrated weapons for the platform, which shows integration happens through a stores management architecture, not through your claimed universal “L4 source code rule”. Without knowing the actual contract on the Azerbaijan program or the complete weapons fit it is pointless hyperbolic discussions on something you cannot prove without knowing what the Azerbaijanis signed for - Maybe @Qaraca knows?

I have commented on this once, but the source for the alleged claim about integration of Turkish weapons on JF-17 was from some obscure blog. To me, that is not a proper source. Now the integration of some PGMs may still be possible of course, but what is there to say without proper information.
 
I don't know about any such plans but there is a focus now on enhancing jointness between all services, a JADC2 kind of approach to bring all sensors-shooters in same network.
SHORADS induction is primarily due to SSCM threat, also an increased EW and GBJ capability for soft kills.
Why focus on SHORADs only?? Shouldn't the focus be instead on Medium range....to be able to track and classify the SSCM/ALCM further out so you have an accurate firing solution and time to engage? SHORADs means its your last line of defense and if it fails to intercept in the relatively short range, then the threat vector will peek through and hit.......... what do you think?
 
Why focus on SHORADs only?? Shouldn't the focus be instead on Medium range....to be able to track and classify the SSCM/ALCM further out so you have an accurate firing solution and time to engage? SHORADs means its your last line of defense and if it fails to intercept in the relatively short range, then the threat vector will peek through and hit.......... what do you think?
The list of requirements is long , from Anti-Ballistic missile shield to CIWS. In time, all layers will be improved but SHORADS have a better interception rate than HIMADS in my opinion. Maybe @side-winder and @Oscar can enlighten us more on that.
 

Users who are viewing this thread

Pakistan Defence Latest

Country Watch Latest

Back
Top