Method and system for data processing

Abstract

The system (100) comprises an edge computing device (ECD) having a sensor (S), and a first central server (CS), where the central server (CS) is arranged to accept a query, the result of which comprises an endless flow of data objects calculated based on data measured by said sensor (S). A central server (CS) parses the query to generate a parsed query expression; generating an execution plan corresponding to the analyzed query expression; and compiling at least a portion of the execution plan by converting the execution plan into a corresponding platform-independent assembly code. An edge computing device (ECD) receives an at least partially compiled execution plan, and it interprets a software function (ES) to run both compiled and uncompiled portions of the partially compiled execution plan to produce query results. The invention also relates to a method.

Description

[0001] The present invention relates to methods and systems for data processing. In particular, the methods and systems of the present invention relate to data processing in an Internet of Things (IoT) environment, comprising a plurality of physically separate edge devices and possibly one or more central devices, all such devices being interconnected for digital communication, such as over the Internet.

[0002] More specifically, the present invention relates to a method of distributing and deploying software functionality on such a system.

[0003] More specifically, the present invention relates to the processing of data collected by such edge devices, and to producing processed data useful for automatically determining and performing various actions.

[0004] In IoT applications, it is known to use more or less autonomous edge devices that can act as sensors and / or participants in an IoT system. Such edge devices can be based on hardware and also more or less on software. For example, such edge devices can be arranged with dedicated hardware implementing certain logic, or generally programmable, running an operating system such as FreeRTOS or Android © .

[0005] Generally, once such a system is installed with edge devices, the installation tends to be relatively static. For example, in many conventional systems, activities such as additional component installation, testing, simulation, functional changes, etc. are time consuming. Even in cases where parameters or the like can be used to configure the edge devices, the functionality of the edge devices can be limited to use cases envisioned by the installation operator.

[0006] Hence, one problem with conventional distributed IoT systems is flexibility of functionality in terms of initial design, deployment, and further development and update. This is particularly true when existing and legacy hardware is employed.

[0007] Another problem is performance and scalability, in view of the large amount of measurement data that many such systems need to process. Real-time requirements are often challenging, and available hardware resources at each edge component are often limited.

[0008] Yet another problem is maintenance, including testing and simulating new operational scenarios or hypothetical operational scenarios.

[0009] Another problem is usability. It would be desirable to have a system that can be deployed, used, developed and maintained without requiring in-depth knowledge of the programming or technical details of the system, in a wide range of applications.

[0010] It is therefore desirable to provide a massively scalable IoT system comprising a plurality of edge devices and possibly one or more central units, which system provides improved flexibility in terms of functionality during design, deployment, further development and maintenance, and which is easy to deploy.

[0011] SE 2050998-0 A discloses a general configuration of a massively distributed system capable of achieving at least one of the above-mentioned objectives.

[0012] However, it is desirable to implement a way for distributing software functionality in such a system which allows for seamless and quick deployment and use of such functionality on any sub-portion of such a system, even in the presence of heterogeneous prerequisites in terms of hardware, operating system, etc.

[0013] Such a system and method for distributing and deploying software functionality should also be capable of being dynamically and interactively distributed and deployed by non-programmer users, e.g. in the general manner described in the previously mentioned Swedish patent application.

[0014] The present invention solves at least some of the above-mentioned problems.

[0015] Embodiments of the present invention thus relate to a system comprising a number of edge computing devices and a first central server, each such edge computing device and each such central server in turn comprising: a memory; a central processing unit, CPU; and a digital communication interface arranged to allow digital communication over a digital communication network. Each of the edge computing devices can further comprise a sensor. The central server can be arranged to accept a query from a querying party and via the digital communication interface, the result of the query comprising at least one stream of data objects, at least one of the streams being an endless stream of objects computed based on data measured by the sensor and continuously or intermittently provided over time and communicated via the digital communication interface, the endless stream having no defined end point at the time of querying.

[0016] The central server can be arranged to perform the steps of: a) parsing the query to produce a parsed query expression; b) producing an execution plan corresponding to the parsed query expression; and c) compiling at least part of the execution plan by converting the at least part of the execution plan into corresponding platform-independent assembly code, thereby obtaining an at least partially compiled execution plan.

[0017] At least one of the edge computing devices can be arranged to subsequently receive the at least partially compiled execution plan via the digital communication interface.

[0018] The at least one of the edge computing devices can be arranged with an interpreted software function arranged to be executed on the CPU of the edge computing device and to run both the compiled and uncompiled parts of the at least partially compiled execution plan by means of an interpretation of at least part of the at least partially compiled execution plan.

[0019] Each edge computing device can be arranged to, when running the at least partially compiled execution plan, produce a first result of the at least partially compiled execution plan and communicate the first result via the digital communication interface.

[0020] The at least partially compiled execution plan can define a computation to be performed based on measurement values from the sensors.

[0021] The considered edge computing device can be arranged to perform the computation as part of the interpretation.

[0022] The query can be defined according to a query language having a predetermined syntax arranged to define queries whose results comprise at least one data stream and to allow the definition of the query according to a computation to be performed based on measurement values from the sensors.

[0023] The query language can be an object-oriented query language.

[0024] The parsing can comprise parsing the query into an equivalent abstract syntax tree, such as into S-expressions.

[0025] The parsing can be into a representation that is one or more of the following types: declarative; object-oriented; based on predicate logic, e.g. employing multi-way external functions; strongly typed; and relational.

[0026] The representation can be extendable by providing primitives for user-defined predicates, e.g. in terms of multi-way external functions where different instantiations are provided depending on the known / unknown status of the external function argument.

[0027] The compiling step can comprise the central server transcribing at least part of the assembly code into platform-specific assembly code.

[0028] Any uncompiled part of the execution plan can be run by the edge computing device's interpreted software function interpreting the considered execution plan part; while any compiled part of the execution plan can be run by the edge computing device's interpreted software function directly initiating its execution by the edge computing device's CPU.

[0029] In the compiling step, there can be a case where only or at least the arithmetic part of the execution plan is to be compiled.

[0030] The central server can be arranged to save the platform-independent assembly code for later reuse.

[0031] The central server can be arranged to transcribe the saved platform-independent assembly code into platform-specific code for different edge computing devices.

[0032] Each sensor and / or edge computing device can be able to refer to a global namespace or set of properties according to said syntax.

[0033] Each edge computing device can be arranged to discard at least some of the measurement data, preferably all of the measurement data, measured by the sensor after having communicated said measurement data and / or a piece of information such as said result computed based on said measurement data over said digital communication interface, instead of storing the measurement data in said memory.

[0034] The system can further comprise a distributed or monolithic central server, each of said edge computing devices having a client role with respect to this central server, wherein all communication between the various edge computing devices can then take place via said central server.

[0035] The interpreted software function can comprise an external application programming interface, API, arranged to allow an expression in said query language to call external computer code and / or to allow external computer code to call an expression in said query language.

[0036] The interpreted software function can comprise a machine learning function arranged to define, train and execute a machine learning model such as a neural network.

[0037] The memory of said edge computing device can comprise a defined and trained machine learning function referenced by an expression of the query interpreted by the considered interpreted software function executing on the edge computing device.

[0038] The considered interpreted software function can be arranged to train said defined machine learning function based on said result of said query.

[0039] Embodiments of the invention relate to a method for collecting data in a system comprising several edge computing devices and a first central server, each such computing device and each such central server in turn comprising: a memory; a central processing unit, CPU; and a digital communication interface arranged to allow digital communication over a digital communication network; each of said edge computing devices further comprising a sensor.

[0040] The method can comprise the steps of: a) the central server accepts a query from an inquirer and via said digital communication interface, the result of the query comprising at least one stream of data objects, at least one of said streams being an endless stream of objects, the endless stream being computed based on data measured by said sensors and being provided continuously or intermittently over time and communicated via said digital communication interface, said endless stream having no defined end point at the time of the query; b) the central server parses said query to produce a parsed query expression; c) the central server produces an execution plan corresponding to the parsed query expression, said execution plan defining computations to be performed based on measurements from said sensors; d) the central server compiles at least part of the execution plan by converting said at least part of the execution plan into corresponding platform-independent assembly code; e) at least one of said edge computing devices receives at least a partially compiled execution plan via said digital communication interface; and f) an interpreting software function of said at least one of said edge computing devices executes on said CPU of said edge computing device and runs both compiled and uncompiled parts of said at least partially compiled execution plan to produce a first result of said at least partially compiled execution plan, said interpreting including execution of said computations.

[0041] In the following, the present application will be described in detail with reference to exemplary embodiments of the application and to the accompanying drawings, in which: Figure 1 A client device according to the application is shown; Figure 2 is an overview of a system according to the application adapted to perform a method according to the application; Figure 3 is an overview of a domain name server database configuration; Figure 4a is a first overview of an architecture of an interpreting software function; Figure 4b is a second overview of an architecture of an interpreting software function, showing more details than Figure 4a the core functionality of said interpreting software function; Figure 5 A constellation of edge computing devices and a central server is shown; Figure 6 is a flow chart exemplifying a first method; Figure 7 is a flow chart exemplifying a second method; Figure 8 is a flow chart exemplifying a third method; Figure 9is a flowchart illustrating the fourth method; Figure 10 information flow in the system is illustrated; Figure 11a an exemplary full-engine edge computing device is illustrated; and Figures 11b to 11d first, second and third exemplary thin-engine edge computing devices are respectively illustrated.

[0042] In the drawings, identical reference numerals have been used, where possible, to designate identical elements common to the figures.

[0043] The present invention relates to a system 100 as generally illustrated in Figure 2 comprises Figure 1 a number of edge computing devices (EDC) 110, 120, 130, 140 of the general type as illustrated in

[0044] Each such edge computing device EDC is a piece of computing hardware comprising a respective sensor S, a memory M, a central processing unit CPU and a digital communication interface IF.

[0045] The sensor S can be any type of sensor arranged to measure a parameter at the edge computing device EDC under consideration. The parameter can represent a physical property at or near the edge computing device EDC, wherein the sensor can be: a light sensor; a camera sensor; a temperature sensor; a sound sensor; an electric or magnetic sensor, such as a current, voltage, impedance or magnetic field sensor; an orientation sensor, such as a gyroscope or accelerometer; a pressure sensor; a chemical sensor, such as a pH sensor or a sensor for sensing a particular solid, liquid and / or gaseous chemical substance; and so on. The parameter can also represent a logical property, such as a settable gate, a button, a logical state delivered by an auxiliary device, and so on, which can be read by the edge computing device EDC.

[0046] In this context, it is important that the sensor S is arranged to sense a particular condition at the “edge” location of the edge computing device EDC. That the computing device is an “edge” device means that it is physically located at a location relevant for the sensed condition. The system 100 typically comprises a plurality of such edge computing devices EDC, each edge computing device EDC being located at a respective such physical location, the physical locations of different edge computing devices EDC typically being different. This means that the system 100 covers a plurality of such physical locations at which such measurements can be performed by the edge computing devices ECD. In this way, data sensed from a plurality of different physical locations can be concatenated by one or several central servers CS in contact with the edge computing devices in the manner described herein to form an overall view of a situation of some type involving the plurality of physical locations.

[0047] Each central server CS can or can not comprise sensors S of the type described herein.

[0048] The sensors S can comprise analog-digital converters to convert sensed analog values, such as temperature, into digital representations that can be fed to the CPU.

[0049] Of course, each edge computing device ECD can comprise more than one sensor S of the same and / or different types. All such sensors are connected to the memory M, such as via a suitable digital communication bus, so that computer software functions executing on the CPU can access measurement values received from the considered sensor S.

[0050] Similarly, each edge computing device ECD can also comprise one or several actuators A, such as optical, mobile, electric or magnetic actuators, as the case can be. All such actuators A are connected to the memory M, such as via the digital communication bus, so that computer software functions executing on the CPU can impose actuations at the considered actuator A.

[0051] The memory M can be a RAM memory, and preferably a digital memory that is interconnected with both the sensors S and the CPU.

[0052] The CPU can be any suitable CPU, such as a single- or multi-core CPU.

[0053] The edge computing device EDC can be a physically independent programmable device. It can be a general-purpose programmable device, or a programmable device whose hardware is limited to a specific use. In that context, it is important that it can be programmed using machine code that can be fed into the memory M from an external source and executed by the CPU. By way of example only, the edge computing device EDC can be a programmable sensor or a PC laptop.

[0054] The edge computing device EDC can comprise an operating system that is arranged to be executed on the CPU and to provide higher-layer services to computer software executing on the CPU within an environment provided by the operating system. However, such an operating system is not necessary in all embodiments of the invention.

[0055] The digital communication interface IF can be any suitable digital wired or wireless interface that is arranged to allow the edge computing device ECD to communicate with external devices. For example, the interface can be: an Internet interface, such as a socket; or a serial interface.

[0056] In particular, as Figure 2 illustrated, the interface IF of each edge computing device ECD allows it to digitally communicate on a digital communication network NW, such as the Internet, to which all system 100 devices are connected for communication.

[0057] In particular, one or more central servers CS, NS can be connected to the network NW to communicate with the edge computing devices ECD. Each edge computing device ECD is connected to at least one, such as exactly one, such central server CS. The central servers CS can in turn be connected in one or more hierarchies, such as in a tree structure, where a leaf (or client) central server CS is connected to a parent (or server) central server CS.

[0058] Figure 2 Also shown is a particular type of central server, namely a namespace server NS (see below).

[0059] A server is “central” in the sense that it defines a logically centralized functionality, in the sense that it is accessible in a single well-defined logical location. For example, a central server can be a regular standalone server, in the form of a single piece of hardware on which computer software is executed. However, each central server can also be embodied as a distributed logical server, such as a defined server functionality reachable via an internet “cloud” type functionality. Thus, several such central servers CS can in fact be partially or entirely executed on a common hardware platform, as the case can be. Such design options are chosen from the perspective of, for example, scalability, performance, security, and elasticity of the system 100.

[0060] The inventive system 100 can be made very scalable, and can include at least 1000, such as at least 10,000 or even at least 100,000 connected edge computing devices ECD, connected to the same system 100 in such a way that they can all communicate with each other directly or indirectly over the network NW as described herein.

[0061] Each central server CS can serve at least 10 edge computing devices ECD, such as at least 100 edge computing devices ECD. Each central server CS can also serve at most 10,000 edge computing devices ECD, such as at most 1000 edge computing devices ECD.

[0062] It will become apparent from the description of the invention that each edge computing device ECD can also refer to other edge computing devices ECD on the network NW. Thus, data can flow in a tree-like structure formed by the system 100, including one or more layers of edge computing devices ECD forming leaves and nodes close to the leaves in said tree-like structure, and also including one or more layers of central servers CS away from such leaves.

[0063] It should also be kept in mind that the explained software functions ES described herein can be executed both on the edge computing devices ECD and on the central server CS, whereby both devices having their own sensors S and cascaded data streams and more centrally located devices processing data measured using their own sensors can handle queries of the type described herein.

[0064] According to the present application, therefore, each edge computing device ECD is arranged with a respective explained software function ES, as Figure 1 is shown in a simplified manner in Fig. 1. The explained software functions ES are arranged to be executed on the respective CPU of the edge computing device ECD under consideration, such as locally on the edge computing device ECD, such as fully locally on the edge computing device ECD.

[0065] As used herein, "local execution" means that the software code embodying the software function ES is loaded directly into the CPU of the edge computing device ECD and executed directly thereon, without any logical or computational function occurring on the CPU of any external device. It is noted that this does not exclude communicating data to and / or from the edge computing device ECD under consideration in an informational sense, which data can be used as a basis for executing the software function ES. For example, a numerical work data product of one edge computing device ECD can be consumed by another edge computing device ECD for further computation therein. However, "local execution" of a piece of software excludes distributed execution, for example in the sense that different computations to be performed by the software function ES are performed in different threads on different, disjoint hardware devices. The present inventors foresee that the individual edge computing devices ECD can be arranged to share some software function ES functionality, even in a distributed execution environment involving a subset of such edge computing devices ECD. This can include one edge computing device ECD delegating a particular defined computation, in particular a query relating to the sensors of such invoked edge computing device ECD, to other edge computing devices. In general, the present application provides the greatest advantage in a hardware environment in which computations requiring a high CPU are performed as far out on the leaves (at the individual edge computing devices ECD) as possible, thereby exploiting the CPU resources of all connected devices.

