Search

The paper starts with a survey over history and present-day situation of educational concepts and design methods in computer architecture. Complexity problems, bad design habits, cooperation problems between specialists, as well as their changing range of responsibility are covered, and the consequences of the developmental trends are discussed: now it is time for switching over to an integrated teaching of hardware/software design methods. The HIM scheme ( h ierarchy of i nterpretive m odules) is suggested as a conceptual machine organization framework for modelling the implementation of language hierarchies. The application of the HIM scheme for better understanding of semantics, and for a derivation of designing guidelines is discussed.

A new approach is introduced for the design of Multi-User Real-Time Computer Networks. The approach leads to a system architecture called "Functional Distribution". Definitions of the concept and key issues of a practical implementation are discussed using as an example a Multi-User Experiment Control System. The discussion also includes the architecture of that hardware which has been traditionally referred to as the "interface between an experiment and a computer".

To anyone who has had the slightest connection with the design and construction of large programs for digital computers, it is obvious that this is no trivial task. Many times the design of such programs is woefully inadequate, and the effort required to get them right is tremendous. The sometimes ruinous cost of such inadequate design is well-known.

In microprogrammable systems a special type of interpretive linkage mechanism is used. This linkage mechanism, among all known interpretive techniques, shows the clearest distinction between linkage implementation and the execution mechanisms of semantics. The essentials of interpretation by micro programs may be used as part of a design guideline for the design of a variety of multi processor systems or multi micro processor systems, aiming hereby at more clearly structured design solutions. After a short discussion of the interpretive mechanisms, known from microprogrammable systems, its possible impact on the design philosophies for hardware design in computer architecture, and for integrated hardware/software design efforts, is the subject of this paper. Especially one particular design philosophy, derived from the interpretive mechanism of microprogrammable systems, is discussed, which results in computer architectures in form of a hierarchy of interpretive modules. A few examples are mentioned.

As electronic devices became increasingly more complex, it was no longer feasible to test such mechanisms with traditional methods. With practically no transition period, the need for a new technology came into existence. The amazing lack of an organized approach in the development of automatic testing techniques has been a handicap to much needed progress. This paper discusses some of the many problem areas that should be considered in the design of the software for a sophisticated checkout project.

The design is outlined of a package comprising four main sets of programs referred to as ‘modules’; progress to date is noted and Modules 1 and 2 are described in some detail. The package is of direct use to IBM 360/370 users wishing to input, process and output MARC and MARC‐like records, but can also serve as a basis for software design and implementation for users of other computers. Module 1,MARC record input, which was developed with OSTI support has already been released in DOS and OS versions. Module 2, Local record input, will be released by the end of September 1973. Module 4, Output, will be released by the end of April 1974. With the completion of Module 4 the package will be operational for basic catalogue input, processing and output. No dates have been set for Module 3 which will be oriented to other application areas. Programs so far written are in Assembler and operate within a 64K core store machine (DOS) or a 64K partition (OS) with a minimum of 2 tape units and 3 disc drives. A number of developments are noted which will very considerably enhance the potential use of BNB/BL MARC services and it is concluded that the package will play its part in encouraging increased use of MARC records. It is projected that the majority of new BNB/BL MARC subscribers with IBM 360/370 machines will use the package, as will the British Library itself. A subsidiary finding of the library software package project is that where common programs are required by a number of installations including a central one, central provision and maintenance of this software has significant advantages.

This paper examines the nature of the software which is necessary so that a real-time computer may be used to control industrial processes. The general nature of a process control software system is discussed, and several methods for implementing such a system are examined. This paper is divided into several sections. First, the general structure of process control software systems is examined, and the programming problems associated with developing such a system are discussed. Then several tools for doing this programming are discussed, including problem-oriented languages, "fill-in-the-blank programming systems," procedural programming languages, and the operating systems which are used to tie the different portions of a process control system together. This paper closes with a dicussion of future trends in process control software, and recent activities in developing software standards. It will be assumed that the reader is generally familiar with software with at least a passable knowledge of FORTRAN programming.

