1 / 31

ToSS: Testbed of Smart Sensors

ToSS: Testbed of Smart Sensors. Deniz Gurkan, PhD Department of Engineering Technology University of Houston dgurkan@uh.edu August 23, 2007. Motivation. Create test procedures for validation of IEEE 1451 NCAP-to-NCAP communications

thane
Download Presentation

ToSS: Testbed of Smart Sensors

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ToSS: Testbed of Smart Sensors Deniz Gurkan, PhD Department of Engineering Technology University of Houston dgurkan@uh.edu August 23, 2007

  2. Motivation • Create test procedures for validation of IEEE 1451 NCAP-to-NCAP communications • Determine possible network performance metrics for a 1451-compatible sensor network • Implement interoperability tests for off-the-shelf IEEE 1451 components • Encourage dissemination of IEEE 1451 standard through interoperability demonstrations

  3. Testbed Research Isolated work between control and decision support and networking aspects rigorous network and communication interface definitions idealized network assumptions TEDS Actuators Actuators Network Delay Mission Control Network Mission Control TEDS Sensors Sensors Instrument Error Transducer Independent Interface NCAP Sensor Error rigorous decision and control support idealized decision and control support

  4. Agenda • What does IEEE 1451 promise? • Overview of IEEE 1451-compatible products • NCAP-to-NCAP communication • Test Approach • Publish-Subscribe • Client-Server • Approach to sensor network performance analysis

  5. IEEE 1451 Allow manufacturers to build interoperable elements of a system: Network Capable Application Processor (NCAP) is a gateway between user’s network and Transducer Interface Modules (TIM) 1451.0 – NCAP ↔ TIM setup/manage, API 1451.1 – NCAP logical object model 1451.2 – RS-232 1451.3 – Wired Multi-drop 1451.4 – TEDS Only 1451.5 – Wireless 1451.6 – CAN Bus 1451.7 – RFID

  6. IEEE 1451 Compatible Products - 1 • Network Capable Application Processor (NCAP) • Manages TIM(s) • Converts Data from TIM and applies Corrections • Transmits corrected data over network • Transducer Interface Module (TIM) • Acquires the signal and performs A/D Conversion • Holds Cal Constants and Operating Parameters in TEDS Database

  7. IEEE 1451 Compatible Products - 2 • IEEE 1451.2 Prototyping Kit includes: • EM04a • EI02 • Wall transformer • Straight Ethernet patch cable • Crossover Ethernet patch cable • ESBus Programming cable • User Manual and CD with WebSensor Configuration software Also IEEE 1451.4 Mini NCAP and a Web Sensor available.

  8. IEEE 1451 Compatible Products - 3 Class II Sensor (RTD) resistance temperature detector LabView Front Panel GUI IEEE 1451.4 SCC Sensor Module NI-DAQmx and LabView Running on PC SC-2350 Carrier PCI-6221 DAQ Card

  9. IEEE 1451 Compatible Products - 4 • TEDS Sensor Interface Kit - Model 400B76 communicate with TEDS sensors over the USB port of a Windows PC. 400B76 reads TEDS from, and writes TEDS to, sensors. IEEE 1451.4 TEDS Editor by Kistler, Type 5000M04 Characteristics: The module is used in conjunction with a personal computer to read and write information stored in TEDS capable sensors. Model 070A70 Product Type: TEDS In-line Memory Module TEDS circuit in a housing for non-TEDS sensor, BNC jack to BNC plug

  10. The goal was … software NCAP … very little is interoperable so far.

  11. NCAP-to-NCAP Communication • Open Source: • Network Neutral NCAP • NIST: 1451.0 and 1451.5 demonstration • Basic requirements: • Publish-Subscribe • Client-Server • Subset of network visible operations

  12. NCAP-to-NCAP Communication: Operational Flow

  13. NCAP-to-NCAP Communication: On-the-wire testing Request_NCAPBlock_Announcement Message

  14. NCAP-to-NCAP Communication: On-the-wire testing NCAPBlock_Announcement Message

  15. Software Components Software Functions User Interface to Main Tester and NCAP under Test NCAP-to-NCAP Network Communications Client Process Server Process Publisher Process Subscriber Process NIST Interface to TIM and Sensors NIST Open Implementation of NCAP Desired for future TIM testing Emulator of NCAP with a State Machine Logical Object Model of NCAP or other Application NCAP under Test and NCAP as Tester Possible in the short run Desired User Interface

  16. NCAP-to-NCAP Communication CLIENT SERVER Client NCAP sends a GetNetworkVisibleServerObjectProperties () packet with Operation ID 4106. The packet length and the header length need to be calculated and the values sent in the packet. NCAP is configured for dynamic setup Server sends the output arguments and the return code that informs us about the success or failure of the operation. The packet format would be GetNetworkVisibleServerObjectProperties () server to client packet format. The return code is verified The server performs the requested operation Client NCAP sends a GetClientPortProperties () with the operation id 6149. The packet length and the header length need to be calculated and the values sent in the packet. The return code is verified The server performs the requested operation Server sends the output arguments and the return code that informs us about the success or failure of the operation. The packet format would be GetClientPortProperties () server to client packet format. Client NCAP sends a SetClientPortServerObjectBindings () with the operation id 6150. The packet length and the header length need to be calculated and the values sent in the packet. The server performs the requested operation The return code is verified Server sends the output arguments and the return code that informs us about the success or failure of the operation. The packet format would be SetClientPortServerObjectBindings () server to client packet format.

  17. Testing • 3 related types of tests: • Conformance Test • Functionality Test • Performance Test • Conformance and functional of higher priority

  18. Flow publish-subscribe

  19. Flow client-server

  20. Flow client-server cont.

  21. LabView NCAP

  22. LabView Hardware

  23. Testing Challenges • No real implementation or application • NCAP-to-NCAP communication • Network physical layer and topology • User and implementation platform choices • On-the-wire formatting • Protocol • Application • No finalized vision of the standard or the industry • Localized PlugFest on 1451 at UH

  24. Test Procedure • Title: The title of the test case provides the number and name. • Objective: Goal of the particular test. • References: List of resources that are used to create the test case. • Preconditions: List of assumptions before the test begins. • General Description: Brief summary of the ideal/expected behavior of the NCAP and the things that may go wrong. • Procedure: How the test cases progress and the essential details of the test case. • Result and Analysis: Final results of the test with all observed comments during the test. • Packets: Conformance tests will be performed over the packets involved in the test.

  25. NCAP under test (NUT) Current State Tester Node (TN) TN listening and NUT joins the network: TN checks for messages from NUT for ΔT NUT has no dynamic announcement CASE A Timeout PUBLISHING_ENABLED PSK_REQUEST_NCAPBLOCK_ANNOUNCEMENT PSK_NCAPBLOCK_ANNOUNCEMENT CASE B NUT identification is achieved TN listening and NUT joins the network: TN checks for messages from NUT for ΔT CASE C NUT is not configured to announce Timeout Test Flow - 1

  26. NCAP under test (NUT) Current State Tester Node (TN) PUBLISHING_ENABLED IgnoreRequestNCAPBlockAnnouncement IgnoreRequestNCAPBlockAnnouncement CASE D Client/Server Return Code - FAIL CASE E Client/Server Return Code - PASS After CASE D or E PSK_REQUEST_NCAPBLOCK_ANNOUNCEMENT CASE F NUT has not disabled its publishing: TN checks for messages from NUT for ΔT PUBLISHING_ENABLED Announcement is received  request message has overwritten ignore PSK_NCAPBLOCK_ANNOUNCEMENT NUT has incorrect state transition PUBLISHING_DISABLED PSK_REQUEST_NCAPBLOCK_ANNOUNCEMENT NUT has disabled its publishing: TN checks for messages from NUT for ΔT CASE G No announcement is received  request message does not overwrite ignore NUT has correct state transition Timeout Test Flow - 2

  27. CASE A If NUT has a dynamic announcement, it would announce itself to the network as soon as it is connected. CASE B NUT’s identification details such as IP address, MAC address, consecutively, object dispatch address, etc are in the announcement. CASE C NCAP is not configured to recognize a Request for Announcemnt message and does not respond with an Announcement. CASE D Return code will be unsuccessful if any one of the major and minor return codes are marked as failed. If all return codes are in pass condition, the tester will display a pass for this case. CASE E NUT has incorrect state for the expected operation – Publishing_Enabled although Ignore_ReguestNCAPBlockAnnouncement has been sent. CASE F NUT has correct state transition from Publishing_Enabled to Publishing_Disabled for the expected operation. CASE G Results

  28. Assign NCAP+TIM integrated modules to multiple sensors and actuators

  29. 1451 Conformance and Functions and Networking Performance Oxidizer Side Sensors and Actuators 1451 Tester Wireshark Fuel Side Sensors and Actuators 1451 Tester Wireshark 1451 NCAPs with actuator and sensor information.

  30. Use Historical Data on Nodes

  31. Thank You

More Related