[0066] The software function ES is an interpreted software function. This means that it can accept information in a predetermined format, step through the information in a specific order, and interpret or execute one piece of said information at a time. Such information processed by the software function ES is denoted herein as "computer code" and is received by the edge computing device ECD under consideration via its digital communication interface IF and stored in its memory M. The computer code in turn comprises definitions, statements and / or instructions that the interpreted software function ES parses, processes and executes. In this sense, a conventional Java virtual machine is an interpreted software function, albeit arranged to interpret Java code rather than computer code according to the present application. The distinction to note here is between "interpret" and "execute", where the latter means loading binary machine code instructions to the CPU for direct execution by the CPU, and the former means interpreting software interpreting computer code and in turn instructing the CPU. In other words, an interpreted language is a language that contains at least some aspects that are not represented in the native, directly executable machine language of the CPU used, but need to be decoded in some way by an interpreter for execution by the CPU.

[0067] According to the present application, the received, stored and interpreted computer code is formatted according to a query language having a predetermined syntax. In this context, a "query language" is a language that allows a user to define a query to a specific data set. For example, conventional SQL is a query language, albeit not according to the present application.

[0068] That is, the syntax of said query language is arranged to define queries whose result is a data stream. As used herein, a data "stream" is a set of data pieces having a temporal dimension, preferably a set of data pieces produced continuously, and possibly even in real time. Thus, each such data piece can be associated with or comprise timing information, such as time of measurement, time of sending, time of reception, etc. For example, the edge computing device ECD can comprise a clock that can be arranged to provide a time associated with each sensor S measurement, such as before the considered measurement is processed by said software function ES.

[0069] In some embodiments of the application, each edge computing device ECD is arranged to, when interpreting the computer code using the software function ES, produce a result of at least one query defined by the computer code. As mentioned, the result can be a data stream. The edge computing device ECD is then further arranged to communicate the considered result to a querying device, such as a different edge computing device ECD or a central server CS, via its digital communication interface IF. In general, the querying device can be any device external to the edge computing device ECD that puts a considered query to the edge computing device ECD via its digital communication interface IF and then receives a response to the query. In some cases, depending on the detailed system configuration, the response can also be returned to a different entity than the one that put the query.

[0070] In particular, the syntax can be arranged to allow for general queries, and in particular queries defined in terms of computations to be performed based on measurement values from the considered sensor S of the edge computing device ECD. Thus, the computer code in the query language format interpreted by the software function can include a reference to a specific sensor S of the edge computing device ECD in an appropriate format, whereby the interpretation involves reading a current value of the considered sensor S and using this read current value in one or several computations based on determining the result of the query.

[0071] In some embodiments, the considered edge computing device ECD, on which the software function ES is executed, is arranged to perform the computations as part of said interpretation.

[0072] The system 100 according to the application can be designed such that it is a self-sufficient system, in the sense that it does not rely on other external systems for its operation. Nonetheless, it can be designed to provide a strong extensibility mechanism to enable tight integration with software on many different hardware platforms. One key aspect of it is the interpreting software function ES executed on each edge computing device ECD. That is, the interpreting software function ES can be downloaded onto each individual edge computing device ECD and installed to be executed on the respective CPU of the considered edge computing device ECD. Once downloaded and installed, the software function ES of each such edge computing device ECD can interpret the computer code as long as the computer code adheres to the well-defined syntax.

[0073] In practice, the software function can be ported (translated) to be executable on many different hardware / software environments, such as different processor architectures and / or different operating systems. In this case, it is preferred that the interpreting software function ES is specifically adapted to each type of such hardware / software environment, but provides a corresponding (or even identical) interpreting functionality with respect to the syntax.

[0074] The resulting agnosticism about the environment, requiring only that the software function ES support certain predetermined functionality, enables the software function ES to be simplified for interpretation, so that it can run on edge computing devices ECD with very limited local hardware resources. On the other hand, the number of such small edge computing devices ECD can be very large, each running such a simplified interpreted software function ES.

[0075] At the same time, the system 100 enables large scale scaling by running many instances of the interpreted software function ES in parallel on different devices. In particular, the system 100 can be scaled to run the interpreted software function ES in many replicas on large multi-core, clusters and clouds.

[0076] These simplified and scaled concepts will now be explained and exemplified briefly.

[0077] With respect to the first simplification, the inventors have successfully configured the interpreted software function ES so that it implements the required "kernel" software functionality, which in turn can be simplified to run directly on small devices with limited or no operating system support. By porting the interpreted software function ES to various such limited resource environments, the system 100 of the present invention can be made almost agnostic to the hardware, operating system and communication infrastructure used by the interpreted software function ES running on each respective edge computing device ECD that implements a predefined such minimal kernel software functionality. Thus, each such interpreted software function ES can run completely independently on a respective supporting device or computer, forming an edge computing device ECD according to the present invention.

[0078] For some types of hardware, the inventors have managed to design such kernel software functionality so that it does not require operating system support, but can run on bare metal. In fact, it has been demonstrated that the minimal possible configuration of the kernel system K requires less than 100K of RAM (transient memory) and only 200K of persistent non-transient memory, such as flash memory.

[0079] The kernel software functionality can be included as part of the interpreted software function ES. For example, the kernel software functionality can provide the required interpretation functionality for a well-defined core part of the query language, including syntax parsing, while the rest of the software function ES, including non-required functionality, etc. can add higher level functionality.

[0080] In general, since different ones of the edge computing devices ECD can include different hardware configurations, the interpreted software function ES can be particularly adapted to the respective hardware configuration of each type of the different edge computing devices ECD, while the syntax can be the same for each of the different edge computing devices ECD.

[0081] In some embodiments, as shown in Figure 1 designed to provide close integration of the interpreting software function ES with other (outside the system 100) software running on the same edge computing device ECD, the interpreting software function ES can run as an embedded engine within other embedded software systems ESS.

[0082] With regard to scaling, we turn to Figure 2 which illustrates how a very large number of such simplified edge computing devices ECD can be interconnected to form a single distributed system 100 containing many different edge computing devices ECD and a central server CS.

[0083] To achieve this, each edge computing device ECD can be managed by a specific central server CS which itself can run as a cloud service on the network NW.

[0084] As mentioned above, the interpreting software function ES can be designed to have the necessary kernel functionality, including computer code query syntax interpretation and interface IF communication support. For very limited hardware environments, only this kernel can constitute the entire interpreting software function ES. Then, depending on the hardware limitations of the edge computing device ECD on which the software function ES is to be executed and depending on the general system 100 configuration, various non-essential additional functionalities can be added.

[0085] In some embodiments, each sensor S and / or edge computing device ECD is capable of being referenced according to the above-mentioned syntax using a global namespace or set of properties. For example, each edge computing device ECD can be assigned a unique number or name, or a unique network NW address can be used as a unique identifier for each edge computing device ECD. Each sensor S of an edge computing device ECD can similarly be addressed using the same or different identification criteria. A simple example of such a name criterion is “[ECD_NO].[SENSOR_NO]”. Preferably, according to the name criterion, the same type of sensor can be denoted using the same sub-name.

[0086] In Figure 2In the example shown, the system 100 globally unique identity of each edge computing device ECD is registered with a respective central server CS, which runs on some servers that are also connected to the network NW; is located in a container or PC; or even as a separate process on the same computer as the edge computing device ECD on which the explanation software function ES is executed. In the latter case, the central server CS and the edge computing device ECD are actually running on the same hardware, but are logically and functionally separated. Each central server CS can serve several edge computing devices ECD to implement the described tree structure with respect to the data flow in the system 100. Generally, however, both the edge computing devices ECD and the central servers CS discussed herein can be implemented as physically separate respective hardware entities from each other.

[0087] In Figure 2 In the example shown, the system 100 globally unique identity of each edge computing device ECD is registered with a respective central server CS, which runs on some servers that are also connected to the network NW; is located in a container or PC; or even as a separate process on the same computer as the edge computing device ECD on which the explanation software function ES is executed. In the latter case, the central server CS and the edge computing device ECD are actually running on the same hardware, but are logically and functionally separated. Each central server CS can serve several edge computing devices ECD to implement the described tree structure with respect to the data flow in the system 100. Generally, however, both the edge computing devices ECD and the central servers CS discussed herein can be implemented as physically separate respective hardware entities from each other.

[0088] The system can generally also include a central namespace server NS, which can be arranged with a database DB that in turn includes information defining the name of each of the edge computing devices ECD. The database DB can be included in or connected to the namespace server NS.

[0089] The database DB can include information about the network address location of each of the edge computing devices ECD. The database DB can also include metadata information about the individual edge computing devices ECD, such as about what type of sensors S are available at each such edge computing device ECD, what type and / or version of explanation software function ES is executed on each edge computing device ECD, what numerical attributes are used when each edge computing device ECD delivers measurement values, such as what units are used, etc. This metadata can subsequently be used to determine parameter values used in the query pre-processing described below, which is performed by certain edge computing devices ECD.

[0090] Generally, the namespace server NS itself can be a central server CS of the type described above, which has the additional namespace information processing functionality and is arranged to serve system 100 participants with namespace-related information services and requests.

[0091] All edge computing devices ECD are interconnected via the central servers CS and at least one such namespace server NS, if used, over the network NW.

[0092] As mentioned, different instances of the interpretation software function ES running on different computers can communicate with a central server CS running on the same or some other computer. Each edge computing device ECD can communicate with the central server CS to which it is registered. The considered serving central server CS can keep some metadata about each edge computing device ECD it serves and can forward data and streams to other central servers CS, such as for distribution to edge computing devices ECD served by other such central servers CS.

[0093] Generally, all connected devices and in particular the edge computing devices ECD can run independently from each other. In particular, the edge computing devices ECD can not need to be continuously connected with the central servers CS, as long as the considered edge computing device ECD is registered with the considered central server CS. Only when needed, the actual digital communication of an object stream between the considered edge computing device ECD and the central server CS can be started and finished. When there is no ongoing active communication, the edge client can be able to run autonomously.

[0094] This functionality can be implemented as part of the digital communication interface IF and reduces the network NW traffic to a minimum, allowing for large-scale scalability. Of course, heartbeats and similar keep-alive signals can be communicated between the devices to keep the registered connections alive. However, even this type of periodic communication can not be necessary, as an offline edge computing device ECD will simply not respond to queries made to it.

[0095] The system 100 thus comprises a set of interconnected peers, which in turn comprise a plurality of devices selected from the following list: • the interpretation software function ES running as embedded software on some network NW connected devices; • dedicated edge computing devices ECD running the interpretation software function ES; • central servers CS; and • namespace servers NS.

[0096] In practice, the system 100 can comprise a large number of such interconnected peers, in particular a very large number of edge computing devices ECD. It is thus desirable to be able to scale the number of peers to handle an extremely large number of edge computing devices ECD from tens of thousands to billions. This can be handled by scaling the number of edge computing devices ECD registered in each central server CS to several thousands of edge computing devices ECD registered in each central server CS and by defining several hierarchy levels of hierarchies as described above.

[0097] Such a system 100 of interconnected peers should persist even when parts of the system 100 stop. To this end, the database DB of the name server NS can be an encapsulated database using a JDBC (Java Database Connectivity) encapsulator which is conventional per se, such as Figure 3 the encapsulated relational database.

[0098] In this particular example, the encapsulator can be a plug-in interpreting the software function ES enabling access to any relational database using a standard database interface such as the JDBC interface. The database DB can hold the identifiers of all peers in the system 100, as well as other metadata such as which equipment is accessible by each edge computing device ECD, which sensors S they have access to, etc.

[0099] It should be noted that a namespace server NS of the type of the present application without a database backend can also be implemented, and in this case such a namespace server can also hold its database. However, to scale to millions of interconnected peers in the system 100, it is preferred to use an encapsulated database DB as described.

[0100] It should also be understood that the namespace server NS and / or its database DB can be implemented as a defined server function executing in a distributed hardware environment.

[0101] As mentioned above, the central servers CS and the namespace server NS can be configured to run on many different kinds of hardware configurations, and can also run in different software environments. In a simple case, they can each run on a conventional PC. In a more scalable configuration, each central server SC can run in a separate container such as Docker (see www.docker.com), and the namespace server NS together with the relational database DB can run on a dedicated cluster. With such scaling, if the number of edge computing devices ECD registered with each central server CS is 1000 and there are two levels of central servers CS, then up to about 10 9 peers can be handled. The database DB will not be a bottleneck in such a configuration, as the limited amount of metadata per peer can be stored there.

[0102] Generally, the explanation software function SA provides general data analysis and inference capabilities to the edge computing device ECD it runs on. This functionality can typically be implemented in the same way on different port versions of the explanation software function SA, such that the explanation software function SA with respect to these functionalities is independent of the particular hardware / software environment it executes on. Generally, the functionality of the explanation software function SA described herein can be implemented in a way that makes it independent of the hardware, operating system and communication infrastructure of the device it runs on. In exemplary embodiments, the kernel of the explanation software function ES can be written in the computer language C99.

[0103] Figure 4a The main components of such an explanation software function ES are exemplified.

[0104] The core of the explanation software function ES is the above-mentioned kernel. It provides the general capabilities required for real-time data stream analysis. This includes a computation engine, a data stream processor and an inference engine. It can also include a main memory local database EDB (see Figure 1 ), which can be an object-oriented database and can also be included in the main memory M of the edge computing device ECD under consideration. The use of such a locally provided database, in particular an object-oriented database, in the edge computing device ECD enables the use of a powerful query processor and optimizer in which, for example, analysis models and edge computing device ECD metadata can be stored and managed.

[0105] Furthermore, an object-oriented data model describing the metadata properties of the edge computing device ECD under consideration, such as information about the type or properties of the edge computing device ECD sensors S, the measurement units used by the edge computing device ECD, the edge computing device ECD hardware specifications or properties, etc., enables the requesting of information from the edge computing device ECD about edge computing device ECD properties, names and measurements, etc. (so-called "mediation"). Such requests can be formulated using the query language and the response to such a query language query depends on the specific metadata information stored in the edge computing device ECD being queried or even in other edge computing devices ECD being subqueried in a query cascade of the general type described herein.

[0106] The kernel includes the dataflow interpretation functionality. In exemplary embodiments, the kernel is tightly integrated with an interpreter for executing plans on a digital dataflow called SLOG (streamed logic), and also with an interpreter for an extended subset of CommonLisp called aLisp (built on the regular computer programming language family Lisp). In fact, the inventors have found that building at least the kernel portion of the interpretation software function ES in a computer programming language such as the Lisp language, in a recursive fashion and using a functional notation, provides very efficient processing of the type of continuous queries processed by the inventive system 100 as described herein.

[0107] Figure 4a The upward arrows indicate dataflow. One or several sensors S of the edge computing device ECD under consideration and / or respective interpretation software functions ES of one or several other edge computing devices ECD produce incoming source data streams that are injected Figure 4a into the kernel shown, which in turn transforms these incoming digital data streams into one or several new streams of digital objects for output from the edge computing device ECD under consideration.

[0108] Such source data streams can be implemented as access by the kernel to raw sensor S interfaces on the edge computing device ECD on which the interpretation software function ES runs. Source streams can also be data streams produced by respective interpretation software functions ES running on another connected edge computing device ECD, received via a network NW such as using a TCP communication protocol. Such source streams can be communicated, for example, in response to a continuous query posed by the interpretation software function ES that receives and consumes the source stream under consideration.

