Wireless programming device for use with an industrial controller

Abstract

A wireless programming device (130) for use with an industrial controller comprises: processing circuitry (131) configured to execute an operating system, OS (140), and to execute software applications (143) in the OS, wherein each software application is associated with a traffic flow (170) to and / or from the industrial controller; and at least two radio technology layers (150), each having a transceiver chain (153) and a software stack (152) for supporting the transceiver chain, and each being operable to maintain a wireless connection (180) to the industrial controller. The OS implements a virtual network switch (144) configured to selectively replicate prioritized ones of the traffic flows, such that the prioritized traffic flows are conveyed over multiple contemporaneous wireless connections to the industrial controller.

Description

WIRELESS PROGRAMMING DEVICE FOR USE WITH AN INDUSTRIAL CONTROLLER TECHNICAL FIELD

[0001] The present disclosure relates to the field of industrial automation, including industrial robotics. In particular it proposes a wireless programming device (e.g., teach pendant) for use with an industrial controller, such as a robot controller. Thanks to selective use of a redundant wireless connection to the industrial controller, the wireless programming device is suitable for conveying safety-critical information and key commands (e.g., relating to robot motion), which typically benefit from replication, alongside non-replicated status and health monitoring information.BACKGROUND

[0002] A teach pendant (TP; see figure 5) is a handheld device which an operator can use as an interface for tasks related to the programming of industrial robots. To mention one example, the applicant currently offers the TPU4 FlexPendant™ product, which is a teach pendant that connects by cable to the IRC5™ robot controller.

[0003] A move from wired to completely wireless TPs first requires a reliable wireless link for the key use cases. Despite recent advancements in wireless technologies, such as Wi-Fi and 5G cellular networks, wireless connections are still sensitive to radio interference and signal propagation obstacles. Such factors may degrade the performance of the communication, or even cause a breakdown of the wireless connection which then needs to be reestablished.

[0004] US9586471B2 discloses robot navigation performed from a mobile phone, a remote controller (e.g., a joystick), or a handheld control panel (with touch monitor). However, it does not describe how wireless networking from such devices could be realized. US9242372B2 is elaborating on a user interface for exchanging robot configuration and operation data over, e.g., a “radio frequency wireless”. The solution does not include any details on technology for implementing and managing wireless nor does it mention simultaneous use of wireless connectivity.US10052164B2 presents a system and method to achieve remote operation of a surgical robot. A “user input device” contains one “wireless communication device” but does not consider any means to improve communication reliability. Reliability istargeted by US11075997B2, which disregards a TP and focuses on communication between robot and its cloud-hosted controller. Establishment of concurrent links by distinct wireless technologies (e.g., 4G and Wi-Fi) is envisaged, but no solution is proposed for configuring those technologies.

[0005] One way to deal with the performance issues is to rely on redundant radio links. If one radio link is affected by a certain issue, there is a limited likelihood that the next radio link suffers from the same issue. Implementing redundancy oftentimes brings the challenge of finding a cost-effective wireless connectivity solution that enables distinct parts of radio spectrum to be assigned for the redundant links. The applicant’s recent international application PCT / EP2024 / 064561 proposes a robot controller equipped with a simultaneous connectivity module (SCM), which is specially configured to maintain two or more simultaneous wireless data links with external entities. For this purpose, the SCM has two or more radio technology layers, where each radio technology layer comprises a transceiver chain and a software stack for supporting the transceiver chain. The SCM further has a shared processing resource which is operable for the execution of any of the software stacks, and which can therefore be utilized more evenly over time.

[0006] Still relating to radio link redundancy, another practical challenge may be how to utilize and manage the link redundancy during operation. To increase the reliability of the related communication, any message of a desired type, such as safety-related messages, can be replicated and sent over two independent radio links, for thereby increasing the probability of timely delivery of either the message or its replica. In parallel, a TP may need to exchange with the robot controller network traffic that pertains to, say, robot jogging. For these reasons, technical means that allow configuration of replication (and elimination at the receiving end) of messages over two or more radio links, as well as configuration of prioritization of handling certain traffic flow in a wireless network over other network traffic flows, would be highly useful and desirable.SUMMARY

[0007] One objective of the present disclosure is to propose improved technical means for configuring replication of traffic flows to be transmitted wirelessly. A further objective is to propose an architecture for a wireless device such thatprioritized traffic flows can be selectively replicated without modifying the software applications which are associated with the traffic flows. A further objective is to propose a wireless programming device, or a teach pendant in particular, which incorporates this architecture. A still further objective is to propose a wireless programming device suitable for use with a robot controller.

[0008] At least some of these objectives are achieved by the invention defined in the independent claims. The dependent claims relate to advantageous embodiments.

[0009] In a first aspect of the present disclosure, there is provided a wireless programming device for use with an industrial controller. The wireless programming device comprises processing circuitry and at least two radio technology layers. The processing circuitry is configured to execute an operating system (OS) and to execute software applications in the OS, wherein each software application is associated with a traffic flow to and / or from the industrial controller. The software applications may, for example, include a robot control application operable to issue motion commands to a robot manipulator controlled by the industrial controller. A traffic flow maybe unidirectional or bidirectional. Each of the at least two radio technology layers has a transceiver chain and a software stack for supporting the transceiver chain, and each is operable to maintain a wireless connection to the industrial controller. According to said first aspect, the OS implements a virtual network switch configured to selectively replicate prioritized ones of the traffic flows, such that the prioritized traffic flows are conveyed over multiple contemporaneous wireless connections to the industrial controller.

