Modular design may appear self-evident. After all, wasn’t that the key to Scania’s success as a relatively small truck manufacturer? Standardization, scalability and integration are also time-honored concepts that imply capacity for upgrades, an ability for the system to grow or contract without problems and for its ability to prevent faults from spreading. Surely it must be better to distinguish between routine tasks and more specialized functions?
With hindsight, nearly everything seems self-evident. Scania, however, had few followers of its philosophy. Standards risk paralyzing technology by preventing innovative leaps that create new features. Modules are like factory clothing, predictably sized, good enough, but never as good as custom-tailored.
The unique qualities of the AXE system’s design must be viewed against the background of what technology permitted when it was conceived. Processing power was still limited and data storage was expensive. The processors, the units that counted, structured and handled the signals, had limited capacity. Designing software and hardware in modules, making square pegs to fit round holes, was regarded as wasteful.
Computer programs were the custom-tailored component. The software for a complete telephone station was not the job of one person, but hundreds. These were also not your ordinary tailors. Instead, many looked more like artists. The problem was that with so many people involved, no one could maintain an overview. The result was called spaghetti code – if a change was made it one place, it could have effects in a completely different place. A fault or a bug might result in a serious malfunction, but the visible fault did not necessarily reveal where the bug was located. And for every fault corrected, a popular rule of thumb held that two new ones would appear.
An important aspect of the AXE project was therefore creating independent program modules that only communicated with each other in a standardized manner. No signal could be introduced that would result in changes in another module. If a module had been made bug-free, it was safe.
Another aspect of modular design was that the system should consist of standardized building blocks, even from a mechanical standpoint. That meant that these building blocks could be tested where they were manufactured, for example in Sweden, and if they worked there, they could then be shipped to Saudi Arabia or anyplace else. Another objective was that it should be possible to replace physical modules with new ones, since technology continued to advance and processors, for example, got faster and more powerful. As if that was not enough, modules could be switched from analog to digital, a change that came more quickly than expected.
Even competitors and researchers found it difficult to understand why AXE appeared to be able to handle everything. One competitor believed that it was impossible to deliver systems as quickly as modularly tested, bug-free software modules allowed. Another designed three different telephone stations in various sizes, while AXE could be made smaller or larger as required.
The system concept contained more than modules. Computing power that was frequently needed for simple tasks was located peripherally, for example, while more advanced functions that were seldom called but demanded complicated programs and more computing power were allocated to more sophisticated central processors.
Compromises were necessary, and with the answers in hand, it is apparent that not all were optimal. But the advantages of the AXE’s design sound like advertising copy: more reliable software, easy to expand with both additional capacity and new functionality, faster production and installation and future-proof technology.
Author: Bengt-Arne Vedin
