AN INTEGRATED COMPUTER SYSTEM FOR ENGINEERING PROBLEM SOLVING

Transcription

1 AN INTEGRATED COMPUTER SYSTEM FOR ENGINEERING PROBLEM SOLVING Daniel Roos Department of Civil Engineering Massachusetts Institute of Technology Cambridge, Massachusetts Computers should provide the mechanism that enables engineers to do better engineering. By permitting faster and more accurate and complete problem analysis to be performed, computers assist the engineer in his computational and decision making roles. The engineer today is faced with problems of increasing magnitude and complexity where the effects and interrelationships of all relevant information must be considered. The computer provides the coordinating and integrating mechanism for the problem information needed by the engineer in the decision making process. Computers enable engineers to perform total problem solutions where all pertinent information is properly considered. This role of the computer in engineering is achieved only when the computer is adequately integrated in the problem-solving environment. This integration must be both external and internal. The computer must be integrated externally with the engineer using it and the programmer developing it, and internally through the proper coupling of hardware and software. The engineer must do more than use the computer. He must actively participate in the computer solution. To do this he needs a language to communi- cate with the computer, physical accessibility to the computer, and a mechanism for obtaining engineering-oriented results from the computer. The communication language must be oriented to the problem rather than the machine, and must allow the engineer to easily specify his problem-solving requirements. Accessibility, provided through some type of remote computing facility such as timesharing, permits the engineer to interact with the computer during the problem solution. Meaningful results are obtained using scopes, plotters and other output devices. Integration of the programmer and the computer is provided through a powerful programming language and the necessary system programming capabilities to support the language. The programming language must be dynamic with respect to both proglem solution and computer memory requirements. It must allow total problem solutions where the type and amount of data can vary. To satisfy these requirements the system must have dynamic memory allocation, alternate forms of data structure, and a data management and transfer mechanism so that the same data can be used in all aspects of the problem solution. 423

2 424 PROCEEDINGS - FALL JOINT COMPUTER CONFERENCE, 1965 A modular, machine-independent system design provides the integrating mechanism for hardware and software. The system can then be implemented on any machine configuration to take full advantage of the available hardware. ICES (Integrated Civil Engineering System) satisfies the above requirements. It is a modular computer system, designed to enable the engineer to easily communicate and interact with the computer. The programmer user the ICETRAN (lces-for TRAN) programming language to develop and modify the necessary components of the system. Dynamic memory allocation, alternate data structures and data transfer and management facilities are available to the programmer. These features combine to make ICES an integrated computer system for total civil engineering problem solving. ICES is currently being developed at a cost in excess of 2 million dollars by a group of over 50 people from the Civil Engineering Systems Laboratory at M. I. T. It will provide the necessary mechanism to permit civil engineers to efficiently solve engineering problems. What are the characteristics of these problems and how do they affect the design of an integrated computer system? Each engineering problem has certain unique characteristics that differentiate it from other similar problems. The solution to all problems however is obtained using a series of basic mathematical and engineering operations, where the order in which they are performed varies with the specific problem. These fundamental operations can be considered basic computational building blocks. A problem solution represents a certain combination of these building blocks. An integrated computer system must therefore include a set of subroutines for these building blocks and some mechanism for specifying the sequence of operations for a given problem (i.e., a mechanism for putting the blocks together). There are three different ways this sequence specification can be made, namely: 1. It can be included in the program. 2. It can be specified by the engineer as part of his data. 3. A combination of the above two methods can be used where the engineer can specify some sequencing and the computer will perform the remainder. The mode of operation used is a function of the complexity of the problem being solved and the ability of the engineer. It is highly unlikely that method 1 will be used exclusively since it requires a considerable amount of programming to insure that all possible cases that could arise in the problem solution are accounted for. Methods 2 and 3 require the engineer to commnicate the sequence of operations to the machine. A language is therefore needed to allow the engineer to communicate with the computer. This language should be oriented toward the engineer and not toward the machine'. The engineer should be able to communicate with the machine in much the same way he communicates with another engineer. He must instruct the computer rather than follow instructions that have been imposed by the machine. Man and machine must form a working partnership to effectively arrive at a problem solution. A communication language satisfying the above requirements may be classified as a problemoriented language. The vocabulary of a problem oriented language consists of a series of commands, where each command represents an operation or group of operations the computer is to perform. A command consists of a command name and data relating to the requested operation. The command name is a technical term that has meaning to the engineer. The data is free format so the engineer need not be concerned with cumbersome card column restrictions. Examples of simple commands are: DISTANCE 2 3 which is used to find the distance between points 2 and 3 and, LOCATE/AZIMUTH which is used to locate point 2 at a given distance (500.26) and azimuth (50 degrees, 23 minutes, 10 seconds) from a kn~wn point (1) (see Fig. 1). ~\ Figure 1. The COGO LOCATE/AZIMUTH command. The two example commands are part of the COGO (CO ordinate GeOmetry) problem oriented language 2

