History of Computer Engineering for Military Real-Time Control Systems in the USSR
Home → Articles → History of Computer Engineering for Military Real-Time Control Systems in the USSR
Vladimir Lipayev
1. Environment and Impetus to Specialized Military Computer Development
At the outset of computer engineering development in the USSR in the 1950s the main attention was concentrated on the creation of computers which could solve complex mathematical problems. Computers then were stationary and intended for successive or batch problem solution irrelatively to the real time and dynamic parameter changes. Later the machines formed the most widespread class of universal computers for various applications.
By the late 1950s the defence industry and the Ministry of Defence took an interest in computers for data processing and control in military systems. The nature of such applications considerably differed from the computational problems which had become traditional by the time.
As a result this trend in computer engineering began to actively progress. It emerged almost simultaneously in a number of branches of defence industry and at various manufacturing plants where systems for Army, Air Force, Navy, Strategic Missile Forces etc. were produced. The ensuing development of military computers was greatly influenced by demands from different customers. Subsequently military computers split into stationary machines for in-door use and mobile models. Such a division led to fundamental differences in architecture and specifications between military computers. Stationary computers gravitated to architectures and technologies immanent to usual universal machines with certain specialised extensions and modifications. Mobile computers were much more specific and greatly differed from other type of computational hardware. The article is aimed to present a historical view on the development of the latter computer category from 1950s to 1980s, both in hardware and software areas.
Particular functional tasks and different demands as well as rigid interdepartmental barriers and stonewalling drastically limited the information exchange between specialists who developed specialised mobile computers in different industries and at plants of this country. Technical characteristics and special features of foreign machines of the same class were also practically unknown here. All this led to the real "Babel" of hundreds of computer architectures and technical parameters. Independent development of such a broad spectrum of computers was very expensive but resulted in the emergence of many ingenious and very effective designs which facilitated maintaining parity with the West in different military enginery areas for a long time.
From 1950s to 1970s the USSR lacked the centralised production of electronic components for computers, and they often were developed at the same plants where computer architecture and control systems were designed. As a consequence the element base for computers was frequently primitive and diverse, its quality and technological level left much to be desired. Many military plants had to develop the whole cycle of their production – from electronic elements to hardware components and software. This not only resulted in many parallel non-unified projects but prolonged the lead times and increased the cost of systems, which made the production of many different computers a complicated task and invoked difficulties in maintaining and upgrading military control systems by and large.
Heads of military system projects generally focussed their attention on hardware development, primarily on computer aids. Late in the 1950s an absolutely new class of products evolved, that is software. It embodied an intellectual essence of control methods and processes as well as a large share of aspects defining the quality and effectiveness of military systems. Such a turn in the situation appeared to be unusual and inapprehensible for many executives. They took software development too lightly, did not allot necessary specialists and time, were not eager to estimate the necessary investments and resources. Many officials were sure the programs demanded no special qualification and could be developed by a do-it-yourselfer or a couple of them. Such an attitude often provoked conflicts among developers and created tensions with consumers because of downscale applications or their unavailability. This delayed the whole projects completion.
A high price of development and manufacture of hardware produced the illusion that the main task was fulfilled, and only some potty expenses on programming lied ahead. Programmers’ labour was deemed to be very simple and cheap, demanding no technological equipment. However, at the end of development process consumers and executives were very much surprised and indignant having found that the expenditures on high-quality programming were comparable with the hardware cost. In the 1960s the working efficiency during the whole-cycle software development of complicated program complexes with a hundred thousand instructions or so was estimated at on average 0.1 to 0.3 instructions per programmer per day. As a consequence the development of such a complex demanded approximately one thousand man-years. Lack of elaborate technologies, comparatively low skill and salaries of the most programmers neither incited any increase in labour productivity nor ensured a high quality of final software products and whole systems.
In the 1960s and 1970s military system consumers were continuously extending the range of computing tasks and stepped up the requirements for solution quality. The trend was accompanied with rapid increase in computer program capacity and complexity. Low labour efficiency made it necessary to actively train new specialists and augment the work force.
Technological progress and element base development lagged behind the requirements for the military computer memory and performance, which were determined by new requirements and tasks. Computer control functions were also becoming more and more complex and critical. This caused gain in requirements for control systems quality, reliability and security.
Many military control systems based on mobile computers were aimed at small-scale (separate specimens, tens or hundreds of pieces) production and use. Therefore, programmers made use of ingenious designs and ignored hardware and software unification and standardization. Consumers did not coordinate the specifications for computer aids, each of which had to be individually adjusted to consumer’s tasks. Hence there emerged a real "zoo" of different computers and software complexes often solving the very same problems, especially in airborne and missile systems.
2. Distinctions of Functional Tasks of Real-Time Control
Development of specifications for mobile military computers required the comprehensive analysis of algorithms and programs. As every computer type was aimed at handling definite tasks, the available element base allowed one to save on the equipment and to improve memory and performance parameters. That is why it is expedient to discuss the basic peculiarities of the mobile military system tasks, which were considered in designing specialised computers.
One of the most important distinctions of mobile military systems is that most of processes run very quickly in them, and the acceptable reaction time may number in minutes, seconds or even a fraction of a second. Therefore computers must process data and prepare control actions at a high rate to correspond to dynamic characteristics of environment. Computers and program complexes should perform all computations in the stringent framework of real time and react on incoming information with the minimal time lag. These requirements were bound to meet with incoming information flow of any intensity despite limited computational resources.
From the very beginning military systems were characterised by an extremely broad spectrum of absolutely new and multifarious tasks. As the tasks were investigated, their quantity and diversification grew up dramatically. To handle the tasks new algorithms aimed at practically real situations and available resources of mobile computers were developed. Algorithms for solving particular problems were gradually united to create more intricate complete algorithmic structures for co-ordinated solution of main specific tasks immanent to a military system. The process required developing new methods and algorithms for integration and complex interaction between different algorithmic systems on a unified or distributed computational platform in real time.
Programs for universal computers initially allowed one to solve computing tasks with predominance of integer or rational numbers arithmetic. But in programs for specialised military control computers a specific aspect soon appeared. Two classes of variables could be distinguished: quasi-continuous measurements of object parameters and coordinates plus logical attributes of objects and their operation. Logical functions prevailed whereas computational operations were comparatively uncommon.
A major part of raw data processed by the systems under consideration represented the results of quantized measurements of continuous physical quantities such as object coordinates and their velocity, and also readings of voltage, pressure and other pickups. Relatively low validity of such information determined the optimal word size for its quantization essential for computerised data processing and storage. The word length structure and operations with partial word were optimised for the bit count of the most often used quantities to minimise the equipment dimensions. Consequently computers featuring different base word sizes of memory and main operations – 12, 16, 18, 20, 24, etc. bits – were created.
Logical operations in programs were executed, as a rule, with short words or even with separate bits. To increase performance it was expedient to optimise the central processor for convenient and fast processing the quantities with definite structure and to use as many as possible special logical operations with separate parts of words. A portion of word (1 to 6 bits) was allotted to logical quantity attributes. All this helped to get necessary memory resources and performance of mobile computers despite rather weak element base. That is why only late in the 1970s many machines began to use universal byte structure of operations and processed data, which was less effective for such applications.
Functional tasks of many military real-time control systems dealt with intensive random flows of heterogeneous data, whose processing duration was of stochastic nature. The time heavily depended on the raw data type and its arrival moment. There was no need to gather a great amount of information and store it for a long time so environmental databases were quite small and practically lacked special management components. Just a few stationary military systems used at headquarters stored large databases but their real-time regulations were less stringent and allowed longer response delays.
Definite and limited destination of the systems made real-time control much easier. Operating systems designed for mobile military computers had no universal components for solving auxiliary problems including technological tasks. Such compact specialised operating systems provided only the minimum of functions necessary for regulating and managing the solution of functional tasks, for information exchange with external subscribers, and for computation control. They were also equipped with some resources increasing the reliability of the system and restarting it after error, malfunctions or crash took place.
3. Characteristics of Computer Aids Used in Mobile Real-Time Systems
The solution of definite functional tasks and minimisation of weight and dimensions of machines drastically limited the military computers memory and performance. Lack of redundancy forced the designers and consumers to look for compromise between functionality, algorithm complexity and quality of final results. Designers had to use the limited computer resources most efficiently and try to find any architectural and technical potentialities for problem solving with resources available.
A single type of machine could not meet the rigid weight and size limitations, high and diverse requirements for environmental specifications and permissible mechanical G-loads, as well as very high reliability standards. All this led to the development of a wide range of military computer designs with architecture and operation structure reflecting the above-mentioned distinctions. By the late 1970s a very broad spectrum (more than 300) of military mobile computer types emerged. The machines differed in architecture and function-oriented instruction structures, and also in design depending on fields of application. The computers were characterised by lack of any auxiliary and peripheral equipment not requiring a specific control system to tackle direct functional tasks.
The tendency toward the architecture unification of mobile military computers manifested itself only in the early 1980s. It was dictated by the necessity to sharply accelerate and automate the development of programs, which demanded much more memory and higher performance than the control machines could offer. The architecture was based on the SM and ES general-purpose computer types widespread in the USSR. It was anticipated that such a move would allow one to design and debug program complexes on universal computers and then to transfer them to control machines without any changes. But the functionality of real-time control computers differed from that of universal machines so the final debugging and testing had to be done on control machines. The trend was evolving very slowly because of a great amount of "inherited" programs already used in real-life systems. That is why modernisation of older computers with their spotty architectures continued in order to boost the memory capacity and computational performance. This made it possible to keep the proven programs and to introduce the new ones without recourse to a complete development of the whole program complex and control systems with necessary tests.
4. Special Features of Technological Tools Used in Program Development
In the early 1960s programs for military systems were developed in object codes directly on control computers without any programming automation due in part to lack of necessary memory and performance resources. This governed a very low working efficiency of programmers and impermissibly long terms of program development.
In the middle 1960s to automate programming, universal technological computers with great resources and various architectures were used. They differed from control machines by design and command structure. The technological computers had general-purpose operating systems and more or less sophisticated periphery helping users to develop programs.
Early technological tools were quite primitive compilers from control computer assemblers to their object code, and also interpreters for executing programs in this object code on general-purpose computers. Such program development tools based on universal machines received the name "cross systems". They significantly accelerated and facilitated the development process and debugging of stand-alone modules and small programs as well as partially automated the issue of software documentation.
The assembler-level programming languages were used because of the need for economy of military computer resources and inadmissibility of object code expansion, which was inevitable with higher-level languages. The trend prevailed up till the late 1980s; during this period third-generation languages were used very seldom. In American military systems high-level algorithmic languages have been widely outspread since the late 1960s. This was due to the large military computer resources, on the one hand, and much higher programmers’ labour cost, on the other. But the algorithms and programs they used did not utilize available computer resources effectively enough.
Initially cross systems were created for each control computer type but with the passage of time they were being improved and programmer service was developing. Consequently by the early 1970s the share of machine-oriented compilers and interpreters in cross systems based on general-purpose computers was relatively small. The rest were visualisation means for users, documentation, test and debugging problems generation, static analysis of program structure accuracy and others, which almost did not depend on control machine features. Therefore it became essential to create configurable compilers and interpreters, which could be set up on the basis of formalized control computer architecture and command system descriptions. The descriptions were automatically translated into machine-oriented compiler and interpreter modules that helped to cut down the expense on developing cross systems for control computers tenfold. In the middle 1970s these principles were used for creating a complex multifunctional YAUZA-6 tool. Based on BESM-6 computer it was set up for twenty or so different military control computers. ES-based RUZA cross system ensued.
By the late 1970s about a hundred thousand programmers were working for military systems developing hundreds of sophisticated program complexes. Their labour productivity rose tenfold and reached an averaged value of one to three instructions per programmer per day. The problems of programming errors and high reliability of real time program complexes became pressing. A very high cost of real-life objects and risk to lose them during complex debugging led to the creation of test beds for a real time environment simulation on technological computers.
Cross systems solved problems only in part, that is they fulfilled initial development and stand-alone debugging of relatively small programs. Complex real-time debugging of large programs could not be done on technological computers because interpreters slowed down the program execution by a factor of several hundreds. That is why hybrid systems came into use, wherein programs for military systems were executed on real control computers in interacting with technological machines used for environment simulation and test generation.
Specialised simulators on universal computers were used to generate appropriate data flows from external objects and to process debugging program responses in real time. This ensured high-quality complex debugging and testing of programs for military systems in an adequate environment without using real-life objects. An example of the technology can be the first successful unmanned flight of the Russian space shuttle Buran, whose programs were debugged and pre-tested on a special test bed.
