Tom A. Grobicki
Michael R. Abram
While market forces drive most businesses, those that specialize in
pollution control and environmental monitoring devices are driven
almost exclusively by changes in Federal, State, and local laws.
Usually embroiled in controversy, new regulations appear frequently,
and interpretations of existing regulations often change. The
companies’ clients therefore need a highly reactive software
environment. In order to control and monitor air pollution, their
software system must be solid enough for government investigators to
hold accountable, yet light enough to change instantaneously with the
laws. The clients demand features from their air pollution monitoring
systems such as low cost, high functionality, simple user interfaces,
reliability, and fast updates to accommodate regulatory changes.
To address their customers’ demand and the increased monitoring
complexity required by law, one company chose to turn to Ada for a new
air pollution monitoring system.
Product and market
Enviroplan, Inc., is a privately-held company located in Roseland, N.J.,
which has addressed the air quality market for over twenty-five years. In
1974, the company began to offer in-house data processing for
monitoring ambient air quality. The company introduced its first
commercial product, an ambient air quality monitoring computer system,
in 1977. In 1983, Enviroplan introduced the Continuous Emission
Monitoring Data Acquisition System (CEMDAS®).
CEMDAS measures gaseous pollutants, opacity, and related process
parameters of industrial boilers and stacks. It acquires data for
reporting in compliance with Federal, state, and local environmental
regulations. The products provide realtime emissions information to
the plant operator and historical data to regulators. Enviroplan
originally sold CEMDAS to electrical utilities, resource recovery
plants, cogeneration plants, and general industry. With plans in
process for a fourth-generation CEMDAS, the software evolved from a
minicomputer-based FORTRAN application to an Ada system on a PC.
The market for large power plants that Enviroplan has targeted since
1972 dried up in the 1990s because the largest polluters for the most
part have been brought under control. Enviroplan is currently
revamping its software to attract second-tier polluters, such as
bakeries and auto manufacturers. These are known within the
regulatory community as “smaller sources,” which emit many fewer BTUs
per hour. The Environmental Protection Agency (EPA) is now pursuing
such smaller polluters.
Typical CEMDAS installation
Enviroplan usually integrates CEMDAS with its Continuous Emission
Monitoring Extractive System (CEMEX®), which consists of a probe in
a stack that sends a diluted sample of stack gas down to
sulfur-dioxide, carbon-dioxide, and nitrogen-oxide monitors in a
shelter at ground level. These instruments, along with opacity and
flow monitors in the stack, provide electrical signals to an
input/output (I/O) subsystem in the shelter. An industry-standard
PC-compatible computer in the plant control room runs the CEMDAS
CEMDAS must simultaneously interface with the I/O subsystem; process
and store average, alarm, and calibration data; produce required
reports in agency-approved formats; and provide real-time displays to
control room operators. CEMDAS’ multitasking design supports several
concurrent users through the system console, remote terminals, and
password-protected telephone access.
Each installation of CEMDAS is unique: the emissions that are measured
and controlled are determined by the U.S. EPA, state and local
agencies, and the terms of each plant’s air quality permit. New
regulations, including the Clear Air Act and proposed Acid Rain
legislation, mandate the use of a high-speed, reliable, and
certifiably correct computer system for the collection of valuable
sulfur-dioxide emission allowance data. Credits for reducing a
plant’s emissions below its allowance can be sold in a new commodity
market, where a company with an older, less efficient plan may buy the
credits to avoid expensive fines.
The move to Ada
Enviroplan switched the development of CEMDAS from a
minicomputer-based FORTRAN-language application to a PC-compatible
microcomputer-based Ada application. Market pressures dictated the
necessity of undertaking such a dramatic change. The traditional
customer base for CEMDAS systems had become more sophisticated, and
the regulatory climate was rapidly changing and becoming more
demanding. Enviroplan had to reconfigure the architecture of the
CEMDAS hardware and software, while keeping up with users’ and
regulators’ expectations and demands.
The key factors demanded by industry included low cost, functionality,
regulatory compliance, simple front-end interaction, total
reliability, fast delivery of a custom system, non-obsolescence, and
access to the data. The program structure had to be flexible enough
to accommodate changes to comply with each plant’s air quality permit,
to accommodate future regulations, and to allow for unique changes
based on installation-specific conditions. In addition, regulatory
agencies had to have access to the system to monitor the plants’
A primary criterion in revamping the system was the hardware platform
to serve as a host for the CEMDAS software. Previous platforms,
including the Data General NOVA and Eclipse computers, had proven to
be too expensive to operate, particularly with respect to long-term
maintenance. Customers began to request support for CEMDAS on PC
systems, which they considered to be reliable, cost effective, and
user friendly. Not only did PC clones provide a less expensive
solution, but they eliminated Enviroplan’s dependence on a single
vendor and were more likely be compatible with clients’ existing plant
Choosing among several languages
Once Enviroplan had decided on the hardware, it realized that the
language/operating system had to be selected together. Several
alternatives that the software developers considered and initially
rejected included iRMS, VRTX, and Unix. In each case, the languages
supported, including C and FORTRAN, would have resulted in an
application that was completely reliant on the operating system for
features like multitasking and communications support.
The MS-DOS operating system (OS) that runs on PCs was not sufficiently
full featured to be considered as a stand-alone mode. A light-weight
OS, it does not include features needed for a real-time data
collection system. However, when it was considered in conjunction
with a language like Ada, its simplicity and minimal overhead proved
to be advantageous. Several vendors provided extensions to the C
programming language that could accommodate some CEMDAS requirements.
However, it was felt that even a multi-vendor solution for language
and tasking would tie CEMDAS to these vendors and could prove to be an
Enviroplan finally chose Ada in part because of its
“government-friendliness” and in part because of its validation, which had engendered a reputation of enduring, formal, and rigorous
testing. But mostly Ada’s multitasking made it the best language for
the software, as well as its flexibility, robustness, and ease of
change, which proved themselves in two subsequent ports of CEMDAS to
Anatomy of Ada features
As the Ada/MS-DOS combination appeared to be a good candidate, the
developers conducted further investigations to determine the impact of
its use on CEMDAS, particularly in terms of long-term costs. The
software engineers purchased an Ada compiler for investigation and
training, and found sources for public-domain software.
From the investigation, the engineers discovered several unique
features of Ada to be key in selecting it as the development language
for the CEMDAS product, listed below:
Positive Features of Ada
Other advantages tend to be more vendor-specific but do reflect a
general trend in the Ada product marketplace. Because of the emphasis
on software engineering, most Ada compilers come with integrated
debuggers and with make facilities to help automate updates. Many
also provide other features that assist developers in managing their
libraries, optimizing the code, and reformatting source code.
Compile-time error messages frequently point to specific sections of
the Ada reference manual. Throughout the selection process, Ada
proved to be a developer-friendly language that aids in the creation
of reliable software.
- Enforced standards for Ada would enhance portability and reduce
future development costs.
- Tasking is built into the language, which improves portability and
reduces multi-vendor incompatibilities.
- Strong typing and package specifications catch programmer errors
during development rather than during testing or in customer
- Separate compilation facilitates integration and future
modifications, and simplifies code maintenance.
- Ada is more readable, further improving maintainability.
Standardized Ada components
A marketplace similar to what developed in the integrated-circuit
marketplace has evolved to provide standardized Ada components. Ada
programs in the public domain often served the Enviroplan software
engineers as examples of style and design and were a source for
standardized components. The engineers anticipated that the Ada
component marketplace would further evolve to provide reusable
components and subsystems that could prove particularly beneficial in
reducing cost and time-to-market of future enhancements.
In the 1980s, the selection of Ada as an implementation language was
not without problems, many of which, however, stemmed from the
weaknesses of early Ada compilers. Also, as with most first-time Ada
users, Enviroplan had to contend with a steep learning curve. Detailed below are some major obstacles.
In most cases, time has solved those problems. Computer-aided
instruction courses are available and have assisted in training the
software engineers. Competitive pressures on vendors have forced them
to provide compilers with better access to other language libraries
and to the external environment.
Competition has also driven compiler vendors to provide additional
components to assist developers in using their compilers. The
component marketplace has filled out with companies such as
Enviroplan supplier AdaSoft, Inc. that provide tested commercial
off-the-shelf components in areas such as device drivers, man-machine
interfaces, and database management systems.
Problems in Ada’s early days
- Time needed to learn Ada made start-up cost high. Easy and
inexpensive access to a compiler was needed during training. However,
few compilers were priced appropriately.
- Access to third-party software libraries was limited and in some
cases did not work. Standardized mechanisms for access to the
external environment were not present in the language, and many
vendors chose to ignore features in Ada that could facilitate such
- Early implementations of the language had bugs. A compiler being
validated does not mean it always compiles legal Ada code, nor is it
necessarily of production quality.
- The component marketplace did not evolve as rapidly as hoped.
Product evolution and future
CEMDAS has improved in many ways since the original implementation
that targeted a real-mode PC-compatible system. Customers have
continued to demand increasingly complex systems that monitor more
data, provide better response time, and generally ease the burden on
the plant operators. Enviroplan has a regular program of product
updates that keep pace with customer demands. Interestingly, many
improvements to the system have come from an evolving component
For example, one severe limit to the system initially was the
640-kilobyte available memory for both operating system and
application memory. Fortunately, Thomson had already anticipated the
need for industry standard extended environments and had selected Phar
Lap 386\DOS-ExtenderTM for use with its MS-DOS ‘386 Ada compiler.
The Phar Lap DOS-Extender allowed Alsys to provide access to extended
memory beyond the 640K DOS limit.
During the transition to the ‘386 extended mode, it was found that
certain terminate-and-stay resident (TSR) routines used for device
drivers could not work in this mode. Previously, Enviroplan would
have been faced with developing new drivers itself and incurring the
resulting schedule and cost impact. At this point, Enviroplan sampled
the available components marketplace and was able to purchase drivers
for serial hardware from AdaSoft. Consequently, the transition from
‘286 real-mode to ‘386 protected-mode took only a week of integration
Enviroplan then upgraded CEMDAS into an SCO Unix system and ported it
to a Sun Workstation, with a graphical user interface (GUI) and a
database backend. The new product was upscale and networked, but the
market for such a powerful system dried up with the pollution-control
market among large power plants.
Like the port from the ‘286 to the ‘386, AdaSoft transitioned CEMDAS
to a modern Unix GUI with few revisions to the code and minimal
redesign. They used Oracle’s Pro-Ada for the database interface and
the Ada binding of the commercial product SL-GMS for generating the
Windows interface and for easing the transition to SCO Unix. They
also used an automated tool to translate some of Unix’s “include”
files into Ada pragma packages. Only the low-level serial port
drivers, some of which CEMDAS uses to communicate to the pollution
monitoring hardware, had to be fixed individually because they vary
from Unix to Unix. To do interfaces, standard pragma interfaces, and
directory searching, the developers also had to write a few other
bindings to operating-system calls. SCO did not support any custom
bindings with Ada into their Unix, which meant AdaSoft wrote
interfaces between their libraries and the CEMDAS software.
Reuse helped the transition. AdaSoft was able to reuse much of
Enviroplan’s DOS code as-is, as well as use some libraries that they
developed in-house that linked list packages and data structure
The new GUI allows Enviroplan to offer a full menu-driven graphical
environment with strip-charts and other graphical representations for
data output. The GUI updates data almost simultaneously with CEMDAS.
The monitoring processes collect the new air-pollution numbers, and
the data-collection engine puts them in the database every six
seconds. The numbers are then displayed on the screen’s graphs and
Power plants are obligated to keep a year of collected data on line at
all times, which includes data that have been derived or computed
from the data of many inputs. The CEMDAS databases are about 100
megabytes, although the size varies from plant to plant. Each plant
purchases different features of CEMDAS according to their EPA
Enviroplan has concluded that the use of Ada for the development of
its CEMDAS product has resulted in a robust commercial product with
better uptime statistics and mean-time-to-repair.