Method for expanding the applicability of a sensor, sensor and application of a sensor

Abstract

The invention relates to a method for extending the application possibilities of a sensor, a sensor and the use of a sensor. The invention discloses a method for extending the application possibilities of a sensor, comprising the following steps: sending an app to a sensor via a communication interface of the sensor when the app is not yet located on the sensor, wherein the firmware of the sensor is configured to receive and store the app; wherein the app comprises at least an identification feature, in particular a name and a version, one or more entry points and a main logic; selecting the app via the identification feature of the app by means of a superior unit via the communication interface of the sensor; executing the selected app, wherein the sensor calls the entry points; and returning at least one return value from the app to the sensor. The invention discloses a sensor for executing the method and the use of a sensor with the method.

Description

Technical Field

[0001] This invention relates to a method for expanding the application possibilities of a sensor, a sensor, and applications of the sensor. Background Technology

[0002] Sensors, primarily optical sensors, detect physical parameters (raw values, often as voltage values) and calculate application-relevant measurements from them. One example is calculating the fat content of milk based on its spectrum. Another example is determining the concentration of a specific substance based on the conductivity of the measuring medium. The algorithm responsible for converting raw values ​​into measurements is called a (computational) model.

[0003] The models in the sensor cannot be supplemented or even replaced as needed. The sensor consists of only one set of models (or only a single model) permanently installed in the firmware, which is at most minimally parameterizable (if any).

[0004] Sensors often support more applications than initially assumed due to their technical data. For example, a turbidity sensor actually developed for measuring slurries in wastewater can also measure fat content in milk, due to its measurement principle. However, because the model used to determine fat content only allows the sensor to measure it via complex firmware updates, the sensor remains in its original application. Summary of the Invention

[0005] The purpose of this invention is to expand the functional range of sensors in a simple way.

[0006] This objective is achieved by a method comprising the following steps: when no application is yet applied to the sensor, an application is sent to the sensor via the sensor's communication interface, wherein the sensor's firmware is configured to receive and store the application; wherein the application includes at least identification features, particularly name and version, one or more entry points, and main logic; an application is selected by means of a higher-level unit via the sensor's communication interface based on the application's identification features; the selected application is executed, wherein the sensor invokes the entry point; and at least one return value from the application is returned to the sensor.

[0007] One embodiment specifies that during app execution, the sensor provides one or more parameters to the entry point.

[0008] One embodiment specifies that the sensor includes an application programming interface (API), through which an app queries one or more parameters from the sensor.

[0009] One embodiment specifies that the sensor cyclically calls the entry point.

[0010] One embodiment specifies that the step "returning at least one return value from the app to the sensor" is performed as a direct return from the app to the sensor.

[0011] One embodiment specifies that the step "returning at least one return value from the app to the sensor" is performed by the sensor, which includes an application programming interface (API), via which the app transmits the return value to the sensor.

[0012] One embodiment specifies that the app is an app for calculating measurement values ​​via a model, wherein the app's sensors send raw values ​​as parameters, or the app calls raw values ​​via an application programming interface (API), wherein the main logic includes an algorithm for signal processing and a routine for calculating measurement values ​​based on raw values ​​via a model, and wherein the measurement value is a return value.

[0013] One embodiment specifies that the sensor includes multiple apps.

[0014] This includes the following two situations:

[0015] 1) Using different apps for the same measurement parameters, especially for the model; however,

[0016] 2) Different apps are used for different measurement parameters, especially for the model.

[0017] In the first case, different measurement performances exist, for example, in terms of accuracy, or separately in terms of the measurement area. In the second case, for example, a given spectrum is processed differently for different parameters.

[0018] One embodiment specifies that the sensor includes multiple apps, and each app includes a different model for calculating the measured values.

[0019] One embodiment specifies that measurements from different apps are compared, and a measurement is selected in case of discrepancy. Various apps are then able to continue operating. The "correct" measurement is selected based on defined criteria (e.g., the measurement being greater than or less than a specific threshold).

[0020] One embodiment specifies that measurements from different apps are compared, and an alarm is triggered if the deviation exceeds a threshold.

[0021] One embodiment specifies that the model is configured for a single measurement point.

[0022] One embodiment specifies that the app is configured or a status query is performed via a sensor entry point.

[0023] One embodiment specifies that the sensor includes a virtual machine. In one embodiment, the virtual machine is configured as an interpreter, particularly as an emulator, configured as an early-stage compiler, a just-in-time compiler, a hypervisor, or a combination thereof.

