Search NASA⌕ Search

SEARCH · Search NASA

Results for “software is hard”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 19 records

Hard- and software problems of spaced meteor observations by optical electronics

An optical electronic facility is being used for meteor observations along with meteor radars and astronomical TV. The main parts of the facility are cameras using UM-92 optical electronic image tubes. The three cascade optical electronic image tube with magnetic focusing has a 40 mm cathode and resolution in the center of up to 30 pairs of lines/mm. The photocathode is of a multislit S-20 type. For meteor spectra observations, replica gratings of 200 and 300 lines/mm are used as the dispersive element.

Shafiev, R. I.↗

Evaluation of Open-Source Hard Real Time Software Packages

Reliable software is, at times, hard to find. No piece of software can be guaranteed to work in every situation that may arise during its use here at Glenn Research Center or in space. The job of the Software Assurance (SA) group in the Risk Management Office is to rigorously test the software in an effort to ensure it matches the contract specifications. In some cases the SA team also researches new alternatives for selected software packages. This testing and research is an integral part of the department of Safety and Mission Assurance. Real Time operation in reference to a computer system is a particular style of handing the timing and manner with which inputs and outputs are handled. A real time system executes these commands and appropriate processing within a defined timing constraint. Within this definition there are two other classifications of real time systems: hard and soft. A soft real time system is one in which if the particular timing constraints are not rigidly met there will be no critical results. On the other hand, a hard real time system is one in which if the timing constraints are not met the results could be catastrophic. An example of a soft real time system is a DVD decoder. If the particular piece of data from the input is not decoded and displayed to the screen at exactly the correct moment nothing critical will become of it, the user may not even notice it. However, a hard real time system is needed to control the timing of fuel injections or steering on the Space Shuttle; a delay of even a fraction of a second could be catastrophic in such a complex system. The current real time system employed by most NASA projects is Wind River's VxWorks operating system. This is a proprietary operating system that can be configured to work with many of NASA s needs and it provides very accurate and reliable hard real time performance. The down side is that since it is a proprietary operating system it is also costly to implement. The prospect of replacing this somewhat costly implementation is the focus of one of the SA group s current research projects. The explosion of open source software in the last ten years has led to the development of a multitude of software solutions which were once only produced by major corporations. The benefits of these open projects include faster release and bug patching cycles as well as inexpensive if not free software solutions. The main packages for hard real time solutions under Linux are Real Time Application Interface (RTAI) and two varieties of Real Time Linux (RTL), RTLFree and RTLPro. During my time here at NASA I have been testing various hard real time solutions operating as layers on the Linux Operating System. All testing is being run on an Intel SBC 2590 which is a common embedded hardware platform. The test plan was provided to me by the Software Assurance group at the start of my internship and my job has been to test the systems by developing and executing the test cases on the hardware. These tests are constructed so that the Software Assurance group can get hard test data for a comparison between the open source and proprietary implementations of hard real time solutions.

Mattei, Nicholas S.↗

Development of a State Machine Sequencer for the Keck Interferometer: Evolution, Development and Lessons Learned using a CASE Tool Approach

This paper presents a discussion of the evolution of a sequencer from a simple EPICS (Experimental Physics and Industrial Control System) based sequencer into a complex implementation designed utilizing UML (Unified Modeling Language) methodologies and a CASE (Computer Aided Software Engineering) tool approach. The main purpose of the sequencer (called the IF Sequencer) is to provide overall control of the Keck Interferometer to enable science operations be carried out by a single operator (and/or observer). The interferometer links the two 10m telescopes of the W. M. Keck Observatory at Mauna Kea, Hawaii. The IF Sequencer is a high-level, multi-threaded, Hare1 finite state machine, software program designed to orchestrate several lower-level hardware and software hard real time subsystems that must perform their work in a specific and sequential order. The sequencing need not be done in hard real-time. Each state machine thread commands either a high-speed real-time multiple mode embedded controller via CORB A, or slower controllers via EPICS Channel Access interfaces. The overall operation of the system is simplified by the automation. The UML is discussed and our use of it to implement the sequencer is presented. The decision to use the Rhapsody product as our CASE tool is explained and reflected upon. Most importantly, a section on lessons learned is presented and the difficulty of integrating CASE tool automatically generated C++ code into a large control system consisting of multiple infrastructures is presented.

interferometer↗

