From Forced-Labor Labs to Russia’s First Intranet: A Tale of Suppression and Technology

By Andrii Nikolaiev, a Ukrainian Principal Engineer and Project Representative who led the Unified Control Center project during Russia’s short-lived democratic era under President Boris Yeltsin.

A painting from Plesetsk command headquarters — not mere art, but an “icon” of a cult where Russian generals drew strength from feeding on fear, romanticizing nuclear apocalypse as heroism. Like the Kremlin’s “desatanization” narrative that frames invasion as salvation, this imagery normalized destruction inside military corporate culture. Hidden for decades, it thrived on secrecy. Publishing it here strips away its power — like disclosing a vulnerability in legacy code.

Introduction: Why Critique?

Russia’s full-scale invasion of Ukraine in 2022 has forced Ukrainians to re-evaluate their historical ties and condemn the aggressive revival of imperial ambitions. For me, a Ukrainian who worked on Russian defense-related technology decades ago, it’s crucial to explain that these projects were carried out when the Russian Federation, under Boris Yeltsin, attempted a more democratic path. Today’s Russia has veered into authoritarianism under Putin—a stark contrast to the relative openness of the 1990s. This article describes how early Russian intranet technologies emerged from a legacy of forced labor and oppression, illuminating a darker side of Soviet and Russian history.

The Roots of Soviet Cryptography: “Sharashkas” and the GULAG

What Were the Sharashkas?
During Joseph Stalin’s rule, the Soviet Union operated a vast system of labor camps known as the GULAG (an acronym in Russian for “Main Administration of Camps”). Millions of people, often political prisoners, were forced to work in brutal conditions. Among these camps were special prisons nicknamed “sharashkas,” where imprisoned scientists and engineers were compelled to develop top-secret military and technological projects.

Prisoners of Vorkutlag, 1945

One such facility was established in 1948 in a place called Marfino, near Moscow. Here, some of the finest minds—both Soviet and, at times, foreign specialists captured or coerced—worked under harsh scrutiny, creating apparatuses for encrypted telephony. The Nobel Prize–winning author Aleksandr Solzhenitsyn, himself a sharashka inmate, described these conditions in his novel The First Circle. According to him, the prisoners had no real hope of release; they were there to invent whatever the state demanded.

The Nobel Prize–winning author Aleksandr Solzhenitsyn, himself a sharashka inmate, described these conditions in his novel The First Circle

Marfino, the former cryptographers' prison, before restoration. The image was taken in modern times.

The tower of Marfino, the prison for cryptographer engineers

General plan of the cryptographer-engineers’ prison in Marfino

Specialists under coercion in the NKVD/MVD system, 1940s-1950s.
Similar conditions existed across various Soviet secret facilities — from Marfino's cryptographic laboratories
to rocket research on Gorodomlia Island.

Why Is This Relevant to Modern IT?
The encryption devices and secure communication methods pioneered in Marfino formed the backbone of later Soviet cryptography. Though these engineers were often denied their own freedom, the fruits of their labor were used to protect state secrets. This paradox—where technology advanced on the backs of forced labor—would shape the mindset of Soviet (and later Russian) informatics for decades.

NIIRI and the Birth of a Secret Intranet

NIIRI (Research Institute of Radio Engineering Measurements)
In the late Soviet and early post-Soviet period, one of the key research centers was NIIRI, or the Research Institute of Radiotechnical Measurements, based in Kharkiv (now Ukraine). This institute worked on various military and aerospace projects, including radio measurements and trajectory tracking for missiles and spacecraft.

A 1991 Milestone in Kharkiv
By 1991, inside a laboratory at NIIRI, an internal network (an intranet) began to operate—an early prototype that would pave the way for what became a larger, classified military network in Russia.

Launching “Collection” in 1993
Two years later, in 1993, Russia officially deployed the first large-scale, secret intranet—part of a system called “Collection.” Overseen by Ukrainian engineer Andrii Nikolaiev (then affiliated with NIIRI in Kharkiv), this network initially linked strategic sites across Russia, including the Plesetsk Cosmodrome and an associated tracking facility known as “Vega” in the Arctic city of Vorkuta.

