1 / 17

Extending the IEEE1451.0 Std. to serve distributed weblab architectures

Extending the IEEE1451.0 Std. to serve distributed weblab architectures. Ricardo Costa - rjc@isep.ipp.pt Gustavo R. Alves - gca@isep.ipp.pt Mário Zenha-Rela - mzrela@dei.uc.pt. 1st Experiment@ International Conference Lisbon, Portugal 17 th – 18 th , November 2011. Introduction

andres
Télécharger la présentation

Extending the IEEE1451.0 Std. to serve distributed weblab architectures

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. Extending the IEEE1451.0 Std. to serve distributed weblab architectures Ricardo Costa - rjc@isep.ipp.pt Gustavo R. Alves - gca@isep.ipp.pt Mário Zenha-Rela - mzrela@dei.uc.pt 1st Experiment@ International Conference Lisbon, Portugal 17th – 18th, November 2011

  2. Introduction IEEE1451.0 Std. overview Modules & Layers TEDS structure HTTP API Distributed weblab architecture LabTEDS Operational sequence Registration Discovery Access process (reconfiguration & logging) Thin implementation Conclusions Presentation outline

  3. Introduction Engineering & Sciences courses require the adoption of good Teaching & Learning processes involving experimental and theoretical work components Experimental work Theoretical work - Traditional laboratories - Remote Laboratories (Weblabs) - Traditional classes - Virtual classes VLE (Virtual Learning Environments) Implemented using diferent architectures and APIs (Application Programming Interfaces) IEEE1451.0 Std. Difficult Developments & Resource Sharing Why ? No standard solution ! Global Online Laboratory Consortium

  4. IEEE1451.0 Std. overview Main modules Standard for network interface smart transducers (Sensors & Actuators) Transducer Interface Module (TIM): controls a set of Transducer Channels (TCs), implementing commands and protocols, supported on information within Transducer Electronic Data Sheets (TEDSs). Network Capable Application Processor (NCAP): performs network and TIM communications, data conversion and processing functions supported on Application Programming Interfaces (APIs).

  5. IEEE1451.0 Std. overview Modules & Layers

  6. IEEE1451.0 Std. overview TEDS structure (Transducer Electronic Data Sheet)

  7. IEEE1451.0 Std. overview HTTP API General format: http://<host>:<port>/<path>?<parameters>) HTTP API: •Discovery: Discovers IEEE1451.x communications modules, TIMs and TCs; •TransducerAccess: Reads/Writes TCs; •TEDSManager: Reads/Writes TEDS and manage NCAP-side cached TEDS. •TransducerManager: Provides control functions over TIM accesses, e.g., send arbitrary low-level commands to it.

  8. Distributed weblab architecture Map table Thin approach New TEDS Represents weblab instruments/modules (I&M) to be reconfigured in TIMs implemented using FPGA-based boards. "Work-in-progress on a thin IEEE1451.0-architecture to implement reconfigurable weblab infrastructures" Vol. 7, No. 3 (2011) of International Journal of Online Engineering (iJOE). ISSN: 1861-2121, November 2011 (already presented at REV'2011).

  9. LabTEDS An experiment may require several weblabs Weblab URI location Log file URI location (assessment purposes) Implemented as a thin or standard architecture (depends on the adopted APIs) Text-based TEDS Lab2go Metadata - Reference Model Specification

  10. Operational Sequence Overview • New IEEE1451.0 HTTP API functions and interfaces: • NCAPRegister, to register or unregister NCAPs (new Register API interface); • NCAPDiscovery, to discovery NCAPs (Discovery API interface); • ReadLabTeds and WriteLabTeds, to read and write LabTEDS (TEDS manager API interface); • ReadTIM and WriteTIM, to reconfigure weblab infrast. (new Reconfiguration API interface) and; • ReadLog and WriteLog, to read/write a log file for assessment (new Log access API interface).

  11. Operational Sequence Registration Process of register/unregister weblab infrastructures

  12. Operational Sequence Discovery Using NCAPDiscovery and ReadLabTeds functions to access registered weblabs infrastructures

  13. Operational Sequence Access (reconfiguration & logging) • Reconfiguring Weblab: • WriteTIM/ReadTIM for accessing the I&M in the TIM Log file xml schema contents format • Logging: • Activated in LabTEDS field 13 (WriteLabTeds) • ReadLog and WriteLog functions to read/write the Log file.

  14. Thin implementation Cross-map functions with low-level commands

  15. Conclusions • Currently there is no standard solution for implementing weblab architectures. • The IEEE1451.0 Std. may be a solution if its features are extended, namely: • Using a new TEDS (LabTEDS) – Provides information about each weblab infrastructure; • Defining new HTTP API functions and interfaces – Allows accessing specific weblab features (e.g. access LabTEDS information and logging files, and reconfigure weblab infrastructures); • Creating a Thin architecture – for single NCAP-TIM implementations it simplifies developments and avoids overloading NCAP/TIM modules. • Therefore, a standard solution based on the proposed architecture, that uses standard APIs and a common architecture, may bring advantages, promoting easier developments & more resources sharing.

  16. Thanks for your attention ! Ricardo Jorge Guedes da Silva Nunes da CostaEmail: rjc@isep.ipp.ptWebpage: http://www.dee.isep.ipp.pt/~rjc Acknowledgments:

  17. Extra slide • replaced by FPGA-based board(s); • the I&Ms will be developed using HDLs (Hardware Description Languages) following the IEEE1451.0 Std..

More Related