METHOD FOR REMOTELY DIAGNOSING DEVICES

Abstract

A method for diagnosing devices via a remote testing device which is connectable to devices to be diagnosed via a communication network. Diagnosing is performed by exchanging diagnostics information between the remote-testing device and the devices to be tested via the communication network. The process of exchanging diagnostics information is at least partially done by using a communication protocol being based on XML-scripts which include the diagnostics information. The advantage of this method is a lean and platform-independent way of diagnosing devices, which enables to avoid unnecessary efforts and costs.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No. 10/303,984, filed Nov. 25, 2002, and is based upon and claims the benefit of priority from prior European Patent Application No. 01 128 244.9, filed Nov. 28, 2001. U.S. application Ser. No. 10/303,984 is incorporated herein by reference.

FIELD

The invention relates to a method, a remote testing device, a device and a system for remotely diagnosing devices.

BACKGROUND

It is known to diagnose devices from remote. Remote diagnostics makes it for example possible for users of home network devices to get immediate help from a service company if the users have problems to use said devices: The service company may for example diagnose the internal state of a home network device from remote, thus determining the kind of problem to be solved. Often it is even possible to “repair” home network devices from remote (for example by a parameter setting process), thus enabling the service company to save a lot of effort and costs.

Different users of home networks, however, may deploy different network technologies which may be wired and wireless network technologies. Therefore, it is often difficult for the service companies to diagnose said devices, since it is not always clear which specific network technology (for example which communication protocol) has to be used in order to deal with a specific home network device to be diagnosed.

As an example of a possible network technology, document WO 00/45265 discloses to use SNMP (Simple Network Management Protocol) to test devices remotely. However, SNMP is a very complicated protocol showing only low efficiency. Bandwidth capacity is needed for information which is not important, such as the SNMP version (transmitted in every SNMP message) and multiple length and data descriptors scattered throughout each message. The way that SNMP variables are identifiers (byte strings where each byte corresponds to a particular node in the MIB data base) leads to unnecessary large data units that consume substantial parts of each SNMP message.

SUMMARY

It is an object of the present invention to provide a method for diagnosing devices which avoids unnecessary information overheads while at the same time being capable to deal with various kinds of network technologies employed by respective devices to be diagnosed.

To solve this object, the present invention provides a method for diagnosing devices. Further, the invention provides a remote testing device. Also, the present invention provides a device. Further, the present invention provides a system for remotely diagnosing devices. Last, a computer program product is provided. Further features and embodiments of the present invention are respectively defined in respective subclaims.

According to the present invention, the method for diagnosing devices uses a remote testing device which is connectable to devices to be diagnosed via a communication network. The diagnosing is performed by exchanging diagnostics information between the remote testing device and the devices to be tested via the communication network. An important aspect of the invention is that the process of exchanging diagnostics information is at least partially done by using a communication protocol being based on XML-scripts which include said diagnostics information.

The method described above provides a common, transparent mechanism for:

• • obtaining information about the devices present in a user's network as well as a connection topology of said devices,
  • issuing diagnostic test commands to individual devices in the user's network, and
  • obtaining the associated test results.

XML (Extensible Mark-Up Language) is already in wide-spread use for a platform-independent communication between devices. Thus, the use of XML-scripts enables to deploy a common communication mechanism regardless of the remote tester computer platform (remote testing device), the various device-under-test-platforms, and the specific network technologies underlying XML. As a result, a service company which has to diagnose a device (for example arbitrary consumer-type equipment) from remote does not have care about technical details of respective network communication technologies which enables to very easily diagnose a broad variety of devices. Further, XML provides a lean way to communicate, thus avoiding unnecessary overheads.

Preferably, the XML-scripts employed by the present invention are defined as an extension to the XML-language, said extension enabling XML to be used for remote diagnosis by defining a mechanism for sending test commands to remotely located devices to be tested and obtaining the results of such tests. Said extension will be specified in detail later on and will be also referred to as Remote Diagnosis Mark-Up Language (RDML).

