【 畢業(yè)設(shè)計 畢業(yè)論文】自動化專業(yè) 計算機 畢業(yè)論文 文獻(xiàn)翻譯 中英文

外文原文Computer ControlW. Daley & R. CareyGTRI, Georgia Institute of Technology, Atlanta, GA 30332 INTRODUCTIONThis chapter discusses both the system and subsystem control computers. The purpose of the system control computer is to provide a single machine that will allow a user to control the operation of the CHARA Array. This computer will allow the user to acquire astronomical data, align optics, and perform diagnostics and is also responsible for interfacing with remote users and providing them access to the system. The subsystem control computer, on the other hand, communicates between the system control computer and each of the subsystems, controlling motors, solenoids, et cetera, and transmitting status reports on each of the subsystems to the central computer. SYSTEM CONTROL COMPUTERU.2.1 FunctionalityThe system will provide a graphical user interface with the following functionality:_ Communicate directly with each subsystem_ Control all subsystems together as one unit_ Acquire and store data_ Display the state of the optics graphically_ Display environmental conditions_ Display any subsystem error conditions_ Control individual telescopes and all subsystemsU.2.2. RequirementsThe system computer needs to:_ Perform multiple tasks concurrently_ Share file information with other computers_ Communicate simple commands and data to subsystems_ Monitor and record real-time control information of the subsystems_ Provide Internet access for remote users_ Provide reliable and maintainable software . Communication and control signals Design HardwareA SUN Microsystems SPARC 10 was chosen for the system control computer. This machine uses the UNIX based Solaris 1.1 operating system which will allow multiple users to log-on and multiple programs to be executed concurrently. The SPARC 10 supports an Ethernet network interface which will be used to send simple commands and data to the individual subsystems. This network will also be used for aligning and trouble-shooting problems with the system. The operating system supports the Network File System (NFS) which will be used to transfer files between the various subsystems.The workstation will have a replicated memory card installed, which will be connected by fiber-optic cables to replicated memory cards installed in each of the subsystem computers. This real-time replicated shared-memory system will connect computers at high data speeds (150 Mbits/sec) with minimal application-to-application transport delay. This network will allow the system control computer to monitor the status of the control variables located on the individual subsystems, by looking at its local memory located on the replicated memory card. The network will also allow the subsystem computers to do real-time control synchronization by using local variables located on the replicated memory cards.The system control computer will generate a TTL clock which will be distributed to all the subsystems over a fiber optic network. This clock will be used to synchronize all the motor controllers to insure stable system operation. The connections between the system computer and the other subsystems can be seen in Figure U.1. . Software object design. SoftwareThe software will be developed in the C+ language, which supports object oriented software design and implementation. The use of object oriented programming (Figure U.2) will ensure that the software is developed so that it is reliable and maintainable. This is done by forcing the consideration of total system functionality and design before any code is written. The program is designed as a number of objects that interact with each other through well-defined interfaces. This means that all objects in the program have to be identified and the data flow between them determined. Once an object has been developed and its associated functions have been debugged, it can be used on any subsystem that has similar requirements without any modification. It also means that an object can be updated without interfacing with the rest of the system.The Graphical User Interface (GUI) will be developed using the X Windows standard and the Motif widget toolset. This GUI supports widgets that implement pop-up windows, scroll bars, push buttons, list boxes, edit boxes, etc. These widgets will allow the user to interact with the GUI using a mouse and keyboard.The GUI will allow objects, like mirrors, telescopes and beam paths to be drawn graphically on the screen. The user will manipulate these objects by clicking the mouse on the object and dragging it to its new location. This will be useful in inserting or removing a mirror from the optical path, for example. RisksThe technical risks associated with the successful completion of this aspect of the project would be minimal. OptionsThere are many options to the various parts of the system control computer but only a few possibilities will be discussed here.The system computer could have been another type of workstation such as HP, IBM, Silicon Graphics and DEC but they each have their limitations of networking, processing speeds, hardware and software availability. The SUN workstation provides the most cost effective solution to the problem. An IBM 486 computer could be used but it would have to run a multi-tasking, multi-user operating system to successfully implement the system control computer. The operating systems that currently run on IBM 486s that meet these requirements are UNIX and Windows NT. SUN's UNIX implementation is a lot better than any UNIX that runs on a PC, and Windows NT is an unproven product.The replicated memory network could be replaced by a deterministic network like a token- ring network. This solution would require that software be developed to handle the message passing between the various subsystems. Although this is not an impossible task, it adds a level of complexity to the system software design, that makes it harder to develop and extremely difficult to maintain.C could have been chosen as the development language, since it is well known and widely used. Although C is a powerful language, it does not force the developer to write maintain- able software. Instead, it leaves it up to the developer to ensure that there are no conflicts between the various modules in the system. In very large software projects like the CHARA Array, a lot of diligence and documentation is required on the part of the developers, to ensure that there are no side effects from one module interacting with another. In C, there is also no well defined mechanism to ensure that code developed for one module will work in another module. C+, on the other-hand, eliminates side effects by hiding the data and function implementations from the rest of the program. This ensures that data is only manipulated by member functions that use the proper procedures, thus eliminating adverse side effects which in most cases reduce the integrity of the software. DATA ACQUISITION COMPUTERWhile the system control computer is responsible for the real time control aspects of the Array another system is required for data logging and reduction. This system will be required to log any data produced by the fringe tracking and imaging systems, produce real-time estimates of visibilities and allow access to, but not control of, many of the Array subsystems. This computer will allow the operator, or a visiting astronomer, to inspect data on the fly and perform basic data reduction without interfering the operation of the Array. A Sun Sparc or equivalent UNIX machine connected to the local area network should be adequit for this job. SUBSYSTEM CONTROL COMPUTER FunctionalityThe subsystems will provide the following functionality:_ Communicate with each subsystem and central controller_ Control necessary control devices (motors, solenoids, etc.)_ Transmit current subsystem status to the central controller_ Transmit error conditions to the central controller RequirementsThe subsystem computer needs to:_ Perform multiple tasks concurrently_ Respond to simple commands from the system control computer_ Control hardware devices (motor controllers, digital I/O, etc.)_ Monitor environmental conditions_ Provide reliable and maintainable software Design MethodologyThere were two hardware design methodologies considered:The first method was to make the initial cost of the system as low as possible while providing the desired functionality. This could be accomplished by determining and defining all the communication protocols between each subsystem. As long as the communication protocols were well defined and adhered to, it would not matter what hardware platform was used for each subsystem. Each subsystem could then be optimized to be the most cost effective for its functionality. For example, a subsystem that monitors environmental variables and controls a set of mirrors could be built on a low-cost STD bus system, whereas a system that needs to acquire real-time data and perform FFT processing would use a VME type system with DSP processor cards installed. Although this design methodology would produce the cheapest initial system, it would be very expensive to maintain in the long run. This is because there would have to be someone who is familiar with each of the different hardware and software architectures used. Such individuals are typically hard to come by. Also, the stocking of spare parts to fix failed boards would be cost prohibitive, since spares would have to be stocked for each different subsystem.The second design methodology was to make the software development and long-term maintenance as simple and cost effective as possible. This was done by using the same base computer system in all the subsystems. While this might be overkill for some subsystems, it will make for a more reliable and maintainable overall system in the long run. The CHARA solution is to specify a BUS architecture, the main processing board, and a real-time operating system. Various I/O, D/A, A/D, and DSP boards are specified that can be used if needed by the subsystems. This means that there is a base configuration that is the same across all subsystems, with modularity built in with the choice of interface boards. This solution allows software developed for one subsystem to be used on another subsystem, and the same spare parts can be stocked for all subsystems.Choosing the correct BUS was very important and the following Buses were considered because of the availability of real-time hardware and software:_ PC_ Multibus_ STD_ STD-32_ VME_ VXITable U.1 shows a comparison of these options; the different category ratings are discussed below.TABLE U.1. Comparison of available BUS architectures Category Rating Description:_ Ethernet SupportExcellent CPU cards have Ethernet ports built in, and software drivers suppliedVery Good Ethernet cards and drivers are available from many vendorsGood: Ethernet cards and drivers are available from a few vendorsFair: Ethernet cards and drivers are available from one vendorPoor: No Ethernet cards or drivers available_ DSP SupportExcellent: Many different vendors with very high speed computational boardsVery Good: Many different vendorsGood: A few different vendorsFair: One vendorPoor: No vendors_ A/D, D/A, & Digital I/O SupportExcellent: Many different vendors with many different boardsVery Good: Many different vendorsGood: A few different vendorsFair: One vendorPoor: No vendors_ Motor Controller SupportExcellent: Many different vendors with many different boardsVery Good: Many different vendorsGood: A few different vendorsFair: One vendorPoor: No vendors_ Real-Time O/S SupportExcellent: BUS supports many different processors and O/SsVery Good: BUS supports many different O/SsGood: BUS supports a few different O/SsFair: BUS supports one O/SPoor: None_ CostExcellent: Many low-cost boards and software (<$500)Very Good: Few low-cost boards and softwareGood: Many medium-cost boards and software ($500 $1500)Fair: Few medium-cost boards and softwarePoor: Only high-cost boards and software (>$1500)_ ReliabilityExcellent: Very high MTBF, very good mechanical support for cardsVery Good: High MTBF, good mechanical support for cardsGood: Average MTBF, average mechanical support for cardsFair: Low MTBF, poor mechanical support for cardsPoor: Very low MTBF, very poor mechanical support for cardsAssigning a scale of 1 5, with 5 being excellent and 1 being poor, gives the following overall rating shown in Table U.2.All categories were determined to be of equal importance and no weighting was used. Based on this selection criteria， the VME BUS scored the highest and was chosen for the subsystem controllers. The available software tools and development environment were not taken into consideration but will be discussed in a later section. HardwareA Motorola-based CPU board was chosen as the central processor for the VME BUS because it is widely supported by the real-time operating systems. The CPU board will have the following specification:25 MHz MC68040 microprocessor with 8KB of CacheTABLE U.2 Rating of available BUS architectures _ 8 MBytes of DRAM_ Ethernet interface_ Sockets for on-board ROM/EPROMThe base system will also contain a replicated shared-memory fiber-optic network card, which will allow each subsystem to have an exact copy of a block of memory. This real-time replicated shared-memory system will connect computers at high data speeds (150Mbits/sec) with minimal application-to-application transport delay. Variables stored in this block of memory will be available on all subsystems as local variables. This will make developing the system software much easier, since time will be spent developing software to control the subsystem as opposed to implementing complex communication schemes between the individual subsystems. For example, the OPLE subsystem needs error information from the fringe tracking subsystem, which can be implemented by having the fringe tracker write the error information to a specific memory location and then set a flag in another memory location. The OPLE subsystem would read the error information when the flag is set, and then clear the flag. In this approach, no software development need be expended on the communication between the OPLE and fringe tracker, since it is all handled in hardware. The replicated memory system will also be invaluable for trouble-shooting and system debugging, since the control variables of each subsystem can be seen and recorded at the central computer.The remaining cards that will go in the VME chassis will be optional and depend on the functionality of the subsystem. A diagram of a typical subsystem can be seen in Figure U.3. SoftwareThe software will be developed in the C+ language, which supports object-oriented software design and implementation. The use of object-oriented programming will ensure that the software is developed for reliability and maintainability, since it forces the software to be completely designed before any code is written. It is anticipated that the CHARA Array will use an open system that will adjust to the needs of its users. The software should thus be designed to accommodate these changes and modifications as painlessly as possible.The program is designed as a number of objects that interact with each other through well-defined interfaces. This means that all the objects in the program have to be identified and the data flow between them determined. Once an object has been developed and its associated functions have been debugged, it can be used on any subsystem that has similar requirements without any modification. VxWorks by Wind River Systems is a real-time operating system that will be used on the subsystem controllers. This UNIX-like operating system will allow multiple tasks to run concurrently while maintaining their priority schemes. This means that the task with the highest priority will execute whenever it needs to, while other lower priority tasks will be put on hold. VxWorks also allows the user to log in from remote locations and interact with tasks running on the system.The software development environment will consist of a product called Object Center from Centerline Software, Inc. This product is hosted on a Sun Sparc Station and provides an intuitive user-friendly environment to develop, debug, and document C+ code. Subsystem controller. RisksThe technical risks associated with the successful completion of the subsystem design and integration are not significant. The areas that would be of most concern would be the development of low-level device drivers to control various pieces of hardware. In most cases this should not be necessary, as it is anticipated that we will be able to purchase most of these drivers with the associated equipment.翻譯計算機控制W. Daley & R. CareyGTRI, 亞特蘭大喬治亞技術(shù)協(xié)會，GA30332簡介本章討論系統(tǒng)以及子系統(tǒng)控制計算機。系統(tǒng)控制計算機的目的是，提供單一的機器，它能夠允許用戶操作控制 CHARA 排列。這一部計算機將會允許用戶獲得龐大的數(shù)據(jù)，進行光學(xué)排列，同時進行診斷，并且負(fù)責(zé)和比較偏遠(yuǎn)的用戶接口以使他們有機會接觸系統(tǒng)。另一方面，子系統(tǒng)控制計算機，通信于系統(tǒng)控制計算機以及每一個子系統(tǒng)，控制馬達(dá)，螺線管，等等之間，并且將每一個子系統(tǒng)的狀態(tài)報告?zhèn)魉徒o中央計算機。. 系統(tǒng)控制計算機U.2.1. 功能性系統(tǒng)將會提供具有以下功能的一個圖形用戶界面：-直接地與每個子要系統(tǒng)溝通；-將所有子系統(tǒng)視為一個整體進行控制；-獲取并存儲數(shù)據(jù)；-圖解式地顯示光學(xué)的狀態(tài)；-顯示環(huán)境狀況；-顯示任何子系統(tǒng)的錯誤情況；-控制個別望遠(yuǎn)鏡和所有子系統(tǒng)。U2.2 要求系統(tǒng)計算機需要：-能同時運行多個任務(wù)；-和其他計算機共享文件信息；-向子系統(tǒng)傳達(dá)簡單的指令和數(shù)據(jù)；-監(jiān)視并記錄子系統(tǒng)的實時控制信息；-提供英特網(wǎng)通路給遙遠(yuǎn)的用戶；-提供可靠的和可維持的軟件。 圖 U.1 通信和控制信號. 設(shè)計 硬件系統(tǒng)控制計算機選擇（SUN）微系統(tǒng) SPARC 10SUN公司的工作站系統(tǒng)。這部機器使用UNIX的基于Solaris 1.1 操作系統(tǒng)，它允許多用戶注銷和多程序的同時運行。SPARC 10支持一個以太網(wǎng)接口用于向個別子系統(tǒng)傳送簡單的指令和數(shù)據(jù)。這一個網(wǎng)絡(luò)也用來矯正和系統(tǒng)問題解析。操作系統(tǒng)支持將會用來在各種不同的子系統(tǒng)之間轉(zhuǎn)移文件的網(wǎng)絡(luò)文件系統(tǒng) (NFS)。工作站裝有復(fù)制存儲卡，它通過光纖與安裝在子系統(tǒng)計算機中的復(fù)制存儲卡連接。這種實時復(fù)制共享存儲系統(tǒng)，能夠在最小的申請-應(yīng)用傳輸延時內(nèi)，以高達(dá)150Mbits/s的速度連接到計算機。這種網(wǎng)絡(luò)允許系統(tǒng)控制計算機，通過觀察位于復(fù)制存儲卡的局部存儲器，監(jiān)視位于個別子系統(tǒng)中的控制變量的狀態(tài)。通過光纖網(wǎng)絡(luò)，系統(tǒng)控制計算機將產(chǎn)生的一個TTL時鐘分配到所有的子系統(tǒng)。時鐘用來使所有的控制器同步工作，從而保證系統(tǒng)操作的穩(wěn)定性。系統(tǒng)計算機和子系統(tǒng)的連接如圖U.1所示。U2.3.2 軟件我們用C+語言開發(fā)此軟件，它支持對象定位的軟件設(shè)計和執(zhí)行。使用對象定位程序（圖U.2）能夠保證軟件開發(fā)的可靠性和可維持性。在任何代碼寫入之前必須考慮到總系統(tǒng)的功能性和設(shè)計本身，必須這樣使用對象定位程序。程序設(shè)計有許多對象，這些對象通過明確定義的接口相互聯(lián)系。這就意味著，必須要識別程序中的所有對象，同時這由它們之間的數(shù)據(jù)流決定。一旦開發(fā)了一個對象，并且調(diào)試了它的聯(lián)想機能，那么它就可以無需任何修改地應(yīng)用在那些具有相似要求的子系統(tǒng)上。也就是說，在不連接其它系統(tǒng)的情況下可以更新目標(biāo)對象。 圖U.2 軟件對象設(shè)計可以運用X Windows標(biāo)準(zhǔn)和圖形裝飾工具組開發(fā)圖形用戶界面（GUI）。圖形用戶界面（GUI）支持具有彈出窗口，滾動條，按鈕，列表框，編輯框等等的窗口小部件。這些窗口部件允許用戶通過鍵盤，鼠標(biāo)與圖形用戶界面進行通信。圖形用戶界面允許對象如鏡子，望遠(yuǎn)鏡，光路能夠形象地在屏幕上顯示出來。用戶可以通過點擊對象上的鼠標(biāo)，以及拖拽到一個新的位置來實現(xiàn)對對象的操作。比如，這將會在插入或把一面鏡子從光學(xué)的路徑上移開方面非常有用。U.2.4 風(fēng)險與計劃的成功完成這一個方面有關(guān)的技術(shù)上的危險會是最小的。U.2.5 選項基于系統(tǒng)控制計算機的很多部分的選項有很多，但是在這里我們只討論其中的一些可能性。系統(tǒng)計算機也可能是另外類型的工作站，象HP，IBM，Silicon Graphics，DEC等，但是他們每一個在網(wǎng)絡(luò)，處理速度，硬件和軟件有效性上都有局限性。SUN工作站在這個問題上提供了最為有效的解決途徑。我們可以使用IBM 485計算機，但是它要成功的完成系統(tǒng)控制計算機的話就必須運行一個多用戶，多任務(wù)操作系統(tǒng)。目前，在IBM 486s上運行的能夠滿足這些要求的操作系統(tǒng)有UNIX，Windows NT。SUNs UNIX在個人計算機上的運行效果比其它UNIX要好的多，況且Windows NT的效果還有待證明。復(fù)制存儲網(wǎng)絡(luò)可能會被象令牌網(wǎng)網(wǎng)絡(luò)這樣的確定性的網(wǎng)絡(luò)取代。這個解決方案要求軟件開發(fā)到：能夠處理在不同的子系統(tǒng)之間交換的信息。盡管這個任務(wù)不可能實現(xiàn)，它將系統(tǒng)軟件設(shè)計的復(fù)雜性提高了一個水平，使得開發(fā)十分不易，維護更加困難。鑒于C語言比較有名并且應(yīng)用廣泛，所以選擇C語言作為開發(fā)語言。盡管C語言的功能十分強大，它并不要求開發(fā)者寫出可以維持的軟件。相反，它使得軟件開發(fā)者要保證系統(tǒng)中的眾多模塊之間沒有沖突。在很大的軟件工程當(dāng)中，如CHARA Array，開發(fā)者要花很大功夫，并且要用到很多文件，以保證模塊之間沒有副作用產(chǎn)生。在C語言中，也沒有明確定義的機制來保證，在一個模塊中開發(fā)中的代碼能夠在另一個模塊中也能正常使用。從另外一方面講，C+，通過隱藏數(shù)據(jù)以及程序其他執(zhí)行功能來消除副作用。這能確保只有使用恰當(dāng)程序的人員才能操作數(shù)據(jù)，因此，消除大多數(shù)情況下產(chǎn)生的不利的副作用簡化了系統(tǒng)的完整性。U.3 采集數(shù)據(jù)計算機當(dāng)系統(tǒng)控制計算機負(fù)責(zé)排列的實時控制方面，那么，數(shù)據(jù)分段和約簡就要用到另外一個系統(tǒng)。這個系統(tǒng)用于將邊緣跟蹤和成像系統(tǒng)產(chǎn)生的數(shù)據(jù)分段，對能見度產(chǎn)生實時評估，并且允許有權(quán)使用許多排列子系統(tǒng)，但不是控制。計算機允許操作者或者訪問天文學(xué)家檢測飛行體上的數(shù)據(jù)，并且無需妨礙排列操作就可以進行原始數(shù)據(jù)約簡。連接到局域網(wǎng)的一個Sun Sparc或者等價的UNIX機器正好適合這個工作。U.4 子系統(tǒng)控制計算機U.4.1 功能性子系統(tǒng)提供以下功能：-同每個子系統(tǒng)和中央控制器進行通訊；-控制必要的控制設(shè)備（馬達(dá)，螺線管等等）；-將當(dāng)前子系統(tǒng)狀態(tài)傳給中央控制器；-將錯誤情況傳送給中央控制器；U.4.2 要求子系統(tǒng)計算機必須：-同時運行多個任務(wù)；-能夠?qū)ο到y(tǒng)控制計算機發(fā)出的簡單命令作出反應(yīng)；-