[0024] One embodiment specifies that the sensor includes an interpreter, particularly a software emulator or scripting language interpreter, the app exists on the sensor in an interpretable format, and the app is executed via the interpreter.

[0025] One embodiment specifies that the sensor includes a just-in-time compiler, and the app exists on the sensor in a corresponding format.

[0026] One embodiment specifies that the sensor includes an advance compiler, and the app exists on the sensor in a corresponding format.

[0027] One embodiment specifies that each sensor can execute multiple interpreters / compilers, specifically each interpreter / compiler executes only one app.

[0028] One embodiment specifies that the sensor provides one or more system calls to the app, wherein the app includes system call stubs.

[0029] One embodiment specifies that the system call includes optimized signal processing routines and sensor functions to query the current raw value and determine the calculated measurement value.

[0030] This objective is also achieved by a sensor used to perform the above-described method, which includes a sensor element for detecting a measurement variable of the measurement medium and a data processing unit having a memory.

[0031] One embodiment specifies that the sensor is designed as an optical sensor with a light source and a light receiver; in particular, the sensor is a spectrometer.

[0032] One embodiment specifies that, in order to detect a boundary layer or liquid level, the sensor is particularly configured as a silt cover layer sensor, which has a transmitter for transmitting electromagnetic waves, light, especially visible light, sound waves or ultrasonic waves in the direction of the boundary layer or surface, and a receiver for receiving the returned waves or light.

[0033] One embodiment specifies that the sensor is designed as a two-dimensional optical sensor, particularly for particle or bacteria counting.

[0034] One embodiment specifies that the sensor is designed as a three-dimensional optical sensor, particularly a lidar sensor.

[0035] This objective is also achieved by applying the methods described above to the sensors described above to determine the composition of milk—such as its fat content. Attached Figure Description

[0036] This will be explained in more detail with reference to the following attached diagram.

[0037] Figure 1 This illustrates the core of the method for which protection is sought in the overview.

[0038] Figure 2 The sensor requiring protection is shown.

[0039] Figure 3a / b indicates the app.

[0040] In the accompanying drawings, the same features are indicated by the same reference numerals. Detailed Implementation

[0041] Due to their measurement principles, sensors typically support far more applications than initially assumed. For example, a turbidity sensor actually developed for measuring slurries in the wastewater field can also measure the fat content in milk, due to its measurement principles. In this case, to enable flexible new applications, the model should not be permanently stored in the sensor, but rather developed as a reloadable app.

[0042] Therefore, existing sensors can operate in new applications without firmware updates. Similarly, customers wishing to use their sensors for different applications can easily modify them. The ability to reload computational models makes it possible to use highly specialized computational models, which, where appropriate, are optimized to a single measurement point.

[0043] Figure 1 A sensor 1 is shown with a reloadable app 2, which has a fully freely definable signal processing 3, i.e., a model, and parameterization 4. The sensor 1 includes a data processing unit 14 with a memory 5 large enough to store multiple apps 2 (represented by open areas).

[0044] Therefore, app 2 is a loadable (downloadable) code snippet that provides additional functionality to the host (i.e., sensor 1). The loadable code is configured to interact with sensor 1 at both ends:

[0045] ● There is an entry point 22, typically an interface method, which calls the sensor to retrieve specific functionality in app 2; example: calculation of measurements, see below.

[0046] ● Sensor 1 provides functionality via system call 24a, which is invoked via system call stub 24 within the app; Example: Access to an index structure or extended calculation method.

[0047] If system call 24a or interface method 22 does not exist, or exists only in an incompatible version, or is incompatible with the target system (i.e., app2 has been written for an incorrect base system 1), then execution of app2 is rejected. If at runtime an attempt is made to execute system call 24a, which does not exist in base system 1 or exists in an incompatible version, then app2 is aborted.

[0048] The firmware of sensor 1 is designed to receive and store apps 2 internally via an interface. Sensor 1 provides a communication interface 6, through which it is notified which stored app to load for measurement calculations. Sensor 1 connects to upper-level units, such as transmitters (measuring transducers) or control systems (control rooms), via communication interface 6. Communication interface 6 is typically wired and can be supported by proprietary protocols or bus systems such as HART, Modbus, and Foundation Fieldbus.

[0049] Sensor 1 will be discussed in more detail below.

[0050] Sensor 1 includes at least one light source 11, a spectrometer 13, and a data processing unit 14. Sensor 1 or data processing unit 14 is designed to perform the steps of the claimed method, that is, for example, turning the light source 11 on and off, or performing data processing.

