Patent Description:
<CIT> discusses testing a control system which includes a field device located in one area and a controller located in a different area. A remote access to the controller while the mobile device is located at the field device allows a single technician to test the control system by interfacing with the controller and the field device simultaneously. More precisely, in <CIT>a mobile application running on a mobile device is used by a technician to test the control system and to input test results manually.

<CIT> discloses a solution how to evaluate functional safety of a safety pro-gram which is intended to prevent people's safety from being threatened by automatically moving devices such as robots.

The evolvement of networking between computers and measurement devices, especially different sensors, capable of communicating without user involvement, has increased the amount of data collected on industrial automation devices or processes controlled by industrial automation devices, for example for different secure cloud services, such as remote monitoring or optimizing settings. However, different services may require different collected data.

According to an aspect, there is provided the subject matter of the independent claims.

Some embodiments provide adaptiveness to the collected data by using a concept called a test in which an industrial automation device is set to use during a test run another, temporary, set of parameter settings.

In the following, exemplary embodiments will be described in greater detail with reference to accompanying drawings, in which.

The present invention is applicable to any system that comprises one or more industrial sites comprising one or more industrial automation devices, equipment configured to provide remote services to one or more of the industrial automation devices via mobile devices, or via any corresponding device that can locate or locates in an industrial site.

Different embodiments and examples are described below using single units, models, devices (equipment) and data storages (memory), without restricting the embodiments/examples to such a solution. A concept called virtualization may be used. The virtualization may allow a single physical computing device to host one or more instances of virtual machines that appear and operate as independent computing devices, so that a single physical computing device can create, maintain, delete, or otherwise manage virtual machines in a dynamic manner. It is also possible that device operations will be distributed among a plurality of servers, nodes, devices or hosts. In cloud computing network devices, computing devices and/or storage devices provide shared resources. Some other technology advancements, such as Software-Defined Networking (SDN), may cause one or more of the functionalities described below to be migrated to any corresponding abstraction or apparatus or device. Therefore, all words and expressions should be interpreted broadly, and they are intended to illustrate, not to restrict, the embodiment.

A general exemplary architecture of a system is illustrated in <FIG> is a simplified system architecture of a cloud-based deployment scenario only showing some equipment (apparatuses, devices) and functional entities, all being logical units whose implementation and/or number may differ from what is shown in <FIG>. It is apparent to a person skilled in the art that the systems may comprise any number of shown elements and that the systems may also comprise other elements, equipment, functional entities and structures, some of which used in or for big data, data management, and communication in the system or in one part of the system. They, as well as the protocols used, are well known by persons skilled in the art and are irrelevant to the actual invention. Therefore, they need not to be discussed in more detail here.

In the example illustrated in <FIG>, the system <NUM> comprises one or more industrial sites <NUM> (only one illustrated in <FIG>) connected over one or more networks (none shown in <FIG>) to one or more clouds <NUM>, or cloud platforms (only one illustrated in <FIG>).

In the illustrated example of <FIG>, in the industrial site <NUM> there is a mobile device (MD) <NUM> of a remote user and one or more industrial automation devices <NUM> (only one illustrated in the example). It should be appreciated that an industrial site depicts herein any industrial site comprising one or more industrial automation devices <NUM>. A non-limiting list of examples of industrial sites includes power plants, manufacturing plants, chemical processing plants, power transmission systems, mining and mineral processing plants, upstream oil and gas systems, data centers, ships, transportation fleet systems and utility plants.