While the West was developing open Internet protocols to connect universities and businesses, “Collection” was strictly classified. It employed T-230 “Interier” encryption hardware—direct descendants of Marfino-era cryptographic methods—to ensure secrecy. For the Russian government, it was less about collaboration and more about surveillance and control.

Russian signalmen operate the secret telephony equipment T-230 ‘Interier’.

A Legacy of Fear: Why Vorkuta and Plesetsk Matter

Plesetsk: Don’t Drink the Water

Plesetsk Cosmodrome. Rocket preparation for launch

Plesetsk — a cosmodrome whose name translates as "a calm, wide section of a river and numerous lakes"

Plesetsk Cosmodrome. Rocket preparation for launch

Plesetsk Cosmodrome. Rocket preparation for launch

Vorkuta: A City Built on Bones
Vorkuta, in the Komi Republic of northern Russia, once hosted the vast Vorkuta Gulag complex. Temperatures can plummet to -40°C, and inmates—called “white coal” by guards—were forced to mine coal in 12-hour shifts. Starvation, executions for minor infractions, and rampant disease claimed countless lives. Today, Vorkuta’s population has shrunk drastically. Yet remnants of mass graves remain in the permafrost, a silent testament to this brutal legacy.

Vorkuta. The cost of coal — extracted using forced labor — was extremely low

Connecting the Dots
Out of these inhospitable locations—Plesetsk with its contaminated wells and Vorkuta built on GULAG graves—emerged Russia’s first high-security intranet. While the Western world championed open protocols and academic freedom, the Soviet (and later Russian) system thrived on top-down secrecy. Even in the supposedly democratic window of Yeltsin’s presidency, these networks retained a deep paranoia inherited from Stalinist times.

ECU (UCC): A Unified Control Center for Ballistic Tracking

Alongside “Collection,” engineers developed a subsystem known as UCC (“Unified Control Center”). The idea was to manage real-time trajectory data for strategic missiles and other military launches scattered across Russia’s massive territory. If a rocket was launched from Severodvinsk (near the Arctic coast) or from a site in Kamchatka (far east), the network could rapidly gather external trajectory measurements, predict the projectile’s path, and re-target tracking antennas accordingly.

This was an impressive technical achievement, involving a distributed computing architecture that linked multiple isolated stations. Yet the ever-present “prison logic” hovered in the background. Soviet-legacy rules, harsh deadlines, and the weight of military secrecy shaped the project’s culture, echoing the ethos of the sharashka system.

From the GULAG to a Secret Intranet: The Price of Control

In the United States, the Internet blossomed in open environments—university labs, private garages, venture-funded startups—where freedom to innovate was prized. In Russia, by contrast, the first intranet was quite literally forged behind barbed wire. It was a direct spiritual successor to the forced-labor labs of Stalinist times.

• “Ours is a great history,” many Russians say. But they often omit the bones, the fear, and the slave labor behind that grandeur.
• Western projects like ARPANET ultimately led to the global, publicly accessible Internet.
• Russia’s intranet remained closed, secretive, and used for military and security purposes, shaped by an age-old tradition of suppressing open discourse.

Conclusion: A Ukrainian Engineer’s Perspective

You might ask: Why does a Ukrainian engineer write about Russia’s clandestine networks so critically? The answer is simple:

1. War and Moral Responsibility. Since 2022, Russia has waged a brutal war against my home country, Ukraine. Silence or neutrality could be misinterpreted as complicity or sympathy for Russia’s actions. I must highlight the repressive nature of Soviet and current Russian regimes, to clarify that my past work occurred under very different historical conditions—specifically during Boris Yeltsin’s short-lived democratic experiment in the 1990s.

Kharkiv school destroyed by Russian occupiers. Ukraine, 2022

1. Context for Technical Details. This article is only half of a larger piece; the second half dives into the technical specifics of intranet architecture, encryption, and distributed computing. Without the historical and moral context, one might miss the darker realities that shaped these systems.

Work in a sharashka. The overseer to the imprisoned engineer: "Integrate!"

