Process for successfully executing app on measurement transducer, measurement transducer, computer program product and computer readable medium

Abstract

The invention relates to a process for successfully executing an app on a measurement transducer, a measurement transducer, a computer program product and a computer readable medium. The process includes the steps of: providing a system call from a measurement transducer; if the app has not been located on the measurement transducer, the app is sent to the measurement transducer, where the app comprises at least program code having at least one app function, and one or more threads are generated and executed at runtime, where each app function is assigned to one or more threads, where which system calls are authorized to use each thread is determined, and where the app is not located on the measurement transducer. Determining which thread is executed in which process; and executing the app on the measurement transducer; and at least one of the process steps.

Description

Technical Field

[0001] The invention relates to a process for successfully executing an app on a measuring transducer of process automation technology, a corresponding measuring transducer, a computer program product and a computer-readable medium. Background Art

[0002] DE 10 2016 124 326 discloses a process for operating a measuring transducer in process automation technology. A measuring transducer is sometimes also referred to as a transmitter. DE 10 2016 124 326 describes the subsequent expandability of a measuring transducer without having to replace its operating software. The measuring transducer described can load and run an "app".

[0003] When executing these apps on the measuring transducers, activities may occur which have to be performed quasi-parallel, such as signal processing for calculating measured values ​​and reading out parameters or generally accessing parameter systems in order to display the measured values ​​on a display (“GUI”, Graphical User Interface).

[0004] Signal processing usually involves a lot of calculations and, therefore, long operation times. On the other hand, access to the parameter system is processed very quickly, since it only involves exchanging values ​​stored there. However, GUI systems require the fastest possible processing speed to avoid delays for the user during operation ("jerky" responses to user input, for example when scrolling). However, in order to display data, the GUI system must frequently (sometimes several times per second) access the parameters managed within the parameter system (set parameters or measured values).

[0005] A general-purpose operating system (GPOS) is a complete operating system that supports process management, memory management, input / output devices, file systems, and user interfaces, thus allowing the execution of almost any application. In a GPOS, processes are created dynamically to execute user commands. In a GPOS, all threads are equivalent from the operating system's point of view, even if they contain different application logic. Equivalence in this sense means:

[0006] • Threads can be assigned to all available processors; when dynamic scheduling is used, this assignment may change continuously

[0007] • All threads have access to the same operating system functionality

[0008] • In processor allocation, threads have the same priority a priori

[0009] In measuring transducers with limited computing power, no GPOS and existing firmware without app functionality, the initial situation is different: the software consists of several (usually statically predefined) operating system processes, among which the application logic and other necessary functionality are located. The operating system processes with the application logic are therefore not equivalent, but perform specialized tasks. Moving existing application logic between operating system processes is usually possible only with major refactoring work, if at all. If new application logic is to be added, it must be implemented within the appropriate operating system process.

[0010] Since this also affects the application logic within the app, adding app functionality to an existing measurement transducer is more difficult without a GPOS than with a GPOS-based system. Summary of the invention

[0011] The invention is based on the object of ensuring that an app in a measuring transducer whose functionality can be extended by an app, without necessarily requiring a GPOS in the measuring transducer, can be successfully executed.

[0012] The object is achieved by a process for successfully executing an app on a measuring transducer of process automation technology, wherein the firmware of the measuring transducer is designed to receive and store the app, wherein the measuring transducer is designed to execute one or more processes, the process comprising the following steps: providing a system call from the measuring transducer; sending the app to the measuring transducer if the app is not yet on the measuring transducer, wherein the app comprises at least a program code having at least one app function, and at runtime one or more threads are generated and executed, wherein each app function is assigned to one or more threads, wherein it is determined which system calls each thread is authorized to use, and wherein it is determined which thread is executed in which process; and executing the app on the measuring transducer; and at least one of the process steps a), b) and / or c), the process steps comprising

[0013] a) At runtime, check with the help of the first authorization matrix whether the thread actually uses only system calls for which the thread is authorized:

[0014] • If authorization exists, execution of the system call occurs, and

[0015] •If authorization does not exist, the app is terminated;

[0016] b) Check at runtime with the help of the second authorization matrix whether the process calls only those functions that the thread makes available to it:

[0017] • If authorization exists, execution of the function occurs, and

[0018] •If the authorization is not present, it is considered that a firmware implementation error has occurred in the host;

[0019] c) At runtime, check with the help of the third authorization matrix whether the process executes only the threads assigned to it:

[0020] • If authorization exists, the thread is executed by the process, and

[0021] • If the authorization is not present, it is considered a firmware implementation error in the host.

[0022] Thus, the process steps under only a), only b), only c), a) and b), a) and c), b) and c), and a), b) and c) may be performed.

[0023] In the following, the term "app" is used synonymously with the term "plug-in" and is a downloadable program code that brings useful functionality. In addition, the term "base system" is used synonymously with "host". This includes in particular the firmware of the measuring transducer.

[0024] One embodiment provides a basic system including multiple apps.

[0025] One embodiment provides that system calls can be called by more than one thread, and shared resources are collectively protected from concurrent access through appropriate protection mechanisms, in particular through locks in the shared memory model and message passing in the isolated memory model.

[0026] One embodiment provides that a system call and the thread that calls it are mapped to a single process.

[0027] One embodiment provides that the step of checking at runtime by means of the first authorization matrix whether the thread actually uses only the system calls for which the thread is authorized comprises one or more of the following measures:

[0028] • Per system call: a bit vector with length equal to the number of threads, where setting bit i indicates that the thread is allowed to call the associated system call;

[0029] • Per thread: a bit vector with length equal to the number of system calls, with bit i set to indicate that the thread is allowed to call system calls;

[0030] • For each system call: a sorted list of unique thread identifiers i that are allowed to call the system call, where, with the help of a binary search, it is checked whether the system call is allowed to be called by the thread;

[0031] • per thread: a sorted list of unique system call identifiers i that the thread is allowed to call, where, with the help of a binary search, it is checked whether the thread is allowed to call a system call;