The mobile device (MD) <NUM> refers to a computing device (equipment), that is a portable device, and it may also be referred to as a mobile terminal, user apparatus, user terminal or user device. Portable computing devices (apparatuses) include wireless mobile communication devices operating with or without a subscriber identification module (SIM) in hardware or in software, including, but not limited to, the following types of devices: mobile phone, smart phone, personal digital assistant (PDA), laptop and/or touch screen computer, tablet (tablet computer), multimedia device, wearable computer and other types of wearable devices, such as clothing and accessories incorporating computer and advanced electronic technologies. The mobile device <NUM> is configured for remote support, for example for configuring (tuning) of industrial automation devices. For that purpose the mobile device <NUM> comprises a remote support application provided by a remote tool <NUM>, the remote tool comprising a test tool for configuring industrial automation devices to perform a test by causing an industrial automation device to install a sub-tool (a sub-program or sub-application, including a set of parameters) called a test, or at least use test parameter values, for example for performance optimization, as will be described in more detail below. It should be appreciated that instead of a test, or test application, or test settings (test parameter values) or test configuration, other terms, for example a temporary application, temporary settings or temporary configuration, may be used.

The industrial automation device <NUM> refers to electronic equipment (device) that is used for controlling one or more industrial processes, devices, or equipment, according to its settings (parameter values) <NUM>. For example, industrial automation devices may control the position, speed, torque and/or direction of electric motors in conveyors, grinders, winders, pumps and/or fans. The industrial automation device may control the speed and/or torque of a motor by changing the frequency, current and/or voltage of the electrical supply to the motor, for example. However, the details of the controlling functionality of the automation device bear no significance and are therefore not described in detail herein. Further, it should be appreciated that the industrial automation device <NUM> depicts herein any device, machine, equipment, system and a process whose operations and/or service and/or maintenance may be taken care remotely. Examples of such industrial automation devices include drives, frequency converters, AC/DC converters, DC/AC converters, programmable logic controllers, switches, motion controllers or motion drives, soft starters, etc. It should be appreciated that in the above only some examples are listed.

In the illustrated example of <FIG>, an industrial automation device <NUM> comprises, as separate components, in addition to the settings <NUM>, a control tool <NUM> and a tool called herein a data logger <NUM>. The control tool <NUM> refers herein to equipment via which parameters and parameter values of the automation device <NUM> may be adjusted or acquired, and the functions of the automation device <NUM> otherwise controlled by the mobile device and/or by a person locating on the site <NUM> and/or remotely from the cloud <NUM> (and/or from a separate service center). The control tool <NUM> may comprise a panel, which may be a separate device, or a device detachable connectable to the automation device, or equipment integrated to the automation device. The data logger <NUM> refers herein to equipment, including different sensors, that measure and collect data according to parameter values in the settings <NUM>. Parameters for the data logger may include a sample interval (sample rate) and/or a buffer size for collected pieces of data (samples) before collected data is transmitted or retrieved, and/or definitions what data to collect, for example.

In the cloud-based deployment, one or more service centers, depicted by a remote user support device <NUM>, provide different remote services using data <NUM> stored into the cloud and performing analytics <NUM> in the cloud. The remote user support device <NUM> comprises user interfaces for user interaction and for remote monitoring and/or remote assistance. In the illustrated example of <FIG>, the data <NUM> stored in the cloud <NUM> comprises at least data collected on the industrial automation device(s). The stored data may comprise also other data, like product data, and/or test configurations, etc. The analysis tools <NUM> in the cloud <NUM> may be based on data mining, self-learning artificial intelligence, mathematical models of an industrial process used, etc. An analysis tool may be a condition monitoring tool configured, for example, to identify in one or more condition parameters changes indicative of a developing fault. Another example of an analysis tool includes a performance optimization tool. The details of implementation, purpose and actual functionality of the analysis tools, and/or how and what data is stored and used and/or how the remote user support device accesses and uses the analysis tools and the data in the cloud, or in any other shared data storage for remote support, are not relevant for the implementations, and therefore they are not described in more detail here. It is obvious for one skilled in the art that any known or future analysis tool and/or access method may be used. Further, implementing the examples described herein using a non-cloud deployment for remote support is a straightforward task for one skilled in the art.