1. Historical Lessons. The story of “Collection” and UCC shows how advanced technology can flourish even in oppressive environments—but at a terrible human cost. Recognizing that cost is essential, especially now, when the Kremlin’s war in Ukraine is reigniting the same logic of fear and coercion that once fueled Stalin’s GULAGs.

Ultimately, understanding this history is vital for anyone who values freedom—particularly American IT professionals and students who see the Internet as a symbol of open collaboration. In Russia’s case, the drive for secrecy overpowered that spirit of openness. While I remain proud of the engineering achievements my colleagues and I accomplished under Yeltsin’s more democratic (though imperfect) Russia, I cannot ignore the moral burden that underlies the entire Soviet and now neo-imperial framework.

Yes, technology can be born of oppression—but at what price? That question resonates loudly today as the world watches modern Russia revert to its darkest impulses.

Photographs of prisoners and a supervisor from Marfino prison.
1. Foreign methods of frequency compression proved unsatisfactory. In early 1949, engineer Nanos developed a new compression scheme in the laboratory with speech frequency division.
2. Preparation for general testing of the electrical frequency compressor.

This concludes the historical and political overview. The second half of this article provides a technical deep dive into the architecture, protocols, and encryption methods that powered “Collection” and UCC.

Technical Part: How "Rough Systems" Became "High Society" of the Network World

In the distant 1990s, we—a group of slightly sleepy but extremely persistent developers—began cobbling together from various "iron boxes" and software components the "Collection" system (collecting external trajectory data on missiles) and the Unified Control Center (UCC) (commanding this entire operation). Imagine someone deciding to build "Lego" from parts that don't fit together at all, with one set pulled from a Soviet-era closet and another from the dark depths of secret warehouses where they even economized on lighting.

Now that the difficult historical context is clear—the legacy of the GULAG, the culture of secrecy, and political instability—we can truly appreciate the engineering marvel that was created from practically nothing. We will now transition from that grim history to a celebration of engineering ingenuity and see exactly how a team of Ukrainian developers made this 'orchestra' of legacy hardware and advanced ideas play in harmony.

Measurement systems along the Northern Route of the Plesetsk Cosmodrome – tracking stations from Mirny to Kamchatka

Although today Russia (to put it mildly) doesn't show itself in the best light on the world stage, back then, under Yeltsin, it seemed that something more free and democratic was coming. But we had no time for political dreams—we ran around with soldering irons, cables, and heaps of fragmented manuals to create a system capable of operating in real-time over encrypted channels. Yes, exactly!

1. What "Wonders" We Had to Deal With

1. Measurement stations scattered across vast territories.
   Each site was built in its own way, like an architectural project of "however I want to do it." Bringing them into one ensemble was roughly like assembling an orchestra where one knows the notes, another plays "by ear," and the third considers a trombone a type of saxophone.
2. Real-time: no excuses!
   When it comes to missiles, a delay or communication break is not a reason to "go have some tea and restart." Everything had to work fast, clearly, and without hysterics.
3. Secret encryption boxes.
   We developers were only allowed to stick a cable in there, while "what's inside" was hush-hush. Everything worked as if there was a capricious gnome sitting inside who would turn the connection on and off at will.
4. Outdated telephone lines, and sometimes telegraph channels.
   Imagine wires that had seen both -40°C frost and wild mosquitoes. But on them we managed to transmit digital data.

2. ISO/OSI: "Theory" Met "Our Rake Stepping"

We were very proud of our "multi-layered" architecture based on the ISO/OSI model.

Adapted Reference Model for Open Systems Interconnection (Adapted OSI Model)

Our key modification: The yellow layers represent standard ISO/OSI functionality, while the blue layers show our specialized extensions. These custom layers enabled seamless integration with radio-technical trajectory measurement systems (Vega, Kama-A, Kama-N, and others), handling both trajectory data frame transmission and bidirectional command/acknowledgment messaging for measurement control.

If in theory people often ignored the session layer, we decided: "How can we do without it when every test launch is a separate session?"
Physical layer, data link+network, session, presentation, application — everything was "brought to life" by our implementations. And this turned out to be far from simple.

