and Data Acquisition (SCADA) System
![]() |
![]() |
SCADAware Splash Screen | Hand crafted graphic display and operator menu |
SCADAware Background
Arthur Zatarain began working with microcomputers in the mid 1970's, including applications for Supervisory Control and Data Acquisition. SCADA, usually pronounced as "Skay-Dah," refers to equipment and systems for industrial remote monitoring and control. The handsome fellow below is Arthur with his first Z-80 "Dataran" microcomputer, circa 1978. His pocket protector will one day be displayed in the SCADAware museum.
![]() |
![]() |
Arthur with a Dataran Z-80
computer running Zatmon in 1978 |
In the field
with SCADA offshore April 1990 |
Arthur's early SCADA work used products by Hewlett Packard, Motorola, Systronics, and Hydril. His experience with that rapidly-aging technology prompted development of his first microprocessor-based SCADA system when he formed Dataran Engineering in 1980. His custom-built RTUs, based on Zilog Z-80 and Motorola 6800 micros, found homes in offshore platforms, remote meter and compressor stations, and industrial SCADA applications.
Users remotely accessed those early units with old school CRT terminals as well as S100 computers running the CP/M operating system and programs similar to Procom Terminal Emulator. Later SCADA projects at Dataran used specially prepared human interface software written by Arthur in PL/M and assembly language for the S100 computers. Some of those systems leveraged the realtime TurboDOS multi-user, multiprocessor operating system instead of the single-user CP/M.
![]() |
![]() |
Dataran Z-80
based RTU circa 1981 |
Analog Devices
RTU in offshore installation c 1986 |
While still at Dataran, Arthur developed a field-programmable SCADA system based on an Analog Devices data logger configured as a remote terminal unit (RTU). The RTU was connected to the monitoring computers via phone and radio links into human interface software written by Arthur in Turbo Pascal. The "AdLink" program ran on a standard IBM-compatible PC rather than the purpose-built S100 computers in Arthur's earlier systems. Although successful in the field, that RTU's limited programmability contrasted sharply with the unlimited potential of the PC back in the office. The path forward became clear: the PC had to go out where it was hot, wet, and dirty.
![]() |
![]() |
High performance PCs noted
in Citybusiness Nov 1986 |
Dataran computer in Omnitron
Remote Afterloader c 1988 |
One of Dataran's clients for the AdLink system was Total Engineering Services Team (TEST). Founded in 1970 by Dick Piner, TEST was a major player and innovator in oilfield control systems. Dataran's work with TEST went so well that Mr. Piner wanted SCADA to be an integral part of TEST's business. The deal was done on Jan 1, 1988 when Arthur and his crew moved into TEST's main office in New Orleans. (Note: Arthur and his brother Dave remained with TEST for another 20 years).
Arthur's experience with building high performance "clone" computers under the Naratad brand name encouraged him to develop an RTU based on industrial strength PC compatible computers. This effort resulted in the SCADAware® product line (then known as TEST SCADA). The hardened computer technology was also used in the patented Omnitron Remote Afterloader nuclear medical device.
![]() |
![]() |
|
Type 1000 "Smart RTU" based on Metrabyte I/O System |
Type 1200 "Smart RTU" based on generic I/O system |
The first TEST Type 1000 RTUs were fabricated in 1988 by Paul Napolitano and Don Caskey for remote onshore and offshore applications. A significant application was the "Hurricane Timer" feature. A reliable SCADA system allowed remote offshore production platforms to continue operating without local supervision when a pending hurricane required early evacuation of onboard personnel. The TEST SCADAware system would continue to monitor onboard operations and communicate status to onshore facilities. Production could continue offshore without interruption if the hurricane failed to cause a threat. If the hurricane did approach then the platform could be shut-in remotely via the SCADAware system. Also, if communications with the onshore computer failed then the SCADAware system would automatically shut-in the offshore production. A few hours of unattended platform operation was typically enough to justify installation of the entire SCADAware system.
Several hundred SCADAware units were eventually fabricated by TEST and installed worldwide between 1988 and the early 2000's. Additional smart RTUs were also fabricated by end users who licensed SCADAware and fabricated systems on their own.
![]() |
![]() |
|
One of the first Smart RTUs in the US Gulf of Mexico - 1988 |
A lineup of Type 1200 RTUs in final testing - 1996 |
As standard PLC and RTU devices became smaller-faster-cheaper, the purpose-built SCADAware RTU designs became less desirable for new projects. Similarly, host computers operating Microsoft Windows made SCADAware's DOS-based software somewhat obsolete. Regardless, TEST's RTUs remained in operation for many years either as originally installed, or via SCADAware's open architecture interface to interact with Windows and other operating systems. Despite its vintage technology, a system of Type 1200 RTUs, along with a SCADAware host PC, was spotted in operation as late as 2014, still "ticking away" on platforms in the Gulf of Mexico.
TEST SCADA Brochure 1989 (click to view entire document)
SCADAware Documentation Online
Arthur Zatarain wrote and managed all of the SCADAware documentation. It was originally developed in WordStar, then the similar NewWord word processor. The entire software package transitioned to WordPerfect, and later to MS Word. The documents were very popular with existing and potential customers, prompting TEST to begin charging for each copy. PDF versions of some documentation for TEST SCADA (its initial name) and SCADAware (its later name) are listed in the table at the end of this web page, click the image below to jump there.
TEST SCADA Document Price List 1996 (click to view document list)
SCADAware PC-Based "Smart RTU" Development
All of the SCADAware "Smart RTU" and Host platforms were based on PC compatible computers. The early Type 1000 RTUs used single board computers manufactured by Ampro connected to MetraByte input/output components. The computer's form factor matched that of a 5-1/4" floppy disc drive allowing the board to be mounted directly to the drive. However, the floppy disc was only used for programming of an early solid state disc cartridge that held a whopping 256K of memory. That limited disc space was used for DOS, the SCADAware program, and data storage.
![]() |
![]() | |
TEST Type 1200 "Smart RTU" with local programming unit |
Type 1200 Demo Unit
sold a lot of SCADA systems |
Later Type 1200 RTUs used single board AT (286 and 386) compatible slot computers installed in a four or six slot card cage. This design provided flexibility to select processor, communications, and I/O boards for each installation. The most common I/O system was based on the industry standard CIO-AD08 I/O interface I/O interface wired to compact analog and digital termination boards designed by Arthur Zatarain and Stan Taravella. This "generic I/O" was economical and reliable, and was used in the majority of SCADAware installations worldwide. Several industry standard I/O modules were also developed including an Opto-22 compatible pulse stretcher for high speed data capture.
![]() |
![]() |
|
SCADAware system checkout before heading to the field |
SCADAware circuit boards designed by Arthur Zatarain |
SCADAware Small "Dumb RTU" Systems
The Type 24, Type 2000, and Type 2200 SCADA Node were "dumb" RTU devices developed to meet customer demand for lower cost, low power, limited capability RTUs. The smaller units were based on Intel MSC-51 / 8052 microcontroller technology from single-board computer maker MicroMint, with embedded firmware written in Assembly and Basic. These RTUs linked with a SCADAware smart RTU or Host for monitoring and control. The Type 24 RTU could be operated with touch tones sent via radio or phone.
![]() |
![]() |
|
Type 2000 "Dumb" RTU MicroMint "Brute" CPU |
Type 2200 "SCADA Node" Demo Unit |
Development of the dumb RTUs required in-house board-level hardware and software design to produce low cost, energy efficient telemetry devices. These small RTU's could operate at low power levels to accommodate "call on exception" and "quiescent" operation. Call on exception conserved power by powering the radio only when an input changed to specified values. The quiescent mode allowed the RTU, I/O, and radio transmitter to be powered off until the host system contacted the RTU for an update, or to control an RTU output. Like most SCADAware RTUs, these units often operated from battery or solar power systems specifically designed for each installation location.
![]() |
![]() |
|
Type 2200 "SCADA Node" low power RTU |
Type 2200 "SCADA on a stick" self-contained solution |
The Type 2200 was also "bi-lingual" because it could talk the industry-standard Modbus protocol as well as TEST SCADA Protocol (TSP). This flexibility allowed the small units to be tied into existing Modbus-based SCADA networks without requiring a SCADAware station to serve as an open architecture interface.
Type 100 Voice RTU and Auto-dialer
A pioneering voice RTU was also part of the SCADAware product line. The Type 100 RTU (originally named LB-100) evolved from the Seekirk A1800 and A2000 telephone auto-dialers designed and programmed by Arthur Zatarain in the mid 1980's while still at Dataran Engineering.
The Type 100 was a Z-80 (Hitachi HD64180) single board microcomputer that responded to digital inputs sent via phone or radio. The human voice alarms and messages, using ADPCM Technology, could be locally announced as well as delivered remotely. The unit also provided control of digital outputs using DTMF "touch tone" codes from any audio source.
![]() |
![]() |
|
Type 100 "Voice RTU" based on Seekirk units |
Portable Touch Tone Pad |
The Type 100 often functioned as a stand alone auto-dialer to detect alarms and alert one or more operators with a voice phone call. Alarms from the unit required acknowledgment via alphanumeric touch tones from the operator. The tone codes for over 30 commands were generated with a standard phone keypad or a small hand-held keypad (i.e. "ACK" = buttons 225). Command codes could also be sent by another Type 100 RTU. The unit provided local or remote operation of its 8 onboard outputs to control equipment at the remote site. The Type 100 could even be networked with other Type 100 units over phone or radio using DTMF touch tones.
Another useful feature of the Type 100 was direct connection to any SCADAware RTU or Host unit. The multiplexed I/O interface, done via the standard PC parallel port, integrated the Type 100 into the SCADAware RTU or Host as virtual digital inputs and outputs. This interface allowed telephone-based remote reaction to, and remote control of, the related I/O and other parameters within the connected SCADAware unit as well as that of any other Host or RTU in the entire system.
Modem Monitor Watchdog Timer
Most SCADAware systems were fitted with a watchdog timer device named the Modem Monitor. This stand-alone activity monitor, designed by Arthur Zatarain in 1989 and manufactured by TEST, tracked local system operations to detect hardware or software problems. Its primary function was to automatically reset the system if the monitored signals failed for a period of time. The Modem Monitor also performed other security functions such as tracking incoming ring counts and providing a remote reset feature via simple "break" signal over the communications line.
![]() |
![]() |
|
Modem Monitor Faceplate |
Modem monitor with 3-1/2" floppy disc drive |
Interestingly, a very similar device was patented in 1995 by George Lazik (see US 5,430,865) for a "hardware remote reset circuit" with features similar to those of the modem monitor.
SCADAware Data Points (Channels)
The data representing I/O points and calculation results in SCADAware were defined as groups of "channels" assigned to separate real and virtual RTUs. A channel was much more than simply a data value; a channel was an object-oriented collection of data, parameters, and functions all related to a single digital (off-on) or analog (numeric) value. A channel provided a multi-purpose data point that could be used by any processor in the system without regard to how or where the channel was created.
Each SCADAware data channel had a long descriptive name and other settings such as call-on-alarm, alarm delay, execute a procedure file, etc. Each channel also had an unambiguous "tag name" based on the combination of the RTU name and the Tag name within that RTU. For example, the tag name "EI258.PumpOn" would uniquely identify a single value related to the off-on condition of a pump connected to an RTU at station EI258. Any automated process, calculation, menu hit, user program, or human operator could reference that tag name without knowing any of the data point's physical (or virtual) characteristics, or its physical location among the connected systems. Any channel could also be accessed by only its tag name (i.e. PumpOn) if the operator (or application program) had preselected a "current RTU" that became the default for all ambiguous tag references.
![]() |
![]() |
|
Data Channel Attributes | Data Channel Types |
A remote SCADAware RTU may have configured only a single RTU to hold its own channels. Alternately, that RTU could also designate channels for other RTUs to which it was logically linked. A Host system would typically have channels for several remote RTUs as well as real and virtual channels for use on the Host system itself. All internal values, regardless of data protocol and format such as TSP, Modbus, Allen Bradley, ASCII, etc., were converted to IEEE floating point and integers in SCADAware's tables and data bases. Likewise, internal data was converted to another type where required for transmission to a system using a different format.
Specific channel types were derived from the generic channel to add aspects particular to each type. For example, an off-on input "Status" channel type could be set to alarm when an input opened, or when it closed. Any use of the channel would report a 1 (true) if the Status point was "active" without concern for the normally open or normally closed physical switch.
Likewise, any value-type channel (such as analog) could be set to alarm when a value went above or below a specific setpoint for a designated amount of time. Numeric settings (i.e. setpoints) for any value-type channel were defined in engineering units, such as PSI or deg-F rather than as binary numbers representing percentages of full scale. A floating point deadband setting in engineering units was also included for all value-type channels.
Complex numeric channel types included AGA3 gas flow computer, pulse counters, rate totalizers, and PID output control. A custom function channel could be programmed by the user to periodically perform any math or procedural function under a variety of automatic and event-driven conditions. All of those complex channel types were easily accessible within SCADAware in the same manner as the more basic digital and analog I/O types.
SCADAware User Programs & Communications
SCADAware applications were programmed and operated with a plain text-based data communications system called Test SCADA Protocol (TSP). This system was used for all commands and data sent between units, or stored in files, or manually typed by an operator (see sample library here). Although plain text TSP required more bytes than an encoded method, the simplicity and transparency allowed any person or computer to evaluate and understand the information with very little information about how and where the data was created. The commands to perform frequent functions were stored in procedures that could be activated by a wide variety of automatic and manual operations.
Automatic operations included response to alarm conditions, time of day, callout schedules, calculation results, and time delays. Manual operations included text and graphic menus that allowed operators at either a Host or RTU station to monitor and control any directly connected or remote data points, system variables, and communication parameters.
![]() |
![]() |
|
User programmable Host menu to operate distant RTU |
User-programmable Host graphic to operate distant wellhead RTU |
The easily configured menus allowed monitoring and operation of local and remote equipment by minimally trained operators. A button press or mouse click would initiate a preprogrammed sequence to perform a specific action, such as the typical RTU download procedure shown below.
Typical TSP download procedure on an RTU
Procedures written for one comm media could be used on other links without modification. Transport of TSP commands over radio, phone, network, or direct connection was transparent to the underlying SCADA application programs. Command and data exchanges between an RTU and Host used the same process in either direction. A unique aspect was that all smart RTU and Host units could have similar command processing and alarming capability. This allowed SCADAware "RTU/Host" stations to perform both roles at the same time.
The example procedure shown below allowed a unit serving as a Host to remotely update parameters on an RTU. Typical examples include remote adjustment of alarm setpoints, output controls, time delays, callout settings, and gas meter parameters at a Host or smart RTU.
TSP procedure on a Host to revise parameters on an RTU
SCADAware's built-in automation features, coupled with user-generated programs and configuration settings, produced systems having aspects of both event-driven and procedural programing. This was uncommon for a DOS-based realtime industrial monitoring and control system in the 1990's. Complete systems ranged from single RTU-to-Host unit connections on up to regional systems combining 30 RTUs, one or more Host PC stations, networked SCADA servers, digital pagers, fax machines, and remote-dial in computers.
For manual operation, TSP commands and data could be entered by hand in what was called "Terminal mode." This feature provided the operator with simple control over configuration and actions of the system. Because the interface was based on standard ANSI ASCII terminal codes, commands could be entered locally via the PC's keyboard and display, or remotely using a simple data terminal or PC emulating a terminal. Automated access to many commands and functions was also provided at the local unit via menus and interfaces based on the PC's normal display, keyboard, and mouse functions.
Some Smart RTUs were equipped with small 12V CRT displays, and later with LCD displays, for use in rugged environments. Other smart RTU's had hand-held terminals offering 4 lines of LCD display and a membrane keyboard. Remote operation was also possible via screen-capture programs such as pcAnywhere, and network-based serial connections such as Telenet that proved useful for programming and support at international locations.
1994 brochure napkin mockup (click to view entire document)
SCADAware's "terminal mode," either local or remote, presented the human operator with a command prompt similar to that of DOS. But instead of showing "C:>" the interface showed the name of the RTU (in the form of SMI320:>) to which commands were addressed by default; other RTU's could be easily accessed by switching logical connections, or by prefacing point names with that of the desired remote unit (as with WD45.PUMP2_ON).
SCADAware's manual command interface also allowed "shelling out" to DOS for manual operation of the computer while SCADAware was still running. The operator then saw the familiar "C:>" prompt at either the local PC interface, or at the remote interface if dialing into the unit via radio, phone, or network connection. This may sound trivial now, but it was magical back then while operating a distant computer over a 1200 baud radio connection.
TSP computer-to-computer links were similar to the human format, with additional error checking and sequencing codes embedded in the message packets. The automated version of the protocol included a sequential block number for each transmission, and required a specific acknowledgement from the receiving unit. A cyclic redundancy check (CRC) code was calculated for each transmission to let the receiver verify proper reception. Correct reception and processing generated an ACK command by the receiver. In some cases. the ACK message also contained data going back to the original sender who would then ACK to the initial receiver. This efficient method allowed two units to communicate with requests for data, sending of data, and processing of commands with the minimum number of transmissions.
SCADAware brochure 1994 by Leonard Joseph
Another key aspect of SCADAware's TSP protocol was that every transmission contained a unit ID field for "From" and "To," and also a "Timestamp." The timestamp identified the local time that the data was initially generated. An additional timestamp feature was available to mark the time that the data was received by any node. Those times may differ when data was relayed among units, such as from a remote RTU to a field Host and then to an office Host. This sophisticated process allowed unit A to send data to unit B relevant to unit C in a form that meant "This is A talking to B at 11:02:15am. The data was valid on unit C at 9:15:22." Because transmissions were mostly text-based, SCADAware's "watch" feature allowed an operator to visually monitor links among multiple units and see the data going out and coming in.
SCADAware's initial phone communications links were landline and cell telephones based on Hayes modem protocols. Motorola "Cellular Connection" adapters were used to link the cellphone to the appropriate modem. Modification of the cellphone was often made to avoid unwanted roaming that inadvertently switched an RTU phone to a different tower (and carrier), a situation that sometimes hampered connections into and out of a very remotely-located RTU.
Radio communications initially used the X-25 protocol over Packet Radio Controllers (PRC). Standard voice radios were tediously modified by Stan Taravella to allow audio in and out, and also push-to-talk, connected to the PRC. SCADAware could automatically program the PRC to directly connect to another unit, or to use the PRC's data relay feature to indirectly connect to distant locations. Arthur Zatarain and Mitch Wiese delivered a paper on PRC and SCADA at the 1992 Entelec Conference in Dallas, TX
![]() |
![]() |
|
Presentation on Packet Radio for SCADA - 1992 |
SCADAware's multi-drop mode - 1993 |
Although the PRC proved to be a workhorse in the field, its relatively slow throughput prompted the addition of a multi-drop communications mode for both direct wire and modem applications. The computer managed the push-to-talk control via an RS-232 output, and provided key-up and key-down delays to suit each radio installation. Further, the use of simple radios gave way to more sophisticated spread spectrum and other digital radio technologies that provided reliable 9600 baud links without need to "hack" the radio's mic, speaker, and PTT connections.
Computer network connections were available for systems operating under both DOS and Windows. A logical connection scheme provided virtual direct connections among multiple RTU and Host units that shared a common network. The update process was very fast and efficient, and allowed multiple computers to share and view RTU data over a network in realtime.
SCADAware maintained a callout list of addresses to be contacted for a matrix of alert or routine reporting situations. The addresses could be phone numbers (modems, pagers, and fax), or radio call signs (packet systems), or RTU IDs (networks, multidrop radio, and direct wired). This flexible and reprogrammable combination of address lists and alert matrix allowed a single unit to call multiple other units under a variety of individually controlled circumstances. The individual callout capability proved very useful for shared installations where different alarm conditions required responses from different entities.
A unique "eavesdrop" feature allowed a SCADAware station to monitor transmissions between other units without being involved in the data acknowledgement process. This allowed a monitoring computer to watch interactions among other units while preserving the ACK security among the primary units in the data conversation.
SCADAware also provided a broadcast feature for delivering simultaneous realtime data updates to multiple receivers. This technique increased the update speed over networked and shared audio connections. The tradeoff was that the sending unit did not receive an acknowledgement for each transmission.
Complete file transfer between SCADAware stations was also done with a simple SEND command. This utility allowed files configurations, procedure libraries, and RTU setup parameters to be downloaded from one station to another over any TSP communications link. This feature allowed for routine adjustment to station operation as well as complete station reconfiguration without having to visit the remote or host location.
SCADAware Open Architecture and PLC/DCS Interfaces
Although SCADAware was based on its own TSP protocol, it also provided Open Architecture links into several other industry protocols. The primary interface was the industry-standard Modbus protocol. SCADAware supported both the RTU and Host variants of Modbus, and also supported the diverse non-standard floating point modes used by Modicon, Daniels, Rosemont, Bailey, Saab, and Fischer Porter. Further, SCADAware also provided interfaces for several proprietary PLC protocols such as Allen Bradley, Square-D, and Texas Instruments.
![]() |
![]() |
|
System combining phone, radio, modbus, and network in 1994 |
SCADAware Modbus link with Wonderware in 1994 |
The availability of Modbus and other PLC & DCS protocols allowed SCADAware systems to link with a variety of platforms. SCADAware software even supported simultaneous communications with multiple protocols on the same data link, allowing TSP, Modbus, and other protocols to share a common connection among all the units.
The open interfaces also allowed SCADAware integration with Windows-based software systems such as RS View, Wonderware, and other industry-standard Human Machine Interface (HMI) programs from the mid 1990's well into the 21st century.
SCADAware Software Development
The initial 1988 version of SCADAware was derived from Arthur's earlier AdLink system. Both used the same realtime software core (or "kernel") called "Zatmon" that was developed by Arthur in the 1970's for Digital Group computers. Initially referred to as "TEST SCADA," the SCADAware RTU or Host program ran under the DOS operating system. DOS and SCADAWare were loaded from floppy disc onto solid state discs for Smart RTUs, or onto hard discs for desktop stations. Later systems used a "generic DOS" provided with low power CPU boards, or in a "DOS box" under Windows. Although DOS/Windows managed the computer's file system, the realtime operation of most functions was controlled by a low level DOS and BIOS manager designed and programmed in assembly language. This robust multitasking component linked with DOS to form a realtime operating system capable of unattended reliable operation in remote SCADA applications.
The SCADAware program system was a continuously evolving group of executables and overlays that targeted three distinct environments. All versions were compiled from the same core software. The "Lite" variant was designed to manage realtime processing with the limited resources of a minimal Smart RTU, typically those with the Ampro 8088 CPU. A medium size version added DOS Protected Mode Interface (DPMI) memory to support RTU expansion features such as open architecture, fax reports, and user-defined text displays. The complete "full" version of SCADAware added advanced features such as graphics, database, local and remote voice/audio output, and networking. Although aimed at office environments, the enhanced versions were also used in rugged industrial or offshore environments that needed a combo RTU/Host.
![]() |
![]() |
|
Type 1200 serving as combo Smart RTU and Host |
Office PC serving as SCADAware Host |
SCADAware operation was secured by a hardware "dongle" attached to a parallel port of every smart RTU or Host. Two type of dongles were provided, termed "Host" and "RTU." However, those names do not clearly reflect the features provided by each type. The RTU dongle enabled all SCADAware features. The Host dongle disabled the interfaces to locally connected I/O (i.e. Metrabus, Generic, etc). Therefore, the RTU dongle was installed on any station requiring local I/O, while the Host version was more appropriate for office and portable "laptop" environments that only processed data from remote units.
The primary SCADAware system architect and programmer was Arthur Zatarain, with programming support over several years by Cory Moragas. Corey was also deeply involved with the human interface programming for the patented Omnitron nuclear medical device of which Arthur is an inventor. The nuclear device was controlled by an embedded PC that used many of the core features of SCADAware's realtime DOS operating system and modified PC BIOS.
SCADAware was programmed in assembly language and Pascal using various Turbo / Borland Pascal compilers. The complete SCADAware package incorporated I/O and communications libraries previously developed in Intel assembly language for microprocessor-based projects, and for AdLink. A demo version of SCADAware briefly transitioned to Borland C, but this was prior to introduction of C+ and C++. The C version of SCADAware proved inefficient for actual implementation on the smaller Intel 8088-based RTUs and never got past the proof-of-concept stage.
Sometime around 1990, SCADAware development moved on to object-oriented programming (OOP) based on Borland Pascal. The use of an OOP compiler allowed integration of enormous code libraries written by Arthur Zatarain, TurboPower, Genus, Intel, Hayes, and open-source providers. Advanced SCADA features included fax transmission, net DDE (dynamic data exchange), PC-based voice announcements, and user-programmable graphic displays. These features were available to any SCADAware station (RTU or Host) operating with DOS Protected Mode Interface (DPMI) memory. The Borland Pascal version continued to be developed until Arthur retired from TEST Automation and Controls in 2008. Ongoing customer support continued to be provided by TEST after Arthur's departure.
![]() |
![]() |
|
Realtime graphic
displays were very popular |
SCADAware's database feature was much desired but rarely used |
SCADAware's graphics capability included realtime images, digital and analog displays, database trends, and multicolored indicators. The VGA graphic backgrounds and icons were tediously developed by Nick Niklaus using tools that, by today's standards, were quite primitive. Likewise, many realtime displays were hand-crafted by Mitch Wiese, one pixel at a time, to keep customers happy. Some customers, such as Dubai Petroleum and Trinmar, developed their own graphics using in-house technicians.
A complete compile of SCADAware "lite" represented nearly one million lines of Pascal and assembly language code. The larger "full" version using the DPMI system and many advanced features approached two million lines. The union of all that system and application code had evolved from a simple core system initiated in the 1970's to produce industrial telemetry products that were still operating in the field well into the 2010's.
![]() |
![]() |
|
Built-in text display on small CRT at an RTU |
Custom graphic display and menu for pipeline leak detection |
SCADAware People
Although Arthur Zatarain developed and managed the SCADAware product line, many key players helped design, program, install, and maintain the systems for over two decades. Early supporters were Mike Moity, Phil Rundle, and Dave Volz who pushed hard to get TEST into the rapidly advancing industrial SCADA industry.
![]() |
![]() |
|
Dave Volz scoping out a SCADAware installation |
Phil Rundle hard at work somewhere in the UK |
Don Caskey, below left, was important to the early installations when cell phones and solar power brought radical changes to offshore telemetry systems. Tim Lynn, shown clowning around below right, was widely known as one of the best SCADA technicians in the industry.
![]() |
![]() |
|
Don Caskey with Type 1000 and early cellphone link c1988 |
Tim Lynn - Super SCADA tech (Tim passed away Feb 2012) |
Stan Taravella, below left at the keyboard, was key to designing both the system packaging as well as the custom circuit boards developed by TEST. Corey Moragas (below) joined the team early on and contributed software development and testing for several years. Glen Melancon served as a field technician for SCADA projects in the Gulf of Mexico.
![]() |
![]() |
|
Stan Taravella (left) and Paul Napolitano with Type 1000 |
Corey Moragas and Glen Melancon in the "SCADA Shop" |
Mitch Wiese was the prime SCADAware contact in Houston. He had a major influence in practical aspects of the installed systems, including the popular "SCADA on a stick" concept. That single-point-lift assembly provided an efficient method of installing a solar powered RTU at remote locations using a portable hoist. He also successfully surveyed about 25 very hot Pemex well sites, gathering stations, and processing plants for SCADAware even though he forgot his tape measure at home.
![]() |
![]() |
|
Carlos Morales Gil of Pemex with Arthur in an ancient Bell 205 |
Mitch Wiese
inspecting a Pemex wellhead circa 1993 |
Other SCADAware veterans include David Zatarain (Arthur's smarter brother) who managed many system designs and installations including large projects in China and Trinidad. Dave worked with Trinmar's Richard Small on one the largest SCADAware installations, spread throughout Trinidad's Gulf of Paria. Richard eventually brought his smarts and work ethic to TEST in the States where he managed PLC and remote monitoring projects.
![]() |
![]() |
|
Dave Zatarain atop the Point Fortin, Trinidad radio tower 1996 |
Richard Small moving fast (as always) in Point Fortin, Trinidad 1996 |
Strong international sales was an important aspect of SCADAware's success. Roger Equerme represented SCADAware in the Middle East. Eric Fidler drove SCADAware's international success by promoting (and often selling) versions that didn't yet exist.
![]() |
![]() |
|
Roger Equerme
faking it with a SCADAware demo in Abu Dhabi |
Eric Fidler relaxing somewhere offshore Jakarta.1995 |
TEST's founder, Dick Piner, was a strong supporter of SCADAware's concept, developers, and loyal customers. Tom Lingoni helped usher many international projects from the design phase through completion. Steve Robertson managed installation and commissioning of SCADAware stations in remote China. Stan Taravella was Arthur's "right hand man" in the SCADA shop for 20 years of SCADAware's development.
![]() |
![]() |
|
Tom Lingoni, Dick Piner, and Steve Robertson in 1994 |
Stan Taravella in 1994 |
A complex SCADAware network was configured by Dubai Petroleum Company (DPC) using in-house fabrication and programming staff. Arthur provided on-site training and technical support to the DPC technicians who managed the project. A key player was Subir "Sam" Pherwani who helped defuse the intentional sabotage done to the SCADAware stations by those who cannot be named (but they know who they are).
![]() |
![]() |
|
Eric Fidler and Dave Zatarain in China c1992 |
Subir "Sam" Pherwani at Dubai Petroleum Company |
Nick Niklaus created most of the SCADAware graphic images that amazed us in the early 90's. Alan Broxson hustled SCADAware throughout Asia in the 1990's and 2000's, and may not have stopped yet.
![]() |
![]() |
|
Nick Niklaus with Arthur in January 1992 |
Alan Broxson with Arthur
helping the UK unload Hong Kong in 1997 |
One and three day SCADA Seminars were a hot ticket in the 1990's as the industry slowly came to terms with remote monitoring and control. Mitch Wiese and Arthur Zatarain conducted dozens of presentations and training programs back when terms such as "modem" and "analog" frightened people to death.
![]() |
![]() |
|
Arthur Zatarain spreading the SCADA word circa 1992 |
Dick Piner, Nick Niklaus, and Mike Moity in trade show 1991 |
Near the end of SCADAware's development both Travis Combel and Vinny D'Ingianni provided product support and project development. They assisted long term customers who continued to use SCADAware despite the availability of more modern systems. They also assisted customers with installation of small Modbus-compatible PLC systems to serve as RTUs. Those replacement RTU's continued to interface with the older SCADAware systems to provide useful features that are still unavailable in many modern systems. Several SCADAware systems were noted in operation in the Gulf of Mexico in 2014, validating a telemetry concept that was first conceived in the 1980's.
![]() |
![]() |
|
Travis Combel looking sharp in Kazakhstan |
Vinny D'Ingianni "muddling through" a SCADAware problem |
SCADAware applications
SCADAware systems were applicable to diverse situations in the US as well as international locations. The range of monitoring and control applications included offshore and onshore oilfield, wastewater systems, power generation and distribution, living quarters, meter stations, drilling, pharmaceutical production, pipelines, tank farms, clean rooms, facility access control, communications rooms, sugar refining, and petrochemical plants.
A list of large and small customers for which SCADAware systems were designed reflects the wide range of situations in which they could be applied:
Air Products
Alabama Power Company
American Cyanamid Corp.
Amgen Pharmaceutical
Atlantic Richfield
BP - Americas & Venezuela
Caroni Sugar - Caribbean
Chevron - Nigeria & USA
Central LA Electric Cooperative
Conoco
Consolidated Natural Gas
CXY Energy
Daweoo Industries - Korea
Dubai Petroleum Co.
Elder Portable Buildings
Eni Exploration Production
Enron - India & Trinidad
Exxon USA
Freeport McMoRan
Houma Industries
Hyundai Heavy Industries
IPC - Malaysia
Jefferson Sewage & Water Bd.
Lake Pontchartrain Causeway
Louisiana Power & Light
Mobil Oil
Monsanto
Nexen
Natural Gas Company - Trinidad
Orleans Sewage & Water Bd.
Occidental Petroleum - Malaysia
PEMEX - Mexico
Pertamina - Indonesia
Petrocom Communications
Petrotrin - Trinidad
Qatar General Petroleum Co
Shell Oil - USA & Thailand
Sheng Li - China
Sohio
Southport Quarters Buildings
Tarim Petroleum - China
Texaco - US & Angola
Total Minitome
Trinmar - Trinidad
Union Pacific Resources
Unocal
Vastar
Wacker Development Corp
Weatherford Enterra
SCADAware brand name
Arthur Zatarain developed the SCADAware brand name and applied for a US Trademark in 1994. The TM was assigned to Total Engineering Services Team (TEST) in 1997. Note that the SCADAware product line developed by Arthur Zatarain is not related to the SCADAware systems integration company located in Illinois.
Whatever became of TEST?
Total Engineering Services Team (TEST) was formed by Dick Piner in 1970. TEST purchased Dataran Engineering in 1988 which brought Arthur and his crew to TEST. The company was rebranded as TEST Automation and Controls during the 1990's and became part of Weatherford-Enterra. Natco Group acquired TEST from Weatherford in 1997. The company grew steadily until key personnel left in 2008 to start VersaTech Automation Services. Natco (including TEST) was purchased by Cameron in 2009, shifting TEST into Cameron's Flow Control division. Finally, in Summer 2013, the spinoff VersaTech purchased "the company formally known as TEST," closing the loop that had begun in 1970.
Fictional SCADAware references
The following presentation never happened, but it would have been a very memorable moment:
SCADAware Documents Online
The following docs are provided for reference only. Any use must be credited to TEST Automation & Controls, and to Arthur Zatarain who fully prepared or significantly contributed to all of these documents:
Copyright © 2024 Arthur Zatarain, all rights reserved. Some images are modified for confidentiality
or illustration clarity. This site should not be used as a technical or legal reference.