Plaque It!
Sponsored by: Flash of Genius |
[0001] The present invention relates generally to an arrangement, storage medium and method for associating an Extensible Stylesheet Language (“XSL”) Device Description file with a non-proprietary language Device Description file. In particular, the present invention is directed to an arrangement, storage medium and method in which processing system associates the XSL Device Description file with the non-proprietary language Device Description file, with each of the non-proprietary language Device Description file and the XSL Device Description file being associated with a field device, and the XSL Device Description file including a script-type language source code.
[0002] Conventional arrangements used by processing plants generally include a number of smart field devices (e.g., temperature sensors, pressure sensors, flow-rate sensors, etc.) which control and measure parameters within a process. Each such smart field device can include several function blocks. For example, the smart field device may include one or more input blocks, output blocks, and/or control blocks. Each block of the smart field device can include one or more parameters (e.g., an attribute of the block which characterizes, affects, or relates to the block). For example, parameters can describe whether the block is an input block, an output, or a control block. The parameters can also describe the maximum operating/measurement range of the block, the mode of the block, the value of the block measurement, etc. Moreover, each parameter includes one or more properties, and each property may describe a portion of the information associated with the parameter. For example, these properties can describe the name of the parameter (e.g., temperature), the value (e.g., a temperature) measured by the smart field device, the units in which the measured value is expressed (e.g., degrees centigrade or degrees Fahrenheit), etc.
[0003] Moreover, Device Description Languages (“DDL”), DDL source files, and Device Description Services have been developed to allow a user (e.g., an employee of the processing plant) to communicate with various smart field devices which are used in the process. The DDL Language is a human-readable language that provides, for example, a protocol for describing the data available from a particular smart field device, the meaning of the data retrieved from such smart field device, the format for communicating with the smart field device to obtain data, user interface information about this device (e.g., displays and menus), parameters of the field device, etc. Nevertheless, it will be understood by those of ordinary skill in the art that a Device Description can provide any information associated with the field device, such as any information used to implement the field device. The DDL source file is a human-readable text that is generally written by developers working on the smart field device. In order to generate the DDL source file for a particular smart field device, the developer can use the DDL to describe core parameter that are characteristics of the device. For example, different DDL source files may be associated with various types of the smart field devices (e.g., one DDL source file may be associated with a first pressure sensor, and another DDL source file can be associated with a second pressure sensor).
[0004] In the conventional arrangements, the source code of the DDL source file is generally compiled into binary format using a tokenizer to generate a machine-readable file known as a binary coded device description file. Each binary coded Device Description file may be forwarded to a developer of a host application. Alternatively, in the case when a particular protocol e.g., PROFIBUS™ protocol is used, the source code of the source file is forwarded to the developer of such application. Subsequently, the developer can develop the host application, and may also make available the host application, the binary coded Device Description files and/or the source code of the DDL source files to an end user. Moreover, the end user may record the binary coded Device Description files and/or the source code of the DDL source files on a storage device of a host processing system (e.g., memory, hard drive, etc.), and the host processing system can decode the binary coded Device Description file and/or the source code of the DDL source files using the interpreter Device Description Service. The host processing system may then display the decoded information to the end user.
[0005] Nevertheless, in the conventional arrangements, the binary coded Device Description file and/or the source code of the DDL source file associated with each type of the smart field devices are generally stored on the storage device of the host processing system, which may decrease the amount of memory or recordable space available to the host processing system for implementing additional applications. Further, the end user generally continuously downloads or installs the most recent version of the binary coded Device Description file and/or the source code of the DDL source file whenever the binary coded Device Description file or the source code is modified or updated. Moreover, the developer of the host application must purchase the interpreter in order to develop the host application. Nevertheless, the developer may be unable to purchase the interpreter, e.g., only a particular company may have access to the interpreter for a particular open smart communication protocol.
[0006] Therefore, a need has arisen to provide an arrangement and method for converting a proprietary language Device Description file and/or a DDL source code associated with a field device into a non-proprietary language Device Description file, and for associating an Extensible Stylesheet Language (“XSL”) Device Description with the non-proprietary language Device Description file, thus overcoming the above-described and other shortcomings of the prior art.
[0007] One of the advantages of an arrangement and method according to the present invention, a proprietary language Device Description file and/or a Device Description language (“DDL”) source code associated with a field device may be converted into a non-proprietary language Device Description file. An Extensible Stylesheet Language (“XSL”) Device Description file including a script-type language source code can be associated with the non-proprietary language Device Description file. The script-type language source code may include code associated with one or more techniques for implementing the field device and/or one or more functions performed by the field device. Moreover, the non-proprietary language Device Description file and the XSL Device Description file can be transmitted to the host processing system. The host processing system (e.g., a parser of the host processing system) may convert the non-proprietary language Device Description file and the XSL Device Description file into a platform-independent file/page having the script-type language source code embedded therein.
[0008] The platform-independent file/page also may include a link to the one or more methods for implementing the field device and/or one or more functions performed by the field device. When the link is selected by the user of the host processing system, the host processing system may execute the script-type language source code. Consequently, the host processing system does not have to receive and download the proprietary language Device Description file, thus increasing the amount of storage that may be available to the host processing system for implementing additional applications. Further, the host processing system does not need to continually download or install the most recent version of the proprietary language Device Description file and/or the DDL source code associated with the field device when the proprietary language Device Description file and/or the DDL source code is modified.
[0009] This and other advantages can be achieved with an exemplary embodiment of the arrangement, a logic arrangement, a storage medium, a software arrangement and/or method according to the present invention. In particular, a processing system (e.g., a first system) can associate a particular Extensible Stylesheet Language (“XSL”) Device Description file with a particular non-proprietary language Device Description file (e.g., a particular non-binary coded Device Description file, such as an Extensible Markup Language (“XML”) Device Description file). For example, the processing system may initially convert a particular proprietary language Device Description file a particular binary coded Device Description file) and/or a particular DDL source code into the particular non-proprietary language Device Description file, and may then associate the particular non-proprietary language Device Description file with the particular XSL Device Description file. Each of the particular non-proprietary language Device Description file and the particular XSL Device Description file may be associated with a particular type of the field device (e.g., a pressure sensor, a temperature sensor, a flow-rate sensor, a valve, a switch, etc.), and the particular XSL Device Description file may include a particular script-type language source code (e.g., a Javescript® language source code, a Visual Basic® language source code, etc.). For example, the particular script-type language source code can be located between tags of the XSL Device Description file, and may include a code associated with one or more methods of implementing the particular type of the field device and/or one or more functions performed by such particular type of the field device.
[0010] Moreover, the particular non-proprietary language Device Description file and the particular XSL Device Description file can be transmitted to another processing system (e.g., a second system using the Internet, an Intranet, etc.), and this second system (e.g., a parser of the second processing system) can convert the non-proprietary language Device Description file and the XSL Device Description file into a platform-independent file/page (e.g., a Hypertext Markup Language (“HTML”) file/page) having the script-type language source code embedded therein. The platform-independent file/page can include one or more parameters associated with the particular type of the field device, a link to the one or more methods for implementing the field device and/or one or more functions performed by the field device, etc. When the link is selected by a user of the second processing system (e.g., by clicking on the link), the second system may execute the script-type language source code, and can invoke and execute an operation of a particular component (e.g., an Object Linked Embedded for a Process Control component) of the first system through a remote procedure call (“RPC”) (e.g., a Web Service, DCOM, or COBRA). The particular component can establish a communication with the field device and implement/execute the one or more methods included in the script-type language source code (e.g., to configure the field device and/or obtain data from the field device). Moreover, the particular component can transmit the data obtained from the field device to the second system through the RPC, such that this second system can display such data to the user.
[0011] Alternatively, the first system (e.g., a parser thereof) may can convert the non-proprietary language Device Description file and the XSL Device Description file into the platform-independent file/page by executing the script-type language source code, and can also internally invoke and execute an operation of the particular component. The particular component can establish the communication with the field device, and implement/execute the one or more procedures included in the script-type language source code (e.g., to configure the field device and/or obtain data from the field device). Moreover, the particular component can transmit the data obtained from the field device to the second system in a platform-independent format, such that the second system can readily display such data to the user.
[0012] In addition, the first system can associate a further XSL Device Description file with a further non-proprietary language Device Description file. For example, the first processing system may initially convert a further proprietary language Device Description file and/or a further DDL source code into the further non-proprietary language Device Description file, and then can associate the further non-proprietary language Device Description file with the further XSL Device Description file. Each of the further non-proprietary language Device Description file and the further XSL Device Description file may be associated with a further type of a field device, and the further XSL Device Description file can include a further script-type language source code. For example, the further script-type language source code can include code associated with one or more methods of implementing the further type of the field device and/or one or more functions performed by the further type of the field device. Moreover, the further non-proprietary language Device Description file may be different than the particular non-proprietary language Device Description file, and the further XSL Device Description file can be different than the particular XSL Device Description file.
[0013]
[0014]
[0015]
[0016]
[0017]
[0018]
[0019]
[0020] Exemplary embodiments of the present invention and their advantages may be understood by referring to
[0021]
[0022] This first software arrangement
[0023] In the exemplary embodiment shown in
[0024] When the link
[0025] As described above, in any of the exemplary embodiments of the present invention, the first software arrangement
[0026] Web Services that can be utilized by the exemplary embodiments of the arrangements and methods of the present invention are programmable application logic accessible using standard Internet protocols. Unlike conventional component technologies, Web Services are not accessed via object-model-specific protocols, such as the Component Object Model, Remote Method Invocation, or Internet Inter-ORB Protocol. In contrast, Web Services may be accessed via ubiquitous Web protocols and data formats, such as Hypertext Transfer Protocol (“HTTP”) and XML. Moreover, a Web Service interface may be defined in terms of messages which the Web Service accepts and/or generates, and the Web Service can be used by applications implemented in any language for any platform. In this manner, the Web Services may be platform-independent, language-independent, and reusable.
[0027]
[0028] Referring again to
[0029] Moreover, the second processing system
[0030]
[0031] It will be readily understood by those of ordinary skill in the art that the system
[0032]
[0033]
[0034] While the invention has been described in connecting with preferred embodiments, it will be understood by those of ordinary skill in the art that other variations and modifications of the preferred embodiments described above may be made without departing from the scope of the invention. Other embodiments will be apparent to those of ordinary skill in the art from a consideration of the specification or practice of the invention disclosed herein. It is intended that the specification and the described examples are considered as exemplary only, with the true scope and spirit of the invention indicated by the following claims.
[0035]