Rebase Systems ApS /
Dansk Engelsk

T-base Framework

Do not fight limitations - make solutions!

T-base is a generic test system software framework designed for Test & Measurement systems. It includes all the common functionalities necessary for automatic and semi-automatic test systems. The concept outlines the full architecture of how to build a top professional module based test system application. T-base is the third successful framework/sequencer developed by the Rebase team.
It is designed in C# and WPF and we recommend that also the test system specific modules are made in C# or Visual Basic.NET.
When utilizing T-base, the only thing left is to implement test cases (using a template), optionally some drivers, and a result/data logger if T-base's standard loggers do not meet your requirements.
That is it! Now you have a stable and nice looking test system software with a super architecture. Nevertheless, T-base gives test automation developers' full control over their test solution SW. Our goal is to make common task easy and uncommon tasks possible.

Easy to learn and easy to use
Performance
User Interface
Architecture
The UI of our T-base Framework for Test & Measurement
The T-base Framework architecture
You do not even have to design a test system configuration user interface, the T-base Configurator handles it all!
Click T-base Configurator if you want to know more.

Below is a general description of test system framework architecture, followed by a description of the specific
T-base Framework architechture.


Test systems do very often have many functionalities in common, even though they do test very different products or parameters. The basic architecture is very often the same:

There are both very small and simple – and very large and advanced test systems. The small test systems do typically not even load a test system configuration, or log data to a file; here the configuration and data logging are performed in the system UI (user interface). This is not very smart because test systems tend to grow over time and it is important both to be able to test in a well-defined way, and to document the test system configuration that generated the test results. It is important to save the data logged by the test system in a format that is easy to post process. The amount of data generated by a test system do grow over time, and thereby grows the need to be able to extract information from the data.

Here is a list of 10 common requirements for a test system:

Simple Framework test system architecture
Now that these demands are quite common for test systems, is it not necessary to reinvent the architecture and implement the functionality every time a new test system is developed. A Test & Measurement Automation Framework based on a well thought through SW architecture should contain all the above demands, it must be both robust and flexible and also easy to both expand and support. A test system Framework shall make common tasks easy and challenging tasks possible!
Using a standard Framework saves a lot of time and money during development. On top of this, you get a robust and well-proven test system, because most parts of the test system SW has been tested on other test systems.

Software design of the T-base Framework

The figure to the right illustrates the overall modules, the Framework functionality and the test system specific modules (green):

This illustration indicates that the test system specific functionalities are implemented into three different kinds of modules (the green boxes). These modules are not part of the Framework, but are well-defined modules that can be interchanged and reused in other test systems where especially Loggers and Drivers are often reused.
It makes perfect sense to implement the functionalities into these three different modules, because the demands and thereby the architecture of each module are different. Common for the three is that they are all built on their own Abstract Base Class that are implemented in the Framework.

What is an Abstract Base Class?
An Abstract Base Class can implement a default functionality that the inheriting class is able to overwrite. This means that if the default functionality is sufficient you just use it as it is, but if not you are able to overwrite the functionality. The Abstract Base Class also defines an Interface containing the methods and properties that the inheriting class can or must implement. The interfaces of the three-abovementioned modules are crucial to how well and flexible the Framework is working – that is what makes the communication between the Framework and the modules work. This concept also gives the advantage that different SW developers working at the same project are guided towards a uniform design.

What is Design Patterns?
Design Pattern is a description or template for how to solve a SW problem. An artisan chooses different ‘Design Patterns' for e.g. the roof or the walls when building a house. You rarely invent a new way of handling the task and if you do, it is associated with some risk. Some of the more common SW Design Patterns fits perfect to the task of developing a Test & Measurement Automation Framework.