Information concentrator software for integrating measurement systems (MS) with heterogeneous data transmission and processing networks

Many books on enterprise integration were born 10-15 years later: for example, Hohpe and Woolf released their pattern collection as late as 2004. But we were already practicing similar ideas in 1991-1993, not suspecting that someday they would be called "patterns."

3. Session Layer: The Star of Our Show

Most theorists considered the session layer redundant. We went all-in. OPEN, SEND, CLOSE — these primitives allowed starting a session, transmitting trajectories and commands, and when communication broke, restoring it without dropping the overall logic.

The session layer implementation method in the "Collection" system is based on creating primitives — special envelopes for meaningful trajectory information

This is my personal contribution: writing and debugging a real "session layer" that lasted many years in harsh operation.

4. UNIX: Friend, Savior, and "Parallel World"

At that time Windows 95 didn't exist yet, and Windows 3.1 didn't shine with multitasking. But UNIX already provided:

• Full multitasking so processes could run in parallel.
• TCP/IP "out of the box" where we could plug in our homemade network code.
• Message queues, FIFO, signals to separate the administrative module from the main processes.

I often say that UNIX and Linux are undervalued in the corporate sphere. What a pity—even in the 90s they allowed enjoying stability and flexibility.

5. Secret Cryptographic Devices: Taming the "Black Box"

The T-230 "Interier" was like an invisible room host: you could only feed it a cable, but looking inside was forbidden. Communication would break, the encryptor would lose synchronization. We had to implement "adaptive recovery logic" — if connection was lost, the software would immediately try to "knock on the door" and negotiate anew. Probably reminds you of playing with a cat that only lets you in if it likes you.

Tracking protocol of the data link layer sublayer - the basis for automatic communication recovery on closed communication lines

Algorithm of the tracking block operation for determining the phasing moment

6. "Rough Systems" and "TCP/IP High Society"

Information concentrators became polite butlers who introduced "rough, wild" measurement systems (created in different eras and by different standards) into the "fine society" of modern protocols. Now these "prehistoric" devices could communicate with elegant network clients via TCP/IP, like schoolchildren at graduation suddenly finding themselves in the company of titled guests.

7. Priorities: Urgent and Non-Urgent Messages

In real-time mode, it was important to distinguish "urgent" commands (going immediately) from "non-urgent" ones (which could wait). We created priority queues. Urgent packets pushed forward without queuing, while the rest of the data mass waited patiently. Later in Western literature this was described as priority queue, but we already had everything running properly in 1993.

Control channel provisioning mechanism within shared pipeline

Priority message scheduler pseudocode with ring buffer drain mechanism:
n — number of elements currently in the buffer; N — buffer size; X — message content

8. Results: Persistence Wins, Even with Old Cables

By the end of the 90s, "Collection" and UCC had survived numerous trials. They exchanged data through unpredictable channels, acquired additional modules, but remained resilient. What can we take away?

• Persistence + UNIX = we defeated even secret encryptors and crackling communication lines.
• Session layer — not empty theory, but an effective thing if you take it seriously.
• Don't wait for ready-made Western books — sometimes it's worth becoming pioneers yourself.

Over time, "Collection" ideas were applied to peaceful developments in Ukraine: hydrometeorology, seismics, mobile networks. Engineering thought knows no boundaries and sometimes produces results — even if funding is modest and the environment is far from "Silicon Valley."

Note. Inconvenient Truth

At the turn of the centuries, telegraph communication lines
were integrated into the closed Intranet
of Russia's Strategic Missile Forces

If you think we only integrated telephone communication lines, I'll have to disappoint you: we also connected telegraph lines with speeds of a whole 50 or even 200 bits/s! Yes, exactly that — not kilobits, not megabits, but "full power" of a couple hundred bits. As they say, "what country — such networks". But nothing, they also fit into our intranet, proving that when engineers stubbornly want something, even "prehistoric channels" can become part of quasi-modern infrastructure.

These telegraph lines carried data from Kama-A radar stations. Kama-A tracked space launch vehicles during orbital insertion. Accuracy requirements for putting military satellites into orbit were less stringent than for strategic ballistic missile launches. Onboard transponders for Kama-A operations were also much smaller and cheaper than those used with "Vega" measurement systems. This made the low data rates of telegraph channels quite sufficient for tracking space launches in our distributed network.

