畢業(yè)設(shè)計(jì)的英文翻譯----開放式控制器體系結(jié)構(gòu) - 過去，現(xiàn)在和未來

1、<p>　　Open Controller Architecture - Past, Present and Future</p><p>　　Gunter Pritschow (Co-ordinator), Yusuf Altintas, Francesco Jovane, Yoram Koren, </p><p>　　Mamoru Mitsuishi, Shozo Taka

2、ta, Hendrik van Brussel, Manfred Weck, Kazuo Yamazaki</p><p><b>　　Abstract</b></p><p>　　Open Control Systems are the key enabler for the realization of modular and re-configurable ma

3、nufacturing systems. The large number of special purpose machines and the high level of automation have led to an increasing importance of open control systems based on vendor neutral standards. This paper gives an overv

4、iew on the past, present and future of Open Controller Architecture. After reflecting on the different criteria, categories and characteristics of open controllers in general, the CNC pr</p><p>　　Keywords: O

5、pen architecture control, CNC, Machine tool</p><p>　　1 INTRODUCTION</p><p>　　Open Architecture Control (OAC) is a well known term in the field of machine control. Since the early nineties severa

6、l initiatives world-wide have worked on concepts for enabling control vendors, machine tool builders and end-users to benefit more from flexible and agile production facilities. The main aim was the easy implementation a

7、nd integration of customer-specific controls by means of open interfaces and configuration methods in a vendor-neutral, standardized environment [13][19].</p><p>　　The availability and broad acceptance of su

8、ch systems result in reduced costs and increased flexibility. Software can be reused and user-specific algorithms or applications can be integrated. Users can design their controls according to a given configuration. Thi

9、s trend was forced both by the increasing number of special purpose machines with a high level of automation and the increasing development costs for software (Figure 1).</p><p>　　Figure 1: CNC Hardware and

10、software -Actual trend existing</p><p>　　In the past the CNC market was dominated by heterogeneous, device-oriented systems with proprietary hardware and software components. The tight coupling of applicatio

11、n software, system software and hardware led to very complex and inflexible systems. Great efforts were made to maintain and further develop the products according to new market requirements. Modern CNC approaches, which

12、 comprise extensive functionality to achieve a high quality and flexibility of machining results combined with a r</p><p>　　Figure 2: PC-based, software-oriented Control Systems </p><p>　　There

13、are a lot of benefits for suppliers and users of open control systems (Figure 3) [7]. CNC designers and academics benefit from a high degree of openness covering also the internal interfaces of the CNC. For CNC users the

14、 external openness is much more important. It provides the methods and utilities for integrating user-specific applications into existing controls and for adapting to user-specific requirements, e.g. adaptable user inter

15、faces or collection of machine and production data. Th</p><p>　　2 STATE OF THE ART</p><p>　　2.1 Control Systems and their interfaces </p><p>　　Controls are highly sophisticated syst

16、ems due to very strict requirements regarding real-time and reliability. For controlling the complexity of these systems hardware and software interfaces are an essential means. The interfaces of control systems can be d

17、ivided into two groups-external and internal interfaces (Figure4). </p><p>　　External Interfaces </p><p>　　These interfaces connect the control system to superior units, to subordinate units and

18、 to the user. They can be divided into programming interfaces and communication interfaces. NC and PLC programming interfaces are harmonized by national or international standards, such as RS-274, DIN 66025 or IEC 61131-

19、3. Communication interfaces are also strongly influenced by standards. Fieldbus systems like SERCOS, Profibus or DeviceNet are used as the interface to drives and 110s. LAN (Local Area Network)</p><p>　　Inte

20、rnal Interfaces </p><p>　　Internal interfaces are used for interaction and data- exchange between components that build up the control- system core. An important criterion in this area is the support of real

21、-time mechanisms. To achieve a re-configurable and adaptable control the internal architecture of the control system is based on a platform concept. The main aims are to hide the hardware-specific details from the softwa

22、re components and to establish a defined but flexible way of communication between the software com</p><p>　　2.2 Hardware and software structure of control systems</p><p>　　Figure 5 shows differ

23、ent variants for the hardware structures of control systems. Variant a) shows an analog drives interface with position controller in the control system core. Each module of this structure uses its own processor which lea

24、ds to a large variety of vendor-specific hardware. Combining modules leads to a significant reduction of the number of processors. Variant b) shows intelligent digital drives with integrated control functionality, which

