Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
SUPPORTING AND/OR CONTROLLING DATA INPUT AND/OR OUTPUT BETWEEN A DEVICE AND A COMPUTER IN A TECHNICAL SYSTEM
Document Type and Number:
WIPO Patent Application WO/2019/013685
Kind Code:
A1
Abstract:
There is provided a method of probing and/or controlling a technical system by using one or more physical hardware devices interacting with the technical system. The method is based on transferring data between the physical hardware device(s) and a computer system, each physical hardware device having or being associated with physical sensor and/or actuator capabilities. The method comprises (S1) collecting and transferring sensor data from the physical hardware device(s) for analysis, presentation and/or storage, and/or (S2) transferring control signaling to the physical hardware device(s) for acting on the technical system. The method further comprises (S3) supporting and/or controlling the data transfer between the physical hardware device(s) and the computer system by using a modular framework implemented in the computer system. The modular framework has a number of different logical modules, arranged in a hierarchical modular relationship.

Inventors:
PETRINI DANIEL (SE)
Application Number:
PCT/SE2018/050659
Publication Date:
January 17, 2019
Filing Date:
June 20, 2018
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
STARDOTS AB (SE)
International Classes:
G06F9/448; G05B19/418
Domestic Patent References:
WO2017117348A12017-07-06
Foreign References:
EP2924573A22015-09-30
US20170005820A12017-01-05
US20170008162A12017-01-12
Attorney, Agent or Firm:
AROS PATENT AB (SE)
Download PDF:
Claims:
CLAIMS

1. A method of probing and/or controlling a technical system (10) by using one or more physical hardware devices (20) interacting with the technical system, wherein the method is based on transferring data between the physical hardware device(s) (20) and a computer system (30), each physical hardware device having or being associated with physical sensor and/or actuator capabilities, wherein the method comprises:

collecting and transferring (S1) sensor data from the physical hardware device(s) for analysis, presentation and/or storage; and/or

transferring (S2) control signaling to the physical hardware device(s) for acting on the technical system, and

supporting and/or controlling (S3) the data transfer between the physical hardware device(s) and the computer system by using a modular framework implemented in the computer system (30), wherein the modular framework has a number of different logical modules, arranged in a hierarchical modular relationship, including a device representing one of the physical hardware devices, a channel associated with a device and representing an interaction point with the technical system, a session representing a holder of a number of devices and a number channels, each of which is associated with a corresponding device, wherein the session defines data generation and data transfer rates, in addition to being a holder of device and channel references, and an assembly, which is a holder for at least one session and controls the start and stop of the data transfer.

2. The method of claim 1, wherein the logical modules of the modular framework further comprises a database representing a physical storage of data and/or a plot representing a visualization of data belonging to one or more specific channels.

3. The method of claim 1 or 2, wherein the method further comprises configuration of the physical hardware devices and/or the data transfer process associated with the physical hardware devices. 4. The method of any of the claims 1 to 3, wherein the step (S2) of transferring control signaling to the physical hardware device(s) for acting on the technical system includes generating control signaling for actuator(s) operating on the technical system. 5. The method of any of the claims 1 to 4, wherein the method further comprises storing and/or processing the collected sensor data, and/or performing data analysis.

6. The method of any of the claims 1 to 5, wherein a start process is initiated when all the modules are ready, prompting the modules to work both individually and together according to the hierarchical modular relationship.

7. The method of any of the claims 1 to 6, wherein the assembly is the top module, and the session, device and channel modules are submodules.

8. The method of claim 7, wherein the submodules, when composed and/or linked together, form an executable application.

9. The method of claim 7 or 8, wherein all or a subset of the submodules are configured to read instructions issued by the assembly module.

10. A system (100; 200; 300) configured to probe and/or control a technical system (10) by using one or more physical hardware devices (20) interacting with the technical system, wherein the system (100; 200; 300) is configured to transfer data between the physical hardware device(s) (20) and a computer system (30), each physical hardware device having or being associated with physical sensor and/or actuator capabilities, wherein the system (100; 200; 300) is configured to collect and transfer sensor data from the physical hardware devices) for analysis, presentation and/or storage; and/or

wherein the system (100; 200; 300) is configured to transfer control signaling to the physical hardware device(s) for acting on the technical system,

wherein the system is configured to operate based on a modular framework for supporting the data transfer between the physical hardware device(s) and the computer system,

wherein the modular framework has a number of different logical modules, arranged in a hierarchical modular relationship, including:

a device representing one of the physical hardware devices, a channel associated with a device and representing an interaction point with the technical system,

a session representing a holder of a number of devices and a number channels, each of which is associated with a corresponding device, wherein the session defines data generation and data transfer rates, in addition to being a holder of device and channel references,

an assembly, which is a holder for at least one session and controls the start and stop of the data transfer.

11. The system of claim 10, wherein the logical modules of the modular framework further comprises a database representing a physical storage of data and/or a plot representing a visualization of data belonging to one or more specific channels.

12. The system of claim 10 or 11, wherein the system is configured to perform configuration of the physical hardware devices and/or the data transfer process associated with the physical hardware devices.

13. The system of any of the claims 10 to 12, wherein the system is configured to generate control signaling for actuator(s) operating on the technical system.

14. The system of any of the claims 10 to 13, wherein the system is configured to store and/or process the collected sensor data, and/or perform data analysis.

15. The system of any of the claims 10 to 14, wherein the system is configured to initiate a start process when all the modules are ready, prompting the modules to work both individually and together according to the hierarchical modular relationship.

16. The system of any of the claims 10 to 15, wherein the assembly is the top module, and the session, device and channel modules are submoduies.

17. The system of claim 16, wherein the submoduies, when composed and/or linked together, form an executable application. 18. The system of claim 16 or 17, wherein all or a subset of the submoduies are configured to read instructions issued by the assembly module.

19. The system of any of the claims 10 to 18, wherein the system is implemented in the computer system.

20. The system of any of the claims 10 to 19, wherein the system (100) comprises processing circuitry (110) and memory (120), the memory (120) comprising a computer program (125) for execution by the processing circuity (120) to perform the functions of the system.

21. A system (200) for converting sensor readings to an output representation, wherein the system is a modular system comprising the following submoduies:

an input module (210) configured to read the output of at least one sensor;

a data conversion module (220) configured to convert the sensor output in order to obtain a representation suitable for storing and/or processing; a data storing module (230) configured to optionally store said converted sensor output;

a processing module (240) configured to collect and process at least part of the converted sensor output wherein said processing is further configured to read instructions specifying how to process said converted sensor output;

an assembly module (250) or session controlling module configured to control the exchange of data between said submodules according to predefined rules, and to control said processing module by means of instructions in order to obtain a suitably processed output.

22. A computer program (125; 135) for supporting, when executed, probing and/or controlling of a technical system through one or more physical hardware devices interacting with the technical system and transfer of data between the physical hardware device(s) (20) and a computer system (30), each physical hardware device having or being associated with physical sensor and/or actuator capabilities,

wherein the computer program (125; 135) comprises instructions, which when executed by a processor (110), cause the processor (110) to:

- support collecting and transferring sensor data from the physical hardware device(s) for analysis, presentation and/or storage; and/or

support transferring control signaling to the physical hardware device(s) for acting on the technical system,

wherein a modular framework is implemented for supporting the data transfer between the physical hardware device(s) and the computer system,

wherein the modular framework has a number of different logical modules, arranged in a hierarchical modular relationship, including:

a device representing one of the physical hardware devices, a channel associated with a device and representing an interaction point with the technical system,

a session representing a holder of a number of devices and a number channels, each of which is associated with a corresponding device, wherein the session defines data generation and data transfer rates, in addition to being a holder of device and channel references,

an assembly, which is a holder for at least one session and controls the start and stop of the data transfer.

23. A computer-program product comprising a non-transitory computer-readable medium (120; 130) having stored thereon a computer program (125; 135) of claim 22.

24. An apparatus (300) for supporting probing and/or controlling of a technical system (10) through one or more physical hardware devices (20) interacting with the technical system, and transfer of data between the physical hardware device(s) (20) and a computer system (30), each physical hardware device having or being associated with physical sensor and/or actuator capabilities, wherein the apparatus comprises:

a support module (310) for supporting collection and transfer of sensor data from the physical hardware device(s) for analysis, presentation and/or storage, and/or for supporting transfer of control signaling to the physical hardware device(s) for acting on the technical system, and

a framework module (320) for providing a modular framework for supporting the data transfer between the physical hardware device(s) and the computer system, wherein the modular framework has a number of different logical modules, arranged in a hierarchical modular relationship, including:

a device representing one of the physical hardware devices, a channel associated with a device and representing an interaction point with the technical system,

a session representing a holder of a number of devices and a number channels, each of which is associated with a corresponding device, wherein the session defines data generation and data transfer rates, in addition to being a holder of device and channel references, an assembly, which is a holder for at least one session and controls the start and stop of the data transfer.

Description:
Supporting and/or controlling data input and/or output between a device and a computer in a technical system

TECHNICAL FIELD

The invention generally relates to the process of data transfer between a device and a computer and more specifically concerns the technical field of probing and/or controlling a physical reality such as a physical or technical system through input and output between a hardware device and a computer, including methods and systems as well as corresponding computer programs and computer program products and apparatuses.

BACKGROUND In general, probing and/or controlling a physical or technical system may include, e.g. the use of sensor and/or actuator technology. Some of the tasks involved include collecting and transferring sensor data from the technical system, storing and/or processing the collected sensor data and/or performing data analysis and optional data presentation, and/or generating suitable control signaling for actuators operating on the technical system.

Basically, one or more physical hardware devices may be interacting with physical reality through sensors and/or actuators, where each device has physical sensor and/or actuator capabilities.

Although significant advances have been made in this area of research, there is still a general need for a systematic and modular approach to the processes of configuring such devices, data transfer from physical device to computer, data processing and/or analysis as well as storage on a physical medium. By way of example, there exist today many different methodologies of the data transfer between hardware device and a computer and the transfer process is sometimes standardized. Modular software programs on the computer are often used as a tool for data transfer. The device carries its controlling software, sometimes referred to as a firmware, describing all the functions and data the device have.

SUMMARY

It is a general object to provide a framework for a modular and standardized approach for transferring data between a physical device and a computer.

It is a specific object to provide a method based on a hierarchal modular relationship that could define a standardized means to transfer data such as sensor data and/or actuator data between a device and a computer, e.g. for further storage and analysis.

It is another object to provide an implementation guide of the above-mentioned data transfer.

In particular, it is an object to provide a method of probing and/or controlling a technical system. It is also an object to provide a system configured to probe and/or control a technical system.

Another object is to provide a system for converting sensor readings to an output representation.

Yet another object is to provide a computer program for supporting, when executed, probing and/or controlling of a technical system, and a corresponding computer program product Still another object is to provide an apparatus for supporting probing and/or controlling of a technical system. These and other objects are met by embodiments as defined herein.

According to a first aspect, there is provided a method of probing and/or controlling a technical system by using one or more physical hardware devices interacting with the technical system. The method is based on transferring data between the physical hardware device(s) and a computer system, each physical hardware device having or being associated with physical sensor and/or actuator capabilities. The method comprises collecting and transferring sensor data from the physical hardware device(s) for analysis, presentation and/or storage, and/or transferring control signaling to the physical hardware device(s) for acting on the technical system. The method further comprises supporting and/or controlling the data transfer between the physical hardware device(s) and the computer system by using a modular framework implemented in the computer system. The modular framework has a number of different logical modules, arranged in a hierarchical modular relationship, including a device representing one of the physical hardware devices, a channel associated with a device and representing an interaction point with the technical system, a session representing a holder of a number of devices and a number channels, each of which is associated with a corresponding device, wherein the session defines data generation and data transfer rates, in addition to being a holder of device and channel references, an assembly, which is a holder for at least one session and controls the start and stop of the data transfer.

According to a second aspect, there is provided a system configured to probe and/or control a technical system by using one or more physical hardware devices interacting with the technical system. The system is configured to transfer data between the physical hardware device(s) and a computer system, each physical hardware device having or being associated with physical sensor and/or actuator capabilities. The system is configured to collect and transfer sensor data from the physical hardware device(s) for analysis, presentation and/or storage, and/or the system is configured to transfer control signaling to the physical hardware device(s) for acting on the technical system. The system is configured to operate based on a modular framework for supporting the data transfer between the physical hardware device(s) and the computer system. The modular framework has a number of different logical modules, arranged in a hierarchical modular relationship, including:

a device representing one of the physical hardware devices, a channel associated with a device and representing an interaction point with the technical system,

a session representing a holder of a number of devices and a number channels, each of which is associated with a corresponding device, wherein the session defines data generation and data transfer rates, in addition to being a holder of device and channel references,

an assembly, which is a holder for at least one session and controls the start and stop of the data transfer.

According to a third aspect, there is provided a system for converting sensor readings to an output representation. The system is a modular system comprising the following submodules:

an input module configured to read the output of at least one sensor; a data conversion module configured to convert the sensor output in order to obtain a representation suitable for storing and/or processing;

a data storing module configured to optionally store said converted sensor output;

- a processing module configured to collect and process at least part of the converted sensor output, wherein said processing is further configured to read instructions specifying how to process said converted sensor output;

an assembly module or session controlling module configured to control the exchange of data between said submodules according to predefined rules, and to control said processing module by means of instructions in order to obtain a suitably processed output. According to a third aspect, there is provided a computer program for supporting, when executed, probing and/or controlling of a technical system through one or more physical hardware devices interacting with the technical system, and transfer of data between the physical hardware device(s) and a computer system, each physical hardware device having or being associated with physical sensor and/or actuator capabilities. The computer program comprises instructions, which when executed by a processor, cause the processor to:

support collecting and transferring sensor data from the physical hardware devtce(s) for analysis, presentation and/or storage; and/or

- support transferring control signaling to the physical hardware device(s) for acting on the technical system,

wherein a modular framework is implemented for supporting the data transfer between the physical hardware device(s) and the computer system,

wherein the modular framework has a number of different logical modules, arranged in a hierarchical modular relationship, including:

a device representing one of the physical hardware devices,

a channel associated with a device and representing an interaction point with the technical system,

a session representing a holder of a number of devices and a number channels, each of which is associated with a corresponding device, wherein the session defines data generation and data transfer rates, in addition to being a holder of device and channel references,

an assembly, which is a holder for at least one session and controls tiie start and stop of the data transfer.

According to a fourth aspect, there is provided a computer-program product comprising a non-transitory computer-readable medium having stored thereon a computer program of the third aspect.

According to a fifth aspect, there is provided an apparatus for supporting probing and/or controlling of a technical system through one or more physical hardware devices interacting with the technical system, and transfer of data between the physical hardware device(s) and a computer system, each physical hardware device having or being associated with physical sensor and/or actuator capabilities. The apparatus comprises:

a support module for supporting collection and transfer of sensor data from the physical hardware device(s) for analysis, presentation and/or storage, and/or for supporting transfer of control signaling to the physical hardware device(s) for acting on the technical system, and

a framework module for providing a modular framework for supporting the data transfer between the physical hardware device(s) and the computer system, wherein the modular framework has a number of different logical modules, arranged in a hierarchical modular relationship, including:

a device representing one of the physical hardware devices, a channel associated with a device and representing an interaction point with the technical system,

a session representing a holder of a number of devices and a number channels, each of which is associated with a corresponding device, wherein the session defines data generation and data transfer rates, in addition to being a holder of device and channel references,