How We Built an "Orchestra" Where Everyone Played Their Own Instrument

When you look at these diagrams, it feels like we didn't just build a system, but a full-fledged symphony orchestra, where everyone plays their own way, yet somehow it all works:

Orchestra of the Unified Control System: Conductors, Concertmasters, and Musicians

🎼 The Unified Control Center (UCC) – the conductor, waving the baton and pretending everything is under control. Although sometimes the orchestra plays something completely different.

🎺 The Data Collection and Processing Center (RMW) – the concertmaster, trying to bring harmony to the chaos. Sometimes even successfully.

🥁 The Measurement Points – musicians scattered across the stage. Some pluck strings gently, others bang on drums, and one is even blowing into a hose instead of a trumpet.

To make this all sound coherent, we had to invent the session layer – something like a network "handshake" that forces the musicians to play in sync. Without it, everyone would perform their own solo while the conductor nervously smoked in the corner.

But there was a catch – 1991–1997. No fancy interfaces, no magic. Everything ran on UNIX. If modern systems automate everything, for us, message queues were our sheet music, and the commands OPEN, SEND, and CLOSE were the conductor’s cues:

• 🎵 OPEN – “Ready? Got your sheet music? Let’s go!”
• 🎵 SEND – “Now play, stay in rhythm!”
• 🎵 CLOSE – “Thank you all, you're dismissed!”

Now imagine this: this orchestra of engineers and hardware worked, transmitted critical data, encrypted information, and tracked trajectories. The "Collection" system and the UCC were like a jazz band that didn’t fall apart simply because the musicians somehow understood each other on a deeper level:

• The musicians (measurement points) were far apart, but they kept the rhythm.
• Some instruments (old telephone lines) crackled, but still played.
• The conductor (control center) sometimes panicked, but led the performance to the end.

The most important thing is that this complex yet brilliant engineering worked reliably, even if sometimes it required a little "kick"—like a pianist stuck on one chord.

With teamwork, humor, and pure enthusiasm, we managed to tame these rugged machines and turn them into the "high society" of the network world. 🎶🎵

Message Structure of the "Unified Control Center" System

The data exchange protocol developed in 1995 for the Vega system control software represents a thoughtful and reliable system for interaction between the central control post (ECU) and remote measurement complexes. Despite the technological limitations of that time, the protocol ensured guaranteed delivery of commands and data in a heterogeneous network environment.

General Message Structure

The protocol is based on a simple and efficient message format consisting of two key parts:

Service Field (Field S): Fixed header of 6 bytes. It serves as an "envelope" for data, containing all necessary information for routing, priority determination, and content type identification.

Information Field (Field D): Variable-length payload from 0 to 255 bytes. This is the actual "letter" — command, data, or text message. This part may be absent if the message is purely administrative.

Figure 1. Basic message structure.

Service Field (Field S) — The "Brain" of the Message

Each of the six header bytes carries critically important information that determines the message lifecycle.

Byte 1: Identification and Priority

• Message type (bits 7, 6): Determines content — Data, Command, or Text
• Urgency class (bits 5, 4): Sets priority. RMV (real-time scale) messages are processed immediately, interrupting transmission of non-urgent messages

Byte 2: Timeout
For RMV class messages, specifies maximum time allocated for command execution.

Byte 3: Message Code
This field specifies the content:

• For commands: Contains operation code ("Report Status", "Enable Transmitter")
• For data: Indicates data type ("Prediction Results", "System Corrections")
• For text: Used as bit mask indicating display method (console screen, printer, save to file)

Bytes 4-6: Routing and Flow Control
Contains sender and receiver addresses, message sequence number in the stream, and length of information field D.

Information Field (Field D) — The Content

This part transmits all useful information necessary for the complex operation:

Commands: Parameters for command execution, such as target designation for direction finder.

Data: Wide range of information — from measurement results and telemetry to files with source data for antenna guidance:

• Ionospheric data: Atmospheric conditions, signal propagation parameters
• Tracking results: Object trajectories, velocity measurements
• Signal characteristics: Frequency analysis, interference levels
• Environmental data: Weather conditions, electromagnetic background
• Measurement corrections: Calibration parameters, error compensation

Text Messages: Arbitrary text for information exchange between system operators.

Key Feature: Two-Level Acknowledgment System

To ensure the highest reliability, the system implements a two-level command execution confirmation mechanism that guarantees not only delivery but also execution.

Level 1 Acknowledgment (Receipt Confirmation): Sent immediately after the receiving system successfully accepts and parses the command. This confirms that the message reached its destination through the communication channel without errors.

Level 2 Acknowledgment (Execution Confirmation): Sent only after the requested operation has been completely executed. This confirms that the command was not just received, but successfully executed at the application level.

Example Flow:

Heterogeneous Network Integration

The system operated reliably across diverse platforms and protocols:

• QNX real-time systems: Microsecond-precision timing requirements
• Various UNIX variants: Standard network protocol handling
• Custom hardware protocols: Specialized equipment interfaces
• Different network topologies: Serial lines, early Ethernet, proprietary links

This sophisticated messaging system, operating over slow modem lines (4800 bps) across thousands of kilometers, allowed ECU operators to have complete confidence in controlling remote complexes.

Vega System Infrastructure

Vega System Hardware Room – Equipment racks and central operator console, 1995

Vega Measurement Complex at Plesetsk Cosmodrome – Satellite view showing distributed infrastructure

Vega Antenna Field in Arctic Tundra near Vorkuta – Demonstrating the massive geographical scale of the distributed measurement system

Vega Central Tower at Vorkuta Arctic Complex – Demonstrating the massive engineering scale required for polar operations

The Tragedy of Advanced Engineering

This remarkable distributed system, decades ahead of its time, remained largely unknown and unrecognized. There were many reasons for this, but the primary cause was the absence of a developed market where advanced systems could be discovered, evaluated, and commercialized.

In the transitional period of the 1990s, everything was focused solely on executing commands from above. The entire system operated like a GULAG: "step left, step right — execution; jump in place — provocation." There was no room for innovation, no mechanism for recognizing engineering excellence, and no economic incentive to develop or promote advanced technologies.

Ukrainian engineers created world-class distributed systems for minimal salaries, building technology that anticipated modern microservices architectures, reliable messaging patterns, and cross-platform integration — all while the world remained unaware of these achievements. The technical brilliance was there, but the socioeconomic framework to recognize and capitalize on it simply didn't exist.

The Underground Path to Freedom

However, the drive for freedom cannot be contained. Young engineers, having gained experience, made a "virtual tunnel under the iron curtain" and created Ukraine's meteorological network based on technologies originally developed for the Russian military — using "Briz" meteorological concentrators.

This transformation was not smooth. The same Ukrainian engineers who had created the sophisticated "Sбор" (Collection) and ECU systems for Russian military purposes in the 1990s faced aggressive resistance from their own management when attempting to repurpose these technologies for civilian use. The leadership — former communists who had hidden their party cards and "changed shoes mid-flight" — preferred the familiar and profitable work for Russia over developing Ukrainian civilian infrastructure.

Working against the current of their own bureaucracy, these engineers persevered in creating truly Ukrainian systems. This meteorological network, once activated at the turn of the 1990s-2000s, has been operating for more than a quarter of a century without ever shutting down.

The technical foundation for this success was extraordinary. The distributed messaging protocols, reliable acknowledgment systems, and cross-platform integration were built upon cryptographic technologies developed in real-time by imprisoned engineers at the Marfino research institute — the "first circle of hell" described by Solzhenitsyn in "The First Circle." These brilliant minds, locked away to preserve state secrets with no hope of release except death, had created the encryption systems that would eventually enable secure communication across thousands of kilometers of harsh terrain — from the polar tundra of Vorkuta to measurement complexes scattered across the Soviet Union.

