METHOD FOR OPERATING A MEASURING TRANSDUCER, AND CORRESPONDING MEASURING TRANSDUCER

20180164130 ยท 2018-06-14

    Inventors

    Cpc classification

    International classification

    Abstract

    The present disclosure relates to a method for operating a measuring transducer of process automation technology, comprising at least the following steps: starting the measuring transducer by starting its operating system, wherein the operating system provides at least one interface; starting at least one interpreter, wherein the interpreter accesses the interface; and executing an extension in the interpreter. The present disclosure further relates to a measuring transducer for implementing the method.

    Claims

    1. A method for operating a measuring transducer of process automation technology, comprising: starting the measuring transducer by starting its operating system, wherein the operating system provides at least one interface; starting at least one interpreter, wherein the at least one interpreter is configured to access the at least one interface; and executing an extension in the at least one interpreter.

    2. The method according to claim 1, wherein the at least one interpreter is a software emulator.

    3. The method according to claim 1, wherein the at least one interpreter is a script language interpreter.

    4. The method according to claim 3, wherein the script language is Lua.

    5. The method according to claim 1, wherein several interpreters can be executed per measuring transducer.

    6. The method according to claim 1, wherein the extension includes sensor-specific software, the method further comprising: connecting a sensor to the measuring transducer; executing the sensor-specific software; and the sensor interacting with the measuring transducer via the interface.

    7. The method according to claim 6, further comprising: transferring the sensor-specific software to the measuring transducer, if it is not yet located on the measuring transducer, from at least one of the following locations: the sensor, a memory card, and a data connection of the measuring transducer.

    8. The method according to claim 6, further comprising: providing the sensor-specific software on the measuring transducer; transferring an identification from the sensor to the measuring transducer; and executing the respective sensor-specific software on the basis of the identification of the sensor.

    9. The method according to claim 6, wherein executing the sensor-specific software includes: executing a sensor driver; signal processing sensor data; executing one or more state machines; parameterizing a sensor; installing a menu navigation of the sensor; and connecting the sensor to a field bus.

    10. The method according to claim 9, wherein, by installing the menu navigation, settings, parameters, calibration processes, and adjustment processes required for the sensor can be adjusted or carried out.

    11. The method according to claim 6, further comprising: connecting several sensors to the measuring transducer, wherein sensor-specific software for each sensor is executed in a separate interpreter.

    12. The method according to claim 1, wherein the extension includes a data processing module, the method further comprising the data processing module: reading input values via the at least one interface; processing the input values; and outputting the processed input values as output values via the at least one interface.

    13. The method according to claim 1, wherein the extension includes a data source, the method further comprising the data source: generating data; and outputting the generated data via the at least one interface.

    14. The method according to claim 1, wherein the extension includes a menu navigation adapted to a user.

    15. The method according to claim 1, wherein the extension includes an interface, by which a user is guided through one or more dialogs for an ergonomic data input.

    16. The method according to claim 1, wherein the extension includes an illustration, adapted to a user, of a system.

    17. A measuring transducer, comprising: a sensor element embodied to detect a physical measurand and to convert the physical measurand to an electrical signal, the sensor element including a unique identification; an operating system having at least one interface for the exchange of information; and at least one interpreter configured to access the at least one interface, wherein the measuring transducer is configured to transfer to itself sensor-specific software from the sensor element, a memory card, and a data connection, based on the unique identification, and wherein the interpreter is embodied to execute an extension and to execute the sensor-specific software.

    Description

    BRIEF DESCRIPTION OF THE DRAWINGS

    [0068] The present disclosure is explained in more detail with reference to the following figures. These show:

    [0069] FIGS. 2A and 2B show a measurement arrangement comprising a measuring transducer in two different embodiments,

    [0070] FIG. 3 shows a system architecture of a sensor arrangement for carrying out the method, and

    [0071] FIG. 4 shows a layer architecture of the sensor arrangement.

    DETAILED DESCRIPTION

    [0072] In the figures, the same features are marked with the same reference characters.

    [0073] The claimed measuring transducer 20 is used in a sensor arrangement 10. The sensor arrangement 10 comprises a sensor 1 and a connection element 11, which shall be discussed first.

    [0074] FIG. 2A represents a first embodiment of a sensor arrangement 10.

    [0075] A sensor 1 communicates with a measuring transducer 20 via a first physical interface 3. An alternative word for measuring transducer is transmitter. The measuring transducer 20 in turn is connected to a higher-level unit 30, such as a control system, by a cable 31. A cable 21 is connected on the sensor side to the measuring transducer 20, and its other end comprises a second physical interface 13 that is complementary to the first physical interface 3. A connection element 11 comprises the cable 21, along with the second physical interface 13. The physical interfaces 3, 13 are designed as electrically isolated in particular, inductive interfaces. The physical interfaces 3, 13 can be coupled with each other by means of a mechanical plug connection. The mechanical plug connection is hermetically sealed, so that no fluid, such as the medium to be measured, air, or dust can enter from the outside.

    [0076] Data (bi-directional) and power (uni-directional, i.e., from the connection element 11 to the sensor 1) are transmitted or transferred via the physical interfaces 3, 13. The sensor arrangement 10 is used predominantly in process automation.

    [0077] The sensor 1 comprises at least one sensor element 4 for detecting a measurand of process automation. The sensor 1 is then, for example, a pH sensor, also [called] ISFET generally, an ion-selective sensor, a sensor for measuring the redox potential from the absorption of electromagnetic waves in the medium, e.g., with wavelengths in the UV, IR, and/or visible range, of the oxygen, of the conductivity, of the turbidity, of the concentration of non-metallic materials, or of the temperature, along with the respectively corresponding measurand.

    [0078] The sensor 1 furthermore comprises a first coupling body 2, which comprises the first physical interface 3. As mentioned, the first physical interface 3 is designed for the transmission of a value that is a function of the measurand to a second physical interface 13. The sensor 1 comprises a data processing unit CS, such as a microcontroller, which processes the values of the measurand, e.g., converts them into a different data format. The data processing unit CS is designed for energy and space reasons to be rather small or economical with respect to the computing capacity and the memory volume. The sensor 1 is thus designed only for simple arithmetic operations for example, for averaging, preprocessing, and digital conversion.

    [0079] Several sensors 1 can also be connected to a measuring transducer 20. Shown in FIG. 2A are two sensors 1, wherein only one of the two is provided with all of the reference characters. The same or different sensors can be connected. The left one of the two is shown in the plugged-in state. Up to eight sensors can be connected to the measuring transducer 20, for example.

    [0080] The sensor 1 can be connected via the physical interfaces 3, 13 to the connection element 11, and ultimately to the measuring transducer 20. The data processing unit CS converts the value that depends upon the measurand (i.e., the measurement signal of the sensor element 4) into a protocol that the measuring transducer 20 can understand. An example in this respect is, for example, the proprietary Memosens protocol. The first and second physical interfaces 3, 13 are thus designed for the bi-directional communication between the sensor 1 and the measuring transducer 20. As mentioned, in addition to the communication, the first and second interfaces 3, 13 also ensure the supply of power to the sensor 1.

    [0081] The connection element 11 comprises the second physical interface 13, wherein the second physical interface 13 is designed to be complementary to the first physical interface 3. The connection element 11 likewise comprises a data processing unit CA. The data processing unit CA may also serve as a repeater for the transmitted signal. Furthermore, the data processing unit CA can also convert or modify the protocol.

    [0082] The connection element 11 comprises a second, cylindrical coupling body 12 that is designed to be complementary to the first coupling body 2 and can be slipped with a sleeve-like end portion onto the first coupling body 2, wherein the second physical interface 13 is plugged into the first physical interface 3. An opposite arrangement, in which the second physical interface 13 is designed to be sleeve-like and the first physical interface 3 is designed to be plug-like, is possible without any inventive effort.

    [0083] The measuring transducer 20 comprises a display 22 and one or more operating elements 23, such as buttons or rotary buttons, by means of which the measuring transducer 20 can be operated. Measured data of the sensor 1 are displayed by the display 22, for example. The sensor 1 can also be configured and parameterized by means of the operating elements 23 and the corresponding view on the display 20 [sic].

    [0084] The measuring transducer 20 directs (communication 35) the measured data via the cable 31, as mentioned, to a control system 30, for example. The control system 30 is in this case designed as a process control system (PLC, SPS), PC, or server.

    [0085] To this end, the measuring transducer 20 converts the data into a data format that the control system can understand, e.g., into a corresponding bus, such as HART, Profibus PA, Profibus DP, Foundation Fieldbus, Modbus RS485, or even an Ethernet-based field bus, such as EtherNet/IP, Profinet, or Modbus/TCP. These data are then forwarded via the communication 35 to the control system 30. This can, if required, be combined with a web server, i.e., they can be operated in parallel to one another.

    [0086] FIG. 2B represents a second embodiment of a sensor arrangement 10. In this case, only one sensor 1 respectively is connected to a measuring transducer 20. The measuring transducer 20 is in this case illustrated symbolically as a rectangle, is smaller in its dimensions than the measuring transducer from FIG. 2A, and is approximately the size of a matchbox. The measuring transducer 20 can in this case be designed as a separate unit that can be connected to the cable 21 or, as shown here, be integrated directly into the cable 21. The measuring transducer 20 thus consists essentially of the data processing unit CA. The measuring transducer 20 does not comprise a display and has only one or two operating elements, if any, which are configured for a reset or for turning on and off. In this embodiment, the measuring transducer 20 preferably comprises no operating elements. The measuring transducer 20 therefore comprises a wireless module 24, such as a Bluetooth module, with the protocol stack Bluetooth Low Energy. A mobile device (not shown), such as a cellphone, tablet, laptop, etc., can thereby be wirelessly connected to the measuring transducer 20. The sensor can be configured and parameterized by means of the mobile device via the wireless module 24 using the wireless connection. The measuring transducer 20 converts the raw measured data such that they are directly transmitted to a higher-level unit 30, such as the control system (communication 35). As mentioned, data can, for example, be transmitted in a proprietary protocol from the sensor 1 to the connection element 11, while the data processing unit CA converts this proprietary protocol into a bus protocol (Modbus, Foundation Fieldbus, HART, Profibus, EtherNet/IP; see above). The measuring transducers in FIG. 2A and FIG. 2B essentially have the same basic functionality.

    [0087] As mentioned, in the prior art, a driver, as well as any signal processing, parameterization, etc., specific to the sensor, must be kept available in the measuring transducer 20; see also FIG. 1.

    [0088] FIG. 3 shows a symbolic illustration of the system architecture as described in the claimed method. Before the architecture is described in more detail, the claimed method shall once again be briefly outlined in general.

    [0089] Initially, the measuring transducer 20 is to be started; more precisely, the operating system OS of the measuring transducer 20 is started. In general, an operating system is a set of software modules that manages the system resources and makes these programs available. The operating system provides one or more interfaces S, which can be used by programs in this case, in particular, by an interpreter (see below). The term, interface, is to be understood here and below as a software interface. The physical interfaces 3, 13 mentioned above, on the other hand, are designed as hardware interfaces.

    [0090] The interface S is that part of a system which is used for communication, i.e., for the exchange of information. The communication between two subsystems is possible only via the interface. It is of no importance to one subsystem how the respective other subsystem handles the information internally and how any responses come about. As mentioned, this is about software interfaces. Software interfaces are, in general, logical points of contact in a software system; they allow and regulate the exchange of commands and data between various processes and components.

    [0091] In the next step, an interpreter 50 is started on the measuring transducer 20, wherein the interpreter 50 accesses the interface S. Several interpreters 50 may also be started, wherein a communication between the various interpreters always takes place via the interface S only. The interpreter 50 can be instantiated. In general, an interpreter is a computer program that, in contrast to assemblers and compilers, does not translate a program source code into a file that can be executed directly on the system, but reads, analyzes, and executes the source code directly. The program is executed step-by-step during the runtime of the program, without the program being converted into the machine code of the target system beforehand.

    [0092] In a first embodiment, an emulator more precisely, a software emulator is to be understood as an interpreter 50. An emulator is an interpreter, since the former executes the machine code of the guest system command-by-command by means of a virtual processor. In the example shown, the interpreter 50 (aka emulator) executes the machine code of the guest system, i.e., of a sensor 1 connected to the measuring transducer 20, or its software interpretation (sensor-specific software; see below), command-by-command on a virtual processor on the measuring transducer 20.

    [0093] In general, a system that simulates another system in certain partial aspects is called an emulator. The simulated system receives the same data, executes the same or at least comparable programs, and achieves results as similar as possible to the system to be emulated. Software emulators are programs that simulate a computer and thus allow the use of software for this computer on a computer with a different architecture.

    [0094] In the interpreter 50, at least one preferably, precisely one extension 60 (per interpreter 50) is executed. Several interpreters 50 are executed per measuring transducer 20.

    [0095] An interpreter 50 basically also comprises the special form of a virtual machine, which can execute parts of the machine code of the guest system on the host system.

    [0096] In one embodiment, the interpreter 50 is not designed as an emulator, but as a script language interpreter. In one embodiment, this script language is Lua. Other examples are Python, VBA, Lisp, VBScript, or JScript. It is basically also possible to install and start various script language interpreters on a measuring transducer 20. As mentioned, the individual interpreters 50 communicate with each other via interfaces S. If these interfaces S are then implemented accordingly in the interpreters 50, communication between the various interpreters 50 is then also possible without difficulty.

    [0097] If the interpreter 50 is started, an extension 60 is subsequently executed on it. An extension 60 is software that is not primarily a part of the measuring transducer 20, i.e., it is explicitly not part of the operating system OS. The extension is reloaded at runtime.

    [0098] FIG. 3 shows the system architecture of the claimed method. It is similarly illustrated with blocks as in FIG. 1. It is to be noted that the sensor 1 is connected, i.e., hooked up, to the measuring transducer 20 in a first step. The sensor 1 sends a unique identification to the measuring transducer 20. Based upon this identification, the measuring transducer 20 determines whether the sensor 1, i.e., the type of sensor, is known to it. As mentioned, the measuring transducer 20 comprises an interpreter 50, on which an extension 60 is executed. Via the interfaces S, the sensor 1 can interact with the measuring transducer 20, or, via the interfaces S, the various interpreters 50 can, as mentioned, exchange data with each other.

    [0099] In a first embodiment, all sensor-specific components are stored in the sensor 1. The sensor-specific components are also called sensor-specific software below. Within the meaning of this application, the sensor-specific software is an extension 60. The sensor-specific software thus constitutes signal processing of sensor data, one or more state machines, parameterization of the sensor, menu navigation of the sensor, or a field bus connection of the sensor. These software components are thus located physically in the sensor 1, e.g., in the form of complete software, as byte code. They are, however, executed on the measuring transducer 20 in an interpreter 50. To this end, the sensor-specific components must be loaded once onto the measuring transducer 20 in order to subsequently be executed within its interpreter 50. This generally takes place after connecting the sensor 1 to the measuring transducer 20, wherein the data communication protocol, required for the sensor 1, between the measuring transducer 20 and the sensor 1 is used.

    [0100] The interpreter 50 is executed on all possible measuring transducers 20 as a common part; only the necessary interfaces S to its own components, such as the display, are specific to the measuring transducer, and are adapted accordingly. In doing so, the interpreter 50 can, for example, be written in a cross-platform programming language like C so that the source code of the interpreter is, in principle, then the same for all different platforms.

    [0101] For each sensor 1 (cf. FIG. 2A) connected to the measuring transducer 20, a separate interpreter 50 is used. Each sensor 1 or its sensor-specific software is thus executed in a separate interpreter 50.

    [0102] There is, basically, the possibility of using a byte code (for example, the one stored on the sensor 1) that is executed directly on the measuring transducer 20 without using an interpreter 50. However, this may possibly be disadvantageous, since different measuring transducers in some circumstances use different microcontrollers with different microarchitectures, on which a common machine code cannot be executed.

    [0103] As an alternative to storing the sensor-specific software in the sensor 1, which software is downloaded onto the measuring transducer 20 as needed, the sensor-specific software is located on a memory card (such as an SD card), which is inserted into the measuring transducer 20, and transferred to it. In an alternative, the measuring transducer 20 establishes a data connection to the internet and downloads the software suitable for the respective sensor. Alternatively, a connection, e.g., to the control system 30, is established via the bus (see above, communication 35), and the control system 30 keeps the respective software available. Based upon a unique identification of the sensor 1, the respectively correct software is found. In an alternative, the sensor-specific software is already available on the measuring transducer 20. This can, for example, be the case with older sensors, wherein their specific software is already stored on the measuring transducer 20 at the time of delivery of said measuring transducer.

    [0104] As mentioned, the measuring transducers 20 according to the prior art must keep available a lot of data for the sensor first and foremost, its drivers. In order to ensure a downward compatibility of the claimed measuring transducer 20 with older sensors 1, the claimed measuring transducer 20 comprises a memory, in which the data required by the old sensor, i.e., in particular, also its drivers, are stored. Accordingly, it is also possible with the measuring transducer 20 to support older sensors 1, i.e., sensors that do not keep their own sensor-specific software available.

    [0105] The measuring transducer has upward compatibility. Upward compatibility in this respect means that sensors that appear after the measuring transducer are or can be supported as well. Previously, a complete software update of the measuring transducer was required for this purpose. Since newer sensors bring along their own sensor-specific software and transfer it when needed to the measuring transducer after a connection to the latter is established, a software update of the entire measuring transducer is no longer necessary. In this way, the newest version of a certain sensor driver can also always be provided for the measuring transducer.

    [0106] In the manner described above, it is possible to connect a sensor to the measuring transducer, wherein the sensor-specific software is executed in an interpreter, as mentioned.

    [0107] In addition to the execution of the extension as sensor-specific software, there are also other possible extensions. Some of them are introduced below. An interaction between the various extensions 60 is possible only via the interfaces S.

    [0108] One possible extension is a data processing module. This data processing module reads input values via an interface S, processes the data further, and then outputs them as output values via an interface S. This module may, for example, be designed as a math module and carry out calculations on the input values. It is conceivable that the data processing module receives, via interfaces, data from another extension, such as the extension, sensor-specific software, and processes them further, e.g., carries out an averaging or smoothing. In one embodiment, the data processing module can also include a control. The data processing module can also receive an input value of an external sensor, e.g., via analog current inputs (4..20 mA) or digital inputs, and possibly process it further and output it via analog current outputs or digital outputs.

    [0109] The data processing module can also be understood as a data converter. As a result, various bus systems can, for example, be made compatible with each other. If a protocol is physically the same as another one, the sensor 1 or the measuring transducer 20 can communicate with each other by a mere calculation or conversion into the other format. As a result, a sensor 1, which is actually subject to a Modbus protocol, can, for example, be connected to a measuring transducer 20 that originally only understands the Memosens protocol mentioned at the beginning. Data can, furthermore, be processed such that they are transmitted via standard interfaces that are also possibly subject to standards, such as HTTP or HTTPS, etc. It is also possible to connect external data sources and data sinks. These are to be understood as, in particular, connections to servers and networks via known internet protocols, such as FTP, etc.

    [0110] An example of an extension is a data source that exclusively generates data and outputs them via an interface S. This extension is thus a data simulation.

    [0111] An example of an extension is a module for performing chemometrics. This extension can also be part of the extension, data processing module.

    [0112] An example of an extension is a menu navigation adapted to a user. This extension recognizes who is logged into the measuring transducer at the moment and/or which role the user has. Based upon this information, the menu navigation is changed and adapted.

    [0113] A support especially, for unexperienced users is an extension by means of which a user [is] automatically guided through one or more dialogs. This is also known as a wizard. Depending upon the answer to a first question, the user is asked a respective second question or provided with other answers. In this way, the user can, for example, be guided through a calibration process by means of step-by-step instructions.

    [0114] An example of an extension is an illustration adapted to a user of a system, for example. To this end, the user can store an image, such as a photo or even a symbolic illustration, of his system in the extension.

    [0115] FIG. 4 shows a layer architecture of the sensor arrangement according to the claimed method. At the very bottom is the operating system OS, which is designed as a real-time operating system. Above it is the access to various communication protocols (such as HTTP, but also the communication protocol, Memosens, of the applicant, bus connection) but also the data memory, the graphical user interface, etc. Above this are the interfaces S via which the interpreters 50 can access the aforementioned communication, data, etc. Several interpreters 50 are started; precisely one extension 60 runs in each of them.