How to meet wireless test world

1
How to meet wireless test world
Veikko Loukusa, Nokia Mobile Phones, Jukka Antila, Nokia Networks ,Tapio
Koivukangas, Nokia Mobile Phones, Markku Moilanen, Oulu University
Abstract
Test methods of the future will communicate test data through advanced wireless technologies. As
technology progresses so these wireless interfaces will progress. In this paper we propose an approach
toward a wireless test standard and describe how its implementation contributes to the life cycle phases of
the product.
1.Introduction
The trends of semiconductor designs are such
that the density and complexity of ICs
(Integrated Circuits) increase and the cost of the
basic elements decrease. The frequencies
increase,
especially
inside
the
ICs.
Correspondingly, the use of external automated
test equipment (ATE) becomes more difficult
and the test costs rise. There is a delay in the
development of external ATE technology
compared to that in the DUT (Device Under
Test) [1].
The above mentioned problems can be avoided
by carrying out test functions inside the ICs and
at a higher level, as embedded solutions in
devices (embedded test). With this approach
testing will have the same technological features
available as the IC functions themselves. The
application of embedded testing decreases the
service cost of the device too, because no
resources are needed to invest in external
instruments or test interfaces in service points.
The same tests are available in production,
service and field testing.
The complexity of IC design and frequency of
operation are continually increasing. The amount
of new generations of products goes up and the
product life time shortens. These factors have an
effect on failure modes, failure diagnostics in the
field, and the nature of service operations.
Standardised telecommunication interfaces and
the remote driving of the embedded test
environment can be utilized both in production
and in the field, because testing, configuration
and re-programming can be carried out during
the whole life cycle of the product through
communication interfaces [2]. In order to use
wireless interfaces with different communication
speeds for testing in the production phase, there
have to be in the embedded test environment
such test methods that shorten the test time and
decrease the need of transferring data. These
kind of methods are at-speed HW built-in selftests (BIST) and software based functional selftests, called at-speed SW self-tests [3]. In
addition, the embedded test solution has to
enable the use of tools for external boundary
scan equipment and test and vector formats like
SVF (Serial Vector Format). This kind of format
offers a higher data capacity than currently
available [4].
Our approach is a suggestion to ‘standardise’
wireless testing in order to be more ready to face
the expected test challenges. In section 2, the
background to wireless testing is described.
Section 3 outlines the main requirements. In
section 4, we describe the wireless test
architecture.
Section
5
outlines
the
implementation towards a standard structure
with the description of the test environment and
the Embedded Test Manager. Section 6 shows
the anticipated results. Section 7 introduces
future work and needed actions, and section 8
concludes the paper.
2.Wireless Testing
Several visions have been presented describing
the future of the wireless world [5]. Wireless
communication systems are widening ever more
from “connecting people” to
“connecting
technical
constructions
of
a
modern
infrastructure”.
This
UBI
(Ubiquitous
Computing) environment consists of cars,
household appliances, watches, remote health
2
care and health monitoring devices, etc., which
can communicate with each others as well as
with external devices [6]. In order to answer to
the questions such as “is this the future ?” and
“how widespread will the wireless world be ?”,
the wireless systems will be dependent on many
factors among which the key issues are reliable
operation of the systems and cost effective
products with easy use. This environment is
undoubtedly very complex, containing devices
from different product manufacturers, and the
applications of the devices in systems are
different (Fig. 1).
Wireless Test Standard
needed !
Mobile Terminals
MA
CD
/W
BT
M
GS
/W
LA
N
Signature /
Wellbeing information
Signature /
Wellbeing information
Wireless Applications
Base Stations
GSM / WCDMA
Fixed Network
Fig.1. Wireless testing.
The devices operating in the future environments
are based on challenging new technologies as
they must have more intelligence in smaller
dimensions, operate at higher frequencies, etc.
Due to the increased complexity of the devices
and the whole system, it is reasonable to assume
that more things can fail. The first challenge is
how to locate the failure in the environment and
in the actual device. From a consumer’s point of
view the crucial question is what he or she
should do. Some proposed applications of the
UBI world are meant to perform critical tasks.
Remote health monitoring applications demand
continuous reliable operation and guidance
information because failure can even be fatal.
Proactive diagnostics of the devices in use and
the entire communication link providing
information about their present and future status
is therefore required. Even in non-critical
consumer products, advance availability of
information about predicted technical problems
and how to solve them is user-friendly and
strongly supports the expansion of the new
technology and business opportunities.
The interoperability of the devices in the
operational networks can be assured in the R&D
phase by following the common accepted
standards. Continuous reliable operation calls for
standardised co-operation and agreement in
terms of testability and testing, these being the
most powerful instruments to verify the quality
and reliability of the device. Therefore the
creation of the Wireless Test Standard (WTS) in
global co-operation with industry and research
institutes is an essential effort for building the
wireless world.
The life cycle testing has to be cost effective
while including high fault coverage and
advanced diagnostics. Continuous debate is
underway on concentrating on different solutions
for optimisation of the entire testing process of
an electronic device. Certainly, the optimum
testing strategy depends on the type of the
device. The testing solutions of high volume,
low cost or low volume, high cost products
respectively may need quite different life cycle
testing strategies. Extensive effort is executed to
develop generic tools for optimising the test
strategy of the electronic devices. However,
some common requirements are usually
presented for different kind of products. The cost
effectiveness of testing means almost in every
case shorter test times and reusability of the tests
during the entire life cycle. Use of embedded test
constructions can, in principle, meet these
requirements [7].
3.Requirements
Testing will be a continuous feature of future
devices. The complexity of devices is increasing
and the amount of testing increases with it in
R&D, in use and in the field repair phase. In
production and in installation the amount of tests
has to be kept as low as possible.
To be cost effective, production testing has to be
considered carefully in order to set the future
wireless test. An increase in integration and
complexity of the products mean more defect
possibilities and more features and parts (blocks,
circuits, etc.) to be tested. Miniaturization
decreases the visibility of interconnections and
components and increases the quantity of these
connections giving the impetus to use wireless
test methods. Reducing production test cost is at
variance with long test times using expensive
instruments and expensive fault finding
3
equipment.
The future of board testing in production can be
seen as a transfer from functional testing with
external instruments to process inspection and
embedded test. Process inspection can be e.g.
automatic x-ray or optical inspection, and
embedded test can be provided by self-tests, selfcalibrations and SW supported Go/No-Go tests.
Standardisation of the wireless test would enable
test re-use, shorten the test development time
and decrease total cost. Standardisation can be
viewed at different levels, inside a product
family, inside a company, inside wireless
telecom or even worldwide. The most important
area
for
standardisation
is
the
test
communication between devices or systems (or
between tester and device/system). This enables
more standard solutions in the areas like test
software implementation in the product and selftest methods and algorithms.
bottom layer up to the top layer (like HW,
interface, IP, TCP/UDP, SNMP, MIB, data
stream, FTTP, http, etc.) are proposed in fig. 3.
Ethernet, GPRS/EDGE/3G, Bluetooth/WLAN
and ISDN Fixed specify already the electrical
and mechanical characteristics to process the test
data signal. The IP protocol is a suitable manager
protocol between different networks. The
transport layer can consist of a transfer
communication protocol (TCP) and User
datagram protocol (UDP). In application layer,
HTTP (hypertext transfer protocol), FTP (file
transfer protocol), SNMP (simple network
management protocol), MIB (management
information base) and data stream are also
suitable alternatives. In this layer, a vendor
specific protocol has to be booked for test
applications. SyncML as one solution that offers
a common data protocol for universal data
synchronization [9].
Test
Synchronization
File transfer Statistics
Wireless Test Standard
needed !
Mobile Terminals
RF
RF
RF ASIC
ASIC
ASIC
MIXED
MIXED
MIXED
ASIC
ASIC
ASIC
SYSTEM
SYSTEM
SYSTEM
ASIC
ASIC
ASIC
Baseband
Baseband
Baseband
TX
TX
TX
Stream
Specific
FTP
SNMP
L7
HTTP
L6
MIB
UDP
L5
TCP
Test
points
LNA
LNA
LNA
RF
RFRF
N
WLA
Signature /
Wellbeinginformation
L4
L3
L2
MA
CD
/W
BT /
IP
Signature /
Wellbeinginformation
RX
RX
RX
Wireless Applications
TX
Vendor
App
SyncML
M
GS
Embedded tests:
1149.x/BIST/Histo
rylog
info/selftuning
etc.
PA
PA
PA
Data
Applications
Ethernet
Base Stations
GPRS / EDGE/ 3G
BT/ WLAN
ISDN FIXED
L1
TX
BB
BB
BB
TX
RF
TX
RF
BB
RF
RX
RF
RX
RX
GSM / WCDMA
RX
BB
BB
BB
RF
RF
RF
TX
TX
TX
Fig. 3. Wireless test architecture.
RX
RX
RX
Due to the structure of SNMP being simple, it
has become the only protocol up to now that has
achieved wide acceptance for network
management purposes [10]. In this respect,
SNMP as a test network protocol is a good
candidate for wireless test protocol. MIB
provides status information, such as hardware
configuration of test modules, type information
of these modules and the possibility to switch on
or off one of these modules. As transporting
protocol, UDP is less reliable than TCP. The
transport layer is a set of rules by which the test
modules talk to each other.
Fig. 2. Applied wireless test
4.Wireless test architecture
Test Program Sets for networked ATE are
presented in [8]. In this solution, test data,
calibration data and other files on ATE stations
can be monitored for troubleshooting of the
system.
It can be suggested that the wireless test
architecture has been inherited from the OSI
model. According to [8], the OSI layers can
assist in protecting data and equipment from
illegal accesses. Based on selected model,
contents, architecture and protocols from the
On top of communication layers there are
applications which use standard commands to
make communication between different systems
possible.
4
To widen the use of embedded testing, the main
focus here is in managing test software in the
DUT and the communication between tester and
DUT. The actual technical solutions for
embedded tests are covered shortly as necessity
elements, the hardware and the test flow. The
lack of standardisation has been limiting
efficient utilization of embedded testing. The
software, which manages test cases, settings and
control communication in DUT, has usually been
specified and implemented separately for every
project. There is a need to improve software
modules of the product for testing it in
production, and this generates many possibilities
to utilize the same architecture in other phases of
the product’s life. The proposed wireless test
architecture enables efficient built-in test
solutions in products.
scan tests, core tests, interconnection tests and
SW self-tests. The test execution can be
launched from different interconnection layers,
which calls for a user / controller access point at
the implemented layers.
STANDARD TEST
STANDARD TEST
5.Implementation of WTS
Application: FTP,SNMP,
MIB,HTTP,SyncML,etc
Transport: TCP,UDP
Network:IP
5.1.Target HW Environment
Embedded test as an applied implementation for
wireless test is shown in fig. 4. The
implementation looks forward to extending use
of DFT structures at IP (intellectual property)
level, at IC level and at system level [11]. In
future, there will be DFT structures serving all
these levels in the digital, mixed-signal and RF
domains. The use of boundary scan and core
access will be a standard test method, and BIST
in all the domains will be a part of the test
implementation.
The hardware calls for embedded test structures,
such as embedded boundary scan (IEEE 1149.1
and 1149.4), core access such as P1500, and
BIST structures to be applied to the application.
The test controller is a test manager SW module,
which is loaded into memory. The module runs
the earlier mentioned HW related test structures
and forms a connection to the upper layers. The
BISTs (embedded in the system) are the key
elements for the use of the standardised
communication channels in the testing. The
BIST can be controlled via low speed
communication channels and can be run at all
stages of the product’s life cycle. The BIST
means less test time, less vectors and can be run
without ATE.
The test itself is a layered standard test, which
runs DFT based tests like BIST tests, boundary
G
G
ICs
with
DFT(BIST, BS)
ICs
with
DFT (BIST,BS)
DFT ICs
uP core
ICs
with
DFT(BIST,BS)
System
Memory
Physical:standard bus(es)
Fig 4. Embedded test in HW.
5.2. SW Application
The main SW application element can be called
the Embedded Test Manager (ETM), which is
implemented in the product.
When testing boards in production there are
some basic needs for the ETM in the DUT while
it is communicating with the test system; tasks
such as starting any self-test and returning the
result. Setting the DUT to a predefined
state/mode for performance tests is also needed
in many cases. When considering the test phases
which may have a long duration (ESS, aging,
reliability, etc.), scheduled self-tests and result
logging are important. The log containing test
results is read after completing the test.
5
When considering testing during the R&D
phases, more needs can be seen. It is useful to
install the ETM to the product for testing the
prototype assembly and HW design. The
product’s own SW is probably the last task to be
ready in the project and so it cannot be utilized
in early HW verification. A HW engineer needs
easy ways to run and update the embedded tests
at any time in his/her work. The tests are
separate modules which can be updated and
loaded into the product during operation. R&D
may also need tools to control the product
without any tester PC. Just a terminal or a web
browser would be suitable for running the selftests and setting the parameters. This feature
could be used also in manufacturing if volumes
are low and automation is not mandatory. In fig.
5 a typical production test environment is shown.
Tester
standards: for example, a terminal can be
connected simultaneously to other systems via
GSM, WCDMA, Bluetooth and IR (infrared)
interfaces.
In a complicated network it is difficult to
identify which node in the network is not
operating properly. This sets new requirements
on every product to be able to identify whether it
itself is working or not. The equipment should
be able to run different tests: power-on tests are
the first to be done, but during operation some
scheduled tests should be done or, if there are
too many errors in the data stream, dedicated
tests should be run. A smart telecommunication
network can, of course, also diagnose itself by
negotiating: nodes in the network ask each other
to run self-tests when they see that something is
wrong.
DUT
5.3.Test Control Interface
Communication
Communication
Standard Tester/
Test ExecutiveDUT interface
SW
Test
Test
Manager
Test
Setup
Fig 5. Production test environment.
We have seen that production and R&D can
utilize ETM effectively. It is easy to understand
how satisfied service and repair departments are
when fault finding is supported with easy selftests. A standard laptop with a terminal emulator
or a browser connected to the faulty equipment
is attractive. The defect can, however, be in the
processor block or in the interface, which
renders the self-tests useless. However, in that
case too, the maintenance engineer knows where
to search for the defect.
The scope of this paper is to propose a future
methodology for testing telecommunication
equipment. The nature of telecommunication
networks bring more possibilities. Testing over
a network is a feature which has an increasing
importance when the network becomes more and
more complicated. This is important especially
in the dynamic wireless environment where
equipment can be connected to other systems
with many interfaces conforming to different
When looking for the possibilities to standardise
embedded testing, the first issue is a standardised
way of communicating in all environments. The
actual SW may be different in different systems,
but what makes this environment work is
standardised communication. This proposal
defines the needed levels for the interface and
the standard commands which the Test Manager
SW in the product must understand. It is
essential to identify the levels of the
communication interface to make it possible to
mix different HW interfaces with different
protocols. It is most useful to use for test control
those standard HW interfaces which already
exist in the product. Generalised levels of the
interface are shown in fig. 6.
Fig. 6. Generalised Interface Levels.
6
5.4.Standardisation structure
The command syntax must define how the
commands are built and how parameters and
variables are transferred. Commands finally
define what the Embedded Test Manager has to
do. Since there are numerous possible situations
to use this standard control procedure, the
standardisation should be implemented at
different levels: basic communication standard,
extensions for various purposes and product
specific features. Fig. 7. shows the detailed
structure.
WTS
Stacks
Controlling System
or Device
(Test System)
Device Under Test
(DUT)
Interface
Level
Specifications
Commands
Syntax
Configuring
commands
Standard
Questions
(wellbeing, log,…)
Standard test
commands
(run/response)
Other
commands
Command syntax(strings, delimiters, parameters,…)
HW related protocols
HW protocol
HW level
SW
dowload
Std Wired IF
Std Wireless IF
(Ethernet, RS 232,…) (GSM, BT, WLAN,…)
Wireless Test IF
(new standard)
Fig.7. WTS structure.
The basic communication standard includes the
protocols, command syntax and a limited set of
basic commands. Extensions for various
purposes define the user environments: R&D,
production, repair, use. This definition means
that the features can also be defined as restricted
sets. This supports efficiently a definition for the
controlling system: the production tester has to
support only the basic communication standard
and production extension. The third level,
product specific features are reserved for ones
which are only needed in certain products:
mobile handset, IP router, etc.
6.Anticipated results
The expected results are considered at two
levels: in general, and separately in different life
cycles of the product. The implementation
requires better test understanding over the life
cycle. It calls for co-operation during the
specification phase of tests for life cycle
purposes. The total cost is visible only when all
the test needs are evaluated at the same time.
Tests (self-tests) contain parameter values so
they are flexible for configuration. The delivery
and download of up-to-date test cases is
straightforward work. A good version control is
mandatory. The re-use of the same tests in
different phases of the product’s life cycle is
realistic. A test and diagnostic SW has to be
developed and tested, which needs extra work.
In the R&D, the product is set in test mode,
which enables the use of flexible and
configurable test procedures. A standard
environment
aids
concentration
on
characterization of the DUT. Tests are available
early in design phase. R&D’s role in test
development is strong, which itself means more
work in the R&D phase.
In production, if any traditional instruments are
needed they will have a WTS interface, which
gives
the
DUT
the
possibilities
of
communicating with the instruments. Self-tests
can be performed during transport or waiting
time. Self-tests are the main mode of testing,
which means a short test time. The re-use of the
tests is an ordinary action. During production,
customer application software and test cases can
be downloaded too. The testers are simple,
standard low-cost ones.
In installation, the installation setup is a laptop
with the necessary interface. Installation is not
dependent on the manufacturer of the products.
Identification of the detected/not-detected plugin unit is a function of installation. Remote
installation is possible. The installation
procedure can be done over a longer period with
the results sent afterwards to the control centre.
The “install” command does everything
mandatory for the product (self-tests,
communication with others in the network, etc.).
Other equipment in the network can check the
installed system and tell if the installation is
successful.
After sales operations, which are the daily use
and the unavoidable repair of the device, change
dramatically. Identifying the faulty device can be
made
in
the
network
by
self-tests,
communication between systems and by
diagnostics. Proactive diagnosis is possible for
identification of weak equipment beforehand.
Self-tests and network diagnostics can report the
defects to the service centre. All earlier phase
tests are available for fault search. The history
log can be read from the equipment and the
repair history can be saved to the device after
7
repairing. SW updates can be done via WTS.
There are business possibilities to develop
“advanced” tests and sell test services to
operators or device owners or make reviews for
magazines. Traceability is a realistic feature
because products are located in the network with
a certain ID (identification code).
7.Future work / needed
actions
The main purpose of the Embedded Test
Manager (ETM) is just to transfer information in
a controlled and standardised way between
different devices. It is a long way to make such
an ETM software platform which could run in
many very different products. The processor and
other SW environment are different and the
needs are not the same. This software can surely
be somehow standardised inside a company and
for certain similar products, but a general
purpose SW platform is probably not the first
step to be taken.
The best way to proceed is to standardise the
communication interface between the devices.
The main issue is that the structure, the syntax
and the contents of the commands and messages
are standardised.
8.Conclusions
A standardised way of managing embedded test
actions in a product is needed to improve
effective and flexible implementation of selftesting in telecommunication products.
The key element in this development is to
standardise the communication protocol, syntax
and commands for product test control. This will
be done in such a way that the same environment
can be utilized in all phases of product’s life
cycle: from design to production, use and
service.
9.Acknowledgements
The authors would like to thank Nothern Center
of Electronics Manufacturing,NCEM, Testing
Board work. Acknowledgement is especially due
to Ari Ahola ( Nokia Networks), Pekka Kaukko
(Elektrobit Group), Timo Piironen (Elektrobit
Group), Janne Göös (VTT), Jukka Rautio (VTT
) and Jussi Roivainen (VTT).
10.References
[1] 2001 Technology Roadmap for
Semiconductors, Computer, Vol. 33, Issue 1, Jan
2002, pp. 42-53
[2] M.M. Saha, O. Werner-Erichsen, K.
Wilhelmsson, Network Protection and Control
Using Standardised Communications, in Conf.
Publ. No. 434 ,Sixth International Conference on
Developments in Power System Protection,
1997, pp. 172 –175
[3] N. Kranitis, A. Paschalis, D. Gizopoulos,
Y.Zorian, Effective software self-test
methodology for processor cores in Proceedings
of Design, Automation and Test in Europe
Conference and Exhibition, 2002,pp. 592 –597
[4] G. Wedge,T. Conner, A Roadmap for
Boundary-Scan Test Reuse in Proceedings of
International Test Conference 1996, pp. 340-346
[5] M.H. Dunham, A. Al-Mogren,; A.Y.Seydim;
V. Kumar; Data in your space [wireless access],
in Proceedings on Third International Workshop
on Advanced Issues of E-Commerce and WebBased Information Systems, WECWIS 2001,
2001, pp. 66 -73
[6] R. Buderi, Computing GOES Everywhere,
Technology Review, Vol. 104,
Iss. 1, pp. 52-59, 2001
[7] B. G. Van Treure, J.M. Miranda, Embedded
boundary scan in IEEE Design&Test of
Computers, March-April 2003, pp. 20- 25
[8] J.R. McCarty, Automatic test equipment
(ATE) on a network (securing access to
equipment and data) in Proceedings of IEEE
AUTOTESTCON Conference, 2000, pp.490 496
[9] http://www.openmobilealliance.org/syncml
[10] W. Kastner, M. Kunes, Device and Network
Management for PDAs: An SNMP-Manager for
the Palm OS, in Proceedings of IEEE 4th
International Workshop on Networked
Alliances, 2002, pp. 67-76
[11] International Technology Roadmap for
Semiconductors, 2001 Edition, Test and Test
Equipment