3 AN INTEGRATED COMPUTER SYSTEM 425 used for the solution of geometric problems and developed by Professor C. L. Miller of the Department of Civil Engineering at M.I.T. The important characteristics of the COGO language are: 1. Programs can be written by the engineer in a matter of minutes. No computer programming knowledge is required. 2. A complete problem can be solved by writing a single CO GO program. Because of the small investment of time and money involved in writing a program, a new program is written for each problem and then discarded when the problem is solved. 3. The engineer must choose the necessary commands to obtain the problem solution. The quality and efficiency of a COGO program is dependent on the engineering ability of the user. Two engineers may write completely different COGO programs to obtain the solution to the same problem. It is interesting to note the impact of CO GO on the civil engineering profession since its introduction in It is used by many of the State Highway Departments and private consulting firms. One State Highway Department uses COGO for over 50 percent of its computer runs. The one COGO system supercedes several hundred special purpose geometric programs. COGO allows the engineer to actively participate in the computer solution. It has introduced many engineers to the computer because it is something they can understand. The acceptance and use of COGO and a companion problem-oriented language STRESS (STRuctural Engineering System Solver), also developed by the Department of Civil Engineering at M.LT., are proven examples of the power of problem-oriented languages. They have suggested how a proper balance between engineer and computer can be achieved. A problem-oriented language is necessary because it is impractical to completely pre-program an engineering problem. Part of the programming must be performed at execution time by the engineer. A problem-oriented language enables the engineer to program the machine without actually realizing he is programming. He can specify the characteristics of the problem, the desired method of solution, the requested sequence of operations, and the desired output (what he wants, where he wants it received, and how he wants it displayed) by using the commands of the problem-oriented language. Although the commands appear as a program to the computer, they appear to the engineer as a logical problem statement in engineering terminology. FORTRAN and other compiler languages have sometimes been referred to as problem-oriented languages. However, FORTRAN contains considerable computer terminology (COMMON, GO TO, DIMENSION, etc.) and is more procedureoriented than problem-oriented. It, therefore, appears more realistic to reserv~ the term problemoriented language to a language with the following attributes: 1. It is oriented to the user rather than the programmer. 2. No computer programming knowledge is required to effectively use the language. 3. The language is command structured where the commands are composed of technical terms. In certain cases the engineer can use a problemoriented language to write all the commands for a problem solution, and then submit his run for processing. It is not always possible or desirable, however, for the engineer to function in this manner. Quite often he will formulate part of the solution and then base the remaining portion on the results o~ the first part. This mode of operation is incompatible with typical batch processing operations. Instead, the engineer must be able to communicate with the computer in an interactive environment where he can: 1. Request an operation. 2. Examine his results. 3. Determine the next operation to be performed based on the previous results. This suggests that a problem-oriented language functions best in a time-sharing environment. With time-sharing the engineer can try many alternate designs and compress into one session the same work that would require many individual sessions over a long period of time in a batch processing mode. Engineering is typically performed under severe time restraints. The turn-around time problem in-

