1 / 16

NeSSI  connectivity: progress on SAM and Smarts

This article discusses the progress made on the development of the NeSSI™ connectivity concept, specifically focusing on the selection of the NeSSI™-bus, the need for embedded and standalone SAM, prioritizing SAM applet software, and the requirements for NeSSI™ product manufacturers. It also explores user needs and the options available for SAM hardware.

royd
Download Presentation

NeSSI  connectivity: progress on SAM and Smarts

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. NeSSI connectivity: progress on SAM and Smarts Jeff Gunnell ExxonMobil Chemical Limited

  2. Domain architecture

  3. The NeSSI rail concept

  4. Objectives for CPAC fall 05 • Selection / finalization of the NeSSI™-bus or buses. • Articulate the need for both an embedded and a standalone SAM. • Prioritize the SAM applet software needed by end users to drive reliability. • Clearly describe what component makers need to do to produce NeSSI™ products.

  5. User wants • NeSSI(TM)-bus that is certified for both IS and non-IS. • Open architecture, non-proprietary NeSSI(TM)-bus communication - anyone's component can talk to anyone's analyzer. • Open connectivity to the process control and maintenance domains, using OPC. • Open transferable applets - across all analyser manufacturer's platforms for both the embedded and stand-alone SAM. • Plug and play sample systems.

  6. NeSSI Bus options

  7. SAM: hardware options Explained in the Gen II spec • updated for clarity in May 05 • see Section 10.3 • see Figure 10 http://www.cpac.washington.edu/NeSSI/NeSSI_Gen_II_Spec_6_21_04.pdf

  8. Figure 10 Stand-alone SAM Embedded SAM

  9. Stand-alone SAM • SAM has its own enclosure • The NeSSI-bus provides intrinsically safe, bi-directional communication with sensors and actuators • Heating for the substrate, enclosure or other devices is controlled by SAM • SAM communicates to the DCS and operations and maintenance domains via Ethernet.

  10. Embedded SAM • The sensor or analyzer has its own controller and is directly connected to the controller, eg: • spectrometer with a sample cell on the substrate connected by fiber optic cable • GC with the sample delivered by NeSSI • pH sensor connected with electrode cable • SAM is embedded into the analyzer controller • The NeSSI-bus provides intrinsically safe, bi-directional communication with sensors and actuators • Heating for the substrate, enclosure or other devices is controlled by SAM • Analyzer controller communicates to the DCS and operations and maintenance domains via Ethernet.

  11. SAM software applets Michelle Kohn (UOP) survey to identify priorities for elements in each major class of functionality: • Analyser / sample handling system monitoring and control • Validation routines • Asset management • Utility management • System health • User interface Responses according to: • Customer viewpoint: importance 1 = Nice to have 2 = Important 3 = Critical • Supplier viewpoint: ease of implementation 1 = Difficult > 6 months 2 = Easy < 6 months 3 = Doable now < 1 month • Priority = Importance x Ease Participants • Customers Dow ExxonMobil UOP/HW CPAC • Suppliers Parker Swagelok Circor ABB Emerson Siemens Infometrix

  12. Analyser / sample handling system monitoring and control

  13. Validation Full survey available on CPAC web-site: http://www.cpac.washington.edu/NeSSI/32_NeSSI_CPAC_Fall_2005/Software_Requirement_11_05.xls

  14. Legacy connectivity

  15. A way forward to develop SAM? • Start off with embedded systems in GCs • hardware (computing power) already there • networking to DCS/maint. domains already there • control of sample systems already part of design • Opportunity to develop and test functionality in fastest time and at lowest cost • Starts out with a natural deployment mechanism • Follow on by deploying the software into a stand-alone package • what ready made devices are already available?

  16. Reminder • Open discussion session this evening • As usual – should be lot’s of fun

More Related