SYSTEM, METHOD AND COMPUTER PROGRAM PRODUCT FOR DETECTION OF GNSS JAMMERS

Abstract

A system, computer program product and method facilitating safe motion of objects, comprising providing GNSS jammer detection functionality, including a hardware processor configured to detect jammers, to at least one networked fleet including plural moving objects, wherein at least one object has, aboard, GNSS functionality and a hardware processor, and wherein information indicative of at least one GNSS jammer position is shared between the plural moving objects.

Claims

1. A method facilitating safe motion of objects, the method comprising providing GNSS jammer detection functionality, including a hardware processor configured to detect jammers, to at least one networked fleet including plural moving objects, wherein at least one object has, aboard, GNSS functionality and a hardware processor, and wherein information indicative of at least one GNSS jammer position is shared between said plural moving objects.

2. The method of claim 1 wherein said GNSS jammer detection functionality includes functionality for identifying positions of GNSS jammers.

3. The method of claim 1 wherein the plural moving objects each use a satellite navigation system and wherein the hardware processor is configured to maintain a table of jammed positions, each of which is indicative of a possible GNSS jammer position, and wherein at least a portion of said table is shared between the plural moving objects.

4. The method of claim 2 and also comprising a GNSS jammer position output generator, including a hardware processor configured to generate and present a display of an area, in which the moving object is moving, in which various levels of jamming intensity are differentially presented.

5. The method of claim 4 wherein said various levels of jamming intensity are color-coded.

6. The method of claim 4 wherein said hardware processor is configured to connect geographical positions for which a first level of jamming intensity was detected, to yield a first polygon which is presented in a first manner, and also to connect geographical positions for which at least a second level of jamming intensity was detected, to yield at least one second polygon which is presented in a second manner.

7. The method of claim 1 wherein said moving objects include at least one of the following groups: an aircraft, a drone, a car or other ground vehicle and a maritime vessel.

8. The method of claim 3 wherein the hardware processor is configured to determine that certain object positions in the table of jammed positions are GNSS jammer positions, if a certain criterion is satisfied (e.g. the direction from which the jamming is coming from is a previously known GNSS jammer position).

9. The method of claim 8 wherein at least one object position which has been determined to be a GNSS jammer position is shared between the plural moving objects and wherein at least one object position which has not been determined to be a GNSS jammer position is not shared between the plural moving objects.

10. The method of claim 6 wherein said first polygon presented in a first manner is presented as a first semi-transparent colored region having a first color and superimposed over a map of the area and wherein said second polygon presented in a second manner is presented as a second semi-transparent colored region having a second color, different from said first color, and superimposed over the map of the area.

11. The method of claim 1 wherein radio communication is provided between the plural moving objects thereby to yield a networked fleet of moving objects.

12. The method of claim 2 wherein said functionality for identifying positions of GNSS jammers processes GNSS data but GNSS data which is pre-known not to be reliable for identifying positions of GNSS jammers are filtered out rather than being processed.

13. The method of claim 12 and wherein said GNSS data which is pre-known not to be reliable includes GNSS data pertaining to a time in which an aircraft is engaged in extreme maneuvers.

14. The method of claim 3 and wherein said satellite navigation system comprises GNSS.

15. A system facilitating safe motion of objects, wherein at least one object has, aboard, GNSS functionality and a hardware processor the system comprising: GNSS jammer detection functionality residing on a hardware processor in data communication with at least one networked fleet including plural moving objects, which is configured to generate information indicative of at least one GNSS jammer position for sharing between said plural moving objects.

16. A computer program product, comprising a non-transitory tangible computer readable medium having computer readable program code embodied therein, said computer readable program code adapted to be executed to implement a method facilitating safe motion of objects, the method comprising: providing GNSS jammer detection functionality including a hardware processor configured to detect jammers, to at least one networked fleet including plural moving objects, wherein at least one object has, aboard, GNSS functionality and a hardware processor, and wherein information indicative of at least one GNSS jammer position is shared between said plural moving objects.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0052] Example embodiments are illustrated in the various drawings. Specifically:

[0053] FIGS. 1a-1b, taken together, form a simplified flowchart illustration of a jammer position detection method according to certain embodiments; the method may include all or any subset of the operations 10, 20, . . . shown and described herein, in any suitable order e.g. as shown.

[0054] FIG. 2a is a simplified block diagram illustration of an example architecture for a jammer detection system according to certain embodiments; all or any subset of the illustrated functionalities, all or any subset of the illustrated inputs, and all or any subset of the illustrated outputs, may be provided. The architecture may employ, typically repeatedly e.g. continuously, or periodically e.g., say, once per second, any suitable jammer position detection method e.g. the method of FIGS. 1a-1b, taken together, or any subset of its operations, in any suitable order.

[0055] FIG. 2b is a pictorial illustration of a map or visual display that may be generated by a GNSS jammer position output generator e.g. hardware processor and presented to an operator, using color-coding (say) to represent several e.g. 3 areas of higher vs. lower levels of jamming intensity.

[0056] FIG. 3 is a semi-block diagram semi-pictorial illustration of a fleet of networked vehicles or platforms, with communication e.g. radio communication therebetween, wherein each vehicle or member in the fleet is configured to utilize a jammer detection system according to certain embodiments.

[0057] Certain embodiments of the present invention are illustrated in the drawings; in the block diagrams, arrows between modules may be implemented as APIs and any suitable technology may be used for interconnecting functional components or modules illustrated herein in a suitable sequence or order e.g. via a suitable API/Interface. For example, state of the art tools may be employed, such as but not limited to Apache Thrift and Avro which provide remote call support. Or, a standard communication protocol may be employed, such as but not limited to HTTP or MQTT, and may be combined with a standard data format, such as but not limited to JSON or XML.

[0058] Methods and systems included in the scope of the present invention may include any subset or all of the functional blocks shown in the specifically illustrated implementations by way of example, in any suitable order e.g. as shown. Flows may include all or any subset of the illustrated operations, suitably ordered e.g. as shown. Tables herein may include all or any subset of the fields and/or records and/or cells and/or rows and/or columns described.

[0059] Computational, functional or logical components described and illustrated herein can be implemented in various forms, for example as hardware circuits such as but not limited to custom VLSI circuits or gate arrays, or programmable hardware devices such as but not limited to FPGAs, or as software program code stored on at least one tangible or intangible computer readable medium and executable by at least one processor, or any suitable combination thereof. A specific functional component may be formed by one particular sequence of software code, or by a plurality of such, which collectively act or behave or act as described herein with reference to the functional component in question. For example, the component may be distributed over several code sequences, such as but not limited to objects, procedures, functions, routines and programs, and may originate from several computer files which typically operate synergistically.

[0060] Each functionality or method herein may be implemented in software (e.g. for execution on suitable processing hardware such as a microprocessor or digital signal processor), firmware, hardware (using any conventional hardware technology such as Integrated Circuit technology) or any combination thereof.

[0061] Functionality or operations stipulated as being software-implemented may alternatively be wholly or fully implemented by an equivalent hardware or firmware module, and vice-versa. Firmware implementing functionality described herein, if provided, may be held in any suitable memory device and a suitable processing unit (aka processor) may be configured for executing firmware code. Alternatively, certain embodiments described herein may be implemented partly or exclusively in hardware, in which case all or any subset of the variables, parameters, and computations described herein may be in hardware.

[0062] Any module or functionality described herein may comprise a suitably configured hardware component or circuitry. Alternatively or in addition, modules or functionality described herein may be performed by a general purpose computer, or more generally by a suitable microprocessor, configured in accordance with methods shown and described herein, or any suitable subset, in any suitable order, of the operations included in such methods, or in accordance with methods known in the art.

[0063] Any logical functionality described herein may be implemented as a real time application, if and as appropriate, and which may employ any suitable architectural option, such as but not limited to FPGA, ASIC or DSP, or any suitable combination thereof.

[0064] Any hardware component mentioned herein may in fact include either one or more hardware devices e.g. chips, which may be co-located or remote from one another.

[0065] Any method described herein is intended to include, within the scope of the embodiments of the present invention, also any software or computer program performing all or any subset of the method's operations, including a mobile application, platform or operating system e.g. as stored in a medium, as well as combining the computer program with a hardware device to perform all or any subset of the operations of the method.

[0066] Data can be stored on one or more tangible or intangible computer readable media stored at one or more different locations, different network nodes, or different storage devices at a single node or location.

[0067] It is appreciated that any computer data storage technology, including any type of storage or memory and any type of computer components and recording media that retain digital data used for computing for an interval of time, and any type of information retention technology, may be used to store the various data provided and employed herein. Suitable computer data storage or information retention apparatus may include apparatus which is primary, secondary, tertiary or off-line, which is of any type or level or amount or category of volatility, differentiation, mutability, accessibility, addressability, capacity, performance and energy use, and which is based on any suitable technologies, such as semiconductor, magnetic, optical, paper, and others.

DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS

[0068] Certain embodiments e.g. as described herein seek to provide a system and method for detecting that an aircraft or other vehicle is being jammed, and for computing position of the GNSS jammer, if anytypically by constantly or continuously or frequently monitoring data which may be aircraft-provided. Typically, the data is provided by the aircraft's navigation system e.g. GNSS receiver and/or INS. If an aircraft is being jammed, an alert may be provided to the operator e.g. by displaying a message on the operator's navigation screen and/or by playing a vocal alert. Typically, there are plural such aircraft (or, more generally, plural members of a networked fleet).

[0069] The GNSS jammer position is typically computed by bootstrapping estimates of the GNSS jammer position provided by the vehicle/plural vehicle (or, more generally, here and vis a vis all other references to vehicle herein, by plural members of a networked fleet). Any suitable method may be used to combine jammer position estimates generated by a fleet member/various fleet members, such as simple averaging or weighted averaging using any suitable weights which may be based, say, on how reliable a given jammer position estimate is judged to be; for example if a fleet member is engaging in extreme maneuvers, its position estimate, if provided at all, rather than being filtered out, may be judged as relatively unreliable; and/or on how recent a reliable jammer position estimate is. It is appreciated that any suitable technology may be employed to group estimates so as to identify the number of jammers which appear to be present, and to determine which estimates apply to which jammer, such as cluster analysis.

