[SystemSafety] GPS jamming

Sat Jul 13 16:25:20 CEST 2019

If I may say so, I see here what IMO is a misguided focus on attempted 
technical solutions to apparent interference with a single system. The 
obvious solution is not to rely on a single network of stations, 
terrestrial or orbiting, to get the primary position data. It is much 
harder for someone to spoof two technically different systems at the 
same time than to spoof just one of them.

Consider the affected parties:

1. Walkers and motorists: Both should be able to read maps. Motorists 
who can't read maps shouldn't be driving. And if GPS can be spoofed, 
they shouldn't be relying on it for intra-urban navigation in case it 
sends them the wrong way down one-way streets.

2. Ships at sea: Plenty of other ways for them to get fixes and it's not 
time-critical.

3. Civil aviation: They shouldn't at any time be relying on a single 
system for providing primary position data.

4. The military: They created the problem. If it's affecting them, they 
should provide their own solutions.

The only big issue here is the dependability of the global navigation 
infrastructure for civil aviation. If GPS or enhanced GPS is vulnerable, 
there need to be alternative systems with different vulnerability 
profiles. The basic problem is not going to be solved by adding 
functionality to GPS or other systems that does not directly address the 
fundamental vulnerability of GPS to spoofing.

Olwen

On 13/07/2019 11:18, Peter Bishop wrote:
>
> I am not an expert, but I understand EGNOS works out corrections to 
> standard GPS signals
> based on a limited number of ground stations (who obviously know where 
> they are).
>
> If spoofing is in a localised area, the ground stations (located 
> elsewhere) would not see the spoof (just the regular satellite 
> signals), so the resultant broadcast Egnos correction data would just 
> make a small correction to the spoofed GPS signal.
>
> Or have I got this completely wrong?
>
> Peter Bishop
>
> On 12/07/2019 13:16, Dewi Daniels wrote:
>> Peter,
>>
>> That is indeed very chilling. It seems that we have an aircraft 
>> operating with certified kit that ended up 12nm off course in 
>> mountainous terrain. Either the certified equipment on board the 
>> aircraft did not work as intended, or even more chilling, there is a 
>> fundamental problem with WAAS. I hope it's not the latter. The WAAS 
>> technical specification promises that "WAAS provides the additional 
>> accuracy, availability, continuity and integrity necessary to enable 
>> users to rely on GPS for all phases of flight, from en route through 
>> approaches with vertical guidance, at all qualified airports within 
>> the WAAS LPV coverage area". This does not appear to have been the 
>> case in this instance.
>>
>> Yours,
>>
>> Dewi Daniels | Director | Software Safety Limited
>>
>> Telephone +44 7968 837742 | Email d 
>> <mailto:ddaniels at verocel.com>ewi.daniels at software-safety.com 
>> <mailto:ewi.daniels at software-safety.com>
>>
>> Software Safety Limited is a company registered in England and Wales. 
>> Company number: 9390590. Registered office: Fairfield, 30F Bratton 
>> Road, West Ashton, Trowbridge, United Kingdom BA14 6AZ
>>
>>
>>
>> On Fri, 12 Jul 2019 at 12:32, Peter Bernard Ladkin 
>> <ladkin at causalis.com <mailto:ladkin at causalis.com>> wrote:
>>
>>
>>
>>     On 2019-07-12 12:21 , Mike Rothon wrote:
>>     > The incident report is available on the NASA ASRS database at
>>     > https://asrs.arc.nasa.gov/search/database.html. Search by
>>     Report Number (ACN) for 1565516.
>>     >
>>     > It was a Cessna Citation 560XL, a mid-size business jet. These
>>     are reasonably well equipped, usually
>>     > a single or dual Honeywell Primus 1000 package (when built).
>>     >
>>     > I thought this system was capable of DME/DME as well, but I
>>     have no idea how the solution would be
>>     > compared or prioritised against a solid WAAS signal.
>>
>>     There is a presentation about the airport (KSUN, Hailey-Friedman
>>     Memorial Airport at Sun Valley,
>>     Idaho, from 2012 at
>>     http://iflysun.com/wp-content/uploads/2016/12/FMAA-Power-Point-Presentation-010312.pdf
>>     Horizon Air
>>     seems to fly in there, with Q400 aircraft and a custom RNP (one
>>     slide says they don't use the "Y"
>>     procedure). There are two poor-resolution approach plates, RNP-W
>>     and RNP-Y, both for RWY 31.
>>
>>     There are better-resolution plates available on the WWW, for example:
>>     RNAV Y RWY 31
>>     https://resources.globalair.com/dtpp/globalair_06239RY31.PDF
>>     RNAV X RWY 31
>>     https://resources.globalair.com/dtpp/globalair_06239rx31.pdf
>>     RNAV W RWY 31
>>     https://www.platinumairways.org/files/DOTW_Charts/KSUNcharts.pdf
>>
>>     There is part of the sectional at
>>     https://skyvector.com/?ll=43.503780556,-114.295558333&chart=301&zoom=1
>>     There is a fairly wide E-W
>>     plain south of the airport, at elevations 4800'-6000' it seems,
>>     and the mountains start about where
>>     the airport is, with peaks at over 10,000' N, E and W.
>>
>>     Besides the RNAV, there is an NDB/DME approach also, coming off
>>     an NDB and DME which is about 10nm
>>     away from the airport. Decision point (visual contact) is about
>>     5nm away from the runway, and 5nm
>>     beyond the NDB/DME installation. There is no kit at the airport
>>     itself.
>>
>>     Fix PRESN is named in the report. PRESN is an IAF for all these
>>     approaches. Note the controller says
>>     tower says AC just reported PRESN, and ARTCC radar was showing
>>     him 12nm NW of that.
>>
>>     The plates give the WAAS data, so KSUN is served by WAAS. Hard to
>>     say how well, though.
>>
>>     The MSA is 13,000, and they were performing an approach to an
>>     airport at 5320' (note two of the
>>     above plates have this, and one has 5318'), so they will be
>>     spending a lot of time on that approach
>>     below the tops of the terrain, which in the vicinity of the
>>     airport go up to almost 9000'. To be
>>     12nm off track in that situation is exceptionally dangerous. To
>>     see on the plate where the AC was
>>     when he thought he had just passed PRESN, note that JUNOL to
>>     CAKIR (the go-around point on the RNAV
>>     approach) is about 10nm.
>>
>>     I agree with Mike's assessment that the incident is "chilling".
>>
>>     In comment on Dewi's and John's speculation that he might have
>>     been operating with non-certified
>>     kit, given it was a Citation I doubt it. In response to Dewi's
>>     query if it is legal to fly IFR with
>>     non-installed kit, the answer is no. The aircraft can only use
>>     installed and regularly calibrated
>>     kit and it is in the maintenance logbook what that is (with the
>>     certificates if it is installed
>>     post-delivery).
>>
>>     That doesn't stop the cowboys, though. But they tend to stop
>>     themselves, in Darwinian fashion -
>>     every US flight school has its story about the pilot who used to
>>     go file IFR here and there without
>>     an IFR rating - and how long he lasted (it is invariably a male,
>>     and invariably a couple of years at
>>     most).
>>
>>     PBL
>>
>>     Prof. Peter Bernard Ladkin, Bielefeld, Germany
>>     MoreInCommon
>>     Je suis Charlie
>>     Tel+msg +49 (0)521 880 7319 www.rvs-bi.de <http://www.rvs-bi.de>
>>
>>
>>
>>
>>
>>     _______________________________________________
>>     The System Safety Mailing List
>>     systemsafety at TechFak.Uni-Bielefeld.DE
>>     <mailto:systemsafety at TechFak.Uni-Bielefeld.DE>
>>     Manage your subscription:
>>     https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety
>>
>>
>> _______________________________________________
>> The System Safety Mailing List
>> systemsafety at TechFak.Uni-Bielefeld.DE
>> Manage your subscription:https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety
> -- 
> Peter Bishop
> Chief Scientist
> Adelard LLP
> 24 Waterside, 44-48 Wharf Rd, London N1 7UX
> http://www.adelard.com
> Recep:  +44-(0)20-7832 5850
> Direct: +44-(0)20-7832 5855
>
> Registered office: 5th Floor, Ashford Commercial Quarter, 1 Dover Place,
> Ashford, Kent TN23 1FB
> Registered in England & Wales no. OC 304551. VAT no. 454 489808
>
> This e-mail, and any attachments, is confidential and for the use of
> the addressee only. If you are not the intended recipient, please
> telephone 020 7832 5850. We do not accept legal responsibility for
> this e-mail or any viruses.
>
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
> Manage your subscription: https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20190713/85e1a9ae/attachment-0001.html>