《【 畢業(yè)設(shè)計(jì) 畢業(yè)論文】自動(dòng)化專(zhuān)業(yè) 計(jì)算機(jī) 畢業(yè)論文 文獻(xiàn)翻譯 中英文》由會(huì)員分享，可在線閱讀，更多相關(guān)《【 畢業(yè)設(shè)計(jì) 畢業(yè)論文】自動(dòng)化專(zhuān)業(yè) 計(jì)算機(jī) 畢業(yè)論文 文獻(xiàn)翻譯 中英文（18頁(yè)珍藏版）》請(qǐng)?jiān)谘b配圖網(wǎng)上搜索。

1、外文原文 Computer Control W. Daley & R. Carey GTRI, Georgia Institute of Technology, Atlanta, GA 30332 INTRODUCTION This 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 t

2、he 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 be

3、tween 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 COMPUTER U.2.1 Functionality The system will provide a graphical user interface with the fol

4、lowing 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

5、 all subsystems U.2.2. Requirements The 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 ac

6、cess for remote users _ Provide reliable and maintainable software . Communication and control signals Design Hardware A SUN Microsystems SPARC 10 was chosen for the system control computer. This machine uses the UNIX based Solaris 1.1 operating system which will al

7、low 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 sys

8、tem. 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 subsy

9、stem 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 individ

10、ual 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 wh

11、ich 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.

12、 . Software object design. Software The 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 ma

13、intainable. 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 an

14、d 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 sys

15、tem. 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 mo

16、use 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

17、 optical path, for example. Risks The technical risks associated with the successful completion of this aspect of the project would be minimal. Options There are many options to the various parts of the system control computer but only a few possibilities will be discussed here. The system

18、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

19、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 UNI

20、X 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 no

21、t 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

22、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 develop

23、ers, 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 implementati

24、ons 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 COMPUTER While the system control computer is responsi

25、ble 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

26、 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 jo

27、b. SUBSYSTEM CONTROL COMPUTER Functionality The 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 _ Trans

28、mit error conditions to the central controller Requirements The 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 condition

29、s _ Provide reliable and maintainable software Design Methodology There 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

30、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

31、. 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 d

32、esign 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. Als

33、o, 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

34、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 sys

35、tem. 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 s

36、ubsystem 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 _ VXI

37、 Table 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 Support Excellent CPU cards have Ethernet ports built in, and software drivers supplied

38、 Very Good Ethernet cards and drivers are available from many vendors Good: Ethernet cards and drivers are available from a few vendors Fair: Ethernet cards and drivers are available from one vendor Poor: No Ethernet cards or drivers available _ DSP Support Excell

39、ent: Many different vendors with very high speed computational boards Very Good: Many different vendors Good: A few different vendors Fair: One vendor Poor: No vendors _ A/D, D/A, & Digital I/O Support Excellent: Many different vendors with many different boards Very G

40、ood: Many different vendors Good: A few different vendors Fair: One vendor Poor: No vendors _ Motor Controller Support Excellent: Many different vendors with many different boards Very Good: Many different vendors Good: A few different vendors Fair: One ve

41、ndor Poor: No vendors _ Real-Time O/S Support Excellent: BUS supports many different processors and O/Ss Very Good: BUS supports many different O/Ss Good: BUS supports a few different O/Ss Fair: BUS supports one O/S Poor: None _ Cost Excellent: Many low-cost boards