In a preferred embodiment, the XML-scripts comprise XML-tag structures which respectively contain parts of said diagnostics information. Using these tag structures, exchanging diagnose command information can be realized by using command tag structures containing diagnose command information within the XML-scripts. Accordingly, exchanging diagnose response information can be realized by using response tag structures containing diagnose response information within the XML-scripts.

In a preferred embodiment, a diagnostic protocol agreement between the remote testing device and the devices to be diagnosed is performed at the beginning of a diagnosing process. The diagnostic protocol agreement specifies which specific XML-syntax has to be used within said XML-scripts when exchanging diagnostics information in the further communication process. For example, a protocol tag structure may be used to exchange diagnostic protocol information, thereby performing the protocol agreement.

In the foregoing description, it has been assumed that the remote testing device as well as the devices to be tested/diagnosed directly support XML-based communication. However, it may be the case that a device to be diagnosed does not directly support XML, which means that this device can only be diagnosed by using a device specific diagnose protocol. In this case, XML-scripts are used to exchange the diagnostics information between the remote testing device and a gateway interfacing the remote testing device and the device to be diagnosed. A device-specific diagnose protocol is then used to exchange the diagnostics information between the gateway and the device to be tested, wherein the gateway transfers the diagnostics information from/to the XML-scripts to/from the device-specific diagnose protocol. In other words, the gateway which may be a device to be tested itself functions like a communication protocol-transferring engine. Thus, even in this case, a service company does not have care about device-specific network technologies, since a possible protocol conversion is completely executed by a respective gateway.

To perform the above-described method, it is necessary that the devices to be tested/diagnosed (also only referred to as devices) as well as the remote testing device comprise specific functionality, respectively. Therefore, the present invention provides a remote testing device being connectable to devices to be diagnosed via a communication network, said remote testing device comprising communication means for sending/receiving diagnostics information to/from the devices to be diagnosed, wherein the communication means comprise an XML-client-module having functionality to use XML-scripts as a communication protocol for sending/receiving the diagnostics information.

The XML-client-module is preferably realized as a software module installed within the remote testing device. The base layer to perform communication preferably is an Internet Protocol (IP) layer, the first layer above the Internet Protocol layer preferably is a Transport Control Protocol (TCP) layer, wherein above the Transport Control Protocol layer preferably a further socket layer is provided. The XML-client-module uses functionality of the socket layer in order to perform respective communication tasks. The remote testing device advantageously comprises embedding means for embedding the diagnostics information into the XML-scripts for sending the scripts together with respective diagnose information to the devices to be tested. Accordingly, the remote testing device may comprise extracting means for extracting diagnostics information from XML-scripts received from the devices to be diagnosed/tested.

The invention further provides a device being connectable to a remote testing device via a communication network, said device comprising communication means for sending/receiving diagnostics information to/from said remote testing device, wherein said communication means comprises an XML-server-module having functionality to use XML-scripts as a communication protocol for sending/receiving the diagnostics information. The device may be a device to be tested itself as well as a gateway interfacing a device to be tested and the remote testing device.

Preferably, the device comprises diagnosing means being connected to the communication means for executing diagnostics tasks in dependence of said diagnostics information. To enable a proper communication between the XML-server-module and the XML-client-module, the communication means of the device in an analogous manner comprises an Internet Protocol layer, a Transport Control Protocol layer being based upon said Internet Protocol layer, a socket layer being based upon said Transport Control Protocol layer, wherein the XML-server-module uses the functionality of the socket layer to perform respective diagnosis communication tasks. In addition, also said device may comprise extracting means for extracting diagnostics information from the XML-scripts and/or embedding means for embedding diagnostics information into the XML-scripts.

In a preferred embodiment, the device comprises communication protocol converting means for transferring diagnostics information from/to the XML-scripts to/from a device-specific diagnose protocol, as already indicated above. To use the device-specific diagnose protocol, a device may comprise a device-specific diagnose protocol layer usable by the XML-server-module to exchange the diagnostics information with a device to be diagnosed which is connectable with the XML-server-module via the device-specific diagnose protocol layer.

