@device(PostScript) @make(Plan) @planhead(versiondate="17 November 1986", plansection="Section B", copyrightdate="1986", title="Objectives and Requirements of the Athena System", author="by S. R. Lerman and J. H. Saltzer") @Majorheading The following one-sentence statement captures the objective of Project Athena at a very high level: @begin(quotation) @b @end(quotation) From that very general statement, a more detailed, but still high-level, list of sub-objectives can be derived: @begin(enumerate) Design and implement the new computing environment with the following properties: @begin(itemize) it provides computing resources needed to support educational uses at M.I.T@.; it accommodates heterogeneous hardware; it provides users and programmers with machine independent interfaces; it maximizes exportability and importability of software; it extends so that by 1990 each student can be provided with a workstation at a total system cost of about 10% of M.I.T@. tuition. @end(itemize) Foster innovative projects by the M.I.T@. faculty that demonstrate the educational value of the new computing environment. Put in place and operate a system of about 1500 workstations for use the M.I.T@. faculty, students and staff. @end(enumerate) @Heading Project Athena is a five-year trial of the widespread use of networked, high performance workstations with advanced graphics capabilities in university educational programs. It is predicated on the hypothesis that such workstations offer the potential for making significant, but as yet unexplored, improvements in the way in which existing undergraduate and graduate curricula are delivered. In addition, the widespread availability of high performance workstations raises important questions about how the current curricula should be altered in response to a shift in the technology to which students and professionals are likely to have ready access in the future. That description of Athena requires some more detailed definitions of terms. First, a @I is a hardware and software system that is significantly different from a set of independent, stand-alone personal computers that are now in widespread use. The Athena system will support much higher computational performance, significantly better graphics and high speed communication of information (programs, data and potentially video images) across the entire campus. The reference to Athena as a @I indicates that part of the project's mission is to determine whether workstations can be used as part of a university education, and if so, where and how. Athena will experiment widely with new concepts in educational computing that have been as yet untested; it is expected that some of these concepts will succeed and others will fail. The Athena software and hardware must be capable of supporting the relatively sophisticated applications the faculty will want to explore. The term @I conveys the concept of a physically ubiquitous system that is accessible by students from most of their usual work places on campus@Ydormitories, libraries, some classrooms, fraternities (and other independent living groups), and public work areas in M.I.T@.'s academic facilities. Widespread access also means availability to the faculty. Instructors who are heavily involved in teaching courses that use Athena's computational resources should have workstations in their offices and in the offices of key teaching assistants. Given the above general definition, Athena has a set of goals for the future of M.I.T@.'s academic computing which are as follows: @begin(enumerate) Innovation @Y Athena should foster innovations in the applications of computation to university education. These innovations should span the entire spectrum of M.I.T@.'s curriculum and provide a base of experience in using computers in education. This base of knowledge will in turn make it possible for M.I.T@. to make well-informed decisions about educational computing beyond the five year Athena experiment. @blankspace(1 line) While many of the innovative uses of computers are likely to arise spontaneously as a result of simply providing the Athena system to the M.I.T@. community, a more coordinated and focused effort is also being undertaken. An internal grant program that provides faculty with funds to take time from their current research and teaching responsibilities is already in operation. This program is expected to provide on the order of $10 million to the faculty. One of Athena's goals is to assist those faculty in developing new software. User coherence @Y The goal is to create a computer system in which students, faculty and staff do not have to invest significant amounts of time learning different operating systems, languages, and applications software in order to cope with differences across different types of workstations. For example, students should not have to learn different operating system commands, editors, text processing systems and other application level software when they move from one part of the Athena system to another. Similarly, educational software developed by faculty should present similar user interfaces; "help" features should be organized in a uniform format, menus should be laid out comparably and information presented to the student should be organized in a similar way across applications. The goal of user coherence is to create a computational environment which can accommodate hardware from a variety of manufacturers without imposing large learning costs on the M.I.T@. community. We envision M.I.T@. as being a multi-vendor computer environment for the forseeable future. Exportability of results @Y The educational software developed at M.I.T@. using the Athena system should be easily exportable to other academic institutions. Ideally, faculty should be able to send colleagues binary versions of their programs which can be run on comparable hardware at their colleague's universities. As a more practical goal, source code compatibility should hold across comparable hardware running the same version of the operating system. When changes in source code have to be made, they should be as small as possible and confined to a relatively small portion of the original source code. Ease of importation @Y Given that there is likely to be a large body of educationally useful software developed outside M.I.T@., the Athena system should be designed to facilitate the importation of software from other universities and software vendors with a minimum of effort on the part of the faculty and users. As in the case of the goal of exportability, the easy transfer of software is likely to be confined to relatively standardized UNIX systems. Ubiquity @Y The Athena system should be available across the campus. In the five years of the formal Athena experiment, Athena will deploy a large number of workstations in all the areas of M.I.T@. community. Much of the Athena hardware will have to be shared by multiple users; this sharing means that while a workstation will provide personal computing for a single individual while it is in use, the identity of that individual will shift from session to session. The Athena workstations will often be in public spaces (e.g. libraries or common areas in dorms) or areas shared by groups of individuals (e.g. laboratories or dorm suites). Beyond the actual experiment, Athena must lay the groundwork for a system in which every student and faculty member at M.I.T@. might have a privately owned workstation. @blankspace(1 line) A key element of ubiquity is that faculty can assume that Athena provides a well-defined, minimum level of computational support that is available to every M.I.T@. student. In the same way that every subject taught to sophomores at M.I.T@. can assume that all students know calculus, faculty will be able to assume that students have easy access to the Athena system, and that all upperclass students have reasonable facility with its use. Those subjects which have computational needs that exceed those provided by Athena will have to make special provisions for hardware and software. This might consist of special work areas created by academic departments (in some cases using augmented Athena equipment) or entirely separate computational facilities. System coherence @Y Athena will encourage the sharing of ideas, program code, data and experience in the use of computation in the curriculum across the entire M.I.T@. community. Sharing will require that there be a uniform set of computer languages and that software be designed to allow its reuse in a variety of contexts. Athena will provide a small set of supported programming languages, standard function libraries, and toolkits designed for rapid construction of applications, with the goal of encouraging their use wherever feasible. Integration and interface with other parts of M.I.T@. @Y Athena must provide computational services that bring together various parts of M.I.T@. For example, access to computer-provided library services, on-line data base searches and the non-Athena computers on campus should be provided. In the long term, Athena must integrate into the regular, ongoing computer services provided on the M.I.T@. campus. The system must be designed so that at the end of the experiment, its operation and maintenance can be "handed off" to either an existing organization within M.I.T@. or a newly created one with a charter going beyond the five year, Athena experiment. Reliability @Y Athena is envisioned as becoming an integral part of an M.I.T@. education. It must therefore provide reliable service to the M.I.T@. community. This implies that services can still be provided in the face of a large class of serious hardware failures, and that shifts in the Athena software do not produce "outdating" of programs that are crucial to the education of students. For example, while individual workstations may fail, there should be adequate redundancy so that a student can still use the Athena system effectively. When there are new software releases, the prior releases should still be available for the hardware that was installed when the earlier release was issued. Mechanisms for providing reliable storage should exist. These may require active intervention by users (as in archiving to floppy disk or other stable media). Cost @Y During its five year life, Project Athena is funded by grants from Digital and IBM and a special fund-raising activity of the Institute. This initial investment will provide for the development of the system and permit a curriculum development effort that "lives in the future" computational environment. The design of the Athena system must, however, be sustainable beyond Athena's five year time frame. This implies that the total costs of operating, maintaining, and upgrading the facilities as needed must be compatible with M.I.T@.'s overall expenditures for instruction and the benefits that accrue to as a result of having widespread use of computation in an M.I.T@. education. @blankspace(1 line) While the precise mechanism for paying for various components of the Athena system after five years is still unclear, one strategy would have students purchase workstations and pay for the running of shared resources (file servers, public workstations, components of the networks, etc.) as part of tuition. Athena must be designed so that the costs of doing this are not an unreasonable fraction of current tuition charges. The design goal is to make to total costs to the student on the order of 10% of tuition. These costs must include hardware, software, maintenance, printing, storage and networking charges. @end(enumerate) @newpage @Majorheading This section translates the goals and objectives into a list of specific requirements that the Athena system design must meet. The remainder of the technical plan describes approaches to meeting the requirements listed here. These requirements have come from several sources: @begin(itemize) Extrapolation from the goals of the previous section. Comments and suggestions from M.I.T@. faculty. Comments and suggestions from M.I.T@. students. Technical forecasts by the Athena management, vendors, and other advisors. Imagination by Athena staff and management about how Athena might be used. @end(itemize) Each requirement or potential requirement includes a bracketed numerical estimate of its importance to Project Athena, in the range from zero to three. The meanings of the numerical values are as follows: @format( 3 Essential to the success of the project. 2 Important to the success of the project. 1 Would be nice but is not important. 0 Not needed; might actually interfere if present. ) We rate potential requirements to the nearest half-integer; 1.5 is the dividing line between features that are requirements and features that might be nice, but are not required. @begin(enumerate) Economic requirement. @enumerate{ Bottom-line total cost of workstation, software, communications, central facilities, and operations must be less than 10% of tuition at a specified near-future date, currently September 1, 1990. [3] } Places that workstations must be located. @enumerate{ Dormitory rooms. Workstation must be quiet, have a small footprint, and be secureable. They must be placeable in every M.I.T@. dormitory room without need for new electric wiring. [2.5] Fraternity. Requirement similar to dormitory room, except location is not under M.I.T@. ownership and may be several miles distant from the M.I.T@. campus. [2.5] Publicly accessable workstations. M.I.T@. classroom converted to contain several workstations at which students work independently on homework. [3] Library carrel. Publicly accessible; in addition, workstation keyboard must be quiet during use. [2] Special teaching facilities. M.I.T@. classroom converted to be a computer-based seminar room where students are expected to work together in the presence of an instructor. [2] Lecture room. Workstation must be capable of coupling with a projection television system. [2.5] Laboratory. Workstation must be capable of interfacing with real-time experiment controllers. [3] Home or apartment. Workstation must be capable of stand-alone use by a person who also visits the campus daily. Must be able to take advantage of dial-up telephone lines to maintain some direct communication with campus. [2] } Workstation hardware requirements. @enumerate{ 1 Mips, 32-bit architecture or an equivalent performance combination. [3] RAM memory of 2 megabytes or greater. [3] Virtual (or real) memory of 16 megabytes or greater. [3] Hardware floating point. [2.5] Fixed disk storage of 40 megabytes with larger options. [3.0] Standard removable media. (Current standard is 1.2 Mbyte AT-compatible diskette.) [2.5] Standard local area network interface. (Standard is Ethernet or IBM token ring.) [3] Hardware must be installable by naive beginner, and the first level of trouble diagnosis must be doable by that same beginner. [2] Graphics-capable display@Ysee section 5, below. [3] } Required workstation options. @enumerate{ Optional removable cartridge tape. [2] Optional ability extend memory size to at least 16 Mbytes. [2] Optional serial port and telephone modem at highest data rate available at moderate cost, for use in home and apartment locations. [2] Optional printer port for standalone locations. [1.5] Optional interface to optical disk ("CD ROM") reader. [1.5] Optional experiment controller interface, for use in laboratory locations. [3] Optional attachment of an industry-standard bus. [1.5] } Hardware graphics requirements. @enumerate{ All displays should have resolution of approximately 1000 by 1000 picture elements and be all-point-addressable. [2.5] Monochrome, small-footprint display for use in large quantity. [2.5] Optional larger-screen monochrome display for use in laboratories and demonstration areas. [2] Optional 16-color display for use in special teaching situations. [2] Optional interface to NTSC television sources. [1.5] Optional interface to projection system for use in lectures. [2.5] Pointing device, e.g. mouse. [3] } Storage requirements. @enumerate{ The student must own the storage medium used to hold bulk of that student's personal files. [3] Storage or distribution media are needed for public libraries, class libraries, and Athena standard software. [3] } Hard copy printing requirements. @enumerate{ Printers must allow text in multiple fonts, graphics, and images, in monochrome. (E.g., capabilities associated with a laser printer.) [2] Low cost, low-duty-cycle printers that can be placed in public workstation rooms, dormitories, and fraternities. [2.5] High-volume printers at a few central locations, available for use by any workstation. [2] Some method of obtaining low-volume hard-copy of color output. [1.5] Accounting for printer use on a per-student basis. [2.5] Ability to control who may use a specific printer. [1.5] } Workstation operating system requirements. @enumerate{ Applications programming interface to the operating system, the network, and the display management system must be hardware- independent. [2.5] Operating system must have potential for availability on several vendors' workstations. [3] Operating system must be widely enough used that many applications tools are available from other vendors. [3] Workstation software must be installable, configurable, and maintainable by a naive beginner. [2] Operating system must support M.I.T@. standard network protocol family, TCP/IP with subnet routing. [3] } Graphics and image manipulation software @enumerate{ General window system with primitive capabilities that support 2-D, text, and color on bit-mapped displays. [2.5] Toolkit for rapidly building graphics applications that make use of window, pointing device, 2-D, text, and color capabilities. (Including library routines that provide, for example, scrollbars, buttons, text windows, and menus.) [2.5] Toolkit facilities must not impose a significant performance penalty when compared with doing graphics applications without it. [2] Ability to capture any screen image in a file or send it to a printer. [2.5] } High-level application software packages. @enumerate{ General purpose text editor. [3] Word processing system, with ability to handle equations, graphics and images. [2.5] General purpose data base management system for use @itemize{ on data bases belonging to a class, department, or M.I.T@. library [2.5] on private files of the student [1.5] } Symbolic algebra manipulation. [2] General purpose spreadsheet. [2] General purpose browsing system. [2] Laboratory data analysis system. [2.5] Statistical analysis system [2] } Software development facilities. (See also graphics software) @enumerate{ C compiler and libraries [3] Fortran 77 compiler and libraries [3] Common Lisp compiler, interpreter, and libraries [2.5] Scheme interpreter [2] Fortran and Common Lisp bindings for all important system, network, and graphics functions. (C bindings assumed.) [2.5] Numerical analysis software [3] Tools for building friendly user interfaces, on-line help, and documentation in a system-standard way. [2] } File access requirements. @enumerate{ A student using any public workstation must be able to read and write that student's current private files. (Archives of old files need not be so accessible, though.) [3] A student using any public or private workstation must be able to read libraries of classes, of organizations, of the M.I.T@. library, of Athena-provided software and data, and of public libraries. [3] Faculty developers must be able to create and update libraries to be used by their students. [3] Any user must be able to export personal files and to import the files of other users. [2] } Electronic mail and related requirements @enumerate{ Any user (faculty member, staff member, or student) must be able to send mail to any other user with knowledge only of the recipient's identity. [2.5] Must provide connections from Athena to other M.I.T@. electronic mail systems. [2] Must be able to send mail to members of shared or private, named mailing lists. [2] Must provide public bulletin boards. [2] Must have on-line group communication system for use in discussion forums and consulting. [1.5] Must have ability to exchange text files with IBM PC compatible and Apple Macintosh workstations. [1.5] } Protection and privacy requirements @enumerate{ Private files of a student should be secure against casual browsing by other students who are knowledgeable about the system design. [2.5] Public libraries should be secure against unauthorized modification by knowledgeable students. [2.5] Labels that appear to identify the originator of mail, messages, and bulletin board entries should be reliable. [2] Accounting (e.g., of printer usage) should be secure against unauthorized modification by knowledgeable students. [2] System must control access to third-party software in accordance with its license provisions. [2.5] } Support system requirements @enumerate{ Failure of any single piece of hardware should render at most a few student workstations unusable or a limited set of services unavailable. [3] Update of Athena standard software must be possible without visiting every workstation. [3] System must permit use of student-owned workstations and at least some public workstations 24 hours per day. [2] System should require a minimum of operational and administrative effort. [3] Restoration of most service following partial or campus-wide electric power failure should be automatic. [2.5] System must make it easy to find services and information. [2.5] System services should be organized in a modular way, so that it is possible to make use of parts of the Athena system without requiring all of it. [2] } Other requirements @enumerate{ A public library to which any student may post programs, data, or graffiti. [2] Update-to-update compatibility must insure that faculty-developed software does not stop working. [3] Ability for faculty to work at home developing materials for use in classes. (Dial-up line is only communication medium.) [2] An up-to-date, on-line directory of Athena users. [2] } @end(enumerate) @Heading(Nice features that are not requirements.) The following potential requirements and other features might be nice, but they are not essential for the success of Project Athena. @begin(enumerate) A shared community file system capable of making the exported files of all users appear to be in a common name space. [1.5] Fee-based file backup and archive services. [1.5] Universal color displays. [1] Deep (more than 4 image planes) color. [1] Universally available optical disk readers. [1] Compatibility/coherence with IBM PC compatible and Apple Macintosh workstations. [1] Optional "manufacturing environment" hardening, for workstations used in some laboratory situations. [1] Controlled mail connections to electronic mail systems outside M.I.T@., especially to other universities. [1] Ability to mix modules written in different languages into a single running program or subsystem. [1.5] An education authoring language or languages. [1] Extensibility to research needs at M.I.T@. [1.5] @end(enumerate)