A software architecture for hard real-time execution of automatically synthesized plans or control laws

The design of a flexible, real-time software architecture for trajectory planning and automatic control of redundant manipulators is described. Emphasis is placed on a technique of designing control systems that are both flexible and robust yet have good real-time performance. The solution presented involves an artificial intelligence algorithm that dynamically reprograms the real-time control system while planning system behavior.

Schoppers, Marcel↗

Autonomy software verification and validation might not be as hard as it seems

The verification and validation of autonomy software is widely believed to be a challenging unsolved problem. To a certain extent this is true, but in this paper I argue that the problem is not nearly as severe as seems to be widely perceived. many of the perceived hard problems in autonomy software V&V also exist for traditional software, and can be solved using many of the same methods and techniques used for traditional spacecraft software. In particular, the problem of intractably large state spaces exists for any non-trivial software system.

Gat, Erann↗

Virtual Microscope Views of the Apollo 11 and 12 Lunar Samples

The Apollo virtual microscope is a means of viewing, over the Internet, polished thin sections of every rock in the Apollo lunar sample collections via software, duplicating many of the functions of a petrological microscope, is described. Images from the Apollo 11 and 12 missions may be viewed at: www.virtualmicroscope.org/content/apollo. Introduction: During the six NASA missions to the Moon from 1969-72 a total of 382 kilograms of rocks and soils, often referred to as "the legacy of Apollo", were collected and returned to Earth. A unique collection of polished thin sections (PTSs) was made from over 400 rocks by the Lunar Sample Curatorial Facility at the Johnson Spacecraft Center (JSC), Houston. These materials have been available for loan to approved PIs but of course they can't be simultaneously investigated by several researchers unless they are co-located or the sample is passed back and forward between them by mail/hand carrying which is inefficient and very risky for irreplaceable material. When The Open University (OU), the world's largest Distance Learning Higher Education Establishment found itself facing a comparable problem (how to supply thousands of undergraduate students with an interactive petrological microscope and a personal set of thin sections), it decided to develop a software tool called the Virtual Microscope (VM). As a result it is now able to make the unique and precious collection of Apollo specimens universally available as a resource for concurrent study by anybody in the world's Earth and Planetary Sciences community. Herein, we describe the first steps of a collaborative project between OU and the Johnson Space Center (JSC) Curatorial Facility to record a PTS for every lunar rock, beginning with those collected by the Apollo 11 and 12 missions. Method: Production of a virtual microscope dedicated to a particular theme divides into four main parts - photography, image processing, building and assembly of virtual microscope components, and publication on a website. Two large research quality microscopes are used to collect all the images required for a virtual microscope. The first is part of an integrated package that utilizes Leica PowerMosaic software and a motorised XYZ stage to generate large area mosaics. It includes a fast acquisition camera and depending on the PTS size normally is used to produce seamless mosaic images consisting of 100-500 individual photographs. If the sample is suitable, three mosaics of each sample are recorded - plane polarised light, between crossed polars and reflected light. In order for the VM to be a true petrological microscope it is necessary to recreate the features of a rotating stage and perform observations using filters to produce polarised light. Thus the petrological VM includes the capability of seeing changes in optical properties (pleochroism and birefringence) during rotation allowing mineral identification. The second microscope in the system provides the functions of the rotating stage. To this microscope we have added a robotically controlled motor to acquire seventy-two images (5 degree intervals) in plane polarised light and between crossed polars. To process the images acquired from the two microscopes involves a combination of proprietary software (Photoshop) and our own in-house code. The final stage involves assembling all the components in an HTML5 environment. Pathfinder investigations: We have undertaken a number of pilot studies to demonstrate the efficacy of the petrological microscope with lunar samples. The first was to make available on-line images collected from the Educational Package of Apollo samples provided by NASA to the UK STFC (Science and Technical Facilities Council) for loan as educational material e.g. for schools. The real PTSs of the samples are now no longer sent out to schools removing the risks associated with transport, accidental breakage and eliminating the possibility of loss. The availability of lunar sample VM-related material was further extended to include twenty-eight specimens from all of the Apollo missions. Some of these samples were made more generally available through an ibook entitled "Moon Rocks: an introduction to the Geology of the Moon," free from the Apple Bookstore. Research possibilities: Although the Virtual Microscope was originally conceived as a teaching aid and was later recognised as a means of public outreach and engagement, we now realize that it also has enormous potential as a high level research tool. Following discussions with the JSC Curators we have received Curation and Analysis Planning Team for Extraterrestrial Materials (CAPTEM) permission to embark on a programme of digitizing the entire lunar sample PTS collection for all three of the above purposes. By the time of the 47th Lunar and Planetary Science Conference (LPSC) we will have completed 81 rocks collected during the Apollo 11 and 12 missions and the data, with cross-links to the Lunar Sample Compendium will go live on the Web at the 47th LPSC. The VM images of the Apollo 11 (41 VM images) and 12 (40 VM images) missions can be viewed at: http:/www.virtualmicroscope.org/content/apollo. The lunar sample VM will enable large numbers of skilled/unskilled microscopists (professional and amateur researchers, educators and students, enthusiasts and the simply curious non-scientists) to share the information from a single sample. It will mean that all the PTSs already cut, even historical ones, could be available for new joint investigations or private study. The scientific return from the collection will increase exponentially as a result of further debate and discussion. Simultaneously the VM will remove the need for making unnecessary multiple samplings, avoid consignment of delicate/breakable specimens (all of which are priceless) to insecure mail/courier services and reduce direct labour and indirect costs, travel budgets and unproductive travelling time necessary for co-location of collaborating researchers. For the future we have already recognized further potential for virtual technology. There is nothing that a petrologist likes more than to see the original rock as a hand specimen. It is entirely possible to recreate virtual hand specimens with 3-D hard and software, already developed for viewing fossils, located within the Curatorial Facility, http://curator.jsc.nasa.gov/lunar/lsc/index.cfm.