4 426 PROCEEDINGS - FALL JOINT COMPUTER CONFERENCE, 1965 herent in batch processing can totally negate the otherwise beneficial results of computers. The engineer needs immediate access to the computer. Time-sharing or some other form of remote computing offers him this access. The combination of the accessibility of remote computing and the communication capability of problem-oriented languages provides the enginp,er with the necessary tools for effective man-computer communication and interaction. COGO and STRESS represent a significant step forward in effective computer utilization. However, both of these systems are limited to problems or portions of problems of a particular discipline. Civil engineering problems generally involve the consideration of many disciplines. Even in a relatively small problem such as the design of a highway interchange, the engineer must consider the highway location and design (highway engineering), settlement, stability and foundation conditions (soil engineering), highway bridges (structural engineering), drainage (hydraulic engineering) and traffic flow (transportation engineering). As engineers we recognize each of these separate disciplines and the necessary interactions that must exist for effective problem solving. In an integrated computer system each of these disciplines must be present as a subsystem and the subsystems must be able to interact with one another. The engineer must be able to procede in his problem solution by using the necessary subsystems at the proper time. At any point in his problem solution, he can leave one subsystem, enter another to perform calculations, and then reenter the original subsystem using the results just obtained. In the past the complexity of engineering problems and the large amount of data often forced the engineer to unnaturally decompose his problem into non-interactive tasks. Many of the feedback aspects of the problem had to be overlooked. The computer now offers the mechanism to permit total problem solutions where all relevant factors and interactions are considered. One data file residing on secondary storage can be associated with the total problem solution. Certain portions of that file can be used by each of the subsystems. A data management facility must supervise the organization of the entire data file and a data transfer mechanism must transfer appropriate data between the sybsystems. What about this data associated with the subsystems? It is difficult to classify engineering data since it is of many types and varieties. In some cases only the numeric value of the data is important, where in other cases, hierarchical and structural relationships between the data are also important. Data with different external characteristics requires different internal computer representation. So~e engineering data is best stored as arrays, other as lists, and other as combinations of lists and arrays. In the past, computer systems have generally been limited to one predominant form of storage ( either list or array). An integrated engineering system must have alternate forms of data structure; namely, arrays, lists and array~lists. The programmer will then choose the proper internal structure for his data based on considerations such as space requirements, access time, information content, manipulation ability and system overhead. The alternate forms of data structure will allow new representations of engineering problems to be achieved on the computer. Most engineering data is best represented in the computer in array form. To achieve optimum capability and remove the restrictions presently associated with normal FORTRAN DIMENSIONed array storage, arrays should be dynamically allocated. Dynamic allocation of data achieves the following: 1. Arrays are allocated space at execution time rather than at compilation time. They are only allocated the amount of space needed for the problem being solved. The size of the array (i.e., the amount of space used) may be changed at any time during program execution. If an array is not used during the execution of a particular problem, then no space will be allocated. 2. Arrays are automatically shifted between primary and secondary storage to optimize the use of primary memory. Dynamic memory allocation is a necessary requirement for an engineering computer system capable of solving different problems with different data size requirements. A dynamic command structured language requires a dynamic internal data structure. The result of dynamic memory allocation is that the size of a problem that can be solved is virtually unlimited since secondary storage becomes a logical extension of primary storage~