[0032] • Each system call: in particular, a balanced binary search tree of unique thread identifiers i, corresponding to the threads that are allowed to call the system call;

[0033] • Per thread: specifically, a balanced binary search tree of unique system call identifiers i, corresponding to the system calls that the thread is allowed to call;

[0034] • Per system call: a hash table of unique thread identifiers i, corresponding to the threads that are allowed to call the system call;

[0035] • Per thread: a hash table of unique system call identifiers i, corresponding to the system calls the thread is allowed to call.

[0036] One embodiment provides that the step of checking at runtime by means of the second authorization matrix whether the process calls only those functions that the thread makes available to it comprises one or more of the following measures:

[0037] • Each app function: a bit vector with length equal to the number of threads, where setting bit i indicates that the thread is allowed to call the associated app function;

[0038] • Per thread: a bit vector with length equal to the number of app functions, with bit i set to indicate that the thread is allowed to call app functions;

[0039] • per app function: a sorted list of unique thread identifiers that are allowed to call the app function, wherein it is checked whether the app function is allowed to be called by a thread by means of a binary search, wherein the binary search searches the sorted list of unique thread identifiers for a thread identifier of the calling thread;

[0040] • per thread: a sorted list of unique app function identifiers that the thread is allowed to call, wherein checking whether the thread is allowed to call an app function is performed by means of a binary search, wherein the binary search searches the sorted list of unique app function identifiers for an app function identifier of the app function to be called;

[0041] • Each app function: specifically, a balanced binary search tree of unique thread identifiers that are allowed to call the app function;

[0042] • Per thread: specifically, a balanced binary search tree of unique app function identifiers that are allowed to call the thread;

[0043] • Per app function: a hash table of unique thread identifiers that are allowed to call the app function;

[0044] • Per-thread: A hash table of unique identifiers of the app functions that the thread is allowed to call.

[0045] One embodiment provides that the step of checking whether a process executes only threads assigned to it by means of a third authorization matrix at runtime includes one or more of the following measures:

[0046] • Each process: a bit vector with length equal to the number of threads, where setting bit i means the process is allowed to execute the app thread;

[0047] • Each thread: a bit vector with length equal to the number of processes, with bit i set to indicate that the thread is allowed to be executed by the process;

[0048] • for each process: a sorted list of unique thread identifiers that the process is allowed to call, wherein it is checked whether the process is allowed to execute a thread by means of a binary search, wherein the binary search searches the sorted list of unique thread identifiers for the thread identifier of the thread to be executed;

[0049] • for each thread: a sorted list of unique process identifiers that the thread is allowed to execute, wherein it is checked whether the thread is allowed to be executed by the process by means of a binary search, wherein the binary search searches the sorted list of unique process identifiers for the process identifier of the executing process;

[0050] • Per process: specifically, a balanced binary search tree of unique thread identifiers that the process is allowed to execute;

[0051] • Per thread: specifically, a balanced binary search tree of unique process identifiers of the threads that are allowed to execute;

[0052] • Per process: a hash table of unique thread identifiers that the process is allowed to execute;

[0053] • Per-thread: A hash table of unique identifiers of the processes that are allowed to execute the thread.

[0054] One embodiment provides that the firmware of the measurement transducer comprises a first authorization matrix, a second authorization matrix and / or a third authorization matrix.

[0055] One embodiment provides that the operating system of the measuring transducer is designed as a real-time operating system.

[0056] One embodiment provides that the program code further includes at least: main logic; and one or more system call stubs, by means of which functions in the base system are called.

[0057] One embodiment provides that the firmware of the measurement transducer implements a virtual machine in which the app is executed.

[0058] One embodiment provides that the virtual machine is designed as a just-in-time compiler, an ahead-of-time compiler, a hypervisor, or a combination thereof, and the app is available on the base system in a corresponding format.

[0059] One embodiment provides that multiple interpreters / compilers / hypervisors may be executed in a measurement transducer; in particular, each interpreter / compiler / hypervisor executes only one app.

[0060] The object is also achieved by a measuring transducer for carrying out some steps of the procedure as above, the measuring transducer comprising a data processing unit with a memory.

[0061] The object is also achieved by a computer program product comprising program instructions which, when executed on a measurement transducer, cause the measurement transducer to perform at least some of the steps of the procedure as above.

[0062] The object is also achieved by a computer-readable medium storing the above-mentioned computer program. BRIEF DESCRIPTION OF THE DRAWINGS

[0063] Refer to the following figure to explain this in more detail.

[0064] Figure 1 A measuring transducer according to the invention is shown.

[0065] Figure 2 shows the (virtual) host architecture.

[0066] Figure 3 Shown from Figure 2 Implementation of the host architecture.

[0067] Figure 4a / Figure 4b The app and the interaction of the app with the measurement transducer are shown.

[0068] In the drawings, like features are marked with like reference numerals. DETAILED DESCRIPTION

[0069] First discuss Figure 1 In general, a measuring transducer 1, also called a transmitter, is a device which converts an input variable into an output variable according to a fixed relationship. In this text, "measuring transducer" and "transmitter" are used synonymously. A sensor is connected to a measuring transducer. Its raw measured values ​​are processed in the measuring transducer, for example, averaged or converted into another variable - for example, a process variable to be determined - with the aid of a calculation model and possibly sent to - for example, a control system.

[0070] Various sensors (not shown) can be connected to the measuring transducer 1. Under the above-mentioned name "Memosens", the applicant markets sensors for measuring pH, conductivity, oxygen, turbidity and other things.

[0071] The measuring transducer can also be an integrated part of the sensor.

[0072] The measuring principle implemented in a sensor can often be used for more applications than were originally offered. For example, a turbidity sensor that was actually developed for measuring sludge in the wastewater sector can also be used to measure the fat content in milk by using the measuring principle. In order to be able to offer new applications flexibly, the corresponding models are not permanently saved in the sensor, but can be reloaded in the form of an app 2.