In the illustrated example of <FIG> the mobile device <NUM> has at least two communications interfaces, depicted by <NUM> antennas, one to connectto the cloud <NUM> wirelessly over one or more networks and one to connect to the industrial automation device <NUM> wirelessly over a local connection. It should be appreciated that the user apparatus <NUM> is depicted to include <NUM> antennas only for the sake of clarity. The number of reception and/or transmission antennas, or other communication interfaces, may naturally vary from one to any number according to a current implementation, and the user apparatus type. The local connection may be based on a short-range communication technology. A non-limiting list of examples for short-range communication technologies include Bluetooth communication standards, and other wireless local area network technologies, such as radio frequency technologies including Wi-Fi, ZigBee, near field communication (NFC), radio-frequency identification (RFID), and optical wireless technologies including Li-Fi and other technologies using at least one of visible light spectrum, ultraviolet and infrared radiation. Naturally the local connection may use any mobile wireless technology, such LTE, <NUM>, <NUM> and beyond, or be a wired connection using Ethernet or universal serial bus (USB), for example. The wireless connection to the cloud <NUM> may be provided by any mobile system, such as LTE, <NUM>, <NUM> and beyond, or a combination of a wireless system and a fixed system, like Wi-Fi or Li-Fi providing access to internet, or other wired network, and via the internet, or the other wired network, to the cloud <NUM>. As to the industrial automation device, it may have a connection to the cloud via any mobile system, such as LTE, <NUM>, <NUM> and beyond, or a combination of a wireless system and a fixed system, like Wi-Fi or Li-Fi providing access to internet, or other wired network, and via the internet, or via the other wired network, to the cloud <NUM>. The connection to the cloud <NUM> from the industrial automation device and/or from the mobile device may be a wired connection as well. As a summary, any existing or future communication technology may be used for the connection between the mobile device <NUM> and the industrial automation device, and for any connection from the mobile device and/or from the industrial automation device in the industrial site <NUM> to the cloud <NUM>.

Further, the connections may be secured connections, established according to any known or future security protocol, for example using authentication and passwords and Bluetooth pairing. In the below examples, secured connections are used, without limiting the examples to such a solution.

<FIG> illustrates an example functionality of an industrial automation device, or more precisely its control tool and data logger, when the industrial automation device has a connection, for example a secure connection to a remote tool, or a test tool, running in a mobile device.

Referring to <FIG>, a set of parameter values with an indication of a test are received in step <NUM> from the mobile device. Depending on an implementation, the set of parameter values may comprise values for all parameters in the automation device, or only to one or more parameters whose values are to be amended for the test. The received set of parameter values may comprise one or more new values defining data to be collected. For example, the received set of parameter values may comprise a new value for a sampling interval, i.e. a test sampling interval value. When a start command is received in step <NUM> from the mobile device, existing parameter values, i.e. parameter values in use when the set was received, are backed up in step <NUM>, because the parameter values were received with the indication of a test. Then the industrial automation device is run in step <NUM> using the received parameter values (and test instructions, if any received), or if no parameter value for a parameter was received in the set of parameter value, using an existing parameter value for the parameter. During the test run, data on the test run is logged in step <NUM>. The data may be logged using the test sampling interval value, if received, or using an existing sampling interval value, if no test sampling interval value was received in the set of parameter values. Depending on an implementation or instructions possibly received with the set of parameter values, the data logged on the test run is sent in step <NUM> to the mobile device during the test run, or when the test run has ended. Further, when the test run ends, the existing parameter values are restored in block <NUM> (since the later values were received with the indication of the test).

According to the invention, the indication of a test is a set of instructions causing the backing up, sending data logged to the mobile device and restoring the earlier (called above existing) parameter values, and deleting after that instructions received in the test. In other words, the test is an application that automatically uninstalls after being executed once.

In a non-claimed alternative, the indication of a test may be a flag, or a parameter value indicating the test, and detecting the indication causes the industrial automation device to perform the backing up, sending data logged to the mobile device and restoring the earlier (called above existing) parameter values, and deleting after that instructions that may have been received in the test.