5 AN. INTEGRATED COMPUTER SYSTEM 427 Dynamic memory allocation would extend to programs as well as data. Programs can then be brought into primary memory only when they are needed. The allocation of programs and data must be properly balanced so that the use of primary memory is optimized. The memory allocation problem has been considerably simplified as a result of newly announced third generation computer hardware, in particular new random access storage devices. The new machines are faster, more powerful, larger and cheaper than their second generation counterparts. The large primary and secondary storage available at reduced prices should increase the size of problems that can. be solved' on the computer and decrease the cost of the problem solution. Briefly summarizing, then, an integrated engineering computer system should have the following computer oriented characteristics: 1. A flexible powerful problem-oriented language for the engineer, to communicate with the computer. 2. Remote computing to make the computer accessible to the engineer. 3. An orientation toward total problem solving, not just computation. 4. An interaction between discipline areas~r subsystems-for solving a problem which encompasses more than one engineering discipline. 5. A data management scheme to organize the data and a data transfer mechanism to pass the data between subsystems. 6. A modular internal building-block structure. 7. An efficient internal data structure where alternate forms of data can be represented. 8. Dynamic allocation of data and programs based on the problem being solved. 9. Computer hardware to accommodate the necessary software. All these features have been incorporated into a computer system for civil engineering called ICES (Integrated Civil Engineering System). The engineer uses ICES to obtain solutions to the problems he faces. The internal capabilities of ICES provide the mechanism for efficient and powerful problem solutions. To function correctly, these internal computer capabilities must be properly linked together. ICES, therefore, includes a programming language ICE TRAN to create the engineering subsystems, and an operating system to coordinate and supervise ICES computer runs, both of which incorporate the necessary internal computer capabilities. ICETRAN and the ICES operating system programs are unique because they are developed by people who are expert in both the information sciences and civil engineering. In the past a schism has existed between the computer language developers and application users. The language developers could not completely appreciate the needs of the users, and their languages therefore were not well suited for the intended users. ICES, however, is developed for civil engineers by engineers. Every computer system needs a basic programming language. With respect to engineering, the FORTRAN language contains many desirable features, and could serve as the basis for the ICES programming language. However, additional capabilities are needed. For this reason, FORTRAN has been extended into a language called ICETRAN which will be used to program the ICES subsystems. ICETRAN contains all of the FORTRAN statements plus additional capabilities to facilitate the problem-solving features of ICES. These additional capabilities are imbedded in the normal FORTRAN structure. No new programming restrictions are imposed on the programmer. One of the additional capabilities contained in ICETRAN is dynamic memory allocation. A typical ICETRAN program illustrating the use of dynamic memory allocation is shown below: SUBROUTINE ADD (I) COMMON A, B, C,... DYNAMIC ARRAYS A, B, C DEFINE C, I, HIGH.. DO I L=I, I 1 C (L) =A(L) + B(L) DESTROY A RELEASE B RETURN END This subroutine adds two one-dimensional dy-. namic arrays (A and B) together to form a new dynamic array (C). To understand the ICETRAN dynamic memory allocation statements it is first necessary to briefly summarize the ICES dynamic memory allocation scheme.

6 428 PROCEEDINGS - FALL JOINT COMPUTER CONFERENCE, 1965 Associated with each dynamic array is one COMMON location known as a codeword-pointer. This location contains the following information about the dynamic array: 1. The size of the array. 2. The residence of the array (primary storage, secondary storage or space not yet allocated). 3. A pointer to the beginning location of the array in the data pool. All dynamic arrays are allocated space in a data pool, which consists of the unused primary memory space at program execution time. 4. The status and the priority of the array, to be used for memory reorganization. Dynamic memory allocation implies that the array space requirements are constantly changing. If the data pool becomes full and more space is needed, then a memory reorganization must be performed. This reorganization is based on the status (active, released, or destroyed) and the assigned priority (high or low) of the array. A sufficient number of arrays are transferred to secondary storage to make room for new active arrays. If an array on secondary storage is later referenced and therefore needed it will automatically be brought back into primary memory. Returning now to our sample program, the DY NAMIC ARRAY statement is used to specify all dynamic arrays. The statement does not cause any instructions to be generated by the compiler. The DEFINE statement is used by the programmer to specify information about a dynamic array that will be stored in the codeword-pointer. The DEFINE statement in the above example causes the size (I) and priority (HIGH) of dynamic array C to be inserted in the codeword-pointer of array C. Dynamic arrays A and B have already been DEFINED in the subprogram that called subroutine ADD. The DEFINE statement does not cause allocation of space for the array. The allocation of space is delayed until the first reference to an array element is made (statement 1 in the above example). The first time statement 1 is referenced "I + 1" contiguous unused locations in the data pool will be located. If they are unavailable a memory reorganization will occur. The pointer of the codeword will then be set to a point to the first of the I + 1 locations, which will contain a backpointer to the codeword. The remaining I locations will be used to store the array. If the array is shifted in the data pool during memory reorganization the pointer of the codeword is appropriately adjusted. After the DOP loop is completed, array A is destroyed (DESTROY A) and array B is temporarily released (RELEASE B). An array should be destroyed if it is no longer needed and released if it is not presently needed. Intelligent use by the programmer of the DESTROY and RELEASE statements decreases the likelihood of memory reorganization and increases the efficiency of one when it does occur. The dynamic memory allocation scheme is quite powerful and can handle arrays of any number of dimensions. An n dimensional array is treated internally as a partitioned set of subarrays. This offers extreme flexibility since 1. Only the subarray the engineer is working on need be in core. 2. The size of each sub array can differ. Figure 2 shows a two dimensional array where the size of each subarray (column) varies (2, 4 and 3). Figure 2. Array size variation. 3. The structure of the subarray can vary so that tree structures can be represented using array notation. A tree structure with the associated subscript notation is shown in Fig. 3. T A (1) I,,\_,.Figure 3. Array structure variations. The programmer can easily set up desired structures using the DEFINE command and then operate