[0073] Thus, app 2 is a (re)loadable program code which provides the measuring transducer with additional or different functionalities. Therefore, the firmware of the measuring transducer is designed to receive, (internally) store and execute apps via the interface. App 2 can be loaded onto the measuring transducer 1 via the interface 8. Likewise, sensors connected to the measuring transducer 1 can carry "their" app and send it via a cable to the measuring transducer 1. Wireless transmission, for example via Bluetooth, is also possible.

[0074] The loadable code of app 2 can be structured to be able to interact with measurement transducer 1 at both ends:

[0075] • There are one or more app functions 22 in app 2, and the measuring transducer 1 can call one or more app functions 22 to retrieve specific functionality in app 2; example: calculation of measurement values

[0076] The measurement transducer 1 in turn provides functionality via one or more system calls 25 which are invoked via a system call stub 24 within the app 2; examples: access to data structures, sensor parameters, sensor configuration or extended calculation processes.

[0077] For example, if a system call 25 or app function 22 does not exist or exists only in an incompatible version or does not match the target system (i.e., app 2 is written for the wrong system 1), then app 2 is refused execution. If app 2 attempts to execute a system call 25 that does not exist in system 1 or exists in an incompatible version during runtime, app 2 is terminated.

[0078] Figure 4aThis is also shown in the overall representation of the app 2 in FIG. The program code comprises three parts: the actual main logic 23 , one or more app functions 22 called by the measurement transducer 1 , and one or more system call stubs 24 based on which the functions in the measurement transducer 1 are called.

[0079] App 2 can only be run on basic system 1 if app 2 supplies functions 22 desired by measuring transducer 1 and vice versa if measuring transducer 1 supplies system calls 25 desired by app 2 .

[0080] The app functions 22 and the system calls 25 represent the interface between the app 2 and the measurement transducer 1. As these interfaces are intended to be extended over time in a backwards compatible manner, the interfaces are preferably versioned.

[0081] The code of app 2 can consist of any algorithm.

[0082] For example, the main logic 23 can be designed to convert the raw values ​​of a sensor connected to the measuring transducer 1 into measured values. The raw values ​​are physical parameters, such as voltage values, while the measured values ​​represent, for example, the fat content of milk or the concentration of a specific substance in the medium to be measured. For example, the app function 22 provides an entry point for calculating the measured values. For example, the measuring transducer 1 can provide the current raw value of the sensor as a parameter to the app function 22, or the app 2 can query the current raw value of the sensor via an API. The app 2 supplies the measured value (optionally with a specific unit) back to the measuring transducer 1, for example as a return value or by supplying the measuring transducer 1 to an API, through which the app communicates the current measured value and the unit.

[0083] like Figure 4b As shown, with the help of the stack, multiple apps 2 can be run at the same time, but all apps 2 of the same type have the same interface. In one embodiment, app 2 runs in an isolated environment to prevent a defective app 2 from causing a complete crash of the measurement transducer 1. Due to this isolation, the measurement transducer 1 cannot directly call functions in app 2. App 2 also cannot perform direct calls to the measurement transducer 1. App 2 also runs in its own address space and cannot access the data of the measurement transducer 1 by default.

[0084] For interaction with app 2, there is an interface stub 21 on the measurement transducer side. App 2 only "enters and exits" via the interface stub 21. If the measurement transducer 1 calls the stub 21, the dispatch mechanism jumps to app 2 and calls the corresponding functional process 22. The corresponding function 22 calls the main logic 23, which performs its function and returns. The main logic 23 can also access the system call 25. In this case, the main logic 23 calls the system call stub 24, and the dispatch mechanism in turn forwards the system call 25 on the measurement transducer side. Now, execution occurs again in the measurement transducer 1, the system call 25 performs its operation, then returns to app 2, and app 2 finally returns to the measurement transducer 1. The application code can consist of a main loop so that this loop can be repeated forever.

[0085] Each firmware of the basic system 1 with the app must specify the interface, ie the functionality 22 of the app 2 must be implemented for this type of measuring transducer 1. Since the interface can be further developed over time, the interface is preferably versioned.

[0086] One or more of the mentioned sensors can be connected to the measuring transducer 1, for example via cables. For example, up to eight sensors can be connected to the measuring transducer 1. The raw measured values ​​of the sensors are processed in the measuring transducer 1, for example, averaged and / or converted into another variable - for example a process variable to be determined - with the aid of a calculation model and possibly sent to - for example a control system. The measuring transducer 1 comprises a data processing unit 3 having a memory 4 which is large enough to store a plurality of apps 2.

[0087] The sensor comprises at least one sensor element for detecting a measured object for process automation. The sensor is then, for example, a pH sensor, also known as an ISFET, typically an ion-selective sensor, a sensor for measuring redox potential, absorption of electromagnetic waves (e.g. wavelengths in the UV, IR and / or visible range) in a medium, oxygen, conductivity, turbidity, concentration of non-metallic materials or temperature and corresponding measured variables.

[0088] The measuring transducer 1 can be connected to a superordinated unit 5, such as a control system, via a communication interface. The measuring transducer 1 forwards the measurement data to the control system. In this case, the control system is designed as a process control system (PLC), a PC or a server. For this purpose, the measuring transducer 1 sends the data via a communication protocol that the control system can understand, for example a fieldbus, such as HART, Profibus PA, Profibus DP, Foundation Fieldbus, Modbus RS485, or an Ethernet-based fieldbus, such as Ethernet / IP, Profinet or Modbus / TCP.

[0089] The measuring transducer 1 comprises a display 6 and one or more operating elements 7, such as rotary knobs or rotary knobs, buttons or soft keys, via which the measuring transducer 1 can be operated. The measurement data of the sensor are displayed, for example, by the display 6. The sensor can also be configured and parameterized via the operating elements 7 and the corresponding views on the display 6. The display 6 can also be designed as a touch display; the operating element 7 can also be part of the touch display, i.e. as a touch operating element. The measuring transducer 1 comprises a data processing unit 3. The measuring transducer 1 can also comprise an SD card slot 8, via which apps can be loaded onto the measuring transducer 1. The measuring transducer 1 can also comprise one or more wireless modules, such as Bluetooth, mobile radio (2G, 3G, 4G, 5G) or other, possibly wireless, bus protocols, such as WirelessHART, by means of which the app 2 can be loaded.

