u/OptigoNetworks

Episode four is up. Jim Meacham from Altura Associates and Doug Plumley from Dartmouth College joined Ping and me to talk about IT/OT convergence — not the LinkedIn-headline version, the version where someone walks into a meeting and says "I have eighteen routers" and the room goes quiet.

A few things we got into that are worth a watch:

• It's all IT once it's on the network, and the "OT" label sometimes gets in the way of the coordination that actually has to happen.
• Ping's million-dollar broadcast-storm story. IT comes in, rips everything out, drops new top-of-the-line switches. System gets worse.
• Security policy when IT's priority order is confidentiality-integrity-availability and OT's is the reverse. Short version: business priorities first, then policy, then a multi-year mitigation plan, because the lifecycle of these systems is way longer than IT is used to.
• Where to actually start as a director on either side: leadership, curiosity, and — Doug's contribution — pizza.

Watch the full version and subscribe for more: tohandshaketheotnetworkingseries.riverside.com

We keep seeing the same pattern in case studies and customer conversations. Building gets commissioned. Network looks fine on day one. Six months later, something is degrading and nobody can pinpoint when it started.

The traffic patterns at handoff are usually the canary. Polling rates that looked reasonable for 200 devices become a flood when the BAS expands to 800. COV thresholds that were never tuned generate noise the network can't process. Broadcast traffic creeps. Routing tables get crowded.

But these don't show up on a typical handoff checklist. The checklist is "all devices respond" and "all schedules execute," and that's a snapshot that goes stale fast.

So the question for the room: what should be on the handoff checklist that isn't? What's the warning sign you've learned to watch for that nobody told you about? Looking for the boring, unglamorous stuff that actually matters.

New episode of How to Handshake is up. This one's on BACnet Secure Connect — what it actually is, what it doesn't fix, and when (or whether) you should bother migrating.

Our guest is Nate Benes from the University of Nebraska. Nebraska is one of the few institutions in North America that designs and builds its own building automation gear in-house — they've been doing it since 1975. Nate is also a working member of ASHRAE's SSPC 135, the BACnet committee. So he's writing the standard and living with it on a real campus.

What we covered:

• BACnet/SC is just another data link in BACnet — same application-layer messages, new transport. Not a re-architecture.
• Hub-and-spoke vs. UDP broadcast, and what that means for BBMDs (spoiler: SC does away with the need for them, and supports a primary/failover hub architecture)
• Zero trust applied to building automation — authenticating who a device is rather than where it sits on the network
• Certificates and the certificate authority: who owns the CA when the integrator walks away, and why long-dated certificates (5, 10, 20 years) are an anti-pattern
• BACnet/SC and BACnet/IP coexisting in the same building via IP-to-SC routers
• BACnet/SC vs. VPN — why the attack surface is smaller (only BACnet packets cross the pipe, no lateral movement to the corporate file share)
• What the standard does and doesn't cover (cert lifetimes, CA ownership, network shape — left to integrators)
• What's in flight at the committee level: automated cert renewal (a Let's-Encrypt-style flow for BACnet), post-quantum cryptography, the EU Cyber Resilience Act, and the U.S. Cyber Trustmark
• BTL listings — you can filter the BTL site for BACnet/SC hubs and devices that are conformance-tested today
• Nate's "don't do this" list: SC is not a reason to put thermostats directly on the public internet, and it's not a reason to abandon network segmentation

Full episode, show notes, and the cleaned-up transcript: https://www.optigo.net/how-to-handshake-ep-3-bacnetsc/

Subscribe so you catch future episodes:

• Apple Podcasts: https://podcasts.apple.com/podcast/id1889945777
• Spotify: https://open.spotify.com/show/6Jg2yumYXCV2dRl1sIuPHO
• Deezer: https://www.deezer.com/us/show/1002831921
• YouTube: https://www.youtube.com/playlist?list=PLzATddJ3Lh0Jvhf7UgxuiBFBjqMibitUt

Happy to answer questions in the comments — and if there are topics, debates, or technical deep-dives you want us to tackle on a future episode, drop them below or send us a message.

Been thinking about commissioning handoffs and what tends to go wrong in the months and years after. This comes partly from conversations with people working in both automated commissioning and hands-on field controls, and it surfaced some early indicators worth sharing.

The ones that came up most:

Response times creeping up. For IP-to-IP controllers, over 100ms is a yellow flag. For controllers routing through an MS/TP segment, over 500ms isn't an early warning — it's already active degradation. Most post-commissioning monitoring doesn't touch this number at all.

Dropped packets and unacknowledged requests. These show up before devices go fully offline. If requests are going out without responses, something is already wrong — but it won't appear on any graphic until the controller stops responding entirely.

Operator overrides accumulating. Less obvious as a network health sign, but worth flagging: if operators are regularly overriding what should be running in auto, the root cause is sometimes a communication problem, not a sequence problem.