[0109] Similarly, the resulting object data streams can be transmitted to other central servers CS and edge computing devices ECD using the communication infrastructure provided by the network NW, such as TCP. In this way, very large distributed systems 100 of peers of the inventive type can be configured, in which such peers produce object data streams for consumption as source data streams by other peers. On edge computing devices ECD, the object stream data elements of computed or received object data streams can be transmitted directly to actuators A installed on the edge computing device ECD under consideration, and such way activate actuation of the actuator A under consideration.

[0110] In general, the systems 100 and methods described herein are specifically designed for simple interactive development and deployment of applications that process and analyze real-time data streams in distributed and mobile environments, enabling online, real-time interactive analysis, processing and aggregation of streams produced by sensors S on edge computing devices ECD.

[0111] The edge computing device can be for example an Android unit, a PC desktop computer, a Raspberry Pi or a MCU (Micro Controller Unit) like MangOH Red or ARM M4. As mentioned above, the interpreting software function ES and in particular the kernel can be designed to have a very small footprint (the inventors have managed to trim a fully functional interpreting software function in a test environment to a total memory M footprint ranging from about 20 kB to about 5 MB, depending on the configuration) and to be intrinsically hardware and operating system independent, as well as completely independent of any third party software.

[0112] In each of the edge computing devices ECD, the combination of the respective main memory M database EDB, the software-implemented computing engine, the software-implemented data flow processor and the software-implemented inference engine allows for using edge analytics directly on the edge computing device ECD. This is in contrast to many conventional approaches where all measurement data is first uploaded from the edge devices to a central server which then centrally performs all data processing. The present approach instead allows for a drastic data reduction by processing the data flow already in the edge computing devices ECD. In this way, only aggregated analysis, such as swarm analysis, of the collection of connected edge computing devices ECD needs to be performed centrally or semi-centrally, such as at different aggregation levels in the tree structure data flow.

[0113] In this way, the interpreting software function ES has a filtering capability, in other words it is arranged to filter out (discard) data from the available source data flow to produce an output object data flow containing less data per time unit than the source data flow.

[0114] In some configurations, the interpreting software function ES can also act as a data flow server role when running on the edge computing device ECD or on the central server CS. In such a data flow server role, the interpreting software function ES is arranged to collect data from one or several connected edge computing devices ECS and to combine and forward the combined / processed data as an object data flow to other peers. For example, whenever an analysis model in some edge computing device ECD detects strong vibrations by performing calculations on the latest readings from its accelerometer sensor, an object data flow containing the spectrum of the vibrations as well as the geographical positioning of the edge computing device ECD under consideration can be sent to a stream server running on the central server CS which in turn is configured to receive similar information from a plurality of different connected edge computing devices ECD. If the stream server receives many such streams simultaneously from edge computing devices ECD which are geographically positioned close to each other, it can be indicative of an earthquake. The stream server can also forward the received and possibly processed data to other connected system 100 peers or external systems, such as for permanent central storage or bulk analysis.

[0115] As mentioned above, the interpretation software function ES is arranged to interpret computer code formatted according to a well-defined query language syntax. Such a query language syntax can be chosen to interactively and at a high and user-oriented level provide analysis of available source data streams.

[0116] In particular, the query language can be a high-level object-oriented query language. This syntax can allow different conditionally logically related execution paths (such as "select-from-where" clauses) to be executed by said interpretation software function ES and interpreted. Queries can be at least partly declarative in that their interpretation and execution only lead to a search of databases within each respective edge computing device ECD and execution of any computations on these databases, without updating these databases within the edge computing devices ECD or changing the state of the devices. However, it is preferred that the queries are at least partly imperative (see below).

[0117] In some embodiments, the query language can be designed to allow queries to have side effects, such as updating databases, signaling actuators to change device states, or sending messages to other edge computing devices ECD when such a query is loaded into the memory M of the edge computing device ECD on which the interpretation software function ES runs and executed by the interpretation software function ES considering the query being interpreted. In other words, when the interpretation software function ES is executed on the edge computing device ECD under consideration and then interprets the loaded computer code, as a result of said interpretation, programming embodied in the computer code is executed, which can include state and / or side effects.

[0118] Another term for the language "declarative" is that it is "non-procedural". Thus, the present query language is preferably not non-procedural, but at least partly procedural. Providing the query language as a declarative / non-procedural query language allows the user to specify the desired result in terms of output data in an intuitive way, rather than precisely specifying what the edge computing device ECD should do in terms of computation to achieve that desired result. However, at the same time defining the query language such that it has certain imperative / procedural elements allows the queries to have side effects and include stateful functionality. Such imperative / non-declarative elements of the query language provide the possibility to extract information from state-changing sensors when processing stream data.

[0119] The following is an example of a declaratively defined object-oriented query that returns a stream of objects from a given sensor reading stream of an accelerometer sensor S: select stream of absolute(shakes) from vector of number shakes, where shakes from accelerometer() The query receives a stream of acceleration readings as a 3D vector shakes from a sensor accessed through the function accelerometer. It returns a stream of single numbers as the absolute value of the shakes object. The function accelerometer() here is stateful, as it returns a new value each time it is called. The explanation software function ES can generally know the fact that a query contains a call to a stateful function, and is arranged to take this into account when parsing and explaining the query. This provides for more efficient processing of queries of the type described. Each time the accelerometer emits a new vector, the query does the computation and emits its absolute value. Functions can also be expressed through queries. For example, the absolute function can be defined as create function absolute(Vector of Number v) ->Number as select sqrt(sum(v.^ 2)) The query select sqrt(sum(v.^ 2)) takes as a parameter a vector of numbers object v and returns its absolute value.

[0120] In some embodiments, the computer code is formatted according to an object-oriented query language, allowing users to specify computations, filters, and / or transformations on data streams at each connected edge computing device ECD. In other words, the current query language can be an object-oriented query language.

[0121] An object-oriented query language is a language that supports queries in which variables are bound to any kind of object (e.g., numbers, vectors, matrices, strings, records, key-value stores, etc.). Objects can even represent entire edge computing devices ECD, so that queries can be performed on possibly large collections of edge computing devices ECD and edge database EDBs inside edge computing devices ECD. In the above code examples, the variables shakes and v are bound to a stream and a vector, respectively. This can be in contrast to relational query languages such as SQL, in which variables in a query (the SELECT statement of SQL) must be bound to rows in a table only. Such an object-oriented query language can allow filtering and transforming any kind of data object.

[0122] The query language can also contain procedural (stateful) functions, where the state of the database EDB or of the edge computing device ECD itself is updated by calling the function. The query processor interpreting the software function ES must then take into account that the order in which stateful functions are called within a query is important, as it will change the result. For example, a database EDB access after a state change will yield a different result than before.

[0123] Note that there are procedural statements in e.g. SQL, allowing manipulation of states and variables in that sense. However, in SQL queries (i.e. select-from-where statements), this is not allowed. Thus, one important difference between the present query language and e.g. SQL is that the present query language allows the use of variables and / or stateful functions defined with the query language and the syntax in queries .

[0124] The result of an object-oriented query can also be a stream of objects. For example, such a computation and filtering of real-time streaming data can be defined as mathematical formulas and expressions using such an object-oriented query language, denoted herein as a "stream model". Such a stream model is a collection of definitions of mathematical functions, filters and other expressions defined on a stream of data such as measurement results. Using an object-oriented query language, the model can be specified at a very high level, without the user needing deep programming knowledge. Instead of writing a detailed program expressing how to perform the model, it is possible to simply specify in the stream model what to do in terms of the final result, and to what extent this final result depends on any intermediate computation results. The user does not need to worry about details of how to efficiently implement an algorithm that integrates a large number of edge computing devices ECD and central servers CS to achieve a common goal in terms of data collection and processing.

[0125] In some embodiments, the object stream in a function that returns a stream is stateful, e.g. by originating from a sensor S on an edge computing device ECD or the environment, such as the accelerometer above. Thus, the query processor interpreting the software function ES can be arranged to take into account the adverse effects of such stateful stream functions when optimizing and executing the query. Furthermore, the order of the objects of the object data stream produced by such a query can also be important, and thus the function used with such a query or by such a query becomes stateful.

[0126] In some embodiments, the computer code can be provided to the edge computing devices ECD via the interface IF as plain text (as opposed to compiled / object / machine code). However, in some embodiments, the computer code can be pre-compiled and provided to the edge computing devices ECD in non-plain text, compiled into the binary instruction format of the edge computing devices ECD (the compilation can then be performed at the central server CS or elsewhere where more CPU / memory resources are available than on the edge computing device ECD under consideration). In the latter case, the interpretation software function ES can be provided with a simpler version configured to read and execute the pre-compiled computer code. This will result in a simpler interpretation software function ES. However, in some embodiments, at least one (such as at least several), substantially all or possibly even all edge computing devices ECD still feature a respective interpretation software function ES arranged to interpret plain text computer code of said syntax. It can be specified in the metadata in the database DB for the edge computing devices ECD or edge computing device ECD types under consideration whether plain text computer code is accepted by each particular edge computing device ECD or not, and the central server CS can be arranged to check this metadata setting and selectively compile or not compile the computer code distributed to each edge computing device ECD based on such metadata settings.

[0127] As mentioned above, the stream of objects can be a stream of data objects, such as a stream of data objects where each data object represents the value of a respective tensor, which in turn can represent the current physical state of a particular local environment sensed using one or several sensors S, for example.

[0128] However, the data objects can be any type of data object, ranging from simple alphanumeric information such as measurement values (INT, LONG, CHAR, etc.) to more complex data structures according to a predetermined syntax (ARRAY, LIST, SET, BAG, RECORD, etc.). Preferably, such data structures define part of the syntax of the query language. In an embedded software system ESS, for example, the data objects can also be references to complex data objects or pointers, such as references to data objects or callback functions.

[0129] In some embodiments, each of the objects is handled by a callback function, such as a callback function of the embedded software system ESS and / or as part of the interface IF, and executed in the defined central server CS, such as in a client application in the central server CS or on an edge computing device ECD. The objects under consideration can include pointers, addresses or other identifications of the callback functions.

[0130] In some embodiments, the object data stream is an endless stream of objects, which is continuously or intermittently computed by the interpretation software function ES of the edge computing device ECD over time and delivered to the query recipient via the interface IF. The object stream can be communicated via said digital communication interface IF, e.g. using a callback function, upon becoming available after said computation, or in batches, as appropriate. As an endless stream of objects, said computation and delivery (e.g. as invocation of a callback function) can go on until something stops it, such as a request to stop the delivery of query results or the considered edge computing device ECD going offline or breaking down. Thus, as used herein, the term "endless stream" is intended to mean that the data object stream has no defined end point in time of the query, but is arranged to produce results, e.g. through a callback function, which continue to be generated (and, where applicable, one or more corresponding callback functions are invoked) until some situation arises that causes the generation to stop. In other words, this situation can be at least partially unpredictable when initiating the endless stream, requiring some kind of completion mechanism to be activated to stop the endless stream.

[0131] In some embodiments, the syntax allows for different conditional logic dependent execution paths to be interpreted and executed by the interpretation software function ES. For example, a query defined according to the computer code can include IF statements, WHILE loops and similar items.

[0132] Thus, a query defined using the query language can be defined to continuously cause computation and / or filtering of measurements in a source data stream available at the edge computing device ECD receiving the considered query, and to deliver an endless data stream as a result. In this document, such a query is denoted as a "continuous query". In some embodiments, the inventive system 100 using a query language allowing for such continuous queries allows a user to interactively specify a continuous query to continuously analyze measurements streaming through the edge computing device ECD and the central server CS in real time. As mentioned, the result of a continuous query is a real-time (endless) object stream of processed / filtered measurements. Thereby, the result can be distributed to a consumer, such as for display to a user, through a special system callback function.

[0133] In contrast to non-continuous queries, a continuous query will have a data stream delivered as a response that not only depends on the state of the queried database at the time the query is posed, but can also change over time as the internal state of the queried database changes. This is for example the case for a continuous query posed to an edge computing device ECD having an internal database EDB, internal state changes of which can influence the value of the data stream produced in response to said continuous query or upon continuous access to the latest readings produced by a sensor.

[0134] As an example illustrating this aspect, a continuous query can be defined to return the stream of positioning vectors of a particular edge computing device EDC, as measured every second at all times when the considered device EDC is close enough to a given geolocation. In this example, the computation involving a comparison between the measured geolocation and a predetermined geolocation is performed locally on the edge computing device EDC, which then sends the processed data as a continuous data stream to the querying peer.

[0135] Both the stream model and the user data can be stored in each individual edge computing device ECD, in its object-oriented in-memory database EDB, and similarly on each central server CS (in general, any central server CS can run the interpretation software function ES and can also include such object-oriented database EDB used by the interpretation software function ES running on the central server CS). Since the data stream processing at each edge computing device ECD typically involves a matching of fast flowing stream objects in real time with data in the local database EDB, the fact that the database EDB is an object-oriented database makes it possible to design the edge computing device ECD to be computationally fast with respect to its CPU capabilities, due to the efficient data representation and processing. Another perspective is that the object-oriented aspect of the database EDB makes it particularly suitable for efficiently processing the objects constituting the data stream, the main task of the interpretation software function ES being to process the data stream. For example, to determine that a measured vibration spectrum can later damage the sensing edge computing device ECD due to material fatigue, the frequencies measured by a vibration sensor S on the considered edge computing device ECD can be matched with a local object-oriented database EDB of the resonant frequencies of the edge computing device EDB itself at the edge computing device ECD.

[0136] An important aspect of the interpretation software function ES is that it can be designed to allow the combination of object streams from several different edge computing devices ECD. In other words, the interpretation software function ES can support the interpretation of "fused queries", which can be defined using said query language and are defined to reference several different available source streams. The interpretation software function ES is then arranged to computationally combine said available object streams to produce a particular output object stream when interpreting such fused queries. An example of such a fused query is a continuous query designed so that when interpreted on a particular edge computing device ECD, it causes the particular edge computing device ECD to observe when several other edge computing devices ECD in a particular geographical area simultaneously detect a strong vibration in a particular geographical area. Then, when the fused query produces a predetermined result, an alert is issued to the user, possibly together with a real-time visualization of the maximum or average amplitude of the observed vibration. The user can then interactively send new queries to the affected edge computing devices ECD on the fly to find out the details of the cause.

[0137] The query language and in particular its syntax can allow a query to reference information received by the first (requesting) edge computing device 110 (see Figure 2 ) from the second (responding) edge computing device 120. Such references make use of the global namespace described above and can in particular use the services of the namespace server NS to find the responding edge computing device 120 on the network NW. This contact can then be mediated by one or several intermediate central servers CS between the requesting edge computing device ECD and the responding edge computing device ECD. To enable this, it is preferred that the query language is an object-oriented query language as described above, according to which variables can be bound to different kinds of edge computing device ECD objects and subqueries can be expressed against edge computing device ECD objects.

[0138] Thus, the first query received by the first edge computing device 110 can include a reference to the second edge computing device 120. When interpreting the first query, as a result of the reference to the second edge computing device 120, the interpreting software function ES running on the first edge computing device 110 will then formulate a second query to the second edge computing device 120, requesting the specific information specified by the first query. The interpreting software function ES running on the second edge computing device 120 will then return an object stream to the first edge computing device 110 when interpreting the second query, which will be used by the interpreting software function ES running on the first edge computing device 110 to compute the result of the first query, in the form of an object stream returned to the entity that formulated the first query to the first edge computing device 110. In other words, the interpreting software function ES executing on the first edge computing device 110 can be arranged to cause the first edge computing device 110 to query the second edge computing device 120 for said information as a result of the query defined by the computer code referencing the second edge computing device 120.

[0139] As an alternative or in addition to the second edge computing device 120, the reference in the query formulated to the first edge computing device 110 can point to a specific sensor S comprised in the second edge computing device 120, such as the sensor S is also identified via said global namespace and is reachable.

