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

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

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

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’ compliance.

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 hardware.

Choosing among several languages

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 unreliable solution.

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 new hardware.

Anatomy of Ada features

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

• 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 installations.
• Separate compilation facilitates integration and future modifications, and simplifies code maintenance.
• Ada is more readable, further improving maintainability.

Standardized Ada components

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 access.
• 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

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-Extender^TM 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 and testing.

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 packages.

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 charts.

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 compliance needs.

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.