Russia’s April 1 GLONASS blackout occurred, ironically, only hours after the U.S. House of Representatives passed legislation to preserve infrastructure that could support a back-up system for GPS that could be used for critical infrastructure and applications in the event of a similar disaster occurring in the United States.
The 2014 Coast Guard Authorization Act requires the Department of Homeland Security (DHS) to halt dismantling and disposal of infrastructure that could be used for a terrestrial system during times and in places where GPS is not available.
DHS had announced in 2008 that it would build such a back-up system, but it never did so, and actually began dismantling, destroying, and divesting itself of Loran equipment and properties. The equipment, facilities, and sites could be used to implement a new-generation eLoran system for GPS back-up, among other applications. Despite strong recommendations to the contrary by its own panel of experts, the Obama administration, DHS, and the Coast Guard moved in 2009 to kill the Loran program.
Ever watchful, Congress has lately become more visibly concerned about the vulnerability of the nation’s space systems. The 2014 National Defense Authorization Act tasked the administration with reporting on how it was going to provide necessary national security capabilities when space systems were disrupted. More recently, Congressmen Duncan Hunter (Republican, California), chair of the House Coast Guard and Marine Transportation Subcommittee, held a hearing at which he expressed his concern that the nation has no back-up for GPS. He also expressed his frustration with the Department of Homeland Security, reporting that “They said they need to do a study about their study.”
Congressman John Garamendi (Democrat, California), commented “GPS will go down one day. The question is, is there a backup?”
The legislation passed by the House authorizes DHS to partner with public or private entities to build a system that would not only backup GPS, but also work indoors, underground and underwater — all characteristics of long-wave Loran technology.
Dana Goward, president of the Resilient Navigation and Timing Foundation, said such a project would be relatively inexpensive. “If the existing equipment and infrastructure are preserved and reused, the system could be restored and put into operation for less than half the cost to dispose of it.”
“It isn’t an issue of money,” Goward continued. “It is a question of the government taking this problem seriously and acting on it.”
The foundation has as offered to partner with the government to build the system.
“Our government has known about this issue for a long time,” Goward said. “At least since 2001. And there has been a standing presidential direction to obtain back-up capability since 2004. But for some reason, it hasn’t yet happened.”
The U.S. government’s official information website about GPS has recently updated its page on eLoran and Loran-C with a tracking log for Coast Guard and Maritime Transportation Act of 2014, which now goes to the Senate.
The GSG-51 GNSS signal generator provides a fast and cost-effective solution for production testing for Galileo and other GNSS. It emulates a single GNSS signal and can be upgraded for Galileo, as well as to increase the channel count, add receiver trajectory control, and add advanced features such as SBAS (WAAS, EGNOS,MSAS, or GAGAN), white noise generation, or multipath simulation. Its main application is a simple but very fast manufacturing test, to assure that the assembly is correct, that the antenna is properly connected, and that the receiver can receive and identify a satellite signal, for instance, in mobile phones with integrated GNSS receivers.
With a wide RF level range from –65 to –160 dBm, the sensitivity of all types of GNSS receivers can be verified with a minimum of delay. The 60-dB of extra power from normal test scenarios allows for splitting the signal many times.
India’s Indian Space Research Organisation (ISRO) launched its second navigation satellite today, April 4, at 11:44 UTC. A Polar Satellite Launch Vehicle (PSLV) rocket launched the IRNSS-1B spacecraft in a mission originating from the Satish Dhawan Space Centre. Read more here.
India’s Indian Space Research Organisation (ISRO) launched its second navigation satellite today, April 4, at 11:44 UTC. A Polar Satellite Launch Vehicle (PSLV) rocket launched the IRNSS-1B spacecraft in a mission originating from the Satish Dhawan Space Centre.
Liftoff was on schedule. IRNSS-1B is the second of seven satellites that comprise the first-generation Indian Regional Navigation Satellite System (IRNSS). IRNSS-1B will join IRNSS-1A already in orbit in forming the first pair of satellites for the IRNSS.
Watch the launch in this video:
The IRNSS system will consist of three geostationary satellites and two pairs of spacecraft in inclined geosynchronous orbits. Each IRNSS satellite uses a rubidium-based atomic clock to keep time, transmitting signals on L and S-band frequencies at 1,176.45 and 2492.028 megahertz respectively. A C-band transponder and an array of retroreflectors will be used to determine ranging data for calibration, according to NASASpaceflight.com.
“From the reports on GLONASS problems, we have an explanation that may be used in our technical support replies:
“Our analysis reveals the GLONASS integration algorithms skipped an interval of around 1.5 minutes at the control centre software.
“At 21:00 UTC April 1, all GLONASS satellites received an orbit state (ephemeris) which was clearly several minutes ahead of the current orbit shape without actually changing the applicable reference time stamp. In other words, future orbit-position, velocity and accelerations were assigned to a current reference timestamp.
“This led to incorrect orbit positions for all GLONASS satellites and subsequent problems with receiver using GLONASS measurements.
“In our receivers, RAIM rejected the solutions because of the large GLONASS errors, and could only work with GPS only and the recently revised RAIM settings for a Base (SRL,ON,-6,-4,-4).
“The issue is now rectified, and the GLONASS constellation is back to normal.”
Broadcom Corporation has announced the industry’s first 5G Wi-Fi (802.11ac) system-on-chip (SoC) to deliver pinpoint indoor positioning technology. The BCM43462 SoC, featuring Broadcom’s new AccuLocate technology, provides sub-meter accuracy on physical locations enabling retailers and public venue operators to deliver more personalized experiences to consumers.
Analysts predict the indoor location market to reach $4 billion in 2018, fueled by increasing demand for location-based services in public venues such as shopping malls, department stores, airports and stadiums. By leveraging location-based services, retailers and venue operators can offer discounts, promotions and personalized services to consumers based on exact locations while enterprise network IT staff can use the technology to track and manage assets, Broadcom said.
Broadcom’s latest 5G Wi-Fi SoC with on-chip AccuLocate technology operates using fine timing measurement (FTM) technology, resulting in highly accurate positioning regardless of environmental factors, Broadcom said. Previous versions of indoor positioning relied on received signal strength indicator (RSSI) technology, where signal strength and performance can vary depending on environmental factors such as crowd density or temperature.
“Broadcom’s latest 5G Wi-Fi innovation with integrated AccuLocate technology delivers highly accurate sub-meter pinpoint technology that rivals the capabilities of outdoor location based technology,” said Ed Redmond, Broadcom vice president and general manager, Compute and Connectivity. “In addition to providing a more customized user experience, this technology has the added benefit of allowing venue operators to monetize their investment in existing Wi-Fi infrastructure.”
“Location-based technology installations will break the 25,000 mark in 2014, while mobile devices capable of supporting indoor location will reach hundreds of millions within two years,” said Patrick Connolly, ABI Research senior analyst. “Rising demand for these services by the world’s leading venue operators and retailers is generating an immense opportunity for leading component suppliers, such as Broadcom, who are early to market with innovative solutions.”
About 5G Wi-Fi
Increased reliance on wireless networks, the explosion of video consumption and growing number of wireless devices are all putting tremendous stress on legacy 802.11a/b/g/n networks. With new innovations that allow for more reliable coverage, 5G Wi-Fi technology addresses these challenges, allowing mobile device users to stream digital content between devices faster, and simultaneously connect more wireless devices to home and enterprise networks, while conserving battery power.
Key Features of the Broadcom BCM43462 SoC
Dual-band (2.4 GHz and 5 GHz) complete 5G WiFi (11ac) SoC with integrated MAC, PHY and radio
Three-stream spatial multiplexing up to 1.3 Gbps
State-of-the-art security provided by industry standardized system support
Embedded hardware acceleration enables increased system performance
Full IEEE 802.11a/b/g/n legacy compatibility with enhanced performance
Support for FASTPATH® UAP, Broadcom’s enterprise class access point software
Availability
Broadcom’s BCM43462 SoC with integrated AccuLocate technology is now sampling. AccuLocate technology is also available on Broadcom’s BCM43520 5G Wi-Fi 2X2 SoC, BCM43460 5G Wi-Fi 3X3 SoC and BCM4354 5G Wi-Fi 2×2 MIMO Combo Chip.
Topcon Positioning Group announces a new data controller — the FC-500 — with numerous features and benefits, including a large 4.3-inch touchscreen display and 5MP camera with built-in LED flash.
The FC-500 is designed for the professional operating Topcon MAGNET Field, Site and Layout software and Topcon’s Pocket 3D.
Ray Kerwin, director of global surveying products, said, “The FC-500 works with all Topcon GPS/GNSS receivers and total stations, and meets or exceeds all field application requirements. Additionally, the FC-500 works with the new Topcon LN-100 instrument dedicated to BIM and one-person construction layout, simplifying workflow with the seamless integration with our MAGNET suite of software solutions.”
Kerwin said, “With a sunlight readable screen, the controller is easy to use even in bright sunlight. It is the ideal job site controller in any condition (waterproof up to one meter, IP68 rating) and the large camera format with built-in LED flash and built-in 8GB flash storage allows the storing of hundreds of job site photos.”
The standard model has both Bluetooth and Wi-Fi connectivity, while the FC-500 GEO has Bluetooth, WiFi and GPS. A third model comes with the addition of a 3.5G cellular modem that allows access to the MAGNET Enterprise Solutions suite, “making the FC-500 the perfect field instrument for sending and receiving data files to the MAGNET cloud,” Kerwin said.
For the GIS professional using MAGNET Field software, the FC-500 has a geotagging feature that allows imprinting file information, including GPS location, directly on photos.
Yesterday we posted news of an 11-hour downtime for the full GLONASS constellation, due to an upload of bad ephemerides. Coincidentally, during that 11-hour period, the mass-market chip company Broadcom was conducting multi-constellation receiver tests in Asia. Frank van Diggelen, Broadcom’s chief GNSS scientist and vice president says, “We have definitive data to show how a multi-constellation receiver survives such an outage.”
Here are the pictures, and the story they tell.
Test data coincident with the GLONASS ephemeris disruption of April 1 and 2 showing conclusively how a GPS/GLONASS/QZSS/BEIDOU receiver survives the complete disruption of one of the constellations.
On April 2 at 1:00 a.m. Moscow time, bad ephemeris was uploaded to all satellites (see chart at the bottom of this story).
There are two receivers shown here, from two different manufacturers, both in smartphones. The yellow dots are for a GPS/GLONASS receiver; the blue dots are from the Broadcom 47531 receiver which tracks GPS/GLONASS/QZSS/BeiDou signals simultaneously. The 47531 receiver includes logic to use redundant measurements to check the validity of all measurements. It successfully identified and removed the bad GLONASS ephemeris 100 percent of the time, as can be seen by the continuity and accuracy of the positions.
Here is the satellite outage chart from yesterday’s story. All GLONASS satellites were restored to healthy state after the 11-hour interruption.
Current plot from the Roscosmos GLONASS Information-Analytical Centre. Things are almost back to normal this morning.
By Mirko Stanisak, Mark Bitter, and Thomas Feuerle
INNOVATION INSIGHTS by Richard Langley
GPS = SAFER FLIGHT. While reviewing material for an article celebrating the 25th anniversary of the launch in February 1989 of the first Block II or operational GPS satellite, I was yet again annoyed by many articles on the Web stating that GPS only became available for civil use after the launch of this satellite. Some sources get closer to the truth when they say that GPS was opened for civil use in 1983, following the shoot-down of the Korean Airlines Flight 007. In fact, GPS was designed to serve the needs of both the military and civil communities from the outset. A government memo from April 1973 clearly states: “Civil user needs should be considered in the design of the spaceborne equipment.”
One of the first demonstrations of the use of GPS for aircraft navigation occurred in July 1983, when a Sabreliner business jet was flown in stages from Cedar Rapids, Iowa, to the Paris Air Show, flying only when a sufficient number of the experimental or Block I satellites were in view. The first standalone GPS receivers certified for aviation use (with Receiver Autonomous Integrity Monitoring or RAIM) became available by the mid-1990s. But already the Federal Aviation Administration had been looking into the development of a system to provide higher accuracies and better integrity than that afforded by standalone receivers. In 1994, the FAA announced the development of the Wide Area Augmentation System, its brand of a system generically known as satellite-based augmentation. Geostationary satellites transmit corrections and integrity information to GPS receivers, permitting GPS use for en route navigation all the way down to traditional Category I approach and landing. CAT I approaches can be flown down to a decision height of 61 meters (200 feet). WAAS was declared operational on July 10, 2003, but enhancements to the system continue. Japan, Europe, and India also have operational SBAS based on GPS.
Ground-based GPS augmentation was first developed for maritime applications with the U.S. Coast Guard’s low-frequency system coming on line in the mid-1990s. Also in the mid-1990s, the FAA began the development of the Local Area Augmentation System, generically known as a ground-based augmentation system (GBAS), to provide aircraft with approach and landing capabilities from CAT I down through CAT II (30-meter or 100-foot decision height) and CAT III (no decision height but certain visual range minima) using a VHF datalink. Initial CAT I systems are being operated at Bremen, Germany, and at Newark Liberty International Airport and Houston George Bush Intercontinental Airport.
While a GPS-based GBAS will definitely offer improved navigation services for aircraft, might these services be even better if the systems were to use satellites from other constellations besides GPS? In this month’s column, we look at a straw-man concept for modifying the GBAS protocols to accommodate multiple constellations and the results of preliminary tests using GPS, GLONASS, and Galileo simultaneously.
“Innovation” is a regular feature that discusses advances in GPS technology and its applications as well as the fundamentals of GPS positioning. The column is coordinated by Richard Langley of the Department of Geodesy and Geomatics Engineering, University of New Brunswick. He welcomes comments and topic ideas. Write to him at lang @ unb.ca.
Ever since the declaration of Full Operational Capability (FOC) of the U.S. Global Positioning System in April 1995, GPS has dominated satellite navigation, especially in aviation applications. By contrast, the Russian GLONASS system cannot be used in western aviation because no approval guidelines exist for GLONASS equipment. Thus GPS has been the de-facto standard in aviation for years.
However, within the last few years, major changes have evolved in the field of GNSS, providing a wide variety of useable satellite navigation systems. The European Union launched its Galileo project, which will provide global multi-frequency services in the near future. China is upgrading its BeiDou system (formerly called Compass) to provide global coverage with more medium-Earth-orbit (MEO) satellites. The operators of GPS and GLONASS have started modernization programs that will enable multi-frequency operations in the future, too. Therefore, a large number of usable satellites and signals from multiple systems will soon be available.
In aviation, almost all phases of flight can be assisted by satellite navigation systems nowadays. The most challenging phase of flight with respect to accuracy, continuity, availability, and integrity is the approach and landing phase. The Ground Based Augmentation System (see FIGURE 1; courtesy of the European Organization for Civil Aviation Equipment) allows precision approaches to be performed using satellite navigation. It uses a VHF data link to broadcast differential GNSS corrections, integrity information, and approach definitions to approaching aircraft. These aircraft combine the differential corrections with their own GNSS measurements, calculate a GBAS-corrected position solution, and determine path deviations based on the selected approach.
FIGURE 1. GBAS principle. (Source: EUROCAE WG 28, ED-114)
From a technical perspective, GBAS can use either GPS or GLONASS for differential corrections. For this, the International Civil Aviation Organization (ICAO) Standards and Recommended Practices (SARPs) include GPS and GLONASS side by side. On the other hand, some standardization documents (for example, those from RTCA) are limited to GPS only, effectively excluding GLONASS from being used in the western world. Nevertheless, Russian GBAS systems provide differential corrections for GPS and GLONASS, and are expected to be certified in Russia in the near future. Additional GNSS such as Galileo or BeiDou are not yet included within these documents, as these systems are not approved for aviation use themselves. This article will focus on how a multi-constellation GBAS with GPS, GLONASS, and Galileo could work.
GBAS installations can provide multiple services for different kinds of operation, based on GNSS L1 corrections only. On the one hand, the differentially corrected positioning service (DCPS) is intended to be a generic service for high accuracy positioning. On the other hand, two different GBAS approach services have been defined. GBAS Approach Service Type C (GAST-C) allows Category I (CAT I) procedures and is already in operation. GAST-D is still under development and will enable precision approaches and landings down to CAT II/III minima once certified. To mitigate all possible hazards, GAST-D will require some additional broadcast messages.
VHF Data Broadcast
The VHF Data Broadcast (VDB) is used to communicate binary GBAS messages to approaching aircraft. It operates in the VHF band (108.025 – 117.975 MHz) and uses time-division multiple access (TDMA) to allow the operation of multiple GBAS ground stations on a single frequency. As shown in FIGURE 2, VDB uses UTC time to have a common time frame. Two frames are transmitted each second, lasting 0.5 seconds each. Within each frame, eight slots with durations of 62.5 milliseconds can be used for transmission. Binary application data is encoded using a differentially encoded eight-phase-shift-keying modulation (D8PSK) and a symbol rate of 10,500 symbols per second. With three bits transmitted per symbol, up to 31,500 bits per second can be transmitted. Each slot can contain up to 222 bytes of binary application data. Usually, only a subset of slots is allocated to a particular ground facility. This way, multiple GBAS ground facilities can share a common VDB frequency.
Within each slot, multiple VDB messages can be transmitted as application data. The coding of information in VDB messages is defined in the RTCA’s GNSS-Based Precision Approach Local Area Augmentation System (LAAS) Signal-in-Space Interface Control Document (ICD) and depends on the VDB message type. (LAAS is the U.S. GBAS.) Currently, message types (MT) 1, 2, 3, 4 and 11 are defined. Figure 2 is derived from this document.
Message Type 1 – MT1. Within VDB Message Type 1, differential corrections based on 100-second smoothing are transmitted. These corrections are required by all GBAS approach services (GAST-C and GAST-D). Aside from the differential corrections, additional information for the first broadcast satellite is transmitted. This includes an ephemeris cyclic redundancy check (CRC), mitigating the effects of wrongly received GNSS navigation data, and the Issue of Data (IOD) flag, indicating the time of applicability for the ephemeris data to be used. To transmit this information for all satellites, the satellite for which differential corrections are transmitted first has to be alternated continuously.
Each MT1 message can contain up to 18 pseudorange- and range-rate corrections for individual satellites. Nevertheless, it is possible to link two consecutive MT1 messages using the Additional Message Flag (AMF). The value of this parameter indicates whether this is a single message (0), or the first (1) or second (3) part of a linked MT1 message. Up to 36 differential corrections can be transmitted using two consecutive VDB time slots with 18 corrections each.
All MT1 measurement blocks must be transmitted at least once per frame. The maximum transmission rate is once per slot for all measurement blocks.
Message Type 2 – MT2. VDB Message Type 2 contains station and integrity parameters such as the coordinates of the reference point to which all differential corrections refer. MT2 messages can include (next to a “core” MT2 message) multiple Additional Data Blocks (ADBs) to transmit information required for different GBAS services. At the moment, the Additional Data Blocks 1, 3, and 4 are defined.
ADB1 contains the maximum distance to the reference point at which the corrections may be used (Dmax) as well as parameters to calculate the remaining risk of incorrect GNSS ephemeris data (Kmd,e). Within ADB3, additional information required for GAST-D is transmitted. ADB4 implements the VDB authentication feature. If this ADB is broadcast by a ground facility, MT2 messages must be transmitted first and contain additional indications about which VDB slots are allocated to the ground facility.
MT2 messages must be transmitted at least each 20th frame, but may be repeated up to once per frame.
Message Type 3 – MT3. The VDB Message Type 3 is a fill message, which is only used in conjunction with the GBAS authentication feature (MT2, ADB4). Among other things, this feature requires a minimum slot occupancy of at least 95 percent. Thus, MT3 messages are broadcast only by ground facilities that support the authentication feature and are completely ignored by airborne GBAS receivers.
Message Type 4 – MT4. With VDB Message Type 4, approach information can be broadcast to approaching aircraft. A pilot can select a specific approach by simply tuning to a given channel number.
Currently, GBAS only uses Instrument Landing System look-alike straight-in approaches called Final Approach Segments (FAS). Each FAS represents one approach. This way, a single GBAS ground facility can provide multiple approaches for all runways of an airport. All approaches must be broadcast at least once per 20 consecutive frames.
Message Type 11 – MT11. The VDB Message Type 11 provides differential corrections in a way very similar to MT1 messages. The main difference is that MT11 corrections are based on 30-second smoothing, which is required for GAST-D service. As for MT1, all MT11 measurement blocks must be transmitted at least once per frame.
Enhancements for GBAS with Galileo
At the moment, the GBAS standardization documents include information on GPS, GLONASS, and SBAS ranging sources. No information on Galileo or other constellations has been added yet. Thus, to include Galileo for GBAS, some Galileo-specific experimental additions to the standards are necessary. These proposed modifications have been made in such a way as to keep as close to the other system standards as possible to preserve consistency. This way, hardly any new functionality is added, but additional satellites can be used. The additional Galileo signals (E5a, E5b, E6) are not used at the moment; however, they might be highly beneficial for multi-frequency applications in the future.
All modifications presented here are purely experimental and will most probably not be exactly the same as those in future standards documents. Nevertheless, they provide a way to test Galileo together with GPS and GLONASS for GBAS on an experimental basis.
Ranging Source ID. The Ranging Source ID uniquely addresses a single satellite. It is used in MT1 and MT11 to transmit the differential corrections and other information for each ranging source. In ICAO Annex 10, Standards and Recommended Practices, the Ranging Source ID is defined for GPS, GLONASS, and SBAS only. To provide Galileo corrections as well, an experimental mapping for Galileo satellites was added; see TABLE 1.
TABLE 1. GBAS Ranging Source IDs.
In this way, up to 36 Galileo satellites can be addressed.
Navigation Data. Galileo provides two different sets of navigation data. The I/NAV data corresponds to the Safety-of-Life (SoL) service and is broadcast on E1 and E5b. The F/NAV data corresponds to the Open Service (OS) and is broadcast on E5a. In order to remain as close as possible to the legacy navigation systems, we selected the I/NAV navigation data for use, as it is broadcast on the E1 frequency and can thus be received with an L1-only GNSS receiver.
The navigation data is primarily used in VDB MT1. For the first transmitted correction in this message, the ephemeris set that shall be used in the aircraft is identified via the Issue of Data (IOD) field. To be consistent with the GPS ephemeris, we used Galileo’s IODnav parameter.
Together with the identification of the navigation data, a CRC parameter is transmitted in MT1 for the first satellite within the differential corrections. This parameter ensures that the receiver as well as the ground facility use identical navigation data for all calculations. The CRC algorithm uses the raw navigation data to generate a distinct CRC value.
For GPS and GLONASS, two ephemeris masks are defined. These masks ensure that only information relevant for GBAS processing are covered by the CRC. For Galileo, a similar mask had to be designed.
Additional Data Blocks in MT2. Within VDB MT2, station parameters and integrity information are transmitted. Some parameters for the over-bounding of possible ephemeris errors are specific to each satellite navigation system.
To extend MT2 to Galileo, parameters for the DCPS, GAST-C, and GAST-D must be added for Galileo. For downward compatibility, these parameters cannot be included in the existing Additional Data Blocks beside the existing parameters. Thus, a new Additional Data Block (ADB5) was defined on an experimental basis. This Additional Data Block is dedicated to Galileo and is structured as shown in TABLE 2. The coding of all values corresponds to the coding of the parameters for the existing systems.
TABLE 2. Additional Data Block 5 in Message Type 2 for Galileo parameters.
Optimized VDB Transmission Scheme
Having available a large number of ranging sources for differential corrections, the VHF VDB is a bottleneck for the transmission of this data. To demonstrate this, we first consider the number of visible satellites that there will be in the future. This leads to construction rules for an optimal VDB transmission scheme, which allows transmitting the maximum number of differential corrections.
Number of Satellites Available. To demonstrate the number of differential corrections enabled by the different systems in the future, we computed the number of visible satellites over a day for a stationary GNSS receiver in Braunschweig, Germany. Even though only four Galileo satellites were in orbit at that time, up to 26 different satellites (GPS, GLONASS, and Galileo) were in view simultaneously. Keeping in mind the preliminary Galileo constellation, it is obvious that more than 30 satellites will be available simultaneously in the future — considering only GPS, GLONASS, and Galileo. Adding BeiDou satellites for GBAS would further boost these numbers.
The broadcast of such a large number of differential corrections is limited by the capacity of the VDB and thus by the number of slots assigned to a GBAS ground facility. The number of assigned slots for a facility should be limited as far as possible to be able to use the same frequency for other GBAS ground facilities. Thus, the available capacity must be used as effectively as possible.
Number of Bytes Required. Each VDB message is framed by a message block header (6 bytes) and the message block CRC (4 bytes).
The length of each message depends on the message type and the amount of information to be transmitted. The resulting length for a message of each type is given in TABLE 3.
TABLE 3. Size of different VDB message types (including message block header and CRC). Variable length message types are dependent on the number of corrections, N.
VDB Constraints. A GBAS ground facility must transmit the VDB data following some constraints. These are:
MT2 messages (including all Additional Data Blocks required) must be transmitted at least each 20th frame (that is, every 10 seconds).
If authentication is required, each MT2 message must be transmitted in the first slot assigned to the GBAS ground facility.
All differential corrections (both MT1 and MT11) must be transmitted at least once in each frame. However, it is possible to split the differential corrections into two adjacent slots using the Additional Message Flags in MT1 and MT11 messages.
Within each MT1 message, the ephemeris decorrelation parameter (Peph), the Issue of Data (IOD), and the ephemeris CRC is transmitted for the first satellite in the message. Thus, the first satellite must be alternated in order to broadcast the ephemeris information for all satellites.
Approach definitions are transmitted in MT4 messages. All MT4 messages must be transmitted within at least each 20th slot.
Based on these constraints, a VDB encoding scheme has been developed, which allows us to fulfill all the requirements listed above while optimizing the number of differential corrections that can be transmitted. Even though it is optimized for GAST-D-like services (including authentication parameters, MT11 messages, and experimental Galileo extensions), it can be used for legacy GAST-C systems, too.
Rules for Optimal VDB Transmission. To fulfill the requirement for the MT2 message to be transmitted first, a complete MT2 message must be transmitted each 20th frame at the beginning of the first slot assigned. If no MT2 message has to be transmitted, an MT4 message is transmitted instead. Thus, all messages are arranged in proper order by three simple rules:
MT2 (each 20th frame) or MT4 (otherwise)
MT11 (all corrections; can be split into two messages)
MT1 (all corrections; can be split into two messages).
Additionally, two more rules must be fulfilled. On the one hand, if supporting the authentication feature, each slot in which the ground facility may transmit VDB data must be filled to at least 95 percent. For this, MT3 null messages may be used to ensure that each slot is filled sufficiently. On the other hand, an additional rule for MT1 messages is necessary if more than three slots are assigned to the GBAS ground facility. In this case, to maximize the number of differential corrections the MT1 messages may be transmitted in the last two assigned slots only. This rule is necessary because the Additional Message Flag is limited to two slots for differential corrections.
Using this transmission scheme, the number of differential corrections is maximized while fulfilling the minimum requirements on the VDB data. Even in case of the maximum number of differential corrections, MT4 approach definitions can still be broadcast. However, in this case, the number of transmittable FAS segments is limited to 19. If more approaches (or different approach types such as Terminal Area Paths (TAPs)) have to be transmitted, the VDB generation scheme must be adapted.
Number of Transmittable Corrections. Using the optimized transmission scheme explained earlier, the number of transmittable corrections can be calculated easily for different numbers of assigned slots for GAST-C as well as for GAST-D services (see TABLE 4).
TABLE 4. Number of differential corrections that can be broadcast.
The exact distribution of VDB messages for the maximum number of differential corrections (18) is shown in FIGURE 3 for an MT1/MT11 configuration and two assigned slots.
FIGURE 3. VDB messages for two slots and 18 satellites (MT1 and MT11).
Experimental Realization of Multi-Constellation GBAS
The experimental GBAS multi-constellation extensions described earlier have been implemented in software for further testing. As these enhancements are purely experimental and might change in the future, we have ensured that these definitions can be changed easily.
Navigation Software. The Institute of Flight Guidance at Technische Universität Braunschweig has been developing an experimental navigation framework for many years. This software, called TriPos, can handle and combine different navigation technologies. TriPos can be used for simulations, post-processing of recorded data, and even for live (online) processing. It is written in C++ and supports various platforms.
The navigation framework can be extended easily. Originally, only GPS was supported within the software, but support for GLONASS and Galileo as well as augmentation systems like SBAS and GBAS were added over the past few years. Additionally, the software handles GNSS data of multiple frequencies internally and can thus be used for multi-constellation and multi-frequency applications. TriPos includes decoders for the binary protocols of most GNSS receivers currently available.
For GBAS research, two components can be simulated using the software. On the one hand, the Ground Facility simulation calculates the differential corrections and provides simulated VDB data. On the other hand, the GBAS receiver simulation emulates the behavior of an airborne GBAS receiver and uses VDB data and GNSS measurements to calculate a GBAS solution. Both simulations can use either recorded data in post-processing or live data for online-processing. This allows complete simulation of GBAS.
Multi-Constellation GBAS Ground Facility Simulation. The GBAS ground facility simulation uses raw binary data from multiple stationary GNSS receivers to calculate binary VDB data. The simulation can be freely configured to process either live or pre-recorded GNSS data. Even though it features all algorithms required by the standards, it does not contain additional monitor algorithms at the moment.
Nevertheless, it can provide a valid VDB signal-in-space (SIS), which can be used by GBAS receivers and simulation tools (such as Eurocontrol’s PEGASUS tool). The ground facility simulation supports legacy GBAS CAT-I (GAST-C) as well as GAST-D (including all additional VDB information required) using GPS and GLONASS. Support for Galileo has been added according to the experimental definitions described earlier. In addition to FAS data blocks, the ground facility simulation is also capable of providing curved approaches using TAP data blocks.
Multi-Constellation Airborne GBAS Receiver Simulation. The GBAS receiver simulation has been used for various GBAS-related projects. It supports GAST-C as well as GAST-D and can be configured flexibly to use GPS, GLONASS, and/or Galileo (using the experimental enhancements as described earlier). For GAST-D, all airborne monitoring algorithms required are present. Thus, the aircraft-specific parameters (for example for the airborne geometry screening) can be configured together with the other parameters.
Flight Trials
The practicability of the multi-constellation GBAS approach has been tested in flight trials. To ensure that all four Galileo satellites were in view and capable of providing valid data during our trials, an orbit prediction tool and the Notice Advisory to Galileo Users (NAGU) service of the European GNSS Service Center (GSC) were used prior to the flight.
The data processing configuration is shown in FIGURE 4 and includes the GBAS simulation components explained earlier. All processing is done in real time while recording all data for later post processing.
FIGURE 4. Schematic data processing for the flight experiments (ground components in orange, airborne components in blue).
Ground Processing. On the ground, two Septentrio AsteRx3 GNSS receivers connected to two roof-top antennas were used. The GNSS receivers were connected to the GBAS ground facility simulation via a network and provided binary GPS, GLONASS, and Galileo raw measurements with an update rate of 2 Hz as well as navigation data. Using this data, the ground facility simulation generated binary VDB data. The GBAS ground facility simulation was configured to generate multi-constellation GAST-D VDB data for a three-slot configuration. All required messages (MT1, MT2 including all required ADBs, MT3, MT4 and MT11) were generated and sent to the telemetry facility via the network.
Telemetry. Official VHF data broadcasts operate in a frequency band between 108 and 118 MHz, which is reserved for authorized aviation applications. However, for our experimental system, an alternative data link was used. The Institute of Flight Guidance operates a full-duplex telemetry system to share data between ground and aircraft. Even though the operating frequencies are different, the telemetry system allows the generated binary VDB data to be transmitted to research aircraft. The airborne telemetry receiver outputs data as if it were a VDB receiver to allow us to switch between a real VDB receiver and the telemetry receiver easily.
Research Aircraft. The Institute of Flight Guidance operates the research aircraft of the Technische Universität Braunschweig. The Dornier Do 128-6 with the call sign D-IBUF (see FIGURE 5) is a twin-engine turboprop aircraft without a pressurized cabin and has been used multiple times for GBAS-related research over the years.
FIGURE 5. Research aircraft D-IBUF (Dornier Do 128-6).
The research aircraft allows us to flexibly integrate experimental equipment for specific flight trials. For the multi-constellation GBAS flights, a JAVAD Delta GNSS receiver (capable of multiple constellations and frequencies), a telemetry receiver, and an experimental cockpit display were installed temporarily.
Airborne Processing. The online GBAS receiver simulator uses GNSS data from the JAVAD Delta GNSS receiver together with the VDB data received via telemetry. The receiver was configured to output raw GPS, GLONASS, and Galileo measurements with an update rate of 10 Hz. The simulator was configured to use this data to calculate a multi-constellation GAST-D solution. Based on the selected approach definition, the resulting information (deviations, distance to threshold, and so on) was displayed in the cockpit using an experimental cockpit display.
Results. The flight test was conducted in the evening of November 6, 2013 (16:52 – 17:58 UTC), at Research Airport Braunschweig (EDVE). We performed five approaches with a 10 nautical mile final segment. The flight path as calculated by the GBAS receiver subsystem is shown in FIGURE 6.
FIGURE 7 shows the number of satellites used for the GBAS receiver simulation, and distinguishes between the different satellite navigation systems used. Up to 22 satellites have been used simultaneously for GBAS processing, including up to 10 GPS satellites, eight GLONASS satellites, and four Galileo satellites.
FIGURE 7. Number of satellites used by the multi-constellation GBAS receiver simulation.
Even though no certified GBAS equipment was used for the flight trials, FIGURE 8 shows the resulting vertical and lateral protection levels (VPL and LPL) of the online multi-constellation GBAS receiver simulation. Both values fluctuate due to the differences between 100- and 30-second smoothing position solutions, which have to be added to the protection levels for GAST-D. Nevertheless, both sets of values remain clearly below the corresponding Alert Limits (FAS Lateral Alarm Limit (FASLAL): 40 meters, FAS Vertical Alarm Limit (FASVAL): 10 meters). A valid GAST-D service was achieved continuously.
FIGURE 8. Vertical and lateral protection levels (VPL and LPL).
FIGURE 9 shows a vertical integrity diagram, commonly known as a Stanford plot, for the integrity of the multi-constellation GBAS simulation. This plot shows the Vertical Protection Level (VPL) as determined by the GBAS receiver simulation against the actual Vertical Position Error (VPE). The Vertical Position Error is a direct measure for the Vertical Navigation System Error (V-NSE). This has been determined using a precise point positioning reference trajectory. Both values are normalized by the current VAL as these values change during the approaches. During the flight, the GBAS online processing ran at a rate of 10 Hz, resulting in 43,670 GAST-D epochs and an availability of 100 percent.
FIGURE 9. Normalized vertical Stanford plot of flight trials (GAST-D using GPS, GLONASS, and Galileo). Color scale indicates number of occurrences.
Of course, these results must not be misinterpreted as a multi-constellation GBAS performance assessment. The ground facility simulation was highly experimental and lacked any kind of long-term analysis. Even the GNSS antennas used do not meet formal requirements. However, aside from a quantitative judgment, these results show the practicability of this multi-constellation GBAS approach on an experimental basis.
Conclusion and Outlook
In this article, experimental extensions to GBAS have been developed to support GPS, GLONASS, and Galileo simultaneously. Based on these extensions, an optimized VDB transmission scheme has been created. In this way, the number of transmittable differential corrections could be maximized. Using flight trials, the multi-constellation GBAS concept has successfully been verified. The experimental airborne GBAS subsystem was able to calculate a valid GBAS solution including GPS, GLONASS, and Galileo satellites continuously.
It has been shown that multi-constellation GBAS is possible from a purely technical perspective. On the other hand, neither operational nor approval aspects for satellite navigation systems other than GPS have been addressed yet. Additionally, further testing would be necessary to ensure the compatibility with legacy GPS-only GBAS equipment. However, in theory, all modifications for Galileo are backward compatible. Nevertheless, it has to be assured that certified GBAS multi-mode receivers only use the GPS part of the VDB data and are not disturbed by additional VDB messages or additional ranging sources, for example. The required tests are planned for the future.
The operational benefit of multi-constellation GBAS systems cannot be foreseen yet. A certification for this will take several years and could only be addressed by the GBAS community after the completion of the GAST-D certification. Most probably, the use of GNSS signals on multiple frequencies could provide a highly improved GBAS service and will allow much more operational benefit. Many of the satellite navigation systems have already introduced additional frequencies, including signals in the protected L5 aviation band. The use of multiple frequencies for satellite navigation in aviation can remove most ionospheric errors effectively and mitigate a major source of uncertainty. Thus, multi-constellation GBAS can just be seen as a preliminary step on the way towards multi-frequency GBAS. The concepts and infrastructure described in this article will serve as a basis for more research in this area.
Acknowledgments
Most of our work on multi-constellation GBAS was done within the research project “Bürgernahes Flugzeug,” which was established in 2009 and is partly funded by the German federal state of Lower Saxony. This is gratefully acknowledged by the authors. Additionally, the authors would like to thank all colleagues involved for constructive discussions and their support. This article is based on the paper “Mulitple Satellite Navigation for the Ground Based Augmentation System” presented at ITM 2014, The Institute of Navigation 2014 International Technical Meeting, held in San Diego, California, January 27-29, 2014.
MIRKO STANISAK is a research assistant at the Institute of Flight Guidance (IFF) at the Technische Universität (TU) Braunschweig in Germany. He received his diploma in mechanical engineering (Dipl.-Ing.) in 2009 from TU Braunschweig.
MARK BITTER holds a Dipl.-Ing. in mechanical engineering from TU Braunschweig and has been employed as a research engineer at TU Braunschweig IFF since 2003.
THOMAS FEUERLE received his Dipl.-Ing. in mechanical engineering in 1997 from TU Braunschweig. He joined the TU Braunschweig IFF in May 1997. Since 2005, he has been the leader of the Air Traffic Management Team at the IFF. In April 2010, he completed his Ph.D. dissertation at TU Braunschweig.
FURTHER READING
• Authors’ Conference Paper
“Multiple Satellite Navigation Systems for the Ground Based Augmentation System,” by M. Stanisak, M. Bitter, and T. Feuerle in Proceedings of ITM 2014, the 2014 International Technical Meeting of The Institute of Navigation, San Diego, California, January 27–29, 2014, pp. 254–264.
• Standards Documents
Aeronautical Communications, Vol. 1, Radio Navigation Aids, Annex 10 to the Convention on International Civil Aviation, International Standards and Recommended Practices, International Civil Aviation Organization, Montreal, Draft Version, May 2010.
GNSS-Based Precision Approach Local Area Augmentation System (LAAS) Signal-In Space Interface Control Document (ICD), DO-246D, RTCA Special Committee 159, Global Positioning Systems, RTCA Inc. Washington, D.C., December 2008.
Minimum Operational Performance Standards for GPS Local Area Augmentation System Airborne Equipment, DO-253C, RTCA Special Committee 159, Global Positioning Systems, RTCA Inc. Washington, D.C., December 2008.
Minimum Operational Performance Specification for Global Navigation Satellite Ground Based Augmentation System Ground Equipment to Support Category I Operations, ED-114, EUROCAE Working Group 28 on Global Navigation Satellite System, European Organisation for Civil Aviation Equipment, Malakoff, France, September 2003.
• GBAS Research and Development
“Conception, Implementation and Validation of a GAST-D Capable Airborne Receiver Simulation” by M. Stanisak, R. Schork, M. Kujawska, T. Feuerle, and P. Hecker in Proceedings of ION GNSS 2012, the 25th International Technical Meeting of the Satellite Division of The Institute of Navigation, Nashville, Tennessee, September 17–21, 2012, pp. 250–257.
“Initial GBAS Experiences in Europe” by A. Lipp, A. Quiles, M. Reche, W. Dunkel, and S. Grand-Perret in Proceedings of ION GNSS 2005, the 18th International Technical Meeting of the Satellite Division of The Institute of Navigation, Long Beach, California, September 13–16, 2005, pp. 2911–2922.
By Tim Reynolds, GPS World’s contributing editor for Europe
This spring, two Brussels conferences focused on new possibilities and modes of transport enabled by satellite navigation, showing the added value delivered by current and future European GNSS solutions.
The European GNSS Agency (GSA) hosted the first gathering in February, discussing its GNSS Applications Action Plan in areas relating to road transport including smart tachographs, long-range buses, transport of dangerous goods, multimodal logistics, and road tolling. The 11th Annual Road User Charging Conference (RUC) in March, an industrial gathering, highlighted recent developments in truck tolling and a possible future breakthrough for lighter vehicles.
Huge Market
The GSA identified the road sector as the largest GNSS market segment (with location-based services) in its October 2013 Market Report. Most GNSS devices were already enabled for European GNSS services, either via EGNOS or Galileo. Developments such as lower costs for connectivity, growing numbers of embedded devices, intelligent transport systems (ITS), and vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communications, together with new European Union policies and regulations, drive new requirements for vehicle positioning, and GNSS technologies are poised to fulfill these.
In two specific policy areas, road tolling and eCall emergency response, GNSS shows particular promise for adding value and providing flexible solutions. The GSA manages a large portfolio of research and innovation projects to develop near-market applications in this area.
e-Freight
E-Freight, a vision of a paperless freight transport system where electronic data flow is linked to the physical flow of goods, can lead to future intelligent-cargo concepts to further automate and improve logistics. Positioning services naturally form an integral part of this concept. The increased availability, resilience, integrity, and accuracy offered by European GNSS will support the uptake and efficiency of e-Freight systems through georeferenced cargo-status monitoring, among other services, seamlessly delivered across transport modes and national borders.
Road Tolling
The GSA delivered its perspective on road tolling in advance of the later industrial conference. Location-based charging offers flexibility, easy extension of schemes, low transaction costs, and — most promising from an agency point of view — could have a big impact on traffic management and environmental policy. GNSS is becoming the technology of choice for free-flow road tolling with its three main advantages: coverage, availability, and no direct installation costs.
The final GSA presentation focused on authentication services offered by Galileo to benefit the next-generation digital tachograph, a device fitted to a vehicle that automatically records its speed and distance, together with the driver’s activity selected from a choice of modes. New government proposals for the digital tachograph will mandate the inclusion of GNSS technology.
Clearly, a tachograph requires a robust and trusted GNSS service that is also very low-cost and resilient against spoofing and other interference. An authentification signal provided via the Galileo Open Service could provide a suitable solution free of charge, offering global coverage and easily initiated in existing Galileo-enabled receivers and terminals when the service was introduced. There is growing interest in such a service and its market potential from a range of stakeholders.
Road-User Charging
GNSS should be a key enabling technology for a scalable and cost-effective approach to fair and flexible road charging. But despite its great promise, implementation of such schemes have proven difficult on both sides of the Atlantic.
GNSS-enabled road-use charging systems now operate in Switzerland, Germany, Slovakia, and Hungary for heavy-goods vehicles (HGVs). Plans are in hand for a similar scheme in France covering 15,000 kilometers of national roads. Russia aims to introduce a GLONASS-mandated operation, initially for 50,000 kilometers of federal road and perhaps half a million kilometers of regional roads.
Belgium plans a HGV GNSS-enabled system to start in 2016, initially using GPS and GLONASS signals, eventually covering its full 150,000-kilometer road system. On-board units (OBUs) will be mandatory, and the system will have the capacity to define up to 10,000 toll rates dependent on factors such as location, time of day, direction of travel, road, and vehicle category.
Factor of Seven. The flexibility and scalability of a GNSS-based charging system was demonstrated by the SkyToll organization that operates the road-user charging scheme for HGVs in the Slovak Republic. This system’s network coverage has recently been extended seven-fold from main motorways and major roads to encompass 17,762 kilometers, effectively bring all motorways and class 1, 2, and 3 roads under charge.
To achieve this with a terrestrial system would have required the construction 4,000 gantries, but the huge expansion was built using software in three months. “This is only possible via GNSS,” stated spokesperson Miroslav Bobošik.
The two-way communications possible with GNSS-enabled OBUs also meant that tariff and network models could be updated and amended quickly and easily. Charge collection efficiency exceeds 99 percent and is independent of road type. “There is a clear trend to GNSS-enabled systems due to their flexibility, efficiency and fast implementation,” said Bobošik.
Belgium First? On the first day of the RUC conference, a Flemish regional government spokesperson described plans for the Belgian road-user charging system for HGVs heavier than 3.5 tonnes that could be launched across the whole of the country in 2016.
In parallel to these developments for HGVs, a major pilot project for lighter vehicles, that is, passenger automobiles, has just started in Belgium’s GEN-zone. This area is effectively the capital city, Brussels, and its surrounding provinces of Flemish and Wallonian Brabant. The pilot will test the practicalities of a GNSS-enabled mileage-based charging system and involves 1,000 selected participants in a three-month trial. First results will be available in April, and the final report is due in the summer. This report will form the basis of future national policy on road-user charging and will likely be on the desk of the new Minister for Transport when he or she takes office after the upcoming Belgian elections.
If the political will is there — and post-election the necessary political capital may well be in place — could Belgium become the first nation to implement a GNSS-enabled road-user charging scheme for all vehicles as early as 2016? Watch this space!
Tim Reynolds is director of Inta Communication Ltd. and a long-term Brussels observer writing on many aspects of European government policy and implementation for a range of clients and publications. The material presented here was first prepared in a somewhat different form for the GSA.He is the contributing editor for GPS World’s new quarterly e-newsletter, EAGER: the European GNSS and Earth Observation Report. Subscribe free at env-gpsworld-integration.kinsta.cloud/subscribe.
In the mass market, individuals around the world are creating vast quantities of location data and GPS traces using not only GPS, but also Russia’s GLONASS, Europe’s Galileo, China’s Compass, and India’s Regional Navigational Satellite System. The value of this data and the value chains that produce it will increase significantly with an increase in interoperability of these satnav systems. Currently, non-interoperability represents a serious obstacle to the growth of the GPS market.
The overall system-of-system’s diversity of data formats, data models, processing models and associated custom- built one-to-one communication interfaces significantly inhibits introduction of new subsystems and also new GPS-dependent systems that would support development of future classes of stakeholders. “Many-to-many” networks based on open standards can create interoperability as well as opportunities for the introduction of new technologies, value-added data products, and new users.
To address this problem, sponsors of the 2012 Open Geospatial Consortium (OGC) OWS-9 Interoperability Testbed, including the U.S. National Geospatial-Intelligence Agency (NGA), documented a set of use cases and associated interoperability requirements, selected strategically to address problems whose solutions would be applicable in a wide variety of GPS value chains.
Technology providers participating in the testbed then implemented standards-based solutions that addressed the requirements. These were documented in a draft Engineering Report, “Use of SWE Common and SensorML for GPS Messaging.” The document focuses on the use of the OGC Sensor Web Enablement (SWE) Common Data 2.0 encodings to support an interoperable messaging description and encoding for the next-generation GPS message streams into and out of processing services that provide improved GPS navigation accuracy.
Standards. The OGC Sensor Web Enablement (SWE) suite of standards specifies models and XML encodings that provide a framework within which the geometric, dynamic, and observational characteristics of all types of sensors and sensor systems can be defined.
Furthermore, through standard web-service interfaces, one can task sensor and actuator systems and have immediate access to observations and alerts. SWE standards, now widely implemented around the world, enable developers to make all types of networked sensors, transducers, and sensor data repositories discoverable, accessible, and usable via the Web or other networks. OGC standards are downloadable at no charge, for use by anyone.
OGC Testbed
The OGC OWS-9 testbed’s OWS Innovations thread included a hands-on prototyping activity that addressed a particular set of interoperability requirements related to GPS accuracy.
GPS relies on accurate knowledge regarding the position, measured time, and state of the satellites, provided to GPS devices and processing centers in the form of satellite ephemeris data and status reports. The accuracy of the system relies on communication between the satellites themselves, the data collection systems, the data processing centers, and the GPS devices that ultimately determine their own location. This communication is through various data streams that consist of predefined message structures and encodings.
The accuracy of the positions derived from GPS can be negatively affected by several well-known factors. Improvements to the derived positions within the current operational system can occur (1) through occasional (once a day or once every few hours) updates to the satellites’ clock and ephemeris on-board information, or (2) through post- processing for applications such as geodetic surveying or image processing and georectification. Efforts are underway to provide more timely updates to satellites or positioning devices to improve the accuracy of positioning in real-time.
The GPS Correction Process
One view of the current system for correcting GPS positioning is provided in Figure 1. A GPS positioning unit (shown as a device with red thumb tack) receives signals from four or more GPS satellites derives its position. In addition, the information being sent by all satellites in the GPS system is also received at various receiving stations, stored as raw navigation data, and used to correct the clock and position information for all of the satellites. The correction process can utilize one or more operational processing systems for correcting satellite clock and ephemeris information. Each of these systems tends to utilize particular data sources and often output their results in different message structures and encodings.
FIGURE 1. Typical flow of data within the GPS correction system.
One such system for correcting the timing and positioning of GPS satellites is Estimation and Prediction of Orbits and Clocks to High Accuracy (EPOCHA). Currently, navigation and timing improvements are only uploaded to the satellites and GPS devices once a day. To improve the EPOCHA system, the National Geospatial Intelligence Agency (NGA) is researching the logistics and benefits of updating the navigation and timing information at much shorter time frames (for example, every 2–15 minutes).
The corrected satellite clock and state data can then be sent to the satellites, to the processing centers to improve geolocation of real-time or archived positions or remotely sensed observations, and to devices in the field to improve real-time position measurements.
A processing system in widespread use for applying these corrections to positional measurements is the open-source GPS Toolkit (GPSTk). This software was used in OWS-9 to demonstrate the processing of SWE Common encoded GPS data within a Web-enabled environment.
As shown in Figure 1, the data flowing between archiving and processing components exist in a wide variety of formats. Currently, these message streams consist of message structures defined through various documents, some of which have restricted access. Additionally, these streams and the messages they contain are being encoded in various formats, including, for example, a binary exchange format (BINEX), a system-specific XML schema, an HDF5 file format, several text-based formats, and others.
The message components within each of these formats are inconsistent, even though two messages may describe similar information. Often a processing system is required to read data and output results in multiple formats and to understand the inconsistencies between them.
By forcing different software and processing systems to support multiple message structures and data formats, the current system inhibits the effective use of these data by:
requiring several format-specific readers and writers to be developed in the appropriate software language (C, C++, Java, Python) as required by each application system;
providing inconsistent message structures between the data used or produced by different processing systems;
requiring meticulous and thus error-prone human interpretation of the data components based on the limited documentation provided for each;
creating lack of interoperability with regard to using data designed for or produced by a different particular processing system; and
discouraging development of new and innovative software and processing solutions.
The Engineering Report addresses the feasibility of using the OGC SWE Common Data v2.0 standard to support all message and data streams within future generations of the GPS operational network. In particular, the effort focuses on message streams that provide input to and output from the processing systems responsible for providing improved position and time accuracy within the GPS network.
Here are the benefits of the SWE Common Data standard:
The data can be fully described in a machine- and human- readable XML document providing: data type, units, constraints, semantics, quality, labels, and so on; and an unambiguous definition of both the data structure and encoding of messages/records.
The data values themselves can be encoded in highly efficient binary or ASCII text blocks or streams.
A single software application is able to read any data described in SWE Common data.
Any process can be described in SensorML using SWE Common as inputs, outputs, and parameters.
Any SensorML-defined process can participate in easily-defined executable workflows.
The Engineering Report describes the formats and how they were encoded, and the Web services created to move data between various GPS processing systems (FIGURE 2).
FIGURE 2. Collection of SWE services providing on-demand access to all GPS-related data in the project.
Conclusions
A common standards framework for all data files and streams within the GPS system would significantly improve interoperability between data centers, processing centers, and user tools.
In addition to a common encoding, common models for equivalent message or data records would also be important for interoperability among data, processing centers, and the tools. Common models and a common data framework enable rapid reconfiguration of workflows using different GPS processing products. Likewise, the availability of a common Web service interface enables one to rapidly and flexibly request specific data products and feed them into an executable workflow.
Here are further benefits:
SWE Common Data framework is fully self-described and machine readable.
Common models for all data would support “mix-and-match” capabilities within the processing workflows.
SWE Web services enable on-demand access to various GPS data products using a common framework.
SWE Common Data enables use of SensorML for readily defining and executing various workflows on demand.
Future Directions
Further research and development should move closer to a highly interoperable GNSS system that meets the needs of a broader community of users and enables the development of new supporting software by outside communities. Thus the following are recommended:
Design and reach consensus on consistent data models for all message types in navigation, observation, and state data streams.
Incorporate SWE Common Data readers/writers in the GPSTk toolkit.
Create SensorML descriptions for GPSTk apps.
Demonstrate on-demand design and execution of SensorML-defined workflows for GPS correction.
Demonstrate on-demand geolocation of UAV, ground-vehicle, and hand- held sensors using SWE services and encodings.
Some of these needs will be addressed in the OWS-10 Testbed that is currently ramping up in the OGC.
MIKE BOTTS is president and CTO of Botts Innovative Research, Inc, specializing in the design and application of open standards for sensor systems. He is the creator and chief architect of Sensor Model Language (SensorML), an OGC technical standard for describing the measurement and processing of observations from virtually any sensor system.
This month’s column is a short one since I’m attending GEOINT 2013* in Tampa. The asterisk on 2013 is a way for USGIF to save a few bucks by not reprinting banners, displays and handouts for the 2014 date. In talking to the USGIF staff, I learned this will be the only symposium for the year, with the next GEOINT Symposium being held in the spring of 2015. The location will be announced soon.
For your information, this is the latest list of keynote speakers:
The Honorable James R. Clapper, Director of National Intelligence (DNI)
LTG Michael T. Flynn, U.S. Army, Director, Defense Intelligence Agency (DIA)
Ms. Letitia A. Long, Director, National Geospatial-Intelligence Agency (NGA)
ADM William H. McRaven, U.S. Navy, Commander, U.S. Special Operations Command (USSOCOM)
Ms. Betty J. Sapp, Director, National Reconnaissance Office (NRO)
Mr. Robert Scoble & Mr. Shel Israel, Co-Authors, “Age of Context”
While attending next week, I’m going to shoot video clips and write blogs that will be posted to this publication. If you’re attending GEOINT and see me (bald head, easy to spot), please stop me and say hello.
If you won’t be able to attend and need eyes on a particular presentation or exhibitor, please contact me. I’ll try my best to sit in on the session and take notes, or visit an exhibitor’s booth to get the information you need. I may shoot a video clip, or at least give you my impression of the session or booth.
