How does a VOR or a VORDME affect the coding decision between CF or IF-TF respectively?

Question

I was reading of the following case in ARINC 424-17 spec. Unfortunately the image is copyrighted and I can't paste it here, so here is a low(er) quality image of mine replicating the situation:

The text says that the path after the VI has to be coded as a CF if the XYZ is a VORDME but if the navaid is VOR only then it should be an IF-TF sequence. My question is not why is that sequence by how does the collocated DME affect the decision? The document mentions

This will allow a segment to be constructed, from one fix to the next fix, using an “intercept” where coding would otherwise not be possible.

But it doesn't explain why is it "not possible" to code this path as a CF if the station doesn't have DME. How does DME help here? In my mind, FOOBR is on a radial, let's say 55 from XYZ so if the airplane intercepts and follows this radial it will arrive to FOOBR, no DME involved. Is there something that I'm missing here?

---

^{VI vector to intercept}

^{CF course to fix}

^{IF initial fix}

^{TF track to fix}

Clarification:

Ralph J asked "what's the difference between CF and TF paths?" That's actually a good question. The spec is quite laconic:

Course to a Fix or CF Leg. Defines a specified course to a specific database fix.

Track to a Fix or TF Leg. Defines a great circle track over ground between two known databases fixes.

To my understanding, TF is more accurate as the course is derived from the previous fix while CF requires the course and recommended navaid to be coded in the aircraft's database, hence making the TF a simpler choice when available.

Answer 1

First; you have to understand that ARINC 424 is an industry standard. It is not regulatory. The regulatory documents are published by RTCA (and EUROCAE in the EU). The basic database coding requirements of it are generally well accepted and used by the industry as those are essential to its primary function of interoperability. But there's a lot of flexibility in how strictly developers follow the standard.

The example you give is one of application of the standard. Both of the leg combinations are valid, though the IF-TF is preferred. Note that ARINC 424 uses the word 'should' and not 'shall'.

Having worked FMS, I can say that the VI-CF could be coded but there are potential issues if XYZ is not a VOR/DME. How is FOOBR defined if there's no DME? It would have to be defined as an intersection with a radial from another VOR and the XYZ radial or as a Lat/Lon fix.

If it's a Lat/Lon fix, you can't reliably use the CF leg to get to it even if it's nominally on the radial as the radial error is quite large and could result in 'missing the fix' while flying the radial. And since the Lat/Lon fix is the RNP standard, the preferred leg type would be an IF-TF leg with the IF at XYZ.

If FOOBR is an intersection, it can be workable once you are established on the CF leg - by tracking the crossing radial. But the VI leg intercept is a floating fix which complicates the path generation as the relative positions of the intercept and FOOBR are not easily computed. That problem is much simplified if FOOBR is a Lat/Lon.

In my experience, I would expect the CF leg to be coded as a IF-TF. That provides fixed start and end points and a much simplified intercept computation. And it wouldn't be unusual for an FMS to convert the the original CF leg (based on the VOR/DME) into a TF leg.