Transcript Future of TTCN3-Power Management and Testing Infrastructure

Future of TTCN-3
Power Management and
Testing Infrastructure
3 May 2012
Sasken Confidential
© 2009 Sasken Communication Technologies
Paper proposition
• The paper is proposed as a value addition in the Future of TTCN-3,
for support of the system power management testing aspects.
• The presentation describes new areas of challenges, issues, use
cases and test solution of the power management in an
embedded/mobile system.
• The power management testing aspects will provide better system
evaluation and help in tuning the system for optimal power usage in
various possible scenarios.
© 2009 Sasken Communication Technologies
2
Why Power Management?
• The objective of power management system is to turn off or
switch the system to a low power state when inactive.
• The evolution of the embedded devices and cell phones is
manifested both by growth in units shipped and a persistently
snowballing feature set. Manufacturers add these features under
the competitive pressures of curtailing cost and maximizing talk
time and stand by power.
• TTCN-3 should support the power measurements and testing
aspects and test automation at all levels of the system starting
from the IC chip boards to the drivers, application framework and
applications.
• The advantages of power management:
1. Reduce overall power consumption
2. Maximize battery life
3. Lower power consumption means lower heat dissipation
which increases system stability
4. Less power consumption will save money and reduce impact
on the environment
© 2009 Sasken Communication Technologies
3
What is Power Management?–(1/2)
• To save power, obvious choice is to power off the device when not in use.
The problem is when user keeps using the device very frequently,
switching off and switching on each time consumes more power than
keeping it powered on.
 Avoid polling: Applications have to avoid unnecessary polling. Though
polling many times will be simple solution, every time application polls,
CPU wakes up from idle state, thus consuming more power.
 Group timers: Polling may not be completely avoidable. If polling is
required, applications that use timers can be grouped such that all
applications polls almost at the same time to avoid multiple wake ups of
CPU.
© 2009 Sasken Communication Technologies
4
What is Power Management?–(2/2)
• Unused devices: If a device is no longer used by application, it has to
be closed. If it is kept open even though it is not required, kernel will
assume that device is in use. As a result, device will not go to power
saving state. Of course, there will be inactivity timer which will make
sure device goes to power saving state.
• Sufficient buffers: Allocate enough buffers to avoid frequent access to
external memory.
© 2009 Sasken Communication Technologies
5
Gaps in the TTCN Test System
• References in power testing:
• Using TTCN-3 to Design Performance Tests, presented by George
Din, Cosmin Rentea at TTCN-3 User Conference 2006, June 2nd
2006, Berlin. This system proposes the general performance
testing and does not refer to power measurements in specific.
• Some papers are there in the distributed testing of the electric
power measurements domain.
• None of the solutions searched on the internet showed up the power
management and testing infrastructure on the TTCN-2 & 3 systems for
the embedded handsets!!
• This is the gap the paper proposes to address, the value add of power
management and testing infrastructure on the embedded handsets.
• Many proprietary power test systems exist. E.g.
http://elinux.org/OMAP_Power_Management
© 2009 Sasken Communication Technologies
6
Power Management Use Cases
• Linux system is managed by either Advanced Power Management (APM)
or Advanced Configuration and Power Interface (ACPI).The core power
driver was added to the Linux kernel in order to facilitate low level
drivers to control the peripherals supported by the Power Manager.
• Multimedia : As codecs is CPU intensive it drains power. So a state
machine to save & resume the decoding state in case of an
interrupt/error is beneficial.
• Messaging and Browser: Applications should avoid parsing the data for
XML, codecs etc. often as this is very CPU intensive and drains power.
• Device Management : The firmware/application updates are power
intensive hence they should consider having the delta firmware memory
updates and not complete firmware updates.
• Memory operations should be limited as they consume power. One
possible way is to allocate a chunk of memory and then keep using and
free the chunk at the application quit time only.
© 2009 Sasken Communication Technologies
7
Future of TTCN-3
TTCN-3 Test Infrastructure
3 May 2012
Sasken Confidential
© 2009 Sasken Communication Technologies
TTCN3 Architectural Blocks
• Support from the TTCN-3 is as elucidated below:
 The Platform Adapter (PA) should offer operations for handling
absolute time and real time platform integrations.
 The Component Handler (CH) should support time synchronization or
test system architecture should be extended by a time
synchronization interface.
 The PA and CH should support multiple cores Symmetric multiprocessing also for multiple core platforms testing.
 For high performance real-time distributed testing all operations of
