In the Area of Architecture: System Software Stack

Publish Date: Oct 17, 2011 | 3 Ratings | 4.00 out of 5 | Print

The Automated Test Outlook is a comprehensive view of key technologies and methodologies impacting the test and measurement industry.  View the other 2011 trends from National Instruments.

2. System Software Stack

Software has been a critical component of automated test systems since it was first used to control stand-alone instruments more than 40 years ago. Since then the role of software in automated test has grown significantly. In fact, software development costs are often 2X to 10X more than capital costs in most test systems today. The makeup of many test engineering organizations reflects this trend of hiring more software engineers than hardware engineers. In response to rising software development costs and accelerated product development cycles, today’s industry-leading companies emphasize designing a robust system software stack to ensure maximum longevity and reuse of their software investments. In fact, a test manager’s survey conducted by National Instruments in 2010 showed that an increased focus on system software was the second-highest strategy for increasing the efficiency of their test development process in 2011.

From a system software perspective, most companies are moving away from monolithic software stacks that often contain fixed-constant code and direct driver access calls to the instruments. Alternatively, they are seeking modular software stacks in the form of separate yet tightly integrated elements for test management software, application software, and driver software. This type of system software stack helps engineers apply the optimal tools for each area and choose between standardized commercial off-the-shelf (COTS) and in-house tools at each level. A key trend is the extension of modularity into each layer of the software stack, including the increasing use of process models, code module libraries, and hardware abstraction layers.

Test management software defines the core automation and sequencing flow of a test system. The process model is a critical technology within the test management software layer because of its role in separating the test tasks from the non-test tasks so engineers can easily standardize and manage non-test tasks across different test sequences and stations. The non-test tasks include much of the connectivity with the enterprise for data inputs, logging data to quality databases, communicating with the shop floor, and generating actionable test reports. With this modular framework, organizations can maintain a few process models that they can apply across many different product lines and hundreds or more deployed testers. The process model also simplifies changes to non-test functions in a test station without impacting the test tasks, thus reducing the time needed to update deployed test stations. For example, engineers can quickly change the execution flow of a test station based on market demand by switching among sequential, batch, and parallel testing process models.

A modular system architecture increases flexibility and shortens test system development time.

The application software layer is equally important because it directly impacts the test-related tasks of a test system. Many organizations have moved to developing modular test code, known as code modules. Called by the test management software, these modules perform the actual measurements and analysis used to determine the pass/fail status of a test step. Many code modules perform similar I/O functions across different types of devices under test (DUTs), so this is a key area for reuse and distributed development responsibilities using team-based development methods. Recently, the industry has seen an increase in companies adopting reusable test code libraries and more source code control (SCC) tools. Many application software vendors now include integration with SCC tools and advanced features such as three-way diff and merge to accommodate this test software development trend. Some organizations have even implemented gatekeeper milestones to ensure a certain level of reuse and team-based development to prevent reinventing the wheel and growing too dependent on a single developer for all code development knowledge.

Additionally, companies are increasingly integrating requirements management software tools in the application software layer. This helps ensure one-to-one tracking of test coverage against design requirements, which is critical in highly regulated industries. New requirements gateway software offers a link between the application software and requirements management environments, such as Telelogic DOORS, to greatly reduce the amount of time spent tracking requirements coverage in test system development.

A final component of the system software stack that is growing in need and usage is a hardware abstraction layer (HAL). A HAL resides within the driver software layer of the system software stack and separates the application software from the instrument hardware, which minimizes the time and costs associated with migrating or upgrading test systems. There are two approaches to designing a HAL: instrument-centric or application-specific. For an instrument-centric API, it helps to define an internal common instrument-centric API “standard” that can be used across multiple types of DUTs.

"We created an automated verification test framework that includes a hardware abstraction layer. This framework gives us the flexibility to set up various configurations of test hardware without having to change the test software code."

- Mohammad Ahmad, Manager, System Test and Verification,                 Thales Communications

Interchangeable Virtual Instruments (IVI), an industry-standard HAL, takes an instrument-centric view of abstraction – that is, having top-level test applications call an instrument-centric API that makes all instruments look similar (for example, IviScope Configure AcquisitionType). In an application-specific approach, the test applications call an application-specific API that is aligned with the type of tests it needs to perform (for example, LED test). A HAL is a proven method to develop and maintain a loosely coupled test system. It better addresses mismatches between product and test instrumentation life cycles and avoids tightly coupled test code with test instrumentation. Loosely coupling test code and the test instrumentation improves the overall design of a test system, making it more maintainable and extensible over its lifetime.

Driving the modularity of the system stack into each software layer delivers additional flexibility and provides a framework to develop sophisticated life-cycle management strategies. These strategies help reduce software development time and mitigate obsolescence issues by addressing subjects such as feature road mapping, system upgrades, and instrumentation and technology insertion planning.

Additional Resources

View the Next Trend: Heterogeneous Computing

View All of the 2011 Automated Test Outlook Trends

Download a PDF of the 2011 Automated Test Outlook

Back to Top

Bookmark & Share


Rate this document

Answered Your Question?
Yes No