By backing up the parameter values and restoring them after the test has ended, it is ensured that the parameter values are for temporary use only, and will be not used accidentally in normal operation. Thanks to that, during the testing strange settings, for example rotating to a counter-direction, may be used without having risk that the strange settings will be in use after the test ends. Further, since the parameter values are used only temporarily, data sampling value may be set to collect data using millisecond or sub-millisecond resolution (granularity), thereby providing more accurate (detailed) information for effective troubleshooting or parameter optimisation (tuning), whereas the remote monitoring in normal operation condition will be continued using a bigger resolution, which is sufficient for efficient monitoring and causes less processing load and smaller amount of data transmitted to the cloud. Hence, the granularity of the collected data may be set in an adaptive manner. The use of temporary parameter values also allows that the data collected for optimisation or for troubleshooting, or for just testing, may be different than data collected for remote monitoring.

<FIG> illustrates another example functionality of an industrial automation device, or more precisely its control tool and data logger, when the industrial automation device has a secure connection with the mobile device (with the remote tool in the mobile device).

Referring to <FIG>, when one or more parameter values are received in step <NUM> from the mobile device, it is checked in step <NUM> whether the received one or more parameter values are associated with an indication of a test run. If the received parameter values are not associated with the indication of a test (step <NUM>: no), existing parameter values are replaced in step <NUM> by the received parameter values. For example, the received parameter values may relate to commissioning the industrial automation device, or configuring (tuning) its settings.

If the received parameter values are associated with the indication of a test (step <NUM>: yes), existing parameter values are backed up in step <NUM>, and parameters are set in step <NUM> to have the received parameter values. Then it is monitored in step <NUM>, whether a start command is received. If a start command is received (step <NUM>: yes), the test is run in step <NUM> and data collected in step <NUM> according to the parameter values for the test (and test instructions, if any received). The test is run until a stop command is received (step <NUM>) or the test ends (step <NUM>), whichever occurs first. If a stop command is received (step <NUM>: yes) before the test ends, or the test ends (step <NUM>: yes), the test run and data collecting are stopped in step <NUM>, the collected data is sent is step <NUM> to the mobile device, and the parameter values are restored in step <NUM> to be the parameter values backed up in step <NUM>, i.e. to the parameter values that existed prior to the test. Hence, regardless of the reason why the test ends, the test parameter values are replaced (overridden), and the settings comprise earlier, "normal" parameter values.

If no start command is received (step <NUM>: no), in the illustrated example it is assumed that a cancel command, or a corresponding command/instruction, is received, and the process proceeds to step <NUM> to restore parameter values. For example, receiving a new set of parameter values may be interpreted to be a cancel command, causing step <NUM> to be performed before the process proceeds to step <NUM>.

<FIG> illustrates an example functionality of the mobile device, or more precisely the functionality of the remote tool comprising the test tool. In the illustrated example it is further assumed that a first secure connection to an industrial automation device and a second secure connection to a cloud platform has been established.

In the illustrated example, a user input triggering a test for the industrial automation device is a user input requesting a specific test for the industrial automation device. Further, in the illustrated example receiving said user input causes that a request for the specific test for the industrial automation device is sent in step <NUM> to the remote support via the cloud platform without any further user input. When a response to the request is received, the response contains the test, or at least one or more parameter values to be used during the test, depending on the implementation. The received test, or at least the one or more parameter values with an indication of a test, is forwarded in step <NUM> to the industrial automation device. Depending on an implementation, the forwarding may be performed without any user input, or the user of the mobile device may be prompted to accept forwarding of the test, perhaps guided to set parameter values for the test before the test is forwarded to the industrial automation device, as will be described below. Then sending a command to start the test is caused in step <NUM>. Depending on an implementation, the user may be prompted to input a start command, and when the user input is received, step <NUM> is performed, or the start command is received as part of the user input triggering the specific test, or accepting forwarding the test.

When data collected during the test is received in step <NUM>, the received collected data is forwarded in step <NUM> to the cloud without any user involvement.

Further, depending on an implementation, different results illustrating the collected data may be displayed on a user interface of the mobile device.