What is Lazy Loading?
Another common concept for the three types of modules are that they are assemblies (.dll's) and are loaded into the test system using ‘Lazy Loading'. The test system configuration defines which modules to load during test system startup. This makes the system startup time kept at a minimum because only necessary modules are loaded and initialized. The Lazy Loading concept supports Interchangeability: If a test system must use another instrument, log results in another format or use another test step library, you do not have to make changes to the source code, you just change the name of the SW module in the configuration file and the new module will be loaded. This concept makes the test system simpler, you avoid error messages about resources that are not present, and you do not need.

The Module Loader concept
In the above figure, you find a Module Loader. Its purpose is to load the three different types of modules using ‘Lazy Loading' and create instances of the classes that are in the modules using the ‘Factory Method Pattern'.
The test sequence definition (sequence file) describes which test steps to instantiate. A test step can occur multiple times in a test sequence, whereby the system creates multiple instances of the step class.

That is what the different modules have in common. Let us look into the specific concepts of the 3 types of modules.

The T-base Framework system architecture
The Data Service and Logger concept
The Data Service and Logger concepts are built upon the ‘Observer Pattern' where Data Service in the Framework is Broker of messages and the Logger modules are ‘Observers' by receiving messages in the form of events.
The test steps has a reference to the Data Service object in its base class. The test steps must send all information to Data Service: Test descriptions, test results, test limits, error messages and information about the tested product, e.g. serial number. Data Service now generates events when receiving data from the test steps. Any given logger decides which types of messages it subscribes to. An error logger is maybe not interested in test results and product serial number.
The advantage of this concept is that the test steps do not know which loggers are loaded or how they are designed; you can change or add new loggers and still be certain that it has no influence on the measuring functionality in the test steps.

The Data Service and Logger concept
The Driver/Resource concept
As mentioned earlier, the driver concept is used to achieve ‘Interchangeability'. This is the ability to switch between same type instrument from different suppliers, without other changes to the test system than changing the driver name in the configuration file and thereby loading the new instrument driver. The driver concept also has the purpose of moving the test step implementation to a higher level and leaving the technical details to the driver. We have chosen to call this kind of modules ‘Resources' because they are used for other types of modules than instrument drivers. It can be functionality used by different steps, or making the test step code more understandable by implementing a more logical separation.
We have mentioned earlier that a driver/resource implements an Abstract Base Class, but it do also implement a ‘Resource Interface'. This Resource Interface describes the interface between the test steps and the driver/resource, which could be a digital Multimeter or an Oscilloscope. If a test system uses two different types of Multimeters, it must include a Multimeter Resource Interface and two different implementations (drivers/resources), one for each type of Multimeter. It is important that the test steps have a reference to the Interface and not to the Implementation because we use ‘Late Binding'. This means that it is not decided which instrument driver each test step is going to use when we develop the test step; the decision is done when the test system starts up and loads the configuration files describing the test system hardware.
The Framework also contains a Visa driver (see Figure 2) that makes it easy to connect and communicate with instruments with different interfaces (GPIB/IEEE-488, USB, RS232, LAN). In addition to this is it possible to exploit all the interfaces supported by .NET such as Socket, RPC, SOAP, unmanaged code, DLL's etc.

The Driver/Resource concept
The Test step concept
A test step assembly (dll) does often contain multiple test steps. A test step is a class with one or more methods. The ‘Sequencer' that is a very important part of the Framework, calls these instances of test steps. The order in which these test steps are called and possible repetitions/test loops are defined in the sequence file which is in a well-defined XML format. This sequence file can also contains parameters such as values to set up an instrument, what parameters to loop on, test limits, just to mention a few possibilities.

System Configuration, Sequence file and the T-base Configurator
Test system applications must be as simple as possible and have a very intuitive UI for the operator to operate. It is also a goal to limit the number of SW updates of the test system SW, not having to update it just to change the configuration, test sequence or other trivial stuff. The main purpose of the test system is to generate test results, not being an administrative tool for configuring and experience tells us that the amount of configuration of test steps, resources and loggers will grow as long as we are developing the test system.
We have therefore chosen to move the test system configuration – and test sequence editing into another application: The T-base configurator. It is still possible to change a parameter in the test system UI, if this for some reason is necessary, but we have developed the T-base Configurator especially for the editing purpose. It is completely generic. It can be used for all test systems without any changes. How is this possible?

Test steps, resources and loggers are all compiled into assemblies. The T-base Configurator loads these assemblies, collects data about the modules and presents the data in an intuitive user interface.


When the T-base Configurator loads the modules, some of the needed information is accessible using ‘Reflection' whereby you can get names of namespaces, classes, version information etc., but not all necessary information is accessible this way. To be able to get the rest of the necessary information, the classes in the modules must implement a method called ‘InitializeMetaData'.
The T-base Configurator calls ‘InitializeMetaData' and information is collected from properties of the class instance. Some of the information items are common for the three types of modules, e.g. name and description/documentation. All types of modules can define a list of configuration parameters of different data types that controls how the module works. Configuration parameters can be any thing: Test limits, IP address of an instrument, file name of the result log, frequency channels to test, debug mode flag etc.
To the right is an example of ‘InitializemetaData' for a thermometer driver:


The method parameters for 'AddMetaDataParameterEnum' are:


The T-base Framework supports many other data types than Enum.
The T-base Configurator uses this information to generate a generic UI for each class and parameter.
The resource/driver configurations are saved in separate XML files and test step configuration is saved into one or more XML sequence files.

The T-base Configurator concept
Initialize meta data for a Thermometer driver
Sequence files
A sequence file defines the test step order to run. A test step can appear multiple times in the same test sequence and the different instances can be configured with different parameters. A sequence file can also define test loops, wherein one or more test steps run multiple times to measure one or more parameters under different conditions. A specific type of looping parameter controls this.
The T-base Configurator displays a list of the accessible test steps. You build a new test sequence by dragging steps from the ‘Available Steps' column into the ‘Sequence' column. Here you can define whether the step is a sub step meaning a step that is looped by a looping parameter. You can change the different step parameters. Finally, you can save the sequence XML file. XML files are straightforward to read and can be edited in a standard XML editor, but it is much more user friendly to edit them in the T-base Configurator.

Want to know more?
Please contact us by the mail or phone number below.