Sweden’s Best-Kept Technology Secret
Did you know that the world’s first commercial Internet-like data communication system was developed in Sweden in the early 1970s? KTH Professor Torsten Cegrell, back then an employee of the electrical engineering firm Asea, developed a routing function to help message packets select the correct path through a network — a solution that made possible the Internet as we know it today.
Histories of the birth of the Internet usually highlight the ARPANET network in the United States, commissioned by the U.S. military and developed as a research project at several American universities in the late 1960s. But that’s only part of the story, according to Torsten Cegrell, Professor of Industrial Information and Control Systems at KTH.
It’s true that the ARPANET project — named for the U.S. Advanced Research Projects Agency — developed the scheme that came to be called packet-switching, Cegrell says. Packet-switching (or message-switching, as it was called in the beginning) means that a message is broken down into packages that take different paths through the network to eventually be re-assembled for delivery to a recipient. But the essential routing mechanism that was supposed to direct packets along the most efficient paths from sender to receiver didn’t work satisfactorily. The solution turned out to be thousands of miles away — in Sweden.
In the early 1970s, the state-owned Swedish energy company Vattenfall placed an order with Asea (now part of the Swedish-Swiss conglomerate ABB) for construction of a data communications system to control and monitor the entire national power grid. The system became known as TIDAS, and the data communication system protocol was dubbed TIDAS-T.
“The whole story was forgotten”
Several options were considered for the design of the basic communication principles, with Vattenfall eventually settling on a method that had never previously been tested in commercial systems — the same principle that had been attempted in the ARPA network. It was a bold decision, but Cegrell now says it was the only candidate that had any real hope of meeting Vattenfall’s requirements for a communication network that was sufficiently robust and at the same time affordable.
The system, which became fully operational in 1975, is still in use, now owned by the transmission operations utility Svenska Kraftnät. Cegrell explains that it’s grown larger and the computers have been replaced three times, but the software is exactly the same.
“The story behind all this was forgotten, and when the Internet boom started about 15 years ago, everyone talked about the old ARPA network as the root of it all,” Cegrell says. “But that’s only half true. ARPA developed the packet-switching technology, but not the routing protocols that came to be called TCP/IP. That’s also a fundamental element of the whole thing.”
Given the importance of the project and the size of the order — both geographically and in financial terms — Asea began with a regime of highly detailed simulations to ensure that the system would deliver as promised.
“We were essentially able to build the entire network in a special computer simulation language. It was incredibly complicated and most people have probably forgotten about it now, but it allowed us to simulate the ARPA network,” Cegrell continues. “They had a routing solution, so we input that as well — and it turned out that it didn’t work well enough. Messages were sent back and forth, but sometimes they never arrived at their final destination.”
An important feature in all networks is the buffer that holds messages while they wait for transmission. It’s similar to the printer queue in any office network.
“When the buffers were full, it was like your head hitting the ceiling. Our simulations showed that the whole system would collapse. We filled it up with data and it would just spin around. We called it the ping-pong effect. And we knew we couldn’t sell it.”
Together with his colleagues, Cegrell began looking for a solution. “In those days, computers used punchcards to store and run programming code, and we were working with a huge simulation program. If you wanted to do more than one run per day, you had to sit in the basement of the computer centre at night. I spent nights in that basement for almost a year,” he laughs.
Working at last
In the end, Cegrell and his colleagues managed to crack the problem, coming up with an adaptive routing mechanism that actually worked. To protect the idea, Asea first tried to apply for a patent (Cegrell still likes to show the document to visitors) but that turned out to be much too expensive. Instead, the company published the results and passed the solution along to the ARPA programmers through Research Director Professor Leonard Kleinrock at UCLA in California.
“He was impressed,” Cegrell says. “I still have the letter he wrote saying his team had looked at this problem and hadn’t been able to come up with a solution. They knew about the ping-pong effect because they’d seen it in the ARPA network, though not as clearly as our simulation showed. Our network was much larger so we had a better view.”
A short time later, Kleinrock wrote to tell Cegrell that ARPA had included Asea’s method in its network.
Cegrell said he hadn’t given much thought to the Vattenfall project until last year, when the company’s Cultural Heritage Committee produced a study of the documentation and conducted interviews with people involved in the team.
No one currently working at Vattenfall had any memory of the project. “They thought it sounded ridiculous,” Cegrell says now. “ARPANET was the first Internet-like network, but that was a research project. We built the world’s first commercial system.”
By Hakan Soold
Footnote: The modelling language that Torsten Cegrell and his colleagues used in their simulations was called Simscript. It’s unlikely that it’s in use anywhere today, largely because most programmers found it too difficult to use. But Cegrell points out that Simscript was essentially a real-time operating system. “So if you know how these things work, it’s fairly simple. Or conversely, if you’ve learned the language, then you understand real-time operating systems. It allows detailed modelling of time queues, spatial queues, prioritisation schemes, events, delays and all that. When our network was finished, we ran test runs for comparison with our simulations. We couldn’t see any difference — the results were exactly the same.”