[0010] In a second aspect of the disclosure, there is provided a system comprising industrial equipment (e.g., a robot manipulator), an industrial controller (e.g., a robot controller) and the wireless programming device according to the first aspect.

[0011] Thanks to the virtual network switch in the OS of the wireless programming device, software applications originally conceived for a wired TP can be used without modification in the wireless programming device. This is because the message replication functionality (for redundancy) is implemented separately from the software applications, e.g., in a separate logical layer and / or such that they execute independently of the virtual network switch. The replication functionality need not be added subsequently to the existing software applications, which avoids the effort of obtaining and editing the source code, and of recompiling the applica-tions after the edits. As such, replication maybe applied to a traffic flow associated with a software application that lacks a traffic replication functionality in itself.

[0012] The virtual network switch provides traffic replication which is selective in the sense of being applied only to the prioritized traffic flows. Any further traffic flows maybe exempted from replication, which saves processing resources and / or radio resources.

[0013] In some embodiments, the virtual network switch replicates the traffic flows in accordance with respective prioritization settings. A prioritization setting may be input by an authorized party, such as a system administrator or an authorized network controller. This way, the authorized party has full control over the replication process.

[0014] In other embodiments, the virtual network switch can be configured with a finer granularity than one software application. More precisely, assuming one of the software applications is associated with multiple traffic flows, the virtual network switch can be caused to replicate all, some, or none of these traffic flows. For each traffic flow, the replication is performed in accordance with an independent prioritization setting pertaining to that traffic flow.

[0015] In some embodiments, the prioritized traffic flows are identified by the virtual network switch on the basis of properties of the associated software application(s). For example, the virtual network switch maybe configured to identify a traffic flow as a prioritized traffic flow if the traffic flow is associated with a safety-related application and / or with an application operable to issue motion commands to industrial equipment (e.g., a robot manipulator) which is controlled by the industrial controller. Indeed, motion commands could cause mobile parts of the industrial equipment to move in potentially hazardous ways, with a risk injuring bystanders and damaging equipment. In these embodiments, it may not be necessary to obtain a prioritization setting from a system administrator, an authorized network controller, or the like.

[0016] In some embodiments, the wireless programming device is equipped with a simultaneous connectivity module (SCM) of the type described in the international application PCT / EP2024 / 064561 mentioned initially. The mentioned radio technology layers are included in the SCM, which further comprises a sharedprocessing resource which is operable for executing the software stacks in the radio technology layers. The SCM structure enables a relatively even utilization of the shared processing resource over time. Compared to an implementation where each radio technology layer has its own processing resource, the SCM structure may reduce the total capital expenditure.

[0017] In some embodiments, additionally or alternatively, the wireless programming device is equipped with a wireless networking manager (WiNeM) which assists in realizing different communication options, as detailed below. The WiNeM maybe associated with a corresponding application programming interface (API) for securely enabling an external party to have process access to the WiNeM for control and / or monitoring purposes.

[0018] In some embodiments, each software stack within the radio technology layers is configured with an independent security mechanism.

[0019] As used herein, “replication” may refer to different activities at a transmitting and a receiving end. The transmitting end may perform replication in a strict sense, that is, providing copies of relevant parts of the messages to be transmitted (e.g., the payloads), so that they can be routed to the receiving end over different physical connections. Meanwhile, the receiving end supports the replication process by eliminating redundant copies of a replicated message, if more than one copy of the message has been successfully received at the receiving end.

[0020] Further, a “prioritized traffic flow” is a traffic flow that is to be replicated by the virtual network switch. This terminology is not meant to exclude the possibility that the wireless programming device may be configured to promote some traffic flows in other ways. The configuration may have the following appearance:• replicate safety-related traffic flows (i.e., they are “prioritized traffic flows”) and assign them a highest handling priority;• do not replicate motion control related traffic flows, and assign them a medium handling priority;• do not replicate traffic flows related to data visualization, and assign them a low handling priority (or no handling priority at all).

[0021] In the terminology of the present disclosure, “industrial controllers” include computing devices arranged to control and monitor certain industrial equipment. To this end, the industrial controller may include an interface for applying control signals to the industrial equipment and receiving sensor signals from the industrial equipment. An industrial controller may for example be a programmable logic controller (PLC), a microcontroller, an automation device, or a robot controller.

[0022] Further, the term “industrial robot” is used in a broad sense, to cover in particular manufacturing robots, material-handling robots, assembly robots, cutting / welding robots, service robots, collaborative robots, hygiene robots, industrial robot tracks, and industrial robot positioners. An industrial robot may be a stationary robot or a mobile robot, such as an automated guided vehicle (AGV), an autonomous mobile robot (AMR), or an autonomous mobile manipulator robot (AMMR). An industrial robot is a special case of industrial equipment, and a robot controller is a special case of an industrial controller.