[0051] An optical sensor, more precisely a spectrometer, is shown. This will be explained in more detail below. However, in principle, the claimed method can also be applied to other sensors that employ other physical or chemical measurement methods.

[0052] Spectrometer 13 only Figure 2 The spectrometer 13 is symbolically shown and includes, for example, at least one beam-shaping element, such as a mirror 15, a grating 16 (typically a dispersive element, such as a prism), and a receiver 17. The mirror 15 and the grating 16 can be configured as a single component. The receiver is configured as a CCD sensor or a linear array detector. An entrance slit 18 is located at the entrance of the spectrometer 13. In principle, the concept according to the invention is applicable to all spectral measurement systems, regardless of whether a prism or a grating is used.

[0053] Light from a light source 11, configured as, for example, a xenon flash lamp, is emitted from the light source 11 in the direction of the measuring medium 12. The light source 11 can also be designed as an LED. If the emission spectrum of the light source 11 is temperature-dependent, the sensor 1 includes a temperature sensor 19, which is disposed at, within, or at least near the light source 1. Therefore, the emission spectrum can be corrected relative to temperature if necessary.

[0054] Transmission measurements are illustrated. For this purpose, the light source 11 includes one or more windows that are at least partially transparent to the emitted light. The measurement medium 12 is separated from the optical and electronic components of the sensor 1 through the windows. Other measurement principles, such as absorption, scattering, or fluorescence measurements, are also possible.

[0055] The data processing unit 14 includes one or more apps 2, indicated by boxes. Apps 2 reside in the memory 5. If an app 2 is not already in the memory 5, it is loaded thereon. This is accomplished, for example, via the communication interface 6. Depending on the sensor configuration, the app 2 can also be sent directly to the sensor, for example, via a wireless data connection such as Bluetooth. Similarly, if the sensor 1 includes such a possibility, the app 2 can be loaded into the data processing unit 14 via a memory card (e.g., an SD card).

[0056] To distinguish app 2 stored in sensor 1, app 2 must carry identification features 21, such as the application's name and version, as metadata. For example, app 2 exists as an image file, in which the actual program code and the identification features 21 (meta-information) of app 2 itself are located.

[0057] This also shows Figure 3a The general representation of app 2 in the context of the application. app 2 includes, for example, three parts: the actual main logic 23, the interface methods 22 called by the basic system, and the system call stubs 24 that call the functionalities in sensor 1 based on this.

[0058] The code for app 2 can consist of any algorithm to convert raw values ​​into measured values. Raw values ​​are physical parameters, such as voltage values, while measured values ​​represent, for example, the fat content of milk or the concentration of a specific substance in the medium being measured. To be more specific: in the example above, interface method 22 is the entry point for calculating the measured value. Main logic 23 represents the actual algorithm used for signal processing. For example, system call 24 would be an optimized routine frequently used in signal processing algorithms and sensor functions to query the current raw value and determine the calculated measured value. Sensor 1 can provide the current raw value as a parameter to interface method 22 of app 2, or app 2 can query the current raw value of sensor 1 via an API. If applicable, app 2 supplies the measured value back to sensor 1a, for example, as a return value, or, through a sensor providing an API, the app transmits the current measured value and the unit via that API.

[0059] Figure 3bThe relationship between app 2 and sensor 1 is illustrated. Multiple apps 2 can run on sensor 1 simultaneously. This is illustrated by the jigsaw puzzle pieces placed one on top of the other in the middle of the accompanying figure. In sensor 1, there is an interface stub 22a, which calls interface method 22 in app 2. Sensor 1 provides the functionality of app 2 in the form of system call 24a. In order for app 2 to be able to call system call 24a in sensor 1, there is a corresponding system call stub 24 in app 2.

[0060] like Figure 3b As shown, multiple apps 2 can be executed simultaneously, but for the same sensor type, all apps 2 have the same interface. In one embodiment, apps 2 run in an isolated environment to prevent a faulty app 2 from causing the host (sensor 1) to crash. Due to this isolation, the sensor cannot directly call methods in app 2. App 2 also cannot make direct calls to sensor 1. App 2 also runs in its own address space and cannot access sensor 1's data by default.

