160 likes | 172 Views
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.
E N D
NeSSI connectivity: progress on SAM and Smarts Jeff Gunnell ExxonMobil Chemical Limited
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.
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.
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
Figure 10 Stand-alone SAM Embedded SAM
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.
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.
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
Validation Full survey available on CPAC web-site: http://www.cpac.washington.edu/NeSSI/32_NeSSI_CPAC_Fall_2005/Software_Requirement_11_05.xls
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?
Reminder • Open discussion session this evening • As usual – should be lot’s of fun