The TR4 is a high-speed computer, constructed with modern techniques, and suitable for commercial as well as for technical and scientific applications. The central processing unit can communicate directly, without additional intervening elements, with the usual input and output devices. The basic design of software and hardware allows the user to benefit from effective programming techniques and parallel processing without extra programming burdens. This last objective is fulfilled by assigning frequently recurring software tasks to the control of the flexible central processor, while other software tasks are performed via a powerful wired in readonly memory. Ubersicht-Die TR4 ist eine in neuzeitlicher Technik gebaute schnelle Rechenanlage, die sich in gleicher Weise fur kommerzielle wie fur technisch-wissenschaftliche Anwendungen eignet. Der zentrale Rechner kann ohne zusatzliche Zwischenglieder unmittelbar mit den ublichen Ein- und Ausgabegerate verkehren. Der Grundbestand an software und hardware ist so realisiert, das sich der Benutzer ohne zusatzliche Belastung einer effektiven Programmierungstechnik sowie der Parallelarbeit bedienen kann. Die Erfullung dieser letzen Forderung wurde gelost indem ein Teil der sehr oft von der software ubernommenen Aufgaben unschwer der flexiblen zentralen Steuerung ubertragen wird; ein weiterer Teil wird durch ein wirkungsvolles, im Festspeicher verdrahtetes Programm realisiert.

To overcome many difficulties besetting the design of a cost-effective stored-program telephone switch control, this paper proposes a systematic three-step approach: 1) selection from twelve basic subclasses of a software organization satisfying flexibility, reliability, and speed-of-service constraints; 2) estimation of program size and processing load assuming a rudimentary processor architecture; and 3) determination of an optimal stored-program-wired-logic boundary and a minimum cost processor architecture. The last step is simplified by using a quantitative criterion called speed-size ratio.

Technology evolutions in logic and memory through increased integration, combined with potential improvements in machine organization, should provide processor performance in the mid 1970's that exceeds the second generation benchmark (IBM 7090) by a factor of 1000. Serious problems of packaging require a greater system designer sensitivity to the electrical and physical properties of materials, as well as requiring a closer tie between the technologist, system designer, and software designer. The increased processor speeds also create a balancing problem as the processor input- output gap widens, and LSI could assist in the solution of this problem. This paper discusses some of the technology- dependent parameters that could permit predicted performances to be achieved.

Military information systems are surveyed in an historical context starting with the SAGE system of the 1950's and projecting to the anticipated supersystems of the 1970's. Human functions in development, operation, and use of these systems are considered from a human factors point of view. This evolutionary overview shows how hardware and software design impact on human performance and how this impact has focused and expanded research in the computer sciences and in the behavioral sciences. The evolving human functions in military information systems are described. These descriptions serve as a basis for defining and researching critical human factors opportunities and problems. Paralleling this analysis is a review of several past, current, and future trends in human factors research for future military information systems.

This paper describes some problems and solutions in the design of software for a multi-computer system for real-time use. Particular concepts discussed are inter-computer communication, computer-aided reconfiguration, data integrity control, selective notification of amendements and the influence of debugging, testing and assembly sequence on the design approach. The problems of designing software for given hardware and ill-defined functions are also mentioned.

The D21 data processing system design uses simple system structure and fast circuits plus flexible memory and is thus adapted to the use of advanced software and easy application to diverse fields. A survey is given of design objectives, background, and the hardware-software system.

