https://preview.redd.it/vak9elwnaqdh1.png?width=1474&format=png&auto=webp&s=124f53c54ccd5286fe9eadce5cfa765b845c5f8f

Need to get data from solar farm, wind turbine, electrical substation, pumping station or sewage water treatment plant, utility meters for billing?

These devices speak by many protocols, so we have you covered:

• IEC 61850 Client and Server
• MMS and GOOSE
• IEC 60870-5-101 Client and Server
• IEC 60870-5-103 Client
• IEC 60870-5-104 Client and Server
• DNP 3.0 Client and Server
• Modbus TCP/RTU Client and Server
• OPC UA Client and Server
• DLMS Client and Server
• SNMP Client and Server
• SMTP Server

Do you need basic calculations such as 

• COS PHI
• APPARENT POWER
• ACTIVE POWER
• REACTIVE POWER

Or to even measure physical values? We have you covered!

• VOLTAGE
• CURRENT
• TEMPERATURE
• PULSES COUNTING

Welcome first RTU in the world with build-in data diode! Need more calculation, processing, archiving, visualising? We have you covered - BeyPur One presents all data as OPC UA, Comes with visualisation tools and with build-in historian.

Compliance is not the same as assurance

Industrial cybersecurity discussions often become trapped in standards language.

IEC 62443. ISO 27001. NIST. NESA. Policies. Certificates. Audits.

All of these can help. None of them can replace judgement.

The practical question is not whether a supplier can produce a certificate or a product security statement. The practical question is whether the actual plant architecture, actual exposure, actual firmware, actual recovery capability and actual operational constraints have been assessed independently.

There is a difference between evidence and judgement.

The OEM should provide evidence:

• product documentation
• firmware history
• patch statements
• hardening guides
• remote-access requirements
• end-of-support information
• known vulnerabilities
• recovery procedures

But the OEM should not own the final cybersecurity assurance conclusion for its own equipment.

Why? Because goat is not good gardener.

Because the same party may have designed it, supplied it, installed it, maintained it, upgraded it and commercially benefit from replacing it.

That is not a moral accusation. It is a conflict-of-interest problem.

Do not confuse OEM knowledge with independent assurance

OEM knowledge is valuable.

In some cases, it is essential. Nobody understands certain product internals better than the manufacturer. The OEM may know undocumented dependencies, firmware limitations, lifecycle constraints and recovery traps that an external assessor would otherwise miss.

So the OEM belongs in the assessment process. But not as the owner of the final risk judgement.

The distinction matters.

In conformity assessment, impartiality is not a cosmetic requirement. ISO/IEC 17065 treats impartiality as fundamental and explicitly separates certification from parties that design, manufacture, install, distribute or maintain the product, process or service being certified.

That principle is directly relevant to industrial control systems.

If a party benefits from one specific remediation path, especially a large upgrade, that party’s recommendation should be treated as input, not as independent assurance.

The board should not be asked to choose between “trust the OEM” and “ignore the OEM”.

The correct model is:

• OEM evidence plus independent assessment plus asset-owner accountability.
• Old does not automatically mean unsafe
• There is another trap in these discussions.
• Old system equals unsafe.
• New system equals secure.
• This is too simple.

An old but isolated, monitored and recoverable system may present less practical risk than a new system with remote access, weak governance and poor visibility.

• A supported operating system does not protect you from a bad architecture.
• A certificate does not remove an exposed attack path.
• A patch does not help if nobody knows the asset exists.
• An upgrade may be the correct decision. Sometimes it is unavoidable.

The issue is whether the system can be seen, understood, isolated, monitored and recovered.

I stood in front of 64 engineers and managers at one of the largest power utilities in Africa.

I asked one question.

"If something breaks, do you know how to fix it?"

The room went silent. Not the polite, waiting-for-the-next-slide kind of silence. The uncomfortable kind. The kind that tells you the honest answer is no. Or at least: not entirely.

That one question did more than any consultant report I have seen in this industry.

Here is the pattern I see before I walk into a meeting like that.

A utility has a real problem. Obsolete hardware. Known vulnerabilities. A compliance gap that keeps someone awake at night. They do the right thing. They call a big IT consulting firm. The firm sends a team, runs an assessment, and delivers a report. Sometimes 200 pages. Sometimes more.

The report says: upgrade everything.

The client looks at the cost. They look at the downtime that upgrade would require. They freeze. Nothing gets approved. Nothing gets done. The report goes on a shelf.

The problem does not go away. It gets bigger.

What makes this pattern dangerous is that the client feels like they acted. They spent money. They got a report. The box is checked. But the vulnerability is still there. The asset is still ageing. The risk is still growing.

That is worse than doing nothing at all.

Hey everyone! I'm u/Roupec, a founding moderator of r/BeyondPurdue.

Since 1996, I’ve worked closely with a large number of Industrial Control Systems clients.

As an Industrial Control Systems expert, I’ve been supporting, helping, and advising companies on how to ensure operational integrity for their Industrial Control Systems (ICS).

And through it all, I’ve discovered the subtle nuances that make a BIG difference in the success

of the companies that struggle and those that succeed in keeping their Industrial Control Systems well-maintained, operational, safe, and secure long-term.

While this encompasses a lot of things, it all pretty much boils down to complete control of your installed assets, secure data transfer, processes and procedures, compliance with the relevant standards, and life extension.

How to Get Started

1. Introduce yourself in the comments below.
2. Post something today! Even a simple question can spark a great conversation.
3. If you know someone who would love this community, invite them to join.
4. Interested in helping out? We're always looking for new moderators, so feel free to reach out to me to apply.

Thanks for being part of the very first wave. Together, let's make r/BeyondPurdue amazing.

Two magic words that explain nothing—so let’s start with a simple thought experiment.

Just imagine you are in a small boat on a river. If you stop paddling, where will it float? Obviously, it will follow the stream downhill, and in one direction only. Can we agree on that?

Now imagine you arrive at a lake created by a dam. The boat stops, but the water keeps flowing. The stopping of the boat represents that only the wanted data will leave the OT (Operational Technology) environment. That equals to protocols—or in other words, the languages systems use to communicate.

You must deliberately instruct the OT computer what data to subscribe to. In our experiment, that data is represented by water.

And the water allowed to flow downhill through the turbines represents the diode principle: it can flow in one way only.

The turbines generating electricity represent the data on the IT side. In other words, useful and only allowed information being presented in IT (Information Technology). But from below the dam, nobody knows what is behind it—because you cannot go back against the stream.

Of course, you can argue that someone could fly a drone over, or bribe a boat operator to see what’s behind the dam. But for that, we have other protective measures—those are outside this thought experiment.

So—is it clear now what a data diode is about? It’s a device which connects two computer and allows communication in one way only