Coordinate-Time and Navigation Support System of Ukraine
This educational lecture series is based on public engineering principles, historical context, and the author's own professional experience. Certain elements have been reimagined in lecture-narrative form for educational clarity.
Lecture Series: Coordinate-Time and Navigation Support System of Ukraine (CTNS/SKNOU)
Day 1: Navigation and Precision
Lecturer: Dr. Andrew, Senior Researcher, Navigation Systems Laboratory
Date: March 2003
Introduction to the Topic
Students from the aviation university attended their first lecture in the navigation systems laboratory, where they were introduced to practical aspects of high-precision navigation and real-world engineering challenges.
Dr. Andrew – Senior Researcher
Standing before the students was a middle-aged man whose posture and focused gaze immediately conveyed a background of precision engineering and advanced technology. His neatly buttoned shirt and composed movements reflected a disciplined and methodical personality.
Right beside him stood the towering frame of the Control and Correction Station (CCS) — the core of the navigation system, integrating state-of-the-art engineering solutions. Beneath its metallic shell were housed satellite signal receivers, an atomic time and frequency standard, a UNIX-based computing module, a router, and multiple data transmission modems. Every component had a single purpose — to ensure the highest possible accuracy and reliability in navigation calculations.
In the dimly lit laboratory, equipment indicators flickered rhythmically, processing a continuous stream of incoming signals. It felt as though the station itself was alive — working, analyzing, and adapting in real time. This wasn't just a set of devices; it was a coordinated intelligence node where every process, every computation, and every algorithm worked in harmony to deliver stable time and positioning references.
"Welcome to the lecture series," Andrew began after a short pause, evaluating the young engineers. "My name is Andrew. I hold a PhD from Kharkiv Aviation University. I've been working in the field of navigation systems long enough to witness how deeply this technology affects security, precision, and geopolitics."
Why Is Independent Navigation Critical?
Dr. Andrew turned to the board and sketched a satellite constellation.
"Many of you consider GPS to be the ultimate and reliable solution," he said. "But in reality, it's a geopolitical tool."
He turned back to the audience and continued:
"When we were preparing a space-launch vehicle test at the Plesetsk Cosmodrome, something unexpected happened. The launch schedule was set, and all preparations were complete. Everything was going smoothly — until the GPS signal became unavailable over the test area shortly before the scheduled launch."
Andrew paused to let the students think.
"What do you think happened?"
Someone cautiously responded: "Equipment malfunction?"
Andrew shook his head.
"The launch was moments away when the GPS signal over the test range suddenly disappeared. We had no choice but to scrub the countdown and wait two tense hours. As the engineer who had been recording every measurement that day, I later reviewed the logs. The pattern was unmistakable: someone had deliberately restricted GPS coverage exactly over our location at the most critical moment.
"That day left a permanent mark on me as an engineer. It was a powerful, real-world lesson — no matter how flawless your preparation on the ground, you can still find yourself completely dependent on a navigation sky controlled by forces beyond your reach. It was one of those moments that shapes how you think about sovereignty in high-precision systems for the rest of your career."
The Danger of Selective Availability
"Now imagine such interference not during a test, but in any real-world system that depends on continuous precise positioning," Andrew continued. "If Selective Availability mode is activated, the consequences can be serious."
"What would happen then?" a student asked.
"Positioning accuracy would degrade significantly — from a few meters down to 80–100 meters or even worse," Andrew replied. "This is unacceptable for applications that require meter-level or better precision, such as civil aviation, marine navigation, geodesy or precision agriculture."
Why Ukraine Needed Its Own System
Andrew took a step toward the whiteboard and wrote in bold letters: SKNOU = Navigation Sovereignty
"This is why Ukraine had to build its own navigation infrastructure. We couldn't afford to rely on GPS or GLONASS alone."
A student raised his hand: "But why was Ukraine so dependent on GPS? Couldn't we use GLONASS instead?"
Andrew sighed: "Because in the 1990s, Ukraine lost virtually all its strategic aerospace capabilities. The political leadership gave up long-range missiles, strategic bombers and other key assets in exchange for international security guarantees."
Navigation and Military Conflicts
Andrew switched the slide and continued:
"The SKNOU system wasn't just built to keep an eye on navigation inside Ukraine — it was also designed to let us independently check how accurate the big global systems really were. Back in early 2003, I was digging deep into NAVSTAR's performance."
Andrew paused for a moment, his face growing more serious.
"During my time in the Air Force from 1984 to 1986, I personally worked on more than 500 operational flights of a MiG. To give you an idea of what that meant — that's roughly the same workload a single U.S. Navy fighter squadron would carry during a major operation. It wasn't textbook stuff. It was real-world engineering under pressure, where every check, every decision, and every mistake could have serious consequences. That experience shaped the way I think about navigation systems to this day."
One of the students asked, "What did you find?"
"According to the data from our SKNOU stations in early 2003, the positioning accuracy was unusually high. Instead of the normal 6 to 10 meters, we were seeing errors of less than 2 meters. For me as an engineer, that level of precision was a clear technical signal that something major was coming — something that would demand top-tier navigation performance."
Andrew added: "Based on those measurements, I reached the conclusion that a large-scale operation requiring high-quality navigation was being prepared."
The students looked at each other.
What Is SKNOU?
Andrew advanced to the next slide, which displayed a schematic diagram of the SKNOU architecture.
"SKNOU is a system designed to maintain navigation accuracy across Ukraine. It follows the principles of the European EGNOS system and works in conjunction with both GPS and GLONASS signals."
He walked over to the screen and pointed to the two key components:
- RPNP – Regional Navigation Field Monitoring Point
- CCS – Control and Correction Station
System Characteristics
Andrew projected a table summarizing the accuracy levels across different SKNOU service modes (where DCI stands for Differential Correction and Integrity):
| SKNOU Services | Wide-Area DCI (Code) | Zonal DCI (Code) | Local DCI (Code) | Local RTK (Phase) DCI | Network RTK (Phase) DCI |
|---|---|---|---|---|---|
| Accuracy, 2σ (RMS) | 1m (horizontal) 2m (vertical) (within network corners) |
<1m (within 150 km radius) |
0.2m–1m (30–150 km from CCS) |
0.02–0.2m (within 30 km of CCS) |
0.02–0.04m (uniformly within RTK cell) |
"It's important to understand," Andrew emphasized, "that each mode offers different levels of accuracy. Wide-area DCI is suitable for applications like aviation and maritime navigation, while RTK services are used in geodesy and precision surveying."
Testing the Ukrainian Segment of EGNOS
He switched slides again.
"Back in the 2000s, we successfully tested Ukraine's segment of EGNOS. This confirmed full compatibility between SKNOU and the European navigation infrastructure."
A map appeared on the screen, showing marked control points.
"We deployed monitoring stations in Kharkiv, Simferopol, and Luhansk. These sites analyzed satellite signals and transmitted their data to the Central Navigation Processing Center (CNPC)."
Conventional Designations
Andrew wrote on the board for everyone to copy:
Development Stages
Key Navigation Terms
Navigation and Precision: A Scientific Internship Diary
Control and Correction Station (CCS)
Andrew led the students into a secure laboratory where one of the operational Control and Correction Stations (CCS) was housed. Inside, server racks buzzed with activity — real-time satellite data was being captured, analyzed, and corrected.
Andrew used a bilingual learning method to explain the station's architecture, constantly toggling between the schematic and the physical hardware. He treated the diagram as the "theory" and the live equipment as the "practice." This parallel approach, much like reading a bilingual text, helps bridge the gap between concept and reality, ensuring a deeper, more practical grasp of how the system truly works.
"This is the beating heart of SKNOU," Andrew said, gesturing toward the racks of precision equipment. "Control and Correction Stations provide high-precision navigation by receiving, analyzing, and correcting signals from GPS and GLONASS satellites."
He continued, outlining the system's structure:
- Roof-mounted receivers – capture GNSS signals from visible satellites.
- Computing center – processes raw data and calculates differential corrections.
- Transmitters – broadcast correction data to end users over secure channels.
Architecture of the Control and Correction Station
The CCS is one of the system's most critical nodes. Its architecture is based on modular principles and includes:
- High-sensitivity satellite signal receivers
- A robust computing cluster for data analysis and integrity monitoring
- Precision frequency standards
- Routing and communication modules for external data transmission
Together, these components ensure that the CCS effectively eliminates distortions caused by ionospheric and tropospheric interference, thereby increasing both horizontal and vertical positioning accuracy across the system.
Andrew paused at the schematic diagram and said: "The CCS didn't emerge from nowhere. Its architecture evolved from earlier systems like 'Collection', 'Unified Control Center (UCC)', and 'Breeze'."
Measurement Information Concentrator
Typical "1990s Information Concentrator"
Used as the closest analogy in building the CCS (Control and Correction Station).
The image shows a John Deere tractor with a multi-section plow, figuratively and accurately reflecting the concentrator architecture:
🚜 Tractor = PC Host (Pentium 4)
Powerful control node that performs computations and system management. Contains the operating system and executes primary processing tasks.
🔗 Hitch = 8-port Multiplexer
Aggregates data streams from the synchronization processor to channels. Serves as the distributing link between computations and communication lines.
🔧 Plow = Synchronization Processor (SP)
Divides the task flow from the PC into multiple independent channels. Synchronizes each communication line and manages concurrent operations.
📡 Furrows = Communication Channels
8 or more simultaneous lines: serial ports, radio channels, network interfaces. All operate independently and in parallel.
🧑🌾 Tractor Driver = Application Layer
Determines route, controls direction, speed, timing, and movement precision. Implements high-level navigation algorithms.
📌 Conclusion: The "Information Concentrator" architecture was adopted and enhanced with sophisticated application layer development, solving navigation challenges as described in lectures by Senior Research Fellow Andrew, to create the CCS — Control and Correction Station, operating in real time.
In these predecessors, the concept of a measurement information concentrator was implemented and tested under real-time operational conditions. UNIX-based platforms provided the backbone for multitasking, fault isolation, real-time processing, and priority message switching.
The Breeze system, in particular, introduced the use of a dynamic status map — a visualization tool that showed the condition of each communication channel. This map enabled instant operator decisions, GNSS sky plot generation, and high-level performance analytics, all in real time.
UNIX Process Management: Like a Well-Organized Pool Party
Extended UNIX Operating System Metaphor:
🏊♂️ Swimming rings = individual processes, each with its own PID (participant number). Can be different sizes (memory footprint) and colors (priorities), but all use shared pool resources.
💻 Workstation in center = system kernel, which monitors all processes in real time, manages resource allocation, and makes critical scheduling decisions.
🌊 Water streams = inter-process communication (IPC): stdin flows from above, stdout exits through pipes, stderr can be redirected to separate channels.
🏊♀️ Inflatable mattress = shell interface (command line), from which child processes "dive" into water when executing commands, controlling their execution.
🏀 Ball = shared memory or file descriptors that processes can pass to each other or use collectively.
🪜 Ladder = system calls — the only "legal" way for processes to interact with the kernel and request system resources.
⭕ Pool diameter = available memory size (RAM) — a fixed system limitation that determines how many processes can comfortably "swim" simultaneously.
💦 Water level = current system load — when the pool overflows, some "swimmers" are temporarily moved to an adjacent water barrel (swap partition on disk).
🌡️ Water temperature = processor load and temperature — the more intensively processes work, the "hotter" the system becomes, requiring cooling or throttling.
🧪 Water chlorination = security and access permissions system — maintains system "cleanliness," preventing infection by malicious processes and controlling resource access.
🏊♂️ Lifeguard = error and exception handling system — watches for "drowning" processes, intercepts critical situations, and prevents total system crash.
🔄 Water circulation = task scheduler, which ensures fair distribution of CPU time among all processes.
In SCNOU, we didn’t just swim in UNIX — we turned it into a fully managed waterpark for real-time systems.
Like a well-organized pool, in UNIX every element has its place and function, and the overall system works smoothly thanks to clear rules and reliable management. This metaphor transforms abstract operating system concepts into an intuitively understandable physical scene — a perfect example of explaining complexity through simplicity.
"Tomorrow," Andrew concluded, "we will explore how the CCS communicates with Regional Navigation Field Monitoring Points (RPNPs) and how this collaboration forms the SKNOU network backbone."
Summary
"That concludes today's lecture," Andrew said. "For your independent study, please review the following materials. I hope you've come to realize that navigation is not merely a collection of formulas — it is a matter of navigation sovereignty."
"Tomorrow, we'll dive into Input Data — the real datasets processed by the system. Be prepared — it's going to get a lot more technical."
Additional Study Materials
As the students were heading out, Andrew called out: "Take a quick look at the Purpose and Characteristics appendix when you get a chance — it'll help keep us all on track with our satellite navigation journey."
Lecture Tables:
📎 Open Appendix – Day 1
Homework
Note (Looking Ahead to 2004):
The following year, Andrew (technical architect, Ukraine) will play a pivotal role in advancing GNSS experimentation and infrastructure.
His contributions include:
- Development and documentation of all feasible broadcasting methods for GNSS differential corrections within the EGNOS/ESTB framework.
- Establishment and maintenance of a satellite radio link between Kharkiv and Norway for real-time correction delivery.
- Analysis of multipath effects in GNSS signal reception using the PEGAS software, within the KKS complex.
- Technical leadership in coordinating national infrastructure for GNSS experiments.
-
🔗
EGNOS System Test Bed – Ukraine Participation (UNOOSA, ICG 2015)
(Document confirming Kharkiv’s role in the 2004–2005 EGNOS/ESTB experiment)
In 2004, the Kharkiv station participated in preliminary trials for Ukraine’s integration into the EGNOS system (see EGNOS on Wikipedia) . As part of this effort, establishing a direct data link between Kharkiv and the processing center in Norway required overcoming a range of technical and regulatory challenges — one of the most critical being the authorization to use a dedicated satellite communication channel.
At the time, this meant navigating Ukraine’s Radio Frequency Service (now known as the Spectrum Management Authority), which involved preparing a detailed roadmap with over 20 technical and procedural steps. The responsibility fell on Andrew, who took full charge of the process — from formalizing the requirements to managing all bureaucratic procedures.
The goal was clear: to establish a reliable, properly authorized satellite data exchange between the two countries. It was far from a pleasant job, but without it, the signal would never have made it through.