Component Architectures

Software written with object-oriented languages, also referred to as component software, tends to be self-documenting and lends itself to standardization. Component software uses programming languages such as Visual Basic, C++, or Java to create blocks of software. Each block of software performs a specific function. These function blocks can be encapsulated together to create procedure blocks. Function blocks are then linked to each other or to procedure blocks to create a software program.

Blocks of software usually can be tested independent of one another. Once a block is written and tested, it can be put into a library for later use. Blocks written by one programmer can be used by another programmer to create a complete software program. Software blocks can also be downloaded from various Internet addresses.

Figure 6-2: Advantages of Component Software
DRAWBACKS OF CUSTOM SOFTWARE	COMPONENT SOFTWARE SOLUTION
High initial cost	Software blocks written by others for similar applications can be reused; much of the initial programming effort is eliminated
High cost to modify	New component software blocks can easily be added to existing programs
High cost to support	Can be controlled if original program blocks are tested properly
Low customer acceptance	"Brand name" development environments such as Visual Basic increase customer acceptance
High risk of obsolescence	Risk is lessened because new features can be added by adding new blocks of software (assuming the original platform is still viable)

A data acquisition software program written with component software thus becomes a collection of linked blocks of software. Because the operation of each block of code has been tested and verified, programming only requires the correct linking of these blocks.

As Figure 6-2 illustrates, component software can overcome many of the problems associated with custom software. This figure would seem to indicate that component software is the ideal solution, combining the flexibility of custom software with the customer acceptance of off-the-shelf programs. This is true to some extent but only if the development platform remains viable and discipline is followed when the software is written and modified.

Long-term viability of the software development platform is critical. It is more important to pick a strong brand name with staying power than to strive for the latest features. If the selected platform vendor goes out of business, the software developer is in trouble. All programs developed with the discontinued software platform immediately become obsolete. Bugs are not fixed, industry advances are not implemented, and most importantly, programmers begin to discontinue development of new software blocks.

The remaining problem with component software is the necessity of maintaining a disciplined approach to software development and support. Relatively small blocks of software code are inherently easier to support than one large monolithic program, but these small blocks of code must still be written in a manner to allow subsequent modification and support. Software blocks must be large enough to perform important functions but not so large as to become unwieldy. The blocks must be developed in a prescribed manner so as to allow communications with other blocks. Judgment and discipline still are required to develop maintainable software.

Objects & Containers

The latest advances in object-oriented development for the Microsoft environment include objects based on Microsoft's Component Object Model (COM), and its distributed extension, DCOM. Formerly know as ActiveX "controls," these objects are created with development systems such as Visual Basic, Visual C++, Borland Delphi, and Microsoft Internet Explorer. Once an object is created it is compiled and tested within the development system. Each ActiveX object follows a prescribed specification, namely 32-bit Object Linking and Embedding (OLE). This allows ActiveX objects to run within OLE control "containers," and to communicate with each other and with other OLE-compliant software.

OLE control containers act as platforms for COM/DCOM-based objects. These objects run inside these containers, communicating with each other and with other objects within the container. Any COM/DCOM development system can act as a container. Other containers of interest to users of data acquisition systems include many of the leading data acquisition software packages, especially on the high end, as well as commercially available word processor and spreadsheet programs.

One object within a container constitutes a working program, albeit not a very effective one. It is only when these objects are combined that useful applications are created to solve real-world problems. The standalone characteristic of an object is nonetheless important because it allows each object to be fully tested in isolation. This greatly simplifies software debugging.

Each object is a block of code, much of which is invisible to the user. Users typically work with only the compiled code and are not allowed access to the source code. Users access the object through its Properties, Events, and Methods. Methods are the least accessed of these parameters. Most object developers intend for users to interact with the object through its Properties and Events. An object can appear as a push-button, an analog or digital display, or as a much more complicated device.

Properties are used to define the visible attributes of the object. For example, a gauge might have the Property of color. This would allow a user to change the color of the gauge. The power of the user to customize the object is determined by the number of Properties. Users want a large number of Properties to increase their ability to customize the object.

On the other hand, the developer wants to minimize the number of Properties. The object grows in complexity and size as more Properties are created. The developer can also lose money by creating too many Properties. If the Property of color is not available to the user and if the user cannot use the standard color, the user must purchase another object from the developer.

Events are the user-accessible items in the object that allow interaction between the object and the outside world. For example, an Event for the gauge might be a change in the input value. This would move the needle on the gauge. Another Event would allow a user to set high and low alarm setpoints for the gauge. Like Properties, Events create usefulness for the object but also add complexity and cost.

Leading vendors of data acquisition software now are selling ActiveX objects. These objects are sold in sets and are meant to address particular classes of applications. They are developed either internally by the vendor, or developed by third parties and private-labeled by the vendor. Many of these vendors will sell these blocks over the Internet.

In theory, a user will soon be able to purchase a low-cost container and fill it with the needed objects. These objects can then be interconnected to create the program. The user could then apply this software program to an application, or become a developer by selling this application to others.

Semi-Custom Software

A compromise approach to custom software development and often inflexible off-the-shelf packages are commercially available, graphically oriented programming environments. These programming environments typically consist of a group of function blocks, each dedicated to a data acquisition or a data manipulation task. Drawing tools and libraries of standard symbols are also provided to create presentation screens.

Users connect the function blocks to each other to create applications, and also fill-in-the-blanks within each block to configure the software for their specific application. Screens are then drawn using the provided drawing tools and library symbols. Finally, screens are linked to function block fields to create animation and live data displays.

One popular program offers function blocks for communications, comparison, data conversion, digital signal processing, data I/O, logic, math, string manipulations, waveform generation and statistical calculations. Free-form blocks also are included. The power of this type of program is evident. Virtually any application can be addressed if enough system resources are available and if high-speed data acquisition is not a requirement.

The line between these types of programs and non-custom, off-the-shelf programs is sometimes murky. Costs tend to be similar, although semi-custom software yields a wider range of functions for the money. Figure 6-3 illustrates some of the main differences.

Figure 6-3: Semi-Custom Development vs. Off-the-Shelf Packages
ATTRIBUTE	SEMI-CUSTOM	OFF-THE-SHELF
Cost per range of functions	Low	High
Cost of customizing for application	Moderate	Low
Ease of use	Moderate	Very easy
Customer acceptance	Moderate	High
Risk of obsolescence	Moderate	Low
Speed	Slow	Moderate
Use of hardware resources	High	Moderate

Semi-custom development environments are a middle-of-the-road approach between writing your own software and buying an off-the-shelf package dedicated to a specific task. One of the most important differences is in the use of hardware resources. Many limited function, off-the-shelf programs can run in a DOS environment on a bare-bones 386 machine. This can be very attractive to an OEM needing an embedded, low-cost solution.

Semi-custom programs by necessity operate only in graphical environments. These types of environments demand the use of a high-powered PC. Throw in a 17-in., high-resolution color monitor, and you have a high-end solution to what may be a low-end problem.

The chief advantage of the semi-custom approach is high flexibility compared to off-the-shelf programs, coupled with relative ease of use compared with writing code. If a user has many different types of data acquisition applications, or if the data acquisition task cannot be clearly defined, semi-custom software may offer the optimal solution.