[0140] The query formulated to the first edge computing device 110 can be a continuous query, as can be the case for the query formulated to the second edge computing device 120 as a result of the previous query. However, both queries can be continuous or not, independent of each other, depending on the actual information sought and how the queries are defined.

[0141] Further, the system 100 can also comprise a third edge computing device 130, which can be of the same type as the second edge computing device 120 in terms of the type of sensors S available in the device, etc., but does not necessarily have to be so.

[0142] The interpretation software function ES running on the first edge computing device 110 can then be arranged to pose respective queries to both the second edge computing device 120 and the third edge computing device 130 as a result of the namespace reference in the query posed to the first edge computing device 110. The interpretation software function ES running on the third edge computing device 130 can then be arranged to generate the resulting object stream in response to receiving the query from the first edge computing device 110 and communicate the object stream to the first edge computing device 110 via the digital interface IF of the first edge computing device 110.

[0143] The interpretation software function ES running on the first edge computing device 110 can then be arranged to use both the object stream received from the second edge computing device 120 and the object stream received from the third edge computing device 130 to perform its computation defined in the query posed to the first edge computing device 110.

[0144] Generally, the respective result of the query by the first edge computing device 110 can comprise the respective endless object stream received by the first edge computing device 110 from the second edge computing device 120 or the third edge computing device 130, which is continuously or intermittently computed by the second edge computing device 120 or the third edge computing device 130 over time and communicated to the first edge computing device 110 via the digital communication interface IF of the first edge computing device 110.

[0145] The interpretation software function ES executing on the first edge computing device 110 is in turn arranged to cause the first edge computing device 110 to pose the query under consideration as a result of the query received by the first edge computing device 110.

[0146] It is noted that the first query can include the second and third queries as part of its computer code definition, or such that the interpreting software function ES executing on the first edge computing device 110 can formulate the second and third queries for communication to the computer code of the second and third edge computing devices 120, 130. The respective interpreting software functions ES executing on the second and third edge computing devices 120, 130 will then respectively interpret the second and third computer code defined queries, and as a result, deliver respective data streams to the first edge computing device 110. Depending on the definition of the first query, the second and / or third queries can in turn be defined in a corresponding manner in a manner referencing fourth and subsequent edge computing devices ECS and / or sensors. Since the query language can support complex logic and / or contain stateful functions as described above, such subsequent queries can be defined dynamically on each interpreting edge computing device ECD, e.g. based on parameters or other updated parameter data describing the local network NW adjacent to the edge computing device ECD under consideration. In this way, a single query posed to the first edge computing device 110 can give rise to an automatically evolving cascade of queries, potentially involving a large number of other edge computing devices ECD to collect, process and communicate data streams ultimately reaching the first edge computing device 110 for processing. This also provides a very powerful way for a user to automatically deploy distributed logic to a complex system of edge computing devices ECD by essentially defining the desired result in the first query with the necessary specificity. For example, the first query can define any other edge computing devices ECD to be involved based on parameter data defined in the first query, such as a particular geographic area of interest and / or a particular type of sensor S to be used. The interpretation of the query can then perform the actual selection of the auxiliary edge computing devices ECD based on such parameter values and current conditions.

[0147] These mechanisms also enable the local computing power of each edge computing device ECD to be utilized to the maximum extent in true distributed computing, while still providing a robust, flexible and user-friendly system 100 that can be customized and updated on the fly and in real time. For example, in the case where a user wishes to see what impact an updated query has, the updated query can simply be pushed to the first edge computing device 110, which will immediately begin interpreting the updated query, including the updated query for the second and third edge computing devices 120, 130, etc., as appropriate, ultimately resulting in an updated object stream returned to the query user. This updated object stream will then be available more or less immediately, or at least sufficiently quickly, to allow the user to perform such a deployment as part of an iterative development function, where the updated object stream constitutes feedback to the design process, which in turn includes a first query definition revised over several iterations.

[0148] With similar goals, each edge computing device ECD can be arranged to filter out (discard) at least some, preferably substantially all or even all such measurement data, instead of storing such measurement data in its memory M, after having communicated by way of the digital communication interface IF, based on the interpreted query, a piece of information computed based on measurement data measured by the sensor S of the edge computing device ECD under consideration. In other words, each edge computing device ECD can perform a measurement, perform a query-defined computation based on the measurement data, and communicate the measurement data and / or the result of said computation to the requester, and thereafter purge the measurement data from the memory M. In this way, an efficient data flow can be achieved throughout the system 100, without blocking the individual memories M of the individual edge computing devices ECD.

[0149] As mentioned, a query of the type described herein can refer to a specific edge computing device ECD and / or a specific sensor S of such edge computing device ECD. However, the interpretation software function ES of a specific edge computing device ECD can also refer to a specific stream of objects produced within another edge computing device ECD, such as in the form of a result from an internal computation, or more generally, to a stream of pre-processed or raw measurement data from a specific sensor S comprised in the other edge computing device ECD.

[0150] In particular, the interpretation software function ES of the first edge computing device 110 can be arranged to accept, in the context of the alpha edge computing device 140 not having posed the query under consideration to the first edge computing device 110, a subscription request from the alpha edge computing device 140 for a stream of objects produced by a single query handled by the interpretation software function ES of the first edge computing device 110. For example, the first edge computing device 110 can compute an endless stream of analyzed vibration measurements from various other edge computing devices ECD as a result of a specific query defined within the first edge computing device 110 or posed to the first edge computing device 110 from some other peer entity. The alpha edge computing device 140 can then issue a subscription to the resulting endless stream by requesting such a subscription via the interface IF of the first edge computing device 110. Such a subscription can be continuous or time-limited, and of course can be cancelled at any time by the alpha edge computing device 140.

[0151] As mentioned above, each edge computing device ECD has a relationship with a specific central server CS and both are in communication. It is generally preferred that this relationship is a client-server type relationship, where the edge computing device ECD assumes the client role and the central server CS assumes the server role. This is advantageous from a security perspective and also enables handling of edge computing devices with limited capabilities or resources.

[0152] Thus, each of the edge computing devices ECD can have a client role in relation to a specific respective one of the central servers CS. In this context, that an edge computing device ECD has a client role means that the central server CS cannot connect to such an edge computing device ECD before a communication connection has been established between the edge computing device ECD and the central server CS. This means that the considered central server CS is not allowed to contact the edge computing device ECD. In other words, the central server CS has no functionality to establish a communication connection with the edge computing device ECD at the initiative of the central server CS or is not granted the necessary access credentials, at least to establish a communication connection that can be used to send or receive computer code of the type described herein. On the other hand, the edge computing device ECD can establish a communication contact with the serving central server CS, such as using credentials (login credentials, PKI key credentials or the like). Thus, before a digital communication contact is established between the edge computing device ECD and the central server CS, the communication with the central server CS is always initiated by the edge computing device ECD and not in the opposite way.

[0153] After such a digital communication is established between the edge computing device ECD and its serving central server CS to implement the described client / server relationship, both the edge computing device ECD and the central server CS can communicate with their counterpart in the client / server relationship using a digital communication protocol that can be conventional per se.

[0154] As mentioned above, in some embodiments all communication between the individual edge computing devices ECD, such as communication with other edge computing devices ECD and the interactive GUI described below, takes place via at least one central server CS, whereby a direct contact between the individual edge computing devices ECD is not allowed. In some cases, the at least one central server CS serving an edge computing device ECD needs to communicate with one or more intermediate central servers CS, such as higher level central servers CS in the described tree structure, in order to reach a central server CS serving another edge computing device ECD.

[0155] Using such a network topology, a secure system is implemented, where also no server functionality needs to be provided to the edge computing devices ECD, thereby saving valuable storage space.

[0156] As mentioned above, in some embodiments the interpreting software function ES running on the first edge computing device 110 is arranged to pose a query to the second edge computing device 120, whereby the interpreting software function ES running on the second edge computing device 120 is arranged to generate a stream of data objects in response thereto and to stream this to the first edge computing device 110 via the digital communication interface IF of the first edge computing device 110. The interpreting software function ES of the first edge computing device 110 is then arranged to use said received stream of data to perform a computation to compute a particular result.

[0157] In this case, the interpreting software function ES of the first edge computing device 110 can be arranged to perform a pre-processing of the stream of data objects received from the second edge computing device 120, which pre-processing then results in a pre-processed stream of data objects which then forms the stream that is finally used in said computation performed by the first edge computing device 110. In particular, this pre-processing operation can be arranged to transform the received stream of data objects such that the data contained therein follows a predefined global data ontology.

[0158] Generally, such pre-processing can include at least one of: mapping of names standards (which are local to the edge computing device ECD) to global name standards (such as the system 100 global name standards); unit of measurement conversion; defined data format conversion; and application of results of calibration of measurement data to measurement values.

[0159] One simple example is the case where the second edge computing device 120 internally uses a different unit of measurement than the correct one according to said global data ontology. However, the pre-processing can also be more elaborate, such as to statistically process the measurement data received in the object stream from the second edge computing device 120 such that it rejects statistical outliers, etc. In other examples, a binary data representation of the received data can be transformed to fit the global data ontology. For example, signed four byte integer values can be transformed to unsigned four byte integer values.

[0160] As used herein, the term "data ontology" refers to a system of definitions and / or rules about measurement data, specifying how to represent measurement data according to measurement units, statistical and calibration considerations, binary representation, etc.

[0161] For example, a fusion query (as described above) requires that the integrated data streams are comparable, even if the involved object streams can represent the same or similar data in different ways. For example, the second edge computing device 120 can represent temperature in Fahrenheit, while the third edge computing device 130 uses Celsius. In order to be able to combine such heterogeneous data streams from different edge computing devices ECD, the explanation software function ES and in particular the explanation software function ES executing on the first edge computing device 110 can be arranged to allow defining a mediation model as a query and function, harmonizing such heterogeneous object streams arriving by transforming them into a common model (global data ontology). Such mediation model can be defined locally in any edge computing device ECD forming a stream server integrating data streams from different other edge computing devices ECD. In addition to the example provided above, such mediation can also include mapping local names of sensors S to well-known nomenclature and calibration of local measurements.

[0162] Thus, in the above described case, where the first edge computing device 110 also poses a query to the third edge computing device 130, the explanation software function ES of the first edge computing device 110 can be arranged to now perform another pre-processing on the data object stream received from the third edge computing device 130. Similar to the pre-processing of the data received from the second edge computing device 120, this other pre-processing can yield data used in the computation performed by the first edge computing device 110, but not the pre-processed stream of data actually received from the third edge computing device 130. In a manner corresponding to the previously described pre-processing, this pre-processing can also be arranged to transform the data stream received from the third edge computing device 130, so that the data follows the global data ontology.

[0163] Each of these pre-processing activities can use defined parameter values for the considered pre-processing. Such parameter values can be different for different pre-processing operations and in particular between data received from different edge computing devices ECD. They can be of the general type described above, including the used unit of measurement, etc. Using such parameters, which can be defined globally or locally for individual edge computing devices ECD or for defined types of such edge computing devices ECD and which can be provided by one or several central servers CS and / or stored in the individual edge computing devices ECD, a common data ontology can be automatically imparted throughout the system 100, even if the system 100 contains many different types of different edge computing devices ECD, the user not having to worry about these aspects when defining his queries.

[0164] In some embodiments, the pre-processing is performed based on metadata about the second edge computing device 120; or about a specific defined type of edge computing device ECD to which the second edge computing device 120 belongs, the pre-processed data stream considered being received from this specific defined type of edge computing device ECD. This metadata can then be defined via the digital communication interface IF of the first edge computing device 110. In other words, the information required to perform the considered pre-processing, e.g. the pre-processed parameters, is conveyed through the digital communication interface IF of the first edge computing device 110. For example, the first edge computing device 110 can query such parameters to its central server CS based on a global namespace identification of the second edge computing device 120, and then use the received such parameters in the pre-processing of the received data stream.

[0165] In some embodiments, the digital communication interface IF of the first edge computing device 110 can comprise at least one wrapper mechanism arranged to transform the received data stream from an external data format into a data format internal to the query language. In other words, the second edge computing device 120 and / or the third edge computing device 130 deliver the data stream using a data format that is not according to the global data ontology and / or not internal to the query language, such as a defined data structure or a binary representation. The wrapper mechanism of the first edge computing device 110 can then convert the received data and encapsulate it into a data format directly acceptable to the interpretation software function ES running on the first edge computing device 110.

[0166] The data format being "internal" to the query language means that it is according to data provided as part of the definition of the query language, and directly used by the interpretation software function ES without further conversion.

[0167] It will be appreciated that corresponding mechanisms can apply when the first edge computing device 110 receives data from a source external to the system 100, or when the first edge computing device 110 receives data from a source internal to the system 100 but not constituting an edge computing device ECD itself. It can be appreciated that the query language can support query definitions according to data collected from such "external" sources. A corresponding wrapper can then be defined with respect to such data sources, arranged to transform the received data into a corresponding query language internal data representation. This principle can apply specifically to such received data streams.

[0168] Thus, the encapsulator functionality of the above type can be in the form of an API that enables mapping of the incoming data stream objects as they arrive, in order to inject them into the interpreted software function ES kernel, so that the accessed data streams can be used in continuous queries defined using the query language. The encapsulator itself can be defined as a query language function that returns a stream of objects from the encapsulated data source. The system 100 can include a library of predefined encapsulators to interoperate with common data infrastructures, such as relational databases through JDBC and data processing systems through Kafka, Azure IoT Hub or MQTT. Using infrastructures with encapsulators, such new encapsulators can be easily developed and deployed on the fly as new needs arise.

[0169] To allow collaboration between the interpreted software function ES and peripheral computer code, such as computer code that is not formed by the query language but is executed on the same edge computing device ECD as the interpreted software function ES, the interpreted software function ES can include an external application programming interface (API) that is arranged to allow expressions of the present query language to call such external computer code and / or that is arranged to allow external computer code to call expressions in the query language. In this context, "external computer code" is intended to mean computer code that is not part of the interpreted software function ES and that is not according to the query language, such as other software running on the same edge computing device hardware or other hardware in digital communication with the edge computing device ECD under consideration.

[0170] For example, the system 100 can include a library of predefined query language functions for performing various specific tasks, such as mathematical / statistical computations, object stream filtering and transformations, signal processing, model and data management, etc. This library can be stored in one or more central servers CS, or bound together with the interpreted software function ES in each or at least several edge computing devices ECD. The function library can be modular in that it can be extended to meet new user needs, and it is arranged so that users can define and deploy new user functions on the fly by simply pushing updated library information to the relevant devices ECD.