42、and software (<$500) Very Good: Few low-cost boards and software Good: Many medium-cost boards and software ($500 { $1500) Fair: Few medium-cost boards and software Poor: Only high-cost boards and software (>$1500) _ Reliability Excellent: Very high MTBF, very good mechan

43、ical support for cards Very Good: High MTBF, good mechanical support for cards Good: Average MTBF, average mechanical support for cards Fair: Low MTBF, poor mechanical support for cards Poor: Very low MTBF, very poor mechanical support for cards Assigning a scale of 1 ~ 5, w

44、ith 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 avail

45、able software tools and development environment were not taken into consideration but will be discussed in a later section. Hardware A 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 wil

46、l have the following specification: 25 MHz MC68040 microprocessor with 8KB of Cache TABLE U.2 Rating of available BUS architectures _ 8 MBytes of DRAM _ Ethernet interface _ Sockets for on-board ROM/EPROM The base system will also contain a replicated shared-memory fiber-optic network

47、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 availab

48、le 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

49、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 cle

50、ar 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 s

51、ubsystem 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. Software The software will be developed in the C++ langua

52、ge, 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

53、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

54、. 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 Wi

55、nd 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 t

56、o, 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 hos

57、ted on a Sun Sparc Station and provides an intuitive user-friendly environment to develop, debug, and document C++ code. . Subsystem controller. Risks The technical risks associated with the successful completion of the subsystem design and integration are not significant. The areas that wo

58、uld 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. 翻譯 計(jì)算機(jī)控制 W. Daley & R. Carey G

59、TRI, 亞特蘭大喬治亞技術(shù)協(xié)會(huì)，GA30332 ．簡(jiǎn)介 本章討論系統(tǒng)以及子系統(tǒng)控制計(jì)算機(jī)。系統(tǒng)控制計(jì)算機(jī)的目的是，提供單一的機(jī)器，它能夠允許用戶(hù)操作控制 CHARA 排列。這一部計(jì)算機(jī)將會(huì)允許用戶(hù)獲得龐大的數(shù)據(jù)，進(jìn)行光學(xué)排列，同時(shí)進(jìn)行診斷，并且負(fù)責(zé)和比較偏遠(yuǎn)的用戶(hù)接口以使他們有機(jī)會(huì)接觸系統(tǒng)。另一方面，子系統(tǒng)控制計(jì)算機(jī)，通信于系統(tǒng)控制計(jì)算機(jī)以及每一個(gè)子系統(tǒng)，控制馬達(dá)，螺線管，等等之間，并且將每一個(gè)子系統(tǒng)的狀態(tài)報(bào)告?zhèn)魉徒o中央計(jì)算機(jī)。 . 系統(tǒng)控制計(jì)算機(jī) U.2.1. 功能性 系統(tǒng)將會(huì)提供具有以下功能的一個(gè)圖形用戶(hù)界面： -直接地與每個(gè)子要系統(tǒng)溝通； -將所有子系統(tǒng)視為一個(gè)整體進(jìn)

60、行控制； -獲取并存儲(chǔ)數(shù)據(jù)； -圖解式地顯示光學(xué)的狀態(tài)； -顯示環(huán)境狀況； -顯示任何子系統(tǒng)的錯(cuò)誤情況； -控制個(gè)別望遠(yuǎn)鏡和所有子系統(tǒng)。 U．2.2 要求 系統(tǒng)計(jì)算機(jī)需要： -能同時(shí)運(yùn)行多個(gè)任務(wù)； -和其他計(jì)算機(jī)共享文件信息； -向子系統(tǒng)傳達(dá)簡(jiǎn)單的指令和數(shù)據(jù)； -監(jiān)視并記錄子系統(tǒng)的實(shí)時(shí)控制信息； -提供英特網(wǎng)通路給遙遠(yuǎn)的用戶(hù)； -提供可靠的和可維持的軟件。 圖 U.1 通信和控制信號(hào) . 設(shè)計(jì) 硬件 系統(tǒng)控制計(jì)算機(jī)選擇（SUN）微系統(tǒng) SPARC 10[SUN公司的工作站系統(tǒng)]。這部機(jī)器使用UNI