[0061] Conversely, the process operates as shown in the diagram. To interact with app 2, an interface stub 22a exists on the sensor side. app 2 "enters and exits" only via interface stub 22a. If sensor 1 calls stub 22a, the scheduler enters app 2 and calls the corresponding interface method 22. Interface method 22 calls the main logic 23, which executes and returns its function. The main logic 23 can additionally access system call 24a. In this case, the main logic 23 calls stub 24, and the scheduler forwards system call 24a on the sensor side. Now execution is again in sensor 1, system call 24a performs its action, then returns to app 2, and finally app 2 returns to sensor 1. The application code can consist of a main loop, allowing the loop to be repeated indefinitely.

[0062] Sensor 1 must be able to load and execute app 2, for example, by implementing sensor firmware in which a virtual machine interprets / executes the app. The virtual machine is configured as an interpreter, particularly as an emulator, configured as an early-time compiler, a just-in-time compiler, a hypervisor, or a combination thereof. The CPU architectures of the host (sensor 1) and the client (app 2 running on it) do not need to be exactly the same. However, especially in the case of a hypervisor, it is preferable to choose the same CPU instruction set for the execution implementation of the app.

[0063] In the embodiment as a virtual machine, inherent measurements for memory protection are achieved, and thus security. Possible malicious code cannot reach outside the virtual machine and therefore cannot negatively affect the running firmware or other virtual machines (multiple virtual machines can run in parallel, see below). Separation exists between different virtual machines because shared memory areas are not used. Different virtual machines interact only through defined interfaces, thus performing only limited functions. The virtual machine, particularly in its embodiment as an interpreter (emulator), forms an environment for executing the app in the form of a virtual CPU with virtual working memory. In this case, the system is isolated from the rest of the system, i.e., isolated from the host system, i.e., isolated from the sensor firmware. If the app is defective, it will not affect the rest of the system. The rest of the system continues to run even if the defective extension crashes. Communication is performed via defined interfaces.

[0064] However, app 2 can also be executed "natively" on the sensor. For this purpose, sensor 1 includes, for example, an early-stage compiler or a just-in-time compiler. app 2 exists on sensor 1 in a corresponding format.

[0065] If the simulation is not performed via a virtual machine (see above) and a CPU architecture that matches the host and client, then the processor of sensor 1 is required to execute the application. For example, a memory management unit (MMU) is required in the hardware to enable memory protection.

[0066] To interpret / execute an app, it must contain program code that can be interpreted / executed or translated into an interpretable / executable form, such as machine-independent bytecode. Similarly, the program must be stored in a binary format, such as Executable and Linkable Format (ELF). This binary format provides information about the app's memory layout, such as the location and size of the code and data. This information is necessary for loading the app and preparing it for execution.

[0067] Program code can be executed via an interpreter (virtual machine), or it can be translated into machine code on a processor used on a sensor (compiler) before execution.

[0068] The entry point could be, for example, a program address stored in metadata, such as as part of identification feature 21. Then, the virtual machine or compiler starts executing app 2 from that program address.

[0069] The entry point can also be identified by an ID. The virtual machine always calls app2 at the starting address stored in the ELF file, with the entry point ID as a further argument. app2 must be programmed to evaluate the ID and call the desired entry point. The ID can be explicitly entered during app creation or automatically assigned.

[0070] app 2 provides the entry point that sensor 1 calls for app 2 to calculate the measurement value from the currently detected raw value (see “Interface Method 22” above). Sensor 1 can assign the current raw value as a parameter to the entry point of app 2, or app 2 can query the current raw value from the sensor via the API.

[0071] Sensor 1 provides the app with access to general, optimized signal processing routines.

[0072] If used with the corresponding unit, app 2 will return the measured value to sensor 1, for example, as a return value, or via an API provided by the sensor, the app will transmit the current measured value and the unit through that API.

[0073] App 2 can also have another entry point, through which sensors can configure the app, perform status queries, etc.

[0074] In yet another embodiment, sensor 1 can operate two or more different models for one and the same application. Therefore, different models can be compared with each other to determine, for example, by a user or machine, which model calculates a more accurate measurement, or to detect deviations between calculated measurements and warn of any anomalies that have occurred in the process. For example, comparisons can be performed via a threshold; that is, if the deviation exceeds a threshold, a different model (i.e., a different app 2) is selected, or even an alarm is triggered. In yet another embodiment, sensor 1 can operate one, two, or more different models for two or more different applications. As a result, for example in the case of a spectrometer, the concentrations of different substances in the measurement medium can be determined based on the same original measurement values.

[0075] List of reference numerals

[0076] 1. Sensor

[0077] 2 app

[0078] 3 Signal Processing / Model

[0079] 4. Parameterization

[0080] 5. Memory

[0081] 6. Communication Interface