Stale databases. Devices that were decommissioned or moved but never removed from programming. They register as unreachable, add noise, and obscure real issues.

The compounding factor is that many buildings are commissioned under conditions — empty, controlled, no real load on the network — that don't reflect how they'll actually run once occupied. Things drift fast once real schedules and overrides start accumulating.

Curious what others are watching for. Is there a sign you've learned to catch early that isn't on this list?

Predictive maintenance gets a lot of attention in industrial OT, and the conversation in smart buildings is catching up. But the honest assessments from people doing the work tend to be more mixed than the marketing suggests. Wanted to open this up.

The skeptical case: most buildings have systems that have been drifting since commissioning. Applying analytics software on top of a network with unresolved issues tends to generate noise — false positives, spurious alarms, flags that don't reflect what's actually happening. Programs get deployed, lose trust within a year, and get quietly abandoned.

The optimistic case: if you deploy it on a well-commissioned, well-documented system with clean, verified data from the start, the upside is real. The problem isn't the concept — it's applying it on a broken foundation and expecting it to sort itself out.

The point both camps seem to agree on: the data has to be verified first. Not just captured — verified. A sensor reading that doesn't match actual equipment conditions makes everything downstream wrong, regardless of how sophisticated the analytics layer is.

Where have you seen predictive maintenance actually deliver in a building context? Where have you seen it fail? Is there a building type — hospital, campus, commercial tower — where it translates better than others?

Commissioning is not the finish line. It's closer to the starting gun.

That's the thread running through episode 2 of How to Handshake, where Saheel Chandrani of PingCX and Matt Miller from Fred Williams joined Ping Yao and I to talk about life after commissioning — and what it actually takes to keep an OT network healthy over the long haul.

We covered early warning signs, the documentation problem that every single person in this industry has hit, predictive maintenance (the honest version), and why the network health score belongs in the commissioning package from day one.

Full show notes and transcript on the blog. Subscribe wherever you get your podcasts!

https://www.optigo.net/how-to-handshake-ep-2-commissioning/

https://youtu.be/S1_74J8456U?si=s7ng5z_YmVvheskH

We published the EllisDon Facilities Services case study this week. It follows Pranjal De, Director of Technical Services at EDFS, and how he's used Optigo tools across nine years and two companies to manage OT network health in complex P3 environments.

A few highlights from the case study:

— A lighting integration dispute that could have run for weeks was resolved in one meeting after OptigoVN data showed the excess reads were originating from the lighting contractor's own system, not the BAS.

— A 14% network health score at a troubled site gave facility ownership the single data point they needed to authorize remediation. Score has since recovered to approximately 50%.

— Pranjal now presents four numbers in quarterly reporting to EllisDon's facilities leadership: the OptigoVN health score plus maintenance, energy, and comfort scores. That's the complete executive summary of how a building is performing.

Full case study: https://www.optigo.net/projects/ellisdon-casestudy/

This comes up constantly for the people we work with — integrators presenting to facility owners, technical services leads reporting to general managers, OT teams briefing real estate operations directors.

The technical reality (broadcast storms, duplicate device IDs, MSTP master conflicts) doesn't land with a non-technical audience. But decisions still need to get made, budgets still need to get approved, vendors still need to be held accountable.

What's worked for you? A single score, a traffic light system, a comparison to a known baseline, something else entirely?

Working through some thinking on this and curious what the community's current approach looks like.

For those managing multiple JACE-based sites: when a network issue shows up, what does your diagnostic process look like? Are you relying on remote access to Workbench, sending someone on-site, using a third-party capture tool, or something else?

Specifically wondering about the gap between detecting that something is wrong and actually capturing traffic to understand what's happening — that middle step feels like it's still pretty manual for most people.

What does your workflow look like?

There's a gap in most digital twin conversations that doesn't get talked about enough. The twin can tell you a zone is underperforming. It cannot tell you whether the root cause is a BACnet communication fault on the MS/TP segment feeding that zone. That requires a separate diagnostic layer that most implementations don't account for until something goes wrong.

We put together a breakdown of what a BACnet digital twin can realistically deliver in a commercial building context, where the performance gains actually come from, and why the OT network layer determines whether the investment pays off.

https://www.optigo.net/bacnet-digital-twin/

Curious what others are running into in the field — are you seeing digital twin projects stall out at the data layer, or is the bigger friction point getting stakeholder buy-in on the infrastructure side?

We're launching a podcast: How To Handshake, The OT Networking Series, presented by Optigo Networks.

Hosted by Ping and Ryan, it's built around the conversations that actually matter to people working on OT networks and building automation — not vendor pitches, not surface-level overviews.

First episode drops April 9th.

If there are topics or questions you'd like to see covered in the show, drop them here — we're still early enough that community input can shape where it goes.

https://preview.redd.it/i2ee67l7q7qg1.png?width=3000&format=png&auto=webp&s=7d936b0923f880596b8b05e80d92928e99f6a2a1