61、X的基于Solaris 1.1 操作系統(tǒng)，它允許多用戶(hù)注銷(xiāo)和多程序的同時(shí)運(yùn)行。SPARC 10支持一個(gè)以太網(wǎng)接口——用于向個(gè)別子系統(tǒng)傳送簡(jiǎn)單的指令和數(shù)據(jù)。這一個(gè)網(wǎng)絡(luò)也用來(lái)矯正和系統(tǒng)問(wèn)題解析。操作系統(tǒng)支持將會(huì)用來(lái)在各種不同的子系統(tǒng)之間轉(zhuǎn)移文件的網(wǎng)絡(luò)文件系統(tǒng) (NFS)。 工作站裝有復(fù)制存儲(chǔ)卡，它通過(guò)光纖與安裝在子系統(tǒng)計(jì)算機(jī)中的復(fù)制存儲(chǔ)卡連接。這種實(shí)時(shí)復(fù)制共享存儲(chǔ)系統(tǒng)，能夠在最小的申請(qǐng)-應(yīng)用傳輸延時(shí)內(nèi)，以高達(dá)150Mbits/s的速度連接到計(jì)算機(jī)。這種網(wǎng)絡(luò)允許系統(tǒng)控制計(jì)算機(jī)，通過(guò)觀察位于復(fù)制存儲(chǔ)卡的局部存儲(chǔ)器，監(jiān)視位于個(gè)別子系統(tǒng)中的控制變量的狀態(tài)。通過(guò)光纖網(wǎng)絡(luò)，系統(tǒng)控制計(jì)算機(jī)將產(chǎn)生的一個(gè)TTL時(shí)

62、鐘分配到所有的子系統(tǒng)。時(shí)鐘用來(lái)使所有的控制器同步工作，從而保證系統(tǒng)操作的穩(wěn)定性。系統(tǒng)計(jì)算機(jī)和子系統(tǒng)的連接如圖U.1所示。 U2.3.2 軟件 我們用C++語(yǔ)言開(kāi)發(fā)此軟件，它支持對(duì)象定位的軟件設(shè)計(jì)和執(zhí)行。使用對(duì)象定位程序（圖U.2）能夠保證軟件開(kāi)發(fā)的可靠性和可維持性。在任何代碼寫(xiě)入之前必須考慮到總系統(tǒng)的功能性和設(shè)計(jì)本身，必須這樣使用對(duì)象定位程序。程序設(shè)計(jì)有許多對(duì)象，這些對(duì)象通過(guò)明確定義的接口相互聯(lián)系。這就意味著，必須要識(shí)別程序中的所有對(duì)象，同時(shí)這由它們之間的數(shù)據(jù)流決定。一旦開(kāi)發(fā)了一個(gè)對(duì)象，并且調(diào)試了它的聯(lián)想機(jī)能，那么它就可以無(wú)需任何修改地應(yīng)用在那些具有相似要求的子系統(tǒng)上。也就是說(shuō)，在不連接

63、其它系統(tǒng)的情況下可以更新目標(biāo)對(duì)象。 圖U.2 軟件對(duì)象設(shè)計(jì) 可以運(yùn)用X Windows標(biāo)準(zhǔn)和圖形裝飾工具組開(kāi)發(fā)圖形用戶(hù)界面（GUI）。圖形用戶(hù)界面（GUI）支持具有彈出窗口，滾動(dòng)條，按鈕，列表框，編輯框等等的窗口小部件。這些窗口部件允許用戶(hù)通過(guò)鍵盤(pán)，鼠標(biāo)與圖形用戶(hù)界面進(jìn)行通信。圖形用戶(hù)界面允許對(duì)象如鏡子，望遠(yuǎn)鏡，光路能夠形象地在屏幕上顯示出來(lái)。用戶(hù)可以通過(guò)點(diǎn)擊對(duì)象上的鼠標(biāo)，以及拖拽到一個(gè)新的位置來(lái)實(shí)現(xiàn)對(duì)對(duì)象的操作。比如，這將會(huì)在插入或把一面鏡子從光學(xué)的路徑上移開(kāi)方面非常有用。 U.2.4 風(fēng)險(xiǎn) 與計(jì)劃的成功完成這一個(gè)方面有關(guān)的技術(shù)上

64、的危險(xiǎn)會(huì)是最小的。 U.2.5 選項(xiàng) 基于系統(tǒng)控制計(jì)算機(jī)的很多部分的選項(xiàng)有很多，但是在這里我們只討論其中的一些可能性。 系統(tǒng)計(jì)算機(jī)也可能是另外類(lèi)型的工作站，象HP，IBM，Silicon Graphics，DEC等，但是他們每一個(gè)在網(wǎng)絡(luò)，處理速度，硬件和軟件有效性上都有局限性。SUN工作站在這個(gè)問(wèn)題上提供了最為有效的解決途徑。我們可以使用IBM 485計(jì)算機(jī)，但是它要成功的完成系統(tǒng)控制計(jì)算機(jī)的話就必須運(yùn)行一個(gè)多用戶(hù)，多任務(wù)操作系統(tǒng)。目前，在IBM 486s上運(yùn)行的能夠滿(mǎn)足這些要求的操作系統(tǒng)有UNIX，Windows NT。SUN’s UNIX在個(gè)人計(jì)算機(jī)上的運(yùn)行效果比其它UNIX要好的