[0023] Generally, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. All references to “a / an / the element, apparatus, component, means, step, etc.” are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order described, unless this is explicitly stated.BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Aspects and embodiments are now described, by way of example, with reference to the accompanying drawings, on which:figure 1 is a block diagram showing a wireless programming device in use with a robot controller, according to first embodiment herein;figure 2 is a block diagram showing a wireless programming device in use with a robot controller, according to second embodiment herein;figure 3 is a detailed view of a radio technology layer;figure 4 is a sequence diagram illustrating high-level interaction for managing wireless TP communication options; andfigure 5 is a front view of a teach pendant, which is an example of a wireless programming device.DETAILED DESCRIPTION

[0025] The aspects of the present disclosure will now be described more fully hereinafter with reference to the accompanying drawings, on which certain embodiments of the invention are shown. These aspects may, however, be embodied in many different forms and should not be construed as limiting; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and to fully convey the scope of all aspects of the invention to those skilled in the art. Like numbers refer to like elements throughout the description.

[0026] Figure 1 shows an industrial controller in the form of a robot controller no suitable for use with industrial equipment, which is here illustrated by a robot manipulator 120. Figure 1 is a block diagram which lays emphasis on the communication aspects. It is appreciated that some technical structures which form part of a realistic implementation (e.g., power cables) may have been deliberately omitted for the sake of clarity. Together, the robot controller 110 and the robot manipulator 120 form an industrial robot. The robot manipulator 120 and the robot controller no are joined by a bidirectional data connection shown in solid line, which conveys control signals, sensor data, etc. As suggested in figure 1, the robot manipulator 120 may for example include an arm, which extends from a stationary or movable base, and which is made up of structural elements and at least one linear or rotary joint. The arm may further carry tools that allow it to interact with various workpieces, which are present in a work area of the robot manipulator 120. The workpieces are subject to manufacturing, processing or other handling by the robot manipulator 120. The work area may further include additional objects, such as containers, fixtures, separators, protective thermal / electric insulators, supports, etc. These objects maybe generic or maybe specifically adapted to the workpieces handled by the robot manipulator 120. The work area may in particular include auxiliary equipment for assisting the robot manipulator 120 in carrying out a utilitytask. The auxiliary equipment maybe directly or indirectly controlled by the robot controller no. The auxiliary equipment may, for example, be a workpiece positioner.

[0027] The arm of the robot manipulator 120 is movable by action of internal motors, drives and / or actuators (not shown), or by action of fully or partially externalized drives. The arm of the robot manipulator 120 includes transducers, sensors and other measuring equipment, from which the arm’s current position, pose, technical condition, load, etc. can be derived, to some degree of accuracy. The position, pose, etc. of the robot manipulator 120 may in particular refer to a point on the arm, particularly to a tool-center point (TCP).

[0028] An industrial robot system may comprise one or more robot manipulators 120 and one or more associated robot controllers no, as well as the novel wireless programming device 130 to be described below. In the examples, for purposes of illustration and not limitation, the wireless programming device 130 will be described when used together with a robot controller no. These examples notwithstanding, the novel wireless programming device 130 may be used not only with a robot controller no but is applicable more generally to any industrial controller. In fact, industrial controllers in such fields as process technology, manufacturing, material handling etc. differ from a robot controller 110 mainly concerning the identities and contents of the software applications 143 that are executed in the OS, but the associated traffic flows behave similarly and can be treated in a neutral manner that ignores the nature of the software applications 143, such that the different traffic flows can handled according to the teachings herein.

[0029] The example robot controller no in figure 1 comprises processing circuitry 111, which is operable to execute one or more robot programs 113 stored in a memory 112. A robot program may include a plurality of movement instructions relating to locations, such as points, poses, paths, or modulated paths. A program may be a compiled executable (a binary) or a script in a robot-executable language (e.g., RAPID™). A movement instruction relating to a modulated path maybe expressed as - or may include - a process-on-path instruction. The robot programs 113 may be created by an operator with the aid of a programming station or the wireless programming device 130. Alternatively, the robot programs 113 maybe created with the aid of a general-purpose computer, or they may be created using a robot controller no of the type that is equipped with an operator interface (not shown infigure i). Versions of the robot programs 113 maybe downloaded to the robot controller no over a wired or wireless connection or by being temporarily stored on a portable memory.

[0030] The processing circuitry 111 of the robot controller no may have access to further resources, including:- basic settings,- software that implements generic movements, sensing, self-monitoring, generically useful functionalities and services (all typically contributed by an original manufacturer),- task- or role-specific configurations,- configuration templates (typically contributed by a robot system integrator), and- site-specific settings (typically contributed by the operator).These further resources maybe offered by a software library or dedicated robotics middleware, such as the open-source Robot Operating System (see www.ros.org), which is to be used in conjunction with a generic OS, or the applicant’s robot controller software RobotWare™.

[0031] The robot controller no further comprises two or more wireless network interfaces 114a, 114b for maintaining wireless links 180a, 180b to at least the wireless programming device 130, and a wired interface 115 connectable to the robot manipulator 120. The wireless network interfaces 114a, 114b may as well be used for connecting to various external entities, such as:- a fleet management system,- a host computer offering connected services or cloud solutions, which may include server, storage and / or auxiliary processing resources,- an edge / cloud platform,- a wireless teach pendant or another human-machine interface for use by an operator,- another industrial robot, which may be a stationary industrial robot or a mobile industrial robot, or even a robot controller associated with said other industrial robot,- the auxiliary equipment in the work area discussed above.

