\vEPA
United States
Environmental Protection
Office of
Solid Waste
Washington, DC 20460
January 23,1989
SYSTEM
ARCHITECTURE
EPA
530/
1989.8 f
RCRIS
-------
PURPOSE
The purpose of this document is to describe the RCRIS architecture. The system
architecture, along with possible alternatives, was updated with the decisions and choices made by
the EPA RCRIS Staff and the Merged Data Base (MDB) Task Group, which was formed on
October 1, 1988. This group was given the responsibility of finalizing the architectural design for
RCRIS, which appears herein.
HEADQUARTERS LIBRARY
ENVIRONMENTAL PROTECTION AGENCY
WASHINGTON, D.C, 20460
Q>
O
CM
-------
THE RCRIS ARCHITECTURE
Overall System Requirements
There are two basic requirements that the RCRIS architecture is designed to support:
1. A two domain structure that provides for an implementer domain and an oversight
domain (see Exhibit 1).
2. A distributed and shared set of responsibilities and information between two
implementers, state and EPA region (known as co-implementers to each other), and a
logical merging of that set of information, which is based upon agreed responsibilities
(see Exhibit 2).
Key Design Concepts
Beside supporting the two basic requirements as stated above, the RCRIS architecture is also
designed to support some key concepts, which provide full functionality to both the implementer
and oversight users of the system. These concepts also cover some features that are accomplished
by the RCRIS software directly or within the framework in which the software operates.
1. The distributed and shared responsibilities are set forth in a separately negotiated
Memorandum of Understanding (MOU) between each state and EPA regional
implementer. The MOU is the repository for the decisions and agreements
between the implementers on a state-by-state basis. Consequently, the RCRIS
software automates and supports the applicable parts of each MOU via table processes
so that initial MOUs and subsequent changes can be implemented through simple
additions, deletions or changes to table file contents.
2. The RCRIS Implementer of Record (IOR) concept ensures that an implementer
controls the data which is their responsibility as set out in each MOU. The final
responsibility for and the integrity of information for the oversight domain is
controlled by IOR blending of implementer data in a merge process, which each EPA
regional office controls.
3. RCRIS architecture allows for the feedback and local merging of co-implementer data.
The local merging of co-implementer data is discretionary and at
the control of the implementer. Such local merging affords each
implementer the capability of monitoring the data of the co-implementer and the status of
the merged data base in a distributed fashion.
-------
4. The scheduling of implementer updates to the Merged Data Base (MDB) is flexible. The
final determination is negotiated between the state and EPA regional
office and documented in the MOU. Since the extraction of oversight domain data and
the generation of oversight reports will be done on a monthly basis, it is expected that
the scheduling of implementer data merging will be at a minimum monthly, but
frequently more often.
5. Electronic data submittals from non-RCRIS state implementers (called
"translators") is fully supported by RCRIS.
6. RCRIS allows the regional office to act as a "surrogate state" implementer for a
manually reporting state while also maintaining its role as a regional implementer.
7. RCRIS has been structured to support a wide range of hardware configurations that run
IBM compatible FOCUS software and also a wide range of electronic exchange media
(e.g., tape, diskette, telecommunications).
Description
This section is divided into four pans. Each of these parts describes the RCRIS architecture
and how the architecture will support the two basic system requirements along with the key design
concepts stated above. In summary these parts:
1. Provide an overview of the RCRIS system architecture;
2. Describe both state and region implementers using RCRIS software,
3. Describe a state using its own non-RCRIS system with automated record transfer
(translator state); and
4. Describe a state sending manual documents to the EPA regional office for processing
into RCRIS.
1. RCRIS Architecture Overview
Exhibit 3 shows the overall RCRIS architecture in its most basic and ideal form, i.e., both
the state and region use RCRIS. As shown, the RCRA data is collected, validated, and
maintained by an implementer on a data base that is locally stored, known as the Implementer
Data Base (IDB). The IDB is the location where ail RCRIS data is initially created and
subsequently changed. The implementer may transfer all of the data or just the oversight ("core")
data to the Merged Data Base (MDB).
.
-------
The MDB stores the data that is sent from each implemented Core data is extracted from the
MDB for the National Oversight Data Base (NODB). Further, core data is extracted from the
MDB by the Region for its oversight purposes. However, the MDB is primarily a place for the
logical merging and subsequent storing of both implementers' data. This "mixing" and "holding"
area is necessary because the state and the EPA region are co-implementers for each of the state's
regulated facilities. This co-implementer arrangement leads to data differences between
implementers which are resolved in the logical merging function of the MDB. The results of the
"successful" merging of data into the MDB are electronically "fed back" to the other implementer
for updating its IDB. This allows each implementer the option of locally capturing the
authorized data values of the co-implementer and the data values in the MDB.
The NODB is the location of the RCRA core data from which the EPA headquarters
accomplishes its oversight responsibilities.
The data flows from the IDB to MDB, the MDB to IDB, and the MDB to NODB are all
initiated by action on the part of the sender (a "push approach") which can be contrasted with an
action initiated by the receiver (a "pull approach"). Throughout this paper, all data flows are
based upon the "push approach".
2. Both Co-Tmplementers with RCRIS Software
Exhibit 4 shows both the state and the EPA region using the RCRIS software.
Though only one state IDB is shown, the state may have more than one. However, the
separate IDBs must be combined before data are sent to the MDB and each IDB must maintain
unique and complete sets of facility data (i.e., no facility may be split between IDBs). This
combining of data is required to eliminate the logistical problems that occur with a proliferation of
intra-implementer merge responsibilities.
The RCRIS architecture supports several user options at the implementer level:
Single-User Option (presumed to be on a PC);
Multi-User Option (presumed to be on a mainframe computer,
though possibly on a mini-computer or a PC network); and
Distributed Single/Multi-User Option (a combination of the first
two user options, each supporting a mutually exclusive subset of handlers).
-------
Since it is the implementer's prerogative to send all or only core data to the MDB, RCRIS
allows the implementer to choose either option via the Core/All Filter (see Exhibit 4).
Because the MDB for each state is initialized from HWDMS (as is the region's IDE and
optionally the state's IDB), only subsequent IDB changes need be transferred to the MDB. To
send only data base changes (in order to avoid sending "all the data, all the time"), a Change Table
is maintained on the IDB for all RCRIS data entry and manipulation modules. This table provides
the necessary and sufficient intelligence for extracting only those IDB portions that have actually
changed since the last extract. Successful extracts cause the Change Table to be re-initialized so
that only the most recent updates are referenced.
The MDB resides on the EPA regional logical mainframe systems or, optionally, on the
mainframe. The update transactions received from the IDB are temporarily stored in a flat file on
the logical mainframe prior to the merging into the MDB. The IOR Filters in Exhibit 4 solve data
currency and data collision problems that occur when two IDBs are combined for the MDB. The
MOU between the co-implementers provides the necessary foundation for the IOR Filter.
If an implementer desires, it may receive and load the successfully merged data from its
co-implementer. Exhibit 4 shows this information being returned from the MBD to the local level
in a flat file. The return of one implementer's data to its co-implementer is via electronic media
(tape, diskette, telecommunications) depending upon both implementers' hardware configurations,
capabilities or preferences. Similar to the MDB merge, the IDB update is via transactions from
the implementer held in a temporary flat file.
Since it may occasionally be advantageous for implementers to send all of their data to the
MDB (i.e., not using the Change Table), such functionality is allowed.
There is only one NODB and it resides on the IBM 3090 system at RTF. The oversight
data is sent from each of the ten regional logical mainframes and concatenated at the national
level. The Core Filter in Exhibit 4 blocks the non-core data during this process. Because the
RCRIS data elements are the same for the IDB, MDB and NODB, the Core/All Filters and the Core
Filter simply place null values in all non-core data fields when filtering for core only.
-------
3. State Implementer with Non-RQRIS Software (Translator Case)
As shown in Exhibit 5, the Translator State case is very similar to the previously discussed
case (Exhibit 4), except that the Core/All Filter has been replaced by a Translator Extract and a
Translator Update has been added. The first operational step for the translator is to extract and
convert RCRA data to proper RCRIS format for sending to the MDB. The Translator Extract
accommodates this function as well as the function of the Change Table for sending only recent
transactions. All other functions work the same as previously discussed for the regional
implementer, the MDB and NODE.
The only other difference for this case is the return of regional implementer data from the
MDB to the translator. A translator state may use the Translator Update to convert the RCRIS flat
file format data into the translator's system format for merging into its IDB of RCRA data.
Alternatively, the state may receive a hard copy report detailing its co-implementer's update
information.
It should be noted that the software development necessary for the Translator Extract and
Translator Update is the responsibility of each translator state (as it requires detailed knowledge of
each state's unique RCRA data base structure). However, the EPA will provide guidance and
technical assistance to states exploring or pursuing the translator option.
4. State Irnplernenter without Automation (Manual Case)
The operation of a manual state implementer is shown in Exhibit 6. In this case, the state
prepares RCRIS information on data forms that are sent to the EPA regional office for computer
entry. The EPA regional office staff simply acts as a data entry service (or "surrogate") for the
state implementer with all reports, edit exceptions, etc. being sent to the state.
A separate IDB is maintained for the manual state on the regional hardware in an analagous
fashion to the regional IDB. Consequently, the EPA regional office maintains a "surrogate" IDB
for the manual implementer state and provides a full range of "surrogate" services for the state.
All other functioning of the RCRIS architecture previously discussed remains the same.
-------
In summary, this "surrogate" approach for manual implementer states has several
advantages:
It maintains complete data separation, which provides IOR integrity;
It parallels all of the significant RCRIS data flows, edits, security controls and
reporting functions of a full RCRIS user; and
It greatly simplifies a state's transition to RCRIS if it should decide to leave manual
processing and become automated.
Conclusion
The foregoing presentation of the RCRIS architecture is purposefully brief to present only
those structural elements that are necessary to show the essence of the overall system approach.
The reader is referred to the MDB Task Group's Functional Requirements and Detail Technical
Specifications Documents for greater specificity.
-------
EXHIBIT 1
TWO DOMAIN REQUIREMENT
Oversight Uses:
Response to Congress
Response to FOIA's
* Management Information
Inter-State Analyses
Inter-Region Analysis
* Universe Calculations
OVERSIGHT DOMAIN
Oversight Data
Collection
Validation
Data
Transfer
to Oversight Data Base
Implementer
Data
Handlers
Implementer Uses:
Response to Legislature/Congress
Public Information
Management Information
Intra-State Analyses
Updates to RCRIS
Universe Calculations
-------
EXHIBIT 2
DISTRIBUTED AND SHARED
REQUIREMENT
Oversight Uses:
Response to Congress
Response to FOIA's
Management Information
Inter-State Analyses
Inter-Region Analyses
Universe Calculations
OVERSIGHT DOMAIN
Oversight Data
Data
Transfer
to Oversight Data Base
Logical Merge
State
Implementer Domain
Collection
Validation
Implementer
Data
Handlers
Implementer Usesr
Response to Legislature
Public Information -
Management Information
Intra-State" Analyses
Updates to RCRIS
Universe Calculations
Region
Implementer Domain
Implementer
Data
Collection
Validation
Implementer Uses:
Response to Congress
Public Information
Management Information
Intra-State Analyses
Updates to RCRIS
Universe Calculations
Handlers
I
-------
Oversight Uses:
Response to Congress
Response to FOIA's
Management Information
Inter-State Analyses
Inter-Region Analyses
Universe Calculations
NATIONAL
EXHIBIT 3
OVERVIEW OF RCRIS
SYSTEM ARCHITECTURE
Oversight Uses:
* Response to Congress
Response to FOIA's
Management Information
Inter-State Analyses
Universe Calculations
REGION
REGIONAL
OVERSIGHT
REPORTS
OVERSIGHT DOMAIN
NATIONAL OVERSIGHT
DATA BASE (NODB)
MERGED
DATA BASE
(MDB)
IMPLEMENTER DOMAIN
Collection
Validation
Implemementer
Data Base (IDB)
L
Implemenler Uses:
Response to Legesfature
Public Information
Management Information
Intra-State Analyses
Updates to RCRIS
Universe Calculations
Implementer Uses:
Response to Congress
Public Information
Management Information
Intra-State Analyses
Updates to RCRIS
Universe Calculations
-------
EXHIBIT 4
BOTH IMPLEMENTERS USE RCRIS
NATIONAL OVERSIGHT
DATA BASE (NODB)
NATIONAL
MERGED
DATA BASE
(MDB)
REGIONAL
OVERSIGHT
REPORTS
[MPLEMENTER
DATA BASE (IDB)
IMPLEMENTER
DATA BASE (IDB)
STATE
REGION
-------
EXHIBIT 5
STATE IMPLEMENTER WITH NON-RCRIS SOFTWARE
(TRANSLATOR CASE)
NATIONAL OVERSIGHT
DATA BASE (NODB)
NATIONAL
MERGED
DATA BASE
(MOB)
REGIONAL
OVERSIGHT
REPORTS
Flit
File
Translator
Update
(Optional)
IMPLEMENTER
DATA BASE (IDB)
STATE
REGION
-------
EXHIBIT 6
STATE IMPLEMENTER WITHOUT AUTOMATION
(MANUAL CASE)
Completed
Forms
Data Entry
Error Reportt
RCfilS Data
Reports
NATIONAL OVERSIGHT
DATA BASE (NODB)
NATIONAL
MERGED
DATA BASE
(MDB)
REGIONAL
OVERSIGHT
STATE
IMPLEMENTER
DATA BASE (IDB)
REGION
IMPLEMENTER
DATA BASE (IDB)
STATE
REGION
------- |