25、result from higher capacity, miniaturiz</p><p>　　2.3 Market overview </p><p>　　The controls available in the market provide different levels of openness according to the criteria shown in Figure

26、 6. An important criterion is the use of a standardized computing platform (i.e. hardware, operating system and middleware) as an environment to execute the HMI and CNC software. Besides this, the connectivity of the CNC

27、 to upper and lower factory levels must be guaranteed. Application Programming Interfaces (API) are used to integrate third party software in the CNC products. Altho</p><p>　　Figure 7 gives an overview of th

28、e characteristics of today’s control systems regarding the degree of openness.</p><p>　　Although many control systems provide open interfaces for software integration (e.g. OPC) there is still no common defi

29、nition of data which is passed back and forth via the programming interface. Therefore, the control systems available on the market today do not implicitly support “plug-and-play” features. To improve this situation, the

30、 fieldbus systems can serve as a role model (see Figure 8). The variety of different fieldbus systems has led to the broad consensus that harmonizing the applica</p><p>　　For example, the SERCOS interface st

31、andard (IEC61491) for the cyclic and deterministic communication between CNC and drives has defined the semantics for approx. 400 parameters describing drive and control functions which are used by the devices of differe

32、nt vendors.</p><p>　　3 DEFINITIONS AND CATEGORIES OF OPENNESS</p><p>　　3.1 Definitions </p><p>　　The “Technical Committee of Open Systems” of IEEE defines an open system as follows:

33、 “An open system provides capabilities that enable properly implemented applications to run on a variety of platforms from multiple vendors, interoperate with other system applications and present a consistent style of i

34、nteraction with the user” (IEEE 1003.0). </p><p>　　To estimate the openness of a controller the following criteria can be applied (Figure 9): </p><p>　　Portability. Application modules (AM) can

35、be used on different platforms without any changes, while maintaining their capabilities. </p><p>　　Extendibility. A varying number of AM can run on a platform without any conflicts. </p><p>　　I

36、nferoperability. AM work together in a consistent manner and can interchange data in a defined way. </p><p>　　Scalability. Depending on the requirements of the user, functionality of the AM and performance a

37、nd size of the hardware can be adapted. </p><p>　　To fulfill the requirements of the IEEE-definition and these criteria of openness, an open control system must be: </p><p>　　vendor neutral. Thi

38、s guarantees independence of single proprietary interests. </p><p>　　consensus-driven. It is controlled by a group of vendors and users (usually in the form of a user group or an interested group).</p>

39、<p>　　standards-based. This ensures a wide distribution in the form of standards (national/international standards or de-facto standards). </p><p>　　freely available. It is free of charge to any inte

40、rested party.</p><p>　　3.2 Categories of Open Control Systems </p><p>　　If we speak of openness in control systems, the following categories can be identified (Figure 10): </p><p>　

41、　Open HMl: The openness is restricted to the non-real-time part of the control system. Adaptations can be made in user oriented applications.</p><p>　　Kernel with restricted openness: The control kernel has

42、a fixed topology, but offers interfaces to insert user-specific filters even for real-time functions. </p><p>　　Open Control System: The topology of the control kernel depends on the process. It offers inter

43、changeability, scalability, portability and interoperability. </p><p>　　Open control systems that are available today mostly offer the possibility for modifications in the non-real-time part in a fixed softw

44、are topology. They lack the necessary flexibility and are not based on vendor-neutral standards.</p><p>　　3.3 Requirements </p><p>　　A vendor-neutral open control system can only be realized if

45、the control functionality is subdivided in functional units and if well-defined interfaces between these units are specified (Figure 11). Therefore modularity can be identified as the key for an open system architecture

46、. In determining the module complexity there is an obvious trade-off between the degree of openness and the cost of integration [6]. Smaller modules provide a higher level of openness and more options, but increase the &

47、lt;/p><p>　　Combining modules in the manner of “mix-and-match’’ requires a comprehensive set of standard Application Programming Interfaces (APIs). For vendor-neutral open control systems the interfaces need to

48、 be standardized and broadly accepted. Due to the complexity of such modular systems the definition of a system architecture is recommendable and helpful. This leads to the introduction of so-called system platforms (Fig

49、ure 12). These platforms encapsulate the specifics of a computing system by absorb</p><p>　　Due to the possibility to “mix-and-match’’ modules via standardized interfaces the quality of the overall system is