an assembly, which is a holder for at least one session and controls the start and stop of the data transfer.

In this way, there is provided a standardized means of the whole data transfer process, in e.g., the Research and Development R&D, industry.

Further, there is provided a gain in versatility and robustness through the hierarchal-modular approach. In addition, data transfer implementation using this framework will be quicker and allows for an Application Programming Interface, API, that the industry is striving towards. Other advantages offered by the invention will be appreciated when reading the below description of embodiments of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention, together with further objects and advantages thereof, may best be understood by making reference to the following description taken together with the accompanying drawings, in which: FIG. 1 is a schematic diagram illustrating the modular approach to the data transfer framework.

FIG. 2 is a schematic diagram illustrating an example of a computer connected to a hardware device interacting with a physical reality of interest

FIG. 3 is a schematic diagram illustrating an example of a computer- implementation according to an embodiment.

FIG. 4 is a schematic diagram illustrating an example of a screen dump for a Graphical User Interface (GUI) corresponding to the modular approach of FIG. 1.

FIG. 5 is a schematic flow diagram illustrating an example of a method of probing and/or controlling a technical system. FIG. 6 is a schematic diagram illustrating an example of an overall scenario of a computer system and associated database(s) and devices having sensor(s) and/or actuator(s).

FIG. 7 is a schematic diagram illustrating an example of a modular system for converting sensor readings to an output representation. FIG. 8 is a schematic diagram illustrating an example of an apparatus for supporting probing and/or controlling of a technical system.

DETAILED DESCRIPTION

Throughout the drawings, the same reference numbers are used for similar or corresponding elements.

For a better understanding of the proposed technology, it may be useful to begin with a brief system overview and/or analysis of the technical problem.

In relation to a physical reality represented by a physical or technical system 10, it may be desirable to probe and/or control the technical system (e.g. see FIG. 2), e.g. by collecting and transferring sensor data from the technical system, storing and/or processing the collected sensor data and/or performing data analysis and optional data presentation, and/or generating suitable control signaling for actuators operating on the technical system.

The so-called data transfer generally relates to the process of transferring data between physical hardware device(s) 20 having p or being associated with hysical sensor and/or actuator capabilities and a computer system 30 and may involve i) collecting and transferring sensor data from the hardware device(s) for analysis, presentation and/or storage, and/or ii) transferring control signaling to the hardware device(s) for acting on the technical system 10. The proposed technology may also involve configuration of the devices and especially the data transfer process associated with the devices.

There exist today a plethora of techniques and approaches related to the transfer of data between a device and a computer. In many cases the data transfer is conducted to better understand, monitor and/or control a physical reality using the input and output channels of a hardware device, which is connected to a sensors and actuators. Often a human interaction of the data transfer process is sought and as a result some visualization is often needed. Storage of the data is often conducted, for history and further analysis, The data transferred is often business critical for the interesting party. A careful analysis by the inventor has revealed that the implementation of the data transfer process is not defined in a modular and standardized manner, resulting in various implementer-specific solutions.

According to a first aspect, there is provided a method of probing and/or controlling a technical system by using one or more physical hardware devices interacting with the technical system. The method is based on transferring data between the physical hardware device(s) and a computer system, each physical hardware device having or being associated with physical sensor and/or actuator capabilities.

With reference to the flow diagram of FIG. 5, the method comprises the step S1 of collecting and transferring sensor data from the physical hardware device(s) for analysis, presentation and/or storage; and/or the step S2 of transferring control signaling to the physical hardware device(s) for acting on the technical system. The method further comprises the step S3 of supporting and/or controlling the data transfer between the physical hardware device(s) and the computer system by using a modular framework implemented in the computer system. The modular framework has a number of different logical modules, arranged in a hierarchical modular relationship, including a device representing one of the physical hardware devices, a channel associated with a device and representing an interaction point with the technical system, a session representing a holder of a number of devices and a number channels, each of which is associated with a corresponding device, wherein the session defines data generation and data transfer rates, in addition to being a holder of device and channel references, and an assembly, which is a holder for at least one session and controls the start and stop of the data transfer. Optionally, the logical modules of the modular framework further comprises a database representing a physical storage of data and/or a plot representing a visualization of data belonging to one or more specific channels. The physical storage is sometimes referred to as persistent storage, and may be located on- premise, on-cloud and/or even distributed over more than one server.

By way of example, the method may further comprise configuration of the physical hardware devices and/or the data transfer process associated with the physical hardware devices.

For example, the step of transferring control signaling to the physical hardware device(s) for acting on the technical system may include generating control signaling for actuator(s) operating on the technical system. By way of example, the control signaling for the actuator(s) may be dependent on input (or feedback) from the technical system such as the obtained sensor data. In other words, the proposed technology may define a feedback control system.

As an example, the method may further comprise storing and/or processing the collected sensor data, and/or performing data analysis.

For example, the processing of the collected sensor data and/or the data analysis may be performed on-chip and/or on-computer, and may be defined, e.g. in the channel module. In a particular example, a start process is initiated when all the modules are ready, prompting the modules to work both individually and together according to the hierarchical modular relationship.

Preferably, the assembly is the top module, and the session, device and channel modules are submodules. For example, the submodules, when composed and/or linked together, may form an executable application.