The full journey of these technologies reveals a profound irony: algorithms born in the GULAG, developed by Ukrainian engineers for Russian military tracking systems capable of measuring rocket trajectories with meter precision at 2500 kilometers, ultimately found their peaceful purpose in monitoring weather patterns for Ukrainian farmers and pilots. The same protocols that once coordinated the "Vega," "Kama," and other measurement systems across the Arctic tundra now quietly serve civilian needs.

This transformation represents more than technical adaptation — it demonstrates how true engineering excellence ultimately transcends the political and economic constraints that initially limited its recognition. The protocols that once coordinated military systems now help farmers plan harvests and pilots navigate safely through Ukrainian skies, proving that authentic innovation always finds a way to serve humanity.

Software of the Collection Center, UCC Workstation Software, Session Level

Software of the Collection Center, UCC Workstation Software, Session Level

Session Layer Software of the Computing Center at the Plesetsk Cosmodrome for the "Collection" System and Unified Control Center

Session Layer Software of the Computing Center at the Plesetsk Cosmodrome for the "Collection" System and Unified Control Center

Session Layer Software of the "Collection" System and Unified Control Center

ECU Computing Architecture for Control Systems – Vega Measurement Point and Information Concentrator

ECU Control Architecture Components

The ECU computing architecture for control systems integrates distributed measurement capabilities with centralized command coordination:

• Remote Concentrator (RC): Information collection hub connecting the measurement point to the central ECU data processing network
• "Vega" Radio-Technical Measurement System: Core measurement infrastructure consisting of:
  • Automated Workstation for Data Processing (2 units) - Redundant real-time processing nodes
  • Automated Workstation for Antenna Control - Programmed antenna guidance system
  • Local Area Network (LAN) - Internal high-speed communication backbone
  • "Vega" Measurement System Hardware - Radio-technical equipment for trajectory measurements

This distributed control architecture enabled the ECU to coordinate measurement stations across thousands of kilometers, from Arctic locations like Vorkuta to the Plesetsk Cosmodrome, achieving real-time trajectory tracking with 5-meter precision at intercontinental ranges.

A Note on Context

While writing this article, Kharkiv has been repeatedly attacked by Russian strike drones. This is their gratitude for our Ukrainian engineering work that once served their military needs. The irony is not lost on me: we built their first intranet, and now they use advanced weapons to destroy the city where it was created.

Kharkiv School No. 17 (Saltivka district), a school with advanced English studies — where my granddaughter was supposed to study. Destroyed by a Russian Iskander missile. Personally photographed in 2025 — this is not from media, but from real life.

They destroy our schools, our cities — yet we continue to innovate and engineer solutions. Because that’s what Ukrainian engineers do.

Historical Note: "The Birth of the Intranet in Russia, 1993"

Everything was going smoothly as the Collection system was being handed over to Russian colonels in their karakul hats. The generals were satisfied, champagne was almost ready…

Suddenly, it emerged that some Ivan the Fool (a hero from Russian folk tales) in the army had formatted the disk of the remote “concentrator” located in Vorkuta.

The Cossack programmers were in shock.

Cossack Andrii grabbed the secret phone and began explaining to old Cossack Afanasich, who had been forgotten somewhere in Vorkuta:

Andrii: “Afanasich, pick up the system programmer’s manual, follow it step by step!”

On the other end there was silence, then a faint mumble:
“What? What manual? Where am I supposed to go? I can’t understand you— the line is terrible! Everything’s garbled!”

The connection was indeed awful; Afanasich couldn’t grasp anything and started arguing, asking the same questions again. The Russian colonels stared at the Cossacks, ready to have everyone shot on the spot.

That’s when Cossack Alekseyevich couldn’t take it anymore. He seized the receiver, and a thunderous tirade erupted:

“You demon from Vorkuta, cursed devil’s own brother! Jerusalem beer-brewer, enemy’s quiver-bearer, unbaptized forehead—may the grandchild of a viper take you!”

Silence.

Suddenly, a clear, confident voice came over the line:
“Understood—got it!”

Afanasich grabbed the manual, put on his glasses, and did what he had never done before— he configured the system himself.

Like a miraculous icon, the manual brought the Collection system back to life.

The Russian colonels had no idea what was going on but proudly announced:
“Behold, the very first ‘Intranet’ in Russia!”

