Patent Description:
<CIT> discloses how to use cloud to collect data from or transmit data to an industrial automation node via a gateway comprised in the industrial automation node. The industrial automation node further comprises one or more industrial automation devices, coupled to the gateway.

After being manufactured, an industrial automation device may be shipped to a warehouse, stay on the warehouse some time and then be delivered to an industrial plant. To update the industrial automation device, for example with one or more bug fixes and/or with one or more industrial plant -specific features, during that time one may have to unpack the industrial automation device, connect the industrial automation to electrical network or power, update the industrial automation device via a control board, for example, disconnect the industrial automation device from the electrical network and repack the industrial automation device. It may be that the updating process takes place more than once. Another commonly used way to update the industrial automation device is to collect features that are to be updated to one or more memory sticks that are sent to the industrial plant for updating the industrial automation device during start up. An example how a memory stick may be used is described in Siemens "Description of the firmware update for failsafe S7-<NUM> I/O modules", in offline firmware update using a SIMATIC memory card. There is a need for an easier way to update the industrial automation devices.

The invention relates to an industrial automation device, a method, and a system, which are characterized by what is stated in the independent claims.

A general aspect introduces a solution to update features in an industrial automation device via electronic part -powered means comprised in the industrial automation device, said means being configured to connect to a low-power wide area wireless network.

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

Furthermore, words "comprising" and "including" should be understood as not limiting the described embodiments/examples to consist of only those features that have been mentioned and such embodiments may contain also features/structures that have not been specifically mentioned.

The present invention is applicable to any industrial automation device whose features can be updated.

An extremely general architecture of an exemplary system <NUM> is illustrated in <FIG> is a simplified system architecture only showing some elements, functional entities, which are logical units whose implementation may differ from what is shown, and some equipment. It is apparent to a person skilled in the art that the system comprises any number of shown elements, other equipment, and structures that are not illustrated.

In the embodiment illustrated in <FIG>, the system <NUM> comprises one or more industrial automation devices <NUM> (only one illustrated in <FIG>), a low-power wide area network <NUM> (LP-WAN), a central server <NUM> and one or more clouds <NUM> (only one illustrated in <FIG>) comprising a cloud storage <NUM>.

The industrial automation device <NUM>, or shortly automation device, refers to electronic equipment that is used for controlling one or more industrial processes having one or more downstream devices. 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. An 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. A non-limiting list of examples of industrial automation devices includes drives, frequency converters, AC/DC converters, DC/AC converters, DC/DC converters, programmable logic controllers, switches, motion controllers or motion drives, servo motors, soft starters, wind turbines, integral motors and solar inverters.

The industrial automation device <NUM> comprises one or more electronic part -powered means <NUM>. An electronic part -powered means may be a self-powered low consumption unit, or any other type of LP-WAN communication part in the industrial automation device. Below the term "self-powered low consumption unit" is used as a synonym to electronic part -powered means, i.e. to cover all possible types of electronic part -powered means. The self-powered low consumption unit <NUM> may be an end device, for example a sensor (sensor device), or a corresponding endpoint in the low-power wide area network <NUM>, the endpoint comprising, for example, at least a chipset and a receiver/transceiver.

The self-powered low consumption unit comprises one or more electronic parts <NUM>-<NUM> (el. part) for providing the self-powered low consumption unit <NUM> with power. An electronic part <NUM>-<NUM> may be arranged to accommodate one or more batteries and/or one or more capacitors, for example supercapacitors, to power the self-powered low consumption unit, especially to enable the self-powered low consumption unit to function even when the industrial automation device is not switched on and the powered. Hence, the self-powered low consumption unit may be called a battery-powered unit or a (super)capacitor-powered unit. The self-powered low consumption unit <NUM> further comprises an interface (IF1) <NUM>-<NUM> via which the self-powered low consumption unit <NUM> is configured to communicate over a wireless connection <NUM>-<NUM> with the low-power wide area network <NUM> at least to receive small amounts of data using a low-power wide area network protocol.

