WO2001028060A1

WO2001028060A1 - Digital testing device

Info

Publication number: WO2001028060A1
Application number: PCT/IL2000/000639
Authority: WO
Inventors: Ofir Efrati
Original assignee: Comlog Telecommunications Engineering Ltd.
Priority date: 1999-10-11
Filing date: 2000-10-10
Publication date: 2001-04-19
Also published as: IL132328A0; AU7815200A; EP1232552A1

Abstract

A digital testing device using protocols to evaluate a system under test (50).

Description

Digital Testing Device

Field of the Invention The present invention relates to a digital testing device, and more particularly but not exclusively to a digital testing device and method for use in the data communications and telecommunications fields.

Background of the Invention

Modern telecommunications systems are generally constructed of various elements capable of data processing and data communication support. The various elements may be interlinked in order to establish reliable data flow between the elements and in order to guarantee proper harmonic operation as one complete system. In passing through such systems digital data can be put through numerous complex processes, each using numerous protocols. For example, in digital communications, switching, modulating, encoding, decoding and numerous other operations are needed. Each operation involves a different algorithm or protocol or series thereof that must be thoroughly tested. The protocols may be standard protocols or they may be proprietary protocols unique to the equipment manufacturer. Frequently the manufacturer uses an in-house modification of a standard protocol. In general, each different protocol or group of similar protocols requires a different test device, and often even minor variations of the algorithm may require the use of a different device. A single communication system may combine equipment of several manufacturers. It may thus require numerous test devices and be very difficult to test. Furthermore, the different test devices generally do not work together and thus test of integrated scenarios is generally not possible.

Manufacturers find the use of proprietary algorithms helpful, however, one of the disadvantages of using such an algorithm is that time to market is delayed whilst a suitable test device can be designed and perfected.

In addition, data links occasionally make use of security algorithms such as encryption systems, which need to be safeguarded, and some manufacturers may wish to keep their proprietary algorithms secret. Summary Of The Invention

In accordance with a first aspect of the present invention there is provided a digital testing device comprising: at least one data interface, a plurality of predetermined protocols, a protocol selector for selecting any combination of said protocols to operate on said digital data, and an output for outputting results of applying said digital data to said selected protocols.

According to a second aspect of the present invention there is provided a digital testing device comprising: at least one data interface, a user interface, a protocol constructor operable to accept data from said user interface and to construct a protocol in accordance therewith, said protocol being able to operate on said digital data, and an output for outputting results of applying said digital data to said selected protocols.

According to a third aspect of the present invention there is provided a digital testing device comprising, at least one data interface, a plurality of predetermined protocols, a user interface, a protocol constructor operable to accept data from said user interface and to construct an additional protocol in accordance therewith, said protocol being able to operate on said digital data, a protocol selector for selecting any combination of said protocols to operate on said digital data and an output for outputting results of applying said digital data to said selected protocols..

A fourth aspect of the present invention comprises a digital simulation device which comprises the protocols, a protocol constructor, the user interface, a protocol selector and the output. Instead data is produced automatically within the device itself and sent via the interface

Preferably, the digital data is the output of all or part of a communications device. The device may be comprised within a computer. The output may comprise a configurable data protocol which may be set to find points of interest in the data under test. The input may comprise a selectable one of a plurality of device interfaces. The device interfaces are preferably designed with specific digital equipment in mind and may be operable to hide characteristics of the equipment from the device. Means are provided for enabling the user to generate new device interfaces or to configure existing device interfaces.

Embodiments of the invention are operable with any digital data.

The protocols referred to above preferably synthesize the data format of various communication protocols as used in communications engineering.

The protocols are preferably descendant objects of a protocol-independent parent object, which may alternatively be referred to as a virtual protocol. The protocol-independent parent object is preferably operable to support processing of data according to any predefined protocol, which may be a descendant object thereof. The algorithm-independent parent object may support certain desirable features such as smart filtering, triggering and simulation operations, which enhance testing ability. The protocols may be templates for arranging incoming data into the data field and packet format of any predetermined protocol or other communication algorithm.

The protocol constructor preferably comprises a bank of predefined protocol sub steps represented by visual items in the user interface, individually selectable by a user through said user interface to build a protocol.

The specific device interfaces referred to above are preferably represented by visual items in the user interface, individually selectable by a user through said user interface.