By obtaining a test from the cloud, it is ensured that an up-to-date test for the specific purpose is run. Further, the amount of specific purpose tests may be huge, thereby allowing very tailored tests with fit-to-purpose granularity of data collected.

<FIG> illustrates an example of information exchange and different functionalities. In the illustrated example, a drive represents an industrial automation device, an UE (user equipment) illustrates a mobile device comprising the remote tool, and an SC illustrates a cloud with a remote service center.

Referring to <FIG>, a user input starting the remote tool is detected in step <NUM>-<NUM>, the remote tool is started and a connection establishment (messages <NUM>-<NUM>) to the drive is caused. Then a user input starting a specific test is detected in step <NUM>-<NUM>. For example, the user may have selected one of the tests displayed in a user interface of the UE, as part of the test tool comprised in the remote tool. For example, the user may have selected "Oscillation damping optimization". Selecting the specific test causes in this example that current parameter values of the drive are obtained (messages <NUM>-<NUM>). In the illustrated example, the specific test contains information that guides in step <NUM>-<NUM> to input parameter values for the test, for example by searching, parameter per parameter those parameters whose values are to be changed, displaying the parameter with its current value, for example as highlighted, and then providing instructions what the value should be. Some of the parameter values, for example one or more parameter values defining data to be collected, may be preset. Hence, setting the test parameter values does not depend on the user's level of expertise or subjective preferences. For example, for the oscillation damping optimization, the user may be prompted to input either a speed error or a DC voltage to be a value for a parameter "oscillation source", to set a parameter "oscillation compensation" to be off, to change a parameter "speed reference" to <NUM> % of the drive's maximum speed, to change a parameter "sample interval" to be <NUM> milliseconds, and to change a parameter "buffer size" to be bigger than a result obtained by dividing a sum of an acceleration time and a deceleration time by the sample interval. However, in some implementation the buffer size may be automatically updated, using the above formula and parameter values, for example. Further, in the illustrated example, the test includes an instruction "once the speed indicated by the speed reference has been reached, use zero as a speed reference". Then the user may be prompted that parameter values for the test are set, and the user is provided with a possibility to command the drive to install the test. In the example it is assumed that a user input to command to install the test to the drive is received in step <NUM>-<NUM>, and the test is sent in message <NUM>-<NUM> to the drive. Further, since the testis installed, in the illustrated example, it also causes that a connection (message <NUM>-<NUM>) to the cloud SC is established. Naturally, the connection may have been established earlier, for example after step <NUM>-<NUM>, or later, after step <NUM>-<NUM>.

When receiving the test (the set of parameters and the instructions/the indication), the drive installs in point <NUM>-<NUM> the test. The installing may include backing up the existing parameter values and temporarily setting the test parameter values to be in use.

Then a user input to start the test is received in step <NUM>-<NUM> in the UE, and corresponding command is sent (message <NUM>-<NUM>) to the drive, causing starting in step <NUM>-<NUM> the drive and running it according to test parameter values (and test instructions, if any received) so that in the illustrated example the motor will reach the indicated top speed. Meanwhile also data is collected in step <NUM>-<NUM>. If not performed during installing, the test may be started by backing up the existing parameter values and temporarily setting the test parameter values to be in use.

In the illustrated example something unexpected happens and the user of the UE wants to stop the test run. A corresponding user input is received and detected in step <NUM>-<NUM>, and a command to stop is sent (message <NUM>-<NUM>) to the drive. Hence, having the user in the site in control of the test run increases safety, since the user may stop the test run at any time.

In response to the command, in step <NUM>-<NUM> the drive stops, restores the earlier parameters, as described with <FIG> and <FIG>, the restoring including deleting the instruction received with the test. The drive also sends (message <NUM>-<NUM>) data collected during the test to the UE.

The UE forwards (message <NUM>-<NUM>) the data collected during the test to the cloud SC. Further, in the illustrated example, a user input stopping the test also triggers that a support request is sent to the remote service center in the cloud SC. A support person in the remote service center may use in step <NUM>-<NUM> one or more analysis tools and the data collected to find out, if any of the parameter values in the test caused problems. In the illustrated example, the support person updates in step <NUM>-<NUM> the parameter values for the test correspondingly, and sends an updated test (message <NUM>-<NUM>) to the UE.

The user is prompted that an updated test is available and the test may be reinstalled and start. In the illustrated example a combined input to reinstall and start is received in step <NUM>-<NUM>. Hence, the updated test is sent (message <NUM>-<NUM>) to the drive, as if it were the first test.

When receiving the test, the drive installs in point <NUM>-<NUM> the test, in a similar way as in step <NUM>-<NUM>.

The command to start the test is sent (message <NUM>-<NUM>) separately to the drive, and the drive will be started to run, in step <NUM>-<NUM>, after installing the test, so that in the illustrated example the motor will reach the indicated top speed. Meanwhile also data is collected in step <NUM>-<NUM> until the drive stops (the test has been run). Then, in step <NUM>-<NUM>, the parameter values are restored, as described with <FIG> and <FIG>, the restoring including deleting any instruction received with the test. The drive also sends (message <NUM>-<NUM>) data collected during the test to the UE.

The UE forwards (message <NUM>-<NUM>) the data collected during the test to the cloud SC. Further, in the illustrated example, a user input requesting support is detected in step <NUM>-<NUM>, and a request for support is sent (message <NUM>-<NUM>) to the remote service center in the cloud SC. A support person (the same or different than the one in step <NUM>-<NUM>) then uses in step <NUM>-<NUM> one or more analysis tools and the data collected to optimize the parameter settings of the drive. Then an optimized set of parameter values is sent (message <NUM>-<NUM>) to the UE. Then the drive is configured (tuned to have optimal parameter values) by updating (step <NUM>-<NUM>) its parameter values, possibly other settings, by the remote tool. For example, the user of the UE may be prompted to approve the parameter values, which, after user input approving them, are forwarded to the drive, which then replaces existing parameter values, and possible other settings, with the values.

It should be appreciated that in step <NUM>-<NUM>, the test may be once again updated, then installed via the UE, test run performed, etc. until the support person decides that test results are good enough to figure out optimal parameter values.

<FIG> illustrates another example of information exchange and different functionalities. In the illustrated example, a drive represents an industrial automation device, an UE (user equipment) illustrates a mobile device comprising the remote tool, and SC illustrates a cloud with a remote service center.

Referring to <FIG>, a user input starting the remote tool is detected in step <NUM>-<NUM>, the remote tool is started and a connection establishment (messages <NUM>-<NUM>) to the drive is caused and a connection establishment (messages <NUM>-<NUM>) to the cloud SC is caused. Then a user input starting a test is detected in step <NUM>-<NUM>. For example, the user may have selected a specific test, one of the tests displayed in a user interface of the UE, as part of the test tool comprised in the remote tool, or just a test without indicating the type of test. Selecting the test causes in this example that current parameter values of the drive are obtained (messages <NUM>-<NUM>), and in the illustrated example the obtained parameter values are transmitted, together with a support request for a test to the remote service center in the cloud SC. A support person in the remote service center may use in step <NUM>-<NUM> one or more analysis tools, data collected earlier, and the received parameter values to set in step <NUM>-<NUM> parameter values for the test, and sends the parameter values for the test (message <NUM>-<NUM>) to the UE. If the support request (message <NUM>-<NUM>) did not indicate a specific test, the support person also determines which test to run.

Then the user of the UE may be prompted that parameter values for the test are received, and the user is provided with a possibility to command the drive to install the test. In the example it is assumed that a user input to install the test to the drive is received in step <NUM>-<NUM>, and the test is sent in message <NUM>-<NUM> to the drive. For example, the test may be, represented as a combination of parameter settings and instructions: "Run <NUM> seconds with half speed, then change the speed to maximum speed and run <NUM> seconds using the maximum speed. Then stop and send data collected during the test. Collect data every half second. " According to the invention, the UE may add instructions to back up, restore and delete instructions to the test before sending the test to the drive.