7 AN INTEGRATED COMPUTER SYSTEM 429 on the structure using normal FORTRAN array notation. Dynamic memory allocation capability is merely one of many features available with ICETRAN. Others include list processing, data management, subsystem data transfer, and matrix manipulation. A completed ICETRAN program must first be processed by the ICES precompiler, which will translate the ICETRAN statements into legitimate FORTRAN statements. Although the generated FORTRAN statements might appear somewhat confusing to a FORTRAN programmer, they will accomplish the requested operations. The resulting FORTRAN program is then processed by the conventorial FORTRAN compiler. The use of the precompiler eliminates the necessity of modifying the FORTRAN compiler or developing a totally new programming language. The ICES precompiler is but one of the system programs comprising the ICES operating system. Other are described separately below. ICES Executive The principal form of input that engineers will use with ICES is problem-oriented language commands. Each ICES subsystem will have a command vocabulary associated with it. The ICES executive processes the problem-oriented language commands that the engineer issues by performing the following operations. Read and encode command. Analyze, convert and store data. Perform consistency checks. Transfer control to routine for command execution. The running of a submitted program therefore essentially consists of two phases; the analysis of the command by the ICES executive, and the execution of the command by the appropriate processing subprograms. A command is completely processed before the next command is read. In this regard the system operates somewhat as an interpreter, except that the commands do not cause computer instructions to be generated. Instead programs that have previously been translated to machine. language instructions are used. The executive has been designed to allow many powerful features to be included in the ICES problem-oriented command input language that were not incorporated in the previously discussed COGO problem-oriented language. It may be recalled that with COGO only numeric data given in a specified order was permitted. The new expanded problemoriented language capabilities and executive features of ICES include: 1. The data associated with a command may be identified by labels and specified in any order. If the engineer prefers, he may omit the labels and enter the data in a standard order (as in CO GO ). An example of a command with labeled data items is STORE POINT 10 X 50 Y which cause the X and Y coordinates of a point to be stored. 2. The engineer may omit a command data item and a standard value will automatically be used by the executive. This value may be either: ( a) permanently present by the programmer when the command is initially set up; (b) temporarily present for a problem by the engineer at' the beginning of the problem; or ( c) may be the value of the data item presently stored in the computer. The programmer who initially sets up the command indicates which of these options should be followed. If a standard value is not associated with the data item, the executive will indicate an error condition whenever the data item is omitted by the engineer. The use of standard values reduces the amount of unnecessary data an engineer must include with a command, since input entries are made only when a nonstandard value is encountered. 3. Data values may be alphanumeric as well as numeric. For example, in a geometric problem the quadrant of an angle may be identi~ fied as NE, SE, SW, or NW. The executive will automatically set a switch based on the alphanumeric value given by the user. This switch can then be interrogated by the command processing routines. 4. Incremental as well as total processing of the input command is permitted. If so instructed, the executive will process part of the data, transfer control to execute that portion of the data, and then return to repeat

