Self Describing SHS Update

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