[0070] It is appreciated that each networked member's estimate of a jammer position may be determined as a function of that member's own position as best known e.g. to the member himself/itself. This self-position estimate may be based on GNSS data or, if the GNSS data contributing to a self-position is deemed unreliable because the fleet member suspects a jammer is in the fleet member's vicinity (e.g. identifies that reception is poor, as in below-threshold), the self-position estimate may be computed by the networked member based on the most recent self-position that is deemed reliable (e.g. the most recent position computed while reception was deemed above-threshold), updated using velocity and/or acceleration and/or position data which may, for example, be provided by the aircraft's avionics systems, or by self-positioning or navigation subsystems serving other vehicles.

[0071] Typically, the system does not assume there is or is not a GNSS jammer about. Typically, series of collected data (e.g. by the vehicle) are analyzed e.g. according to a suitable data model including rules (e.g. what is the legal number of available GNSS satellites) and/or computational functions (e.g. geometrical median) in order to determine the jamming situation and/or in order to determine a jammer position. The model typically can be updated during the system's life cycle, by the solution supplier and/or by the customer. Developing the model includes collecting raw data (e.g. aircraft maneuver) from the avionics systems and from experts (e.g. common range of jammers typesevery jammer type has its unique characteristics including its range, static or dynamic position, and coverage). The data model is typically tested with recording files from the system. Typically, during the development process of the system, record files are generated, of real or simulated avionic and jammers data produced during real or simulated flights. The system developers may use those files to generate an accurate model. The system may be expected to locate the position of the jammers which were used during the development phase. The data model typically includes a data structure (such as an XML structure) and/or rules that may be applied to data elements (e.g. when number of available satellites is less than 4, the vehicle is assumed to be jammed). This allows the system to differentiate jamming from other situations such as breakdown or a temporary blocking.

[0072] The system or method may include a Filtering Process (e.g. ignoring aircraft maneuver in which a GNSS satellite may not be reliable) in order to update the data model and/or to verify that the jamming event is real. The algorithm of FIG. 2a, e.g. any suitable process for estimating GNSS jammer positions such as the method of FIGS. 1a-1b, taken together, may then take place or be executed, only for inputs that the filtering process passes or allows, e.g. to eliminate information that may produce false positive indications, for example, when the aircraft is engaged in flight involving extreme maneuvers (e.g. the aircraft flying upside down, extreme (over threshold) acceleration, sharp (number of radians over threshold) turn, etc.; it is appreciated that each aircraft can become aware of such situations from its own avionics systems. Thus, GNSS data may be filtered out rather than being processed, each time the aircraft is engaged in flight involving extreme maneuvers. Alternatively, GNSS data may be weighted differently, depending on an extent to which the aircraft is engaged in flight involving extreme maneuvers.

[0073] The filtering process may be applied as a function of all or any subset of the following information: [0074] 1. aircraft maneuver [0075] 2. Data Sample rate [0076] 3. Sequence of jamming events

[0077] The system may determine that the vehicle is being jammed, according to all or subset of the following information or criteria which are indicative thereof, especially in combination: [0078] 1. Satellite/s used by the navigation system on the platform is/are different than expected [0079] 2. The direction from which the GNSS transmission is coming from, may be different than expected [0080] 3. Position error measurement provided by the GNSS is above a given threshold [0081] 4. Time error measurement is above a given threshold [0082] 5. GNSS position and INS position are different than expected [0083] 6. Information from another vehicle (optional) regarding a given position

[0084] A method of operation may be provided in accordance with certain embodiments, for areas in which a jammer may be present. For each geographic position there may be a data structure (subset of the data model) which represents a typical situation. Typically, the profile is a set of data, stored in memory by the platform, that presents the definition and the behavior of an object (e.g. a profile which includes the geographical position of the jammer). Profile behavior may include expected or typical or observed operation hours and or range of a jammer. Then, according to the behavior of the object, the system can determine if there is an exception which can imply a jamming situation. For example, when the position error received by the GNSS is bigger than the expected profile behavior, this may mean (e.g. at a certain confidence level) that the vehicle is being jammed. If the position error that is being received by the GNSS is smaller or equal to the expected profile behavior, the vehicle is probably (e.g. at a certain confidence level) not being jammed. For example, when the time error received by the GNSS is bigger than the expected profile behavior, this may mean (e.g. at a certain confidence level) that the vehicle is probably being jammed. If the time error that is being received by the GNSS is smaller or equal to the expected profile behavior, the vehicle is probably (e.g. at a certain confidence level) not being jammed.

[0085] The method typically comprises all or any subset of the following operations, suitably ordered e.g. as follows: [0086] a. The system receives information (e.g. navigation data) [0087] b. The system filters the data to process only reliable information, and discards unreliable information [0088] c. The system compares the incoming data (e.g. as filtered) with expected data e.g. as defined in a previously stored profile.

[0089] Inputs to the method and system shown and described herein may (e.g. as shown in FIG. 2a) include all or any subset of the following which may be provided at any suitable interval e.g. periodically e.g. once per second: [0090] 1. Data from vehicle's CRPA (controlled Reception Pattern Arrayadjustable antenna) Antenna (if available) [0091] 2. Data from vehicle's GNSS (Global Navigation Satellite System). It may be assumed that after the filter process, the GNSS data can be handled by the jamming position detection method of FIG. 2a to imply a jamming situation. [0092] 3. Data from vehicle's INS (Inertial Navigation Systems, may optionally be GNSS-aided) [0093] 4. Other vehicle data (information that define vehicle's position and/or vehicle clock) provided by smart sensors on the vehicle [0094] 5. Number of GNSS satellites available-data may be supplied by the vehicle's GNSS navigation system, periodically, e.g. once per second [0095] 6. Position of GNSS satellites-may be supplied by the vehicle's GNSS navigation system, periodically, e.g. once per second [0096] 7. Common jammers range of operation-typically, the system maintains a jammer DB, that may collect information regarding (e.g. range of operation of) jammers which have been encountered to date, by a given vehicle A and typically also by other vehicle which cooperate with vehicle A. [0097] The jammer DB maintains or stores position and type information regarding jammers. This information is typically continuously updated from all or any subset of the following three resources: [0098] R1. Available offline information regarding known jammers (such as jammer information that was reported from other aircrafts from previous flights, previous knowledge from other resources, such as law enforcement). [0099] R2. On Line information from the processor's own vehicle [0100] R3. Network information from other vehicles networked to the processor's own vehicle. [0101] The information held by the jammer DB may include both information regarding positions of jammers in the area, and/or technical information characterizing various jammer types (i.e. range of operation, size etc.). [0102] 8. DTM-Digital Terrain Model/s. typically, the system maintains terrain data repository, that stores information regarding the terrain over which the aircraft is flying such as a DTM or digital elevation model e.g. as described here: https://en.wikipedia.org/wiki/Digital_elevation_model. [0103] 9. Jamming intensity and continuity (typically of jammers previously encountered, by a given vehicle A and/or by other vehicle which cooperate with e.g. are networked with vehicle A.