50、 determined by the degree of the interoperability between the single modules (see Section 5).</p><p>　　4 SYSTEMS ON THE WAY TO THE MARKET </p><p>　　4.1 Major international activities </p>

51、<p>　　OSEC (Japan) </p><p>　　The OSE (Open System Environment for Manufacturing) consortium was established in December 1994. Three project phases were carried out until March 1999 [1][2][3]. The OSEC

52、Architecture was intended to provide end users, machine makers, control vendors, software vendors, system integrators, etc. a standard platform for industrial machine controllers, with which they can add their own unique

53、 values to the industrial machines, and hence promote the technical and commercial development of the indust</p><p>　　JOP (Japan) </p><p>　　In parallel to the OSE consortium activities, MSTC for

54、med the Open-Controller Technical Committee (OC- TC) from 1996 to 2000, under the umbrella of JOP (Japanese Open Promotion Group). The objectives of OC-TC were to provide the opportunities for various companies to discus

55、s and work together on the standardization of open controller technologies. The OC- TC was also expected to act as liaison between domestic and international activities in this field. OC-TC was participated by approximat

56、ely 50</p><p>　　OMAC (USA) </p><p>　　The Open Modular Architecture Controllers (OMAC) Users Group is an industry forum to advance the state of controller technology [l0]. An effort was undertake

57、n within OMAC to define API specification for eventual submittal to an established standards body. The OMAC API adopted a component-based approach to achieve plug-and-play modularization, using interface classes to speci

58、fy the API [11]. For distributed communication, component-based technology uses proxy agents to handle method invocations t</p><p>　　To integrate components, a framework is necessary to formalize the collabo

59、rations and other life cycle aspects in which components operate. The OMAC API uses Microsoft Component Object Model (COM) as the initial framework in which to develop components, with the expected benefit that control v

60、endors could then concentrate on application-specific improvements that define their strategic market-share - as opposed to spending valuable programming resources reinventing and maintaining software “plum</p>&l

61、t;p>　　Figure 15 illustrates a sketch of OMAC API controller functionality. The HMI module is responsible for human interaction with a controller including presenting data, handing commands, and monitoring events and i

62、n the OMAC API “mirrors” the actual controller with references to all the major modules and components via proxy agents. The Task Coordinator module is responsible for sequencing operations and coordinating the various m

63、odules in the system based on programmable Tasks. The Task Coordinato</p><p>　　OSACA (Europe)</p><p>　　In Europe the ESPRIT project OSACA (Open System Architecture for Controls within Automation

64、 Systems) was initiated in 1992 with the aim to unite European interests and to create a vendor-neutral standard for open control systems[9][16].It was supported by major European control vendor and machine tool builders

65、. OSACA reached a mature state already in April 1996 having at its disposal a stable set of specifications and a tested pool for system software. Based on these results, several application</p><p>　　The basi

66、c technical approach of the OSACA architecture is the hierarchical decomposition of control functionality into so-called functional units (Figure 16).For each of these functional units (e.g. motion control, motion contro

67、l manager, axes control, logic control, etc.) the interfaces are specified by applying object-oriented information models. This technique is similar to the approach of MAP/MMS but with a limited and manageable number of

