correct as-is CMWS Keeps repeating Programs after missile destroyed

[Scaley]

Hard to definitively say this is a "bug" since the real workings of the system are classified and I'm sure ED had to do some abstraction with how they model the system. However...

The AUTO dispensers component of the CMWS continues to run flare programs after the incoming missile can no longer possibly detected (for example, because it has crashed into the sea). It seems unlikely that the intent was for the system to continue dispensing when the threat has passed some time ago. It seems the minimum number of dispense profiles that will get triggered is 3 before the system stops. Given that at the ranges a typical MANPAD or other IR SAM is fired, only the first run of the program will have fired before the missile reaches the aircraft the subsequent 2 program runs are effectively wasted every time.

 

CMS Repeat.trk

Edited April 8, 2022 by Scaley
sp

[NineLine]

This is correct as is, it will run its duration unless manually cancelled, if you need a shorter program you should select another. Thanks!

[Scaley]

20 hours ago, NineLine said:

This is correct as is, it will run its duration unless manually cancelled, if you need a shorter program you should select another. Thanks!

Sorry, NineLine, I may not have explained the problem very well in the first post. I understand that the program selected will complete once it's triggered. The behaviour I suspect isn't correct is that the CMWS continues to start NEW programs after the threat is no longer visible or in existence.

The setting used in the original track file posted are:

• Burst count: 6 (or maybe 4, can't remember)
• Burst Interval: 0.1 (the smallest)
• Salvo Count: 1
• Salvo Interval: 1 (also tried 8 but made no difference)
• Flare Delay between Programs: 4 (the longest)

These settings are not explained in the manual, but the common sense interpretation of these is that we should see 6 flares at 0.1s spacing, with only one salvo fired. This is what happens if the program is run manually.  

However, if you let the program run automatically you actually see 3 salvos of 6 flares at 4 second spacing. This suggests that the program is getting re-triggered after the "Flare Delay between Programs" delay has expired. 

I've attached some more tracks, and in these I've gone to F2 view prior to reaching the MANPAD and run the program manually so you can see what one iteration of the program is. I probably should have done this before to make it easier to see what the problem is, sorry for my bad explanation!

Some Tacview files are also attached for reference showing the same thing. It looks perhaps like the issue is that the CMWS continues to show a missile warning for some time after the missile is destroyed, thereby triggering additional flare programs to run. The dispenser system appears to be responding correctly to an incorrect missile warning. I know these systems are far from perfect IRL but this is 100% repeatable and will happen every time the system is triggered. 

Hope that helps.

 

 

CMWS repeat 4.trk CMWS repeat 2.trk CMWS Repeat 4.acmi CMWS c.zip.acmi CMWS a.zip.acmi CMWS repeat 3.trk CMWS b.zip.acmi

[NineLine]

On 4/12/2022 at 7:45 AM, Scaley said:

Sorry, NineLine, I may not have explained the problem very well in the first post. I understand that the program selected will complete once it's triggered. The behaviour I suspect isn't correct is that the CMWS continues to start NEW programs after the threat is no longer visible or in existence.

The setting used in the original track file posted are:

• Burst count: 6 (or maybe 4, can't remember)
• Burst Interval: 0.1 (the smallest)
• Salvo Count: 1
• Salvo Interval: 1 (also tried 8 but made no difference)
• Flare Delay between Programs: 4 (the longest)

These settings are not explained in the manual, but the common sense interpretation of these is that we should see 6 flares at 0.1s spacing, with only one salvo fired. This is what happens if the program is run manually.  

However, if you let the program run automatically you actually see 3 salvos of 6 flares at 4 second spacing. This suggests that the program is getting re-triggered after the "Flare Delay between Programs" delay has expired. 

I've attached some more tracks, and in these I've gone to F2 view prior to reaching the MANPAD and run the program manually so you can see what one iteration of the program is. I probably should have done this before to make it easier to see what the problem is, sorry for my bad explanation!

Some Tacview files are also attached for reference showing the same thing. It looks perhaps like the issue is that the CMWS continues to show a missile warning for some time after the missile is destroyed, thereby triggering additional flare programs to run. The dispenser system appears to be responding correctly to an incorrect missile warning. I know these systems are far from perfect IRL but this is 100% repeatable and will happen every time the system is triggered. 

Hope that helps.

 

 

CMWS repeat 4.trk 545.52 kB · 0 downloads CMWS repeat 2.trk 495.36 kB · 0 downloads CMWS Repeat 4.acmi 45.07 kB · 0 downloads CMWS c.zip.acmi 50.26 kB · 0 downloads CMWS a.zip.acmi 82.04 kB · 0 downloads CMWS repeat 3.trk 487.14 kB · 0 downloads CMWS b.zip.acmi 52.95 kB · 0 downloads

Thanks for the added explanation, I will take another look. 

[NineLine]

Ok, I see now what you mean, its not so much how the auto is operating, its that the threat indication is active when there is no longer any threat, so the question is how fast that should update after the missile is destroyed. 

[NineLine]

Ok, so after more testing (and chatting with the devs), I think it needs to stay correct as is. First, defensive systems do not have a lot of available information, SME's (smart ones) will not talk about them or share info that will put real world pilots at risk. So based on our best available info, and understanding of these systems, it makes sense for the warning to stay active for a short time afterwards, even if the missile is destroyed. As always, if you have info, please feel free to PM me on it, but also be very careful if you do, as I said, defensive systems can be super delicate. 

I will leave this open for now, in case there is something additional you want to add, but unless you have specific info on the above that can be shared, it will most likely stay like that. 

Thanks.

[Deezle]

It doesn't detect the missile itself, it detects the burning rocket motor, the system doesn't know if the missile has been destroyed or if the rocket motor has simply reached the end of its burn and the missile is still coming towards you. Seems correct to me.

[Scaley]

22 hours ago, NineLine said:

Ok, so after more testing (and chatting with the devs), I think it needs to stay correct as is. First, defensive systems do not have a lot of available information, SME's (smart ones) will not talk about them or share info that will put real world pilots at risk. So based on our best available info, and understanding of these systems, it makes sense for the warning to stay active for a short time afterwards, even if the missile is destroyed. As always, if you have info, please feel free to PM me on it, but also be very careful if you do, as I said, defensive systems can be super delicate. 

I will leave this open for now, in case there is something additional you want to add, but unless you have specific info on the above that can be shared, it will most likely stay like that. 

Thanks.

Thanks for looking again. Clearly there is no publicly (PM or otherwise) sharable information on this kind of system so if it's been decided that this is correct then there isn't anything I can say that will support a change beyond applying some engineering logic. I have worked on (much older) systems of this kind, but none of that information is releasable either, nor would it in any way be relevant. Personally I still don't think the sensor latency is correct based on the capabilities of stuff that is 20 years older, but I can't evidence that belief so we can just take it as given that it's unlikely that it will get changed. We then need to be able to configure the correct flare profiles within the limitations of the system we've been given.  What's below is a fairly long explanation but there is a simple TLDR at the bottom!

The best way I can think of to explain this is looking at the threat the system is designed to defeat. In reality the logic in these kind of systems is tailored based on the expected threats in the particular area of operations, and a lot of effort is spent designing and tailoring the software based on threat library data. In DCS we have a relatively limited set of IR missile threats so we can consider those as our threat systems. The longest range IR system in DCS is the SA-13 with a range of 5km.  At that engagement range the TOF is about 10 seconds, which therefore becomes the MAXIMUM amount of time you'd want to plan to run your countermeasures over. A MANPAD will engage typically at ranges closer to 2km, with a TOF of 3 seconds or less. The automated component of systems like this are there primarily to defeat the close-in MANPAD shot that will impact the aircraft before the pilot has a chance to react, sometimes within one second of launch.

As a sensible countermeasures system designer who only has access to a single flare profile you would logically then bias your system to dispense most/all of the program within the first 1-2 seconds of receiving the alert to defeat the close-in MANPAD shot. You would design the system to dispense what you reasonably believed to be a "good enough" profile to defeat the threat most or all of the time. If you knew the system had a "latency" time where the warning was still displayed, as you have modelled the on the DCS AH-64, you would also factor that into your profile settings.  

Taking account of all of that what would be designed for the DCS system? Well the number of flares required to reliably defeat a MANPAD is 4-5 depending on your risk tolerance. We can't dispense 5 on the system we have in DCS, so we would choose 6. These 6 flares all have to go in the same profile, because the minimum interval between profiles is too long for the second salvo to trigger before the MANPAD impacts. This is essentially the minimum useful salvo for the intended use of the system as modelled in DCS. (6 flares, 0.1s spacing). Of note the actually optimal profile in DCS would be 6 flares, zero spacing, but the Apache dispensers I'm fairly sure can't do that.  

Based on the DCS tracks we can see the sensor system as modelled triggers for at least 8 seconds (since it fires 2 subsequent salvos at 4 and 8 seconds after missile launch when the lockout is 4 seconds) regardless of missile burnout prior to that time. Now we know the system has a sensor latency of 8 seconds, and will keep triggering an alert we (as the profile designer) need to choose what to do. Given our main threat system has an average TOF of 3 seconds it's fairly unlikely we would program the system to still keep dispensing countermeasures 8 seconds after it detects the missile motor. The only time this would be of use would be against a near max range shot from an SA-13 that was detected straight off the rail. That shot has a tiny pk against the Apache anyway. We also know that (in DCS) these systems are easy to defeat. With the current Apache CMWS and countermeasures you can literally fly right over a MANPAD straight and level at 100' at 80kts with near 100% safety. In other words running multiple flare salvos out to 6+ seconds if fairly pointless because it's very unlikely a CMWS alert at that point is real, and it's very likely that the missile has already been defeated. What would be sensibly designed for the DCS system as modelled, is to run one flare salvo with at least 5 flares released within 1 second, maybe with a repeat 0.5-1s later. Unfortunately this isn't possible in DCS. What happens when you try to do this is that you get your 6 flares released at least 3 times, using 18 flares.  This means instead of being able to defeat 10 missiles your system can now only defeat 3.

This is completely solved by having a longer lockout time that stops the programs repeating based on a single alert (with latency). If the system is know to have an 8 second latency it needs lockout settings that go all the way up to 8 seconds, but currently it stops at 4.

The TLDR of this is that is your team have decided that the sensor and system latency we have is correct then we need the "flare delay between programs" setting to go all the way to 8 seconds (so ideally a 6 and 8 second setting in addition to the current ones). IRL this would be a software setting that could be whatever the program designer chose. I certainly can't evidence that any similar setting goes beyond 4 seconds in the real system, but there is absolutely no way that a defensive systems engineer would run the system with the current profile settings knowing the detection system latency was so long and they couldn't do anything to stop the system just continuing to throw out flares. As currently modelled the best use of the auto dispensers is to turn them off. I CAN evidence that in reality they are definitely not turned off. If you read Apache Over Libya by Will Laidlaw there are several accounts of how well the automated systems were used.

I hope that helps. I guess this is one of those things where the ED team will have to make some sensible assumptions, but having made them the rest of the system then has to work alongside those assumptions, simply because the real data isn't going to be available.  Like I say there is no way to reference most of this but quite happy to continue the conversation in PM or here if it's useful.  

Edited April 14, 2022 by Scaley

[Scaley]

Any chance of an indication of whether ED would be willing to look at this?

[NineLine]

No, currently the team is happy with how it is looking, maybe later on down the road we can revisit. 

[Swift.]

2 hours ago, NineLine said:

No, currently the team is happy with how it is looking, maybe later on down the road we can revisit. 

Can we at least in the short term have the ability to better control this behaviour through a lua? Just so that the user can adjust the behaviour to suit their needs, in lieu of the ability to match it closer to RL.

[NineLine]

12 minutes ago, Swift. said:

Can we at least in the short term have the ability to better control this behaviour through a lua? Just so that the user can adjust the behaviour to suit their needs, in lieu of the ability to match it closer to RL.

Match it closer to real life based on what?

[Swift.]

30 minutes ago, NineLine said:

Match it closer to real life based on what?

I assumed that based on what you said about this topic being hard to find info about, that what we had now was a best guess. So I was imagining that we might try to use what information we know the aircraft is being provided (look at the way the missile alert stops at the right time) and attempt to 'code our own logic' so to say.

As Scaley wrote above, there is a way to effectively code a threat defeat system based on information we already have in DCS. We know missile TOF, we know what the aircraft sensors are seeing, we know the countermeasure efficacy. So all we need to do is put it together in a way that reliably and efficiently defeats threats.
ie. 6 flares for a single missile warning, aka a single program run per launch warning. 

Basically what I'm trying to get at, is that if we don't have the info on the way the RL CMWS is coded, then we need to use the intention behind the real CMWS. And I'm sure the intent behind the system wasn't to waste countermeasures on programs being run after the threat is known to be a none factor. 

So our ideal solution, is for the above issue to be corrected in vanilla DCS. But if we cant have that, then it would be similarly ideal to be able to code our own behaviours into the CMWS, I imagine (and hope) the eventual mission planner/data card implementation will allow this, but I appreciate that is not quite ready yet. So in the interim, a simple lua file that would allow us to code this specific behaviour would help fix the immediate issue: That the AUTO mode of the CMWS is unusable.

[Scaley]

51 minutes ago, NineLine said:

Match it closer to real life based on what?

Thanks for the reply NineLine. I think what I'm trying to get at is that right now all the ED modules that have automated systems are used by players with those systems switched off because they deplete countermeasures too quickly to be useful. None of these systems have publicly available reference documents for obvious reasons, so we are all going to be working from either first principles and general information, or sensible assumptions. 

If you read my very long post above the TLDR is that as the system is modelled right now the lockout period ( called "Flare Delay between Programs" ) does not go to along enough settings to allow the system to be used on a normal DCS mission because it will currently dispense nearly 1/3rd of the aircraft's total flare load each time it gets a missile alert if you use effective program settings. You either have to accept this, or set a smaller program and accept the system may well not protect you from a close-in MANPAD shot (which based on he book referenced we know in reality the equivalent system on UK AH.1 Apaches does very very well)

The team have done a really good job with the Apache system and it is AMAZINGLY close to being genuinely useful in a way that would let people operate the aircraft with the automated system switched on most of the time. ALL that is required to make this the first ED module (in fact, the first combat simulation aircraft in any sim I've ever seen) that has a really useful and very effective automated countermeasures system is that the maximum lockout period is increased to (I would suggest) 12 seconds. Even 10 or 8 would be OK.  This should need one or maybe two lines of code changing at a single digit. I think the reason I'm pushing here is that the difference for the player experience to have such a system is significant!

None of us here will know how this system works in real-life, and the people that do can't talk about it.  What we do know (see the book referenced above) is that in real life the Apache operates with the automated system switched on, because it works! If you change one or two lines of code you can match this outcome for the player. Right now with the current settings the outcome will be that everyone will switch the system off as they do in all the other aircraft.

As I said before, if you want to PM, or me to show any of the team to couple of digits that could be changed I'm more than happy to lend a hand.

Hope that helps.

Edited April 21, 2022 by Scaley

[NineLine]

Sorry guys, as I said, and I do appreciate the effort, but we are happy with how it performs right now, once we get down the road and the -64 is a little more complete maybe we could challenge the devs with these opinions. Until then, lets just work with what we have, which with my testing isnt horrible anyways, and we will go from there. 

PS I did read your posts, and I appreciate the well thought out responses, remind me again down the line and we can take a look at it, if nothing has changed here by then.

Thanks.

[Scaley]

No worries, I'll pop another post up in due course once the module has settled down.

[Swift.]

Just now, NineLine said:

Sorry guys, as I said, and I do appreciate the effort, but we are happy with how it performs right now, once we get down the road and the -64 is a little more complete maybe we could challenge the devs with these opinions. Until then, lets just work with what we have, which with my testing isnt horrible anyways, and we will go from there. 

PS I did read your posts, and I appreciate the well thought out responses, remind me again down the line and we can take a look at it, if nothing has changed here by then.

Thanks.

Thanks Nineline, as a final thought, do we know yet whether this kind of detailed programming will be available as part of the DTU? It seems like the kind of place where this stuff would be coded IRL.

[Scaley]

@NineLine It's been a few years since this topic was visited. I was wondering if it would be ok to bring back to the devs the possibility of changing a couple of digits of code (I know where one is, but the other is in complied code) to allow us to use the Apache automated flare dispensers effectively. As predicted in the original post, everyone I fly with online keeps the system in manual for exactly the reason predicted - there is no combination of settings that are effective and not wasteful of flares. It's literally a 10 second fix to change this to make the Apache CMWS system have an effective and useful AUTO mode. 

[ruiner_]

For all of the logic you cover in your post you base it on a 5km max range, ignoring the fact that there are a2a ir missiles with far longer range. 

You can't tell me you would still have enough flares in auto in a busy environment with friendlies firing off a lot of missiles just by making it run the program a bit shorter. 

Edited January 19 by ruiner_

[Scaley]

17 hours ago, ruiner_ said:

For all of the logic you cover in your post you base it on a 5km max range, ignoring the fact that there are a2a ir missiles with far longer range. 

You can't tell me you would still have enough flares in auto in a busy environment with friendlies firing off a lot of missiles just by making it run the program a bit shorter. 

 

Indeed, but no one designs attack helicopter countermeasures systems to defeat AIMs in preference to MANPADS. The public sources that are available suggest these systems are in reality used in AUTO mode, and are effective against MANPADS.  Whether or not they work against AIMs is speculation since there are no recorded modern jet Vs helicopter engagements. 

[ruiner_]

On 1/19/2024 at 2:42 PM, Scaley said:

Indeed, but no one designs attack helicopter countermeasures systems to defeat AIMs in preference to MANPADS. The public sources that are available suggest these systems are in reality used in AUTO mode, and are effective against MANPADS.  Whether or not they work against AIMs is speculation since there are no recorded modern jet Vs helicopter engagements. 

I'm sure this version got put into bypass at times, unless the datalink had the capability to send realtime rifle info and that was integrated into the cmws but based on what we know about the datalink that does not seem to be the case at all. 

I was thinking this was going to be a lost cause for you with no public information available but I think I have found something at least semi applicable. I'll pm nineline about it. 

[Swift.]

On 1/21/2024 at 6:49 AM, ruiner_ said:

I'm sure this version got put into bypass at times, unless the datalink had the capability to send realtime rifle info and that was integrated into the cmws but based on what we know about the datalink that does not seem to be the case at all. 

I was thinking this was going to be a lost cause for you with no public information available but I think I have found something at least semi applicable. I'll pm nineline about it. 

It would be theoretically possible for a CMWS to discriminate between different types of missile, and also missiles that are on intercept or not. Depends on how precise the sensors are of course, modern vs old etc.

For example, the IR/UV signature of a hellfire would be unique when compared to an igla or something. Similarly, if a detection is made with a rapidly transiting line of sight, it can be said that that detection isnt for a missile thats on a collision with your aircraft. Things on collision courses tend to have 0 line of sight rate.