CA2097564C - Method of coupling open systems to a proprietary network - Google Patents
Method of coupling open systems to a proprietary network Download PDFInfo
- Publication number
- CA2097564C CA2097564C CA002097564A CA2097564A CA2097564C CA 2097564 C CA2097564 C CA 2097564C CA 002097564 A CA002097564 A CA 002097564A CA 2097564 A CA2097564 A CA 2097564A CA 2097564 C CA2097564 C CA 2097564C
- Authority
- CA
- Canada
- Prior art keywords
- module
- data
- memory
- shared memory
- proprietary network
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
Abstract
An interface provides a path to transfer data from a proprietary network to an open system. The proprietary network includes at least one module central processing unit (CPU) and a module memory associated therewith operatively connected to the proprietary network. A shared memory and shared memory logic are interposed between the proprietary network and the open system, thereby forming the data path.
The method comprises the steps of accepting requests for data from the open system by a parasitic task function within the module CPU. The data requested of the proprietary network is obtained and placed in a predetermined location of the module memory in a form understandable to the open systems. A
pointer value is placed in the shared memory, the pointer value containing the value of the predetermined location of the module memory, the shared memory being mapped in the addressable memory space of the shared memory logic using virtual memory techniques. The data is obtained directly from the module memory utilizing the pointer value corresponding to the data requested, thereby allowing open systems to access the proprietary system while maintaining the integrity of the proprietary network.
The method comprises the steps of accepting requests for data from the open system by a parasitic task function within the module CPU. The data requested of the proprietary network is obtained and placed in a predetermined location of the module memory in a form understandable to the open systems. A
pointer value is placed in the shared memory, the pointer value containing the value of the predetermined location of the module memory, the shared memory being mapped in the addressable memory space of the shared memory logic using virtual memory techniques. The data is obtained directly from the module memory utilizing the pointer value corresponding to the data requested, thereby allowing open systems to access the proprietary system while maintaining the integrity of the proprietary network.
Description
6~115~~-1379 A METHOD OF COUPhTNG OPEN HYSTEhlS TO A PROPRIETARY NETWORK
F3ACF<t~;E~OCJIyL7 ,y F' ,C,f.IF.:, >:1~'s?E"~'t'T~),d 'This invention relatc.;~ t<> distx ib:l1-~ed ciig.ital systems, anc~ more p;~r_t::i.cu:l.ar ~.y,, t-c.;~ yi;.;t r ?_k~u F.,ci tligs.t.al systems having a plur,~lit~y of rm~,~lec,.~<;u:,~:31r-ecl t::c> a net=.wc>rk for communicating between node s, why>reir:. a once ~~losed (ox-proprietary) network .i~u~ opened t..~ uerm:it. a rariet..y of nodes tc> bc> coupled to th~:e nc.~twc~r k .
There cur.rernt:ly f.,xi_st:~,, syTsk~envs ;~ua~.;i.r...~c~ ~~ ~,luxal.ity of nodes ops~:rativel~y c~::3nne.c.t.~.-.c.~ t'., ,:a k.~u~ ;.rv lEtwox'k :i.n which the nodes a.te develope~::~ ;;ay a s~.n~~l.t:= rnar,~.~f,=pct:«tw~r who enforces strict contro7_ over t.l"ue t.~lesi.gn ;~:f t_he nodes a.nd over the fur~et:ions tc~ k:>e ~~e:erfc~r.m~~ra x;y t r;..; rz.~cl~~s. Further, a predetermined protocol. is ~:at~i.7.a r c::~r.~ i~~~ tln=' nk.t~woz~k whictu results in a ~~ closed" envi t oment .
In order t=o .311ow a ~;ser the op~:ic::~n of selecting eduipment of other manufact:ure:., hr:uu i.rz<a iif °_e.ring pro t.ocols, and trnereby expand.i,~c:~ t:.he ~~apal.. a 1. :i. t irr:=s ~c7~:~i I-zxruc:tior.ality of these systems, it is d"s:ired to toac~e ar: "~~pt:er~" systerra envin_onment which per~rni.t:; t=.he ra fe.r' t. c:. c: ~~,r.~a;~'':t:
(directly or indirectly) these ec~m:L~~ment: ._ot ~.>~~r~f:~r rrnr.~i~~_rf:;:~~'t ~°~.rers having differing designs to tine network i~t the vys~.E:m. By opening up tree system to the;;e edur~prner;t.:~, glue ~~L-i~~i:~i.l:i.ty of the system is now suscept:i.kole to ~:my errors, (,bu~:~t.~, viru.ses,...) of the new equipment bei_n~:~ added wr: ick1 u~~ n,ot ;,rider the control of the manufacturer of th.e ~~y~~t:a~rra.
Thus, the present:. i.nvf-r-i.t. ~.or:~ Cr:~ . ~sr:i..~a~w, a methc;d for coupl ing open systems ~o a prcy:.x i r=t_ary nevtw~::vrk while maintaining the higln r~:~liabiLit..Y ~:kat t:rm~ :~~:~st:em had before opening up the enV_i:r_onmentr ~~kw ~::~k:o:~r:~ sy:>r~,rn:, iruc:lud:ing networks, computer pl.at.forms,... oa ot.tiex rnarn:fai~turers. By opensng the system, cor,unez:<~~i,~ll_~~ a~?a:..:La~:i~.r ~:t.ility software can be util_i.zed on true opeo~ .~~,> >_c-°~in: ':k ~:'~ ..t:,y iric.:;reasi.ng t:;~e software functionality of th~:a ~sy~>4~-gym.
n L.
;:pUMC~IAR~' a~l~' 'I"f~IE:, I. t~VF_;N 1' .:~.~>N
In acc:c~rcianc:~: w~_th 't to z .:, i..zzvcJ:c'1. ~ car. k pert: Ls provided a method f or proviai.n~.~ ran i_nt.~:.rfacr~ to S~ransfer data from a proprie'k.~r y ne ~wc:>rl; t. c:; .3r1 c,y,ezn 7y....5t:~:~rn, t.rue.~
proprietary network in;=ludi.ng ._a t Least: c:ne ~nc~~:aule cent: ral procassing ani't (CL?U) ~~rvc~ a rrzo~:k~a1 c~:: rr~~rczc;ry a ,r;c~c-;~
<:zted therewith oper_ative.l.y ~::onnecte~:~ t c.:~ tizr~ L:r~:priE~t.ao°y nEzi:.work, wherein a shared memory ~~n<i sh:ir~~d mercm~r.-y L~~e~:C.c~ tire interposed between the proLsz :i a ~ a r..y;, ne t wc. rh :~zncl t~ze c~~a~;~n system, the method corrpri_s.:ing k:h~=' ;steps c~f : ,_:r;~ ac:cepting requests fo:r data fr~>rc, tha-~ c~~~Pr~. ::y;_~tE~rr~ t~~ a para:;it~~.c:
task function within the module GfU; b) obt:.ainin~~ t:t~e data requested: c) placirz~~ t:he c.~at:a:~ i.n ~r ~~e:< ~.~e~t:errr~.l.rrec::l ~_oca;~tion of the module memory in a form underst:s~ridabl.e3 to the c.~pen systems; d) plac:inq ~ L:oairat:e.r ,r~.~:l.t:o.e~ i.fv t_,~~_~ .~~ni:3-E:~c~
memory, the pointer value containing tl,c~ v~~liar.:~ c:,( t:rh:e prE~detei.mined locar~ion of the modu.Le memory, ttee 5rza~:ed mc~mc>ry being mapped in the address>aC->le rnerrcor~~ :>Ca«ca~ c.~i: f ue sCuared n:~em.ory logic; and e) obtain the data cair_e~.~tl_~.,e aturn the module memory utilizing the pc~int.r=~r v<~ ~ ~.ac:~ ~:or re.~pc~crcwting t<., tree data requested.
Therefore, there is provided by the present invention, a method for coupling open systems to a proprietary network.
An interface provides a path to transfer data from a propri-etary network to an open system. The proprietary network includes at least one module control processing unit (CPU) and a module memory associated therewith operatively connected to the proprietary network. A shared memory and shared memory logic are interposed between the proprietary network, and the open system, thereby forming the data path. The method comprises the steps of accepting requests for data from the open system by a parasitic task function within the module CPU. The data requested of the proprietary network is obtained and placed in a predetermined location of the module memory in a form understandable to the open systems. A
pointer value is placed in the shared memory, the pointer value containing the value of the predetermined location of the module memory, the shared memory being mapped in the addressable memory space of the shar~:d memory logic using virtual memory techniques ., The data is obtained directly from the module memory utilizing the pointer vales corresponding to the data requested, thereby allowing caper systems to access the proprietary system while maintaining the integrity of the proprietary network.
Accordingly, it is an object of the present invention to ~~9~~~~~
provide a method of coupling open systems to a proprietary network.
It is another object of the present invention to provide.
a method of coupling open systems to a proprietary network wherein the open systems has access to data of the proprietary network.
It is yet another object of the present invention to provide a method of coupling open systems to a proprietary network wherein the open system has direct access to data of the proprietary network.
It is still another object of the present invention to provide a method of coupling open systems to a proprietary network wherein the open systems has direct access to data of the proprietary network on essentially a realtime basis.
It is a further object of the present invention to provide a method of coupling open systems to a proprietary network wherein the open system has direct access to data of the proprietary network while maintaining the integrity of the praprietary network.
These and other objects of the present invention will become more apparent when taken in conjunction with the following description and attached drawings, wherein like characters indicate like parts, and which drawings form a part of the present application.
Docket No. I2000101 5 15 June 1J9~
~~9'~~64 BR~FF DESCRIPTION OF TI-IF DRAWINGS
Figure 1 shows. a black diagram of a process control, system of the preferred embodiment in which the present invention can be utilizedo Figure 2 shows a block diagram of common elements of each physical module of the process control system of Figure 11 Figure 3 shows a functional block diagram of a typical physical module of the process control system;
Figure 4 shows a partial, functional block diagram of the existing system and the opened system of the preferred embodi-ment;
Figure 5 shows a functional block diagram of an open operator station of the preferred embodiment;
Figure 6 shows a block diagram of the proprietary network and the interface for coupling to open systems;
Figure 7 shows a block diagram of a graphics card of the preferred embodiment; and Docket No. I200~101 6 15 June 199x Figure 8, which comprises Figures 8A and 8~, shows examples of screen displays of the display unit of the process control system.
Docket No. 12000101 7 15 June 1992 DETAILED DESCRIPTION
Before describing the method of the present invention, it will be helpful in understanding a system environment in which the invention is utilized. Referring to Figure 1, there is shown a block diagram of a pracess control system 10 of the preferred embodiment in which the present invention can be found. The process control system 10 includes a plant control network 11, and connected thereto is a data highway 12, which peru~its a process contraller 20' to be connected thereto. In the present day process control system 10, additional process controllers 20' can be operatively connected to the plant control network 11 via a corresponding highway gateway 601 and a corresponding data highway 12. A process controller 20, an interface apparatus which includes many new, additions, improvements, and features over the process controller 20°, is operatively connected to the plant control network 11 via a universal control network (UUN) 14 to a network interface module (NIM) 602. In the preferred embodiment of the process control system 10, additional process controllers 20 can be operatively connected 'to the plant control network 11 via a corresponding UCN 14 and a corresponding NIM 602. The process controllers 20, 20' interface the analog input and output signals, and digital input and output signals (A/I, A/O, D/I, and D/O rasp~at~.vely) to the process control system 10 Prom the variety of Eield devices (not shown) of the process being Docket No. I2000101 8 1S June 1992 ~09'~~~4 controlled which include valves, pressure switches, pressure gauges, thermocouples,....
The plant control network (or more simply network) 11.
provides the overall supervision of the controlled process, in conjunction with the plant operator, and obtains all the information needed to perform the supervisory function, and includes an interface with the operator. The plant control network 11 includes a plurality of physical modules, which include a universal operator station (US) 122, an application module (AM) 124, a history module (F~i) 126, a computer module (CM) 128, and duplicates (backup or secondary) of these modules (and additional types of modules, not shown) as necessary to perform the required control/supervisory function of the process being controlled. Each of these physical modules is operatively connected to a local control network (hCN) 120 which permits each of these modules to communicate with each other as necessary. The NIM 602 and HG 601 provide an interface between the hCN 120 and the UCN 14, and the LCN
120 and the data highway 12, respectively.
Physical modules 122, 124, 126, 128,... of network 17. of the preferred embodiment are op various specialized functional types. Each physical module is the peer, or equivalent, of the other in terms, of right of, access to the network's communication medium, or hCN 120, for the purpose of transmit-ting data to other physical modules of network 11.
Docket No. I2000101 9 15 June 1992 Universal operator station module (US) 122 of network 11 is a work station for one or more plant operators. It includes an operator console which is the interface between.
the plant operator, or operators, and the process or processes of the plant for which they are responsible. Each universal operator station module 122, is connected to the LCN 120, and all communications between the universal operator station module 122, and any other physical module of network 1l, is via the hCN 120. Universal operator station m~dule 122 has access to data that is on the LCN 120 and the resources and data available through, or from, any of the other physical modules of network 11. The universal station module 122 includes a cathode ray tube display (CRT) (not shown) which includes a video display generator, an operator keyboard (KH) (not shown), a printer (PRT) (not shown), and can also include (but not shown) a cartridge disk data storage device, trend pen recorders, and status displays, for example.
A history module (Hilt) 126 provides mass data storage capability. The history module 126 includes at least one conventional disk mass storage device such as a Winchester disk, which disk storage device provides a large volume of nonvolatile storage capability for binary data. The types of data stored by such a mass storage device are typically trend histories, event histories, ....or data from which such histories can be determined, data that constitutes or forms CRT type displays, copies of programs for the physical Docket No. 12000101 10 15 June 1992 modules....
An application module (AM) 124 provides additional data processing capability in support of the process control.
functions performed by the controllers associated with the process control subsystem 20, 20' such as data acquisition, alarming, batch history collection, and provide continuous control computational facilities when needed. The data processing capability of the application anodule 124 is provided by a processor (not shown) and a memory (not shown) associated with the module.
Computer module (CM) 128 uses the standard or common units of all physical modules to permit a medium-to-large scale, general purpose data processing system to communicate with other physical modules of network 11 and the units of such modules over the LCN 120 and the units of process control subsystems 20, 20' via the highway gateway module 601, and the NIM 602, respectively. Data processing systems of a computer module 128 are used to provide supervisory, optimization, generalized user program preparation and execution of such programs in higher level program languages. Typically, the data processing systems of a computer module 128 have the capability of communicating with other such systems by a c~mmunication processor and communication lines.
The local control network 1211 (LCN) is a high-speed, bit serial, dual redundant communication network that intercon-nects all the physical modules of plant control network 11.
Docket No. I2000101 11 1~ June 1992 ~p9"d~6~
LCN 120 provides the only data transfer path between the principal sources of data, such as highway gateway module 601, application module 124, and history module 126, and principal.
users of such data, such as universal operator station module 122, computer module 128, and application module 124. LCN 120 also provides the communication medium over which large blocks of data, such as memory images, can be moved from one physical module such as history module 126 to universal station module 122. LCN 120 is dual redundant in that it consists of two coaxial cables that permit the serial transmission of binary signals over both cables.
Referring to Figure 2, there is shown a block diagram of the common elements of each physical module of the network 11 or the process control system 10. Rach of the physical modules includes a module central processor unit 38 and a module memory 40, a random-access memory (not shown) , and such additional controller devices, or units (not shown), which are configured to provide the desired functionality of that type of module, i.e., that of the operator station 122, for example. The data-processing capabilities of each module's CFU 38 and module memory 40 create a distributed processing environment which provides for improved reliability and performance of network 11 and process control system 10. The reliability of network 11 and system 10 is improved becaus~, if one physical module of network 11 fails the other physical modules will remain operational. As a result, network 11 as Docket No. I2000101 12 15 June 1992 2~9"~5~~
a whole is not disabled by such an occurrence as would be the case in centralized systems. Performance is improved by this distributed environment in that throughput and fast operator response times result from the increase computer processing resources, and the concurrency and parallelism of the data-processing capabilities of the system.
As mentioned above, each physical module includes the bus interface unit, BIU, 32 which is connected to the LCN 120 by the transceiver 34. Each physical module is also provided with the module bus 36 which, in the preferred embodiment, is capable of transmitting 16 bits of data in para11e1, between the module CPU 38 and the module memory 40. Other units, utilized to tailor each type of physical module to satisfy its functional requirements, are operatively connected to module bus 36 so that each such unit can communicate with the other units of the physical module via its module bus 36. The BTU
32 of the physical module initiates the transmission of data over LCN 120. In the preferred embodiment, all transmissions by a BIU 32 are transmitted over the coaxial cables which, in the preferred embodiment, form the LCN 120.
Referring to k"igure 3 there is shown a functional block diagram of a typical physical module 122, 124, 126, 128 of the plant control network 11, and includes the bus interface unit (BrU) 32 arid the transceiver 34, which connects BIU 32 to the LCN 120. BIU 32 is capable of transmitting binary data over LCN 120 and of receiving data from LCN 120. Transceiver 34 in Docket No. 12000101 13 1S June 19J2 ~~~9'~~6~
the preferred embodiment, is transformer coupled to the LCN
120. In the preferred embodiment, the LCPd 120 is a dually redundant coaxial cable with the capability of transmitting.
bit serial data. HIU 32 is provided with a very fast micro-engine 56. In the preferred embodiment, micro engine 56 is made up of bit slice components so that it can process eight bits in parallel, and can execute a 24 bit macroinstruction from its programmable read only memory (PROM) 58.
Signals received from the LCP~ 12o are transmitted by transceiver 34 and receive circuitry 52 to receive FIFO
register 54. Micro engine 56 examines the data stored in FIFO
register 54 and determines if the information is addressed to the physical module. If the data is an information frame, the received data is transferred by direct memory access (DMA) write circuitry 66 by conventional direct memory access technidues to the physical module memory unit (MMU) 40 over module bus 36.
Communication between MCPU pracessor 68, a Motorola 68020 microprocessor in the preferred embodiment, and other func-tional elements of MCPU 38 is via local microprocessor bus 39.
Module bus interface element 41 provides the communication link between local bus 39 and module bus 36. Processor 68 executes instructions fetched from either its local memory 43, in the preferred embodiment an EPROM, or from MMU 40.
Processor 68 has a crystal controlled clock 45 which produces clock pulses, or timing signals. Input/output (I/0) port 49 Docket rro. x2000101 14 15 June 199z 209' X64 provides communication between MCPU 38 and equipment external to the physical module to permit program loading, and the diagnosis of errors, or faults, for example.
Each MCPU 38 includes a timing subsystem 48 which, in response to clock signals from module clock 45 produces fine resolution, synchronization, and real-time, timing signals.
Any timing subsystem 48 which is provided with a timing subsystem driver 50, has the capability of transmitting timing information to other physical modules over the LCN 12~.
Another input to each timing subsystem 48, is timing informa-tion which is transmitted over LCN 120 and which is received through transceiver 34, timing receiver 55 and timing driver 57 of HxU 32. Timing pulses from module power supply 59 which are a function of the frequency of the external source of A.C.
electric power applied to power supply 59 are used by timing subsystem 48 to correct longer term frequency drift of the clock pulses produced by clock 45.
Additional information of the 81U 32 can be found in U.s.
Patent No. 4,556,974. A more detailed description of the process control system 10 can be had by referring to U.s.
Patent No. 4,607,256. Additional information of the individu-al, common, functional blocks of the physical modules can be had by reference to U.S. Patent No. 4,709,347, all of the above-identified patents being assigned to the assignee of the present application, and additional infarmation of the process controller 20° can be had by referencing U.s. Patent No.
Docket No. 12000101 15 15 June 1992 ~p9'~~6~
4,296,46.
The addition of an interface apparatus which interfaces other systems (i.e., open or foreign systems) to the process control system 10 described above, which includes providing the capability to readily permit nodes of differing designs to communicate to the network 120, will now be described. Also, specifically describes is a modification to a graphics generator in the US 122 which opens up the existing system, in particular the graphics interface.
Referring to Figure 4, there is shown a partial functional block diagram of the existing system and the open (or opened) system. The universal operator station (US) 122 is coupled to a co-processor 200, arid the co-processor is coupled to an open system, i.e., interfaces/protocols of differing design, including Transmission Control Protocol.
Internet Protocol (TCP/IP), open system interface (OSI), DECnet (a product of the Digital Equipment Corporation of Maynard, Massachusetts), Hewlett Packard personal computers, (HP),.... The universal station 122 is also connected to the LCN 120 as described above. Thus, the new universal operator station (open US) 123 includes the US 122 as described above in conjunction with the co-processor 200. The purpose of the open US 123 is to open the graphical interface to the open systems and to provide information from the closed US to the open systems. The co-processor 200 is structured to permit the interface to other systems, i.e., the open systems without Docket No. I2000101 16 15 June 1992 ~~9"~56~
jeopardizing the integrity of the existing system. The co-processor 200 of the preferred embodiment is a HIotorola ~8040 microprocessor which is executing the UNIX operating systems, (UNIX is an operating system of the American Telephone and Telegraph Company, ATT, is readily available and is well known to those skilled in the art), and is sometimes referred to as a UNIX co-processor.
Referring to Figure 5, there is shown a funo~tioraal block diagram of the open operator station 123 of the preferred embodiment. The operator station 122 as described above includes the BIU 32 connected to the module bus 36, the module memory 40, and the module CPU 38, both also connected to the module bus 36. These basic functional blocks are contained in all the physical modules. Additional functional blocks added to the physical module is what gives the physical module its personality apart from any other physical module. The operator station 122 includes a graphics card 150 which interfaces with a display (CRT) and a keyboard (RB) 151, 153.
A shared memory 202 is included and is also connected to the module bus 36 which provides for communication between the ca-processor 200 and the US physical module 122 (thereby providing communication to the rest of the process control system to via the module CPU 38). The method of communication between the module CPU 38 and the coprocessor essentially implements the method of the present invention whereby the open systems is coupled to the proprietary netwark. Thus, the Docket No. 12000101 17 15 June 1992 co-processor 200 requests service (e. g., the value of a point, contents of a file,... or any information of the process control system 10) of the module CPU 38 through shared memory.
202. The module CPU 38 then communicates with the appropriate module to perform the requested service in a normal fashion.
Once the response is obtained the information is passed to the co-processor 200 via shared memory 202. Since the module CPU
38 is cammunicating via the LCN 120, the integrity of the LCN
(i.e., the system) is maintained and similarly the module memory 40 cannot be corrupted by the co-processor 200.
although shared memory 202 is shown within the dotted lines of US 122 (dotted line A), it will be recognized by those skilled in the art that shared memory 202 can also be part of coprocessor 202 or a stand-alone unit interposed between the US 122 and coprocessor 200 (dotted line H). Such arrangements are essentially °°packaging°°
arrangements and have essentially no bearing of the function provided. The shared memary 202 (and associated circuitry, not spawn) provides for the direct coupling of an open systems processor (i.e., DEC, HP,...) to the process control system 10, thereby permitting the open systems processor to effectively function as a peer to the other physical modules or nodes of the network 120.
In this environment, the coprocessor 200 essentially has direct access to~ the module memory 40. Through this direct access, the coprocessor 200 can access and/or modify data in real time. (Hy convention, the coprocessor 200 is not permit-l7ocke~t No. I2000101 18 15 June 1992 ted to modify data in the module memory 40.) However, the module CPU 38 provides the interface which translates the proprietary LCN data to a farm usable by the open system and/or coprocessor 200.
Also shown in Figure 5 is an example open system (or foreign system), for example, a Digital Equipment Corporation system which includes the DECnet network and protocol and a DEC processor 300 attached to the DECnet network. xn the preferred embodiment, the communication between the DEC open system and the co-processor 200 is via an X-windows protocol (X-windows being a protocol defined by the Massachusetts institute of Technology, Cambridge, Massachusetts) for graphical display information, and other open systems stan-dards being used for data exchange. Any requests of the outside system to the LCN is made via the co-processor 200 through the shared memory 202 to the module CPU 38 as de-scribed above.
As mentioned above, the physical modules include common elements; however additional modules to each of the physical modules provides the °'personality" of the physical module.
The personality of the physical module provides the base environment for enhancements and improvements to the process control system 10 by the addition of the open systems. For example, the application module 124 of the process control system 10, exhibits a personality which provides for the complex control of process data through user programs. This Docket No. r2000101 19 15 June 1992 personality provides the basis for enhancement by the co-processor 200 by exploiting the computing capabilities of both the open system and the coprocessor 200 to further extend the.
programs through commercially available software such as spread sheet, data base manager,.... In the case of US 122, the personality is based on the graphics card 150. In the preferred embodiment, the coprocessor 200 provides the capability to enhance the display of the U~ 122 (and thereby enhancing the personality of the process control system 10) by utilising the advanced display capabilities of the coprocessor such as multiple display windows.
Referring to Figure 6, there is shown a block diagram of the proprietary network and the interface for coupling to ,open systems. The coupling to span systems is achieved through the use of the coprocessor 200A and shared memory 202A. Through this path, first channel 157, the c~processor 200A can see the module memory 40N and the shared memory 202A. Each module CPU
38 is executed and modifying data within its corresponding module memory 40. A module CPU 38 communicates that data among other module CPU°s by indicating where the data is located. In the process control system 10 {or bCN environ-ment) each module CPU knows the LCN protocol and therefore knows the data structure. The data exchange is communicated between other module CPU or between tasks within the same module CPU via messages which are essentially pointers indicating where the data is located. The data can also be ~ocket No. I2000101 20 15 June 1992 'zo9~~e~
passed to another node by actually passing the data value itself. In the process of connecting open system to the proprietary network, an objective is to maintain high reli-ability of the proprietary network. In response to a request from the open system through the coprocessor 200A, data can be sent to the open system; however, the data can subsequently change so that the original requester does not always have the latest value of the data, i.e., the data is transitory.
Shared memory is utilized so that the open system can have direct access to the data location, the data location being the only copy of the data thereby ensuring that the open system always has access to the latest data value.
The structure of the physical modules, in particular the module CPU 38, is such that various tasks are executing under the control of an operating system. In order to minimize the impact to the physical module and thereby potentially intro-ducing new errors and reducing the reliability, the interface communication is achieved by adding a new task in the module CPU 38, the new task performing a parasitic function. The newly added task intercepts data between tasks or between nodes and passes the data to the open system before the originally intended recipient has,acceas to the data. Thus, the open system can use/modify the data and then pass it on to the originally intended recipient (or assume the role of the intended recipient with respect to the data). The direct access to the module memory 40 by the coprocessor 200 is Docket No. 12000101 21 15 June 1932 achieved through the use of shared memory, the coprocessor mapping the shared memory in its addressable memory location.
Thus the coprocessor only has access to the data of the module memory in which it has knowledge of where the data is located within module memory through a pointer in the shared memory 202. The coprocessor mapping is achieved via virtual memory mapping techniqtaes well known those skilled the art. The newly added task performs the loading of the pointers in the shared memory and also performs a translation of the data in the module memory such that the data is meaningful to the open system.
The coprocessor 200 also communicates directly to the graphics card 150 by a direct path, second channel, 159 essentially the same as the communication between the co-processor 200 and shared memory 202. The interface consists of two distinct elements that are coupled through a shared memory 158 on the graphics card 150. A first logic element or task which implements the communication function is executed by the coprocessor 200 connected to the card bus 152. The first logic element executes on the graphics card, i.e., a graphics processor 160. When the second logic element is started, the shared memory 158 is memory mapped into the address range of the second element address range. The second element executing in the coprocessor 200, after the graphics card 1.50 is started, loads the graphics processor 160 with the necessary program functions stored in the coprocessor 200.
Docket No. 7L2000101 22 15 June 192 ~~'~'~56~
The second element executing in the coprocessor 200 passes messages to the graphics processor 160 through the shared memory 158 of graphics card 150. Messages are passed with the.
use of pointers, the pointers being kept in a structure of the shared memory 158 with both the coprocessor 200 addressing and the graphics processor 160 addressing. Through the use of passing messages, the control of the display unit is per°
formed, including various data information, command informa-tion, and validation or status checks. These checks and validations are described in related application b.
It will be recognized by those skilled in the art that various configurations may be implemented in capturing the spirit and scope of the present invention. For example the coproc~ssor 200A can have additional channels to the open systems. Additional coprocessors 2008 with corresponding shared memory 2028 can be interfaced to any of the physical modules. Further since the module CPU 38 can communicate via the LCN 120 with any of the other physical modules the need to interface a coprocessor 200 and shared memory 202 to an individual physical module is unnecessary since, as mentioned above the module CPU 38 can communicate with any other physical modules on the LCN 120. The co-processor 200A is shown interfacing w~.th the physical module N, the physical module being the universal station 122. This is indicated by the graphics card 150 b~ing attached to the module bus 36N, the graphics card giving the physical module the personality Docket No. I2000101 23 15 June 1992 ~0~'~~~~
as discussed above. The coprocessor 200A interfaces to the open system via an open system protocol, in the specific example and in the preferred embodiment the X--windows proto-col. In a similar fashion coprocessor 2008 interfaces to the open system, in this case an HP computer platform using a predefined available protocol. By providing the logic within the coprocessor and within the newly added task added to the various module CPU°s, the interface with the proprietary LCN
network is thereby achieved.
The module CPU 38 executes a set of tasks under an operating system. These tasks execute the variaus tasks and utilize existing interfaces to access the location of and movement of data within the process Control system l0. The primary function of these tasks is to provide the predetermine functions consistent with the personality of the physical module. In addition, the present invention adds a task for implementing the method of the present invention which services requests for data by the copracessor 200. In addition, the newly added task provides a translation of the process control system data (or LCN data) usable by the copracessor 200. The newly added task executes the requested service in the module CPU 38 and passes a pointer to the coprocessor by a shared memory 202 so that the coprocessor does not have to wait for a copy of the data. This also insures uniqueness through use of a single copy of the data when it is maintained dynamically by the module CPU 38, or any Docket No. 12000101 24 15 ,3une 1992 ~zoo~~s~
other physical module of the process control system 10. The pointer value passed to the coprocessor 200, paints to a virtual memory location in which the module memory 40 is mapped. Thus, the coprocessor 200 can directly access module memory 40 utilizing the point of value, 'the data having been translated by the module CPU 38 into a form compatible with and usable by the coprocessor 200. The coprocessor 200 can have more than a single request from more than a single requestor of the open systems. Tn such case, the shared memory 202 is mapped into a virtual memory format allocating virtual memory space for the various requestors.
The coprocessor 200 includes logic which interfaces with and communicates with the newly added task of the module CPU
38. The coprocessor 200 logic perforaas functions to utilize and conform to establish industry standard interfaces re-cognizied by the commercial software. In this interface the software functions as a server which provides a unique interface path for module CPU 38 for each program of the open system that requests its services. An application software package which executes on the coprocessor 200 is designed and implemented using commercial tools, software utilities, and data libraries. The application is designed to utilize the capabilities afforded by the commercial software to perform service neat available on tha process control system 10. such services may include access of data on multiple open system computer platforms within the outside systems environment Docket No. 12000101 25 15 June 1992 yn~~ ~~~
which are not compatible with the process control system 10 environment. These services are combined with the capability to access the process control system data needed to perform the application. Functionally, each application software program utilizes a defined set of generic or general purpose requests to access process control system data and functions.
These requests utilize industries standard data format representations that is easily exchanged with and manipulated by commercial software programs. The interface function of the coprocessor 200 provides the service of passing these requests to the process control system physical module. The module CPU 38 of the physical module translates the service to its proprietary LCN form and executes the request. The response is returned to the requesting open system by the coprocessor 200 in a form which the application software can interpret.
It is also desired to open up the graphics interface such that a display which is not on the LCN can be displayed onto the CRT 151 of the U8 122. This is achieved by the interface to the graphic card 150 from the co-processor 200. Referring to Figure 7, there is shown a block diagram of the graphics card 150 of the preferred embodiment. The graphics card includes a card bus 152. Attached to the card bus 152 is a data memory 154 which contains the information which is to be displayed onto the CRT, and also contains some control information. A microprocessor 156 is also coupled to the card Docket No. 12000101 26 15 June 1992 '~~1~~~~~~
bus 152 and further is coupled to the module bus 36. A
graphics processor 160 is coupled to the card bus 152 and performs all the processing for developing the information stored in the data memory 154, including some control func-Lions. A shared memory 158 is coupled to the card bus 152.
A connection is made from the card bus 152 to the co-processor 200, thereby providing the interface mentioned above to the graphics card 150 from the co-processor 200. The microproces-sor 156 of the preferred embodiment of the graphic card 15 is a Motorola 68020 processor. The graphics card 150 is a two port graphics card, one port of the graphics card being tied to the module bus 36 which is how a display is driven from LCN. The LCN 120 provides a "single window to the process,"
i.e., a screen display of what the process/process control system is doing. The second port is coupled to the ca-processor 200 and provides the windows interface for the universal station 122. The windows interface is the X-windows interface which is well defined and well known to those skilled in the art (the interface being defined by MIT, Cambridge, Massachusetts). It is through the interface from the co-processor 200 that all the window displays [i.e., the screen display(sj of the open system(sj] and windows controls are performed, including commands to the graphic card 150 to specify where to place the single window to the process on the screen of the CRT 151. The interface between the graphics card 150 and the ca-processor 200 is the full windows inter-Docket No. I2000101 27 15 June 1992 2~9'~56~
face. One of the windows is the display referred to above as the '°single window to the processor°' (sometimes referred to as the LCN window). The co-processor 200 commands the graphics.
card 150 where the LCN window is to be placed on the CRT 151 and its relative size on the display. X-windows is a well defined protocol of how to communicate with the graphics card 150 (or any graphics card) and display, and a computer permitting many windows to be displayed. This includes displaying at least one window from the LCN and/or at least one window from the open system 300. In this system, a server is defined in X-windows as the machine that is driving the display (or that portion of the co-processor 200 which interfaces to the graphics card 150), and a client is the application program, in the present embodiment, the DEC
processor 300.
The client 300 can have data which is desired to be displayed. The client 300 communicates with the server portion of the co-processor 200 through an X-windows protocol indicating data to be displayed. .The server portion of the co-processor 200 communicates with the graphics card 150 through a device dependent layer (DDL) and is provided by the vendor of the graphics card, or in X-windows is via DDX
protocol. The microprocessor 156 maintains the integrity of the card bus 152 into the data memory 154. The processing of the data to be displayed on the CRT 151 is performed by the graphics processor 160. HThen a predetermined data screen is Docket No. I2000101 26 15 June 192 c to be displayed, the microprocessor 156 (which accepts requests from the LCN 120 via module bus 36) places the data in shared memory 158, and is subsequently processed by the.
graphics processor 160, and is then stored in data memory 154.
When the open system 300 (via the client) desires to display some information, 'the information is communicated to the server portion of the co-processor 200 which then stores the information in the shared memory 158. The graphics processor 160 then processes that information and stores it in the data memory 154 for display. In that manner, and under the control of the graphics processor 1.60, the plurality of displays, i.e., windows, is displayed on the CRT 151.
It will be understood by those skilled in the art that the X-window protocol is essentially the open interfcace standard, the X-window protocol being readily available and well known to those skilled in the art. In the preferred embodiment the UNIX operating system is utilized, the UNIX
operating system being able to run on many commercially available processors. Further information on the preferred embodiment of the graphics card 150 of the preferred embodi-ment of the US 122 can be had by reference to U.S. Patent Numbers 4,490,797 and 4,663,619, although it will be under-stood that any graphics card can be utilized as discussed above. The graphics processor 160 of the preferred embodiment of the present invention is a Texas Tnstruments (TI) TMS
34020. The microprocessor 156 and the module CPU 38 is a Docket No. I2000101 29 15 June 1992 ~Zgg~~6~
Motorola 68020. The co-processor 200 of the preferred embodiment of the present invention is a Motorola 68040, having bus capability with the other microprocessors of the system. %t will be understood that a variety of processors can be utilized including a reduced instruction set processor which is available from Hewlett Packard among other processor manufacturers.
Although the preferred embodiment utilizes the UNIX
operating system, it will be recognized by those skilled in the art that any operating system can be utilized, including OSF1, Open Systems Foundation/USA, Cambridge, Massachusetts.
Although the co-processor 200 is controlling the display in the preferred embodiment the graphics card can also perform the display control. Since X-windows was readily available and performed the desired display control function, X-windows was utilized to take advantage of the availability of the desired cantrol function. It will be recognized by those skilled in the art that implementation of the present inven-tion is not limited to X-windows, and that any protocol can be utilized.
Ttaus it can be seen that the process control system 10 is open system permitting other system to interface into the LCN
of the process control system and, because of the co~nunica-tion scheme as described above, thm integrity of the process control system 10 is maintained.
Further, if the co-processor 200 is running and control-Docket No. I2000101 30 15 .Tune 1992 '~~~'~J6 ling the display unit 151 (and in particular the actual display on the screen of the display unit 151) and a malfunc-tion occurs or some other anomaly occurs to the co-processor 200, the function of the graphics card 150 guarantees that a single view of the process control system is maintained. As discussed above, the co-processor is connected into the US 122 and has (and controls) a graphical interface through the display 1571 and keyboard 153.
Referring to Figure 8, which comprises Figures 8A and 8B, there is shown an example of two displays of the display unit 151. Figure 8A shows an example of a typical normal display and Figure 8H shows a display when an anomaly occurs with the co-processor 200, or the fallback display. Figure 8A shows, for example, the windows which can be displayed. xhe windows always include a "view of the process", i.e., a control view from the process control system 10. Also included can be, for example, a window showing event history (a process control system application) coming from an outside system, running a process control system application, for example a DEC computer system 300 as shown in Figure 5. Another window can be data carving from another outside computer system (not shown), for example such as an Apple computer. xhis computer system can be running another application pragra~a referred to as documen-tation (in the preferred embodiment of the process control system the documentation of the process control system is created on an Apple computer). Still another window can be Docket No. 12000101 31 15 June 1992 °
zo~~~6~
displayed, for example, lab data, coming from a Hewlett Packard computer system. The windows, eaccept for the control view, are displayed on a single screen of the display unit 151, the display information for these windows coming from a number of outside computer systems connected into the co-processor 200. If an error is detected with. the co-processor 200, the method of the present invention guarantees that the display windows from the outside systems are inhibited and the control view is the only display shown and is zoomed to take up the entire screen of the display unit 151. This observa-tion also serves as an indication to the operator that a malfunction has occurred with the interface to the outside systems.
The graphics card 150 has two input communications channels, as discussed above, a first channel is to the LCN
120 via the microprocessor 156/module bass 36 and a second channel is to the co-processor 200 via the microprocessor 156/card bus 152. The first channel is a fail safe channel and utilizes all the same mechanisms that is utilized by the LCN 120. The microprocessor 156 of graphics card 150 grants the communication of the first channel (i.e., the c~aannel to the LCN 120) a higher priority than that of the second channel. The data received from the first channel is main-tained securely by the graphics card 150 in order to insure that the co-processor 200 cannot corrupt that data, i.e., the co-processor 200 does not have direct access to the module Docket No. I2000101 32 15 June 1992 '~~1~'~~~~
memory 40 and the data memory 154.
The second channel provides, in the preferred embodiment of the present invention, the X-windows environment, i.e., the open systems OSF (Open Systems Foundation Standard). Also as has been mentioned above, the X-windows is a standard which defines a protocol between different computer systems to allow them to display from any of the computers connected to the display, thereby being able to achieve the windows display as discussed hereinunder in conjunction with Figure 0 In order to maintain the integrity of the process control system 10 the system includes those functions which guarantees that the control view will always be maintained. Therefore, if any malfunction occurs to the machines on the outside network to cause the co-processor 200 to malfunction (i.e., X-windows to crash), the control view is the primary (or fallback) view to the operator. The process control system 10 (i.e., the modules of the process control system l0 and specifically the operator station 122) takes control of the graphics and displays the control view. The reliability of the process control system is very high, thus it is highly certain that the control view can always be displayed. The control view display data comes from the ILCN totally indepen-dent of the co-processor 200 of the opens systems network.
However, everything else on the display comes from the open systems network. In the preferred embodiment the X-windows environment, the co-processor 200 is controlling the windows.
Docket No. I2000201 33 15 June 1992 '~09"~56~
The co-processor 200 is communicating with the graphics card 150, i.e., passing along all the data collected from the open systems network and passing along the control display informs-tion, thereby controlling the display. However the co-processor 200 is not drawing the control view, but is control-ling where on the screen the control view is displayed.
The display example of Figure 8 has all the display information and control information stored in the data memory 154 of graphics card 150. The control view data is inputted into the data memory 154 of graphics card 150 from the LCN 122 by a module bus 36 and microprocessor 156. All the display data of the other views is inputted to the graphics card 150 from the co-processor 200. This data is stored in the data memory 154 via card bus 152, shared memory 158, and graphics processor 160. The graphics processor 160 is processing the inputs and storing the results in the data memory 154 in a predetermined format consistent with the control commands from the co-processor 200 and in a format consistent with the information as is anticipated by the display unit 151.
While there has been shown what is considered the preferred embodiment of the present invention, it will be manifest that many changes and modifications can be made therein without departing from the essential scope and spirit of the invention. It is intended, therefore, in the annexed claims to cover all such changes and modifications that fall within the true scope of the invention.
Docket No. I2000101 34 15 June 1992
F3ACF<t~;E~OCJIyL7 ,y F' ,C,f.IF.:, >:1~'s?E"~'t'T~),d 'This invention relatc.;~ t<> distx ib:l1-~ed ciig.ital systems, anc~ more p;~r_t::i.cu:l.ar ~.y,, t-c.;~ yi;.;t r ?_k~u F.,ci tligs.t.al systems having a plur,~lit~y of rm~,~lec,.~<;u:,~:31r-ecl t::c> a net=.wc>rk for communicating between node s, why>reir:. a once ~~losed (ox-proprietary) network .i~u~ opened t..~ uerm:it. a rariet..y of nodes tc> bc> coupled to th~:e nc.~twc~r k .
There cur.rernt:ly f.,xi_st:~,, syTsk~envs ;~ua~.;i.r...~c~ ~~ ~,luxal.ity of nodes ops~:rativel~y c~::3nne.c.t.~.-.c.~ t'., ,:a k.~u~ ;.rv lEtwox'k :i.n which the nodes a.te develope~::~ ;;ay a s~.n~~l.t:= rnar,~.~f,=pct:«tw~r who enforces strict contro7_ over t.l"ue t.~lesi.gn ;~:f t_he nodes a.nd over the fur~et:ions tc~ k:>e ~~e:erfc~r.m~~ra x;y t r;..; rz.~cl~~s. Further, a predetermined protocol. is ~:at~i.7.a r c::~r.~ i~~~ tln=' nk.t~woz~k whictu results in a ~~ closed" envi t oment .
In order t=o .311ow a ~;ser the op~:ic::~n of selecting eduipment of other manufact:ure:., hr:uu i.rz<a iif °_e.ring pro t.ocols, and trnereby expand.i,~c:~ t:.he ~~apal.. a 1. :i. t irr:=s ~c7~:~i I-zxruc:tior.ality of these systems, it is d"s:ired to toac~e ar: "~~pt:er~" systerra envin_onment which per~rni.t:; t=.he ra fe.r' t. c:. c: ~~,r.~a;~'':t:
(directly or indirectly) these ec~m:L~~ment: ._ot ~.>~~r~f:~r rrnr.~i~~_rf:;:~~'t ~°~.rers having differing designs to tine network i~t the vys~.E:m. By opening up tree system to the;;e edur~prner;t.:~, glue ~~L-i~~i:~i.l:i.ty of the system is now suscept:i.kole to ~:my errors, (,bu~:~t.~, viru.ses,...) of the new equipment bei_n~:~ added wr: ick1 u~~ n,ot ;,rider the control of the manufacturer of th.e ~~y~~t:a~rra.
Thus, the present:. i.nvf-r-i.t. ~.or:~ Cr:~ . ~sr:i..~a~w, a methc;d for coupl ing open systems ~o a prcy:.x i r=t_ary nevtw~::vrk while maintaining the higln r~:~liabiLit..Y ~:kat t:rm~ :~~:~st:em had before opening up the enV_i:r_onmentr ~~kw ~::~k:o:~r:~ sy:>r~,rn:, iruc:lud:ing networks, computer pl.at.forms,... oa ot.tiex rnarn:fai~turers. By opensng the system, cor,unez:<~~i,~ll_~~ a~?a:..:La~:i~.r ~:t.ility software can be util_i.zed on true opeo~ .~~,> >_c-°~in: ':k ~:'~ ..t:,y iric.:;reasi.ng t:;~e software functionality of th~:a ~sy~>4~-gym.
n L.
;:pUMC~IAR~' a~l~' 'I"f~IE:, I. t~VF_;N 1' .:~.~>N
In acc:c~rcianc:~: w~_th 't to z .:, i..zzvcJ:c'1. ~ car. k pert: Ls provided a method f or proviai.n~.~ ran i_nt.~:.rfacr~ to S~ransfer data from a proprie'k.~r y ne ~wc:>rl; t. c:; .3r1 c,y,ezn 7y....5t:~:~rn, t.rue.~
proprietary network in;=ludi.ng ._a t Least: c:ne ~nc~~:aule cent: ral procassing ani't (CL?U) ~~rvc~ a rrzo~:k~a1 c~:: rr~~rczc;ry a ,r;c~c-;~
<:zted therewith oper_ative.l.y ~::onnecte~:~ t c.:~ tizr~ L:r~:priE~t.ao°y nEzi:.work, wherein a shared memory ~~n<i sh:ir~~d mercm~r.-y L~~e~:C.c~ tire interposed between the proLsz :i a ~ a r..y;, ne t wc. rh :~zncl t~ze c~~a~;~n system, the method corrpri_s.:ing k:h~=' ;steps c~f : ,_:r;~ ac:cepting requests fo:r data fr~>rc, tha-~ c~~~Pr~. ::y;_~tE~rr~ t~~ a para:;it~~.c:
task function within the module GfU; b) obt:.ainin~~ t:t~e data requested: c) placirz~~ t:he c.~at:a:~ i.n ~r ~~e:< ~.~e~t:errr~.l.rrec::l ~_oca;~tion of the module memory in a form underst:s~ridabl.e3 to the c.~pen systems; d) plac:inq ~ L:oairat:e.r ,r~.~:l.t:o.e~ i.fv t_,~~_~ .~~ni:3-E:~c~
memory, the pointer value containing tl,c~ v~~liar.:~ c:,( t:rh:e prE~detei.mined locar~ion of the modu.Le memory, ttee 5rza~:ed mc~mc>ry being mapped in the address>aC->le rnerrcor~~ :>Ca«ca~ c.~i: f ue sCuared n:~em.ory logic; and e) obtain the data cair_e~.~tl_~.,e aturn the module memory utilizing the pc~int.r=~r v<~ ~ ~.ac:~ ~:or re.~pc~crcwting t<., tree data requested.
Therefore, there is provided by the present invention, a method for coupling open systems to a proprietary network.
An interface provides a path to transfer data from a propri-etary network to an open system. The proprietary network includes at least one module control processing unit (CPU) and a module memory associated therewith operatively connected to the proprietary network. A shared memory and shared memory logic are interposed between the proprietary network, and the open system, thereby forming the data path. The method comprises the steps of accepting requests for data from the open system by a parasitic task function within the module CPU. The data requested of the proprietary network is obtained and placed in a predetermined location of the module memory in a form understandable to the open systems. A
pointer value is placed in the shared memory, the pointer value containing the value of the predetermined location of the module memory, the shared memory being mapped in the addressable memory space of the shar~:d memory logic using virtual memory techniques ., The data is obtained directly from the module memory utilizing the pointer vales corresponding to the data requested, thereby allowing caper systems to access the proprietary system while maintaining the integrity of the proprietary network.
Accordingly, it is an object of the present invention to ~~9~~~~~
provide a method of coupling open systems to a proprietary network.
It is another object of the present invention to provide.
a method of coupling open systems to a proprietary network wherein the open systems has access to data of the proprietary network.
It is yet another object of the present invention to provide a method of coupling open systems to a proprietary network wherein the open system has direct access to data of the proprietary network.
It is still another object of the present invention to provide a method of coupling open systems to a proprietary network wherein the open systems has direct access to data of the proprietary network on essentially a realtime basis.
It is a further object of the present invention to provide a method of coupling open systems to a proprietary network wherein the open system has direct access to data of the proprietary network while maintaining the integrity of the praprietary network.
These and other objects of the present invention will become more apparent when taken in conjunction with the following description and attached drawings, wherein like characters indicate like parts, and which drawings form a part of the present application.
Docket No. I2000101 5 15 June 1J9~
~~9'~~64 BR~FF DESCRIPTION OF TI-IF DRAWINGS
Figure 1 shows. a black diagram of a process control, system of the preferred embodiment in which the present invention can be utilizedo Figure 2 shows a block diagram of common elements of each physical module of the process control system of Figure 11 Figure 3 shows a functional block diagram of a typical physical module of the process control system;
Figure 4 shows a partial, functional block diagram of the existing system and the opened system of the preferred embodi-ment;
Figure 5 shows a functional block diagram of an open operator station of the preferred embodiment;
Figure 6 shows a block diagram of the proprietary network and the interface for coupling to open systems;
Figure 7 shows a block diagram of a graphics card of the preferred embodiment; and Docket No. I200~101 6 15 June 199x Figure 8, which comprises Figures 8A and 8~, shows examples of screen displays of the display unit of the process control system.
Docket No. 12000101 7 15 June 1992 DETAILED DESCRIPTION
Before describing the method of the present invention, it will be helpful in understanding a system environment in which the invention is utilized. Referring to Figure 1, there is shown a block diagram of a pracess control system 10 of the preferred embodiment in which the present invention can be found. The process control system 10 includes a plant control network 11, and connected thereto is a data highway 12, which peru~its a process contraller 20' to be connected thereto. In the present day process control system 10, additional process controllers 20' can be operatively connected to the plant control network 11 via a corresponding highway gateway 601 and a corresponding data highway 12. A process controller 20, an interface apparatus which includes many new, additions, improvements, and features over the process controller 20°, is operatively connected to the plant control network 11 via a universal control network (UUN) 14 to a network interface module (NIM) 602. In the preferred embodiment of the process control system 10, additional process controllers 20 can be operatively connected 'to the plant control network 11 via a corresponding UCN 14 and a corresponding NIM 602. The process controllers 20, 20' interface the analog input and output signals, and digital input and output signals (A/I, A/O, D/I, and D/O rasp~at~.vely) to the process control system 10 Prom the variety of Eield devices (not shown) of the process being Docket No. I2000101 8 1S June 1992 ~09'~~~4 controlled which include valves, pressure switches, pressure gauges, thermocouples,....
The plant control network (or more simply network) 11.
provides the overall supervision of the controlled process, in conjunction with the plant operator, and obtains all the information needed to perform the supervisory function, and includes an interface with the operator. The plant control network 11 includes a plurality of physical modules, which include a universal operator station (US) 122, an application module (AM) 124, a history module (F~i) 126, a computer module (CM) 128, and duplicates (backup or secondary) of these modules (and additional types of modules, not shown) as necessary to perform the required control/supervisory function of the process being controlled. Each of these physical modules is operatively connected to a local control network (hCN) 120 which permits each of these modules to communicate with each other as necessary. The NIM 602 and HG 601 provide an interface between the hCN 120 and the UCN 14, and the LCN
120 and the data highway 12, respectively.
Physical modules 122, 124, 126, 128,... of network 17. of the preferred embodiment are op various specialized functional types. Each physical module is the peer, or equivalent, of the other in terms, of right of, access to the network's communication medium, or hCN 120, for the purpose of transmit-ting data to other physical modules of network 11.
Docket No. I2000101 9 15 June 1992 Universal operator station module (US) 122 of network 11 is a work station for one or more plant operators. It includes an operator console which is the interface between.
the plant operator, or operators, and the process or processes of the plant for which they are responsible. Each universal operator station module 122, is connected to the LCN 120, and all communications between the universal operator station module 122, and any other physical module of network 1l, is via the hCN 120. Universal operator station m~dule 122 has access to data that is on the LCN 120 and the resources and data available through, or from, any of the other physical modules of network 11. The universal station module 122 includes a cathode ray tube display (CRT) (not shown) which includes a video display generator, an operator keyboard (KH) (not shown), a printer (PRT) (not shown), and can also include (but not shown) a cartridge disk data storage device, trend pen recorders, and status displays, for example.
A history module (Hilt) 126 provides mass data storage capability. The history module 126 includes at least one conventional disk mass storage device such as a Winchester disk, which disk storage device provides a large volume of nonvolatile storage capability for binary data. The types of data stored by such a mass storage device are typically trend histories, event histories, ....or data from which such histories can be determined, data that constitutes or forms CRT type displays, copies of programs for the physical Docket No. 12000101 10 15 June 1992 modules....
An application module (AM) 124 provides additional data processing capability in support of the process control.
functions performed by the controllers associated with the process control subsystem 20, 20' such as data acquisition, alarming, batch history collection, and provide continuous control computational facilities when needed. The data processing capability of the application anodule 124 is provided by a processor (not shown) and a memory (not shown) associated with the module.
Computer module (CM) 128 uses the standard or common units of all physical modules to permit a medium-to-large scale, general purpose data processing system to communicate with other physical modules of network 11 and the units of such modules over the LCN 120 and the units of process control subsystems 20, 20' via the highway gateway module 601, and the NIM 602, respectively. Data processing systems of a computer module 128 are used to provide supervisory, optimization, generalized user program preparation and execution of such programs in higher level program languages. Typically, the data processing systems of a computer module 128 have the capability of communicating with other such systems by a c~mmunication processor and communication lines.
The local control network 1211 (LCN) is a high-speed, bit serial, dual redundant communication network that intercon-nects all the physical modules of plant control network 11.
Docket No. I2000101 11 1~ June 1992 ~p9"d~6~
LCN 120 provides the only data transfer path between the principal sources of data, such as highway gateway module 601, application module 124, and history module 126, and principal.
users of such data, such as universal operator station module 122, computer module 128, and application module 124. LCN 120 also provides the communication medium over which large blocks of data, such as memory images, can be moved from one physical module such as history module 126 to universal station module 122. LCN 120 is dual redundant in that it consists of two coaxial cables that permit the serial transmission of binary signals over both cables.
Referring to Figure 2, there is shown a block diagram of the common elements of each physical module of the network 11 or the process control system 10. Rach of the physical modules includes a module central processor unit 38 and a module memory 40, a random-access memory (not shown) , and such additional controller devices, or units (not shown), which are configured to provide the desired functionality of that type of module, i.e., that of the operator station 122, for example. The data-processing capabilities of each module's CFU 38 and module memory 40 create a distributed processing environment which provides for improved reliability and performance of network 11 and process control system 10. The reliability of network 11 and system 10 is improved becaus~, if one physical module of network 11 fails the other physical modules will remain operational. As a result, network 11 as Docket No. I2000101 12 15 June 1992 2~9"~5~~
a whole is not disabled by such an occurrence as would be the case in centralized systems. Performance is improved by this distributed environment in that throughput and fast operator response times result from the increase computer processing resources, and the concurrency and parallelism of the data-processing capabilities of the system.
As mentioned above, each physical module includes the bus interface unit, BIU, 32 which is connected to the LCN 120 by the transceiver 34. Each physical module is also provided with the module bus 36 which, in the preferred embodiment, is capable of transmitting 16 bits of data in para11e1, between the module CPU 38 and the module memory 40. Other units, utilized to tailor each type of physical module to satisfy its functional requirements, are operatively connected to module bus 36 so that each such unit can communicate with the other units of the physical module via its module bus 36. The BTU
32 of the physical module initiates the transmission of data over LCN 120. In the preferred embodiment, all transmissions by a BIU 32 are transmitted over the coaxial cables which, in the preferred embodiment, form the LCN 120.
Referring to k"igure 3 there is shown a functional block diagram of a typical physical module 122, 124, 126, 128 of the plant control network 11, and includes the bus interface unit (BrU) 32 arid the transceiver 34, which connects BIU 32 to the LCN 120. BIU 32 is capable of transmitting binary data over LCN 120 and of receiving data from LCN 120. Transceiver 34 in Docket No. 12000101 13 1S June 19J2 ~~~9'~~6~
the preferred embodiment, is transformer coupled to the LCN
120. In the preferred embodiment, the LCPd 120 is a dually redundant coaxial cable with the capability of transmitting.
bit serial data. HIU 32 is provided with a very fast micro-engine 56. In the preferred embodiment, micro engine 56 is made up of bit slice components so that it can process eight bits in parallel, and can execute a 24 bit macroinstruction from its programmable read only memory (PROM) 58.
Signals received from the LCP~ 12o are transmitted by transceiver 34 and receive circuitry 52 to receive FIFO
register 54. Micro engine 56 examines the data stored in FIFO
register 54 and determines if the information is addressed to the physical module. If the data is an information frame, the received data is transferred by direct memory access (DMA) write circuitry 66 by conventional direct memory access technidues to the physical module memory unit (MMU) 40 over module bus 36.
Communication between MCPU pracessor 68, a Motorola 68020 microprocessor in the preferred embodiment, and other func-tional elements of MCPU 38 is via local microprocessor bus 39.
Module bus interface element 41 provides the communication link between local bus 39 and module bus 36. Processor 68 executes instructions fetched from either its local memory 43, in the preferred embodiment an EPROM, or from MMU 40.
Processor 68 has a crystal controlled clock 45 which produces clock pulses, or timing signals. Input/output (I/0) port 49 Docket rro. x2000101 14 15 June 199z 209' X64 provides communication between MCPU 38 and equipment external to the physical module to permit program loading, and the diagnosis of errors, or faults, for example.
Each MCPU 38 includes a timing subsystem 48 which, in response to clock signals from module clock 45 produces fine resolution, synchronization, and real-time, timing signals.
Any timing subsystem 48 which is provided with a timing subsystem driver 50, has the capability of transmitting timing information to other physical modules over the LCN 12~.
Another input to each timing subsystem 48, is timing informa-tion which is transmitted over LCN 120 and which is received through transceiver 34, timing receiver 55 and timing driver 57 of HxU 32. Timing pulses from module power supply 59 which are a function of the frequency of the external source of A.C.
electric power applied to power supply 59 are used by timing subsystem 48 to correct longer term frequency drift of the clock pulses produced by clock 45.
Additional information of the 81U 32 can be found in U.s.
Patent No. 4,556,974. A more detailed description of the process control system 10 can be had by referring to U.s.
Patent No. 4,607,256. Additional information of the individu-al, common, functional blocks of the physical modules can be had by reference to U.S. Patent No. 4,709,347, all of the above-identified patents being assigned to the assignee of the present application, and additional infarmation of the process controller 20° can be had by referencing U.s. Patent No.
Docket No. 12000101 15 15 June 1992 ~p9'~~6~
4,296,46.
The addition of an interface apparatus which interfaces other systems (i.e., open or foreign systems) to the process control system 10 described above, which includes providing the capability to readily permit nodes of differing designs to communicate to the network 120, will now be described. Also, specifically describes is a modification to a graphics generator in the US 122 which opens up the existing system, in particular the graphics interface.
Referring to Figure 4, there is shown a partial functional block diagram of the existing system and the open (or opened) system. The universal operator station (US) 122 is coupled to a co-processor 200, arid the co-processor is coupled to an open system, i.e., interfaces/protocols of differing design, including Transmission Control Protocol.
Internet Protocol (TCP/IP), open system interface (OSI), DECnet (a product of the Digital Equipment Corporation of Maynard, Massachusetts), Hewlett Packard personal computers, (HP),.... The universal station 122 is also connected to the LCN 120 as described above. Thus, the new universal operator station (open US) 123 includes the US 122 as described above in conjunction with the co-processor 200. The purpose of the open US 123 is to open the graphical interface to the open systems and to provide information from the closed US to the open systems. The co-processor 200 is structured to permit the interface to other systems, i.e., the open systems without Docket No. I2000101 16 15 June 1992 ~~9"~56~
jeopardizing the integrity of the existing system. The co-processor 200 of the preferred embodiment is a HIotorola ~8040 microprocessor which is executing the UNIX operating systems, (UNIX is an operating system of the American Telephone and Telegraph Company, ATT, is readily available and is well known to those skilled in the art), and is sometimes referred to as a UNIX co-processor.
Referring to Figure 5, there is shown a funo~tioraal block diagram of the open operator station 123 of the preferred embodiment. The operator station 122 as described above includes the BIU 32 connected to the module bus 36, the module memory 40, and the module CPU 38, both also connected to the module bus 36. These basic functional blocks are contained in all the physical modules. Additional functional blocks added to the physical module is what gives the physical module its personality apart from any other physical module. The operator station 122 includes a graphics card 150 which interfaces with a display (CRT) and a keyboard (RB) 151, 153.
A shared memory 202 is included and is also connected to the module bus 36 which provides for communication between the ca-processor 200 and the US physical module 122 (thereby providing communication to the rest of the process control system to via the module CPU 38). The method of communication between the module CPU 38 and the coprocessor essentially implements the method of the present invention whereby the open systems is coupled to the proprietary netwark. Thus, the Docket No. 12000101 17 15 June 1992 co-processor 200 requests service (e. g., the value of a point, contents of a file,... or any information of the process control system 10) of the module CPU 38 through shared memory.
202. The module CPU 38 then communicates with the appropriate module to perform the requested service in a normal fashion.
Once the response is obtained the information is passed to the co-processor 200 via shared memory 202. Since the module CPU
38 is cammunicating via the LCN 120, the integrity of the LCN
(i.e., the system) is maintained and similarly the module memory 40 cannot be corrupted by the co-processor 200.
although shared memory 202 is shown within the dotted lines of US 122 (dotted line A), it will be recognized by those skilled in the art that shared memory 202 can also be part of coprocessor 202 or a stand-alone unit interposed between the US 122 and coprocessor 200 (dotted line H). Such arrangements are essentially °°packaging°°
arrangements and have essentially no bearing of the function provided. The shared memary 202 (and associated circuitry, not spawn) provides for the direct coupling of an open systems processor (i.e., DEC, HP,...) to the process control system 10, thereby permitting the open systems processor to effectively function as a peer to the other physical modules or nodes of the network 120.
In this environment, the coprocessor 200 essentially has direct access to~ the module memory 40. Through this direct access, the coprocessor 200 can access and/or modify data in real time. (Hy convention, the coprocessor 200 is not permit-l7ocke~t No. I2000101 18 15 June 1992 ted to modify data in the module memory 40.) However, the module CPU 38 provides the interface which translates the proprietary LCN data to a farm usable by the open system and/or coprocessor 200.
Also shown in Figure 5 is an example open system (or foreign system), for example, a Digital Equipment Corporation system which includes the DECnet network and protocol and a DEC processor 300 attached to the DECnet network. xn the preferred embodiment, the communication between the DEC open system and the co-processor 200 is via an X-windows protocol (X-windows being a protocol defined by the Massachusetts institute of Technology, Cambridge, Massachusetts) for graphical display information, and other open systems stan-dards being used for data exchange. Any requests of the outside system to the LCN is made via the co-processor 200 through the shared memory 202 to the module CPU 38 as de-scribed above.
As mentioned above, the physical modules include common elements; however additional modules to each of the physical modules provides the °'personality" of the physical module.
The personality of the physical module provides the base environment for enhancements and improvements to the process control system 10 by the addition of the open systems. For example, the application module 124 of the process control system 10, exhibits a personality which provides for the complex control of process data through user programs. This Docket No. r2000101 19 15 June 1992 personality provides the basis for enhancement by the co-processor 200 by exploiting the computing capabilities of both the open system and the coprocessor 200 to further extend the.
programs through commercially available software such as spread sheet, data base manager,.... In the case of US 122, the personality is based on the graphics card 150. In the preferred embodiment, the coprocessor 200 provides the capability to enhance the display of the U~ 122 (and thereby enhancing the personality of the process control system 10) by utilising the advanced display capabilities of the coprocessor such as multiple display windows.
Referring to Figure 6, there is shown a block diagram of the proprietary network and the interface for coupling to ,open systems. The coupling to span systems is achieved through the use of the coprocessor 200A and shared memory 202A. Through this path, first channel 157, the c~processor 200A can see the module memory 40N and the shared memory 202A. Each module CPU
38 is executed and modifying data within its corresponding module memory 40. A module CPU 38 communicates that data among other module CPU°s by indicating where the data is located. In the process control system 10 {or bCN environ-ment) each module CPU knows the LCN protocol and therefore knows the data structure. The data exchange is communicated between other module CPU or between tasks within the same module CPU via messages which are essentially pointers indicating where the data is located. The data can also be ~ocket No. I2000101 20 15 June 1992 'zo9~~e~
passed to another node by actually passing the data value itself. In the process of connecting open system to the proprietary network, an objective is to maintain high reli-ability of the proprietary network. In response to a request from the open system through the coprocessor 200A, data can be sent to the open system; however, the data can subsequently change so that the original requester does not always have the latest value of the data, i.e., the data is transitory.
Shared memory is utilized so that the open system can have direct access to the data location, the data location being the only copy of the data thereby ensuring that the open system always has access to the latest data value.
The structure of the physical modules, in particular the module CPU 38, is such that various tasks are executing under the control of an operating system. In order to minimize the impact to the physical module and thereby potentially intro-ducing new errors and reducing the reliability, the interface communication is achieved by adding a new task in the module CPU 38, the new task performing a parasitic function. The newly added task intercepts data between tasks or between nodes and passes the data to the open system before the originally intended recipient has,acceas to the data. Thus, the open system can use/modify the data and then pass it on to the originally intended recipient (or assume the role of the intended recipient with respect to the data). The direct access to the module memory 40 by the coprocessor 200 is Docket No. 12000101 21 15 June 1932 achieved through the use of shared memory, the coprocessor mapping the shared memory in its addressable memory location.
Thus the coprocessor only has access to the data of the module memory in which it has knowledge of where the data is located within module memory through a pointer in the shared memory 202. The coprocessor mapping is achieved via virtual memory mapping techniqtaes well known those skilled the art. The newly added task performs the loading of the pointers in the shared memory and also performs a translation of the data in the module memory such that the data is meaningful to the open system.
The coprocessor 200 also communicates directly to the graphics card 150 by a direct path, second channel, 159 essentially the same as the communication between the co-processor 200 and shared memory 202. The interface consists of two distinct elements that are coupled through a shared memory 158 on the graphics card 150. A first logic element or task which implements the communication function is executed by the coprocessor 200 connected to the card bus 152. The first logic element executes on the graphics card, i.e., a graphics processor 160. When the second logic element is started, the shared memory 158 is memory mapped into the address range of the second element address range. The second element executing in the coprocessor 200, after the graphics card 1.50 is started, loads the graphics processor 160 with the necessary program functions stored in the coprocessor 200.
Docket No. 7L2000101 22 15 June 192 ~~'~'~56~
The second element executing in the coprocessor 200 passes messages to the graphics processor 160 through the shared memory 158 of graphics card 150. Messages are passed with the.
use of pointers, the pointers being kept in a structure of the shared memory 158 with both the coprocessor 200 addressing and the graphics processor 160 addressing. Through the use of passing messages, the control of the display unit is per°
formed, including various data information, command informa-tion, and validation or status checks. These checks and validations are described in related application b.
It will be recognized by those skilled in the art that various configurations may be implemented in capturing the spirit and scope of the present invention. For example the coproc~ssor 200A can have additional channels to the open systems. Additional coprocessors 2008 with corresponding shared memory 2028 can be interfaced to any of the physical modules. Further since the module CPU 38 can communicate via the LCN 120 with any of the other physical modules the need to interface a coprocessor 200 and shared memory 202 to an individual physical module is unnecessary since, as mentioned above the module CPU 38 can communicate with any other physical modules on the LCN 120. The co-processor 200A is shown interfacing w~.th the physical module N, the physical module being the universal station 122. This is indicated by the graphics card 150 b~ing attached to the module bus 36N, the graphics card giving the physical module the personality Docket No. I2000101 23 15 June 1992 ~0~'~~~~
as discussed above. The coprocessor 200A interfaces to the open system via an open system protocol, in the specific example and in the preferred embodiment the X--windows proto-col. In a similar fashion coprocessor 2008 interfaces to the open system, in this case an HP computer platform using a predefined available protocol. By providing the logic within the coprocessor and within the newly added task added to the various module CPU°s, the interface with the proprietary LCN
network is thereby achieved.
The module CPU 38 executes a set of tasks under an operating system. These tasks execute the variaus tasks and utilize existing interfaces to access the location of and movement of data within the process Control system l0. The primary function of these tasks is to provide the predetermine functions consistent with the personality of the physical module. In addition, the present invention adds a task for implementing the method of the present invention which services requests for data by the copracessor 200. In addition, the newly added task provides a translation of the process control system data (or LCN data) usable by the copracessor 200. The newly added task executes the requested service in the module CPU 38 and passes a pointer to the coprocessor by a shared memory 202 so that the coprocessor does not have to wait for a copy of the data. This also insures uniqueness through use of a single copy of the data when it is maintained dynamically by the module CPU 38, or any Docket No. 12000101 24 15 ,3une 1992 ~zoo~~s~
other physical module of the process control system 10. The pointer value passed to the coprocessor 200, paints to a virtual memory location in which the module memory 40 is mapped. Thus, the coprocessor 200 can directly access module memory 40 utilizing the point of value, 'the data having been translated by the module CPU 38 into a form compatible with and usable by the coprocessor 200. The coprocessor 200 can have more than a single request from more than a single requestor of the open systems. Tn such case, the shared memory 202 is mapped into a virtual memory format allocating virtual memory space for the various requestors.
The coprocessor 200 includes logic which interfaces with and communicates with the newly added task of the module CPU
38. The coprocessor 200 logic perforaas functions to utilize and conform to establish industry standard interfaces re-cognizied by the commercial software. In this interface the software functions as a server which provides a unique interface path for module CPU 38 for each program of the open system that requests its services. An application software package which executes on the coprocessor 200 is designed and implemented using commercial tools, software utilities, and data libraries. The application is designed to utilize the capabilities afforded by the commercial software to perform service neat available on tha process control system 10. such services may include access of data on multiple open system computer platforms within the outside systems environment Docket No. 12000101 25 15 June 1992 yn~~ ~~~
which are not compatible with the process control system 10 environment. These services are combined with the capability to access the process control system data needed to perform the application. Functionally, each application software program utilizes a defined set of generic or general purpose requests to access process control system data and functions.
These requests utilize industries standard data format representations that is easily exchanged with and manipulated by commercial software programs. The interface function of the coprocessor 200 provides the service of passing these requests to the process control system physical module. The module CPU 38 of the physical module translates the service to its proprietary LCN form and executes the request. The response is returned to the requesting open system by the coprocessor 200 in a form which the application software can interpret.
It is also desired to open up the graphics interface such that a display which is not on the LCN can be displayed onto the CRT 151 of the U8 122. This is achieved by the interface to the graphic card 150 from the co-processor 200. Referring to Figure 7, there is shown a block diagram of the graphics card 150 of the preferred embodiment. The graphics card includes a card bus 152. Attached to the card bus 152 is a data memory 154 which contains the information which is to be displayed onto the CRT, and also contains some control information. A microprocessor 156 is also coupled to the card Docket No. 12000101 26 15 June 1992 '~~1~~~~~~
bus 152 and further is coupled to the module bus 36. A
graphics processor 160 is coupled to the card bus 152 and performs all the processing for developing the information stored in the data memory 154, including some control func-Lions. A shared memory 158 is coupled to the card bus 152.
A connection is made from the card bus 152 to the co-processor 200, thereby providing the interface mentioned above to the graphics card 150 from the co-processor 200. The microproces-sor 156 of the preferred embodiment of the graphic card 15 is a Motorola 68020 processor. The graphics card 150 is a two port graphics card, one port of the graphics card being tied to the module bus 36 which is how a display is driven from LCN. The LCN 120 provides a "single window to the process,"
i.e., a screen display of what the process/process control system is doing. The second port is coupled to the ca-processor 200 and provides the windows interface for the universal station 122. The windows interface is the X-windows interface which is well defined and well known to those skilled in the art (the interface being defined by MIT, Cambridge, Massachusetts). It is through the interface from the co-processor 200 that all the window displays [i.e., the screen display(sj of the open system(sj] and windows controls are performed, including commands to the graphic card 150 to specify where to place the single window to the process on the screen of the CRT 151. The interface between the graphics card 150 and the ca-processor 200 is the full windows inter-Docket No. I2000101 27 15 June 1992 2~9'~56~
face. One of the windows is the display referred to above as the '°single window to the processor°' (sometimes referred to as the LCN window). The co-processor 200 commands the graphics.
card 150 where the LCN window is to be placed on the CRT 151 and its relative size on the display. X-windows is a well defined protocol of how to communicate with the graphics card 150 (or any graphics card) and display, and a computer permitting many windows to be displayed. This includes displaying at least one window from the LCN and/or at least one window from the open system 300. In this system, a server is defined in X-windows as the machine that is driving the display (or that portion of the co-processor 200 which interfaces to the graphics card 150), and a client is the application program, in the present embodiment, the DEC
processor 300.
The client 300 can have data which is desired to be displayed. The client 300 communicates with the server portion of the co-processor 200 through an X-windows protocol indicating data to be displayed. .The server portion of the co-processor 200 communicates with the graphics card 150 through a device dependent layer (DDL) and is provided by the vendor of the graphics card, or in X-windows is via DDX
protocol. The microprocessor 156 maintains the integrity of the card bus 152 into the data memory 154. The processing of the data to be displayed on the CRT 151 is performed by the graphics processor 160. HThen a predetermined data screen is Docket No. I2000101 26 15 June 192 c to be displayed, the microprocessor 156 (which accepts requests from the LCN 120 via module bus 36) places the data in shared memory 158, and is subsequently processed by the.
graphics processor 160, and is then stored in data memory 154.
When the open system 300 (via the client) desires to display some information, 'the information is communicated to the server portion of the co-processor 200 which then stores the information in the shared memory 158. The graphics processor 160 then processes that information and stores it in the data memory 154 for display. In that manner, and under the control of the graphics processor 1.60, the plurality of displays, i.e., windows, is displayed on the CRT 151.
It will be understood by those skilled in the art that the X-window protocol is essentially the open interfcace standard, the X-window protocol being readily available and well known to those skilled in the art. In the preferred embodiment the UNIX operating system is utilized, the UNIX
operating system being able to run on many commercially available processors. Further information on the preferred embodiment of the graphics card 150 of the preferred embodi-ment of the US 122 can be had by reference to U.S. Patent Numbers 4,490,797 and 4,663,619, although it will be under-stood that any graphics card can be utilized as discussed above. The graphics processor 160 of the preferred embodiment of the present invention is a Texas Tnstruments (TI) TMS
34020. The microprocessor 156 and the module CPU 38 is a Docket No. I2000101 29 15 June 1992 ~Zgg~~6~
Motorola 68020. The co-processor 200 of the preferred embodiment of the present invention is a Motorola 68040, having bus capability with the other microprocessors of the system. %t will be understood that a variety of processors can be utilized including a reduced instruction set processor which is available from Hewlett Packard among other processor manufacturers.
Although the preferred embodiment utilizes the UNIX
operating system, it will be recognized by those skilled in the art that any operating system can be utilized, including OSF1, Open Systems Foundation/USA, Cambridge, Massachusetts.
Although the co-processor 200 is controlling the display in the preferred embodiment the graphics card can also perform the display control. Since X-windows was readily available and performed the desired display control function, X-windows was utilized to take advantage of the availability of the desired cantrol function. It will be recognized by those skilled in the art that implementation of the present inven-tion is not limited to X-windows, and that any protocol can be utilized.
Ttaus it can be seen that the process control system 10 is open system permitting other system to interface into the LCN
of the process control system and, because of the co~nunica-tion scheme as described above, thm integrity of the process control system 10 is maintained.
Further, if the co-processor 200 is running and control-Docket No. I2000101 30 15 .Tune 1992 '~~~'~J6 ling the display unit 151 (and in particular the actual display on the screen of the display unit 151) and a malfunc-tion occurs or some other anomaly occurs to the co-processor 200, the function of the graphics card 150 guarantees that a single view of the process control system is maintained. As discussed above, the co-processor is connected into the US 122 and has (and controls) a graphical interface through the display 1571 and keyboard 153.
Referring to Figure 8, which comprises Figures 8A and 8B, there is shown an example of two displays of the display unit 151. Figure 8A shows an example of a typical normal display and Figure 8H shows a display when an anomaly occurs with the co-processor 200, or the fallback display. Figure 8A shows, for example, the windows which can be displayed. xhe windows always include a "view of the process", i.e., a control view from the process control system 10. Also included can be, for example, a window showing event history (a process control system application) coming from an outside system, running a process control system application, for example a DEC computer system 300 as shown in Figure 5. Another window can be data carving from another outside computer system (not shown), for example such as an Apple computer. xhis computer system can be running another application pragra~a referred to as documen-tation (in the preferred embodiment of the process control system the documentation of the process control system is created on an Apple computer). Still another window can be Docket No. 12000101 31 15 June 1992 °
zo~~~6~
displayed, for example, lab data, coming from a Hewlett Packard computer system. The windows, eaccept for the control view, are displayed on a single screen of the display unit 151, the display information for these windows coming from a number of outside computer systems connected into the co-processor 200. If an error is detected with. the co-processor 200, the method of the present invention guarantees that the display windows from the outside systems are inhibited and the control view is the only display shown and is zoomed to take up the entire screen of the display unit 151. This observa-tion also serves as an indication to the operator that a malfunction has occurred with the interface to the outside systems.
The graphics card 150 has two input communications channels, as discussed above, a first channel is to the LCN
120 via the microprocessor 156/module bass 36 and a second channel is to the co-processor 200 via the microprocessor 156/card bus 152. The first channel is a fail safe channel and utilizes all the same mechanisms that is utilized by the LCN 120. The microprocessor 156 of graphics card 150 grants the communication of the first channel (i.e., the c~aannel to the LCN 120) a higher priority than that of the second channel. The data received from the first channel is main-tained securely by the graphics card 150 in order to insure that the co-processor 200 cannot corrupt that data, i.e., the co-processor 200 does not have direct access to the module Docket No. I2000101 32 15 June 1992 '~~1~'~~~~
memory 40 and the data memory 154.
The second channel provides, in the preferred embodiment of the present invention, the X-windows environment, i.e., the open systems OSF (Open Systems Foundation Standard). Also as has been mentioned above, the X-windows is a standard which defines a protocol between different computer systems to allow them to display from any of the computers connected to the display, thereby being able to achieve the windows display as discussed hereinunder in conjunction with Figure 0 In order to maintain the integrity of the process control system 10 the system includes those functions which guarantees that the control view will always be maintained. Therefore, if any malfunction occurs to the machines on the outside network to cause the co-processor 200 to malfunction (i.e., X-windows to crash), the control view is the primary (or fallback) view to the operator. The process control system 10 (i.e., the modules of the process control system l0 and specifically the operator station 122) takes control of the graphics and displays the control view. The reliability of the process control system is very high, thus it is highly certain that the control view can always be displayed. The control view display data comes from the ILCN totally indepen-dent of the co-processor 200 of the opens systems network.
However, everything else on the display comes from the open systems network. In the preferred embodiment the X-windows environment, the co-processor 200 is controlling the windows.
Docket No. I2000201 33 15 June 1992 '~09"~56~
The co-processor 200 is communicating with the graphics card 150, i.e., passing along all the data collected from the open systems network and passing along the control display informs-tion, thereby controlling the display. However the co-processor 200 is not drawing the control view, but is control-ling where on the screen the control view is displayed.
The display example of Figure 8 has all the display information and control information stored in the data memory 154 of graphics card 150. The control view data is inputted into the data memory 154 of graphics card 150 from the LCN 122 by a module bus 36 and microprocessor 156. All the display data of the other views is inputted to the graphics card 150 from the co-processor 200. This data is stored in the data memory 154 via card bus 152, shared memory 158, and graphics processor 160. The graphics processor 160 is processing the inputs and storing the results in the data memory 154 in a predetermined format consistent with the control commands from the co-processor 200 and in a format consistent with the information as is anticipated by the display unit 151.
While there has been shown what is considered the preferred embodiment of the present invention, it will be manifest that many changes and modifications can be made therein without departing from the essential scope and spirit of the invention. It is intended, therefore, in the annexed claims to cover all such changes and modifications that fall within the true scope of the invention.
Docket No. I2000101 34 15 June 1992
Claims (3)
- Claim 1. A method for providing an interface to transfer data.
from a proprietary network to an open system, the proprietary network including at least one module central processing unit (CPU) and a module memory associated therewith operatively connected to the proprietary network, wherein a shared memory and shared memory logic are interposed between the proprietary network and the open system, the method comprising the steps of:
a) accepting requests for data from the open system by a parasitic task function within the module CPU;
b) obtaining the data requested;
c) placing the data in a predetermined location of the module memory in a form understandable to the open systems;
d) placing a pointer value in the shared memory, the pointer value containing the value of the predetermined location of the module memory, the shared memory being mapped in the addressable memory space of the shared memory logic;
and e) obtain the data directly from the module memory utilizing the painter value corresponding to the data request-ed. - Claim 2. A method for providing an interface according to Claim 1, wherein the shared memory logic is a coprocessor having a processor and memory, the coprocessor communicating with the open system via a known predetermined protocol.
- Claim 3. A method for providing an interface according to Claim 1 wherein the memory mapping utilizes virtual memory mapped techniques.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US89944292A | 1992-06-16 | 1992-06-16 | |
| US07/899,442 | 1992-06-16 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2097564A1 CA2097564A1 (en) | 1993-12-17 |
| CA2097564C true CA2097564C (en) | 2004-05-25 |
Family
ID=25410984
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002097564A Expired - Fee Related CA2097564C (en) | 1992-06-16 | 1993-06-02 | Method of coupling open systems to a proprietary network |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US5530844A (en) |
| EP (1) | EP0575144B1 (en) |
| JP (1) | JP3293073B2 (en) |
| AU (1) | AU657223B2 (en) |
| CA (1) | CA2097564C (en) |
| DE (1) | DE69328132T2 (en) |
Families Citing this family (26)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2699305B1 (en) * | 1992-12-11 | 1995-01-13 | Bull Sa | Device for using pseudo remote communication point functions (pseudo sockets). |
| US5706432A (en) * | 1993-11-04 | 1998-01-06 | International Business Machines Corporation | Mechanism for receiving messages at a coupling facility |
| US5742845A (en) | 1995-06-22 | 1998-04-21 | Datascape, Inc. | System for extending present open network communication protocols to communicate with non-standard I/O devices directly coupled to an open network |
| US5758125A (en) * | 1995-12-28 | 1998-05-26 | Newframe Corporation Ltd. | Method of sharing data in a heterogeneous computer system |
| US6233660B1 (en) | 1996-02-16 | 2001-05-15 | Emc Corporation | System and method for emulating mainframe channel programs by open systems computer systems |
| US5867673A (en) * | 1996-10-07 | 1999-02-02 | Honeywell Inc. | Universal operator station module for a distributed process control system |
| US7013305B2 (en) | 2001-10-01 | 2006-03-14 | International Business Machines Corporation | Managing the state of coupling facility structures, detecting by one or more systems coupled to the coupling facility, the suspended state of the duplexed command, detecting being independent of message exchange |
| US6294982B1 (en) * | 1999-02-10 | 2001-09-25 | Symon Communications, Inc. | Visual messaging system for high speed networks |
| US6545591B2 (en) | 1999-02-10 | 2003-04-08 | Symon Communications, Inc. | Apparatus for providing power to a visual messaging system for high-speed networks |
| KR100376924B1 (en) * | 1999-04-09 | 2003-03-20 | 미쓰비시덴키 가부시키가이샤 | Cpu unit of programmable controller and operation proxy control method |
| US6400810B1 (en) | 1999-07-20 | 2002-06-04 | Ameritech Corporation | Method and system for selective notification of E-mail messages |
| US6438215B1 (en) | 2000-02-29 | 2002-08-20 | Ameritech Corporation | Method and system for filter based message processing in a unified messaging system |
| US6498835B1 (en) | 2000-02-29 | 2002-12-24 | Ameritech Corporation | Method and system for providing visual notification in a unified messaging system |
| US6487278B1 (en) | 2000-02-29 | 2002-11-26 | Ameritech Corporation | Method and system for interfacing systems unified messaging with legacy systems located behind corporate firewalls |
| US7899690B1 (en) | 2000-08-18 | 2011-03-01 | The Crawford Group, Inc. | Extended web enabled business to business computer system for rental vehicle services |
| US8600783B2 (en) | 2000-08-18 | 2013-12-03 | The Crawford Group, Inc. | Business to business computer system for communicating and processing rental car reservations using web services |
| US7275038B1 (en) * | 2000-08-18 | 2007-09-25 | The Crawford Group, Inc. | Web enabled business to business operating system for rental car services |
| US6993506B2 (en) | 2000-12-05 | 2006-01-31 | Jgr Acquisition, Inc. | Method and device utilizing polymorphic data in e-commerce |
| DE10162986B4 (en) * | 2001-12-20 | 2004-01-15 | Siemens Ag | Connection of networks with different protocols |
| US8108231B2 (en) | 2002-06-14 | 2012-01-31 | The Crawford Group, Inc. | Method and apparatus for improved customer direct on-line reservation of rental vehicles |
| US20040039612A1 (en) | 2002-06-14 | 2004-02-26 | Neil Fitzgerald | Method and apparatus for customer direct on-line reservation of rental vehicles |
| JP2006053629A (en) * | 2004-08-10 | 2006-02-23 | Toshiba Corp | Electronic equipment, control method and control program |
| US8271309B2 (en) | 2006-03-16 | 2012-09-18 | The Crawford Group, Inc. | Method and system for providing and administering online rental vehicle reservation booking services |
| US7970943B2 (en) * | 2007-08-14 | 2011-06-28 | Oracle International Corporation | Providing interoperability in software identifier standards |
| GB2601081B (en) * | 2016-10-24 | 2022-09-28 | Fisher Rosemount Systems Inc | Systems and methods for merging modular control systems into a process plant |
| KR20190115811A (en) * | 2018-04-04 | 2019-10-14 | 에스케이하이닉스 주식회사 | The data processing system including expanded memory card |
Family Cites Families (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5109483A (en) * | 1987-06-15 | 1992-04-28 | International Business Machines Corp. | Node initiating xid exchanges over an activated link including an exchange of sets of binding signals between nodes for establishing sessions |
| US5185877A (en) * | 1987-09-04 | 1993-02-09 | Digital Equipment Corporation | Protocol for transfer of DMA data |
| KR920001576B1 (en) * | 1987-09-09 | 1992-02-18 | 가부시끼가이샤 도시바 | Network system using token-passing bus with multiple priority levels |
| AU3348489A (en) * | 1988-02-05 | 1989-08-25 | Commodore-Amiga, Inc. | Universal connector device |
| US5163138A (en) * | 1989-08-01 | 1992-11-10 | Digital Equipment Corporation | Protocol for read write transfers via switching logic by transmitting and retransmitting an address |
| US5163131A (en) * | 1989-09-08 | 1992-11-10 | Auspex Systems, Inc. | Parallel i/o network file server architecture |
| US5150472A (en) * | 1989-10-20 | 1992-09-22 | International Business Machines Corp. | Cache management method and apparatus for shared, sequentially-accessed, data |
| DE69029084D1 (en) * | 1990-02-27 | 1996-12-12 | Ibm | Message routing device by several computers that are coupled by means of a shared intelligent memory |
| AU628753B2 (en) * | 1990-08-14 | 1992-09-17 | Digital Equipment Corporation | Method and apparatus for implementing server functions in a distributed heterogeneous environment |
| US5377191A (en) * | 1990-10-26 | 1994-12-27 | Data General Corporation | Network communication system |
| US5404445A (en) * | 1991-10-31 | 1995-04-04 | Toshiba America Information Systems, Inc. | External interface for a high performance graphics adapter allowing for graphics compatibility |
| US5289575A (en) * | 1991-11-22 | 1994-02-22 | Nellcor Incorporated | Graphics coprocessor board with hardware scrolling window |
| JP2760731B2 (en) * | 1992-04-30 | 1998-06-04 | 株式会社東芝 | External interface circuit for high-performance graphics adapter that enables graphics compatibility |
-
1993
- 1993-06-02 CA CA002097564A patent/CA2097564C/en not_active Expired - Fee Related
- 1993-06-09 AU AU40140/93A patent/AU657223B2/en not_active Ceased
- 1993-06-15 DE DE69328132T patent/DE69328132T2/en not_active Expired - Fee Related
- 1993-06-15 EP EP93304648A patent/EP0575144B1/en not_active Expired - Lifetime
- 1993-06-16 JP JP16843193A patent/JP3293073B2/en not_active Expired - Fee Related
-
1994
- 1994-02-10 US US08/194,777 patent/US5530844A/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| DE69328132T2 (en) | 2000-11-09 |
| AU657223B2 (en) | 1995-03-02 |
| JPH06337834A (en) | 1994-12-06 |
| DE69328132D1 (en) | 2000-04-27 |
| JP3293073B2 (en) | 2002-06-17 |
| EP0575144A1 (en) | 1993-12-22 |
| AU4014093A (en) | 1993-12-23 |
| CA2097564A1 (en) | 1993-12-17 |
| US5530844A (en) | 1996-06-25 |
| EP0575144B1 (en) | 2000-03-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2097564C (en) | Method of coupling open systems to a proprietary network | |
| EP0575150B1 (en) | Method for controlling window displays in an open systems windows environment | |
| EP1276026B1 (en) | Object oriented Internet interface for industrial controller | |
| CA2097558C (en) | Directly connected display of process control system in an open systems windows environment | |
| US6732191B1 (en) | Web interface to an input/output device | |
| US7058693B1 (en) | System for programming a programmable logic controller using a web browser | |
| US6151625A (en) | Internet web interface including programmable logic controller for controlling output devices based on status of input devices | |
| EP1188293B1 (en) | Dual ethernet stack for maximum speed access to a plc | |
| US6061603A (en) | System for remotely accessing an industrial control system over a commercial communications network | |
| US8291121B2 (en) | System and method for interfacing with a controller | |
| JP5444312B2 (en) | Method, system, and machine accessible medium for automatically generating a script for writing data to a process control system | |
| CN100452027C (en) | Self-contained network browser with diagnostic function | |
| WO1994029788A1 (en) | A method for utilizing a low resolution touch screen system in a high resolution graphics environment | |
| US20010003804A1 (en) | Web interface to a programmable controller | |
| EP0575145B1 (en) | Open distributed digital control system | |
| EP0770958A1 (en) | WinSock network socket driver subsystem and method for windows emulator running under unix operating system | |
| AU5191501A (en) | Web interface to an input/output device | |
| JPH05334272A (en) | Monitoring and operating method for plural electronic computers | |
| CN117596143A (en) | Real-time virtualization architecture and platform integrating computing and network | |
| EP0575147A2 (en) | Device dependent layer of a windowing system for a process control system display | |
| AU2007202547A1 (en) | Web interface to an input/output device | |
| JPH0659997A (en) | System for corresponding to abnormality in inter-program communication system | |
| JPH0242850A (en) | Protocol verifing system | |
| JPH01288953A (en) | Terminal equipment control system for on-line processing system | |
| JPH0746295A (en) | Communication control method |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |