Pub Date : 2012-10-22DOI: 10.1109/AUTEST.2012.6334526
K. Paton
This paper discusses how to interpret system specifications that involve the switching subsystem and how these specifications can be used to predict the effect on the signals passing through the system and if the system will even support those signals. These specifications include bandwidth, crosstalk and insertion loss. Actual waveform examples are included showing how the switching path can dramatically alter signals, particularly signals with higher frequencies or fast rise times.
{"title":"Interpreting system switching specifications and how they relate to waveform quality","authors":"K. Paton","doi":"10.1109/AUTEST.2012.6334526","DOIUrl":"https://doi.org/10.1109/AUTEST.2012.6334526","url":null,"abstract":"This paper discusses how to interpret system specifications that involve the switching subsystem and how these specifications can be used to predict the effect on the signals passing through the system and if the system will even support those signals. These specifications include bandwidth, crosstalk and insertion loss. Actual waveform examples are included showing how the switching path can dramatically alter signals, particularly signals with higher frequencies or fast rise times.","PeriodicalId":142978,"journal":{"name":"2012 IEEE AUTOTESTCON Proceedings","volume":"34 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2012-10-22","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"116963495","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 2012-10-22DOI: 10.1109/AUTEST.2012.6334529
P. Donnelly, L. Sturlaugson, J. Sheppard
As part of a project to examine how current standards focused on test and diagnosis might be extended to address requirements for prognostics and health management, we have been exploring alternatives for incorporating facilities to represent gray-scale health information in the IEEE Std 1232 Standard for Artificial Intelligence Exchange and Service Tie to All Test Environments (AI-ESTATE). In this work, we extend the AI-ESTATE Common Element Model to provide “soft outcomes” on tests and diagnoses. We then demonstrate how to use these soft outcomes with the AI-ESTATE Fault Tree Model to implement a “fuzzy” fault tree. The resulting model then enables isolating faults within a system such that levels of degradation can also be tracked. In this paper, we describe the proposed extensions to AI-ESTATE as well as how those extensions work to implement a fuzzy fault tree using the demonstration circuit from previous Automatic Test Markup Language (ATML) demonstrations.
{"title":"A standards-based approach to gray-scale health assessment using fuzzy fault trees","authors":"P. Donnelly, L. Sturlaugson, J. Sheppard","doi":"10.1109/AUTEST.2012.6334529","DOIUrl":"https://doi.org/10.1109/AUTEST.2012.6334529","url":null,"abstract":"As part of a project to examine how current standards focused on test and diagnosis might be extended to address requirements for prognostics and health management, we have been exploring alternatives for incorporating facilities to represent gray-scale health information in the IEEE Std 1232 Standard for Artificial Intelligence Exchange and Service Tie to All Test Environments (AI-ESTATE). In this work, we extend the AI-ESTATE Common Element Model to provide “soft outcomes” on tests and diagnoses. We then demonstrate how to use these soft outcomes with the AI-ESTATE Fault Tree Model to implement a “fuzzy” fault tree. The resulting model then enables isolating faults within a system such that levels of degradation can also be tracked. In this paper, we describe the proposed extensions to AI-ESTATE as well as how those extensions work to implement a fuzzy fault tree using the demonstration circuit from previous Automatic Test Markup Language (ATML) demonstrations.","PeriodicalId":142978,"journal":{"name":"2012 IEEE AUTOTESTCON Proceedings","volume":"28 3","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2012-10-22","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"114107024","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 2012-10-22DOI: 10.1109/AUTEST.2012.6334546
K. Fertitta
The IVI Foundation has developed and maintained specifications for building instrument drivers for more than a decade. Until recently, there were two choices for building IVI-compliant instrument drivers - IVI-COM and IVI-C. Each of these driver technologies offers its own advantages for specific types of users, and each comes with its own set of disadvantages. The release of the IVI.NET specifications from the IVI Foundation introduces a new mechanism for controlling instrumentation from test system software. As a great deal of Windows desktop application development (as well as a considerable amount of web development) has shifted to the Microsoft .NET platform, the demand for tools that help test system developers work with .NET has grown. Conventional desktop application developers have benefited considerably from the productivity gains of working with .NET, and test system developers have already begun to enjoy the same. Having a driver technology that fully capitalizes on the benefits of the .NET platform and that marries naturally with .NET-based test system software is critical. This paper will examine the new IVI.NET standard and take a practical look at how IVI.NET drivers can simplify test system development.
{"title":"Simplifying test system development with IVI.NET","authors":"K. Fertitta","doi":"10.1109/AUTEST.2012.6334546","DOIUrl":"https://doi.org/10.1109/AUTEST.2012.6334546","url":null,"abstract":"The IVI Foundation has developed and maintained specifications for building instrument drivers for more than a decade. Until recently, there were two choices for building IVI-compliant instrument drivers - IVI-COM and IVI-C. Each of these driver technologies offers its own advantages for specific types of users, and each comes with its own set of disadvantages. The release of the IVI.NET specifications from the IVI Foundation introduces a new mechanism for controlling instrumentation from test system software. As a great deal of Windows desktop application development (as well as a considerable amount of web development) has shifted to the Microsoft .NET platform, the demand for tools that help test system developers work with .NET has grown. Conventional desktop application developers have benefited considerably from the productivity gains of working with .NET, and test system developers have already begun to enjoy the same. Having a driver technology that fully capitalizes on the benefits of the .NET platform and that marries naturally with .NET-based test system software is critical. This paper will examine the new IVI.NET standard and take a practical look at how IVI.NET drivers can simplify test system development.","PeriodicalId":142978,"journal":{"name":"2012 IEEE AUTOTESTCON Proceedings","volume":"135 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2012-10-22","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"126888749","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 2012-10-22DOI: 10.1109/AUTEST.2012.6334562
S. Sobolewski, W. L. Adams, R. Sankar
Automatic Modulation Recognition (AMR) is an example of implementation of Artificial Intelligence to cognitive radio received signal software testing. This article proposes two fairly simple and computationally feasible AMR algorithms, based on the principles of cyclostationarity and multi-fractals, suitable for practical real-time software radio communications applications for distinguishing Linear Frequency Modulation (LFM or Chirp), Pulse Width and Pulse Position Modulations (PWM/PPM) waveforms used in Radar systems, both commercial and military, from other commonly employed modulations such as, for example, BPSK, BFSK, GMSK. In these techniques, the incoming received signal is processed to determine the cyclostationary and multifractal features of the waveforms which are later matched by a neural network classifier with corresponding feature patterns of stored modulated waveforms, declaring the appropriate modulation present for whichever waveform produces the highest matching output. A spreadsheet of classification probabilities for both techniques is generated which compares their performance for the six studied waveforms.
{"title":"Automatic Modulation Recognition techniques based on cyclostationary and multifractal features for distinguishing LFM, PWM and PPM waveforms used in radar systems as example of artificial intelligence implementation in test","authors":"S. Sobolewski, W. L. Adams, R. Sankar","doi":"10.1109/AUTEST.2012.6334562","DOIUrl":"https://doi.org/10.1109/AUTEST.2012.6334562","url":null,"abstract":"Automatic Modulation Recognition (AMR) is an example of implementation of Artificial Intelligence to cognitive radio received signal software testing. This article proposes two fairly simple and computationally feasible AMR algorithms, based on the principles of cyclostationarity and multi-fractals, suitable for practical real-time software radio communications applications for distinguishing Linear Frequency Modulation (LFM or Chirp), Pulse Width and Pulse Position Modulations (PWM/PPM) waveforms used in Radar systems, both commercial and military, from other commonly employed modulations such as, for example, BPSK, BFSK, GMSK. In these techniques, the incoming received signal is processed to determine the cyclostationary and multifractal features of the waveforms which are later matched by a neural network classifier with corresponding feature patterns of stored modulated waveforms, declaring the appropriate modulation present for whichever waveform produces the highest matching output. A spreadsheet of classification probabilities for both techniques is generated which compares their performance for the six studied waveforms.","PeriodicalId":142978,"journal":{"name":"2012 IEEE AUTOTESTCON Proceedings","volume":"15 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2012-10-22","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"132212495","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 2012-10-22DOI: 10.1109/AUTEST.2012.6334528
P. Gilenberg
Cabling from the Unit Under Test (UUT) to the Test System has become an increasingly difficult challenge to overcome. There are a few distinct challenges. The distance between the UUTs and the Test System has become a major challenge with today's high speed busses. Current UUTs and Test Systems have trouble driving long cable lengths of 10 meters or more due to signal integrity reasons, latency, and the skew across high speed busses which can run as fast as 5Gb/s. Also, multipoint busses such as PCI do not have support for external cabling solutions which makes testing difficult. Furthermore, limited space in the General Purpose Interface (GPI) prevents the tester from cabling out all necessary signals. This paper will explore a solution to these problems, which is to bring a piece of the Test System close to the UUT, instead of bringing the UUT close to the Test System. In most Test Systems, there exists a master chassis with instrumentation. The key to solving this problem is to create a small form factor chassis that can be placed close to the UUT, which can be thought of as a Remote Test Head. The Remote Test Head is an extension of the Master Chassis allowing the same instrumentation and software to be used as in the local system; therefore saving the System Designer and TPS Developer from having to design new instrumentation or writing new tests. The connection between the Test System and the Remote Test Head is optical thus alleviating problems with signal integrity. The connection allows the Remote Test Head and the Test System to be more than 10m apart while still maintaining a throughput of 5Gb/s even when going through a GPI.
{"title":"What to do when your automated test equipment and Unit Under Test are out of reach?","authors":"P. Gilenberg","doi":"10.1109/AUTEST.2012.6334528","DOIUrl":"https://doi.org/10.1109/AUTEST.2012.6334528","url":null,"abstract":"Cabling from the Unit Under Test (UUT) to the Test System has become an increasingly difficult challenge to overcome. There are a few distinct challenges. The distance between the UUTs and the Test System has become a major challenge with today's high speed busses. Current UUTs and Test Systems have trouble driving long cable lengths of 10 meters or more due to signal integrity reasons, latency, and the skew across high speed busses which can run as fast as 5Gb/s. Also, multipoint busses such as PCI do not have support for external cabling solutions which makes testing difficult. Furthermore, limited space in the General Purpose Interface (GPI) prevents the tester from cabling out all necessary signals. This paper will explore a solution to these problems, which is to bring a piece of the Test System close to the UUT, instead of bringing the UUT close to the Test System. In most Test Systems, there exists a master chassis with instrumentation. The key to solving this problem is to create a small form factor chassis that can be placed close to the UUT, which can be thought of as a Remote Test Head. The Remote Test Head is an extension of the Master Chassis allowing the same instrumentation and software to be used as in the local system; therefore saving the System Designer and TPS Developer from having to design new instrumentation or writing new tests. The connection between the Test System and the Remote Test Head is optical thus alleviating problems with signal integrity. The connection allows the Remote Test Head and the Test System to be more than 10m apart while still maintaining a throughput of 5Gb/s even when going through a GPI.","PeriodicalId":142978,"journal":{"name":"2012 IEEE AUTOTESTCON Proceedings","volume":"39 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2012-10-22","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"132413402","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 2012-10-22DOI: 10.1109/AUTEST.2012.6334545
T. Mcquillen
For the most part, our military's legacy Test Program Sets (TPSs) are written in some derivative of IEEE Std 416/716 ATLAS (called adapted subsets, e.g. CASS ATLAS). Some have been in use for 30 years. As the hosting ATE systems are wearing out, we are faced with upgrading the hardware to support the legacy systems as well as technology insertion via system upgrades or new systems/subsystems being designed. From a software perspective, there are many avenues to be taken to “modernize” the legacy TPSs for the future. : Stay with the legacy adapted ATLAS subset. : Re-host in an industry standard ATLAS system. : Translate into another standard such as ATML with a “Carrier” language. : Rewrite from scratch into “C/C++/C#”. : Re-implement in a bench tester “Graphic/drag and drop” type system. : Or some combination of all of the above. The goals are the same no matter which method is chosen. Create a suite of TPSs that will support the legacy “black boxes” and future “black boxes”, and that are maintainable for the next 30 years. This paper discusses the various approaches and some of the pitfalls we may encounter.
在大多数情况下，我们军队的遗留测试程序集(tps)是用IEEE标准416/716 ATLAS的一些衍生版本编写的(称为适应子集，例如CASS ATLAS)。有些已经使用了30年。随着托管ATE系统的磨损，我们面临着升级硬件以支持遗留系统以及通过系统升级或设计新系统/子系统来插入技术的问题。从软件的角度来看，有许多方法可以使遗留的tps“现代化”，以便将来使用。:继续使用传统的ATLAS子集。:在工业标准的ATLAS系统中重新主机。:用“Carrier”语言翻译成另一种标准，如ATML。:从头重写为“C/ c++ / c#”。:在测试台上重新执行“图形/拖放”类型系统。或者以上几种情况的结合。无论选择哪种方法，目标都是相同的。创建一套tps，以支持遗留的“黑箱”和未来的“黑箱”，并在未来30年内可维护。本文讨论了各种方法和我们可能遇到的一些陷阱。
{"title":"Dealing with the multitudes of legacy TPSs","authors":"T. Mcquillen","doi":"10.1109/AUTEST.2012.6334545","DOIUrl":"https://doi.org/10.1109/AUTEST.2012.6334545","url":null,"abstract":"For the most part, our military's legacy Test Program Sets (TPSs) are written in some derivative of IEEE Std 416/716 ATLAS (called adapted subsets, e.g. CASS ATLAS). Some have been in use for 30 years. As the hosting ATE systems are wearing out, we are faced with upgrading the hardware to support the legacy systems as well as technology insertion via system upgrades or new systems/subsystems being designed. From a software perspective, there are many avenues to be taken to “modernize” the legacy TPSs for the future. : Stay with the legacy adapted ATLAS subset. : Re-host in an industry standard ATLAS system. : Translate into another standard such as ATML with a “Carrier” language. : Rewrite from scratch into “C/C++/C#”. : Re-implement in a bench tester “Graphic/drag and drop” type system. : Or some combination of all of the above. The goals are the same no matter which method is chosen. Create a suite of TPSs that will support the legacy “black boxes” and future “black boxes”, and that are maintainable for the next 30 years. This paper discusses the various approaches and some of the pitfalls we may encounter.","PeriodicalId":142978,"journal":{"name":"2012 IEEE AUTOTESTCON Proceedings","volume":"13 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2012-10-22","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"114213550","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 2012-10-22DOI: 10.1109/AUTEST.2012.6334559
J. Harnack
One of the major challenges engineers face when developing military test systems is balancing the life cycle mismatch of test equipment that's commonly deployed for 20+ years with the shorter life cycle of commercial-off-the-shelf (COTS) components often used in those systems. To ensure long term supportability of these systems, it is important to plan for obsolescence issues starting in the product development phase and continuing through the sustaining state to end of life. Successful long term support of test systems requires careful up-front planning, a proper system architecture, and a comprehensive long term life cycle management plan. Software is becoming increasingly more important in long term sustainment as it continues to define more and more of the test system functionality. A key software architecture for mitigating the impact of obsolescence is the implementation of hardware abstraction layers (HALs). A modular software architecture, such as a HAL, is an important proactive component of a life cycle management plan that also includes traditional hardware life cycle management strategies such as sparing, obsolescence tracking and planned technology refreshes. This paper examines some of the techniques used to manage test system obsolescence through HALs and hardware life cycle management.
{"title":"Life cycle planning from product development to long term sustainment","authors":"J. Harnack","doi":"10.1109/AUTEST.2012.6334559","DOIUrl":"https://doi.org/10.1109/AUTEST.2012.6334559","url":null,"abstract":"One of the major challenges engineers face when developing military test systems is balancing the life cycle mismatch of test equipment that's commonly deployed for 20+ years with the shorter life cycle of commercial-off-the-shelf (COTS) components often used in those systems. To ensure long term supportability of these systems, it is important to plan for obsolescence issues starting in the product development phase and continuing through the sustaining state to end of life. Successful long term support of test systems requires careful up-front planning, a proper system architecture, and a comprehensive long term life cycle management plan. Software is becoming increasingly more important in long term sustainment as it continues to define more and more of the test system functionality. A key software architecture for mitigating the impact of obsolescence is the implementation of hardware abstraction layers (HALs). A modular software architecture, such as a HAL, is an important proactive component of a life cycle management plan that also includes traditional hardware life cycle management strategies such as sparing, obsolescence tracking and planned technology refreshes. This paper examines some of the techniques used to manage test system obsolescence through HALs and hardware life cycle management.","PeriodicalId":142978,"journal":{"name":"2012 IEEE AUTOTESTCON Proceedings","volume":"160 Pt 1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2012-10-22","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"128741706","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 2012-10-22DOI: 10.1109/AUTEST.2012.6334570
B. Hoehne
In many applications, including radar, EW and SIGINT, the modulation bandwidth requirements are constantly increasing, but at the same time excellent signal fidelity is necessary and distortions have to be kept at a minimum. Traditional signal generators can provide the required signal purity, but most of them offer modulation bandwidths of only about 100 MHz. External arbitrary waveform generators and IQ modulators can achieve a much larger bandwidth, but the downside to their use is carrier feed-through and images. Another alternative is the digital I/Q modulation inside the arbitrary waveform generator (AWG). This paper presents a solution using a wide-bandwidth, high-precision AWG to generate waveforms with 2 GHz or more of modulation bandwidth and discusses the pros and cons of the different alternatives.
{"title":"Digital up conversion VS IQ modulation using a wideband arbitrary waveform generator","authors":"B. Hoehne","doi":"10.1109/AUTEST.2012.6334570","DOIUrl":"https://doi.org/10.1109/AUTEST.2012.6334570","url":null,"abstract":"In many applications, including radar, EW and SIGINT, the modulation bandwidth requirements are constantly increasing, but at the same time excellent signal fidelity is necessary and distortions have to be kept at a minimum. Traditional signal generators can provide the required signal purity, but most of them offer modulation bandwidths of only about 100 MHz. External arbitrary waveform generators and IQ modulators can achieve a much larger bandwidth, but the downside to their use is carrier feed-through and images. Another alternative is the digital I/Q modulation inside the arbitrary waveform generator (AWG). This paper presents a solution using a wide-bandwidth, high-precision AWG to generate waveforms with 2 GHz or more of modulation bandwidth and discusses the pros and cons of the different alternatives.","PeriodicalId":142978,"journal":{"name":"2012 IEEE AUTOTESTCON Proceedings","volume":"26 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2012-10-22","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"134456814","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 2012-10-22DOI: 10.1109/AUTEST.2012.6334582
J. Wu
Today's military systems rely for their performance on combinations of hardware and software. While testing of hardware performance during design, development and operation is well understood, the testing of software is less mature. In particular, the effect of hardware failures in the field on software performance, and therefore systems performance, is all-too-often overlooked or is tested in a far less rigorous manner that that applied to Hardware failures alone. Numerous examples exist of major system failures driven by software anomalies but triggered by Hardware failures, with consequences that range from degraded mission performance to weapons system destruction and operator fatalities. Measuring software development quality and fault tolerance is a challenging task. Many software test methods focus on source-code only approach (unit tests, modular test) and neglect the impacts caused by hardware anomalies or failures. Such missing test coverage can and will result in potential degraded software performance quality, thereby adding to project cost and delaying schedule. It can also result in far more disastrous consequences for the warfighters. This paper will discuss the general nature of the hardware-failure-software anomaly - system failure flow-down. It will then describe techniques that exist for system software testing and will highlight extensions of these techniques to focus on an effective and comprehensive software testing that includes performance prediction and hardware failure fault tolerance. The end result is a suite of test methods that, when properly applied, offer a systematic and comprehensive analysis of prime software behaviors under a range of hardware field failure conditions.
{"title":"Stress testing software to determine fault tolerance for hardware failure and anomalies","authors":"J. Wu","doi":"10.1109/AUTEST.2012.6334582","DOIUrl":"https://doi.org/10.1109/AUTEST.2012.6334582","url":null,"abstract":"Today's military systems rely for their performance on combinations of hardware and software. While testing of hardware performance during design, development and operation is well understood, the testing of software is less mature. In particular, the effect of hardware failures in the field on software performance, and therefore systems performance, is all-too-often overlooked or is tested in a far less rigorous manner that that applied to Hardware failures alone. Numerous examples exist of major system failures driven by software anomalies but triggered by Hardware failures, with consequences that range from degraded mission performance to weapons system destruction and operator fatalities. Measuring software development quality and fault tolerance is a challenging task. Many software test methods focus on source-code only approach (unit tests, modular test) and neglect the impacts caused by hardware anomalies or failures. Such missing test coverage can and will result in potential degraded software performance quality, thereby adding to project cost and delaying schedule. It can also result in far more disastrous consequences for the warfighters. This paper will discuss the general nature of the hardware-failure-software anomaly - system failure flow-down. It will then describe techniques that exist for system software testing and will highlight extensions of these techniques to focus on an effective and comprehensive software testing that includes performance prediction and hardware failure fault tolerance. The end result is a suite of test methods that, when properly applied, offer a systematic and comprehensive analysis of prime software behaviors under a range of hardware field failure conditions.","PeriodicalId":142978,"journal":{"name":"2012 IEEE AUTOTESTCON Proceedings","volume":"29 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2012-10-22","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"134553963","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 2012-10-22DOI: 10.1109/AUTEST.2012.6334561
R. Dunkley
Supporting a variety of communication protocols for test support equipment has typically required extensive hardware and Input/Output (I/O) interfaces targeting each protocol specifically. Recent advanced designs in the past ten years have created more dynamic approaches by using Field Programmable Gate Arrays (FPGAs) and embedded hardware to implement or simulate previous hardware I/O designs. The dynamic possibilities of FPGAs have recently been expanded with the introduction of Dynamic Partial Reconfiguration (DPR), which allows part of the FPGA to be reconfigured while the rest of the logic remains static. This paper evaluates the advantages and disadvantages of using DPR to interface with various communication protocols in test equipment.
{"title":"Supporting a wide variety of communication protocols using partial dynamic reconfiguration","authors":"R. Dunkley","doi":"10.1109/AUTEST.2012.6334561","DOIUrl":"https://doi.org/10.1109/AUTEST.2012.6334561","url":null,"abstract":"Supporting a variety of communication protocols for test support equipment has typically required extensive hardware and Input/Output (I/O) interfaces targeting each protocol specifically. Recent advanced designs in the past ten years have created more dynamic approaches by using Field Programmable Gate Arrays (FPGAs) and embedded hardware to implement or simulate previous hardware I/O designs. The dynamic possibilities of FPGAs have recently been expanded with the introduction of Dynamic Partial Reconfiguration (DPR), which allows part of the FPGA to be reconfigured while the rest of the logic remains static. This paper evaluates the advantages and disadvantages of using DPR to interface with various communication protocols in test equipment.","PeriodicalId":142978,"journal":{"name":"2012 IEEE AUTOTESTCON Proceedings","volume":"566 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2012-10-22","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"116655015","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
京公网安备 11010802042870号
京ICP备2023020795号-1
扫码关注我们
求助内容：
应助结果提醒方式：