8 430 PROCEEDINGS ~ FALL JOINT COMPUTER CONFERENCE, 1965 the cycle, continuing until the data is exhausted. Incremental processing minimizes storage requirements when the data field contains a variable number of data items. 5. The executive can initialize variables and incremental counters that are specified by the programmer at command definition time. These variables and counters can then be used by the command processing routines. 6. The command data field can contain command name modifiers which permit complicated tree structured commands to be set up by the programmer. To illustrate command name modifiers consider the three versions of the INTERSECT command shown below. The command data consists of the POINT number assigned to the intersection point and the two geometric objects (ARC, LINE) being intersected. In the last two commands a known point NEAR the desired intersection point must be specified since a line and an arc or two arcs can intersect at two different points: INTERSECT POINT 5 LINE 10 LINE 20 INTERSECT POINT 5 LINE 10 ARC 20 NEAR 3 INTERSECT POINT 5 ARC 10 ARC 20 NEAR 3 The engineer thinks of these as the same command (INTERSECT) but the programmer must think in terms of three different commands, since each has a different type and amount of data associated with it and each requires different subroutines for execution. The programmer views the command as the tree structure shown in Fig. 4, where the labels ARC and LINE serve as command name modi- Figure 4. The use of command name modifiers. Command name modifiers minimize the number of necessary commands and increase the capabilities of the commands. With ICES the structure of the problem oriented language input has been generalized so that the same executive can be used for all ICES subsystems. The command vocabulary of each subsystem differs but the command structure is identical. Each subsystem has associated with it a set of internally stored tables which define the commands to the executive. When the executive processes the engineer's commands, it uses the appropriate set of command tables for the sybsystem the engineer is working with. A programmer uses a command definition language to set up the subsystem commands and generate these command tables. This command definition language is a problem-oriented language designed for the subsystem developer. ICES therefore includes a problem-oriented language to generate problem-oriented languages. In addition to generating new problem-oriented languages, the command definition language can be used to easily add, modify or delete commands from a subsystem that already exists. This ability to easily modify a subsystem is a necessary requirement in engineering organizations where both the problems and the organization itself can change. The simple example below illustrates some of the features of the ICES executive and the command definition language. The STORE command used to define the X and Y coordinates of a known point will be added to the COG0 subsystem of ICES. A typical STORE command as entered by the engineer could appear: STORE POINT 10 X Y 960 The command definition program below adds the new command to the COGO vocabulary. The underlined words are the vocabulary of the command definition language and the information in quotes is the input data that the programmer supplies. SYSTEM 'COGO' ADD 'STORE' ID 'P' INTEGER 'N POINT' REQUIRED ID 'X' REAL 'XCOORD' STANDARD 0 ID 'V' REAL 'YCOORD' STANDARD 0 EXECUTE'STORE' FILE SYSTEM specifies the ICES subsystem (COGO) being modified, and ADD specifies the type of modification (addition of a command) and the name of the command (STORE). ID gives the characteristics of the data items associated with the command. One ID entry is required for each of the three data items of the STORE command. The information included as part of the ID entry includes:

9 AN INTEGRATED COMPUTER SYSTEM The identifier for the data item. The identifier defines permissable labels that the engineer can use to label the data items. A permissible label is one that begins with the specified identifier. For example the identifier of P permits the engineer to use P, PT, POINT etc. as labels for the point number. The identifiers for the X and Y coordinates given in the second and third ID commands are X and Y. 2. The internal machine representation of the data item (REAL or INTEGER). 3. The computer location where the data item will be stored (NPOINT, XCOORD, YCOORD in the above example). 4. The action to be followed if the data item is omitted by the engineer. A REQUIRED data item must be entered by the engineer or an error will be indicated by the executive. The STANDARD entry is used to specify a preset data value that will be used by the executive if the data item is omitted by the engineer. Since the coordinates of a point are quite often (0, 0), they have been preset to these values in the above example. If the action field of the ID command is left blank (this does not occur in the above example), then the data item will retain its current value if omitted from the command by the engineer. EXECUTE specifies the subroutine to be entered (STORE) to execute the command, and FILE con~ eludes the command definition. If no errors have been detected by the command definition program, the necessary tables for the newly defined command will be generated and the command will be added to the COGO subsystem of ICES. The above system modification can be run as a normal ICES job. This example is for a trivial command and does not demonstrate many of the capabilities of the ex~ ecutive and the command definition language. Unfortunately, space does not permit more interesting commands to be discussed. The reader is referred to reference 13 which contains a complete description of the executive capabilities and the command definition language. Many examples of different types of command structures are included in that paper. Dynamic Memory Allocation A series of programs has been developed to facilitate the dynamic allocation of data and programs. With regard to data, these programs define, allocate, destroy and release arrays by operating on the codeword-pointers and data pool. They retrieve and store referenced array elements, transfer arrays between primary and secondary storage and reorganize the data pool whenever necessary. Dynamic allocation of programs is accomplished by system programs which generate program segment modules from compiled subprograms, and then load and relocate these modules as they are needed during command execution. Data Management Data management system programs control the organization of the data files which reside on secondary storage and are associated with the engineer's problem solution. The data management programs allow the same data file to be used by all the subsystems of ICES, and each subsystem to use different names to refer to the same data. Variable and array names in one subsystem are mapped into different variable and array names in the other subsystems. Whenever an engineer switches from one subsystem to a different subsystem, data transfer programs use the mapping function to automatically rearrange the data to reflect the new subsystem. Data management also allows the engineer to easily operate on data files. He can print, modify or delete any of his files. The data files can serve as permanent documents of completed problems. Space considerations will of course influence how much information the engineer should keep on secondary storage and for how long this information can be retained. The data management facility will permit public files to be created so that several engineers can have access to the data to work on the same problem. Suitable protection features will be provided to ensure that unauthorized users may not examine another person's files. System Generation and Modification Necessary utility programs have been developed to set up the ICES system on a computer configuration and then make modifications to the system.

10 432 PROCEEDINGS - FALL JOINT COMPUTER CONFERENCE, 1965 The modifications are performed as normal jobs under ICES so that the system is self-modifying. ICES is modular so that each organization can adapt the system to their problem solving requirements and hardware capabilities. ICES has been designed to be manufacturer- and machine-independent. The original system has been developed for the IBM System 360. Minimum hardware requirements for ICES include: 65 k bytes core storage (any model of the System 360 may be used) ; two 2311 disk drives (three drives will result in a superior system); card input/output facilities. The usefulness of ICES is substantially improved when on-line plotting devices, graphical input/ output devices and remote computing are available. The ICES system being implemented on the model 40 System 360 of the Civil Engineering Systems Laboratory at M.l. T. features all of these capabilities. A substantial portion of the civil engineering community, however, cannot afford these added capabilities, and others who can afford them do not feel they are economically justified. As a result none of these capabilities are required in a minimum ICES system. The inclusion of any or all of the features will result in a far superior ICES system. ICES Supervisor The ICES supervisor coordinates all of the ICES system programs' and supervises the use of the computer. It calls on the proper system program or user program based on the requested operations. Some people will no doubt express concern over the time overhead of the above system programming capabilities. A system objective should be the minimization of time required for problem solution. However, this must not be done at the expense of finding the optimal or best solution to a problem. Quite often an increase of several microseconds is completely justified by the benefits obtained from the operations performed. For example, dynamic memory allocation does involve additional machine cycles, but it also eliminates many bookkeeping requirements and the packing of information that are necessary without its Use. It also allows increased problem-solving capabilities. One principle of ICES is that no system programming capabilities are forced upon the programmer. He is, for example, given the choice between normal dimensioned arrays and dynamic arrays, between the input capability of the executive or normal FOR TRAN READ statements. The programmer must consider the problem being solved and the tradeoffs associated with each of the available alternatives, and then make his choice. Let us now reexamine the ICES system in total. One approach is shown in Fig. 5. Each of the vertical boxes represents a subsystem of ICES. These subsystems utilize the basic engineering building-block routines represented by the horizontal box at the bottom, and the system programming capabilities of the ICES operating system (top horizontal box). This framework enables subsystem programmers with no system programming capabilities to easily develop high-performance subsystems using the ICE TRAN language. ICES SYSTEM PROGRAMS Sub- Sub- Sub- -- System System ~ System A B N BASIC ENGINEERING BUILDING BLOCKS Figure 5. The ICES system. The Civil Engineering Systems Laboratory at M.1. T. is currently developing a comprehensive series of ICES subsystems. (See, for example, references 4 and 5 and 8 for a description of subsystems being implemented for ICES). ICES subsystem development should not, however, be restricted to M.LT. Instead, ICES should be considered as a framework for civil engineering computer \vork, where all members of the profession make contributions. It is the integrating mechanism for the programs that have been developed 'in the past and the work that will be performed in the future. User groups such as SHARE have demonstrated how needless duplication of programming effort can be reduced. The ICES concept is a natural extension of this idea. The user organizations provided a framework for rational development and distribution of the necessary component programs. ICES provides a framework for uniting these components in ':1n -inte-