the TTCN-3 test system should have deterministic time behavior.
This can be realized by using real-time operation system and realtime programming (e.g. JRTS) for developing TTCN-3 test system.
© 2009 Sasken Communication Technologies
9
TTCN-3 Architecture
Note: Diagram from: http://www.ttcn-3.org/Testsystems.htm
© 2009 Sasken Communication Technologies
10
TTCN-3 System Details – (1/2)
• TTCN-3 is used to specify tests, the order of execution and a test
system to execute the TTCN-3 tests.
• TRI and TCI standards define test system architecture.
• TTCN-3 tools are required to support internal interfaces.
• Allows reuse of test platform components with different tools but also
for different System Under Tests (SUTs).
• The construction of a TTCN-3 test system requires A TTCN-3 test suite.
• A TTCN-3 tool, i.e., a TTCN-3 compiler (or interpreter) plus execution
environment .
© 2009 Sasken Communication Technologies
11
TTCN-3 System Details – (2/2)
• Optionally implementations for test execution control, logging and
codecs.(Most commercial tools offer default implementations for these
entities).
• A SUT Adapter implementing the means of communication required by
SUT platform interfaces.
• A Platform Adapter implementing a timing model, e.g., power timing
clock, and external platform functions (if there are any defined in the
test suite).
© 2009 Sasken Communication Technologies
12
Future of TTCN-3
Power Management TTCN-3
Test Infrastructure
3 May 2012
Sasken Confidential
© 2009 Sasken Communication Technologies
Power Management Test Architecture in TTCN-3
Power Management Tests
Multimedia, Browser,
DM applications tests
Monkey tests,
benchmark tests
Protocols & network
Graphics
Test System Executor
Session
Manager
User
Interface
tests
TTCN-3 Test System
OS calls tests
Hardware, drivers,
battery, CPU tests
Mobile Handset
Applications
Application
Framework
Protocols & Libraries
OS layer
Test Control
Codecs
Logging
TTCN-3 Executable
SUT Adapters
Platform
(Platform Calls)
Adaptors(OS call)
System Under Test
Hardware & drivers
© 2009 Sasken Communication Technologies
14
Power Management Tests Functionality – (1/2)
• The power management test automation suite helps run the power
management functionality tests and report results for:
 CPU frequency
 CPU idle
 CPU state
 CPU Active durations
 CPU Sleep
 Peripheral power usage
• There could be graphs like:
 Power versus time
 CPU frequency versus time
 CPU frequency versus power
 Memory versus power etc.
© 2009 Sasken Communication Technologies
15
Power Management Tests Functionality – (2/2)
• E.g. Power TOP could give the CPU states of the processes. That could
further be analyzed and based on the results system CPU, drivers and
software could be fine tuned for optimized power.
• CPU consolidation test cases should be executed for multiple numbers
of CPUs. If system is hyper threaded but number of CPU is 1 then some
of the test cases will be executed. For better coverage of test cases
there should be support for selecting a system which is at least quad
core and then hyper threaded so that multiple CPU's testing could be
covered. This would require the Symmetric multi-processing
techniques to be supported. And also real time support.
• Timer migration and Symmetric multi-processing functionality
verification test cases should be executed only on suitable
architecture like quad core or multiple CPUs.
© 2009 Sasken Communication Technologies
16
Power Management Test System Flow
Power Management Tests
Multimedia, Browser,
DM applications tests
Monkey tests,
benchmark tests
Protocols & network
tests
TCI Interfaces
Test System Executor
Session
Manager
Test Control
OS calls tests
Logging
Hardware, drivers,
battery, CPU tests
Codecs
User
Interface
Graphics
Platform Adaptors(OS )
Solution to
measure platform
data
Time measures
TRI
SUT Adapters
Interfaces
(Platform Calls)
Power vs. Time Graph
Memory details
Battery Levels
CPU details
© 2009 Sasken Communication Technologies
17
Support in TTCN-3 for Physical Layer of Testing
• The physical layer of the batteries, CPU, clock etc.: access, continuous
signals and physical environment.
• Platform adapter and TRI interfaces will help to access the physical
layer registers, events and triggers from hardware and set, monitor
them in the test control and logging modules.
• The implementation would cover particular platform adaptors for
various mobile platforms and mobile OSes.
• The implementation of PA/SA is specialized for each cellular devices
for platform related and system related aspects like drivers, OS calls
and peripherals.
• The PA and CH should support multiple cores Symmetric multiprocessing also for multiple core platforms testing.
• The TTCN-3 executable will contain the power management tests
module.
© 2009 Sasken Communication Technologies
18
Support in TTCN-3 for the Testing of Power Management
• Test control & execution would allow tester to configure different
parameters, timing related and iteration related parameters. The TCI
interfaces will integrate this with the TTCN-3 executable.
• Logging would log all the power parameters tested for a session.
• Test system executor, will contain the session management. It would
also manage multiple sessions during testing. This would help the
tester to have multiple application sessions run and evaluate the
power parameters across the system. The session manager will receive
all the inputs from logging and test control during a session.
• Graphics support can be used to plot the power graphs. This can be
incorporated in TTCN-3 executable.
• TTCN-3 test System executor would have a user interface to take in
user inputs/display power test results as tables/graphs.
© 2009 Sasken Communication Technologies
19
Benefits and Advantages
• The organizations benefits are as anticipated below:
 Cellphones, smart phones and other embedded device manufacturers
demand increasingly complex power management chipsets and
software systems while driving lower cost. The TTCN-3 must enable
manufacturers to satisfy these needs.
 At system level a TTCN-3 software environment allows rapid debug
and release to production.
 An architecture that supports high parallel efficiency and power
allows manufacturers to take advantage of multiple CPU systems.
 TTCN-3 enables solid repeatability and reproducibility, supports fast
threshold determination and be able to make accurate differential
measurements.
© 2009 Sasken Communication Technologies
20
Conclusion
• With TTCN-3 test tools, test engineering organizations are wellpositioned to deliver on-time, cost effective solutions into
production.
• The addition of the test infrastructure of the power management
aspects in the TTCN-3 would empower the accomplishment of testing
characteristics.
• The test outcomes would further aid to fine tune the system and
hardware parameters and application parameters as essential.
© 2009 Sasken Communication Technologies
21
Thank You
Visit us at www.sasken.com
Sasken Confidential
© 2009 Sasken Communication Technologies