Gibson, E. K.↗

In the soft-to-hard technical spectrum: Where is software engineering?

In the computer journals and tabloids, there have been a plethora of articles written about the software engineering field. But while advocates of the need for an engineering approach to software development, it is impressive how many authors have treated the subject of software engineering without adequately addressing the fundamentals of what engineering as a discipline consists of. A discussion is presented of the various related facets of this issue in a logical framework to advance the thesis that the software development process is necessarily an engineering process. The purpose is to examine more of the details of the issue of whether or not the design and development of software for digital computer processing systems should be both viewed and treated as a legitimate field of professional engineering. Also, the type of academic and professional level education programs that would be required to support a software engineering discipline is examined.

Leibfried, Theodore F.↗

Overview on METEOSAT geometrical image data processing

Digital Images acquired from the geostationary METEOSAT satellites are processed and disseminated at ESA's European Space Operations Centre in Darmstadt, Germany. Their scientific value is mainly dependent on their radiometric quality and geometric stability. This paper will give an overview on the image processing activities performed at ESOC, concentrating on the geometrical restoration and quality evaluation. The performance of the rectification process for the various satellites over the past years will be presented and the impacts of external events as for instance the Pinatubo eruption in 1991 will be explained. Special developments both in hard and software, necessary to cope with demanding tasks as new image resampling or to correct for spacecraft anomalies, are presented as well. The rotating lens of MET-5 causing severe geometrical image distortions is an example for the latter.

Diekmann, Frank J.↗

Processing the Viking lander camera data

Over 1000 camera events were returned from the two Viking landers during the Primary Mission. A system was devised for processing camera data as they were received, in real time, from the Deep Space Network. This system provided a flexible choice of parameters for three computer-enhanced versions of the data for display or hard-copy generation. Software systems allowed all but 0.3% of the imagery scan lines received on earth to be placed correctly in the camera data record. A second-order processing system was developed which allowed extensive interactive image processing including computer-assisted photogrammetry, a variety of geometric and photometric transformations, mosaicking, and color balancing using six different filtered images of a common scene. These results have been completely cataloged and documented to produce an Experiment Data Record.

Levinthal, E. C.↗

RSRA/X-Wing flight control system development - Lessons learned

The X-Wing, in concept, marries the efficiencies of a helicopter and fixed wing aircraft through the use of a four-bladed wing/rotor that can be rotated or stopped in flight. The RSRA/X-Wing flight test program was a technology demonstration of this concept which, after three successful flights, was discontinued in late 1987. In spite of many technical challenges in this program, such as the use of circulation control, the fabrication of a large all-composite rotor, the development of an advanced, quadruplex digital flight control system, and the need for higher harmonic control, no major technical problems had been encountered at the time of the stop-work order. This paper addresses the issues of flight control system development and focuses on lessons learned. As with other such programs, software development was the most consuming issue. Other subjects of discussion include the problems of balancing program goals with technical goals, software- and hard-ware-related problems, safety issues, and system testing.