The self-powered low consumption unit <NUM> also comprises a memory <NUM>-<NUM> for storing at least data received over the wireless connection <NUM>-<NUM>. Examples of the data received will be given below. Depending on an implementation, the memory <NUM>-<NUM> may also store data to be transmitted over the wireless connection <NUM>-<NUM>. The self-powered low consumption unit <NUM> has identification information, for example an identifier, called herein a unit identifier u-id, identifying the self-powered low consumption unit <NUM> uniquely in the low-power wide area network <NUM>. The unit identifier may be stored to the memory <NUM>-<NUM> and used in data transmission in the low-power wide area network, for example to indicate a recipient, when the data is addressed (targeted) to the self-powered low consumption unit <NUM>. The memory <NUM>-<NUM> may also store information, for example address information, or identification information, that can be used to communicate with the central server. Depending on an implementation, the memory <NUM>-<NUM> in the self-powered low consumption unit <NUM> may further store information identifying the industrial automation device and/or one or more keys for decrypting data received and/or encrypting data to be transmitted.

The self-powered low consumption unit <NUM> may be, and/or comprise, or be comprised in, or connected to, means detecting changes in the self-powered low consumption unit <NUM> or in the industrial automation device <NUM> or in environment, and may be configured to receive and/or fetch and/or store to the memory <NUM>-<NUM> and/or report the changes, for example by transmitting corresponding data over the wireless connection <NUM>-<NUM>. A non-limiting list of changes include location (geographical position), determined by a global positioning system unit or device, temperature, sensed for example by the self-powered low consumption unit or a temperature sensor, humidity, sensed for example by the self-powered low consumption unit or a humidity sensor, and vibration sensed for example by the self-powered low consumption unit or a vibration sensor. When a separate sensor, unit or device is used and the self-powered low consumption unit <NUM> is configured to fetch the change (sensed information), the memory <NUM>-<NUM> may comprise information indicating how or wherefrom to fetch the change (sensed information).

The industrial automation device <NUM> further comprises a control unit <NUM> configured to control operation of the industrial automation device. The control unit <NUM> further provides means for updating features in the industrial automation device <NUM>, for example as will be described in detail below. In other words, the control unit <NUM> is configured to update features using data in the self-powered low consumption unit, or more precisely in its memory <NUM>-<NUM>. For that purpose, the control unit <NUM> is connected via an interface <NUM>-<NUM> to the self-powered low consumption unit <NUM>. The interface <NUM>-<NUM> may be a serial peripheral interface (SPI) or a universal asynchronous receiver-transmitter (UART) interface, for example. The control unit <NUM> may be configured to communicate, when the industrial automation device <NUM> is connected to an electric network, and power being switch on, via one or more modules <NUM>, with the cloud over a connection <NUM>-<NUM> either directly or via a local connection at an industrial site or at a manufacturing site, for example. The control unit may be implemented using software and/or hardware and/or firmware components, for example by one or more processors, microprocessors or chipsets, programmed to provide the means for updating the features.

The module <NUM> may provide at least one wireless interface via which module <NUM> features and parameters of the industrial automation device <NUM> in the memory <NUM> may be adjusted or acquired via the control unit, when power is on in the industrial automation device <NUM>, and the functions of the industrial automation device <NUM> otherwise controlled by a person locating on the site and/or remotely from a service center (not illustrated separately in <FIG>) in the cloud <NUM>. The module <NUM> may be a separate device (terminal device), or a device detachable connectable to the industrial automation device, or equipment integrated to the industrial automation device. At the simplest, the module may be a mere interface.

Further, the industrial automation device <NUM> comprises one or more memories, depicted by one memory <NUM> in <FIG>, in which features, or a list of features, including values and/or content for features are stored, to be used for example when the industrial automation device is running. It should be appreciated that term "feature" covers herein also feature versions (feature variants). A non-limiting list of examples of features that may be stored include parameters, parameter values (parameter settings), software and parameters to configure different products including different power range ratings, one or more software modules, for example original equipment manufacturer (OEM) firmware software modules, software versions, one or more configurations, one or more licenses and/or license keys required for application(s), or for add-ons to application(s), or for software module(s), to run, applications and add-ons to applications (with different versions, if two or more different versions exits), bug fixes to applications and software bug fixes. A configuration means herein one set of parameters/parameter values defining an application or an application scenario. (One application may have different application scenarios resulting that said application have different behaviour. ) Further, there may be features that are common for industrial automation devices, or to industrial automation devices of the same type as the industrial automation device <NUM>, and features tailored for example for the industrial site, for example language version selected based on location of the site, or site type, or are device-specific, such as a code required to establish the local connection or the connection <NUM>-<NUM> to the industrial automation device in question. The memory <NUM> may also comprise other information, such as the information identifying the industrial automation device <NUM>, for example a device identifier, device-id, and/or one or more keys for decrypting or encrypting, wherein a key or some of the keys may be the same as those in the memory <NUM>-<NUM> in the self-powered low consumption unit and/or the information identifying the self-powered low consumption unit and/or one or more functional safety criteria, examples of which will be given below. The memory <NUM> may also comprise the unit identifier (per a self-powered low consumption unit if the industrial automation device <NUM> comprises more than one self-powered low consumption units) and/or information identifying the central server <NUM>.

