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
- Easy and cost-effective to install, configure, maintain and operate.
- In seconds you can install and run you first test run using the included dummy test system.
- Commonly used loggers for result and error logging are included in the package.
- Templates for test steps, instrument drivers and data loggers make it easy to get started and extend T-base solutions.
- Only basic knowledge of C# or Visual Basic needed for making professional test automation solutions .
- Huge C# community. Easy to find resources, training courses, online help and supporting applications (SVN ankh, Sandcastle, NUnit etc.).
- Extremely easy instrument communication supporting all VISA interfaces.
- Light weight (memory, processor and screen size).
- Fast test execution.
- Scalability. From small simple systems to huge systems with thousands of test steps supporting many instruments.
- Supports up to 2 147 000 000 step calls in one test run
- Supports 'unlimited' levels of sub tests and looping
- Modern Windows UI (WPF based).
- Look and feel is simple and robust.
- Open for customization/tailoring, e.g. UI design and different formats for result reporting.
The system can operate without UI.
- Modular design using well known SW patterns.
- Supports instrument interchangeability.
- ‘Pre-run check' concept minimizes run-time problems.
- HW setup and test sequences specified in XML files.
- Easy and safe to edit HW configuration and sequence files using the T-base Configurator application (see T-base Configurator section).
- C# is text based and object oriented and together with the concepts modularity. This supports professional SW processes and multi-site
development due to the modularity and supports version control compare and auto merge.
- The concepts modularity, the use of an object oriented language and the available .NET tools gives a great support for professional
SW processes and multi-site development.
- Supports development of modules in both C# and Visual Basic.
- Framework models do not have the same problem with limitations as other sequence applications.
- Supports access to third part SW by using Soap, RPC, XML-RPC and direct use of modules developed in C, C++, Python, Java and LabView.
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:
- Result logging to a file or database and to the UI. This includes an overall product result verdict (passed or failed).
- Support for testing variants of the product.
- Simple operator UI.
- Support for changing parameters without having to make changes to the code, e.g. change of limits, IP address for an instrument or the file path to the result data.
- Ability to change a product test by running another test sequence containing more or less test steps.
- ‘Interchangeability', the ability to e.g. switch between same type of instruments from different suppliers, without having to change anything else than the instrument
driver. This demands a well thought through software structure containing the use of modules.
- Possibility to add a new logging format or to change the existing, without changing the actual measurement functionality.
- A good error handling with error messages sent to both the UI and an error log file.
- An indication of when the test is completed.
- A possibility for the operator to start, stop, pause or step in the test sequence.
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
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
- The test system modules are loaded into the T-base Configurator and the information about test steps, resources and loggers are collected and presented.
- The user can now use the T-base Configurator to edit the presented data or create new configuration – and sequence files
- The test system loads the configuration and sequence files from the XML files edited or created by the T-base configurator.
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
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:
- 'DefaultReferenceName' is used as reference for the thermometer driver.
- 'Description' is a description of the driver.
- 'AddMetaDataParameterEnum' defines a parameter whether measuring in Celsius or Fahrenheit.
The method parameters for 'AddMetaDataParameterEnum' are:
- 'DefaultReferenceName' is the name of the parameter.
- ‘Description' is a description of the parameter.
- 'AddMetaDataParameterEnum' is a parameter of the type Enum. It must have a specific number of possibilities separated by a colon. Here the possibilities are Celsius and
- The last parameter defines the default value.
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
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.