For years, the benefits of using interchangeable hardware parts to design a product have saved time and money and improved quality and reliability. This practice enables companies to produce products in large quantities.
The Need For CBD
Continuously changing test requirements, complex test systems, faster time to market, and budget constraints are realities of today’s business environment. These demands require a more efficient and predictable approach to software development.
Technological advances have greatly improved the test-software development process but also increased expectations on the capabilities of software. Software now is required to handle new and multiple instruments, platforms, and environments and adapt to new communications standards. With the advances in communications, customers expect data to be readily available anywhere and anytime.
Companies need to be dynamic and adapt to this changing environment. Software development must deliver high-quality applications faster than ever before. For this reason, any software solution must be reusable. Lev-eraging from what has been done and proven is crucial for a successful solution.
Defining Components
The concept of building parts to a predefined specification has been around for more than a century. Today, the manufacturing sector can produce many devices in large quantities using interchangeable parts to assemble products.
CBD applies the same principles to software development. Parts designed according to predefined specifications can be assembled to create applications. These parts are known as components.
Software components are “binary units of independent production, acquisition, and deployment that interact to form a functioning system.”1 In basic terms, software components are pieces of software that can be used together to build an application. The goal of component-based software development is to standardize the interfaces between software components so they can work together seamlessly.
Encapsulated, Replaceable, and Independent
Components are considered to be black boxes. A component is encapsulated because the details of the underlying implementation are hidden from the users and all interactions take place through well-defined interfaces.
An encapsulated component separates the what—what the component is—from the how—how the component does it. The interface defines what the component is and how it is used. This way, anyone using the component only has to be concerned with how to interact with it.
The component must have predictable behavior, and its implementation is independent from the rest of the application. Figure 1 represents this concept of encapsulation. The client communicates with a component through a well-defined interface, represented by a line terminated with a circle, but the client does not need to know the implementation details of the component.
A component is not bound to any particular application. Many components are created to meet the requirements of a specific application. But once they have been built, they can be used for different applications.
Because components have strictly defined interfaces, as long as the interfaces of the component meet the consumer’s needs, the same component can be used to develop or enhance other applications. Moreover, components can be easily replaced by other components offering new or enhanced functionality as long as they support the same interface.
Figure 1 shows how a component is replaceable. A client communicates with Component A through a well-defined interface. A new Component B is developed that supports the defined interface as well as a new one. Component A can be replaced with Component B, and the client still can communicate with it without having to recompile any code. Moreover, any new client can communicate with Component B using either interface.
A component can be implemented independently from other components via encapsulation. Each component is its own self-contained unit of development and test.
Because you can define component interfaces before beginning development, you can assign tasks and develop the software components independently and in parallel. This positively impacts the time to market for a product and provides more control and manageability in the software development process.
Benefits of Components in Test Applications
The benefits of using components are maintainability, reusability, and scalability. Their use also promotes distributed computing.
Maintainability
In a monolithic application with significant interdependencies, a change to one part of the application can affect other parts. By designing an application with discrete components, the dependencies between the different parts of the system are minimized. Changes to an application are isolated to the affected components and do not require modifications to the entire application.
Improving the speed of software development is beneficial, but once the application is finished, you usually will need to change and maintain it. For example, requirements will change, problems with the current solution will arise, and improvements will be requested.
During the life of a software application, much time and effort are spent maintaining it. The key requirement in managing change is keeping it localized, minimizing its scope and impact so that you do not propagate changes through the software as in monolithic applications.
In a component-based system, functionality ideally is implemented only once. This results in easier maintenance, which leads to lower cost and a longer life for the system.
Reusability
Discrete components with encapsulated data minimize system dependencies and reduce interaction to a set of inputs and desired outputs. This black-box behavior enables maximum code reusability.
To use a component, a developer simply would call its interface. There is no need to understand how it is implemented. When a system is in development, a lot of the functionality has to be generated from scratch. If another system needs similar functionality, it must be developed again.
With CBD, the test engineer creates a component that is a full implementation of a solution. The component then is reused in different systems, which helps maintainability. If you need to fix the system, the impact is localized to the component, which helps to manage changes to the application.
Reusability increases the robustness of components. As more and more applications use the component, bugs are fixed, and functionality is added. Over time, the component becomes widely used, and consumers know what to expect from it. A component becomes a more stable unit of software than it would be if it were used only in one application.
Scalability
Frequently, the test developer will want to add more features in the future without modifying the entire application. Decoupling the different components of an application makes it easier to scale different parts according to dynamic requirements.
For that reason, component-based systems are much more adaptable and extendable than systems built by traditional design techniques. Additionally, components usually are not changed but replaced. This results in a more rapid migration from one instrument to another or from one operating system to another.
Distributed Computing
Distributed applications have software running on different computers that must work together. CBD gives test developers the capability to distribute software modules and run them on different PCs.
This still is a complex task to achieve, but components help in this process. CBD makes it possible to design distributed systems. Technologies such as DCOM, CORBA, and .NET provide a platform for the communications among components and make distributed computing easier to achieve.
Example Using Components
It always is useful to create components for the tasks that will be repeated on multiple test systems with different functionality. Examples of these repeatable tasks are log on; add, edit, and delete users; save and retrieve configuration information; save and retrieve test data; view and print test certificates; communicate with the UUT; and many others. By developing components for these tasks, you can use them as building blocks that can be assembled easily and reused in many test systems.
For example, you are required to develop a functional test system for Product A123. It makes sense to build a component that handles the communications with the UUT. The communications component could offer functionality to initialize and terminate the UUT, configure the UUT with selected information, get a software version, and execute a script from a file.
Dim objUUT As New MyCommComponent.ProductA123
objUUT.Initialize
objUUT.Configure (TEST_CONFIGURATION_A)
If objUUT.GetSoftwareVersion () = “1.0.23” Then
objUUT.ExecuteScriptFromFile (PATH_TO_SCRIPT_FILE)
…
(Figure 2)Funtional Code Using COM Architecture
The code in Figure 2 shows how this is implemented using the COM architecture. The component is called MyCommComponent, and it exposes the interface Product A123.
First, it creates a new object called objUUT. This object then is used to call methods to initialize, configure, get software version, and execute script.
If Product A123 is modified, you only replace the current communications component with the new version, and the test code does not need to be recompiled or changed in any way. This capability to minimize code changes is an advantage for developing test systems more quickly.
Component Technologies
Component technologies have been evolving for more than a decade. Most component-based systems have an underlying software architecture. The most common are the Common Object Request Broker Architecture (CORBA) and the Distributed Component Object Model (DCOM).
By understanding the commercially available component technologies, test engineers can choose the appropriate one when developing applications. Figure 3 shows how these technologies have been evolving over time, especially within the last decade.
COM, DCOM, and COM+
The Component Object Model (COM), formerly known as OLE, was introduced in 1993, and it is the component software architecture from Microsoft. COM is considered the most widely used component software model.
There are many tools and programming environments available today to use and build COM objects. To support distributed computing, in 1996, Microsoft introduced Distributed COM (DCOM), which extends the COM model by adding a protocol that enables software components to communicate directly over a network.
In 1998, Microsoft introduced COM+, an extension to COM, and Microsoft Transaction Server (MTS) that enhances applications written using COM, MTS, and other COM-based technologies. COM+ handles many of the resource management tasks that developers previously had to program, such as thread allocation and security.
ActiveX
ActiveX controls are reusable software components and services based on COM. These controls can add specialized functionality to test applications. ActiveX controls have become a well-known and widely used architecture for developing programmable software components for use in many applications and development tools.
CORBA
CORBA is a framework designed by the Object Management Group (OMG) to facilitate communications between applications distributed across a network. CORBA is considered to be very reliable, especially within servers with high volumes of traffic and heavy hit rates. CORBA is platform independent, and several implementations of CORBA are commercially available to support different platforms.
.NET
Microsoft .NET is a platform for building, deploying, and running distributed applications and systems. It takes advantage of the Extended Markup Language (XML) and other technology standards.
The .NET platform enables software integration through the use of XML Web services, which are small, discrete, building-block applications that connect to each other. .NET tools are not just for building Web applications. You can use any .NET language available to create standard Windows applications.
Component Technologies in Test and Measurement
Today, practically all of the popular software development tools support ActiveX, COM, and .NET. This gives you the ability to use components from development environments such as LabVIEW, Agilent VEE, LabWindows/CVI, Visual Basic .NET, Visual C#, and Visual C++.
Through ActiveX automation, these environments provide ways to control other applications such as Microsoft Word, Excel, and Access. This way, test systems can be programmed to send data to the applications to read data and generate reports.
Test-Software Development Tools
Microsoft Visual Studio .NET supports all the .NET technologies as well as DCOM/COM, allowing developers to build and use components using these and other technologies in an integrated environment. There also are add-on tools that integrate with Microsoft Visual Studio .NET to provide an integrated development environment tailored for test and measurement system development.
National Instruments’ LabVIEW has included support for COM since Version 4.1. LabVIEW 7 Express now provides support for COM modules as a client or server, ActiveX controls, and .NET components. LabWindows/CVI and TestStand also support COM. Measurement Studio provides a collection of ActiveX controls designed to build test and measurement software inside any ActiveX control container.
Agilent Technologies’ VEE for Windows supports ActiveX automation and controls computers running Windows. ActiveX automation support lets you use VEE as an automation controller to run other Windows applications.
Test Data Management Software
Test data management traditionally is an afterthought for test engineers. Usually, it is a cumbersome task to connect to different data sources and query and combine the right data.
Component technologies also can greatly improve these deficiencies. For example, all of the common commercial Relational Database Management Systems (RDBMS), such as Oracle and SQL Server, support ActiveX Data Objects (ADO) and ADO.NET. ADO is a component model based on COM that provides access to multiple sources of data. ADO is accessible from any environment that supports COM.
Additionally, there are other tools that add one more level of abstraction to make test data management easier. They provide interfaces and techniques to model data more naturally from a test and measurement point of view rather than a RDBMS point of view. The Arendar product from VI Technology is an example of such a tool.
Automation Data Access Software
The OLE for Process Control (OPC) specification defines a set of standard interfaces based on Microsoft’s COM technology. Traditionally, to access any field device or its data, developers were required to write custom interfaces. OPC designates a common interface that eliminates this need.
Additionally, the OPC Foundation announced the release of the OPC XML specification based on XML and Microsoft .NET technologies. OPC XML builds on the existing OPC data-access specification.
Instrument Driver Software
The Interchangeable Virtual Instrument (IVI) specification provides a standard for instrument drivers and a robust architecture for interchanging instruments. The IVI Foundation already has defined specifications for several instrument classes including DMM, DC power supply, oscilloscope, and arbitrary waveform/function generator.
IVI-COM is the same IVI driver-architecture standard based on COM. With IVI-COM, instrument drivers based on this specification work with industry-standard software-development environments such as Visual Studio.NET, Visual C++, Visual Basic, and any other test and measurement software that supports COM.
The Next Step
Component technologies have been evolving for the last decade from OLE to CORBA and most recently .NET. Many of these technologies already have proven reliable and efficient, and they are being used on many applications throughout different industries.
When compared to other industries, test engineering has been slightly slower to adopt some of these technologies, but it is moving in the right direction. Most of the common commercial instruments offer drivers and interfaces using these technologies, which greatly simplifies the way engineers interface with them.
As developers of test systems, you have a great opportunity to make your development process a more efficient and predictable endeavor. In moving toward a CBD, the first step is to understand the technologies and create a plan to incorporate CBD into your development process.
Reference
1. Szyperski C., Component Software: Beyond Object-Oriented Programming, ACM Press, New York, 1998.
About the Author
Cesar Gamez has been with VI Technology since 1998 and currently is the manager of the Arendar Test Data Management Software product. As a senior engineer, he has developed test and measurement systems for various industries. His previous experience includes development of network engineering systems for telecommunications. Mr. Gamez holds a B.S. in electronic systems engineering from ITESM University (Instituto Tecnologico y de Estudios Superiores de Monterrey) and is working on an M.B.A. at St. Edward’s University. VI Technology, 3700 W. Parmer Lane, Unit 200, Austin, TX 78727, 512-327-3348 ext. 206, e-mail: [email protected]
Return to EE Home Page
Published by EE-Evaluation Engineering
All contents © 2003 Nelson Publishing Inc.
No reprint, distribution, or reuse in any medium is permitted
without the express written consent of the publisher.
October 2003