[0032] The wireless programming device 130 is a physical device. It maybe a handheld and / or wireless device, such as a teach pendant. Figure 5 shows an example outer appearance of a wireless programming device 130 in the form of a teach pendant. The teach pendant comprises a visual display 131, an emergency stop button 132, and input means 133 for use during normal (non-emergency) operation. The wireless programming device 130 may further comprise enable switch or dead man’s handle. The enable switch, which is preferably arranged on the wireless programming device’s 130 rear side, maybe implemented as a three-position safety switch with a spring -loaded knob or stick that is linearly movable by hand between two inactive end positions, between which an active position is defined. The enable switch maybe a safety-certified switch, i.e., one that has been certified in view of the ISO 13849-1 standard (Safety of machinery - Safety-related parts of control systems - Part 1: General principles for design), the IEC 61508 standard (Functional Safety of Electrical / Electronic / Programmable Electronic Safety-related Systems), or an application-specific standard such as ISO 26262, IEC 61511, IEC 62061, IEC 62279, etc.

[0033] An overreaching purpose of the wireless programming device 130 is to assist in the creation of the robot programs 113. For instance, an operator may use the wireless programming device 130 for inputting commands, or for performing various types of demonstration-based programming, including lead-through programming. The wireless programming device 130 in figure 1 comprises a central processing unit (CPU) 131, a memory 132 storing executable code 133 and a simultaneous connectivity module (SCM, or SimCoM) 160. The SCM 160, which is an optional component of the wireless programming device 130, is configured to maintain two or more simultaneous data links 180a, 180b from the CPU 131 to the robot controller 120, and possibly to entities which are external to the wireless programming device 130. Each data link 180a, 180b includes at least one wireless link segment, in addition to any wired link segment(s).

[0034] In the wireless programming device 130, further, the CPU 131 is configured to execute an operating system (OS) 140. Within the OS 140, the processing circuitry 131 enables the execution of at least one wireless network interface 141, an SCM driver 142 (if an SCM 160 is provided) and other hardware drivers, as well as software applications 143a, 143b, 143c, 143d, and a virtual network switch 144. Software processes are executed in an OS in the sense that the OS acts as an intermediary for accessing storage and processing resources, including resources offered by the CPU 131 of the wireless programming device 130.

[0035] The wireless network interfaces 141 in the OS 140 may be instantiated (or created) by the SCM 160. The network interfaces 141 may include one or more of the following:- a network interface 141 allocated to transferring data related to process visualization services or work area visualization services;- a network interface 141 allocated to transferring program instructions and data;- a network interface 141 allocated to transferring input / output signals;- a network interface 141 allocated to transferring motion control signals and motion feedback;- a network interface 141 allocated to transferring safety signals; e.g., via a black channel;- a network interface 141 allocated to transferring status signals and diagnostics information;- a network interface 141 allocated to transferring files, e.g., program code, binary images, and / or data.Because respective radio technology layers 150 can be allocated to different responsibilities, the occurrence of collision periods in which two or more radio technology layers 150 compete for the shared processing resource 161 can be made relatively rare.

[0036] The SCM driver 142 may be constituted by an executing software process. The SCM driver 142 maybe configured to support a single high-speed serial data bus. It is understood that a serial data bus is configured to convey a single data stream,e.g., as obtained by multiplexing a plurality of data sub-streams into one. In particular, the SCM driver 142 maybe implemented based on a driver compliant with the PCI-Express™ (PCIe) standard, such as PCIe version 4.0 or higher. In particular, the SCM driver 142 maybe implemented by adapting a driver with a single PCIe lane.

[0037] The software applications 143a, 143b, 143c, 143d may include a robot control application for influencing the controlling of the robot manipulator 120, in accordance with the performing of useful tasks or other behaviors programmed by an operator or a system owner. Further, the robot control application maybe operable to issue motion commands to the robot manipulator 120 that is controlled by the robot controller no.

[0038] The software applications 143a, 143b, 143c, 143d may include a safety application which is configured for exchanging safety-related messages (in particular: messages related to functional safety, messages indicating a status of an emergency stop button, or messages indicating a status of an enable switch) between the wireless programming device 130 and a safety controller (not shown) in the robot controller no. The presence of one or more such safety applications maybe mandatory pursuant to the Machinery Directive (2006 / 42 / EC) of the European Parliament and of the Council.

[0039] The realizations of the SCM 160 disclosed in the international application PCT / EP2024 / 064561 are useful for implementing the novel wireless programming device 130 as well. In the example shown in figure 1, the SCM 160 comprises two radio technology layers 150a, 150b. Each radio technology layer 150a, 150b consists, in general terms, of hardware and software for maintaining a corresponding data link 180a, 180b to the robot controller no. For this purpose, as shown in figure 3, the radio technology layer 150 comprises a transceiver chain 153 and a software stack 152 for supporting the transceiver chain. Each transceiver chain 153 includes a radio frontend and baseband circuitry, and it is associated with an antenna arrangement 154. Each software stack 152, which may be stored in a suitable memory 151 in the radio technology layer 150, is configured for one or more of the following functionalities relating to the radio technology layers:- control functionalities,- signal processing functionalities,assistance functionalities,supervisory functionalities.The software stacks 152 can be executed by a shared processing resource (processing circuitry) 161, which is at the disposal of all radio technology layers 150 in the SCM 160. By allocating the respective radio technology layers 150 to different responsibilities (e.g., transfer of data relating to different applications or services), the occurrence of collision periods, in which two or more radio technology layers 150 need to utilize the shared processing resource 161 simultaneously, can be made relatively rare.