An experimental checkout system was built for demonstrating a method of assisting the astronaut to cope with all his various data management requirements. Data from two functionally simulated, critical spacecraft subsystems and one experiment apparatus were sent through a model telemetry system to a computer having characteristics similar to those of available spacecraft computers. A wide variety of malfunction situations could be inserted into the subsystem hardware. Through software design, the major checkout functions of status monitoring, malfunction detection, and fault isolation were incorporated into a system which included a computer-drive n alphanumeric readout device. Astronaut control was provided through a display and keyboard unit installed in a space-station simulator that provided a "cockpit" environment. Stimulus generation was minimized in favor of fault isolation based on performance analysis of the equipment being tested. The experiment verified the design approach and provided a tool for evaluating man-machine interaction in subsequent revisions of the system. Background N UMEROUS reports have discussed the requirements for an onboard checkout system (OBCS) to be used on postApollo programs (1) and (2). The OBCS simulator project described in this paper was an independent development program performed in support of an Apollo Application Program (AAP) study contract. It was structured to be applicable to existing hardware. For the purposes of this discussion, an OBCS is defined as one capable of automatically monitoring and checking inflight spacecraft equipment. The Apollo spacecraft is sufficiently instrumented to permit isolation of malfunctionin g equipment by using the onboard telecommunications system, but such equipment would not be considered as an OBCS. Only onboard equipment that can automatically and rapidly provide status monitoring, malfunction detection, and malfunction isolation of all spacecraft systems would properly fit our description of an OBCS. Another aspect of OBCS which is beyond the more usual categories of spacecraft instrumentation is provision for onorbit maintenance and experiment readiness checks. This represents a capability not emphasized in present systems, but for which future requirements will exist. Planned mission objectives include the acquisition of large volumes of data from a wide variety of experiments to be conducted from an orbiting laboratory during manned missions extended to 120 days, with certain modules manned by different crews for up to 365 days. Under computer control, an OBCS would relieve the astronaut from performing tasks such as onboard data acquisition and processing, status monitoring, malfunction detection, and fault isolation involved in the operation and in in-flight maintenance of both experiment and spacecraft equipment.

The display system discussed in this paper was implemented to provide a flexible test bed for man-machine interaction. The discussion includes both hardware and software design concepts, and concludes with an evaluation of the system based on operating experience. The two significant organizational features of the hardware are 1) the sharing of memory between a normal computer and a special picture computer (display device), together with 2) the capability of the latter to execute subroutines. The philosophy of design was that hardware should not limit the programmer's flexibility. This idea has been extended to utility software.

The technology of software of data base management systems is described, and the influence that hardware has had on such systems in the past is discussed. In addition, an attempt is made to highlight some hardware advances that are awaited eagerly by software designers.

Although minicomputer hardware costs are rapidly decreasing, minicomputer software seems to be continuously increasing in cost. A contributing factor to this situation is a lack of recognition of the scope of the problem of software production, which must be considered to include analysis, design, implementation, integration, testing, delivery, and maintenance. Various tools for minicomputer software production are discussed, including specification and design standards, software engineering techniques, implementation and testing methods, and project controls.

A recent trend in operating system design [1,2,6,7] is to consider the design as a hierarchy of abstract machines. The problem is viewed as constructing a “users' machine” from a given hardware machine by means of software. Rather than do this in one large step, a progression of abstract machines are defined starting at the hardware machine and ending with the users' machine. Each new machine is “built from” the earlier machines, adding to their capabilities. This approach appears to be a strong positive step toward bringing more discipline to the software development process. Liskov [6, 7] carefully documents the advantages. She also tries to establish formal rules to guide the process and relates this approach to structured programming [3, 8].

With computer numerical control the design emphasis changes from being hardware orientated to software orientated. While the user will not see any radical external changes, merely because the machine tool is being driven by a computer numerical control (CNC) system, the design changes are considerable. User demand for a cheap, but reliable system places stringent constraints on the software design.

This paper could well be titled, "Systems Engineering for Navy Platform Effectiveness," since the major decision and control issues are focused on optimizing the performance of the platform. Platform effectiveness is largely determined by the electronic systems aboard. In the past, optimizing such electronic systems usually reverted to the effectiveness of a software system contained in a general purpose digital computer. The role of the system engineer usually broke down somewhere between identification of functional requirements and transfer of these into computer instructions by programming personnel. The reasons for past failures and the challenge of new approaches are the theme of this presentation. In summary, what is needed most is unambiguous communication among all persons involved in development of Navy digital electronic systems, with the most probable solution resting in the language of mathematics, science and engineering.

The use of on-line computers for reactor control is investigated. The modular approach to hardware and software design is shown to be the most prospective way. Application of results from modern control theory is shown to be feasible. A specific system using a minicomputer for the automation and control of a research reactor is given.

