Mica Controls can help customers transition from the "Stone Age" to the "Jet Age" of SCADA (Supervisory Control and Data Acquisition)


We can help you take the steps you need to move forward.

The result is better control of assets and a heightened reduction in cost: Not only in procuring, installing, and maintaining equipment, but also in a reduction of labor costs, with less people required in the field for day to day operations.

What We Work with Now

Today we have several companies manufacturing a miniature device that snaps onto a din rail and does everything a multi-million-dollar system could do 30 years ago, for under $600.  This is a part of the IoT revolution. This new class of IoT device is the controller, HMI, HOST, data logger, call out system, FTP client and servicer, digital camera, webserver, and with a cell modem built onto it. You can remotely manage and deploy that system, and your high-tech staff can be where they want to be in the world without the need of locally babysitting this automation equipment. All you need in the remote area is someone to physically install the device and wire it to the sensors and final elements.

ScadaFlexBanner (2)
Nexto-express_top (2)

History of Industrial SCADA


The Beginning


The Industrial SCADA market began by using dedicated computers that were made for telemetry applications. In the stone age of SCADA, back in 1991, it was implemented by distributing Unix computers along pipelines and facilities which were interfaced to PLCs, flow computers, and analytical equipment.  Back then a SCADA project was a multi-million-dollar project, which took over a year to implement and used very expensive devices, and specialized people.  Only the most critical projects could take advantage of SCADA due to the high cost. In order to make remote changes go live a person had to be sent out to each station of the SCADA system to restart computers. This made it costly to make changes.

Adoption of PCs by the Industry

It was now possible to control your equipment using software independent of the computer you were using. Software was used as the graphical interface to the people who controlled the process. A desktop computer would run the software that communicated to the PLCs, data was then displayed on 24-inch CRT monitors. When PCs were first introduced into SCADA, back in the 386 DX days, a PC could only run one software package; no multitasking. In a large project you would need to have several servers that would send data between PLC’s and workstations. It was a lot of work to integrate, and it would take plenty of engineering hours. But you could do things remotely instead of having someone walk into each site and manually turn each valve. A nightmare in reference to how we work today, but a huge step forward from what it had been 30 years ago.

The Internet

Dial up modems brought along the remote access craze. Now we had access to controls systems by dialing into them, and no longer needed to go to site to resolve most issues. As part of the IoT revolution, manufacturing companies are making miniature devices that simply snap onto a din rail. This devices can do everything a multi-million-dollar system could do 30 years ago, but for $600. This new class of IoT device leverages the internet via ISP or cellular link.




After the internet expanded into email, In the mid to late 1990’s, SCADApack released a miniature programmable logic solver with embedded I/O.  This is an example of an Remote Telemetry Unit or RTU. It was a shoe box sized and din rail mounted and, at the time, was a miracle. 


This one device could be put in a small cabinet in the field, and we could add controls to very small projects. It allowed us to automate things as small as an oil and gas well site, and a wastewater lift station. This class of equipment still required a lot of talent to get working, we had to integrate a radio system, call out systems, data loggers, HMIs, and create the application software for the controllers, and connect it to a host system and configure the host system for remote monitoring. It took a lot of skilled people to put this all together.

Foundation Fieldbus


In the early 2000’s Computer technology became miniaturized to the point where we could install a process controller in a sensor and a valve. A method was developed by a group of contributing manufacturers, where you could implement a control system by only using sensors and valves connected on a network. The processor was no longer in a centralized computer module, it was instead distributed within the sensor and the valves of the process control system. This was originally marketed as a solution to lower wiring costs. We worked on a project that leveraged Foundation Fieldbus, to enable a global company to be able to monitor and control their complete gas field network in North America from anywhere in the world. This required the deployment of high-power spread spectrum radios to connect these Foundation Fieldbus distributed control systems to a global host system. If a valve started to fail, the diagnostic system would be able to detect the failure and could trigger an alarm.


Anyone in the world, with access to the host, would be able to check out the valve diagnostic, diagnose the problem, without having to travel to the field. This helped with preventative maintenance, the company could plan all the travel needed to manage a large number of facilities with a small number of people.

We deployed this technology in 5 fields, tested it on compressors, and did an entire field development in Canada with well sites, compressors, and gas processing plants. We had a lot of fun making the most out foundation field bus, remote PTZ cameras, SCADA host software, and Foundation fieldbus host systems, and radios. We soon realized It was the wrong implementation of this technology because the systems were so overly complicated that replacing a simple failed transmitter became the job of a highly trained individual. When the control functions of the control system are distributed in different instruments, the replacement of a single instrument requires recommissioning the impacted control functions – not fun.  A better plan would have been to centralize the control in the controller, the H1 Host and use foundation fieldbus only for end device interface and for diagnostics. Putting control in the field bus devices adding complexity and this proved to be a problem, as the most highly trained individuals did not live in the remote locations where these sites would be.


Yokogawa FCJ  provides the reliability for the SCADA communication with network redundant capability.


Now we have a solution where ONE product (Scadaflex II, or Nexto Xpress) contain all of the system resources. The devices serve up the user and engineering interface via a web browser. Communications are via secure VPN over a cell modem. Multiple users can access the system via secure VPN over the internet.

Technology is constantly evolving and we can’t predict what will be the next improvement in remote work, but somehow, we think it will involve drones!