The present invention further provides a system for remotely diagnosing devices which comprises a remote testing device according to the present invention, and at least one device to be diagnosed according to the present invention, wherein the remote testing device and the at least one device to be diagnosed are respectively connected via the communication network.

Finally, the present invention provides a computer program product comprising computer program means adapted to perform the method steps according to the present invention or any step thereof when it is executed on a computer, a digital signal processor or the like.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following description, further features and embodiments of the present invention will be discussed while making reference to the accompanying drawings, wherein:

FIG. 1 shows a schematic drawing illustrating the correlation between a remote testing device and a device to be diagnosed according to the present invention;

FIG. 2 shows a preferred embodiment of a protocol stack used to communicate between the remote testing device and the devices to be diagnosed according to the present invention;

FIG. 3 shows a flow-chart illustrating respective steps performed when communicating between a remote testing device and a device to be tested according to the present invention;

FIG. 4 shows a sequence diagram illustrating respective steps performed when communicating between a remote testing device and the devices to be tested according to the present invention;

FIG. 5 shows the relationship between the remote testing device and devices to be tested in the case that the devices to be tested are interconnected within a respective home network according to the present invention;

FIG. 6 shows respective protocol stacks of a preferred embodiment used when having a network structure as shown in FIG. 5 according to the present invention.

FIG. 7 shows an example of visualizing topology issues of interconnected devices according to the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

In the following description, a preferred embodiment of an extension to the XML-language (RDML) will be given.