In a particular example, all or a subset of the submodules are configured to read instructions issued by the assembly module.

In the following, a non-limiting example of a modular framework for providing a device-computer data-transfer is presented, as seen in Fig 1. In this example framework we define different modules, such as assembly, database, session, device, channel and plot, of which some may be optional. They relate to each- other as Fig. 1 indicates, where a top-most module forms one or more relationships to sub-modules indicated by arrows. These modules are implemented on the computer-side, e.g., in a desktop application, and will be described below.

A plot is a visualization of data belonging to one or more specific channels. This is the aid for a human in the interaction with the reality, as seen in Fig. 2. A channel is the one-dimensional interaction point to the reality. It is located on the device, and may be both input and output data, and also scaled to whatever the reality describes or what is suited. A device is a physical or technical device such as, or including, an electronical entity, that defines as the end-point to one to infinity number of channels. However, in practice, the number of channels on a device is often very limited, ranging from 1 to below 100. A session is a holder of one to infinite number of devices, and one to infinite number of channels, all of which shall be connected to a corresponding device. In addition to being a holder of device and channel references, the session defines the data generation and data- transfer rates, resulting in the resolution of the experiment, and the perceived level of real-time data for an observer. A database is defined as a long-term physical storage for the data, for further utilization. It describes where and how the data from the sessions shall be stored. And, finally, an assembly is the top-module which is basically a holder for one to infinite sessions and zero to infinite databases. The start and stop of the data-transfer is controlled via an assembly. All of the module to sub-module relationships should be generic in the sense that they are not dependent on the specific sub-module implementation. Stated otherwise, a user could utilize any module combination, as long as the relationship rules above are fulfilled and the hardware requirements are met.

FIG. 4 is a schematic diagram illustrating an example of a screen dump for a Graphical User Interface (GUI) corresponding to the modular approach of FIG. 1.

Expressed slightly different, modules may belong to a class and be of a certain type. The modules relate and connect to each other in what could be described as a hierarchy. An assembly can be considered as the entity being executed, i.e. the application or experiment. An assembly can be coupled to a number of session and optionally also one or more databases. A session is a module that connects a number of channels to a device, and it may specify how often, which device, and what channels to sample for data. Each module may have an ID that identifies the module.

For example, an assembly may combine with other modules to form a recipe for an application representing, e.g. a lab experiment. The assembly module may link sessions and optionally database(s) to form an executable application, e.g. representing an experiment (test, data acquisition, control, trial).

As an example, a session is normally confined in time, and may define how often the channels shall generate data to/from devices and optionally to plots and/or databases. A session couples a device to a number of channels, and may also define how often the device shall be polled for data, i.e. the session rate (different from the I/O rate, which is the sample rate).

By way of example, a device is a physical hardware device. A rationale that channel modules are not directly coupled to device modules is that a device could be performing a lot of different l/O-tasks, and it would not be optimal to define new devices for each of them. For example, a channel may be viewed as a representing discrete data vector, e.g. data related to a sensor such as a temperature sensor.

According to an aspect of the invention, a basic idea is to define a generic module with a base-class and let sub-classes derive from that base-class. This ensures a common set of functions, needed for the modules to form references to each other, amongst other things. A session may be controlled by a software timer, for non-real-time updates to the I/O function and the visualization techniques. The device and computer may communicate via a protocol independent of communication methodology. This protocol should be able to deploy session(s) and channel(s) to the device, start, stop and pause the device and perform the acquiring, queueing and storage of sensor data. The sensor data is transferred to the session where (if configured) it is temporarily stored. The overall process may then include acquiring data, processing data, storing (processed data), selecting (processed) data for visualization, rendering data. Control signalling for the device may be generated, for controlling actuators that operate on the technical system.

By way of example, the proposed technology may involve a number of basic key features followed by some optional features:

FIG. 7 is a schematic diagram illustrating an example of a modular system 200 for converting sensor readings to an output representation.

In a sense, the proposed technology may be regarded as a system 200 for converting sensor readings to an output representation. The system 200 being a modular system comprising the following submodules:

an input module 210 configured to read the output of at least one sensor;

a data conversion module 220 configured to convert the sensor output in order to obtain a representation suitable for storing and/or processing; a data storing module 230 configured to optionally store said converted sensor output;

a processing module 240 configured to collect and process at least part of the converted sensor output, wherein said processing is further configured to read instructions specifying how to process said converted sensor output;

an assembly module 250, also referred to as a session controlling module, configured to control the exchange of data between said submodules according to predefined rules, and to control said processing module by means of instructions in order to obtain a suitably processed output.

For example, the suitably processed output may include any of the following:

- an analysis friendly representation such as a plot, numerical reading(s);

- a control signal for controlling an externally connected actuator for: e.g., feed-back controlled systems, heat regulation, electronically controlled systems etc. As an example, all or a subset of said submodules are configured to read instructions issued by the assembly module or session controlling module.

For example, the assembly module or session controlling module may include an input unit for reading manually input instructions specifying a suitable output representation.