Meanwhile, the Cossack programmers exchanged glances and whispered:
“That’s how great Russian achievements are born…”

🔥 The End. 😆🚀

Appendix: Photographic Records of the Era

From the USSR Ministry of State Security to Strategic Missiles: A Visual History of the Technological Chain

Historical Progression: A line of development from Stalin's generals and Ukrainian engineering to modern strategic systems. Documents and photographs spanning the 1940s to the present day illustrate the evolution from the forced labor of imprisoned cryptographers to advanced military complexes.

USSR MGB Generals
Problem Statement

Andrii Nikolaiev
Principal Engineer

Project Completion Act
1998

Sineva Missile Launch
Ballistic Tests

Launch Facility
Test Complex

Nuclear Submarine
Strategic Carrier

Submarine at Sea
Combat Patrol

Topol-M Missile Launch
Plesetsk Tests

Vega System
Mirny (Google Maps)

Vega System
Small Cross (62.783026, 40.333077)

Vega System
Site Overview (62.782966, 40.333082)

Vega System Gates
Mirny (Winter)

Vega System
Vorkuta (Winter Complex)

Vega System
Technical Facility (Vorkuta)

Vega System Engineer
Returning from Calibration

Vega System
Snow Protection (Vorkuta)

Vega System
Norilsk (69.404609, 87.634750)

Vega System Norilsk
Technical Position (Summer)

Vega System Norilsk
View from Light Tower

Vega System Norilsk
Right Wing Technical

Vega System Norilsk
Right Wing (Winter)

Vega System Norilsk
Right Wing in Blizzard

"Small Cross"
Norilsk Vega (Summer)

"Small Cross" Norilsk
Black Blizzard

Vega System
Yakutsk (Winter Period)

Norilsk Vega MS
Calibration Mast Landscape

Nikolaiev A.V.
UCC System Testing

Communication Testing
Vega — Collection System

Direction Finder
Vega System

Vega Direction Finder
on Rotational Platform

Vega System Vorkuta
Detailed Satellite Overview

Vega System Severodvinsk
Measurement Antenna

Engineering Poetry: Geography of the Vega MS

Panoramas of Arctic measurement complexes: masts, antennas, and the harsh beauty of northern landscapes

Norilsk Vega MS
Summer Technical Facility

Norilsk Vega MS
Sunny Winter Day

Calibration Mast
Norilsk Summer

Calibration Mast
Summer Tundra

Calibration Mast
Summer Tundra

Summer Tundra
Norilsk

Small Cross
Polar Day

Small Cross
Kayerkan View

Technical Facility
Backyard

Technical Facility
Backyard

Cable Corridor
Arctic Tundra

Arctic Tundra
End of Summer

Diesel Generator
Power Supply

Calibration Mast
Norilsk Vega MS, End of Summer

Small Cross
Direction Finders and Cable Corridor

Cable Corridor
Norilsk Vega MS

Calibration Mast in Fog
Norilsk Vega MS

Technical Facility
Backyard

Technical Facility
Different Angle

Technical Buildings
Tsubik Residential Block

Living Quarters
Service Complex

Technical Structures
Tank Farm

Garage
Station Vehicle Fleet

Small Cross
Direction Finders

Highway View
Polar Summer

Highway View
First Snow, Autumn

Calibration Masts
Plateau, End of Summer

Rear Yard
Brick Communications Building

Polar Sun
Over Tundra

Polar Sun
and Calibration Masts

Calibration Mast
Through the Seasons

Calibration Mast
Seasons (Series)

9 Months a Year
Snow in Tundra

Garage and Masts
Norilsk, Summer

Backyard
Blizzard

Garage and Masts
Winter Period

Lighting Tower
and Blizzard

Cable Corridor
in Tundra

Cable Corridor
Blizzard

Left Wing
Technical Facility

Left Wing
in Blizzard

Right Side
in Blizzard

Small Cross
Direction Finders

Base Gates
and Mast

Base Gates
in Snow

Calibration
Mast and Fence

Power
Transmission Line

Behind the code, there’s always a human

×