The industrial automation device <NUM> further comprises means <NUM> (el. n), for example one or more power supplies, for connecting the industrial automation device <NUM> to the electric network to power the industrial automation device when switched on.

The low-power wide area network <NUM> may comprise one or more sub-networks (not illustrated in <FIG>), and it may be a decentralized network formed by different apparatuses, an apparatus functioning as a gateway, or an access node, or a base station or a router or a hotspot in the low-power wide area network. Such an apparatus provides to the self-powered low consumption unit <NUM> the wireless connection <NUM>-<NUM> and access to the internet and via the internet to the central server <NUM>, using a corresponding low-power wide area network protocol. Such a protocol is preferably designed to facilitate low power data transmission and reception, i.e. to carry small amounts of data, so that battery-powered sensors, for example, can function for several years. The apparatus providing access and/or the self-powered low consumption unit <NUM> may be an Internet of Thing apparatus, and the low-power wide area network <NUM> may be called an Internet of Things network.

The low-power wide area network <NUM> may be a long-range low-power wide area network, for example the Helium network. The Helium network is a blockchain based decentralized network of nodes called hotspots. In the Helium network a hotspot is a combination of a wireless gateway and a blockchain mining device. Internet of Things devices, or corresponding low powered wireless devices, for example the self-powered low consumption unit <NUM> as an end-device in the Helium network, may send or receive data across the Helium network via the wireless gateways using LoRaWAN® protocol for communications. Further examples of low-power wide area networks include SigFox, Loriot, MachineQ, Senet, to name a few. Another example of a protocol that can be used for communications in the low-power wide area network is MQTT-SN (MQTT for sensor networks) protocol, which is a lightweight, publish-subscribe network protocol that transports messages between devices, over a wired or wireless connection.

The central server <NUM> may be implemented as a centralized or decentralized server in the low-power area network. The central server <NUM> may be configured to determine an optimal data rate and transmit power to transmit (send down) data to the self-powered low consumption unit <NUM> over the low-power area network. The central server <NUM> has in the low-power area network an organizationally unique identifier, or corresponding identifying information, so that transmissions can be routed to the central server in the low-power area network. The organizationally unique identifier may identify the manufacturer of the industrial automation device <NUM>. The central server <NUM> may be a MQTT message broker, or a network server on the Helium, for example, that may be under control of the manufacturer, or more precisely under control of or comprised in a cloud server of the manufacturer, or any other organization responsible for features to be updated in the industrial automation device. Hence, in the illustrated example, the central server <NUM> is further arranged to have access to the cloud storage <NUM>. Further, it should be appreciated that even though in <FIG> there is one central server <NUM>, one organization may have more than one central server.

In the illustrated example, the cloud storage <NUM> comprises at least information associating the industrial automation device with its self-powered low consumption unit, for example associating the device identifier device-id with the unit identifier u-id. Further the cloud storage may associate the industrial automation device with features installed to the industrial automation device and/or features to be updated/installed to the industrial automation device and/or features that are being currently updated as data transmitted to the self-powered low consumption unit <NUM>. For example, the cloud storage may comprise information of software version and original equipment manufacturer (OEM) software modules, if any installed, and configurations. Naturally the cloud storage <NUM> may comprise other information, for example key information for encrypting/decrypting transmissions.

The cloud <NUM> providing the cloud storage <NUM> may be a private cloud (operated solely for an organization), a community cloud (operated for organizations sharing e.g. mission and security requirements), a public cloud (provider sells cloud services) or a hybrid cloud, i.e. a composition of two or more different clouds. Examples of public cloud providers include Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure, etc..