According to another example, the assembly module or session controlling module may be configured to provide a user with suggestions of possible output representations. According to yet another example, the assembly module or session controlling module may be configured to enable collection and/or processing of additional data from e.g. external databases, e.g. in order to provide reference data. According to still another example, the assembly module or session controlling module may be configured to instruct the processing module to collect, in addition to said data comprising at least part of the converted sensor output, additional data and to process said converted sensor output and said additional data according to specific instructions. In other words, the submodules may be designed and/or configured individually and, when composed and/or linked together, they form or construct an executable application.

In addition, submodules may have Its own submodules, which in turn may have its own submodules, in a nested and/or recursive structure.

FIG. 6 is a schematic diagram illustrating an example of an overall scenario of a computer system and associated database(s) and one or more devices having sensor(s) and/or actuator(s).

By way of example, the proposed technology may be implemented as a product for conducting l/O-experiments using a unique combination of hardware, graphs, storage and analytical modules, including one or more of the following features: · A modular approach - easily configurable with the possibility to combine different types of modules to near infinite possibilities.

• Hardware - Cost effective hardware support with the possibility to employ off-the-shelf hardware using unique firmware.

• Firmware - The firmware is based on highly optimized C++ code, with compile-time buffer systems. • Graphs - Sharp beautifully rendered graphs, including 2D-lineplots and 3D- surface plots. Insights - visualize, compare, and perform various data analytics of previously acquired data.

• Scripting language - Possibility to configure and execute the different modules using a simple textfile. Share between users/colleagues, customize run-scripts for robust and repeatable experimental setups, etc.

• Console - Possibility to show engine outputs and execute scripts or commands directly into the engine.

• Multi-user support - Possibility to customize each user to specialize the experience. A shared profile defines a common location of scripts, modules and so forth available to all or selected users.

• Updates - Update the application from our cloud-servers, for more features and enhancements.

• Off-line mode - Possibility to work off-line without internet connection.

Optionally, the product may be downloadable, e.g. from a cloud server via the Internet, and download links and licenses may be obtained from a suitable website. Examples of devices include:

Single-board microcontrollers, and single board computers, capable of controlling transducers such as temperature sensors, and pulse-width modulation actuators, as well communicating with a computer through any standard protocol such as the standard serial RS-232 communication transmission.

Examples of sensors include:

Any type of sensor that may transmit signal(s) to the device through change in its e.g., voltage, current or resistance. The device will convert the signal to an internal digital representation, based on resolution of the converters. Explicit examples include temperature sensors, and photo sensors. Examples of actuators include:

Electronic and pneumatic actuators that the device will control through some control-signal originating from the computer. The actuator is expected to have its own energy-source.

In the following a particular example of a non-limiting technical application will be described. For example, the proposed technology could be used in a scenario where an operator/implementer would like to acquire, let's say 12 different signals (from 12 temperature sensors) and output 2 different signals (where one may be a function of time, and the other may be a function of the average of most recent acquired signals). This system may be connected to two devices, one for controlling the output signals, and acquiring two signals, the other device for acquiring the ten remaining input signals. In addition, the 12 sensors are spatially separated in the x-y-plane or in x-y-z-space. The output signal that is dependent on external data (i.e., as a function of time, in this case), may collect its output data from a server, such as an Hadoop server, prior to queueing to the output buffers of the device. Assuming the experiment is intended to run for an extended period of time such as one or several days using an l/O-rate of 1000 Hz, rendering the to-be-stored data in the big-data realm. Also, it may be of importance mat the operator of this implantation gets feedback in the form data- visualization, both as individual lines as well as a contour-plot of the sensor-data. All communication may be conducted over TCP/IP, but for example with fail-over to USB in-case of network loss. An operator/implementer could define an assembly which includes a database (e.g., a non-SQL database, located on a cloud-server) and a session, defined to have an l/O-rate of 1000 Hz and an acquire/queue rate to the device of e.g., 10 Hz, This is a function of the perceived real-time of the feedback in the form of visualizations, and the buffer capacity on the device. The session is referenced to two devices, and 14 channels (12 inputs and 2 outputs). The 14 channels are all connected to one plot, for overview, and all 12 input channels are connected to another 2D plot (a contour-plot). The channels are then configured for their respective hardware port, signal calibration etc. When all modules are ready, a start process could be initiated, prompting the modules to work both individually and together according to their relationship, as defined above. The proposed technology could provide a framework for managing these requirements presented above, where the module relationships, and the hierarchy extends to encompass many such examples encountered in real-life, without toss of generality, robustness or experiment requirements. For example, adding a plot, off-loading a device to two devices carrying 6 input channels each, etc requires no special programming. It is a matter of defining the modules, and how they should interact. The operator/implementer is free to choose software language, however, an object oriented language is preferred. The user does not need any programming skills, reducing the need for dual skill user (both operator and programmer), and the number of programmed systems (implementations) whose solutions almost invariably differs.

In a particular, non-limiting example, a solution according to the proposed technology is to write the software program, e .g., in Matlab from Mathworks for proven, field-tested and broad analytical and visualization capabilities, as well as a strong object oriented programming language and integrates well with both hardware and platforms (such as Linux and Mac) for cross-platform application. As mentioned, by way of example, our implementation is to define a generic module and let all other subclasses derive from that base-class. This ensures a common set of functions, needed for the modules to form references to each- other, amongst other things. The session may be controlled by a software timer, for non-real-time updates to the i/o function and the visualization techniques. For example, the device software may be written in C or 0++, for speed and memory requirements of often low-memory devices. The device and computer may communicate via a protocol independent of communication methodology. This protocol should be able to deploy session and channel to the device, start, stop and pause the device and performing the acquiring and queueing of data. The data is transferred to the session where (if configured) it is temporarily stored in a binary raw file, using fastest possible read and write speeds.

Hence, once all modules are initiated, a timer-controlled pipeline of the session may thus be defined as follows:

• Acquire the device data.

• Apply transform and scaling to data.

• Queue data from the output sources (some predefined data, e.g., in a file as well as a function of the acquired data).

• Store both input and output data.

• Discriminate which data to be transferred to which plot.

• Render data (this may be done, e.g., via the OpenGL library).

• Exit from the pipeline, and await next timer-induced pipeline call.

If the time to perform the pipeline process exceeds the timer update frequency, we opt to drop the queued timer events, in order to prevent clogging of the process queue. The end-user of our technology will now only have to define a set of configurations (often limited and within the user field of expertise), as well as which (and not how) modules to relate to each-other. This will significantly decrease time to experiment, as well increase solution robustness, in addition, the above mentioned technique will allow the user to extend the application of the transducer-device-computer system, by focusing/concentrating on the interaction with the real-world (often the mission critical part), instead of programming aspects. Further software enhancements will benefit many people. Reinvention of wheel if also lessened. Finally, it is within the proposed technology entirely possible by extending the e.g., device module to allow for external defined device- modules (i.e., to form an API), by requiring the API implementer to obey the proposed technology rules. The proposed technology also works well with applications such as Internet of Things (loT). In loT applications, sensors and actuators blend seamlessly with the environment around us, and the information may be shared across platforms in order to develop a common operating picture.

It will be appreciated that the methods and devices described above can be combined and re-arranged in a variety of ways, and that the methods can be performed by one or more suitably programmed or configured digital signal processors and other known electronic circuits (e.g. discrete logic gates interconnected to perform a specialized function, or application-specific integrated circuits).

Many aspects of this invention are described in terms of sequences of actions that can be performed by, for example, elements of a programmable computer system.

The steps, functions, procedures and/or blocks described above may be implemented in hardware using any conventional technology, such as discrete circuit or integrated circuit technology, including both general-purpose electronic circuitry and application-specific circuitry.

Alternatively, at least some of the steps, functions, procedures and/or blocks described above may be implemented in software for execution by a suitable computer or processing device such as a microprocessor, Digital Signal Processor (DSP) and/or any suitable programmable logic device such as a Field Programmable Gate Array (FPGA) device and a Programmable Logic Controller (PLC) device.

It should also be understood that it may be possible to re-use the general processing capabilities of any device in which the invention is implemented. It may also be possible to re-use existing software, e.g. by reprogramming of the existing software or by adding new software components. It is also possible to provide a solution based on a combination of hardware and software. The actual hardware-software partitioning can be decided by a system designer based on a number of factors including processing speed, cost of implementation and other requirements.

According to an aspect, there is provided a system configured to probe and/or control a technical system by using one or more physical hardware devices interacting with the technical system. The system is configured to transfer data between the physical hardware device(s) and a computer system, each physical hardware device having or being associated with physical sensor and/or actuator capabilities.

The system is configured to collect and transfer sensor data from the physical hardware device(s) for analysis, presentation and/or storage; and/or the system is configured to transfer control signaling to the physical hardware device(s) for acting on the technical system.

The system is further configured to operate based on a modular framework for supporting the data transfer between the physical hardware device(s) and the computer system, wherein the modular framework has a number of different logical modules, arranged in a hierarchical modular relationship, including:

a device representing one of the physical hardware devices, a channel associated with a device and representing an interaction point with the technical system,

a session representing a holder of a number of devices and a number channels, each of which is associated with a corresponding device, wherein the session defines data generation and data transfer rates, in addition to being a holder of device and channel references,

an assembly, which is a holder for at least one session and controls the start and stop of the data transfer. Optionally, the logical modules of the modular framework further comprises a database representing a physical storage of data and/or a plot representing a visualization of data belonging to one or more specific channels. By way of example, the system may be configured to perform configuration of the physical hardware devices and/or the data transfer process associated with the physical hardware devices.

As an example, the system may be configured to generate control signaling for actuator(s) operating on the technical system.

Optionally, the system may be configured to store and/or process the collected sensor data, and/or perform date analysis. For example, the system may be configured to initiate a start process when all the modules are ready, prompting the modules to work both individually and together according to the hierarchical modular relationship.

Preferably, the assembly is the top module, and the session, device and channel modules are submodules.

By way of example, the submodules, when composed and/or linked together, may form an executable application. In a particular example, all or a subset of the submodules may be configured to read instructions issued by the assembly module.

For example, the system may be implemented in the computer system. According to a particular example, the system comprises processing circuitry and memory, the memory comprising a computer program for execution by the processing circuity to perform the functions of the system. FIG. 3 is a schematic diagram illustrating an example of a computer- implementation 100 according to an embodiment. In this particular example, at least some of the steps, functions, procedures, modules and/or blocks described herein are implemented in a computer program 125; 135, which is loaded into the memory 120 for execution by processing circuitry including one or more processors 110. The processors) 110 and memory 120 are interconnected to each other to enable normal software execution. An optional input/output device 140 may also be interconnected to the processor(s) 110 and/or the memory 120 to enable input and/or output of relevant data such as input parameter(s) and/or resulting output parameter(s).

