EP4652506A1

EP4652506A1 - A controller for an industrial system

Info

Publication number: EP4652506A1
Application number: EP23700886.7A
Authority: EP
Inventors: Bjarne SANDVIK; Arnt-Olav AALGAARD
Original assignee: ABB Schweiz AG
Current assignee: ABB Schweiz AG
Priority date: 2023-01-16
Filing date: 2023-01-16
Publication date: 2025-11-26
Also published as: CN120530369A; WO2024153312A1

Abstract

A controller (₁₀₀) configured to control an industrial system (₁₉₀), comprising: a processor (no) configured to read sensor signals from sensors (₁₉₁) arranged in the industrial system and to make available status data derived from at least the sensor signals; and an operator interface (₁₂₀) configured to provide system diagnostic information on the basis of the status data and display this to an operator, a memory buffer (₁₃₀) through which the processor makes available the status data; and a wireless service interface (₁₄₀) operable to grant a connecting wireless device ₁8₂ read access to the memory buffer. A method of operating such controller (₁₀₀), wherein the wireless service interface (₁₄₀) is activated if the operator interface (₁₂₀) fails to initialize.

Description

A CONTROLLER FOR AN INDUSTRIAL SYSTEM

TECHNICAL FIELD

[0001] The present disclosure relates to the field of automatic control suitable for industrial systems, and notably industrial robots. In particular, it proposes a controller for an industrial system with a service interface for use during failures that affect the controller’s regular operator interface.

BACKGROUND

[0002] Controllers for controlling industrial systems are known in the art, in particular robot controllers to be used with industrial robots. The controller, while in normal operation, provides an operator with access to system diagnostics through a human-machine interface (HMI), which retrieves status data from the controller’s central processing unit (CPU) and presents it to the operator after optional processing, graphical rendering or the like. The CPU, in turn, has provided the status data on the basis of sensor signals read from sensors in the industrial system.

[0003] To mention one example, DE102012102506A1 is concerned with fault diagnosis for an automation system. The fault diagnosis is carried out over a wireless HMI in the form of a diagnostic smartphone app, and the smartphone executing the app communicates wirelessly with the automation system. It is foreseen that a hardware interface can be provided as an alternative, to allow devices without wireless capabilities to perform a corresponding fault diagnosis procedure.

[0004] It is furthermore known that an HMI sometimes becomes inoperable due to a malfunction of the industrial system. Another error scenario is where the HMI itself fails to boot or crashes due to a runtime error. This deprives the operator of access to the system diagnostics.

SUMMARY

[0005] One objective of the present disclosure is to propose a controller suitable for an industrial system with a robustness to certain HMI failures. In particular, the controller should be able to provide an operator access to system diagnostics during failures of certain types. A further objective is to propose a controller with these capabilities which is such that the operator can be granted access to the system diagnostics during said failures without necessarily having physical access to the controller. A still further objective is to propose a method for operating such a controller in such manner that the operator is not dependent on successful initialization or execution of a normal operator interface; rather, the operator should retain access to the system diagnostics also during certain failures.

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

[0007] In a first aspect of the present disclosure, there is provided a controller configured to control an industrial system. The controller comprises a processor (e.g., CPU), which is configured to read sensor signals from sensors arranged in the industrial system and to make available status data derived from the sensor signals (and possibly derived from further sources), and an operator interface (or HMI), which is configured to provide system diagnostic information on the basis of the status data and display this to an operator. According to this first aspect, the controller further comprises a memory buffer, through which the processor makes available the status data, and a wireless service interface, which is operable to grant a connecting wireless device read access to the memory buffer.

[0008] By the technical features of the first aspect, a fallback path is provided through which the operator can inspect at least a simplified version of the system diagnostics even at times of failures that affect the operator interface.

[0009] In other words, the inventors are proposing a controller equipped with a wireless interface for use during failures that affect the operator interface. The wireless interface, which can be of the short-range type, such as Bluetooth, NFC or RFID, provides read access to the memory buffer where the processor makes available the up-to-date status data on a running basis. The status data can be used as a substitute for the system diagnostics, and may thereby provide sufficient guidance for the operator to resolve the failures. Preferably, the processor is configured to operate independently of the operator interface, so that it will normally keep functioning even when the operator interface crashes or when it fails to boot.

