PAF J-10CE News, Updates and Discussion
- Thread starter amuqeetk
- Start date
- Status
falcon34
Registered Member
Radar on or just the aircraft using it's datalink to directly communicate with missile
This from air force monthly at one point he says that my radar is locked on the target and than says target info is fed through DL.
So what is it actually?.
gusto
Trusted Member
such a beauty, ruined by the underside paint scheme, which i think is the thing of the past.
instead go for a false canopy/false cockpit, although it is also not needed since a dogfight situation ever arises.
Attachments
Pakistan Space Agency
Elite Member
What a beauty! m52k85
Registered Member
Dear mods, please consider this on topic. After all there can be a scenario where PAF J-10s are required to confront carriers, in some future world 
Anyone has expertise on this? I am interested to know about sortie generation equations, recovery complexity and how to model it:
@JamD @Oscar any leads, will appreciate it.
Great question. This is exactly the kind of problem where naïve simulations fall apart and the right modeling choice matters more than code speed.
This is fundamentally a Discrete-Event Simulation (DES) problem.
But a plain DES is not enough, because the carrier deck is also a tight spatial puzzle with blocking, precedence, and routing constraints. You need DES + constrained logistics / rearrangement planning.
Think:
on a postage stamp that’s pitching in the ocean.
A carrier deck is driven by events, not timesteps:
Nothing meaningful happens “per second.” Everything happens when something completes.
So your core engine is a DES scheduler:
Classic DES.
The dominant delay is not service time (fueling, arming, catapult cycle).
It is:
This is a combinatorial rearrangement problem embedded inside the DES.
If you don’t model that correctly, your simulation will wildly overestimate sortie rate.
Model the flight deck as:
Now you don’t have “move aircraft to catapult”.
You have:
This is a multi-agent path planning + blocking problem.
Very similar to:
This is the hard part and the fun part.
Each time you want aircraft A to reach catapult C:
You must solve:
That’s NP-hard in general (rearrangement with blocking).
You cannot brute force.
You need heuristics like:
This is exactly what real deck crews do intuitively.
You want three layers:
Resources:
Events:
A live occupancy map of:
This layer answers:
When movement is needed, this planner computes:
This is where you use:
This planner feeds delays back into the DES.
If you treat it as queues:
You’ll get fantasy results like:
Because you ignored that aircraft #23 is boxed in by 11 others.
This is the classic mistake in carrier sims and wargames.
You’ll find useful literature in:
Carrier ops is a mashup of all of them.
You do not simulate individual inches of taxi.
You do:
This keeps it computationally tractable.
The carrier is not an airport.
It is a sliding block puzzle that periodically has to become an airport for 15 minutes.
Then it goes back to being a puzzle.
Your sim must capture that.
If you model it this way, you’ll reproduce real phenomena like:
Which is exactly what happens in reality.
Anyone has expertise on this? I am interested to know about sortie generation equations, recovery complexity and how to model it:
@JamD @Oscar any leads, will appreciate it.
Great question. This is exactly the kind of problem where naïve simulations fall apart and the right modeling choice matters more than code speed.
This is fundamentally a Discrete-Event Simulation (DES) problem.
But a plain DES is not enough, because the carrier deck is also a tight spatial puzzle with blocking, precedence, and routing constraints. You need DES + constrained logistics / rearrangement planning.
Think:
on a postage stamp that’s pitching in the ocean.
Why DES is the correct backbone
A carrier deck is driven by events, not timesteps:
- Aircraft finishes fueling
- Catapult becomes free
- Elevator arrives at deck
- Aircraft blocks taxi path
- Recovery window opens
- Aircraft hits bingo fuel and must recover
- Deck reconfiguration starts/ends
Nothing meaningful happens “per second.” Everything happens when something completes.
So your core engine is a DES scheduler:
- Event queue (priority by time)
- Resources with constraints
- State changes triggering new events
Classic DES.
But here’s the part most people miss
The dominant delay is not service time (fueling, arming, catapult cycle).
It is:
This is a combinatorial rearrangement problem embedded inside the DES.
If you don’t model that correctly, your simulation will wildly overestimate sortie rate.
The deck is a graph, not a queue
Model the flight deck as:
- Nodes = parking spots, catapults, elevators, landing area
- Edges = taxi paths with width/one-way constraints
- Each node holds at most one aircraft
- Some edges blocked by parked aircraft
Now you don’t have “move aircraft to catapult”.
You have:
This is a multi-agent path planning + blocking problem.
Very similar to:
- Container yard reshuffling
- Train yard switching
- Warehouse robot congestion
- Sokoban-style puzzles
The combinatorics you asked about
This is the hard part and the fun part.
Each time you want aircraft A to reach catapult C:
You must solve:
That’s NP-hard in general (rearrangement with blocking).
You cannot brute force.
You need heuristics like:
- Greedy local clearing
- Priority zones (catapult lanes kept semi-clear)
- Cost-to-move scoring for each parked aircraft
- Pre-staging aircraft in anticipation of next launches
This is exactly what real deck crews do intuitively.
Correct modeling layers
You want three layers:
1) DES layer (time & resources)
Resources:
- Catapults (4)
- Elevators (2–3)
- Fuel crews
- Ordnance crews
- Landing area (mutually exclusive with certain deck ops)
Events:
- Fuel complete
- Arm complete
- Taxi complete
- Launch
- Recovery window start/end
2) Spatial logistics layer (deck state)
A live occupancy map of:
- Every aircraft position
- Every taxi path
- Blockages
- Safe staging zones
This layer answers:
3) Rearrangement planner (the combinatorics)
When movement is needed, this planner computes:
This is where you use:
- A* or heuristic search on deck graph
- Cost = number of moves × move time
- Penalize moving armed/fueled aircraft
- Prefer moving cold aircraft
This planner feeds delays back into the DES.
Why queueing theory alone fails
If you treat it as queues:
You’ll get fantasy results like:
Because you ignored that aircraft #23 is boxed in by 11 others.
This is the classic mistake in carrier sims and wargames.
This is closest to what fields?
You’ll find useful literature in:
- Container terminal yard optimization
- Automated warehouse robot congestion
- Railway yard switching optimization
- Aircraft gate/taxiway scheduling at airports
Carrier ops is a mashup of all of them.
Practical way to implement (what actually works)
You do not simulate individual inches of taxi.
You do:
- Represent deck as discrete slots
- Predefine legal taxi corridors
- When a move is requested:
- Run pathfinding on slot graph
- If blocked → call rearrangement planner
- Rearrangement planner outputs a move list
- DES schedules those moves with realistic times
This keeps it computationally tractable.
The elegant mental model
The carrier is not an airport.
It is a sliding block puzzle that periodically has to become an airport for 15 minutes.
Then it goes back to being a puzzle.
Your sim must capture that.
Yes — this is a textbook DES + combinatorial logistics problem
If you model it this way, you’ll reproduce real phenomena like:
- Why alpha strikes cap at ~20 aircraft
- Why deck jams dominate delays
- Why pre-staging matters more than fueling speed
- Why recovery windows destroy launch tempo
Which is exactly what happens in reality.
I guess the Erieye had a Lock, but that was not taken as a threat as it was an AWACS flying too far.
That info was passed on to the jets , which fired the PL-15 and without a Lockon by the jet .
Since none of the PAF jets had a Radar Lock on Indian jets, they did not break the formation and did not take any evasive measures.
The PL-15 reached the target area then switched on its AESA radar, which was detected by Rafale RWR, and by then it was too late. The PL-15 must have lock on the Rafale , gone " Kutta" and hit the target.
Tariq Habib Afridi
Registered Member
that will mean that SAAB Erieye is integrated with J-10CE and than it also brings another question why JF-17B3 didnt get fired its PL-15 if it has to be guided by SAAB Erieye?
Integrated via Link 17, which is a Ground based Translator.
The Allen Warnes article posted above also mentions Indigenous encryption , which may also explain how Erieye can also talk to PL-15 , and PAF assumes it safe. Because if any other aircraft can talk to a missile fired from another aircraft, chances of that missile being hacked are imminent . But PAF apparently is confident about their signal encryption , integrity , and allows offboard targeting and guidance .
About why one aircraft was used in a certain role and why not another? It depends on PAF war plan, which are pre existing, with designated roles to each type of aircrafts.
I am assuming J-10C carries the longest range PL-15, while JF-17 carries SD-10 .
Ali_Baba
VIP Member
We are entering the era of quantum computing, so the idea of encryption keys being "safe" will disappear into history until/unless quantum safe encryption keys can be developed, or there is constant changing of keys, such that you can be sure they are secure for a period of time. Additionally, maybe move into a model where each plane can have its own encryption keys etc ( i wont go into it, it is topic in itself.).
RedRock
Registered Member
Thank you for sharing, amazing read. but, would appreciate it if you could upload complete pages. Thanks
Oscar
Moderator
J-10 Acts as data aggregator then passes info to PL-15. This is similar to discussion made earlier on JF-17 thread.
J-10 mission computer is basically fed through the Mil STD bus messages, its Sensor/Data fusion module creates a picture of the target information which it then feeds through the messages it needs to send to PL-15 on where the target is.
No source code required.
AeronautIR
HemlockKhalid
JF-17 can't stay at 40000 ft for long, so it flies at 30000. This reduces range of PL-15, even if it is guided by some other asset.
- Status
Users who are viewing this thread
Pakistan Defence Latest
-
-
-
-
-
Killings linked to illegal intrusion or criminal acts should not be called border killings: Salahuddin (3 Viewers)
- Latest: baldfish
Country Watch Latest
-
-
Iran - Israel/US War: Israel-US declare war on Iran, Iran responds (54 Viewers)- Latest: Persian Gulf
-
-
CHINESE PLAAF ‘FLANKERs’ - Su-27SK/UBK Su-30MKK/MK2 - Su-35 - J-11 - J-11B - J-16 (4 Viewers)- Latest: Beijingwalker
-