The details how to establish the connection <NUM>-<NUM> between the industrial automation device <NUM> (module <NUM>) and the cloud, and protocols used for the connection <NUM>-<NUM> bear no significance to the described examples and hence are not described in detail herein.

The details of low-power wide area networks, the central server, clouds and cloud storages, are well known by persons skilled in the art and are, as such, irrelevant to the examples. Therefore, there is no need to describe them in more detail here.

<FIG> describe example functionalities of the self-powered low consumption unit. In the examples it is assumed that LoRaWAN® protocol is used and that the self-powered low consumption unit is an end-device of class A, class B or class C, without limiting the examples of such solutions. In class A, an end-device's uplink transmission is followed by two short downlink receive windows. In class B, the end-device opens extra receive windows at scheduled times. For that the end-device receives a time-synchronized beacon from the gateway (hotspot). This allows the central server to know when the end-device is listening. Class C allows nearly continuously open receive windows which may be closed only when the end-device is transmitting. The details of transmissions and receptions, including encrypting and decrypting data if encrypting and decrypting are used in transmissions, are well known and hence are not described in more detail herein. Further, implementing the examples to other low-power long range network protocols is straightforward for a person skilled in the art.

Referring to <FIG>, the self-powered low consumption unit detects in step <NUM> that a receive window is open, receives in step <NUM> data addressed to the self-powered low consumption unit (to the end-device), and stores in step <NUM> the data. The data may be stored with time information indicating a time when it is stored or received.

Hence, updates to features can be delivered to the industrial automation device when it is in a warehouse or being transported to its final place. For example, during transportation of the industrial automation device tailored features may be delivered to the industrial automation device.

In the example of <FIG>, the self-powered low consumption unit is further configured to report a change or changes to the central server, as described above with <FIG>. When the self-powered low consumption unit detects in step <NUM> that there is data, i.e. the change or changes, to be transmitted to the central server, the self-powered low consumption unit request and obtains in step <NUM> a transmission slot for the data, and transmits in step <NUM> the data in the transmission slot. This enables collecting feedback on the industrial automation device.

<FIG>, <FIG> describe example functionalities of the industrial automation device, or more precisely, example functionalities of the control unit, or corresponding means for updating.

Referring to <FIG>, when it is detected in step <NUM> that power is switched on (the industrial automation device has been connected to power or electric network), data is retrieved in step <NUM> from the memory of the self-powered low consumption unit, and features are updated in step <NUM> with the data retrieved. For example, license keys may be updated. Hence, less time is required at site to finalize the industrial automation device for intended use during start up/commissioning.

In the example of <FIG>, it is assumed that some updates may be received via the self-powered low consumption unit even after the start-up process described in <FIG>. Further, as a background process, not described in <FIG>, time information indicating the last data retrieval time is maintained.

Referring to <FIG>, when it is detected in step <NUM> that power is switched on (the industrial automation device has been connected to power or electric network), data that the self-powered low consumption unit has received after previous retrieval of data is retrieved in step <NUM> from the memory of the self-powered low consumption unit.

Then it is checked in step <NUM>, whether any data was retrieved in step <NUM>. If data was retrieved (step <NUM>: yes), features are updated in step <NUM> with the data retrieved, and the process continues to step <NUM> to monitor, whether a preset time after step <NUM> has lapsed or the power is switched off (step <NUM>).

If no data was retrieved (step <NUM>: no), the self-powered low consumption unit had not received any new data, and the process monitors, whether a preset time after step <NUM> has lapsed (step <NUM>) or the power is switched off (step <NUM>).

When the time has lapsed (step <NUM>: yes), the process returns to step <NUM> to retrieve data the self-powered low consumption unit has received after previous retrieval of data.

When the power is switched off, the process starts again in step <NUM> when the power is switched on.