[0040] In some embodiments, at least two of the radio technology layers 150 are configured for a common cellular or non-cellular radio access technology, and they are restricted to operate in disjoint frequency bands. In other embodiments, different ones of the radio technology layers 150 use different radio access technologies, in particular different cellular radio access technologies or non-cellular radio access technologies.

[0041] The following example products available at the time of filing may be considered to be a Wi-Fi-enabled SCM 160 in the sense of the present disclosure: u-blox JODY-W3 module, AzureWave AW-XM458 module based on an NXP 88W9098 chip, Quectel FC6xE module, Voxmicro AIRETOS E20 module based on a Qualcomm QCA206X chips, and Renesas CL8000 chips. Further, the following example products available at the time of filing maybe said to constitute a cellular-enabled SCM 160: MediaTek M80, and Cradlepoint 1200M-B.

[0042] Figure 2, which will be discussed below, shows an alternative wireless programming device 130, where each radio technology layer 150 has its own processing resource. This is to say, the radio technology layers 150 are implemented outside any SCM structure.

[0043] Returning to figure 1, reference number 170 is used to denote traffic flows. For the purposes of this disclosure, a traffic flow 170 refers to the data which is conveyed from one of the software applications 143a, 143b, 143c, 143d to the robot controller no, or from the robot controller no to one of the software applications 143a, 143b, 143c, 143d, or bidirectionally. Two example bidirectional traffic flows 170b, 170c associated with the second and third software applications 143b, 143c are indicated by bold-dashed line and dotted line in figure 1. It is appreciated that atraffic flow 170 may refer to payload data or to data together with one or more layers of added protocol headers. It is further appreciated that the data transmissions in a traffic flow 170 can be intermittent, e.g., the execution of the associated software application may continue without transmitting or receiving data, in which case no data is conveyed in that traffic flow 170. Accordingly, even though various replication functionalities maybe active for a certain traffic flow 170, these functionalities may perform actual message duplication / elimination operations, which support the replication, only at such times when data is being conveyed.

[0044] The virtual network switch 144 is configured to selectively replicate prioritized ones of the traffic flows 170, such that the prioritized traffic flows are conveyed over multiple contemporaneous connections (i.e., multiple contemporaneous physical connections) to the robot controller no. In this disclosure, as explained above, the terminology “prioritized” shall not exclude the possibility that some traffic flows maybe promoted in other ways, such as by being assigned a certain handling priority.

[0045] On outgoing data, the virtual network switch 144 provides copies of relevant parts of the messages to be transmitted (e.g., the payloads), so that one copy can be routed to the robot controller no over a wireless connection 180a, and another copy can be routed to the robot controller 110 over a contemporaneous wireless connection 180b. This is achieved by routing each message to multiple different radio technology layers 150a, 150b. This is shown for the second traffic flow 170b, which is subject to replication, but not for the third traffic flow 170c.

[0046] It is noted that the second software application 143b, which is associated with the second traffic flow 170b, does not necessarily have an integral traffic replication functionality (or built-in traffic replication functionality). Because the replication of the second traffic flow 170b is instead carried out by the virtual network switch 144, a generic software application 143b - which is agnostic to replication -can be executed in the OS 140 without modification.

[0047] On incoming data, which has undergone replication in the robot controller no, the virtual network switch 144 may support the replication process by eliminating redundant copies of a replicated message. More precisely, there is at least one redundant copy if two or more copies of the message have been successfully received at the virtual network switch 144. For this purpose, the virtual networkswitch 144 may perform bookkeeping of those incoming messages that it has routed to the software applications 143, such that it can discover and eliminate redundant copies that arrive later (and usually on a different radio technology layer 150). In figure 1, such elimination may be applied to the second traffic flow 170b, but it is unlikely to be needed for the third traffic flow 170c, where data only arrives on one radio technology layer 150a.

[0048] The virtual network switch 144 may be a generic component which is configured for the duties just described. For example, there exist several software realizations of network switch which could be utilized for a wireless programming device 130 according to the embodiments herein. These include Open vSwitch (OVS) and the virtual network switch in libvirt’s virtual networking library. The virtual network switch is set up in a way that all network traffic from and to applications in a wireless programming device 130 traverses the switch, but without needing to make any modifications in the applications themselves.

[0049] Preferably, the software applications 143 execute in the OS 140 independently of the virtual network switch 144. In particular, there is no mutual dependence between the execution of the software applications 143 and the software that realizes the virtual network switch 144. Further, the execution of the software applications 143 and the virtual network switch 144 can be started, interrupted, terminated, and restarted independently of one another. Further, an execution error affecting the software applications 143 does not necessarily affect the virtual network switch 144, and vice versa.

[0050] The example wireless programming device 130 depicted in figure 1 further comprises a wireless networking manager (WiNeM) 145, which maybe realized by software executed in the OS 140. The WiNeM 145 maybe configured for at least one of the following:i) controlling the execution of each of the software stacks 152 of the radio technology layers 150;ii) enabling and disabling execution of each software stack 152 of the radio technology layers 150;hi) configuring rules for handling traffic flows 170;iv) configuring a prioritization setting (see below) for a traffic flow 170;v) retrieving report data relating to network traffic performance from the radio technology layers 150;vi) retrieving capability information or configuration information relating to the radio technology layers 150.