Corliss, Lloyd D.↗

Galileo mission planning for Low Gain Antenna based operations

The Galileo mission operations concept is undergoing substantial redesign, necessitated by the deployment failure of the High Gain Antenna, while the spacecraft is on its way to Jupiter. The new design applies state-of-the-art technology and processes to increase the telemetry rate available through the Low Gain Antenna and to increase the information density of the telemetry. This paper describes the mission planning process being developed as part of this redesign. Principal topics include a brief description of the new mission concept and anticipated science return (these have been covered more extensively in earlier papers), identification of key drivers on the mission planning process, a description of the process and its implementation schedule, a discussion of the application of automated mission planning tool to the process, and a status report on mission planning work to date. Galileo enhancements include extensive reprogramming of on-board computers and substantial hard ware and software upgrades for the Deep Space Network (DSN). The principal mode of operation will be onboard recording of science data followed by extended playback periods. A variety of techniques will be used to compress and edit the data both before recording and during playback. A highly-compressed real-time science data stream will also be important. The telemetry rate will be increased using advanced coding techniques and advanced receivers. Galileo mission planning for orbital operations now involves partitioning of several scarce resources. Particularly difficult are division of the telemetry among the many users (eleven instruments, radio science, engineering monitoring, and navigation) and allocation of space on the tape recorder at each of the ten satellite encounters. The planning process is complicated by uncertainty in forecast performance of the DSN modifications and the non-deterministic nature of the new data compression schemes. Key mission planning steps include quantifying resource or capabilities to be allocated, prioritizing science observations and estimating resource needs for each, working inter-and intra-orbit trades of these resources among the Project elements, and planning real-time science activity. The first major mission planning activity, a high level, orbit-by-orbit allocation of resources among science objectives, has already been completed; and results are illustrated in the paper. To make efficient use of limited resources, Galileo mission planning will rely on automated mission planning tools capable of dealing with interactions among time-varying downlink capability, real-time science and engineering data transmission, and playback of recorded data. A new generic mission planning tool is being adapted for this purpose.

Gershman, R.↗

Software Fault Tolerance: A Tutorial

Because of our present inability to produce error-free software, software fault tolerance is and will continue to be an important consideration in software systems. The root cause of software design errors is the complexity of the systems. Compounding the problems in building correct software is the difficulty in assessing the correctness of software for highly complex systems. After a brief overview of the software development processes, we note how hard-to-detect design faults are likely to be introduced during development and how software faults tend to be state-dependent and activated by particular input sequences. Although component reliability is an important quality measure for system level analysis, software reliability is hard to characterize and the use of post-verification reliability estimates remains a controversial issue. For some applications software safety is more important than reliability, and fault tolerance techniques used in those applications are aimed at preventing catastrophes. Single version software fault tolerance techniques discussed include system structuring and closure, atomic actions, inline fault detection, exception handling, and others. Multiversion techniques are based on the assumption that software built differently should fail differently and thus, if one of the redundant versions fails, it is expected that at least one of the other versions will provide an acceptable output. Recovery blocks, N-version programming, and other multiversion techniques are reviewed.

Torres-Pomales, Wilfredo↗

Trusted Autonomy for Space Flight Systems

NASA has long supported research on intelligent control technologies that could allow space systems to operate autonomously or with reduced human supervision. Proposed uses range from automated control of entire space vehicles to mobile robots that assist or substitute for astronauts to vehicle systems such as life support that interact with other systems in complex ways and require constant vigilance. The potential for pervasive use of such technology to extend the kinds of missions that are possible in practice is well understood, as is its potential to radically improve the robustness, safety and productivity of diverse mission systems. Despite its acknowledged potential, intelligent control capabilities are rarely used in space flight systems. Perhaps the most famous example of intelligent control on a spacecraft is the Remote Agent system flown on the Deep Space One mission (1998 - 2001). However, even in this case, the role of the intelligent control element, originally intended to have full control of the spacecraft for the duration of the mission, was reduced to having partial control for a two-week non-critical period. Even this level of mission acceptance was exceptional. In most cases, mission managers consider intelligent control systems an unacceptable source of risk and elect not to fly them. Overall, the technology is not trusted. From the standpoint of those who need to decide whether to incorporate this technology, lack of trust is easy to understand. Intelligent high-level control means allowing software io make decisions that are too complex for conventional software. The decision-making behavior of these systems is often hard to understand and inspect, and thus hard to evaluate. Moreover, such software is typically designed and implemented either as a research product or custom-built for a particular mission. In the former case, software quality is unlikely to be adequate for flight qualification and the functionality provided by the system is likely driven largely by the need to publish innovative work. In the latter case, the mission represents the first use of the system, a risky proposition even for relatively simple software.

