Welcome to our 7th article focused on Orbit 60. This article comes as we approach the first full commercial release of the Orbit 60 platform. As we reach this milestone, we have already started delivering and installing several systems across many market segments, and in several different countries. Our Minden, Nevada location has ramped up production and is currently busy fulfilling the dozens of pre-ordered systems in the queue.
Our past articles have been focused on the cyber security, hardware, and configuration aspects of the system:
- Q1 2020 Orbit Article – Introducing Orbit 60
- Q2 2020 Orbit Article – Available to Quote – Explore the Cost Savings
- Q3 2020 Orbit Article – Now – Less Spares!! – How to Choose Input Modules
- Q4 2020 Orbit Article – System Fundamentals – Output Cards
- Q1 2021 Orbit Article – Cyber Secure Condition Monitoring!
- Q2 2021 Orbit Article – Orbit Studio Configuration Software
In this article, we focus on how Orbit 60 was designed to comply with API Standard 670 and why that matters to you – even if you are not within the petroleum industries. Since Orbit 60 is built on a completely new architecture with many new features, including centralized processing, bridging, and cyber secure condition monitoring communications, it is natural to question if Orbit 60 is API 670 compliant.
In a nutshell, yes it is!
What is API 670?
API stands for American Petroleum Institute, and 670 represents the standard number. The 600-series body of standards and recommended practices encompasses mechanical equipment such as steam turbines, gas turbines, gears, pumps, centrifugal/axial compressors, couplings, and reciprocating compressors – to name a few. The API is a nonprofit trade organization that represents all aspects of America’s oil and natural gas industry. With 400 companies as corporate members, API’s membership spans everything from the largest major oil companies to the smallest of independents, whether involved in upstream, downstream, or mid-stream activities.
API has been primarily focused on the U.S., but in recent years, their work has grown to encompass a growing international dimension. API is recognized globally for its broad range of programs including:
- Research and Statistics
Each standard is worked on by a committee of experts in that field, representing end users, manufacturers, and specifiers (such as Engineering and Procurement Contractors) and centers on using proven-in-use experience to drive what an ideal product should provide. As such, API standards are often cited in product requisitions. API 670 is the standard that details how a Machinery Protection System should be specified.
Some other aspects of API 670:
- It is practical and detailed. Remember the committee members are all in the industry, and many of them have learned – often the hard way - what works and what does not.
- It is “testable.” In other words, it is easy to determine whether a system is compliant.
- It is a balance of “what” and “why.” In other words, it does not just say “do this”; it educates the user by saying “why you should do this.”
- It is voluntarily applied by users. In other words, if the standard suggests that a user do A, B and C, but the user has their own reasons for not doing “C,” that is acceptable; just do A and B.
- It is intended for Critical Turbomachinery. In other words, if you are monitoring a low-criticality, high-reliability asset, such as a 5 HP mister, then the requirements of API 670 may not be applicable.
- It resides within the same family of standards (600-series) as the mechanical equipment it is intended to monitor, and is thus overseen by API’s Subcommittee on Mechanical Equipment (SOME). This means that the individuals creating and maintaining the standard have both broad and deep machinery expertise – not just generic instrumentation expertise.
- It can be applied to other industries. The attributes of an API 670 system that allow it to work so well in oil and gas industry applications are the same reasons that its general provisions will usually also work in your industry.
What is the relevant scope of API 670?
- Design and performance specifications for…
- Monitor systems
- Displays / Indicators
- Field wiring, conduit, and enclosures
- Functional requirements
- Response speed
- Alarming capabilities
- Signal processing capabilities
- Fault tolerance and segregation
- System maintenance features (bypasses, alarm suppression, keylocks, fault indicators, etc.)
- Monitor racks / systems
- Field Wiring
- Test certificates
- Compliance certificates
- Factory Acceptance Testing
- Site Acceptance Testing
Does Orbit 60 comply with API 670?
As mentioned previously, yes it does. In this section, we address some of the specific details that are frequently questioned regarding Orbit 60’s compliance.
As the scope of API 670 is quite broad (it covers transducers as well as monitors), and many of the subsection items cover detailed specifications such as temperature, conformal coating, and areas where we have already proven we can and do meet the requirements with our 3500 system, this article will only cover some of the fundamental changes we’ve implemented in Orbit 60, such as the use of centralized rather than distributed processors, bridging multiple racks via Xtend™ fiber optic cables, cybersecure condition monitoring via patented aXess™ technology in our Condition Monitoring Module, and bi-directional communications in our Communications Gateway Module using ConneX™ technology. In this article, we reference the current (Fifth) edition of API 670, published in November of 2014. Readers should be aware that shortly after API publishes a new edition of a Standard, it starts work on the next edition as part of a 10-year cadence to ensure standards remain up-to-date and relevant. Instrumentation is especially impacted by advancements in technology, such as those that we are introducing with Orbit 60, and this is why the 6th edition of API 670 is currently in preparation with an anticipated publication date of 2023/2024.
Section 4.11.1 of API 670 describes functional safety, which has become an industry focus in the last two decades. Functional safety refers to a statistical analysis of the probability that a system will work when it is called upon. i.e. will there be any components, from the sensor, to the wiring, to the monitor, to the logic driver, to the contact, to the final element that will fail to operate correctly when a dangerous situation occurs? SIL 1 is the lowest “Safety Integrity Level,” while SIL 4 is the highest. In our experience, most customers use SIL 2 for radial vibration and axial position, and SIL 3 for overspeed. Orbit 60 has been designed to meet SIL 2 criteria without any component redundancy. SIL 3 overspeed detection, currently offered in our 3701 ESD product, will be released in the Orbit 60 platform in the near future.
4.11.4 d of 670 specifies that individual unfiltered buffered output connections for all transducers (except for temperature) must be made on the front and rear of the rack. In our past products, we have provided front panel BNC connectors. With Orbit 60, however, we have reduced the height of the rack by 50% and are adding an available (coming soon) front-facing integral display that occupies the entire front panel. So, where would we mount the individual BNC connectors, given the reduced rack size and the large integral display? Good question. Our solution is a special breakout adapter “dongle” that can be inserted into an ix Industrial Ethernet mating connector. These ix connectors are located on the front and rear of each input/output card. The signals are analog in nature – just as they have always been – and the connector style was chosen because it is locking, because it consumes very little panel space, because it can use standard CAT6 cable for longer runs where required, and because the components to build extension cables in the field are readily available.
The next subsection, 4.11.4 e, notes that if specified, a 4-20 mA DC analog output shall be provided for each measured variable used for machinery protection (in addition to a digital output as required by 4.13.1). In the first release of Orbit 60, this is accomplished through an auxiliary device that connects to the Communication Gateway and provides proportional outputs for each measurement. Next year this solution will be augmented by a dedicated Orbit 60 recorder output card. This card is very versatile, allowing users to output proportional 4-20 mA, 1-5 Vdc, or 0-10 Vdc signals. Further, if for some reason you wanted both Direct and 1X amplitudes for a particular channel, they can be assigned to separate outputs (as many cards as required can be installed in the rack and output channels are very easy to configure). To make this output card even more unique, we sample its outputs to verify that they are correct, and if this was not enough, we also designed this card to be SIL rated, such as when used as the input to a safety PLC!
Section 4.12 addresses relays. While 3500 is available with gold-plated mechanical relays to handle low current applications, Orbit 60 has been designed with two different types of relay cards: electromechanical and solid-state. Both meet API requirements.
In section 4.11.3 c it states that all modules will be capable of removal and insertion while the system is under power. This is nothing new for Bently Nevada equipment, our 3500 system has been capable of this for over 20 years. Orbit 60 also has this important capability as well.
Skipping over the transducer and transducer mounting requirements in sections 5 and 6, brings us to section 7 where the Vibration Monitor System is addressed1. 7.1.2 requires that unless otherwise specified, all system components shall be contained in one contiguous rack enclosure. While this can certainly be accomplished by utilizing either a 3U (half-height when compared with 3500) or a 6U (full-height, coming soon) system, we envision that with our new ConneX™ bridging capabilities, it will be much more economical in a new installation to split the system into remote input/output at the machine and a main processing unit in the control room. As has been communicated previously, this bridging system is quite robust and, with the use of fiber optic cables, allows for remote distances of up to 2 km. Further, the remote i/o concept allows users to instrument their auxiliary support equipment much more easily and cost effectively, allowing them to reap additional reliability benefits.
1 API 670 covers four different types of systems: vibration monitoring systems, overspeed detection systems, surge detection systems, and emergency shutdown systems. Section 7 deals with system attributes unique to vibration monitoring.
Single Circuit Failure
Section 7.1.3 a requires that a single circuit failure (power source and monitor power supply excepted) shall not affect more than two channels (regardless of channels available on the monitor module) of radial shaft vibration, casing vibration, sped indicating tachometer or six channels of temperature or rod drop on a single machine case. Further, it notes that the intent of this requirement is to ensure a design that will not lose all monitoring on a machine case in the event of a single circuit failure.
Orbit 60 addresses this requirement in several ways. First, we eliminated the need to have channel pairs, X and Y are easily mapped in the configuration software. This means that you can have bearing 1 X on a separate input card from bearing 1 Y, and the system will still provide measurements such as Smax. The second method we used was centralizing the processing power. For API 670 compliant installations, or for those units that are tripping machines, the installation of two Processing modules in a redundant configuration eliminates the single point of failure concern.
Section 7.1.6 requires an integral, dedicated display. The Orbit 60’s integral display will display all required indications and more, and will be released in the near future. However, just as 3500 met this section using externally connected displays a variety of non-integral displays are available now and can be mounted locally or remotely.
Rod Drop and Rod Position
Section 7.4.3 deals with piston rod drop measurements on reciprocating compressors. Reciprocating compressor monitoring functionality will be released in Orbit 60 in the near future. While this functionality will contain both triggered (18.104.22.168.a) and average (22.214.171.124.b) piston rod drop measurement modes, we have found that the use of an orthogonal probe in an X-Y arrangement instead of a single vertical probe yields superior results in many applications. This second probe is an “if specified” option in paragraph 126.96.36.199 and paragraph 188.8.131.52 provides an “if specified” option for a second channel to monitor this X-Y probe arrangement. Rod drop is a single-channel measurement that infers rider band wear. Rod position probes can be used to deliver both a rod drop measurement as well as the instantaneous motion of the rod for the entire stroke and for all positions within the cylinder clearance rather than just a single axis. For more information on piston rod position, please see our Orbit Article on New Piston Rod Condition Monitoring Functionality.
Section 8 describes Electronic Overspeed Detection Systems. We currently supply the ADAPT 3701/55 system for this purpose. It combines the functions of both overspeed detection and Emergency Shutdown (ESD) into a single integrated solution, as allowed under API 670 (see 8.3.3). Overspeed detection functionality will become available in the Orbit 60 platform in an upcoming release. It should be noted that although Orbit 60 is capable of providing integrated overspeed detection (API 670 section 8), ESD (section 9), and vibration monitoring functionality (section 7), API 670 explicitly precludes the integration of vibration monitoring with the overspeed system (see 8.3.4). As such, a separate Orbit 60 system with its own dual protection processors will be required for overspeed when strict compliance with API 670 is required. When strict compliance is not required, overspeed and vibration monitoring can reside in the same system.
Annex N, which is listed as “informative” rather than “prescriptive” discusses Condition Monitoring including methods, intervals, required data, and more.
Its first point, which is a cautionary statement and implemented in bold font, is that the Condition Monitoring functionality should in no way impede or compromise the purpose of the protection system. In Orbit 60, these two functions are firmly separated. As has been discussed in our article “Orbit 60 Series Update: Cyber Secure Condition Monitoring,“ the architecture of the Orbit 60’s Condition Monitoring Module, CMM, is such that it can listen to all of the signals on the system and report them to System 1, but - and this is very important – it cannot talk to the system at all. This means that there is no way for the CMM to interupt or impact the protective functionality of the Orbit 60 system.
- Process Data
Section 3.2.D of Annex N discusses the usefulness of process data brought into the Condition Monitoring System (CMS) from control and automation systems. While this data has always been available to System 1 via a Modbus connection, in Orbit 60 we have made it even easier through our ConneX™ Communications Gateway, available in 2022. This gateway not only serves our data to your DCS/Historian, it will also query data from these systems and pass it along to both the processing module for implementing state based alarming and the CMM for cyber secure passthrough of the data to System 1.
- Rolling Element Bearings
Section 11.6 of Annex N is focused on Anti-friction bearings. Later in 2021 Orbit 60 will include state-of-the-art rolling element bearing diagnostic information, including acceleration enveloping (N.13.2.14). This technique is generally regarded as the earliest detection method for rolling element, cage, outer race, and inner race defects because of its ability to detect peak impacts. Orbit 60’s algorithms have been developed to include this measurement for accelerometer channels. Because it is available as a standard measurement, it is trended in System 1. As noted in N.13.2.14, this technique is also applicable to gearboxes as well.
- Fluid-Induced Instabilities
Section 12 of Annex N addresses fluid induced instabilities. Oil whirl and whip are usually associated with vibration that is slightly less than half running speed (less than 0.5X). With Orbit 60, we now have the capability of adding trended variables for each of the vibration channels. These can be bandpass variables or nX vectors. The “n” in nX can be anywhere from 0.1 to 100 in increments of 0.1X. As can be imagined, there are many more applications for these new functions than just fluid instabilities. For example, 5X could be used for vane pass frequencies on five-vane pumps, gearmesh frequency for gears, ballpass and ball-spin frequencies for rolling element bearing defects, etc.
- Remote Access
Remote access is the subject of section N.17.6. The intrinsically cyber secure aXess™ technology used in our Condition Monitoring Module provides access to the data in the Orbit 60 system without having any ability to change alarm setpoints or protective system configurations. This means that it is possible to connect the Orbit 60 directly to the internet without any fear that a malicious party could disturb operations. While connection directly to the internet is possible, anyone desiring access to the data would have to have proper credentials and handshakes to gain admission to it.
Reciprocating Compressor Monitoring
Annex P is again informative rather than prescriptive. It pertains to the specifics of monitoring reciprocating compressors, which are covered in API Standard 618. This functionality will be introduced in the Orbit 60 platform in the near future.
So, to make a long answer short, YES, Orbit 60 is API 670 compliant!
Our teams are excited to discuss Orbit 60 in more detail, we have multiple technical white papers available for a deeper dive into the following topics. Please reach out through the contact us link below to receive a copy and we will connect you with your local expert.
- Orbit 60 Series or 3500 Detailed Comparison - This document details the difference between Bently Nevada’s Orbit 60 Series machinery protection system and the 3500 system.
- Orbit 60 Data Security Condition Monitoring Module - This document is intended to describe how the Condition Monitoring Module in the Orbit 60 Series Monitoring System provides a secure solution with full high-resolution data to external networks without jeopardizing the operation of the protection functions.
- Orbit 60 Series Bridging Concepts - Bently Nevada introduces the concept of bridging with the Orbit 60 Series system architecture.
- Coming Soon: Protection Schemes & 3500 Retrofit White Papers
Learn more about Orbit 60
As Global Hardware Commercial Leader, Darren is involved early in the new product introduction (NPI) process to commercially validate product viability, prioritize features based on customer value, and define overall commercial strategy on the hardware product portfolio. Darren has a Bachelors Degree of Mechanical Engineering and just celebrated 22 years with Bently Nevada.
Mr. Kingham has been involved in the rotating machinery realm for more than 35 years. He started with Bently Nevada in 1986 as a Machinery Diagnostics Engineer, where he diagnosed machinery problems based upon their vibration characteristics. Mr. Kingham has held various roles including Training Team Leader, Service Director, Field Application Team Leader, and now as Strategic Field Application Engineer. Mr. Kingham is a registered Professional Engineer with a BS Mechanical Engineering from Tufts University.