United States
Environmental Protection
Agency
Office of
Water
(WH-550E)
EPA 800-F-92-003
xvEPA
Public Water
System Supervision
Information Strategy Plan
Contract No. 68-W1-0055
Delivery Order No. 012
Document No. SDC-0055-012-TB-2009
December 31, 1992
-------
United States
Environmental Protection
Agency
Office of
Water
(WH-550E)
EPA 800-F-92-003
&EPA
Public Water
System Supervision
Information Strategy Plan
Contract No. 68-W1-0055
Delivery Order No. 012
Document No. SDC-0055-012-TB-2009
December 31, 1992
-------
SDC-0055-012-TB-2009
December 31, 1992
Public Water System Supervision
Information Strategy Plan
Contents
Chapter 1 Introduction
Chapter 2 Information Architecture
Chapter 3 Business Systems Architecture
Chapter 4 Technical Architecture
Chapter 5 Analysis of Information Strategies
Appendices
A Information Engineering Methodology (IEMTJ Overview
B Current Technical Environment
C JRP Participants List
D Strategies Supported by Information Needs
E Critical Success Factors Supported by Information Needs
F Objectives Supported by Information Needs
G Information Needs and Associated Descriptions
H Entity Types with Descriptions
I Entity-Relationship Diagram
J Function Hierarchy Diagram with Descriptions
-------
SDC-0055-012-TB-2009
December 31, 1992
K Function Supports Organizational Unit
L Concerns with the Current Environment
M Entity Type Supported by Current Data Store
N Entity Type Satisfies Information Need
O Information Need is for Organizational Unit
P Function Supported by Current Information System
Q Current Data Store Used by Current Information Systems
R Organizational Unit Uses Current Information System
S Business Function by Entity Type Usage
T Business System by Business Function
U Data Store by Entity Type
V Business Area by Natural Data Store
W Business Area by Entity Type
X Business Area by Business System
Y Business Area by Business Function
Z System to System Category
AA Business System by User
BB Technical Architecture Working Group Participants List
CC Entity Type by User
DD Communications Feasibility Analysis
EE Data Store by User
11
-------
-------
Chapter 1
Introduction
-------
SDC-0055-OI2-TB-20(W
December 31. 1992
Introduction to this Report
The Public Water System Supervision (PWSS) Information Architecture Report, was
published in a series of four draft reports. The four reports were:
Task 2 - Draft Information Architecture Report
Task 3 - Draft Business Systems Architecture Report
Task 4 - Draft Technical Architecture Report
Task 5 - Draft Information Strategy Report
This Report. The Information Strategy Plan Final Report, integrates the four interim
reports and incorporates all EPA comments on the three reports listed above. The graphic
below depicts the stages of development of the Information Strategy Plan Final Report.
Business
Systems
Architecture
Report
Technical
Architecture
Report
Information
Architecture
Report
Information
Strategy &
Presentations
1
INFORMATION
STRATEGY
PLAN
1 CHAPTE
3
-JCHAPTI
:o
10
=F=
o
-------
SDC-0055-OI2-TB-2009
December 31, 1992
Introduction to the ISP Effort
The United States Environmental Protection Agency (EPA) Office of Ground Water and
Drinking Water (OGWDW) is responsible for the implementation of the Public Water System
Supervision (PWSS) Program. In an effort to improve the quality and utilization of PWSS
data and to assess the information needed to manage program implementation, the OGWDW
has established the PWSS Information System Modernization (ISM) Project. The PWSS
project goals are:
Provide blueprints for future PWSS ISM projects;
Provide a means to tie systems to information needs;
Improve the quality of data;
Provide for the collection of essential data required to satisfy PWSS goals and
objectives; and
Provide flexibility in responding to State and EPA needs.
In order to satisfy the project goals, a strategy has been developed to use the Information
Engineering Methodology (IEMrM) to guide development of components of the PWSS ISM
over the next few years. The first step of the IEM is the development of an Information
Strategy Plan (ISP). The ISP documents the information strategy and details the
architectures for the enterprise. The IEM'M is embodied in a computer aided software
engineering (CASE) tool known as the Texas Instruments Information Engineering Facility
(IEFrM), ^j^ waj) selected to support the analysis and development of a PWSS Information
Strategy Plan.
The Information Strategy Plan Report presents the findings of a high level analysis of the
PWSS Program policies and strategies, and the Information Architecture.developed for the
PWSS Program.
The reader should note that this plan describes the information needs and presents a
comprehensive model for State and Federal implementation of activities related to Public
Water System Supervision. This comprehensive model provides the framework for
development of information systems supporting high priority information needs and
functions. However, the specification of a function or information need does not mean that
the specific function or need will be implemented within the resulting PWSS information
systems. Some functions will continue to be supported by existing State or Federal systems;
other functions will continue to be supported by manual systems; and other functions will be
selected for implementation by the PWSS Information System Modernization, (ISM) Project.
-------
SDC-0055-OI2-TB-2009
December 31, 1992
Scope of the ISP Project
The scope of the PWSS Information Strategy Plan (ISP) is to support the development of
information systems to accomplish the mission and goals of the PWSS ISM project. This
support focuses on implementing the operational aspects of the program at the Primacy
Agency level as well as supporting National level oversight and enforcement of the program.
The implementation of the PWSS ISM project places emphasis on responding to information
needs and performing functions necessary to achieve success.
The five key products of the PWSS ISP
are shown on the right. This report
documents the results of the analysis of
strategies and policies and presents the
Information Architecture. Appendix A
provides an overview of the Information
Engineering Methodology (IEMIM) used to
develop the ISP. Appendix B presents an
analysis of the current technical
environment.
Goal of the ISP Project
Analysis of Business Strategies and
Policies
Information Architecture
Business Systems Architecture
Technical Architecture
Analysis of Information Strategies
ISP Key Products
The goal of the PWSS ISP project is to
provide a framework for systems development and to develop an Information Strategy to
satisfy program needs.
The following strategies support this broad project goal:
Develop the preliminary information architecture based on analysis of the business
strategies and policies,
Verify and prioritize the information needs required to achieve the business strategy,
Define the Information Architecture, Business Systems Architecture, and Technical
Architecture, and
Develop an Information Strategy to implement the architectures
-------
SDC-0055-OI2-TB-2009
December 31. 1992
Public Water System Supervision
(PWSS) Program Background
The EPA Office of Ground Water and Drinking Water (OGWDW) is responsible for the
implementation of the PWSS program established under the auspices of the Safe Drinking
Water Act (SDWA). Two of OGWDW's major responsibilities under the SDWA are to set
National standards for drinking water quality and to ensure that the States that have been
delegated primary enforcement responsibility (primacy) are complying with these standards.
Primacy Agencies use a variety of state developed and maintained data systems and
periodically report a subset of their inventories and exceptional events to EPA regional
offices. The EPA regions are responsible for assuring that all the required primacy agency
data are entered into OGWDW's national information system, the Federal Reporting Data
System (FRDS). The flow of data into FRDS is graphically depicted below.
MoraionnglJ^
BT j
HQ
FRDS
Keoon.
I EPA
i REGION
STATE
An.jlyi.cjt KfsulU
PWS
LAB
An.iiyU<..il
-------
SDC-0055-OI2-TB-2000
December 31. 1992
Today, the FRDS database and computer system continues to support most of OGWDW'b
management and oversight requirements. However, increased demands are being placed
upon it as a result of the 1986 amendments to the SDWA, and the new regulations (e.g.,
Surface Water Treatment Rule, Lead and Copper Rule) that have recently been promulgated.
The burden placed upon State data management systems has become increasingly onerous as
States attempt to incorporate all these new rules into their systems during a time of
significant fiscal difficulties.
OGWDW recently produced a Mission Needs Analysis (MNA) to re-evaluate the
management information requirements for EPA's management of the PWSS program. The
results of that effort, coupled with priority changes of OGWDW's senior management, have
necessitated a re-evaluation of OGWDW's entire information management philosophy for the
PWSS program.
The MNA recommended the design and implementation of a national system. The
primary portion, would be operated from EPA's National Computer Center (NCC), but
would be flexible enough to accommodate states' varying requirements. This would enable
EPA to address some of the most important data quality, timeliness, and completeness
problems by working closely with the states. This would also enable EPA regional office
access to better use of drinking water information.
Mission and Membership
The mission of the Public Water System Supervision Program is to provide an adequate
quantity of safe drinking water. The program is comprised of States, U.S. territories, and
Indian tribes. Currently 49 States have primacy; Wyoming and the District of Columbia do
not have primacy. US territories and Indian tribes also do not currently have primacy.
The high level PWSS program organizational structure is represented by the following
diagram.
-------
SDC-0055-012-TB-2009
December 31, 1992
1
OGWDW
PWSS
i
EPA ORD
!
! STATE DW
| ADMINISTRATOR
:^^^^^^_
1 _
EPA 1
REGION |
< STATE. REGION.
OR DISTRICT DW
> ADMINISTRATOR
i PUBLIC
WATER
SYSTEM
I
ISP Participants
One executive interview and two Joint Requirements Planning (JRP) sessions were conducted
during the information gathering process for this ISP. During the course of these sessions,
approximately 43 subject matter experts representing 27 organizations have provided input.
A listing of individual participants is contained in Appendix C. Organizations that have
directly participated in this effort are listed below.
Alaska Environmental Conservation
Arizona Department of Environmental Quality
California DOHG, ODW
Georgia EPA
Illinois EPA
Kansas DHE
Kentucky NREPC
Marasco Newton Group, LTD
Missouri Department of Natural Resources
Nonh Carolina Public Water Supply
OGWDW/TSD/Cincinnati
Oregon Health Division
Pennsylvania Department of Environmental Resources
South Carolina DHEC
Utah Department of Environmental Quality
Virginia Department of Health
Washington State Department of Health
-------
SDC-0055-OI2-TB-2009
December 31. 1992
US EPA Headquarters (OGWDW)
US EPA Region I
US EPA Region III
US EPA Region IV
US EPA Region V
US EPA Region VI
US EPA Region VII
US EPA Region VIII
US EPA Region IX
US EPA Region X
Washington EPA
-------
SDC-0055-012-TB-2009
December 31. 1992
This page intentionally left blank.
-------
-------
Chapter 2
Information Architecture
-------
SDC-0055-012-TB-2009
December 31, 1992
Analysis of Strategies and Policies
The first step in laying the foundation for an information architecture is to understand the
approach of the Public Water System Supervision (PWSS) Program to meeting its business
goals. Analyses of strategies and policies focuses on the identification of the mission, goals,
and objectives of the PWSS Program as well as on critical success factors that inhibit or
facilitate achieving goals.
Inputs to this analysis included reviews of existing documentation (e.g., Mission Needs
Analysis), discussions with subject matter experts, interview results, and two Joint
Requirements Planning (JRP) Sessions conducted with middle- and first-line managers within
the program. Information from each source was compiled, assessed, and documented using
the IEF tool.
Organizational Unit
In deploying the strategy, the ISP Project Team considered the following representative
organizational units:
Office of Ground Water Drinking Water (OGWDW)
EPA Office of Research and Development (EPA ORD)
EPA Regions
State Drinking Water Administrators
State Region or District Drinking Water Administrators
Public Water System (PWS)
PWSS Program Strategy Statement
The mission, goals, and strategies for the PWSS Program have been developed and refined
through the planning process. The mission and goals defined for the program in the Mission
Needs Analysis were the basis for the initial strategy statement and served as a departure
point for facilitating discussions during executive interviews, consultations with subject
matter experts, and the Joint Requirements Planning Sessions. The PWSS strategy
statement, which appears on the following page, is the final product of the analysis of
-------
SDC-0055-012-TB-2009
December 31, 1992
MISSION *
To provide an adequate supply of
safe drinking water
GOALS
Supply: Ensure an adequate quantity of drinking water by the
regulated community.
Quality: Reduce/eliminate public health nsk by identifying, assessing.
and responding to threats to water supplies in a timely manner.
Compliance: Identify, assess, prioritize and appropriately respond to
non-compliance in a timely manner
AffordabPtty: Improve affordabibty by Increasing the effectiveness and
reducing the cost of applying technology (e.g. treatment, data/sample
collection and analysis, and information analysis).
Outreach: Improve the effectiveness of technical assistance, training.
and public education.
STRATEGIES
Operational Effectiveness: Promote primacy delegation, compliance
determination, water-quality assurance and allocation through: assessment
of water systems and threats: technology assistance: consolidation and
standardization; and Improvement of regulations.
Information Gathering: Collect and analyze the base line data needed to
improve primary and support activities of the program (e.g. PWS inventory.
supply characterizations, scientific research findings, lab characterizations).
Technology: Discover, assess, develop, and demonstrate new tools and
techniques to Improve the operation and administration of the program.
Funding: Fight for adequate budget for regulating and regulated communities
and develop alternate sources of funding (e.g. usage fees, surcharges.
technical grants, demonstration grants).
Marketing: Further the understanding of solutions to drinking water problems
by enlisting support from regions, states. PWSs. and the public.
Coordination: Coordinate efforts among agencies and drinking water
programs to improve program efficiency.
Developed by State and EPA Representatives attendng PWSS JRPs.
-------
SDC-0055-012-TB-2009
December 31, 1992
strategies and policies. The sections following the PWSS strategy statement will discuss the
components of the statement in further detail.
Results of the information gathering activities were captured in the IEF tool and
matrices were developed to document the interaction of the program strategy objects.
PWSS Goals and Objectives
PWSS goals describe the long-term results that must be achieved to accomplish a mission.
Each goal has been further refined into shorter term objectives which must be satisfied to
achieve the goal. This section presents each goal and the objectives that support it.
Supply: Ensure an adequate quantity of drinking water by the regulated community.
Characterize source water supply including alternate sources.
Ensure adequate distribution of water to consumers on demand. Consider consumer
demographics.
Ensure water is properly treated before it is provided to consumers.
Quality: Reduce/eliminate public health risk by identifying, assessing, and responding to
threats to water supplies in a timely manner.
Ensure PWSSs are compliant with other EPA/State environmental regulations (e.g.,
discharge of treatment waste and air discharges).
Ensure all supplies are evaluated for potential risk.
Perform studies and analyses to support development of regulations and standards.
Eliminate/reduce risks to consumers (immediately) by identifying and assessing all
threats and take action to prevent threats (e.g., well head protection and coordination
with other program permitting activities).
Effectively respond to threats in time to protect the public health and to meet public
notification requirements.
Compliance: Identify, assess, prioritize and appropriately respond to non-compliance in a
timely manner.
11
-------
SDC-0055-012-TB-2009
December 31, 1992
Bring systems into compliance by addressing violations within appropriate
timeframes. Addressing violations includes technical assistance and enforcement.
Develop complete and accurate monitoring plans for all systems.
Ensure compliance data is timely, reliable, complete, and accurate. Includes lab
certification.
Identify 100% of violations (State and Federal) within prescribed timeframes (PWS
and regulators). Note that timeframes will vary (e.g., whether the violation is acute
or chronic, reporting to State vs. reporting to Federal, reporting agency (PWS, lab,
regulator), etc.).
Improve accuracy of data relating to the implementation of the PWSS program.
Includes reducing duplication of data.
Encourage/mandate the direct reporting of analytical results by electronic means
(EDI) by certified laboratories to State regulators.
Improve the sharing of data with other programs and agencies, with the public, and
within the PWSS program, including providing for reasonable access/authority.
Includes establishing protection for data from unauthorized access or modification.
Maintain a complete and accurate inventory of all PWSs.
Reduce impact of new regulations on the regulating and regulated community.
Provide opportunity for input by States and PWSs earlier in the regulation
development process (e.g., review of strawman regulations, considering impacts on
other environmental regulations, minimize reporting requirements, regulation
development workgroups, assess and consider data management impacts, development
of flow diagrams in parallel with regulation development, etc.)
Take actions to simplify the implementation of the drinking water program and
determining if PWSs are compliant. Could include improving user documentation and
system interfaces, providing clearinghouse for information relating to drinking water.
Also, includes model state regulations, guidance on implementation, regulation/rule
interpretation. May also include providing for regional variations or redefining rules.
Affordability: Improve affordability by increasing the effectiveness and reducing the cost
of applying technology (e.g., treatment, data/sample collection and analysis, and
information analysis).
12
-------
SDC-0055-012-TB-2009
December 31, 1992
Conduct field demonstrations and pilot studies to prove field performance of new
technologies and distribute results throughout the community.
Encourage technology transfer among States, Federal agencies, consulting engineers,
manufacturers, laboratories, and utilities.
Identify and coordinate the use of resources for research and development of new
technologies.
Improve usability/flexibility of automation supporting PWSS program
implementation. Includes efforts to standardize/integrate data and procedures.
Provide States and EPA with improved data management capabilities beginning in FY
1995.
Promote application of emerging and existing technology including reduction of
treatment waste.
Outreach: Improve the effectiveness of technical assistance, training, and public
education.
Facilitate/encourage development of materials at Federal level suitable for adoption by
States. Also includes items such as data management standards and lab automation
standards.
Improve communications within the regulating and regulated communities.
Provide effective emergency notification (warning) concerning contamination and
posed risk so that the public can protect themselves.
Involvement of community and industry groups to further the implementation of goals
of the public water supply program. Establishes the value and appreciation of
drinking water and support for building/improving State capacity.
Provide education so that the public will be willing to protect themselves, pay for
needed improvements of PWSs, and support regulation of PWSs.
Provide adequate technical assistance to regulators, regulated communities, and PWS
engineering activities to ensure the proper design and operation of PWSs and
implementation of NPDWRs and State regulations.
13
-------
SDC-0055-012-TB-2009
December 31, 1992
Strategies
A strategy is an approach, planned or in place, to achieve a goal. A strategy states the
"how" of the approach being considered/used.
During the JRP sessions 37 strategies were identified. These strategies were analyzed
and categorized into the six high level groupings listed in the PWSS Program Strategy
Statement. Below is a listing of each high level groupings and the identified strategies for it.
The supported goal(s) are shown in parenthesis.
Strategies to improve Operational Effectiveness include:
Use enforcement as needed to return systems to compliance. (Compliance)
Establish a data management program to improve the quality of data management
relating to PWS supervision, including efficiency, effectiveness, analysis, accuracy,
timeliness, and ease of reporting. (Compliance, Qualilty)
Implement water allocation and administer water rights as required to control demand.
(Supply)
Establish and maintain the primacy program. (Compliance, Outreach, Supply,
Quality)
Perform trend analysis of violations, analytical results, disease outbreaks, health
assessments, and sanitary surveys to assess the effectiveness of the drinking water
program. (Compliance, Quality, Supply)
Promote and provide technical assistance for engineering design for PWSs. Includes
working with design engineers, including coordination meetings, and preliminary
review of designs. (Affordablity, Compliance, Outreach, Supply)
Promote economies of scale with respect to operation and management of small
PWSs, including mergers and annexations. Includes centralized management,
composite sampling, centralized billing, master planning, and consolidated operations
and maintenance. (Affordability, Compliance)
Promote the security of PWSs, including source protection, system protection, and
distribution protection. Includes physical security. (Quality, Supply)
Promote uniform standards at the state level. (Compliance, Quality)
14
-------
SDC-0055-012-TB-2009
December 31, 1992
Provide financial and technical assistance for treatment to correct deficiencies and to
improve capacity. (Affordability, Outreach, Supply)
Reduce the burden of program implementation. (Affordability)
Review the financial viability of PWSs to ensure that they can adequately supply the
public. (Affordability, Supply)
Simplify regulations and develop regulations in response to increase knowledge of
risks caused by specific contaminants. (Compliance, Outreach)
Strategies to facilitate Information Gathering include:
Identify and characterize existing, alternate, and emergency sources. (Supply)
Collect and analyze data concerning public water systems necessary to manage the
drinking water program, including information on unregulated contaminants and
analytical results for regulated contaminants below MCLs. (Compliance, Supply)
Assess PWS facility-related, source, and demand needs on a regional basis and
develop regional solutions. (Compliance, Quality, Supply)
Improve and streamline the process for alternative analysis method review and
approval. (Compliance, Outreach)
Network with other agencies to leverage their knowledge and tools, Includes
networking with and obtaining data from land, waste, air, and water resource
management agencies at federal, state, and local levels; universities and professional
associations; etc. (Outreach)
Use modeling and cost-benefit analysis to maximize return on investment.
(Affordability)
Promote use of geographical information system technology for characterization of
sources, demographics, water system facility management, potential sources of
contamination, etc. Note: may require a large front-end investment to achieve
return. (Outreach, Supply)
Obtain information about and track sources (non-point and point) of pollution and
assess impacts on drinking water. (Supply)
15
-------
SDC-0055-012-TB-2009
December 31, 1992
Strategies to improve Technology include:
Achieve economies of scale in information system development, continuing to
improve existing systems while developing the modernized PWSS program.
(Affordability)
Conduct research and development to determine how to measure water quality and to
develop technology to facilitate treatment (including desalinization), simplify analysis
and geolocation, and improve compliance assessment. (Affordability, Compliance,
Outreach)
Encourage interaction with universities and research institutions for development of
PWS related technologies. (Affordability, Outreach)
Strategies to gain Finding include:
Develop alternate sources of funding (e.g., usage fees, surcharges, technical grants,
demonstration grants). (Affordability, Compliance)
Fight for an adequate budget for the regulating and regulated communities to ensure
safe drinking water. (Affordability, Compliance)
Strategies for Marketing the PWSS Program include:
Advertise enforcement and technical assistance successes to the public and throughout
regulated and regulating communities. (Outreach)
Advertise the results of applying new and innovative technology and new applications
of existing technology throughout the regulated and regulating communities. Includes
advertising the availability of resources (products, techniques, etc.). (Outreach)
Encourage PWSs to maintain, develop, and construct adequate facilities for supply,
treatment, distribution and storage of water that will support existing, emergency, and
future demand. (Compliance, Outreach, Supply)
Encourage policies, standards, and building codes which allow use of new technology.
(Affordabilty, Outreach)
Encourage the establishment of permitting programs for PWSs. (Compliance)
16
-------
SDC-0055-012-TB-2009
December 31, 1992
Promote conservation of water use by the public. Includes promoting reuse of non-
potable water, when appropriate. (Outreach)
Promote membership and participating in professional associations (e.g., AWWA,
ASDWA). (Outreach)
Promote public education about drinking water quality and safety. (Outreach)
Strategies for Coordination of efforts among Agencies include:
Conduct cross-program coordination with other agencies involved in environmental
regulation and land-use planning, promote sharing of information, and assess the
impact of land use planning, promote sharing of information, and assess the impact of
land use and air, waste, and water pollution on supply. (Compliance, Outreach,
Quality)
Promote prevention of contamination through coordination with community and land-
use planning and implementation of source and distribution protection programs.
Includes cross-connection control, wellhead protection, watershed protection,
backfiow prevention. (Compliance, Outreach, Quality, Supply)
Provide timely communication throughout the regulated and regulating community.
Includes communication between PWSs and consumers (compliance status, sources,
prevention, comparative risk, conservation, etc.); between the regulating community
and consumers (town meetings); between states and local regulators and PWSs (e.g.,
through newsletters and bulletin boards); and between EPA and states. (Compliance,
Outreach)
Critical Success Factors
A critical success factor (CSF) is a situation or event that cause success (a facilitator) or
failure (an inhibitor) in reaching a goal or objective. It is often, but not always, outside the
control of the manager or organization but is generally something of which the manager
needs to be aware.
Eighteen critical success factors have been identified. Each critical success factor is
classified as an inhibitor or a facilitator. The following two lists list inhibitors and
facilitators respectively. Supported goals are shown in parenthesis.
17
-------
SDC-0055-012-TB-2009
December 31, 1992
Inhibitors
Inadequate quantity or quality of source water. (Quality, Supply)
High level of complexity of federal and state statues and regulations relating to drinking
water. (Compliance)
Adverse weather resulting in increased storm runoffs or droughts. (Quality, Supply)
Turnover of personnel. (Quality, Supply)
Economic situtation/stability.
Inability or difficulty in acquiring loans, grants, increased fees or other financial
assistance.
Facilitators
High level of third party support for the drinking water program (e.g., consumer
education and technical dialogue by professional associations). (Outreach)
Ready availability of hydrological, toxicity, and risk assessment data within data systems.
(Compliance)
Ready availability and affordability of analytical, prevention, and remediation technology
supporting the drinking water program. (Affordability)
Increases in development of industry and population. (Quality, Supply)
Increased threats from terrorists or from geologic activity. (Quality, Supply)
Support by the legislative and executive branches of State and Federal government,
evidenced by their understanding and competent support of water quality issues.
(Compliance, Outreach)
Ready availability of mapping data (e.g., river reach Mies) within automated systems.
(Supply)
Increases in point and non-point source contamination. (Quality)
Public awareness of issues relating to health impacts of drinking water. (Outreach)
18
-------
SDC-0055-012-TB-2009
December 31. 1992
Public interest in conservation. (Outreach)
Thorough coordination of research and regulatory development activities among State and
Federal agencies. (Affordability)
Existence of State and local construction standards which favorably consider drinking
water issues. (Affordability, Quality, Supply)
Ready availability of water system engineering data within automated systems.
(Compliance, Quality, Supply)
19
-------
SDC-0055-012-TB-2009
December 31, 1992
Information Needs
This subsection focuses on the information needs and how they are interrelated to the entities
types and organizational units.
Developing Information Needs
An information need is a specific information requirement of a particular person or
organizational unit that can be used to make decisions or complete a task. Information needs
helps to:
Evaluate a strategy,
Detect the occurrence/non-occurrence of critical success factors, and
Measure progress toward meeting an objective or goal.
The information need is the link to ensunng that system development projects are tied to
the specific business requirements. An alphabetical listing of the 76 information needs and
their definitions are in Appendix G. Matrices associating information needs with strategies,
critical success factors, objectives, and organizational units are found in Appendices 0, E, F,
and J respectively.
Information needs are determined based on the mission, goals, strategies, objectives, and
critical success factors as shown on the next page.
Information Needs by Entity Type
Appendix N identifies the information need with the entity type in which the supporting data
is stored. This exercise veifies theat all information needs are supported by one or more
entity types.
Information Needs by Organizational Unit
Appendix O shows what information needs are required by which organizational unit. This
exercise assists in identifying which information need is shared by what organizational unit
and ensures that all the information needs are needed by one or more organizational units.
20
-------
SDC-0055-012-TB-2009
December 31, 1992
Mission
Goals
Critical
Success
Factors
Information
Needs
Strategies
21
-------
SDC-0055-012-TB-2009
December 31, 1992
Information Architecture Components
The PWSS information architecture defines the activities performed by the organization and
the informationed needed to perform the activities. The information architecture consists of
several components, which are referred to as business objects. These objects are captured in
the IEF tool as the PWSS model presents these objects in a graphical form to facilitate
understanding and support analysis. The major high-level components that make up the
preliminary information architecture for PWSS include:
Entity types,
Subject areas,
Relationships,
Major business functions, and
Matrices.
The subsequent paragraphs discuss each of these components. Data analysis and activity
analysis, done concurrently, are the principal analytical activities that bring the components
together to form the information architecture for PWSS.
Entity Types
An entity type is a fundamental thing of relevance to the PWSS Program about which data
may be kept. Examples of this data include:
inventory information,
violation, and
enforcement action taken against a PWS.
The PWSS project team identified entity types using two methods. Entity types were
developed by analyzing written documentation related to the PWSS Program, and by
analyzing the information needs.
Appendix H contains a description for each entity type in the PWSS Program.
22
-------
SDC-0055-012-TB-2009
December 31, 1992
Subject Areas
As the entity types were identified, they were categorized into high level subject areas. The
resulting subject areas represent a collections of related entity types. Each subject area is
named using a plural noun and entity types are named using a singular noun. This naming
convention assists the analyst by distinguishing the names of data related objects.
For PWSS, eight subject areas were identified as follows:
Compliances: Information supporting compliance determination. Used to evaluate
program implementation, oversight, violations, and actions required to return PWS's
to compliance.
Controlling Instruments: Information concerning statutes, regulations, policies,
guidance, agreements, standards, and schedules for regulatory implementation.
Cross-Media Sources: Data gathered by other environmental and natural resources
programs required to support implementation of the PWSS program.
Inventories: Information concerning the inventory of PWS's, water sources, and
populations served by PWS's.
Legal Entities: Information describing the legal entities involved with the PWSS
program, including Government and Non-Government Agencies and private citizens.
Programs and Plans: Environmental Programs and implementing plans impacting the
PWSS program.
Samples: Information associated with the collection and analysis of water samples
taken to evaluate the quality of drinking water or the efficacy of treatment or analysis
techniques.
Technologies: Information related to the technologies required to treat water, assess
water quality, or analyze data relating to the PWSS program implementation.
Relationships
One of the primary analysis tools used during an information engineering systems
development process is the Entity Relationship Diagram (ERD). The principal purpose of
the ERD is to graphically illustrate the information of interest to an organization and to
23
-------
SDC-0055-012-TB-2009
December 31, 1992
identify the relationships among data. These relationships reflect the business rules
associated with the PWSS Program.
The ERD is made up of three parts: entity types, subject areas, and relationships.
Relationships characterize the business reasons for associating different entity types. A
relationship is shown by drawing a line between two entity types, and is labeled to express
the relationship as shown below:
SAMPLE
Contains
\s Contained In
CONTAMINANT
The relationship in the above diagram is read as follows:
A Contaminant "is contained in zero or more" Samples (reading right to left), and a
Sample "contains zero or more" Contaminants (reading left to right).
The following diagram is a high level ERD which is also known as a subject area
diagram. Appendix I presents the fully expanded ERD for the PWSS Program.
24
-------
SDC-0055-012-TB-2009
December 31, 1992
Major Business Functions
The PWSS functional model provides a high level picture of the activities performed by
organizations supervising public water systems. A high level function is a grouping of
related business activities, which may be performed at varying levels of an organization or in
completely different organizations. Inherent within each function are the coordinating,
supervising, managing and reporting activities common to any area within an organization.
The business functions are depicted graphically in an hierarchical decomposition called a
Function Hierarchy Diagram (FHD), which breaks principal functions down into more
detailed subfunctions. Specifics and details about each function and subfunction are shown in
Appendix J.
The following FHD represents the derived high-level breakdown of activities performed
within the PWSS Program.
25
-------
SDC-0055-012-TB-2009
December 31, 1992
iPUBl
C HA.TE8 STSTEH SUPCTVISIOM
PMBUM AflHlllISTMTiai
pumme
BIST
-------
SDC-0055-012-TB-2009
December 31, 1992
The sixteen PWSS high level functions depicted in the previous diagram include:
Program Administration: Rule and Regulation Development; Resource Management;
Implementation Planning; Primacy Administration; Guidance Provision (seep-Apt);
Grant and Loan Administration; and Implementation Support.
Water Resource Planning: Supply Forecasting; Demand Forecasting; Geographic
Area Analysis; Fund Need Forecasting; Source Protection; Contingency Planning;
Allocation; and Conservation Actions.
Risk and Vulnerability Assessment: Risk Determination; Vulnerability Analysis;
Health Advisory Development; and Cross Connection Control.
Technology and Methods: Technology Assessment; Periodic Survey Performance;
Applications and Methods Development; and Standard Development.
Data Management: State and Federal Interface Guidance; Information Systems
Development; Information Systems Maintenance; Request for Information Response;
Cross Program Coordination; and Data Analysis and Interpretation.
Lab Capacity and Certification: Lab Site Reviews; Lab Personnel Qualification; Lab
Capability/Capacity Assessment; Lab Quality Assurance/Quality Control Plan
Evaluation; and Lab Certification.
Operator Certification: Operator Tracking; Operator Classification; Operator Exam
Administration; and Operator Certificate Issuance.
Engineering Plan Review: Construction Standards Development; Engineering Plan
Evaluation; Engineering Financial Assistance; and Construction Inspection.
Field Surveillance: Sanitary Survey Scheduling; Sanitary Survey Performance;
Inspection and Site Visits; and Survey and Inspection Follow up.
Disease Outbreak and Surveillance: Outbreak Analysis and Recommendation;
Epidemiology and Public Health Coordination; and Public Notification.
Compliance Determination and Resolution: Inventory; Waiver and Exception
Administration; Permit Issuance; Monitoring Plan Development; and Monitoring
Performance Assessment.
27
-------
SDC-0055-012-TB-2009
December 31, 1992
Technical Assistance: Technical Assistance Needs Assessment; Third Party
Coordination; and Technical Support Provision.
Enforcement: Enforcement Policy Development; Enforcement Case Development;
and Enforcement Tracking.
Emergency Response: Emergency Plan Implementation; Emergency Response
Assistance; and Response Coordination.
Training: Training Needs Identification; Training Development; Training
Presentation; and Training Records Maintenance.
Outreach: Outreach Material Development, Networking, Risk Communication; and
Public Education.
Mapping of Business Functions and Organizational Units
The business functions identified during functional decomposition are related to
organizational units in order to improve the general understanding of the organization's
current strategies, to verify the functional decomposition, and to provide a basis for a more
in-depth assessment of the organization later on in the analysis.
The business functions are mapped to the appropriate organizational units using the
Business Function/Organization matrix which appears in Appendix K of this document.
Business Requirements
Introduction
This section briefly describes the business requirements of the PWSS project and transition
from the Information Architecture to the Business Systems Architecture. These two products
of the ISP differ in that the Information Architecture defines the activities performed by the
organization and the information required to perform them, while the Business Systems
Architecture describes probable business systems and data stores required to support the
Information Architecture.
Although a more detailed understanding of the actual information requirements is needed
to determine the exact contents of each business system, the Business Systems Architecture
provides a high-level initial prediction of the application systems to be developed. This
28
-------
SDC-0055-012-TB-2009
December 31, 1992
section begins the examination of the Business Systems Architecture, although the actual
Business Systems Architecture will be presented in the next chapter. A full list of the issues
and concerns affecting the PWSS ISP project is presented as Appendix L.
Current Business Problems
Several major business problems and opportunities for improvement have been identified by
the documentation reviews, consultations with subject area experts, executive interviews and
Joint Requirements Planning sessions conducted during this phase of the ISP. Business
problems and design considerations fall into several categories. These are:
State apprehensions about national systems and their ability to satisfy State
requirements
Differing goals and objectives between State and National programs
Constantly changing legislation/rules that put an ever increasing development burden
on the States, Labs and Public Water Systems.
Declining resources (e.g., personnel, funding, etc.)
There are issues and concerns associated with each of these broad categories. In the area
of State apprehensions, some of the issues and concerns are:
Lack of State input and involvement in Federal systems development, and
Lack of understanding of the purposes for Federally desired information.
Constantly changing rules and regulations and increasing State burdens are reflected in
such concerns as:
Lack of State participation (and opportunities for participation) in the rule and
regulation development process,
The need to provide a stronger correlation between rule development and data
management, and
The need to redesign regulations and reduce the number of violation types.
The problem of differing goals and objectives between State and National programs is
shown in issues like:
29
-------
SDC-0055-012-TB-2009
December 31, 1992
The need for a new system that has capabilities beyond compliance and enforcement,
Ensuring that development plans span other environmental areas (e.g., provide
integration amongst all data, such as Superfund, Clean Water Act, and CIS), and
Understanding the need to reduce the reporting burden on the States, Labs and Public
Water Sytems.
In an age of declining resources, issues and concerns reflecting the need for a system to
provide help in this area are:
The need to reduce repetitive data entry and paper,
Better management of system development, maintenance, and enhancement costs,
Ensuring that State variants to the new system are easy to develop, and
Providing easier and quicker access to regulations and rules (e.g., Reg-in-a-box, etc.).
Business problems and areas for improvement need to be handled in two ways. Those
that can be addressed by changes in the information systems that support the PWSS program
can be corrected by systems development. Some issues can only be addressed by changes to
EPA policy.
System Difficulties
In addition to business problems and opportunities for improvement in the non-automated
areas of the investigation, major difficulties with the current automated systems used to
support the PWSS program were also identified. These problems fell into the three major
areas below:
Current systems contained data of marginal quality and lacked timeliness,
The analytical tools possessed by the current systems were in need of improvement,
and
The current systems were housed on aging and soon-to-be unsupported software.
Data quality and timeliness was the most pressing problem and the need to address this
issue is reflected in concerns such as:
30
-------
SDC-0055-012-TB-2009
December 31, 1992
The need to improve reliability by ensuring consistency of process and data,
Ensuring the improvement of timeliness and accuracy of data collection by
incorporating such techniques as Electronic Data Interchange (EDI),
The need to provide user-friendly interfaces (i.e., Graphical User Interface (GUI)),
and
Providing the capability for decision support information.
The problem of improving the analytical tools and capabilities of the current systems can
be seen in these issues and concerns expressed by the interviewees:
Data analysis must be enhanced by providing new and/or improved analysis tools
(e.g., filter rule regression analysis),
Enhancement of engineering tools for process monitoring and control are needed,
The system needs to provide meaningful statistical data,
A means of easily verifying correcting and analyzingdata must be supplied, and
Providing the capability for use of and ready access to inventory data.
The fact that the current systems for PWSS support are contained on aging software and
need to be migrated is expressed in concerns such as:
Any new system must improve response time,
There is a need to reduce sampling and analysis costs,
State and National formats must be compatible, and
The ability to easily modify existing databases to handle additional kinds of
information is required.
These concerns and issues helped to document the areas that need improvement for any
new PWSS system. The information needs that must be addressed by the new system are
shown in the Appendix G.
31
-------
SDC-0055-012-TB-2009
December 31, 1992
This page intentionally left blank.
32
-------
-------
Chapter 3
Business Systems Architecture
-------
SDC-0055-012-TB-2009
December 31, 1992
Business Systems Architecture
The Business Systems Architecture describes the business systems and data stores required to
implement the Information Architecture presented in Chapter 2. Business systems are
collections of related functions required to accomplish an aspect of the PWSS program. Data
stores are collections of related information required by or produced by the business systems.
Additionally, the Business System Architecture describes the relationships among the
business systems and data stores, and groups business systems and data stores into business
areas for follow-up analysis.
As a result of the development of the Business Systems Architecture, a ranked list of
Business Areas was developed, prioritizing the information systems required to support the
requirements of the PWSS Information Systems Modernization effort.
The following describes the five step approach used to develop the Business System
Architecture:
Interaction Analysis
The interaction between the data and functions is examined. The analyst determines
which functions create, update, delete, or read each entity type. This analysis
highlight and explain the dependencies and interactions among each function and
entity type.
Business Systems Analysis
Once the dependencies and interactions are understood, the analyst identifies
collections of related functions that use the same types of information. These
groupings of related functions are called business systems.
Data Stores Analysis
At the same time the business systems are being identified, the analyst is reviewing
the data interactions in order to group entity types used by each business system into
data stores.
33
-------
SDC-0055-012-TB-2009
December 31, 1992
Business Systems Architecture Analysis
The business systems are grouped into business areas and categorized. The data
flows and functional dependencies are also diagrammed to ensure that the business
systems will support the Information Architecture.
Business Area Evaluation
Once the Business Systems Architecture is completed, the individual business areas
are ranked to support development of an implementation strategy.
The results of the analysis will now be presented in more detail following the five steps
outlined above.
Interaction Analysis
The primary analytical tool for interaction analysis is a matrix that maps the business
functions to the entity types. This matrix is commonly referred to as the "CRUD" Matrix
because it designates which functions Create (C), Read (R), Update (U), or Delete (D) each
entity type. A copy of the Business Function by Entity Type Usage matrix is included in
Appendix S.
Solving the CRUD matrix involves documenting the expected actions that the functions
will have on the data. The functions of the organization are listed on the vertical axis of the
matrix and are entered in dependency order. For example, the function of Monitoring Plan
Development is shown before the function of Water Sampling as Monitoring Plan
Development should be completed before Water Sampling is performed. As the analysis of
the interaction between the functions and data continues, all data created by specific functions
(depicted with a "C" at the intersection of the rows and columns) are grouped together within
the matrix. The Cs are arranged along a diagonal path in the matrix. Next, the Us and Rs
are arranged to align as closely with the diagonal as possible. This process results in
showing the closeness (affinity) of the entity types with their associated functions. Due to
the high number of read events, Rs are not displayed in the CRUD matrix shown in
Appendix S. Additionally, deletes were excluded from the matrix at this time, as deletes will
be identified later during the Business Area Analysis (BAA) phase of PWSS systems
development.
34
-------
SDC-0055-012-TB-2009
December 31, 1992
Business Systems Analysis
Using knowledge derived from analysis of the CRUD Matrix, the project team conducted
Business Systems Analysis for the PWSS program. This analysis developed natural business
systems, or logical groupings of business functions, that satisfy the business needs identified
in the Information Architecture Phase.
Business systems are groupings of one or more of the functions identified in the
Information Architecture. The functions are grouped using affinity analysis algorithms and
clustering techniques built into the IEF development tool. A total of 29 business systems
were identified.
Names for the business systems were selected to represent the functional groups, using
terms consistent with the technical vocabulary of PWSS community. For example, the
"Compliance Determination" Business System is comprised of a group of business functions
that perform the following functions: analyze and assess samples; conduct inspections and
audit reviews; and perform other monitoring activities to determine whether or not a PWS is
complying with the appropriate rules and regulations. Another example is the
"Enforcement" Business System, which includes functions for developing legal and
administrative cases, taking enforcement actions, and tracking enforcement actions.
A Business System by Business Function Matrix, shown in Appendix T, was also
prepared. This matrix relates the business systems with the business functions identified in
the Information Architecture. This process ensures that all business functions identified in
the Information Architecture are accounted for in the Business System Architecture.
Data Stores Analysis
As the business systems were being identified, the data interactions were reviewed in order
to group entity types used by each business system into natural data stores (we will use the
term data stores to refer to the natural data stores).
Data stores represent collections of data needed to support the business systems that have
been identified. The approach for determining data stores is similar to the one employed to
determine the natural business systems. The CRUD Matrix was analyzed to determine the
affinity among entity types. The analysis first clusters entity types used by each function and
then determines which entity types should be grouped within a data store.
A total of 17 data stores were identified. The data stores were named based on the entity
types contained within the data store. For instance, the "Agencies" natural data store is
35
-------
SDC-0055-012-TB-2009
December 31, 1992
composed of two entity types: Government Agency and Non-Government Agency or
Company. The data store was named "Agencies" since both entity types are agencies.
Another example of naming a data store is the "Financial Assistance" data store, which
consists of three entity types: Budget, Grant, and Guaranteed Loan. The name "Financial
Assistance" was selected as all of the entity types in this group involve financial assistance
functions.
A Data Store by Entity Type matrix was also completed to ensure that all entity types
described in the Information Architecture were contained within a data store. A copy of the
Data Store by Entity Type Matrix is shown at Appendix U.
Business Systems Architecture Analysis
Once business systems and data stores have been identified, the business systems are grouped
into business areas. Business areas result from grouping the related business systems and
data stores. A business area can be thought of as a collection of business functions and
entity types that defines the scope of a component of the PWSS Program. The sum of all the
Business Areas completely defines the scope of the PWSS Program. The business areas are
assigned names that best convey the overall meaning of the collection of systems a given area
encompasses.
For instance, the "Compliance" Business Area deals with the group of Business Systems
designed to monitor individual PWS and state program performance, build cases against
violators and non-compliers, take enforcement actions, and track enforcement actions.
Another example is the "Inventory" Business Area, which involves characterizing public
water systems, and inventoring natural resources and demograqhic statistics.
Four matrices were created during the Business System Architecture analysis. The first
matrix, Business Area by Natural Data Store, shown in Appendix V maps the Business Areas
to the data stores identified in the entity type by business function analysis. The second
matrix, Business Area by Entity Type, appears in Appendix W, compares the Business Areas
to the entity types identified during the Information Architecture phase analysis of Task 2.
The third matrix, Business Area by Business System, shown in Appendix X, contrasts the
natural business areas with the natural business systems that were derived from the business
function by Entity Type Matrix analysis. The fourth matrix, Business Areas by Business
Function, Appendix Y, illustrates how the business functions identified in the Information
Architecture map to the business areas identified in the Business System Architecture. The
main purpose for conducting this part of the analysis and preparing these matrices are to
ensure that all of the functional activities of the business identified in the Information
Architecture were transitioned to the Business System Architecture.
36
-------
SDC-0055-012-TB-2009
December 31, 1992
Once the business areas are identified, they are categorized as Strategic Systems,
Planning Systems, Controlling Systems, or Operational Systems. Note that it is common for
a system to be placed in more than one category. The definitions for the categories are
shown below.
Strategic - focuses on a wide-range of "what-if1 analysis and is
referred to as the PWSS Executive Information System.
Planning - deals with a structured framework to conduct "what-if'
analysis with a high concentration of statistical analysis.
Controlling - involves monitoring and managing operational aspects
of PWSS with emphasis on routine analysis and reporting.
Operational - supports high volume, time-critical day-to-day
operational features of the PWSS, most of which are pre-defined on-
line transactions.
System Categories
After the business areas were categorized, a business system architecture diagram was
developed showing the interrelationships of all of the business systems. The PWSS Business
System Architecture Diagram, shown on the following page, is a graphical representation of
the analysis.
The functions listed across top horizontal axis of the diagram represent the 16 high level
functions identified in the Information Systems Architecture. Note that the business systems
identified in the Business System Architecture Diagram support one or more of the PWSS
program system categories. For instance, the "Regulations Development" Business System
only supports the Strategic system level. On the other hand, the "Forecasting" Business
System supports both the Strategic and Planning system levels. Another example involves
the "Coordination" Business System that spans across all four levels of the system
categories. The interaction between the Business Systems is shown graphically by the lines
and arrows connecting one system to another.
37
-------
00
Business System Architecture Diagram
n
6
to
rSJ
-------
SDC-0055-012-TB-2009
December 31, 1992
In support of this analysis, the PWSS project team prepared a System to System Category
Matrix as shown in Appendix Z. This matrix shows the interrelations of PWSS system
categories to the natural business systems identified in the PWSS Business System
Architecture presented in this chapter. The System to System matrix serves as a valuable
tool in visualizing which business systems support the various system level requirements.
/
Another way of depicting the Business System Architecture is shown on the following
fold out page. The diagram displays the business systems within each business area and the
related data stores. Significant relationships among the business areas are also shown.
The remainder of this chapter will provide the specific descriptions for each business area
and business system, beginning with the Technical Assistance Business Area, located at the
upper left-hand corner of the foldout. Descriptions of the data stores will follow the business
area discussion.
39
-------
This page intentionally left blank.
-------
PAGE NOT
AVAILABLE
DIGITALLY
-------
This page intentionally left blank.
-------
SDC-0055-012-TB-2009
December 31. 1992
Technical Assistance
TE<
:HNICAL ASSISTANCE
Technical
Support
[_ roSTi'B
Training
Support
Technical Assistance Business Area
The Technical Assistance business area provides assistance to the regulated
community and regulators in the form of expertise, technology, and training.
Technical Assistance consists of the following two business systems:
Technical Support: Providing technical advice and services to PWSs and the
regulators.
Training Support: Includes functions relating to development and presentation of
training related to PWSS implementation.
43
-------
SDC-0055-012-TB-2009
December 31, 1992
Compliance
COMPLIANCE
Monitoring
Requirements
Development
Compliance
Determination
Compliance Business Area
The Compliance business area develops monitoring plans, monitors performance,
builds cases against violators and noncompliers, takes enforcement actions, and tracks
enforcement actions and public notification.
Compliance consists of the following three business systems:
Compliance Determination: Analyzing and assessing sampling, inspection, audit
review, and other monitoring information to determine whether a violation has
occurred.
Enforcement: Building cases against violators and noncompliers, taking enforcement
actions, and tracking the enforcement actions.
Monitoring Requirements Development: Preparing monitoring plans.
Public Notification: Development and dissemination of the public of violation and
related health effects information.
44
-------
SDC-0055-012-TB-2009
December 31. 1992
Field Surveillance
FIELD
SURVEILLANCE
Lab
Certification
Operator
Certification
Sampling
Field
Surveillance
Permitting
Field Surveillance Business Area
The Field Surveillance business area includes certifying labs and personnel. Also,
includes conducting surveys and inspections and taking samples.
Field Surveillance consists of the following six business systems:
Field Surveillance: Performing sanitary surveys and site inspections, including
construction inspections, and performing follow-up.
Lab Certification: Certifying or licensing labs that do analyses of drinking water
compliance samples.
Operator Certification: Certifying operators of water treatment and distribution
systems.
Permitting: Issuing permits, excemptions, waivers and variances.
Sampling: Taking water samples to comply with monitoring requirements and
comply with water quality standards.
45
-------
SDC-0055-012-TB-2009
December 31, 1992
Regulation
REGULATION
Primacy
Implementation
Technology
Assessment
Regulation
Development
Standards
Development
Regulation Business Area
The Regulation business area is concerned with scanning scientific and technological
research. Using the research in developing regulation, policy, and standards; in planning
and delegating primacy; and in assessing regulatory and implementation success.
Regulation consists of the following four business systems:
Primacy Implementation: Interpreting regulation. Also planning, delegating, and
assessing the successfulness of regulation implementation.
Regulation Development: Planning, developing, assessing the successfulness of, and
recommending changes to regulation.
Standards Development: Developing methods and techniques and setting standards.
Includes reviewing third party standards as well as conducting pilot studies and
demonstrations and performing field tests and evaluations.
i
Technology Assessment: Retrieving scientific research and identifying available
technologies. Evaluating the information for use in the following activities:
46
-------
SDC-0055-012-TB-2009
December 31, 1992
developing regulation, policy, and standards; assessing nsk; characterizing water
resources; responding to disease outbreak; responding to information requests; and
assessing program success.
Water Resource Planning
WATER
RESOURCE
PLANNING
L
Vulnerability
Assessment
1
1
esource
arization
Forecasting
|
Allocation
Water Resource Planning Business Area
The Water Resource Planning business area concentrates on characterizing water
resources, providing forecasts, promoting water conservation, and allocation. Includes
assessing risks to water sources and human health.
Water Resource Planning consists of the following five business systems:
Allocation: Allocating water resources and taking proactive actions to protect against
contamination of water sources and systems and to avoid water shortages.
Contingency Planning: Preparing contingency plans for shortages and emergency
situations.
47
-------
SDC-0055-012-TB-2009
December 31, 1992
Forecasting: Forecasting drinking-water demand, supply, and financial need for
water-system investment.
Vulnerability Assessment: Assessing risks to water resources; such as contamination
or drought.
Water Resource Characterization: Characterizing water resources, including water
rights, point and non-point sources of contamination.
Inventory
INVENTORY
Inventory Natural
Characterization Resource
II& Demographic
Inventory
Inventory Business Area
The Inventory business area functions include characterizing public water systems,
including plants and equipment, human resources, and populations served.
Inventory consists of the following two business systems:
PWS Characterization: Characterizing public water systems, including plants and
equipment, human resources, populations served, water resources, responding to
disease outbreak, responding to information requests, and assessing program success.
Natural Resource and Demographic Inventory: Inventorying of natural resources,
land use, and statistics about people, animals and plant life.
48
-------
SDC-0055-012-TB-2009
December 31. 1992
Disease Prevention and Assessment
DISEASE
PREVENTION
& ASSESSMENT
Disease &
Risk
Assessment
Health
Advisory
Disease Prevention and Assessment Business Area
The Disease Prevention and Assessment business area is concerned with developing
disease prevention and outbreak information. Compiling the information to be
communicated to the public. Identifying the proper means and alternative modes of
communication. Conducting the communication and responding to requests for
information.
Disease Prevention and Assessment consists of the following three business systems:
Disease and Risk Assessment: Analyzing and assessing disease-related information to
determine whether drinking contaminated water caused or can cause illness.
Outreach: Developing program and health-related information, identifying the means
of communication, and communicating the information in emergency and
non-emergency situations. Includes responding to requests for information.
Health Advisory: Taking preventive measures to protect the public from health
problems.
49
-------
SDC-0055-012-TB-2009
December 31. 1992
Management and Budget
MAN
AGEMENT and BUDGET
Coordination
1
Funds
Management
i
Resource
Management
t
~mam
'»CunM>n»
PnfOfCIBMMHBfW
EK"**
»MM
Mom Don
L_ ^
mm^m
Information
Systems
Management
Management and Budget Business Area
The Management and Budget business area deals with coordinating activities and
information with other organizations, including the provision of information-retrieval
capabilities and other information systems development. Includes financial assistance and
management of resources.
Management and Budget consists of the following four business systems:
Coordination: Networking and coordinating with other government and
nongovernment organizations.
Funds Management: Providing grants and guaranteed loans, such as for
construction. Includes monitoring/reviewing compliance with the requirements for the
grant/loan. Developing a budget for operations, maintenance, monitoring, personnel
and other areas necessary to comply with PWSS program requirements.
50
-------
SDC-0055-012-TB-2009
December 31, 1992
Information Systems Management: Developing and maintaining information
systems.
Resource Management: Managing plants and equipment, budgets, and people.
The approach used by the PWSS project team arrived at the names for the above business
systems. For example, the "Compliance Determination1' Business System is comprised of a
group of business functions that do the following: analyze and evaluate sampling; conduct
inspections and audit reviews; and perform other monitoring activities to determine whether a
PWS is in violation. From a logical viewpoint, naming this business system "Compliance
Determination" is representative of the group of functions being carried out in this business
system. Another example is the "Enforcement" Business System, which includes functions
for building cases against violators and non-compliers, taking enforcement actions, and
tracking enforcement actions taken. The overall objectives of this group of functions can be
expressed as enforcement. All of the business systems that compose the PWSS Business
System Architecture were formed using this approach.
Another automated product that helped the PWSS project team identify the natural
business systems is the Business System by Business Function Matrix, shown in Appendix T.
This matrix relates the natural business systems with the original business functions. This
process ensures that all business functions identified in the PWSS Information Architecture
are accounted for in the Business System Architecture.
The strategy used by the PWSS project team to identify the above business areas was
based on the logical grouping of functions that support the various PWSS program activities
in today's operational environment at both EPA Headquarters and the individual States. For
instance, the "Compliance" Business Area deals with the group of Business Systems designed
to monitor individual PWS and state program performance, build cases against violators and
non-compliers, take enforcement actions, and track enforcement actions. From a logical
standpoint, the "Compliance" Business Area captures the essence of the group of functions
being carried out in this Business Area. Another example is the "Inventory" Business Area,
which involves functions such as characterizing public water systems to include plants and
equipment, natural and human resources, and populations served. The overall goal of this
group of functions can be expressed very logically under an inventory Business Area.
The Business System Architecture also included the identification of the natural data
stores to support each of the business areas listed in the preceding section. The primary
function of the natural data stores are to create repositories of data for the users in support of
each of the natural business areas identified in the Business System Architecture Summary
foldout.
51
-------
SDC-0055-012-TB-2009
December 31, 1992
To arrive at the natural data stores, the PWSS project team used an approach similar to
the one employed to determine the natural business systems. The CRUD Matrix was
analyzed to obtain the natural data stores, consisting of groups or clusters of entity types that
are manipulated (e.g., Created and Updated) by a specific business function. As a result of
the CRUD analysis, the IEF development tool assisted the project team to create groups of
entity types that were closely related to each other because of the functions, and ultimately,
the business area they support. The 17 natural data stores to support the PWSS Information
System Modernization are as follows:
Agencies: Includes Government Agency and Non-Government Agency or Company
entity types.
Agreement: Includes Agreement entity type such as permits, primacy, enforcement.
Certificates: Includes Lab Certificate, Operator Certificate, and Permit entity types.
Compliance: Includes Deviation, Sample, Sample Analytical Result, Sample
Assessment, Violation, and Enforcement Action entity types.
Cross Media: Includes Environmental Event, Weather Data, Water Habitat Quality
Information, and Water Threat entity types.
Evaluation: Includes Review Audit and Evaluation and Complaint entity types.
Financial Assistance: Includes Budget, Grant, and Guaranteed Loan entity types.
Inventory: Includes Legal Entity, Public Water System, Water System Facility,
Treatment Equipment, and Population Group entity types.
Outreach: Includes Communications Media, Public Notification, Technical
Publication, and Information Request entity types.
Plans: Includes Monitoring Plan, Cross Media System, Contingency and Emergency
Plans, and Engineering Plan entity types.
Programs: Includes Program and Program Plan entity types.
Requirements: Includes Legal Mandate, Regulation, Research Need, and
Requirement entity types.
Research Results: Includes Research Result and Contaminant entity types.
52
-------
SDC-0055-012-TB-2009
December 31, 1992
Resources: Includes Analytical Equipment, Field Equipment, Individual, and
Laboratory entity types.
Rules: Includes Policy and Guidance and Standard Techniques or Procedures entity
types.
Source Data: Includes Drinking Water Source, Hydrological Information, and
Hazardous Waste Information entity types.
Technical Assistance: Includes Technical Assistance and Training Event entity types.
Refer to the Business System Architecture Summary foldout shown on page 7 to follow
along with the listing of the business areas with their supporting natural data stores. Note
that many of the natural data stores support more than one natural business system. This
design supports the data sharing concept that is inherent with information engineering.
Technical Assistance business area consists of the following natural data stores:
Financial Assistance
Inventory
Outreach
Resources
Technical Assistance
Field Surveillance business area consists of the following natural data stores:
Agencies
Certificates
Compliance
Cross Media
Evaluation
Financial Assistance
Inventory
Plans
Resources
Compliance business area consists of the following natural data stores:
Agencies
Compliance
Evaluation
53
-------
SDC-0055-012-TB-2009
December 31, 1992
Inventory
Plans
Resources
Regulation business area consists of the following natural data stores:
Agencies
Agreement
Financial Assistance
Inventory
Programs
Requirements
Research Results
Rules
Inventory business area consists of the following natural data stores:
Inventory: Data store contains individual PWS, facility and personnel data.
Cross Media
Management and Budget business area consists of the following natural data stores:
Agencies
Agreement
Certificates
Compliance
Financial Assistance
Inventory
Plans
Programs
Rules
Source Data
54
-------
SDC-0055-012-TB-2009
December 31, 1992
Disease Prevention and Assessment business area consists of the following natural data
stores:
Agencies
Compliance
Cross Media
Evaluation
Inventory
Outreach
Plans
Requirements
Rules
Business Area Evaluation
The primary reason for performing the assessment described in the Business Systems
Architecture is the identification of business areas for the PWSS program. In order to
designate the relative importance of a business area in fulfilling the users' information needs,
the PWSS project team used a two-step method to rank the business areas identified during
the Business Area Evaluation process. This method involved:
Counting the number of information needs that a particular Business Area supports
and ranking the business areas accordingly.
Analyzing the program requirements and priorities, the potential development time,
and other issues, and then revising the business area rankings based on these criteria.
The first step in this method is straightforward. The PWSS program information needs,
shown in Appendix G and developed for the Information Architecture in Chapter 2, was the
basis for ranking the Business Areas. This process resulted in the construction of a ranked
list of the eight business area projects for the PWSS program as shown in the Initial Business
Area Ranking list that follows.
55
-------
SDC-0055-012-TB-2009
December 31, 1992
Rank Business Area Name Info Needs
Supported
1 COMPLIANCE 69
2 REGULATION 66
3 MANAGEMENT AND BUDGET 61
4 INVENTORY 56
5 WATER RESOURCE PLANNING 51
6 FIELD SURVEILLANCE 48
7 TECHNICAL ASSISTANCE 29
8 DISEASE PREVENTION AND ASSESSMENT 19
Initial Business Area Ranking
The second step used to rank the business areas is a little more complex. The PWSS
MNA addressed the oversight requirements primarily from the EPA Headquarter's
perspective instead of the State's perspective. For instance, while some States consider
issuing PWS permits one of their highest priorities, other states are more concerned with
enhancing their enforcement capabilities. Still other issues such as systems development
sequence and program impact must be considered. For example, it is reasonable to assume
that the "Regulation" Business Area should be developed before the "Compliance" Business
Area. However, in reality at the state level, the sequence may be altered by the lag time
between federal and state regulation development, conflicting priorities, and available
resources. Another issue to consider is the availability of systems (e.g., Model State
Information System or the Drinking Water Information System) to support a particular State.
Costs and schedule to complete a particular business are (or part of a business area, in the
case of a rapid application development project) also plays a role in this ranking process.
This second process considered the importance of the Business Area to the fulfilling the
mission of PWSS and its impact; the complexity of Business Area (how hard would it be is
56
-------
SDC-0055-012-TB-2009
December 31, 1992
design and implement) and development time required; and the required development ordered
(which Business Area must be completely developed before another can begin). This process
resulted in the construction of a revised ranked list of the eight business area projects for the
PWSS program as shown in the list that follows.
Rank Business Area Name
1 INVENTORY
2 FIELD SURV1ELLANCE
3 COMPLIANCE
4 WATER RESOURCE PLANNING
5 TECHNICAL ASSISTANCE
6 REGULATION
7 DISEASE PREVENTION AND ASSESSMENT
8 MANAGEMENT AND BUDGET
Final Business Area Ranking
The "Management and Budget" Business Area appears last because it is felt that current
systems address the "near term" requirements of this business area. The revised ranked list
of business areas represents the recommended ordering of the development efforts to be
adopted for implementation in the PWSS Information Strategy Planning project.
57
-------
SDC-0055-012-TB-2009
December 31, 1992
This page intentionally left blank.
58
-------
-------
Chapter 4
Technical Architecture
-------
SDC-0055-012-TB-2009
December 31, 1992
Technical Architecture
The Technical Architecture defines the operating environment required to implement the
Information and Business Systems Architectures defined in Chapters 2 and 3. The Technical
Architecture specifies the computers, telecommunications, supporting utilities, database
management systems, and operating systems needed to support the business systems.
The Technical Architecture defines a general framework for the system, describing where
components would be located and how the components would interact. The Technical
Architecture is refined during follow-on Business Area Analysis (BAA) projects, adding
technical detail and specifications, including model numbers and software product names.
Three major products result from completing the Technical Architecture: the "Statement of
Technical Requirement," the "Technical Architecture" chart, and the "Statement of Technical
Direction." The "Statement of Technical Requirement" specifies needed system throughput,
availability, response, and security for each proposed business system. The "Technical
Architecture" chart illustrates the basic architectural options proposed for PWSS
development. The "Statement of Technical Direction" describes long-term plans and
recommended alternative(s) for the PWSS system; it also describes policy implications and
proposed changes that could affect the PWSS program. These products are presented later in
this chapter.
To develop the Technical Architecture, the PWSS project team used the following four-
step approach: business area distribution analysis, performance requirements analysis,
technical distribution requirements analysis, and architectural options definition and
evaluation.
Business Area Distribution Analysis
Business systems and data stores are used by each user category are identified. PWSS user
categories are: EPA Headquarters, EPA Regions, Primacy Agencies, Laboratories (Labs),
and Public Water Systems (PWSs). Primacy Agencies consist of State, State Region, or in
certain cases, EPA Regions.
59
-------
SDC-0055-012-TB-2009
December 31, 1992
Performance Requirements Analysis
The high-level technical performance requirements are identified. These performance
requirements are later used to evaluate various Technical Architecture options.
The "Statement of Technical Requirement" is produced during this analysis step.
Technical Distribution Requirements Analysis
The required computer hardware, software, and communications capabilities are
determined for each user category.
Architectural Options Definition and Evaluation
The architectural options that form the basis for the Technical Architecture are defined.
Evaluation of the options involves using the technical performance requirements identified
above to determine the most suitable architecture(s) for each organizational level of the
PWSS program.
The "Technical Architecture" chart and "Statement of Technical Direction" are produced
during this step.
The above four-step analysis process and the results produced from it are described in the
following sections.
60
-------
SDC-0055-012-TB-2009
December 31, 1992
Business Area Distribution Analysis
When building the Technical Architecture, it is important to identify the functions and data
required by each organization. This process helps determine what information is shared by
the organizations and how the information flows between them. For PWSS, business area
distribution analysis focused on developing a thorough understanding of the organizations'
and users' functional requirements and data requirements. This effort involved three steps:
Assessment of Organizational Data Sharing
Assessment of Organizational Functions
Data Life-Cycle Assessment
The results of these three steps are described below.
Assessment of Organizational Data Sharing
PWSS users are located within State and EPA organizations nationwide. In addition, the
public and other State and Federal organizations are potential PWSS users. The public
includes any person or organization outside the government, from average citizens to
citizens' action and interest groups. Other organizations are EPA organizations outside the
Drinking Water program and State and Federal organizations and agencies outside the EPA.
The following "General Organizational Relationships of PWSS" diagram represents
information-sharing relationships within the user community. Organizations shown adjacent
to each other typically share information directly.
Assessment of organizational data sharing helps determine the interrelationships of the
system from an informational point of view. The interrelationships help determine
communication-connection needs and help establish the kinds of communication hardware and
software necessary to support the sharing of data.
61
-------
SDC-0055-012-TB-2009
December 31, 1992
STATE/
STATE REGION
General Organizational Relationships of PWSS
Assessment of Organizational Functions
Each user category typically performs a set of business activities, represented by a collection
of PWSS business systems, that accesses a portion of selected data stores. A business system
is considered to be used by a user category if any of the functionality of the particular
business system is needed by typical users within the specific user category. For example,
Labs can be expected to use at least one of the functions performed by each of the following
62
-------
SDC-0055-012-TB-2009
December 31. 1992
business systems: Lab Certification, Coordination, Information Systems Management, and
Operator Certification.
The "Primary Business System Usage" chart below displays the business systems used by
each user category. This information provides insight into the distribution of system
functionality and helps determine the expected technical architectural components needed by
each user level within the PWSS system hierarchy.
USER
PWS
LAB
PRIMACY
AGENCY
EPA REGION
EPA
Primary Business System Usage
63
-------
SDC-0055-012-TB-2009
December 31, 1992
Data Life-Cycle Assessment
Business area distribution analysis also included analysis of entity types (an entity type is a
collection of related information [data] required to be kept by the system) from two
additional perspectives:
Data Life Cycle
First, a typical life cycle of operational data was developed showing the functional How of
the data from its origin at a PWS or Lab through its use by various organizations needing it.
Data Distribution
Then it was determined which user categories need the information, with respect to age and
data owner. A data owner is a governmental user entrusted with custody of the data. Data
owners typically have authority to validate and release data to other agencies or the public
and to remove data from a system.
Results from the above two analysis perspectives are described below.
Data Life Cycle
The "Typical Entity Life Cycle" diagram, which follows, is a conceptual view of the
functional flows affecting the following four PWSS operational entity types: Sample, Sample
Result, Violation, and Enforcement Action.
64
-------
SDC-0055-012-TB-1006C
November 13, 1992
PVBUC/OTHER
ORGANBAHONS
HB
,HW
90
30
IS
10
5
0
PRMACY AGENCY
NVS
ANMYE
SAVR£
OEIBMNMION
AM)
SUMMARTOMA j
AcnvmES
Typical Entity Life Cycle
65
-------
SDC-0055-012-TB-2009
December 31, 1992
This "Typical Entity Life Cycle" diagram is an abstract representation of the delegated
responsibilities and functions of the typical Primacy Agency. These responsibilities are based
on a typical State implementation plan, and are not intended to capture all variations.
The diagram highlights the interaction of selected functions with entity types. The diagram
is useful in developing a general model for determining where the data typically should be
located and what age of the data would be acceptable for performing particular functions.
Acceptable age of data is a significant design consideration, because an often-stated general
requirement for many modern data systems is to provide the most recent data. Since costs
associated with real-time (or almost real-time) data availability are significantly greater than
those associated with a less time-critical database, an understanding of data requirements as
being Strategic, Planning, Controlling, or Operational allows for realistic design. (Refer to
Chapter 3 for definitions of Strategic, Planning, Controlling, and Operational requirement
levels.)
Operational functions generally need the most recent data to support their efforts.
Controlling functions generally need the most recent data, but may tolerate older data.
Strategic and Planning functions generally can tolerate older data. All these factors influence
design. For example, a realistic design would not require extraordinary or unnecessary
investment in communications and processing capabilities to allow instantaneous updates if
the effort is to review natural trends over the past five years.
On the "Typical Entity Life Cycle" diagram, the vertical axis "Days" represents time
frame for the entity-type life cycle. For example, day 0 is the day a particular sample is
taken; it is the day the entity-type SAMPLE is created. The horizontal axis represents
activities that occur that use and transform the entity types. (For clarity, entity types are
written with all capital letters within the remainder of this explanation.) Shortly after the
SAMPLE is taken, the Lab receives the SAMPLE, reads the SAMPLE data, analyzes the
SAMPLE, and documents the findings. This process creates SAMPLE RESULTS data. The
Lab forwards SAMPLE RESULTS to the PWS and Primacy Agency. The Primacy Agency
reads SAMPLE and SAMPLE RESULTS data, determining compliance and creating
VIOLATION data, if appropriate. Then the Primacy Agency reads and assesses
VIOLATION data, considering ENFORCEMENT ACTIONS. The Enforcement function
reads SAMPLE, SAMPLE RESULT, and VIOLATION data, and creates ENFORCEMENT
ACTION data. The process outlined above may occur within a few days or (more typically)
over thirty days. Generally, the operational functions accessing SAMPLE, SAMPLE
RESULT, VIOLATION, and ENFORCEMENT ACTION need the most current data
available.
66
-------
SDC-0055-012-TB-2009
December 31, 1992
While the above discussion highlights the use of data by Operational functions, the data is
still needed for Planning and Strategic functions for such purposes as trend analysis, primacy
oversight, and program implementation review. The b'fe cycle of the various entity types
(SAMPLE, SAMPLE RESULT, VIOLATION, and ENFORCEMENT ACTION) may range
from thirty days to several years. As a result of data life-cycle analyses, it was determined
that Strategic and Planning functions accessing SAMPLE, SAMPLE RESULT,
VIOLATION, and ENFORCEMENT ACTION information can tolerate data from two to
three months old (i.e., historic data); these functions do not require the most recent data for
analysis.
Data Distribution
To understand the distribution of information within the PWSS program, it was necessary to
assess the users of and sources for data. This assessment is discussed below.
Users
The Entity Type by User Category Matrix, included as Appendix AA, displays the data
needs of the various PWSS user categories. For each entity type, the PWSS project team
first indicated the data owner. Note that a particular entity type may have several data
owners. For example, SAMPLE may be owned by a Primacy Agency or the EPA. A
Primacy Agency is the custodian for SAMPLES created in response to its own programs.
EPA is custodian for SAMPLES that the Agency takes directly, outside the auspices of a
Primacy Agency.
Once owners were determined, entity-type usage was considered. If an entity type is
needed to perform Operational functions by a user category, then the use was coded
operational. If the entity type is needed to perform only Strategic or Planning functions,
then the use was coded strategic/planning.
Sources
Analyzing the operations and information stored at each organization results in the
"Organization Information Interface Matrix," which follows. This matrix considers each
organization as an information source (shown along the horizontal axis) that supplies other
organizations as information users (the vertical axis). The type of information passed from
the source organization to the user organization is marked at each matrix intersection with
a number. The number 4, for example, at the intersection of EPA (source) and EPA
Region (user) indicates that rules, regulations, etc., are passed from the EPA to the EPA
Region. Six numbered categories of interfaced data are defined in the table below and are
used in the matrix.
67
-------
SDC-0055-012-TB-2009
December 31, 1992
Category
0
1
2
3
4
5
6
Data Description
The source organization is not the normal data source for another user
organization. Exceptions may occur, but the intent of the matrix is to be
a general representation.
The organization is a source for the data; i.e., it "owns" the entity type,
which can be read by other user organizations. For example, an EPA
Region or State would own violation data.
Inventory data, such as the numbers and types of laboratory equipment,
flow from the source.
Analytical results flow from the source to the user. For example, a Lab
sends water-analysis reports to a Primacy Agency.
Static and directive data (rules, regulations, etc.) flow from the source to
the user.
The source organization determines violations and generates
enforcement data.
The source organization is a Primacy Agency and is the source for
implementation status.
Categories of Interfaced Data
68
-------
SDC-0055-012-TB-1006C
November 13, 1992
\ USER
\
\ EPA
SOURCE \
EPA PRIMACY
REGION AGENT
PWS
LAB PUBLIC OTHER
AGENCIES
EPA
EPA
REGION
PRIMACY
AGENT
PWS
LAB
PUBLIC
OTHER
AGENCIES
Sf
i 6
3,5
0
0
0
4e
l 5
3,5,6
0
0
0
»5
,4
2,3
3
0
«4,5
1,4,5
3
0
»4
1,4,5
2
0
/4,5
r 4,5
1,4,5
0
0
» 4.5
1,4,5
1,4,5
0
0
0
0 = NOT NORMAL DATA SOURCE
1 = SOURCE FOR DATA ACCESS
2 = INVENTORY DATA
3 - SAMPLE RESULTS
4 » RQLES, REGULATIONS, ETC.
5 - VIOLATION i ENFORCEMENT DATA
6 PRIMACY (IMPLEMENTATION STATUS)
Organization Information Interface Matrix
The analysis of business area distribution for the PWSS system shows that both the
national EPA Drinking Water program and various Primacy Agency drinking water programs
need full PWSS functionality. The division of some business areas is more definitional than
actual, in that both the national program and the Primacy Agency programs can perform
aspects of the same function, (e.g., both the States and the national EPA engage in
regulation development, technical assistance, management and budget, etc.) Similarly, the
location of data stores to support these business areas is dependent on the definition, since
information such as sample data and inventory data may appear in both Primacy Agency and
national EPA databases.
69
-------
SDC-0055-012-TB-2009
December 31, 1992
Performance Requirements Analysis
The second step in defining the Technical Architecture is assessing performance
requirements. A recommended Technical Architecture is determined mainly by how it meets
performance requirements in two categories: programmatic performance and technical
performance.
Programmatic Performance
For PWSS, programmatic performance includes considerations such as cost, portability,
and compatibility with existing State systems.
Technical Performance
Technical performance includes features such as response time, security features, and the
ability of the system to meet key PWSS functionality requirements.
Summaries of the analyses performed for the two categories of performance requirements
are discussed below in detail. The "Statement of Technical Requirement," which recaps the
results from the analyses, follow the summaries.
Programmatic Performance
Considerations identified as important to programmatic performance are listed below. The
identified considerations are:
Acquisition Cost
Maintenance Cost
Operational Cost
Portability and Scalability
Accessibility to Information
User Acceptance
Compatibility
70
-------
SDC-0055-012-TB-2009
December 31, 1992
Ability to Satisfy Requirements
Conversion Cost
Political Acceptability.
Following is a description of each consideration:
Acquisition Cost - The initial cost incurred to acquire the system. This includes the costs
of purchasing hardware and software components used at each level. The number of
components in each organizational level is important because it is a multiplierthe more
components, the greater the cost. For example, at the Primacy Agency level the multiplier
is low compared with the multiplier for PWSs (65 Primacy Agencies compared with over
200,000 PWSs).
Maintenance Cost - The cost of keeping the system running at a uniform level of
operation. This includes the costs of hardware/software upgrades and the costs associated
with special operators and computer technicians.
Operational Cost - The day-to-day cost built into the system. This includes the costs of
leasing/using communication lines and the costs of purchasing supplies.
Portability and Scalability - A feature of open systems (also known as open systems
interconnection [OSI]) in data communications. The International Standards Organization
developed OSI to coordinate standards development at all communications levels. OSI
permits a single software product to be used across a wide range of computing platforms.
Accessibility to Information - A view of the Technical Architecture from the perspective of
how communications interfaces are implemented needed in order to provide the necessary
access to PWSS information while maintaining the necessary security.
User Acceptance - Consideration of how users, especially at the State and local levels,
view the PWSS. The Technical Architecture must offer apparent benefits to users.
Compatibility - Consideration of how compatible the PWSS will be with regard to the way
States currently do business. If the system is radically different from what users expect or
are comfortable with, it may not be accepted.
71
-------
SDC-0055-012-TB-2009
December 31, 1992
Ability to Satisfy Requirements - The Technical Architecture must be capable of satisfying
all identified functional requirements. There must be nothing inherent in the Technical
Architecture that prevents implementing the required functionality. Technical requirements
cover features such as response time and security. Since technical performance can vary,
this consideration evaluates the degree to which the system meets its performance
requirements.
Conversion Cost - The cost of converting the software and hardware of existing systems to
conform to the Technical Architecture.
Political Acceptability - Consideration of how acceptable the Technical Architecture is to
all user organizations. Influencing this evaluation are personal preferences, existing
computer hardware and software, training/familiarity investments, and other qualitative
factors.
Members of the PWSS Technical Architecture Working Group, which met October 21-23,
1992, weighted the above considerations on a scale of 1 to 10. (Appendix BB contains a list
of Working Group participants.) The composite result of the meeting is shown in the
following table.
CONSIDERATION
Ability to Satisfy Requirements
Accessibility to Information
User Acceptance
Acquisition Cost
Maintenance Cost
Political Acceptability
Compatibility
Portability and Scalability
Operational Cost
Conversion Costs
WEIGHTED AVERAGE
8.7
8.1
7.3
7.2
7.1
7.0
6.7
6.2
5.8
5.6
Weighted Considerations In Technical Architecture Evaluation
72
-------
SDC-0055-012-TB-2009
December 31, 1992
Technical Performance
Three main areas of technical performance are considered when developing the Technical
Architecture:
System Response
System Security
Functional Performance
This information gathered in these areas is used to aid selection of options for data
communications, levels of security, etc. This data, combined with the business area
distribution developed in the previous task, can be used to determine the kind of technical
support that is needed throughout the organization. The three areas of technical performance
are discussed below.
System Response
System response can be constrained either by communications capacity or by computational
capacity. If communications are limited, then transactions flow slowly between
organizations, (i.e., communications capacity limits response). When communications are
adequate so that transactions flow quickly. On the other hand, if the computers in each
organization cannot respond, then computational capability limits response.
Computational capacity limitations can be easily overcome by ensuring that the computing
platforms at each location are adequate for the processing load. This can be done by using
modem computing technology, provided the costs of the computers are within acquisition
budgets. Communications, on the other hand, is a recurring expense directly related to the
time of channel use and the bandwidth (bits per second) of the channel. Since
communications costs are recurring, care must be taken that the Technical Architecture is
configured so large amounts of data need not be transferred between the source and the user.
An example of communications inefficiency is the use of a remote graphical user interface
(GUI). If the GUI program resides remotely, then each time the user accesses the system,
bit-mapped graphics are transferred between the host machine (containing the GUI program)
and the user. Since access takes place over communications lines, response is slowed and
the amount of actual data transferred is small relative to overall channel use. In other words,
GUI programs and data should reside with local users. Another example of potential
communications inefficiency is in the area of data queries. If a user (such as the public) is
73
-------
SDC-0055-012-TB-2009
December 31, 1992
given free-form query capability of an organization's database, response to the query could
be an extremely large amount of data. This would effectively lock up the communications
channel and require a great deal of time to transfer the information.
The Technical Architecture must also support essential data transfer in a timely manner by
limiting the amount of extraneous data flowing through the system. Essential data transfer
involves the analytical results taken from water samples and corresponding physical inventory
that pass from PWSs and Labs to higher level organizations.
The reporting of sample results for all contaminants is a goal of the PWSS system and is
expected to result in maximum communications loading. System feasibility depends on
providing adequate communications Consequently estimating communications loading is
useful to ensure that communication requirements are reasonable. Appendix DD, the
"Communication Feasibility Analysis," describes an analysis that defines worst-case type
bounds on communication requirements. The analysis assumes the worst-case reporting
situation is caused by each Lab reporting results for all contaminants in each sample. The
analysis considers annual, quarterly, monthly, weekly, and daily sampling, and assumes an
efficient coding system (other than straight ASCII) is used to represent contaminant type and
sample value. The results of the analysis show that the communications needed to report all
contaminant measurements are reasonable and within the scope of dial-up and/or leased-line
interconnections. However, success of using dial-up lines is dependent on development of a
PWSS Communications Management Plan that distributes the transfer of information over a
reporting period.
System Security
The PWSS user community is diverse. It includes both official government users and the
public as well as PWSs, Labs, and other drinking-water program participants. In addition,
information to be stored within the system would include sensitive information, potentially
including data protected by the Privacy Act of 1974, and sensitive enforcement data.
The PWSS system will process sensitive data as defined by OMB Circular A-130, and will
require incorporation of security safeguards to preclude unauthorized access, modification, or
inadvertent loss of PWSS data.
Also, each user category will be restricted to performing only their prescribed set of
functions within specific business systems. For example, a PWS should be able to review
their inventory information, but should not be permitted to unilaterally change the inventory
records. However, a PWS should be able to submit a proposed change to inventory records
for verification and approval by the government data custodian. As a result, the security
design must provide for limiting access to prescribed business systems and to specified
74
-------
SDC-0055-012-TB-2009
December 31, 1992
functions within each business system. Security would also include controlling access to the
capabilities that establish authority (by user category or user identifier) over the ability to
create, update, delete, and read each entity type.
Additionally, the system must provide a means to audit use by individual users, including
the logging of data activity. Included would be the capability to roll back changes, should
unauthorized access occur. Audit trail records of any updates to the database are critical to
developing and maintaining data integrity and traceability.
Functional Performance
Analysis of functional performance involves consideration of needed system functionality in
light of its potential impact on choosing a Technical Architecture. Of the functional needs
discussed during the Technical Architecture Working Group Meeting, the following eleven
items directly affect the Technical Architecture:
Automated Data Flow
Retrieval
Update
Cross-Media Data Access
Compatibility and Scalability
Interface
Flexibility
Response Time
Security
System Maintenance
Historical Record Keeping
Each of these functional needs is described in more detail below:
Automated Data Flow - The system must be able to maintain schedules by which
automated synchronization of selected entity types are performed between Primacy Agency
data stores and EPA data stores. Primacy Agencies must be able to define the schedules
according to agreements with other organizations (field office, EPA Regional office, etc.).
This functionality must be transparent to the user.
75
-------
SDC-0055-012-TB-2009
December 31, 1992
Issue:
Should a truly distributed architecture be selected, synchronization would be
managed by the database management system (DBMS).
Retrieval - Both batch and online data retrieval must be available locally and remotely
(field personnel, Labs, PWSs, etc.) and to the public. Access to the system must be
simple and must include the ability to formulate data queries and define and select reports.
Responses to retrieval requests must be timely. Retrieval of sensitive/confidential data
must be controlled appropriately.
Issues:
Deciding and controlling who has access.
Achieving economies of scale between batch and online capabilities.
Limiting the size of query responses and reports so normal processing is not
impacted, or providing sufficient systems and communications capacity to generate
them.
Update - Both batch and online updating must be available to locally and remotely. The
update process must be straightforward and simple (i.e., responsive [timely and logically
complete and intuitive], with easy-to-use add, change, and delete capabilities). The online
update process must be immediate. The system must support total data replacement as
well as traditional updating (inserting new database records, deleting existing records, and
modifying values). Updates to sensitive/confidential data must be controlled appropriately.
Issues:
Deciding and controlling who has access.
Whether to update a master file through the use of a batch transaction file.
Whether to allow online access to edit erroneous data.
How to realize economies of scale by maintaining both batch and online
capabilities
Maintaining audit trail records of every update to the database.
Cross-Media Data Access - The system must be able to possess the minimum data set
necessary to access other information systems (STORET, USGS, PCS, CERCLIS, etc.).
Of special interest is compatibility with EPA geographic information systems. Access to
76
-------
SDC-0055-012-TB-2009
December 31, 1992
other data systems would include the following minimal capabilities: fundamental data
retrieval; foreign data integration with PWSS-specific data; and/or augmentation of PWSS-
specific data with foreign systems' data.
Issues:
Which "hooks" are needed to the other database systems.
Whether compatibility should include direct import.
Whether database systems should be integrated.
Suitability of periodic imports of selected data from other systems.
Compatibility and Scalability - The system must be compatible with personal computer
(PC), minicomputer, and mainframe implementations found throughout the PWSS
community and must avoid (as much as possible) use of unusual or uncommon equipment.
In PC environments, the system must be single-user compatible as well as network
compatible.
Issues:
Providing compatibility with systems in broad use in the community.
Providing a de facto standard that satisfies the majority of users.
Providing portability within EPA standard technologies.
Providing scalability.
Achieving the goal of developing a usable system within ten years.
Interface - For States, field offices, Labs, and PWSs not choosing to use the PWSS system
directly, a common system interface (standard/data format) must be established.
Automated data entry may also be necessitated. Overall, however, the system should
support existing and emerging state-of-the-art technologies for data acquisition (GPS
equipment, laboratory information management systems, portable computers, etc.) and
interchange (electronic data reporting, electronic data interchange [EDI], etc.).
Flexibility - The system must be adaptable to State-specific requirements, which include the
following:
State-definable data elements (i.e., customization and expandability).
State-definable code values and descriptions.
State-definable data-validation criteria (e.g., date, numeric, min/max value, value
range, code-table lookup).
State-definable rule bases for compliance determination, correspondence generation,
etc.
77
-------
SDC-0055-012-TB-2009
December 31, 1992
Response Time - The system must provide "reasonable" response times to user inquiries,
report-production requests, and batch processing. The "reasonableness" of response time
will vary depending on the characteristics of the task in question and the other demands
being placed on the system at the time.
Security - Retrieval and update of sensitive/confidential data must be controlled
appropriately. Access authority must be controllable to the individual user level, and
States must be able to define and customize their access authorities.
Issues:
Whether a master user list should contain the privileges and authorities.
The number of public access points (the more points of entry, the greater the
risk).
System Maintenance - To reduce cost and manpower burdens on users, the system must be
centrally maintained and installation of system upgrades should need minimal user
intervention.
Historical Record Keeping - The system must support retrieval of operational and
historical data. Types of data for which historical records are maintained must be
determined by agreement between EPA and the Primacy Agencies.
Issue:
The age of historical data maintained in a readily available media is often
established in Federal or State rules. When not established by rule, the age may
be determined at State discretion. Data older than established limits must be
archived in a manner allowing for retrieval if needed.
In analyzing the performance requirements of each business system has been assessed to
determine the kind of technical support needed throughout the PWSS program. Performance
requirements for all levels of PWSS have been established for throughput, availability of the
system, response times, and the need for security.
These performance requirements will be fully detailed during the Business Area Analysis
portion of the systems development life cycle, and are shown for the above mentioned
categories on the "Statement of Technical Requirement," which follows.
78
-------
SDC-0055-012-TB-2009
December 31, 1992
Certain performance criteria are associated with each of the 29 business systems that comprise
the PWSS Business Architecture. These criteria help identify the technological requirements and
constraints that define the Technical Architecture. Broad statements about four areas of
identified technological requirements-Throughput, Response, Availability, and Security-arise
from the performance requirements for business systems.
Throughput
Throughput requirements vary widely across business systems. The largest flow of data will be
from PWSs and Labs to Primacy Agencies at the State level. Some States receive hundreds.
even thousands, of sample-analytical results per day. The timeliness of submissions is based on
the monitoring schedules of the PWSs and the reporting requirements of the Labs. PWSs and
Labs must comply with State and Federal policies and have reporting requirements for given
contaminants. Other throughput requirements pertain to the transfer of data between nodes of
the PWSS communications network. Large volumes of data may move throughout the system,
driving the need for automated data-flow procedures.
Response
Response requirements also cover a wide range. Sub-second response times are required for
online transaction processing at the Primacy Agency level. Less stringent response is required
for query and summary functions at all levels of the PWSS structure. To reduce network traffic
and response-time degradation, the application software must be able to identify potentially time-
consuming queries and warn users before the queries are executed.
Availability
No requirement exists for 24-hour availability of the PWSS system. It is assumed that the
system will be available at all levels for online access and transaction processing during normal
working hours with nonworking hours reserved for system maintenance, batch processing,
backup and recovery, and upgrading of system hardware and software.
Security
The PWSS system will process sensitive data as defined by OMB Circular A-130, and will
require incorporation of security safeguards to preclude unauthorized access, modifications, or
inadvertent loss of PWSS data. Determining who has access to the system at each level and
across the levels will be established according to policy based on agreements between Primacy
Agencies and the national EPA. Public access is assumed to be read only.
Statement of Technical Requirement
79
-------
SDC-0055-012-TB-2009
December 31, 1992
Technical Distribution Requirements Analysis
The third step in defining the Technical Architecture is to identify the technical support
needed for each predicted business system and data store in terms of required computer
hardware and software. That is, this step determines the level of technology required to
satisfy the needs of each business area. Analysis is based on the distribution of business
areas for various organizations and on the performance requirements for the business systems
making up each business area.
This analysis involves assessing integration requirements for each organization, then
determining the levels of technology required to satisfy the requirements. Assessing
integration requirements consists of judging whether business systems and data stores should
be highly integrated (implemented at a central facility), moderately integrated (implemented
using some form of distributed processing), or stand-alone (implemented through local
processing at a single site or workstation).
The approach used was to evaluate the technical support required at each organizational
level. For PWSS, evaluation involved the following four areas of consideration:
PWS and Lab
The technical functionalities needed at the PWS and Lab levels.
Primacy Agency
The technical functionalities at the State, State Regions, and EPA Regions with Primacy.
EPA/EPA Region
The technical functionalities at the national and Regional EPA levels.
NCC
The technical functionalities at EPA's National Computer Center, Research Triangle Park,
North Carolina.
Each organizational level is characterized in terms of data operations, storage, applications,
hardware, and communications. The results of evaluating the four PWSS areas are explained
in the following sections.
80
-------
SDC-0055-012-TB-2009
December 31, 1992
PWS and Lab
The large numbers of PWSs and Labs are significant cost multipliers when considering which
computer technology should be used. The most effective computing platform meeting all
PWS and Lab needs is the PC. A table of technical functionalities for the PWSs and Labs
follows.
Primacy Agency (State/State Region)
Primacy Agency centers require computing platforms capable of operating the database
management systems needed to meet data organizational and security requirements. These
computing platforms can range from capable workstations and minicomputers to mainframes.
Technical functionalities for Primacy Agencies are also shown in the following table.
EPA/EPA Region
EPA Regional offices require technical facilities comparable with those of the Pnmacy
Agencies. EPA Headquarters and Regions will use the technical facilities provided by EPA's
National Computer Center, Research Triangle Park, North Carolina (NCC). Technical
functionalities for EPA Headquarters and EPA Regions are also shown in the following table.
NCC
Currently, the computers at the NCC are mainframes. These computers can accommodate
the additional software necessary to support PWSS reporting, so no additional hardware is
required. Since NCC is not a separate user within the system, the technical distribution
requirements shown for the EPA/EPA Region include the NCC, so NCC is not specified in
the table.
81
-------
SDC-0055-012-TB-2009
December 31, 1992
Technical Distribution. Requirements
PWS
Lab
Primacy
Agency
EPA/
EPA
Region
DATA/OPERATIONS
PWSS functionality:
Data entry/edit capability
Ad hoc query capability
Submission of change request required
No direct update capability
Data uploads to State/State Region
Data verification
Data retrieval (analysis)
Data reporting
STORAGE
Local storage:
Of Lab reports
Of sample records
Of system inventory data
APPLICATIONS
Range of business systems
Communication software (commercial)
Shell (DOS/Windows)
Terminal emulation (VT-100, 3270)
Strategic functions
DBMS
Limited
/ (to create
initial record)
/
/
/
(ot Lab
reports ta
State/ State
Region) /
/
/
/
/
possible
/
Limited
/ (to create
initial record)
/
/
/
(of Lab
reports to
State/State
Region and/or
PWS) /
/
/
/
/
/
Full (data
owner)
/
/
S (to national
EPA)
/
/
/
Large
/
/
/
Full
/
/
/
Full (data
owner)
/
/
/ (to
national EPA)
/
/
/
Large
/
/
/
Full
/
/
/
/
82
-------
SDC-0055-012-TB-2009
December 31, 1992
Technical Distribution Requirements
HARDWARE
Use of existing PCs. or optional purchase of
PCs, as required
Local Area Network (LAN) environment:
Application server
Data server
Communication server
Minicomputer
Mainframe
Host-to-public interface
PC-to-host (NCC)
COMMUNICATIONS
Dial-up or leased circuits to States/State
Regions
Communication interface:
PWS
Lab
State/State Region
EPA/EPA Region
Public
Other organizations, including Federal,
States, and local government databases
PWS
Lab
Primacy
Agency
EPA/
EPA
Region
/
/
/
/
(or Labs)
/
(or PWSsI
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
Technical Distribution Requirements
Based on the above distribution of technical functionalities required by each PWSS user
group, another matrix was developedthe Technical Facility by User Matrix, which follows.
This matrix identifies the technical support (i.e., computer hardware and software) required
83
-------
SDC-0055-012-TB-2009
December 31, 1992
to satisfy the needs of each business area. The technical facilities shown in this matrix are
categorized and described as follows:
Processing Facilities - Includes computers, peripherals, data stores, and support software.
Workstations and Terminals - Includes PCs and systems software (VMS/XA, CICS,
IMS/DC, network protocols, etc.).
Communications Facilities - Includes facilities supporting all communications-hardware
interfaces to PWSS.
DBMS - Database management system software, which includes data dictionaries.
System Development Facilities - Includes systems-development software such as computer-
aided software engineering (CASE) tools, compilers, debuggers, and code generators.
Office Support Software - Includes software to support the office environment (word
processing, electronic mail, etc.).
Decision Support Software - Includes software packages such as spreadsheets and
statistical software (SAS, etc.).
External Resources - Includes timesharing services, service bureaus, and facilities
management.
84
-------
SDC-0055-012-TB-2009
December 31, 1992
Processing Facilities
Workstations. PCs. and
Terminals
Communications Facilities
DBMSSW
System Development
Facilities
Office Support SW
Decision Support SW
External Resources
Technical Facility by User Matrix
This section identifies the locations (users) where various categories of hardware units and
software products are required. From the matrix, we can see that the bulk of the technical
distribution will be at the Primacy Agency and national EPA levels. Other users will need
access to data, but they have more limited requirements for hardware and software to support
their operations.
85
-------
SDC-0055-012-TB-2009
December 31, 1992
Architectural Options Definition and Evaluation
The fourth step in defining the Technical Architecture is to identify feasible architectural
options and provide the basis for mapping the options into the proposed Technical
Architecture. Each candidate Technical Architecture presents particular strengths and
weaknesses. Because the PWSS Technical Architecture represents a concept for building a
geographically diverse system with differing functional and information-storage requirements
at each organizational level, the Technical Architecture is expected to incorporate features
from several of the candidates presented here. For PWSS, analysis of architectural options
involved three steps:
References to the technical facilities at each organizational level were used to
identify architectural alternatives and combinations that are feasible both
technically and financially.
Then the alternatives and combinations that best satisfy the performance
requirements discussed earlier in this chapter were evaluated.
Finally, the best architectural solution was recommended in the "Statement of
Technical Direction."
The above analytical procedures resulted in the development of the three following
architectual evaluation assessments:
Candidate Architectures
Mapping of Candidate Architectures to the PWSS Technical Architecture
Software Considerations
The results of each of these assessments are described in the next section, followed by
the "Statement of Technical Direction," which was produced from the assessments.
86
-------
SDC-0055-012-TB-2009
December 31, 1992
Candidate Architectures
Five candidate architectures have been identified:
Time-sharing
Client/Server
Distributed Database
Cooperative Processing
Store-and-Forward (Two-Tiered)
These five candidate architectures are discussed on the following pages.
87
-------
SDC-0055-012-TB-2009
December 31, 1992
Time-sharing
The traditional time-sharing approach consists of dumb terminals connected to a central mini
or mainframe computer that manages all databases, processes all applications, and handles all
user interfaces. A recent variation on this model is the development of "screen scrappers,"
which are software applications that provide graphical interfaces to users and process
transactions between PC terminal emulators and a central computer. "Screen scrappers" may
provide some data-validation and help facilities; however, they do not store operational data.
The application and operational data stores all reside and operate on the central host
computer.
The diagram below depicts the time-sharing architecture.
Selected:
To minimize change to
environment
To migrate existing
- application
For applications th
- cannot benefit
from a GUI
Cost reasons
Mini or Mainframe
Central Server
DBMS
Application
User Interface
Processing
Terminals
-------
SDC-0055-012-TB-2009
December 31. 1992
Client/Server
The client/server approach consists of many client workstations or PCs connected to a central
server or computer. Client/server software manages a tightly coupled relationship between
client processes and server processes. Workstations typically handle user interface.
Applications may either be retrieved from the server or reside on the client. In either case,
the application executes on the workstation, while the server centrally stores the databases
and perform database-management services.
The diagram below depicts the client/server architecture.
D
Intelligent Workstations
Server
DBMS
Datastorage
Application Storage
Selected:
To centrally control data
and functions
Client downloads
from Server
Application processing
User interface
processing
89
-------
SDC-0055-012-TB-2009
December 31, 1992
Distributed Database
The distributed database approach utilizes one logical DBMS operating across multiple
physical computers, generally at separate geographic locations. Distributed database
computers may be connected with many intelligent workstations that individually process
applications and handle user interface.
The diagram below depicts the distributed database architecture.
D
DBMS
Machine
Intelligent Workstations
Selected:
To fundamentally
'lange
process strategy
To gain flexibility and
end-user productivity
Manage workload in
Integrated hosts, each
provides:
Application processing
Synchroniztion by DBMS
90
-------
SDC-0055-OI2-TB-2009
December 31, 1992
Cooperative Processing
The cooperative processing approach provides for the exchange of data between two or more
computer systems performing independently. Each computer provides database-management
services to its user community and interacts with other computers to exchange selected
information. Generally the processes running on the various computers have knowledge of
one another and essentially "co-operate," exchanging information transparently to the user.
The diagram below depicts the cooperative processing architecture.
PC. Mini, or
Mainframe
Each host:
DBMS
Application
Datastorage
Selected.
To support varying
functionality
To maintain centralized
control of data
To utilize existing resources
Each host:
Application processing
Datastorage
Synchronization by
application
91
-------
SDC-0055-012-TB-2009
December 31, 1992
Store-and-Forward
Store-and-forward is a two-tiered approach. While computer systems may be physically
connected, applications do not directly intercommunicate and do not have "knowledge" of
one another. Typically, extracts of databases from a "local" computer are performed, then
physically or electronically forwarded to a "remote" computer. The database extract is then
imported into the database system residing on the "remote" computer. Batch programs may
be written to facilitate extract, store, forward, and import processes.
The diagram below depicts the store-and-forward architecture.
a c
D
D
PC/Desktop
Local mini,
Mainfram
DBMS
Applications
User Interface
92
-------
SDC-0055-012-TB-2009
December 31, 1992
Mapping of Candidate Architectures to the PWSS Technical
Architecture
The recommended PWSS Technical Architecture is a composite of architectural candidates
applied at each organizational level and between organizations. Analysis for the
recommendation addressed four user categories:
PWS and Lab
Primacy Agency
EPA Region
EPA Headquarters/NCC
The analysis descriptions that follow present the architectural candidates considered most
likely to be used at the different organizational levels. An illustration of the complete
architecture is presented on the fold-out page at the end of this Chapter.
PWS and Lab
At the PWS and Lab levels, architectural options are limited. Neither type of site is a
candidate for full PWSS-application implementation, and the actual technical architecture for
these sites cannot be mandated by the PWSS program. The architecture for these levels
consists of PCs or workstations running low-end (less than full PWSS functionality)
application shells and commercial communications software. This architecture would enable
the sites to interface with the Primacy Agency level on a time sharing basis to do uploading
of required data and change requests and to do read-only querying of information stored at
higher levels in the architecture. Communication would be through dial-up access or leased
line for sites with appropriate hardware.
More advanced communications options are envisioned for the Labs to support connection
of PWSS to Lab data systems using electronic data interchange (EDI). The Lab-PWSS
component would receive and format data from the Lab's data system, and would enable the
forwarding of data on a periodic basis to the Primacy Agency.
93
-------
SDC-0055-012-TB-2009
December 31, 1992
Primacy Agency (State/State Region)
Primacy Agency architectural options are more varied than PWS and Lab options. Some
States have complex and fully functional PWSS systems already in place that would only
need interface access to the national level PWSS. Other States have virtually no existing
systems. Still other States have some hardware and software capability that either would be
replaced by the new PWSS applications or would have to interface with them.
States desiring to continue use of existing automated systems could adopt one of the
following approaches:
Modify existing State software to conform to the data and interface requirements of
PWSS.
Implement a PC-based PWSS interface to maintain an interface between the State system
and the national PWSS system. Since this interface approach would have the least
impact on existing State software, it offers the lower risk.
For Primacy Agencies having few PWSs, obtaining PWSS functionality would require
opting for one of the following architectures:
PC(s) connected to the NCC through leased or dial-up line(s) on a timesharing basis.
The State database would be established on the NCC computing environment and would
interact with the NCC PWSS environment as would any other State. Public access
would be through the NCC PWSS public-access gateway. (A gateway is a software
application with network protocols, hand-shake dialogues, and access-processing modules
that allow users to seamlessly access databases other than their own.) Lab and PWS
access would be manual; i.e., through a PWSS application shell and also by mailing
magnetic media or hard copy reports to the Primacy Agency.
PC-based PWSS applications processing cooperatively with the NCC. The PWSS
applications and database would reside on the State PC(s), which would interact with the
NCC on a cooperative basis. Public access, including access by Labs and PWSs, would
be through the State PC(s).
For States with large number of PWSs, obtaining PWSS functionality would require
implementation of a server-based PWSS system architecture. The PWSS system potentially
could include applications, communications, and database servers. Terminals connected to
94
-------
SDC-0055-012-TB-2009
December 31, 1992
the server would operate in a client/server architecture. The State PWSS system would
operate in a cooperative architecture with EPA's system. Connection would be established
through the communications server using leased lines. Public access, including PWS and
Lab access, would be managed through the communications server. Depending on the size
of the database and the number of users, the functions of the database server, application
server, and communications server may be performed by a processor ranging from a single
PC to minicomputer. Primacy Agencies below the State level would interconnect with this
mature system using any of the architectural options outlined above, depending on their work
load and data requirements.
EPA Region
Two architectures would be supported for EPA Regions: timesharing by connection with the
NCC, and client/server on a Regional LAN. Timesharing would support the majority of
Regional functions. Client/server would be most appropriate for an EPA Region with
Primacy, or for downloading selected data from the NCC for Regional analysis. Public
access is not envisioned at the Regional level.
EPA Headquarters/NCC
EPA Headquarters would be supported using the same approaches developed for the EPA
Regions. Public access would be accomplished by dial-in to the NCC.
Software Considerations
The PWSS system is being developed using the Texas Instruments Information Engineering
Facility (TEF) computer-aided software engineering (CASE) tool set. The initial
application environment will be the NCC mainframe computer using the MVS operating
system and DB2 database system. Workstations at EPA, EPA Regions, and States are
envisioned to include Microsoft Windows, OS/2 Presentation Manger, VAX VMS, and
UNIX operating systems. The Current Operating System Comparison exhibit, which
follows, summarizes some of the advantages and disadvantages of the principal operating-
system candidates.
95
-------
SDC-0055-012-TB-2009
December 31, 1992
The DBMS for workstations, minicomputers, and LANs will be varied; however, each
must be compliant with Structured Query Language (SQL). (SQL is the standard open-
system compliant language for building database queries.) Candidate DBMSs for
workstations and minicomputers include DBM, ORACLE, INFORMIX, and
SYBASE.
The selection of supported DBMSs will be discussed further in Chapter 5, which outlines
the Information Strategy.
Three options for the technical architecture are presented in the "Statement of Technical
Direction," which follows. The phasing of the implementation and the importance of making
use of available hardware and software serve to differentiate the options.
Option one, for example, details the initial automation of "have not" States with basic
PWSS functionality, moving over time into option two, where States with full or partially
automated PWSS programs are brought into the system. The Technical Architecture
diagram, which follows, depicts the options defined in the "Statement of Technical
Direction."
96
-------
SDC-0055-012-TB-2009
December 31, 1992
OPERATING
SYSTEM
TECHNICAL
FEATURES
ADVANTAGES
DISADVANTAGES
DOS
Standard
operating
system for
PCs. In use
since
introduction
of PC
Widespread use
Several suppliers
Mature operating system
User familiarity
Much available low cost
applications software
640 Kbyte DOS memory partition
PC technology trends (more
processing, more memory) not fully
utilized with DOS
May be nearing end of life-cycle for
use in newer powerful PCs
WINDOWS
NT
Full 32-bit
operating
system with
graphical
(e.g.
windows)
user
interface
Compatible with Windows 3.0
Large compatible third party
applications software base
Compatible with DOS applications
Runs on many different computing
platforms (PCs to RISC machines)
for wider spectrum of applications
Has potential to become new
standard PC operating system
Not yet released m commercial version
OS/2
Full 32-bit
operating
system with
graphical
(e.g.
windows)
user
interface
Uses full capabilities of modern
PCs
Low cost
Computing platforms running OS/2
are also low cost
Can run multiple DOS partitions
Not widely used
Lack of low cost third party software
packages
Single supplier
UNIX/
POSIX
UNIX/
POSIX has
become a
standard"
for most
modern mid-
range to
upper range
computing
systems.
Standardization
Portability
Wide-use, proven with good
software support tools such as X-
wmdows, OSF/MOTIF, and
applications.
UNIX-based workstations tend to cost
more than PC based systems
There are no "good" inexpensive UNIX
operating systems for PCs
UNIX application software (e.g.
wordprocessors, spreadsheets, etc)
are limited and more expensive (up to
10 times) than PC-based equivalents
Current Operating System Comparison
97
-------
This page intentionally left blank.
-------
PAGE NOT
AVAILABLE
DIGITALLY
-------
SDC-0055-012-TB-2009
December 31, 1992
Three PWSS architectural options are presented:
Option One
The basic low-end architecture is a national system residing on a time-sharing mainframe at the
NCC; the system would have direct connections with Regional offices nationwide through the
EPA backbone. Application shells would reside on Regional office computers and be used to
examine and report on information obtained from the States. States having their own application
systems would retain their structures, but would have communication servers with appropriate
PWSS software to facilitate transmission of State data to the national level. Individual PWSs
and Labs would be encouraged to acquire PCs or intelligent workstations and use leased-lme or
dial-up connections with the State or State Regional offices for electronic data interchange (EDI).
The PWSS application shell and communications software would be available to PWSs and Labs
having PC/workstation systems that enable the connection.
Option Two
The high-end solution consists of tailored PWSS application systems functioning at each Primacy
Agency; the systems would communicate interactively with PWSs, Labs, and national level EPA.
The architecture would be a combination of client/server and cooperative processing
architectures, whereby Primacy Agencies maintain control over their own data while allowing
querying and extraction of selected information. The national database would house summary
information and such specific sample and sample analytical-results as needed for rule and
regulation formulation and trend analysis. Each State level system would be connected to the
national network by dedicated lines to facilitate data transfer and speed of access. The central
national database would support both national office LANs and Regional office systems.
Option Three
The recommended solution is a marriage of the two previous solutions. While PWSS application
systems would be provided to States having limited (or no) automated capability. States hav.ng
fully functional systems would attach to the PWSS system PWSS interface systems servers over
leased-line or dial-up connections. Portions of the PWSS system would gradually be incorporated
into these existing systems, the desired end being full replacement of the existing system by
PWSS over time. Primacy Agencies having partially automated systems would adopt pieces of
PWSS that replace their current modules; they would acquire those PWSS modules that
automate manual portions of their systems. This would be done over time based on the
availability of PWSS modules. Initially, communications would be provided either through leased
lines from Primacy Agencies that require direct connectivity to the EPA communication network
or through dial-up connections where leased lines are impractical. Within Primacy Agencies,
PWSs and Labs would be encouraged to establish EDI connections with the State PWSS
systems.
Statement of Technical Direction
99
-------
SDC-0055-012-TB-2009
December 31, 1992
RECOMMENDATION
While all three architectural alternatives are possible over time, the third option presents the
most logical solution for meeting the needs of EPA and the Primacy Agencies. For the first
phase of implementation, by concentrating on those Primacy Agencies with little or no
automated solutions, the PWSS ISM will make the best use of economies of scale by providing
immediate improvement to the quality and quantity of data available. This solution would also
provide nationally maintained basic PWSS modules that would be modifiable by Primacy
Agencies, reducing the need for the Primacy Agencies to maintain large system-development
staffs. The third option provides for a partially distributed database consisting of State-specific
data residing at the Primacy Agencies and having a national database for summary and trend
data as well as selected State-specific data used in regulation and rule development. The
recommended solution provides for:
Nonautomated Primacy Agencies being brought up first with basic functionality.
Primacy Agencies maintaining their own data and cooperatively sharing data with EPA.
The national PWSS database housing summary and historical data as well as selected sample
and sample analytical results for regulation development and trend analysis.
PWSS-developed interface systems interconnected to existing full-function Primacy Agency
systems to transfer selected data to EPA.
Flexible communication network options using existing leased-line and dial-up capabilities and
supporting nonelectrical transfer of magnetic media where appropriate.
Communications from the State level to EPA using existing EPA network facilities.
Phased implementation allows all Primacy Agencies to evaluate the new PWSS applications
and encouraging State "buy-in."
Providing the best use of existing hardware and software.
The recommended option provides the necessary flexibility, scalability, cost effectiveness, and
ease of implementation not available from the other options. It will have the least impact on the
current environment, while providing the greatest level of functionality to all levels of the
system.
conT<
Statement of Technical Direction
100
-------
-------
Chapter 5
Analysis of Information Strategies
-------
SDC-0055-012-TB-2009
December 31, 1992
The Information Strategy
The Information Strategy provides the blueprint for implementing the PWSS ISM Project,
including a prioritized development plan and implementation schedule. The Information
Strategy was developed using the following steps:
Principles of the Strategy. The general principles for developing the strategy
are determined to help establish priorities for development.
Development Prioritization. The specific priorities for system implementation
are determined, considering the importance of the particular business systems
to accomplishing the organization's mission.
Technical Capability Projects. Specific technical projects required to develop
essential technologies demanded by the Technical Architecture are determined.
Implementation Schedule Options. The implementation schedule options are
developed based on resource constraints. For the PWSS ISM Project, the
implementation schedule options were based on three levels of resources.
Organizational Concepts. Organizational concepts that relate to developing the
software required to implement the PWSS ISM Project are outlined.
Next Steps. The follow on systems development activities are outlined.
Principles of the Strategy
The Information Strategy for the PWSS ISM Project is based on the following principles:
Initial development for states with limited automation capabilities
Interface with mature state systems
Modular development and phased implementation of system components
Early development and refinement of a standard user interface.
Each of these principles will now be discussed in detail.
101
-------
SDC-0055-012-TB-2009
December 31, 1992
Initial Development for States With Limited Automation Capabilities
Some states have little in the way of automated help for their drinking water programs. The
intent of the PWSS ISM Project is to begin by targeting development that will aid these states
with limited automation capabilities. Selected states with limited automation capabilities will
receive the initial PWSS component releases developed during the Rapid Application
Development (RAO) and Business Area Analysis projects. Incremental implementation
allows for rapid development and implementation of certain critical portions of the database,
while the long-term project continues to be developed in the background.
Interface with Mature State Systems
Some states have already spent considerable resources developing their own systems for basic
inventory and water quality data maintenance, electronic data reporting, violation calculation,
compliance and enforcement tracking and reporting, and other areas. The PWSS ISM
project will develop interfaces, when feasible, to allow the existing systems to interface with
the PWSS data structures. Additionally, interfaces with state electronic data interchange
(EDI) systems will be explored, with potential capabilities to accept selected data directly
through EDI systems, avoiding the re-entry of electronic data.
Modular Development and Phased Implementation of System
Components
Modular development and phased implementation of system components will allow early
fielding of critical capabilities and provide time to test and refine components throughout the
development life cycle. Modules supporting core business functions constitute the baseline
system and provide essential means to comply with Federal enforcement and data reporting
requirements. Supporting and ancillary system business functions provide the means to
support the full range of primacy implementation requirements.
Early Developmental Refinement of a Standard User Interface
All PWSS ISM program business systems will be supported by a standard graphical user
interface (GUI). The standard user interface will be developed during the first development
project and refined throughout the system development life cycle. The user interface will
include pull-down menus, user help, and limited data editing facilities.
102
-------
SDC-0055-012-TB-2009
December 31, 1992
Development Prioritization
The PWSS Information Strategy Plan has identified eight business areas that need to be
developed. As noted in the Business System Architecture, the prioritized business areas are:
Inventory
Field Surveillance
Compliance
Water Resource Planning
Technical Assistance
Regulation
Outreach
Management and Budget
The prioritized development plan was determined by first considering the relative
importance of the eight business areas. The business systems within each business area were
then analyzed and categorized as follows:
Core business systems may be thought of as the backbone of the day-to-day
operation of the PWSS program. Thus, it is logical that most all of these
business systems will be automated in their entirety. Business systems
classified as core include:
Compliance Determination
Enforcement
Field Surveillance
PWS Characterization
Lab Certification
Primacy Implementation
Public Notification
Sampling
Monitoring Requirements Development
103
-------
SDC-0055-012-TB-2009
December 31, 1992
Support business systems serve a supporting role for the core business
systems. Although most of the business systems in this category should be
automated, many of these business systems could be manual processes.
Business systems falling into this category include:
Allocation
Coordination
Forecasting
Funds Management
Natural Resources and Demographics
Outreach
Permitting
Technical Support
Training Support
Vulnerability Assessment
Water Resource Characterization
Ancillary business systems consists of information of importance to the PWSS
program that is obtained from a wide-range of sources. A few of these
business systems may be automated in part or entirely. Many of these
systems, however, will support the PWSS program using a manual interface.
Business systems that make up this category include:
Contingency Planning
Disease Prevention and Assessment
Health Advisory
Information Systems Management
Operator Certification
Regulation Development
Resource Management
Standards Development
Technology Assessment
The figure on the following page summarizes the business system categorization.
104
-------
BUSINESS SYSTEM CATEGORY SUMMARY
D
n
-------
SDC-0055-012-TB-2009
December 31, 1992
Technical Capability Projects
The development plan must also consider the development of specific technologies required
to support the PWSS ISM Project. Within the development plan, these technologies are
developed by technical capability projects.
The SDC project team has identified seven technical capabilities that are essential for
satisfying the Technical Architecture. Realizing that these capabilities could not all be
phased-in at the same time, the SDC project team assigned priorities to these capabilities
based on their criticality to the PWSS program. The required technical capabilities include:
Priority Technical Capability
1 Dial-In State Environment at NCC.
States with limited automation capabilities must be
provided sufficient data processing and storage facilities
early in the development cycle. One option to satisfy
this requirement is to develop a technical means to
establish state databases on the EPA mainframe
computer. This solution provides a fully functional
system without making a major investment in computer
hardware within the state environment.
2 User Interface
The PWSS user interface will consist of a set of
standardized elements and interaction techniques. PWSS
will rely on a graphical user interface (GUI) that will
have the same "look and feel" across all applications to
all user groups.
3 Interface System
The PWSS program will provide interfaces to external
systems, when feasible. This capability will be limited
to transferring, formatting, and verifying files for
uploading to the National database. Additionally, this
technology will interface selected EDI systems to PWSS.
106
-------
SDC-0055-012-TB-2009
December 31, 1992
4 Client/Server
The Client/Server architecture will be required to support
large state systems. This technical project develops the
technology required for client/server operation.
5 Cooperative Database
Cooperative database technology will be required to
support interaction between state region, state, and
national systems.
6 Public Access Interface
In support of the EPA's Public Access Program, the
PWSS program will develop a Public Access Interface to
give the general public and other organizations (e.g.,
Association of State Drinking Water Administrators,
USGS, etc.) access to the PWSS system. PWSS
information available to these users will be identified in
EPA's Online Library System, which can be accessed via
a dial-in access commercial telephone circuit. The
electronic information services offered by EPA's Public
Information Center is also available to the public and
other organizations wishing to access PWSS database.
PWSS will also be available to universities and other
scientific institutions via EPA's Internet. Similar
capabilities for public access to state systems will be
explored.
7 User-Defined Reports
This technology is required to allow users to create
tailored reports and to produce files for import to other
software packages (e.g., SAS).
The PWSS ISM Development Plan
This analysis addresses the recommended sequence in which the business areas should be
developed, assigns a business area analysis (BAA) Roman numeral to each business area,
107
-------
SDC-0055-012-TB-2009
December 31, 1992
identifies two Rapid Application Development (RAD) projects, and correlates how the
technical capabilities described above will be phased-in with these development projects.
The chart on the following page displays the general development plan and the phase-
in points for the technical capability projects.
Implementation Schedule Options
Three implementation schedule options have been defined based on the system category
breakdown presented in the previous section.
Option 1 represents the full implementation of the PWSS Business System
Architecture by the end of FY 95. This schedule provides for design and development of
each of the business systems that make up the architecture, and includes full automation of
the core and support systems as well as bridges to the ancillary systems needed by the
design. It will deliver the full functionality of the core and support business systems and will
automate the connections needed to enable the exchange of information with the ancillary
business systems that have been identified. The full development schedule is presented in the
Option 1 foldout at the end of this section.
Option 2 implements the core and support business systems. It does not include the
automation of the bridges to the ancillary systems. The definition of the interface links will
be completed, but fully-automated electronic connections will not be developed. Data will be
able to be shared with these ancillary processes, but online connection and data transfer may
not be included in the final product of this option. This option would provide complete
PWSS functionality and will interface with the ancillary business systems, but will not
provide for the automated interchange of data between PWSS and the other systems outside
of the PWSS automation boundary. The development schedule for this option is presented in
the Option 2 foldout that follows.
Option 3 only develops the core functionality of PWSS. The support and ancillary
business systems would not be included in the automation boundary of PWSS at this time.
This does not mean that these systems could not be automated at a later date; only that they
will not be automated as part of this option. The development of the core business systems
would provide minimum functionality for PWSS. Connections to the support and ancillary
systems would be defined and preliminary designs for these interfaces would be created.
Actual connections between the PWSS system and these business systems would be
accomplished through indirect means such as transfer of electronic media and hard copy.
Option 3 represents the lowest cost and the shortest development time frame with completion
of the core systems scheduled for the end of December 1994. The Option 3 foldout presents
the development schedule for this option, and appears at the end of this section.
108
-------
TECHNICAL CAPABILITY PROJECTS IMPLEMENTATION PHASE-IN POINTS
£) = Technical Capability Partial Implementation Point £ « Technical Capability Full Implementation Point
Note: The fully shaded circles under BAA VIII Indicate that all technical capabilities have been Implemented
*
N)
-------
SDC-0055-012-TB-2009
December 31, 1992
Each of these options will enable PWSS to be implemented in support of both national
EPA and state needs. As previously mentioned, the proposed development schedules for
each of the options are presented on the following pages. The differences in these options
reflect the differing levels of automation required by the three options.
110
-------
PAGE NOT
AVAILABLE
DIGITALLY
-------
This page intentionally left blank.
-------
PAGE NOT
AVAILABLE
DIGITALLY
-------
This page intentionally left blank.
-------
PAGE NOT
AVAILABLE
DIGITALLY
-------
This page intentionally left blank.
-------
SDC-0055-012-TB-2009
December 31, 1992
Organizational Concepts
Development Coordination
Implementation of the ISP requires effective management of a shared development
environment. The development coordination approach assigns responsibilities and fosters
necessary interactions required for successful implementation of Business Area Analysis
projects. Additionally, a Development Coordination Approach contributes toward:
Producing highly integrated business systems.
Improving the quality of the systems being developed through the
establishment and enforcement of development standards.
Improving productivity by facilitating the sharing of reusable processes and
procedures, as well as other design and development objects.
Within the EPA Systems Development Center, development coordination
responsibilities are shared between elements of the Development Methodology and
Maintenance Group (DMMG) and the development project team.
The interrelationship of development coordination functions is detailed on the SDC
Development Coordination Template diagram on the next page. The key functions presented
are:
Data Administration
Data Base Administration
Encyclopedia Administration
Project Model Coordination
Project Application Architect
Methodology Guidance
Training
Three functions (data administration, encyclopedia administration, and methodology
guidance) are performed primarily within the SDC's Development Maintenance and
Methodology Group (DMMG). Two functions (database administration and training) are
performed by both the DMMG and the PWSS project staff. PWSS model coordination and
the PWSS application architect functions are performed within the PWSS project. The SDC
Development Coordination Template also shows the major relationships between functions.
For example, while training may be provided to all functions, within the context of
development coordination training is primarily the link between methodology, project model
coordination, and the development teams.
114
-------
SDC-0055-012-TB-2009
December 31, 1992
This page intentionally left blank.
-------
PAGE NOT
AVAILABLE
DIGITALLY
-------
This page intentionally left blank.
-------
-------
SDC-0055-012-TB-2009
December 31, 1992
Appendix A
Information Engineering Methodology (IBM) Overview
This appendix presents an executive level overview of the Information Engineering
Methodology.
-------
SDC-0055-012-TB-2009
December 31, 1992
Appendix A
Information Engineering Methodology (IEM)
Overview
Software development has traditionally been process driven, focusing on developing
computer code to automate processes that manipulate data. That is, each process has one or
more associated data sets, and often the data relationships are embedded, to some degree,
with the process. If there is a need to change the process or functionality of the system, the
resulting data set must also be modified. Consequently, as the system matures and
functionality changes, so must the data. This process-driven approach often precipitates
significant maintenance costs, and seriously limits efforts to share or to integrate data.
The PWSS Program has chosen to respond to this information management challenge
by incorporating Information Engineenng (IE) concepts and principles into software system
development efforts. IE is data-centered and process driven. Data-centered means that the
methodology is centered on the most stable aspect of the business, as the data and their
relationships change slowly. For example, the type of information maintained about
employees is relatively stable, even though the way employee information is used may vary
greatly based on legislation or personnel regulations (i.e., the changes directed by the
Privacy Act of 1974 on access to information about employees).
Process-driven means that methodology focuses on developing basic building blocks to
implement functions. Data relationships are defined apart from the descriptions of the
functions and their resulting processes. These building blocks are called processes and may
be used to support several different organizations.
The detailed models of unctions and data are linked through association matrices,
defining the precise interactions of data and functions. As systems are enhanced or
developed, designers consider all interactions (existing and planned) and build towards the
envisioned architecture. Should changes occur in the function or data, the developer updates
the appropriate model and confirms the interaction. As a result, information systems can be
more readily adopted to the changing needs of the enterprise without major redesign or new
development of systems.
The Information Engineering Methodology (IEM) is a formal approach for the
development of information systems focused primarily on detailed analysis and modeling of
A- 1
-------
SDC-0055-012-TB-2009
December 31, 1992
an organization's business. As shown in the exhibit below, the methodology begins at the
strategic level with the Planning Stage and proceeds through the life cycle to the Retirement
Stage. Information Strategy Planning is the principle component of the Planning Stage.
The life cycle activities build on the information developed during the ISP by iterative
application of software engineering techniques and organization modeling activities. A
comprehensive model of the business is developed which includes goals, objectives,
strategies, critical success factors, performance measures as well as detailed organizational,
functional, and data models for the enterprise.
The remainder of this section provides a summary of the Information Engineering
Methodology, followed by a detailed description of the planning activities performed to
develop the PWSS ISP.
Planning Stage
Information Strategy Planning (ISP) is concerned with identification and analysis of the
mission, goals, objectives, strategies, performance measures, information needs, data; and
functions of an organization; the development of a target information environment to satisfy
the information needs; and the development of a strategy to achieve the target information
environment. This high-level view is extremely important in laying the foundation and in
A-2
-------
SDC-0055-OI2-TB-2009
December 31, 1992
setting the direction for follow-on system development activities. Three architectures are the
core products of the ISP. The core products are the Information Architecture, which defines
the activities performed by the organization and the information needed to perform the
activities; the Business System Architecture, describing the business systems and data stores
required to support the Information Architecture; and the Technical Architecture, describing
the hardware and software environment needed to implement the Business System
Architecture. Information is gathered using Executive Information Planning (EIP) and Joint
Requirements Planning (JRP) facilitated work groups to elicit information needs and to gam a
detailed understanding of the business of the enterprise.
Analysis Stage
During the Analysis stage, information engineering activities are primarily focused on
gaining a better understanding of the data, the basic business process, and the more detailed
interactions of the data and processes. Business Area Analysis (BAA) begins with planning
and conducting additional information gathering. The results are analyzed, using IEF tools
to develop data and process diagrams and to update the project. The outputs from the IEFrM
CASE tool, along with visual prototypes, are used to review the analysis results.
Involvement by subject area experts during all phases of the analysis ensures that the client's
functional area experts at all organizational levels understand the model of their data and
business activities. These prototypes are rapidly constructed, with minimal functionality, to
represent only the data requirements. The outputs of IEF along with the prototype are used
to encourage discussion and obtain feedback in facilitated sessions. Once the subset of a
functional area has been stabilized, other fundamental entities may be identified for addition
to the model. This process will be continued until all data requirements are addressed.
Design Stage
The objective of the Design stage is to determine "how" the set of needs identified and
specified in the first two stages will be satisfied in terms of an information system. The
products of this stage are designs based on data and process architectures, man-machine
interfaces, and system administration procedures.
The design process proceeds in two parallel thrusts: data design and process design.
In data design, the logical data model is translated into a physical data structure design that
will be used to produce the physical data base tables. The logical data model is analyzed to
ensure the integrity of all relationships, cardinalities, and definitions. Open issues that
preclude the successful design of the data base are documented. The open issues are
resolved in Joint Application Design (JAD) facilitated sessions with the client functional area
A-3
-------
SDC-0055-012-TB-2009
December 31, 1992
experts. The CASE tool is used to generate data structure diagrams showing the resultant
data base design.
The procedure design is developed by implementing the elementary processes defined
in the BAA within online or batch procedures. The resultant logical model transformed into
a representation of the physical data structure. The detailed system design includes dialogue
flow diagrams and procedure action diagrams. Screen and report layouts are also developed.
Data conversions and bridges to current systems are also designed.
Rapid Application Design (RAD) can be applied during the design stage as an
alternative approach for certain types of systems development projects. The RAD approach
uses a small team of highly experienced developers to design and implement well-defined
projects within a compressed development cycle. The RAD approach features strong reliance
on a continuous interaction with the system manager and users throughout the development
process. Concepts are prototyped and approved designs are documented and implemented.
It is important to document all of the key options considered and the reasons for selecting a
particular option. If this process is not followed, the same decision process could be
repeated again and again, reducing productivity. At the end of each prototyping any open
design issues are formally recorded and tracked to closure.
Development Stage
The preferred approach to development is automated code generation using a fully developed
IEF project model. Of course, since not all target environments are supported, capabilities
for manual coding may be a requirement.
Languages currently supported by IEF include COBOL and C. DB2, DBM,
Oracle, and RDB are the supported databases. Operating environments include IBM (CIC,
IMSDC, and TSO), DEC VAX, UNIX, and OS/2. The code construction is performed on
mainframe and personal computer platforms and utilize the CASE tool's procedures,
dialogue flows, and screen designs.
Unit and integration test plans are reviewed during the walkthroughs to ensure that the
planned testing addresses all requirements, both functional and performance. Following the
walkthroughs, the code is unit and integration tested. If required, data bases are constructed
to support both the testing and future operations of the system. For some projects, hardware
and software may be installed during this phase in order to meet construction and operational
requirements.
A-4
-------
SDC-0055-012-TB-2009
December 31, 1992
Implementation Stage
Implementation planning begins back in the analysis and design stages during documentation
of current systems and specification of conversion requirements. The implementation plan is
developed in collaboration with the client and operators of the target host computer and
includes a schedule of 1) the hardware (if any) and software installation, 2) user acceptance
testing, and 3) final cut-over from the current system. It defines how any existing electronic
data will be transferred to and formatted for the new application and how any non-electronic
data will be gathered and input. The Transition Plan ensures quality of the conversion
software and the converted data by rigorous testing and evaluation of sample data sets using
file comparison tools to verify that outputs of converted processes match original outputs.
The acceptance test procedures are developed in close collaboration with the client
and are administered using the test plans developed in the previous stage. Testing tools are
used to run scripts and compare actual results with the planned results. All problems
identified are recorded and tracked to resolution, including failure mode analysis to isolate
process related problems, as well as fixes to developed products.
User training is developed and is provided prior to system cut-over.
System Maintenance Stage
Maintenance is tailored to specific types of maintenance activities. One activity is minor
system enhancements to accommodate changes in either the computer of the client's
operating environments. The second type of maintenance activity involves analysis and
resolution of identified problems. For both types of activities a maintenance request is
generated and used to track the activity through its resolution.
Before any maintenance request can be implemented, the proposed change must be
processed through the Software Configuration Management procedures and be approved by
the Change Control Board. Approved maintenance tasks are scheduled and prioritized.
For implementing software maintenance requests, the same Design and Development
processes that was applied to the original or last enhancement to the system is followed.
First, the modules requiring updates are identified and the CASE tool products or source
code is checked out through the configuration control process. If the source code is not
structured, then a re-engineering tool is used, if possible, to structure the source code. If
source code or CASE tool products are not available, then a reverse engineering tool can be
applied. Manual reverse engineering analysis may also be required.
A-5
-------
SDC-0055-012-TB-2009
December 31, 1992
After CASE tools products or the source code has been acquired, the changes are
made following Design and Development stage processes. This includes the creating of test
data, if there is no original test data. Next, unit testing is performed, followed by systems
integration and regression testing. Upon successful completion of the regression testing, the
system is turned over for final independent verification and validation testing.
Problems requiring analysis and resolution are routed for application by Hotline
Services if they are available for the system. If it is determined that software changes are
required to correct the problems, a software maintenance request is generated and tracked to
resolution.
When a system becomes operational, on going user training and consultation via its
Hotline service, User Support, and Information Services Support activities are outlined and
implemented where feasible.
With this overview setting the context, we now turn to a more detailed presentation of
the Planning Stage of the IEM.
The Planning Stage of Information Engineering
An overview of the ISP phase of information engineering is shown on the following page.
Information strategy planning begins with work planning, including development of a detailed
project plan and work schedule. Naming conventions for objects entered into the IEF
toolset are also established). Information gathering focuses on developing the details
required to analyze the strategic planning objects, including missions, goals, strategies,
objectives, critical success factors, and performance measures. An analysis of the
organization's hierarchy is also conducted, including documenting the missions and high-level
functions of the major elements of the organization.
The next stage of information strategy planning includes data analysis and function
analysis. This stage analyzes the detailed information gathered during the analysis of
business strategies and policies, and includes analysis and prioritization of information needs
and an assessment of business problems noted during the executive interviews and planning
sessions. Preliminary definitions for data and function planning objects are developed as
well as preliminary relationships among the entity types. These relationships are represented
on a high-level entity relationship diagram.
The core products of the information strategy plan are developed during the
interaction analysis stage. These products are the Information Architecture, Business
Systems Architecture, and the Technical Architecture. Additionally, the Analysis of
A-6
-------
SDC-0055-012-TB-2009
December 31, 1992
Information Strategies is also developed with recommendations for proceeding from the
current environment to the objective environment represented by the three architectures.
Throughout the development of the ISP, client confirmation activities are performed,
including preparation of bi-weekly status reports and review meeting at the conclusion of
each stage of the process. The review meetings are an essential component of the process
and help to ensure scheduling and other issues are identified. A formal management
presentation of the results of the information strategy planning is developed and presented to
the project sponsors at the conclusion of the effort. The presentation can also serve to
provide feedback to the executives and mid-level managers to participated and interacted with
the ISP Team throughout the project.
A-7
-------
-------
SDC-0055-012-TB-2009
December 31, 1992
Appendix B
Current Technical Environment
This appendix details the current technical environment.
-------
SDC-0055-012-TB-2009
December 31. 1992
Appendix B
Current Technical Environment
Technical Environment Assessment
This technical assessment describes the current PWSS technical environment. The Federal
Reporting Data System II (FRDS-II) is the primary system supporting PWSS. The OGWDW
delegated day-to-day operational responsibility of FRDS-II to the Enforcement and
Implementation Division (EIPD). In addition to FRDS-II, a large number of other data base
systems collect and store data related to drinking water quality. This technical assessment
focuses on a selected number of key Federal and State systems that support various aspects
of the PWSS Program. These systems are candidates for data sharing with PWSS.
Key Federal Systems
Many large scale and small scale systems currently support the PWSS Program. The large
scale applications operate on a mainframe at EPA's National Computer Center (NCC) at
Research Triangle Park, North Carolina. The small scale applications run on a variety of
stand-alone microcomputer systems within in the immediate office environment. Appendix Q
shows the relationship of these current data stores to the entity types in PWSS.
Large Scale Systems
Large scale systems, operating on an NCC mainframe computer, analyzed during this
technical assessment include:
Comprehensive Environmental Response, Compensation and Liability Information System
(CERCLIS)
Environmental Review Tracking System (ERTS)
Facilities Index System (FINDS)
Freedom of Information and Control System (FIATS)
FRDS-II
B- 1
-------
SDC-0055-OI2-TB-2009
December 31, 1992
Grants Information and Control System (GICS)
National Water-User Data System (NWUDS)
Permit Compliance System (PCS)
Reach File (RF)
Storage and Retrieval (STORET) of U.S. Waterways - Biological System
(BIOS) and Water Quality System (WQS)
Water Quality Analysis Simulation Program (WASP4)
Water Body System (WBS).
CERCLIS
The CERCLIS information system version 3.0 will support EPA HQ and regions for the
management & oversight of the Superfund program. CERCLIS serves two purposes: to
maintain an automated inventory of abandoned, inactive, or uncontrolled hazardous waste
sites; and to act as the vehicle for the regions to report to headquarters on the status of major
stages of cleanup at sites. CERCLIS V3.0 will be developed with an in-depth look at the
long term information needs of state and other federal agencies in effectively managing clean
ups. CERCLIS V3.0 may be developed using a data base manager other than System 2000,
such as ADABAS. CERCLIS V3.0 will begin with a long-range study of the relationships of
CERCLIS to Federal Agencies.
ERTS
ERTS is a management information system used to track all Environmental Impact
Statements (E1S), in addition to other actions for EPA. ERTS stores a wide range of
environmental data and serves as a cross media system for use throughout the EPA.
B-2
-------
SDC-0055-012-TB-2009
December 31, 1992
FINDS
FINDS is a computerized inventory of facilities regulated or tracked by EPA. All facilities
are assigned unique Facility Identification numbers by FINDS that serve as cross-reference
numbers to facility information residing in the EPA program system. This function supports
cross-media data integration by tracking facility locations across EPA program offices.
FINDS is useful in integrating enforcement analysis, hot-spot determination, and risk
analysis.
FIATS
FIATS is an administrative system used by EPA's FOI Officer. The system tracks the status
of requests for information under the requirements of the Freedom of Information Act. The
data from this system is used for the Agency's annual FOIA activity report to Congress.
The system also reports types of requestors, program office caseload and performance, and
appeal activity. In conjunction with new FOI policies and procedures, the system streamlines
request processing and tracks and records the seemingly endless dispositions of a request or
the possibilities for responding to a request.
FRDS-II
The primary system supporting the current PWSS program requirements is FRDS-II. This
system maintains inventory and compliance data (violations and follow-up actions) reported
by primacy agents under the PWSS program. Headquarters EPA uses FRDS-II to provide
quarterly reports to other components of EPA and to satisfy external reporting requirements.
Headquarters, Regions, and States also use FRDS-II to perform oversight. FRDS-II
currently supports rolling quarter compliance data for the previous four quarters only and it
currently contains compliance information from 1980 to the present and relates follow-up
actions to specific violations. PWSS will replace FRDS-II.
B-3
-------
SDC-0055-012-TB-2009
December 31, 1992
GIGS
GICS is the EPA's management information system for all grant programs. This national
system is used by Headquarters, Regions, and States to administer and monitor grants. GICS
uses the ADABAS DBMS and the Natural Programming language to support data
requirements. Report menus for HQs, Regions, and Programs are available for batch or
on-line reporting. On-line data entry systems for the construction and non-construction
programs have been customized to provide for updating and tracking of the grant process.
NWUDS
NWUDS stores and retrieves data on site-specific water-use data and aggregate water-use
data. States routinely collect information in these areas for inclusion in the system, but the
level of detail and coverage varies by state. Most of the information in this system is still
valid even though the latest information available was collected in 1985.
PCS
PCS is a computerized management information system for tracking permit, compliance, and
enforcement status for the National Pollutant Discharge Elimination System (NPDES)
program under the Clean Water Act. PCS contains information on more than 63,000 active
water discharge permits issued to facilities throughout the nation. The Office of Water
Enforcement and Permits (OWEP) in the EPA is responsible for the operation and
maintenance of PCS. EPA Regional Offices and State users of PCS are responsible for the
entry and quality of the data in the system. The system components are (1) on-line and batch
data entry; (2) batch update; and (3) batch and on-line retrieval packages.
RF
The RF is a hydrographic database of the surface waters of the continental United States.
Elements within the database were created for the express purpose of performing hydrologic
routing for modeling programs, identifying upstream and downstream elements and providing
a method to uniquely identify any particular point associated with surface waters. Any point
within any of these databases can be associated with, and identified by a specific location on
any surface water element. The RF can be defined as the U.S. Surface Water Hydrographic
Identification Database.
B-4
-------
SDC-0055-012-TB-2009
December 31, 1992
STORE!
The STORE! system assists State and EPA officials in making pollution control decisions by
providing a capability to store, retrieve and analyze water quality information. Current
emphasis of control decisions are: issuing water quality based NPDES permits; inclusion of
toxic pollutants in water quality standards; evaluating water quality impacts of control
programs; and assessing levels of toxic pollutants, including dioxin and other bio
accumulative pollutants in the aquatic biological data, hydrologic data, stream reach data,
ground-water data, and other related information. The system is used by State and EPA
analysts to assemble and analyze data to support each of the above types of decisions.
WASP4
WASP4 is a generalized compartment modeling program for simulating water quality in
rivers, lakes, and estuaries. Linked with the various kinetic subroutines, WASP4 is used to
predict water quality response to waste water management strategies. Version 4.2 is linked
to the hydrodynamics program DYNHYD. Water quality kinetic subroutines are provided to
simulate conventional pollutants including, nutrients, algae,), and toxic pollutants (organic
chemicals, sediment) in the water column and benthos. WASP4 runs on a mainframe or a
microcomputer.
WBS
WBS contains state-reported information on the water quality status of specific water bodies.
States input data including causes, sources, and monitoring basis.
Small Scale System
Small scale systems, operating on a stand-alone microcomputer, that analyzed during this
technical assessment include:
Inventory of Certified Labs
Reg-In-A-Box
State Revolving Fund (SRF) Award List.
B-5
-------
SDC-0055-012-TB-2009
December 31, 1992
Inventory of Certified Labs
The Inventory of Certified Labs system contains a list of laboratories certified to do
compliance analyses and the chemicals and methods for which they are certified to test in
each state.
Reg-ln-A-Box
Reg-In-A-Box enables users to quickly find all National Primary Drinking Water Regulations
applicable to PWS's that have been promulgated or proposed through July 18, 1991.
Promulgated regulations include Surface Water Treatment Rule, Total Coliform Rule, Phases
I and II, Fluoride, Lead and Copper, and the pre-1986 amendment rules. Proposed rules
include Phase V and Radionuclides. The system includes the full Federal Register text, a
brief description, and unreasonable risk to health information for each rule. Reg-In-A-Box
features five different ways to access information: by reading the Federal Register, and by
PWS characteristic. All of the instructions for using this convenient way of accessing
regulations are contained within the application itself.
SRF Award List
The SRF Award List system tracks the amounts and dates of SRF grant awards to States.
Information contained in the system includes: the State to which the grant is being made, the
grant number, grant amount, date grant awarded, the appropriation from which the grant was
provided, and the amount of State match.
Key State Systems
Key state systems analyzed during this technical assessment include:
Model State Information System (MSIS)
PA State Water Plan System
Drinking Water Information System (DWIMS).
B-6
-------
SDC-0055-012-TB-2009
December 31, 1992
MSIS
The MSIS was developed by EPA for the express purpose of assisting the states to manage
their drinking water program. MSIS was divided into several modules, each of which
supported a specific functional area in the drinking water program. Examples of the modules
include: PWS inventory management, violations determination, and enforcement tracking.
Funding the maintenance of MSIS became cost prohibited as a result of the changing
drinking water requirements. As a result, EPA decided to discontinue supporting MSIS.
Despite this situation, a few states are still using portions of MSIS to support some of their
reporting requirements.
PA State Water Plan System
The PA State Water Plan System records and tracks water uses and discharges and maintains
an inventory of water storage facilities. Virtually all water users (industrial, mining, public
water system, power generation, irrigation, and domestic) are tracked by the system.
Information from the system is used to allocate current water usage and to plan for future
system needs. The system currently resides on a Burrough's mainframe as flat files, but will
be converted to the DEC/Oracle platform in the near future. Applicationc for the current
system were mostly developed in COBOL, but a few applications were written in
FORTRAN.
DWIMS
DWIMS was initially developed for States in Region V. In DWIMS, site inspectors use a
lap top computer and portable telephone to dial-in and make on-line updates to Public Water
System inspection results. The system is menu-driven and supports ad hoc queries and
compliance evaluations. DWIMS requires significant tailoring to meet the varying needs of
the states. DWIMS is currently used by a limited number of States.
Non-Automated System Interaction
PWSS will interact with the Drinking Water Regulatory Impact Analyses (RIA) system. This
is a paper collection of studies performed by the OGWDW in accordance with Executive
Order 12291. The order requires that an analysis of benefits and costs be performed for
every major rule to be promulgated by the PWSS Program and Underground Injection
Control (UIC's) Program. A regulatory impact analysis provides the EPA Administrator
B-7
-------
SDC-0055-012-TB-2009
December 31, 1992
with analyses of the potential costs and benefits of, and alternative approaches, to the
regulation of drinking water contaminants and/or injection practices.
PWSS will develop an automated capability to support future drinking water
regulatory impact analyses.
Information Needs
This subsection focuses on the information needs and how they are interrelated to the entities
types and organizational units.
Information Needs by Entity Type
Appendix N identifies the information needs with the entity type in which the supporting data
is stored. This exercise verifies that all information needs are supported by one or more
entity type.
Information Needs by Organizational Unit
Appendix O shows what information needs are required by which organizational unit. This
exercise assists in identifying which information need is shared by what organizational unit
and ensures that all of the information needs are needed by one or more organizational unit.
Current Environment Assessment
This assessment contrasts the relationships of the objects under development in PWSS to
those already existing in the PWSS Program environment.
Mapping of Entity Types and Current Data Store
Appendix M maps entity types to current data stores. In the context of this project, data
stores equate to the data base of the current system identified in this document. This
exercise assists in detecting if there are any entity types that have been overlooked or if there
is currently an entity type unsupported in the current information environment.
B-8
-------
SDC-0055-012-TB-2009
December 31, 1992
Business Functions Supported by Current Information Systems
Appendix P identities the business functions that are supported by which of the current
systems. This exercise assists in detecting if there are any business functions that have been
overlooked or if there is a business function that is unsupported in the current information
environment.
Current Data Stores Used by Current Information Systems
Appendix Q identifies the current data stores that are supported by which of the current
systems. This exercise assists in detecting if there are any data stores that are not being used
and if any data stores or organizational units have been left out of the preliminary
information architecture.
Organizational Units Uses Current Information Systems
Appendix R identifies the organizational units that are supported by which of the current
systems. This exercise assists in detecting if there are any current systems that are not being
used and if any current systems or organizational units have been left out of the preliminary
information architecture.
B-9
-------
n
-------
SDC-0055-012-TB-2009
December 31, 1992
Appendix C
JRP Participants List
This appendix contains an alphabetical listing of the participants of each JRP session, and also
an alphabetical listing of the contractor ISP Project Team members with their roles and
responsibilities.
-------
SDC-0055-012-TB-2009
December 31, 1992
San Francisco
August 18 - 20, 1992
Attendee
Mary Alvey
Tracy Bair
Ken Bousfield
Cliff Bowen
LouAllyn Byus
Stan Calou
JonDahl
Bill Davis
Fran Haertel
Peggy Johnson
Ron Johnston
Bruce Keith
Richard Lampert
Clint Lemmons
Corine Li
Dennis Martin
Doug Martinson
Jon Merkle
Tom Poleck
Bill Robberson
Jeff Sexton
Jim Walasek
Organization
Oregon Health Division
SAIC
UtahODW
CDOHG, ODW
Illinois EPA
US EPA Region VII
Arizona Dept of Environmental Quality
US EPA Region VI
US EPA Region VI
Washington State Dept of Health
SDC/SAIC Team
SAIC
US EPA Region IX
US EPA Region VIII
US EPA Region IX
SAIC
Alaska Environmental Conservation
US EPA Region IX
US EPA Region V
US EPA Region IX
US EPA Headquarters
OGWDW/TSD/Cincinnati
C- 1
-------
SDC-0055-012-TB-2009
December 31, 1992
San Francisco
August 18 - 20, 1992
Attendee
Larry Weiner
Organization
US EPA Headquarters
C-2
-------
SDC-0055-012-TB-2009
December 31, 1992
Arlington, VA
August 25 - 27, 1992
Attendee
Tracy Bair
Allen Basham
Mary Brewster
Chrysa Cullather
Jon Dahl
Claudia Darnell
Rob Daubenspeck
Doug Davenport
Jim Elder
Ray Enyeart
Barry Greenawald
Jeff Mass
Anne Jaffe Murray
Bruce Keith
Kathy Lynch
A.W. Marks
Dennis Martin
Evans Massie
John McFadyen
Doug McKenna
Darrell Osterhoudt
Darrel Plummer
Organization
SAIC
Virginia Dept of Health
US EPA Region III
Marasco Newton
Arizona Dept of Environmental Quality
US EPA Region IV
SAIC
Georgia EPD
OGWDW
OGWDW
Pennsylvania DER
US EPA Region III
OGWDW
SAIC
US EPA Region I
OGWDW
SAIC
Virginia Dept of Health
North Carolina Public Water Supply
US EPA Region II
Missouri DNR
Kansas DHE
C-3
-------
SDC-0055-012-TB-2009
December 31, 1992
Arlington, VA
August 25 - 27, 1992
Attendee
Yield Ray
Jeff Sexton
Charles Stringfellow
Steve Vassey
Larry Weiner
Sonny Wolfe
Larry Worley
Organization
Kentucky NREPC
OGWDW
SAIC
SCDHEC
OGWDW
SAIC
US EPA Region X
C-4
-------
SDC-0055-012-TB-2009
December 31, 1992
Arlington, VA
August 25 - 27, 1992
Attendee
Kenna Study
John Grace
Alan Roberson
Van Hoofhagle
Ron Decesare
Rey de Castro
Steve Clark
Lynn Curry
Linda Kemp
Jeff Markham
Marilynn Dokos
Organization
FLDER
Maryland DE
AWWA
FLDER
OGWDW
ASDWA
OGWDW
SAIC
SAIC
SAIC
SAIC
C-5
-------
SDC-0055-012-TB-2009
December 31, 1992
Name
Tracy Bair
Debbie Bruce
Chrysa Cullalfaer
Lynn Curry
Jon Dahl
Rob Daubenspeck
Marilyn Dokos
Barry Creenawald
Ron Johnston
Bruce Keith
Linda Kemp
Jeff Markbam
Dennis Martin
Adair Martinez
Evans Massie
Sonny Wolfe
Role/Responsibilities
Project Manager - Responsible and accountable for all aspects of the project.
Senior Analyst - Responsible for document control and deliverable coordination
Systems Analyst - Drinking water program analyst responsible for subject area support and analysis
and design guidance.
Senior Environmental Scientist - Expert on State drinking water programs responsible for subject area
support and expertise.
Environmental Scientist - PWSS expert responsible to provide subject area expertise and design
guidance
Senior Analyst - Responsible for quality assurance and product control Also to provide IE expertise
Senior Analyst - Responsible for the PWSS Organizational Model and authorship of all the outline* of
deliverables through completion of Task 2.
Environmental Scientist - Water expert and State level Water Division Information System.- Chief
responsible for subject area analysis and design guidance.
Periodic Expert - IEM and IEF expert responsible for methodology and tool usage guidance and
facilitation support.
Systems Designer - PWSS expert responsible for providing subject area analysis and design guidance.
Senior Analyst - Responsible for the Activity Model and Project Librarian
Senior Analyst - Responsible for IE technical support and maintaining and using the IEF tool
Technical Project Lead - Responsible for the technical accuracy, quality, completeness and timeliness
of the project and its deliverables.
Data Base and Central Encyclopedia Support Manager - Responsible for coordinating all data base and
central encyclopedia support functions.
Environmental Scientist - Water expert and Slate level Water Division Chief responsible for subject
area expertise and project support
Senior Systems Engineer - Responsible for the Data Model and Current Systems Technology.
C-6
-------
-------
SDC-0055-012-TB-2009
December 31, 1992
Appendix D
Strategies Supported by Information Needs
This appendix contains a matrix showing strategies associated with information needs. An
indicates that a particular strategy is supported by a particular information need.
-------
PAGE NOT
AVAILABLE
DIGITALLY
-------
-------
SDC-0055-0I2-TB-2009
December 31, 1992
Appendix E
Critical Success Factors Supported by Information
Needs
This appendix contains a matrix showing critical success factors associated with information
needs. An "x" indicates that a particular critical success factor is supported by a particular
information need.
-------
PAGE NOT
AVAILABLE
DIGITALLY
-------
-------
SDC-0055-012-TB-2009
December 31, 1992
Appendix F
Objectives Supported by Information Needs
This appendix contains a matrix showing objectives associated with information needs. An "x"
indicates that a particular objective is supported by a particular information need.
-------
PAGE NOT
AVAILABLE
DIGITALLY
-------
-------
SDC-0055-012-TB-2009
December 31, 1992
Appendix G
Information Needs and Associated Descriptions
This appendix contains a list of the information needs and their associated descriptions.
-------
Model : PUBLIC WATER SYSTEM SUPERVISION Sept. 15, 1592 11-4-
Subset: (complete model)
Information Strategy Planning
Information Need
ANALYTICAL_RESULTS_OF_TESTS
Detailed laboratory test results, including
sample purpose and results of the analysis.
(different retention times may be used for
positive and negative results). If sample is
not accepted, need reason for not accepting
sample.
Priority (0 - 9): 0
Satisfaction Rating (0 - 3): 0
Requirement Weight: 0
Importance Factor (1 - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
ANALYTICALJTECHNIQUE
Approved or proposed analytical techniques
for assessing the quality of drinking water,
including approving authority, date, and
purpose.
Priority (0 - 9): 0
satisfaction Rating (0 - 3): o
Requirement Weight: 0
Importance Factor (1 - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
APPLICABLE_DATA_STANDARDS
Descriptions of'data standards relating to
drinking water.
Priority (0 - 9): 0
Satisfaction Rating (0 - 3): 0
Requirement Weight: 0
Importance Factor (1 - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
BARRIERS TO_DSE OF NEW TECH
Information on barriers to State/local use of
new technology (e.g., construction
standards).
Priority (0 - 9): 0
satisfaction Rating (0-3): o
Requirement Weight: 0
Importance Factor (1-5): 1
Information should be updated continually.
Information may be categorized as: summary.
-------
Model : PUBLIC HATER SYSTEM SUPERVISION Sept. 15, 1992 11:41
Subset: (complete model) pag4 2
Information Strategy Planning
BEST_AVAILABLE_TECHNOLOGY_BAT
Information on best available technology for
treatment of drinking water.
Priority (0 - 9): 0
Satisfaction Rating (0 - 3): 0
Requirement Height: 0
Importance Factor (1 - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
BUILDING_CODES_RELATING_TO_PWS
Bui lding~codes~~relating~~to~~PWS construction,
including plumbing and electrical codes.
Priority (0 - 9): 0
satisfaction Rating (0-3): 0
Requirement Height: 0
Importance Factor (1 - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
CERTIFIED_LABS
Information concerning certified labs,
including purpose certified for,
certification authority, certification
period, lab owner/operator, certified
technician in charge, PHss served, capacity,
analytical equipment and methods, etc.
Priority (0 - 9): 0
Satisfaction Rating (0-3): 0
Requirement Height: 0
Importance Factor (1 - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
COMMUNICATIONS JfEDIA_SOORCES
Information on"~various public communications
media suitable for disseminating public
information, including public notifications
for a PWS.
Priority (0 - 9): 0
Satisfaction Rating (0 - 3): 0
Requirement Height: 0
Importance Factor (1 - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
-------
Model : PUBLIC WATER SYSTEM SUPERVISION Sept. IS, 1992 11-41
Subset: (complete model) paq4 3
Information Strategy Planning
COMMUNITY_6ROUPS ' ~ "~~~~~~~~~~~~~
Information on community groups interested in
drinking water issues.
Examples include: environmental groups,
advisory boards, etc.
Priority (0-9): 0
Satisfaction Rating (0 - 3): 0
Requirement Weight: 0
Importance Factor (1 - 5): l
Information should be updated continually.
Information nay be categorized as: summary.
COMPLAINTS
Complaints from consumers and other
interested parties concerning drinking
water.
Priority (0-9): 0
Satisfaction Rating (0-3): 0
Requirement Weight: 0
Importance Factor (1 - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
CONSUMER_PRODUCT_EVALUATIONS
Consumer~product~evaluations, including
devices such as POE, POU, filters, bottle
water coolers/dispensers, cross-connection
device evaluations, including date and
purpose of evaluation, evaluating activity,
and findings/recommendations.
Priority (0-9): 0
Satisfaction Rating (0 - 3): 0
Requirement Weight: 0
Importance Factor (1 - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
CONTAMINANT TREND ANALYSIS
Results of trend analysis of analytical
results, including isolating sources of
contaminants, assessing efficacy of treatment
techniques, assessing remediation actions,
etc.
Analysis may be characterized by PWS,
geographic area, watershed, etc.
Priority (0-9): o
Satisfaction Rating (0-3): 0
Requirement Weight: 0
-------
Model : PUBLIC WATER SYSTEM SUPERVISION Sept. IS, 1992 II-AI
Subset: (complete model) page 4
Information Strategy Planning
Importance Factor (1 - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
COST_IMPACT_ANALYSIS
Cost impact and cost/benefit analysis of
application of technology for various typical
PHSs, including large and small systems.
Priority (0-9): 0
Satisfaction Rating (0 - 3): 0
Requirement Weight: 0
Importance Factor (1 - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
COSTJTO_SATISFY_INFORMATION_NEED
Estimates of the costs to satisfy various
information needs. Used for cost/benefit
analysis.
Priority (0-9): 0
Satisfaction Rating (0-3): 0
Requirement Height: 0
Importance Factor (1 - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
CPE_RESULTS
Results of Comprehensive Plant Evaluations.
Priority (0-9): 0
Satisfaction Rating (0-3): 0
Requirement Height: 0
Importance Factor (1 - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
GROSS_MEDIA_ZMTERACTION
Information~on impacts of interaction of air,
water, and waste programs, (i.e., TRIS, PCS,
UST, underground injection, STORET)
Priority (0-9): 0
Satisfaction Rating (0-3): 0
Requirement Height: 0
Importance Factor (1-5): 1
Information should be updated continually.
Information may be categorized as: summary.
CURRENT_INFORMATION_SYSTEMS_INV
-------
Model : PUBLIC WATER SYSTEM SUPERVISION Sept. 15, 1992 11:41
Subset: (complete model) pag4 5
Information Strategy Planning
Information on the current information
systems supporting PWSS activities. Also
includes plans for future technical
architectures.
Priority (0 - 9): 0
Satisfaction Rating (0 - 3): o
Requirement Weight: 0
Importance Factor (1-5): l
Information should be updated continually.
Information may be categorized as: summary.
DATA_ACCESS_REQUIREHENTS
Includes both security concerns as well as
provisions for allowing/promoting public
access.
Priority (0-9): 0
Satisfaction Rating (0 - 3): 0
Requirement Height: 0
Importance Factor (1 - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
DATA_MGT_NEEDS_AND_REQUIREMENTS
Priority (0-9): 0
Satisfaction Rating (0 - 3): 0
Requirement Height: 0
Importance Factor (1 - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
DATA PROCESSING IMPACT OF RULE
The Impact of prcposedTstatutes, regulations,
and rules on data management.
Priority (0-9): 0
Satisfaction Rating (0 - 3): 0
Requirement Weight: 0
Importance Factor (1 - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
DEFICIENCIES ANDJULESTONES
Descriptions~"of deficiencies, needs, costs,
and projected milestones for correcting
deficiencies for each PWS. Includes
cost/benefit analysis.
Priority (0 - 9): 0
Satisfaction Rating (0-3): 0
-------
Model : PUBLIC WATER SYSTEM SUPERVISION Sept. 15, 1992 11:41
Subset: (complete model) page 6
Information -Strategy Planning
Requirement Weight: 6
Importance Factor (1 - 5): l
Information should be updated continually.
Information may be categorized as: summary.
DISTRIBUTION_SYSTEM_CHARACTER
Distribution systenTcharacterization,
including size of pipe, corrosion and
depositation, flushing program, compliance
with distribution related rules (e.g., lead
and copper).
Priority (0 - 9): 0
Satisfaction Rating (0 - 3): 0
Requirement Weight: 0
Importance Factor (1 - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
EMERGENCY_CONTACTS
Details on emergency contacts at PHSs and at
State/Federal emergency agencies.
Priority (0 - 9): 0
Satisfaction Rating (0 - 3): o
Requirement Weight: 0
Importance Factor (1 - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
EMERGING_TECHNOLOGY_STATDS
Maintain'avareness of new technology which
might be appropriate for application to
treatment, collection, and information
analysis.
Information gathered by review of research
needs, vendor product reviews, literature
reviews, attendance at conferences and
symposiums.
Priority (0-9): 0
Satisfaction Rating (0 - 3): 0
Requirement Weight: 0
Importance Factor (1 - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
ENFORCEMENT ACTIONS
Details on planned or issued enforcement
actions, including compliance orders and
administrative orders, required actions,
-------
Model : PUBLIC WATER SYSTEM SUPERVISION Sept. 15, 1992 11:41
Subset: (complete model) page 7
Information Strategy Planning
target completion date, and date corrective
actions completed.
Priority (0 - 9)s 0
Satisfaction Rating (0-3): 0
Requirement Height: 0
Importance Factor (1-5): 1
Information should be updated continually.
Information may be categorized as: summary.
FIELDJMONITORING_RESULTS
Reporting of monitoring operational
information that relates to compliance (i.e.,
turbidity and disinfectant residual results).
Priority (0 - 9): 0
Satisfaction Rating (0-3}: 0
Requirement Weight: 0
Importance Factor (l - 5): l
Information should be updated continually.
Information may be categorized as: summary.
HEALTH_EFFECTS_DATA
Data on the health effects relating to
drinking water, including relative dangers of
specific contaminants.
Priority (0-9): 0
Satisfaction Rating (0 - 3}: 0
Requirement Weight: 0
Importance Factor (1-5): l
Information should -be updated continually.
Information may be categorized as: summary.
HYDROGEOLOGICAL_XNFORMATION
Hydrogeological~~descriptors (e.g., geologic
structure, topography, and aquifer and river
reach characterizations).
Priority (0 - 9): 0
Satisfaction Rating (0 - 3): 0
Requirement Weight: 0
Importance Factor (1-5): l
Information should be updated continually.
Information may be categorized as: summary.
IMPACTS OF RULES ON SYSTEMS
Analysis of the Impacts of existing or
proposed Federal and State statutes,
regulations, and rules on PWSs, particularly
relating to small systems.
-------
Model : PUBLIC WATER SYSTEM SUPERVISION Sept. 15, 1992 11:41
Subset: (complete model) pa_e g
Information Strategy Planning
Priority (0 - 9):o
Satisfaction Rating (0-3): 0
Requirement Weight: 0
Importance Factor (1 - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
INCIDENCEJ^CONTAMINATION
Analysis of Tnformation on incidence of
contaminants in drinking water, their
potential effects on public health, and
efficacy of treatment or other controls.
(PDMSA)
Priority (0 - 9): o
Satisfaction Rating (0-3): 0
Requirement Weight: 0
Importance Factor (1-5): 1
Information should be updated continually.
Information may be categorized as: summary.
INTERCONNECTIVITY
Interconnectivity (buy and sell) of PWSs.
Priority (0-9): 0
Satisfaction Rating (0-3): 0
Requirement Weight: 0
Importance Factor (1 - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
LAB_AUTOMATION_CAPABILITIES
Includes knowledge of lab automation software
and knowledge of where software could be
applied/used.
Priority (0-9): 0
Satisfaction Rating (0-3): 0
Requirement Weight: 0
Importance Factor (1 - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
MEANS FOR ASSESSING COMPLEXITY
Information to assist in assessing the
complexity of rules and regulations.
Priority (0 - 9): 0
Satisfaction Rating (0-3): 0
Requirement Weight: o
Importance Factor (1 - 5): 1
Information should be updated continually.
-------
Model : PUBLIC WATER SYSTEM SUPERVISION Sept. 15, 1992 11-4-
Subset: (complete model) page c
Information Strategy Planning
Information may be categorized as: summary. "
MONITORING_SCHEDULE_BY_CONTAMINA
Monitor ing~schedule~by~contaminant and site
(e.g., sample site plan for TCR). Schedule
applies to State and Federal requirements.
Priority (0-9): o
Satisfaction Rating (0-3): 0
Requirement Weight: o
Importance Factor (1 - 5): l
Information should be updated continually.
Information may be categorized as: summary.
NEEDED_ANALYTICAL_TOOLS
Statements of need for new analytical tools
to support PWSS implementation.
Priority (0-9): 0
Satisfaction Rating (0-3): 0
Requirement Height: 0
Importance Factor (1-5): 1
Information should be updated continually.
Information may be categorized as: summary..
HEW_INFO_SYS_TECH»OLOGY
Status of* emerging information system
technology. Includes EDI technology to
improve transfer of data from point of
collection.
Priority (0-9): 0
Satisfaction Rating (0-3): 0
Requirement Weight: 0
Importance Factor (1 - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
OPERATOR_CERTIFICATION_STATUS
Status of certification of operators,
including level of operations/treatment
techniques certified for, PWS assigned to,
designation as operator in charge
(responsible operator), etc.
Priority (0-9): 0
Satisfaction Rating (0-3): 0
Requirement Weight: o
Importance Factor (1 - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
-------
Model : PUBLIC WATER SYSTEM SUPERVISION Sept. 15, 1993 11-41
Subset: (complete model) page'io
Information strategy Planning
PERMITS_ISSUED
Information on permits issued for operation
or construction of PWS, including issuing
authority, permitted treatment, population
served, etc.
Also includes information on other
environmental permits issued which may impact
on drinking water quality.
Priority (0 - 9): 0
Satisfaction Rating (0-3): 0
Requirement Weight: 0
Importance Factor (1-5): 1
Information should be updated continually.
Information may be categorized as: summary.
POPULATIONS_SERVED
Descriptions on populations served, include
number of people, ages, education level,
language spoken, average income, political
unit (county, district, etc.), servicing PWS,
etc.
Priority (0 - 9): 0
Satisfaction Rating (0-3): 0
Requirement Weight: 0
Importance Factor (1 - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
PRESS RELEASES RELATING_TO_PWS
Press-release Information,"including date and
releasing activity, author/point of contact,
distribution, and synopsis.
Priority (0 - 9): 0
Satisfaction Rating (0 - 3): 0
Requirement Weight: 0
Importance Factor (1 - 5}: l
Information should be updated continually.
Information may be categorized as: summary.
PUBLIC HEALTH TRENDS
Trend analysis of public health with respect
to drinking water.
Priority (0 - 9): 0
Satisfaction Rating (0-3): 0
Requirement Weight: 0
Importance Factor (l - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
-------
Model : PUBLIC WATER SYSTEM SUPERVISION Sept. 15, 1992 11-41
Subset: (complete model) page 11
Information Strategy Planning
PUBLIC_NOTICES_ISSUED
Information on~Public Notices issued,
including date, period, and content of
notice; community affected; and servicing
PWS.
Priority (0-9): 0
Satisfaction Rating (0 - 3): 0
Requirement Height: o
Importance Factor (1-5): 1
Information should be updated continually.
Information may be categorized as: summary.
PWS_DEMONSTRATIONS_STATUS
Information on on-going or planned
demonstrations, including purpose, sponsor,
demonstration dates, and outcomes/findings.
Priority (0-9): 0
Satisfaction Rating (0 - 3}: 0
Requirement Weight: o
Importance Factor (1 - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
PWS_ENGINEERING_PLAN_INFORMATIO
Information to support review of construction
permits or other permits related to PWSs.
Includes proposed, planned, or ongoing
construction.
Priority (0-9): 0
Satisfaction Rating (0 - 3): 0
Requirement Weight: 0
Importance Factor (1 - 5): 1
Information should be updated continually.
Information nay be categorized as: summary.
PWS_FACILrTY_INVENTORY
Information on PWSs, including location,
treatment, population served, ownership,
addresses, responsible operator in charge,
etc.
Priority (0-9): 0
Satisfaction Rating (0-3): 0
Requirement Weight: o
Importance Factor (1-5): 1
Information should be updated continually.
Information may be categorized as: summary.
-------
Model : PUBLIC WATER SYSTEM SUPERVISION Sept. 15, 1992 11:41
Subset: (complete model) page 12
Information -Strategy Planning
PWS_OPERATIONAL_INFORMATION
Operational information from PWS relating to
compliance, including vater served,
population served, and treatments being used.
(reported in annual or monthly water supply
reports which not used by all states)
Priority (0-9): 0
Satisfaction Rating (0 - 3): 0
Requirement weight: 0
Importance Factor (1 - 5): 1
Information should be updated continually.
Information nay be categorized as: summary.
PWS_OWNERSHIP_INFORMATION
PWS~~ownership~*information, including
financial viability.
Priority (O - 9): 0
Satisfaction Rating (0-3): 0
Requirement Weight: 0
Importance Factor (1 - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
PWS REXATED_GRANTS AND_LOANS
Information on grants and loans supporting
improvements to PWSs, PWSS, and research on
PWS related technologies.
Priority (0-9): 0
Satisfaction Rating (0-3): 0
Requirement Weight: 0
Importance Factor (1 - 5): l
Information should be updated continually.
Information may be categorized as: summary.
PWS WITH SPECXFIC_PROBLEMS
Information on PWSs with specific problems
which might be remedied by a demonstration or
pilot project.
Priority (0-9): 0
Satisfaction Rating (0-3): 0
Requirement Weight: 0
Importance Factor (1 - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
QA_STATISTICS_FOR_SAMFLIHG
Statistics on QA programs for certified labs
-------
Model : PUBLIC WATER SYSTEM SUPERVISION Sept. 15, 1992 11*41
Subset: (complete model) page*i3
Information. 'Strategy Planning
and field sampling by PWS operators, '
including QA Plans and QA results.
Priority (0 - 9}: 0
Satisfaction Rating (0-3): 0
Requirement Weight: 0
Importance Factor (1 - 5): l
Information should be updated continually.
Information may be categorized as: summary.
REGULATORS
Regulator descriptive information, including
political/geographic area regulated, name,
points of contact, type of activities
regulated, etc.
Priority (0 - 9): 0
Satisfaction Rating (0-3): 0
Requirement Weight: 0
Importance Factor (1 - 5): l
Information should be updated continually.
Information may be categorized as: summary.
REQUESTS FOR_TECHNICAL_ASSISTANC
Information on requests for technical
assistance from PWSs or regulators, including
date, requestor name, address, point of
contact, subject, synopsis of requested
assistance, synopsis of actions taken to
respond, etc.
Priority (0-9): 0
Satisfaction Rating (0 - 3): 0
Requirement Weight: 0
Importance Factor (1 - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
RESEARCH_NEEDS
Research needs identified with possible
application to drinking water.
Priority (0-9): 0
Satisfaction Rating (0 - 3): 0
Requirement Weight: 0
Importance Factor (1-5): 1
Information should be updated continually.
Information may be categorized as: summary.
RESEARCR_RESULTS
Results of PWS related reseach, including
pilot studies and demonstrations.
-------
Model : PUBLIC WATER SYSTEM SUPERVISION Sept. 15, 1992 11-4-
Subset: (complete model) page'i
Information Strategy Planning
Priority (0 - 9): 0
Satisfaction Rating (0 - 3): 0
Requirement Height: 0
Importance Factor (1-5): l
Information should be updated continually.
Information may be categorized as: summary.
RISK_ASSESSMENTS
Assessments of health risk related to
drinking water.
Priority (0-9): 0
Satisfaction Rating (0 - 3): 0
Requirement Weight: 0
Importance Factor (1-5): 1
Information should be updated continually.
Information may be categorized as: summary.
SAMPLE_LOCATIONS
Locations where samples are to be taken
(plant, entry point, tap)
Priority (0 - 9): 0
Satisfaction Rating (0 - 3): 0
Requirement Weight: 0
Importance Factor (1 - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
SAKPLE_SITIN6_PLAH
Sample siting plan information (e.g., TCR
siting plan), including schedule.
Priority (0-9): 0
Satisfaction Rating (0 - 3): 0
Requirement Weight: 0
Importance Factor (1-5): l
Information should be updated continually.
Information may be categorized as: summary.
SANITARY SURVEY_RESULTS
Results of sanitary surveys for each PWS,
including date, sanitarian, and
findings/recommendations.
Priority (0-9): 0
Satisfaction Rating (0-3): 0
Requirement Weight: o
Importance Factor (l - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
-------
Model : PUBLIC HATER SYSTEM SUPERVISION Sept. 15, 1992 11:41
Subset: (complete model) page is
Information 'Strategy Planning
SPILLS_AND_EVENTS_IMPACTING_PWS
Details concerning environmental spills and
natural phenomenon with actual or potential
impact on drinking water sources, including
date and location of event, emergency
agencies, and description of threat and
remediation activities.
Priority (0-9): o
Satisfaction Rating (0-3): 0
Requirement Weight: 0
Importance Factor (1 - 5): l
Information should be updated continually.
Information may be categorized as: summary.
STATE AND NATIONAL_REGULATIONS
Descriptions of requirements of State and
Federal statutes, regulations and rules, and
how they are applied to various types of
PHSs.
Priority (0-9): 0
Satisfaction Rating (0 - 3): 0
Requirement Weight: 0
Importance Factor (1-5): 1
Information should be updated continually.
Information may be categorized as: summary.
STATUS_OF FUNDING
Status of~~budgets (planned and actual) and
expenses relating to implementation of the
PWSS program.
Priority (0-9): 0
Satisfaction Rating (0-3): 0
Requirement Weight: 0
Importance Factor (1 - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
SURFACE_WATER_INTAKES
Surface~~water~intake information, including
source identifier, location (latitude and
longitude), depth, seasonal use, etc.
Priority (0-9): 0
Satisfaction Rating (0-3): 0
Requirement Weight: 0
Importance Factor (1 - 5): l
Information should be updated continually.
Information may be categorized as: summary.
-------
Model : PUBLIC WATER SYSTEM SUPERVISION Sept. 15, 1992 11-4
Subset: (complete model) page 1
Information Strategy Planning
TECHNICAL ASSISTANCE_PROVIDED
Technical~assistance~requested and provided,
including date, purpose, action taken,
schedule of future assistance, etc.
Priority (0 - 9): 0
Satisfaction Rating (0 - 3): 0
Requirement Height: 0
Importance Factor (1-5): 1
Information should be updated continually.
Information may be categorized as: summary.
TECHNICALJLITERATURE
Technical'literature and outreach information
relating to treatment or analysis of drinking
water, including date published,
author/publishing activity, subject,
applicability, availability, and synopsis.
Priority (0 - 9): 0
Satisfaction Rating (0-3): 0
Requirement Weight: 0
Importance Factor (1 - 5): l
Information should be updated continually.
Information may be categorized as: summary.
THREATS BY NATURAL_PHENOMENON
Information on threats to public water
supplies due to natural phenomenon such as
earthquakes, floods, and severe storms.
Priority (0-9): 0
Satisfaction Rating (0 - 3): 0
Requirement Height: 0
Importance Factor (1 - 5): l
Information should be updated continually.
Information may be categorized as: summary.
THREATS OF T£RRORIST_ACTIVITY
Information on threat of terrorist activities
posing danger to public water supplies.
Priority (0 - 9): 0
Satisfaction Rating (0 - 3): 0
Requirement Height: 0
Importance Factor (1 - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
TRADE ASSOCIATIONS
-------
Model : PUBLIC WATER SYSTEM SUPERVISION Sept. 15, 1992 11:41
Subset: (complete model) page 17
Information-.Strategy Planning
Information on trade associations and their
literature, including purpose, address,
leadership, training provided, and membership
statistics.
Priority (0 - 9): 0
Satisfaction Rating (0-3): 0
Requirement Weight: 0
Importance Factor (1 - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
TRADE_CONFERENCES
Information on trade conferences, including
schedule, topics, sponsoring association(s),
attendees, etc.
Priority (0 - 9): 0
Satisfaction Rating (0-3): 0
Requirement Weight: 0
Importance Factor (1 - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
TRAINING EVENTS
Inf ormatTon on planned or completed training
events (including 3d party), including
purpose, intended cost, presenting activity,
point of contact, attendees, etc.
Priority (0 - 9): 0
Satisfaction Rating (0 - 3): 0
Requirement Weight: 0
Importance Factor (1 - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
TREATMENT_TECHNIQUE
Approved or proposed treatment techniques for
treating water for use as drinking water,
including approving authority, date, purpose,
chemicals used, etc.
Priority (0 - 9): 0
Satisfaction Rating (0 - 3): 0
Requirement Weight: 0
Importance Factor (l - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
UNDERSTAHDABILITY OF_COMPLIANCE
Information on the state of regulators' and
-------
Model : PUBLIC WATER SYSTEM SUPERVISION Sept. 15, 1992 11-4
Subset: (complete model) page'i:
Information Strategy Planning
regulated community's understanding of ~~
compliance requirements.
Priority (0-9): 0
Satisfaction Rating (0-3): 0
Requirement Weight: 0
Importance Factor (1-5): 1
Information should be updated continually.
Information may be categorized as: summary.
VARIANCES_AND^EXCEPTIONS
Status of "variances and exceptions, as well
as waivers, exceptions, exclusions, etc., for
a PWS, including date granted and provisions.
Priority (0-9): 0
Satisfaction Rating (0-3): 0
Requirement Weight: o
Importance Factor (1 - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
i
VIOLATION INFORMATION
Information on violations, including PWS and
community served, regulatory provisions that
were violated, date on which violation
identified, date on which SNC status
determined, SNC expiration date, etc.).
Includes monitoring and reporting violations.
Priority (0-9): 0
Satisfaction Rating (0 - 3): 0
Requirement Weight: 0
Importance Factor (1 - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
WELL DESCRIPTORS
Well~descriptors, including location
(latitude and longitude), depth, aquifer
identifier, seasonal availability, elevation,
casing material, screen size, age, etc.
Priority (0-9): 0
Satisfaction Rating (0 - 3): 0
Requirement Weight: 0
Importance Factor (1 - 5): 1
Information should be updated continually.
Information may be categorized as: summary.
WELL HEAD PROGRAM_IMPLEMENTATION
Information on well head protection for each
-------
Model : PUBLIC WATER SYSTEM SUPERVISION Sept. 15, 1992 11:41
Subset: (complete model) page*19
Information Strategy Planning
Priority (0 - 9): 0
Satisfaction Rating (0 - 3): 0
Requirement Weight: 0
Importance Factor (1 - 5): l
Information should be updated continually.
Information may be categorized as: summary.
ZONINGJUn>_LANDJ7SE_ACTIVITY
Information on Zoning activity, to include
land use. Used to forecast demand as veil as
impact of development on water supply and
quality.
Priority (0 - 9): 0
Satisfaction Rating (0 - 3): 0
Requirement Weight: o
Importance Factor (l - 5): l
Information should be updated continually.
Information may be categorized as: summary.
-End of Report-
-------
-------
SDC-0055-012-TB-2009
December 31, 1992
Appendix H
Entity Types with Descriptions
This appendix contains an alphabetical listing of entity types and their associated descriptions.
-------
Model : OGWDW PWSS ISP MODEL V01.01D . Dec. 21, 1992 18:13
Subset: (complete model) page 1
Entity Definition
Entity: AGREEMENT
Description: Documents formal and informal understandings
(oral and written) between two or more
parties.
Examples: primacy agreements, bilateral
compliance agreements, grant agreements,
memorandums of understanding between
agencies, delegation agreements with county
health departments, dedicated well site
documents, contractual agreements.
Example descriptors: type and date of
agreement, purpose of agreement, agreement
number, date signed, and redress information.
Subject area: CONTROLLING_INSTRUMENTS
Properties: Min Occ: 0 Avg Occ: 0
Max Occ: 0 Growth Rate: 0% per year
Relationships:
Sometimes (0%) IS_A_RESULT_OF many VIOLATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) ADMINISTERS many REQUIREMENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_A_RESULT_OF many ENFORCEMENT_ACTION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_SIGNED_BY many LEGAL_ENTITY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_THE_BASIS_FOR many GRANT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D
Subset: (complete model)
Entity Definition
Dec. 21, 1992 18:13
page 2
Entity:
Description:
ANALYTICAL_EQUIPMENT
Identifies and describes capabilities of
laboratory equipment, field equipment, and
information systems processing equipment used
to measure or assess water quality.
Equipment may report results.
Examples: spectrometers, ADPE, analytical
software, and sampling devices.
Example descriptors: name of equipment,
precision and detection limit, calibration
schedule, cost, type of output.
Relationships: detects CONTAMINANT,
manufactured (or sold) by NON GOVERNMENT
AGENCY, located at/owned by LEGAL ENTITY,
funded by BUDGET
Subject area: TECHNOLOGIES
Properties:
Min Occ:
Max Occ:
0 Avg Occ:
0 Growth Rate:
0% per year
Relationships:
Sometimes (0%) USES many STANDARD_TECHNIQUE_OR_PROCEDURE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_IMPROVED_BY many RESEARCH_RESULT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_USED_BY many WATER_SYSTEM_FACILITY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_USED_BY many LABORATORY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_DESCRIBED_IN many TECHNICAL_PUBLICATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_TRAINED_BY many TRAINING_EVENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D
Subset: (complete model)
Dec. 21, 1992 18:13
page 3
Entity Definition
Entity:
Description:
BUDGET
Information on planning and execution of
funds for the PWSS. Budgets may be planned
(outyears) or actual (current year and
carryover), and may be amended.
National-level budgets normally include the
current operating year and forecasts for the
outyears.
Budgets may also account for/plan use of fees
cost recovery, or fines.
Examples: national budgets for Federal
programs, State budgets for State programs,
certified laboratory budgets/fees, research
and development budgets, and PWS budgets.
Example descriptors: appropriation,
accounting year, budget amount, budget
purpose, budget status, and budget line item,
actual expense information.
Subject area:
Properties:
PROGRAMS AND PLANS
Min Occ:
Max Occ:
0 Avg Occ:
0 Growth Rate:
0% per year
Relationships:
Sometimes (0%) FUNDS many GRANT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Always FUNDS many PROGRAM
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
Sometimes (0%) IS_ESTABLISHED_FOR one LEGAL_ENTITY
cannot transfer.
Sometimes (0%) IS_USED_BY many LEGAL_ENTITY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) SUPPORTS_IMPLEMENTING many CONTINGENCY_AND_EMERGENCY_PLANS
Cardinality Min: l (est) Max: 1 (est) Avg: 'l
cannot transfer.
Sometimes (0%) SUPPORTS many MONITORING_PLAN
Cardinality Min: l (est) Max: 1 (est) Avg: l
cannot transfer.
Sometimes (0%) SUPPORTS_IMPLEMENTING one ENGINEERING_PLAN
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D
Subset: (complete model)
Entity Definition
Dec. 21, 1992 18:13
page 4
Entity:
Description:
COMMUNICATIONS_MEDIA
Information on communications media and
community groups serving PWS consumers.
Examples: newspapers, television, radio,
billboards, newsletters, billing inserts,
etc.
Example descriptors: point of contact, name,
subject area, frequency.
Subject area: LEGAL_ENTITIES
Properties:
Min Occ:
Max Occ:
0 Avg Occ:
0 Growth Rate:
per year
Relationships:
Sometimes (0%) DISTRIBUTES one TECHNICAL_PUBLICATION
cannot transfer.
Sometimes (0%) IS_OWNED_BY many LEGAL_ENTITY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) SERVES many POPULATION_GROUP
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D Dec. 21, 1992 18:13
Subset: (complete model) page 5
Entity Definition
Entity: COMPLAINT
Description: Written/oral communications received
concerning drinking water or water systems.
Examples: complaints about taste, color,
odor, pressure, illness, fees, operation,
etc.
Example descriptors: date, prognosis,
corrective action(s), location of problem,
nature of problem, duration, etc.
Subject area: COMPLIANCES
Properties: Min Occ: 0 Avg Occ: 0
Max Occ: 0 Growth Rate: 0% per year
Relationships:
Sometimes (0%) LODGED_BY many LEGAL_ENTITY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_RESPONDED_TO many LEGAL_ENTITY
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
sometimes (0%) CONCERNS many PUBLIC_WATER_SYSTEM
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) CONCERNS many LABORATORY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) CONCERNS many GOVERNMENT_AGENCY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) RESULTSJEN many VIOLATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) RESULTS_IN many REVIEW_AUDIT_AND_EVALUATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D
Subset: (complete model)
Entity Definition
Dec. 21, 1992 18:13
page 6
Entity:
Description:
CONTAMINANT
Any physical, chemical, biological, or
radiological substance, parasitic/pathogenic
organism, or matter in water that is of
interest.
Contaminants may result in a health risk to
the consumer or may be aesthetically
obj ectionable.
Maximum contaminant level goals and maximum
contaminant levels (MCLs) are established for
regulated contaminants identified by Federal
and State Primary Drinking Water Regulations.
Other contaminants are identified in Federal
and State Secondary Drinking Water
Regulations.
Examples of regulated contaminants include:
inorganics (e.g., arsenic, barium, and
cadmium), organics (e.g., endrin,
lindane, methoxychlor, and trihalothanes),
(3) microbials (e.g., coliform bacteria), and
(4) radionuclides (e.g., gross alpha and
gross beta).
Examples of regulated contaminant groupings
include inorganics, synthetic organic
contaminants, and volatile organic
contaminants.
Example descriptors include: name,
description, health effects, sources, etc..
Subject area: SAMPLES
Properties: Min Occ:
Max Occ:
0 Avg Occ:
0 Growth Rate:
0% per year
Relationships:
sometimes (0%) MCL IS_IDENTIFIED_BY many REQUIREMENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
sometimes (0%) IS_MONITORED_BY many MONITORING_PLAN
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_MEASURED_BY many LABORATORY
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
Sometimes (0%) IS_MEASURED_BY many SAMPLE_ANALYTICAL_RESULT
Cardinality Min: 1 (est) Max: l (est) Avg: l
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D Dec. 21, 1992 18:13
Subset: (complete model) page 7
Entity Definition
Sometimes (0%) HAS_ACTION_LEVEL_SPECIFIED_BY many REQUIREMENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_RELEASED_BY many ENVIRONMENTAL_EVENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) ARE_FORECAST_BASED_UPON many WEATHER_DATA
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D Dec. 21, 1992 18:13
Subset: (complete model) page 8
Entity Definition
Entity: CONTINGENCY_AND_EMERGENCY_PLANS
Description: Descriptions of foreseen actions,
responsibilities, and coordination procedures
for contingency or emergency situations.
Examples: plans for loss of capability at a
water facility, loss of source, natural
disasters, etc.
Example descriptors: date, purpose, summary
of actions to be taken.
Subject area: PROGRAMS_AND_PLANS
Properties: Min Occ: 0 Avg Occ: 0
Max Occ: 0 Growth Rate: 0% per year
Relationships:
Sometimes (0%) IS_PREPARED_BY many LEGAL_ENTITY
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
Sometimes (0%) IS_APPROVED_BY many GOVERNMENT_AGENCY
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
Sometimes (0%) RESPONDSJTO many WATERJTHREAT
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
Sometimes (0%) ARE_PREPARED_FOLLOWING many POLICY_AND_GUIDANCE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) REQUIRE_SUPPORT_FROM many BUDGET
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) RESPOND_TO many ENVIRONMENTAL_EVENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) CONSIDER many WEATHER_DATA
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D Dec. 21, 1992 18:13
Subset: (complete model) page 9
Entity Definition
Ent ity: CROSS_MEDIA_SYSTEM
Description: Descriptions of cross media information
systems.
Examples: PCS, STORET, FINDS, RCRA, CERCLIS,
GIGS, USGS's National Water Data Exchange
(NAWDEX), Weather Data Bases, etc.
Example descriptors: name, description,
platform, access information
Subject area: CROSS_MEDIA_SOURCES
Properties: Min Occ: 0 Avg Occ: 0
Max Occ: 0 Growth Rate: 0% per year
Relationships:
Sometimes (0%) PROVIDES many WEATHER_DATA
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) PROVIDES many WATER_HABITAT_QUALITY_INFO
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) PROVIDES many HAZARDOUS_WASTE_INFORMATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_OWNED_BY many LEGAL_ENTITY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_DESCRIBED_IN many TECHNICAL_PUBLICATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) PROVIDES many HYDROLOGICAL_INFORMATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) PROVIDES many ENVIRONMENTAL_EVENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_USED_BY many PROGRAM
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D
Subset: (complete model)
Entity Definition
Dec. 21, 1992 18:13
page 10
Entity:
Description:
DEVIATION
Provisions for an EPA or primacy State
official to grant a public water system a
deviation from one or more requirements.
Deviations may be granted if, for some
compelling reason, a public water system is
unable or not required to comply with one or
more mandated requirements (e.g., maximum
contaminant level, treatment technique, or
technology requirement). Deviations must not
result in unreasonable health risks to the
consumers. Deviations are granted for a
prescribed period of time. A public hearing
or public notice may be required.
Examples: variances and exemptions (SDWA),
waivers, and exceptions.
Example descriptors: type, date issued,
purpose, schedule, conditions, and duration.
Subject area: CONTROLLING_INSTRUMENTS
Properties:
Min Occ:
Max Occ:
0 Avg Occ:
0 Growth Rate:
0% per year
Relationships:
Sometimes (0%) MITIGATES many REQUIREMENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_EXAMINED_BY many REVIEW_AUDIT_AND_EVALUATION
cardinality Min: l (est) Max: 1 (est) Avg: l
cannot transfer.
Always IS_GRANTED_BY many GOVERNMENT_AGENCY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Always APPLIESJTO many PUBLIC_WATER_SYSTEM
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D
Subset: (complete model)
Entity Definition
Dec. 21, 1992 18:13
page 11
Entity:
Description:
DRINKING_WATER_SOURCE
Information characterizing a source from
which a public water system obtains water.
Examples: ground water sources (e.g. ,
aquifers), surf ace water (e.g. rivers,
streams, lakes, and reservoirs), and water
purchased from other systems. Also may
include bottled water and interstate carrier
conveyances .
Example descriptors: type, quantity,
location (latitude and longitude) , depth,
elevation, reach or aquifer identifier, and
quality.
Subject area: INVENTORIES
Properties:
Min Occ:
Max Occ:
0 Avg Occ:
0 Growth Rate:
0% per year
Relationships :
Sometimes (0%) IS_USED_BY many PUBLIC_WATER_SYSTEM
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_JEOPARDIZED_BY many WATER_THREAT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_ANOTHER many PUBLIC_WATER_SYSTEM
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
Sometimes (0%) IS_EVALUATED_BY many SAMPLE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_DESCRIBED_BY many HYDROLOGICAL_INFORMATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_IMPACTED_BY many HAZARDOUS_WASTE_INFORMATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_DESCRIBED_BY many WATER_HABITAT_QUALITY_INFO
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_ANALYZED_BY many WEATHER_DATA
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D Dec. 21, 1992 18:13
Subset: (complete model) page 12
Entity Definition
Ent i ty: ENFORCEMENT_ACTION
Description: Documents actions taken against a PWS,
laboratory, or operator.
Includes requirements that must be met in
order to rectify a failure to perform under
the PWSS Program.
Enforcement actions are informal and formal.
They may be issued by the Primacy State (or
its representative) or the EPA.
Examples: administrative and civil/criminal
legal actions, warning notices, citations,
orders to follow water treatment procedures,
orders to follow sampling requirements,
orders to resolve violations, moratoriums on
connections, temporary injunctions,
restraining orders, penalties, and orders to
comply with reporting requirements.
Example descriptors: type of enforcement
action, directed actions, and milestone
date(s).
Subject area: COMPLIANCES
Properties: Min Occ: 0 Avg Occ: 0
Max Occ: 0 Growth Rate: 0% per year
Relationships:
Always RESULTS_FROM many VIOLATION
cardinality Min: l (est) Max: l (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_DIRECTED_AGAINST many LEGAL_ENTITY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_ISSUED_BY one GOVERNMENT_AGENCY
cannot transfer.
Sometimes (0%) RESULTS_IN many AGREEMENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) APPLIESJTO many PUBLIC_WATER_SYSTEM
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Always IS_BASED_ON many REQUIREMENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) RESULTS_IN many PUBLIC_NOTIFICATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D Dec. 21, 1992 18:13
Subset: (complete model) page 13
Entity Definition
Entity: ENGINEERING_PLAN
Description: Describes engineering work to be completed
for a PWS or water system facility.
Examples: installation of new treatment
system, construction of new well, etc.
Example descriptors: schedule,
responsibilities, inspection requirements,
etc.
Subject area: PROGRAMS_AND_PLANS
Properties: Min Occ: 0 Avg Occ: 0
Max Occ: 0 Growth Rate: 0% per year
Relationships:
Sometimes (0%) SPECIFIES many BUDGET
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_PREPARED_BY many PUBLIC_WATER_SYSTEM
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) CONSTRUCTS_OR_MODIFIES many WATER_SYSTEM_FACILITY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_APPROVED_BY many GOVERNMENT_AGENCY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_PREPARED_PER many STANDARD_TECHNIQUE_OR_PROCEDURE
cardinality Min: l (est) Max: l (est) Avg: l
cannot transfer.
Sometimes (0%) REQUIRES_INSTALLATION_OR_MOD_OF many TREATMENT_EQUIPMENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_SUPPORTED_BY many GRANT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_SUPPORTED_BY many GUARANTEED_LOAN
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) REQUIRES many PERMIT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) REQUIRES many TECHNICAL_ASSISTANCE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_PREPARED_PER many POLICY_AND_GUIDANCE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) CONSIDER many HAZARDOUS_WASTE_INFORMATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D Dec. 21, 1992 18:13
Subset: (complete model) page 14
Entity Definition
This page intentionally left blank.
-------
Model : OGWDW PWSS ISP MODEL V01.01D Dec. 21, 1992 18:13
Subset: (complete model) page 15
Entity Definition
Entity: ENVIRONMENTAL_EVENT
Description: Describes non-weather-related occurrences
which may affect drinking water
quality/quantity.
Examples include: earthquakes, volcano
eruptions, mudslides, toxic spills, land
subsidence, etc.
Example descriptors include: type, date(s),
population affected, geographical area
affected, potential impacts on drinking
water, etc.
Subject area: CROSS_MEDIA_SOURCES
Properties: Min Occ: 0 Avg Occ: 0
Max Occ: 0 Growth Rate: 0% per year
Relationships:
Sometimes (0%) IS_PROVIDED_BY many CROSS_MEDIA_SYSTEM
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_RESPONDED_TO_BY many CONTINGENCY_AND_EMERGENCY_PLANS
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_RESPONDED_TO_BY many GOVERNMENT_AGENCY
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
Sometimes (0%) RELEASES many CONTAMINANT
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
Sometimes (0%) IMPACTS many POPULATION_GROUF
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_EVALUATED_BY many REVIEW_AUDIT_AND_EVALUATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_RESPONDED_TO_BY many TECHNICAL_ASSISTANCE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) RESULTS_IN many VIOLATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) CAUSES many WATERJTHREAT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D
Subset: (complete model)
Dec. 21, 1992 18:13
page 16
Entity Definition
Entity:
Description:
Subject area:
Properties:
FIELD_EQUIPMENT
Equipment used to perform field operations.
Examples: test kits, instrumentation,
GPS aids, mobile labs, etc.
Example descriptors: name, capability,
type, cost, precision and detection limit,
calibration schedule, inventory number, etc.
Relationships: owned by GOVERNMENT AGENCY,
measures CONTAMINANT, owned by PWS, owned by
LABORATORY
TECHNOLOGIES
Min Occ:
Max Occ:
0 Avg Occ:
0 Growth Rate:
0% per year
Relationships:
Sometimes (0%) IS_DESCRIBED_IN many TECHNICAL_PUBLICATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_TRAINED_BY many TRAINING_EVENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D Dec. 21, 1992 18:13
Subset: (complete model) page 17
Entity Definition
Ent ity: GOVERNMENT_AGENCY
Description: A government agency, including the staff,
organizational structure, and operating
mission.
Examples: Federal agencies, State
agencies, State Legislature, Federal Court,
local governments, and Indian
tribes or other governments (e.g., foreign).
Example descriptors: name, type,
purpose, address, points of contact, and
staff.
Subject area: LEGAL_ENTITIES
Properties: Min Occ: 0 Avg Occ: 0
Max Occ: 0 Growth Rate: 0% per year
Relationships:
Always IS_A many LEGAL_ENTITY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) ISSUES many LAB_CERTIFICATE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) ISSUES many ENFORCEMENT_ACTION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) EMPLOYS many INDIVIDUAL
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) BACKS many GUARANTEED_LOAN
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) EXECUTES many PROGRAM
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) ISSUES many PERMIT
Cardinality Min: 1 (est) Max: l (est) Avg: l
cannot transfer.
sometimes (0%) ISSUES many VIOLATION
Cardinality Min: l (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) ISSUES many REGULATION
Cardinality Min: 1 (est) Max: l (est) Avg: l
cannot transfer.
Sometimes (0%) ISSUES one LEGAL_MANDATE
cannot transfer.
Sometimes (0%) PERFORMS many REVIEW_AUDIT_AND_EVALUATION
Cardinality Min: 1 (est) Max: l (est) Avg: l
cannot transfer.
Sometimes (0%) ISSUES many POLICY_AND_GUIDANCE
-------
Model : OGWDW PWSS ISP MODEL V01.01D Dec. 21, 1992 18:13
Subset: (complete model) page 18
Entity Definition
CardinalityMin: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) APPROVES many CONTINGENCY_AND_EMERGENCY_PLANS
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) ESTABLISHES many REQUIREMENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_AUTHORIZED_BY many REQUIREMENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) GRANTS many DEVIATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) APPROVES one ENGINEERING_PLAN
cannot transfer.
Sometimes (0%) DEVELOPS many PROGRAM
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) APPROVES many PROGRAM
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_THE_SUBJECT_OF many COMPLAINT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) COORDINATES_RESPONSE_TO many ENVIRONMENTAL_EVENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D
Subset: (complete model)
Entity Definition
Dec. 21, 1992 18:13
page 19
Entity:
Description:
GRANT
Information relating to an application for
and award of grants, grant agreements and
work plans, plan implementation status, and
funds need. Also included are the criteria
for grant eligibility.
Examples: technology demonstration grants,
public water system construction grants,
special program grants (e.g., school water
cooler program, drinking water related
training, and education grants), Community
Development Block Grant (CDBG), technical
assistance grants, and primacy grants to
States having primary enforcement
responsibility.
Recipients of grants include primacy States,
public water systems, private citizens, and
technology vendors.
Example descriptors: grant amount,
grant purpose, award date, eligibility
criteria.
Subject area:
Properties:
PROGRAMSANDPLANS
Min Occ:
Max Occ:
0 Avg Occ:
0 Growth Rate:
0% per year
Relationships:
Always IS_FUNDED_BY many BUDGET
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_PROVIDED_FOR_BY many PROGRAM
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_PROVIDED_TO many LEGAL_ENTITY
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
Sometimes (0%) SUPPORTS many ENGINEERING_PLAN
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_PROVIDED_BASED_ON many PROGRAM_PLAN
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_BASED_ON one AGREEMENT
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D
Subset: (complete model)
Entity Definition
Dec. 21,
1992 18:13
page 20
Entity:
Description:
GUARANTEED_LOAN
An arrangement between Federal/ State
agencies and a qualified financial
institution (e.g., Federal Reserve backed
bank) to guarantee a loan for construction of
water supply facilities. Includes
applications for loans and loan approval
criteria.
Examples: loans for the construction of new
or improved PWS facilities.
Example descriptors: loan amount,
terms, loan purpose, loan status.
loan
Subject area:
Properties:
PROGRAMS AND PLANS
Min Occ:
Max Occ:
0 Avg Occ:
0 Growth Rate:
0% per year
Re1at ionships:
Always IS_BACKED_BY many GOVERNMENT_AGENCY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) PROVIDES_FUNDS_FOR many PUBLIC_WATER_SYSTEM
Cardinality Mi'n: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
Sometimes (0%) IS_ESTABLISHED_BY many PROGRAM
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) SUPPORTS many ENGINEERING_PLAN
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Always IS_ISSUED_TO many LEGAL_ENTITY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Always ARE_ISSUED_BY many LEGAL_ENTITY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D
Subset: (complete model)
Dec. 21, 1992 18:13
page 21
Entity Definition
Entity:
Description:
HAZARDOUS_WASTE_INFORMATION
Describes hazardous waste sites, spills,
sources 'that may affect drinking water
supply.
Examples include: nuclear waste disposa
sites, chemical plants, refuse sites, etc.
Example descriptors include: name, type,
owner, potential threat to drinking water,
regulatory agency, location, etc.
Subject area:
Properties:
CROSS MEDIA SOURCES
Min Occ:
Max Occ:
0 Avg Occ:
0 Growth Rate:
0% per year
Relationships:
Sometimes (0%) IS_PROVIDED_BY many CROSS_MEDIA_SYSTEM
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
Sometimes (0%) CAUSES many WATER_THREAT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IMPACT many DRINKING_WATER_SOURCE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_CONSIDERED_BY many ENGINEERING_PLAN
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_CONSIDERED_BY many PUBLIC_WATER_SYSTEM
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D
Subset: (complete model)
Entity Definition
Dec. 21, 1992 18:13
page 22
Entity:
Description:
HYDROLOGICAL_INFORMATION
Describes hydrological water sources.
Examples include: water basins, water
bodies, flood plains, underground water
sources, water tables, surface water, etc.
Example descriptors include: name, location,
quantity, pollutants, water quality
assessment, threat evaluation, etc.
Subject area: CROSS_MEDIA_SOURCES
Properties:
Min Occ:
Max Occ:
0 Avg Occ:
0 Growth Rate:
0% per year
Relationships:
Sometimes (0%) IS_PROVIDED_BY many CROSS_MEDIA_SYSTEM
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) DESCRIBES many DRINKING_WATER_SOURCE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D Dec. 21, 1992 18:13
Subset: (complete model) page 23
Entity Definition
Entity: INDIVIDUAL
Description: A person involved in the implementation of
the PWSS.
Example descriptors: name, address,
identifying number, skill, and
responsibility.
Subject area: LEGAL_ENTITIES
Properties: Min Occ: 0 Avg Occ: 0
Max Occ: 0 Growth Rate: 0% per year
Relationships:
Always IS_A one LEGAL_ENTITY
cannot transfer.
Sometimes (0%) HOLDS many LAB_CERTIFICATE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_RESPONSIBLE_OPERATOR_FOR many PUBLIC_WATER_SYSTEM
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_EMPLOYED_BY many GOVERNMENT_AGENCY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_EMPLOYED_BY many NON_GOVERNMENT_AGENCY_OR_COMPANY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_CERTIFIED_TECHNICIAN_FOR many LABORATORY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) TAKES many SAMPLE
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
Sometimes (0%) ATTENDS many TRAINING_EVENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) PRESENTS many TRAINING_EVENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) DEVELOPS many TRAINING_EVENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) PREPARES one SAMPLE_ANALYTICAL_RESULT
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.010
Subset: (complete model)
Dec. 21,
1992 18:13
page 24
Entity Definition
Entity:
Description:
INFORMATION_REQUEST
Describes a request for information regarding
the PWS program. Requests include
information on health risks, rules and
policies, public water systems,
consumers, treatment techniques, and
contaminant levels.
Examples: inquiries by government
officials/agencies, private firms, private
citizen requests, FOIA requests, and other
requests.
Example descriptors: form of request,
request date, required and actual response
dates, if response complied with legal
requirements, nature of request, form of
response cost.
Subject area: PROGRAMS_AND_PLANS
Properties:
Min Occ:
Max Occ:
0 Avg Occ:
0 Growth Rate:
0% per year
Relationships:
Sometimes (0%) IS_RESPONDED_TO_BY many LEGAL_ENTITY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_FULFILLED_UNDER many PROGRAM
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_SUBMITTED_BY many LEGAL_ENTITY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_SUBMITTED_UNDER many LEGAL_MANDATE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D
Subset: (complete model)
Dec. 21, 1992 18:13
page 25
Entity Definition
Entity:
Description:
LABORATORY
Documents information on laboratories that
are certified or applied for certification by
EPA or States to conduct drinking water
sample analysis.
Examples: Environmental organic
laboratory and microbiological laboratory.
Example descriptors: lab identification,
location and address, area served, capacity,
point of contact, type of reporting
(capability, method, and means), fee
information, other services provided.
Subject area: SAMPLES
Properties:
Min Occ:
Max Occ:
0 Avg Occ:
0 Growth Rate:
0% per year
Relationships:
Sometimes (0%) ANALYZES many SAMPLE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_CERTIFIED_BY many LAB_CERTIFICATE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Always IS_OWNED_BY many LEGAL_ENTITY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) HAS_AS_CERTIFIED_TECHNICIAN many INDIVIDUAL
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) USES many ANALYTICAL_EQUIPMENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_CERTIFIED_FOR_ANALYZING_FOR many CONTAMINANT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_CERTIFIED_FOR many STANDARD_TECHNIQUE_OR_PROCEDURE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) PREPARES many SAMPLE_ANALYTICAL_RESULT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_THE_SUBJECT_OF many COMPLAINT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D
Subset: (complete model)
Entity Definition
Dec. 21, 1992 18:13
page 26
Entity:
Description:
Subject area:
Properties:
IAB_CERTIFICATE
Includes applications for certification,
tracking information, including renewal
dates and fees.
Examples: laboratory certifications, lab
technician certification.
Example descriptors: purpose of certificate,
date of issue, period of validity,
competency test results, applicant
qualifications (including education and
training), fees paid.
CONTROLLING INSTRUMENTS
Min Occ:
Max Occ:
0 Avg Occ:
0 Growth Rate:
0% per year
Relationships:
Always BASEDJDN one REQUIREMENT
cannot transfer.
Sometimes (0%) CERTIFIES one LABORATORY
cannot transfer.
Always IS_ISSUED_BY one GOVERNMENT_AGENCY
cannot transfer.
Sometimes (0%) CERTIFIES one INDIVIDUAL
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D Dec. 21, 1992 18:13
Subset: (complete model) page 27
Entity Definition
Ent ity: LEGAL_ENTITY
Description: A person, corporation, government agency,
private commission, etc.
Example descriptors: name, address(es), and
telephone number(s)
Subject area: LEGAL_ENTITIES
Properties: Min Occ: 0 Avg Occ: 0
Max Occ: 0 Growth Rate: 0% per year
Relationships:
Sometimes (0%) TAKES many SAMPLE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) RESPONDS_TO many INFORMATION_REQUEST
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) OWNS many PUBLIC_WATER_SYSTEM
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_A many GOVERNMENT_AGENCY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS many NON_GOVERNMENT_AGENCY_OR_COMPANY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS many INDIVIDUAL
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_ISSUED many PERMIT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) OWNS many LABORATORY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_THE_SUBJECT_OF many ENFORCEMENT_ACTION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Always ESTABLISHES many BUDGET
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) PREPARES many CONTINGENCY_AND_EMERGENCY_PLANS
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) USES many BUDGET
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) APPROVES many TRAINING_EVENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) PRESENTS many TRAINING_EVENT
-------
Model : OGWDW PWSS ISP MODEL V01.01D Dec. 21, 1992 18:13
Subset: (complete model} page 28
Entity Definition
CardinalityMin: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) PREPARES many TECHNICAL_PUBLICATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) DISTRIBUTES many TECHNICAL_PUBLICATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
Sometimes (0%) RECEIVES many GRANT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) ISSUES many PUBLIC_NOTIFICATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) SIGNS many AGREEMENT
Cardinality Min: 1 (est) Max: l (est) Avg: l
cannot transfer.
Sometimes (0%) PROVIDES many TECHNICAL_ASSISTANCE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_PROVIDED many TECHNICAL_ASSISTANCE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) ARE_ISSUED many GUARANTEED_LOAN
Cardinality Min:. 1 (est) Max:. 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) ISSUES many GUARANTEED_LOAN
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) SUBMITS one INFORMATION_REQUEST
cannot transfer.
Sometimes (0%) OWNS many CROSS_MEDIA_SYSTEM
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
Sometimes (0%) OWNS many COMMUNICATIONS_MEDIA
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) RECEIVES many SAMPLE_ANALYTICAL_RESULT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) PERFORMS many SAMPLE_ASSESSMENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
Sometimes (0%) LODGES one COMPLAINT
cannot transfer.
Sometimes (0%) RESPONDSJTO many COMPLAINT
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
Sometimes (0%) ORIGINATES many RESEARCH_NEED
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D Dec. 21, 1992 18:13
Subset: (complete model) page 29
Entity Definition
Entity: LEGAL_MANDATE
Description: A law passed by the U.S. Congress/State
Legislature or an order signed by the
President of the United States/State
Governor.
Examples: the Safe Drinking Water
Act and the Clean Water Act.
Example descriptors: title, dates,
legislature/congress, rules and requirements,
costs to implement, and milestones.
Subject area: CONTROLLING_INSTRUMENTS
Properties: Min Occ: 0 Avg Occ: 0
Max Occ: 0 Growth Rate: 0% per year
Relationships:
Sometimes (0%) ESTABLISHES many REQUIREMENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_IMPLEMENTED_BY many REGULATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IMPLEMENTS_ANOTHER many LEGAL_MANDATE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IMPLEMENTS many LEGAL_MANDATE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Always IS_ISSUED_BY one GOVERNMENT_AGENCY
cannot transfer.
Sometimes (0%) APPLIESJTO many INFORMATION_REQUEST
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D Dec. 21, 1992 18:13
Subset: (complete model) page 30
Entity Definition
Entity: MONITORING_PLAN
Description: Documents the specific approach and schedule
that a PWS will use to satisfy monitoring
requirements.
Examples: Standardized Monitoring Framework.
Example descriptors: approval information,
required sampling frequency, required
sampling locations, deviation provisions
Subject area: PROGRAMS_AND_PLANS
Properties: Min Occ: 0 Avg Occ: 0
Max Occ: 0 Growth Rate: 0% per year
Relationships:
Sometimes (0%) IS_THE_BASIS_FOR many VIOLATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_BASED_ON many REQUIREMENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
Sometimes (0%) REQUIRES_SAMPLING_USING many STANDARD_TECHNIQUE_OR_PROCEDURE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) PRESCRIBES_TRANSPORTING_BY many STANDARD_TECHNIQUE_OR
PROCEDURE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) PRESCRIBES_ANALYSIS_BY many STANDARD_TECHNIQUE_OR_PROCEDURE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) APPLIES_TO many PUBLIC_WATER_SYSTEM
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) REQUIRES_SAMPLING_FOR many CONTAMINANT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_IMPLEMENTED_BY many BUDGET
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) PRESCRIBESJTAKING many SAMPLE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D
Subset: (complete model)
Entity Definition
Dec. 21, 1992 18:13
page 31
Entity:
Description:
Subject area:
Properties:
NON_GOVERNMENT_AGENCY_OR_COMPANY
A non-government agency, company, or
corporation (e.g., a private water company).
Examples include: professional association,
private water company, or
laboratory.
Example descriptors: name, address,
location, function.
LEGAL_ENTITIES
Min Occ:
Max Occ:
0 Avg Occ:
0 Growth Rate:
0% per year
Relationships:
Always IS_A many LEGAL_ENTITY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) EMPLOYS many INDIVIDUAL
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D
Subset: (complete model)
Entity Definition
Dec. 21,
1992 18:13
page 32
Entity:
Description:
Subject area:
Properties:
OPERATOR_CERTIFIGATE
Includes applications for certification,
tracking information, including renewal dates
and fees.
Examples: PWS operator certifications,
sample-taker certifications, back-flow tester
certifications, and certifications issued by
other agencies (e.g., plumber licenses,
electrician licenses, well-driller licenses,
etc.).
Example descriptors: purpose of certificate,
date is issue, period of validity, competency
test results, applicatant qualifications
(including education and training), and fees
paid.
CONTROLLING INSTRUMENTS
Min Occ:
Max Occ:
0 Avg Occ:
0 Growth Rate:
0% per year
Relationships:
Always BASED_ON one REQUIREMENT
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D
Subset: (complete model)
Entity Definition
Dec. 21, 1992 18:13
page 33
Entity:
Description:
PERMIT
Permit is issued by a government agency to
a PHS for a specified purpose and period.
Includes applications for permits,
tracking information, fees, including renewal
dates.
Examples: operating permit and
construction permit.
Example descriptors: application date, date
issued, period (end date), fee, activity
(e.g., treatment) permitted, conditions,
milestones, descriptions of limits/term of
permit.
Subject area:
Properties:
CONTROLLING INSTRUMENTS
Min Occ:
Max Occ:
0 Avg Occ:
0 Growth Rate:
0% per year
Relationships:
Always BASED ON many REQUIREMENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_ISSUED_TO one LEGAL_ENTITY
cannot transfer.
Sometimes (0%) APPLIESJTO many PUBLIC_WATER_SYSTEM
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Always IS_ISSUED_BY one GOVERNMENT_AGENCY
cannot transfer.
Sometimes (0%) IS_REQUIRED_TO_IMPLEMENT many ENGINEERING_PLAN
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D Dec. 21, 1992 18:13
Subset: (complete model) page 34
Entity Definition
Entity: POLICY_AND_GUIDANCE
Description: A set of instructions used to establish
policy or guide implementation of
Federal/State regulations.
Examples: the Primacy Guidance Manual Phase
II Implementation Guide for the Lead and
Copper Rule, also the Federal Reporting Data
System (FRDS) Reporting.
Example descriptors: title, date,
applicability, policies, and milestones.
Subject area: CONTROLLING_INSTRUMENTS
Properties: Min Occ: 0 Avg Occ: 0
Max Occ: 0 Growth Rate: 0% per year
Relationships:
Sometimes (0%) HELPS_TO_IMPLEMENT many REQUIREMENT
Cardinality Min: l (est) Max: 1 (est) Avg: l
cannot transfer.
Always IS_ISSUED_BY many GOVERNMENT_AGENCY
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
Sometimes (0%) HELPS_IN_PREPARATION_OF many CONTINGENCY_AND_EMERGENCY_PLANS
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
Sometimes (0%) GUIDES_PREPARING many ENGINEERING_PLAN
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWOW PWSS ISP MODEL V01.01D
Subset: (complete model)
Dec. 21, 1992 18:13
page 35
Entity Definition
Entity:
Description:
POPULATION_GROUP
Characterization of a group of persons who
consume drinking water provided by a public
water system as described and regulated by
Federal and State Drinking Water Regulations.
Examples: trailer parks, rest stops,
institutions, Indian tribes, subdivisions,
camp sites, cities, and districts.
Example Descriptors: political area, type of
population (wholesale, retail, transient,
non-transient, etc.) age, average income,
other demographic and geographical
characteristics of the consumer groups,
residence type, size of community, location
of community, distance community is from the
PWS, education level, primary language.
Subject area: INVENTORIES
Properties:
Min Occ:
Max Occ:
0 Avg Occ:
0 Growth Rate:
0% per year
Relationships:
Sometimes (0%) IS_SERVED_BY many PUBLIC_WATER_SYSTEM
Cardinality Min: 1 (est) Max: l (est) Avg: l
cannot transfer.
Sometimes (0%) RECEIVES many PUBLIC_NOTIFICATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_SERVED_BY one COMMUNICATIONS_MEDIA
cannot transfer.
Sometimes (0%) IS_IMPACTED_BY many ENVIRONMENTAL_EVENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_AFFECTED_BY many WEATHER_DATA
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D
Subset: (complete model)
Dec. 21,
1992 18:13
page 36
Entity Definition
Entity:
Description:
PROGRAM
Documents information on a component of an
environmental program. Includes Federal and
State programs and special programs (e.g.,
Pesticide Survey)
Examples: laboratory certification program,
reclamation and recharge program, ground
water permitting program, water treatment
device certification program, interstate
carrier program, bottled water program,
wellhead protection program, primacy
program, and grant and loan programs.
Example descriptors: program type, program
purpose, and milestones (beginning and ending
date).
Subject area: PROGRAMS_AND_PLANS
Properties:
Min Occ:
Max Occ:
0 Avg Occ:
0 Growth Rate:
0% per year
Relationships:
Sometimes (0%) IS_IMPLEMENTED_BY many PROGRAM_PLAN
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_DESCRIBED_BY many TECHNICAL_PUBLICATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_EXECUTED_BY many GOVERNMENT_AGENCY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) FUNDED_BY many BUDGET
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_EXAMINED_BY many REVIEW_AUDIT_AND_EVALUATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) PROVIDES_FOR many GUARANTEED_LOAN
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) REQUIRES many PUBLIC_NOTIFICATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) REQUIRES many TRAINING_EVENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) PROVIDES_FOR many TECHNICAL_ASSISTANCE
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
Sometimes (0%) RESPONDSJTO many INFORMATION_REQUEST
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
-------
Model : OGWDW PWSS ISP MODEL V01.01D Dec. 21, 1992 18:13
Subset: (complete model) page 37
Entity Definition
cannot transfer.
Sometimes (0%) PROVIDES_FOR one GRANT
cannot transfer.
Sometimes (0%) IS_DEVELOPED_BY one GOVERNMENT_AGENCY
cannot transfer.
Sometimes (0%) IS_APPROVED_BY many GOVERNMENT_AGENCY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) USES many CROSS_MEDIA_SYSTEM
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
Sometimes (0%) IS_DEVELOPED_BASED_UPON many RESEARCH_NEED
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D
Subset: (complete model)
Entity Definition
Dec. 21, 1992 18:13
page 38
Entity:
Description:
Subject area:
Properties:
PROGRAM_PLAN
Documents methods and assigns
responsibilities for implementing part of or
the entire program or programs mandated in
the Safe Drinking Water Act/State statute and
other regulatory instruments developed to
support the PWSS Program.
Examples: Outreach Plan, Regulatory Program
Plan, Work Plan, Lead & Copper Plan, etc.
Example descriptors: type, time,
dates, milestones, objectives, and
performance measurements.
PROGRAMS AND PLANS
Min Occ:
Max Occ:
0 Avg Occ:
0 Growth Rate:
0% per year
Relationships:
Always IMPLEMENTS many PROGRAM
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) PROVIDES_A_BASIS_FOR many GRANT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D
Subset: (complete model)
Entity Definition
Dec. 21,
1992 18:13
page 39
Entity:
Description:
Subject area:
Properties:
PUBLIC_NOTIFICATION
A notice that informs the public of possible
health risks, violations or operational
advisories (e.g, flushing). Public
notifications are made by public water
systems (but may be also made by government
agencies). Notifications may be written or
verbal.
Requirements for notification include
monitoring and reporting violations, MCL
violations, treatment technique violations,
variance/exemption non-compliance, failure to
comply with specified testing procedures, or
that a variance/exemption has been allowed.
An insufficient notification made by a PWS
may require that a government agency issue a
follow-up notification, which corrects the
deficiency.
Examples: news releases, personal letters,
boil water advisories, door-to-door
notification, postings, radio/TV
announcements and in-person notices.
Example descriptors: date of
release, description of health risk,
reporting period, duration of risk, risk
mitigation actions.
PROGRAMS AND PLANS
Min Occ:
Max Occ:
0 Avg Occ:
0 Growth Rate:
0% per year
Relationships:
Sometimes (0%) IS_A_RESULT_OF many VIOLATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Always IS_MADE_TO many POPULATION_GROUP
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_PROVIDED_FOR_BY many PROGRAM
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Always IS_ISSUED_BY many LEGAL_ENTITY
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
Sometimes (0%) IS_A_RESULT_OF many ENFORCEMENT_ACTION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D Dec. 21, 1992 18:13
Subset: (complete model) page 40
Entity Definition
This page intentionally left blank.
-------
Model : OGWDW PWSS ISP MODEL V01.01D Dec. 21, 1992 18:13
Subset: (complete model) page 41
Entity Definition
Entity: PUBLIC_WATER_SYSTEM
Description: Information concerning public water systems
(PWS). A PWS has at least 15 service
connections or regularly serves at least 25
individuals.
State and local definitions/classifications
may be more stringent than the SDWA
definition.
Examples: municipal water treatment
systems, rest stops, and camp sites.
Example descriptors: numbers of
service connnections, plant capacity,
addresses, operations and maintenance data,
distribution system information, etc.
Subject area: INVENTORIES
Properties: Min Occ: 0 Avg Occ: 0
Max Occ: 0 Growth Rate: 0% per year
Relationships:
Always USES many DRINKING_WATER_SOURCE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Always IS_OWNED_BY many LEGAL_ENTITY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) SERVES_AS_A_SELLING many DRINKING_WATER_SOURCE
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
Sometimes (0%) IS_JEOPARDIZED_BY many WATER_THREAT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) SERVES many POPULATION_GROUP
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) CONSISTS_OF many WATER_SYSTEM_FAGILITY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) HAS many PERMIT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) HAS_A_RESPONSIBLE many INDIVIDUAL
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_FUNDED_BY many GUARANTEED_LOAN
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_EXAMINED_BY many REVIEW_AUDIT_AND_EVALUATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
-------
Model : OGWDW PWSS ISP MODEL V01.01D Dec. 21, 1992 18:13
Subset: (complete model) page 42
Entity Definition
cannot transfer.
Sometimes (0%) IS_THE_SUBJECT_OF many ENFORCEMENT_ACTION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_REQUIRED_TO_FOLLOW many REQUIREMENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_GRANTED many DEVIATION
Cardinality Min: l (est) Max: l (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_GOVERNED_BY many MONITORING_PLAN
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) PREPARES many ENGINEERING_PLAN
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
Sometimes (0%) IS_THE_SUBJECT_OF many COMPLAINT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) CONSIDERS many HAZARDOUS_WASTE_INFORMATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D Dec. 21, 1992 18:13
Subset: (complete model) page 43
Entity Definition
Entity: REGULATION
Description: A directive and enforceable document, issued
by a State or Federal agency, that implements
a Federal or State law.
Examples: National Primary Drinking
Water Regulations and National Secondary
Drinking Regulations.
Example descriptors: issue date,
effective date(s), citation, level, name,
number, and milestones.
Subject area: CONTROLLING_INSTRUMENTS
Properties: Min Occ: 0 Avg Occ: 0
Max Occ: 0 Growth Rate: 0% per year
Relationships:
Sometimes (0%) ESTABLISHES many REQUIREMENT
Cardinality Min: l (est) Max: 1 (est) Avg: l
cannot transfer.
Sometimes (0%) IMPLEMENTS_ANOTHER many REGULATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IMPLEMENTS many REGULATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IMPLEMENTS many LEGAL_MANDATE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_RELATED_TO_ANOTHER many REGULATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_RELATED_TO many REGULATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Always IS_ISSUED_BY one GOVERNMENT_AGENCY
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D
Subset: (complete model)
Dec. 21, 1992 18:13
page 44
Entity Definition
Entity:
Description:
REQUIREMENT
Identifies State and Federal PWSS Program
requirements resulting from statutes,
agreements, policies, regulations, permits,
certifications, and guidance.
Examples: type contaminants being
tracked, maximum contaminant levels, type of
samples, sampling techniques, treatment
techniques, and frequency of sampling.
Example descriptors: type, frequency, and
milestones.
Subject area: CONTROLLING_INSTRUMENTS
Properties:
Min Occ:
Max Occ:
0 Avg Occ:
0 Growth Rate:
0% per year
Relationships:
Sometimes (0%) IS_ESTABLISHED_BY many REGULATION
Cardinality Min: 1 (est) Max: l (est) Avg: l
cannot transfer.
Sometimes (0%) IS_ESTABLISHED_BY many LEGAL_MANDATE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_DESCRIBED_BY many POLICY_AND_GUIDANCE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_ADMINISTERED_BY many AGREEMENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) ESTABLISHED_CRITERIA_FOR many LAB_CERTIFICATE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_CITED_BY many VIOLATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) PROVIDES_FOR_ISSUING many PERMIT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_MITIGATED_BY many DEVIATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) GUIDES many REVIEW_AUDIT_AND_EVALUATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IDENTIFIES_MCL_FOR many CONTAMINANT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_THE_BASIS_FOR many ENFORCEMENT_ACTION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D Dec. 21, 1992 18:13
Subset: (complete model) page 45
Entity Definition
Sometimes (0%) APPLIES_TO many PUBLIC_WATER_SYSTEM
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Always IS_ESTABLISHED_BY many GOVERNMENT_AGENCY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_THE_BASIS_FOR many MONITORING_PLAN
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) AUTHORIZES one GOVERNMENT_AGENCY
cannot transfer.
Sometimes (0%) SPECIFIES_ACTION_LEVELS_FOR many CONTAMINANT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) ESTABLISHES many OPERATOR_CERTIFICATE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D Dec. 21, 1992 18:13
Subset: (complete model) page 46
Entity Definition
Entity: RESEARCH_NEED
Description: Documents the needs for new and innovative
requirements to support the PWSS Program.
Examples include: new treatment techniques
and new sampling methods.
Example descriptors: type, sponsoring
organization (s), research organization (s),
and milestones.
Subject area: TECHNOLOGIES
Properties: Min Occ: 0 Avg Occ: 0
Max Occ: 0 Growth Rate: 0% per year
Relationships:
Sometimes (0%) IS_DESCRIBED_IN many TECHNICAL_PUBLICATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_ORIGINATED_BY many LEGAL_ENTITY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_FOLLOWED_BY many PROGRAM
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_CREATED_BY many REVIEW_AUDIT_AND_EVALUATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_CREATED_BY many SAMPLE_ASSESSMENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D
Subset: (complete model)
Entity Definition
Dec. 21, 1992 18:13
page 47
Entity:
Description:
RESEARCH_RESULT
Documents information obtained from research
and development projects, pilot studies, and
demonstrations.
Examples: Drinking water surveys and
studies, health effects studies, and
information on emerging technology.
Example descriptors:
findings.
type study, date, and
Relationships: published by LEGAL ENTITY
Subject area: TECHNOLOGIES
Properties:
Min Occ:
Max Occ:
0 Avg Occ:
0 Growth Rate:
0% per year
Relationships:
Sometimes (0%) ARE_BASIS_FOR_DEVELOPING many TREATMENT_EQUIPMENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) EXAMINES many STANDARD_TECHNIQUE_OR_PROCEDURE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) APPLIESJTO many ANALYTICAL_EQUIPMENT
Cardinality Min: l (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_DESCRIBED_IN many TECHNICAL_PUBLICATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D
Subset: (complete model)
Dec. 21, 1992 18:13
page 48
Entity Definition
Entity:
Description:
REVIEW_AUDIT_AND_EVALUATION
Results of an examination process of a
regulated entity or regulating community
activity. Review findings could result in a
formal audit or the scheduling of additional
on-site follow-up visits to support or
correct the situation.
Examples: Comprehensive Plant Evaluations
(CPE), reviews of exemptions and variances to
determine their validity, reviews of PWS
compliance with sampling requirements as
established by regulations, audits of proper
accounting practices, audits of the
maintenance of sampling records, on-site
visits to conduct a PWS sanitary survey,
on-site inspections of new PWSs, and reviews
of state drinking water programs. Reviews
may be formal (i.e., mandated by regulatory
instruments) or informal.
Example descriptors: date(s) of
review, type of review, finding(s),
recommended actions, and status of actions.
Subject area:
Properties:
COMPLIANCES
Min Occ:
Max Occ:
0 Avg Occ:
0 Growth Rate:
0% per year
Relationships:
Sometimes (0%) DETECTS many VIOLATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_GUIDED_BY many REQUIREMENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) EXAMINES many DEVIATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Always IS_PERFORMED_BY many GOVERNMENT_AGENCY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) EXAMINES many PROGRAM
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
Sometimes (0%) EXAMINES many PUBLIC_WATER_SYSTEM
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) RESULTS_FROM many COMPLAINT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) EVALUATES_IMPACT_OF many ENVIRONMENTAL_EVENT
-------
Model : OGWDW PWSS ISP MODEL V01.01D Dec. 21, 1992 18:13
Subset: (complete model) page 49
Entity Definition
CardinalityMin: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) RESULT_IN many RESEARCH_NEED
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D
Subset: (complete model)
Entity Definition
Dec. 21, 1992 18:13
page 50
Entity:
Description:
SAMPLE
Physical description of a water specimen
taken for the purpose of analyzing water
quality. Samples may be taken from either
raw (untreated) or treated water sources.
Samples are typically taken at representative
points within the distribution system or at
entry points to the distribution system, but
may be taken at the consumer's tap, or at the
water source (Surface Water Treatment Rule
[SWTR]).
Some samples may be combined (in a
laboratory) to form a composite sample.
Samples may be rejected (e.g., due to
improper handling or time lapse).
Examples:
sample.
raw water sample and treated water
Example descriptors: volume, date
and time collected, purpose, date reported,
sample type (e.g., routine, special, repeat),
preservative/preservation techniques,
chain of custody.
Subject area:
Properties:
SAMPLES
Min Occ:
Max Occ:
0 Avg Occ:
0 Growth Rate:
0% per year
Relationships:
Always IS_TAKEN_BY one LEGAL_ENTITY
cannot transfer.
Sometimes (0%) IS_ANALYZED_BY one LABORATORY
cannot transfer.
Sometimes (0%) IS_TAKEN_AT many DRINKING_WATER_SOURCE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Always IS_TAKEN_BY one INDIVIDUAL
cannot transfer.
Sometimes (0%) IS_TAKEN_AT many WATER_SYSTEM_FACILITY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_TAKEN_ACCORDING_TO many MONITORING_PLAN
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_TAKEN_ACCORDING_TO many STANDARD_TECHNIQUE_OR_PROCEDURE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) RESULTS_IN many SAMPLE_ANALYTICAL_RESULT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D Dec. 21, 1992 18:13
Subset: (complete model) page 51
Entity Definition
Sometimes (0%) IS_A_COMPOSITE_OF many SAMPLE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_A_COMPOSITE many SAMPLE
Cardinality Min: I (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) CHARACTERIZES one WATER_HABITAT_QUALITY_INFO
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D
Subset: (complete model)
Dec. 21,
1992 18:13
page 52
Entity Definition
Entity:
Description:
SAMPLE_ANALYTICAL_RESULT
Results of the analysis of samples by
laboratories and field equipment.
Typically identifies contaminants and
the level of contamination. A sample that
exceeds maximum contaminant levels may result
in an MCL violation and a sample that exceeds
the method detection
limit may result in a detection.
The sample analytical result may be rejected
and/or invalidated the reason for the
rejection will be
noted.
Example descriptors: results (measurements),
date analysis completed, date results
reported.
Subject area:
Properties:
SAMPLES
Min Occ:
Max Occ:
0 Avg Occ:
0 Growth Rate:
0% per year
Relationships:
Sometimes (0%) MEASURES many CONTAMINANT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Always IS_PREPARED_BY one LABORATORY
cannot transfer.
Always IS_BASED_ON many SAMPLE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_REPORTED_TO many LEGAL_ENTITY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Always IS_PREPARED_BY many INDIVIDUAL
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_BASED_ON many STANDARD_TECHNIQUE_OR_PROCEDURE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) ARE_USED_TO_PERFORM many SAMPLE_ASSESSMENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D
Subset: (complete model)
Entity Definition
Dec. 21, 1992 18:13
page 53
Entity:
Description:
Subject area:
Properties:
SAMPLE_ASSESSMENT
Assessment of analytical results to determine
action to be taken.
Examples: compliance determination
findings, determinations of changes to
monitoring schedules, 90th percentile results
compared with action levels, etc.
Example descriptors: findings of the
assessment, date, required/recommended
actions, schedules
SAMPLES
Min Occ:
Max Occ:
0 Avg Occ:
0 Growth Rate:
per year
Relationships:
Always IS_BASED_ON one SAMPLE_ANALYTICAL_RESULT
cannot transfer.
Always IS_PERFORMED_BY one LEGAL_ENTITY
cannot transfer.
Sometimes (0%) RESULT_IN many RESEARCH_NEED
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D Dec. 21, 1992 18:13
Subset: (complete model) page 54
Entity Definition
Entity: STANDARD_TECHNIQUE_OR_PROCEDURE
Description: Identifies standards to follow in a
scientific method or procedure, data flow
procedure, data formats, or operational
procedure.
Examples: analytical method, treatment
technique, preservation technique, and
sampling procedure.
Example descriptors: title, effective date,
purpose, method detection limit, and
approving authority, BAT status,
certifications, etc.
Relationships: approved by LEGAL ENTITY,
developed by LEGAL ENTITY
Subject area: TECHNOLOGIES
:
Properties: Min Occ: 0 Avg Occ: 0
Max Occ: 0 Growth Rate: 0% per year
Relationships:
Sometimes (0%) IS_USED_BY many ANALYTICAL_EQUIPMENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
Sometimes (0%) IS_EXAMINED_BY many RESEARCH_RESULT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_APPLIED_BY many WATER_SYSTEM_FACILITY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_USED_FOR_SAMPLING_BY many MONITORING_PLAN
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_CITED_FOR_TRANSPORTING_BY many MONITORING_PLAN
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
Sometimes (0%) IS_CITED_FOR_ANALYSIS_BY many MONITORING_PLAN
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) ARE_USED_IN_PREPARING many ENGINEERING_PLAN
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_DESCRIBED_BY many TECHNICAL_PUBLICATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_TRAINED_BY many TRAINING_EVENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
Sometimes (0%) IS_PRESCRIBED_FOR_TAKING many SAMPLE
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
-------
Model : OGWDW PWSS ISP MODEL V01.01D Dec. 21, 1992 18:13
Subset: (complete model) page 55
Entity Definition
cannot transfer.
Sometimes (0%) IS_CERTIFIED_FOR_USE_BY many LABORATORY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_USED_TO_DETERMINE many SAMPLE_ANALYTICAL_RESULT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D Dec. 21, 1992 18:13
Subset: (complete model) page 56
Entity Definition
Entity: TECHNICAL_ASSISTANCE
Description: Describes technical services provided to/or
requested by a PWS, laboratory or regulating
activity.
Examples: Routine and emergency technical
assistance.
Example descriptors: cost(s), method,
date(s), reason, and technical staff.
Subject area: PROGRAMS_AND_PLANS
Properties: Min Occ: 0 Avg Occ: 0
Max Occ: 0 Growth Rate: 0% per year
Relationships:
Sometimes (0%) IS_PROVIDED_FOR_UNDER many PROGRAM
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_PROVIDED_BY many LEGAL_ENTITY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_PROVIDED_TO many LEGAL_ENTITY
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
Sometimes (0%) IS_PROVIDED_TO_SUPPORT many ENGINEERING_PLAN
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) RESPONDS_TO many ENVIRONMENTAL_EVENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D
Subset: (complete model)
Dec. 21, 1992 18:13
page 57
Entity Definition
Entity:
Description:
TECHNICAL_PUBLICATION
Describes the inventory of outreach products
about the State or Nation's drinking water,
or related topic.
Examples: information guides, health
advisories, pamphlets, newsletters, public
news releases, videos, and audio cassettes
used for consumer education and/or technical
assistance/water system outreach.
Example descriptors: type, title,
medium, targeted community, publication
date, synopsis, version, and cost.
Subject area: TECHNOLOGIES
Properties:
Min Occ:
Max Occ:
0 Avg Occ:
0 Growth Rate:
0% per year
Relationships:
Sometimes (0%) DESCRIBES many PROGRAM
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
Sometimes (0%) IS_PREPARED_BY many LEGAL_ENTITY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_DISTRIBUTED_BY many LEGAL_ENTITY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_DISTRIBUTED_BY many COMMUNICATIONS_MEDIA
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) DESCRIBES many STANDARD_TECHNIQUE_OR_PROCEDURE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) DESCRIBES_USE_OF many TREATMENT_EQUIPMENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) DESCRIBES_USE_OF many FIELD_EQUIPMENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) DESCRIBES_USE_OF many ANALYTICAL_EQUIPMENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) DESCRIBES many RESEARCH_RESULT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) DESCRIBES many RESEARCH_NEED
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_THE_BASIS_FOR many TRAINING_EVENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
-------
Model : OGWDW PWSS ISP MODEL V01.01D Dec. 21, 1992 18:13
Subset: (complete model) page 58
Entity Definition
cannot transfer.
Sometimes (0%) DESCRIBES many CROSS_MEDIA_S₯STEM
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D Dec. 21, 1992 18:13
Subset: (complete model) page 59
Entity Definition
Entity: TRAINING_EVENT
Description: Describes training associated with
requirements of the PWSS program, including
operator and laboratory certification
training.
Examples: classroom lecture, self-study
guide, automated tutorial, and
video for certification, regulatory
implementation, sanitary engineers, data
management.
Example descriptors: descriptions,
staff requirements, durations, locations, and
schedules, CEUs, level of certification
supported, costs, prerequisites.
Subject area: PROGRAMS_AND_PLANS
Properties: Min Occ: 0 Avg Occ: 0
Max Occ: 0 Growth Rate: 0% per year
Relationships:
Sometimes (0%) SUPPORTS many PROGRAM
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_APPROVED_BY many LEGAL_ENTITY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_PRESENTED_BY many LEGAL_ENTITY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_ATTENDED_BY many INDIVIDUAL
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_PRESENTED_BY many INDIVIDUAL
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_DEVELOPED_BY many INDIVIDUAL
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) PROVIDES_TRAINING_FOR many STANDARD_TECHNIQUE_OR_PROCEDURE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_BASED_ON many TECHNICAL_PUBLICATION
cardinality Min: 1 (est) Max: l (est) Avg: l
cannot transfer.
Sometimes (0%) PROVIDES_TRAINING_FOR many ANALYTICAL_EQUIPMENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) PROVIDES_TRAINING_FOR many FIELD_EQUIPMENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D Dec. 21, 1992 18:13
Subset: (complete model) page 60
Entity Definition
Sometimes (0%) PROVIDES_TRAINING_FOR many TREATMENT_EQUIPMENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D
Subset: (complete model)
Dec. 21, 1992 18:13
page 61
Entity Definition
Entity:
Description:
TREATMENT_EQUIPMENT
Capabilities of equipment used to
alter/improve water quality.
Examples: Filters, sedimentation basins, and
chlorinators.
Example descriptors: type and purpose, date
installed and manufactured date, capacity,
usage period (e.g., seasonal), backup or
on-line, chemicals needed for the process,
maintenance and inspection schedule.
Relationships: uses STANDARD TECHNIQUE OR
PROCEDURE, manufactured by LEGAL ENTITY
Subject area:
Properties:
TECHNOLOGIES
Min Occ:
Max Occ:
0 Avg Occ:
0 Growth Rate:
0% per year
Relationships:
Sometimes (0%) IS_USED_AT many WATER_SYSTEM_FACILITY
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_DEVELOPED_BASED_ON many RESEARCH_RESULT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_INSTALLED_OR_MODIFIED_PER many ENGINEERING_PLAN
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_DESCRIBED_BY many TECHNICAL_PUBLICATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_TRAINED_BY many TRAINING_EVENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D
Subset: (complete model)
Dec. 21, 1992 18:13
page 62
Entity Definition
Entity:
Description:
VIOLATION
Documents a breach of a requirement.
Violations are detected by assessment of
sample results or reviews (including on site
visits). Violations may lead to legal
actions or compliance orders. Violations are
publicized, when required, by public
notification. Violations may be remedied
by compliance/enforcement remedies, such as
improved filtration techniques or changes in
procedures.
Examples: MCL violations, failure to replace
lead service lines, monitoring and reporting
violations, treatment technique violations,
and procedural violations.
Example descriptors: type, date,
description, severity, and recommended
corrective action(s) to include milestones.
Subject area: COMPLIANCES
Properties:
Min Occ:
Max Occ:
0 Avg Occ:
0 Growth Rate:
per year
Relationships:
Sometimes (0%) IS_DETECTED_BY many REVIEW_AUDIT_AND_EVALUATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) RESULTS_IN many AGREEMENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) RESULTS_IN many ENFORCEMENT_ACTION
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Always CITES many REQUIREMENT
cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
Sometimes (0%) RESULTS_IN many PUBLIC_NOTIFICATION
cardinality Min: 1 (est) Max: l (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_BASED_ON_FAILING_TO_FOLLOW many MONITORING_PLAN
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Always IS_ISSUED_BY one GOVERNMENT_AGENCY
cannot transfer.
Always IS_THE_RESULT_OF many COMPLAINT
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
Sometimes (0%) IS_THE_RESULT_OF many ENVIRONMENTAL_EVENT
Cardinality Min: 1 (est) Max: l (est) Avg: l
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D
Subset: (complete model)
Entity Definition
Dec. 21, 1992 18:13
page 63
This page intentionally left blank.
-------
Model : OGWDW PWSS ISP MODEL V01.010
Subset: (complete model)
Dec. 21, 1992 18:13
page 64
Entity Definition
Entity:
Description:
WATER_HABITAT_QUALITY_INFO
Provides viability information relating to
the suitability of water systems as habitats
for nature.
Examples include: marshlands, lakes, bays,
rivers, estuaries, etc.
Example descriptors include: pollutants,
name, type, geographical location, water
quality assessment, biological population,
etc.
Subject area: CROSS_MEDIA_SOURCES
Properties:
Min Occ:
Max Occ:
0 Avg Occ:
0 Growth Rate:
0% per year
Relationships:
Sometimes (0%) IS_PROVIDED_BY many CROSS_MEDIA_SYSTEM
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_CHARACTERIZED_BY many SAMPLE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) DESCRIBES many DRINKING_WATER_SOURCE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D
Subset: (complete model)
Dec. 21, 1992 18:13
page 65
Entity Definition
Entity:
Description:
WATER_SYSTEM_FACILITY
Describes the public water system's resources
to collect, store, treat, and distribute
water to its consumers.
Examples: treatment facility, pumping
station, storage tank, wellhead,
water intake, entry points, pipeline
systems , etc .
Example descriptors: type facility, storage
capacity, pumping capacity, and location.
EPA's "Facility Identification Data Standard
Implementation Plan" codes may be used in the
future to identify these facilities.
Subject area: INVENTORIES
Properties:
Min Occ:
Max Occ:
0 Avg Occ:
0 Growth Rate:
0% per year
Relationships :
Sometimes (0%) USES many TREATMENT_EQUIPMENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_PART_OF many PUBLIC_WATER_SYSTEM
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) USES many ANALYTICAL_EQUIPMENT
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) APPLIES many STANDARD_TECHNIQUE_OR_PROCEDURE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_BUILT_OR_MOD_ACCORDING_TO one ENGINEERING_PLAN
cannot transfer.
Sometimes (0%) PROVIDES many SAMPLE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D
Subset: (complete model)
Dec. 21, 1992 18:13
page 66
Entity Definition
Entity:
Description:
WATER_THREAT
Documents phenomena and events that
adversely affect drinking water.
Examples: threats from nature (e.g.,
bacteria, viruses, other microorganisms),
naturally occurring materials such as
arsenic, cadmium, chromium, and nitrates;
threats from society (e.g., spills,
chemicals both legally and illegally
discharged from industrial and other
processes, "tampering, runoff from city
streets, parking lots, and rooftops, leakage
of chemicals and wastes from underground
storage tanks; runoff of agricultural
pesticides and fertilizers, leachate from
landfills and waste dumps, injection of waste
fluids into underground wells, improper use
and disposal of household wastes, such as
used oil, cleaning products, and lawn and
garden chemicals, faulty septic tanks and
sewage systems; and threats from treatment
and distribution (e.g., formation of
disinfection by-products (for example,
trihalomethanes), corrosion by-products, and
other contaminants resulting from water
treatment and distribution).
Includes risk assessment methods,
vulnerability analysis, and rate of return on
investment information.
Example descriptors: threat type,
threat site, expected effects on water
quality, threat probability, health risks,
mitigation options, and mitigation costs,
regulating program.
Subject area: INVENTORIES
Properties: Min Occ:
Max Occ:
0 Avg Occ:
0 Growth Rate:
0% per year
Relationships:
Sometimes (0%) JEOPARDIZES many DRINKING_WATER_SOURCE
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) JEOPARDIZES many PUBLIC_WATER_SYSTEM
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) IS_RESPONDED_TO_BY many CONTINGENCY_AND_EMERGENCY_PLANS
Cardinality Min: l (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D Dec. 21, 1992 18:13
Subset: (complete model) page 67
Entity Definition
Sometimes (0%) IS_CAUSED_BY many HAZARDOUS_WASTE_INFORMATION
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
Sometimes (0%) RESULTS^FROM many ENVIRONMENTAL_EVENT
Cardinality Min: T (est) Max: 1 (est) Avg: 1
cannot transfer.
-------
Model : OGWDW PWSS ISP MODEL V01.01D
Subset: (complete model)
Entity Definition
Dec. 21, 1992 18:13
page 68
Entity:
Description:
WEATHER_DATA
Describes meteorological phenomenae.
Examples include: hurricanes, tornadoes,
floods, thunderstorms, climatological data,
etc.
Example descriptors include: type, date(s),
threat evaluation, impacts, population
affected, etc.
Subject area: CROSS_MEDIA_SOURCES
Properties:
Min Occ:
Max Occ:
0 Avg Occ:
0 Growth Rate:
0% per year
Relationships:
Sometimes (0%) IS_PROVIDED_BY many CROSS_MEDIA_SYSTEM
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) HELP_ANALYZE many DRINKIN6_HATER_SOURCE
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
Sometimes (0%) IS_CONSIDERED_BY many CONTINGENCY_AND_EMERGENCY_PLANS
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
Sometimes (0%) FORECASTS many CONTAMINANT
Cardinality Min: 1 (est) Max: 1 (est) Avg: l
cannot transfer.
Sometimes (0%) AFFECTS many POPULATION_GROUP
Cardinality Min: 1 (est) Max: 1 (est) Avg: 1
cannot transfer.
-End of Report-
-------
-------
SDC-0055-012-TB-2009
December 31, 1992
Appendix I
Entity Relationship Diagram
This appendix contains a diagram depicting the relationships of entity types with other entity
types, as well as, entity types within subject areas.
-------
PAGE NOT
AVAILABLE
DIGITALLY
-------
-------
SDC-0055-012-TB-2009
December 31, 1992
Appendix J
Function Hierarchy Diagram with Descriptions
This appendix contains a diagram of the top level functions and separate diagrams of the next
level functions for each sibling of the top level. The sibling diagrams will be accompanied by
the definitions of each function within the diagram.
-------
SDC-0055-012-TB-2009
December 31, 1992
iPUBL
RISK AND VULNERABILITY
C UATER SYSTEM SUPERVISION
PROGRAM ADMINISTRATION
UATER RESOURCE PLANNING
[TECHNOLOGY AMD METHODS
DATA MAMAfiEMCIIT
LAB CAPACITY AMD CERTIFICATION
OPERATOR CERTIFICATION
ENGINEERING PLAN REVIEW
FIELD SURVEILLANCE
DISEASE OUTBREAK AMD SURVE1LLANC
COMPLIANCE DETERMINATION RESOLUT
TECHNICAL ASSISTANCE
ENFORCEMENT
.TRAINING
OUTREACH
ooo
ooo
000
000
000
ooo
ooo
ooo
ooo
ooo
000
000
J-1
-------
SDC-0055-012-TB-2009
December 31, 1992
PROGRAM ADMINISTRATION
RULE AND REGULATION DEVELOPM>
RESOURCE MANAGEMENT
IMPLEMENTATION PLANKING
PRIMACY ADMINISTRATION
LCIITDAKCE PROVISION
-u
GRANT AND LOAN A
OfLLHXSTK
ATION
SUPPORT
J-2
-------
SDC-0055-012-TB-2009
December 31, 1992
RULE_AND_REGULATION_DEVELOPMENT
Developing rules and regulations, including inputing to higher level policies (i.e.,
State input to Federal rule development), and inputing to other program
rule/regulation development processes.
RESOURCE_MANAGEMENT
Managing resources (equipment, budgets and people) for PWS supervision, justifying
resource needs, and defending resources. Includes steps taken by States to sustain
primacy, obtain sufficient resources to fulfill primacy responsibilities, etc.
IMPLEMENTATION_PLANNING
Preparing and reviewing implementation plans. Examples include:
PRIMACY_ADMINISTRATION
Developing and reviewing primacy packages; requesting, granting and revoking
primacy; and developing and reviewing requests to revise primacy agreements.
GUIDANCE_PROVISION
Providing information on current and new programs (e.g., well head protection,
vulnerability assessment), interpreting regulations, providing reporting guidance,
providing guidance on systems interface, and providing information on steps
necessary to retain/obtain primacy.
GRANT_AND_LOAN_ADMINISTRATION
Preparing and reviewing grant requests, developing and implementing guidance for
work plans, preparing and reviewing work plans, funding work plans, and reporting
and reviewing progress on work plans. Also including guaranteed loan administration
at the State level.
IMPLEMEhfTATION_SUPPORT
Providing support in implementing PWS programs. Examples include:
Intergovernmental Personnel Act (IPA) program support, ad hoc personnel
assignments such as paralegal support, etc.
J-3
-------
SDC-0055-012-TB-2009
December 31. 1992
WATER RESOURCE PLANNING
SUPPLY FORECASTING
DEMAND FORECASTING
GEOGRAPHIC AREA ANALYSTS
INEED FORECASTING
SOURCE PROTECTION
CONTINGENCY PLANNING
ALLOCATION
CONSgRVA
.TTON ACTIONS
J-4
-------
SDC-0055-012-TB-2009
December 31, 1992
SUPPLY_FORECAST1NG
Includes analyzing source capacity and availability to determine future supply.
Includes long and short range and State-wide forecasts.
DEMAND_FORECASTING
Conducting studies of demographics and industrial/residential/agricultural development
to characterize future/existing demand.
GEOGRAPfflC_AREA_ANALYSIS
Performing analyses of geographic areas to support water resource allocation.
Includes demand, water rights, vulnerability assessment, non-point and point sources,
etc.
NEED_FORECASTING
Forecasting the needs for funds to support provision of adequate water supplies.
Includes projecting growth and analyzing other demographic information, projecting
plant/treatment capacity, engineering evaluations, etc.
SOURCE_PROTECTION
Protecting sources (and potential sources) from contamination. Includes evaluation of
zoning, land use restrictions, building permits for large residential and industrial
facilities, as well as source evaluation and protection including well head protection,
watershed protection, etc.
CONTINGENCY_PLANNING
Planning to respond to shortages and emergencies (e.g., emergency responses,
regional shortages, seasonal variations, planning alternate sources for supply, etc.).
Includes preparation and review of plans, providing guidance, and performing
coordination.
ALLOCATION
Activities relating to allocating water resources, including water rights, reviewing and
approving allocation permit applications, etc.
J-5
-------
SDC-0055-012-TB-2009
December 31, 1992
CONSERVATION_ACTIONS
Activities relating to the implementation of water conservation.
J-6
-------
SDC-0055-012-TB-2009
December 31, 1992
RISK AND VULNERABILITY ASSES>
RISK DETERMINATION
VnUTERABILTTY ANALYSIS
HEALTH ADVISORY DEVELOPMENT
CROSS
J-7
-------
SDC-0055-012-TB-2009
December 31, 1992
RISK_DETERMINATION
Establishing the risk and potential risk to the public of using drinking water from
specific systems.
VULNERABILITY_ANALYSIS
Analyzing occurrence data, geological and hydrological information, and other
information concerning sources of contamination to assess trends and determine
vulnerabilities. Includes considering occurrences and trends in other environmental
and land use programs (e.g., underground storage, coordination with wellhead
protection program, agricultural chemical use, underground injection, etc.).
HEALTH_ADVISORY_DEVELOPMENT
Establishing State advisory levels, action levels, health based guidance levels, and
health advisories. Issuing advisories is detailed within Outreach.
CROSS_CONNECTION_CONTROL
Establishing and maintaining programs for cross-connection control and backflow
prevention. Includes site visits and inspections.
J-8
-------
SDC-0055-012-TB-2009
December 31, 1992
TECHNOLOGY AMD METHODS
TECHNOLOGY ASSESSMENT
PERIODIC SURVEY PERFORMANCE
APPLICATIONS AND METHODS DEV>
STANDARD DEVELOPMENT
J-9
-------
SDC-0055-012-TB-2009
December 31, 1992
TECHNOLOGY_ASSESSMENT
Assessing technology (existing,new or emerging) for application to treatment,
analytical techniques, or data collection and processing activities.
PERIODIC_SURVEY_PERFORMANCE
Conduct surveys to support ongoing research (e.g., National Pesticide Survey, NIRS,
unregulated contaminants, and special studies).
APPLICATIONS_AND_METHODS_DEVELOP
Activities relating to development of applications, methods and techniques. Includes
pilot studies, demonstrations, performance evaluations, and field tests of methods and
systems.
STAND ARD_DEVELOPMENT
Performing analysis and research to develop standards, including reviewing and
approving third party standards (analytical and treatment), out-of-state lab
certification, additives and tank coatings, POU device evaluations, and studies of
health effects; and performing cost/benefit analysis.
J-10
-------
SDC-0055-OI2-TB-2009
December 31, 1992
DATA MANAGEMENT
STATE FEDERAL INTERFACE GUID>
INFORMATION SYSTEMS DEVELOPM>
INFORMATION SYSTEMS MAINTENA>
REQUEST FOR INFORMATION RESP>
CROSS PROGRAM COORDINATION
[DATA ANALYSIS AND IHTERPRETA>
J-11
-------
SDC-0055-012-TB-2009
December31, 1992
STATE_FEDERAL_INTERFACE_GUIDANCE
Developing and providing guidance for system interfaces among Federal, State, local
and industry association systems as well as regulated community.
INFORMATION_SYSTEMS_DEVELOPMENT
Activities related to developing information systems.
lOTORMATIONJYSTEMSJtfADSTTENANCE
Maintaining and enhancing information systems, user support, maintaining
information system inventories and controlling information systems equipment.
Includes protecting information systems from loss, unauthorized access or
modification.
REQUEST_FOR_INFORMATION_RESPONSE
Responding to requests for information, including FOIA, congressional/legislative
inquiries, requests from AWWA and ASDWA, requests by lending institutions, etc.
Includes analysis of information.
CROSS_PROGRAM_COORDINATION
Coordinating with other programs, such as public health, water rights, CWA, RCRA,
Superfund, and CAA.
DATA_ANALYSIS_AND_INTERPRETATION
Performing analysis, verification and interpretation of data relating to implementation
of the PWSS program. Includes trend analysis.
J- 12
-------
SDC-0055-012-TB-2009
December 31, 1992
LAB CAPACITY AND CERTIFICATE
IAB SITE REVIEW
LAB PERSONNEL QUALIFICATION
LAB CAPABILITY CAPACITY ASSE>
IAB QA Qg PIAM EVALPATTOM
LAB CERTIFICATION
J-13
-------
SDC-0055-012-TB-2009
December 31, 1992
LAB_SITE_REVIEW
Visiting labs to evaluate methods, reporting procedures, chain of custody procedures,
etc.
LAB_PERSONNEL_QUALIFICATION
Evaluating the qualifications of lab personnel. May also include certification of
laboratory technicians. This function is performed by various agencies in the States,
and there are reciprocity agreements among various States.
LAB_CAPABILITY_CAPACITY_ASSESS
Assessing the capability of labs to perform analysis. Evaluating audit samples,
reviewing analysis results, and making assessment of capability and capacity using lab
certification standards. Includes assessing State-wide capacity, by method and
contaminant. May include work load allocation for some State-operated labs.
LAB_QA_QC_PLAN_EVALUATION
Evaluating laboratory quality assurance (QA) and quality control (QC) plans to
determine compliance with standards. May include data audits conducted by States
and EPA Regions.
LAB_CERTIFICATION
Issuing or revoking certificates of certification (or licenses), reviewing compliance
with terms of certification, renewing/revoking certification, assessing and collecting
fees. Certification is by method and contaminant group. May include activities to
certify certifying officers.
J- 14
-------
SDC-0055-012-TB-2009
December 31, 1992
OPERATOR CERTIFICATION
OPERATOR TRACKING
OPERATOR CLASSIFICATION
OPERATOR EXAM ADMINISTRATION
OPERATOR CERTIFICATE ISSUANCE
J- 15
-------
SDC-0055-012-TB-2009
December 31, 1992
OPERATORJTRACKING
Tracking operator applicants, operator certification levels, CEUs, and designation of
operator in charge and tracking fees.
OPERATOR_CLASSIFICATION
Determining the class of a specific PWS to determine operator classification level
requirements. Reviewing staff qualifications of PWSs to ensure that properly certified
staff are assigned. May also include determining if each shift at a PWS has properly
certified staff (by class).
OPERATOR_EXAM_ADMINISTRATION
Writing, validating and administering operator certification exams and collecting fees.
May be performed by other State agencies or third party agencies.
OPERATOR_CERTIFICATE_ISSUANCE
Preparing and issuing operator certificates. Certificates/licenses are issued for the
operation of the PWS. Includes revoking and renewing certificates and collecting fees.
J- 16
-------
SDC-0055-012-TB-2009
December 31. 1992
ENGINEERING PLAN REVIEW
CONSTRUCTION STANDARDS DEVEL>
ENGINEERING PLAN EVALUATION
[ENGINEERING FINANCIAL ASSIST>
[CONSTRUCTION INSPECTION
J- 17
-------
SDC-0055-012-TB-2009
December 31, 1992
CONSTRUCTION_STANDARDS_DEVELOPME
Developing standards (codes) for PWS construction. Includes design policies and
standards, construction permit requirements, etc.
ENGINEERING_PLAN_EVALUATION
Evaluating, commenting, and approving/rejecting proposed engineering plans (permit
applications) and reports relating to PWS construction. Also includes audit of
delegated evaluation (e.g., delegation of plan review to State regions, or delegation of
plan review to major utilities).
ENGINEERING_FINANCIAL_ASSISTANCE
Developing and reviewing requests for financial assistance to implement engineering
plans and construction, performing feasibility studies, prepare system designs, and
providing/tracking funds.
CONSTRUCnONJNSPECTION
Performing on site visits to review PWS construction projects and to verify
construction according to approved plans. Permits to operate are issued based on
results of these inspections.
J- 18
-------
SDC-0055-012-TB-2009
December 31, 1992
FTELD StJRVETtlANCE
SANITARY SURVEY SCHEDULING
SANITARY SURVEY PERFORMANCE
INSPECTION AMD SITE VISITS
SURVEY AND INSPECTION FOTrT^W>
J- 19
-------
SDC-0055-012-TB-2009
December 31, 1992
SANITARY_SURVEY_SCHEDULING
Scheduling sanitary surveys.
SANITARY_SURVEY_PERFORMANCE
Performing sanitary surveys, including providing technical assistance, enforcement
and permit review. Includes Comprehensive Performance Evaluation (CPE).
INSPECTION_AND_SITE_VISITS
Performing site visits and other inspections, O&M inspections, enforcement case
support, complaint investigations, special projects, etc.
SURVEY_AND_INSPECnON_FOLLOWUP
Verifying completion of corrective actions recommended/directed as a result of
sanitary surveys and other inspections. Includes tracking responses to third party
visits.
J-20
-------
SDC-0055-012-TB-2009
December 31, 1992
OUTBREAK ANALYSTS AND RECOMM>
[EPIDEMIOLOGY AMD PUB HEALTH >
PUBLIC NOTIFICATION
J-21
-------
SDC-0055-012-TB-2009
December 31, 1992
OUTBREAK_ANALYSISiAND_RECOMMENDA
Analyzing the disease outbreak to determine actions which should be taken to
preclude reoccurrence.
EPIDEMIOLOGY_AND_PUB_HEALTH_COOR
Collecting data and performing analyses and epidemiological investigations in
response to incidents and possible outbreaks of disease and other public health issues.
Includes studying numbers of occurrences to determine outbreaks, the source of the
outbreak (confirming or ruling out role of water). Also includes coordination with the
Center for Disease Control (CDC) and State Health Departments.
PUBLIC_NOTIFICATION
Notifying the public of precautionary measures required to protect themselves (cause,
effect, and treatment/preventative measure).
J-22
-------
SDC-0055-012-TB-2009
December 31, 1992
.COMPLIANCE DETERMINATION RESOLUT
INVENTORY
WAIVERS AND EXCEPTIONS ADMIN
PERMIT ISSUANCE
MONITORING PLAN DEVELOPMENT
WATER SAMPLING
MONITORING PERFORMANCE ASSESSMNT
J-23
-------
SDC-0055-012-TB-2009
December 31, 1992
INVENTORY
Identifying and maintaining the inventory of PWSs, including all characteristics and
facilities. Also includes complying with legal requirements relating to maintaining
inventory.
WAIVERS_AND_EXCEPTIONS_ADMIN
Considering needs to grant deviations to regulations or statutes, including waivers,
exceptions, variances, etc, and granting and revoking waivers/exceptions/variances.
Includes tracking and reviewing applications as well as compliance with terms of
waiver.
PERMTTJSSUANCE
Analyzing permit applications and provide comment/approval. Reviewing
qualifications of applicant, including financial viability, assessing and collecting fees,
and tracking. Includes issuing construction permits.
MONTTORING_PLAN_DEVELOPMENT
Developing monitoring plans and schedules, tracking compliance with schedules.
Includes site plan development and review.
WATER_SAMPLING
Taking water samples. Consists of planning, scheduling, taking and shipping
samples.
MONTTORING_PERFORMANCE_ASSESSMENT
Receiving and reviewing monitoring results and comparing with monitoring plans,
MCL's, Monitoring/Reporting, treatment techniques. Reviewing public notification
and PWS operational reports and O&M plans.
J-24
-------
SDC-0055-OI2-TB-2009
December 31, 1992
TECHNICAL ASSISTANCE
ITECH ASSISTANCE NEEDS ASSESS>
THIRD PARTY COORDINATION
TECHNICAL SUPPORT PROVISION
J-25
-------
SDC-OQS5-012-TB-2009
December 31, 1992
TECH_ASSISTANCE_NEEDS_ASSESSMENT
Assessing problems with the PWSs or regulating activities in order to determine the
need for technical assistance.
TEflRD_PARTY_COORDINATION
Arranging and coordinating to reduce overlap, and participating in seminars and
conferences.
TECHNICAL_SUPPORT_PROVISION
Providing technical support Includes providing funds, bulletin boards, hotline, site
visits, reporting experiences and trouble shooting. Also includes providing support to
State Utility Commissions for rate hearings.
1-26
-------
SDC-0055-012-TB-2009
December 31. 1992
.ENFORCEMENT
I ENFORCEMENT POLICY DEVELOPME>
L ENFORCEMENT CASE DEVELOPMENT
ENFORCEMENT TRACKING
j.27
-------
SDC-0055-012-TB-2009
December 31, 1992
ENFORCEMENT_POLICY_DEVELOPMENT
Developing enforcement policies, including review of State authority, developing of
State/EPA enforcement agreements, delegations to counties/State regions, targeting
and working with other agencies, determining SNC level, setting priorities for
enforcement.
ENFORCEMENT_CASE_DEVELOPMENT
Developing and preparing cases for enforcement actions against laboratories or PWSs.
Includes determining whether or not to pursue enforcement, type of enforcement
action to take, coordinating with State/Federal agencies, referrals, and preparing for
administrative and criminal/civil actions.
ENFORCEMENTJTRACKING
Tracking activities relating to enforcement. Includes tracking compliance order
implementation, penalties, coordination with Attorney General/Federal
prosecutor/State prosecutors, linking enforcement to violations, reporting
progress/status relating to enforcement actions, etc. Includes formal and informal
enforcement actions.
J-28
-------
SDC-0055-012-TB-2009
December 31, 1992
EMERGENCY RESPONSE
EMERGENCY PLAN IMPLEMENTATION
EMERGENCY RESPONSE ASSISTANCE
RESPONSE COORDINATION
J-29
-------
SDC-0055-012-TB-2009
December 31, 1992
EMERGENCY_PLAN_IMPLEMENTATION
Reviewing/rehearsing emergency plans to determine actions required, coordinating
with State/Federal emergency planning agencies, and providing input to State/Federal
emergency planning. Includes both local water system response (e.g., what to do if
the pump fails), as well as responding to broader area-wide emergencies.
EMERGENCY_RESPONSE_ASSISTANCE
Providing technical and financial assistance to PWSs so that they can effectively
respond to an emergency situation.
RESPONSE_COORDINATION
Coordinating with other State/Federal agencies to respond to emergencies and
analyzing results of remedial actions.
J-30
-------
SDC-0055-012-TB-2009
December 31, 1992
[TRAINING
TRAINING NEEDS IDENTIFICATION
TRAINING DEVELOPMENT
TRAINING PRESENTATION
TRAINING RECORDS MAINTENANCE
J-31
-------
SDC-0055-012-TB-2009
December 31, 1992
TRAINING_NEEDS_IDENTIFICATION
Reviewing survey results, violations, rules, regulations, technology, requests for
technical assistance, and needs of water systems to determine training needs. Includes
determining the type of training required for specific operator class and size of PWS
operation. Includes conducting operator job/skill task analysis to determine training
needs. May be performed by other State agencies.
TRAINING_DEVELOPMENT
Developing the training materials for presentation of training and arranging and
scheduling of training events. Includes developing training videos, handouts, lending
libraries, reference materials, including procedures to perform training.
TRAINING_PRESENTATION
Presenting training, including in-house and third party and training opportunities, for
the improvement of knowledge of technologies, rules, and management skills.
Includes training for PWSs, operators, technical providers, (e.g., rural water
association), labs, design engineers, and the regulating community.
TRAINING_RECORDS_MAINTENANCE
Evaluating, recording and maintaining the results of training.
J-32
-------
SDC-0055-012-TB-2009
December 31, 1992
OUTREACH
OUTREACH MATERIAL DEVELOPMENT
NETWORKING
RISK COMMUNICATION
PUBLIC EDUCATION
J-33
-------
SDC-0055-012-TB-2009
December 31, 1992
OUTREACH_MATERIAL_DEVELOPMENT
Developing and distributing reference materials and products to support the outreach
program. Includes software products, reference materials, establishing a bulletin
board, etc.
NETWORKING
Conducting interagency coordination, participating in professional and industry
associations and advisory committees, and developing press and legislative contacts to
support the outreach program.
RISK_COMMUNICATION
Providing information to the public and water industry (engineers, labs, etc.)
concerning risks relating to drinking water. Examples include preparing and
distributing public notification, boiled water* orders, newsletters, MCLs, health-based
guidance levels and their significance.
PUBLIC_EDUCATION
Educating the public concerning the drinking water program. Includes communicating
standard drinking water treatment technologies; responding to public inquiries; and
providing information on regulatory programs, enforcement, health effects, public
notice purpose. Uses a variety of media (e.g., hotline numbers, newspapers,
television, etc.).
J-34
-------
SDC-0055-012-TB-2009
December 31, 1992
This page intentionally left blank.
J-35
-------
SDC-0055-012-TB-2009
December 31, 1992
Function Dependency Diagrams
The following top level functional dependency diagram shows the sequence in which the
sixteen functions are chained together in the information architecture.
The following top level functional dependency diagram shows the sequence in which the
sixteen functions are chained together in the information architecture. The following
symbols are used in the diagram:
A large arrow represents one of three things: an event; the
availability of information from outside the business; or the passing
of a specific point in time, which triggers the execution of a process.
A box with rounded corners represents a business function.
A two-tiered box represents an external object, which is either the
source of information used by a process or the destination of
information produced by the process.
A line with arrows represents either a dependency or an information
flow. It shows either flow of control or the movement of
J-36
-------
nmic tarn n*n» WMIVIIIM
n
I
V/l
6
10
Nl
-------
SDC-0055-012-TB-2009
December 31, 1992
The following pages reflect each of the sixteen lower level functions in the order in which
they are shown in the functional hierarchy diagram on page N-3.
J-38
-------
u>
NO
D
§
IO
-------
s
N>
~£
-------
MtK MB MN.NCRMILIIV AUIUNM
> >
UVISORIES
-> >
CROM CONNECT
ION COHtROl
CONTROLS
Co
O
I
en
-------
1ICNNMMY AND NEIHOOI
IfH fCCHHOLM \ > >
i
ft
IEIE MCH HEED
lEWMCH NEED
\f
EV MMOMUNC
SMNOMDS AN
c/j
D
n
Ln
(fa
\o
-------
00
8
a w
Is
-------
LAB CAPACITY AND CERTIFICATE
IT FOR
CERT OR A
NNUAL REV
IEW
LAB SITE
REVIEW
FOR
CERT OR A
NNUAL REV
I EH
LAB PER80
NNBL QUAL
IFICATION
FOR
IEW
LAB CAPAB
ILITY CAP
ACITY ASS
ESS
HOST FOR
CERT OR A
NNUAL REV
IEW
LAB
PLAL _
LUATION
8A OC
EVA
LAB CERTI
FICATION
CERTIFIC
ATION OR
RENEWAL
-------
OTHATM CERTIFICATION
CEMIIMCMIO
M RENEWAL
CO
D
n
ft Ul
B E
fr£
» lv>
£ ^
- 00
-------
CHGINfMIM PLAN MVKU
CONSIMUCTIOM
INSPECIION
PPM
t
iKJfIOMS "
sr 2
-------
FIELD SURVEILLANCE
5EQUIREMB
TS
SANITARY
SURVEY SO
HBDULING
SANITARY
SURVEY PE
RFORNANCE
SURVEY AN
D INSPECT
ION FOLLO
HUP
1UIREME
INSPECTIO
N AND SIT
E VISITS
IEPORTS
VND VIOL
\TIONS
in
-------
DISEASE OUTBREAK AND SURVEI>
ts
E O
EPIDEHIOL
OGY AND P
UB HEALTH
COOR
OUTBREAK
ANALYSIS
AND RECON
MENDA
DISEASE
RESPONSE
PUBLIC NO
TIFICATIO
N
PUBLIC N
OTICE
-------
CO
(^
8
to
r5l
-------
TICMNICM. MIUTANCt
WMIIM Him «0
'S&S'SUBSS
NT
W
MM1 COO
SPRR""0
IION
MRCCNENTS
TECHNICAL SUPP
(Wl
D
§
li H
00
Sg
VO O
to C5
-------
ENFORCEMENT
STATUTE
VIOLATION
\ t
ENFORCEME
NT CASE D
EVELOPMEN
T
ENPORCEHE
NT TRACKI
NG
ENFORCEN
ENT RESU
LTS
-------
EMERGENCY RESPONSE
EMERGENCY 81
TUATION
EMERGENCY RE
SPONSB AS8IS
TANCE
A
EMERGENCY PL
AN IMPLEMENT
ATION
PERSON AGEN
CY OR PUS
RESPONSE COO
RDINATION
in
O
- 00
1
-------
1MIHIM
I
LA
08
-------
IIBK
M1MMIMO
AGKENENTS
A
\f
ItMH
I rot *wr
/ V
UK COHMMICAI
ION
PUBLIC COUCATIO
PUBLIC
2 H
- CO
-------
-------
SDC-0055-012-TB-2009
December 31, 1992
Appendix K
Function Supports Organizational Unit
This appendix contains a matrix showing functions associated with organizational units. An "x"
indicates that a particular function is supported by a particular organizational unit.
-------
PAGE NOT
AVAILABLE
DIGITALLY
-------
-------
SDC-0055-012-TB-2009
December 31, 1992
Appendix L
Concerns with the Current Environment
This appendix contains a consolidated list of concerns with the current environment which were
gathered during the interviews and JRP sessions.
-------
SDC-0055-012-TB-2009
December 31, 1992
Appendix L
Concerns with the Current Environment
Operational Considerations
Timeliness - data must be current to support operational decisions
need for timely feedback to field with reasons for non-compliance
Responsiveness, in terms of:
Getting information from the system
Accuracy of information
Better response time - need to respond to queries in a timely way
Data quality must be improved
edit process - data validation
should not be intrusive
present rules may be too tight (e.g., lab must be certified to accept data)
maybe different levels of validity instead of binary decision
The system must be user-friendly in terms of:
Ease to input data
Ease of producing reports
Ease of use by infrequent users (menu driven)
User help
Training of users must be straightforward, including:
Simplicity
Intuitive interface
The system must be flexible and tailorable to State needs.
Need to reduce repetitive data entry and reduce paper
Need easy method to input analysis results into the system
Cross Fiscal Years
L- 1
-------
SDC-0055-012-TB-2009
December 31, 1992
Operational Considerations (continued)
Need access to regulations/rules, such as:
"Reg in a Box" - including States
Compliance strategies, guidance
All reference materials
Need to capture deficiencies and remedial costs, including:
capitalization needs
engineering observations
milestones - 5 year plan
Costs to develop/maintain/enhance current systems must be brought under control
Need to capture contamination incidents which might impact supply, including:
linking pollution prevention with health vulnerability assessments
Ensure^garalfei developmeot at ihe State;Jeve1 wi& that at the Federal'level
fiif ca»\pa»vidfe bora State and Federal data
L. - .. . ** * ^ ' . f , ,. .
*»ew issues '
e^l - $&riag ' tW ^r liiigton ' 'JRP' session
,A.S . ' f SV t
L-2
-------
SDC-0055-OI2-TB-2009
December 31, 1992
Use of data
Use of information to support decision making (make my job easier)
* * ** * >-. Ww^J- *t f f f . *
Sampling data must be tied to specific samples
PWSS data must be integrated with other data, including
Clean Water Act data
Superfund data
Non-point source pollutant data
New systems must provide for public access, while protecting information from:
Tampering
Unauthorized access (i.e., raw data)
Data must be useful for the States and utilities
the
.
L-3
-------
SDC-0055-012-TB-2009
December 31, 1992
Data and Data Integration Requirements
Location information, including latitude and longitude, is essential
Compatibility with CIS systems (ARCINFO) must be achieved, including information
such as:
maps
hydrological
risk assessment of supply
cartography
analysis of supply
presentation
The timeliness and accuracy of data collection must be improved (electronic reporting
of data by labs)
ed data collection to' Iielp us write better regulations (economic,
, etc.)
'j"w'
Need for inventory data to be used/accessible
improve type* of data in the $ysC^iu».add qualify and quantity, etc,
eur issues adde4 ^taring tfce 'Ariihgteui 3SP session
* JJ f A . A %^ JV^ J^ t f f f ff f. ^ f. f t % ^
L-4
-------
SDC-0055-012-TB--2009
December 31, 1992
Data Analysis
A simplified means for determining compliance is essential
New systems must provide easy means to manipulate data, including:
Correcting errors
Updating data
Revising data
The system must provide clear ways to remove SNC's once they are compliant
Engineering tools are required for PWSs, including:
Process control/monitoring
Tracking contaminants by distribution zone
The system must provide meaningful statistics to support enforcement.
analysis of violations to develop program responses
same SNC algorithm as National
Costs of sampling and analysis must be reduced.
PWSs must be notified promptly of problems (automatic generation of notices?)
The system must support public notification.
Lack of analysis tools (filter rule - regression analysis)
System needs to determine MCL violations - not rely on labs/manual procedures
L-5
-------
SDC-0055-012-TB-2009
December 31, 1992
Other Considerations
States and Regions must know EPA's expectations for the new system and must have
assurance that EPA will follow through and Meld/support the new system.
The system must satisfy end-user's needs.
The system should be designed to promote compliance and use - the current system tends
to penalize States that fully satisfy reporting requirements.
States must be motivated to use the system by its functionality and benefits.
There must be a stronger correlation between rule development and data management.
The participation by States in the rule development process must be improved.
The reporting burden on States must be reduced.
The system must serve the people (vs. people serving the system).
The National needs for historical data should not dictate the means for satisfying real-
time needs at the operational (State) levels.
Users must understand the purpose for desired information.
Need to redesign regulations and reduce the number of types of violations. (Simplify)
Need to be able to develop variants to system easily
Can we> walk away w&h a gcxxt'system vision and future?
S f ^AA . J f. J* IF -fff ,.,f . . T*Jv . -k. W ". f St -.Aff * f f ft *nV f f>fffffff \ , f\V
tent.,, know our voice cos
Indicates *»e*r
'adde&T during t1i>^Ariihgt.o-n
L-6
-------
SDC-0055-012-TB-2009
December 31, 1992
Other Considerations (continued)
t ^ihe Ajc&i»gt0» CBRP ssession
-. V. . V. f.V \< 'f' * .f -. * 1. JWL .-
L-7
-------
SDC-0055-012-TB-2009
December 31, 1992
This page intentionally left blank.
»ek
L-8
-------
-------
SDC-0055-012-TB-2009
December 31, 1992
Appendix M
Entity Type Supported by Current Data Store
This appendix contains a matrix showing entity types associated with current data store. An "x1
indicates that a particular entity type is supported by a particular current data store.
-------
PAGE NOT
AVAILABLE
DIGITALLY
-------
-------
SDC-0055-012-TB-2009
December 31, 1992
Appendix N
Entity Type Satisfies Information Need
This appendix contains a matrix showing entity types associated with information needs. An "x"
indicates that a particular entity type satisfies a particular information need.
-------
PAGE NOT
AVAILABLE
DIGITALLY
-------
-------
SDC-0055-012-TB-2009
December 31, 1992
Appendix 0
Information Need is for Organizational Unit
This appendix contains a matrix showing information needs associated with organizational units.
An "x" indicates that a particular information need is for a particular organizational unit.
-------
PAGE NOT
AVAILABLE
DIGITALLY
-------
-------
SDC-0055-OI2-TB-2009
December 31, 1992
Appendix P
Function Supported by Current Information System
This appendix contains a matrix showing functions associated with current information systems.
An "x" indicates that a particular function is partially or fully supported by a particular current
information system.
-------
PAGE NOT
AVAILABLE
DIGITALLY
-------
-------
SDC-0055-012-TB-2009
December 31, 1992
Appendix Q
Current Data Store Used by Current Information
System
This appendix contains a matrix showing current data stores used by current information
systems. A "C" indicates that a particular current data store is used by a particular
organizational unit.
-------
Model :OGWDW PWSS ISP MODEL V01.01D
Date: Dec. 31, 1992
Subset: ALL Time: 09:13
Cell Values:
= Not referenced
C = Create
D = Delete
U = Update
R = Read only
!
§
3
Current Info System
CERCLIS
CL
DU1MS
ERTS
FIATS
FINDS
FRDS II
GICS
MSIS
NUUDS
PA STATE WATER PLAN SYSTEM
PCS
REG IN A BOX
RF
RIA
SRF AL
STORET BIOS
STORET UQS
UASP4
UBS
g
10
C
8
d
C
&
C
s
§
C
3
I
C
s
C
s
B
C
s
C
s
i
C
s
C
s
\
I
<
C
s
2
C
s
§
<
M
1
C
s
Si
C
s
g
C
s
£
i
C
s
C
s
s
C
s
C
s
s
C
Q-i
-------
-------
SDC-0055-012-TB-2009
December 31, 1992
Appendix R
Organizational Unit Uses Current Information System
This appendix contains a matrix showing organizational units associated with current information
systems. An "x" indicates that a particular organizational unit uses a particular current
information system.
-------
Model :OGWDW PWSS ISP MODEL V01.01D Date: Dec. 31, 1992'
Subset: ALL 'Time: 09:26
Cell Values:
= Not referenced
X = Include
123
4 5 6 |
7891
8
Current Info System
CERCLIS
CL
DWIMS
ERTS
FIATS
FINDS
FRDS II
GICS
MSIS
NWUDS
PA STATE WATER PLAN SYSTEM
PCS
REG IN A BOX
RF
RIA
SRF AL
STORET BIOS
STORET WQS
WASP4
WBS
§
g
X
X
X
X
X
X
X
9
g
X
X
X
X
X
X
X
X
X
X
X
s
X
X
X
X
X
X
X
X
X
X
X
X
X
X
I
g
i
X
X
X
X
X
i
X
X
X
X
X
X
.X
X
X
X
X
X
X
X
X
X
X
X
X
X
a
X
X
STATS IIGIOH 01 D1STIICT W MMI
X
X
X
X
X
X
X
X
X
X
X
R-l
-------
-------
SDC-0055-012-TB-2009
December 31, 1992
Appendix S
Business Function by Entity Type Usage
This appendix contains a matnx showing business functions with respect to entity type usage.
The cells of the Business Function by Entity Type Usage (or CRUD) matrix contain one of the
following "involvement indicators":
C = Create
R = Read
U = Update
D = Delete
A specific letter within a cell indicates that an entity type is either created, read, updated, or
deleted within a particular business function. The different involvement indicators do not carry
equal significance with regard to analysis. In order of importance, creates (Cs) supersede
deletes (Ds), which supersede updates (Us), which in turn supersede reads (Rs). To focus
attention on the most significant relationships, Rs have been hidden on this copy of the matrix.
Deletes are also excluded, because they will be identified during the Business Area Analysis
(BAA) development stage of the PWSS project.
-------
PAGE NOT
AVAILABLE
DIGITALLY
-------
-------
SDC-0055-012-TB-2009
December 31, 1992
Appendix T
Business System by Business Function
This appendix contains a matrix showing business systems associated with business functions.
An "x" indicates that a particular business system is supported by a particular business function.
-------
PAGE NOT
AVAILABLE
DIGITALLY
-------
-------
SDC-0055-012-TB-2009
December 31, 1992
Appendix U
Data Store by Entity Type
This appendix contains a matrix showing natural data stores associated with entity types. An
"x" indicates that a particular data store is supported by a particular entity type.
-------
PAGE NOT
AVAILABLE
DIGITALLY
-------
-------
SDC-0055-012-TB-2009
December 31, 1992
Appendix V
Business Area by Natural Data Store
This appendix contains a matrix showing business areas associated with natural data stores.
An "x" indicates that a particular business area is supported by a particular data store.
-------
PAGE NOT
AVAILABLE
DIGITALLY
-------
-------
SDC-0055-012-TB-2009
December 31, 1992
Appendix W
Business Area by Entity Type
This appendix contains a matrix showing business areas associated with entity types. An "x"
indicates that a particular business area is supported by a particular entity type.
-------
PAGE NOT
AVAILABLE
DIGITALLY
-------
-------
SDC-0055-012-TB-2009
December 31, 1992
Appendix X
Business Area by Business System
This appendix contains a matrix showing business areas associated with business systems. An
x" indicates that a particular business area is supported by a particular business system.
it _, it
-------
PAGE NOT
AVAILABLE
DIGITALLY
-------
-------
SDC-0055-012-TB-2009
December 31, 1992
Appendix Y
Business Area by Business Function
This appendix contains a matrix showing business areas associated with business functions. An
"x" indicates that a particular business area is supported by a particular business function.
-------
PAGE NOT
AVAILABLE
DIGITALLY
-------
N
-------
SDC-0055-Q12-TB-2009
December 31, 1992
Appendix Z
System to System Category
This appendix contains a matrix showing business systems associated with system categories.
System categories include:
Strategic
Planning
Controlling
Operational
An "x" indicates that a particular business system falls into one or more of the system categories
listed above.
-------
PAGE NOT
AVAILABLE
DIGITALLY
-------
-------
SDC-0055-012-TB-2009
December 31, 1992
Appendix AA
Business Area by Business System
This appendix contains a matrix showing business systems associated with users. A " 1" is used
to indicate operational functions and a "2" is used to indicate strategic functions.
-------
PAGE NOT
AVAILABLE
DIGITALLY
-------
W
-------
SDC-0055-012-TB-2009
December 31, 1992
Appendix BB
Technical Architecture Working Group
This appendix lists the attendees to the Oct 21-23, 1992 Technical Architecture Group.
-------
SDC-0055-012-TB-2009
December 31, 1992
Technical Architecture Working Group Participants List
October 21 - 23, 1992
Attendee
Tracy Bair
AlBasham
Lynn Curry
Jon Dahl
Claudia Darnell
Randall Davis
Rey de Castro
Terry Fields
Barry Greenawald
Van Hoomagle
Bruce Keith
Bob King
Richard Lampert
Lee Manning
Dennis Martin
Doug Martinson
Evans Massie
Randy Moody
Abe Seigel
Jeff Sexton
Richard Smith
Steve Vassey
Larry Weiner
Sonny Wolfe
Don Worley
Larry Worley
Organization
SAIC
VADept of Health
SAIC
SAIC
US EPA Region IV/DWS
US EPA Region IV
ASDWA
AZ Dept of Environmental Quality
PA Dept of Environmental Resources
FL Dept of Environmental Resources
SAIC
US EPA Headquarters
US EPA Region DC
US EPA
SAIC
AKADEC
VADept of Health
NC Dept of Health and Natural Resources
US EPA Headquarters
US EPA Headquarters
SAIC
SC Dept of Health & Environmental Control
US EPA Headquarters
SAIC
US EPA, NDPD
US EPA Region X
BB- 1
-------
n
n
-------
SDC-0055-012-TB-2009
December 31, L992
Appendix CC
Entity Type by User
This appendix contains a matrix showing entity type associated with users. A "1", "2", or "3"
indicates a particular entity type is supported by a particular user.
-------
PAGE NOT
AVAILABLE
DIGITALLY
-------
o
D
-------
SDC-0055-012-TB-2009
December 31, 1992
Appendix DD
Communications Feasibility Analysis
This appendix contains a detailed analysis of the communications requirements to support data
transmission needs of the user groups within the PWSS Information System Technical
Architecture.
-------
SDC-0055-012-TB-2009
December 31, 1992
APPENDIX DD
COMMUNICATIONS FEASIBILITY ANALYSIS
The Public Water System Supervision (PWSS) Technical Architecture is dependent on
communication links between information sources, such as public water systems (PWSs) and
laboratories (Labs), and information centers, such' as State, State Region, EPA Region and the
National Computer Center (NCC). The central question for the PWSS Technical Architecture
is whether the goal of reporting contaminant measurements for all samples taken will result in
the need for excessive communications bandwidth. The analysis presented in this appendix
provides an estimate of the communications requirements needed so that the feasibility of the
PWSS Technical Architecture, from a communications point of view, can be determined. The
analysis considers the potential worst-case reporting requirement, namely that of reporting the
results for each contaminant, each sample, and each test The analysis is based on certain
assumptions, including the total number of PWSs reporting, the frequency of the laboratory (Lab)
reports, and the size of the Lab reports. The conclusions from this analysis are: the
communications needed to make the PWSS information System realizable are not a fundamental
constraint; and timely reporting of all contaminant measurements is feasible using a reasonable
dial-up and/or leased-line communications scheme.
The following steps are used to estimate the communications load:
» Find the total number of reporting units (on both a State and national basis).
These are the PWSs from which samples are taken.
* Determine the frequency (quarterly, monthly, weekly, etc.) of the samples.
V
* estimate the si Tie of each contaminant report.
» Determine the time to transmit the total number of reports within a State at
various line speeds (2.4Kbps, 4.8Kbps, and 9.6Kbps).
» Find the utilization of one communications line into the data center (at State level)
by averaging the time to transmit the report data over the reporting period.
The first step to determine the number of Lab reporting units on a State basis uses information
provided in the "Briefing on The Public Water System Supervision Compliance and Enforcement
Program," dated July 1991. This appendix gives the number of PWSs in -the Federal inventory
and the population served.
The data of interest are:
Number of PWSs = 200,990
- Population Served by PWSs = 242,048,000
DD- 1
-------
SDC-0055-012-TB-2009
December 31, 1992
Using these numbers, the following generalization can be made: The number of people per PWS
is approximately 1,204.
Using the above number and the population of each State, and assuming a normal distribution
of PWSs for estimating purposes, an approximate model of the number of reports sent from
PWSs and Labs in each State can be determined. Table DD-1 shows an estimate for the baseline
number of Lab reports sent to a State (State Region or EPA Region) data center from PWSs and
Labs. The number of PWSs shown in Table DD-1 is a baseline estimate and is meant to be an
average representation, not a detailed accurate count Table DD-1 shows three columns labelled
QUARTERLY, MONTHLY, and WEEKLY. These columns mean the following:
» QUARTERLY means the frequency of sampling and reporting is done on a
quarterly basis. The number shown in the column represents the number of Lab
reports sent per month based on quarterly sampling.
» MONTHLY means the frequency of sampling and reporting is done on a monthly
basis. The number shown in the column represents the number of Lab reports
sent per month based on monthly sampling.
» WEEKLY means the frequency of sampling and reporting is done on a weekly
basis. The number shown in the column represents the number of Lab reports
sent per month based on weekly sampling.
Some contaminant samples must be taken at least quarterly from each PWS (i.e., organic
chemicals and radionuclide chemicals). The use of quarterly, monthly, and weekly sampling in
this analysis is meant to define a potential reporting range with weekly sampling representing the
worst case (maximum number of Lab reports per fixed interval).
Using Pennsylvania (PA) as an example in Table DD-1, the row indicates that if all the PWSs
in that State sampled once per quarter, the number of reports per month would be 3,289. If
sampling was done on a monthly basis the number of reports per month would be 9,868 and if
sampling was done on a weekly basis, the number of reports per month would be 39,472. These
numbers are meant to bound the aggregate reporting load.
Table DD-2 uses the number of Lab reports estimated to be sent on a quarterly, monthly, and
weekly basis to compute the
communications load for line speeds of 2.4Kbps, 4.8Kbps and 9.6Kbps. Table DD-2 is based
on the following assumptions'
» Each PWS report contains information on 158 contaminants (83 at present, 25
additional over next three years). This number is taken from "The Mission Needs
Analysis for Information Systems Support for EPA's Public Water System
Supervision (PWSS) Program," January 9, 1992.
» Each contaminant measurement will be identified with a binary representation in
a fixed format report to maximize the information sent for a given number of bits.
DD-2
-------
SDC-0055-012-TB-2009
December 31, 1992
In such a scheme, each contaminant and its measurement test value can be
represented by an average of 4 bytes.
» The total number of bytes for a full contaminant Lab report is approximately 636
bytes. Assuming an approximate 80% overhead for error correction, etc., a
contaminant report size of 1000 bytes is assumed.
» Each byte transmitted requires 10 bits due to start and stop bits per byte
transmitted for asynchronous communications.
Based on the above, Table DD-2 shows the time (in hours) to transmit all the contaminant Lab
reports from all FWSs in a State to a State data center for different line speeds. Using Arizona
(AZ), for example, the Lab reports from all the PWSs will take 3.52 hours at 2.4Kbps, 1.76
hours at 4.8Kbps, and 0.88 hours at 9.6Kbps. California (CA), for example, requires 28.61
hours to transmit Lab reports from all PWSs to a State data center.
The time to transmit all Lab reports can be spread over the reporting interval to determine the
utilization of one communications line into the State data center. Using Arizona (AZ), for
example, we see that a single line utilization based on quarterly reporting is 0.73% for a 2.4
Kbps line, 0.37% for a 4.8 Kbps line, and 0.18% for a 9.6Kbps line. A single line utilization
based on samples taken each'month for all PWSs in Arizona would be 2.20% for a 2.4Kbps line,
1.10% for a 4.8Kbps line, and 0.55% for a 9.6Kbps line.
The values shown for a single line utilization can be used to estimate the number of dial-up lines
and/or leased lines needed at a State data center. Using California as an example, and assuming
samples are taken weekly and reported at 2.4Kpbs, shows that a single line is utilized 71.52%
of the time. If ten 2.4Kbps lines were employed at the State data center the utilization per line
would be 7.1%.
The utilization figures in Table DD-2 are based on a standard 8 hour per workday (as opposed
to multiple shift operation). The available time per quarter is 480 hours, per month is 160 hours,
and per week is 40 hours.
The utilization numbers shown in Table DD-2 are sufficiently low to provide a high confidence
that communications should not be a problem in the PWSS Information System, if care is taken
to optimize data transmission (i.e. use data compression, no transmittal of graphics, etc.). The
utilization numbers also assume report transmissions are spread over the reporting period.
Clearly, if all units attempted to report at once, there would be communication line congestion.
This assumption means a PWSS Communications Management Plan is an integral part of system
development. This plan must insure that transmissions are uniformly distributed over the
available reporting interval.
Assuming a single Federal data center (i.e., the NCC) receives Lab reports from 200,990 PWSs,
the following utilizations can be expected for samples reported quarterly, monthly, and weekly:
DD-3
-------
SDC-0055-012-TB-2009
December 31, 1992
One line* Quarterly
Monthly
Weeldv
2.4Kbps
4.8Kbps
9.6Kbps.
48.5%
24.2%
12.1%
145.4%
72.7%
36.3%
581.6%
290.8%
145.4%
Five lines: Quarterly Monthly Weekly
2.4Kbps
4.8Kbps
9.6Kbps
Ten lines *
2.4Kbps
4.8Kbps
9.6Kbps
9.7%
4.8%
2.4%
4.8%
2.4%
1.2%
29.1%
14.5%
7.3%
Monthly
14.5%
7.3%
3.6%
116.3%
58.2%
29.1%
Weekly
58.2%
29.1%
14.5%
The results of the analysis presented in this appendix are not intended to be an exact estimate of
communications requirements, but are presented here to provide an overall order of magnitude
estimate of communications needs. The order of magnitude estimate is useful in determining if
the concept of the PWSS Information System is feasible and not constrained by unreasonable
communications requirements.
DD-4
-------
TABLE DD-1
ESTIMATES OF NUMBER OF LAB REPORTS/MONTH FOR FULL CONTAMINANT REPORTING
§
STATE
AL
AK
AZ
AR
CA
CO
CT
OE
Fl
GA
HI
10
IL
IN
IA
KS
KY
LA
HE
HO
HA
HI
HN
HO
HS
HT
HE
NV
HH
HJ
NH
NY
NC
.NO
Oil
OK
POPULATION BASELINE
(HILLIONS) NUMBER OF
COMMUNITY
UATER
SVSTEHS
NUHBER OF CONTAMINANT REPORTS PER HONTH AS FUNCTION
OF SAMPLING FREQUENCY AT COMMUNITY UATER SYSTEMS
4.04
0.55
3.665
2.35
29.76
3.294
3.287
0.666
12.94
6.478
1.108
1.006
11.43
5.544
2.776
2.477
3.685
4.219
1.227
4.781
6.016
9.3
4.375
5.117
2.573
0.8
1.578
1.2
1.1
7.73
1.51
17.99
6.628
0.638
10.847
3.145
3355
457
3044
1952
24718
2736
2730
553
10748
5380
920
836
9493
4605
2306
2057
3061
3504
1019
3971
4997
7724
3634
4250
2137
664
1311
997
914
6420
1254
14942
5505
530
9009
2612
QUARTERLY
1118
152
1015
651
8239
912
910
184
358J
1791
307
279
3164
1535
769
686
1020
1168
340
1324
1666
2575
1211
1417
712
221
437
332
305
2140
418
4981
1835
177
3003
871
MONTHLY
3355
457
3044
1952
24718
2736
2730
553
10748
5380
920
836
9493
4605
2306
2057
3061
3504
1019
3971
4997
7724
3634
4250
2137
664
1311
997
914
6420
1254
14942
5505
530
9009
2612
UEEKLV
13422
1827
12176
7807
98870
10944
10920
2213
42990
21522
3681
3342
37973
18419
9223
8229
12243
14017
4076
15884
19987
30897
14535
17000
8548
2658
5243
3987
3654
25681
5017
59767
22020
2120
36037
10449
-------
TABLE DO-I (continued)
S1A1E POPULATION BASELINE NUMBER OF CONTAMINANT REPORIS PER MONTH AS FUNCTION
(MILLIONS) NUMBER OF OF SAMPLING FREQUENCY AT COHHUNITV UAIER SYSTEMS
COMMUNITY
WATER
SYSTEMS QUARTERLY MONTHLY WEEKLY
OR 2.842 2360 787 2360 9442
PA 11.B81 9868 3289 9868 39472
HI 1.003 B» 278 833 3332
SC 3.486 2895 965 2B95 11581
SD 0.696 578 193 578 2312
TN 4.877 4051 1350 4051 16203
IX 16.986 14108 4703 14108 56432
UT 1.722 1430 477 1430 5721
VA 6.187 5139 1713 5139 20555
WA 4.866 4042 1347 4042 16166
UV 1.793 1489 496 1489 5957
Ul 4.891 4062 1354 4062 16249
UV 0.4S3 376 125 376 1505
o
0
i
oo
' 00
-------
TABLE DD-2
8
i
so
STATE
AL
AK
AI
AR
CA
CO
CT
DE
FL
COMMUNICATIONS UTILIZATION FOR FULL CONTAMINANT REPORTING
UTILIZATION OF COMMUNICATIONS CAPACITY FOR ONE LINE AT STATE
CENTRAL DATA LOCATION FOR REPORTING ALL CONTAMINANTS AT VARIED
-RVALS
NONTHLV WEEKLY
(160 hours) (40 hours)
LINE TRANSFER UHLIZAIIC
SPEED tIHE CENTRAL Of
IN REPORT INO
HOURS OUARTERLV
(480 houn
2.4Kbpa
4.8Kbpa
9.6 Kbps
2.4Kbpa
4.8Kbpa
9.6 Kbps
2.4Kbps
4.8Kbpa
9.6 Kbps
2.4Kbps
4.8Kbbs
9.6 Kbps
2.4Kbpa
4.8XbpB
9.6 Kbps
2.4Kbps
4.8KbpS
9.6Kbpa
2.4Kbpa
4.8Kbpa
9.6 Kbps
2.4Kbp*
4.8Kbpa
9.6 Kbps
2.4Kbpa
4.8Kbpa
9.6 Kbps
S.88
1.94
0.97
0.53
0.26
0.13
3.52
1.76
0.68
2.26
1.13
0.56
28.61
14.30
7.15
3.17
1.58
0.79
3.16
1.58
0.79
0.64
0.32
0.16
12.44
6.22
3.11
0.61X
0.40X
0.20X
0.11X
0.06X
0.03X
0.73X
0.37X
0.18X
0.47X
0.24X
0.12X
S.96X
2.98X
1.49X
0.66X
0.33X
0.16X
0.66X
0.33X
0.16X
0.13X
0.07X
0.03X
2.59X
1.30X
0.65X
2.43X
1.21X
0.61X
0.33X
0.17X
0.08X
2.20X
1.10X
0.55X
1.41X
0.7IX
0.35X
17.8BX
8.94X
4.47X
1.98X
0.99X
0.49X
1.97X
0.99X
0.49X
0.40X
0.20X
0.10X
7.77X
3.89X
1.94X
9.71X
4.85X
2.43X
1.32X
0.665!
0.33X
8.B1X
4.40X
2.20X
5.65X
2.B2X
1.41X
71.52X
35.76X
17.8BX
7.92X
3.96X
1.98X
7.90X
3.95X
1.97X
1.60X
0.80X
0.40X
31.10X
15.55X
7.77X
-------
table OD-2 (continued)
o
o
SIAIE
GA
HI
ID
IL
IN
IA
KS
KV
LA
HE
LINE TRANSFER UTILI2ATIC
SPEED IIHE CENTRAL Of
IN REPORTING
HOURS QUARTERLY
(480 hourc
2.4Kbps
4.8Kbps
9.6 Kbps
2.4Kbps
4.BKbps
9.6 Kbps
2.4Kbps
4.8Kbps
9.6 Kbps
2.4Kbps
4.8Kbps
9.6 Kbps
2.4Kbps
4.8Kbps
9.6 Kbps
2.4Kbps
4.8Kbps
9.6 Kbps
2.4Kbps
4.8KbpS
9.6 Kbps
2.4Kbps
4.8Ktaps
9.6 Kbps
2.4Kbp>
4.8Kbps
9.6 Kbps
2.4Kbps
4.8Kbps
9.6 Kbps
6.23
3.11
1.56
1.07
0.51
0.27
0.96
0.48
0.24
10.99
5.49
2.75
5.33
2.66
1.33
2.67
1.33
0.67
2.38
1.19
0.60
3.54
1.77
0.89
4.06
2.03
1.01
1.1B
0.59
0.29
I.SOX
0.6SX
0.32X
0.22X
0.11X
0.06X
0.20X
0.10X
O.OSX
2.29X
1.14X
0.57X
1.11X
0.56X
0.28X
O.S6X
0.28X
0.14X
O.SOX
0.25X
0.12X
0.74X
0.37X
0.18X
0.84X
0.42X
0.21X
0.2SX
O.T2X
0.06X
UTILIZATION OF COMMUNICATIONS CAPACITY FOR ONE LINE AT STATE
CENTRAL DATA LOCATION FOR REPORTING ALL CONTAMINANTS AT VARIED
RVALS
MONTHLY MEEKLY
(160 hours) (40 hours)
3.B9X
1.95X
0.97X
0.67X
0.33X
0.17X
0.60X
0.30X
0.15X
87X
43X
72X
3.33X
1.67X
O.B3X
1.67X
O.B3X
0.42X
1.49X
0.74X
0.37X
21X
11X
0.5SX
53X
27X
0.63X
0.74X
0.37X
0.1BX
1S.57X
7.78%
3.89X
2.66K
1.33X
0.67X
2.40X
1.20X
0.60X
27.47X
13.73X
6.arc
13.32X
6.66X
3.33X
6.67X
3.34X
1.67X
S.95X
2.98X
1.49X
8.86X
4.4.3X
2.21X
10.14X
5.07X
2.S3X
2.95X
1.47X
0.74X
-------
TABLE 00-2 (continued)
SIATE
ND
Nl
MM
HO
HS
NT
HE
NV
NH
LINE TRANSFER UTILIZATK
SPEED TINE CENTRAL D<
IN REPORTING
HOURS QUARTERLY
(480 houri
2.4Kbps
4.8Kbps
9.6 Kbps
2.4Kbps
4.8Kbpa
9.6 Kbps
2.4Kbps
4.8Kbps
9.6 Kbps
2.4Kbps
4.8Kbps
9.6 Kbps
2.4Kfapa
4.8Kbps
9.6 Kbps
2.4Kbps
4.8Kbps
9.6 Kbps
2.4Kbps
4.8Kbps
9.6 Kbps
2.4Kbps
4.8Kbps
9.6Kbps
2.4Kbpa
4.8Kbps.
9.6 Kbps
2.4Kbps
4.8Kbps
9.6 Kbps
4.60
2.30
1.15
5.78
2.89
1.4S
8.94
4.47
2.24
4.21
2.10
1.05
4.92
2.46
1.23
2.47
1.24
0.62
0.77
0.38
0.19
1.52
0.76
0.38
1.15
0.58
0.29
1.06
0.53
0.26
0.96X
0.48X
0.24X
1.20X
0.60X
0.30X
1.86X
0.93X
0.47X
0.8BX
0.44X
0.22X
1.02X
0.51X
0.26X
0.52X
0.26X
0.13X
0.16X
O.OBX
0.04X
0.32X
0.16X
O.OBX
0.24X
0.12X
0.06X
0.22X
0.11X
0.06X
UTILIZATION OF COMMUNICATIONS CAPACITY FOR ONE LINE AT STATE
CENTRAL DATA LOCATION FOR REPORTING ALL CONTANINANTS AT VARIED
RVALS
MONTHLY WEEKLY
(160 hours) (40 hours)
2.87X
1.44X
0.72X
S.61X
1.81X
0.90X
5.S9X
2.79X
1.40X
2.63X
1.31X
0.66X
3.07X
1.54X
0.77X
t.SSX
0.77X
0.39X
0.4BX
0.24X
0.12X
0.93X
0.47X
0.24X
0.72X
0.36X
0.18X
0.66X
0.33X
0.17X
11.49X
S.74X
2.67X
14.46X
7.23X
3.6IX
22.3SX
11.W
5.59X
10.SIX
5.26X
2.63X
12.30X
6.15X
3.07X
6.16X
3.09X
1.5SX
1.92X
0.96X
0.4BX
3.79X
1.90X
0.9SX
2.88X
1.44X
0.72X
2.64X
1.32X
0.66X
-------
TABLE DD-2 (continued)
STATE
HJ
ttc
D
O
OH
OK
OR
PA
Rl
LINE TRANSFER UTILI2ATIC
SPEED TIME CENTRAL Of
IN REPORTING
HOURS QUARTERLY
(480 houri
2.4Kbps
4.8Kbps
9.6 Kbps
2.«Kbps
4.8Kbps
9.6 Kbps
2.4Kbps
4.8Kbps
9.6 Kbps
2.4Kbps
4.8Kbps
9.6 Kbps
2.4Kbps
4.8Kbps
9.6 Kbps
2.4Kbps
4.8Kbps
9.6 Kbps
2.4Kbps
4.8Kbps
9.6 Kbps
2.4Kbps
4.8Kbps
9.6 Kbps
2.4Kbps
4.8Kbps
9.6 Kbps
2.4Kbps
4.8Kbps
9.6 Kbps
7.43
3.72
1.86
1.4S
0.73
0.36
17.29
8.65
4.32
6.37
3.19
1.59
0.61
0.31
0.15
10.43
5.21
2.61
3.02
1.51
0.76
2.73
1.37
0.68
11.42
5.71
2.86
0.96
0.48
0.24
1.55X
0.77X
0.39X
0.30X
0.15X
O.OBX
3.60X
1.BOX
0.90X
1.33X
0.66X
0.33X
0.13X
0.06X
0.03X
2.17X
1.09X
0.54X
0.63X
0.31X
0.16X
0.57X
0.28X
0.14X
2.3BX
1.19X
O.S9X
Q.20X
0.10X
0.05X
UTILIZATION OF COMMUNICATIONS CAPACITY FOR ONE LINE AT STATE
CENTRAL DATA LOCATION FOR REPORTING ALL CONTAMINANTS AT VARIED
RVALS
MONTHLY WEEKLY
(160 hours) (40 hours)
4.64X
2.32X
1.16X
0.91X
0.45X
0.23X
10.BIX
5.40X
2.70X
3.98X
1.99X
1.00X
0.38X
0.19X
0.10X
6.52X
3.26X
1.63X
1.B9X
0.94X
0.47X
1.71X
0.8SX
0.43X
7.14X
3.S7X
1.78X
0.60X
0.30X
0.15X
18.5BX
9.29X
4.6V/.
3.63X
1.81X
0.91X
43.23X
21.62X
10.81%
15.93X
7.96JS
3.98X
1.53X
0.77%
0.3BX
26.07X
13.03%
6.52X
7.S6X
3.78%
1.89X
6.83X
3.42X
1.71%
28.55X
14.2BX
7.14X
2.40X
1.20X
0.60X
-------
TABLE OD-2 (continued)
SIATE
SC
SD
TN
TX
UI
VA
UA
UV
UI
UV
LINE TRANSFER UIILIZATK
SPEED 1IKE CENTRAL 01
IN REPORTING
HOURS QUARTERLY
(480 houn
2.4Kbps
4.8Kbps
9.6 Kbps
2.4Kbps
4.BKbpS
9.6 Kbps
2.4Kbps
A.BKbps
9.6 Kbps
2.4Kbps
4.8Kbps
9.6 Kbps
2.4Kbps
4.8Kbps
9.6 Kbps
2.4Kbps
4.BKbps
9.6 Kbps
2.4Kbps
4.BKbps
9.6 Kbps
2.«Kbps
4.8Kbps
9.6 Kbps
2.4Kbps
4.8Kbps
9.6 Kbps
2.4Kbps
4.8Kbps
9.6 Kbps
3.J5
1.68
0.84
0.67
0.33
0.17
4.69
2.34
1.17
16.33
8.16
4.08
1.66
0.63
0.41
5.95
2.97
1.49
4.68
2.34
1.17
1.72
0.86
0.43
4.70
2.35
1.18
0.44
0.22
0.11
0.70X
0.3SX
0.17X
0.14X
0.07X
0.03X
0.9BX
0.49X
0.24X
3.40X
1.70X
0.85X
0.34X
0.17X
0.09X
1.24X
0.62X
0.31X
0.97X
0.49X
0.24X
0.36X
o.tax
0.09X
0.98X
0.49X
0.24X
0.09X
O.OSX
0.02X
UTILIZATION OF COMMUNICATIONS CAPACITY FOR ONE LINE AT STATE
CENTRAL DATA LOCATION FOR REPORTING ALL CONTAMINANTS AT VARIED
RVALS
HONTHLV UECKLT
(160 hours) (40 hours)
2.09X
1.05X
0.52X
0.42X
0.21X
0.10X
2.93X
1.47X
0.73X
10.21X
5.10X
2.S5X
1.03X
0.52X
0.26X
3.72X
1.06X
0.93X
2.92X
1.46X
0.73X
1.08X
0.54X
0.27X
2.94X
1.47X
0.73X
0.27X
0.14X
0.07X
B.38X
4.19X
2.09X
1.67X
0.84X
0.42X
11.72X
5.86X
2.93X
40.82X
20.41X
10.21X
4.14X
2.07X
1.03X
14.87X
7.43X
3.72X
11.69X
S.8SX
2.92X
4.31X
2.15X
1.08X
11.75X
5.8BX
2.94X
1.09X
0.54X
0.27X
m
.i
i
g
DD- 13
-------
w
-------
SDC-0055-012-TB-2009
December 31, 1992
Appendix EE
Data Store by User
This appendix contains a matrix showing data stores that support the user groups. A "1"
indicates that a particular data store is utilized Realtime, "2" shows Historical usage of a Data
Store, "3" represents Ownership, while a blank indicates no involvement
-------
PAGE NOT
AVAILABLE
DIGITALLY
------- |