TL;DR
- Baker Hughes’ System 1 page now presents the software as “an all-in-one condition monitoring platform that is part of our Cordant™ suite of software offerings”, driven by three pillars: Connectivity, Analytics and Visualization.
- Nothing on the page announces a release, a version number or a new model. The change is content maintenance, not a product launch — the page carries no visible “last updated” line.
- Cordant is an umbrella brand, not a single application: Baker Hughes describes it as a modular, AI-enabled industrial enterprise solution, split into Cordant Applications and Cordant Devices. System 1 sits inside that suite as software.
- The page lists “seamless integration” with Orbit 60 Series, 3500, Orbit DCM, Ranger Pro and SCOUT. The only mechanism it actually names is OPC UA export of waveforms, trends and alarm data, plus built-in data replication and data diode support.
- “Cyber Asset Management and Protection” protects the monitoring system itself — System 1 servers and clients, with patch management, antivirus and host intrusion protection — not the machine’s mechanical health. Machinery health is a separate service line on the same page.
What actually changed on the System 1 page on 7 November?
Very little, in product terms. The page is a product overview for System 1 Asset Health Management Software, and what it now states is a positioning statement: System 1 is the all-in-one condition monitoring platform inside the Cordant suite, organised around three pillars, with a list of supported monitoring and protection hardware and a set of support services attached.
There is no release note, no version number, no new hardware model and no dated announcement on the page. That matters for anyone reading the change as news: a page edit is not a version release. If you arrived here expecting a System 1 22.x feature announcement, this is not it.
Version numbering is worth one clarification, because it is widely misread. System 1 Evo is Evolution, not a separate product: Bently Nevada’s own device documentation refers to “System 1 Evo version 18.2 and newer” and “System 1 Evo (v20.1 and later)”, and the v20.1 What’s New support matrix lists 17.2, 18.1, 18.2, 19.1, 19.2 and 20.1 in a single table. Those are one line, numbered year.sequence, with the real architectural break further back at System 1 Classic. Baker Hughes also states a semi-annual cadence — “targeted releases in April/May and October/November”, each supported for a minimum of two years — so a November page edit carries no implication of a release. Nor is 21.2 the current reference point: Baker Hughes’ own Cordant training catalogue lists System 1 v23.2 or later.
It is also worth being precise about the date. Baker Hughes does not print a “last updated” line on this page, and the page metadata still records an earlier modification date, so the 7 November change is best treated as a content-maintenance edit picked up by page monitoring rather than something the company announced. The substance below is what the page says today, read directly from it.
Is System 1 a product, or one part of Cordant?
Both, depending on how you draw the line. System 1 is a named, licensable software product with its own datasheet, brochures, maintenance agreements and version history. At the same time, Baker Hughes now files it under Cordant, and the wording is specific: System 1 is part of the Cordant suite of software offerings, not the suite itself and not a Cordant sub-brand.
The Cordant page describes the parent differently again — “a modular, AI-enabled industrial enterprise solution designed to optimize assets, processes, and energy use at scale” that combines sensing and protection hardware with open digital solutions, drawing on the Bently Nevada and ARMS Reliability heritage. It is split into two visible halves: Cordant Applications, which carry the analytics and workflow layer, and Cordant Devices, the hardware side.
So the structure reads as: Cordant is the enterprise-level brand and architecture; System 1 is the condition monitoring platform inside it; Orbit 60 and 3500 are the protection and monitoring devices that feed it. That is a brand and portfolio reorganisation, not a re-platforming of the software. For a plant running System 1 today, the practical question is unchanged — what data goes in, what analysis comes out, and what it takes to keep the servers patched. If you are tracking how the hardware side of that branding shifted, the [Cordant Devices label and what it changed for 3500 spares buyers](/bently-nevada-cordant-devices-spares-buyers/) is the relevant background.
What do the three pillars actually mean in practice?
The pillar framing is not decorative: each pillar has three named capabilities underneath it, and those nine capabilities are the most concrete content on the page. They are worth reading as a specification of scope rather than as marketing categories.
| Pillar | Named capabilities | What it means on a plant |
|---|---|---|
| Connectivity | Comprehensive Machine Data Collection; Intelligent Machine Health Data Management; Flexible and Secure Data Transfer | Getting machine, process and control data into one place, collecting at different rates by operating state, and moving data out again without opening the plant network. |
| Analytics | State-Based Alarms; Knowledge-Based Machine Learning; Advanced Machine Thermodynamic Monitoring | Alarm thresholds that follow load and operating state, rule-based Decision Support on top of them, and thermodynamic performance analytics as an option. |
| Visualization | Plantwide HMI; Comprehensive Machine Diagnostics Tools; Case Management | A plant schematic with colour-coded health, the plot and diagnostic toolset behind it, and a record of findings that survives the engineer who found them. |
Connectivity: where does the data come from, and how does it leave?
The page is unusually specific here, and three details carry most of the weight.
Collection is state-aware. System 1 collects at different rates depending on machine operating mode, and then applies data thinning — periodically summarising historical data into smaller sets with fewer points — so that years of history stay storable. For a plant deciding how much historian to buy, that is the mechanism that determines the answer; it is not a bolt-on.
Export is OPC UA. The page states that System 1 “supports the industry-standard OPC UA protocol for export of waveforms, trends and alarm data to other data systems, data lakes and analytics platforms.” Note the direction: this is export. It is the hook that lets System 1 feed a corporate data platform without replacing the condition monitoring layer — and it is the single integration claim on the page that names a protocol.
Transport is replication and data diode. Built-in replication and data diode support let System 1 data cross public and internal networks in one direction, which the page ties explicitly to simplifying NERC CIP and other cybersecurity compliance. In practice that is the difference between an air-gapped monitoring network and one with a controlled, documented egress path.
One nuance worth knowing if you are auditing an existing install: data collection over OPC is a separate path from OPC UA export. Bently Nevada’s “What’s New” note for System 1 version 21.1 refers to OPC DA import settings being renamed after the Baker Hughes separation from GE, which is the inbound side of the same protocol family. The page does not describe inbound collection in protocol terms.
Analytics: what does System 1 do with the data?
Three layers are named, and they are not interchangeable.
The base layer is state-based alarming: collected values are compared against alarm levels that vary with load and operating state, so a start-up ramp does not trip the same thresholds as steady-state running. That is the foundation for a proactive strategy, and it is the part every System 1 installation uses.
The second layer is Decision Support, described as knowledge-based machine learning: configurable rules that encode an experienced engineer’s logic and apply it consistently. It is an option, not part of the base platform, and it is where plant-specific knowledge becomes repeatable rather than dependent on who is on shift.
The third layer is Bently Performance, which adds thermodynamic and mechanical information to condition analytics — performance monitoring alongside vibration. Again an option, and the reason performance and condition data can be correlated within one tool rather than across two.
Because two of the three are options, “System 1” in a quotation can mean materially different scope depending on whether Decision Support and Bently Performance are licensed. That is a procurement detail the page does not resolve.
Visualization: what does “plantwide visibility” look like?
The pillar’s first capability is a plantwide HMI: a virtual depiction of plant assets with colour-coded health indicators, so an operator sees priority assets at a glance rather than a list of tags. The second is the diagnostics toolbox — trend analysis and baselining, alarm prioritisation and suppression, fault and root-cause analysis, repair confirmation and setpoint management, across asset-specific plot types.
The third, Case Management, is the one most often skipped in evaluations and the one that decides whether a monitoring programme compounds. It provides the tools to annotate instances of machine damage, generate reports for field or plant teams, and build audit files as archives. Without it, a fault that was diagnosed in 2024 is re-diagnosed from scratch in 2027.
How do Orbit 60 and 3500 actually connect to System 1?
The page’s own sentence is marketing language: System 1 “provides seamless integration with a variety of industry-leading machinery monitoring and protection hardware, vibration sensors, and sensor platforms.” What follows that sentence is more useful — a named device list with links, which is the real compatibility statement.
What the page does not do is describe the connection per device. There is no statement of which protocol each family uses, whether a gateway or transient data interface is required, how the data path differs between an Orbit 60 rack and a 3500 rack, or whether third-party protection systems are supported on the same footing. Those gaps matter, because “seamless integration” covers several quite different architectures: a device that streams to System 1 directly, a device that needs an intermediate server, and a device whose data arrives through an OPC path are all “seamless” in a brochure.
Which hardware feeds System 1?
The page names five device families from Bently Nevada and Baker Hughes. Their roles are not the same, and that distinction determines what a System 1 installation can actually see.
| Device | Role as described by Baker Hughes | Why it matters for System 1 scope |
|---|---|---|
| Orbit 60 Series | Machinery protection and condition monitoring device | Protection plus condition data from a current-generation platform; the newest rack family in the list. |
| 3500 | Machinery protection and condition monitoring device | The installed base. Most System 1 sites inherit a 3500 rack, so its module mix sets what data exists to analyse. |
| Orbit DCM | Distributed condition monitoring device | Extends monitoring to assets that are not worth a rack, which changes channel economics. |
| Ranger Pro | Wireless condition monitoring device | Reaches balance-of-plant assets where cabling cost would otherwise kill the business case. |
| SCOUT | Portable condition monitoring device | Route-based data that fills gaps between permanently monitored machines. |
The pattern is a portfolio argument rather than an engineering one: protection racks for critical trains, distributed and wireless devices for the long tail, portable collection for everything else, one software layer over the top. Whether that layer is genuinely one depends on the connection mechanism, which is where the page goes quiet.
Two adjacent subjects are worth separating from this. Orbit 60’s own security posture is a device question, covered in the analysis of [what “designed to SL4” does and does not certify](/orbit-60-iec-62443-sl4-architecture-vs-certification/). And the long-term support position for the older rack family is a lifecycle question, covered in the [3500 long-term support and PCBA refresh review](/bently-nevada-3500-pcba-refresh-long-term-support/). Neither is a System 1 software issue, even though all three get discussed in the same maintenance meeting.
What does “Cyber Asset Management and Protection” actually protect?
This is the item most often misread, so it is worth stating plainly: it protects the monitoring system, not the machine.
On the page, “Cyber Asset Management and Protection (health monitoring, backup, updates, anti-virus, patches)” appears as a line item inside System 1 Hosted Services. Read in context, “health monitoring” here means the health of the System 1 servers and clients — is the historian running, is the service up, is the disk filling — not the mechanical health of a turbine. The parenthetical gives it away: backup, updates, antivirus and patches are IT/OT hygiene tasks applied to hosts.
The separate, longer description on the same page uses a slightly different name, “Bently Nevada Cyber Asset Protection (CAP)”, and defines it as “cyber security best practices for patching and defending System 1 Servers and Clients using patch management and antivirus/host intrusion protection”, with tested, documented, scripted and securely delivered Windows and antivirus patches on a monthly basis. It is supplied under a Premier-level maintenance and support agreement or as a standalone option.
Note the two naming variants — “Cyber Asset Management and Protection” in the hosted services list and “Cyber Asset Protection (CAP)” in the support section — and the small scope difference between them: backup appears in the hosted-services wording but not in the CAP description. If a contract depends on backup being included, that is a question for the order, not the brochure.
The machine-health counterpart is listed separately, as “Machinery Asset Health Services”, linking to remote condition monitoring and machine diagnostics. That is the service that looks at the asset: diagnostics, interpretation, recommendations. Two different services, two different budgets, and — importantly — two different failure modes if you buy one and assume you bought the other.
What the page does not disclose
For a reader who needs to specify or budget, the gaps are as important as the claims. The page does not state:
- any System 1 version number, release date or feature delta;
- the connection protocol for each supported device, or whether a gateway or transient data interface is needed per family;
- support for Modbus, or for third-party protection systems beyond the Bently Nevada and Baker Hughes list;
- inbound collection protocols, as distinct from the OPC UA export path;
- licensing structure, pricing, or which of Decision Support, Bently Performance and Case Management are separately licensed;
- the cybersecurity certification level of System 1 itself, as opposed to its patch process;
- hosted service regions, SLA terms, or what a “remote system health check” covers in hours and depth.
None of these can be inferred from the page, and none should be filled in from a brochure. They belong in a written clarification request to Baker Hughes or an authorised channel.
What this means for a reliability or spares team
Three practical readings.
The software did not change; the framing did. If your site runs System 1, nothing in this page edit changes your upgrade path, your licence position or your support agreement. Treat announcements of “page updates” as positioning signals, and check version-specific documents before planning any software move.
The hardware list is the compatibility statement. Orbit 60, 3500, Orbit DCM, Ranger Pro and SCOUT are the named families, and the practical constraint on any expansion is which of those you already own and how their data reaches the System 1 server. A new wireless or distributed layer is only “seamless” if the path is documented — ask for it per family.
Separate the two health conversations. System health (patches, antivirus, backups, server uptime) and machinery health (diagnostics, root cause, recommendations) are different services with different owners. Sites that conflate them tend to discover the gap during an incident, when the monitoring server is the thing that failed. The 20-year record behind the platform — [10,000-plus active users and two decades of installed base](/bently-nevada-system-1-20-years-10000-users/) — is precisely why so many sites now have both an ageing server estate and a mature analytics practice. A published refinery case, such as the [Natref reciprocating compressor programme built on 3500 and System 1](/natref-bently-3500-system-1-recip-compressors/), shows what the combination looks like when both halves are resourced.
For compact or skid-mounted assets that sit outside a rack architecture entirely, the same question recurs at smaller scale — see how [DIN-rail vibration monitoring in the 2300 Series](/bently-nevada-2300-series-din-rail-vibration-monitoring/) is positioned for that segment. The pattern holds: the device decides what data exists, the software decides what you can do with it, and neither substitutes for the other.
Frequently asked questions
Did Baker Hughes release a new version of System 1 in November 2026?
The System 1 page carries no release announcement, version number or dated statement, so there is no evidence of a software release in this change. It is a content-maintenance update to the product overview page. Version history is published separately in Bently Nevada’s “What’s New” documents, which cover releases such as 21.1, 22.2 and 23.x.
Is System 1 the same thing as Cordant?
No. Cordant is the umbrella brand for Baker Hughes’ industrial enterprise software and hardware portfolio, split into Cordant Applications and Cordant Devices. System 1 is described on its own page as an all-in-one condition monitoring platform that is part of the Cordant suite of software offerings. Cordant is the portfolio; System 1 is a product inside it.
Does System 1 integrate with Orbit 60 and 3500?
Yes, both are named on the page as supported machinery protection and condition monitoring devices, alongside Orbit DCM, Ranger Pro and SCOUT. The page calls this “seamless integration” but does not state the protocol, gateway or data path for each family, so the mechanism has to be confirmed per device rather than assumed.
Which protocols does System 1 use?
The only protocol the page names is OPC UA, used for exporting waveforms, trends and alarm data to other systems, data lakes and analytics platforms. It also states built-in data replication and data diode support for secure transfer across networks. Modbus and other inbound collection protocols are not mentioned anywhere on the page.
Does Cyber Asset Management and Protection monitor machine health?
No. It protects the monitoring system itself — System 1 servers and clients — through patch management, antivirus and host intrusion protection, with monthly Windows and antivirus patches. Machine health is a separate service line, Machinery Asset Health Services, which covers remote condition monitoring and diagnostics of the assets.
What are the three pillars of System 1?
Connectivity, Analytics and Visualization. Each has three named capabilities: Comprehensive Machine Data Collection, Intelligent Machine Health Data Management and Flexible and Secure Data Transfer under Connectivity; State-Based Alarms, Knowledge-Based Machine Learning and Advanced Machine Thermodynamic Monitoring under Analytics; Plantwide HMI, Comprehensive Machine Diagnostics Tools and Case Management under Visualization.
Sources
- Baker Hughes, System 1 | Bently Nevada — read 9 November 2026; source of the Cordant positioning, the three pillars and their nine capabilities, the device list, the OPC UA statement, the hosted services wording and the Cyber Asset Protection description.
- Baker Hughes, Cordant — source of the description of Cordant as a modular, AI-enabled industrial enterprise solution and of the Cordant Applications / Cordant Devices split.
- Baker Hughes, Plant-Wide Condition Monitoring with Clarity and Context — background on Replication and the HMI Builder within System 1.
- Bently Nevada, Welcome to System 1 Version 22.2 and What’s New v21.1 — version context and the OPC DA import note.
Note on dating: the System 1 page carries no visible last-updated line and no release date. This article describes what the page states as read on 9 November 2026, and treats the 7 November change as content maintenance rather than an announced release.
SpareTechHub supplies Bently Nevada and Baker Hughes monitoring hardware — 3500 modules, Orbit 60 cards, sensors and cable assemblies — to plants maintaining installed condition monitoring systems. If you are matching system-side software scope with the hardware actually installed, send us your module list and rack configuration and we will confirm part numbers and availability.
