Hello everyone,

I work in the field of electrical substation automation.

Situation
Our Efacec UC 500E has failed (hardware defect). We do not have a spare unit and we would like to replace it with a standard desktop PC to maintain service continuity.

What we have

• A full system image (Windows 10) of the old UC 500E, backed up with Acronis True Image.
• All configuration files for the UC 500 software (.cfg, .conf, database, etc.).
• A standard desktop PC available for the replacement.

Our questions

1. Has anyone replaced a UC 500E with a standard desktop PC before? Is it feasible?
2. What are the minimum hardware requirements (serial ports, interface cards, etc.) for the UC 500 software to work properly on a standard PC?
3. Are there any specific steps to follow when migrating the system from a UC 500E to a desktop PC (drivers, network configuration, services, etc.)?
4. What are the common pitfalls to avoid during this type of replacement?
5. Is there any documentation or guide available for this kind of migration?

Any experience or advice would be greatly appreciated. Thank you in advance.

 

Short answer: it is feasible in the narrow sense — what defines a UC 500 is the software, not the enclosure. But "a standard desktop PC" is usually the wrong target, and the things that actually decide this project are not in your list of questions. Two of them can kill the migration before the first driver is installed.

First, test it in a VM today — before you buy anything

You already have the Acronis image and the configuration files. Restore the image into a virtual machine and see what happens. That costs one afternoon and answers your question 1 definitively:

- Does the Automation Studio runtime start?
- Does it complain about a missing licence, dongle, or hardware ID?
- Do the communication drivers bind, or do they fail looking for COM ports the VM cannot present?

If the software refuses to run because of a node-locked licence or a dongle keyed to the old hardware, the plan stops there — and you learned it for the price of an afternoon instead of after buying a PC, a chassis and a DC/DC converter.

The four things that actually decide it

1. Licence and dongle binding. This is the most common killer and the hardest to see in advance. Legacy station-server software is often locked to a MAC address, a disk serial, a USB dongle, or a soft-licence file tied to the machine. An image restore onto dissimilar hardware can invalidate all of it. Establish this before anything else, and get it in writing from whoever still supports the product.

2. Serial port identity. A substation station server talks to protection relays and RTUs over RS-232 / RS-485, often several ports, and the configuration frequently references them by fixed name — COM1, COM3, COM7. A desktop with a USB-to-serial adapter will enumerate differently between reboots depending on which socket it was plugged into. If you go down this road, use a multi-port PCIe serial card with fixed resources and pin the port numbers by device path rather than by enumeration order.

3. Time and determinism. A station server carries event timestamps and drives the master link (typically IEC 60870-5-101/104 or DNP3) with timeout-based state machines. That demands an accurate time source on the same interface you use today — IRIG-B, GPS, or NTP on a dedicated NIC — and a host that never enters power-saving states, throttles its CPU, or loses the link because a background task grabbed the network. A consumer desktop's defaults are actively hostile to this: you will be disabling C-states, disk spin-down and every "optimisation" the OS ships with.

4. Power, thermal and watchdog. The hardware you are replacing almost certainly ran from a substation DC supply (48 / 110 / 220 Vdc) off a battery and charger, in a cabinet, 24/7, with a hardware watchdog and no fan. A desktop assumes 230 Vac from a wall socket, expects airflow, and has no watchdog — if the software hangs, nothing restarts it. If you insist on a PC, make it an industrial IPC with a wide-range DC input, a fanless enclosure and a watchdog, and set the BIOS to power on after power loss. That is no longer "a standard desktop PC"; it is a purpose-built replacement, and the price gap belongs in the decision.

The question you did not ask, and should

Before spending engineering time resurrecting a dead platform, write a one-page interface inventory of what the UC 500E actually does:

- Which devices does it talk to, over which physical port, with which protocol?
- Which of those links are serial and which are Ethernet?
- Where do the event timestamps go, and what accuracy do they need?
- Is it a master, a slave, or a protocol converter between the two?
- Is anything behind it safety-related or revenue-metering related?

With that on paper, the choice between "restore the software on new hardware" and "migrate the function to a currently supported RTU or station gateway" becomes a costed engineering decision instead of an emergency. In most substations I would expect the second to win, for three reasons: the vendor platform is end-of-life and spares get harder every year; a functional migration is bounded and can be tested in a lab before cutover; and you end up with something a utility can maintain and audit for the next fifteen years.

Two constraints specific to a substation that are easy to forget

Compliance. A white-box PC running an unsupported operating system in a substation is an audit finding in most utilities — network access control, patch management and anti-malware policy all assume the vendor supports the platform. Check what your asset owner and your cyber-security policy require before you commit, not after. Windows 10 being out of support makes that sharper, not softer.

Single point of failure. If the UC 500E failing stopped service once, the replacement should not be another single box with no spare and no documented restore procedure. Whatever you install, write the restore procedure down and test it — the next failure should be a two-hour job, not a project.

On your question about documentation

Do not expect a vendor guide for this. What you are describing is a method, not a product, and it is documented in the field rather than on paper: inventory the interfaces, virtualise the image to prove the licensing, choose industrial hardware if you proceed, and keep a cold spare image plus the interface inventory in the substation document set.

If you post the interface list — ports, protocols, and what sits at the other end of each link — I will be glad to comment on which parts of the migration are routine and which are the ones that usually bite.

 