[0104] FIG. 3 is a semi-pictorial diagram of the system, including at least one hardware processor that may perform the method of FIGS. 1a-1b, taken together, described herein, or known equivalents or any subset of the operations of FIGS. 1a-1b, taken together. The processor typically resides on each platform, e.g. vehicle, where each vehicle typically includes legacy sensors such as but not limited to all or any subset of the following: CRPA sensors, GNSS sensors, INS sensors, DTM sensors, e.g. as shown in FIG. 2a.

[0105] The platforms typically comprise networked platforms e.g. using radio communication to send and receive from one platform to another (such as Eurocontrol) which may be regulated by any suitable standard, such as for example a User's Manual such as [0106] https://www.eurocontrol.int/publication/ifps-users-manual

[0107] The method of FIGS. 1a-1b, taken together, may compute the position of the jammer even without the CRPA, by using information from the vehicle's long-term memory (saved from the vehicle or received from other vehicles) regarding the same area, by performing polygon's intersection.

[0108] The CRPA information may be used when the CRPA communicates with the algorithm of FIG. 2a on the vehicle. The method may be the same for both cases, except from using Long Term MemoryLTM e.g. information accumulated from previous flights that can be used e.g. in a specific profile for accurate positioning of the jammer when the CRPA is not available in subsequent flights, in order to determine jammer position during at least one subsequent flight.

[0109] The method of FIGS. 1a-1b, taken together, may include all or any subset of the following operations, suitably ordered e.g. as follows:

[0110] Operation 10: sampling all or any subset of the GNSS jamming indications values, periodically at a suitable rate such as once a second (1 HZ rate). Typically, all operations of FIGS. 1a-1b, taken together, are performed sequentially, periodically, e.g. once a second. The values sampled typically include general data and/or aircraft maneuver information and/or aircraft position information.

[0111] The general data typically includes all or any subset of the following: [0112] 10i. N, Number of available satellites (an input from the vehicle's navigation system) is less than the expected. The expected number may be known to the system using prior knowledge from a GNSS system expert. Typically, between 4-7 satellites are available in a GPS system. [0113] 10ii. S, Satellites used by the GNSS (an input from the vehicle's navigation system) have different (ID) than expected (to be determined according to the GNSS system expert, according to the GNSS system almanac).

[0114] As described in https://www.spirent.com/blogs/2011-05-12_gps_almanac, in the art of satellite navigation systems, the almanac is a regularly updated digital schedule of satellite orbital parameters for use by GNSS receivers. The almanac for any given GNSS consists of coarse orbit and status information covering every satellite in the constellation, the relevant ionospheric model and time-related information. For example, the GPS almanac provides the necessary correction factor to relate GPS time to co-ordinated universal time (UTC). The major role of the almanac is to help a GNSS receiver to acquire satellite signals from a cold or warm start by providing data on which satellites may be visible at any given time, together with their approximate positions. An ephemeris message is still required from each satellite for the receiver to compute the exact position, but it is the almanac for the constellation that gives the receiver its starting point.