68、object classes.</p><p>　　The data interface consists of several variable objects that support the read and/or write access to data structure(data flow).The data can be of a simple type or of a complex type(a

69、rray, structure, union).By using formal templates(Figure17) all the characteristics of a single interface object are specified. These elements cover the name (e.g, “mc-active-feed-override”), the type (e.g. UNS32: 32-bit

70、 unsigned value), the scaling (e.g. 0.l%),the range and the access rights (read only, to all the</p><p>　　開放式控制器體系結(jié)構(gòu) - 過去，現(xiàn)在和未來 </p><p><b>　　摘要</b></p><p>　　開放式控制系統(tǒng)是用于

71、模塊化和可重新配置制造系統(tǒng)實(shí)現(xiàn)的關(guān)鍵推動者。.特殊用途的機(jī)器和自動化程度高，導(dǎo)致大量的開放式控制系統(tǒng)的供應(yīng)商中立的標(biāo)準(zhǔn)為基礎(chǔ)的重要性與日俱增。本文給出了一個(gè)概述了過去，現(xiàn)在和未來的開放式控制器體系結(jié)構(gòu)。經(jīng)過對不同的標(biāo)準(zhǔn)，分類和一般開放式控制器的特點(diǎn)，反映在市場上的數(shù)控產(chǎn)品進(jìn)行評估和對在歐洲，北美和日本的全球性研究活動概述給定。隨后，努力協(xié)調(diào)不同的結(jié)果，以便在將來建立一個(gè)共同的全球性標(biāo)準(zhǔn)。由于“混合和匹配”，必須集中注意于開放式控制系統(tǒng)的

72、性質(zhì)來進(jìn)行一致性和互操作性測試。</p><p>　　關(guān)鍵字：開放式結(jié)構(gòu)控制 數(shù)控 機(jī)床</p><p><b>　　1介紹：</b></p><p>　　開放式控制器體系結(jié)構(gòu)長期以來在機(jī)械控制領(lǐng)域是眾所周知的。自九十年代初，世界各地的若干措施一直致力于讓控制供應(yīng)商，機(jī)床廠商和最終使用者從靈活敏捷的生產(chǎn)設(shè)備中獲取更多的利益。主要目的是用于在

73、一個(gè)廠商中立，標(biāo)準(zhǔn)化的環(huán)境中通過開放接口控制和配置方法進(jìn)行易操作和集成的客戶指定控制。這種系統(tǒng)的廣泛接受和使用使得成本降低，靈活性增加。軟件可重復(fù)使用，用戶特定算法和應(yīng)用程序可以集成。用戶根據(jù)給定的控制配置可以自己設(shè)計(jì)控制方法。這種趨勢迫于越來越多的特殊用途的高自動化水平的機(jī)械和越來越多的軟件開發(fā)成本（圖1）。</p><p>　　圖1：數(shù)控硬件和軟件—實(shí)際的發(fā)展趨勢</p><p>　　

74、過去數(shù)控領(lǐng)域的實(shí)際趨勢是由與專有的硬件和軟件組件相結(jié)合的獨(dú)特的設(shè)備導(dǎo)向系統(tǒng)所主導(dǎo)。應(yīng)用軟件，系統(tǒng)軟件和硬件的緊耦合導(dǎo)致系統(tǒng)非常復(fù)雜和靈活性差。為了維護(hù)和更遠(yuǎn)的發(fā)展產(chǎn)品，按照新的市場要求，巨大的措施已經(jīng)被實(shí)施?，F(xiàn)代數(shù)控方法，包括了廣泛的功能來完成一個(gè)高質(zhì)量，靈活的機(jī)械成果，在一個(gè)相同的標(biāo)準(zhǔn)化的環(huán)境下，它與減少處理時(shí)間，利于個(gè)人電腦的措施相結(jié)合（圖2）。由于定義的接口和軟件的平臺，這種結(jié)構(gòu)是軟件導(dǎo)向的、可配置的。開放式控制接口需要不斷整合新

75、的、先進(jìn)的功能到控制系統(tǒng)中去。，而且對于創(chuàng)造可重新配置的制造單元是非常重要的[17]。分拆硬件和軟件可以從半導(dǎo)體產(chǎn)業(yè)和信息技術(shù)產(chǎn)業(yè)縮短的創(chuàng)新周期中獲益。在重利用軟件組件的可能性下，簡單的通過升級硬件平臺，系統(tǒng)的整體性能便增加了。</p><p>　　圖2：基于個(gè)人電腦的，面向軟件的控制系統(tǒng)</p><p>　　對于提供和使用開放式控制系統(tǒng)的人都有很多好處（圖3）[7]。數(shù)控設(shè)計(jì)師和學(xué)者受益

76、于高度開放也包括CNC的內(nèi)部接口。對于數(shù)控裝置的使用者外部的開放性更顯重要。它提供了用于集成專用用戶對現(xiàn)有控制的應(yīng)用，和適應(yīng)專用用戶的要求，例如：適應(yīng)性強(qiáng)的用戶界面或機(jī)器和生產(chǎn)數(shù)據(jù)的收集。外部的開放主要基于內(nèi)部的開放但是有功能上的或者性能上的限制。</p><p><b>　　2 這種技術(shù)現(xiàn)狀</b></p><p>　　2.1控制系統(tǒng)及其接口</p>

77、<p>　　控制是非常復(fù)雜的系統(tǒng),由于非常嚴(yán)格的實(shí)時(shí)的和可靠的需求。為了能控制復(fù)雜的系統(tǒng)，硬件和軟件接口是本質(zhì)的問題?？刂葡到y(tǒng)的接口可以被分為兩類—外部和內(nèi)部接口。（圖4）</p><p><b>　　外部接口</b></p><p>　　這些接口把控制系統(tǒng)連接到上一個(gè)單元、下一個(gè)單元、用戶。它們可以分為編程接口和通信接口。NC和PLC編程接口由國家或國際標(biāo)

78、準(zhǔn)來統(tǒng)一，例如RS- 274，DIN66025或IEC61131-3。</p><p>　　通訊接口也受標(biāo)準(zhǔn)很大程度的影響。現(xiàn)場總線系統(tǒng)像SERCOS，Profibus或DeviceNet是用來作為對驅(qū)動器和110s的接口。局域網(wǎng)（局域網(wǎng)），主要基于以太網(wǎng)和TCP/ LP，的確可以反應(yīng)卓越系統(tǒng)的接口。</p><p><b>　　內(nèi)部接口</b></p>

79、<p>　　內(nèi)部接口主要用于構(gòu)成控制系統(tǒng)核心的組件間的交互和數(shù)據(jù)交換。在這一領(lǐng)域的重要標(biāo)準(zhǔn)是實(shí)時(shí)機(jī)制的支持。為了實(shí)現(xiàn)重新配置以及適應(yīng)的配置，控制系統(tǒng)的內(nèi)部結(jié)構(gòu)基于一個(gè)平臺概念。</p><p>　　主要目的是從軟件組件中隱藏具體硬件細(xì)節(jié)，在軟件組件之間建立一個(gè)定義了的、靈活的方式。一個(gè)應(yīng)用程序編程接口（API）可以確保這些要求。一個(gè)控制系統(tǒng)的整體功能細(xì)分成幾個(gè)部分，通過模塊化軟件定義的API交互組件&

80、lt;/p><p>　　2.2控制系統(tǒng)的硬件和軟件結(jié)構(gòu)</p><p>　　圖5顯示控制系統(tǒng)的硬件結(jié)構(gòu)不同的變化。變化a）顯示的是在控制系統(tǒng)的核心部分帶有位置控制的模擬驅(qū)動接口。這種結(jié)構(gòu)的每個(gè)模塊使用自己的處理器，這導(dǎo)致特定供應(yīng)商提供各種各樣的硬件。結(jié)合模塊導(dǎo)致了處理器的數(shù)量有明顯意義上的減少。變化b）顯示的是在集成控制功能下的智能數(shù)字驅(qū)動，由于高容量、小型化、處理器更高的性能。變化c）顯示的

81、是一個(gè)基于個(gè)人電腦的單個(gè)處理器解決方案，它是在操作系統(tǒng)的實(shí)時(shí)擴(kuò)展下。所有的控制功能在實(shí)時(shí)環(huán)境中就像個(gè)人電腦中的軟件一樣運(yùn)行著。</p><p><b>　　2.3市場概述</b></p><p>　　這些在市場上有用的控制提供了不同層次的開放，按照圖6顯示的標(biāo)準(zhǔn)。一個(gè)重要的標(biāo)準(zhǔn)是標(biāo)準(zhǔn)計(jì)算機(jī)（軟件，操作系統(tǒng)和中間件）環(huán)境作為執(zhí)行HMI和CNC軟件的使用。除此之外，連接的

82、數(shù)控廠上下各級必須得到保證。應(yīng)用程序編程接口（API）是用于集成在數(shù)控產(chǎn)品的第三方軟件。雖然今天的大部分控制系統(tǒng)提供了開放性，這種開放性包括了與操作者相關(guān)的控制功能（人機(jī)交互，HMI），還是有少數(shù)控制系統(tǒng)允許用戶修改他們的低層次的控制算法，來改變機(jī)器相關(guān)的控制功能。</p><p>　　圖7給出了今天的控制系統(tǒng)方面的開放程度特點(diǎn)的概述。</p><p>　　雖然一些控制系統(tǒng)給軟件集成提供了

83、開放的接口（例如OPC），但是通過程序接口的來來回回的數(shù)據(jù)仍然沒有共同的定義。因此，控制系統(tǒng)對目前市場并不隱式支持“插件和播放“的特點(diǎn)。為了改善這種情況，現(xiàn)場總線系統(tǒng)可以作為一個(gè)模型（見圖8）。在各種不同的現(xiàn)場總線系統(tǒng)中，達(dá)成了廣泛的共識，統(tǒng)一了面向應(yīng)用的接口是可取的，為了向用戶隱藏多元性和系統(tǒng)的復(fù)雜性。大多數(shù)現(xiàn)場總線組織已經(jīng)使用所謂的設(shè)備配置文件，以支持不同廠商的設(shè)備互換。</p><p>　　例如，SERCO

84、S接口標(biāo)準(zhǔn)對于數(shù)控和驅(qū)動器之間的循環(huán)和確定性通信（IEC61491）已經(jīng)確定大約的語義。</p><p>　　400參數(shù)描述驅(qū)動和控制，是由不同廠商的設(shè)備使用的功能。</p><p>　　3開放式的定義和種類</p><p><b>　　3.1定義</b></p><p>　　IEEE的“開放系統(tǒng)技術(shù)委員會“定義了一個(gè)開

85、放的系統(tǒng)如下：“一個(gè)開放的系統(tǒng)提供一種能力，使應(yīng)用程序能夠運(yùn)行在多個(gè)供應(yīng)商的平臺上，與其它系統(tǒng)互通應(yīng)用程序，展現(xiàn)與用戶互動的一貫風(fēng)格(IEEE 1003.0)。</p><p>　　為了估計(jì)控制的開放性，下面的標(biāo)準(zhǔn)可以被使用（圖9）：</p><p>　　可移植性: 應(yīng)用程序模塊(AM)可以不經(jīng)過任何變化就能應(yīng)用在不同平臺上，同時(shí)保持自己的能力。</p><p>　

86、　可擴(kuò)展性：各種不同的應(yīng)用模塊可以無沖突的在平臺上運(yùn)行。</p><p>　　互操作性：應(yīng)用模塊可以以一種持續(xù)的方式一塊運(yùn)行，以及可以以一種定義過的方式互換數(shù)據(jù)。</p><p>　　可擴(kuò)展性：根據(jù)用戶要求，應(yīng)用模塊的功能和性能以及硬件的大小可以被調(diào)整。</p><p>　　為了實(shí)現(xiàn)了IEEE定義的要求和這些公開式的標(biāo)準(zhǔn)，一個(gè)開放式控制系統(tǒng)必須是：</p>

87、;<p>　　廠商中立;它保證了單個(gè)專有喜好的獨(dú)立性。</p><p>　　共識達(dá)成: 它是由一個(gè)供應(yīng)商和用戶組（通常是以一個(gè)用戶組或興趣小組的形式）?；跇?biāo)準(zhǔn)的。這確保了以一種標(biāo)準(zhǔn)的形式廣泛分布（國際/國家標(biāo)準(zhǔn),廠商間的標(biāo)準(zhǔn)）。</p><p>　　免費(fèi)提供。它向任何感興趣的群體免費(fèi)。</p><p>　　3.2開放式控制系統(tǒng)的分類如果我們講控制