The term 'processor * should be interpreted in a general sense as any system or device capable of executing program code or computer program instructions to perform a particular processing, determining or computing task.

The processing circuitry including one or more processors 110 is thus configured to perform, when executing the computer program 125, well-defined processing tasks such as those described herein. The processing circuitry does not have to be dedicated to only execute the above- described steps, functions, procedure and/or blocks, but may also execute other tasks.

Moreover, this invention can additionally be considered to be embodied entirely within any form of computer-readable storage medium having stored therein an appropriate set of instructions for use by or in connection with an instruction- execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch instructions from a medium and execute the instructions.

The software may be realized as a computer program product, which is normally carried on a non-transitory computer-readable medium, for example a CD, DVD, USB memory, hard drive or any other conventional memory device. The software may thus be loaded into the operating memory of a computer or equivalent processing system for execution by a processor. The computer/processor does not have to be dedicated to only execute the above-described steps, functions, procedure and/or blocks, but may also execute other software tasks.

According to an aspect, there is provided a computer program for supporting, when executed, probing and/or controlling of a technical system through one or more physical hardware devices interacting with the technical system, and transfer of data between the physical hardware device(s) and a computer system, each physical hardware device having or being associated with physical sensor and/or actuator capabilities.

The computer program comprises instructions, which when executed by a processor, cause the processor to:

support collecting and transferring sensor data from the physical hardware device(s) for analysis, presentation and/or storage; and/or

support transferring control signaling to the physical hardware device(s) for acting on the technical system,

wherein a modular framework is implemented for supporting the data transfer between the physical hardware device(s) and the computer system,

wherein the modular framework has a number of different logical modules, arranged in a hierarchical modular relationship, including:

a device representing one of the physical hardware devices,

a channel associated with a device and representing an interaction point with the technical system,

a session representing a holder of a number of devices and a number channels, each of which is associated with a corresponding device, wherein the session defines data generation and data transfer rates, in addition to being a holder of device and channel references, an assembly, which is a holder for at least one session and controls the start and stop of the data transfer.

There is also provided a computer-program product comprising a non-transitory computer-readable medium having stored thereon such a computer program.

The flow diagram or diagrams presented herein may be regarded as a computer flow diagram or diagrams, when performed by one or more processors. A corresponding apparatus may be defined as a group of function modules, where each step performed by the processor corresponds to a function module. In this case, the function modules are implemented as a computer program running on the processor.

The computer program residing in memory may thus be organized as appropriate function modules configured to perform, when executed by the processor, at least part of the steps and/or tasks described herein.

FIG. 8 is a schematic diagram illustrating an example of an apparatus for supporting probing and/or controlling of a technical system.

The apparatus is adapted for supporting probing and/or controlling of a technical system through one or more physical hardware devices interacting with the technical system, and transfer of data between the physical hardware device(s) and a computer system, each physical hardware device having or being associated with physical sensor and/or actuator capabilities. The apparatus 300 comprises:

a support module 310 for supporting collection and transfer of sensor data from the physical hardware device(s) for analysis, presentation and/or storage, and/or for supporting transfer of control signaling to the physical hardware device(s) for acting on the technical system, and

a framework module 320 for providing a modular framework for supporting the data transfer between the physical hardware device(s) and the computer system, wherein the modular framework has a number of different logical modules, arranged in a hierarchical modular relationship, including:

a device representing one of the physical hardware devices, a channel associated with a device and representing an interaction point with the technical system,

a session representing a holder of a number of devices and a number channels, each of which is associated with a corresponding device, wherein the session defines data generation and data transfer rates, in addition to being a holder of device and channel references,

an assembly, which is a holder for at least one session and controls the start and stop of the data transfer.

Alternatively it is possible to realize the modute(s) predominantly by hardware modules, or alternatively by hardware, with suitable interconnections between relevant modules. Particular examples include one or more suitably configured digital signal processors and other known electronic circuits, e.g. discrete logic gates interconnected to perform a specialized function, and/or Application Specific Integrated Circuits (ASICs) as previously mentioned. Other examples of usable hardware include input/output (I/O) circuitry and/or circuitry for receiving and/or sending signals. The extent of software versus hardware is purely implementation selection.

It is becoming increasingly popular to provide computing services (hardware and/or software) where the resources are delivered as a service to remote locations over a network. By way of example, this means that functionality, as described herein, can be distributed or re-located to one or more separate physical nodes or servers. The functionality may be re-located or distributed to one or more jointly acting physical and/or virtual machines that can be positioned in separate physical node(s), i.e. in the so-called cloud. This is sometimes also referred to as cloud computing, which is a model for enabling ubiquitous on- demand network access to a pool of configurable computing resources such as networks, servers, storage, applications and general or customized services.

The embodiments described above are to be understood as a few illustrative examples of the present invention. It will be understood by those skilled in the art that various modifications, combinations and changes may be made to the embodiments without departing from the scope of the present invention. In particular, different part solutions in the different embodiments can be combined in other configurations, where technically possible.