U.S. patent application number 12/045605 was filed with the patent office on 2008-07-03 for method for remotely diagnosing devices.
This patent application is currently assigned to Sony Deutschland GmbH. Invention is credited to Ulrich Clanget, Paul SZUCS.
Application Number | 20080162994 12/045605 |
Document ID | / |
Family ID | 8179373 |
Filed Date | 2008-07-03 |
United States Patent
Application |
20080162994 |
Kind Code |
A1 |
SZUCS; Paul ; et
al. |
July 3, 2008 |
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.
Inventors: |
SZUCS; Paul; (Ostfildern,
DE) ; Clanget; Ulrich; (Stuttgart, DE) |
Correspondence
Address: |
OBLON, SPIVAK, MCCLELLAND MAIER & NEUSTADT, P.C.
1940 DUKE STREET
ALEXANDRIA
VA
22314
US
|
Assignee: |
Sony Deutschland GmbH
Berlin
DE
|
Family ID: |
8179373 |
Appl. No.: |
12/045605 |
Filed: |
March 10, 2008 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10303984 |
Nov 25, 2002 |
7370236 |
|
|
12045605 |
|
|
|
|
Current U.S.
Class: |
714/25 ;
714/E11.001; 714/E11.173 |
Current CPC
Class: |
G06F 11/2294
20130101 |
Class at
Publication: |
714/25 ;
714/E11.001 |
International
Class: |
G06F 11/00 20060101
G06F011/00 |
Foreign Application Data
Date |
Code |
Application Number |
Nov 28, 2001 |
EP |
01128244.9 |
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.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] 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
[0002] The invention relates to a method, a remote testing device,
a device and a system for remotely diagnosing devices.
BACKGROUND
[0003] 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.
[0004] 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.
[0005] 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
[0006] 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.
[0007] 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.
[0008] 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.
[0009] The method described above provides a common, transparent
mechanism for: [0010] obtaining information about the devices
present in a user's network as well as a connection topology of
said devices, [0011] issuing diagnostic test commands to individual
devices in the user's network, and [0012] obtaining the associated
test results.
[0013] 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.
[0014] 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).
[0015] 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.
[0016] 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.
[0017] 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.
[0018] 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.
[0019] 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.
[0020] 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.
[0021] 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.
[0022] 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.
[0023] 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.
[0024] 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
[0025] In the following description, further features and
embodiments of the present invention will be discussed while making
reference to the accompanying drawings, wherein:
[0026] 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;
[0027] 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;
[0028] 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;
[0029] 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;
[0030] 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;
[0031] 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.
[0032] FIG. 7 shows an example of visualizing topology issues of
interconnected devices according to the present invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0033] In the following description, a preferred embodiment of an
extension to the XML-language (RDML) will be given.
[0034] 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.
[0035] In this embodiment, all communication is done by command and
response tags (blocks). The general tag structure for a command
is:
TABLE-US-00001 <cmd> <name> command name </name>
<parameter> command parameter </parameter>
</cmd>
[0036] 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:
TABLE-US-00002 <response> response content
</response>
[0037] 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:
TABLE-US-00003 <exception> <errorcode> code
</errorcode> <message> text </message>
</exception>
[0038] 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.sup.15].
TABLE-US-00004 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
[0039] Preferably, a mechanism for custom error codes is provided.
Custom error code range is at ]2.sup.15 . . . 2.sup.16[. The
<message> tag is optional and may contain a detailed
description of the error.
[0040] 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:
TABLE-US-00005 <event> <name></name>
<content></content> </event>
[0041] 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:
TABLE-US-00006 <cmd> <name>protocol</name>
<parameter> <version> <major> x </major>
<minor> y </minor> <version> </parameter>
</cmd>
[0042] 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.
[0043] 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.
[0044] 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:
TABLE-US-00007 <cmd> <name>devicelist</name>
<parameter/> </cmd>
[0045] A corresponding response tag contains the list of devices,
and shows the following tag structure:
TABLE-US-00008 <devicelist> devices </devicelist>
[0046] wherein "devices" represents at least one of the following
tag structures:
TABLE-US-00009 <device> <guid> guid</guid>
<modelid>modelid </modelid> <flags>
flags</flags> </device>
[0047] 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
TABLE-US-00010 [0048] <device>
<guid>0800465788632</guid>
<modelid>MDA-LSA1</modelid>
<flags>00000001</flags> (LSB is set)
</device>
[0049] 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.
[0050] The command tag structure for retrieving the network
topology is:
TABLE-US-00011 <cmd> <name>networktopology</name>
<parameter/> </cmd>
[0051] The structure of a network topology, returned in a response
block with content <topology>, shows the following tag
structure:
TABLE-US-00012 <topology>
<networkstandard>standard1</networkstandard>
<nodes> nodes.... </nodes> <edges> edges....
</edges>
<networkstandard>standard2</networkstandard>
<nodes> nodes.... </nodes> <edges> edges....
</edges> ... </topology>
[0052] The whole topology contains a collection of network
standards, each of which contains a node list and an edge list.
[0053] The <networkstandard> tag may for example assign the
following lists of nodes and edges to their network technology:
TABLE-US-00013 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
[0054] Each node tag conforms to the syntax:
TABLE-US-00014 <node> <id> </id> <guid>
</guid> <label> </label> <description>
</description> </node>
[0055] 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.
[0056] Each network-standard-specific connection, whether real
(wired) or virtual (wireless) is documented as an edge block:
TABLE-US-00015 <edge> <source> </source>
<sink> </sink> </edge>
[0057] 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.
[0058] 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:
TABLE-US-00016 <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>
[0059] This method of representing graphs in XML can be seen as a
much more simple subset of XGMML (eXtensible Graph Markup and
Modeling Language).
[0060] 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:
TABLE-US-00017 <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`.
[0061] 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:
TABLE-US-00018 Error Code Description 50 Unknown event
[0062] 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:
TABLE-US-00019 <event>
<name>networktopology</name> <content/>
</event>
[0063] The content of the <networktopology> event is empty.
The client must acquire the actual network topology with a separate
call.
[0064] 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:
TABLE-US-00020 <cmd> <name>diagnostictest</name>
<parameter> <guid> </guid> <code>
</code> </parameter> </cmd>
[0065] 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:
TABLE-US-00021 <sdiresponse> <responsecode>
</responsecode> <description> <language>
</language> <text> </text> </description>
</sdiresponse>
[0066] If an error occurs during the test, an exception is thrown
with either a common error code or one of the following error
codes:
TABLE-US-00022 Error Code Description 30 Test timeout 31 Test
execution failure 32 Invalid test data 33 Unknown device
[0067] 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.
[0068] 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.
[0069] 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.
[0070] A first protocol stack 4 being located within the remote
testing device 1 comprises an IP-layer 4.sub.1, an TCP-layer
4.sub.2, a socket layer 4.sub.3, and an XML-client-module 4.sub.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.sub.1, a TCP-layer 5.sub.2, a socket layer 5.sub.3, and an
XML-server-module 5.sub.4, also referred to as RDML-server. Each
layer uses functionality of the respective underlying layer to
perform its tasks. The IP-layer 4.sub.1 of the first protocol stack
4 and the IP-layer 5.sub.1 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.
[0071] 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.sub.4. Results or device-specific data are supplied
to the RDML-server 5.sub.4 which uses above-described protocol
stack layers 5.sub.1 to 5.sub.3 to transmit this information back
to the remote testing device 1.
[0072] In a preferred embodiment, the RDML-server 5.sub.4 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.sub.4.
[0073] 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.sub.4. In the second scenario which deals with multiple DUTs 3 in
a home network, the complete functionality of the RDML-server
5.sub.4 as described above is needed to perform the diagnostic
process.
[0074] 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.
[0075] 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.
[0076] In a first step S1, the remote testing device 1 uses the
RDML-<devicelist> command tag to request the RDML-server
5.sub.4 of the DUT 3 to return device list information. The
RDML-server 5.sub.4 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.sub.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.
[0077] 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.sub.1. Then, the DUT 3 sends a device list back to the remote
testing device 1 which is indicated by a second arrow 9.sub.2. In
the second step, the remote testing device 1 sends a request to the
product data base 8, indicated by the third arrow 9.sub.3. The
product data base 8 sends back a corresponding set of information,
indicated by the fourth arrow 9.sub.4. 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.sub.5 to 9.sub.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.sub.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.sub.n+2.
[0078] 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.
[0079] A home network 10 comprises a home gateway as a first DUT
3.sub.1, a TV set as a second DUT 3.sub.2, a recording device as a
third DUT 3.sub.3, and a camcorder as a fourth DUT 3.sub.4. The
home gateway 3.sub.1 and the TV set 3.sub.2 are connected with each
other via network1 11 (cable), the TV 3.sub.2 and the recording
device 3.sub.3 are connected with each other via network2 12
(cable) and the home gateway 3.sub.1 and the camcorder 3.sub.4 via
network3 13 (wireless).
[0080] 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.sub.1 to 3.sub.4 with each
other which could also have something to do with the problem at
hand.
[0081] A preferred embodiment of respective protocol stacks used in
the network test scenario of FIG. 5 is shown in FIG. 6. Each DUT
3.sub.1 to 3.sub.4 comprises its own diagnostics module (a first to
fourth diagnose module 7.sub.1 to 7.sub.4) and its own protocol
stack (a first to fourth protocol stack 5.sub.1 to 5.sub.4).
[0082] The first and the fourth DUT 3.sub.1, 3.sub.4 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.
[0083] As can be taken from FIG. 6, the second DUT 3.sub.2
comprises an additional protocol stack 14 comprising a test
protocol layer 14.sub.1 and a non-IP network layer 14.sub.2.
Accordingly, in the third DUT 3.sub.3, another additional protocol
stack 15 is installed. The second DUT 3.sub.2 and the third DUT
3.sub.3 communicate with each other by respectively using said
additional protocol stacks 14 and 15. The second DUT 3.sub.2
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.sub.1, 3.sub.2, and 3.sub.4 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.sub.3 does not implement the IP protocol.
For the third DUT 3.sub.3 to be reachable for remote-testing via
RDML, the second DUT 3.sub.3 acts as a proxy for a legacy test
protocol implemented by the third DUT 3.sub.3, for example,
indicated by the additional protocol stacks 14 and 15.
[0084] 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.sub.1 to 3.sub.4 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.sub.1 to 3.sub.4.
* * * * *