Generally, this embodiment of RDML consists of two parts, namely network information retrieval and device diagnostics. The network information retrieval part enables a service center using the remote testing device to find out which devices to be tested are connected by which network technologies (for example in the user's (home) network), and the actual topology of the whole network. The device diagnostics part enables the service center to address diagnostic test commands to a particular device in the home network and retrieve the result of that test or device status. The execution and communication of diagnostic tests will be network-dependent in the home network, if an end device to be tested does not support the IP-protocol (for example SDI-based communications used for non-IP devices connected via i.Link), but the content and transfer of information between the service center and a gateway interfacing said device is common, i. e. is based on RDML. In other words, all home network devices not supporting IP communication mechanisms and therefore not supporting XML-based communications are hidden behind a gateway supporting IP/XML communication which acts as an interface between the remote testing device and the devices to be diagnosed. All other home network devices may be directly addressed by the remote testing device without using the gateway, but nevertheless it may be communicated via the gateway which in this case has a router function.

In this embodiment, all communication is done by command and response tags (blocks). The general tag structure for a command is:

<cmd>
<name> command name </name>
<parameter>
command parameter
</parameter>
</cmd>

If no parameters are passed for a particular command, then the <parameter> block will be empty, signified by the <parameter/> tag. The general tag structure for a response is:

<response>
response content
</response>

If an error occurs while executing an RDML command set, an exception is thrown (enclosed in a response tag) and is delivered back to the command initiator (remote testing device). The general structure of an exception is:

<exception>
<errorcode> code </errorcode>
<message> text </message>
</exception>

The <errorcode> is an unique integer identifier for the occurred error. There are some standard codes defined for common errors. Standard error codes are in range [0 . . . 2¹⁵].

Error Code Description
0          Unknown error (should not be
           used)
1          Service unavailable
10         Unknown command
11         Incomplete/invalid parameter
12         Protocol error
20         Home network failure
21         Network failure

Preferably, a mechanism for custom error codes is provided. Custom error code range is at ]2¹⁵ . . . 2¹⁶[. The <message> tag is optional and may contain a detailed description of the error.

RDML supports an event mechanism which enables clients (for example the remote testing device) to get status changes in the home network. An event is defined as follows:

<event>
<name></name>
<content></content>
</event>

Before exchanging/processing any command tags, a protocol agreement must be performed. To start said protocol agreement, the client uses the following tag structure as protocol command:

<cmd>
<name>protocol</name>
<parameter>
<version>
<major> x </major>
<minor> y </minor>
<version>
</parameter>
</cmd>

The <version> parameter contains the major and minor version number. For example, the major version number is 1 and the minor version number is 0.

To perform the protocol agreement, the client sends the protocol command with the highest protocol version it supports. The server (for example device to be diagnosed) reads the protocol version and sends its highest protocol version back to the client (enclosed in a response tag). The client and the server now agree on the minimum of the two delivered versions.

To get an overview of the devices in the (home) network, the RDML server supports a command to get a list of all devices. The command has the simple tag structure:

<cmd>
<name>devicelist</name>
<parameter/>
</cmd>

A corresponding response tag contains the list of devices, and shows the following tag structure:

<devicelist>
devices
</devicelist>

wherein “devices” represents at least one of the following tag structures:

<device>
<guid> guid</guid>
<modelid>modelid </modelid>
<flags> flags</flags>
</device>

where “guid” (global unique identifier) is a unique reference to the device in question like its serial number or the IEEE1394 GUID. “modelid” contains a string for the model class of the device, and “flags” defines properties for this device. The properties format may be a 32 bit mask, converted to a hexadecimal representation without a leading “0x”. For example, only one property is defined: diagnostics support. This flag signifies whether the “standard” network-specific test/diagnostics mechanism is supported by that device. For example, for i.LINK this flag signals support of SDI. If diagnostics is supported by the device, the LSB (least significant bit) in flags should be set.

EXAMPLE

<device>
<guid>0800465788632</guid>
<modelid>MDA-LSA1</modelid>
<flags>00000001</flags> (LSB is set)
</device>

The network topology defines the structure of the home network (which devices are directly connected and which device is the root of the network). The topology for an IEEE1394 network has the structure of a tree, but other networking technologies have different topology structure. For RDML, preferably a common representation for all networking technologies is used, in the following referred to as “graphs”. In the graph topology, nodes represent devices, and each edge defines a connection between devices. In wired networking technologies, this is a cable, in wireless networks this is a virtual connection. For wired-wireless bridges, the topology reveals which device is acting as the bridge for any particular wireless device.

The command tag structure for retrieving the network topology is:

<cmd>
<name>networktopology</name>
<parameter/>
</cmd>

The structure of a network topology, returned in a response block with content <topology>, shows the following tag structure:

<topology>
<networkstandard>standard1</networkstandard>
<nodes>
nodes....
</nodes>
<edges>
edges....
</edges>
<networkstandard>standard2</networkstandard>
<nodes>
nodes....
</nodes>
<edges>
edges....
</edges>
...
</topology>

The whole topology contains a collection of network standards, each of which contains a node list and an edge list.

The <networkstandard> tag may for example assign the following lists of nodes and edges to their network technology:

Network Standard          Tag value
IEEE1394 standard wired   IEEE1394-1995
IEEE1394a                 IEEE1394-2000
IEEE1394b high speed/long IEEE1394b
reach                     Ethernet
IEEE802.3                 IEEE802.11b
IEEE802.11b wireless      HiperLAN/2
ETSI Hiperlan/2 wireless  Bluetooth
Bluetooth                 IEEE802.11a
IEEE802.11a wireless

Each node tag conforms to the syntax:

<node>
<id> </id>
<guid> </guid>
<label> </label>
<description> </description>
</node>

An RDML node tag contains four subtags. <id> is a unique arbitrary integer to identify each node in the edges list. The <guid> tag is used to assign each node to a unique network-standard-specific device identifier. The <label> tag preferably is a short description of the device, normally the model name. The <description> tag enhances the label description.

Each network-standard-specific connection, whether real (wired) or virtual (wireless) is documented as an edge block:

<edge>
<source> </source>
<sink> </sink>
</edge>

To define a connection between nodes, an edge list is supported. An edge contains a source and a destination node, called sink. While the terms “source” and “sink” imply a direction in the connection, this is not relevant to most networking technologies and may be ignored in that sense. These terms have been taken from standard network graph theory.

An example for a network topology is shown in FIG. 7. In this topology, a gateway 20 is connected to a DVB tuner 21 and a mini disc deck 22. The mini disc deck 22 itself is connected to a CD player 23 and an amplifyer 24. The topology of this example can be expressed as follows:

<topology>
<networkstandard>
IEEE1394-1995
</networkstandard>
<nodes>
<node>
<id>0</id>
<label>Gateway</label>
<guid>0800460578632</guid>
<description>Home Network Gateway</description>
</node>
<node>
<id>1</id>
<label>DVB-ATCS</label>
<guid>0800460578633</guid>
<description>Digital Satellite Receiver</description>
</node>
<node>
<id>2</id>
<label>MDS-LSA1</label>
<guid>0800460578634</guid>
<description>Mini Disc</description>
</node>
<node>
<id>3</id>
<label>CDP-LSA1</label>
<guid>0800460578635</guid>
<description>CD Player</description>
</node>
<node>
<id>4</id>
<label>STR-LSA1</label>
<guid>0800460578636</guid>
<description>Receiver</description>
</node>
</nodes>
<edges>
<edge>
<source>0</source>
<sink>1</sink>
</edge>
<edge>
<source>0</source>
<sink>2</sink>
</edge>
<edge>
<source>2</source>
<sink>3</sink>
</edge>
<edge>
<source>2<source>
<sink>4</sink>
</edge>
</edges>
<topology>

This method of representing graphs in XML can be seen as a much more simple subset of XGMML (eXtensible Graph Markup and Modeling Language).

The RDML server supports an event mechanism which enables clients to get a reltime view of the inspected home network environment. A client must register himself to get the network update events. The registration is done by the registerevent command:

<cmd>
<name>registerevent</name>
<parameter>
<event> </event>
</parameter>
</cmd>

The event to register is specified via the <event> tag. In case of the network topology update the event name is ‘networktopology’.

If an error occurs during the event registration, an exception is thrown with either a common error code or one of the following error codes:

Error Code Description
50         Unknown event

If the network topology changes, the client receives an asynchronous event on the same connection as the command pipe. This event has the following structure:

<event>
<name>networktopology</name>
<content/>
</event>

The content of the <networktopology> event is empty. The client must acquire the actual network topology with a separate call.

Performing diagnosis tests is done on the basis of sending a test command and receiving a response code and optional readable text describing the result of the test. Thus, this part of RDML gives for example a network-independent abstraction of an IEEE1394-specific test and diagnosis mechanism. A test command is bundled in the following XML structure:

<cmd>
<name>diagnostictest</name>
<parameter>
<guid> </guid>
<code> </code>
</parameter>
</cmd>

where <guid> is the unique id for the DUT (Device Under Test) returned by the devicelist command and <code> is an integer preferably coded in hexadecimal format without a leading 0x. The response contains a response code for example in a hexadecimal format (31 bit when dealing with IEEE1394 devices which support SDI (Service Diagnostic Interface, see for example European Patent Application No. 01 102 231.6)) and a description of the test result in a specified language:

<sdiresponse>
<responsecode> </responsecode>
<description>
<language> </language>
<text> </text>
</description>
</sdiresponse>

If an error occurs during the test, an exception is thrown with either a common error code or one of the following error codes:

Error Code Description
30         Test timeout
31         Test execution failure
32         Invalid test data
33         Unknown device

In the following description, making reference to FIG. 1, the principle of the communication between a remote testing device and a device to be tested will be described.

A remote testing device 1, for example a computer, is linked via an IP-based network connection, for example the Internet 2, to a device to be tested/diagnosed 3 also referred to as DUT (Device Under Test). The remote testing device 1 sends diagnostics information in form of XML-scripts via the IP-based network connection 2 to the DUT 3 which processes the information, eventually performs self-diagnostic tasks and sends respective results in form of XML-scripts via the IP-based network connection 2 back to the remote testing device 1.

Referring to FIG. 2, a preferred embodiment of a protocol stack used to communicate between the remote testing device 1 and the DUT 3 will be discussed.

A first protocol stack 4 being located within the remote testing device 1 comprises an IP-layer 4₁, an TCP-layer 4₂, a socket layer 4₃, and an XML-client-module 4₄, also referred to as RDML-client. In an analogous manner, a second protocol stack 5 being located within a DUT 3 comprises an IP-layer 5₁, a TCP-layer 5₂, a socket layer 5₃, and an XML-server-module 5₄, also referred to as RDML-server. Each layer uses functionality of the respective underlying layer to perform its tasks. The IP-layer 4₁ of the first protocol stack 4 and the IP-layer 5₁ of the second protocol stack 5 are interconnected via an IP-based connection 6. The first protocol stack 4 and the second protocol stack 5 are preferably realized as software modules and can be regarded as part of respective communication means.

The DUT 3 further comprises a diagnose module 7 for performing self-tests, providing device-specific information and the like. The diagnose module 7 performs respective tasks in response to a communication process with the remote testing device 1 in dependence of diagnostics information provided by the RDML-server 5₄. Results or device-specific data are supplied to the RDML-server 5₄ which uses above-described protocol stack layers 5₁ to 5₃ to transmit this information back to the remote testing device 1.

In a preferred embodiment, the RDML-server 5₄ listens for client requests on the prescribed socket. A test process being executed by the diagnose module 7 is initiated by the RDML-client 4₄.

In the following, two test scenarios are described. The first is to use a single DUT 3. Here, the remote testing device 1 just uses the functionality of the testing part of the RDML-server 5₄. In the second scenario which deals with multiple DUTs 3 in a home network, the complete functionality of the RDML-server 5₄ as described above is needed to perform the diagnostic process.

In the case of using just one single DUT 3, the remote testing device 1 uses the “devicelist” command to determine what kind of device the DUT 3 is. On account of the model ID returned by the DUT 3, the remote testing device 1 then locally retrieves information (for example from a attached product database) about which tests are implemented on this DUT 3. The remote testing device 1 then proceeds with issuing RDML-test commands to the DUT 3.

In the following, making reference to FIG. 3, a preferred sequence of establishing and performing a diagnostic session with the single DUT 3 after the point of physical connection set-up is shown. This is common to all types of access network. All transitions in the sequence diagram between the remote-testing device 1 and the DUT 3 involve the transfer of RDML-content over IP, as described above.

In a first step S1, the remote testing device 1 uses the RDML-<devicelist> command tag to request the RDML-server 5₄ of the DUT 3 to return device list information. The RDML-server 5₄ executes this command using the RDML-<devicelist> response tag with appropriate contents. In a second step S2, the remote testing device inquires a product data base (not shown) being connected to the remote-testing device 1 as to which tests the respective DUT 3 supports, as well as expected and possible test results and status. In a third step S3, the remote-testing device 1 initiates respective tests on the DUT 3. To do this, the RDML-client 4₄ could be an application comprising either a manual user interface-driven software operated by test personal, or an automated software agent deriving enough intelligence from the product data base in the implemented test in order to purposefully diagnose the DUT 3 and its interconnects. Preferably, this step S3 involves many exchanges of RDML-tests, RDML-responses, and getstatus tag blocks between the remote testing device 1 and the DUT 3. In a fourth step S4 it is decided whether a problem has been to be diagnosed. If this is the case, then in a fifth step a respective solution is provided. In the ideal case, the result of the test session is that a user or a DUT problem has been solved by some parameter setting, or by a hint submitted to the user. Other possibilities are that a required spare part for a repair is ascertained, and necessary information about this case is passed to other instances for completion. In case that the problem has not been diagnosed by a specific test, another test may be initiated by the remote-testing device 1. After having finished the diagnose session illustrated by FIG. 3, in a sixth step S6 the physical connection between the remote testing device 1 and the respective DUT 3 is closed.

In FIG. 4, it is illustrated between which devices communication takes place when executing the first to sixth step S1 to S6 of FIG. 3. In the first step S1, remote testing device 1 sends a first request to the DUT 3, indicated by the first arrow 9₁. Then, the DUT 3 sends a device list back to the remote testing device 1 which is indicated by a second arrow 9₂. In the second step, the remote testing device 1 sends a request to the product data base 8, indicated by the third arrow 9₃. The product data base 8 sends back a corresponding set of information, indicated by the fourth arrow 9₄. Then, in the third step S3, several requests and answers are performed between the remote testing device 1 and the DUT 3, indicated by the fifth arrow to the n-th arrow 9₅ to 9_n. Last, in the fifth step S5, the remote testing device 1 provides a solution to the DUT 3, indicated by the (n+1)-th arrow 9_n+1. The DUT 3 communicates to the remote testing device 1, if the solution-providing process has been successfully completed, indicated by the (n+2)th arrow 9_n+2.

In the following description, making reference to FIG. 5, a network test scenario is presented in which the devices to be diagnosed are home network devices being connected with partly different network technologies.

A home network 10 comprises a home gateway as a first DUT 3₁, a TV set as a second DUT 3₂, a recording device as a third DUT 3₃, and a camcorder as a fourth DUT 3₄. The home gateway 3₁ and the TV set 3₂ are connected with each other via network1 11 (cable), the TV 3₂ and the recording device 3₃ are connected with each other via network2 12 (cable) and the home gateway 3₁ and the camcorder 3₄ via network3 13 (wireless).

The remote testing device 1 receives, when applying the RDML-“devicelist” command, the information that there are several devices present. Thus, the remote testing device 1 then uses the “network topology” command to establish the nature of the network connecting the first to fourth DUTs 3₁ to 3₄ with each other which could also have something to do with the problem at hand.

A preferred embodiment of respective protocol stacks used in the network test scenario of FIG. 5 is shown in FIG. 6. Each DUT 3₁ to 3₄ comprises its own diagnostics module (a first to fourth diagnose module 7₁ to 7₄) and its own protocol stack (a first to fourth protocol stack 5₁ to 5₄).

The first and the fourth DUT 3₁, 3₄ show the same construction as that of the DUT 3 described in conjunction with FIG. 2, and a further description within this respect will be omitted therefore.

As can be taken from FIG. 6, the second DUT 3₂ comprises an additional protocol stack 14 comprising a test protocol layer 14₁ and a non-IP network layer 14₂. Accordingly, in the third DUT 3₃, another additional protocol stack 15 is installed. The second DUT 3₂ and the third DUT 3₃ communicate with each other by respectively using said additional protocol stacks 14 and 15. The second DUT 3₂ further comprises functionality for converting diagnostics information from/to XML scripts to/from the device-specific diagnose protocol. In other words, the first, second, and fourth DUT 3₁, 3₂, and 3₄ are IP-enabled devices, each device having an RDML-server capable to receive and process RDML-scripts addressed to them coming from the remote testing device. The third DUT 3₃ does not implement the IP protocol. For the third DUT 3₃ to be reachable for remote-testing via RDML, the second DUT 3₃ acts as a proxy for a legacy test protocol implemented by the third DUT 3₃, for example, indicated by the additional protocol stacks 14 and 15.

The remote testing device 1 uses the RDML <networktopology> command tag to request an RDML server to return topology information. The server does this using the RDML <networktopology> response tag with appropriate contents. This step is done in addition to the first step S1, wherein the rest of the diagnost procedure for each DUT 3₁ to 3₄ is the same as that previously described in the context for a single DUT 3: The remote testing device 1 retrieves each different DUT's set of implemented tests preferably from a database and executes them on the respective DUT's 3₁ to 3₄.

Claims

1. A method for diagnosing devices via a remote testing device which is connectable to devices to be diagnosed via a communication network, wherein said diagnosing is performed by exchanging diagnostics information between said remote testing device and said devices to be tested via said communication network,

wherein said diagnostics information is included within XML-scripts being exchanged between said remote testing device and said devices to be tested, wherein said XML-scripts constitute XML-language extensions, the method comprising:

providing a diagnosing unit within each of the devices;

implementing self-tests in each diagnosing unit;

requesting by the remote testing device execution of at least one self-test; and

executing said diagnostics self-tests based on said diagnostics information received from said remote testing device.