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 –Reduced Operational and Maintenance Costs The specific need for SHS access, control, and visualization

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

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

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

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

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