Apache Datalink

[Raptor9]

8 minutes ago, QuiGon said:

Damn, EPLRS isn't in use at all?

There are a few legacy systems that use a elements of the original EPLRS architecture, but as a system it is not in use, and was never actually fielded as an over-arching force-wide network.

[FalcoGer]

I wonder why they mix the systems up so much. Wouldn't it be better to integrate everything into link 16 or any other datalink format just to keep software development costs, parts compatibility and platform interoperability good? If you have 20 different datalinks then you have 20 different softwares to write and maintan, 20 different radio protocols, 20 different networks that can't talk to one another. It seems downright stupid. Pick one, upgrade everything to it and stick to it. It's cheaper and better. If that MBT at the front wants to send targeting data to some F16 they have to talk through several people and relay information verbally. Instead they could just ask one person, get affirmation and then send a 9 line via link. Or the E-8 picks up a column of tanks over the next ridge and the blue tanks can just see them on some screen and plan for it. Or the apache sees the enemy fighters flying their way on the TSD and they can hide. Instead it's segregated. Why?

[Raptor9]

@FalcoGer, you're applying simplistic logic to a much more in-depth system of systems. Different platforms have different requirements to do their mission. Different missions are in accordance with widely different doctrines. There is no way to design a singular software solution to meet everyone's mission, comms, and security requirements.

If you did, every time they want to add a new feature to support one type of platform or one mission set used by one type of unit, you would have to update EVERYONE'S systems, which would take forever and cost a lot of money. It's not necessary that everyone be able to talk to everyone.

Granted, there has been times in the past when there were identified needs to more seamlessly integrate with different platforms, services or countries that couldn't at that time. When that occurs, that normally drives a requirement to adopt some platforms to others or upgrade some equipment to new standards. F-22's, A-10C's, and AH-64E's are all newcomers to the Link16 fold, something that has been around for many years. Evolving needs based on joint interoperability and/or changing doctrine drive upgrades. But upgrading a tank to Link16 is silly unless there is an existing need for it.

The Apache has multiple datalinks it communicates on because it has a varied list of mission sets that require they talk to a lot of different people, platforms, and systems. But a tank on one datalink the AH-64 has to talk to doesn't need to talk to an F-16 on another datalink the Apache also has to talk to.

[FalcoGer]

If you apply some basic software engineering principles then it should not be a problem. I understand that there are different requirements. That is fine. If you look at another network protocol you will see why it is fine. TCP/IP is used for a lot of traffic on the interwebs and elsewhere, despite there being a myriad of requirements. If you design the protocol to be extensible then there is no issue, although DL would be more akin to ICMP with message types rather than encapsulating more protocols. If you require datalink then there is some commonalities between the systems, in particular most if not all solutions have the positions of your group on some sort of HSD. That F16 doing CAP doesn't need to know where the tanks are. Fine, just don't show them even though it can understand the message because it inherently understands position messages. The abrams doesn't need to know who that F16 locked up on the FCR and it doesn't need the software to decode that ever. Ignore the message.

If you have an addition to the protocol then any platform that is not updated will simply not understand the new message. I think it's a lot cheaper to have a single software update distributed than it is to develop and maintain 20 different solutions altogether and save costs on distributing them only to subsets, which you could still do with an extensible protocol.

I can come up from the top of my head with a dozen or two message types that would probably cover 80% of applications for datalink for all services.

 

I believe it has more to do with politics, bureaucracy and capitalism and not working together than it has to do with cost saving and requirements.

[Raptor9]

The infeasibility of having a singular datalink solution has nothing to do with software engineering or protocols, it's about real-world logistical and fiscal realities in managing a large, multi-branch military force.

7 minutes ago, FalcoGer said:

 

I believe it has more to do with politics, bureaucracy and capitalism and not working together than it has to do with cost saving and requirements.

Well you are certainly entitled to your opinion; but, respectfully, it is an ill-informed opinion.

