Embedded platforms pose test challenge
EE Times: Latest News Embedded platforms pose test challenge | |
Venkataraman Prasannan and Lakshmi Raman (10/04/2004 9:02 AM EDT) URL: http://www.eetimes.com/showArticle.jhtml?articleID=48800544 | |
The current trend is to develop embedded systems using platforms common to many different applications spanning multiple industries, particularly telecommunications. But the advantage gained by using embedded platforms is only possible if the platforms are built to support the requirements of the system. The wide variation in configuration and usable applications offers a challenge in certifying that embedded platforms are robust and that they perform with no single point of failure under most stress conditions. Testing such platforms adequately within the business constraints requires building a test strategy into the overall development process. When testing an end system, the common approach is twofold: first, define test plans and test cases for the various functions supported by the system, and second, conduct testing based on how an end user will operate the system. Special attention is also required for testability at the platform level to avoid problems in the field. Designing for testability offers many new challenges when considering platforms vs. end systems built on the platforms. Consider a network element such as an optical cross-connect with a number of line cards supporting different rates and protocols. In building such a system, the functional requirements are specified in detail, and typical configurations for the system are known in most cases. Therefore, testing the embedded end system can be done with a comprehensive set of regression tests, with test coverage for most of the expected configurations. Testing the same embedded system based on a flexible platform becomes significantly more complex. One can define a typical configuration for the expected applications, however, so the flexibility of the platform opens up choices not usually available in an end system. That said, testing for all applications and configurations is not realistic. A method for bounding the problem is necessary. One method is to identify a number of use cases that meet the needs of a typical application. Each use case may have a number of scenarios specified with reference to a sample set of configurations. The use cases also include the expected behavior under both normal operating conditions and exception conditions. The exception conditions are further exercised in test cases by performing what is referred to as negative testing. An example test configuration could be where two blade server platforms are connected together and a subset of the modules is selected. With five types of modules, two shelves and 14 slots in each shelf, the configuration combinations that would have to be tested to provide exhaustive test coverage could be on the order of 109, assuming all slots are universal. This is clearly impractical, so alternative means are necessary to provide the requisite test coverage. An alternative approach is to incorporate a methodology based on functional requirements. The platform is tested to verify the following as a minimum:
When testing embedded systems, OEMs must also take into account both the environmental factors and the application. Systems involved in life sciences will need additional testing to reflect many of the safety aspects needed for use on people. Similarly, mission-critical systems and military systems will require different aspects of testing. While open architectures and standards do not reduce or eliminate the testing burden. they do promote excellent economy of scale and allow designers to leverage standard embedded platforms that are completely tested and validated for the right application. Venkataraman Prasannan (venkataraman.prasannan@radisys.com) is senior director of product line management and Lakshmi Raman is senior director, system engineering for RadiSys Corp. (Hillsboro, Ore.).
| |
All material on this site Copyright © 2005 CMP Media LLC. All rights reserved. Privacy Statement | Your California Privacy Rights | Terms of Service | |
Related Articles
- Understanding the Deployment of Deep Learning algorithms on Embedded Platforms
- Automating C test cases for embedded system verification
- Intellectual property security: A challenge for embedded systems developers
- Maximizing battery life on embedded platforms - Part 4. Turning off peripherals and subsystems
- Metric Driven Validation, Verification and Test of Embedded Software
New Articles
- Quantum Readiness Considerations for Suppliers and Manufacturers
- A Rad Hard ASIC Design Approach: Triple Modular Redundancy (TMR)
- Early Interactive Short Isolation for Faster SoC Verification
- The Ideal Crypto Coprocessor with Root of Trust to Support Customer Complete Full Chip Evaluation: PUFcc gained SESIP and PSA Certified™ Level 3 RoT Component Certification
- Advanced Packaging and Chiplets Can Be for Everyone
Most Popular
- System Verilog Assertions Simplified
- System Verilog Macro: A Powerful Feature for Design Verification Projects
- UPF Constraint coding for SoC - A Case Study
- Dynamic Memory Allocation and Fragmentation in C and C++
- Enhancing VLSI Design Efficiency: Tackling Congestion and Shorts with Practical Approaches and PnR Tool (ICC2)
E-mail This Article | Printer-Friendly Page |