[0051] The WiNeM 145 may be operable to configure and / or manage one or more of the network-related components that are executed in the OS 140, including the virtual network switch 144, the wireless network interfaces 141a, 141b, and the SCM driver 142. The WiNeM 145 may influence these components directly or, as suggested in figure 1, by the intermediary of a configuration interface 146. If Open vSwitch (OVS) is used, its tool called ovs-vsctl enables the WiNeM 145 to enforce rules about replicating network traffic (and eliminating redundant message copies). Regarding the wireless network interfaces 141a, 141b, e.g., the Linux Traffic Control subsystem and its utilities facilitate scheduling of network traffic, thus allowing the WiNeM 145 to define rules about network traffic prioritization.

[0052] In below Table 1, the different rows illustrate example inputs and outputs of the WiNeM 145, as follows:1. Reading capability information concerning the SCM 1602. Writing configuration of a software stack 152 managed by the SCM 160 3. Retrieving performance report for a software stack 152 managed by the SCM 1604. Setting rules for handling network traffic5. Assumptions underlying the example in row 4.It is noted that the values or ranges in square brackets are merely for illustration purposes.

[0053] In some implementations, the WiNeM 145 is configured to operate an endpoint 145.1 of an application programming interface (API) for enabling external control of the WiNeM’s 145 operation, such as one or more of i)-vi) listed above. Said external endpoint of the WiNeM API maybe one of the software applications 143a. The API and the further control paths have been drawn in figure 1 as thin dashed-line double arrows.

[0054] The WiNem API provides a set of methods to interact with the WiNeM 145 and manage communication options for the wireless programming device 130 in an abstracted fashion, i.e., without needing to know about SCM implementation details and wireless networking specifics. Any authorized TP application may use the WiNeM API. Different frameworks and protocols can be exploited for implementing the WiNeM API, e.g., Representational state transfer (REST) with HTTP or HTTP Secure (HTTPS), or the OpenAPI specification (OAS). As a possible implementation, the WiNeM API is a RESTful API and makes use of the HTTPS protocol and the JSON data format. This addresses any risks stemming from using wireless connectivity in the wireless programming device 130.

[0055] Figure 2 shows an alternative implementation of the wireless programming device 130. It differs from the implementation depicted in figure 1 mainly in that no SCM 160 and no WiNeM 145 are provided. These are, as explained, not essential for practicing the present invention. It is understood that each of the radio technology layers 150a, 150b, 150c has its own processing resource (not shown), which serves substantially the same purpose as the processing resource 161 of the SCM 160. The processing resource maybe provided in the radio technology layer 150 or in association with the radio technology layer 150. It is furthermore understood that, when no SCM 160 is present, the wireless network interfaces 141 in the OS 140 are instantiated in accordance with a static configuration by a system owner. The three radio technology layers 150a, 150b, 150c are configured to establish and maintain a wireless connection 180a, a contemporaneous wireless connection 180b, and a further contemporaneous wireless connection 180c to corresponding wireless network interfaces 114a, 114b, 114c in the robot controller no. Each wireless connection 180a, 180b, 180c is a physical connection, and it may optionally correspond to a logical connection as well. As suggested in figure 2, the wireless connections 180a, 180b, 180c are at least in part mediated by network infrastructure.The network infrastructure may include one or more radio access networks (RANs) 181, 182, wherein the wireless connections 180a and the contemporaneous wireless connection 180b use a first cellular or non-cellular RAN 181, and the further contemporaneous wireless connection 180c uses a second cellular or non-cellular RAN 182.

[0056] In figure 2, the software applications 143a, 143b, 143c executing in the OS 140 are associated with respective traffic flows 170a, 170b, 170c. From these, the virtual network switch 144 replicates the second traffic flow 170b. In other words, the second traffic flow 170b - unlike the first and third traffic flows 170a, 170c - is a prioritized traffic flow, to which replication is to be applied. Outgoing data on the second traffic flow 170b is transmitted through the first and second radio technology layers 150a, 150b, which are also used for receiving incoming data on this traffic flow.

[0057] In a first embodiment, which is applicable to all the described implementations of the wireless programming device 130, there is a prioritization setting for each traffic flow 170, and the virtual network switch 144 is configured to replicate each traffic flow 170 in accordance with the respective prioritization setting. A system owner, the system owner’s delegate or an authorized network controller (e.g., within a network management system) may be authorized to set and modify the prioritization settings. The granularity of the prioritization setting maybe one independently configurable setting per software application 143. Alternatively, if one software application 143 is associated with two or more traffic flows 170, the granularity of the prioritization setting could be one independently configurable setting per traffic flow. This reflects the fact that distinct traffic flows 170 to or from the same software application 143 can have quite different replication demands; compare, for instance, an outgoing emergency-stop traffic flow and an incoming traffic flow to a graphical output interface of the wireless programming device 130. The independent configurability according to this alternative may contribute to saving resources on system level.