Edited October 15, 2021 by Raptor9

[Clean]

These systems remind me of a business ERP system. For example, you have a bunch of different businesses, some of them can buy and use the same off the shelf system, but they'll all end up modifying them to fit specific organizational needs. Then when updates come out for the base system later on, they get harder and harder to integrate due to all the specific requirements of the individual businesses, and the changes they've made to it. Over time these base systems get more and more robust as a natural response to progress, innovation, and lessons learned.

I think eventually they'll get to one unit that does everything for everyone close to perfectly, but they'll always need at least some alterations to accomplish organizational specific tasks. From an outsider that seems like Link-16 and I imagine other examples are early forays towards that kind of progress. Radios have started going the same way too haven't they?

I get that upgrade costs would increase, that's just logical based on the pure number of units there would be, but I think that limiting the number of systems would lower training costs, and the per unit R&D/production costs would significantly decrease.

[M1Combat]

Hmmm...  A few points...

We're only talking protocol here...  not equipment.  Any equipment would be able to send bits in the right order on layer 2 for any other system to interpret them on layer 2.  That's really not much of an issue.  Layer 1 may indeed be a problem.  You can't interpret a pulsed laser sending encrypted data with a radio receiver :).  Everything speaks to everything else with a protocol and that protocol can be adjusted/re-written etc.  I hesitate to say "No Problem" here because it would require many different companies and entities to get together and make it happen....  BUT...

 

While I can see that a single solution would indeed be feasible, doable, less expensive and largely better...  

I can think of one VERY good reason to have all kinds of different software that may or may not talk to each other... 

 

Many points of failure/attack instead of one.

[Frederf]

What other platforms is the AH-64 able to interact with datalink-ly (with and without intermediaries)?

For cooperative (Apache-Apache) Hellfire attacks can the laser prompt timer be communicated electronically to the designating platform?

Edited April 5, 2022 by Frederf

[llOPPOTATOll]

1 hour ago, Frederf said:

What other platforms is the AH-64 able to interact with datalink-ly (with and without intermediaries)?

For cooperative (Apache-Apache) Hellfire attacks can the laser prompt timer be communicated electronically to the designating platform?

 

E-8, Kiowa, some artillery stuff, it also has Blue force tracker (not coming in dcs  ), it can send data over the HF radio presumably to ground stations and maybe some airborne stations.

Edited April 5, 2022 by llOPPOTATOll

[Frederf]

I read that the IDM works over each crew's radio selection for IDM so it looks like the pilot and CPG can IDM over different radios. I have no idea how that works.

[llOPPOTATOll]

I read that the IDM works over each crew's radio selection for IDM so it looks like the pilot and CPG can IDM over different radios. I have no idea how that works.

Thats correct, you just use the idm rocker to select what radio you want to use for idm.

[WHOGX5]

On 4/5/2022 at 8:38 PM, llOPPOTATOll said:

E-8, Kiowa, some artillery stuff, it also has Blue force tracker (not coming in dcs  ), it can send data over the HF radio presumably to ground stations and maybe some airborne stations.

Shouldn't the AH-64D be able to send and receive datalink messages directly with F-16CM-50's, seeing as they both have IDMs who communicate over the AFAPD and TACFIRE protocols?

[Raptor9]

1 hour ago, WHOGX5 said:

Shouldn't the AH-64D be able to send and receive datalink messages directly with F-16CM-50's, seeing as they both have IDMs who communicate over the AFAPD and TACFIRE protocols?

I've heard anecdotally that some foreign militaries have used TACFIRE in this manner, but I don't know when, how often, or whether it was simply proof of concept or an actual operational practice. In any case, TACFIRE isn't planned.

As for the AFAPD, the AH-64D and the F-16 are not compatible because their avionics don't recognize the messages transmitted by either platform. It's like if I called you on the phone and we spoke different languages; being able to communicate doesn't mean we can understand each other.