Embodiments of the invention may thus provide a multi-interface, multi-protocol analyzer and simulator for testing or simulating .complex communication systems involving any standard or proprietary protocol. The embodiments are based on a virtual protocol model.

In an embodiment, automatic association may be made between a given device interface and one of said plurality of protocols. In a further embodiment, external test devices may be integrated into the system using a suitably designed interface.

Embodiments of the invention may provide a device that can test an entire telecommunication system comprising equipment from numerous manufacturers, using a plurality of ports each of which can be programmed to operate on a different protocol, and which can be associated logically one with the other. The device may enable a reduction in development time and cost.

Brief Description of the Drawings For a better understanding of the invention and to show how the same may be carried into effect, reference is now made, purely by way of example, to the accompanying drawings, in which:

Fig. 1 is a simplified diagram of a first embodiment of a device according to the invention, Fig. 2 is a generalized block diagram of a device according to a preferred embodiment of the present invention,

Fig. 3 is a generalized layer diagram of an embodiment of the present invention,

Fig. 4 is a generalized diagram showing in more detail the virtual protocol model core of

Fig. 3,

Fig. 5 is a screen view of an exemplary protocol of the kind described in Fig. 4, as seen from within the protocol designer, Fig. 6 shows the first step in the process of designing an object for testing a proprietary protocol,

Fig. 7 is a screen view showing how the user interface 26 permits selection of a prestored interface for the interface object,

Fig. 8 is a screen view of available protocols including that defined in Fig. 6,

Fig. 9 is a screen view showing a new logical channel configured with a protocol and physical interface,

Fig. 10 is a tree diagram showing a tree object based on the protocol shown in Fig. 6,

Fig. 1 1 is a screen view showing the monitor output when test data bytes arrive and fit into the protocol tree as shown in Fig. 10, and

Fig. 12 is a screen view showing a capture filter for monitoring the results of the analysis of Fig. 11.

Description of the Preferred Embodiments

Reference is firstly made to Fig. 1, which is a simplified diagram of a first embodiment of a device according to the invention. An interface connector 10 is attachable to a telecommunications system unit 12 or other communication device, in such a way that it is able to extract data for testing. The interface connector is attached to a portable, or other, computer 14, which carries out an analysis of the extracted data. The interface connector is simply a buffering device allowing data from the exchange unit 12 to reach an input port of the computer 14. In some embodiments, buffering may not be necessary.

The use of a general-purpose computer for carrying out the analysis of the extracted data is preferred but not essential. As an alternative, it is possible to use a dedicated digital device.

Reference is now made to Fig. 2, which is a generalized block diagram of a device according to a preferred embodiment of the present invention. It is to be borne in mind that the invention does not solely encompass the device configured for use but also relates to the features of the device that aid easy configuration and also to the method of configuration.

In Fig. 2, a device interface 20 provides interfacing with the equipment to be tested. The interface is preferably selected to be specific to the equipment and is operable to hide hardware features of the equipment under test from the device.

A protocol bank 22 comprises a plurality of predefined protocols PI...PN, all of which are designed to simulate the operation, on a datastream, of a specific item of equipment. The relevant protocol or protocols are selected by the user through a protocol selector screen of a user interface (Fig. 8 below). The user interface is preferably a visual interface; wherein objects to be selected by the user are generally presented as graphical icons.

In the event that the desired protocol is not present, the device allows for the easy addition of new protocols. This may be done by obtaining a predefined protocol from an external source such as the Internet, or it may be done by use of a protocol designer (46 in Fig.3). The protocol designer 46 contains a bank of protocol substeps (not shown), which are preferably represented by icons in the user interface. The user is able to select from the substeps to build his own protocol P_New, as will be explained in greater detail below. The newly formed protocol is then available for protocol selection in the same way as the predefined protocols P_I...P_N

An output unit 32, again configurable through the user interface, filters the output data for interpretation by the user. User configurable filters F_I .. .F are stored in a filter bank 24 and customization thereof will be discussed below with respect to Fig. 12. User configurable triggers T_L .. T_K, for triggering test operations and the like, are stored in a trigger bank 26 and are likewise customizable through the user interface.

As will be discussed below, devices according to the present invention may run simulations as well as tests. Thus a bank of prestored and configurable simulations is stored in a simulation bank 28.

