Abstract
Testbeds for wireless IoT devices facilitate testing and validation of distributed target nodes. A testbed usually provides methods to control, observe, and log the execution of the software. However, most of the methods used for tracing the execution require code instrumentation and change essential properties of the observed system. Methods that are non-intrusive are typically not applicable in a distributed fashion due to a lack of time synchronization or necessary hardware/software support. In this article, we present a tracing system for validating time-critical software running on multiple distributed wireless devices that does not require code instrumentation, is non-intrusive and is designed to trace the distributed state of an entire network. For this purpose, we make use of the on-chip debug and trace hardware that is part of most modern microcontrollers. We introduce a testbed architecture as well as models and methods that accurately synchronize the timestamps of observations collected by distributed observers. In a case study, we demonstrate how the tracing system can be applied to observe the distributed state of a flooding-based low-power communication protocol for wireless sensor networks. The presented non-intrusive tracing system is implemented as a service of the publicly accessible open source FlockLab 2 testbed.
Highlights
The development and validation of networking protocol implementations for distributed IoT devices is challenging
6.3 Non-Intrusive Tracing of a Time-Critical Synchronous Transmission Protocol In the first part of the case study, we investigate the impact of serial logging compared to nonintrusive tracing using the data trace service
We present how native on-chip debugging can be put to use in the context of testbeds for wireless IoT devices
Summary
ACM Transactions on Internet of Things, Vol 3, No 1, Article 5. Hardware assisted debugging and tracing: Tracing with dedicated debug and trace hardware (including built-in subsystems) allows for non-intrusive tracing and does not require code instrumentation, see for example References [14, 29] This is usually only supported for a single device under test. To the best of our knowledge, no testbed architecture provides a truly non-intrusive distributed tracing method without the need to instrument the code This would be necessary to validate the software in the last stage before deployment [34]. Based on our own needs to test timing-critical networking protocols in setups that are as close to the real-world deployment as possible, we worked out the following requirements that should be met by a testbed when debugging and validating target node software before deploying it:.
Sign-in/Register to view highlights & summary Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a callDisclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.
