1 / 8

Self Describing SHS Update

Self Describing SHS Update. Tracy Dye, ABB CPAC November 9, 2006. Self Describing SHS Update. Acknowledgements: Kevin Sexton Lynn Hutchison. Why a Self Describing SHS?. Value proposition Improved System Reliability and Serviceability Reduced Capital Costs

Download Presentation

Self Describing SHS Update

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. Self Describing SHS Update Tracy Dye, ABB CPAC November 9, 2006

  2. Self Describing SHS Update • Acknowledgements: • Kevin Sexton • Lynn Hutchison

  3. Why a Self Describing SHS? • Value proposition • Improved System Reliability and Serviceability • Reduced Capital Costs • Reduced Operational and Maintenance Costs • The specific need for SHS access, control, and visualization

  4. Concept and Methodology Review • Pervasive system vs. component centric design philosophy • System level control, awareness, access resides in a local SHS controller/server w/ IS power and comms • Not all components have to be networked to create a self describing SHS (bar code or RFID) • Every component is described in a device profile and translated to XML schema (component state matrices, port location, schematic symbol, etc.) • Couple w/, control, flow and electrical net lists to create as-built system config file

  5. Self Describing SHS Progress • Much of the effort and focus in 2006 has been on the IS CAN physical layer standard • ABB has developed an XML schema framework for SHS component description is in place • Creation of SHS component device profile standard has been placed within the SP76.51 subcommittee

  6. The Next Steps • Work with SHS component suppliers to create SHS component classes (for example, multivariate data/networked, single signal non-networked, mechanical only) • Gain agreement w/ component suppliers on standard device profile template for all applicable SHS components (including power management/current consumption); work into SP76 • Apply the developed XML schema framework to the component device profiles

  7. Areas of Standardization • Device profile for SHS component data and mechanical makeup • Existing comm and user layer device profiles (IS CAN and Foundation Fieldbus)

  8. Areas of Commercialization • CAD tools for self describing SHS design configuration • SHS diagnostic macros • User layer apps

More Related