A virtual protocol model core 30 is a parent object that encapsulates a generic description of a communication protocol. It is preferably able to take on the characteristics of any protocols and the like that are applied to it. This is because all of the protocols etc. that have been discussed with respect to Fig. 2 are preferably defined as descendant objects thereof, as will be discussed in more detail below. An advantage of such a parent descendant arrangement is that when a protocol is prepared and or applied by a user, it requires no compilation or pre-processing but rather can be used immediately.

Reference is now made to Fig. 3, which is a generalized layer diagram of an embodiment of the present invention. A virtual protocol model core 40, as discussed above, is a parent object that encapsulates a generic description of a communication protocol. Three types of descendant objects of the core 40 are defined as a protocol simulator 42, a protocol analyzer 44 and a protocol designer 46. The protocol designer allows for the definition of a new protocol using the user interface as discussed above. A dedicated language is preferably used in order to facilitate the application of the virtual protocol by which the new protocol is to be described. The dedicated language preferably permits the creation of any combination of protocol layers by applying the object-oriented concept (inheritance & encapsulation). A simple linkage between protocol components can lead to the construction of a wide and complex protocol library, where each protocol is built from very simple protocol components.

The user interface preferably provides a visual protocol designer utility, as mentioned above, which allows the construction of protocol components without the user needing to be familiar with the modeling language.

The protocol analyzer 44 allows for analysis of any protocol added to the protocol model core, or any set or combination of protocols. The protocol simulator 42 allows for the simulation of any protocol, or set or combination thereof added to the model core 40.

A further parent object is the device interface object 48, which is a generic model of a device data interface. A specific interface object appropriate to the system under test 50 and which is a descendant of the generic interface object, is preferably selected as described above. The model core, as mentioned, is preferably hardware independent. It is preferably data frame oriented, which means that any data pattern can be analyzed or generated as long as it is bit oriented. The specific interface object 48 permits easy interfacing with external hardware. The generic interface object 48 preferably comprises several interface functions that hide hardware dependent parameters.

A plurality of interfaces may be used at the same time so that more than one data channel or device may be tested simultaneously. Preferably, the device is configurable so that logical connections are provided between different channels. Thus, the data connected over numerous different channels can be analyzed as a single logical unit. Likewise, in simulation, several devices or data channels may be simulated simultaneously and logical connections may be configured between them.

A series of logical connections may be configured and particular series of data may be tested to produce logical scenarios. This may be done as part of testing or as part of a simulation or as a combination of the two.

If testing of communications equipment is being carried out then the interface is used to obtain data from the equipment. It can also return data to the equipment, as part of a simulation and thus serve as a link in an operational connection. The interface may be a single channel or it may be multi-channel, allowing the testing of combined systems or testing of combined systems simultaneously.

If simulation is being carried out then the data interface may be dispensed with, and an embodiment built solely for simulation need not comprise a data interface.

Reference is now made to Fig. 4, which is a generalized diagram showing in more detail the virtual protocol model core of Fig. 3. As mentioned above, the virtual protocol model is a non-specific protocol analyzer. It analyzes collected data according to a predefined protocol, that is to say one of the protocols referred to above. The model is based on the OSFs layered model and supports among other the following main features:

Multi-layer analysis,

Any field, any data format and any intelligent algorithm concerning data processing, and

Multi channel analysis/data generation in parallel.

A tree structure is an optimal structure for presentation of any protocol, algorithm or filter. In general, a predefined protocol is maintained as a tree object, that is to say a descendent of the generalized tree structure. Figure 4 is a generalized tree structure, designed for an embodiment of the present invention, in which the various nodes can be defined with properties of the protocol (nodes 60, 62 64 and 66) or they may lead to a whole new layer of nodes, (sub-node 68). A second layer is shown explicitly but the only limit on the number of layers that may be included is the available memory. That is to say the number of layers is practically unlimited. The existence of one or more sub-layers, each of which can be constructed with any degree of complexity, gives the embodiments of the present invention the degree of flexibility necessary to apply testing to a wide variety of devices and protocols.

Each node in the tree may indicate a field, a group of fields or a sub-protocol layer. A field is an abstract term that covers a data pattern, ranging from a single bit to an endless chain of bit-data. A branch in the tree represents a branch in the protocol. Such a branch may, for example, be represented by the command "separate two messages by a message type field". Numerous other functions and properties may be added to the tree to allow flexibility and automation of the data process/generation.

Examples of the kind of properties that may be comprised in nodes within the tree are:

Automatic check sum data fields,

Variable length of data field according to dynamic conditions (dependent on other received data),

