[SystemSafety] GPS jamming

Sat Jul 13 18:31:06 CEST 2019

Hi,

it´s been some time that I contributed to this list. Today, I do it as I
am a bit ´´lost´´.

Galileo is certified to be accurate, approved, encoded (parts of it) and
more, multiple industries: the works.

Now, please check this status page:
https://www.gsc-europa.eu/system-status/user-notifications

As I am writing this, it -partly- looks like this:

Thus, NAGU 2019025 is active.
https://www.gsc-europa.eu/notice-advisory-to-galileo-users-nagu-2019025

Text:

  NOTICE ADVISORY TO GALILEO USERS (NAGU) 2019025

DATE GENERATED (UTC): 2019-07-11 14:45
NAGU TYPE: GENERAL
NAGU NUMBER: 2019025
NAGU SUBJECT: SERVICE DEGRADATION
NAGU REFERENCED TO: N/A
START DATE EVENT (UTC): 2019-07-11 01:00
END DATE EVENT (UTC): N/A
SATELLITE AFFECTED: ALL
EVENT DESCRIPTION: UNTIL FURTHER NOTICE, USERS MAY EXPERIENCE SERVICE
DEGRADATION ON ALL GALILEO SATELLITES. THIS MEANS THAT THE SIGNALS MAY
NOT BE AVAILABLE NOR MEET THE MINIMUM PERFORMANCE LEVELS DEFINED IN THE
SERVICE DEFINITION DOCUMENTS AND SHOULD BE EMPLOYED AT USERS’ OWN RISK.
THE NOMINAL SERVICE WILL BE RESUMED AS SOON AS POSSIBLE.
Download NAGU (.txt)
<https://www.gsc-europa.eu/sites/default/files/NOTICE_ADVISORY_TO_GALILEO_USERS_NAGU_2019025.txt>

Updated:Jul 11, 2019

The NAGU became active 2 days ago....and I expected an updated message
to arrive in very short order, like hours... but no message (´Galileo is
healthy again´) was published.

So, Galileo is essentially unserviceable (=my interpretation, I am not a
GNSS expert)......yet, I couldn´t find anything in the newspapers on this.

Any idea how severe this is, how significant ? My feelings tell me it´s
very significant.

Best,

Klaus Sievers

P.S.: I asked their helpdesk, but didn´t get a reply yet.

Am 13.07.2019 um 16:25 schrieb Olwen Morgan:
>
>
> 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
>
> _______________________________________________
> 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/bc27e8bf/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nlagbiijdeadlakb.png
Type: image/png
Size: 52099 bytes
Desc: not available
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20190713/bc27e8bf/attachment-0001.png>