[0171] However, existing algorithms and code libraries can be implemented in other programming languages, or for other reasons are not directly compatible with the interpreted software function ES. Such existing code can then be used as "external" query language functions (see Figure 4aInsert system 100. Then, such external functions can be used transparently in queries and expressions defined using this query language. For example, in cases where the interpreted software function ES is implemented in Lisp, and where it is desirable to use code in the C programming language as part of the computation of query results in an edge computing device ECS, such C-language-specific APIs can be used, allowing the interpreted software function ES to directly call the C-language-implemented code, resulting in the execution of the corresponding C code as a result of the interpretation and processing of the query executed by the interpreted software function ES.

[0172] like Figure 4a As shown, using the concepts of external functions and stream wrappers, it can be explained that software functions ES can be arranged to be highly scalable, in the sense that many different kinds of plugins can be added without changing other parts of the system 100.

[0173] "Analysis Model" Figure 4a An analysis model is a model that specifies the transformation, filtering, computation, and inference of a source data stream to produce an object data stream as a result. Such analysis models can be specified by the user without requiring deep programming skills or detailed knowledge of the internal workings of the interpreter software function ES kernel. Furthermore, such analysis models can be defined using the same object-oriented query language used to define queries of this invention type (using the syntax described above). Therefore, an analysis model can be defined as a set of query language functions and / or sequential query definitions pushed to the edge computing device ECD via the interface IF and stored in the local database EDB. The analysis model can then be used in queries proposed to the edge computing device ECD via the API of the interpreted software function ES running on the ECD under consideration.

[0174] Still referencing Figure 4a "External functions" are functions implemented in any conventional programming language (such as C, Lisp, or Java) to implement external algorithms, such as numerical, statistical, and / or inference algorithms. Such external functions can be used as plug-ins, referenced in queries of the type defined in this invention using the query language. Using the external function API of the interpreted software functions ES, such functions can be directly referenced and accessed from the interpreted software functions ES via query language references without any other porting or modification. Such external functions can be pre-compiled and loaded into local memory M during installation or later (such as when needed). Specifically, such external function algorithms can be used in analysis models of the type described above to filter and transform incoming data streams into exported object streams.

[0175] In addition, external functions can be permitted to access functionality provided by the interpreted software function ES, thereby allowing very powerful capabilities to be added to the interpreted software function ES via such external functions, such as access to file systems, operating system calls, inference engines, or complex database managers forming part of the kernel functionality. The external function API can also include mappings of external language data structures to query language data structures, so that data can be accessed directly without the need for data conversion. For example, based on a single mapping definition (included in the API) regarding simple and complex data types, C language data structures can be directly mapped to corresponding query language data structures.

[0176] In order to access incoming data streams in a continuous query, a data stream wrapper can be implemented as a function defined in part (as an external function) or entirely using the query language. For example, the query language can be arranged with standard sensor interfaces for commonly used sensors S, provided as part of the interpreted software function ES. For each incoming data stream, only one such data stream wrapper needs to be implemented; once implemented for a particular stream type, all such streams can be queried using a continuous query of the type of the present invention. Such a data stream wrapper can then be defined as a continuous query that returns an object data stream. Such a query can be defined in the form of a function, thereby accepting arguments, for example to represent the identity of the stream it wraps.

[0177] The data stream wrapper needs to physically access the external data stream and convert each of the data stream elements it arrives at into a suitable data format for efficient and flexible processing by the interpreted software function ES. Different streams typically use different data structures to represent their elements, so a data stream wrapper of the type of the present invention will typically convert such external data representations into a format already supported by the interpreted software function ES. However, in some cases, binary data representations can be lifted directly into the interpreted software function ES without any data transformation. This can be achieved by mapping such binary data representations to an internal binary data format that is particularly suited to correspond to a known binary data format output by the sensor S under consideration.

[0178] The interpreted software function ES can be arranged with a built-in library of built-in data stream wrappers for common infrastructures, such as for Kafka, Azure IoTHub, MQTT, CVS, and JSON streams. In addition to this, additional wrappers can be easily downloaded onto each edge computing device ECD as needed, and thus form part of the interpreted software function ES that takes immediate effect.

[0179] In general, the data stream originating from the sensor S will be endless (as mentioned above). However, in some cases, the data stream can also be finite. For example, there can be a special JDBC data stream wrapper available that handles a finite result from a SQL query that is passed via JDBC to the relational database as a wrapper function parameter. This wrapper can then be used to keep the peer metadata in the domain name server NS.

[0180] As mentioned above and as Figure 4a shown, the interpretation software function ES can also be embedded in the software environment present on the hardware on which the interpretation software function ES executes. In this way, an embedded application or system can access the object data stream produced by the continuous query API provided by the interpretation software function ES. The embedded application or system can run in the same process and address space as the interpretation software function ES, such as when running an embedded interpretation software function ES on an edge computing device ECD with limited hardware resources. In another example, the interpretation software function ES running on a particular edge computing device ECD can act as a client for a central server CS running on some other computer or cluster that communicates via TCP or some other communication infrastructure. For example, there can be an embedded such interface defined for public infrastructures such as Kafka, MQTT, or Azure EventHub.

[0181] Figure 4b The hierarchy of components in an example of an edge computing device ECD of the type of the present invention is illustrated. The deeper layers are independent of the upper layers. The "local database" is the local master database EDB present in each edge computing device ECD as described above. In this database EDB, the stream model and temporary data are stored. The local database EDB is managed by a subsystem denoted as "saStorage" via the interface "sa_storage.h".

[0182] On top of "saStorage", there are two independent interpreters ("SLOG" and "aLisp"). The module "Lisp-SLOG API" is the connecting link between these interpreters so that "aLisp" can be called from "SLOG" and vice versa.

[0183] "aLisp" is an interpreter of a subset of "CommonLisp" (a regular dialect of the Lisp programming language) extended with functions required for implementing the upper application layer in the edge computing device ECD, i.e. "sa_kernel". "CommonLisp" is a regular functional programming language where all functions return (finite) objects of different types as a result. The objects returned from functions are stored in the main memory EDB, which becomes a problem in case the result is too large. Note that the Lisp code is data stored in the main database EDB.

[0184] On the other hand, "SLOG" is a dataflow interpreter of execution plans expressed in a language similar to programming languages such as Prolog. "SLOG" operators do not return a single object, but the result is a handle to a stream of objects. The calling application sends a callback to "SLOG", which applies the callback to the elements of the resulting stream of objects. Thus, "SLOG" operators are so-called generators, which is different from functions in "aLisp". An external object-oriented query language ("OSQL") function can be implemented as an external "SLOG" operator. The external "SLOG" operator, i.e. the external query language function, returns the resulting stream of objects by iteratively calling a callback function in the interpretation software IS as a parameter.

[0185] An external program, such as an external program in the embedded software system ESS, can call the edge computing device ECD kernel via the API "CQ API". The calling application can be executed as a separate process on the same computer, or from a different peer or even an external entity via some suitable communication system such as TCP. The calling application can also be in the form of one or more application threads. Thereby, the kernel guarantees thread safety. The elements of the stream of objects can be passed to the embedded software system ESS by the interpretation software IS calling a callback function in the ESS.

[0186] Referring again to Figure 2 In some embodiments of the invention, the system 100 further comprises an interactive graphical user interface (GUI) allowing a user of the system 100 to visually view computer code of the type of the invention formatted according to the syntax. The viewed computer code is computer code stored in the edge computing device ECD, in several different edge computing devices ECD, which computer code defines several different queries using the query language using the syntax. The several different queries can typically include mutual relationships between requesting edge computing devices 110 and responding edge computing devices 120, 130 defined by the considered query as described above, and also in a cascade / tree configuration of complex query definitions of the type in question.

[0187] However, even the GUI can be arranged to display the computer code as alphanumeric text, but in the presently discussed embodiments the GUI is arranged to visualize the computer code using a visual notation system.

[0188] That is, the query language can be isomorphic with such a visual notation system, meaning that any query language computer code following the syntax will have a visual corresponding representation that can be visualized in the interactive GUI. The visual notation system can be based on graphical primitives that have a well-defined one-to-one mapping to computer code corresponding representations and that are graphically interconnected in a way that represents how entities, data, computations and queries are interconnected as defined by one or more queries as defined by the computer code, such as using lines or arrows.

[0189] The isomorphism can be arranged such that the visual representation is more abstract than the actual computer code, thereby hiding certain details of the computer code, such as specific computations performed on specific data. However, it is preferred that the isomorphism is complete, meaning that the computer code can be fully represented by the visual notation system, and that the computer code and the visual representation can be converted to each other without losing any information.

[0190] Furthermore, the interactive GUI can be arranged to allow the user to interactively change / modify / define one or several of the queries directly using the visual notation system in a graphical manner, such as using a computer screen and a computer mouse; or a touch screen. For example, the user can drag and drop individual edge computing devices ECD to define a requesting edge computing device ECD and a responding edge computing device ECD, or can add queries, query parameters and logic using graphical primitives in the interactive GUI. It is noted here that due to the isomorphism such changes will always perfectly correspond to changes in the graphically represented alphanumeric computer code.

[0191] Then, as a result of such changes, the interactive GUI is arranged to communicate said updated computer code to any relevant edge computing device ECD, thereby reflecting any updates made to the visual representation. This can mean: providing an updated query for one or several edge computing devices ECD; indicating to one or several edge computing devices ECD that a previously loaded continuous query is no longer active; and / or providing an updated query for one or several edge computing devices ECD. This providing is done in the manner generally described herein, using the corresponding central server CS to automatically push the considered update to the considered edge computing device ECD. Once updated, the relevant edge computing device ECD can typically start using (interpreting) the loaded query immediately. Especially in case such visually defined and loaded query is a continuous query of the type described above, this will result in changes of the interactive GUI causing immediate and automatic full deployment of computer logic at possibly a large number of relevant edge computing devices ECD.

[0192] The system 100 can be configured such that the interpreting software function ES continuously provides the interactive GUI (such as via its respective central server CS) with updated states regarding the state and information flow of the interpreting software function ES, such that the interactive GUI is updated in real-time or near real-time about the current state of the query programming and information flow in the system 100.

[0193] In this way, the interactive GUI will be dynamically updated to display the changed information flow based on query initiation, running, stopping, etc. This means that when a user uses the interactive GUI to change the visual representation of the computer code, these changes are immediately translated into corresponding computer code and pushed to the relevant edge computing devices ECD (possibly after automatic compilation of the computer code for very thin edge computing devices ECD). The pushed query information in turn results in various modified information flows, which are immediately reflected in the graphical GUI by feedback information from the considered edge computing devices ECD for the user to view.

[0194] The interactive GUI can be arranged to request the computer code stored in each of the relevant edge computing devices ECD and provide said visual view based on the computer code received from said edge computing devices ECD in response to the request.

[0195] Figure 6 A method for collecting data in the system 100 is exemplified.

[0196] In a first step, the method starts.

[0197] In a subsequent step, at least a first edge computing device 110 and a second edge computing device 120 of a plurality of edge computing devices ECD comprised in the system 100 are provided with respective interpreting software functions ES of the general type discussed herein, arranged to execute on the CPU of the considered edge computing device ECD and to interpret computer code of the type discussed herein, received via the digital communication interface IF of the considered edge computing device ECD and stored in the memory M of the considered edge computing device ECD. Said computer code is according to a query language of the type of the present invention, having a predetermined syntax which in turn is arranged to define a query whose result is a data stream.

[0198] In a subsequent step, the first edge computing device 110 of said edge computing devices ECD provides the second edge computing device 120 with computer code of said type defining at least one query using said syntax, via the digital communication interface of the second edge computing device 120.

[0199] In a subsequent step, said second edge computing device interprets the received computer code, which interpretation comprises the second edge computing device 120 performing calculations based on measurement values from sensors S of the second edge computing device, and the query is defined in dependence of the calculations to be performed.

[0200] In a subsequent step, the second edge computing device produces a result of said at least one query.

[0201] In a subsequent step, the second edge computing device communicates said result to said first edge computing device 110 via said digital communication interface IF of the second edge computing device 120.

[0202] It is to be understood that in this embodiment example as well as in other embodiment examples, the communication between edge computing devices ECD can generally be made via the respective digital communication interface IF of each of the edge computing devices ECD involved in the considered communication and also via any intermediate central server CS involved.

[0203] In a subsequent step, the method ends.

[0204] Figure 7 A method for collecting data in the system 100 is exemplified. Again, the system 100 comprises at least a first edge computing device 110 and a second edge computing device 120.

[0205] In a first step, the method starts.

[0206] In a subsequent step, at least said first edge computing device 110 and second edge computing device 120 are provided with respective interpreting software functions ES of the type of the present invention, arranged to execute on the CPU of the edge computing device ECD under consideration and to interpret computer code of the type of the present invention, received via the digital communication interface IF of the edge computing device ECD under consideration and stored in the memory M of the edge computing device ECD under consideration according to a query language of the type of the present invention having a predetermined syntax arranged to define queries whose result is a data stream.

[0207] In a subsequent step, the first interpreting software function ES of the type executed on the first edge computing device 110 formulates a first query of the type to the second edge computing device 120.

[0208] In a subsequent step, in response to said first query received by the second edge computing device 120, the second interpreting software function ES of the type executed on the second edge computing device 120 generates a second data stream (the term "second data stream" simply indicates a data stream produced by the "second" edge computing device 120). The second edge computing device 120 communicates this second data stream back to the first edge computing device 110 via the digital communication interface IF of the first edge computing device ECD.

[0209] In a subsequent step, the first interpreting software function ES performs a pre-processing of said second data stream (a "second" pre-processing, indicated in this way since it is performed on the "second" data stream), thus producing a pre-processed second data stream used in said first computation. This second pre-processing transforms the second data stream so that it complies with a predefined global data ontology of the type described herein.

[0210] In a subsequent step, the first interpreting software function ES performs a first computation using said pre-processed second data stream to compute a first result.

[0211] In a subsequent step, the method ends.

[0212] Figure 8 A method for collecting data in a system 100 comprising several edge computing devices ECD of the type of the present invention is exemplified.

[0213] In a first step, the method starts.

[0214] In a subsequent step, each of the plurality of edge computing devices ECD is provided with a respective interpretation software function ES of the type described herein, arranged to execute on the CPU of the edge computing device ECD under consideration and to interpret computer code received via the digital communication interface IF of the edge computing device ECD under consideration and stored in the memory M of the edge computing device ECD under consideration according to a query language of the type of the present application having a predetermined syntax arranged to define, from a respective requesting edge computing device ECD, queries transmitted to one or more respective responding edge computing devices ECD according to respective calculations to be performed by the responding edge computing device ECD based on measurement values from respective sensors S of the responding edge computing device ECD, the result of the query being a data stream returned to the requesting edge computing device ECD. The query language is isomorphic to the type of visual notation system and employs the above-described manner.

[0215] In a subsequent step, an interactive graphical user interface (GUI) of the type described above is provided, thereby allowing a user of the system 100 to visually view computer code stored in a number of different edge computing devices ECD of the system 100 and to define a number of queries using the query language, including the interrelation between requesting edge computing devices ECD and responding edge computing devices ECD defined by the query under consideration using the visual notation system, using the syntax.

[0216] In a subsequent step, the user uses the interactive GUI to graphically and interactively change one or more of the queries using the visual notation system.

[0217] In a subsequent step, the interactive GUI therefore automatically communicates updated computer code of the type to any relevant edge computing devices ECD, thereby reflecting the changes to the queries.

[0218] In a subsequent step, the method ends.

[0219] These methods and / or other aspects of the methods described herein can generally be freely combined.

[0220] In the following, the processing of queries in a system 100 of the type described herein will be described in more detail.

[0221] Generally, queries are processed by transforming and converting the query into a so-called execution plan. The execution plan is an intermediate program that, for a given query or function definition, explicitly specifies how to process the query to achieve a response to the query. In particular, the execution plan specifies a specific sequence of steps for accessing data, such as in a database, to process the query.

[0222] Aspects specified by the execution plan can include an optimized order and / or selected strategies for accessing system internal, external algorithms and / or data streams. To tune the performance of a query, the execution plan can be configured to be inspectable by a query tuning expert and thus expressed at a higher human-readable level. However, they are not designed for actually programming the query algorithms (i.e., writing programs); rather, the execution plan can be represented as a data structure in the main memory of an edge computing device ECD. It can also be presented graphically to the user in the GUI described above.

[0223] In the system 100 of the present invention, the execution plan can express a stream computation, in other words, a description of a high-performance computation of a numerical algorithm applied to a possibly endless (and possibly also continuous) stream of data flowing through the system 100. In the example of the presently described system 100, the internal execution plan language in which the execution plan is expressed can be a language called SLOG (Streamed Logic). SLOG is a very simple but powerful procedural algebra for representing executable procedural code on streamed data to implement an optimized OSQL. The internal execution plan language used to define the execution plan in the system 100, such as SLOG, can have one of the following properties, any combination of several of the following properties, or all of the following properties: Streaming: The internal execution plan language can be configured to generate a possibly endless stream of bindings of variables to different kinds of objects, including strings, numbers, vectors, arrays, and even other streams, rather than producing complete data objects as in regular programming languages. This can be achieved by not building complete data structures as results of queries, but rather producing bindings to stream elements and passing them to applications through callback functions.

[0224] Filtering: The internal execution language can be configured to provide powerful logical filtering on data objects. This can be achieved by providing operators based on predicate logic, as in Datalog or SQL.

[0225] Computing: The internal execution language can be configured to enable high-performance numerical computation by being at least partially compilable to assembly instructions supported by the relevant hardware. This can be achieved by providing the possibility to declare variables and functions used in the query language to use basic hardware-oriented data types and instructions, such as functions on numbers, arrays, or strings.

[0226] Simplicity: The internal execution plan language can be defined in terms of a small number of primitives, such as less than 10 operators, which are well suited for efficient filtering and efficient computation on data streams, and where at least some of the operators, specifically the numerical operators, can be easily compiled into corresponding assembly instructions that are supported by hardware. In the specific case of SLOG, it can be described by only five operators that are used to define increasingly complex combination operators that involve both stream logic filtering and numerical computation.

[0227] ABSTRACT: As mentioned, the internal execution plan language can be configured so as not to allow users to write computer programs in the internal execution plan language; instead, the internal execution plan language programs can be configured to be represented as data structures in the internal main memory database in the edge computing device ECD. Such execution plans can be generated by a query optimizer based on a query under consideration. For example, when an OSQL query or function definition is perceived to be slow, a high-level user can inspect the generated SLOG algebraic expression to identify any bad optimization decisions in order to reformulate the query or instruct the query optimizer how to improve the plan.

[0228] Extensible: The internal execution language can be extensible so that new types of filtering and computation can be added to the data stream without changing the system core. To this end, the internal execution plan language can be configured to support external functions of the general type described above. Such external functions can be implemented in some conventional general-purpose programming language, for example to extend SLOG with new operators. The programmer thereby uses the API of the edge computing device ECD under consideration so that the computation can be issued based on the iteration so far of binding variables (tuples of) new variable bindings bound by the external function, thereby generating a stream of variables bound to objects. The API can be configured to include the possibility to influence the query optimizer, for example by providing the cost and size of the results produced by the external function to guide the query optimizer to reorder and transform operators so as to optimize execution speed and data requirements.

[0229] Embeddable: The internal execution plan language can be configured so that functions expressed in the internal execution plan language can be called from a conventional general-purpose programming language used by an embedded software system ESS. The result is then returned as a stream of objects by a callback function in the embedded software system ESS expressed in said general-purpose programming language that accesses the objects bound to the variables generated by the stream of objects. In said API, for each tuple of bound variables in the returned stream of objects, a function in the program is called back from the edge computing device ECD's interpretive software function ES.

[0230] As detailed below, one (e.g., each) individual piece of the execution plan can be compiled all the way to binary machine-specific instructions, while any remaining part of the internal execution plan language program can be interpreted.

[0231] Starting from a general point of view and as described above with respect to Figure 2 , the system 100 can be highly distributed, comprising a federation of several central servers CS managing possibly very large numbers of edge computing devices ECD. By forming a hierarchy of central servers CS with registered edge computing devices ECD, the system 100 can be scaled to handle large numbers of edge computing devices ECD. This is illustrated in the examples provided in Figure 5 .

[0232] Each edge computing device ECD A (and possibly also each central server CS) can be of one of several possible types. A “full engine” device (“query processor”) comprises all software modules needed for query processing; while a “thin engine” device (“query executor”) can only run an execution plan that has been generated (processed) by a full engine device. In this text, the term interpretation software IS is used to denote such software modules that are configured to run query code in the manner described in this text.

[0233] As small edge computing devices ECD can have limited resources, such as at most 1 MB RAM, or at most 512 KB RAM, or at most 256 KB RAM, or at most 128 KB RAM, or even at most 64 KB RAM, for thin engine devices, such as devices without user data stored in a local database and without a query optimizer, for example as Figure 11b , Figure 11c , Figure 11dThe RAM can be volatile (non-persistent) RAM memory, excluding any non-volatile (persistent) memory such as flash memory. Small edge computing devices ECD can also have limited connectivity. Thus, they can not be able to handle queries on their own, but need to be configured as thin engines. Each such thin engine edge computing device ECD can then be arranged to only be able to execute queries that have been optimized and compiled on a full engine device, such as on a different edge computing device ECD or on a central server CS that is a full engine type device. Note that streaming architecture of operators as used in the execution plan in SLOG significantly limits the amount of memory needed compared to materializing large query results; large query results are typically not possible to implement in small devices with limited memory. In some embodiments, the central server CS is always a full engine, while the edge computing devices ECD can be full or thin engines. For thin engine edge computing devices ECD, query processing can take place in their registered central server CS. Full engine devices can be implemented using up to 100 MB RAM, or up to 50 MB RAM, or up to 20 MB RAM, or up to 10 MB RAM, or even less than 5 MB RAM, such as Figure 11a The devices are generally illustrated in the middle, with the corresponding definition of "RAM" as described above.

[0234] Nevertheless, it should be understood that the various central servers CS and edge computing devices ECD can run the interpreted software function ES which can differ or can be the same in details, scope or functionality between any two entities.

[0235] As will be described below, queries formulated in the present query language can be converted into corresponding execution plans. The execution plans can then be compiled into device-independent binary code and / or device-dependent binary code. Depending on the hardware prerequisites on each type of edge computing device ECD, the interpreted software function ES executed on the edge computing device ECD under consideration can include various levels of functionality.

[0236] In the simplest case, for thin engine edge computing devices ECD with very limited hardware specifications, the interpreted software IS can be arranged to interpret and execute pre-compiled device-independent binary code, requiring each such binary instruction to be converted into a corresponding device-specific machine code instruction. There can also be thin engine edge computing devices ECD that can only execute pre-compiled device-specific binary code, but in this case the system 100 will also include edge computing devices ECD arranged to interpret code rather than just execute code.

[0237] For a thin engine or full engine edge computing device ECD with a more powerful hardware specification, the interpretation software IS can interpret not only device-independent binary code of the type described, but also can interpret and execute uncompiled execution plans.

[0238] For a full engine edge computing device ECD with an even more powerful hardware specification, the interpretation software IS can interpret not only device-independent binary code and uncompiled execution plans, but also can interpret and run queries of the type described.

[0239] The system 100 can include one or more of the thin engine and full engine edge computing devices ECD of the type described above.

[0240] Figures 11a to 11d An overview of various alternatives is provided.

[0241] Figure 11aSelected parts of an exemplary full engine edge computing device ECD are exemplified. As mentioned above, the edge computing device ECD comprises an interface IF via which the edge computing device can receive queries, uncompiled execution plans, machine specific assembler code and / or machine independent assembler code from peer edge computing devices ECD and / or a central server CS. After processing a query, such as producing a compiled or uncompiled execution plan from a query, the edge computing device ECD can transmit the result of such processing to one or more peer edge computing devices ECD and / or a central server CS. The edge computing device ECD comprises an interpretive software function ES which in turn comprises the interpretive software IS. The interpretive software IS in turn comprises a module 201 which is arranged to interpret uncompiled query language code of the kind of the present invention and possibly to produce compiled and / or uncompiled execution plan code of the kind of the present invention. Thus, the module 201 can interpret, run and possibly at least partly translate and / or compile incoming queries. The interpretive software IS further comprises a module 202 which is arranged to interpret and run uncompiled execution plan code, such as SLOG code. The interpretive software IS further comprises a module 203 which is arranged to interpret and run platform independent assembler code, such as SLAP code, see below. The interpretive software IS further comprises a module 204 which is arranged to execute platform specific assembler code, such as by invoking a loader. Since code defining a query to be run by the edge computing device ECD can comprise elements from each of the code abstraction layers (query language code, execution plan code, machine independent assembler code, machine specific assembler code), the modules 201, 202, 203, 204 can communicate with each other so that the correct part or parts of a query under consideration are handled by the correct module. In particular, the module 201 can be arranged to push execution plans to the module 202 for processing; while the module 202 can push assembler code to the modules 203 and / or 204 for processing. Any work product, such as an execution plan or a compiled part, can be distributed back to other edge computing devices ECD and / or a central server CS via the interface IF.

[0242] Figure 11b A first exemplary lean engine client edge computing device ECD is exemplified which does not comprise the module 201 but is arranged to use the modules 202, 203, 204 as described above to handle execution plans and machine independent / machine specific assembler code. Any compiled assembler code produced can be distributed back to other edge computing devices ECD and / or a central server CS via the interface IF. Otherwise, Figure 11b The edge computing device ECD of Figure 11a will work in the same way as the edge computing device ECD of

[0243] Figure 11cA second exemplary lean engine client edge computing device ECD is illustrated, which corresponds to Figure 11b the lean engine client edge computing device ECD of Figure 11c but does not include the module 202. Figure 11c The client edge computing device ECD of

[0244] Figure 11d Analogous to Figure 11c but a third exemplary lean engine client edge computing device ECD is illustrated, which also does not include the module 203.

[0245] It can be the case that all queries and models cannot or are not fully compiled into binary instructions. For example, for this reason, in some embodiments, the respective interpretation software IS of all, at least most or at least several of the edge computing devices ECD in the edge computing devices ECD is arranged to interpret at least the execution plans that are not fully compiled, in order to interpret the execution plan fragments that have not yet been converted into binary code. In such cases, the execution plan compiler (query processor) identifies the code fragments in the execution plan that it can compile, and then generates binary code for those compiled execution plan fragments, while leaving the rest to the interpreter. Thus, in such cases, the execution plan can comprise both internal execution plan language code and pointers to binary code fragments.

[0246] Alternatively, in some embodiments, all, at least several or at least one of the interpretation software IS in the edge computing devices ECD can not include a query processor. Instead, a query executor for assembly code, such as SLAP code, again see below, can be provided in order to interpret any compiled machine-independent assembly code that forms part of the query passed to the device in question.

[0247] In both of these alternatives, some (but not all) of the lean engine edge computing devices ECD of the system 100 can also be completely free of interpretation software functions ES, but are arranged to receive only queries in the form of compiled platform-specific binary code that is invoked by the loader.

[0248] The main purpose of the presently described system 100 is to enable full interactivity of the operating user, such as via the GUI. After a query or function definition has been defined, all optimizations and compilations should be performed without delay.

[0249] In order to achieve this, it is important to minimize the compilation time in order to guarantee immediate execution of defined or updated queries without any noticeable delay for the operating user.

[0250] Furthermore, the generated code size should be minimized due to the typically very limited memory on the lean engines. Considering the typically slow processing speed of such lean engines, the generated code should also be as efficient as possible.

[0251] The compilation and optimization of the query should also take into account that both the edge computing devices ECD and the central servers CS in the federation of the system 100 can have different hardware and / or operating system architectures. That is, the system 100 architecture should be able to handle the distribution of code to all different kinds of peers in the federation, so it must be possible to transfer code for different architectures around the considered federation.

[0252] Furthermore, some edge computing devices ECD and / or central servers CS can lack certain functionalities. For example, some devices can not support the generation of binary code (e.g. this is the case for OSX devices). Then, the system 100 can include functionality to compensate for such missing functionalities in different edge computing devices ECD and / or central servers CS.

[0253] Figure 9 Steps of a method for query processing in the system 100 are exemplified, the system 100 being arranged to perform the steps. As mentioned above, the method is also used for distributing and deploying software functionality on the system 100.

[0254] Figure 10 The information flow and processes are exemplified from the perspective of the action entities (software modules of the interpretation software functions ES of the central servers CS) and the data on which the action entities operate.

[0255] It is noted that, Figure 9 All intermediate representations of the information indicated in the steps are inspectable to the tuning expert.

[0256] In a first step, the method starts.

[0257] In a subsequent step, the currently described type of interpretation software function ES can be provided to one or more central servers CS and / or one or more edge computing devices ECD, if this has not already been performed.

[0258] In a subsequent step, the central server CS accepts a query of the type of the present application from a querying party and via said digital communication interface IF. The querying party can be a different central server CS, an edge computing device ECD or any external entity using an API of the central server CS to formulate said query. As mentioned above, the query is defined such that the result of the considered query is a stream of data objects, where at least one stream is an endless stream of objects computed based on data measured by the sensors S of the edge computing devices ECD as described above. The result can then be provided continuously or intermittently over time and communicated via said digital communication interface IF as will be described below.

[0259] In particular, the received query can be defined according to a query language of the type of the present application having a predetermined syntax arranged to define queries whose result is a stream of data and to allow defining said query according to a computation to be performed based on measurement values from said sensors S.

[0260] The query language can be an OSQL (Object-oriented) query language.

[0261] To illustrate the principles of the present application, the following example is provided in the form of an OSQL function whose task is to find a stream of prime numbers containing integers smaller than n: create function primes(Integer n)->Stream of Integer m as select m where notany(select factor from Integer factor where mod(m,factor) = 0 and factor in range(2,sqrt(m))) and m in range(2,n) Note that the select expression in the body does not state in what order the function and filter should be evaluated; it only states the desired properties of the resulting stream of integers. An optimized executable program computing the stream of prime numbers is automatically generated by the query processor.

[0262] Furthermore, OSQL functions can be defined according to variables of arbitrary domains, such as integers, vectors, matrices, strings, etc., which facilitates defining queries and functions involving numerical computations.

[0263] The OSQL query is considered to be an anonymous (lambda) function without arguments, which is executed immediately after being defined. For example, the following OSQL query (defined to find the stream of numbers between 1 and 10 whose square root is less than 10): select Stream of i from Integer i where i in range(1,10) and sqrt(i)<10 can be handled by generating the following anonymous lambda function: create function lambda()->Stream of Integer as select i from Integer i where i in range(1,10) and sqrt(i)<10, and then immediately invoking lambda().

[0264] In a subsequent step, the interpretation software function ES of the central server CS parses the received query to produce a parsed query expression.

[0265] The query received by the central server CS can be in text (plain) format, or easily transformed into such format by, for example, unpacking and / or decrypting the query.

[0266] Hence, the first step of the query processing is to parse the query in textual fashion into an equivalent syntax for further internal processing. Such equivalent can be a so-called abstract syntax tree, for example an S-expression.

[0267] An abstract syntax tree is generally a data tree representation of the abstract syntactic structure of a text, such as source code, written in a formal language. Each node of the tree represents a construct occurring in the text.

[0268] An S-expression (or "symbolic expression") is generally an expression in a notation similar to that of a symbolic name for nested lists (tree-structured) data. In the common parenthesized syntax of Lisp, an S-expression can be defined as: 1. an atom, or 2. an expression of the form (x. y), where x and y are S-expressions.

[0269] More specifically, S-expressions can be viewed as Lisp programs that can be evaluated immediately. Evaluation of S-expressions can result in execution of at least some (such as all) of the query processing steps described below to evaluate an initially received query. Use of S-expressions enables OSQL to be represented in Lisp code that can then be executed immediately or passed to other peer devices for remote evaluation (i.e., executable software code is sent from a central server CS to a remote computer entity for subsequent execution, and the results of the execution are subsequently returned to the central server CS).

[0270] An S-expression for (equivalent to) primes() is as follows: (create-function primes ((integer n)) ((stream of ((integer m)))) as (m) where(and (notany (select (factor) foreach((integer factor) where (and (= (mod m factor) 0) (= (in (range 2 (sqrt m)))factor)))) (= (in (range 2 n)) m))) In a subsequent step, the parsed query can be converted by an interpretation software function ES of the central server CS into an equivalent query in a predicate-logic based declarative object-oriented query representation. A "declarative" representation is one that defines the logic of a computation without specifying its control flow. A "predicate" is a logical symbol that represents a property or a relation. For example, in the first-order formula P(a), the symbol P is a predicate that applies to each constant a. Similarly, in the formula R(a,b), R is a predicate that applies to each constant a and b. A predicate can be interpreted as a relation. For example, in the standard semantics of first-order logic, the formula R(a,b) is true in interpretation if the entities represented by a and b represent the relation represented by R.

[0271] In some embodiments, a declarative object-oriented query representation can well classify various objects such as tensors, functions, data generators, etc. A "strongly typed" language has strict typing rules that allow the compiler to determine the type of an expression at compile time, as opposed to a "weakly typed" (or "late bound") language such as Lisp and Python, which must determine the type of each object at run time. The present inventors have successfully used a declarative object-oriented query representation that extends Datalog, a declarative logic programming language that is a subset of Prolog. However, Datalog's bottom-up query processing is not suitable for dataflow because it materializes large data objects to produce complete query results, whereas dataflow produces a stream of variable bindings to small transient objects that are passed to callback functions in the application.

[0272] An exemplary extension of conventional languages such as Datalog is a primitive for defining user-defined predicates in terms of multi-directional foreign functions (i.e., functions that can depend on what arguments and results are bound or unbound, called binding patterns, in the form of external OSQL functions defined in some external programming languages such as Lisp, Lisp, or Java). See T. Risch et al., "Representing Matrices Using Multi-Directional Foreign Functions," in Gray et al., "Functional Approach to Computing with Data," Springer, ISBN 3-540-00375-4, 2004. For example, a call to the function sqrt(Real x) -> Real y in the query select sqrt(4) requires that the computation of y be as the square root of x = 4, i.e., x is bound and y is unbound. However, in the query select x from Number x where sqrt(x) = 2, y = 2 is bound and x is computed to be the square root of y 2 In the query select sqrt(4) = 2, both x and y are bound, and the query optimizer will subsequently choose an execution plan that tests 2 2 = 4, which is cheaper than testing that 2 is the square root of 4.

[0273] In some embodiments, a declarative object-oriented query representation can require that external function definitions also correspond to inverse external function definitions, or support such definitions.

[0274] Thus, when using a multi-way external function, the programmer can not only choose to implement the function in the chosen external language, but also to implement the inverse of the function. For example, the inverse of the external function sqrt(Real x) -> Real r is r 2 This can significantly improve the performance of queries using external functions, as it allows the query optimizer to choose between the function and its inverse to bind variables in the subsequent steps of defining the execution plan. By defining the inverse of a function, the query optimizer has more choices to optimize the query, as it can bind more variables by applying such inverses.

[0275] Thus, a declarative query representation can include such multi-way (or at least bi-directional) functions.

[0276] In some embodiments, a declarative object-oriented query representation can require or support the use of an associated cost function (cost model) for external function definitions.

[0277] The present inventors have successfully used the query language ObjectLog (see Risch et al., "Main Memory Oriented Optimization of OO Queries using Typed Datalog with Foreign Predicates", IEEE Transactions on Knowledge and Data Engineering, Vol. 4, No. 6, December 1992) for the present purposes by extending it with streams and tensors.

[0278] In the presently described conversion to an equivalent query, the interpretation software function ES of the central server CS can use type inference (in general, "inference" refers to the automatic detection of the type of an expression in a formal language) to determine the types of variables occurring in the parsed query. The internal use of the above-described predicate-logic-based representation of types enables powerful logic-based transformations in the subsequent definition of the execution plan. Such transformations can be used to simplify and optimize the logical query expressions to produce equivalent smaller and faster expressions. However, the predicate representation itself can not be sufficient for efficient query execution, so the subsequent query processing steps (defining the execution plan) can be supplemented with information from the initial query as well as data statistics and knowledge about the functions (such as statistics about their execution cost, result size, and possibly how large a percentage of the input arguments produces non-empty results) to automatically select a good strategy for the execution plan.

[0279] The above-described ObjectLog representation of a function definition is as follows: predicate primes (Integer n, Integer m) locals Stream of Integer v7 where makestream((lambda (Integer m1, Integer factor) locals Real v3,Integer v6 where mod(m1, factor, 0) and sqrt(m1, v3) and cast_integer(v3, v6) and range(2, v6, factor)), m, v7) and notany(v7) and range(2, n, m); ObjectLog is a relational language (a programming language where programming logic consists of relations and outputs are computed based on the applied queries), in which predicates p(v1,…,v) are defined. n ), without specifying which variables v i What are the inputs and which variables v? i This is the output. Therefore, ObjectLog is a purely logical representation of the query definition, well-suited for logical transformations and simplifications (to define the execution plan, see below) prior to subsequent query optimization steps. In contrast, OSQL is both a relational and functional query language, where OSQL functions are defined based on declarative queries (“select” expressions), with the function's input and output indicated by the -> symbol in the function header. In OSQL, functions are defined with logical directions and produce results based on the bound variables. This is not the case in ObjectLog relations where no variables are specified as bound. To run an ObjectLog program from a given OSQL query, additional information about the variables bound in the OSQL query is required. This additional information may also include the inverse of the function and the cost model of the outer function. It should be recognized that ObjectLog is one possible example of a useful relational language and other relational languages ​​with one or more of the properties described herein with respect to ObjectLog can be used instead.

[0280] As a simple example of the ObjectLog representation of a parsed query, suppose it is defined as the following query that finds the square root of 4 for integers between 1 and 1,000,000: select Stream of x from Integer x where x in range(1,1000000) and sqrt(x)=4 Without knowing that the inverse of y = sqrt(x) is x = y 2 , the entity processing the query will have to test for whether sqrt(x) = 4 for one million values of x. By knowing the inverse, one can instead perform a single multiplication , which is more than a million times faster.

[0281] In the prime number example described above, the ObjectLog compiler can perform type checking and expand the nested function call into a union predicate. In addition, it can generate the variables v7 through to a binding of the integer stream represented by the anonymous lambda predicate applied to the parameter m and v7. The anonymous lambda predicate and function are not specific to ObjectLog, but can also be used in other examples. Note here that the test predicate mod(n, factor, 0) requires that the variables n and factor are known, and that the call makestream(pred, arg, b) to define a stream b of integers as the set of possible bindings of v in pred(arg, v) requires the binding m so that the predicate definition cannot be executed as it is presented. However, the query optimizer will produce an executable program in the form of an execution plan.

[0282] That is, in a subsequent step, the interpretation software function ES of the central server CS can produce an execution plan corresponding to the parsed (and possibly compiled) query expression described above, whereby the execution plan defines at least one computation to be performed based on measurement values from a sensor S of an edge computing device ECD. It will be appreciated that this definition can be explicit (e.g. explicitly referring to the sensor S and / or edge computing device ECD under consideration) or implicit (i.e. the identity of the sensor S is inferred from other information in the query, or is externally provided to the central server CS and / or edge computing device ECD, or is dynamically determined on the fly based on current parameter values).

[0283] To this end, SLOG (as characterized above) can be used, or an alternative internal execution plan language having one or more of the above-mentioned properties can be used.

[0284] As mentioned above, a non-procedural, logic-based query representation does not specify what algorithm (i.e. external function) to use and in what order to produce the elements of a result stream or collection. Therefore, in this case and in other cases, responding to the query or calling the function requires the query optimizer of the interpretation software function ES of the central server CS to select a good execution strategy.

[0285] Cost-based query optimization (the practice of determining the most efficient way to execute a given query by considering a set of possible query plans) is useful for the purposes of the present invention to produce an execution plan based on data statistics and other knowledge about the operators in the query and the data stored in the memory database of the central server CS. Query optimization is used to produce an efficient and executable execution plan. This can be important because a poor execution plan can be thousands of times slower than an optimal execution plan, or even not executable at all.

[0286] As mentioned above, the execution plan can be expressed using said internal execution plan language, specifically for OSQL queries, the internal execution plan language can be SLOG. Thus, for a given OSQL function, the query optimizer of the interpretation software function ES of the central server CS generates in SLOG an optimized stream generator that implements the considered function. The optimization can be guided by (based on) a query cost model that estimates the cost of invoking a stream generator based on the optimization metrics of the operators and the algorithms used in it. A stream generator is a predicate extended with binding annotations that respectively indicate what variable is an input and an output in the predicate. When executed, a stream generator will generate a binding stream for the output variable, assuming the input variable is known. For example, the function primes(Integer n) -> Stream of Integer m will produce a binding stream of variable m to prime numbers smaller than n.

[0287] SLOG is an example of a very simple but powerful language for representing execution plans of OSQL as stream generators. It has only five built-in operators, namely "call" (invoke an external stream generator), "funcall" (external function call), "and" (intersection), "or" (union), and "or!" (conditional union). In addition to the five system operators, users can also implement stream generators in some external programming language through an API. The system can include and support a library of predefined stream generators that can be used directly by the programmer.

[0288] Below are some examples of SLOG algebraic expressions generated for some exemplary OSQL queries.

[0289] The following stream generator is generated by the query optimizer for the function primes(): primes-+(Integer n, Integer m)<- locals(Bag of Integer v6) call(range--+,2,n,m) and funcall(makebag, (lambda- + (Integer m1, Integer factor) <- locals (Real v2, Integer v5) funcall(sqrt, m1, v2) and funcall(cast_integer, v2, v5) and call(range--+, 2, v5, factor) and funcall(mod, m1, factor, 0)), m, v6) and funcall(notany, v6) Here, the test funcall(notany, v6) calls the external function notany(v6), which succeeds when it returns true in the case that the bag v6 is empty.

[0290] Here, the stream generators in the SLOG execution plan are generated by annotating the previous ObjectLog predicates with binding patterns that indicate that the argument n must be bound for them to apply and to produce a bound stream to m. Binding patterns are strings in which a “-” indicates that a variable must be bound to some value, and a “+” indicates that the variable will be bound by a call to a stream generator. In general, an SLOG stream generator produces zero, one, or several bindings of unbound variables for a given bound variable. For example, a call to range--+(2, v5, factor) generates a stream of bound objects of the variable factor to each of the integers 2 and 3 when v5 is bound to 3. A common case is that a stream generator generates a single value, which is called an external function. For example, the external function sqrt(x) computes the positive square root of x, and the external function call funcall(sqrt, m1, v2) binds v2 to 2 if m1 is bound to 4.

[0291] A query can produce an anonymous (lambda) stream generator, for example: lambda+(Integer i) <- call(range--+, 1, 10, i) and funcall(less, i, 5) Thus, as a result of this step, an execution plan is established, which is equivalent to receiving a query (defined using the query language described), the execution plan defining an effective way to produce a response (result) to the query.

[0292] In a subsequent step, as part of the interpretation software function ES of the central server CS, which is an internal language compiler, can subsequently compile at least part of the resulting execution plan by converting said at least part of the execution plan into corresponding platform-independent assembly code (defined in an "assembler language" of an assembler).

[0293] It is noted here that the term "assembler language" refers to a symbolic machine code language where typically each machine instruction uses one statement. However, the assembler can be defined in a platform-independent way, independent of specific hardware and / or operating system requirements or functionalities that can exist on the edge computing device ECD that is to execute the corresponding binary machine code (see below). The assembler can be defined as binary or plaintext code. The assembler can be converted into binary code for a specific computer architecture by a binary code generator for the specific computer architecture.

[0294] However, in some embodiments, at least part of the resulting execution plan is not compiled, but is kept as non-assembled, non-binary code to be interpreted by the interpretation software function ES of the edge computing device ECD.

[0295] As a result of the compilation into assembler code, the performance of the execution plan produced by the query optimizer in the above general manner is further improved. Continuing the example of using SLOG as the internal execution plan language, the SLOG compiler converts the SLOG stream generators of the above type into an assembler language called SLAP (SLog Assembly Program).

[0296] In general, a machine-independent assembly language can be used as the assembler language. SLAP is an example of such a machine-independent assembly language. When compiling the execution plan into such an assembly language, some further code generation optimization methods can be applied to improve the execution speed and minimize the code size, such as removing unnecessary jumps, optimizing register allocation, peephole optimization, and dead code elimination.

[0297] In some embodiments, where no binary code generator is implemented for some computer architectures, or if one is generated for a certain architecture such as OS X, the abstract code (e.g. SLAP) interpreter of the interpretation software IS can be used to interpret the assembler.

[0298] In some embodiments, the internal execution plan language is of a type that the interpreter function of the edge computing device ECD can directly interpret without the internal execution plan language statements being compiled. For example, this is the case in the exemplary system 100 described herein, using SLOG as the internal execution plan language and SLAP as the assembler language.

[0299] Thus, the established execution plan defined using the internal execution plan language does not need to be fully compiled into assembly language, as it can also be directly interpreted by the interpretation software function ES. Thus, the (e.g., SLOG) compiler can generate (e.g., SLAP) assembly language code snippets for (e.g., SLOG) expressions that it can compile (e.g., into SLAP), while the interpretation software function ES handles the remaining (e.g., SLOG) code that cannot be further compiled or for which compilation by interpretation is deemed not worthwhile.

[0300] For example, the compiler can be configured to not compile: objects whose type cannot be statically determined; and / or operations that are not supported by the compiler, such as string operations, iteration over bags and streams, data conversions, etc., as the case can be. Generally, high cost operations that are not supported by the compiled machine instructions, such as FFT (Fast Fourier Transform), image recognition, and advanced numerical array calculations, are not worthwhile. Thus, such operators are implemented inversely as an interpreted call to a regular external function.

[0301] Continuing the example primes above, the SLOG code with SLAP code snippets is shown below: primes-+(Integer n, Integer m)<- locals(Bag of Integer v6) call(slap-+, <code1>, n, m) and funcall(makebag,(lambda-+(Integer m1,Integer factor)<- call(slap--+, <code2>, m1, factor)), m, v6) and funcall(notany(v6)) Since the SLOG code in the body of the internal anonymous (lambda) stream generator contains only defined types (integers and reals) and only arithmetic operations, it can be compiled completely to <code2>SLAP code in the middle. <code1>The SLAP code implementation in the middle produces a loop over the integers between 2 and n.

[0302] In a subsequent step, the binary code assembler part of the interpretation software function ES of the central server CS can transcribe at least parts of the assembler into platform specific binary code. This transcription process can consist entirely of simple statement by statement conversion that converts the produced platform independent assembler assembly statements into corresponding platform specific binary statements for the specific hardware / operating system platform on which the execution plan is intended to be executed.

[0303] Thus, the binary code assembler of the interpretation software function ES of the central server CS, such as the SLAP assembler, can produce binary code (statements) for one or several of the target architectures supported by the system 100 in order to produce a code package for binary code for different architectures. Both the platform specific code packages and the platform independent (SLAP) code can be saved in the database of the central server CS for later reuse. In order to produce platform specific binary code for different kinds of edge computing devices ECD, a specific binary assembler, such as a specific SLAP binary assembler, can be made available for each supported target architecture. The code package can also contain several kinds of assembled binary machine code that is then invoked (execution initiated by) from an interpreter on the target machine (the edge computing device ECD under consideration) at runtime.

[0304] The machine specific binary code can be assembled into the target machine architecture on the fly and saved in the database of the central server CS, thus directly related to when (the) code is transferred to the edge computing device ECD for query processing. If the code is executed in the central server CS, it can be assembled into the native machine code of the central server CS immediately.

[0305] As an alternative to binary code, the binary code assembler can also produce platform specific assembler code. In this case, such assembler code can be efficiently byte code interpreted in edge computing devices ECD whose machine architecture does not allow for just-in-time compilation. This is the case, for example, for OSX.

[0306] Continuing the SLOG / SLAP example, the following are exemplary statements in different platform specific formats (the corresponding platform independent SLAP statements are shown in addition to the first line): dadd D2,D3 ; SLAP assembly instruction addsd xmm2,xmm3 ; Intel x86-64 assembly instruction fadd D2, D3 ; ARM Aarch64 assembly instruction A binary code assembler can allocate available registers of the target architecture, place the remaining operands on the stack (SLAP typically has more registers than the physical device), and transcribe each instruction one-to-one.

[0307] Any portion of the execution plan that is not compiled into assembly code and / or not transcribed into platform-specific assembly / binary code can be interpreted by the edge computing device ECD of the interpretation software function ES. Any compiled and transcribed binary code portions of the execution plan can conversely be executed directly by the processor of the edge computing device ECD.

[0308] In cases where the entire execution plan can be compiled into assembly code, not even an execution plan interpreter on the edge computing device ECD is needed, which saves storage space (both RAM and flash) on the edge computing device ECD. In such cases, the central server CS can determine whether a particular query definition requires an execution plan language interpreter function to be installed on the edge computing device ECD in order to run a given query or call function, and if so, initiate automatic download and installation of such a function on the edge computing device ECD under consideration (if not already installed).

[0309] In some embodiments, at least for one (such as several) edge computing devices ECD in the system 100, the edge computing device ECD under consideration is capable of interpreting the internal execution plan language code and at least one of compiled assembly code and transcribed binary code. Furthermore, in some embodiments, at least a portion of the execution plan definition is compiled, while at least a portion of the execution plan is not compiled.

[0310] In a subsequent step, at least one of the edge computing devices ECD can subsequently receive the at least partially compiled execution plan as generated as described above via its digital communication interface IF.

[0311] In a subsequent step, the interpretation software function ES of the edge computing device under consideration runs both any compiled portions and any uncompiled portions of the at least partially compiled execution plan on the CPU of the at least one of the edge computing devices ECD, as appropriate, to produce a first result of the at least partially compiled execution plan. The interpretation includes performing the above-described calculations based on the measured sensor S data.

[0312] As is clear from the above, the execution can be performed on a single edge computing device ECD; in parallel on several edge computing devices ECD; and / or in a multi-tiered set of edge computing devices ECD reporting to each other according to a tree structure of such edge computing devices ECD. Typically, this will be defined directly in the parsed query.

[0313] As already exemplified and explained above, any non-compiled part of the execution plan is run by the edge computing device ECD's interpreted software functions ES interpreting the considered execution plan part; while any compiled part of the execution plan is run by the edge computing device ECD's interpreted software functions ES directly initiating its execution by the edge computing device ECD's CPU.

[0314] In a subsequent step, the edge computing device ECD communicates the result of running the execution plan (the first result, which then is the endless stream of objects as described above) to the central server CS via its digital communication interface IF.

[0315] In a subsequent step, the central server CS, in response to receiving the result from the edge computing device ECD, communicates the result of the query or a secondary result computed based on the result received from the edge computing device ECD to the considered query party. This then constitutes the response to the posed query.

[0316] In alternative embodiments, the edge computing device ECD can communicate the result to a different entity, such as a different central server CS or a different edge computing device, as can be specified (or implied) as part of the query. Correspondingly, in case the central server CS receives the result, it can provide the result (or a secondary result) to an entity different from the query entity.

[0317] The system 100 can be configured such that any system receiving a query from any entity, the peer edge computing device ECD and / or the central server CS, can request immediate full query processing of such received query by its parent central server CS. The parent central server CS will then perform the above described steps in response to such request to produce an at least partially compiled execution plan that is communicated back to the requesting child entity. This communicated execution plan can subsequently only contain platform specific binary code for the specific hardware and / or operating system of the requesting child entity (as well as any non-compiled parts of the execution plan). It can also contain platform independent binary code as described above. The parent central server CS can be configured to store the compiled and non-compiled parts of the execution plan in its database for later use by edge computing devices ECD of similar or different configuration.

[0318] The system 100 can generally be designed to minimize unnecessary work and keep the thin engine (edge computing device ECD) as simple as possible, while guaranteeing full engine's full functionality. Moreover, by transmitting queries for optimization and compilation to some other peers in the federation, resulting execution plans and / or binary code for execution on the peers can be operated using a variety of functions to operate the thin engine.

[0319] Accordingly, the internal language compiler can be configured to compile only or at least the arithmetic portion of the internal language execution plan and leave the remaining predicates intact for interpretation by the interpreted software function ES at the edge computing device ECD. Accordingly, the internal language compiler can be configured to replace the compiled predicates with one CODE object for each group of adjacent predicates.

[0320] In some embodiments, the internal language compiler can be configured to compile the execution plan into a platform-independent assembler and then save the assembler in a database such as the central server CS. Then, in case additional edge computing devices ECD are invoked to process the same query or a portion of the query, the saved assembler can be quickly transcribed by the same or a different central server CS into binary code specific to whatever hardware and / or operating system platform the additional edge computing devices ECD have. The saved assembler, such as SLAP code, can be stored in a shared manner in the system 100, such as shared among the peer central servers CS for reuse at the level of the system 100. This makes the internal language compiler not have to compile the same execution plan multiple times for different machine architectures; transcription is typically much faster than compilation. The platform-independent assembler can also be interpreted on one or more edge computing devices ECD, as described above.

[0321] Moreover, using the above-described approach, the central server CS can be configured to transcribe the platform-independent assembler into platform-specific machine code only when necessary and then retain (cache) the resulting platform-specific binary code for later reuse.

[0322] Since transcription is typically a very cheap operation, it can be configured to be performed on the fly, such as even while transmitting the execution plan to a peer central server CS or edge computing device ECD as part of it.

[0323] Moreover, the platform-independent assembler, such as SLAP code, can be easily made portable and efficient in terms of code size and interpretation time, for easy sharing among the peer central servers CS for reuse and deployment at various edge computing devices ECD.

[0324] In case the platform-independent assembler is interpreted by an interpretation software function ES at the edge computing device ECD (which is also possible in some embodiments), such interpretation is typically faster than the interpretation of the internal execution plan language, at least in case it represents several predicates.

[0325] In some embodiments, the assembler contains one or several special instructions that are arranged to invoke an interpreter when called for internal language code that cannot or is not converted into binary code. For example, the interpreter can need to be called when starting to process a new stream. This makes it possible to eliminate part or all of the interpreter for the execution language on small edge computing devices ECD.

[0326] Hence, the interpretation software function ES of each edge computing device ECD can be configured to interpret the internal execution plan language and / or the assembler language, as the case can be.

[0327] Hence, the full engines can be provided with and process code (corresponding to a query or a part of a query) defined in the internal execution plan language, the assembler language and / or the platform-specific binary code, and then each of these instances can be processed by its locally installed and executed interpretation software function ES. In contrast, the thin engines can be configured to always only receive the respective platform-specific binary code. In the latter case, no interpreter for the execution language is needed.

[0328] All parsed, compiled, optimized and transcribed code can be cached and / or shared between different central servers CS for reuse. For example, when a new target architecture is added for an edge computing device ECD, it is quite simple to implement a transpiler backend for this new target architecture. Since all code optimization is done at a higher level (when defining the execution plan), the transpilation can be performed centrally and then automatically propagated to all relevant devices, such as on the fly when needed.

[0329] As mentioned, the thin engine edge computing devices ECD can be configured to not include the query processing algorithms, and their interpretation software function ES can therefore not define but only execute the optimized and compiled execution plan, as Figure 10 The illustrated (explanation software function ES then includes only an internal execution plan language interpreter and downstream components, or in some embodiments only downstream components). In the example of SLOG discussed above, the internal execution plan language interpreter can be the SLOG interpreter, which is available on the thin engine edge computing device ECD and is configured to handle SLOG primitives for which the SLOG compiler cannot generate assembly code. For a thin engine edge computing device ECD, the execution plan can typically include pointers to binary code snippets that are invoked by the internal execution plan language interpreter when encountered in the execution plan, so such a thin engine edge computing device ECD can also handle such pointed-to binary code included in the interpreted execution plan.

[0330] There can be computer architectures that do not implement a binary code generator (such as no SLAP binary code generator), or computers that for platform reasons do not allow dynamic generation of binary code, for example in OSX devices. To account for this, the system 100 can also include an assembler (such as SLAP) bytecode interpreter as part of the explanation software function ES on at least some edge computing devices ECD, which interprets assembler instructions on the computer where the assembler language cannot be transcribed into binary code. This is also illustrated in Figure 10

[0331] The above, a preferred embodiment has been described. However, it will be apparent to a person skilled in the art that many modifications can be made to the disclosed embodiment without departing from the basic idea of the invention.

[0332] For example, the edge computing devices ECD can take many different forms in terms of hardware platform and software platform. Since the explanation software function ES is easily portable and can run in a way that is substantially independent of the details of its environment (much like Java code), it can be deployed and operated on any general purpose programmable hardware connected to a computer network such as the Internet in at least one of the above forms. The same system 100 can include many different types of edge computing devices ECD without having to take into account anything other than the hardware limitations of each edge computing device ECD.

[0333] In some embodiments, the device is only intermittently connected to the computer network, in which case the installation of the execution plan is delayed until the device is later connected to the network.

[0334] ​In some embodiments, the device can only connect to the internet when the (compiled) execution plan is installed on the device. The execution plan runs autonomously after this without connecting to the network again.

[0335] The above description describes many different embodiments. In general, all embodiments are freely combinable, unless otherwise stated and as long as they are compatible. This should happen frequently.

[0336] For example, the edge computing devices EDC and / or the central servers CS can make queries to each other in a tree structure, as described herein. In such cases, each pair of querying and queried entities can act as a respective central server CS in relation to the respective edge computing device EDC in terms of parsing, compiling, optimizing and transcribing of the query code, also as described herein. Thus, such queries can occur in a multi-layered device.

[0337] The application is therefore not limited to the described embodiments, but can vary within the scope of the attached claims.

Claims

1. A system (100) comprising a number of edge computing devices (ECD) and a first central server (CS), each such edge computing device (ECD) and each such central server (CS) in turn comprising a memory (M); Central processing unit CPU; and a digital communication interface (IF) arranged to allow digital communication over a digital communication network (NW), each of the edge computing devices (ECD) further comprising a sensor (S), wherein the central server (CS) is arranged to accept a query from a querying party and via the digital communication interface (IF), the result of the query comprising at least one stream of data objects, at least one of the streams being an endless stream of objects, the endless stream being computed based on data measured by the sensor (S) and continuously or intermittently provided over time and communicated via the digital communication interface (IF), the endless stream having no defined end point at the time of the query, characterized in that the central server (CS) is arranged to perform the following steps: a) parsing the query to produce a parsed query expression; b) producing an execution plan corresponding to the parsed query expression; and c) compiling at least part of the execution plan by transforming the part of the execution plan into corresponding platform-independent assembly code while leaving the at least part of the execution plan uncompiled, thereby obtaining a partially compiled execution plan, in that at least one of the edge computing devices (ECD) is arranged to subsequently receive the partially compiled execution plan via the digital communication interface (IF), in that the at least one of the edge computing devices (ECD) is arranged with an interpreted software function (ES) arranged to be executed on the CPU of the edge computing device and to run both the compiled and uncompiled parts of the partially compiled execution plan by means of interpretation of at least part of the partially compiled execution plan; in that each edge computing device (ECD) is arranged to, when running the partially compiled execution plan, produce a first result of the partially compiled execution plan and communicate the first result via the digital communication interface (IF), in that the partially compiled execution plan defines a computation to be performed based on measurements from the sensor (S), and in that the edge computing device (ECD) in question is arranged to perform the computation as part of the interpretation.