Data masking and pattern comparison,

Idle line timeout, and

Data size trash hold.

The virtual protocol model core permits the integration of externally provided data processes that have been generated by users in the way described above. The internal working of the externally provided processes are preferably totally hidden from the model core itself, and this is achieved by utilizing an external DLL (Dynamic Link Library). Any node in the virtual protocol tree can be assigned to such a DLL. This feature is important, for example if the user wishes to safeguard protocols involving security applications and the like. The data processes referred to include both the protocols and the data interfaces. Both may be provided as external DLLs with their internal data processing being hidden from the core.

Reference is now made to Fig. 5, which is a screen view of an exemplary protocol of the kind described in Fig. 4, as seen from within the protocol designer 46. Various nodes are shown which define the parts of a data packet for the well-known TCP/IP protocol. It features internal branching for a higher protocol layer, as well as TCP and UDP protocols which are encapsulated as sub-protocol nodes denoted as "TCP packets" and "UDP packets".

In the aforementioned embodiments there is thus provided a testing device that is multi-protocol, multi-channel and multi-interface.

Reference is now made to Fig. 6, which shows the first step in the process of designing an object for testing a proprietary protocol. As in Fig. 5, there is shown a screen view of a protocol as seen from within the protocol designer 46. The protocol requires a definition of the data fields of a data packet and a series of nodes define open flag, message format connect, message format disconnect, data and close flag data fields. The definitions preferably include a size and a format for data within the field.

Reference is now made to Fig. 7, which is a screen view showing how the user interface 26 permits selection of a prestored interface for the interface object 48, and to Fig. 8 which is a screen view of available protocols including that defined in Fig. 6. A 'channel configuration manager' window (not shown), appears or is invoked and the user is directed to create a new logical channel and then select the required physical interface and assign a protocol. The physical interface objects are all presented as icons on the screen and the user simply clicks on the desired icon. Then the protocol defined in Fig. 6 is selected from the list shown in Fig. 8, which is a selection screen showing all previously defined screens.

Reference is now made to Fig. 9, which is a screen view showing the new logical channel, here labeled simply "my proprietary channel" configured with the protocol and physical interface previously selected. The process can be extended to add more channels and protocols, and thus to construct a comprehensive configuration for analyzing and simulating multi-channel systems to any desired degree of complexity.

The model is now ready for analysis. The analysis object is preferably activated to execute real time data capture and analysis. Data bits from the external device are captured by the interface. From the interface they are forwarded to the protocol tree where they filter through, starting at the root node and branching to other nodes and protocol layers, as though the data were being fed through a real device according to the protocol rules. The data as received is fitted into the data fields as defined in the protocol, ready for further analysis.

Reference is now made to Fig. 10 which is a tree diagram showing a tree object based on the protocol shown in Fig. 6. In this example there is only a single protocol layer and a single branch. Now assume the following data bytes are captured: 0x02, 0x03, 0x02, 0x01, 0x01, 0x03 (Ox - indicates hexadecimal digit). Fig. 10 shows the data bytes fitted into the fields of the protocol as discussed with respect to Fig. 9.

Reference is now made to Fig. 11, which shows the monitor output when the data bytes listed as above arrive and fit into the protocol tree as shown in Fig. 10.

Reference is now made to Fig. 12, which is a screen view showing a capture filter for monitoring the results of the analysis of Fig. 11. It will be apparent that for large quantities of data, the monitor output as shown in Fig. 11 could be difficult to interpret. There is thus provided a capture filter which can be set to look out for certain key features of the incoming data that it is desired to study. In the screen view the only messages that are studied are those wherein the fields "message format: disconnect" and "length of field" contain 0x2 values. All else is ignored.

If, instead of analyzing a particular device it is desired instead to test the operation of a particular protocol then the procedure is the same as described above except that the simulation object is entered before beginning the test. In the testing object, data is obtained from the interface, however, in the simulation object, data is produced, either at random or in a predetermined manner. The remainder of the operation is identical.

It is appreciated that various features of the invention which are, for clarity, described in the contexts of separate embodiments may also be provided in combination in a single embodiment. Conversely, various features of the invention which are, for brevity, described in the context of a single embodiment may also be provided separately or in any suitable subcombination.