[0082] 11 Light Source

[0083] 12. Measuring medium

[0084] 13. Spectrometer

[0085] 14 Data Processing Unit

[0086] 15 Reflectors

[0087] 16 gratings

[0088] 17 Receivers

[0089] 18. Entrance gap

[0090] 19 Temperature Sensor

[0091] 21 Identification Features

[0092] 22 Interface methods / entry points

[0093] 22a Interface stub / Entry point stub

[0094] 23 Main Logic

[0095] 24 System call stubs

[0096] 24a System Call

Claims

1. A method for expanding the application possibilities of a sensor (1), comprising the following steps: - When app (2) is not yet on the sensor (1), the app (2) is sent to the sensor (1) via the communication interface (6) of the sensor (1). The firmware of the sensor (1) is configured to receive and store app (2). - Wherein, the app (2) includes at least identification features (21), one or more entry points (22), and main logic (23); - The app (2) is selected by the upper unit via the communication interface (6) of the sensor (1) through the identification feature (21) of the app (2). - Execute the selected app (2), wherein the sensor (1) calls the entry point, During the execution of the app (2), the sensor (1) provides one or more parameters to the entry point (22); and - Return at least one return value from the app (2) to the sensor (1). Wherein, the app (2) is an app used to calculate the measured value via the model. Among them, the sensor (1) of the app (2) transmits the original value as a parameter, or The sensor (1) includes an application programming interface (API), the app (2) queries one or more parameters of the sensor (1), and the app (2) calls the raw values ​​via the application programming interface (API). The main logic includes an algorithm for signal processing and a routine for calculating the measured value based on the original value via the model. The measured value is the returned value.

2. The method according to claim 1, in, The app (2) includes a name and a version.

3. The method according to claim 1, in, The sensor (1) calls the entry point (22) in a loop.

4. The method according to any one of claims 1-3, in, The step "return at least one return value from the app (2) to the sensor" is performed as a direct return from the app (2) to the sensor (1).

5. The method according to any one of claims 1-3, in, The step "returning at least one return value from the app (2) to the sensor (1)" is performed by the sensor (1) which includes an application programming interface (API), and the app (2) transmits the return value to the sensor (1) via the API.

6. The method according to any one of claims 1-3, in, The sensor (1) includes multiple apps (2).

7. The method according to any one of claims 1-3, in, The sensor (1) includes multiple apps (2), and each app (2) includes a different model for calculating the measured value.

8. The method according to claim 7, in, Compare the measurements from different apps (2) and select the measurement in case of deviation.

9. The method according to claim 8, in, Compare measurements from different apps (2) and trigger an alarm if the deviation exceeds a threshold.

10. The method according to claim 1, in, The model is configured for a single measurement point.

11. The method according to any one of claims 1-3, in, The sensor (1) configures the app (2) via the entry point (22), or a status query is run.

12. The method according to any one of claims 1-3, in, The sensor (1) includes an interpreter, the app (2) exists on the sensor (1) in an interpretable format, and the app (2) is executed via the interpreter.

13. The method according to claim 12, in, The sensor (1) includes a software simulator or a scripting language interpreter.

14. The method according to any one of claims 1-3, in, The sensor (1) includes a just-in-time compiler, and the app (2) exists on the sensor (1) in a corresponding format.

15. The method according to any one of claims 1-3, in, The sensor (1) includes a pre-compiler, and the app (2) exists on the sensor (1) in a corresponding format.

16. The method according to any one of claims 1-3, in, Each sensor (1) can execute multiple interpreters / compilers.

17. The method according to claim 16, in, Only one app is executed per interpreter / compiler (2).

18. The method according to any one of claims 1-3, in, The sensor (1) provides one or more system calls (24a) to the app (2), wherein the app (2) includes system call stubs (24).

19. The method according to claim 18, in, System call (24a) includes optimized signal processing routines and sensor functions to query the current raw values ​​and determine the calculated measurements.

20. A sensor (1) for performing the method according to any one of claims 1-19, comprising: - Sensor elements used to detect the measured variable of the measured medium. - A data processing unit (14) with memory.

21. The sensor (1) according to claim 20, in, The sensor (1) is designed as an optical sensor with a light source (11) and a light receiver (17).

22. The sensor (1) according to claim 21, in, The sensor (1) is a spectrometer.

23. A method of using a sensor (1) according to any one of claims 20-22 to determine the composition of milk using the method according to any one of claims 1-19.

24. The usage according to claim 23, in, The composition of the milk includes its fat content.

Images