[0090] As mentioned, the measuring transducer 1 or a sensor connected thereto can be operated and parameterized via the operating element 7. For this purpose, a menu or a menu structure is displayed on the display 6. The menu structure describes the hierarchy, navigation and text of the individual menu pages shown on the display 6. The menu structure makes it possible to select the desired command from the offered content and execute it.

[0091] The operating system of the measuring transducer 1 is designed as a real-time operating system.

[0092] Terms important to the process described further are defined below.

[0093] A "process" is a computer program at runtime. More precisely, a process is a specific instantiation of a program's execution within a computer system, supplemented by further (management) information and resource allocations of the operating system for this execution. A process is the execution environment of a program on a computer system. A "process" is identified with the reference symbol 11. If multiple processes are mentioned in an example, they are marked with subscript numbers, e.g., if there are two processes, " "and" ”, or if there are n processes, then the i-th process is “ ”.

[0094] A "thread" is a line of execution or sequence of execution in a program process. A thread is part of a process. Threads in the narrow sense are sometimes called kernel threads and run under the control of the operating system. A (kernel) thread is a sequential execution run within a process and shares many resources with other existing threads (multithreading) of the associated process, such as the code segment, data segment, and used file descriptors. Threads within the same process can be assigned to different processors. A "thread" is identified by the reference symbol 12. If multiple threads are mentioned in an example, they are marked with subscript numbers, for example, for two threads, " "and" ”, or for n threads, the i-th thread is “ ”.

[0095] A "system call" is an interface for the application logic of a thread to access system resources or functionalities, such as sensor communication functions via the serial interface of the measuring transducer 1. A "system call" is identified with reference symbol 25. If multiple system calls are mentioned in an example, they are marked with subscript numbers, for example, for two system calls, " "and" ", or accompanied by n system calls, the i-th system call is " ”.

[0096] A "subsystem" is a logically related component that manages system resources or functionality. Application logic gains access to the functionality of a subsystem via a system call. In the further description, it is then understood that a system call implements, manages or is assigned to a subsystem. In this application, the terms system call and subsystem are strictly distinguished only when necessary and are used synonymously otherwise.

[0097] As a special feature, there may be system resources as system elements of a computer system (hardware or software) which can or are only allowed to be used by a single process. For example, a serial interface of a measuring transducer 1 intended for sensor communication may be assigned to exactly one process so that only this process is allowed to use system calls for sensor communication.

[0098] Since threads assigned to the same process use the same memory address space, communication between these threads is very easy from the beginning.

[0099] As part of the present application, system calls 25 (see below) are hosted by one or more processes 11. A thread 12 is allowed to call a system call 25 only if the process 11 to which the thread 12 is assigned hosts the system call 25.

[0100] Other system resources are not exclusively bound to processes. This means that they can be used jointly by all threads from all processes. Shared use of resources can also lead to conflicts. These must be resolved by using synchronization mechanisms.

[0101] One such measure is "mutual exclusion", also known as locking or mutex. When sharing system resources (i.e., using system calls 25 from multiple processes 11 simultaneously), critical parts that would cause conflicts without synchronization measures are protected by lock variables (also known as mutexes or semaphores). Therefore, the program code that manages system resources is executed from all processes 11.

[0102] Another measure is message exchange, also referred to as message passing. Here, the program code that manages system resources can only be executed from a precise process 11. The calling process 11 that wants to access system resources via a system call 25 sends a message to the implementing process 11.

[0103] For example, to prevent long-running signal processing from slowing down the GUI system, the signal processing and the parameter system (see below) must be run in separate threads in order to decouple the two processing threads from each other. Subsystems (such as sensor communication) are partially assigned to one or more operating system processes and are only allowed to be used within these assigned processes using system calls 25. An operating system process is often also referred to as a host process, in this case process 11 on the measurement transducer 1.

[0104] If the measuring transducer 1 is now made app-capable as described above, and in particular a virtual machine (VM) is used for this purpose (see Virtual Machine below), the situation changes as follows: the host process becomes a virtual processor that executes the VM's app 2; the application logic is completely or partially migrated from the usual native host implementation to the app thread 12, and the app thread 12 is executed in the virtual machine in the context of the process 11 on the measuring transducer 1. This will first be explained by way of example.

[0105] Similar to a general purpose operating system, it makes sense to initially execute any app thread 12 on any host process 11. However, such an embodiment is usually not possible on an app-enabled field device 1 whose firmware is subsequently extended to allow apps to be loaded, or only after a large (error-prone) refactoring of the firmware. The reason for this is that on such RTOS-based firmware, the host processes are not equivalent and host different subsystems in addition to the VM. Assume that the first subsystem is started via the (first) system call is addressed and assigned to the first host process . Then only in the host process The app thread running in Only then are system calls allowed For illustration, see Figure 3 . Therefore, in the second host process The second app thread running on Not allowed to call the first process any functionality in the system, because otherwise serious errors such as data corruption may occur, with consequences such as system crashes: via the (first) system call The managed first subsystem is not prepared for the data it manages to be changed by other processes or threads during processing.

[0106] In an app-supporting system in which the app allows multiple quasi-parallel threads via multithreading, there is no predetermined system architecture: the app code cannot know the system architecture of all host systems on which the app code is executed. Without the measures according to the invention, the app code can therefore perform arbitrary, undefined accesses, which means that stable operation of the system cannot be ensured.

