1 / 25

Self Describing Smart Sample Handling Systems and Intrinsically Safe CAN Bus

Self Describing Smart Sample Handling Systems and Intrinsically Safe CAN Bus. Tracy Dye, P.E. ABB Analytical. Why a Self Describing Smart Sample Handling System?. Concept and Vision. Concept

vereen
Download Presentation

Self Describing Smart Sample Handling Systems and Intrinsically Safe CAN Bus

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 Smart Sample Handling Systems and Intrinsically Safe CAN Bus Tracy Dye, P.E. ABB Analytical

  2. Why a Self Describing Smart Sample Handling System?

  3. Concept and Vision Concept An integrated process analytical system that can access and control the SHS while graphically displaying key SHS status and performance information in real time from any networked client (Process GC, Analyzer Network PC, etc.) Vision The combination of standard/non-proprietary building blocks in application layers (IS CAN physical layer and device profiles) grants component suppliers and analyzer OEMs the latitude to commercialize and end users the flexibility of a standard platform.

  4. Why IS CAN For NeSSI Bus? • Ability to “plug and play” in a Div 1 and Zone 1 classified area • CAN is everywhere for demanding applications (marine, auto, aerospace) • Balanced signaling (differential drive) enables superior noise rejection (relative to unbalanced single end) especially over cables • “As the EM spectrum becomes more fully utilized, EM fields radiated by a wide range of devices are increasing the probability of interference with other electronic equipment. Due in part to the wireless revolution in electronics, EM interference is increasingly becoming a widespread concern” - Steve Corrigan, Texas Instruments, Q3, ’06 • Already built in … • Data Integrity Mechanisms • Integral Bus Error Recovery and Self Correction • Message Prioritization Via Non-Destructive Arbitration • Mature and Well Defined Application Layers Such As CANOpen

  5. The Value Proposition • Improved System Reliability and Serviceability • Reduced Capital Costs • Reduced Operational and Maintenance Costs • Standard/non-proprietary platform basis

  6. Concept Origin • NeSSI Generation 2 • Opportunities For Improvement • Component Centric • Location of system level intelligence • Method for accessing, controlling, and graphically representing NeSSI system undefined • All components are networked

  7. Concept Origin • Pervasive System Philosophy • System centric architecture • System level control, awareness, access resides in a local SHS controller/server • System is object oriented and “Self Describing”

  8. Concept Building Blocks • SHS (Networked and Non-networked Components) • Process Analyzer (Including Non-network Enabled 3RD Party) • SHS Server/Controller

  9. Process Analyzer Integrated Smart Analytical System Architecture DCS Control Domain Plant PC Gateway Analyzer Domain Enclosure (NEMA & IP rated) Ethernet IS CAN Bus Component Domain EExd Div1/Zone 1 Heater ANSI/ISA SP76 substrate PID PID IS CAN SHS Server/Controller

  10. NETWORKED SHS DEVICES • SYSTEM LEVEL ADVANTAGES • SHS C/S can access and automatically observe and gather component ID, supplier data, etc. • Multivariate data are provided at a single node • Reduction in and management of communication cables • A/D conversion local to the SHS component

  11. NETWORKED SHS DEVICES • SYSTEM LEVEL DISADVANTAGES • Higher costs • IS requirements for the physical layer limit the choices for a communication bus; network link budgets tend to degrade

  12. The Methodology • SHS Component Visibility Framework • Networked and Non-Networked Components • Self Describing SHS • System Level Control

  13. SHS Component Visibility • SHS Node Classifications • Accessible • Directly acquirable by the SHS C/S • Detectable • Indirectly acquirable by the SHS C/S • Invisible • Neither accessible nor detectable

  14. SHS Component Visibility • Accessible SHS Node Classifications • Networked: Multivariate data and control access are provided over a common wire IS interface. • Non-Networked (Signal Level): Single signal/control access provided per interface connection.

  15. Accessible Accessible SHS Component Visibility • Non-Networked • Networked

  16. SHS Component Visibility • Detectable SHS Node Classifications • Isolatable: Attribute or detected condition ascribable to specific SHS component • Non-Isolatable: Attribute or detected condition not ascribable to any specific SHS component

  17. Flow Detectable Invisible Detectable SHS Component Visibility • Isolatable • Non-Isolatable

  18. Interim Conclusions • Making all SHS components network accessible is not entirely practical nor necessary • A unified procedure for acquiring data from all SHS components (Networked and non-networked) and “self describing” the SHS are still needed.

  19. The Methodology • Sample System Component Visibility • Networked and Non-Networked Components • Self Describing SHS • System Level Control

  20. SHS SYSTEM LEVEL CONTROL • Object Orientation • Each SHS component described by an object model using standard XML schema • Icon, port names and locations, predefined values and control fields to display component status or provide a graphical control handle, supplier specific data • The component class models coupled with structures and procedures (interconnection and collective operation) make up a composite SHS class

  21. C1 Component Object Models C2 C3 FP1 FP1 FP2 FP1 FP2 C4 Flow and Electrical Connection Netlists FP1 FP2 Component and System Object Modules SHS Controller/Server Data Structures

  22. SHS SYSTEM LEVEL CONTROL • SHS system centric approach • Control and access services are made available to external clients (PC, process analyzer, etc.) via a standardized XML schema served from the SHS Controller/Server • The SHS becomes “self describing” via this server-client relationship The object oriented approach embraces a holistic view of the SHS as a coherent system of both physical and logical components that must be combined to work collectively to fully realize SHS functionality.

  23. SHS SYSTEM LEVEL CONTROL • The “As-Built” Configuration • The system level representation of the SHS is now captured and described in an “As-Built” configuration file • The “As-Built” configuration file is flashed to the SHS server/controller and presented on various networked clients

  24. Summary • Reduced maintenance staffs; need for increased reliability and serviceability strongly dictate the need for a system centric, self describing SHS • IS driven by desire to plug and play (no EExd, no EExp); IS CAN with so much functionality already built in is a logical choice • A fully functional and cost effective smart SHS is achievable with a hybrid of networked and non-networked • Changes to the As-Built SHS Configuration requires no changes to software

More Related