2. The system (100) according to claim 1, wherein the query is defined according to a query language having a predetermined syntax, the syntax being arranged to define queries whose result comprises at least one data stream and to allow the definition of the query according to a computation to be performed based on measurements from the sensor (S).

3. The system (100) according to claim 1 or 2, wherein the query language is an object-oriented query language.

4. The system (100) according to any preceding claim, wherein the parsing comprises parsing the query into an equivalent abstract syntax tree, such as into an S-expression.

5. The system (100) according to any preceding claim, wherein the parsing is into a representation of one or more of the following types: declarative; object-oriented; based on predicate logic, e.g. employing multi-way external functions; strongly typed; and relational.

6. The system (100) according to claim 5, wherein the representation is extendable by providing primitives for user-defined predicates, e.g. multi-way external functions according to which different implementations are provided depending on known / unknown state of arguments of the external function.

7. The system (100) according to any preceding claim, wherein step c comprises the central server (CS) transcribing at least part of the assembly code into platform-specific assembly code.

8. The system (100) according to any preceding claim, wherein any uncompiled part of the execution plan is run by the edge computing device’s (ECD) interpretation software function (ES) interpreting the considered execution plan part; whereas any compiled part of the execution plan is run by the edge computing device’s (ECD) interpretation software function (ES) directly initiating its execution by the edge computing device’s (ECD) CPU.