When receiving the test (the set of parameters, an indication of the test and possibly one or more instructions), the drive detects in point <NUM>-<NUM> the indication of the test, backs up the existing parameter values and sets the test parameter values to be in use temporarily. (It should be appreciated that in another implementation this may be performed after a command to start is received.

Then a user input to start the test is received in step <NUM>-<NUM> in the UE, and corresponding command is sent (message <NUM>-<NUM>) to the drive, causing starting in step <NUM>-<NUM> the drive to start and run according to the test parameter values and possible instructions. Meanwhile also data is collected in step <NUM>-<NUM> until the drive stops (the test has been run). Then, in step <NUM>-<NUM>, the parameter values are restored, as described with <FIG> and <FIG>, the restoring including deleting possible instructions received with the test. The drive also sends (message <NUM>-<NUM>) data collected during the test to the UE.

The UE forwards (message <NUM>-<NUM>) the data collected during the test to the cloud SC. Further, in the illustrated example, based on receiving the data collected, the UE detects in step <NUM>-<NUM> that the test has ended and displays in step <NUM>-<NUM> information that the test has ended to the user of the UE so that the user may decide how to continue.

It should be appreciated that in another implementation, instead of messages <NUM>-<NUM>, <NUM>-<NUM> and step <NUM>-<NUM>, the test tool in the remote tool in the UE is configured to obtain/retrieve a specific test from the cloud.

It should be appreciated that also in the example of <FIG>, the user of the UE may at any time the test is running, command the drive to stop.

As is evident from the examples, having a user on the site, giving the test related commands and settings to the drive, increases security of the test runs. Further, a drive cannot be commanded to run a test without a user input received in a mobile device that would provide the drive to run the test.

The steps, information exchange, and related functions described above in <FIG> are in no absolute chronological order, and some of the steps/information exchange/related functions may be performed simultaneously or in an order differing from the given one. For example, a connection establishment may happen earlier or later than what is described in an example above. Other functions can also be executed between the steps or within the steps, and other information can be exchanged. Some of the steps or part of the steps or some of information exchange can also be left out or replaced by a corresponding step or part of the step or information exchange. Further, the described processes, information exchange and steps within processes, may run in parallel, and features from one process (functionality) may be combined to another process (functionality).

The techniques and methods described herein may be implemented by various means so that an apparatus/equipment/a device configured to provide the test tool, or to perform a test run according to at least partly on what is disclosed above with any of <FIG>, including implementing one or more functions/operations of a corresponding apparatus/tool described above with an embodiment/example, for example by means of any of <FIG>, comprises not only prior art means, but also means for implementing the one or more functions/operations of a corresponding functionality described with an embodiment/example, for example by means of any of <FIG>, and the apparatus may comprise separate means for each separate function/operation, or means may be configured to perform two or more functions/operations. Apparatuses (devices, equipments) may generally include one or more processors, controllers, control units, micro-controllers, or the like connected to one or more memories and to various interfaces of the apparatus/equipment, configured to implement the test tool or the test run. For example, one or more of the means and/or any tool described above may be implemented in hardware (one or more devices), firmware (one or more devices), software (one or more modules), or combinations thereof.

<FIG> is a simplified block diagram illustrating some units for an apparatus <NUM> configured to provide the functionality described above with <FIG> with the terminal device or the UE, or a corresponding computing device, comprising at least the remote tool with the test tool, or an apparatus <NUM> comprising some of the corresponding functionality if functionalities are distributed in the future.

Referring to <FIG>, the apparatus <NUM> comprises one or more interfaces (IF) <NUM> for retrieving (obtaining) data from industrial automation devices and from one or more clouds, or from different shared databases and for receiving and/or transmitting information from or to industrial automation devices and remote service centers, including different human-machine interfaces. The apparatus further comprises one or more user interfaces (U-IF) <NUM>' for user interaction. The apparatus <NUM> further comprises one or more processors <NUM> configured to implement the functionality of the terminal device, or the UE, or a corresponding computing device, described above with <FIG> and <FIG>, or at least part of corresponding functionality as a sub-unit functionality if a distributed scenario is implemented, with corresponding algorithms <NUM>, and one or more memories <NUM> usable for storing a computer program code required for the functionality of the apparatus, including the test tool, or a corresponding computing device/equipment, i.e. the algorithms for implementing the functionality. The memory <NUM> is also usable for storing other information, such as information for establishing secure connections.

<FIG> is a simplified block diagram illustrating some units for an apparatus <NUM> configured to provide the industrial automation device, or a corresponding computing device, configured to process parameter sets with indication of a test as described above with <FIG>, or an apparatus <NUM> comprising some of the corresponding functionality if functionalities are distributed in the future.

Referring to <FIG>, the apparatus <NUM> comprises one or more interfaces (IF) <NUM> for for receiving and/or transmitting information, including parameter values, from or to other apparatuses, including different human-machine interfaces. The apparatus <NUM> further comprises one or more processors <NUM> configured to implement the functionality of the industrial automation device or the drive, or a corresponding computing device, described above with <FIG>, <FIG> and <FIG>, or at least part of corresponding functionality as a sub-unit functionality if a distributed scenario is implemented, with corresponding algorithms <NUM>, and one or more memories <NUM> usable for storing a computer program code required for the functionality of the apparatus, or a corresponding computing device/equipment, i.e. the algorithms for implementing the functionality. The memory <NUM> is also usable for storing (backing up) parameter values, for temporarily storing test parameter values, possible test instructions, collected data (or buffers for the collected data), and other information.

Generally a processor <NUM>, <NUM> is a central processing unit, but the processor may be an additional operation processor. Each or some or one of tools and/or algorithms described herein may be configured as a computer or a processor, or a microprocessor, such as a single-chip computer element, or as a chipset, including at least a memory for providing storage area used for arithmetic operation and an operation processor for executing the arithmetic operation. The one or more processors may comprise one or more computer processors, application-specific integrated circuits (ASIC), digital signal processors (DSP), digital signal processing devices (DSPD), programmable logic devices (PLD), field-programmable gate arrays (FPGA), graphics processing units (GPUs), logic gates and/or other hardware components that have been programmed and/or will be programmed by downloading computer program code (one or more algorithms) in such a way to carry out one or more functions of one or more embodiments/implementations/examples. An embodiment provides a computer program embodied on any client-readable distribution/data storage medium or memory unit(s) or article(s) of manufacture, comprising program instructions executable by one or more processors/computers, which instructions, when loaded into an apparatus/device, constitute the test tool, or the remote tool, or the control tool or the data logger tool. Programs, also called program products, including software routines, program snippets constituting "program libraries", applets and macros, can be stored in any medium and may be downloaded into an apparatus. In other words, each or some or one of the tools and/or the algorithms described above may be an element that comprises one or more arithmetic logic units, a number of special registers and control circuits.

Claim 1:
A computer-implemented method for a mobile device, the method comprising:
running (<NUM>-<NUM>) in the mobile device a remote tool for remote support for industrial automation devices;
establishing (<NUM>-<NUM>, <NUM>-<NUM>), by the mobile device, using the remote tool, a first connection to an industrial automation device and a second connection to a shared data storage;
detecting (<NUM>-<NUM>) in the remote tool a user input triggering a test for the industrial automation device;
causing sending (<NUM>-<NUM>) via the first connection, from the mobile device, at least a set of parameter values with an indication of the test to the industrial automation device
the indication of the test being a set of instructions comprising at least instructions to back up existing parameters before the test is run and to restore the existing parameter after the test ends;
receiving (<NUM>-<NUM>) in the mobile device a user input to start the test;
causing sending (<NUM>-<NUM>), from the mobile device, via the first connection, a command to start to run the test to the industrial automation device;
receiving (<NUM>-<NUM>) in the mobile device data from the industrial automation device via the first connection; and
forwarding (<NUM>-<NUM>) by the mobile device the data to the shared data storage via the second connection.