It will be appreciated by persons skilled in the art that the present invention is not limited to what has been particularly shown and described hereinabove. Rather, the scope of the present invention includes both combinations and subcombinations of the various features described hereinabove as well as variations and modifications thereof which would occur to persons skilled in the art upon reading the foregoing description and which are not in the prior art. The source code for the virtual protocol core analyzer is given in the following tables:

Claims

1. A digital testing device comprising: at least one data interface for interfacing to at least one device to be tested, a plurality of predetermined protocols, a protocol selector for selecting any combination of said protocols to operate on digital data obtained via said interface, and an output for outputting results of applying said digital data to said selected protocols.

2. A digital testing device comprising: at least one data interface, a user interface, a protocol constructor operable to accept data from said user interface and to construct a protocol in accordance therewith, said protocol being able to operate on digital data obtained from said interface, and an output for outputting results of applying said digital data to said selected protocols.

3. A digital testing device comprising: at least one data interface, a plurality of predetermined protocols, a user interface, a protocol constructor operable to accept data from said user interface and to construct an additional protocol in accordance therewith, said protocol being able to operate on digital data obtained via said interface, a protocol selector for selecting any combination of said protocols to operate on said digital data and an output for outputting results of applying said digital data to said selected protocols.

4. A digital simulation device comprising: a plurality of predetermined protocols, a user interface, a protocol constructor operable to accept data from said user interface and to construct an additional protocol in accordance therewith, said protocol being able to operate on digital data obtained via said interface, a protocol selector for selecting any combination of said protocols to operate on said digital data and an output for outputting results of applying said digital data to said selected protocols.

5. A device according to claim 4, further comprising a script constructor for preparing scenarios for simulation.

6. A device according to either of claims 4 and 5, comprising further inputs to collect data from the simulation for testing.

7. A device according to any preceding claim, wherein said digital data is the output of all or part of a communications device.

8. A device according to any preceding claim, comprised within a computer.

9. A device according to any preceding claim, wherein said output comprises a configurable data filter.

10. A device according to any of claims 1 to 3 and 7 to 9, wherein said data interface comprises a selectable one of a plurality of specific interfaces.

11. A device according to either of claim 9 and claim 10, wherein said specific interfaces are designed for specific digital equipment and are operable to hide characteristics of the equipment from the device.

12. A device according to either of claims 10 and 11, further comprising an interface constructor operable through a user interface to construct a specific interface.

13. A device according to any preceding claim, operable with any digital data.

14. A device according to any preceding claim, wherein said protocols are operable to synthesize the operation of various electronic apparatus.

15. A device according to any preceding claim, wherein said protocols are templates for fitting said data into a data field structure of a communication protocol.

16. A device according to any preceding claim wherein said protocols are descendant objects of a protocol-independent parent object.

17. A device according to claim 16, wherein said protocol-independent parent object comprises a tree structure.

18. A device according to either of claim 16 and claim 17, wherein said protocol-independent parent object is operable to support processing of data according to any predefined protocol which is a descendant object thereof.

19. A device according to claim 16 or claim 18, wherein said protocol-independent parent object is operable to support any one of a group comprising smart filtering, triggering and simulation operations.

20. A device according to any one of claims 3 to 19, wherein said protocol constructor comprises a bank of predefined protocol substeps represented by visual items in the user interface, individually selectable by a user through said user interface to build a protocol.

21. A device according to either of claim 9 and claim 10, wherein said device interfaces are represented by visual items in the user interface, individually selectable by a user through said user interface.

22. A device according to any of claims 9, 10, and 21, comprising a plurality of additional device interfaces, allowing a plurality of devices to be tested simultaneously.

23. A device according to claim 22, wherein the number of additional device interfaces is limited only by constraints of available device memory.

24. A device according to any preceding claim, further having a storage unit for storing data for later analysis.

25. A device according to claim 22, wherein logical connections between different ones of said plurality of devices to be tested are viewable within said device.

26. A device according to claim 4, wherein a plurality of different simulations are operable to be run simultaneously and wherein said device is configurable to show logical connections between said simulations.

27. A device according to any preceding claims wherein a plurality of channels may have logical connections made therebetween and wherein a logical scenario is testable over said logical connections.

28. A device according to any preceding claims wherein a plurality of channels may have logical connections made therebetween and wherein a logical scenario is simulatable over said logical connections.

29. A device according to claim 22, wherein automatic association is made between a given device interface and one of said plurality of protocols.

30. A digital testing device substantially as hereinbefore described with reference to the accompanying drawings.