[0010] The use of a wireless interface is particularly advantageous in that the operator need not be granted physical access to the controller. Instead, the controller can be installed inside a closed cabinet. Such a closed cabinet may be required, notably for regulatory or quality-assurance reasons, to protect the controller from unauthorized tampering and from environmental hazards.

[oon] In a second aspect of the present disclosure, there is provided a method of operating a controller for an industrial system. The method comprises: initializing a processor in the controller; reading, using the processor, sensor signals from sensors arranged in the industrial system; and deriving, using the processor, status data from the sensor signals; making the status data available through a wirelessly accessible memory buffer in the controller. It is understood that the initialization of an operator interface is attempted, upon which the execution continues differently depending on the success of these attempts. If the operator interface is not successfully initialized, a connecting wireless device is granted read access to the memory buffer using a wireless service interface in the controller. In some embodiments, if instead the operator interface is successfully initialized, system diagnostic information is provided on the basis of the status data and displayed to an operator using the operator interface.

[0012] In many implementations, the operator interface includes or is constituted by an executing software process, which can be failure-prone. Because the the status data is made available through a wirelessly accessible memory buffer in the controller independently of the initialization of the operator interface, the operator has access to the status data at all times and can use these as a substitute for the system diagnostics if the operator interface does not initialize in an orderly fashion. Another advantage is that the status data becomes available after relatively brief time, such as less than one minute, or in some tens of seconds, or even less. For comparison, the complexity and the large number of remote devices interacting with the controller may lead to initialization time of the order of several minutes.

[0013] The present disclosure further relates to a computer program containing instructions for causing a computer, or the industrial-system controller in particular, to carry out the above method. The computer program may be stored or distributed on a data carrier. As used herein, a “data carrier” maybe a transitory data carrier, such as modulated electromagnetic or optical waves, or a non-transitory data carrier. Non-transitory data carriers include volatile and non-volatile memories, such as permanent and non-permanent storage media of magnetic, optical or solid-state type. Still within the scope of “data carrier”, such memories may be fixedly mounted or portable.

[0014] 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 explicitly stated.

BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Aspects and embodiments are now described, by way of example, with reference to the accompanying drawings, on which: figure 1 shows an industrial system which is controlled by a controller according to embodiments presented herein, and the figure further shows wireless and wired devices which can connect to the controller over respective service interfaces to inspect status data in a memory buffer; figure 2 shows an industrial robot which is controlled by a controller; figure 3 shows a controller for an industrial system according to other embodiments herein; and figure 4 is a flowchart of a method for operating an industrial-system controller, according to embodiments herein.

DETAILED DESCRIPTION

[0016] 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. [0017] To illustrate some embodiments of the first aspect of the present disclosure, figure 1 shows a controller 100 configured to communicate, over a wired or wireless connection, with sensors 191 and actuators 192 arranged in an industrial system 190. An industrial system is understood as technical machinery made up of one or more interacting devices designed for extraction of raw materials, processing of raw materials or semi-finished products, recycling or destruction, logistics or similar activities. Accordingly, the industrial system 190 maybe, for example, an industrial plant, a factory process, a logistics site, a mobile or stationary robot. Figure 2 shows the particular use case of a stationary industrial robot 290. A sensor 191 is understood as a device comprising a transducer for generating an informationcarrying signal to represent a physical or otherwise technical condition prevailing at the sensor 191. An actuator 192 can be, for example, a controllable device for influencing the operation of the industrial system, such as a motor, a brake, a pneumatic or hydraulic valve, an electric switch or an electromagnet. The sensors 191 maybe arranged to sense a technical condition of one or more actuators 192, such as a pneumatic pressure, a motor temperature, an execution state of a local subcontroller. Furthermore, the sensors 191 maybe designed to capture emergency- related states, as is the case with smoke sensors, safety light curtains and the like.