9. The system (100) according to any preceding claim, wherein in step c only or at least the arithmetic part of the execution plan is compiled.

10. The system (100) according to any preceding claim, wherein the central server (CS) is arranged to save the platform-independent assembly code for later reuse.

11. The system (100) according to claim 10, wherein the central server (CS) is arranged to transcribe the saved platform-independent assembly code into platform-specific code for different edge computing devices (ECD).

12. The system (100) according to any preceding claim, wherein each sensor (S) and / or edge computing device (ECD) is able to refer to global namespaces or attribute sets according to the syntax.

13. The system (100) according to any preceding claim, wherein each edge computing device (ECD) is arranged to discard at least some of the measurement data, preferably all of the measurement data, measured by the sensor (S) instead of storing the measurement data in the memory (M) after having communicated the measurement data and / or a piece of information computed based on the measurement data, such as the result, by the digital communication interface (IF).

14. The system (100) according to any preceding claim, wherein the system (100) further comprises a distributed or monolithic central server (CS), each of the edge computing devices (ECD) having a client role with respect to the central server, and wherein all communication between the individual edge computing devices (ECD) is via the central server (CS).

15. The system (100) according to any preceding claim, wherein the interpretation software function (ES) comprises an external application programming interface, API, arranged to allow an expression in the query language to call external computer code and / or to allow external computer code to call an expression in the query language.