[0107] Thus, the system call 25 is initially provided by the measurement transducer 1. The system call 25 is implemented on the host 1 and provides functionality for the plugin 2 ("app"). For example, the measurement transducer 1 can provide a procedure to read or write a specific memory area via the system call 25. The system call 25 is defined, for example, by a versioned interface specification. Other examples are sensor parameters, sensor configuration or extended calculation procedures. The system call 25 has a name, a unique identifier (system call identifier) ​​and a version. The same procedures apply to the system call 25 as for the app functionality 22 (see below).

[0108] Instead of refactoring the firmware of the measurement transducer (which is error prone) so that all system calls 25 can be called from all app threads 12 from all host processes 11, the present invention restricts the degrees of freedom that are not required for successful execution of the app. Thus, the refactoring work in the firmware to support the app is minimized.

[0109] The app 2 comprises at least a program code with at least one app function 22, and one or more threads 12, wherein each app function 22 is associated with one or more threads 12. It is determined which system calls 25 are called by each thread 12. Finally, at runtime it is checked with the aid of an authorization matrix whether the threads 12 actually only call the system calls 25 for which the threads 12 are authorized. If there is authorization, the execution of the system call 25 occurs, and if there is no authorization, the app 2 is terminated.

[0110] The above specifications must be executable at runtime. At the development time of app 2, it must preferably be possible to determine which app threads 12 app 2 consists of and which subsystems they call. Such a procedure limits unnecessary degrees of freedom when assigning app threads 12 to processes 11 on the measurement transducer 1 and thus simplifies the implementation of the measurement transducer, since the interaction between the app and the host (measurement transducer) that was excluded from the beginning no longer needs to be considered in the implementation. Therefore, a correct implementation of the system call 25 including the assignment to the host process 11 must take into account far fewer interaction possibilities. This greatly simplifies the (subsequent) implementation of scalability through the app in the measurement transducer.

[0111] Therefore, the app interface description for the measuring transducer states

[0112] • which app functions 22 must be provided by app 2 running on measuring transducer 1,

[0113] • measure which system calls 25 transducer 1 makes to app 2,

[0114] • Which app threads 12 does app 2 consist of?

[0115] • which app threads 12 provide app functionality 22, and

[0116] •Which system calls 25 are called by the app thread 12?

[0117] This interface description may be referred to as a virtual host architecture or a virtual measurement transducer architecture.

[0118] Figure 2 A (virtual) host architecture according to the claimed process is shown. Figure 2 It shows how a certain number of threads 12 can access a certain number of system calls 25, and which threads 12 supply which app functions 22; this is also called app interface thread deployment.

[0119] App 2 uses two threads here, and These threads are necessary for the measurement value processing MS, the parameter system PMS and the graphical user interface GUI. The measuring transducer 1 supplies the system calls , , and . First Thread The host 1 is provided with an app function 22 to access the measurement value processing MS. Second thread The host is provided with app functions 22 for the parameter system PMS and the graphical user interface GUI.

[0120] The principle is that the thread 12 "stays (docked)" on top and thus makes computing time available for the app internal code in the relevant context. The routines running there can now in turn call system calls 25 on the host side. These run in the context of the relevant thread 12 executing the relevant code. Now it is important to prevent that every thread 12 is allowed to call every (arbitrary) system call 25, because the system calls implemented there can usually only be safely executed in a specific context (i.e. a specific thread). In order to be able to let every thread 12 call every system call 25, the overhead on the host side will be greatly increased.

[0121] Figure 2 The app interface thread deployment in is now specified in a binding fashion: a thread 12 "entering" from the top can only "come out" from the bottom via a very specific system call 25. Host 1 now only has to functionally ensure this set of bindings of possibilities in order to be able to execute app 2 correctly.

[0122] In summary, thread 12 is at the top calling into app, and comes out at the bottom with system call 25 that may have triggered on the host, and the thread identifier listed indicates which thread Which system calls are allowed Occurs everywhere.

[0123] Figure 2 The top circle indicates functionality provided by app 2. These functionalities are assigned to app threads. The functionality implemented behind the "circle" triggers a system call. Since the "circle" runs inside app thread 12, system call 25 is ultimately executed by app thread 12, which in turn runs on host process 11. Therefore, you can see in the following Figure 2 Which app thread is seen in Which system call can be finally triggered (or allowed to execute depending on the virtual host architecture).

[0124] In principle, the number n of supported app threads 12 is not limited by app 2, but is fixed per host architecture, while the number of system calls 25 is limited.

[0125] If a virtual host architecture is given, the developer of the firmware of the measurement transducer must define how the threads 12 and system calls 25 are mapped to the host process 11 , ie how to concretely implement the virtual host architecture on the measurement transducer 1 .

[0126] The measuring transducer 1 knows the type of implementation, i.e. the interface description, and stores it in the firmware. Based on the interface specification, the data structures required for checking the authorization can be generated (see below).

[0127] In one embodiment, all apps 2 have the same interface description, or app 2 must comply with the same interface. Therefore, as long as the interface remains unchanged, no firmware update of the host is required. If the interface evolves and app 2 requests a newer version of the interface, a firmware update is required.

[0128] In one embodiment, the measurement transducer 1 supports multiple versions of interfaces. The software architecture of the measurement transducer 1 is then designed to map the virtual host architecture of all interfaces to be supported.

[0129] For a measurement transducer executing app 2 with the above interface, the firmware is implemented to comply with the virtual host architecture.

[0130] As described above, the system calls 25 are implemented so that they can be directly called by all app threads 12 used and their corresponding function calls of the host process 11. Therefore, the host process 11 directly accesses the data of the subsystem managed by the system call 25 (shared memory method). In order to avoid conflicts caused by simultaneous access by multiple host processes 11, locks are used.

[0131] Alternatively, the developer of the firmware for the measurement transducer may choose to map the subsystem including the associated system calls 25 and all app threads 12 that call these system calls 25 to a single host process 11. This eliminates the need for the coordination of multiple host processes 11 including the associated subsystem's system calls 25 described above.

