and Data Acquisition (SCADA) System
 |
 |
|
| Type 1200 in a trade show booth | Hand crafted graphic display |
SCADAware Background
The concept for a PC based supervisory control and data acquisition system (often called "SCADA") was first developed by Arthur Zatarain in the mid 1980's. The idea evolved from a telemetry system dubbed "AdLink" that he developed in 1984 at Dataran Engineering. That programmable SCADA system used Analog Devices RTU (remote terminal unit) products managed by PC and AT class computers connected over both phone and radio links. Although successful in the field, the limited programmability of the Analog Devices RTU equipment contrasted sharply with the unlimited potential of the personal computers back in the office. The future path was clear: the personal computer had to go out where it was hot and dirty.
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 that was first introduced to the offshore oilfield in 1988. The first units were fabricated by Paul Napolitano and Don Caskey for applications in offshore oil & gas production in the Gulf of Mexico. Several hundred SCADAware units were installed worldwide during the 1990's before PLC and RTU devices with Microsoft Windows interfaces surpassed SCADAware's unique capabilities. Regardless, many RTU units remained in operation through the 2000's by migrating to Windows interfaces using SCADAware's open architecture interface, or operating with DOS-under-Windows.
 |
 |
|
| TEST Type 1200 Smart RTU | Type 1200 Demo Unit |
SCADAware Smart RTU Development
The SCADAware Smart RTU hardware 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.
Later Type 1200 RTU units used single board AT 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 DAS08 I/O interface wired to digital and analog 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.
 |
|
|
| Type 2000 Dumb RTU Prototype | Type 1200 with TEST I/O Boards |
Other SCADAware Hardware
The Type 2000 and 2200 SCADAware "dumb" RTU devices were developed to meet customer demand for a lower cost, limited capability RTU. The smaller units were based on Intel MSC-51 / 8052 microcontroller technology, with embedded firmware written in Assembly and Basic. RTU configuration for each location was done via download from a Smart RTU that also controlled most system operation. Development of the Type 2000 RTU series required board-level hardware and software design to produce a low cost, energy efficient RTU. These small RTU's could operate at low power levels with "Call on exception" and "quiescent operation" using periodic operation to update the Host system. Like all SCADAware RTUs, these units often operated from solar power systems specifically designed for each installation location.
A pioneering voice announcing RTU was also produced as part of the SCADAware product line. The Type LB-100 was based on the Seekirk A1800 telephone auto-dialer, also designed and programmed by Arthur Zatarain while still at Dataran. This Z-80 (Hitachi HD64180) based ingle board microcomputer could respond to digital inputs and control digital outputs using DTMF "touch tone" codes received over any audio source. It could also link to a smart RTU or Host via parallel port connection to perform a variety of voice announcing, auto-dial callout, and digital output control.
Most SCADAware systems were fitted with a watchdog timer device named the Modem Monitor. This stand-alone gadget tracked local system activity to detect hardware or software problems, and could automatically reset the system if the activity signal failed for a period of time. The Modem Monitor also performed other handy functions such as tracking incoming ring counts and providing a remote reset feature via simple "break" signal over the communications line.
 |
 |
|
| Realtime Graphic Display | Type 1200 RTU's destined for Trinidad |
SCADAware Software Development
SCADAware's realtime software core was based on a Z-80 operating system called "Zatmon" that was developed by Arthur Zatarain in the 1970's for Digital Group computers. Early versions of SCADAware used the standard DOS operating system loaded from floppy disc, while later versions used a "generic" DOS loaded from solid state discs. Although DOS managed the computer's file resources, the realtime system operation of all hardware resources 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 two distinct environments. The "RTU" version was designed to manage realtime processing with the limited CPU and memory resources of an RTU. This version lacked graphics and other advanced features not needed in the field. The larger "Host" version of SCADAware provided all of the RTU features as well as many other database, graphics, and network features that were useful in an office environment. However, the "office" was often in a very rugged industrial or offshore environment, so the Host version often saw rough duty in the field.
The primary system architect and programmer was Arthur Zatarain, with programming support over several years by Cory Moragas. Corey was also deeply involved with 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 Borland Pascal packages. The original version was written in the first release of Turbo Pascal on PC class computers. This version relied on I/O and communications libraries previously developed in Intel assembly language by Dataran for industrial process applications (for ADLink etc.). That initial version of SCADAware briefly transitioned to Borland C, but this was prior to introduction of C+ and C++. The original C version of SCADAware proved too inefficient for actual implementation on limited resource computers in the field RTUs and never got past the proof-of-concept stage.
SCADAware development abandoned C and moved on to object-oriented designs based on Borland Pascal using libraries by Arthur Zatarain and TurboPower. Advanced features incldued fax transmission, net DDE (dynamic data exchange), voice announcements, and user-programmable graphic displays. These features were possible on the Host version that used the DOS Protected Mode Interface (DPMI) memory management system operating under DOS. The Borland Pascal version continued to be developed and supported until Arthur retired from TEST Automation and Controls in 2008.
A complete compile of the final RTU version of SCADAware crunched through over one million lines of assembly language and Pascal code The larger Host version using the DPMI system topped two million lines. All that code had evolved over 20 years of industrial program development, producing telemetry products that are still operating in the field as of July 2011.
 |
 |