Freed, Michael↗

Advanced Avionics and Processor Systems for a Flexible Space Exploration Architecture

The Advanced Avionics and Processor Systems (AAPS) project, formerly known as the Radiation Hardened Electronics for Space Environments (RHESE) project, endeavors to develop advanced avionic and processor technologies anticipated to be used by NASA s currently evolving space exploration architectures. The AAPS project is a part of the Exploration Technology Development Program, which funds an entire suite of technologies that are aimed at enabling NASA s ability to explore beyond low earth orbit. NASA s Marshall Space Flight Center (MSFC) manages the AAPS project. AAPS uses a broad-scoped approach to developing avionic and processor systems. Investment areas include advanced electronic designs and technologies capable of providing environmental hardness, reconfigurable computing techniques, software tools for radiation effects assessment, and radiation environment modeling tools. Near-term emphasis within the multiple AAPS tasks focuses on developing prototype components using semiconductor processes and materials (such as Silicon-Germanium (SiGe)) to enhance a device s tolerance to radiation events and low temperature environments. As the SiGe technology will culminate in a delivered prototype this fiscal year, the project emphasis shifts its focus to developing low-power, high efficiency total processor hardening techniques. In addition to processor development, the project endeavors to demonstrate techniques applicable to reconfigurable computing and partially reconfigurable Field Programmable Gate Arrays (FPGAs). This capability enables avionic architectures the ability to develop FPGA-based, radiation tolerant processor boards that can serve in multiple physical locations throughout the spacecraft and perform multiple functions during the course of the mission. The individual tasks that comprise AAPS are diverse, yet united in the common endeavor to develop electronics capable of operating within the harsh environment of space. Specifically, the AAPS tasks for the Federal fiscal year of 2010 are: Silicon-Germanium (SiGe) Integrated Electronics for Extreme Environments, Modeling of Radiation Effects on Electronics, Radiation Hardened High Performance Processors (HPP), and and Reconfigurable Computing.

Keys, Andrew S.↗

Mark 4A antenna control system data handling architecture study

A high-level review was conducted to provide an analysis of the existing architecture used to handle data and implement control algorithms for NASA's Deep Space Network (DSN) antennas and to make system-level recommendations for improving this architecture so that the DSN antennas can support the ever-tightening requirements of the next decade and beyond. It was found that the existing system is seriously overloaded, with processor utilization approaching 100 percent. A number of factors contribute to this overloading, including dated hardware, inefficient software, and a message-passing strategy that depends on serial connections between machines. At the same time, the system has shortcomings and idiosyncrasies that require extensive human intervention. A custom operating system kernel and an obscure programming language exacerbate the problems and should be modernized. A new architecture is presented that addresses these and other issues. Key features of the new architecture include a simplified message passing hierarchy that utilizes a high-speed local area network, redesign of particular processing function algorithms, consolidation of functions, and implementation of the architecture in modern hardware and software using mainstream computer languages and operating systems. The system would also allow incremental hardware improvements as better and faster hardware for such systems becomes available, and costs could potentially be low enough that redundancy would be provided economically. Such a system could support DSN requirements for the foreseeable future, though thorough consideration must be given to hard computational requirements, porting existing software functionality to the new system, and issues of fault tolerance and recovery.

Briggs, H. C.↗

LANDO: Developing Autonomous Payload Offloading Capabilities for Lunar Surface Operations

