Salem Automation, Inc.

09/03/2026

What every Data I/O 280 needs: a UV erase station. Another one from Salem Automation's trove of old artifacts.

Before an EPROM could be programmed, it had to be blank — and blanking it meant light, not electricity. On this one, a lamp head sits on a cantilever arm above a transformer box. You'd slide the chip under the lamp, set the dial, and walk away.

That dial was the entire user interface. No verify, no feedback. You dosed by the clock and found out back at the programmer whether it took. And you couldn't be generous with the exposure — UV is hard on the gate oxide, so every EPROM had a finite number of erase cycles in it before it stopped holding a program reliably.

Salem loves the legacy, but we're not stuck in it. We enjoy reminiscing about the past, and we enjoy helping our customers preserve their mission-critical systems through every stage of modernization.

See how: https://www.salemautomation.com/resources/case-studies/

09/01/2026

Delivered in partnership with , vtSparc is here:
https://www.salemautomation.com/vtsparc-emulator/
— full-system emulation that moves your Solaris environment off aging Sun hardware and onto modern infrastructure, with the applications, data, and operator screens untouched.

What you gain isn't just survival. Modern hardware platform gives you the peace of mind for the software investments you have made in the past. The infrastructure around your application finally becomes defensible, proper network segmentation, real disaster recovery, a host you can actually patch.

08/27/2026

Part of Salem Automation's treasure trove of old artifacts: a Data I/O 280 Set Programmer.

For most of our history, the meat and potatoes has been the computer room — VAX, Alpha, OpenVMS, and the work of virtualizing those mission-critical systems onto hardware that isn't dying. But our engineers have never had the luxury of stopping at the machine room door. You can't support a system you only understand from one end.

This is what the other end looked like. An engineer built the code on a VAX, sent the image down a serial line to this box, and burned it into a set of EPROMs. Then someone carried those chips out to the floor and installed them in the unit that actually moved product.

Today that same change is a download. Less cumbersome, and that's exactly the point — the plumbing got easier, but the requirement didn't. You still have to know what happens downstream of the computer, or you're guessing.

Thirty-plus years later, we still do. Legacy and modern.

08/19/2026

Right this way to K15 at TechNet Augusta!

08/13/2026

If your team is working through OT security right now, four near-term moves tend to pay off first:

1. Inventory what you actually run — down to the OS versions and the hardware underneath.

2. Find your single points of failure. Every system with no viable spare, no vendor support, and no one left who knows it. That list is both your cyber-risk list and your supply-chain-risk list.

3. Segment before you replace. Even on legacy platforms, isolating OT from IT and controlling remote access buys real protection while you plan.

4. Treat "unsupportable" as the priority, not the excuse. The systems you're most afraid to touch are usually the ones putting you most at risk.

Start where the risk is highest, not where the work is easiest.

08/12/2026

Under pressure, the instinct is to reach for rip-and-replace. For most manufacturers, that's neither affordable nor safe — you don't casually swap out the system running a live process.

There's a more practical path: make the legacy environment supportable again.

Move a workload off failing, unobtainable hardware and onto a maintainable modern host through emulation, and the application still does exactly what it did — but now you're on a platform you can patch, segment, back up, and monitor. The spare-parts gamble is gone. And you've bought time to plan a real migration on your terms, not after an outage.

That's the foundation we help build: keeping critical systems running, getting them off unsupportable hardware, sustaining the applications and databases that carry decades of business logic, and modernizing SCADA and HMI layers — often in Shadow Mode, so the current system keeps running while the new one proves itself.

Keep operating. Keep modernizing. In OT security, those aren't competing priorities. They're the same one.

08/11/2026

For aging control systems, cybersecurity and supply-chain resilience are the same problem wearing two hats.

The software side is what most people think of first — dependencies, third-party components, the regulators now want to see.

But for legacy environments, the more urgent supply-chain risk is physical.

When your process depends on original VAX or Alpha hardware, your continuity plan is a gray-market parts search and a prayer. One failed board can idle a line for weeks.

And that fragility is a security problem in its own right: a system you're afraid to touch is a system you'll never harden. A system with no spare is a system that pushes operators toward risky workarounds the moment something breaks.

Resilience and security aren't two projects. They're one.

08/10/2026

08/06/2026

Here's what makes securing a control system genuinely hard, and different from securing IT:

Often, you can't apply the fix.

A modern IT vulnerability gets patched on the next maintenance window. But a control system running on an unsupported OS — or on hardware the original vendor stopped making twenty years ago — has no next patch coming. There's no update to install. You can't take a continuous process down for a rebuild. And the people who knew the system best may have already retired.

Segmentation, monitoring, and access control all matter. But bolting controls onto a platform you can no longer support, patch, or reliably replace is building on sand.

You cannot secure what you cannot sustain.