Short answer: it is feasible in the narrow sense — what defines a UC 500 is the software, not the enclosure. But "a standard desktop PC" is usually the wrong target, and the things that actually decide this project are not in your list of questions. Two of them can kill the migration before the first driver is installed.

First, test it in a VM today — before you buy anything

You already have the Acronis image and the configuration files. Restore the image into a virtual machine and see what happens. That costs one afternoon and answers your question 1 definitively:

- Does the Automation Studio runtime start?
- Does it complain about a missing licence, dongle, or hardware ID?
- Do the communication drivers bind, or do they fail looking for COM ports the VM cannot present?

If the software refuses to run because of a node-locked licence or a dongle keyed to the old hardware, the plan stops there — and you learned it for the price of an afternoon instead of after buying a PC, a chassis and a DC/DC converter.

The four things that actually decide it

1. Licence and dongle binding. This is the most common killer and the hardest to see in advance. Legacy station-server software is often locked to a MAC address, a disk serial, a USB dongle, or a soft-licence file tied to the machine. An image restore onto dissimilar hardware can invalidate all of it. Establish this before anything else, and get it in writing from whoever still supports the product.

2. Serial port identity. A substation station server talks to protection relays and RTUs over RS-232 / RS-485, often several ports, and the configuration frequently references them by fixed name — COM1, COM3, COM7. A desktop with a USB-to-serial adapter will enumerate differently between reboots depending on which socket it was plugged into. If you go down this road, use a multi-port PCIe serial card with fixed resources and pin the port numbers by device path rather than by enumeration order.

3. Time and determinism. A station server carries event timestamps and drives the master link (typically IEC 60870-5-101/104 or DNP3) with timeout-based state machines. That demands an accurate time source on the same interface you use today — IRIG-B, GPS, or NTP on a dedicated NIC — and a host that never enters power-saving states, throttles its CPU, or loses the link because a background task grabbed the network. A consumer desktop's defaults are actively hostile to this: you will be disabling C-states, disk spin-down and every "optimisation" the OS ships with.

4. Power, thermal and watchdog. The hardware you are replacing almost certainly ran from a substation DC supply (48 / 110 / 220 Vdc) off a battery and charger, in a cabinet, 24/7, with a hardware watchdog and no fan. A desktop assumes 230 Vac from a wall socket, expects airflow, and has no watchdog — if the software hangs, nothing restarts it. If you insist on a PC, make it an industrial IPC with a wide-range DC input, a fanless enclosure and a watchdog, and set the BIOS to power on after power loss. That is no longer "a standard desktop PC"; it is a purpose-built replacement, and the price gap belongs in the decision.

The question you did not ask, and should

Before spending engineering time resurrecting a dead platform, write a one-page interface inventory of what the UC 500E actually does:

- Which devices does it talk to, over which physical port, with which protocol?
- Which of those links are serial and which are Ethernet?
- Where do the event timestamps go, and what accuracy do they need?
- Is it a master, a slave, or a protocol converter between the two?
- Is anything behind it safety-related or revenue-metering related?

With that on paper, the choice between "restore the software on new hardware" and "migrate the function to a currently supported RTU or station gateway" becomes a costed engineering decision instead of an emergency. In most substations I would expect the second to win, for three reasons: the vendor platform is end-of-life and spares get harder every year; a functional migration is bounded and can be tested in a lab before cutover; and you end up with something a utility can maintain and audit for the next fifteen years.

Two constraints specific to a substation that are easy to forget

Compliance. A white-box PC running an unsupported operating system in a substation is an audit finding in most utilities — network access control, patch management and anti-malware policy all assume the vendor supports the platform. Check what your asset owner and your cyber-security policy require before you commit, not after. Windows 10 being out of support makes that sharper, not softer.

Single point of failure. If the UC 500E failing stopped service once, the replacement should not be another single box with no spare and no documented restore procedure. Whatever you install, write the restore procedure down and test it — the next failure should be a two-hour job, not a project.

On your question about documentation

Do not expect a vendor guide for this. What you are describing is a method, not a product, and it is documented in the field rather than on paper: inventory the interfaces, virtualise the image to prove the licensing, choose industrial hardware if you proceed, and keep a cold spare image plus the interface inventory in the substation document set.

If you post the interface list — ports, protocols, and what sits at the other end of each link — I will be glad to comment on which parts of the migration are routine and which are the ones that usually bite.

I installed the image and it ran for about a minute, then I received a message stating that the license is invalid. This computer is used for command‑type tasks such as remote desktop, not for SCADA.


Possible solutions for the “invalid‑license” situation

 

That "invalid licence" after about a minute is typical of a licence bound to the original hardware (hardware ID, MAC address, disk serial, or a dongle). The VM test did its job: it shows the image can't simply move to new hardware as-is.

The clean way forward:

1. Contact Efacec, or the integrator who supplied the system, and ask for a licence transfer (re-host) to new hardware. Vendors usually handle this for failed hardware if you can show the original licence or serial number and the defect. Ask at the same time whether the software version you run is supported on the replacement platform you have in mind.
2. Check whether the old unit had a USB dongle or a licence file. If there was a dongle, moving the dongle may be all that is needed.
3. While you wait, document the interface inventory aiepco described. If re-hosting turns out to be impossible or expensive, that list is what you need to price a migration to a currently supported gateway.

I would avoid trying to spoof the hardware ID or patch the licence check on a substation asset. Apart from breaking the licence terms, you end up with a system nobody can support or patch, which tends to become an audit finding later.