[0058] In a simple implementation of the first embodiment, the prioritization setting is a binary variable which can take the values ‘prioritized’ and ‘not prioritized’. In more sophisticated implementations, it would also be possible to configure different degrees of prioritization, such as five or ten different prioritization levels. Then, the virtual network switch 144 may, at a given time t, assess that the currentlyavailable networking and / or processing resources suffice for replicating Nttraffic flows, rank the active traffic flows by descending prioritization setting, identify the Nttraffic flows with the currently greatest values of the prioritization setting, and apply replication to these traffic flows.

[0059] In a second embodiment of the wireless programming device 130, the virtual network switch 144 is adapted to identify a traffic flow as a prioritized traffic flow (i.e., to which replication is to be applied) if the traffic flow is associated with a safety-related application 143 and / or if the traffic flow is associated with a software application 143 operable to issue motion commands to a robot manipulator 120 (industrial equipment) controlled by the robot controller no (industrial controller). Further identification criteria maybe configured, e.g., in terms of characteristics of the software applications 143. In other words, the prioritization setting is replaced in the second embodiment by the virtual network switch’s 144 automatic identification of software applications based on the identification criterion or criteria, which are such that the software application’s associated traffic flows maybe expected to need -or benefit from - replication. This second embodiment therefore relieves the system owner, system owner’s delegate, etc. from having to configure a prioritization setting for each traffic flow or each software application.

[0060] The first and second embodiments relate to the specific ways of causing the virtual network switch 144 to treat a traffic flow 170 as prioritized. Further embodiments, which are freely combinable with the first and second embodiments, provide advantageous further developments of the SCM 160. In particular, the SCM 160 may be implemented such that each software stack 152 of the radio technology layers 150 is configured with an independent security mechanism. The security mechanisms may be compliant with one or more of:- Wi-Fi Protected Access 3 (WPA3),- Wi-Fi Protected Access 2 (WPA2), preferably with Advanced Encryption Standard (AES),- Challenge Handshake Authentication Protocol (CHAP),- Password Authentication Protocol (PAP).The third and fourth options above can be used with a cellular-enabled SCM 160. In addition, if the SCM 160 is 3GPP LTE-compliant, it supports the so-called 4GEvolved Packet System Authentication and Key Agreement (EPS-AKA). For 3GPP NR, the so-called Extensible Authentication Protocol - Transport Layer Security (EAP-TLS) method is recommended, as its model of trust between a client device and the network is based on public key infrastructure. This public key infrastructure is not specific to cellular technology. Without departing from the scope of the present disclosure, the software stack’s 152 security mechanism may be compliant with one or more further security mechanisms not mentioned above.

[0061] Furthermore, the radio technology layers 150 are logically isolated from one another with respect to network traffic forwarding therebetween. This could act as an additional security layer in a wireless programming device 130 that is created for different SCM stacks. More precisely, the OS 140 may be configured in such manner that it prevents forwarding of network traffic between the wireless network interfaces 141. For example, if the TP receives any network traffic on ‘wireless network interface 2’, under no circumstances will the OS 140 forward that traffic to ‘wireless network interface 1’, and vice versa.

[0062] Still further security measures may be applied, including timely updates to the SCM driver 142 and / or regulating a radio transmit power of at least one of the transceiver chains 153 in such manner that radio signal propagation outside a preconfigured area of operation is limited. Such transmit power regulation could help avoid connecting the wireless programming device 130 to the wrong robot controller no or wrong robot manipulator 120. The transmit power regulation may take into account known radiated emission patterns of directional and non-directional antennas and / or local transmit power measurements away from the wireless programming device 130.Example

[0063] Figure 4 is a sequence diagram illustrating high-level interaction for managing wireless TP communication options. The interaction occurs between the following components in the wireless programming device 130:- a GUI application, which is one of the software applications 143,- the WiNeM 145, and- the OS 140.The messages between the software application 143 and the WiNeM 145 are sent on the WiNeM API 145.1 described above, which is symbolized by a hashed rectangle in figure 4. The following phases are indicated:51 Define configuration which runs all SCM stacks52 SCM driver: Software stacks up and running53 OS: Wireless network interfaces connected54 Specify rules for handling network traffic55 Message replication (including elimination at receiving end) configured 56 OS: Network traffic forwarding defined57 Detected performance issue over wireless network interface58 OS: Envisaged actions include down-prioritizing certain traffic flows The following messages and events are indicated in figure 4:Mi Fetch SCM capabilities (response: dashed leftward arrow just below) M2 Read SCM capabilities (response: dashed leftward arrow just below) M3 Write SCM configurationM4 Enforce SCM configurationM5 Configure the SCMM6 Connectivity establishedM7 Connectivity establishedM8 Start and activate connectivity monitoringM9 Connectivity monitoring dataMio Write traffic handling configurationMil Enforce traffic handling configurationM12 Configure traffic handlingM13 Traffic handling configuredM14 Traffic handling configuredM15 Start and activate traffic monitoringM16 Traffic monitoring dataM17 Enforce traffic handling reconfigurationM18 Reconfigure traffic handlingM19 Traffic handling reconfigured

