Text preview for : 5988-9819EN English _ 2014-07-31 _ PDF 593 KB c20140828 [21].pdf part of Agilent 5988-9819EN English 2014-07-31 PDF 593 KB c20140828 [21] Agilent 5988-9819EN English _ 2014-07-31 _ PDF 593 KB c20140828 [21].pdf
Back to : 5988-9819EN English _ 201 | Home
Keysight Technologies
Test-System Development Guide
Choosing Your Test System Software Architecture
Application Note
This application note is part of the Test-System Development
Guide series, which is designed to help you quickly design a test
system that produces reliable results, meets your throughput
requirements, and does so within your budget.
Introduction
The information presented here will help you choose the direction for your software based on the
application you have in mind and the amount of experience you have. We will explore the entire
software development process, from gathering and documenting software requirements through
design reuse considerations.
The complete list of application notes for this series is available on page 19.
This white paper will help you understand the tools required to design, develop and deploy the
software component of your test system
(see Figure 1).
Time
Gather Open standards?
manufacturing Data
requirements collection
Graphical or
Performance textual?
Gather Software Test executive?
R&D Requirements
requirements Specifiaction (SRS)
Design operator interface
Test
specification
Finalize Prepare data collection strategy
test system
User interface
hardware Design for reuse
Figure 1. Test-system software development process overview
Gathering and documenting software requirements--Before gathering and documenting your
software requirements, inalize your test system hardware design. Once inalized, start working
with your R&D and manufacturing teams to collect the information you need to create software
requirements speciications (SRS).
Programming and controlling your instruments--The control of instruments is rapidly evolving from
proprietary test and measurement standards to open, computer-based industry standards. This trend
affects the hardware that connects the PC to the instrument as well as the software and drivers that
control the instrument.
Collecting and storing test data--Data collection is the science of obtaining, moving and formatting
data. The integrity of your test system depends on obtaining the right data at the right time.
Designing the user interface--One of the most important (and easily overlooked) aspects of test
systems is the Graphical User Interface (GUI). This is what the test engineers, operators and
technicians see when they interact with your software.
03 | Keysight | Test-System Development Guide Choosing Your Test System Software Architecture - Application Note
Introduction (continued)
Choosing the development environment-- The software environment and tools you choose will have a
signiicant impact on the overall cost of your test system. When choosing your software environment,
consider more than just the purchase price of the software. Also, consider how easy it is to learn and
use the software, how hard it is to connect to other languages, devices or enterprise applications,
as well as support and maintenance costs. Over the life of a test system, software support and
maintenance costs alone can exceed hardware costs.
Working with open standards--Today, the industry trend is to move away from closed, proprietary
development environments. More and more people are embracing open, industry-standard
development environments as their platform of choice for test-system development projects.
Making the right choice now will give you the lexibility and capabilities you need in the future.
Developing a test sequence--Test executives are applications designed to run a series of tests
quickly and consistently in a pre-deined order. Of the 93% of test-system developers who use
test equipment, approximately 37% use a commercial test executive for test sequencing, while
the remaining 56% use a "homegrown" test executive.
Planning for software reuse--Designing for code reuse means you and your co-workers won't have to
re-create your software components every time you start a new project. Instead, you can build up a
company knowledge base of best ideas, best practices, and software components. This knowledge
base will bring uniformity and consistency to your company's product testing functions.
This application note will provide you with a solid overview of the testsystem software architecture as
outlined above. For more in-depth information, refer to the sources listed throughout this document.
Now, let's get started with the irst phase of choosing your test-system software architecture--
gathering and documenting your software requirements.
04 | Keysight | Test-System Development Guide Choosing Your Test System Software Architecture - Application Note
Gathering and documenting Ideally, the SRS will describe WHAT Within the product development
you need the software to do, not HOW lifecycle, the R&D department
software requirements
the software will do it. In other words, should provide a formal list of testing
you can look at the software as a requirements to the test-development
The Software Requirements "black box" that controls a set department. The System Requirements
Speciications (SRS)1 is a prioritized of external resources such as Speciications, also referred to as a
list of required test-system software instruments, a computer monitor Project Requirements Speciication,
capabilities and information on and other components (see Figure 2). refers to the system as a whole and
the software's external interfaces, therefore is different from the Software
performance requirements, system The SRS will include implementation Requirements Speciications.
attributes and design constraints. details only if those requirements are Furthermore, the manufacturing
Typically, some requirements "musts" imposed externally. For example, your department will have their own
are essential and others "wants" can company may require that a portion requirements, such as safety
be traded for time (e.g., to meet a of the system be implemented in a standards. It is the combination
project deadline). speciic programming language. A of R&D and manufacturing
good SRS should answer the following speciications that determine the
The IEEE Society identiies the questions: hardware requirements of a test
following areas you should address system and provide the basis for
in your SRS:2 1. What measurements and tests the Software Requirements