Introduction: The Lightweight Surface Manipulation System (LSMS) AutoNomy capabilities Development for surface Operations and construction (LANDO) project is an Early Career Initiative selected for funding by NASA Space Technology Mission Directorate. LANDO is developing a general-purpose autonomy framework applicable to serial and tension-actuated manipulation agents, that will be validated using an existing prototype of the LSMS-L35 (35-kg wrist lift capacity on the lunar surface [Fig. 1], sized for a Commercial Lunar Pay-load Services (CLPS) mission). The autonomous LSMS-L35 will be used to demonstrate autonomous payload handling capabilities for Lunar and other planetary surfaces, directly addressing STMD capability gaps in autonomous excavation and construction operations, advanced robotics and spacecraft autonomy technologies, and technologies supporting emerging space industries including the In-Space Servicing, Assembly and Manufacturing national strategy. LSMS: The LSMS is a tension actuated robotic agent that is scalable (reach and lifting capacity in different gravity environments), versatile (types of surface operations), and reusable. Compared to serial arms, the LSMS provides significantly higher structural efficiency and mechanical advantage, enabling a greater payload lift capacity at a lower system mass. The LSMS is envisioned to be a crucial part of the excavation and construction portfolio, capable of supporting a variety of activities on the lunar surface. Autonomous payload handling is one of the first activities the LSMS can support that develops capabilities that are extensible to other surface operations. Payload handling is required to: remove payloads from a lander; place payloads on mobile agents for transport from a lander to construction site/assembly point; emplace payloads in their operational configuration, and aggregate components to create an asset. As an example of this critical gap, manifested CLPS missions do not currently have a ubiquitous payload offloading capability; payloads (excluding rovers) are designed to remain on the lander. Why Autonomy? Autonomous robotic systems capable of carrying out excavation and construction operations are a fundamental and critical capability required for realizing the NASA Artemis program vision to “emplace and build the infrastructure, systems, and robotic missions that can enable a sustained lunar surface presence.” While teleoperation is still feasible for lunar surface operations, increased latency at Mars will require validated supervised autonomous technologies capable of operating with minimal human involvement (human-on-the-loop) unless an unexpected event occurs requiring human intervention. Autonomy reduces operator burden, allows operations to continue during uncrewed periods, in-creases the safety of operations by automatically detecting and handling faults, and allows operating in high latency environments. Development Activities: LANDO is extending critical autonomous operations to the manipulation domain and creating an integrated system, based on reusable software modules, that is capable of planning and executing payload handling and autonomous surface operations without requiring hu-man intervention beyond a supervisory role. The priority features under development are 1) autonomously offload payloads from a tilted lander deck without buckling the LSMS; 2) sensing whether a payload is safe to lift and handle; and 3) integrate with Astrobotic’s CLPS lander. The poster presentation will highlight current development activities over the past year on LSMS-L35 prototype hard-ware design, and autonomy software.

in-space assembly↗

Managing Software Design and Design Changes

Microprocessor-based system for document production work scheduling, and change control and management information aids in design, development, and control of software. Main components Z80 microprocessor, floppydisk and hard-disk drives, and a character printer. System linked to large computer. Major software components are control program monitor (CP/M), text-editing and wordprocessing system, workbreakdown-schedule processor, and data-base management tool.

Loesh, R. E.↗

Spacelab, Spacehab, and Space Station Freedom payload interface projects

Contributions were made to several projects. Howard Nguyen was assisted in developing the Space Station RPS (Rack Power Supply). The RPS is a computer controlled power supply that helps test equipment used for experiments before the equipment is installed on Space Station Freedom. Ron Bennett of General Electric Government Services was assisted in the design and analysis of the Standard Interface Rack Controller hardware and software. An analysis was made of the GPIB (General Purpose Interface Bus), looking for any potential problems while transmitting data across the bus, such as the interaction of the bus controller with a data talker and its listeners. An analysis was made of GPIB bus communications in general, including any negative impact the bus may have on transmitting data back to Earth. A study was made of transmitting digital data back to Earth over a video channel. A report was written about the study and a revised version of the report will be submitted for publication. Work was started on the design of a PC/AT compatible circuit board that will combine digital data with a video signal. Another PC/AT compatible circuit board is being designed to recover the digital data from the video signal. A proposal was submitted to support the continued development of the interface boards after the author returns to Memphis State University in the fall. A study was also made of storing circuit board design software and data on the hard disk server of a LAN (Local Area Network) that connects several IBM style PCs. A report was written that makes several recommendations. A preliminary design review was started of the AIVS (Automatic Interface Verification System). The summer was over before any significant contribution could be made to this project.

Smith, Dean Lance↗