[0018] The controller 100 in figure 1 is implemented as at least one localized physical device, such as a rack server, stationary personal computer or portable computer. The controller 100 may optionally include remote processing or storage resources in addition to the localized physical device, such as a networked processor (e.g., host computer, server), a cloud processor or edge processor. Regardless of whether the localized physical device constitutes the entirety of the controller 100 or whether the localized physical device is supported by remote resources, it can be installed in a closed cabinet. Such a closed cabinet maybe required, notably for regulatory or quality-assurance reasons. To protect the controller 100 from unauthorized tampering, one may use a locked - or otherwise passage-controlled - cabinet with optional passages for ventilation, cooling, cables and the like. To shield the controller 100 from environmental hazards, such as liquids, corrosive gases and solid contaminants, the cabinet may have to be more or less impermeable to these substances, with suitable seals at hatches and any further apertures. [0019] Turning to the inner workings of the controller 100, it is seen in figure 1 that it is equipped with a processor no (e.g., a central processing unit, CPU), an operator interface 120 and a memory buffer 130. The connection lines represent data connections, such as a data bus, local-area network or wide-area network, for unidirectional or bidirectional communication. For example, to protect the processor no from malicious attacks via the memory buffer 130, it maybe suitable to provide a unidirectional (diode-like) connection from the processor 110 to the memory buffer 130.

[0020] The processor 110 is configured to derive status data from sensor signals that the processor 110 reads from the sensors 191 in the industrial system 190, and to make this status data available through the memory buffer 130. The memory buffer 130 may be configured to perform recurrent purging of old status-data items to make room for newer status-data items. Alternatively, the memory buffer 130 maybe configured to operate as a cyclic buffer, such that when a new status-data item arrives after the capacity has been reached, the oldest status-data item is overwritten.

[0021] The status data may include the sensor signals themselves or a time sequence of the sensor signals. Another option is to simulate representative state variables of the industrial system during operation of the industrial system, e.g., in accordance with a predefined dynamic system model in terms of a vector x of state variables, such as:

(x = Ax + Bu (y = Cx + Du where A, B, C, D are matrices, it is a vector of control signals, and the observable y correspond to the sensor signals. The simulation may be performed using an observer, such as a Kalman filter, in a per se known manner. In one example, a tank is provided with sensors 191 for sensing momentary inward and outward flows of a liquid, and the current fill level is used as a state variable. In another example, a robot arm has sensors 191 for reporting a tool-center position and motor drive currents, and the joint angles are used as state variables of the robot arm.

[0022] In broad terms, the operator interface 120 is configured to provide system diagnostic information on the basis of the status data from the processor no and display the system diagnostic information to an operator. The operator interface 120 can be configured to obtain the status data directly from the processor 110, which provides it. In particular, the operator interface 120 may send requests for recent status data to the processor no, which returns messages with the requested status data. Alternatively, the operator interface 120 maybe authorized to read the status data from the processor 110.

[0023] On the one hand, the operator interface 120 may be configured to generate the system diagnostic information by processing the status data. The processing may include interpreting the status data, in particular comparing the status data with nominal values or nominal ranges of variables that constitute the status data, to allow a conclusion whether the industrial system 100 is operating normally or is an abnormal or a failure condition. The processing may furthermore include automated decision-making, e.g., by evaluating a multivariate utility function for the status data, or by feeding the status data to a machine-learning model that has been pre-trained to discern abnormal or failure conditions. The operator interface 120 may further be configured to report, if it detects a likely failure condition, a suggestion or instruction to the operator for resolving the failure condition.

[0024] On the other hand, the operator interface 120 maybe configured to render graphical elements representing values of the system diagnostic information. The graphical elements, including shapes, text, images, animations etc. may be displayed on a stationary or handheld workstation 181 connected to the operator interface 120, or the operator interface 120 itself may comprise a visual display. The graphical elements maybe displayed in the framework of a graphical user interface (GUI). This allows more efficient and possibly less failure-prone communication with an operator, with an ability to add visual, auditory or tactile emphasis to urgent or important messages. It may also help the operator focus on the essential information if graphical elements representing information of secondary relevance are rendered to have a less conspicuous appearance and/or away from a central field of view.

[0025] The processor no and operator interface 120 are distinct; they may correspond to nonoverlapping hardware resources or nonoverlapping software code, or both. On the implementation level, it is noted that the processor no is preferably configured for operating independently from the operator interface 120. This entails, in particular, that the operation of the processor 110 can begin without interaction with the operator interface 120, and it can continue to operate even if the operator interface 120 is affected by a partial or total failure. Further, the operator interface 120 is preferably configured to boot separately from the processor no, and these two components may have two independent power supplies. This way, a large class of problems affecting the operator interface 120 do not stop the processor no from booting. Similarly, the processor 110 may have an ability to reboot, e.g. in case of a failure or in response to an operator’s request, without requiring the operator interface 120 to reboot together with it.

[0026] In accordance with the first aspect of this disclosure, the controller 100 further comprises a wireless service interface 140. The wireless service interface 140 can be in an off or standby mode while the operator interface 120 is operating normally. In principle, although this may not serve any evident useful purpose, the wireless service interface 140 can be in an active mode even though the operator interface 120 is operating.

[0027] However, when the operator interface 120 has a full or partial failure, it is foreseen that the wireless service interface 140 is activated so as to grant a connecting wireless device 182 read access to the memory buffer, where the status data is deposited. The connecting wireless device 182 may for example be a wireless-enabled portable computer, vehicle-carried computer, or handheld device. The wireless device 182 may read the status data over a multi-hop connection, with one wireless segment from the wireless device 182 to the wireless service interface 140, and one or more wired segments from the wireless service interface 140 to the memory buffer 130. The wireless service interface 140 is configured for a suitable type of short-range wireless communication. This may include Bluetooth™ communication, near-field communication (NFC) and/or radio-frequency identification (RFID). Preferably, the wireless segment from the wireless device 182 to the wireless service interface 140 is not a Wi-Fi™ connection, nor is it a cellular connection (e.g., uplink and downlink via a base station). Because operators of the controller 100 can gain access to the status data via the wireless service interface 140 using a connecting wireless device 182, they can continue to monitor the industrial system 190 even when the operator interface 120 is not functioning. In particular, if the industrial system 190 is concurrently affected by a failure condition, the service data may provide the operators with useful assistance in identifying and resolving this failure condition. It is noted that an NFC interface can normally be activated in very short time, to be operable in merely one or two seconds. The NFC interface can then be used to access, say, debut information on bootloader level.

[0028] In some embodiments, the wireless service interface 140 is a component of a localized physical device belonging to the controller 100, preferably a device hosting the processor no or the memory buffer 130 or both. This way, the communication between the wireless service interface 140 and the memory buffer 130 is independent of a remote connection, as is the case with a cloud or cloud-supported implementation of the controller 100, but instead the wired segment can be established simpler and operate more reliably. In other embodiments, the wireless service interface 140 is located remotely from the memory buffer 130.

[0029] It is understood that the status data, which is accessed via the wireless service interface 140, could provide a more rudimentary view of the current condition of the industrial system 190 than the system diagnostic information does. For example, the interpretive and assistive functionalities of the operator interface 120 are not available. The temporary absence of these functionalities may be compensated for by the experience and practical knowledge of the operator, or by consulting a user’s manual to confirm nominal variable ranges and similar information. Furthermore, the connecting wireless device 182 may incorporate at least some of the functionalities of the operator interface 120, including the processing of the status data into some type of diagnostics information.

[0030] As noted above, the controller 100 maybe deployed inside a closed cabinet to protect it from tampering or environmental hazards. Electric safety regulations maybe a further reason for deploying the controller 100 inside a closed cabinet. In such deployments, it is understood that the closed cabinet has at least one portion (window) that is permeable to a radio-frequency spectrum for which the wireless service interface 140 is configured. For example, if the wireless service interface 140 is configured for Bluetooth communication, which has a spectrum of 2.402 to 2.480 GHz, the cabinet - or at least a portion thereof - attenuates or reflects electromagnetic radiation in this frequency range only to a limited extent, so that it is possible to maintain a useful Bluetooth connection. It is to be borne in mind, on the one hand, that the Bluetooth connection will be used relatively infrequently, i.e. at the normal incidence and duration of failures in the operator interface 120. On the other hand, it maybe expected that operators (service technicians) maybe using portable equipment with a limited battery capacity.

[0031] In some embodiments, the controller 100 further comprises a wired service interface 150 as a further fallback. The wired service interface 150 may include a console port. More precisely, the wired service interface 150 could be used during concurrent failures in the operator interface 120 and the wireless service interface 140, in which case the wired service interface 150 offers a connecting wired device 183 read access to the memory buffer 130. Another reason for using the wired service interface 150 even though the wireless service interface 140 is operational may be an expectation that a wired data connection is more stable and has greater bandwidth (or data transfer capacity). Further, the wired service interface 150 maybe intended for vendor-side service personnel authorized to access the controller 100 physically, whereas the wireless service interface 140 is suitable for a client-side operator.

[0032] As for the wireless service interface 140, it is preferred to co-locate the wireless service interface 150 with the memory buffer 130, e.g., in a localized physical device accessible to operators.

[0033] Figure 3 shows a controller 100 for an industrial system according to another group of embodiments of the first aspect. It differs from the embodiments illustrated in figure 1 notably by the topology of the connections between the processor no, operator interface 120 and memory buffer 130. In particular, there is a direct connection from the operator interface 120 to the memory buffer 130. This allows the operator interface 120 to obtain the status data from the memory buffer 130, that is, without querying the processor no. In the present group of embodiments, the presence of the connection between the processor 110 and the operator interface 120, which was seen in figure 1, is not necessary. The wireless service interface 140 and any wired service interface 150 are connected to the memory buffer 130 in parallel, like in figure 1.

[0034] A method 400 of operating a controller 100 for an industrial system, as exemplified in figures 1 and 3, will now be described with references to the flowchart in figure 4. The method 400 may be executed by the controller 100, and more precisely by a program executing on the controller’s 100 processor no, by firmware (e.g., bootloader) in the controller 100, or by a low-level operating system in the controller 100. Alternatively, the method 400 is executed by a device that is external to the controller 100 but is authorized to influence the operation of at least the processor no, operator interface 120 and wireless service interface 140. The external device may for example be a server, such as a cluster manager configured to monitor the health of the controller no.

[0035] The method 400 may be represented as executable program code (binary) or as a script.

[0036] In a first step 410 of the method 400, the processor 110 is initialized. This may correspond to one or more of the following actions: power-on self-test, detection of a basic input/ output system (BIOS) or equivalent firmware, memory test, identification of a boot device, execution of a boot record in the boot device, loading of an operating system. In many envisioned implementations, it is not necessary to initialize the processor no completely (say, including the loading of the operating system) in order for the subsequent steps 412, 414, 416 to start; by accepting a lighter type of initialization of the processor no, the status data may become available at an earlier point in time.

[0037] When the processor 110 has been initialized, it reads, in a second step 412, sensor signals from sensors 191 arranged in the industrial system 190.

[0038] The processor 110 then derives, in a step 414, status data from the sensor signals. Optionally, the status data maybe derived from the sensor signals in combination with at least one further data source or preconfigured data, such as a dynamic model of the industrial system. As noted above, the status data may correspond to the sensor signals in unprocessed form, or a time sequence thereof, or the status data may be provided by applying filtering or a similar operation aiming to determine a state of the industrial system 190 to the sensor signals.

[0039] The status data thus obtained is then made available, in a fourth step 416, through a wirelessly accessible memory buffer 130 in the controller no. More precisely, as also described in detail above, the memory buffer 130 can be accessed through a wireless service interface 140 while this wireless service interface 140 is active. It is noted that the present step 416 can be executed in parallel with steps 412 and 414, or possibly in a cyclic fashion, so that older status data is gradually replaced by newer status data as time evolves. [0040] The execution of the method 400 then proceeds to a step 418, in which it is attempted to initialize the operator interface 120 of the controller 100 and it is determined whether this succeeds. The initialization of the operator interface 120 can consist, in some implementations, in a self-test of the operator interface’s 120 hardware and executing a software program. In other implementations, the initialization of the operator interface 120 is more demanding and maybe similar to the initialization of the processor no or a generic boot procedure. The initialization of the operator interface 120 can fail not only due to unforeseeable factors but also due to changes to its configuration, application of a safety policy and the like. The success of the initialization of the operator interface 120 determines the next step of the method 400.

[0041] If the operator interface 120 is successfully initialized, the execution flow proceeds to a step 420 (left branch from step 418), in which the operator interface 120 is caused to provide system diagnostic information on the basis of the status data. The operator interface 120 also displays the system diagnostic information to an operator. In the event of a successful initialization of the operator interface 120, it is optional to activate the wireless service interface 140.

[0042] Alternatively, if the operator interface 120 is not successfully initialized, a step 422 is executed in which the controller’s no wireless service interface 140 is activated, for thereby granting read access to the status data in the memory buffer 130 to a wireless device 182 that connects to the wireless service interface 140. This provides a fallback path through which an operator can inspect or download the status data - by way of simplified system diagnostics - even at times when the operator interface 120 is not functioning.

[0043] In further developments of the method 400, the decision step 418 can be repeated even after successful initialization of the operator interface 120. For example, the decision step 418 can be repeated in the form of a status check performed on the operator interface 120. This way, if the operator interface 120 crashes during operation, the wireless service interface 140 can be activated (step 422) until the operator interface 120 is back in operation. The decision step 418 can be implemented by means of a self-diagnosis of the operator interface 120, in particular, by listening for an expected heartbeat signal from the operator interface 120 representing normal operation. [0044] 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

1. A controller (100) configured to control an industrial system (190; 290), the controller comprising: a processor (no) configured to read sensor signals from sensors (191) arranged in the industrial system and to make available status data derived from the sensor signals; and an operator interface (120) configured to provide system diagnostic information on the basis of the status data and display this to an operator, characterized by a memory buffer (130) through which the processor makes available the status data; and a wireless service interface (140) operable to grant a connecting wireless device (182) read access to the memory buffer.

2. The controller (100) of claim 1, wherein the wireless service interface (140) is configured for short-range wireless communication, in particular for Bluetooth communication, near-field communication, NFC, and/or radio-frequency identification, RFID.

3. The controller (100) of claim 1 or 2, wherein the processor (no) is configured for operating independently of the operator interface (120).

4. The controller (100) of any of the preceding claims, wherein the controller is provided in a closed cabinet having at least one portion which is permeable to a radio-frequency spectrum for which the wireless service interface (140) is configured.

5. The controller (100) of any of the preceding claims, wherein the operator interface (120) is configured to boot and/or reboot separately from the processor (no).

6. The controller (100) of any of the preceding claims, wherein the operator interface (120) is configured to generate the system diagnostic information by processing the status data.

7. The controller (100) of any of the preceding claims, wherein the operator interface (120) is configured to render graphical elements representing values of the system diagnostic information.

8. The controller (100) of any of the preceding claims, wherein the operator interface (120) is configured to obtain the status data directly from the processor (no).

9. The controller (100) of any of the preceding claims, wherein the operator interface (120) is configured to obtain the status data from the memory buffer (130).

10. The controller (100) of any of the preceding claims, further comprising: a wired service interface (150) operable to grant a connecting wired device (183) read access to the memory buffer (130).

11. The controller (100) of any of the preceding claims, which is configured to control an industrial robot (290).

12. A method (400) of operating a controller (100) for an industrial system (190; 290), the method comprising: initializing (410) a processor (no) in the controller; reading (412), using the processor, sensor signals from sensors (191) arranged in the industrial system; deriving (414), using the processor, status data from the sensor signals; making (416) the status data available through a wirelessly accessible memory buffer (130) in the controller; and, if an operator interface (120) is not successfully initialized, granting (422) a connecting wireless device (182) read access to the memory buffer using a wireless service interface (140) in the controller.

13. The method of claim 12, further comprising: attempting (418) to initialize said operator interface (120); and if the operator interface is successfully initialized, providing (420) system diagnostic information on the basis of the status data and displaying this to an operator using the operator interface. 14- A computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out the steps of the method of claim 12 or 13.