Publisher Summary This chapter describes the design methodology and structured design. Designing is a creative process. There are no exact rules that have to be followed in designing an operating system. One must either learn from his own experience or from the experience of others and then decide which techniques contribute to a good system and which problems should be avoided. There are some general guidelines and overall approaches that can be followed. A design methodology for software is emerging rapidly. To some extent, software design principles are similar to design principles in many other fields. Structured design usually implies the use of structure to separate different parts of the system. Each part can then be designed separately. One of the most traditional design methods in operating systems is to design each major module of the system separately, and this is sometimes called the modules-interface approach. By examining existing systems, one finds an operating system to be composed of an I/O system, a scheduler for processor time, a memory manager, and a file system. Each module is isolated and specified.

In microprogrammable systems a special type of interpretive linkage mechanism is used. This linkage mechanism, among all known interpretive techniques, shows the clearest distinction between linkage implementation and the execution mechanisms of semantics. The essentials of interpretation by micro programs may be used as part of a design guideline for the design of a variety of multi processor systems or multi micro processor systems, aiming hereby at more clearly structured design solutions.After a short discussion of the interpretive mechanisms, known from microprogrammable systems, its possible impact on the design philosophies for hardware design in computer architecture, and for integrated hardware/software design efforts, is the subject of this paper. Especially one particular design philosophy, derived from the interpretive mechanism of microprogrammable systems, is discussed, which results in computer architectures in form of a hierarchy of interpretive modules. A few examples are mentioned.

An interactive data processing system enables a seismic data analyst to interrupt and modify the automatic processing of seismic data. It results in increased efficiency of retrieving desired seismic data. Also, it results in increased capability of the analyst to accurately describe and document seismic events. Principles are described to effectively design software for a seismic interactive data processing system. A set of tasks were described in detail as promising applications. Certain functions needed for seismic surveillance will require a very effective interactive data processing system.

A synthesis of System Development Corporation's accumulated experience in the field of command and control software development is presented. Research shows that software design and imple mentation is deserving of the best professional resources, and concludes that while the software development process is complex, it has yielded to orderly description and management and that relevant knowledge and skills exist that can be used to increase our understanding, competence, and control over this critical portion of the job of creating military command and control system.

By the analysis on traditional methods for rules of flash metal consume design, the idea of regression mining for flash metal consume design is proposed. Then according to related definitions, we construct a linear regression model. Its parameter estimation method and significant test methods of linear correlation are discussed in detail. We also analyze the method of applying mathematical statistics to formulation process algorithm. The flash calculation and mathematical description are studied. Through the research on regression analysis software design, the formulation of the forging flash size design guidelines and forging flash metal consuming design criteria. The progressive regression analysis software is used to construct above criteria and the results are analyzed. The algorithm is improved to be effective during our experiments and shows better self assemble ability and self adaptive ability

The aim of our current efforts is to present a framework that will support further consideration, and hopefully development, of a Prototype Community Information Utility (PCIU). There is a continuing explosive growth in the number and size of data bases and information services that are potentially useful to various segments of the community. If a common point of contact can be developed among these data bases and services (no mean problem in itself), then the economic and social value of a properly integrated data bank could greatly exceed the value of the individual data bases. To exploit such a data bank in any effective manner requires a number of things:• Data bases, individually and collectively, must be organized in a consistent manner, their utility and scope of application carefully defined, and their validity certified.• A continuing process must be established for the collection, organization, evaluation, and certification of new data.• The set of services that utilize the data bank must be carefully selected, defined, and implemented so that the system is not burdened with applications that are individually of limited scope and difficult to interface with one another.• The system that supports these services must be virtually failsafe, guarantee a very high degree of data security and privacy, and provide the basis for management mechanisms that insure its continued operation within accepted guidelines.

This paper presents a methodology for developing an organizational process model based on the principles of object-oriented design and formal software engineering methods. The methodology begins with the development of an object-oriented domain model which consists of an informal Rumbaugh model formally specified in the Z (Zed) formal specification language. The Z specifications are then translated into an executable model in the Software Refinery Environment. The Refine environment provides an executable language that allows behavior to be expressed declaratively, giving the developer an executable specification. This results in an observable domain model with attributes to describe organizational level metrics. While the model described in this paper is based on the Air Force wing C3I domain, both the methodology and the resulting model are shown to be very general and tailorable for other domain applications. The use of formal methods and an object-oriented approach leads to a more mathematically verifiable and more easily maintained executable process model.