65、多，況且Windows NT的效果還有待證明。 復(fù)制存儲(chǔ)網(wǎng)絡(luò)可能會(huì)被象令牌網(wǎng)網(wǎng)絡(luò)這樣的確定性的網(wǎng)絡(luò)取代。這個(gè)解決方案要求軟件開(kāi)發(fā)到：能夠處理在不同的子系統(tǒng)之間交換的信息。盡管這個(gè)任務(wù)不可能實(shí)現(xiàn)，它將系統(tǒng)軟件設(shè)計(jì)的復(fù)雜性提高了一個(gè)水平，使得開(kāi)發(fā)十分不易，維護(hù)更加困難。 鑒于C語(yǔ)言比較有名并且應(yīng)用廣泛，所以選擇C語(yǔ)言作為開(kāi)發(fā)語(yǔ)言。盡管C語(yǔ)言的功能十分強(qiáng)大，它并不要求開(kāi)發(fā)者寫(xiě)出可以維持的軟件。相反，它使得軟件開(kāi)發(fā)者要保證系統(tǒng)中的眾多模塊之間沒(méi)有沖突。在很大的軟件工程當(dāng)中，如CHARA Array，開(kāi)發(fā)者要花很大功夫，并且要用到很多文件，以保證模塊之間沒(méi)有副作用產(chǎn)生。在C語(yǔ)言中，也沒(méi)有明確定義的機(jī)

66、制來(lái)保證，在一個(gè)模塊中開(kāi)發(fā)中的代碼能夠在另一個(gè)模塊中也能正常使用。從另外一方面講，C++，通過(guò)隱藏?cái)?shù)據(jù)以及程序其他執(zhí)行功能來(lái)消除副作用。這能確保只有使用恰當(dāng)程序的人員才能操作數(shù)據(jù)，因此，消除大多數(shù)情況下產(chǎn)生的不利的副作用簡(jiǎn)化了系統(tǒng)的完整性。 U.3 采集數(shù)據(jù)計(jì)算機(jī) 當(dāng)系統(tǒng)控制計(jì)算機(jī)負(fù)責(zé)排列的實(shí)時(shí)控制方面，那么，數(shù)據(jù)分段和約簡(jiǎn)就要用到另外一個(gè)系統(tǒng)。這個(gè)系統(tǒng)用于將邊緣跟蹤和成像系統(tǒng)產(chǎn)生的數(shù)據(jù)分段，對(duì)能見(jiàn)度產(chǎn)生實(shí)時(shí)評(píng)估，并且允許有權(quán)使用許多排列子系統(tǒng)，但不是控制。計(jì)算機(jī)允許操作者或者訪問(wèn)天文學(xué)家檢測(cè)飛行體上的數(shù)據(jù)，并且無(wú)需妨礙排列操作就可以進(jìn)行原始數(shù)據(jù)約簡(jiǎn)。連接到局域網(wǎng)的一個(gè)Sun Sparc或者等價(jià)的UNIX機(jī)器正好適合這個(gè)工作。 U.4 子系統(tǒng)控制計(jì)算機(jī) U.4.1 功能性 子系統(tǒng)提供以下功能： -同每個(gè)子系統(tǒng)和中央控制器進(jìn)行通訊； -控制必要的控制設(shè)備（馬達(dá)，螺線管等等）； -將當(dāng)前子系統(tǒng)狀態(tài)傳給中央控制器； -將錯(cuò)誤情況傳送給中央控制器； U.4.2 要求 子系統(tǒng)計(jì)算機(jī)必須： -同時(shí)運(yùn)行多個(gè)任務(wù)； -能夠?qū)ο到y(tǒng)控制計(jì)算機(jī)發(fā)出的簡(jiǎn)單命令作出反應(yīng)； -