|
| Simple text display on field RTU | Type 1000 with solar power system |
SCADAware Communications
SCADAware was 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, stored in files, or manually typed by an operator (see sample here). Although plain text TSP required more bytes than an encoded method, the simplicity and transparency allowed any person or computer to easily evaluate and understand the information. Commands and data could be entered by hand in what was called "Terminal mode." This feature presented the human operator with a command prompt similar to that of DOS. The manual command interface even allowed "shelling out" to DOS for manual operation of the computer while SCADAware was still running. This may sound trivial now, but it was magical in 1988 when operating a distant computer over a 1200 baud radio connection.
TSP computer-to-computer links were similar to the human format. The protocol also included a sequential block number for each transmission, and required a specific acknowledgement from the receiving unit. A cyclic redundancy check (CRC) code was also 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 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.
Another key aspect of SCADAware's data protocol was that every transmission contained a field from From, To, and Timestamp. The timestamp identified the local time that the data was transmitted or stored. An additional timestamp feature was available to mark the time that the data itself became valid. This time may differ from the transmit time when data was relayed among units. 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.
The initial communications links were direct wired between units, and also telephone using Hayes modem protocols. SCADAware maintained a callout list of phone numbers to be contacted for a matrix of conditions. This allowed a single unit to call multiple other units under a variety of individually controlled circumstances.
SCADAware radio communications initially used the X-25 protocol over Packet Radio Controllers (PRC). Standard voice radios were 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 Intellect Conference in Dallas, TX.
Although the PRC proved to be a workhorse in the field, its relatively slow throughput prompted the addition of a more direct audio radio connection using a simple audio modem. The computer managed the push-to-talk control via an RS-232 output. This method was similar to a direct wired connection with the addition of key-up and key-down delays as well as control of push-to-talk.
Computer network connections were eventually added for systems operating with DOS under Windows. A logical connection method allowed a virtual direct connection between multiple units on a common network. The update process was very fast and efficient, and allowed multiple computers to view RTU data over a network in near realtime.
An "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 contained a broadcast feature in which a sending unit sent data to multiple receivers at the same time. This was similar to data "streaming" now used on the internet. This feature 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.
SCADAware Documentation
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. A PDF version of all available documentation can be found here.
SCADAware people
Although Arthur Zatarain developed the SCADAware product line, many key players helped design, program, install, and maintain the systems. 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 cellphone | Tim Lynn - Super SCADA tech |
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 joined the team early on and contributed software development and testing for several years. Glen Melancon worked for a short time as a field technician for SCADA projects in the Gulf of Mexico.
 |
 |
|
| Stan Taravella (left) with an early Type 1000 | Corey Moragas and Glen Melancon |
Mitch Wiese was the prime SCADAware contact in Houston. He had a major influence in practical aspects of the installed systems, and he developed the "SCADA on a stick" concept shown below on the right. This single-point-lift concept provided an efficient method of installing a solar powered RTU onto small offshore platforms using a portable hoist.
 |
 |
|
| Mitch Wiese on Pemex wellhead 1993 | Type 2200 "SCADA on a stick" |
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 in the Gulf of Paria. Richard eventually joined TEST in the States to manage many 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 had a strong influence on SCADAware's international success by promoting (and often selling) versions that didn't yet exist.
 |
 |
|
|
Roger Equerme with SCADAWare demo unit in Dubai |
Eric Fidler offshore Jakarta 1995 |
One and three day SCADAware 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 back when terms such as "modem" and "analog" frightened people to death. The handsome fellow below right is Arthur Zatarain with his first Z-80 microcomputer, circa 1978. His pocket protector will one day be displayed in the SCADAware museum.
 |
 |
|
| Arthur with SCADA class in Houston | "Hand crafted" Z-80 micro c1978 |
Near the end of the product's development both Travis Combel and Vinnie D'Ingianni provided product support and project development. They assisted long term customers who continued to use SCADAware systems despite the availability of more modern graphic-based designs. They also assisted customers with replacement of outdated SCADAware RTU's using Modbus compatible PLC systems. Those new RTU's continued to interface with the SCADAware host systems that provided useful real world features unavailable in more complex systems.
SCADAware brand name
Arthur Zatarain developed and trademarked the SCADAware brand name that was assigned to Total Engineering Services Team (TEST). That company name was later changed to TEST Automation and Controls, which was sold to Natco Group. That company was rolled into Cameron Flow Control in 2009. By mid-2010, the only remaining "TEST hand" familiar with SCADAware was Stan Taravella.
Note that the SCADAware product line developed by Arthur Zatarain is not related to the SCADAware systems integrator company located in Illinois. That company was requested by TEST to cease using the SCADAware brand name for industrial telemetry products and services. That company agreed to stop, but never did. No action is known to have ever been taken by TEST against the Illinois company.