<FIG> describes an example functionality that may be performed after data has been retrieved from the self-powered low consumption unit (or more precisely, from its memory) to ensure that one or more safety criteria relating to updates and/or a feature to be updated is met (fulfilled) before performing the updating. The safety criteria may relate to cybersecurity and/or to functional safety update requirements. For example, most of the industrial automation devices include safe torque off (STO) function. A non-limiting list of examples of other safety functions that an industrial automation device may comprise include safe stop <NUM> (SS1), safe stop emergency (SSE), safe brake control (SBC), safely-limited speed (SLS), safe maximum speed (SMS) and prevention of unexpected startup (POUS). The safety function and criteria relating to functional safety update requirements are known by one skilled in the art, details of them are not relevant to the disclosed example functionality, and hence there is no need to describe them in more detail herein.

Referring to <FIG>, when the data has been retrieved (step <NUM>) from the self-powered low consumption unit, a piece of data is taken in step <NUM> to be processed. A piece of data means herein one update to one feature. Then it is checked in step <NUM>, whether the piece of data meets safety criteria, i.e., is its safety ok. For example, if the feature to update relates to a safety function, it is checked whether the update (piece of data) meets corresponding functional safety update requirements. It should be appreciated that there may be features, for example license keys, for which there is no specific safety criteria, in which case they will meet the safety criteria checked in step <NUM>. Depending on an implementation, a common safety criterion, or common safety criteria, for example relating to cybersecurity, may be checked piece by piece in step <NUM>, or as one go for the data, as will be described with the example in <FIG>.

If the piece of data meets the safety criteria (step <NUM>: yes), the feature is updated in step <NUM> with the piece of data and then it is checked in step <NUM>, whether all pieces of data retrieved have been processed. If not (step <NUM>: no), the process returns to step <NUM> to process the next piece of data.

If the piece of data does not meet the safety criteria (step <NUM>: no), the process proceeds to step <NUM> to check whether all pieces of data retrieved have been processed. In other words, an update not meeting the safety criteria is not used to update a feature, thereby ensuring that the industrial automation device has proper functional safety features, for example. In another implementation, a fault message may also be sent and/or outputted to indicate an unacceptable update.

When all pieces of the data have been processed (step <NUM>: yes), the data retrieved have been processed (step <NUM>), and the thus triggered updating can end.

<FIG> illustrates an example of information exchange between a control unit C-U and a self-powered low consumption unit S-U in an industrial automation device IAD, information exchange over the low-power wide area network, and different example functionalities of the control unit, the self-powered low consumption unit, a server, for example a central server, connected to the low-power wide area network and to a cloud storage (not illustrated) whereto apparatuses, depicted by S-C, may store information and/or retrieve information. Further, in the illustrated example it is assumed that shared secrets are used in encrypting/decrypting and encrypting and decrypting succeeds, for the sake of clarity. Implementing the example using public key infrastructure is a straightforward process for one skilled in the art. Further, in the illustrated example of <FIG>, different identifiers are used as an additional security providing feature. It should be appreciated that the example may be implemented without the additional security providing feature.

Referring to <FIG>, in a hypothetical example, the IAD, identified by d-id, has just arrived in a warehouse when a salesperson receives an order for an industrial automation device, the order requiring to activate licensed software modules. The salesperson selects, using the S-C and information in the cloud storage, the IAD and OEM software package corresponding to the order, and provides an input <NUM>-<NUM> to update features in the IAD to correspond to the OEM software package by uploading missing features to the IAD. In the illustrated example, the S-C, determines in step <NUM>-<NUM> data to be delivered to update the IAD. More precisely, using the d-id of the IAD, the S-C retrieves from the cloud storage the u-id of the S-U and the current software version number of the IAD. Further, the S-C retrieves the current content of the selected OEM software package. Based on the content and the software version number of the IAD the S-C determines one or more pieces of data to be uploaded/delivered to the IAD, encrypts in step <NUM>-<NUM> the one or more pieces and the u-id (as additional security providing feature) with K1 to be data to be delivered, and stores the data associated with the d-id to the cloud storage with information indicating that the data is waiting to be delivered for update. Naturally device information in the cloud storage may be updated correspondingly.

When the S-U in the IAD detects in step <NUM>-<NUM> that it is time to request whether there is any data to be downloaded, the S-U encrypts in step <NUM>-<NUM>, as additional security providing feature, the d-id with K2, and transmits the request (message <NUM>-<NUM>) over the low-power wide area network to the server.