[0064] The following main steps can be discerned in figure 4:- Step 1: The GUI application 143 in the wireless programming device 130 is used by an operator to, via the WiNeM API, obtain SCM capabilities and configure operation of its stacks, enable associated wireless network interfaces in the OS and connect them to the selected networks, and activate connectivity monitoring by the WiNeM 145.- Step 2: The operator specifies rules of network traffic handling in the GUI application 143, which then triggers, again via the WiNeM API, for them to be implemented in the wireless programming device’s 130 networking (including the potential use of message replication) as well as to activate network traffic monitoring.- Step 3: An incident is handled where the WiNeM 145 receives reports of a connectivity performance issue (e.g., increased number of frame retransmissions) on one of the wireless network interfaces (e.g., ‘wireless network interface 1’). This causes the WiNeM 145 to initiate reconfiguration of network traffic handling (e.g., replicate also ‘traffic flow 2’, OPC UA Datagram Protocol messages, over ‘wireless network interface 2’).Closing remarks

[0065] To summarize, the present disclosure aims to provide or enable:• A teach pendant architecture with simultaneous wireless networkingThe teach pendants include the capabilities of connecting to two (or more) wireless networks and simultaneously transmitting data over disjoint radio links, which improves communication reliability.Presented security measures mitigate risks from using wireless connectivity in a teach pendant.• Replication (including elimination) of network traffic transparent to existing teach pendant applicationsNo changes are called for in the applications, while still receiving benefits of improved communication reliability.• A management API with an easy-to-configure approach for the simultaneous wireless networkingFlexibility of configuring and monitoring not just wireless connectivity but also network traffic performance, while “hiding” away many technology specifics.The envisaged wireless networking manager enables adaptations of connectivity and communication configurations in an automated fashion.• Potential solution offerings around end-to-end wireless communication for industrial equipment, including stationary and mobile robots• Communication adaptivity to fit specific needs in robotics Wireless networking can be reconfigured to support different communication use cases of teach pendants.

[0066] The aspects of the present disclosure have mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the invention, as defined by the appended patent claims.

Claims

CLAIMS1. A wireless programming device (130) for use with an industrial controller arranged to control industrial equipment, the wireless programming device comprising:processing circuitry (131) configured to execute an operating system, OS (140), and to execute software applications (143) in the OS, wherein each software application is associated with a traffic flow (170) to and / or from the industrial controller; and at least two radio technology layers (150), each having a transceiver chain (153) and a software stack (152) for supporting the transceiver chain, and each being operable to maintain a wireless connection (180) to the industrial controller,wherein the OS implements a virtual network switch (144) configured to selectively replicate prioritized ones of the traffic flows, such that the prioritized traffic flows are conveyed over multiple contemporaneous wireless connections to the industrial controller.

2. The wireless programming device (130) of claim 1, wherein the software applications (143) execute in the OS (140) independently of the virtual network switch (144).

3. The wireless programming device (130) of claim 1 or 2, wherein the virtual network switch (144) replicates at least one traffic flow, which is associated with a software application that lacks an integral traffic replication functionality.

4. The wireless programming device (130) of any of the preceding claims, wherein the virtual network switch (144) is configured to replicate each traffic flow in accordance with a respective prioritization setting.

5. The wireless programming device (130) of claim 4, wherein:at least one of the software applications is associated with multiple traffic flows; and the virtual network switch (144) is configured to replicate each of the multiple traffic flows in accordance with an independent prioritization setting for the respective traffic flow.

6. The wireless programming device (130) of any of claims 1 to 3, wherein the virtual network switch (144) is adapted to identify a traffic flow as a prioritized trafficflow if the traffic flow is associated with a safety-related application and / or with an application operable to issue motion commands to the industrial equipment controlled by the industrial controller.

7. The wireless programming device (130) of any of the preceding claims, further comprising a simultaneous connectivity module, SCM (160), itself comprising: said at least two radio technology layers (150); anda shared processing resource (161) which is operable for execution of the software stacks.

8. The wireless programming device (130) of claim 7, wherein the SCM is operable to instantiate at least one network interface.

9. The wireless programming device (130) of any of the preceding claims, further comprising a wireless networking manager, WiNeM (145), which is configured for at least one of:controlling the execution of each of the software stacks (152) of the radio technology layers (150);enabling and disabling execution of each software stack of the radio technology layers;configuring rules for handling network traffic flows;configuring a prioritization setting for a traffic flow;retrieving report data on network traffic performance;retrieving capability information or configuration information relating to the radio technology layers.

10. The wireless programming device (130) of claim 9, wherein the WiNeM is further configured to operate an endpoint (145.1) of an application programming interface for enabling external control of the WiNeM’s operation.

11. The wireless programming device (130) of any of the preceding claims, wherein each software stack (152) of the radio technology layers (150) is configured with an independent security mechanism.

12. The wireless programming device (130) of claim 11, wherein the security mechanisms of said software stacks (152) are compliant with one or more of:Wi-Fi Protected Access 3, WPA3; Wi-Fi Protected Access 2, WPA2; Challenge Handshake Authentication Protocol, CHAP; Password Authentication Protocol, PAP.

13. The wireless programming device (130) of any of the preceding claims, wherein the software applications (143) include a robot control application operable to issue motion commands to a robot manipulator (120) controlled by the industrial controller.

14. The wireless programming device (130) of any of the preceding claims, wherein at least two of the radio technology layers (150) are configured for a common cellular or non-cellular radio access technology, and they are restricted to operate in disjoint frequency bands.

15. The wireless programming device (130) of any of the preceding claims, which is a teach pendant.

16. The wireless programming device (130) of any of the preceding claims, wherein the industrial controller is a robot controller (110) arranged to control a robot manipulator (120).

Images