11 AN INTEGRATED COMPUTER SYSTEM 433 grated system. We can now, therefore, think of system coordination as well as program coordination. What then is ICES? ICES is many partnerships. A partnership between the third generation hardware and the ICES programming software, a partnership between ICETRAN and programmers, a partnership between the problem-oriented language command structure and the engineer, and a partnership between the integrated computer system and the engineering organization. It is an integrated system for civil engineering where each of the necessary components (hardware, software, engineer, manager, and programmer), properly contribute and interact. ACKNOWLEDGMENTS A project such as ICES is the result of careful planning and represents a natural evolution of previous work. For the past ten years Professor C. L. Miller as director of the Civil Engineering Systems Laboratory at M.I. T. has demonstrated how computers can effectively be used in engineering practice and education. This past work serves as the foundation for ICES, which was conceived by Professor Miller and is now being developed by individuals who were trained and inspired by him. These individuals include Robert Logcher, Jay Walton, Alan Hershdorfer, Alden Foster, Ron Walter, and Richard Goodman. The work reported in this paper was formulated by these people. The author is also indebted to Miss Betsy Schumacker of IBM for her advice and contributions. REFERENCES 1. J. A. Champy, "Man Machine Computer Systems in a Public Works Agency: A Management View," Industrial Management Review, Spring S. J. Fenves et ai, Stress: A Users Manual, M.I.T. Press, , R. D. Logcher and S. P. Mauch, Stress: A Reference Manual, M.I.T. Press, , "The Form and Use of an Interactive Problem Oriented Language," this volume. 5., et ai, "A Users Manual for the On- Line Use of the Structural Design Language," Internal Project MAC Memo M-234, M.I.T. 6. C. L. Miller, "Man-Machine Communications in Civil Engineering," Department of Civil Engineering, T63-3, M.I.T. (June 1963). 7. and R. Walter, "Communicating with Computers in Civil Engineering Design," Department of Civil Engineering, T65-4, M.LT. (Mar. 1965). 8. P. O. Roberts and J. H. Suhrbier, "Highway Location Analysis, An Example Problem," Department of Civil Engineering, R62-1, M.LT. (Mar. 1962). 9. D. Roos and B. Schumacker, "ICES: Integrated Civil Engineering System," American Association of State Highway Officials Conference on Improved Highway Engineering Productivity, Boston (May 1965). 10. and C. L. Miller, "COGO-90: Engineering Users Manual," Department of Civil Engineering, R64-12, M.I.T. (Apr. 1964). 11. and, "The Internal Structure of COGO-90," Department of Civil Engineering, M.I.T. (Feb. 1964). 12. and, "COGO-90 Time-Sharing Versions," Department of Civil Engineering, M.I.T. (May 1964). 13. R. A. Walter, "A System for the Generation of Problem Oriented Languages," this v~_lume.

12