[0132] Another alternative is to implement the subsystem corresponding to the system call 25 in a single first host process 11. App threads 12 mapped to other host processes 11 can request the system call 25 via message passing. The subsystem assigned to the system call 25 then runs only in the first host process 11, processes the request, and then sends a response message to the other host processes 11 and the app threads 12 running there.

[0133] The developer of the firmware of the measuring transducer is responsible for choosing the distribution of the system calls 25 and the app threads 12 to the host processes 11 sent to the firmware, including the appropriate implementation strategy just described. It is also easy to imagine choosing different strategies for each system call 25.

[0134] Instead of spending a lot of effort on typically preparing the firmware for the measurement transducer so that each app thread can use each system call, the complexity of the host-side implementation is now reduced by defining a virtual host architecture.

[0135] Figure 3 Shown from Figure 2 Implementation of the virtual host architecture. The system call 25 allowed into the app thread 12 is indicated by an arrow. All other calls are not allowed.

[0136] Two host processes and Running on measurement transducer 1. They contain app threads for executing app 2 and virtual machines. They act as two app threads and The first and second system calls or Can be assigned exclusively to the first process , and can be accessed from the thread Therefore, no implementation is needed to make it available, also from the second app thread (and thus from the host process ). The third system call Assigned exclusively to the second process and the second thread . The fourth system call It is a thread and The example implements the "shared memory" method: assigning to the system call The subsystem is implemented so that it can be called directly from the first host process via a function and the second host process Call it. This accordingly expands to two processes and If assigned to the fourth system call The subsystem contains host processes that must be prevented from and If a data structure or resource is accessed concurrently, the subsystem must use locks.

[0137] When app 2 is running, the measurement transducer 1 must enforce that the app thread 12 only calls the system calls 25 for which it is authorized. If the app thread 12 calls the system call 25, then:

[0138] • the VM adds at least one identification of the calling app thread 12 - for example a thread identifier - to the system call 25,

[0139] •When the system call 25 is entered, the system call 25 must use the thread identifier to check whether the app thread 12 is authorized to call the system call 25.

[0140] • If authorization exists, system call 25 is executed.

[0141] • If authorization does not exist, app 2 is terminated, for example with an error message; another alternative is to not terminate app 2, but to let the system call 25 return an error code, to which app 2 must react in an appropriate way, for example by terminating with an error.

[0142] Various algorithms and data structures can be used to check whether a thread 12 is authorized to execute a system call 25. For this purpose, an authorization matrix is ​​used, in which, for example, a Boolean value of an authorization definition is stored for each combination of an app thread 12 and a system call 25.

[0143] The possible implementations are:

[0144] • Each system call 25: a bit vector of length n equal to the number of threads 12, with bit i set to indicate a thread Allowed to call related system calls 25;

[0145] • Each thread 12: a bit vector of length n equal to the number of system calls 25, with bit i set to indicate that thread 12 is allowed to call the system call ;

[0146] • for each system call 25: a sorted list of unique thread identifiers that are allowed to call the system call 25, wherein it is checked whether the system call 25 is allowed to be called by the thread 12 by means of a binary search, wherein the binary search searches the sorted list of unique thread identifiers for the thread identifier of the calling thread 12;

[0147] • for each thread 12: a sorted list of unique system call identifiers that the thread 12 is allowed to call, wherein it is checked whether the thread 12 is allowed to call the system call 25 by means of a binary search, wherein the binary search searches the sorted list of unique system call identifiers for the system call identifier of the system call 25 to be called;

[0148] • Per system call 25: a (balanced) binary search tree of unique thread identifiers that are allowed to call system call 25;

[0149] • For each thread 12: a (balanced) binary search tree of unique system call identifiers that thread 12 is allowed to call;

[0150] • per system call 25: a hash table of unique thread identifiers that are allowed to call system call 25; or

[0151] • Per thread 12: a hash table of unique identifiers of the system calls 25 that thread 12 is allowed to call.

[0152] On the contrary, it must also be enforced that the host process 11 only calls those functions 22 that the app thread 12 makes available to it. The same issues as for the system call 25 also apply when calling the app function 22. Similar to the system call 25 and the app thread 12, a (second) authorization matrix is ​​introduced, which specifies whether the host process is allowed to call the app function 22 of the thread 12. If the host process 11 wants to call the app function 22 on the app thread 12, the second authorization matrix is ​​checked in advance. If no authorization exists for the app thread 12 executed by the host process 11, it is regarded as a firmware implementation error in the host. Possible algorithms and data structures for checking authorization are similar to those for the system call 25, so the second authorization matrix can be implemented as follows:

[0153] • Each app function 22: a bit vector with a length equal to the number of threads 12, with bit i set to indicate thread Allowed to call related app functions 22;

[0154] • Each thread 12: a bit vector with a length equal to the number of app functions 22, with bit i set to indicate that thread 12 is allowed to call app functions ;

[0155] • for each app function 22: a sorted list of unique thread identifiers that are allowed to call the app function 22, wherein it is checked whether the app function 22 is allowed to be called by the thread 12 by means of a binary search, wherein the binary search searches the sorted list of unique thread identifiers for the thread identifier of the calling thread 12;

[0156] • for each thread 12: a sorted list of unique app function identifiers that the thread 12 is allowed to call, wherein it is checked whether the thread 12 is allowed to call the app function 22 by means of a binary search, wherein the binary search searches the sorted list of unique app function identifiers for the app function identifier of the app function 22 to be called;

[0157] • per app function 22: a (balanced) binary search tree of unique thread identifiers that are allowed to call the app function 22;

[0158] • per thread 12: a (balanced) binary search tree of unique app function identifiers that thread 12 is allowed to call;

[0159] • per app function 22: a hash table of unique thread identifiers that are allowed to call the app function; or

[0160] • Per thread 12: A hash table of unique identifiers of app functions 22 that the thread 12 is allowed to call.

[0161] Furthermore, it must be ensured that the host process 11 only executes the app threads 12 assigned to it. This is checked via a (third) authorization matrix. This third authorization matrix is ​​not derived from the virtual host architecture, but is derived from the virtual host architecture implementation chosen by the firmware developer of the measurement transducer. The third authorization matrix can be implemented as follows:

[0162] • Each host process 11: a bit vector with a length equal to the number of threads 12, with bit i set to indicate that the host process 11 is allowed to execute the app thread ;

[0163] • Each thread 12: a bit vector having a length equal to the number of host processes 11, with bit i set to indicate that thread 12 is allowed to be hosted by the host process implement;

[0164] • for each host process 11: a sorted list of unique thread identifiers that the host process 11 is allowed to call, wherein it is checked whether the host process 11 is allowed to execute a thread 12 by means of a binary search, wherein the binary search searches the sorted list of unique thread identifiers for the thread identifier of the thread 12 to be executed;

[0165] • for each thread 12: a sorted list of unique host process identifiers that the thread 12 is allowed to execute, wherein it is checked whether the thread 12 is allowed to be executed by the host process 11 by means of a binary search, wherein the binary search searches the sorted list of unique host process identifiers for the host process identifier of the executing host process 11;

[0166] • For each host process 11: a (balanced) binary search tree of unique thread identifiers that the host process 11 is allowed to execute;

[0167] • For each thread 12: a (balanced) binary search tree of unique host process identifiers that are allowed to execute thread 12;

[0168] • For each host process 11: a hash table of unique thread identifiers that the host process 11 is allowed to execute; or

[0169] • Per thread 12 : A hash table of unique identifiers of the host processes 11 that are allowed to execute thread 12 .

[0170] As mentioned, the measuring transducer 1 must be able to load and execute the app 2, for example by means of a firmware implementing a virtual machine, in which the app 2 is interpreted / executed. The virtual machine is designed as an interpreter, in particular an emulator, an ahead-of-time compiler, a just-in-time compiler, a hypervisor or a combination thereof. The CPU architecture of the measuring transducer and of the connected device on which the app 2 runs does not necessarily have to be the same. However, especially in the case of a hypervisor, it is recommended that embodiments of the app be implemented to select the same CPU command set.

[0171] In the embodiment as a virtual machine, inherent measures for memory protection and therefore also security are obtained. Possible malicious code cannot get out of the scope of the virtual machine and, as a result, cannot negatively influence the firmware or other running virtual machines (several virtual machines can be run in parallel, see below). There is a separation between the different virtual machines, since no common memory areas are used. The different virtual machines interact only via defined interfaces, so that only limited functions can be executed as a result. The virtual machine, especially in its embodiment as an interpreter (emulator), forms an environment for executing apps in the form of a virtual CPU with a virtual working memory. In this case, the system is isolated from the rest of the system, i.e. the host system, i.e. the firmware of the sensor. If the app is defective, it does not affect the rest of the system. Even if the defective extension crashes, the rest of the system continues to operate. Communication takes place via defined interfaces.

[0172] However, the app 2 can also be run "natively" on the measuring transducer 1. For this purpose, the measuring transducer 1 comprises, for example, an ahead-of-time compiler or a just-in-time compiler. The app 2 is present on the basic system 1 in a corresponding format.

[0173] If emulation does not take place via a virtual machine (see above) and the CPU architectures of the host and guest match, processor support of the measurement transducer 1 is needed to execute the app; for example a memory management unit (MMU) is needed in hardware to enable memory protection.

[0174] In order to interpret / run app 2, app 2 must contain program code in a form that is interpretable / executable or can be converted to an interpretable / executable form, such as machine-independent byte code. Likewise, the program must be stored in a binary format, such as the Executable and Linking Format (ELF). The binary format provides information about the memory layout of the app, such as the location and size of code and data. This information is necessary to load app 2 and prepare it to run.

[0175] The program code may be executed via an interpreter (virtual machine) or may be translated into machine code for the processor used on the underlying system (compiler) before execution.

[0176] Reference numerals list

[0177] 1 Measuring transducer

[0178] 2 apps

[0179] 3 Data processing unit

[0180] 4 Memory

[0181] 5 Parent Unit

[0182] 6 Display

[0183] 7 Operating elements

[0184] 8 SD card slot

[0185] 11 Process

[0186] 12 Threads

[0187] 21 Interface Stub

[0188] 22 app features

[0189] 23 Main Logic

[0190] 24 System call stubs

[0191] 25 System calls

[0192] MS measurement processing

[0193] PMS parameter system

[0194] GUI Graphical User Interface

Claims

1. A process for successfully executing an app (2) on a measuring transducer (1) for process automation technology, in, The firmware of the measuring transducer (1) is designed to receive and store the app (2), wherein the measuring transducer (1) is designed to execute one or more processes (11), The process includes the following steps: - providing a system call (25) from said measurement transducer (1); – if the app (2) is not already located on the measuring transducer (1), sending the app (2) to the measuring transducer (1), The app (2) at least comprises a program code having at least one app function (22), and generates and executes one or more threads (12) during operation. Each app function (22) is assigned to one or more threads (12). Therein, determining which system calls (25) each thread (12) is authorized to use, and wherein determining which thread (12) is executed in which process (11); and - executing the app (2) on the measuring transducer (1); and at least one of the process steps a), b) and / or c), said process step comprising a) checking at runtime with the aid of a first authorization matrix whether the thread (12) actually uses only the system calls (25) for which the thread (12) is authorized: • If authorization exists, execution of the system call (25) occurs, and • If authorization does not exist, the app (2) is terminated; b) At runtime, it is checked with the aid of a second authorization matrix whether the process (11) calls only those functions (22) that the thread (12) makes available to it: • If authorization exists, execution of said function (22) occurs, and • If no authorization exists, it is deemed that a firmware implementation error has occurred in said host; c) Checking at runtime with the aid of a third authorization matrix whether the process (11) executes only the threads (12) assigned to it: • If authorization exists, the thread (12) is executed by the process (11), and • If authorization is not present, it is considered a firmware implementation error in the host in question.