88、系統(tǒng)的開放性，以下類別可識別（圖10）：</p><p>　　開放性人機(jī)交互：這種開放性僅限于控制系統(tǒng)的非實(shí)時(shí)部分。在用戶導(dǎo)向的應(yīng)用中可進(jìn)行改編。</p><p>　　有限開放的內(nèi)核：控制核心有一個(gè)固定的拓?fù)浣Y(jié)構(gòu)，但是提供接口來嵌入用戶專用過濾器，深知對于實(shí)時(shí)功能。</p><p>　　開放控制系統(tǒng)：控制核心拓?fù)淙Q于進(jìn)程。它提供了互換性，可擴(kuò)展性，可移植性和互操作

89、性。</p><p>　　開放式控制系統(tǒng)，可提供當(dāng)今大多為在一個(gè)固定的軟件拓?fù)浞菍?shí)時(shí)部分修改的可能性。</p><p>　　他們?nèi)狈Ρ匾撵`活性，并沒有以供應(yīng)商中立的標(biāo)準(zhǔn)為基礎(chǔ)。</p><p>　　3.3要求一個(gè)廠商中立的開放式控制系統(tǒng)才能實(shí)現(xiàn)，如果控制功能細(xì)分為功能單位，如果在這些單元間良好定義的接開口被指定 一個(gè)廠商中立的開放式控制系統(tǒng)才能實(shí)現(xiàn)（圖11）。因

90、此模塊化可以被認(rèn)定為是開放系統(tǒng)體系結(jié)構(gòu)的關(guān)鍵。在確定模塊化的復(fù)雜程度中，在開放程度和集成成本間有一個(gè)很好的權(quán)衡[6].越小的模塊提供了一個(gè)更高水平的開放性和更多的選擇性，但是增加了復(fù)雜性和集成成本。而且這種低水平的粒度可導(dǎo)致對資源的更高的要求，甚至可能惡化了整個(gè)系統(tǒng)的實(shí)時(shí)性能。</p><p>　　以“混合和匹配”的方式連接模塊需要一個(gè)標(biāo)準(zhǔn)應(yīng)用程序編程接口（API）的綜合設(shè)置。對于廠商中立的開放式控制系統(tǒng)的接口必

91、須標(biāo)準(zhǔn)化和廣泛接受。由于這種模塊化系統(tǒng)的復(fù)雜性對系統(tǒng)架構(gòu)的定義是可取的和有益的。這導(dǎo)致了所謂的系統(tǒng)平臺（圖12）的介紹。這些平臺通過吸收封裝硬件，操作系統(tǒng)和通信的特點(diǎn)計(jì)算系統(tǒng)的細(xì)節(jié)。這種中間件系統(tǒng)的可用性促進(jìn)了應(yīng)用軟件輕松移植，也是應(yīng)用模塊，即使在??分布式異構(gòu)環(huán)境的互操作性。</p><p>　　由于混合和匹配模塊的可能性，通過標(biāo)準(zhǔn)化接口，系統(tǒng)的整體質(zhì)量由單一模塊間的交互程度所決定（見第5）。</p>

92、;<p><b>　　4關(guān)于市場的系統(tǒng)。</b></p><p>　　4.1重大國際活動日本的OSEC（日本）</p><p>　　日本的OSE（關(guān)于制造的開放系統(tǒng)環(huán)境）財(cái)團(tuán)于1994年12月成立。三個(gè)項(xiàng)目的各個(gè)階段進(jìn)行到1999年的三月[1] [2] [3]。該財(cái)團(tuán)體系的目的是為最終用戶，機(jī)床制造商，控制供應(yīng)商，軟件供應(yīng)商，系統(tǒng)集成商，為工業(yè)機(jī)器等控

93、制器，提供一個(gè)可以添加自己的獨(dú)特價(jià)值的工業(yè)機(jī)器的標(biāo)準(zhǔn)平臺，從而促進(jìn)工業(yè)機(jī)器技術(shù)和商業(yè)的發(fā)展。在日本的OSEC API是??定義一個(gè)接口協(xié)議，它是用來在代表了功能性和實(shí)時(shí)循環(huán)的控制軟件組件間交換信息。每個(gè)功能塊可以被封裝為一個(gè)對象，因此沒有必要處理一個(gè)功能塊是怎樣在結(jié)構(gòu)層面上傳遞信息的（圖13）</p><p>　　雖然功能塊的結(jié)構(gòu)可以被該財(cái)團(tuán)體系從視覺上的邏輯點(diǎn)定義，該系統(tǒng)是既不被確定的也不被限制的在它的實(shí)施階段

94、，因?yàn)樵趯?shí)施階段有太多選擇。這些選項(xiàng)可能包括系統(tǒng)詭計(jì)，如設(shè)備驅(qū)動程序，進(jìn)程間通信，如靜態(tài)庫和DLL安裝機(jī)制，如硬件因素像控制器卡的選擇，以及軟件模塊對執(zhí)行控制和/或監(jiān)控各種軟件的</p><p>　　實(shí)現(xiàn) 。換句話說，實(shí)現(xiàn)結(jié)構(gòu)模塊的實(shí)施模塊是不被限制在某些模塊的。根據(jù)系統(tǒng)的大小或它的硬件實(shí)施和/或利用，它被確定把各種想法納入實(shí)施模塊。</p><p><b>　　JOP (日本)

95、</b></p><p>　　為與OSE財(cái)團(tuán)平齊，MSTC從1996年到2000年在JOP（日本公開賽推廣組）的旗下形成了開放式控制器技術(shù)委員會（業(yè)主立案法團(tuán)，訓(xùn)練班）。OC – TC的各項(xiàng)指標(biāo)是在開放式控制技術(shù)的標(biāo)準(zhǔn)上為各種公司提供在一起討論和工作的機(jī)會。業(yè)主立案法團(tuán)超導(dǎo)還預(yù)計(jì)，在這一領(lǐng)域作為國內(nèi)和國際活動之間的聯(lián)系。OC-TC由大約50名成員，其中包括日本大型控制器供應(yīng)商，機(jī)床制造商，集成商，用戶

96、和學(xué)者參加了會議。一些成員代表的其他群體，如華泰財(cái)團(tuán)和FA聯(lián)網(wǎng)推廣集團(tuán)。其中的一個(gè)工作組是致力于在數(shù)控和基于個(gè)人電腦的人機(jī)交互之間開發(fā)一個(gè)為了交互的標(biāo)準(zhǔn)的API。它還應(yīng)在數(shù)控和高層管理控制之間的交流是有效的。這項(xiàng)工作基于來自主要控制供應(yīng)商和華泰財(cái)團(tuán)的提議而被執(zhí)行。開發(fā)的規(guī)格被命名為PAPI發(fā)布于1999年的7月。PAPI 被批準(zhǔn)為JIS（日本工業(yè)標(biāo)準(zhǔn)）的技術(shù)報(bào)告，并在2000年10月出版。為了證明由OC-TC研制的規(guī)格的有效性，1999

97、年10月在名古屋由不同廠商生產(chǎn)的兩個(gè)碳奈米尖錐被連接到一個(gè)Windows NT計(jì)算機(jī)，即由東京大學(xué)所開發(fā)的同一個(gè)HMI系統(tǒng)被實(shí)施(圖14)。由于任何特定的控制結(jié)構(gòu)都不是假設(shè)的，PAPI可</p><p>　　OMAC（美國）開放式模塊化結(jié)構(gòu)控制器（OMAC）用戶組是一個(gè)行業(yè)論壇，用來推動控制器技術(shù)現(xiàn)狀[10]。關(guān)于OMAC夫人措施正在實(shí)施，用來定義API的規(guī)范性，從而最終達(dá)成穩(wěn)固的標(biāo)準(zhǔn)組織。OMAC的API通過

98、接口類來指定使用的API [11]，從而實(shí)現(xiàn)一個(gè)基于組件的方法來實(shí)現(xiàn)插件和播放模塊化。對于分布式通信，基于組件的技術(shù)使用代理來處理跨進(jìn)程邊界的調(diào)用方式。OMAC API包含不同的“大小”和“類型”的可重復(fù)使用的插件和播放組件 - 組件，模塊和任務(wù)-每一個(gè)都有一個(gè)獨(dú)特的有限狀態(tài)機(jī)（FSM）的合作模式，從而組件協(xié)作以一種未知的方式來進(jìn)行。術(shù)語組件應(yīng)用于可重復(fù)使用的軟件中，該軟件像一個(gè)帶有應(yīng)用的構(gòu)建塊一樣運(yùn)行，而術(shù)語模塊指的是模塊的容器件。任

99、務(wù)是用來封裝的可編程功能行為的一個(gè)組件，包括了一系列運(yùn)行完成的步驟，它支持包括開始，停止，重新啟動，暫停和恢復(fù)，并可能被多次運(yùn)行當(dāng)控制器在運(yùn)行時(shí)。任務(wù)可以被用來建立控制程序，這種控制程序包括一系列的轉(zhuǎn)換任務(wù)，有能力重啟，導(dǎo)向或者作為一個(gè)獨(dú)立的駐地任務(wù)來處理特定的控制請求，（例如軸歸位或緊急停止）。為了整合元件，一個(gè)框架必須規(guī)范協(xié)作和其他組件操縱的生命</p><p>　　圖15闡明了OMAC控制器功能。人機(jī)界面模

100、塊負(fù)責(zé)與人類的互動，包括提交數(shù)據(jù)，移交命令和監(jiān)控事件以及在OMAC API“映射”中的與所有主要的模塊相關(guān)的，通過代理的組件的引用實(shí)際控制器。任務(wù)協(xié)調(diào)員模塊在基于編程的系統(tǒng)中負(fù)責(zé)測試和協(xié)調(diào)不同的模塊。任務(wù)協(xié)調(diào)員可以被認(rèn)為是控制器中的最高級別的有限狀態(tài)機(jī)。一個(gè)任務(wù)生成模塊把特殊應(yīng)用的控制程序（例如，零件加工程序的RS274）轉(zhuǎn)換成一系列的與應(yīng)用無關(guān)的瞬態(tài)任務(wù)。軸組模塊負(fù)責(zé)協(xié)調(diào)各軸的運(yùn)動，把一個(gè)傳入規(guī)范運(yùn)動段轉(zhuǎn)換成一系列的同等時(shí)間間隔的設(shè)定