In response to receiving message <NUM>-<NUM>, the server decrypts in step <NUM>-<NUM> the message with K2, detects the d-id, uses the d-id to obtain in step <NUM>-<NUM> the data (stored in step <NUM>-<NUM>) from the cloud storage, and encrypts the data with K2. It should be appreciated that in another implementation the u-id may be used to obtain the corresponding data, and/or as a further step the server may be configured to check that the d-id in the message and the u-id who sent the message have the same values as device and unit identifiers associated with each other in the cloud storage, and only if that is the case, obtains the data. The data obtained may be encrypted pieces of data (one piece being the encrypted u-id), a piece having a size that is, after the piece is encrypted with K2, at most a payload size of the low-power wide area network protocol used. After encrypting the obtained data the server sends the data in one or more messages <NUM>-<NUM> to the S-U.

The S-U decrypts in step <NUM>-<NUM> the content (payload) in the one or more messages <NUM>-<NUM> with K2, and detects in step <NUM>-<NUM> that the data contains, as the additional security related feature, a d-id that has the same value as the d-id in the memory, and therefore stores in step <NUM>-<NUM> the data received to its memory. In the illustrated example, should the values of d-ids be different, no storing of the data would take place.

The above process may be triggered more than once, for example during the transportation, for example because some customer-related parameters or configurations being defined and/or common software updates takes place.

When the IAD is on a site, and is connected to power, the C-U is powered (step <NUM>-<NUM>) and retrieves (message <NUM>-<NUM>) from the memory in the S-U the data received (pieces of data received) and decrypts in step <NUM>-<NUM> the data received with K1. Then in the illustrated example, the C-U detects in step <NUM>-<NUM> that the data contains, as the additional security related feature, a u-id that has the same value as the u-id in the memory, and therefore updates in step <NUM>-<NUM> one or more features in the IAD with the data received, for example as described above with <FIG>.

As can be seen from the above examples, an easier way, compared with use of memory sticks and/or unpacking and repacking, to update an industrial automation device is achieved with integrating one or more self-powered low consumption units to the industrial automation device. The updating can take place even when the industrial automation device is being transported to a warehouse or from the warehouse. Furthermore, safety and cybersecurity related issues can be taken care by using predefined safety criteria, which may include, as described with <FIG> and <FIG>, encrypting/decrypting and/or safety requirements to be met and/or use of additional security related features.

The steps, related functions and information exchange described above in <FIG> are in no absolute chronological order, and some of the steps and/or information exchange may be performed simultaneously or multiple times or in an order differing from the given one. Other functions can also be executed between the steps or within the steps. Some of the steps and/or information exchange or part of the steps and/or information exchange can also be left out or replaced by a corresponding step or part of the step.

The techniques described herein may be implemented by various means so that an apparatus, for example an industrial automation device, or its units, or a server, implementing one or more functions described with an example/implementation comprises not only prior art means, but also specific means for implementing the one or more functions described with an example/implementation and the apparatus may comprise separate means for each separate function, or specific means may be configured to perform two or more functions. The specific means may be software and/or software-hardware and/or hardware and/or firmware components (recorded indelibly on a medium such as read-only-memory or embodied in hard-wired computer circuitry) or combinations thereof. Software codes may be stored in any suitable, processor/computer-readable data storage medium(s) or memory unit(s) or article(s) of manufacture and executed by one or more processors/computers, hardware (one or more apparatuses), firmware (one or more apparatuses), software (one or more modules), or combinations thereof. For a firmware or software, implementation can be through modules (e.g., procedures, functions, and so on) that perform the functions described herein.

Claim 1:
An industrial automation device (<NUM>) comprising at least:
electronic part (<NUM>-<NUM>) -powered means (<NUM>) for connecting wire-lessly (<NUM>-<NUM>) to a low-power wide area network (<NUM>), said electronic part -powered means comprising first identification information in the low-power wide area network and being arranged at least to receive data addressed to the first identification information and store (<NUM>-<NUM>) the data received when the industrial automation device is not connected to an electrical network, said electronic part (<NUM>-<NUM>) -powered means comprising one or more electronic parts providing said means with power;
means (<NUM>) for connecting the industrial automation device to the electrical network; and
means for updating (<NUM>), in response to connecting the industrial automation device to the electrical network, one or more features (<NUM>) in the industrial automation device by the data received.