2. The process according to claim 1, in, The system call (25) can be called by more than one thread (12), and the shared resources are collectively protected from concurrent access by appropriate protection mechanisms, in particular by locks in the shared memory model and message passing in the isolated memory model.

3. The process according to claim 1 or 2, in, The system call (25) and the thread (12) that calls it are mapped to a single process (11).

4. The process according to any one of the preceding claims, in, The step of checking at runtime with the aid of the first authorization matrix whether the thread (12) actually uses only the system calls (25) for which the thread (12) is authorized comprises one or more of the following measures: • Each system call (25): a bit vector with length (n) equal to the number of threads (12), with bit i set to indicate the thread ( ) is allowed to call the relevant system call (25); • Each thread (12): a bit vector of length (n) equal to the number of system calls (25), with bit i set to indicate that the thread (12) is allowed to call the system call ( ); • For each system call (25): a sorted list of unique thread identifiers i that are allowed to call said system call (25), wherein, by means of a binary search, it is checked whether said system call (25) is allowed by thread ( ) call; • For each thread (12): a sorted list of unique system call identifiers i that the thread (12) is allowed to call, wherein, by means of a binary search, it is checked whether the thread (12) is allowed to call a system call ( ); • For each system call (25): in particular, a balanced binary search tree of unique thread identifiers i, corresponding to the threads that are allowed to call the system call (25) ( ); • For each thread (12): in particular, a balanced binary search tree of unique system call identifiers i, corresponding to the system calls (i) that the thread (12) is allowed to call. ); • Per system call (25): a hash table of unique thread identifiers i, corresponding to the threads that are allowed to call the system call (25) ( ); • For each thread (12): a hash table of unique system call identifiers i, corresponding to the system calls (i) that the thread (12) is allowed to call ).

5. The process according to any one of the preceding claims, in, The step of checking at runtime with the aid of the second authorization matrix whether the process (11) calls only those functions (22) that the thread (12) makes available to it comprises one or more of the following measures: • Each app function (22): a bit vector with length equal to the number of threads (12), with bit i set to indicate the thread ( ) is allowed to call related app functions (22); • Each thread (12): a bit vector with length equal to the number of app functions (22), with bit i set to indicate that the thread (12) is allowed to call app functions ( ); • for each app function (22): a sorted list of unique thread identifiers that are allowed to call said app function (22), wherein it is checked whether said app function (22) is allowed to be called by a thread (12) by means of a binary search, wherein said binary search searches said sorted list of unique thread identifiers for said thread identifier of the calling thread (12); • for each thread (12): a sorted list of unique app function identifiers that the thread (12) is allowed to call, wherein it is checked whether said thread (12) is allowed to call an app function (22) by means of a binary search, wherein said binary search searches said sorted list of unique app function identifiers for said app function identifier of said app function (22) to be called; • Each app function (22): specifically, a balanced binary search tree of unique thread identifiers that are allowed to call the app function (22); • per thread (12): in particular, a balanced binary search tree of unique app function identifiers that are allowed to call said thread (12); • Each app function (22): a hash table of unique thread identifiers that are allowed to call the app function (22); • Per thread (12): A hash table of unique identifiers of the app functions (22) that the thread (12) is allowed to call.

6. The process according to any one of the preceding claims, in, The step of checking at runtime by means of the third authorization matrix whether the process (11) executes only the thread (12) assigned to it comprises one or more of the following measures: • Each process (11): a bit vector with a length equal to the number of threads (12), where setting bit i indicates that the process (11) is allowed to execute the app thread ( ); • Each thread (12): a bit vector with length equal to the number of processes (11), with bit i set to indicate that the thread (12) is allowed to be executed by process ( )implement; • for each process (11): a sorted list of unique thread identifiers that said process (11) is allowed to call, wherein it is checked whether said process (11) is allowed to execute said thread (12) by means of a binary search, wherein said binary search searches said sorted list of unique thread identifiers for said thread identifier of said thread (12) to be executed; • for each thread (12): a sorted list of unique process identifiers that the thread (12) is allowed to execute, wherein it is checked whether said thread (12) is allowed to be executed by a process (11) by means of a binary search, wherein said binary search searches said sorted list of unique process identifiers for said process identifier of the executing process (11); • Each process (11): specifically, a balanced binary search tree of unique thread identifiers that process (11) is allowed to execute; • Each thread (12): specifically, a balanced binary search tree of unique process identifiers of the threads (12) that are allowed to execute; • For each process (11): a hash table of unique thread identifiers that the process (11) is allowed to execute; • Per thread (12): a hash table of unique identifiers of the processes (11) that are allowed to execute said thread (12).

7. The process according to any one of the preceding claims, in, The firmware of the measurement transducer comprises the first authorization matrix, the second authorization matrix and / or the third authorization matrix.

8. The process according to any one of the preceding claims, in, The operating system of the measuring transducer (1) is designed as a real-time operating system.

9. The process according to any one of the preceding claims, in, The program code also includes at least: • Main logic (23); and • A system call stub (24), by means of which functions in the base system (1) are called.

10. The process according to any one of the preceding claims, in, The firmware of the measuring transducer (1) implements a virtual machine in which the app (2) runs.

11. The process according to the preceding claim, in, The virtual machine is designed as a just-in-time compiler, an ahead-of-time compiler, a virtual machine hypervisor or a combination thereof, and the app (2) exists on the basic system (1) in a corresponding format.

12. The process according to any one of the two preceding claims, in, A plurality of interpreters / compilers / hypervisors can be executed in the measuring transducer (1), in particular each interpreter / compiler / hypervisor executes only one app (2).

13. A measuring transducer (1) for performing some steps of the process according to any of the preceding claims, comprising • A data processing unit (14) with a memory (5).

14. A computer program product comprising program instructions which, when executed on a measuring transducer (1), cause the measuring transducer (1) to perform at least some of the steps of the process according to any of the preceding claims.

15. A computer readable medium on which is stored a computer program according to the preceding claim.

Images