[0115] The ionospheric model contained within the almanac is essential for single-frequency receivers to correct for ionospheric errors-the largest error source for GPS receivers. However, modern dual-frequency receivers have no need for this data as the dual-frequency design can correct for such errors without any assumed model. [0116] 10iii. Po, Position error measurement (an input from the vehicle's navigation system indicating the possible error in the vehicle's own position) [0117] 10iv. T, Time error measurement (an input from the vehicle's navigation system indicating the possible error in knowledge of the current time) [0118] 10v. Current gap g (aka current computed result), computed by combining all or any subset of the 4 above parameters, e.g.

g=W1*N+W2*S+W3*Po+W4*T

[0119] It is appreciated that N, S, Po and T each contribute to the error hence gap g. Typically, the weights are determined according to experimentation, including many measurements by a human expert before activating the system. In order to set up the weights, a simulation environment may be built that simulates, typically off-line e.g. during development of the system shown and described herein, GNSS jammers in a pre-known position and vehicle data (e.g. navigation data). A human expert may determine the weights in order to locate the pre-known position of the GNNS jammers. This process is typically run several times and in several scenarios in order to build a reliable algorithm. [0120] 10vi. Gap indicator G (aka standard computed result), standard error hence standard gap G. G is stored in the system's long term memory and is based on field tests (flight+simulation environment) in which the process was used in order to locate jammers. [0121] G=Average (g(1) . . . g(N)) (previous computed results-in case that g(i) is less than 3 standard deviations that were computed for g(1) . . . g(N)) [0122] 10vii. The aircraft maneuver information typically includes all or any subset of the following: Current Pitch, Roll, Yaw values, designated herein as p r y respectively; and/or maximum allowed values (which may be based on expert knowledge) for Pitch, Roll, Yaw, designated herein as P R Y respectively. [0123] 10viii. The vehicle position information typically includes all or any subset of the following: [0124] a. Current vehicle position according to GNSS, INS, GNSS/INS (the navigation system provides all the relevant information which may include only GNSS, may include only INS, and may combine both (blended solution). [0125] b. Vehicle position gap gap_c which represents the actual difference between the current vehicle position as per the blended solution, and the vehicle position based only on INS. [0126] c. Expected vehicle position gap drift_C which represents the expected difference between the current vehicle position as per the blended solution, and the vehicle position based only on INS. [0127] Each INS system has unique drift rate. [0128] drift_C typically includes Flight Time (hours) and/or Drift per hour (predefined drift, which may be expressed in nanometers, which is expected per hour), thus allowing the Expected drift_C to be computed by multiplying Flight Time X Drift per hour.

[0129] Operation 20: If (g>G or gap_c>drift_C) and (p<P and r<R and y<Y) then add the current position of the vehicle to jammed positions table at index i and go to operation 30, otherwise discard the current position of the vehicle and go to operation 10.

[0130] Operation 30: compute the CIntensity (Current intensity, which indicates the level or intensity of jamming encountered at the vehicle's current position). This may be computed using the following formula: CIntensity=(Wgap_c*gap_c+Wg*g)) of the current position. Add CIntensity to jammed positions table at index i. A human expert may determine the weights Wgap_c, Wg.

[0131] Operation 40: compute the average, ACIntensity, of the most recent N CIntensity values. [0132] Add ACIntensity to jammed positions table at index i. [0133] CP=Current vehicle position jamming classification [0134] ACIntensity=Average (CIntensity (1) . . . . CIntensity (N)) [0135] If ACIntensity>=Hard Criterion, CP=HARD [0136] If ACIntensity<Hard Criterion and ACIntensity>=Med Criterion, CP=MED [0137] If ACIntensity<Low Criterion, CP=LOW

[0138] Hard Criterion, Med Criterion, Low Criterion is based on expert knowledge

[0139] Add the classification (e.g. HARD/MED/LOW) to jammed positions table at index i.

[0140] Operation 50: Compute the vehicle position: [0141] If the vehicle is jammed (CP/LOW): [0142] vehicle position=last reliable vehicle position+((velocity in X, Y and Z axis)*delta time) [0143] last reliable vehicle position=vehicle position [0144] Else, last reliable vehicle position is the vehicle position according to the blended solution.

[0145] Operation 60: read the direction, absolute and/or relative) of the jamming from the vehicle's CRPA antenna (a feature in the CRPA interface). If no CRPA antenna is available, long term memory, which stores data from the past e.g. data collected when a CRPA antenna was available, may be used, and/or using the jammer position from other vehicles.

[0146] Relative jammer direction typically comprises the direction of the jammer according to the CRPA antenna (relative to the aircraft maneuver).

[0147] Absolute jammer direction typically comprises a computed direction of the jammer relative to a reference direction, e.g. the north (aircraft direction relative to the north+/?relative jammer direction).

[0148] Absolute jammer direction=(aircraft direction relative to the north)+/?(relative jammer direction)

[0149] Direction vector typically comprises a vector from the current vehicle position to the jammer according to the jammer's absolute jammer direction. The starting point or origin of the vector typically comprises the current position of the vehicle.

[0150] Direction vector=last reliable vehicle position+Absolute jammer direction Add the direction vector to jammed positions table at index i.

[0151] Operation 70: Build a jammed areas map which maps jammed areas. If the jammed position classification is greater than MED (e.g. is HARD), send the position and the CIntensity to the vehicles network in order to build a jammed areas map that presents jammed areas' locations and/or the intensity of each such area.

[0152] Operation 80: Compute the range (distance) of the vehicle from the jammer according to all or any subset of the following data, inter alia: [0153] 70i: The range is computed according the CIntensity (operation 30) and a predefined table which may be based on a priori expert knowledge. It is appreciated that, typically, the stronger the intensity, the shorter the range. [0154] e.g. range=a*CIntensity+b, where a and b are constants [0155] 70ii: DTM (Digital Terrain Model) data characterizing the terrain over which the aircraft is flying to determine the range from the jammer position by computing the intersection between the direction vector (operation 50) and the surface (geographic position) e.g. as described in the following:. [0156] e.g. https://en.wikipedia.org/wiki/Line%E2%80%93plane_intersection [0157] 70iii: Using predefined jammers range (which may be stored in the system's long-term memory). For example, if the strongest or highest intensity of the known jammers can jam GNSS in a range of 50 KM, the range may not exceed 50 KM.

[0158] Operation 90: Compute the position of the jammer by using the vehicle position and the range.

[0159] Current jammer position=vehicle position+range (according to the direction) Add the current jammer position to jammed positions table at index i.

[0160] Operation 100: Define if a jammer position is a new one or belongs to other jammers in the area. The operation 100 may include operations 100i and/or 100ii, e.g. as described below.

[0161] Operation 100i: The system may assume that all jammers in a predefined area (e.g. in a vicinity e.g. circle whose radius is a predefined value, surrounding a given vehicle) are the same jammer, in which case the system may receive second estimations of jammer position (if any exist) from other vehicle within the predefined vicinity (jammer range), within a time-interval of predefined duration (seconds, for example 35 seconds).

[0162] Operation 100ii: Retrieve, e.g. from the vehicle's long-term memory or wherever the jammer database described herein is stored), information regarding position of jammers in this specific area (predefined vicinity of the vehicle position e.g.) in a time-interval of predefined duration, such as 35 seconds.

[0163] Operation 110: Compute the distance between the current jammer position and the median of the previous jammer position E.g. using distance=current jammer position?median(jammer position (1) . . . jammer position (N))

[0164] If the distance is bigger than half of the jammer range (for example: 5 KM) ignore it, else continue.

[0165] Operation 120: Compute a geometrical median function (e.g. https://en.wikipedia.org/wiki/Geometric_median) of the computed jammer position (operation 90) and/or jammer positions from long-term memory and/or jammer position from other vehicles, with the previous geometrical median in order to derive the jammer's updated position. For example:

[0166] Median Jammer position=geometrical median (jammer position (1) . . . jammer position (N))

[0167] If 75% (predefine value) of the estimated jammer positions in the past are located within a distance of, say, 2 standard deviations, or less than, say, 100 meters, from the current computed median, this validates assuming that the jammer exact position is the Median Jammer position (geometrical median).

[0168] If the jammer exact position is valid the method typically proceeds to operation 140.

[0169] Operation 130: Store the Median Jammer position, if any, computed in operation 120, in a repository for the next iteration (that begins in operation 10)

[0170] Operation 140: The jammer exact position may be published to the user (operator/other vehicles) after a predefined percentage (for example: 90%) of the last N measurements (predefined number of jammer positions) comply with the terms in operation 120. In addition, the average standard deviation of the last N measurements may be published (as a quality criteria). In addition, this information may be updated on the jammed areas map.

[0171] Use cases include identifying jammers which are hampering aircraft including commercial aircraft whose flight routes hardly change. At least in civilian use-cases, flight routes are well defined, hence can support building a reliable database storing information regarding jammers typically including jammer position/s and/or types (e.g. by sharing the information between the aircrafts). The fact that aircraft typically fly along predefined routes can provide more computed jammer positions in the same area, which facilitates provision of precise jammer positions.

[0172] Finding the position of a GNSS jammer may facilitate elimination of the GNSS jammer by local law enforcement authorities, in order to make flights safer or plan alternative routes which have less GNSS jamming, or no GNSS jamming, and/or, alerting other objects e.g. airplanes about a GNSS jammer allows these objects to refrain from entering the range of the GNSS jammer and/or to use an alternative other than GNSS, for navigation.

[0173] According to certain embodiments, each object moving in a jamming area (region in which a jammer is operating) computes the jammer position plural times e.g. periodically e.g. at least once a second. As computations accumulate, the accuracy of the estimated position of the jammer, improves.

[0174] If a specific vehicle allocates or detects a jammer position, at a threshold level of accuracy (e.g. if the vehicle manages to accumulate enough samples, according to operation 120), then that vehicle's data (including jammer position estimation) may be shared with other vehicle that may then use that data to improve their own computing of the jammer position, or to further improve the estimate of the jammer's position.

[0175] Outputs of the flow of FIGS. 1a-1b, for each iteration thereof performed by a given vehicle, typically includes all or any subset of the following: [0176] a. Position of the jammer e.g. as estimated in operation 120; and/or [0177] b. Approximated position error e.g. the estimated error in the jammer position e.g. as computed in operation 140. [0178] c. A map of jammed areas that may be distributed to others e.g. to other networked objects e.g. as shown in FIG. 2b.

[0179] Typically, a DB is maintained which contains geographical positions where the vehicle has been. The distance in meters (or time interval) between adjacent geographic positions is typically constant. For each geographic position, the encountered jamming intensity level (HARD/MED/LOW) is saved, and colored polygons (which may be, say, red, yellow) are generated by connecting all geographical positions for which the level of jamming intensity encountered was MED, to yield a first polygon which is colored yellow (say), and, similarly, connecting all geographical positions for which the level of jamming intensity encountered was HARD to yield a second polygon, and coloring that polygon red (say).

[0180] Alternatively, or in addition, the polygons' colors may indicate a probability or confidence that a jammer is present.

[0181] In FIGS. 2b, 3 (by way of example) various colors indicating various levels of jamming intensity are represented in monochrome as forward slanting hatching (///), back-slanting hatching (\\\), and no hatching, respectively.

[0182] This DB is shared between the vehicles (each vehicle creates its own map based on the information received from other vehicles and from its own system). A visual display may be presented, e.g. to operators, that show the vehicle in a jammed position area in the visual display, aka map. This data may be sent between the networked fleet members; the data sent may include the entire visual display, or data which enables the visual display to be generated by each fleet member using suitable graphics software configured to generate the display locally. Superposition of polygons onto a map showing known features of the region e.g. land boundaries, may be performed either locally or centrally.

[0183] Marking of each vehicle's position including the vehicle's (or networked fleet member more generally) own position may be performed either locally or centrally. The red area represents an area with HARD level of jamming intensity. The yellow area represents an area with MED level of jamming intensity. Typically, the map includes a designation of the center, right of center (RC), left of center (LC) and far right and left (R and L)from the viewpoint of the vehicle whose human operator is viewing the map. The map typically includes, e.g. as a visual representation, all estimated jammer positions detected by any of the networked objects. The map is typically updated periodically, e.g. once per second.

[0184] Typically, a GNSS jammer alert is shown or not shown to a human operator of a moving object in a given region and/or data regarding a suspected jammer and its position is or is not sent to other airplanes, and/or is or is not included in the map used by the networked airplanes, only if the position error is below a given e.g. predetermined or learned threshold. For example, a threshold position error may be 100 meters, since the method is able to achieve a position error of several e.g. less than 10 meters.

[0185] The map may contain information from other aircraft members in the same communication network which fly in the same operation area (based on the actual aircraft flying route, several miles from each direction of the route). Typically, the estimated position of a jammer converges to the jammer's true position, and the error of estimation approaches zero as objects generate more and more estimates of the jammer's position.

[0186] It is appreciated that terminology such as mandatory, required, need and must refer to implementation choices made within the context of a particular implementation or application described herewithin for clarity, and are not intended to be limiting, since, in an alternative implementation, the same elements might be defined as not mandatory and not required, or might even be eliminated altogether.

[0187] Components described herein as software may, alternatively, be implemented wholly or partly in hardware and/or firmware, if desired, using conventional techniques, and vice-versa. Each module or component or processor may be centralized in a single physical location or physical device, or distributed over several physical locations or physical devices.

[0188] Included in the scope of the present disclosure, inter alia, are electromagnetic signals in accordance with the description herein. These may carry computer-readable instructions for performing any or all of the operations of any of the methods shown and described herein, in any suitable order including simultaneous performance of suitable groups of operations, as appropriate. Included in the scope of the present disclosure, inter alia, are machine-readable instructions for performing any or all of the operations of any of the methods shown and described herein, in any suitable order; program storage devices readable by machine, tangibly embodying a program of instructions executable by the machine to perform any or all of the operations of any of the methods shown and described herein, in any suitable order i.e. not necessarily as shown, including performing various operations in parallel or concurrently rather than sequentially as shown; a computer program product comprising a computer useable medium having computer readable program code, such as executable code, having embodied therein, and/or including computer readable program code for performing, any or all of the operations of any of the methods shown and described herein, in any suitable order; any technical effects brought about by any or all of the operations of any of the methods shown and described herein, when performed in any suitable order; any suitable apparatus or device or combination of such, programmed to perform, alone or in combination, any or all of the operations of any of the methods shown and described herein, in any suitable order; electronic devices, each including at least one processor and/or cooperating input device and/or output device, and operative to perform, e.g. in software, any operations shown and described herein; information storage devices or physical records, such as disks or hard drives, causing at least one computer or other device to be configured so as to carry out any or all of the operations of any of the methods shown and described herein, in any suitable order; at least one program pre-stored e.g. in memory or on an information network such as the Internet, before or after being downloaded, which embodies any or all of the operations of any of the methods shown and described herein, in any suitable order, and the method of uploading or downloading such, and a system including server/s and/or client/s for using such; at least one processor configured to perform any combination of the described operations or to execute any combination of the described modules; and hardware which performs any or all of the operations of any of the methods shown and described herein, in any suitable order, either alone or in conjunction with software. Any computer-readable or machine-readable media described herein is intended to include non-transitory computer-or machine-readable media.

[0189] Any computations or other forms of analysis described herein may be performed by a suitable computerized method. Any operation or functionality described herein may be wholly or partially computer-implemented e.g. by one or more processors. The invention shown and described herein may include (a) using a computerized method to identify a solution to any of the problems or for any of the objectives described herein, the solution optionally including at least one of a decision, an action, a product, a service or any other information described herein that impacts, in a positive manner, a problem or objectives described herein; and (b) outputting the solution.

[0190] The system may, if desired, be implemented as a networke.g. web-based system employing software, computers, routers and telecommunications equipment, as appropriate.

[0191] Any suitable deployment may be employed to provide functionalities e.g. software functionalities shown and described herein. For example, a server may store certain applications, for download to clients, which are executed at the client side, the server side serving only as a storehouse. Any or all functionalities, e.g. software functionalities shown and described herein, may be deployed in a cloud environment. Clients, e.g. mobile communication devices, such as smartphones, may be operatively associated with, but external to the cloud.

[0192] The scope of the present invention is not limited to structures and functions specifically described herein and is also intended to include devices which have the capacity to yield a structure, or perform a function, described herein, such that even though users of the device may not use the capacity, they are, if they so desire, able to modify the device to obtain the structure or function.

[0193] Any if-then logic described herein is intended to include embodiments in which a processor is programmed to repeatedly determine whether condition x, which is sometimes true and sometimes false, is currently true or false and to perform y each time x is determined to be true, thereby to yield a processor which performs y at least once, typically on an if and only if basis e.g. triggered only by determinations that x is true, and never by determinations that x is false.

[0194] Any determination of a state or condition described herein, and/or other data generated herein, may be harnessed for any suitable technical effect. For example, the determination may be transmitted or fed to any suitable hardware, firmware or software module, which is known or which is described herein to have capabilities to perform a technical operation responsive to the state or condition. The technical operation may, for example, comprise changing the state or condition, or may, more generally, cause any outcome which is technically advantageous given the state or condition or data, and/or may prevent at least one outcome which is disadvantageous given the state or condition or data. Alternatively, or in addition, an alert may be provided to an appropriate human operator or to an appropriate external system.

[0195] Features of the present invention, including operations, which are described in the context of separate embodiments may also be provided in combination in a single embodiment. For example, a system embodiment is intended to include a corresponding process embodiment, and vice versa. Also, each system embodiment is intended to include a server-centered view or client centered view, or view from any other node of the system, of the entire functionality of the system, computer-readable medium, apparatus, including only those functionalities performed at that server or client or node. Features may also be combined with features known in the art and particularly although not limited to those described in the Background section or in publications mentioned therein.

[0196] Conversely, features of the invention, including operations, which are described for brevity in the context of a single embodiment or in a certain order, may be provided separately or in any suitable sub-combination, including with features known in the art (particularly although not limited to those described in the Background section or in publications mentioned therein), or in a different order. e.g. is used herein in the sense of a specific example which is not intended to be limiting. Each method may comprise all or any subset of the operations illustrated or described, suitably ordered, e.g. as illustrated or described herein. Devices, apparatus or systems shown coupled in any of the drawings may, in fact, be integrated into a single platform in certain embodiments, or may be coupled via any appropriate wired or wireless coupling, such as but not limited to optical fiber, Ethernet, Wireless LAN, HomePNA, power line communication, cell phone, Smart Phone (e.g. iPhone), Tablet, Laptop, PDA, Blackberry GPRS, Satellite including GPS, or other mobile delivery. It is appreciated that in the description and drawings shown and described herein, functionalities described or illustrated as systems and sub-units thereof can also be provided as methods and operations therewithin, and functionalities described or illustrated as methods and operations therewithin can also be provided as systems and sub-units thereof. The scale used to illustrate various elements in the drawings is merely exemplary and/or appropriate for clarity of presentation, and is not intended to be limiting. Any suitable communication may be employed between separate units herein e.g. wired data communication and/or in short-range radio communication with sensors such as cameras e.g. via Wifi, Bluetooth or Zigbee.

[0197] It is appreciated that implementation via a cellular app as described herein is but an example, and, instead, embodiments of the present invention may be implemented, say, as a smartphone SDK, as a hardware component, as an STK application, or as suitable combinations of any of the above.

[0198] Any processing functionality illustrated (or described herein) may be executed by any device having a processor, such as but not limited to a mobile telephone, set-top-box, TV, remote desktop computer, game console, tablet, mobile e.g. laptop or other computer terminal, embedded remote unit, which may either be networked itself (may itself be a node in a conventional communication network e.g.), or may be conventionally tethered to a networked device (to a device which is a node in a conventional communication network, or is tethered directly or indirectly/ultimately to such a node).

[0199] Any operation or characteristic described herein may be performed by another actor outside the scope of the patent application and the description is intended to include apparatus, whether hardware, firmware or software, which is configured to perform, enable or facilitate that operation, or to enable, facilitate or provide that characteristic.

[0200] The terms processor or controller or module or logic as used herein are intended to include hardware such as computer microprocessors or hardware processors, which typically have digital memory and processing capacity, such as those available from, say Intel and Advanced Micro Devices (AMD). Any operation or functionality or computation or logic described herein may be implemented entirely or in any part on any suitable circuitry including any such computer microprocessor/s, as well as in firmware or in hardware, or any combination thereof.

[0201] It is appreciated that elements illustrated in more than one drawing, and/or elements in the written description, may still be combined into a single embodiment, except if otherwise specifically clarified herewithin. Any of the systems shown and described herein may be used to implement or may be combined with, any of the operations or methods shown and described herein.

[0202] It is appreciated that any features, properties, logic, modules, blocks, operations or functionalities described herein which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment, except where the specification or general knowledge specifically indicates that certain teachings are mutually contradictory, and cannot be combined. Any of the systems shown and described herein may be used to implement, or may be combined with, any of the operations or methods shown and described herein.

[0203] Conversely, any modules, blocks, operations or functionalities described herein, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable sub-combination, including with features known in the art. Each element e.g operation described herein may have all characteristics and attributes described or illustrated herein or according to other embodiments, may have any subset of the characteristics or attributes described herein.