In this paper we consider the problem of teaching systems programming and software design. We point out some of the major faults of many courses in this area and propose a course structure and method of presentation which we feel overcomes these faults. We review our past experience in using the proposed method and point out some aspects which need further development.

SIMULA (1) is a general purpose language, specially oriented towards the development of user oriented software in various fields. The language provides the programmer with means (notably the class-subclass facility) to define concepts relevant to a particular problem — or problem area. The basic properties of concepts can be collected in a class definition, which serves as a foundation for further development. Specific characteristics can be added, in the format of lower level subclass definitions, and this process of progressive refinement can be repeated as often as required.

All of the features that have been designed into digital computers may be considered to be, at least to some extent, reflections of software needs.

Any user of a computer system is aware that current systems are unreliable because of errors in their software components. While system designers and implementers recognize the need for reliable software, they have been unable to produce it. For example, operating systems such as OS/360 are released to the public with hundreds of errors still in them.

The popular concept of a multiple-access processing system as a common facility for many users (at remote terminals) with varied processing requirements, has over the past few years received considerable attention. The research for proper hardware and software design solutions has been primarily directed at installations which would support a large and diverse group of users with varied and sometimes complex applications, thus implying the requirement for a powerful computer and large memory storage. The usefulness of these time-sharing systems stems from their capability to provide computing power to any user when, where and in the amount needed.

A recent special issue of the Proceedings of the IEEE on computer communications' provides an excellent state-of-the-art report on the burgeoning field of digital telecommunications and computer networks. Included are papers on terminals, modems, errors and error control, multiplexing, processors and computer communication networks. Many of the system elements and system concepts in Tactical Military data processing systems are similar to those discussed in the above papers but there are also distinct differences. The purpose of this paper is to identify the differences between the hardware required for Tactical Military Data Processing Systems and the better known hardware requirements for fixed commercial and strategic military data processing systems. As system designers will appreciate, it is not possible to address the hardware aspects independently of the overall system design concepts including the software design. Accordingly, some discussion of overall system design concepts is included as background to the discussion of the hardware requirements. Discussion of the software problems, however, will not be covered except as necessary in this context, since other papers will emphasize the unique software requirements of these systems.

In general, computer software is getting more complicated at an increasing rate. Unfortunately, the people who have to develop this software have been at it for only a relatively short time. The result is predictable: ever-larger software troubles. This, in turn, leads many people to feel insecure about software development, to think of it as a modern "black art" for which even the most able practitioners lose the recipe every few months.

When generating compilers for use with automatic test equipment (ATE), a substantial need arises for flexibility in both the source and object languages. Flexibility is desirable for two reasons: (1) The field of ATE construction is rapidly expanding and (2) the hardware and support software design, development, and debug cycles are often going on simultaneously. In earlier, more standard compilers, the modifications and/or extensions of either language could easily create chaos for the systems programmer.

An important objective of software test programs is to identity, "high-risk" components. This paper focuses on one method which can be applied to identify high-risk software components, the use of a classification tree with an established software metrics set. The selected examples of high-risk software components are those modules which are most likely to induce errors in the target operational system, and those software components which will require the most effort in the development process. The associated metrics are software reliability and productivity. This paper describes the methodology utilized by the US Army in the application of classification trees for analysis of software metrics data. A detailed example is provided with a step-by-step procedure for construction of a classification tree for software metrics analysis. >

Publisher Summary This chapter discusses behavioral misconceptions facing the software engineer. Design of software, for information systems, proceeds on the basis of several tacit assumptions concerning behavioral patterns. The standard approach specifies design of an information system to serve all members of a technical staff. Software design and engineering is based implicitly upon thoughtless misconceptions concerning user behavior. These can concern interest of the potential customer, validity of introspection as a design guide, identification of the primary user, absence of secondary system functions, and adequacy of initial design. User behavior patterns can determine whether the system is ultimately successful or unsuccessful, regardless of technical excellence. Sophisticated computer based information systems are frequently installed on the basis of organizational status, and any such system, which lacks demonstration packages to show off its capabilities easily, has poor relationships with organization management. All software designs must provide for subsequent modification and tuning after initial implementation.