16. The system (100) according to any preceding claim, wherein the interpretation software function (ES) comprises a machine learning function arranged to define, train and execute a machine learning model, such as a neural network.

17. The system (100) according to claim 16, wherein the memory (M) of the edge computing device (ECD) comprises the defined and trained machine learning function interpreted by the interpretation software function (ES) under consideration executing on the edge computing device (ECD) of the query reference.

18. The system (100) according to claim 16 or 17, wherein the interpretation software function (ES) under consideration is arranged to train the defined machine learning function based on the result of the query.

19. A method for collecting data in a system (100) comprising a number of edge computing devices (ECD) and a first central server (CS), each such computing device (ECD) and each such central server (CS) in turn comprising: a memory (M); a central processing unit, CPU; and a digital communication interface (IF) arranged to allow digital communication on a digital communication network (NW), each of the edge computing devices (ECD) further comprising a sensor (S), characterized in that the method comprises the steps of a) the central server (CS) accepting a query from a querying party and via the digital communication interface (IF), the result of the query comprising at least one stream of data objects, at least one of the streams being an endless stream of objects, the endless stream being computed based on data measured by the sensor (S) and provided continuously or intermittently over time and communicated via the digital communication interface (IF), the endless stream having no defined end point at the time of the query; b) the central server (CS) parsing the query to produce a parsed query expression; c) the central server (CS) producing an execution plan corresponding to the parsed query expression, the execution plan defining computations to be performed based on measurements from the sensor (S); d) the central server (CS) compiling parts of the execution plan by converting at least part of the execution plan into corresponding platform-independent assembly code, while leaving the at least part of the execution plan uncompiled, thereby obtaining a partially compiled execution plan; e) at least one of the edge computing devices (ECD) receives the partially compiled execution plan via the digital communication interface (IF); and f) an interpreted software function (ES) of the at least one of the edge computing devices (ECD) executes on the CPU of the edge computing device (ECD) and runs both compiled and uncompiled parts of the partially compiled execution plan by means of an interpretation of at least parts of the partially compiled execution plan to produce a first result of the partially compiled execution plan, the interpretation including the execution of the computation.

Images